Outbound Orders: von der Pickliste zum Frachtbrief

Ein Outbound Order ist der Spiegel eines Inbound: Assets gehen raus, der Papierkram folgt, die Finance schließt den Deal ab. Die Plattform übernimmt jedes Stück davon, damit der Operator es nicht von Grund auf neu zusammenbaut. Jeder Auftrag bekommt eine Nummer in der Form OUT-2026-00042, vergeben pro Tenant und Jahr von der Datenbank unter einem Lock, sodass zwei Personen, die in derselben Sekunde Aufträge anlegen, nie dieselbe Referenz auf zwei verschiedenen Lkw stehen haben.

Fünf Outbound-Typen

Verkauf, Recycling, interner Transfer, Rückgabe an den Kunden und Spende. Der Typ steuert, welche Dokumente Sinn ergeben und wie sich der Auftrag verhält. Ein Verkauf, der aus einem Market-Deal oder einem Auction-Zuschlag kommt, trägt seinen Deal mit sich; ein Verkauf ohne Market oder Auction dahinter ist ein Direktverkauf und braucht ein Verkaufsdossier, bevor er überhaupt existieren kann — Käufer, genaue Assets, Preis, Rechnungs- und Settlement-Entscheidungen. Dieser Ablauf hat einen eigenen Artikel, Direktverkauf, und dieser hier wiederholt ihn nicht.

Der Dokumentensatz

Für jeden Outbound erzeugt die Plattform die passenden Dokumente auf Abruf — Pickliste, Lieferschein, Frachtbrief, Verladebericht, Recyclingzertifikat. Jedes ist eine Route unter /core/outbound/[id]/{type}, serverseitig gerendert und druckbar. Dokumentvorlagen sind pro Outbound-Typ tenant-konfigurierbar über /settings/core/templates, sodass ein Frachtbrief für einen Verkauf andere Textbausteine nutzt als einer für einen internen Transfer.

Pickliste und der Items-Tab

Die Pickliste ist das Dokument für die Lagerfläche: welche Palette, welches Rack, welche Position, welches Asset. Der Outbound-Modus des Scanners läuft sie ab — Asset scannen, die Plattform bestätigt, dass es auf der richtigen Zeile steht, und meldet einen Fehler, wenn nicht. Auf dem Auftrag selbst sucht der Items-Tab über jede Position des Auftrags nach Asset-Tag, Seriennummer, Modell, Grade, Standort oder Pick- und Pack-Status, bevor er eine Seite zeigt. Der Wechsel von „wird gepickt“ auf „gepickt“ bestätigt, dass die Pickliste erledigt ist; der Wechsel von „wird gepackt“ auf „versandbereit“ bestätigt, dass die Packliste erledigt ist.

Das Ready-Tor

Bevor ein Asset auf einem Verkauf landen darf, muss es das Ready-Tor passieren: Grades vorhanden, ein verkaufbarer Gesamt-Grade, eine Wiederverkaufs-Disposition und ein Löschnachweis für alles, was Daten trägt. Auf der Datenseite liest die Plattform den D-Grade: D0 heißt nicht gelöscht und fällt am Tor durch; D1, D2 und D3 kommen durch, wobei D3 die zertifizierte Löschung ist. Eine protokollierte Aufbereitung ist nicht nötig — „Wie erhalten“ ist eine gültige Art, ein Gerät zu verkaufen. Ihr Team stellt unter /settings/core/outbound genau einen Regler: einen minimalen Quality Score von 0 bis 5, mit einem Schalter, um alles darunter auszublenden. Das Tor wird serverseitig durchgesetzt; der Operator kann nicht versehentlich ein D-Grade-Asset an einen Käufer schicken, der für B-Grade bezahlt hat.

Stornieren, zurücknehmen — und was stehen bleibt

Ein Auftrag, dessen Versand noch nicht begonnen hat, lässt sich mit Begründung stornieren. Hängt an diesem Auftrag ein gehaltenes Escrow, hängt das Geld nicht mit daran: Die Plattform setzt das Escrow auf erstattet, legt ein Settlement für die Käufererstattung an und hält fest, welche Stornierung das ausgelöst hat. Sobald ein Auftrag verschickt, teilweise verschickt oder zugestellt ist, ist Stornieren nicht mehr das Werkzeug — Zurücknehmen ist es. Das Zurücknehmen eines verschickten oder teilweise verschickten Auftrags setzt ihn auf versandbereit zurück, löscht die Versand-Flags und bringt die tatsächlich verschickten Assets in ihren Status und ihre Workflow-Stage von vor dem Versand zurück; eine Position, die nie verschickt wurde, bleibt unangetastet. Evidence bleibt als historischer Nachweis stehen. Gehaltenes Escrow bleibt gehalten, solange kein eigener Escrow-Weg Geld bewegt. Wo ein Admin-Override nötig ist, braucht er eine echte Begründung. „Weil ich draufgeklickt habe“ ist keine Begründung. Das ist ein Geständnis.

Stornierung, eine mögliche Erstattungsbuchung und der Auditnachweis werden gemeinsam gespeichert, auch über eine Integration. Bei einem Fehler bleibt der vorherige Zustand erhalten. Dieselbe Anfrage erneut zu senden erzeugt keine doppelte Erstattung; ein gleichzeitiger Versand kann den stornierten Auftrag nicht wieder öffnen. Diese Buchung führt keine Banküberweisung aus.

Cross-Tenant-Deals fahren mit Absicherung oder gar nicht

Ein Verkauf, der aus einem Market- oder Auction-Deal kommt, darf erst raus, wenn das Escrow gehalten oder erlassen ist oder der Deal einen bestätigten beidseitigen Verzicht trägt. Eine fehlende Escrow-Zeile ist kein Verzicht, und ein Kein-Escrow-Grund, der in ein Direktverkaufs-Dossier getippt wurde, gilt für einen Deal-Outbound nicht. Die Finance kann jederzeit sagen, ob die Mittel abgesichert waren oder bewusst außerhalb abgewickelt wurden — und wenn sich keines von beidem belegen lässt, wartet der Lkw.

Carrier

Tracking braucht einen Carrier. Ein Tenant, der noch keinen eingerichtet hat, sieht im Tracking-Formular „Noch keine Transportdienstleister eingerichtet“, mit einem Link zu Einstellungen → Versanddienstleister, wo „Standarddienste anlegen“ die gängigen mit einem Klick hinzufügt. Die Liste der Carrier, die Ihr Team konfiguriert, ist die Liste, aus der Ihre Operators wählen können — nichts Globales, nichts Abgestandenes.