Amazon-Angebote verwalten
Die Seite Amazon-Angebote verwalten ist die zentrale ArbeitsflĂ€che fĂŒr die Pflege deines Amazon-Sortiments in Flowkom. Sie ersetzt die alte Einzelzeilen- Zuordnung und bietet stattdessen eine JTL-artige Multi-Select-Tabelle mit Filterleiste, Bulk-Aktionen, konfigurierbaren Spalten und CSV-Export.
Wo finde ich die Seite? Einstellungen â Integrationen â Amazon-Integration auswĂ€hlen â Button âAlle Angebote verwaltenâ in der Karte âAmazon-Angeboteâ.
Der Workflow auf einen Blick
Einmal gelernt, bearbeitest du damit 50, 500 oder 5.000 Angebote in wenigen Sekunden â ohne zig Einzeldialoge.
Filterleiste
Die Toolbar kombiniert alle relevanten Filter frei miteinander. Jeder aktive Filter erscheint als Chip unterhalb der Leiste und kann einzeln entfernt werden. Der Button Alle zurĂŒcksetzen setzt sĂ€mtliche Filter auf Default.
| Filter | Zweck |
|---|---|
| Suche (SKU, ASIN, Titel) | Trigram-Index-basiert, schnelle Volltextsuche ĂŒber alle drei Spalten gleichzeitig |
| Marktplatz (Multi-Select) | z.B. nur DE + FR filtern; mehrere MarktplÀtze gleichzeitig möglich |
| Fulfillment | FBA, FBM oder beide |
| Status | Aktiv, Inaktiv, UnvollstÀndig oder alle |
| Nur nicht zugeordnet | Zeigt ausschlieĂlich Angebote ohne Flowkom-Artikel |
| Bestand = 0 | Zeigt nur FBA-Angebote mit 0 lieferbaren Einheiten in Amazon-Lagern |
Filter-State ist in der URL
Die aktiven Filter werden als Query-Parameter in die URL geschrieben. Das bedeutet:
- Teilbar: URL kopieren und an Kollegen schicken â sie sehen genau dieselbe Filter-Ansicht.
- Back-Button funktioniert: Browser-ZurĂŒck springt zur vorherigen Filterkombination.
- Bookmark-fÀhig: HÀufig genutzte Filter als Lesezeichen speichern.
FBA vs. FBM â was ist der Unterschied?
| Aspekt | FBA (Fulfillment by Amazon) | FBM (Fulfillment by Merchant) |
|---|---|---|
| Versand | Amazon (aus FBA-Lager) | Du selbst (aus deinem Flowkom-Lager) |
| Bestand relevant | FBA-Lagerbestand wird von Amazon gemeldet | Dein Flowkom-Bestand wird an Amazon gepusht |
| Default-Mapping | SKU mit optionalem -FBA-Suffix wird automatisch auf den Basisartikel gemappt | Exakter SKU-Match, Fallback ohne -FBM-Suffix |
| Typische Arbeit auf dieser Seite | Altlasten und Cross-Marketplace-Mapping | Mapping bei SKU-Umbenennungen, Fremdangebote |
| Badge-Farbe | grĂŒn | blau |
Selektion & Bulk-Aktionen
Zeilen markieren
- Einzelne Zeile: Checkbox in der Zeile.
- Ganze Page: Checkbox im Tabellen-Header (wirkt nur auf sichtbare 50 Zeilen).
- Alle gefilterten: Sobald Header-Checkbox gesetzt ist und mehr als eine Seite Treffer existiert, erscheint der Link âAlle N gefilterten Angebote auswĂ€hlenâ. Der Bulk-Request arbeitet dann gegen den kompletten Filter, nicht nur gegen die sichtbare Page.
Die Auswahl ĂŒberlebt Page-Wechsel. Wechselst du hingegen die Filter, fragt Flowkom einmal nach, ob du die Auswahl verwerfen willst â damit niemand aus Versehen an Zeilen schreibt, die er gerade nicht im Blick hatte.
Die drei Bulk-Aktionen
| Aktion | Was passiert |
|---|---|
| Zuordnen | Ăffnet den Produkt-Picker. Der gewĂ€hlte Flowkom-Artikel wird auf alle markierten Zeilen geschrieben. Danach lĂ€uft automatisch die Cross-Marketplace-Propagation, sodass z.B. eine Zuordnung auf DE auch auf FR/IT ĂŒbernommen wird. |
| Zuordnung aufheben | Entfernt den Flowkom-Artikel-Link von allen markierten Zeilen â die Amazon-Angebote selbst bleiben bestehen. Mit Confirm-Dialog. |
| Aus Sortiment entfernen | Setzt den Status auf inactive (Soft-Delete). Solange das Angebot auf Amazon nicht wieder BUYABLE wird, lÀsst der nÀchste Sync es in Ruhe. Mit Confirm-Dialog. |
Jede Bulk-Aktion schreibt einen einzigen Eintrag ins
amazon_sync_log mit Typ listings_bulk_edit, sodass die Aktionen spÀter
nachvollziehbar sind.
Beispiel-Workflow: 50 unzugeordnete FBA-DE-Angebote auf einmal mappen
Klassisches Szenario nach einem SKU-Rebrand:
- Filter setzen
- Marktplatz: DE
- Fulfillment: FBA
- Toggle Nur nicht zugeordnet: an
- Die Tabelle zeigt nur die betroffenen Zeilen.
- Header-Checkbox klicken â 50 Zeilen markiert.
- Button Zuordnen â Produkt-Picker öffnet sich.
- Im Picker den neuen Flowkom-Artikel suchen, auswÀhlen, Zuordnen klicken.
- Toast: â50 Angebote zugeordnet (+12 ĂŒber MarktplĂ€tze propagiert)â.
Die +12-Propagation bedeutet: weitere 12 Zwillings-SKUs auf FR/IT/ES wurden
automatisch auf denselben Flowkom-Artikel mitgezogen, ohne dass du dort erneut
filtern musstest.
Spalten konfigurieren
Oben rechts: Button Spalten. Dort kannst du pro Benutzer:
- Spalten ein- und ausblenden
- Reihenfolge per Drag & Drop festlegen
- Mit ZurĂŒcksetzen auf die Defaults zurĂŒckfallen
Die Konfiguration wird im Browser gespeichert (localStorage). Default-Spalten sind: Bild, Titel, SKU, ASIN, Marktplatz, Kanal, Status, FBA-Bestand, Flowkom-Artikel, Zuletzt synchronisiert.
FBA-Bestand
Die Spalte FBA-Bestand zeigt fĂŒr jedes FBA-Angebot die Anzahl der
Einheiten, die Amazon aktuell in seinen Lagern lieferbar fĂŒhrt â aggregiert
ĂŒber alle Fulfillment-Center des Marktplatzes. FBM-Angebote zeigen hier â,
weil der Bestand dort vom Flowkom-WMS gefĂŒhrt wird und nicht aus Amazon
zurĂŒckgespiegelt werden muss.
| Ereignis | Was passiert |
|---|---|
StĂŒndlicher Cron amazon-fba-inventory-pull | Zieht paginiert alle FBA-Summaries und schreibt sie nach amazon_fba_inventory |
| Button âJetzt FBA-Bestand pullenâ in der Integration-Detailseite | Gleiche Logik, sofort ausgefĂŒhrt â fĂŒr Verdachts-Checks |
DB-Trigger auf amazon_fba_inventory | Recomputed amazon_listings.quantity automatisch nach jedem Upsert |
| Listings-UI lÀdt Tabelle | Zeigt frischen Stand aus amazon_listings.quantity ohne weiteren API-Call |
Technische Details â warum Trigger statt Duplikation?
amazon_fba_inventory ist pro Listing Ă Fulfillment-Center-Country
normalisiert, weil Amazon den Bestand pro FC aufschlĂŒsselt. FĂŒr die UI
brauchen wir aber einen aggregierten Wert pro Listing. Statt diese Summe
beim Pull in amazon_listings.quantity zu duplizieren (und dann bei jedem
Upsert, Delete, Partial-Pull manuell nachzuziehen), hÀngt ein AFTER
INSERT/UPDATE/DELETE-Trigger auf amazon_fba_inventory und recomputed die
Summe atomar:
SELECT COALESCE(SUM(quantity_available), 0)
FROM amazon_fba_inventory
WHERE amazon_listing_id = <target>;Vorteile: Single Source of Truth bleibt in amazon_fba_inventory, keine
Drift möglich, auch manuelle Datenkorrekturen auf der Quelltabelle landen
sofort in der UI, FBM-Listings werden nie berĂŒhrt (deren quantity bleibt
NULL, UI zeigt â).
FBM-Bestandssync â separate Richtung
Wichtig: FĂŒr FBM-Angebote lĂ€uft der Bestand in die andere Richtung â
vom Flowkom-WMS zu Amazon. Der FBA-Inventory-Pull berĂŒhrt FBM-Angebote
nicht. Wenn du bei einem FBM-Listing einen falschen Amazon-Bestand
vermutest, schau stattdessen in den FBM-Bestandssync-Log (Modul
amazon-inventory-push).
CSV-Export
Der Button Exportieren in der Toolbar lÀdt die aktuell gefilterte Liste als CSV herunter:
- Semikolon-Separator (Excel-DE kompatibel)
- UTF-8 mit BOM â Umlaute werden korrekt dargestellt
- Hard-Cap: 50.000 Zeilen pro Export (bei Ăberschreitung: Fehlermeldung, bitte Filter enger ziehen)
Der Export ist als Analyse-Werkzeug gedacht, nicht als JTL-Ameise- Import-Format. Spalten: SKU, ASIN, Titel, Marktplatz, Fulfillment, Status, Bestand, Flowkom-Artikel-Nr., Flowkom-Artikel-Name, Zuletzt synchronisiert.
Leere ZustÀnde
- Keine Treffer fĂŒr die aktuellen Filter â Button âFilter zurĂŒcksetzenâ.
- Gar keine Angebote synchronisiert â Hinweis, zuerst einen Listings-Sync im Integration-Dashboard anzustoĂen.
Tipps & Best Practices
- Nutze Deep-Links: Bookmark fĂŒr âNicht zugeordnete FBA-DE-Angeboteâ â der erste tĂ€gliche Reiniger-Workflow erledigt sich in einer Minute.
- Soft-Delete statt Hard-Delete: Aus Sortiment entfernen ist der einzig sinnvolle Weg, Angebote aus der Ansicht zu bekommen. Ein echtes Delete wĂŒrde der nĂ€chste Sync sofort wiederherstellen.
- Cross-Marketplace-Propagation nutzen: Bei Zwillings-SKUs reicht es, auf dem PrimĂ€rmarktplatz (z.B. DE) zu mappen â FR/IT/ES folgen automatisch.
Technik-Details fĂŒr Admins & Entwickler
Daten-Quelle: Tabelle amazon_listings (PROJ-166, PROJ-169). Diese wird
vom Background-Job listings_refresh gefĂŒllt (SP-API Listings API v2021-08-01
mit withStatus=BUYABLE).
Filter-Performance: Trigram-GIN-Indizes (PROJ-45-Pattern, PROJ-170) auf
title, seller_sku und asin sorgen fĂŒr <200ms-Volltextsuche auch bei
5.000+ Zeilen pro Integration.
Server-Endpoints:
| Endpoint | Zweck |
|---|---|
GET /api/integrations/[id]/amazon/listings | Paginierter List-Fetch mit allen Filtern |
POST /api/integrations/[id]/amazon/listings/bulk-assign | Bulk-Mapping + Cross-MP-Propagation |
POST /api/integrations/[id]/amazon/listings/bulk-unassign | Bulk-Unmapping |
POST /api/integrations/[id]/amazon/listings/bulk-deactivate | Soft-Delete (status=inactive) |
GET /api/integrations/[id]/amazon/listings/export | CSV-Export (50k Hard-Cap) |
Sortierung: Server-seitig, indiziert auf seller_sku, last_synced_at,
status, quantity. Alle anderen Spalten sind nur optisch sortiert.
Selektions-Modell: Der Frontend-State hĂ€lt ein Set<UUID> â bei âAlle
gefiltertenâ wird stattdessen der Filter gemerkt und die IDs erst beim Bulk-
Request nachgeladen (max. 10.000 pro Request).
NĂ€chtlicher automatischer Refresh
Damit der Listings-State nicht davon abhĂ€ngt, dass jemand tagsĂŒber den Listings aktualisieren-Button drĂŒckt, lĂ€uft seit v1.37.000 (PROJ-172) ein nĂ€chtlicher Cron-Job, der alle aktiven Amazon-Integrationen inkrementell synchronisiert â komplett ohne Browser-Tab, komplett ohne manuellen Klick.
Wann lÀuft was?
| Cron-Job | Uhrzeit (UTC) | Was macht er? |
|---|---|---|
| Amazon Listings Nightly Refresh | 02:00 | Inkrementeller Sync aller Amazon-Angebote (nur geÀnderte seit letztem Erfolg minus 1 h Safety) |
| Amazon FBA Inventory Pull | 03:15 | Holt aktuelle FBA-BestĂ€nde fĂŒr die frisch synchronisierten Listings |
Die Reihenfolge ist bewusst so gewĂ€hlt: Neue oder gerade erst in Amazon freigeschaltete Angebote werden zuerst als Listings erfasst, und eine Stunde spĂ€ter zieht der FBA-Inventory-Pull dafĂŒr die BestĂ€nde â alles in derselben Nacht.
Der Ablauf im Detail
Wichtige Verhaltensweisen
- Opt-Out pro Integration. In der Integration-Settings-Card gibt es einen Schalter NĂ€chtlicher Listings-Refresh. Standard: an. Wer eine Test-Integration hat oder die API-Budget-Rechnung nicht belasten will, kann ihn ausschalten.
- Per-Marketplace-Fehler-Isolation. Wirft ein Marktplatz 503 oder hat ein
Auth-Problem, lĂ€uft der Job fĂŒr die ĂŒbrigen MarktplĂ€tze trotzdem durch. Der
Fehler landet im
amazon_sync_log.details.per_marketplace[mp].errorund der Final-Status des Jobs wird alspartialmarkiert. - Time-Budget 20 Minuten pro Integration. LĂ€uft ein Sync gegen die Wand
(ungewöhnlich lange Ketten, Provider-Outage), wird der Job als
partialmitfinished_reason='time_budget_exceeded'beendet, damit die nÀchste Integration nicht blockiert wird. In der Praxis braucht ein inkrementeller Sync Minuten, nicht Stunden. - Kein Resume zwischen NÀchten. Partial-Jobs werden abgeschlossen; die
nĂ€chste Nacht startet einen frischen Log. Es gibt bewusst kein âdort weiter
machen, wo gestern aufgehört wurdeâ â die KomplexitĂ€t wĂŒrde nichts lösen,
weil der inkrementelle Sync selbst nach mehrtĂ€gigem Ausfall ĂŒber
lastUpdatedAfterzuverlĂ€ssig alle Ănderungen nachzieht. - Inkrementell by default, Force-Full nur manuell. Der Nightly-Job nutzt
lastUpdatedAfter = letzter Erfolg â 1 h Safety. Ein vollstĂ€ndiger Katalog-Refresh wird nie nĂ€chtlich gefahren â das wĂŒrde unnötig API-Budget verbrennen. Wer einmal einen vollstĂ€ndigen Refresh braucht, triggert ihn manuell ĂŒber den Jetzt starten-Button und wĂ€hlt dort im Admin-Endpointforce_full: true.
Manuell testen
Es gibt zwei Wege, den Cron-Pfad manuell zu triggern â ohne auf 02:00 UTC zu warten:
- FĂŒr alle Integrationen gleichzeitig: Settings â Cron-Jobs â Amazon Listings Nightly Refresh â Jetzt ausfĂŒhren. LĂ€uft ĂŒber den gleichen Endpoint wie der echte Nightly-Run.
- FĂŒr eine einzelne Integration: In der Amazon-Integration-Settings-Card
unten den Jetzt starten-Button. Der ruft den Admin-Run-Endpoint
(
POST /api/integrations/[id]/amazon/listings/nightly-run) auf und zeigt eine Toast-Summary mit Items + Laufzeit.
Nach dem Lauf sollte in der Cron-Health-Ăbersicht ein frischer Eintrag
erscheinen (Job-ID amazon-listings-nightly-refresh) und im amazon_sync_log
ein neuer Eintrag mit job_type='listings_refresh'.
Warum kein pg_cron + net.http_post in Supabase?
Die ursprĂŒngliche Spec hatte eine pg_cron-Migration vorgesehen. Bei der Implementierung wurde entschieden, stattdessen den bestehenden externen Scheduler-Mechanismus von Flowkom zu nutzen, weil:
- Alle anderen Amazon-Cron-Jobs (FBM-Import, FBA-Import, FBA-Inventory-Pull,
Inventory-Flush, Shipment-Confirmation) bereits ĂŒber dasselbe Pattern
laufen: Endpoint im
cronJobs-Array in der Settings-Seite registriert, externer Cron-Service (Coolify Cronjob / EasyCron / all-inkl KAS) triggert ihn per HTTP-Request mitx-cron-secret-Header. - Die
cron_base_url-Konfiguration pro Workspace ermöglicht Multi-Deployment-Setups (Staging + Prod zeigen jeweils auf ihren eigenen Scheduler). - Keine zusÀtzlichen Postgres-GUCs (
app.internal_base_url,app.cron_secret) notwendig, die je nach Datenbankversion unterschiedlich gesetzt werden mĂŒssten. - Konsistenz > technische Finesse.
Warum keinen separaten wöchentlichen Force-Full-Cron?
Auch das war in der Spec andiskutiert. Bei der Umsetzung hat sich gezeigt:
Der inkrementelle lastUpdatedAfter-Modus fĂ€ngt alle Ănderungen zuverlĂ€ssig
ab, solange der tĂ€gliche Lauf nicht ĂŒber 23 Stunden ausfĂ€llt. Und fĂŒr den
seltenen Ausnahmefall (z. B. nach mehrtÀgigem Credential-Ablauf) gibt es den
Admin-Trigger mit force_full: true. Ein automatisierter wöchentlicher
Force-Full wÀre nur Overhead ohne nachweisbaren Nutzen.