Bestell-Sync
Vom ERP zu Polygon One und die DDS-Referenzen zurück — der zentrale EUDR-Ablauf. Ihr ERP überträgt Stammdaten und Bestellungen; in Polygon One werden die Bestellungen mit DDS-Erklärungen verknüpft; Ihr ERP liest je Bestellung und Position zurück, ob die Bestellung abgedeckt ist und welche TRACES-Referenz dazugehört.Zuerst Stammdaten: Lieferanten, dann Artikel
hsCode und articleDescription einer Bestellzeile werden nur
gelesen, wenn der Artikel noch nicht existiert (nur beim Anlegen).
Lieferanten werden über externalSupplierId oder den Namen abgeglichen, Artikel über
internalArticleNr. Ein Einkaufsartikel braucht einen Lieferanten (supplierId oder
supplierName).202 mit einer jobId. Warten Sie, bis der Lieferanten-Job abgeschlossen ist,
bevor Sie die Artikel senden, und bis der Artikel-Job abgeschlossen ist, bevor Sie die
Bestellungen senden (Abfrage wie in Schritt 3). Jobs eines Arbeitsbereichs können gleichzeitig
laufen: Eine Artikelzeile, deren supplierName noch nicht gespeichert ist, legt einen neuen
Lieferanten an, der nur diesen Namen trägt.Bestellungen als Stapel senden — alle Zeilen einer Bestellung in derselben Anfrage
orderNumber bilden eine
Bestellung. Der Import einer Bestellung ersetzt alle ihre Zeilen, eine Anfrage, die eine
Bestellung nennt, muss also alle ihre Zeilen enthalten. Hat Ihr ERP Positionsnummern,
senden Sie sie als positionId an jeder Zeile der Bestellung.quantity ist die Nettomasse in Kilogramm. Höchstens 5.000 Zeilen pro Anfrage — teilen Sie
größere Abgleiche auf mehrere Anfragen auf und halten Sie dabei die Zeilen jeder Bestellung
zusammen.Import-Job abfragen und Ergebnis speichern
status completed oder failed ist. Speichern Sie result bei sich — der
Job-Datensatz wird ~30 Tage nach Erstellung gelöscht. Fehlgeschlagene Zeilen tragen stabile
Fehlerschlüssel in failed[].error.key. Ein failed-Job trägt seinen Grund in error, einem
Text; bei lineReplacementRequired enthält er JSON mit den orderNumbers — eine Anfrage hätte
gespeicherte Zeilen gelöscht: Senden Sie die genannten Bestellungen mit allen ihren Zeilen
erneut.Bestellungen regelmäßig per Delta abfragen
changedSince = Beginn Ihres letzten Abrufs minus einige Minuten (ein
ISO-8601-Zeitstempel mit Z oder Versatz) und limit=1000 ab. Stündlich wird empfohlen.
fields beschränkt die Antwort auf das, was die Entscheidung in Schritt 5 braucht.changedSince-Fenster mit offset, bis eine Seite kürzer als limit
ist, und fragen Sie häufiger ab. Eine Bestellung kann doppelt erscheinen; eine, die sich während
des Blätterns ändert, kommt im nächsten Delta wieder.Je Bestellung und Position entscheiden
- Ob die ganze Bestellung abgedeckt ist:
status(done,openodernotRelevant). Ein Artikel, der auf die manuelle Prüfung der EUDR-Relevanz wartet, hält die Bestellung aufopen. - Freigabe einer Position (z. B. SAP-Sperre): Geben Sie eine Position nur frei, wenn
- der
statusder Bestellungdoneist (jede EUDR-relevante Zeile ist durch eine eingereichte DDS-Erklärung abgedeckt) odernotRelevant, oder - für eine einzelne Zeile
lines[].article.eudrRelevantfalseundlines[].article.needsManualCheckfalseist (der Artikel der Zeile ist nicht EUDR-relevant).
- der
- Welche TRACES-Referenz Sie drucken: erst nach dieser Entscheidung, aus
ddsReferences(referenceNumber,verificationNumber), für die Dokumente.
status kann open sein, obwohl ddsReferences nicht leer ist (z. B. bei einem Entwurf oder
einer externen DDS-Erklärung). Eine zurückgezogene oder abgelehnte DDS-Erklärung fällt aus
ddsReferences heraus, und die Bestellung erscheint im nächsten Delta erneut.Nächtlicher Voll-Sync als Auffangnetz
offset, bis eine Seite kürzer als limit ist. Behandeln
Sie eine Bestellung, die in der vollständigen Liste fehlt, als gelöscht.?status=open&limit=1000 neu und blättern Sie ebenso mit offset.- Eine Bestellung auf mehrere Anfragen verteilen. Die zweite Anfrage würde die Zeilen der
ersten löschen; die Prüfung auf ersetzte Zeilen lässt stattdessen den ganzen Job mit
lineReplacementRequiredfehlschlagen. Senden Sie alle Zeilen jeder Bestellung, oder"replaceLines": true, wenn eine Bestellung Zeilen verlieren soll. positionIdnur an einigen Zeilen. Alle Zeilen einer Bestellung tragen eine oder keine (positionIdMixed), und jede nur einmal pro Bestellung (duplicatePositionId). Eine ohne Positionsnummern gespeicherte Bestellung, die erstmals mit ihnen gesendet wird, braucht"replaceLines": true.- Ware auf eine Referenz freigeben. Geben Sie nur auf
statusoder auflines[].article.eudrRelevantundlines[].article.needsManualCheck, beidefalse, im aktuellen Abruf frei — nie, weilddsReferencesnicht leer ist, und nie auf Grundlage eines früheren Abrufs. - Bei einer vollen Delta-Seite aufhören. Die Bestellungen dahinter kommen nur wieder, wenn sie
sich erneut ändern; blättern Sie das Fenster mit
offsetdurch.
Variante: Herkunft pro Bestellung aus dem ERP
Eine Bestellzeile zeigt auf eine eigene Kopie des Artikels, wenn der Artikel eine Pro-Bestellung-Vorlage ist: ein Artikel, den ein Einkaufsbestellungs-Import angelegt hat, ein mitsourceScope: "perOrder" gesendeter Artikel, oder — mit der Arbeitsbereich-Einstellung
„Bestellimport legt Pro-Bestellung-Kopien an“ (standardmäßig aus, wird auf Anfrage von Polygon
One eingeschaltet) — ein vorhandener Artikel, den eine Zeile einer Einkaufsbestellung nennt. Ihr ERP
kann dieser Kopie Parzellen und Dokumente direkt zuordnen, ohne Lieferantenportal: Kopie finden,
Parzellen mit ihrer supplierArticleId anlegen, Nachweise hochladen. Dafür braucht der Schlüssel
plots:write und evidence:write; die Schlüssel-Vorlage ERP-Anbindung enthält beide (einem
damit vor dem 1. Oktober 2026 angelegten Schlüssel fehlen sie — prüfen Sie seine Berechtigungen).
Schritte und Antworten: Herkunft pro Bestellung per ERP.
Sind alle aktuellen Parzellen hochgeladen, rufen Sie
POST /api/v1/orders/{id}/origin-confirmation mit den ausgewählten supplierArticleIds der
Bestellzeilen auf; der Lieferant bestätigt dann die aktuellen Herkunftsdaten dieser Bestellung.
Daten früherer Bestellungen werden nie übernommen, die Urheberschaft des Käufers bleibt unverändert.
Details: Herkunft vom Lieferanten bestätigen lassen.
Parzellen und Geo-Analyse
Parzellengeometrie senden, Entwaldungsanalyse abwarten, Ergebnis lesen, Bericht herunterladen. Ein Artikel oder Lieferant ist nicht nötig — eine Parzelle mit Rohstoffgruppe genügt.Optional: Geometrie prüfen
valid und den
Codes, die das Anlegen liefern würde. commodityGroup ist hier optional; senden Sie aber
"wood", verlangt auch der Probelauf eine wissenschaftliche Holzart, wie beim Anlegen. Ihr
Parzellen-Limit prüft er nicht.Parzelle anlegen
201 mit der Parzelle unter created. Übernehmen Sie created.id. 409 mit
code: "PLOT_LIMIT_REACHED" heißt: Ihr Parzellen-Limit oder Monatskontingent ist erreicht;
nichts wird angelegt, und eine Wiederholung hilft nicht.Analysestatus abfragen
analysisStatus pending oder in_progress ist:Bericht einmal herunterladen
- Eine
FeatureCollectionsenden. Eine Anfrage legt eine Parzelle an — senden Sie jedes Feature einzeln. - Den Bericht statt des Status abfragen. Jeder Berichtsaufruf erzeugt das PDF neu; laden Sie es einmal herunter, sobald das Ergebnis vorliegt.
- Keine Parzellenreferenz in
name. Gleichername, gleichescountry, gleiche Geometrie und gleichesupplierArticleIdswerden wiedererkannt ("deduplicated": true) — das macht eine Wiederholung gefahrlos. - Kein
country. Ohne Land greift das Überspringen für Länder mit geringem Risiko nie, und die Parzelle wird immer analysiert.
PPWR-Mengenmeldung
Eine Kurzfassung des Integrationsrezepts ERP zu LUCID. Schritte 1–3 sind einmalige Stammdaten, Schritte 4–6 der wiederkehrende Job. Die Stammdaten-Endpunkte antworten synchron (200); der Mengen-Feed ist ein Import-Job. Die Artikel (SKUs) müssen in
Polygon One schon existieren: Legen Sie fehlende mit POST /api/v1/articles an
(articles:write). Eine unbekannte Artikelnummer ist in article-links und im Mengen-Job eine
Fehlerzeile.
Komponenten mit Material und Masse
Verpackungseinheiten — immer mit internalRef
internalRef legt immer eine neue Einheit an. notes ist Pflicht.Stückliste und SKU-Verknüpfungen
POST /api/v1/ppwr/links und Artikel (SKUs) mit
Einheiten über POST /api/v1/ppwr/article-links, das eine unbekannte Artikelnummer als
Fehlerzeile meldet.Wiederkehrend: Mengen je SKU, Markt und Jahr senden
202 mit einer jobId — fragen Sie GET /api/v1/import-jobs/{jobId} ab wie beim Bestell-Sync.
Die quantity jeder Zeile ist die Gesamtmenge für diese SKU, dieses Jahr und diesen Markt und
ersetzt den gespeicherten Wert — senden Sie nie Zuwächse, Retouren oder Gutschriften als eigene
Zeilen, sondern verrechnen Sie sie in der Gesamtmenge. Senden Sie
replaceScope: "period-market", wenn der Stapel die vollständige Liste für jedes genannte Jahr
und jeden genannten Markt ist; lassen Sie das Feld weg, wenn der Stapel nur die geänderten SKUs
enthält.Bericht erzeugen
422 nennt Ihnen Punkt für Punkt, welche Daten noch nicht meldefähig sind — korrigieren,
erneut senden, erneut erzeugen.Datei abholen und bei LUCID hochladen
GET /api/v1/ppwr/mengenmeldung/{id}/xml herunter:- Einheiten-Zeilen ohne
internalRef. Jede Wiederholung legt eine weitere Einheit an. - SKUs über
articleNumbersder Einheiten-Zeile verknüpfen. Eine unbekannte Artikelnummer wird dort übersprungen; die Antwort zählt solche Nummern nur (articleNumbersUnmatched) und nennt sie nicht.POST /api/v1/ppwr/article-linksmeldet jede als Fehlerzeile. - Einen gespeicherten Wert ohne
overwrite: trueüberschreiben. Der ganze Stapel wird mit409 overwriteRequiredabgelehnt, nichts wird geschrieben. - Erwarten, dass der Feed einen von Hand eingetragenen Wert ersetzt. Das tut er nie; betroffene
Einheiten kommen in
conflictszurück.
Vor dem Go-live
- Schlüsselberechtigungen je Ablauf. Bestell-Sync:
suppliers:write,articles:write,orders:write(Stapelimport); Herkunft pro Bestellung zusätzlichplots:writeundevidence:write; Parzellen:plots:write(Geo-Analyse); PPWR:packaging:write, dazuarticles:write, wenn Sie die SKUs über die API anlegen (PPWR). Schreibrechte schließen Leserechte ein. Die Schlüssel-Vorlage ERP-Anbindung enthält all diese (einem damit vor dem 1. Oktober 2026 angelegten Schlüssel fehlenplots:writeundevidence:write). - Module und Exporte. Ein Schlüssel handelt als ein Benutzer. Die PPWR-Endpunkte brauchen das
PPWR-Modul für diesen Benutzer. Der Parzellenbericht braucht das EUDR-Modul für diesen Benutzer
und aktivierte Exporte für Ihren Arbeitsbereich (sonst
403). - Das Rate-Limit gilt je IP. 1000 Anfragen pro 60 Sekunden je Client-IP, über alle
/api-Pfade und einschließlich der Nutzer der Web-App aus demselben Netz. Verteilen Sie geplante Jobs zeitlich und nutzen Sie die Stapel-Endpunkte (Rate-Limit). - Nur wiederholen, was gefahrlos wiederholbar ist.
429mit JSON und5xxmit exponentiellem Backoff und Jitter; Stapelimporte sind gefahrlos wiederholbar. Ein wiederholterPOSTmit einem einzelnen Lieferanten antwortet409(gleicher Name oder gleicheexternalSupplierId). Ein wiederholterPOSTmit einer einzelnen Bestellung antwortet409, ebenso das Umbenennen einer Bestellung auf eine bereits vorhandene Bestellnummer — suchen Sie die Bestellung zuerst, oder senden Sie Bestellungen als Stapel mit einer Zeile (Wiederholungen). - Es gibt keine Sandbox. Jeder Aufruf wirkt auf Ihren Live-Arbeitsbereich (Nicht in v1).
- Protokollieren Sie
x-vercel-idbei jedem fehlgeschlagenen Aufruf — der Support braucht den Wert (Anfrage-Referenz). - Unbekannte Antwortfelder ignorieren. v1 ergänzt mit der Zeit Felder (Versionierung).