Bestellungen und Checkout

Eine Bestellung trägt drei voneinander unabhängige Status und ein Kennzeichen, und die meisten Bestellfragen beantworten sich, wenn Sie alle drei lesen, bevor Sie etwas anfassen. Der Lebenszyklus sagt, wo die Bestellung steht, der Zahlungsstatus, ob Geld angekommen ist, und der Erfüllungsstatus wird aus dem abgeleitet, was versandt wurde.

Eine Bestellung bewegt sich seit einer Woche nicht. Was prüfe ich?

Sechs Ursachen, die günstigste zuerst: Sie ist gesperrt, und das Banner nennt den Grund; sie wartet auf Freigabe, und Ihre Schwelle ist womöglich so niedrig, dass gewöhnliche Bestellungen in der Warteschlange landen; der Bestand fehlt, oft weil available null ist, obwohl on_hand gut aussieht; das ERP hat sie nie übernommen, erkennbar an einem leeren acknowledged_at bei einer tagealten Bestellung; sie wurde aus dem Lagersystem versandt, ohne dass eine Sendung erfasst wurde; oder niemand ist für die Warteschlange zuständig. Siehe Bestellungen, die hängen bleiben.

Was bedeuten die drei Statusfelder an einer Bestellung?

status ist der Lebenszyklus: pending, placed, in_fulfillment, completed oder cancelled, bewegt durch Aktionen wie Bestätigen und Versenden. payment_status wird von der Payments-App gespeist oder für eine Überweisung von Hand gesetzt. fulfillment_status setzt niemand; er wird aus den Positionsmengen gelesen und steht auf partial, sobald ein Teil versandt ist. placed / open / partial heißt bestätigt, unbezahlt und halb geliefert, alles zugleich und vollkommen korrekt. Siehe Die drei Bestellstatus.

Warum steht eine Bestellung auf abgeschlossen, obwohl sie nicht bezahlt ist?

Weil eine Bestellung standardmäßig abschließt, sobald jede Position versandt ist, und auf Rechnung kommt die Zahlung später. Wenn für Sie eine unbezahlte Bestellung eine offene Bestellung ist, stellen Sie den Abschluss auf vollständigen Versand und Zahlung um, oder auf manuell. So oder so: Mahnen Sie die Zahlung, nicht die Bestellung. Gefährdeter Umsatz ist eine Frage von payment_status, und kein Bericht allein auf status wird ihn zeigen. Siehe Die drei Bestellstatus.

Die Bestellung ist nie im ERP angekommen. Wo sehe ich nach?

An drei Stellen, in dieser Reihenfolge: im Tab History der Bestellung, wo ein Platzierungs-Event ohne Folgeeintrag bedeutet, dass die Bestellung korrekt aufgegeben wurde und das Problem dahinter liegt; unter Integration Studio › Ausführungen, dem Bildschirm, der die Frage „die Bestellung kam nie in SAP an" beantwortet; und beim Event selbst, denn Integrationen reagieren auf das Platzierungs-Event und nicht auf eine neue Zeile. Eine tagealte Bestellung ohne Bestätigung ist ein Integrationsalarm, kein langsames Lager. Siehe Bestellungen mit dem ERP abgleichen.

Bestellungen kommen doppelt im ERP an.

Das Leben einer Bestellung wird absichtlich zweimal veröffentlicht: als benannte Events für jedes Ereignis und als roher Audit-Feed jedes Übergangs. Ein Workflow, der beides abonniert, verarbeitet jede Bestellung doppelt. Nehmen Sie die benannten Events für alles, was handelt, und behalten Sie den rohen Feed für Archive. Die andere Ursache ist ein Empfänger, der nach einem Timeout erneut versucht und nicht über die Message-ID dedupliziert. Siehe Bestellungen mit dem ERP abgleichen.

Wie versende ich einen Teil einer Bestellung?

Öffnen Sie die Bestellung, wählen Sie Create shipment (Sendung anlegen) und tragen Sie je Position die Menge ein, die tatsächlich geht; Positionen auf null bleiben offen. Die Sendung bekommt eine eigene Nummer, quantity_shipped der Zeilen steigt, und die Bestellung steht auf in_fulfillment / partial. Wiederholen Sie das für die nächste Lieferung; geht die letzte offene Menge raus, schließt die Bestellung ab. Rechnen Sie nicht selbst; die Bestellung kennt die offene Menge je Position. Siehe Teillieferungen und Rückstände.

Wo ist die Rückstandsliste?

Es gibt kein Rückstandsobjekt. Eine Position mit offener Menge ist der Rückstand, und die offene Menge ist quantity − quantity_shipped − quantity_cancelled. Ihre Rückstandsliste ist die Bestellliste, gefiltert auf fulfillment_status = partial, plus die placed-Bestellungen, die noch nicht begonnen haben. Ob ein Rückstand überhaupt entstehen darf, regelt die Rückstandsrichtlinie des Bestandssystems. Siehe Teillieferungen und Rückstände.

Kann ich die Lieferadresse nach der Bestätigung noch ändern?

Hier standardmäßig nicht. Die Bestätigung ist der Moment, in dem das ausführende System die Bestellung übernimmt, und danach sind Adressen, Käuferdaten und Referenzen eingefroren, weil zwei Systeme, die parallel an einer Bestellung arbeiten, der Weg sind, auf dem Ware an die alte Adresse geht. Ein Tenant kann späte Änderungen erlauben, aber tun Sie das bewusst. Siehe Bestellung bearbeiten.

Der Shop sagt ausverkauft und das Regal ist voll.

Veraltete Reservierungen, fast immer. Ein abgebrochener Checkout, der Bestand reserviert hat und kein Ablaufdatum trägt, hält ihn für immer, und available ist on_hand − reserved. Prüfen Sie unter Order Management › Bestand › Reservierungen aktive Reservierungen auf Bestellungen, die nie aufgegeben wurden, führen Sie Release expired (abgelaufene freigeben) aus und setzen Sie eine Reservierungsdauer, damit es nicht wieder passiert. Beheben Sie es nicht mit einer Korrekturbuchung von +20; damit stimmt on_hand auch nicht mehr. Siehe Wenn Bestandszahlen driften.

Wie wickle ich eine Retoure ab, und erstattet sie dem Kunden Geld?

Erfassen Sie sie aus dem Tab Fulfilment der Bestellung mit Positionen, Grund und einer Wiedereinlagerungsentscheidung je Position; bearbeiten Sie sie unter Order Management › Retouren über registered, received und completed. Eine Retoure bewegt nur Ware und Mengen. Die Gutschrift entsteht in Ihrer Buchhaltung, und eine Erstattung auf eine Zahlung ist eine eigene Aktion, bei der refunded vollständig erstattet heißt. Siehe Retouren und Gutschriften.

Eine teilweise versandte Bestellung steht noch auf placed.

Von innen unmöglich, denn eine Sendung bewegt den Lebenszyklus auf in_fulfillment. Es heißt, jemand hat aus dem Lagersystem versandt und die Sendung hier nie erfasst. Erfassen Sie sie jetzt, nachträglich; die Bestellung korrigiert sich nicht selbst, und jeder Bericht bis dahin ist falsch. Siehe Bestellungen, die hängen bleiben.

Was ist die Kundenbestellnummer, und warum ist sie wichtig?

Die eigene Bestellnummer des Käufers, im Checkout eingegeben und als customer_order_number gespeichert. Seine Kreditorenbuchhaltung gleicht Ihre Rechnung damit ab, und eine Rechnung ohne sie kommt häufig unbezahlt zurück. Sie ist eine von drei Referenzen an einer Bestellung: Ihre eigene number, seine Bestellnummer und die external_ref des ERP, die bei der Bestätigung geschrieben wird. Siehe Bestellungen mit dem ERP abgleichen.

Was blockiert das Sperren einer Bestellung?

Das ist eine mandantenweite Einstellung: nur den Versand, Versand und Stornierung, oder nichts, womit das Kennzeichen eine sichtbare Warnung ist und mehr nicht. Nutzen Sie Sperren für Bonitätsprüfungen, ist das Blockieren der Stornierung meist richtig, denn Sie wollen die Bestellung nicht unter der laufenden Prüfung weg storniert sehen. Release hold (Sperre aufheben) stellt sie zurück in die Warteschlange. Siehe Die drei Bestellstatus.