pixi

Direct Fulfillment

Ü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:

  1. Die vom Endkunden bestellten Artikel werden direkt durch den Fulfillment-Dienstleister an den Endkunden verschickt.

  2. 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)

Zum Seitenanfang

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

0 / leer

pixi versendet

pixi versendet die Bestellzeile direkt an den Endkunden - kein Direct Fulfillment.
Diese Bestellzeilen werden i. d. R. gar nicht an den Direct Fulfillment-Dienstleister übermittelt.

1

DF-Dienstleister versendet

Die Bestellzeile wird komplett an den Direct Fulfillment-Dienstleister übergeben.
Dieser verarbeitet die Bestellung und versendet die Bestellung an den Endkunden.

2

pixi versendet;
die Ware wird allerdings beim DF-Dienstleister bestellt

Die Bestellzeile wird über pixi versendet.
Sollte der Artikel nicht vorrätig sein (verfügbarer Bestand (reserviert) < bestellte Anzahl des Artikels) wird dieser beim DF-Dienstleister bestellt.
WICHTIG: Die Ware muss zum Händler verschickt werden, nicht an den Endkunden.

3

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 die Artikel nicht auf Lager und ein DF-Lieferant ist den Artikeln zugewiesen, wird die jeweilige Bestellzeile mit Status FUT markiert und der DF-Dienstleister verschickt die Ware zum Endkunden.


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.

Zum Seitenanfang

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).

Zum Seitenanfang

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)

Zum Seitenanfang

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)

Zum Seitenanfang

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)

Zum Seitenanfang

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)

Zum Seitenanfang

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.

Zum Seitenanfang

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.

Zum Seitenanfang

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

Zum Seitenanfang

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
1 = alle Bestellungen des Lieferanten 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

Zum Seitenanfang

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
1 = alle Bestellzeilen im Status FUT, inkl. der bereits bestätigten


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

Zum Seitenanfang

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
1 = alle Bestellzeilen im Status FUT, inkl. der bereits bestätigten


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

Zum Seitenanfang

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.

Zum Seitenanfang

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
oder pixiDFGetChanges => Spalte: OrderHistKey

Status

varchar (3)

ja

FUS (Fulfillment Sent), wenn die Bestellzeile verschickt wurde
STO (Storniert), wenn die Bestellzeile nicht verschickt werden kann
BES (Bestellt), wenn die Bestellzeile beim DF-Dienstleister bestellt 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.

Zum Seitenanfang

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:

<SETDFSTATUS>
<ITEM>
<ORDERHISTORYKEY>432046</ORDERHISTORYKEY>
<STATUS>FUS</STATUS>
<QTY>1</QTY>
<SHIPDATE>20160114 16:46:12</SHIPDATE>
<TRACKINGID>233242345345</TRACKINGID>
<INVOICENREXTERNAL>RE234234</INVOICENREXTERNAL>
</ITEM>
<ITEM>
<ORDERHISTORYKEY>384578</ORDERHISTORYKEY>
<STATUS>FUS</STATUS>
<QTY>1</QTY>
<SHIPDATE>20160114 16:46:12</SHIPDATE>
<TRACKINGID>233242345345</TRACKINGID>
<INVOICENREXTERNAL>RE234234</INVOICENREXTERNAL>
</ITEM>
</SETDFSTATUS>
  • OrderHistoryKey: eindeutige ID der Bestellzeile

  • Status: Status, auf den die Bestellzeile gesetzt werden soll

  • Qty: Menge der Bestellzeile für die Statusänderung

  • ShipDate: Versanddatum der Bestellzeile festlegen (DF Versandt am)

  • TrackingID: DF TrackingID zur Bestellzeile

  • InvoiceNrExternal: Rechnungsnr. zur Bestellzeile (wird nicht im Kundenservice angezeigt)

Info: Je nachdem, wo Sie den Call ausführen, muss der XML-Code von einem
<![CDATA[...]]> Block umschlossen werden.

CreateInvoices

varchar (1)

nein

N (Standard) = es wird keine Rechnung für die Bestellzeile erstellt
Y = es wird eine 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.

Zum Seitenanfang

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:

<Orderlines>
<Orderline>
<OrderlineKey>12345</OrderlineKey>
<ShipVendor>DHL</ShipVendor>
<ShipmentTrackingId>tracking2;tracking1;</ShipmentTrackingId>
<ReturnTrackingId>return1;</ReturnTrackingId>
</Orderline>
<Orderline>
<OrderlineKey>67890</OrderlineKey>
<ShipmentTrackingId>tracking3;tracking4;</ShipmentTrackingId>
</Orderline>
<Orderline>
<OrderlineKey>13579</OrderlineKey>
</Orderline>
</Orderlines>

  • OrderlineKey: eindeutige ID der Bestellzeile

  • ShipVendor: Logistiker, der für die Rechnung verwendet werden soll
    (max. 3 Zeichen)

  • ShipmentTrackingId: Versand-Tracking-ID(s), durch Semikolon getrennt
    (max. 512 Zeichen)

  • ReturnTrackingId: Retouren-Tracking-ID(s), durch Semikolon getrennt
    (max. 512 Zeichen)

Info: Je nachdem, wo Sie den Call ausführen, muss der XML-Code von einem
<![CDATA[...]]> Block umschlossen werden.

ShowDetailedMessage

BIT

nein

NULL / 0 = Kein Ergebnis
1 = Der Call gibt je nach Status (OK, ERROR) unterschiedliche Meldungen zurück



Rückgabewerte:

Spalte

Datentyp

Beschreibung

ReturnCode

varchar (10)

OK oder ERROR

ErrorMessage

varchar (512)

OK

  • Direct fulfilment Invoice(s) created with invoice number(s): "Rechnungsnummer(n)"

ERROR

  • XML is empty or not proper. Please review and adapt.

  • Ship vendor code is too long, field size max. of 3 characters was reached. Please review and adapt.

  • TrackingId is too long, field size max. of 512 characters was reached. Please review and adapt.

  • ReturnTrackingId is too long, field size max. of 512 characters was reached. Please review and adapt.

  • One or more orderline keys does not exist in database. Please review and adapt.

Zum Seitenanfang