Bug in EcommerceCustomer.sync_customer(): _("Individual") speichert übersetzten Wert statt Select-Option #34

Open
opened 2026-08-22 21:02:03 +00:00 by csaeum · 1 comment
Owner

Problem

ecommerce_integrations/controllers/customer.py::EcommerceCustomer.sync_customer()
(gemeinsame Basisklasse für alle Connectors, u. a. genutzt vom bestehenden
Shopify-Connector shopify/customer.py:ShopifyCustomer und von unserem neuen
shopware6/customer.py:ShopwareCustomer, #28) setzt beim Anlegen eines neuen
Customers:

"customer_type": _("Individual"),

_() übersetzt den String vor dem Speichern anhand der Sprache der Site
(System Settings.language). Auf einer deutschsprachigen Site (language = "de")
wird dadurch literal "Einzelperson" in die Datenbank geschrieben.

Das Core-Feld Customer.customer_type (Select) hat aber weiterhin die
unübersetzten, englischen Optionen als gültige Werte:
Company\nIndividual\nPartnership. ERPNext lehnt "Einzelperson" deshalb mit
einem ValidationError ab:

Kundentyp kann nicht "Einzelperson" sein . Es sollte aus "Unternehmen",
"Einzelperson", "GbR" sein.

Live-Reproduktion (erpnext-sync Testbench)

frappe.db.get_single_value("System Settings", "language")  # "de"
frappe.local.lang  # "de"
from frappe import _
_("Individual")  # "Einzelperson"

EcommerceCustomer.sync_customer()'s eigener customer.insert(...)-Aufruf
wirft den ValidationError bereits beim allerersten neuen Customer.

Tragweite

Kein Shopware-spezifisches Problem — betrifft jeden Connector, der
EcommerceCustomer.sync_customer() nutzt (aktuell: Shopify, ab #28: Shopware),
sobald die Site auf Deutsch (oder eine andere Nicht-Englisch-Sprache mit
Übersetzung für "Individual") läuft. Für dieses DACH-Projekt ist das der
Standardfall, nicht die Ausnahme.

Vorschlag

_("Individual") durch den literalen, unübersetzten Wert "Individual"
ersetzen — der gespeicherte Wert eines Select-Felds darf nicht von der
UI-Sprache abhängen, nur das Label wird beim Anzeigen übersetzt.

Vorgehen für uns

Da wir noch keinen PR an Frappe/ERPNext senden und uns weiterhin mit dem
Upstream-Repo syncen, bis alles geprüft ist:

  1. Upstream-Issue bei frappe/ecommerce_integrations erstellen (oder an ein
    bestehendes anhängen) — [wird verlinkt, sobald angelegt].
  2. Bis zur Lösung dort: lokaler Workaround in shopware6/customer.py
    (Basisklasse controllers/customer.py bleibt unangetastet, um beim
    nächsten Sync mit Upstream keine Konflikte zu erzeugen).
  3. Sobald Upstream den Fix übernommen hat und wir resynct haben: lokalen
    Workaround wieder entfernen, dieses Issue schließen.

Gefunden während der Live-Verifikation von #28 (Kundenanlage aus
Shopware-Bestellungen).

## Problem `ecommerce_integrations/controllers/customer.py::EcommerceCustomer.sync_customer()` (gemeinsame Basisklasse für alle Connectors, u. a. genutzt vom bestehenden Shopify-Connector `shopify/customer.py:ShopifyCustomer` und von unserem neuen `shopware6/customer.py:ShopwareCustomer`, #28) setzt beim Anlegen eines neuen Customers: ```python "customer_type": _("Individual"), ``` `_()` übersetzt den String **vor dem Speichern** anhand der Sprache der Site (`System Settings.language`). Auf einer deutschsprachigen Site (`language = "de"`) wird dadurch literal `"Einzelperson"` in die Datenbank geschrieben. Das Core-Feld `Customer.customer_type` (Select) hat aber weiterhin die unübersetzten, englischen Optionen als gültige Werte: `Company\nIndividual\nPartnership`. ERPNext lehnt `"Einzelperson"` deshalb mit einem `ValidationError` ab: ``` Kundentyp kann nicht "Einzelperson" sein . Es sollte aus "Unternehmen", "Einzelperson", "GbR" sein. ``` ## Live-Reproduktion (erpnext-sync Testbench) ```python frappe.db.get_single_value("System Settings", "language") # "de" frappe.local.lang # "de" from frappe import _ _("Individual") # "Einzelperson" ``` `EcommerceCustomer.sync_customer()`'s eigener `customer.insert(...)`-Aufruf wirft den `ValidationError` bereits beim allerersten neuen Customer. ## Tragweite Kein Shopware-spezifisches Problem — betrifft **jeden** Connector, der `EcommerceCustomer.sync_customer()` nutzt (aktuell: Shopify, ab #28: Shopware), sobald die Site auf Deutsch (oder eine andere Nicht-Englisch-Sprache mit Übersetzung für "Individual") läuft. Für dieses DACH-Projekt ist das der Standardfall, nicht die Ausnahme. ## Vorschlag `_("Individual")` durch den literalen, unübersetzten Wert `"Individual"` ersetzen — der gespeicherte Wert eines Select-Felds darf nicht von der UI-Sprache abhängen, nur das Label wird beim Anzeigen übersetzt. ## Vorgehen für uns Da wir noch keinen PR an Frappe/ERPNext senden und uns weiterhin mit dem Upstream-Repo syncen, bis alles geprüft ist: 1. Upstream-Issue bei `frappe/ecommerce_integrations` erstellen (oder an ein bestehendes anhängen) — [wird verlinkt, sobald angelegt]. 2. Bis zur Lösung dort: **lokaler Workaround** in `shopware6/customer.py` (Basisklasse `controllers/customer.py` bleibt unangetastet, um beim nächsten Sync mit Upstream keine Konflikte zu erzeugen). 3. Sobald Upstream den Fix übernommen hat und wir resynct haben: lokalen Workaround wieder entfernen, dieses Issue schließen. Gefunden während der Live-Verifikation von #28 (Kundenanlage aus Shopware-Bestellungen).
Author
Owner

Upstream-Issue erstellt: https://github.com/frappe/ecommerce_integrations/issues/465

Nächster Schritt: lokaler Workaround in shopware6/customer.py, ohne controllers/customer.py anzufassen. Dieses Issue bleibt offen, bis der Upstream-Fix übernommen wurde und wir den Workaround wieder entfernt haben.

Upstream-Issue erstellt: https://github.com/frappe/ecommerce_integrations/issues/465 Nächster Schritt: lokaler Workaround in `shopware6/customer.py`, ohne `controllers/customer.py` anzufassen. Dieses Issue bleibt offen, bis der Upstream-Fix übernommen wurde und wir den Workaround wieder entfernt haben.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Frappe-Projekte/ecommerce_integrations#34
No description provided.