Centre d’aide/Opérations Core/Outbound orders : de la pick list au bill of lading
12Opérations Core5 min de lecture

Outbound orders : de la pick list au bill of lading

Cinq types d’outbound, les documents générés par la plateforme, la gate qui garde le stock pas prêt hors d’une vente, et le revert quand une order doit revenir.

Un outbound order est le miroir d’un inbound : les assets sortent, la paperasse suit, la finance clôture le deal. La plateforme prend en charge chaque élément pour que l’opérateur n’ait pas à le reconstruire depuis zéro. Chaque order reçoit un numéro de la forme OUT-2026-00042, attribué par tenant et par année par la base de données sous verrou, pour que deux personnes créant un order à la même seconde ne se retrouvent jamais avec la même référence sur deux camions différents.

Cinq types d’outbound

Sale, recycling, internal transfer, return to client et donation. Le type détermine quels documents ont du sens et comment l’order se comporte. Une sale issue d’un deal Market ou d’une victoire en Auction emporte son deal avec elle ; une sale sans Market ni Auction derrière est une direct sale et exige un dossier de vente avant même de pouvoir exister — buyer, assets exacts, prix, choix de facturation et de settlement. Ce flow a son propre article, Direct sale, et celui-ci ne le répète pas.

L’ensemble documentaire

Pour chaque outbound, la plateforme génère les documents pertinents à la demande — pick list, packing slip, bill of lading, loading report, recycling certificate. Chacun est une route sous /core/outbound/[id]/{type}, rendue côté serveur et imprimable. Les document templates sont configurables par tenant et par type d’outbound via /settings/core/templates, donc un BOL pour une sale utilise un autre boilerplate que celui d’un internal transfer.

Pick list et l’onglet items

La pick list est le document du warehouse-floor : quelle palette, quel rack, quelle position, quel asset. Le mode outbound du scanner la suit — scannez un asset, la plateforme confirme qu’il est sur la bonne ligne et signale une erreur sinon. Sur l’order lui-même, l’onglet items cherche dans tous les items de l’order par asset tag, serial, modèle, grade, emplacement ou état de pick/pack avant d’afficher une page. Passer de picking à picked confirme que la pick list est faite ; passer de packing à ready to ship confirme que la pack list est faite.

La ready gate

Avant qu’un asset puisse atterrir sur une sale, il doit passer la ready gate : grades présents, un grade global vendable, une disposition resale, et une preuve d’erasure pour tout ce qui porte des données. Côté données, la plateforme lit le D-grade : D0 signifie non effacé et échoue à la gate ; D1, D2 et D3 passent, D3 étant l’effacement certifié. Un refurbishment journalisé n’est pas requis — « Tel que reçu » est une façon valable de vendre un device. Votre équipe règle un seul bouton sous /settings/core/outbound : un quality score minimum de 0 à 5, avec un interrupteur pour masquer tout ce qui est en dessous. La gate est appliquée côté serveur ; l’opérateur ne peut pas expédier par accident un asset D-grade à un buyer qui a payé du B-grade.

Annuler, revert, et ce qui ne bouge pas

Un order dont l’expédition n’a pas commencé peut être annulé avec une raison. Si cet order est adossé à un escrow held, l’argent ne reste pas suspendu avec lui : la plateforme passe l’escrow en refunded, crée un settlement de remboursement acheteur et enregistre quelle annulation l’a provoqué. Une fois qu’un order est shipped, partiellement shipped ou delivered, l’annulation n’est plus l’outil — le revert l’est. Reverter un order expédié ou partiellement expédié le ramène à ready to ship, efface les flags d’expédition et rend aux assets réellement expédiés leur statut et leur workflow stage d’avant l’expédition ; un item jamais parti est laissé tranquille. L’evidence reste comme record historique. Un escrow held reste held tant qu’un chemin escrow distinct ne déplace pas l’argent. Là où un admin override est requis, il lui faut une vraie raison. « Parce que j’ai cliqué dessus » n’est pas une raison. C’est un aveu.

L’annulation, l’enregistrement éventuel du remboursement et la trace d’audit sont sauvegardés ensemble, y compris via une intégration. En cas d’échec, l’état précédent reste intact. Répéter la même demande ne crée pas de remboursement en double, et une expédition simultanée ne peut pas rouvrir la commande annulée. Cet enregistrement n’exécute aucun virement bancaire.

Les deals cross-tenant partent protégés, ou ne partent pas

Une sale issue d’un deal Market ou Auction ne peut partir que si l’escrow est held ou waived, ou si le deal porte un mutual waiver confirmé. Une escrow row absente n’est pas un waiver, et une raison de non-escrow saisie dans un dossier de direct sale n’est pas valable pour un outbound de deal. La finance peut toujours dire si les fonds étaient protégés ou délibérément réglés en dehors — et si ni l’un ni l’autre n’est démontrable, le camion attend.

Transporteurs

Le tracking a besoin d’un transporteur. Un tenant qui n’en a configuré aucun voit « Aucun transporteur configuré » sur le formulaire de tracking, avec un lien vers Paramètres → Transporteurs, où « Créer les transporteurs par défaut » ajoute les plus courants en un clic. La liste de transporteurs que votre équipe configure est la liste dans laquelle vos opérateurs peuvent choisir — rien de global, rien de périmé.