Der Lebenszyklus einer Bestellung

Im B2B beginnt mit dem Aufgeben einer Bestellung ein Prozess, statt dass einer endet. Er läuft Tage oder Wochen, beteiligt Ihr Lager, Ihr ERP, einen Versanddienstleister und die Kreditorenbuchhaltung Ihres Kunden, und er muss für alle Beteiligten hinterher noch erklärbar sein. Dieser Artikel handelt davon, was eine Bestellung ist, bevor sie ein Bildschirm ist, auf dem Sie klicken.

Eine Bestellung ist ein Snapshot, keine Live-Ansicht

Die wichtigste Eigenschaft einer Bestellung hier: Sie wird in dem Moment eingefroren, in dem sie aufgegeben wird.

Jede Position trägt eine Kopie des Produkts, wie es beim Aufgeben aussah (Name, Preis, Einheit, Steuersatz), in ihrem eigenen product-Snapshot. Käufer, Rechnungsadresse, Lieferadresse, die gewählte Zahlungsvereinbarung und die gewählte Versandvereinbarung werden alle auf die Bestellung kopiert. Die Summen (subtotal, tax_total, shipping_total, grand_total) werden einmal aus den Positionen berechnet und nie neu gerechnet.

Das ist Absicht, und es unterscheidet eine Bestellung von einem Warenkorb:

Woher Bestellungen kommen

Bestellungen kommen von außerhalb des Cockpits:

• aus einem Checkout in Ihrer Storefront,
• aus einer gespeicherten Bestellliste des Käufers, mit einem Klick umgewandelt,
• aus einer Schnellbestellung oder einem Warenkorb-Upload,
• aus einer Punchout-Sitzung im Beschaffungssystem Ihres Kunden (Punchout erklärt),
• aus EDI oder Ihrem ERP über die API, dieselbe Tür, die auch die Storefront benutzt.

Im Cockpit bearbeiten Sie eine Bestellung, Sie tippen dort keine ein. Nimmt Ihr Innendienst noch Bestellungen am Telefon an, muss auch diese Bestellung durch eine dieser Türen hinein, sonst bleibt die Hälfte Ihres Bestellvolumens für jeden Bericht unsichtbar, den Sie später bauen.

Die fünf Zustände

status ist die Lebenszyklus-Dimension. Sie hat fünf Werte und einen geraden Weg:

pending ──► placed ──► in_fulfillment ──► completed
   │            │              │
   └────────────┴──────────────┴──► cancelled

completed und cancelled sind die beiden Endzustände. Alles andere ist eine offene Bestellung. Filtern Sie eine Arbeitsliste nach dieser Frage, „Ist die Bestellung noch offen?“, statt nach einer Liste von Statusnamen, die Sie pflegen müssen.

Wo completed liegt, ist eine Einstellung. Der Zustand kann bei vollständiger Lieferung erreicht werden, bei vollständiger Lieferung und Zahlung, oder nie automatisch. Siehe Die drei Bestellstatus.

Positionen führen ihre eigenen Bücher

Ein Status auf Bestellebene kann „sechs von zehn geliefert“ nicht ausdrücken. Deshalb trägt jede Position vier Mengen:

Die offene Menge einer Position ist quantity − quantity_shipped − quantity_cancelled. Jede Teillieferung, Teilstornierung und Teilretoure in der Plattform ist Arithmetik auf diesen vier Zahlen. Die Plattform führt keinen eigenen Rückstandsdatensatz, der davon abweichen könnte.

Positionen tragen außerdem position (10, 20, 30; der Schritt ist konfigurierbar, siehe Nummernkreise), eine unit, eine cost_center und einen freien position_text. Eine Position kann ein Katalogprodukt sein, eine configuration (ein konfigurierter Artikel mit seinen Optionen im Feld configuration) oder eine custom-Zeile für etwas, das gar nicht im Katalog steht.

Die zwei Referenzen, auf denen B2B läuft

Zwei Textfelder entscheiden, ob Ihre Bestellung auf der anderen Seite zugeordnet werden kann.

customer_order_number ist die eigene Bestellnummer des Käufers, seine Nummer und nicht Ihre. Im deutschen B2B ist dieses Feld das, was Ihre Rechnung bezahlt bekommt. Das ERP des Käufers hat eine Bestellung angelegt, bevor er Ihren Shop überhaupt geöffnet hat; seine Kreditorenbuchhaltung gleicht Ihre Rechnung dagegen ab, und eine Rechnung ohne diese Nummer kommt regelmäßig unbezahlt zurück. Erfassen Sie sie im Checkout, drucken Sie sie auf jedes Dokument, und verstecken Sie sie nie in einem Kommentarfeld.

external_ref zeigt in die andere Richtung: Es ist die Identität der Bestellung in Ihrem abwickelnden System. Das ERP schreibt sie zurück, wenn es die Bestellung bestätigt.

acknowledged_at ist der Zeitstempel dieser Bestätigung, und er ist eine Grenze. Solange er nicht gesetzt ist, lässt sich eine Bestellung noch eng begrenzt ändern: Adressen, Käuferdaten, Referenzen. Danach gehört die Bestellung dem abwickelnden System, und Änderungen laufen über dieses System. Ein Mandant, der späte Adresskorrekturen braucht, kann Änderungen nach der Bestätigung zulassen. Der Standard ist die eingefrorene Bestellung, denn zwei Systeme, die dieselbe Bestellung parallel bearbeiten, sind der Grund, warum eine Lieferung an die alte Adresse geht.

Gesperrt ist eine eigene Markierung

on_hold ist eine Markierung mit eigenem hold_reason, und sie steht quer zu allem oben. Während einer Bonitätsprüfung, eines offenen Streitfalls oder einer Zollfrage bleibt die Bestellung genau dort im Lebenszyklus, wo sie ist, und kommt nicht weiter. Was eine Sperre blockiert, ist konfigurierbar: den Versand, Versand und Stornierung, oder nichts (nur Hinweis). Eine gesperrte Bestellung zeigt auf ihrer Detailseite ein Banner mit der Aktion Sperre aufheben.

So funktioniert es in der Revenue Cloud

Die Orders-App ist der Kern der Bestellabwicklung. Im Cockpit finden Sie sie unter Order Management › Bestellungen, daneben Retouren und Sendungen, und Nummernkreise unter Configuration.

Die Detailseite einer Bestellung ist aus dem Modell oben aufgebaut:

Der Reiter Verlauf ist die Prüfspur, und er ist derselbe Strom, den Ihre Integrationen abonnieren: Jede Aktion schreibt ein Event, und auf diese Events reagiert ein ERP-Workflow oder eine Benachrichtigung. Siehe Events und Webhooks.

Weiter

• Die drei Bestellstatus: das Konzept, von dem alles andere in diesem Bereich abhängt.
• Eine Bestellung bearbeiten: die tägliche Schleife.