Nur geänderte Bestände pushen (Delta-Sync) #22

New issue

Closed

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

csaeum commented

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

(Migrated from gitlab.localdomain)

Bestandssync optimieren: nur Artikel pushen deren Bestand sich seit dem letzten Sync geändert hat:

Letzten übertragenen Bestand pro Artikel und Warehouse speichern (Custom Field oder eigener DocType)
Vor dem Push vergleichen ob sich der Bestand geändert hat
Nur geänderte Artikel an Shopware übertragen
Zeitstempel des letzten Syncs speichern
Vollsync weiterhin manuell auslösbar halten

Bestandssync optimieren: nur Artikel pushen deren Bestand sich seit dem letzten Sync geändert hat: - Letzten übertragenen Bestand pro Artikel und Warehouse speichern (Custom Field oder eigener DocType) - Vor dem Push vergleichen ob sich der Bestand geändert hat - Nur geänderte Artikel an Shopware übertragen - Zeitstempel des letzten Syncs speichern - Vollsync weiterhin manuell auslösbar halten

csaeum commented

2026-08-22 17:34:09 +00:00

Owner

Umgesetzt über zwei neue Custom Fields auf Item (shopware_stock_synced_qty, shopware_stock_synced_on) und einen neuen Pflicht-Parameter full_sync: bool (bewusst ohne Default) auf #20s push_stock():

full_sync=False: ein Item wird übersprungen (skipped_unchanged), wenn der frisch berechnete Bestand exakt dem zuletzt erfolgreich gepushten Wert entspricht und das Item schon mal synchronisiert wurde — kein API-Call. Wird ab jetzt vom stündlichen Scheduler-Job (#21, sync_stock_hourly()) genutzt.
full_sync=True: pusht immer alle Items, ignoriert die Änderungserkennung komplett — bleibt exakt das Verhalten des manuellen "Push Stock"-Buttons ("Vollsync weiterhin manuell auslösbar halten").
Nach jedem erfolgreichen Push (in beiden Modi) werden die beiden Sync-Felder aktualisiert, damit auch ein Vollsync die Vergleichsbasis für künftige Delta-Läufe aktuell hält.

Live entdeckter, echter Bug während der Verifikation: der allererste Delta-Lauf nach dem Deploy hat fälschlich 10 von 11 Test-Items als "unverändert" übersprungen — obwohl sie noch nie synchronisiert worden waren. Ursache: shopware_stock_synced_qty ist ein Int-Custom-Field, und Frappe befüllt die DB-Spalte für Bestandsdatensätze standardmäßig mit 0, nicht NULL — nicht unterscheidbar von "wurde auf echten Wert 0 synchronisiert", was bei genau diesen Test-Items auch der reale Bestand war. Behoben, indem stattdessen shopware_stock_synced_on (Datetime, bleibt bei Frappe korrekt None/ungesetzt) als "nie synchronisiert"-Erkennung dient. Dokumentiert in docs/stolperfallen.md als generelle Frappe-Falle.

Live-Verifikation (alle vier Fälle bestätigt):

Erstsync (full_sync=False): alle 11 verlinkten Items gepusht.
Zweiter Lauf ohne Bestandsänderung: alle 11 als skipped_unchanged, kein PATCH (Zeitstempel unverändert geblieben).
Bestand geändert (Stock Entry): dritter Lauf pusht nur das geänderte Item, Rest bleibt skipped_unchanged.
full_sync=True direkt danach (keine weitere Änderung): pusht trotzdem alle 11, Shopware-Wert per POST /api/search/product bestätigt.

Testdaten sind nach dem Test wieder gelöscht. Damit ist Milestone 6 ("Bestandssync") komplett (#20-#22).

Volle Begründung: docs/architecture.md#issue-22

Umgesetzt über zwei neue Custom Fields auf `Item` (`shopware_stock_synced_qty`, `shopware_stock_synced_on`) und einen neuen Pflicht-Parameter `full_sync: bool` (bewusst ohne Default) auf #20s `push_stock()`: - `full_sync=False`: ein Item wird übersprungen (`skipped_unchanged`), wenn der frisch berechnete Bestand exakt dem zuletzt erfolgreich gepushten Wert entspricht und das Item schon mal synchronisiert wurde — kein API-Call. Wird ab jetzt vom stündlichen Scheduler-Job (#21, `sync_stock_hourly()`) genutzt. - `full_sync=True`: pusht immer alle Items, ignoriert die Änderungserkennung komplett — bleibt exakt das Verhalten des manuellen "Push Stock"-Buttons ("Vollsync weiterhin manuell auslösbar halten"). - Nach jedem erfolgreichen Push (in beiden Modi) werden die beiden Sync-Felder aktualisiert, damit auch ein Vollsync die Vergleichsbasis für künftige Delta-Läufe aktuell hält. **Live entdeckter, echter Bug während der Verifikation**: der allererste Delta-Lauf nach dem Deploy hat fälschlich 10 von 11 Test-Items als "unverändert" übersprungen — obwohl sie noch nie synchronisiert worden waren. Ursache: `shopware_stock_synced_qty` ist ein Int-Custom-Field, und Frappe befüllt die DB-Spalte für Bestandsdatensätze standardmäßig mit `0`, nicht `NULL` — nicht unterscheidbar von "wurde auf echten Wert 0 synchronisiert", was bei genau diesen Test-Items auch der reale Bestand war. Behoben, indem stattdessen `shopware_stock_synced_on` (Datetime, bleibt bei Frappe korrekt `None`/ungesetzt) als "nie synchronisiert"-Erkennung dient. Dokumentiert in `docs/stolperfallen.md` als generelle Frappe-Falle. Live-Verifikation (alle vier Fälle bestätigt): 1. Erstsync (`full_sync=False`): alle 11 verlinkten Items gepusht. 2. Zweiter Lauf ohne Bestandsänderung: alle 11 als `skipped_unchanged`, kein PATCH (Zeitstempel unverändert geblieben). 3. Bestand geändert (Stock Entry): dritter Lauf pusht nur das geänderte Item, Rest bleibt `skipped_unchanged`. 4. `full_sync=True` direkt danach (keine weitere Änderung): pusht trotzdem alle 11, Shopware-Wert per `POST /api/search/product` bestätigt. Testdaten sind nach dem Test wieder gelöscht. Damit ist **Milestone 6 ("Bestandssync") komplett** (#20-#22). Volle Begründung: [docs/architecture.md#issue-22](https://git.web-seo-consulting.eu/Frappe-Projekte/ecommerce_integrations/src/branch/shopware6-dach/docs/architecture.md#issue-22-delta-stock-sync)

csaeum closed this issue

2026-08-22 17:34:11 +00:00

csaeum referenced this issue from a commit

2026-08-22 17:38:57 +00:00

feat(shopware): add delta stock sync (#22)

csaeum referenced this issue

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

Artikelbilder aus ERPNext an Shopware pushen #31

csaeum referenced this issue from a commit

2026-08-23 16:19:40 +00:00

feat(shopware): push item images (cover + gallery) to Shopware (closes #31)