Le projet en un coup d’œil
L’un expose commandes et shipments par API ; l’autre produit un rapport de fulfillment dont plusieurs lignes doivent être regroupées.
Ciama conserve le statut, la date, le transporteur et le tracking au niveau global, puis les colis et quantités expédiées par SKU.
Les équipes filtrent les expéditions par statut, transporteur, tracking, pays et dates ; les limites propres à chaque source restent explicites.
Une expédition n’est pas seulement un numéro de suivi. Elle rattache une commande à une date de départ, un statut, un transporteur, une méthode, un ou plusieurs colis et des quantités réellement expédiées. Lorsque ces informations viennent de systèmes différents, le plus grand risque n’est pas seulement de manquer une donnée : c’est de forcer des sources hétérogènes dans un récit uniforme qui leur ferait dire plus qu’elles ne savent.
Dawap a construit dans Ciama une couche de fulfillment capable de recevoir deux réalités logistiques. ShippingBO est interrogé par pages de commandes, puis enrichi avec le détail de leurs shipments. Amazon FBA Europe passe par un rapport SP-API asynchrone : le rapport doit être demandé sur une période, attendu, téléchargé, décompressé, lu puis regroupé par commande, expédition et canal de vente. Les deux chemins aboutissent à un même modèle sans effacer leurs différences.
La valeur du projet est concrète pour la logistique et le fulfillment marketplace : rechercher une expédition dans son compte, retrouver sa commande source, vérifier présence ou absence de tracking, lire les quantités par SKU et exposer le résultat par API OMS. Mais cette valeur repose aussi sur une règle de vérité : un champ absent reste absent, une commande non rapprochée reste identifiable par son numéro, et une date fournie par la source n’est pas transformée en promesse de livraison mesurée.
1. Ciama, un cockpit commerce qui doit aussi comprendre la sortie d’entrepôt
Les ventes deviennent des expéditions, parfois partielles et parfois réparties en plusieurs colis
Ciama centralise commandes, catalogue, offres, achats et stocks pour plusieurs univers de vente. Le fulfillment prolonge ce parcours après la commande : il décrit ce qui a effectivement quitté une source logistique, à quel moment, pour quelle référence de commande et avec quelles quantités.
Le vocabulaire varie selon le fournisseur. ShippingBO distingue la commande, ses shipments et les lignes rattachées. Amazon fournit un rapport tabulaire où chaque ligne représente une partie d’une expédition FBA. Un même identifiant d’expédition peut donc apparaître plusieurs fois, avec différents SKU ou quantités, avant d’être consolidé.
Le modèle Ciama devait préserver trois granularités. L’expédition porte le contexte global ; le colis possède son identifiant, son statut et son tracking propres ; la ligne porte le SKU vendeur et la quantité expédiée. Réduire ces données à un seul statut de commande aurait perdu la réalité des expéditions partielles et des colis multiples.
Le compte reste la première frontière. La recherche du back-office et l’API OMS injectent systématiquement l’identifiant du compte connecté. La vue détaillée vérifie à nouveau l’appartenance de l’expédition avant d’afficher ses lignes. La consolidation multi-sources ne doit jamais devenir une consolidation entre clients.
2. Normaliser le contrat, puis respecter chaque mode de collecte
Un pipeline commun après deux lectures fournisseurs volontairement différentes
Le chantier a commencé par un contrat de lecture commun. Pour chaque expédition, le lecteur fournit un identifiant fournisseur, une commande source, une date d’expédition, un statut et, lorsqu’ils existent, la livraison, le transporteur, le tracking, la méthode, le poids, le canal de vente, les lignes, les colis et la charge brute.
La collecte valide ensuite la période, la connexion, ses identifiants et le fournisseur actif. Seuls deux couples sont acceptés : ShippingBO comme fournisseur logistique et Amazon FBA Europe comme entrepôt. Une autre combinaison s’arrête avec une erreur explicite au lieu de produire des objets partiellement interprétés.
Chaque expédition reçue est recherchée par compte, connexion fournisseur et identifiant externe. Si elle n’existe pas, elle est créée ; sinon elle est mise à jour. Les lignes et les colis suivent le même principe avec leur propre identifiant source. Cette logique permet de relire une période sans recréer chaque expédition à chaque passage.
Enfin, treize fichiers de tests ciblés couvrent le contrat : lecteurs ShippingBO et Amazon, service de collecte, créations et mises à jour, requêtes de recherche, recherche back-office, API OMS, commande planifiée et résistance du rapport Amazon aux attentes longues comme aux limitations de quota.
3. Avant le modèle commun : des preuves logistiques difficiles à comparer
Un shipment API et une ligne de rapport FBA ne sont pas encore une expédition exploitable
ShippingBO expose des commandes mises à jour sur une période. Pour retrouver leurs expéditions, il faut demander le détail de chaque commande, parcourir les shipments et reconstruire les lignes expédiées à partir des relations avec les articles. La liste initiale ne suffit donc pas à décrire le colis ou le SKU concerné.
Amazon FBA suit un chemin très différent. La source ne renvoie pas directement une collection d’objets prête à afficher. Elle prépare un rapport, fournit ensuite un document, puis un fichier tabulaire dont les en-têtes peuvent varier selon la langue ou la forme. Plusieurs lignes appartiennent à la même expédition et doivent être additionnées sans perdre le canal de vente.
Sans couche commune, une recherche transverse aurait mélangé identifiant de commande, identifiant d’expédition et identifiant de ligne. Elle aurait également risqué de compter plusieurs fois le même shipment Amazon ou de résumer une expédition ShippingBO à l’état de sa commande quand aucun shipment n’était encore disponible.
Le projet répond à cette tension par une normalisation prudente. Il ne prétend pas que toutes les sources possèdent les mêmes données ; il garantit que les informations disponibles trouvent une place stable et que le lecteur peut reconnaître la source qui les a produites.
4. Transformer deux sources en une base de fulfillment consultable
Identifier, filtrer, relire et exposer sans fabriquer les champs manquants
Le premier objectif était de conserver une identité stable par expédition et par connexion. Un identifiant externe n’est unique que dans le bon contexte fournisseur. L’association du compte, de la connexion et de cet identifiant devient donc la clé opérationnelle utilisée pour décider entre création et mise à jour.
Le deuxième objectif était de garder la structure physique de l’envoi. Une expédition peut contenir plusieurs lignes et plusieurs colis. Chaque ligne porte son identifiant fournisseur, son SKU vendeur et la quantité expédiée ; chaque colis peut porter son propre tracking, transporteur, statut, poids et dates.
Le troisième objectif était de rendre la base exploitable. Une page de recherche devait répondre aux questions courantes : quelle expédition, quelle commande, quel statut, quel transporteur, quelle méthode, quel pays, avec ou sans tracking, et sur quelle période ? Une API devait fournir la même collection aux consommateurs autorisés.
Enfin, la collecte devait accepter la répétition. Les reprises historiques et le passage planifié Amazon recouvrent volontairement des périodes déjà lues. Le pipeline doit donc mettre à jour l’existant au lieu de dupliquer les preuves logistiques à chaque exécution.
5. Un modèle à trois niveaux pour ne pas confondre commande, colis et produit
L’expédition rassemble le contexte ; le colis et la ligne conservent leur identité propre
Au niveau de l’expédition, Ciama stocke les identifiants interne et fournisseur, la référence de commande, le statut, les dates d’expédition et de livraison lorsqu’elles existent, le transporteur, la méthode, le poids, le coût réel éventuel, le tracking principal et la charge brute.
Au niveau du colis, le modèle garde un identifiant lié à l’expédition, puis éventuellement statut, transporteur, code transporteur, numéro et URL de suivi, dates de départ et de livraison, et poids. Cette granularité permet de ne pas réduire un envoi multi-colis à une seule référence de tracking.
Au niveau de la ligne, le SKU vendeur, la quantité expédiée et l’identifiant de ligne fournisseur sont conservés. Un produit Ciama peut être associé lorsque le référentiel permet de le résoudre. La quantité porte sur ce qui est expédié, pas sur la quantité initialement commandée.
Les trois étages répondent à trois enquêtes différentes. Le support part de la commande ou du tracking ; la logistique vérifie le colis ; le catalogue identifie le SKU et la quantité. Le modèle commun évite que chacun reconstruise cette relation à partir d’un export différent.
6. Lire ShippingBO par pages de cent commandes puis ouvrir leurs shipments
La période porte sur les commandes mises à jour, le détail fournit les expéditions
Le lecteur ShippingBO commence par vérifier l’URL de base et l’authentification. Il accepte un flux OAuth avec client, secret et jeton de rafraîchissement, ou un jeton statique lorsque cette configuration est celle de la connexion. L’identifiant d’application reste obligatoire et la version d’API peut être ajoutée aux en-têtes. Cette mise en œuvre concrétise notre savoir-faire d’intégration API ShippingBO.
Les commandes sont demandées par pages de cent, triées par création décroissante et filtrées entre les deux bornes de mise à jour. Une source ShippingBO optionnelle peut réduire le périmètre. Tant qu’une page contient cent lignes, le lecteur poursuit avec l’offset suivant.
Pour chaque commande valide, une seconde requête ouvre le détail et cherche ses shipments. La référence métier privilégie la référence source, puis la référence d’origine, avant de reprendre l’identifiant numérique. La date d’expédition utilise la date du shipment, sa création ou, en dernier repli, la date connue sur la commande.
Le tracking est recherché dans plusieurs champs possibles : référence d’envoi, numéro de tracking, tracking, référence transporteur, code-barres transporteur, SSCC ou URL. Cette série de replis reflète la variété des réponses sans prétendre que chaque expédition possède un numéro normalisé.
7. Conserver une commande ShippingBO même lorsque son shipment manque
Une preuve partielle reste visible, mais elle n’est pas présentée comme un colis complet
Si le détail d’une commande ne contient aucun shipment, le lecteur crée tout de même une expédition de repli. Son identifiant commence par la commande ShippingBO, son statut reprend l’état de la commande et son poids peut provenir du total. Tracking, transporteur, colis et lignes restent absents.
Ce comportement évite de perdre complètement une commande présente dans la fenêtre de collecte. Il matérialise aussi la limite : une ligne visible peut représenter une commande logistique sans shipment détaillé. L’absence de tracking n’est donc pas automatiquement une erreur ; elle peut simplement correspondre à ce stade de la source.
Lorsqu’un shipment existe, ses lignes sont rapprochées des articles de commande. Les relations explicites entre article et shipment sont prioritaires ; le lecteur peut sinon utiliser des lignes directement présentes dans le shipment. Une quantité non positive est ramenée à un pour éviter une ligne physiquement présente mais nulle dans la consolidation.
Le lecteur ShippingBO ne fournit pas aujourd’hui le canal de vente au pipeline commun. Il conserve la référence de commande, mais ne résout donc pas la relation avec la commande Ciama par le mécanisme réservé aux canaux Amazon. Cette frontière est assumée dans la page publique au lieu de promettre une jointure qui n’existe pas.
8. Demander à Amazon FBA un rapport sur la période exacte
Authentification LWA, création du rapport, attente du document et parsing tabulaire
Le lecteur Amazon FBA vérifie client, secret et jeton de rafraîchissement, puis obtient un accès LWA. Il demande le rapport des expéditions gérées par Amazon sur dix identifiants marketplace européens, en convertissant les bornes reçues vers UTC. La période demandée reste donc celle du passage, pas une fenêtre cachée du lecteur.
La création retourne un identifiant de rapport, mais pas immédiatement les données. Le lecteur interroge son état jusqu’à recevoir un document terminé. Un rapport annulé produit une collection vide ; un état fatal ou en échec arrête explicitement le traitement ; une attente trop longue devient elle aussi une erreur identifiable.
Une fois le document prêt, Ciama demande son URL, télécharge le contenu et utilise un parseur capable de décompresser le GZIP annoncé. Les en-têtes sont translittérés, passés en minuscules et normalisés afin de reconnaître plusieurs variantes anglaises ou françaises d’une même colonne.
Cette normalisation porte notamment sur commande Amazon, shipment, ligne d’expédition, SKU, quantité, canal de vente, transporteur, tracking et dates. Une ligne sans commande, shipment ou identifiant de ligne est ignorée plutôt que transformée en expédition impossible à rattacher.
9. Regrouper les lignes Amazon par commande, expédition et canal
Une expédition unique peut agréger plusieurs SKU et plusieurs lignes du rapport
La clé de regroupement combine référence de commande, identifiant d’expédition et canal de vente. Cette troisième composante évite de confondre deux occurrences qui partageraient les premiers identifiants dans des contextes de canal différents. Le résultat porte un statut « shipped », cohérent avec la nature du rapport.
Les lignes sont ensuite indexées par identifiant d’article d’expédition. Si le même identifiant apparaît plusieurs fois, les quantités sont additionnées. La collection finale remet les lignes sous forme de liste et conserve dans la charge brute toutes les lignes source qui ont contribué au groupe.
Le premier colis reprend l’identifiant du shipment, le transporteur, le tracking et les dates trouvées. Lorsque des lignes suivantes apportent un transporteur, un tracking, une date de livraison ou une date d’expédition plus récente, la synthèse est enrichie sans créer artificiellement un second colis.
Le rapport peut fournir des intitulés de date différents, y compris une arrivée estimée selon la colonne. La valeur alimente le champ de livraison du modèle actuel : elle représente la date transmise et interprétée par ce lecteur, pas une confirmation universelle de remise physique au destinataire.
10. Attendre les rapports lents et respecter les quotas Amazon
Une collecte robuste ne traite pas un délai externe comme une absence de fulfillment
Le rapport peut rester en préparation longtemps. La configuration actuelle autorise jusqu’à quatre cent cinquante contrôles espacés de deux secondes, soit une fenêtre théorique de quinze minutes hors temps des appels. Un test reproduit plus de cent cinquante états « en cours » pour vérifier que l’ancienne limite de cinq minutes n’arrête plus prématurément le traitement.
Les appels d’état et de document possèdent aussi une stratégie de nouvelle tentative, jusqu’à quinze essais avec une attente croissante bornée à soixante secondes. Les réponses de limitation temporaire ou d’indisponibilité peuvent ainsi être absorbées sans confondre quota et rapport vide.
La création d’un rapport obéit à une contrainte plus stricte. En cas de limitation Amazon, Ciama peut refaire jusqu’à trois tentatives dédiées, espacées par défaut d’au moins trente minutes, et renouvelle le jeton d’accès avant de recommencer. Des tests vérifient l’attente et l’utilisation du nouveau jeton sur les appels suivants.
Les durcissements du 8 septembre 2026 portent précisément sur cette réalité : période correcte, rapports lents, limitation de l’API, quota de création et rafraîchissement du jeton. La fiabilité du projet ne repose donc pas sur l’hypothèse qu’Amazon répond immédiatement à chaque demande.
11. Créer ou mettre à jour selon l’identité fournisseur
Relire une période complète sans reproduire la même expédition
Le service de collecte recherche chaque expédition par compte, connexion fournisseur et identifiant externe. Cette clé est plus sûre qu’un identifiant seul : deux connexions peuvent employer des espaces d’identifiants différents et un même compte peut agréger plusieurs sources logistiques.
Une expédition nouvelle reçoit un identifiant interne et tous les champs du contrat. Une expédition déjà présente met à jour statut, dates, relation de commande, transporteur, méthode, tracking, poids, coût éventuel et charge brute. Le résultat de collecte compte séparément les ajouts, mises à jour et erreurs.
Les lignes sont ajoutées ou mises à jour selon leur identifiant fournisseur dans l’expédition. Les colis suivent le même principe selon leur identifiant. Une relecture enrichit donc les objets connus et peut ajouter un colis ou une ligne apparus plus tard, sans remplacer l’identité globale.
Le pipeline ne supprime pas automatiquement une ligne ou un colis absent d’une lecture suivante. Il fonctionne comme un upsert, pas comme une réconciliation destructive. Ce choix protège l’historique contre une réponse partielle, mais signifie qu’une disparition à la source n’est pas propagée comme suppression dans ce périmètre.
12. Rapprocher une expédition Amazon de la bonne commande Ciama
Quinze variantes de canal reconnues, puis une recherche par canal et référence
Le rapport Amazon transmet un canal de vente tel qu’Amazon.fr, Amazon.es ou Amazon.co.uk. Ciama le convertit vers l’identifiant de catalogue du canal configuré dans le compte. Quinze variantes sont reconnues, couvrant notamment France, Espagne, Italie, Allemagne, Irlande, Royaume-Uni, Belgique, Pays-Bas, Suède et Pologne.
Lorsque le canal correspondant existe dans le compte, la commande est recherchée par cet identifiant de canal et la référence Amazon. L’expédition conserve alors une relation directe vers la commande, ce qui permet à la liste d’afficher le pays de livraison et d’ouvrir la commande depuis sa référence.
Lorsqu’un canal est absent, inconnu ou non configuré, l’expédition reste stockée avec son `orderIdentifier`, mais sans relation locale. Ce repli préserve la donnée logistique sans créer une association approximative avec une commande portant par hasard le même numéro dans un autre canal.
Si une date de livraison est présente et que toutes les expéditions déjà rattachées à la commande possèdent elles aussi cette date, le statut de commande est passé à « delivered ». Cette automatisation reste bornée au rapprochement Amazon actuel ; elle n’est pas présentée comme une réconciliation universelle de tous les transporteurs.
13. Une recherche opérationnelle centrée sur les vraies questions de fulfillment
Référence, statut, transporteur, méthode, tracking, pays et période dans le même écran
La recherche libre porte sur l’identifiant d’expédition ou la référence de commande. Les listes de statuts, transporteurs et méthodes sont calculées à partir des valeurs réellement présentes dans le compte. L’écran n’impose donc pas un référentiel de statuts artificiel commun à ShippingBO et Amazon.
Un filtre sépare les expéditions avec tracking de celles qui n’en ont pas. Le pays de livraison devient filtrable lorsque la relation avec la commande et son adresse existe. Deux bornes de date limitent enfin le départ des expéditions, de minuit pour le début à 23 h 59 min 59 s pour la fin.
La pagination propose vingt-cinq, cinquante, cent ou deux cents résultats, avec cinquante lignes par défaut. Le tri porte sur la date d’expédition ou la dernière mise à jour, dans les deux sens. En l’absence de choix valide, les expéditions les plus récentes restent prioritaires.
Onze colonnes rapprochent identifiant et date, commande, pays, statut, partenaire, transporteur, méthode, poids, tracking, coût réel éventuel et mise à jour. Une valeur manquante apparaît comme telle ; elle n’est pas remplacée par un texte promettant une disponibilité qui n’existe pas.
14. Ouvrir une expédition et retrouver les quantités par SKU
Le détail conserve la synthèse en tête et descend jusqu’aux lignes expédiées
La vue détaillée reprend statut, identifiants d’expédition et de commande, transporteur, tracking, méthode, poids, date d’expédition et dernière mise à jour. Elle fournit une photographie lisible avant d’ouvrir la table des produits.
Chaque ligne affiche le SKU vendeur, la quantité expédiée et sa dernière mise à jour. Si un produit Ciama a été associé, son identifiant devient un lien vers sa vue PIM. Dans le cas contraire, le SKU reste la preuve disponible sans forcer un rapprochement incertain.
L’accès recharge l’expédition par identifiant, retourne une page introuvable si elle n’existe pas et refuse l’accès si son compte diffère de celui de la personne connectée. Connaître un identifiant ne permet donc pas de traverser la frontière client.
Les colis sont bien persistés avec leurs propres données, mais cette vue actuelle ne les liste pas. Le tracking visible en tête est celui de l’expédition. L’interface reste ainsi plus synthétique que le modèle conservé en arrière-plan.
15. Exposer les expéditions par une API OMS cloisonnée au compte
Une collection paginée pour réutiliser la preuve logistique hors du back-office
L’API `GET /oms/fulfillments` reprend la recherche par identifiant d’expédition ou de commande, le filtre de statut, la pagination et le tri par expédition ou mise à jour. Elle applique un maximum de deux cents lignes par page et injecte toujours le compte de la personne authentifiée.
Chaque item fournit identifiants interne et fournisseur, référence de commande, statut, transporteur, tracking, fournisseur, connexion, date d’expédition et date de mise à jour. La pagination accompagne les items afin qu’un consommateur puisse parcourir la collection sans deviner le nombre de pages.
Cette API ne restitue pas aujourd’hui les lignes et les colis dans la collection de recherche. Elle ne doit donc pas être présentée comme l’export complet de tout le modèle. Son rôle est de rendre la synthèse des fulfillments interrogeable par les outils autorisés.
La documentation OpenAPI décrit les paramètres, les tris possibles et les réponses d’authentification. Un test applicatif vérifie le contrat de recherche. L’API prolonge le cockpit sans introduire un second langage de filtre ou une nouvelle frontière de données.
16. Reprendre l’historique par fenêtres maîtrisées
Un jour par défaut pour ShippingBO, trente jours pour Amazon FBA
Deux commandes interactives permettent de choisir un compte actif, une borne de début, une borne de fin et une taille de fenêtre. Elles refusent le mode non interactif afin qu’une reprise étendue ne soit pas lancée accidentellement comme une tâche silencieuse.
Pour ShippingBO, la fenêtre proposée par défaut est d’un jour. Chaque segment devient une sous-exécution rattachée à une exécution parente, avec volumes collectés, ajoutés, mis à jour et en erreur. Le fournisseur doit être logistique, actif, disponible et relié à une connexion valide dont la fonction de fulfillment est activée.
Pour Amazon FBA, la reprise historique propose trente jours par segment et applique les mêmes contrôles à un fournisseur de type entrepôt. Les ajouts et mises à jour peuvent être distribués de manière asynchrone, chaque fenêtre conservant sa propre trace d’exécution.
Le découpage protège la lisibilité et respecte les caractéristiques des sources. Il ne garantit pas qu’une période immense sera gratuite : ShippingBO ouvre le détail des commandes et Amazon prépare des rapports soumis à quota. La taille reste donc un paramètre explicite de l’opération.
17. Relever Amazon FBA toutes les deux heures avec trois jours de recouvrement
Une cadence réelle et volontairement limitée à la source warehouse active
En production, la collecte planifiée démarre à la minute quarante-cinq toutes les deux heures. Elle examine les connexions dont la fonction warehouse fulfillment, ou son ancienne clé compatible, est active. Seules les connexions Amazon FBA Europe valides et disponibles sont retenues.
Chaque passage demande les trois derniers jours. Ce recouvrement permet de relire une expédition enrichie ou apparue tardivement. La logique d’upsert transforme ce chevauchement en mises à jour plutôt qu’en doublons, tandis que les écritures d’ajout et de modification sont distribuées au transport asynchrone.
L’exécution conserve les bornes, le fournisseur et les compteurs. Zéro fulfillment produit un état « vide », une erreur de validation ou d’appel produit un échec, et une collection reçue termine en succès avec ses volumes. La collecte rejoint ainsi le journal de supervision général de Ciama.
La cadence automatisée de quinze minutes concerne Amazon FBA. ShippingBO reste collectable par sa commande interactive ; son automatisation demande une planification dédiée et sécurisée avant de rejoindre le même rythme d’exploitation.
18. Treize fichiers de tests pour couvrir les frontières du projet
Du rapport fournisseur jusqu’à la recherche et à l’API OMS
Les services d’ajout, de collecte et de mise à jour possèdent chacun un test unitaire et un test d’intégration. Ils vérifient les validations, l’identité fournisseur, les compteurs, les lignes, les colis et la décision entre création et mise à jour avec la couche de données réelle lorsque nécessaire.
Deux tests contrôlent les pullers ShippingBO et Amazon à partir de fixtures. Le premier vérifie notamment le transporteur, le tracking et la charge source ; le second vérifie le canal Amazon, deux lignes et un colis sur une expédition de référence.
Le client de rapport Amazon possède quatre scénarios dédiés : période et GZIP, attente supérieure à l’ancienne limite, répétition après limitation et délai minimum avant une nouvelle création. Un test de commande planifiée complète cette couverture sur la sélection des connexions et la fenêtre courante.
Enfin, le moteur de requête, la recherche back-office et l’API OMS possèdent leurs propres tests. Le total de treize fichiers décrit les points de contrôle du périmètre et sécurise les chemins les plus importants face aux incidents fournisseur.
19. Ce que la consolidation change réellement dans le run
Une expédition retrouvable, des quantités lisibles et une collecte répétable
Le premier gain observable est une identité durable. Une période Amazon relue ou une commande ShippingBO rencontrée à nouveau met à jour la même expédition dans sa connexion. L’équipe peut suivre sa dernière version sans trier manuellement des doublons d’import.
Le deuxième gain est la lecture des quantités effectivement expédiées. Le détail ne s’arrête pas au statut global : il conserve chaque SKU et sa quantité. Une expédition partielle peut ainsi être comprise au niveau produit, là où un simple numéro de tracking resterait ambigu.
Le troisième gain est la recherche commune. Référence de commande, statut, transporteur, méthode, présence de tracking, pays et période sont accessibles dans un écran cloisonné au compte. L’API OMS rend la synthèse réutilisable sans demander un accès direct aux systèmes fournisseurs.
Enfin, le projet rend les limites actionnables. Une expédition sans relation de commande, un colis non visible dans le détail ou un coût non fourni ne sont pas masqués derrière une promesse générale. L’équipe sait quelle donnée existe, quelle source l’a produite et quelle évolution reste à construire.
20. Les frontières actuelles de la couche fulfillment
Pas d’alerte de retard, de timeline transporteur ni de vérité identique pour les deux sources
L’écran ne calcule aucun retard et n’envoie aucune alerte. Il filtre les dates et expose les statuts reçus, mais ne compare pas une promesse client à un événement transporteur attendu. Une telle capacité demanderait des seuils par service, canal, pays et calendrier, qui ne sont pas implémentés ici.
Le modèle stocke un statut courant et des dates, pas une timeline complète des scans transporteur. Il ne conserve pas dans ce périmètre chaque événement intermédiaire de prise en charge, transit, incident ou livraison. Le suivi ne doit donc pas être présenté comme un portail transporteur universel.
ShippingBO ne résout pas encore le lien vers la commande Ciama et n’a pas de tâche planifiée dédiée. Amazon peut résoudre quinze variantes de canal, mais le rapport demandé vise dix identifiants marketplace. Une date interprétée comme livraison peut provenir d’un en-tête d’arrivée estimée selon le fichier source.
Les colis existent en base mais ne sont pas affichés dans la vue détaillée ni exposés par la collection API. Le champ de coût réel est prêt dans le modèle et la table, mais les deux lecteurs actuels ne le renseignent pas. Ces frontières constituent la roadmap réelle, pas des fonctionnalités déjà livrées.
21. Scénario : retrouver ce qui a réellement quitté Amazon FBA
Du rapport multi-lignes à une expédition reliée à sa commande et à ses SKU
Un passage planifié demande les trois derniers jours à Amazon FBA. Le rapport contient plusieurs lignes pour une même commande et un même shipment, sur le canal Amazon.fr. Ciama normalise les en-têtes, groupe les lignes, additionne les quantités par identifiant d’article et conserve toutes les lignes source dans la charge brute.
Le canal Amazon.fr est converti vers le canal marketplace français du compte. Si la commande portant la référence correspondante existe, l’expédition lui est associée. Le pays de livraison devient alors disponible dans la liste, et la référence ouvre directement la commande.
L’opérateur filtre la période, recherche la référence et ouvre l’expédition. Il retrouve le tracking principal, le transporteur, la date de départ et les lignes SKU avec leurs quantités. Si le même rapport est relu au passage suivant, l’identité fournisseur conduit à une mise à jour, pas à une nouvelle expédition.
Si aucune commande locale ne correspond ou si le canal n’est pas configuré, l’expédition n’est pas perdue : sa référence source reste visible. Ce scénario résume la philosophie du projet. Rapprocher lorsque les clés sont fiables, conserver lorsque le rapprochement manque, ne jamais fabriquer une relation pour rendre l’écran artificiellement complet.
22. Relier le fulfillment aux autres preuves du cycle commande-stock
La commande donne le contexte, le stock explique la disponibilité et la supervision suit la collecte
La centralisation des commandes marketplace présente le socle auquel les expéditions Amazon peuvent être rattachées. Le fulfillment prolonge la vente sans remplacer son détail commercial ou financier.
La chaîne de stock ERP et marketplace raconte l’amont de la promesse : collecte d’entrepôt, cible par offre, push et relecture. L’expédition décrit ensuite ce qui a réellement été confié à la logistique.
Le journal des synchronisations Ciama conserve enfin le passage planifié Amazon et les fenêtres historiques avec leurs volumes d’ajout, de mise à jour et d’erreur. Il permet de distinguer absence de données et échec de collecte.
Ensemble, ces briques construisent une lecture continue sans prétendre qu’un seul écran sait tout. La logistique marketplace devient pilotable lorsque commande, stock, expédition et preuve d’exécution partagent des identifiants fiables et des limites clairement nommées.
23. Conclusion : consolider la logistique sans simplifier la vérité
Une couche commune vaut par les correspondances qu’elle prouve et les écarts qu’elle conserve
Ce projet donne à Ciama un objet d’expédition cohérent sans prétendre que ShippingBO et Amazon FBA racontent la même histoire. L’API ShippingBO part de commandes et de shipments ; le rapport Amazon part de lignes qu’il faut regrouper. Le pipeline rapproche ces mondes autour d’une expédition, de ses colis et de ses quantités.
La robustesse vient ensuite de choix précis : identité par connexion, upsert non destructif, fenêtres historiques, recouvrement de trois jours, attente des rapports lents, respect du quota de création, renouvellement du jeton et treize fichiers de tests. La recherche et l’API rendent la preuve exploitable ; elles n’inventent ni tracking, ni coût, ni relation de commande lorsque la source ne les fournit pas.
Pour un vendeur multicanal, cette honnêteté est plus utile qu’un statut vert générique. Elle permet de retrouver ce qui est parti, sur quelle commande, avec quels SKU et depuis quelle source, puis de voir exactement ce qui manque encore. C’est le niveau d’exigence que Dawap applique à ses projets de logistique et fulfillment marketplace : relier les opérations sans rendre leur réalité artificiellement simple.
