Commandes, exécution et réception
Cette page décrit la chaîne commande, plan d’exécution, remise et réception. Les actions dépendent des droits, du client, de l’entité juridique et de l’état du processus.
Créer et confirmer une commande
Ouvrez /operations/orders/new ou partez de la fiche client. Ajoutez une ou plusieurs lignes, de 1 à 40. Chaque ligne possède sa propre offre du catalogue, quantité, unité et conditions tarifaires figées ; la dernière ligne ne peut pas être supprimée. Les devises mixtes sont interdites et bloquent l'envoi. Si le répertoire ou les conditions sont indisponibles, n’utilisez pas zéro et ne créez pas à l’aveugle ; l’erreur de conditions concerne la ligne fautive et permet une nouvelle tentative sur celle-ci.
\nAprès avoir choisi le client et la première offre/prix, le portail propose un nom du type « offre — client ». Tant que vous ne le modifiez pas, un changement de sélection actualise la proposition ; après une modification manuelle, votre texte est conservé. Une commande peut rester sans nom et reçoit un libellé neutre dans la liste : n’inventez pas de données pour remplir le formulaire.
Le cycle est draft → submitted → confirmed → provisioned. Enregistrez le brouillon, envoyez-le avec une référence, puis confirmez la version actuelle. La confirmation crée l’engagement et le provisionnement le plan d’exécution. Si une action n’est pas acceptée, vérifiez les droits et les champs requis, rechargez la commande, puis réessayez.
Pour une ligne de service géré (managed_service), l’action distincte Connecter le service crée ou réutilise le droit de service. Confirmer la commande ou démarrer le plan ne crée pas ce droit à lui seul. Si l’action est indisponible ou qu’aucun droit n’apparaît dans Services et SLA, vérifiez l’état de la ligne et l’accès, relisez la fiche et ne réessayez qu’avec les données actuelles.
Dans /operations/orders, les filtres acceptent draft, submitted, confirmation_pending, confirmed, on_hold et completed. Les lignes peuvent porter provisioned, fulfilled, cancelled ou closed; ces états restent visibles dans la commande. La liste propose tableau/cartes, totaux, pagination, nouvelle tentative et états vides.
Si vous avez accès à une ligne, ouvrez la fiche de la commande à l’adresse /operations/orders/:orderId pour consulter les lignes, les parties, le statut et l’étape suivante disponible. L’URL est accessible directement et peut être partagée avec vos collègues, mais l’accès reste soumis aux droits.
Pour une commande confirmée, la fiche affiche aussi l’avancement de chaque ligne du plan : planned, in_progress, handed_over, accepted ou cancelled. Lorsque la quantité remise atteint la quantité requise, la ligne est indiquée comme entièrement remise, même si le statut du plan parent n’est pas encore synchronisé. Pour agir, ouvrez /operations/fulfillment et relisez la ligne actuelle ; ne déduisez pas la remise du seul statut de la commande parente.
Le registre commence avec tous les clients lisibles, charge jusqu’à 25 lignes et poursuit la liste avec Afficher plus. Les filtres de statut/client et le choix tableau/cartes sont locaux ; vide, vide après filtre et erreur de chargement sont des états différents.
Lorsque les lectures liées réussissent, le passeport de commande affiche Ce qui est issu de cette commande avec des liens vers la fiche d’engagement et la réception. Le bloc peut manquer si le résultat est vide ou si la lecture échoue ; son absence ne prouve pas qu’aucun enregistrement dérivé n’existe.
Préparer l’exécution
Dans /operations/fulfillment, vérifiez le plan et ses lignes. planning ou blocked devient ready, puis ready ou partially_completed peut démarrer. Chaque transition exige une confirmation ou référence non vide et la version actuelle. Une commande confirmée ne signifie pas à elle seule que le plan est prêt ; vérifiez lignes, quantité, unité, responsable et entité juridique. Un paquet de travail absent peut ne pas être créé ou être lié dans la section des paquets de travail.
Démarrer le plan et remettre une ligne individuelle sont deux étapes différentes. Le démarrage met le plan en cours, mais ne remet aucune ligne. La remise n’est disponible que lorsque le plan est in_progress et que la ligne choisie conserve une quantité non remise ; vérifiez son statut et le reste avant d’agir.
Le registre des remises couvre tous les clients par défaut ; le filtre client est local à cet écran et n’est pas conservé. Le bloc des plans promis mais pas encore remis ne se charge qu’après la sélection d’un client ; effacez le filtre pour revenir à toutes les remises. Un bloc de plans vide sans client sélectionné ne prouve pas l’absence de données.
Chaque remise affichée sur la fiche client renvoie désormais ici avec ce client déjà présent dans le filtre de l’URL, et la ligne ouvre une fiche de détail distincte à l’adresse /operations/fulfillment/deliveries/:deliveryId. Cette fiche sert à consulter les détails et l’état ; les actions de ligne Ouvrir la réception, Retourner, Corriger, Signaler un problème et Annuler restent lancées depuis ce registre. La ligne utilise le nom d’affichage humain de la remise lorsqu’il existe et ne retombe sur le mode de remise que pour les anciennes données.
À l’ouverture, la route de détail peut d’abord afficher un chargement ; attendez sa fin sans en déduire que les données sont absentes. Une erreur temporaire propose Réessayer ; cette reprise relit la fiche sans exécuter d’action. Si l’accès est refusé, demandez l’autorisation ou revenez au registre : cela ne signifie pas que la remise est absente. Une fiche sans lignes peut être un état vide valide : aucune action n’y démarre et ce n’est pas une erreur en soi.
Les remises utilisent le registre partagé, avec tableau/cartes et menu d’actions par ligne. Les actions indisponibles restent visibles avec leur motif ; après une opération, relisez le registre, car le message de succès ne remplace pas la vérification du statut obtenu.
Une cellule « Dossier de travail » vide peut aussi être normale : si executionContainerPolicy=work_order n’est pas utilisé, le travail est suivi sur la ligne, mais cela ne prouve pas qu’une tâche ait été créée, attribuée ou terminée. Si la politique l’exige, « Pas encore créé » signifie seulement que le paquet n’est pas encore matérialisé, et non une erreur d’accès. Dans le portail actuel, le cycle de vie d’un dossier de travail et son paquet ne permettent pas de créer ou d’envoyer un composant de tâche et ne prouvent pas qu’un exécutant a reçu ou terminé le travail. Avant une remise ou une vérification de clôture, contrôlez le résultat réel dans le contexte convenu de la tâche et du responsable ; s’il n’est pas disponible, arrêtez-vous et demandez au responsable du portail, sans contourner cela par un appel API direct.
Remettre une ligne
La remise est possible seulement avec le plan in_progress et pour une quantité non encore remise ou reçue. Ajoutez preuve et méthode : un bien physique utilise shipment, les autres types le chemin service. En cas de résultat partiel, actualisez plan et historique avant de réessayer pour éviter un doublon. Une ligne déjà remise, une révision obsolète et un conflit sont des résultats distincts. Une annulation exige un motif non vide.
Le menu propose Corriger et Retour dès qu’une remise a eu lieu ; les deux demandent une
description et ne concernent qu’une remise à une seule ligne. Le retour exige aussi la révision
actuelle et n’est plus possible après une décision de réception ; la correction est enregistrée
à côté de l’original. Sans ligne ou avec plusieurs lignes, le menu explique la restriction. Les
états ready_for_handoff, received, accepted, returned et exception décrivent le registre
et ne prouvent pas à eux seuls un mouvement de stock.
Si une remise apparaît mais n’est pas confirmée, relisez le registre au lieu de créer une deuxième remise. L’annulation exige un motif et une fiche actualisée ; une ligne déjà remise ne peut pas être annulée.
Une remise créée par erreur peut être retirée uniquement dans les états planned, ready_for_handoff ou exception, tant qu’aucune ligne remise n’est enregistrée. Après la remise, l’action n’est plus proposée. Le retrait exige un motif et la version courante de la fiche ; en cas de succès, l’état devient cancelled. La date du registre est la création, pas la date de remise ; l’état indique si la remise a eu lieu.
Si la version actuelle propose Report a problem (une interface déjà localisée peut afficher Signaler un problème), cette action enregistre un incident sans agir sur la marchandise. Elle peut être disponible pour planned, ready_for_handoff, partially_handed_over et handed_over ; décrivez ce qui s’est passé. La remise est marquée comme problématique, mais aucun retour, aucune réception ni aucun mouvement de stock ne démarre. Si l’état ou la version de la fiche a changé, rechargez le registre et vérifiez à nouveau.
Sur une fiche de réception, le titre de la commande source devient un lien vers /operations/orders/:orderId lorsque la commande est accessible. Si le titre est indisponible ou encore en chargement, le portail affiche un libellé neutre et aucun ID technique.
Vérifier la réception
/operations/acceptance et la fiche de réception affichent commande, quantités acceptées et refusées, statut, avertissement de reprise, dates, documents et historique. Pour ouvrir directement une fiche précise, utilisez /operations/acceptance/:acceptanceCaseId. L’écran peut être en lecture seule ; accepter, reprendre ou refuser exige des droits distincts et une séparation des tâches. Ne promettez pas un bouton absent.
Dans la liste commune, chaque ligne de réception reprend le titre de la commande source ; tant que
ce titre n’est pas chargé, le repli neutre Réception est utilisé. Les états sont affichés comme
draft (brouillon), collecting_evidence (preuves en collecte), ready_for_submission (prêt à
envoyer), submitted (envoyé au client), pending (en attente de décision), under_review (en
examen), partially_accepted (partiellement accepté), accepted, rejected et cancelled
(retiré). En ready_for_submission, le portail affiche Envoyer au client ; l’envoi ouvre
un flux d’approbation séparé et peut demander la confirmation d’un second collaborateur selon
la séparation des tâches.
Ouvrir la réception concerne une ligne de remise précise au statut handed_over, et non
le seul statut de la remise : elle peut aussi apparaître si la remise est en exception, lorsque
la ligne déjà remise doit encore être réceptionnée. L’action n’est pas proposée pour une remise retournée ou annulée.
Sur la fiche de réception, choisissez d’abord Joindre une preuve : depuis draft, le dossier passe à collecting_evidence. Le personnel peut annuler le dossier uniquement depuis draft,
avec un motif non vide et la révision actuelle. Prêt à envoyer apparaît seulement depuis
collecting_evidence et exige une marque de preuve immuable et non vide. En ready_for_submission,
Envoyer au client crée ou réutilise la demande d’approbation ; la référence technique de décision
n’est pas affichée. La décision du client
(decide) suit un chemin séparé de l’autre partie et n’est pas une action du personnel. Accepter,
reprendre ou refuser exige la capacité correspondante et la séparation des tâches.
Si le client a confirmé le résultat hors du portail, n’enregistrez une preuve manuelle qu’à partir d’une confirmation externe réelle : indiquez la personne qui confirme, le fondement, le moment et la quantité acceptée ou refusée. La preuve est d’abord enregistrée, puis appliquée au dossier dans une confirmation distincte. Avec la séparation des tâches, la personne qui a créé le dossier, la remise ou la ligne ne peut pas l’enregistrer, et celle qui l’a enregistrée ne peut pas l’appliquer : ce sont deux étapes suivantes différentes. Le portail ne peut pas transmettre cette preuve à un collègue et, après avoir quitté la page, elle ne peut pas être rouverte avec un code technique. Ne copiez pas ce code, ne contournez pas la règle par une requête directe et coordonnez la seconde personne avant l’enregistrement.
Après une décision accepted ou partially_accepted, la fiche de réception propose une action pour garantir le poste de facturation et un lien vers les postes de facturation (route /operations/billing?view=charges). Aucun montant n’est saisi : le serveur le déduit de la quantité acceptée, des conditions et de la politique figées, du prix unitaire et de la précision autorisée. La répétition est idempotente : la fiche distingue « poste créé » et « poste déjà existant », sans doublon. L’action exige la capacité appropriée et la séparation des fonctions ; déclencheur de facturation désactivé, prix/conditions/précision invalides, état ou source d’acceptation invalide, enregistrement introuvable et conflit de version sont des erreurs distinctes (en cas de conflit, relisez la fiche). Affichez le montant dans la devise de la locale et de l’entité juridique choisies ; utilisez seulement des données synthétiques, sans vraies factures, données bancaires ou clients.
Preuves, argent et confidentialité
Utilisez des données synthétiques. Pour un montant, vérifiez que la devise correspond à la langue et à l’entité juridique choisies. La confirmation doit expliquer l’événement, le responsable et la version de la commande. N’exposez ni contrats, factures, données bancaires, jetons ni données client réelles. Après une erreur, vérifiez l’état et l’historique et ne répétez qu’avec la version actuelle.
Pages associées