Über Direct Fulfillment (im Folgenden kurz DF) können Bestellungen, die durch pixi bearbeitet werden, über einen externen Dienstleister versendet werden.
Dieses Verfahren ist teilweise auch unter der Bezeichnung „Dropshipping“ bekannt, wenn der Versand direkt vom Lager eines Lieferanten oder Herstellers an den Endkunden erfolgt – ohne dass der Händler selbst Kontakt mit der Ware hat. In pixi wird diese Vorgehensweise über verschiedene DF-Typen abgebildet.
Direct Fulfillment-Arten
Artikel, die Sie nicht auf Lager haben, können auf zwei unterschiedlichen Wegen zum Endkunden versandt werden:
Die vom Endkunden bestellten Artikel werden direkt durch den Fulfillment-Dienstleister an den Endkunden verschickt.
Der Fulfillment-Dienstleister schickt die vom Kunden bestellten Artikel an das Versandlager des Händlers, welcher anschließend die Artikel an den Endkunden verschickt.
In jedem Fall gilt: Der DF-Dienstleister ist Eigentümer der Waren in seinem Lager. Die für Kundenbestellungen versendeten Artikel werden Ihnen in Rechnung gestellt.
Versand vom DF-Lieferanten zum Endkunden
Die am häufigsten verwendete Art des Direct Fulfillment ist der Versand der vom Endkunden bestellten Artikel direkt durch den Fulfillment-Dienstleister an den Endkunden (Dropshipping).
Der Vorteil dieser Vorgehensweise ist, dass der Händler selbst keinerlei Kosten für Personal und/oder die benötigte Lagerkapazität für die Artikel aufbringen muss. Die Artikel werden direkt aus dem Lager des Fulfillment-Dienstleisters verschickt - ohne Umwege.
Diese Art des Direct Fulfillment wird bei den DF-Typen 1 und 3 angewandt.
Hinweis: Besitzen Sie selbst keinerlei Versandlager und der DF-Dienstleister verschickt Artikel an Endkunden, die jedoch Ihr Eigentum sind, dann lässt sich dieser Prozess wie in diesem Abschnitt beschrieben abbilden.
Versand vom DF-Lieferanten zum Händler
Bei dieser Art des Direct Fulfillment werden die vom Endkunden bestellten Artikel durch den Fulfillment-Dienstleister an das Versandlager des Händlers geschickt, welcher wiederum die Artikel an den Endkunden versendet.
Hier liegt der Vorteil darin, dass der Kunde auch dann seine Bestellung komplett erhält, wenn ein Artikel zum Zeitpunkt der Bestellaufgabe nicht lagernd war. Ein Nachteil dieser Art ist jedoch, dass der Endkunde aufgrund des "Zwischenstops" der Artikel im Versandlager des Händler ggf. länger auf sein Paket warten muss, als es beim Versand durch den Fulfillment-Dienstleister der Fall ist.
Diese Art des Direct Fulfillment wird beim DF-Typ 2 angewandt.
Haben Sie keine Artikel auf Lager, liefern aber an Kunden aus Ihrem Versandlager, können Sie diesen Prozess auch unter Nutzung der pixi Web-Applikation in Verbindung mit pixi Mobile durchführen.
Erstellen Sie dazu eine Lieferantenbestellung über die Bestellmethode On Demand beim Automatischen Bestellvorschlag. Wurde die Bestellung angeliefert, können Sie diese mithilfe von pixi Mobile über das Programm Cross Docking/On Demand (WE) direkt weiterverarbeiten.
Weitere Informationen: Automatischer Bestellvorschlag, Bestellmethode On Demand, pixi Mobile: Cross Docking, On Demand (WE)
Direct Fulfillment-Typen
Aufgrund des beim Bestellimport mitgelieferten Flags entscheidet pixi automatisch, wie mit der Bestellung verfahren werden soll. Eine DF-Bestellung wird in pixi bis zum Zahlungseingang wie eine normale Bestellung behandelt. Sollte eine Bestellung noch nicht bezahlt sein, wird, bevor die Bestellung an den Dienstleister übergeben wird, auf den Zahlungseingang gewartet. Bestellungen mit Bestellzeilen im Status HAL (Halten) werden somit nicht an den DF-Dienstleister übergeben.
Sobald die Zahlung für die Bestellung vorliegt und die Bestellzeile in der Regel auf ANG (Angenommen) springen würde, prüft pixi den Direct Fulfillment-Typ jeder Bestellzeile und weist ggfs. den zugehörigen DF-Lieferanten zu.
In pixi wird zwischen 3 DF-Typen unterschieden:
DF-Typ |
Verfahren |
Beschreibung |
pixi versendet |
pixi versendet die Bestellzeile direkt an den Endkunden - kein Direct Fulfillment. |
|
DF-Dienstleister versendet |
Die Bestellzeile wird komplett an den Direct Fulfillment-Dienstleister übergeben. |
|
pixi versendet; |
Die Bestellzeile wird über pixi versendet. |
|
In Abhängigkeit des Lagerbestandes versendet entweder pixi oder der DF-Dienstleister |
pixi versendet die Artikel selbst, falls diese auf Lager sind (verfügbarer Bestand (reserviert) > Anzahl). |
Sind Bestellzeilen nicht auf Lager, ändert sich der Bestellzeilenstatus auf FUT. Diese Bestellungen stehen dann über die pixi API zur Abholung bereit. Nach der Abholung muss jede einzelne Bestellung mit einem zusätzlichen API Call bestätigt werden, um sicherzustellen, dass auch alle Bestellungen richtig übertragen wurden.
Der DF-Dienstleister führt nun den Versand der Bestellungen durch. Als Dokument wird der Bestellung lediglich ein Lieferschein beigelegt. Es gibt auch die Möglichkeit, eine externe Rechnungsnummer zu verwenden, falls vom DF-Dienstleister eine Rechnung mit Rechnungsnummer generiert wird. Diese externe Rechnung muss aber mit der von pixi automatisch generierten Rechnung übereinstimmen.
Nach dem Versand wird über die API der Status der Bestellung in pixi auf versendet umgestellt. Dabei kann je Bestellzeile eine Tracking-ID übergeben werden, die bei Rechnungsgenerierung an die Rechnung übernommen wird. Alternativ - falls eine Bestellzeile auch beim DF-Dienstleister nicht mehr verfügbar ist - kann eine Bestellzeile auch durch den DF-Dienstleister storniert werden.
pixi erledigt den Rest: Besteht die Kundenbestellung aus weiteren, beim Versandhändler lagernden Artikeln, werden diese ganz normal durch den Versandhändler gepickt, gepackt und verschickt (DF-Typ 0 / leer).
Bestellzeilen der beim Versandhändler lagernden Artikel werden über die Rechnungsautomatik erfasst und die Rechnung wird erstellt. Die Rechnung der Bestellzeilen, die durch den DF-Dienstleister verschickt werden, kann entweder manuell über die API oder ebenfalls automatisch über die Rechnungsautomatik erstellt werden.
Die folgenden Erläuterungen für jeden DF-Typen beziehen sich jeweils auf eine komplette Bestellung. Es kann ein DF-Typ auch pro Bestellzeile übergeben werden, dann beziehen sich die Aussagen selbstverständlich nur auf eine Bestellzeile.
Abbildung: Bestellzeilenstatusverlauf in pixi |
DF-Typ 0 / leer
Die Bestellung wird aus dem Versandlager des Händlers an den Endkunden verschickt.
Ist ein Artikel nicht lagernd, wird er entweder storniert oder beim Lieferanten nachbestellt und anschließend durch den Händler verschickt. Ein DF-Dienstleister ist hier nicht involviert.
Die Bestellung folgt dem üblichen Ablauf:
Ist die Zahlung noch nicht geklärt, befindet sich die Bestellung im Status HAL - der Zahlungseingang wird abgewartet.
Ist die Zahlung eingegangen und der Bestellung zugewiesen, ändert sich der Status auf ANG.
Befinden sich alle bestellten Artikel auf Lager, werden diese gepickt, in die Versandboxen gescannt (Status EIN) und versendet (Status AUS).
DF-Typ 1
Der DF-Dienstleister versendet in jedem Fall die Bestellung - unabhängig vom Artikelbestand in Ihrem Lager.
Der Bestellablauf ist hier wie folgt:
Ist die Zahlung noch nicht geklärt, befindet sich die Bestellung im Status HAL - der Zahlungseingang wird abgewartet.
Ist die Zahlung eingegangen und der Bestellung zugewiesen, ändert sich der Status auf FUT (Fulfillment Transfer). Die Bestellzeilen werden über die API Calls pixiDFGetOrders & pixiDFGetOrderlines vom DF-Dienstleister abgeholt.
Anschließend werden die Bestellzeilen über den API Call pixiDFGetChangesConfirmation bestätigt.(Optional) Mit pixiDFGetChanges kann vor dem Versand geprüft werden, ob Bestellzeilen mittlerweile möglicherweile durch Kunden storniert wurden oder ob es Änderungen an der Bestellmenge gibt.
Der DF-Dienstleister versendet die Bestellung und markiert die Bestellung über den API Call pixiDFSetStatus oder pixiDFUpdateOrderlineStatus als versendet. In pixi springt der Status nun automatisch auf FUS (Fulfillment Sent).
Nachdem in pixi die DF-Rechnung entweder in pixi über die Rechnungsautomatik oder über den API Call pixiDFCreateInvoices generiert wurde, wird die Bestellung in pixi mit dem Status AUS markiert.
Abbildung: Bestellzeilenstatusverlauf in pixi |
Abbildung: Prozess in API Calls (aus Sicht des DF-Dienstleisters) |
DF-Typ 2
Die Artikel der Bestellung werden in jedem Fall aus dem Versandlager des Händlers verschickt.
Der Bestellablauf ist hier wie folgt:
Ist die Zahlung noch nicht geklärt, befindet sich die Bestellung im Status HAL - der Zahlungseingang wird abgewartet.
Ist die Zahlung eingegangen und der Bestellung zugewiesen, wechselt der Status der jeweiligen Bestellzeile in Abhängigkeit des Lagerbestandes im Versandlager des Händlers.
Ist genügend Bestand auf Lager, ändert sich der Status auf ANG. Der DF-Dienstleister ist in diesem Fall nicht involviert.
-
Ist nicht genügend Bestand auf Lager, ändert sich der Status auf FUT (Fulfillment Transfer).
Die Bestellzeilen werden über die API Calls pixiDFGetOrders & pixiDFGetOrderlines vom DF-Dienstleister abgeholt.
Anschließend werden die Bestellzeilen über den API Call pixiDFGetChangesConfirmation bestätigt.(Optional) Mit pixiDFGetChanges kann vor dem Versand gerüft werden, ob Bestellzeilen mittlerweile möglicherweile durch Kunden storniert wurden oder ob es Änderungen an der Bestellmenge gibt.
Der DF-Dienstleister versendet die Bestellung an das Versandlager des Händlers und markiert die Bestellung über den API Call pixiDFSetStatus oder pixiDFUpdateOrderlineStatus als versendet. In pixi springt der Status nun automatisch auf BES (Bestellt).
Die Artikel der Bestellung werden nun über das Versandlager des Händlers gepickt und in die Versandboxen gescannt (Status EIN).
Nachdem in pixi die DF-Rechnung manuell oder automatisch in der pixi Rechnungen Applikation generiert und versendet wurde, wird die Bestellung in pixi mit dem Status AUS markiert.
Abbildung: Artikel lagernd |
Abbildung: Artikel nicht lagernd |
Abbildung: Prozess in API Calls (aus Sicht des DF-Dienstleisters) |
DF-Typ 3
Die Artikel der Bestellung werden nach Verfügbarkeit aus dem jeweiligen Lager verschickt.
Der Bestellablauf ist hier wie folgt:
Ist die Zahlung noch nicht geklärt, befindet sich die Bestellung im Status HAL - der Zahlungseingang wird abgewartet.
Ist die Zahlung eingegangen und der Bestellung zugewiesen, wechselt der Status der jeweiligen Bestellzeile in Abhängigkeit des Lagerbestandes im Versandlager des Händlers.
Ist genügend Bestand auf Lager, ändert sich der Status auf ANG. Der DF-Dienstleister ist in diesem Fall nicht involviert.
-
Ist nicht genügend Bestand auf Lager, ändert sich der Status auf FUT (Fulfillment Transfer).
Die Bestellzeilen werden über die API Calls pixiDFGetOrders & pixiDFGetOrderlines vom DF-Dienstleister abgeholt.
Anschließend werden die Bestellzeilen über den API Call pixiDFGetChangesConfirmation bestätigt.(Optional) Mit pixiDFGetChanges kann vor dem Versand gerüft werden, ob Bestellzeilen mittlerweile möglicherweile durch Kunden storniert wurden oder ob es Änderungen an der Bestellmenge gibt.
Der DF-Dienstleister versendet die Bestellung und markiert die Bestellung über den API Call pixiDFSetStatus oder pixiDFUpdateOrderlineStatus als versendet. In pixi springt der Status nun automatisch auf FUS (Fulfillment Sent).
Nachdem in pixi die DF-Rechnung entweder in pixi über die Rechnungsautomatik oder über den API Call pixiDFCreateInvoices generiert und versendet wurde, wird die Bestellung in pixi mit dem Status AUS markiert.
Abbildung: Artikel lagernd |
Abbildung: Artikel nicht lagernd |
Abbildung: Prozess in API Calls (aus Sicht des DF-Dienstleisters) |
Besondere Prozesse
Kein eigenes Versandlager; Versand der Händler-Artikel durch den DF-Dienstleister
In diesem Szenario besitzt der Händler kein eigenes Versandlager. Die Artikel werden ausschließlich durch den DF-Dienstleister an die Endkunden verschickt. Die Artikel im Lager des DF-Dienstleisters befinden sich allerdings im Eigentum des Händlers.
Dies ist ein mögliches Szenario zur Verarbeitung der Bestellungen:
Nachdem die Bestellung über den Bestellimport oder manuell in pixi angelegt wurde, ruft der DF-Dienstleister alle Bestellungen des Händlers über die API Calls pixiGetOrderHeader und pixiGetOrderlines ab. Die Bestellzeilen der Bestellung befinden sich in pixi im Status HAL, wenn die Zahlung noch nicht geklärt wurde oder ANG, wenn die Bestellzeilen versandfertig sind.
-
Der DF-Dienstleister verarbeitet nun alle versandfertigen Bestellzeilen und kann Bestellungen in pixi mit pixiGetOrder auf etwaige Änderungen, die zwischen dem Import der Bestellungen und Verarbeiten der Bestellzeilen aufgetreten sind, prüfen.
Im gleichen Schritt können die Bestellzeilen oder die Bestellung in pixi über pixiUpdateOrderline oder pixiAddOrderComments mit einem Kommentar versehen, sodass ersichtlich ist, dass die Bestellung verarbeitet wird und Änderungen an der Bestellung nicht mehr durchgeführt werden sollten.
-
Hat der DF-Dienstleister die Artikel der Bestellung verarbeitet, wird der Bestellzeilenstatus der Artikel in pixi für alle abgearbeiteten Artikel über den API Call pixiUpdateOrderline auf den DF-Typ 1 gesetzt.
pixi setzt in diesem Fall den Bestellzeilenstatus der Artikel mit DF-Typ 1 auf FUT.
Da der Bestand der Artikel im Lager des DF-Dienstleisters das Eigentum des Händlers ist und dieser Bestand an alle angebundenen Kanäle exportiert wird, muss der Bestand für alle Artikel entsprechend korrigiert werden, die vom DF-Dienstleister gepickt wurden. Der DF-Dienstleister verringert daher den Bestand der gepickten Artikel mit pixiSetStockMultiple.
Nach der Bestandsanpassung wird der Bestellzeilenstatus dieser Artikel mithilfe von pixiDFSetStatus auf FUS gesetzt.
In pixi wird nun automatisch über die Rechnungsautomatik oder pixiDFCreateInvoices eine DF-Rechnung erstellt und die Bestellung automatisch auf AUS gesetzt - Sie gilt damit in pixi als versendet.
Abbildung: Bestellzeilenstatusverlauf in pixi |
Abbildung: Prozess in API Calls (aus Sicht des DF-Dienstleisters) |
Konfiguration
Wichtige Datenbank-Einstellungen
DF aktivieren: pixi Control Center > Datenbank Einstellungen > Direct Fulfillment
Diese Einstellung muss aktiviert sein, sodass Sie Direct Fulfillment nutzen können. Sollte diese Einstellung für Sie nicht aktiviert sein, kontaktieren Sie bitte Ihren zuständigen Account Manager für den Erwerb der Direct Fulfillment Lizenz.
DF API - Vollen Zugriff ohne Passwort erlauben: pixi Control Center > Datenbank Einstellungen > Direct Fulfillment
Ist diese Einstellung aktiviert, dann müssen beim Ausführen der API Calls zum Abrufen der DF-Bestellungen die Lieferantennummer und die Lieferantenkundennummer nicht übergeben werden.
Ist die Einstellung deaktiviert, dann müssen diese Informationen übergeben werden.
Fullfillment Typ 1 & Fullfillment Typ 2: pixi Control Center > Datenbank Einstellungen > Direct Fulfillment
Diese beiden Einstellungen müssen aktiviert sein, sodass Rechnungen automatisch für DF-Bestellungen, die Bestellzeilen im Status FUS beinhalten, über pixi Rechnungen erstellt werden.
Zeige Status FUA statt FUT: pixi Control Center > Datenbank Einstellungen > Kundenservice
Ist diese Einstellung aktiviert, wird statt dem Status FUT der Status FUA angezeigt, wenn die Bestellzeile durch den Fulfiller noch nicht mithilfe des API Calls pixiDFGetChangesConfirmation bestätigt wurde.
Berücksichtige diese Status für die Rechnung: pixi Control Center > Datenbank Einstellungen > Direct Fulfillment
Bestellungen mit dem hier eingetragenen Status, sind im pixi Versand, Reiter Direkter Rechnungsdruck sichtbar.
Wird hier FUT als Status hinterlegt, erscheinen Artikel mit diesem Status auf der Rechnung.
Pickliste, Bestellungen mit Status FUT einbeziehen: pixi Control Center > Datenbank Einstellungen > Versand
Wenn diese Einstellung aktiviert ist, dann werden Bestellungen, die auch Bestellzeilen im Status FUT enthalten bei der Erstellung einer Pickliste berücksichtigt. Dennoch erscheinen nur die Bestellzeilen der Bestellung, die sich im Status ANG befinden, tatsächlich auf der Pickliste.
Wenn diese Einstellung deaktiviert ist, werden alle Bestellungen mit Bestellzeilen im Status FUT von der Picklisten-Erstellung ausgeschlossen.
Standardwert: AUS.
Status FUT für Lieferantenbest. einbeziehen: pixi Control Center > Datenbank Einstellungen > Direct Fulfillment
Wenn Sie die Checkbox aktiviert haben (ON), werden Lieferantenbestellungen automatisch auch für offene Direct Fulfilment-Bestellungen generiert (Bestellungen, mit dem Status FUT) und FUT Bestellzeilen als Offene Bestellmenge interpretiert.
So können offene Bestellmengen in Status FUT bei Bestellvorschläge idR. für Methode On-Demand über den pixi Einkauf an DF-Lieferanten versendet werden. Bei Rückmeldung des Versands durch den Lieferanten, kann nun der Status der ältesten offenen Kundenbestellzeilen der versendeten Artikel über die API auf BES gestellt werden können, bis die Liefermenge erreicht ist.
Bestellimport
Beim Import der Bestellungen wird jeder Bestellung ein Flag mitgegeben, ob der Artikel oder eine Bestellung mit pixi selbst, d. h. im Versandlager des Händlers oder durch einen DF-Dienstleister versendet werden soll. Enthält die Bestellung dieses Flag nicht, wird der DF-Typ anhand folgender Datenbank-Einstellung ermittelt:
DF-Typ - Standardwert: pixi Control Center > Datenbank Einstellungen > Direct Fulfillment
Diese Einstellung bestimmt den Standardwert für den Direct Fulfillment-Typ einer Bestellzeile, wenn die Bestellimport-XML keinen Wert enthält.
Sie können Werte von 1 bis 3 eintragen.
Die Details zur Übergabe finden Sie in der in der openTRANS Syntax-Spezifikation.
DF-Lieferanten
Um einen Lieferanten als DF-Dienstleister zu kennzeichnen, müssen Sie diesen Lieferanten in der pixi Web-Applikation unter Einkauf > Lieferanten öffnen, und im Reiter Allgemein die Option Direct Fulfillment auf "Ja" setzen.
Weiterhin muss für diesen Lieferanten eine Kundennummer vergeben werden, welche bei der Verwendung von API Calls standardmäßig abgefragt bzw. neben der Lieferantennr. zusätzlich übergeben werden muss. Diese Kundennummer darf maximal 20 Zeichen lang sein.
In pixi LOU befindet sich die Lieferantenverwaltung im pixi Control Center > Tabellen > Lieferanten.
Weitere Informationen: Lieferanten
API-Calls
pixiDFGetOrders
Dieser API Call gibt alle noch offenen Bestellungen (ohne Versandsperre oder Kundensperre) des ausgewählten Lieferanten zurück.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
SupplNr |
varchar (4) |
nein |
Lieferantennummer in pixi, welche der DF-Dienstleister bedient (z.B. MGS für den Standardlieferanten) |
Secret |
varchar (20) |
nein |
Kundennummer des Lieferanten in pixi, diese wird als zusätzliche Sicherheit abgefragt |
AllOrders |
bit |
nein |
0 = nicht bestätigte Bestellungen werden zurückgegeben |
Die Rückgabe liefert neben kundenbezogenen Daten (Lieferadresse, etc.) folgende wichtige Werte für die Weiterverarbeitung durch den DF-Dienstleister:
Spalte |
Datentyp |
Beschreibung |
OrderNR |
int |
Bestellnummer der Kundenbestellung |
pixiDFGetOrderlines
Dieser API Call gibt die Bestellzeilen eines bestimmten Lieferanten der ausgewählten Bestellung zurück.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
OrderNR |
int |
ja |
Bestellnummer pixi aus dem vorherigen API Call pixiDFGetOrders => Spalte: OrderNR |
SupplNr |
varchar (4) |
nein |
Lieferantennummer in pixi, welche der DF-Dienstleister bedient (z.B. MGS für den Standardlieferanten) |
Secret |
varchar (20) |
nein |
Kundennummer des Lieferanten in pixi, diese wird als zusätzliche Sicherheit abgefragt |
AllOrderlines |
bit |
nein |
0 = nicht bestätigte Bestellzeilen im Status FUT |
Die Rückgabe liefert unter anderem folgende wichtige Werte für die Weiterverarbeitung durch den DF-Dienstleister:
Spalte |
Datentyp |
Beschreibung |
OrderlineRef |
int |
Eindeutige ID der Bestellzeile |
OrderHistKey |
int |
Eindeutiger Schlüssel für die Bestätigung der Bestellzeile durch den DF-Dienstleister |
pixiDFGetChanges
Dieser API Call gibt die Bestellzeilen eines bestimmten Lieferanten der ausgewählten Bestellung zurück, die noch nicht bestätigt wurden.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
OrderNR |
int |
ja |
Bestellnummer pixi aus dem vorherigen API Call pixiDFGetOrders => Spalte: OrderNR |
SupplNr |
varchar (4) |
nein |
Lieferantennummer in pixi, welche der DF-Dienstleister bedient (z.B. MGS für den Standardlieferanten) |
Secret |
varchar (20) |
nein |
Kundennummer des Lieferanten in pixi, diese wird als zusätzliche Sicherheit abgefragt |
AllOrderlines |
bit |
nein |
0 = nicht bestätigte Bestellzeilen im Status FUT |
Die Rückgabe liefert unter anderem folgende wichtige Werte für die Weiterverarbeitung durch den DF-Dienstleister:
Spalte |
Datentyp |
Beschreibung |
ordernr |
int |
Bestellnummer der Kundenbestellung |
OrderLineRef |
int |
Eindeutige ID der Bestellzeile |
OrderHistKey |
int |
Eindeutiger (max) Schlüssel für die Bestätigung der Bestellzeile durch den DF-Dienstleister |
pixiDFGetChangesConfirmation
Jede abgeholte Bestellzeile muss einzeln mit pixiDFGetChangesConfirmation bestätigt werden.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
SupplNr |
varchar (4) |
ja |
Lieferantennummer in pixi, welche der DF-Dienstleister bedient (z.B. MGS für den Standardlieferanten) |
Secret |
varchar (20) |
ja |
Kundennummer des Lieferanten in pixi, diese wird als zusätzliche Sicherheit abgefragt |
OrderHistKey |
int |
nein |
Der Schlüssel OrderHistKey aus dem vorherigen API Call pixiDFGetOrderlines oder pixiDFGetChanges => Spalte: OrderHistKey |
Anschließend taucht die Bestellzeile nicht mehr unter pixiDFGetOrderlines und (wenn alle Bestellzeilen markiert wurden) auch nicht mehr unter pixiDFGetOrders auf.
pixiDFUpdateOrderlineStatus
Mit pixiDFUpdateOrderlineStatus wird eine Bestellzeile als versendet markiert, kann storniert werden oder wird auf bestellt gesetzt.
Hinweis: Um ein Splitting bei Rechnungserstellung in pixi zu vermeiden, empfehlen wir bei Versandmeldungen die Verwendung von pixiDFSetStatus um alle Positionen eines Versandauftrags gemeinsam zu aktualisieren.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
SupplNr |
varchar (4) |
ja |
Lieferantennummer in pixi, welche der DF-Dienstleister bedient (z.B. MGS für den Standardlieferanten) |
Secret |
varchar (20) |
ja |
Kundennummer des Lieferanten in pixi, diese wird als zusätzliche Sicherheit abgefragt |
OrderHistoryKey |
int |
ja |
Der Schlüssel OrderHistoryKey aus dem vorherigen API Call pixiDFGetOrderlines |
Status |
varchar (3) |
ja |
FUS (Fulfillment Sent), wenn die Bestellzeile verschickt wurde |
DFShipDate |
datetime |
nein |
Versandzeitpunkt der Bestellung |
DFTrackingID |
varchar (100) |
nein |
Trackingnummer des Pakets, falls vorhanden; mehrere Tracking-IDs mit , trennen |
Qty |
int |
nein |
Menge der Bestellzeilen, deren Status geändert werden soll |
InvoiceNrExternal |
varchar (20) |
nein |
externe Rechnungsnummer, falls die Rechnung durch den DF-Dienstleister erstellt wird |
OrderLineRef |
int |
nein |
Eindeutige ID der Bestellzeile |
Die Rückgabe gibt den Error Code 200 zurück, wenn die Bestellzeile erfolgreich markiert wurde, andernfalls den Error Code 500 und eine Fehlerbeschreibung.
pixiDFSetStatus
[Empfohlen] Mit pixiDFSetStatus können mehrere Bestellzeilen storniert (DF-Typ 1, 2 und 3), auf bestellt (DF-Typ 2) gesetzt oder als versendet (DF-Typ 1 und 3) markiert werden.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
XML |
varchar (max) |
ja |
Es können mehrere Bestellzeilen in einem XML aktualisiert werden. Beispiel:
Info: Je nachdem, wo Sie den Call ausführen, muss der XML-Code von einem |
CreateInvoices |
varchar (1) |
nein |
N (Standard) = es wird keine Rechnung für die Bestellzeile erstellt |
SupplNr |
varchar (4) |
nein |
Lieferantennummer in pixi, welche der DF-Dienstleister bedient (z.B. MGS für den Standardlieferanten) |
Secret |
varchar (20) |
nein |
Kundennummer des Lieferanten in pixi, diese wird als zusätzliche Sicherheit abgefragt |
Die Rückgabe gibt den Error Code 200 zurück, wenn die Bestellzeile erfolgreich markiert wurde, andernfalls den Error Code 500 und eine Fehlerbeschreibung.
pixiDFCreateInvoices
Mit diesem API Call können Sie eine Rechnung für Fulfillment-Bestellungen mit Bestellzeilen im Status FUS erstellen.
Wird kein Parameter übergeben, dann hat der API Call die gleiche Funktion, wie die Schaltfläche Fulfillment-Rechnungen generieren in der pixi Rechnungen Applikation.
Parameter |
Datentyp |
Erforderlich |
Beschreibung |
OrderLinesXML |
varchar (max) |
nein |
Es können mehrere Bestellzeilen in einem XML aktualisiert werden. Beispiel:
Info: Je nachdem, wo Sie den Call ausführen, muss der XML-Code von einem |
ShowDetailedMessage |
BIT |
nein |
NULL / 0 = Kein Ergebnis |
Rückgabewerte:
Spalte |
Datentyp |
Beschreibung |
ReturnCode |
varchar (10) |
OK oder ERROR |
ErrorMessage |
varchar (512) |
OK
ERROR
|