Skip to Content
IntegrationenAmazon-Angebote verwalten

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.

FilterZweck
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
FulfillmentFBA, FBM oder beide
StatusAktiv, Inaktiv, Unvollständig oder alle
Nur nicht zugeordnetZeigt ausschließlich Angebote ohne Flowkom-Artikel
Bestand = 0Zeigt 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?

AspektFBA (Fulfillment by Amazon)FBM (Fulfillment by Merchant)
VersandAmazon (aus FBA-Lager)Du selbst (aus deinem Flowkom-Lager)
Bestand relevantFBA-Lagerbestand wird von Amazon gemeldetDein Flowkom-Bestand wird an Amazon gepusht
Default-MappingSKU mit optionalem -FBA-Suffix wird automatisch auf den Basisartikel gemapptExakter SKU-Match, Fallback ohne -FBM-Suffix
Typische Arbeit auf dieser SeiteAltlasten und Cross-Marketplace-MappingMapping bei SKU-Umbenennungen, Fremdangebote
Badge-Farbegrünblau

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

AktionWas 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 aufhebenEntfernt den Flowkom-Artikel-Link von allen markierten Zeilen — die Amazon-Angebote selbst bleiben bestehen. Mit Confirm-Dialog.
Aus Sortiment entfernenSetzt 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:

  1. Filter setzen
    • Marktplatz: DE
    • Fulfillment: FBA
    • Toggle Nur nicht zugeordnet: an
  2. Die Tabelle zeigt nur die betroffenen Zeilen.
  3. Header-Checkbox klicken → 50 Zeilen markiert.
  4. Button Zuordnen → Produkt-Picker öffnet sich.
  5. Im Picker den neuen Flowkom-Artikel suchen, auswählen, Zuordnen klicken.
  6. 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.

EreignisWas passiert
Stündlicher Cron amazon-fba-inventory-pullZieht paginiert alle FBA-Summaries und schreibt sie nach amazon_fba_inventory
Button “Jetzt FBA-Bestand pullen” in der Integration-DetailseiteGleiche Logik, sofort ausgeführt — für Verdachts-Checks
DB-Trigger auf amazon_fba_inventoryRecomputed amazon_listings.quantity automatisch nach jedem Upsert
Listings-UI lädt TabelleZeigt 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:

EndpointZweck
GET /api/integrations/[id]/amazon/listingsPaginierter List-Fetch mit allen Filtern
POST /api/integrations/[id]/amazon/listings/bulk-assignBulk-Mapping + Cross-MP-Propagation
POST /api/integrations/[id]/amazon/listings/bulk-unassignBulk-Unmapping
POST /api/integrations/[id]/amazon/listings/bulk-deactivateSoft-Delete (status=inactive)
GET /api/integrations/[id]/amazon/listings/exportCSV-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-JobUhrzeit (UTC)Was macht er?
Amazon Listings Nightly Refresh02:00Inkrementeller Sync aller Amazon-Angebote (nur geänderte seit letztem Erfolg minus 1 h Safety)
Amazon FBA Inventory Pull03:15Holt 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].error und der Final-Status des Jobs wird als partial markiert.
  • Time-Budget 20 Minuten pro Integration. Läuft ein Sync gegen die Wand (ungewöhnlich lange Ketten, Provider-Outage), wird der Job als partial mit finished_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 lastUpdatedAfter zuverlä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-Endpoint force_full: true.

Manuell testen

Es gibt zwei Wege, den Cron-Pfad manuell zu triggern — ohne auf 02:00 UTC zu warten:

  1. Für alle Integrationen gleichzeitig: Settings → Cron-Jobs → Amazon Listings Nightly RefreshJetzt ausführen. Läuft über den gleichen Endpoint wie der echte Nightly-Run.
  2. 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 mit x-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.