Tax Mapping DocType anlegen (pro Storefront) #23

New issue

Closed

opened 2026-05-10 16:45:37 +00:00 by csaeum · 1 comment

csaeum commented

2026-05-10 16:45:37 +00:00

(Migrated from gitlab.localdomain)

Einen neuen DocType Shopware Tax Mapping anlegen:

Felder: Shopware Storefront (Link), Steuersatz in % (Float), ERPNext Tax Template (Link auf Sales Taxes and Charges Template), Kundentyp (B2B/B2C/Alle)
Mehrere Einträge pro Storefront möglich
DocType über Frappe UI anlegen und JSON exportieren
In shopware6/doctype/shopware_tax_mapping/ ablegen

Einen neuen DocType `Shopware Tax Mapping` anlegen: - Felder: Shopware Storefront (Link), Steuersatz in % (Float), ERPNext Tax Template (Link auf `Sales Taxes and Charges Template`), Kundentyp (B2B/B2C/Alle) - Mehrere Einträge pro Storefront möglich - DocType über Frappe UI anlegen und JSON exportieren - In `shopware6/doctype/shopware_tax_mapping/` ablegen

csaeum commented

2026-08-22 18:00:35 +00:00

Owner

Umgesetzt, mit einer bewussten Scope-Anpassung gegenüber dem ursprünglichen Issue-Text.

Scope-Korrektur: Statt shopware_storefront + tax_rate + tax_template (Link → Sales Taxes and Charges Template) + customer_type wurde das Mapping auf shopware_storefront + tax_rate + tax_account (Link → Account) verschlankt. Grund: eine Shopware-Bestellung liefert Steuerbetrag und -satz bereits fertig berechnet (calculatedTaxes) sowie B2B/B2C bereits eindeutig über taxStatus (net/gross/tax-free) — ERPNext muss die Steuer beim Import also nicht neu berechnen (kein Tax Template nötig) und braucht kein eigenes customer_type-Feld (Dopplung zu taxStatus). Was Shopware nicht liefert, ist das Ziel-Konto — genau das schließt dieses Mapping, pro Storefront (nicht global), damit z. B. DE/AT/CH trotz ähnlicher Sätze nie versehentlich dasselbe Konto treffen.

alyf-de-Check (wie gewünscht, vor der Umsetzung): erpnext_germany, erpnext_datev, eu_einvoice geprüft — keine der drei Apps deckt ein Shopware-Storefront-zu-Konto-Mapping ab, alle arbeiten nur downstream auf bereits gesetzten ERPNext-Feldern (tax_category, taxes_and_charges). Kein Duplikat, sicher umsetzbar.

Umsetzung: neuer DocType Shopware Tax Mapping (shopware6/doctype/shopware_tax_mapping/), autoname format:{shopware_storefront}-{tax_rate} (erzwingt Eindeutigkeit pro Storefront+Satz ganz ohne eigene Validierung). Erstellt über Frappes eigenen DocType-Controller (frappe.get_doc(...).insert() bei temporär aktiviertem developer_mode, danach Dateien exportiert und developer_mode wieder deaktiviert) — kein manuell geschriebenes JSON.

Live verifiziert: zwei Mappings mit unterschiedlichem Satz für denselben Test-Storefront erfolgreich angelegt; ein drittes mit identischer Storefront+Satz-Kombination korrekt von Frappes eigener Namens-Eindeutigkeit abgelehnt (IntegrityError 1062). Testdaten anschließend entfernt. bench migrate sauber durchgelaufen, Tabelle existiert.

Details: docs/architecture.md#issue-23

Vorgemerkt für spätere Issues (nicht Teil von #23): #30 sollte beim Anwenden des Mappings auch ERPNext's natives tax_category-Feld mitpflegen statt eigene Parallel-Felder zu bauen; #25/#26 sollten für Reverse-Charge/Steuerbefreiung ebenfalls auf tax_category + erpnext_germanys tax_exemption_reason setzen statt Julians eigene Custom Fields zu kopieren.

Umgesetzt, mit einer bewussten Scope-Anpassung gegenüber dem ursprünglichen Issue-Text. **Scope-Korrektur**: Statt `shopware_storefront` + `tax_rate` + `tax_template` (Link → Sales Taxes and Charges Template) + `customer_type` wurde das Mapping auf `shopware_storefront` + `tax_rate` + `tax_account` (Link → Account) verschlankt. Grund: eine Shopware-Bestellung liefert Steuerbetrag und -satz bereits fertig berechnet (`calculatedTaxes`) sowie B2B/B2C bereits eindeutig über `taxStatus` (net/gross/tax-free) — ERPNext muss die Steuer beim Import also nicht neu berechnen (kein Tax Template nötig) und braucht kein eigenes `customer_type`-Feld (Dopplung zu `taxStatus`). Was Shopware nicht liefert, ist das Ziel-Konto — genau das schließt dieses Mapping, pro Storefront (nicht global), damit z. B. DE/AT/CH trotz ähnlicher Sätze nie versehentlich dasselbe Konto treffen. **alyf-de-Check** (wie gewünscht, vor der Umsetzung): `erpnext_germany`, `erpnext_datev`, `eu_einvoice` geprüft — keine der drei Apps deckt ein Shopware-Storefront-zu-Konto-Mapping ab, alle arbeiten nur downstream auf bereits gesetzten ERPNext-Feldern (`tax_category`, `taxes_and_charges`). Kein Duplikat, sicher umsetzbar. **Umsetzung**: neuer DocType `Shopware Tax Mapping` (`shopware6/doctype/shopware_tax_mapping/`), autoname `format:{shopware_storefront}-{tax_rate}` (erzwingt Eindeutigkeit pro Storefront+Satz ganz ohne eigene Validierung). Erstellt über Frappes eigenen DocType-Controller (`frappe.get_doc(...).insert()` bei temporär aktiviertem `developer_mode`, danach Dateien exportiert und `developer_mode` wieder deaktiviert) — kein manuell geschriebenes JSON. Live verifiziert: zwei Mappings mit unterschiedlichem Satz für denselben Test-Storefront erfolgreich angelegt; ein drittes mit identischer Storefront+Satz-Kombination korrekt von Frappes eigener Namens-Eindeutigkeit abgelehnt (`IntegrityError 1062`). Testdaten anschließend entfernt. `bench migrate` sauber durchgelaufen, Tabelle existiert. Details: [docs/architecture.md#issue-23](docs/architecture.md#issue-23-tax-mapping-doctype) Vorgemerkt für spätere Issues (nicht Teil von #23): #30 sollte beim Anwenden des Mappings auch ERPNext's natives `tax_category`-Feld mitpflegen statt eigene Parallel-Felder zu bauen; #25/#26 sollten für Reverse-Charge/Steuerbefreiung ebenfalls auf `tax_category` + `erpnext_germany`s `tax_exemption_reason` setzen statt Julians eigene Custom Fields zu kopieren.

csaeum closed this issue

2026-08-22 18:00:40 +00:00

csaeum referenced this issue from a commit

2026-08-22 18:02:50 +00:00

feat(shopware): add Shopware Tax Mapping doctype (closes #23)

csaeum referenced this issue

2026-08-22 18:27:36 +00:00

Steuerregeln DE (19%), AT (20%), CH (7.7%) implementieren #24

csaeum referenced this issue from a commit

2026-08-22 18:41:38 +00:00

docs(shopware): close #24 without code, DE tax already covered by ERPNext core

csaeum referenced this issue