Musterbestellungen / Plugin-Produkte ohne echtes Item behandeln #33

New issue

Open

opened 2026-08-22 20:19:38 +00:00 by csaeum · 1 comment

csaeum commented

2026-08-22 20:19:38 +00:00

Owner

Zu klären:

Wie erkennen wir eine solche Position zuverlässig? Kandidaten:
- lineItem.type (analog zu "product"/"credit"/"custom" — hat das Plugin einen eigenen Typ?)
- Artikelnummer-Präfix/-Suffix (fragiler, abhängig von einer Namenskonvention, die sich ändern kann)
- Präfix/Suffix am Produktnamen (noch fragiler)
- → Live gegen das konkrete Plugin prüfen, welches Signal tatsächlich zuverlässig vorhanden ist, bevor eine Lösung gebaut wird.
Wie bilden wir sowas in ERPNext ab? ERPNext kennt keine echten Freitextpositionen ohne Item-Verknüpfung (Sales Order Item.item_code ist Pflicht-Link auf Item). Optionen:
- Ein generisches Platzhalter-/Sammel-Item (ähnlich dem in #27 für Versandkosten gebauten Muster)
- Automatisches Anlegen eines echten (nicht lagergeführten) Items pro Muster-Artikel
- Position beim Import bewusst überspringen/nur loggen, nicht in die Sales Order übernehmen

Bezug zu #27: Der aktuelle Bestellungsimport (#27) überspringt die komplette Bestellung, wenn eine Position nicht auf ein ERPNext-Item aufgelöst werden kann ("fail loud, nicht raten"). Ohne Erkennung würde jede Bestellung mit einer Musterposition dauerhaft übersprungen — dieses Issue klärt, wie solche Positionen stattdessen korrekt (nicht nur "irgendwie durchgewunken") behandelt werden.

Ein Shopware-Plugin ermöglicht Musterbestellungen ("Sample Orders"). Die darin enthaltenen "Artikel" sind keine echten Produkte — weder im Shopware-Produktkatalog noch (dadurch) als ERPNext Item vorhanden. **Zu klären:** - Wie erkennen wir eine solche Position zuverlässig? Kandidaten: - `lineItem.type` (analog zu `"product"`/`"credit"`/`"custom"` — hat das Plugin einen eigenen Typ?) - Artikelnummer-Präfix/-Suffix (fragiler, abhängig von einer Namenskonvention, die sich ändern kann) - Präfix/Suffix am Produktnamen (noch fragiler) - → Live gegen das konkrete Plugin prüfen, welches Signal tatsächlich zuverlässig vorhanden ist, bevor eine Lösung gebaut wird. - Wie bilden wir sowas in ERPNext ab? ERPNext kennt keine echten Freitextpositionen ohne Item-Verknüpfung (`Sales Order Item.item_code` ist Pflicht-Link auf `Item`). Optionen: - Ein generisches Platzhalter-/Sammel-Item (ähnlich dem in #27 für Versandkosten gebauten Muster) - Automatisches Anlegen eines echten (nicht lagergeführten) Items pro Muster-Artikel - Position beim Import bewusst überspringen/nur loggen, nicht in die Sales Order übernehmen **Bezug zu #27**: Der aktuelle Bestellungsimport (#27) überspringt die komplette Bestellung, wenn eine Position nicht auf ein ERPNext-Item aufgelöst werden kann ("fail loud, nicht raten"). Ohne Erkennung würde jede Bestellung mit einer Musterposition dauerhaft übersprungen — dieses Issue klärt, wie solche Positionen stattdessen korrekt (nicht nur "irgendwie durchgewunken") behandelt werden.

csaeum added the

Artikel

Bestellungen

labels

2026-08-22 20:19:45 +00:00

csaeum commented

2026-08-22 20:21:11 +00:00

Author

Owner

Live-Fund beim Bestellungsimport-Test (#27), direkt aus dem echten DDEV-Testshop: eine reale Bestellung (Nr. 10000) besteht ausschließlich aus zwei Musterpositionen.

Wichtig für die Erkennungsfrage — lineItem.type reicht NICHT aus: beide Musterpositionen haben type: "product", identisch zu einer echten Position. Die zuverlässige Erkennung ist stattdessen:

"payload": {
  "isSample": true,
  "originalProductId": "019a2fe58ed67203ba841114cf13ccac",
  ...
}

payload.isSample (Boolean) ist ein explizites, vom Plugin gesetztes Flag — deutlich robuster als Artikelnummer- oder Namens-Präfix (der Name trägt zwar auch ein "Muster - "-Präfix, aber das ist reiner Anzeigetext, kein stabiles Erkennungsmerkmal).

Zweiter wichtiger Fund: referencedId/productId der Musterposition zeigen auf die echte Produkt-ID (payload.originalProductId ist identisch) — es handelt sich technisch nicht um ein separates "Phantom-Produkt", sondern um dasselbe reale Produkt, nur mit unitPrice: 0/totalPrice: 0. D.h. die Position lässt sich über die bereits bestehende shopware_product_id/shopware_variant_id-Verknüpfung (#16/#19) ganz normal auf ein echtes ERPNext-Item auflösen — es muss dafür kein Platzhalter-/Sammel-Item erfunden werden. Die eigentliche Frage ist nur noch: soll eine solche Position mit Rate 0 in die Sales Order übernommen werden (aktuell würde #27s Code das einfach tun, da taxRate/price sauber auf 0 auflösen) oder soll sie bewusst herausgefiltert/anders markiert werden (z. B. eigenes Flag auf der Sales Order Item-Zeile, damit Reporting sie von echten Verkäufen unterscheiden kann)?

Live-Fund beim Bestellungsimport-Test (#27), direkt aus dem echten DDEV-Testshop: eine reale Bestellung (Nr. 10000) besteht ausschließlich aus zwei Musterpositionen. **Wichtig für die Erkennungsfrage — `lineItem.type` reicht NICHT aus**: beide Musterpositionen haben `type: "product"`, identisch zu einer echten Position. Die zuverlässige Erkennung ist stattdessen: ```json "payload": { "isSample": true, "originalProductId": "019a2fe58ed67203ba841114cf13ccac", ... } ``` `payload.isSample` (Boolean) ist ein explizites, vom Plugin gesetztes Flag — deutlich robuster als Artikelnummer- oder Namens-Präfix (der Name trägt zwar auch ein "Muster - "-Präfix, aber das ist reiner Anzeigetext, kein stabiles Erkennungsmerkmal). **Zweiter wichtiger Fund**: `referencedId`/`productId` der Musterposition zeigen auf die **echte** Produkt-ID (`payload.originalProductId` ist identisch) — es handelt sich technisch nicht um ein separates "Phantom-Produkt", sondern um dasselbe reale Produkt, nur mit `unitPrice: 0`/`totalPrice: 0`. D.h. die Position lässt sich über die bereits bestehende `shopware_product_id`/`shopware_variant_id`-Verknüpfung (#16/#19) ganz normal auf ein echtes ERPNext-Item auflösen — es muss dafür kein Platzhalter-/Sammel-Item erfunden werden. Die eigentliche Frage ist nur noch: soll eine solche Position mit Rate 0 in die Sales Order übernommen werden (aktuell würde #27s Code das einfach tun, da `taxRate`/`price` sauber auf 0 auflösen) oder soll sie bewusst herausgefiltert/anders markiert werden (z. B. eigenes Flag auf der Sales Order Item-Zeile, damit Reporting sie von echten Verkäufen unterscheiden kann)?

csaeum referenced this issue

2026-08-22 20:26:25 +00:00

Bestellungen aus Shopware als Sales Order in ERPNext importieren #27

csaeum referenced this issue from a commit

2026-08-22 20:41:07 +00:00

feat(shopware): import Shopware orders as Sales Orders via polling (closes #27)