Échanges de données

Un référentiel n’est jamais alimenté par vous seul. Un constructeur livre son catalogue, un service de codification renvoie des numéros, une autorité technique attend vos retours. Chacun vous envoie des données que vous n’avez pas produites.

Le cockpit des échanges est l’endroit où ces flux se pilotent — et surtout, où vous décidez de ce qui entre.

La règle qui gouverne tout l’écran

Un fichier partenaire n’écrase jamais votre référentiel. Il propose, vous disposez.

Ce n’est pas une précaution d’usage, c’est ce qui rend l’interopérabilité tenable. Un constructeur qui se trompe de révision, un fichier extrait au mauvais moment, une désignation modifiée pour des raisons commerciales : sans décision humaine entre le fichier et la base, chacun de ces cas abîme votre référentiel sans laisser de trace.

Le moteur refuse donc d’appliquer un lot tant qu’une seule de ses lignes attend votre décision.

Trois onglets, et des alertes qui filtrent

Le cockpit a trois onglets : Flux (celui qui s’ouvre), Journal des lots et Couverture. L’onglet et le flux sur lequel le journal est filtré sont dans l’adresse de la page : un lien « les lots de ce flux » se partage, et le bouton retour ramène au tableau des flux.

Sous les onglets, les alertes ne s’affichent que s’il y en a — une alerte à zéro n’en est pas une :

Cliquer une alerte filtre le tableau sur les flux qu’elle compte ; un second clic le rend entier. Sans aucune alerte, le cockpit le dit : les flux sont à jour.

Pourquoi « muet » mérite sa propre alerte

C’est la panne d’interface la plus fréquente, et la moins visible : rien ne casse. Aucune erreur, aucune alerte, aucun fichier en échec — il ne se passe simplement plus rien. On s’en aperçoit le jour où l’on cherche une donnée qui n’est jamais arrivée, souvent des mois plus tard.

Un flux n’est déclaré muet que s’il a une cadence attendue. Une interface quotidienne silencieuse depuis trois jours est une panne ; une interface annuelle silencieuse depuis trois jours est normale. Sans cadence déclarée, il n’y a pas de silence — seulement une absence, et l’écran ne crie pas au loup.

Les réponses en retard : l’autre alerte

Le silence dit « plus rien n’arrive ». La réponse en retard dit autre chose : ce lot précis que vous avez émis attend encore ce que le partenaire vous doit — l’accusé de réception d’une commande, le résultat d’une demande de codification.

Elle ne se déclenche que si la ligne d’échange du partenaire déclare un délai de réponse (fiche du partenaire, onglet Échanges) et que le message appelle une réponse. Le décompte part de la remise du lot, en jours calendaires. Une section « Réponses en retard » liste les lots concernés sous les flux — seulement s’il y en a —, avec la date attendue et le retard ; le lot lui-même le rappelle en tête de sa fiche, et la ligne du flux le dit dans sa colonne À traiter.

Vous n’avez rien à lever. L’alerte disparaît d’elle-même dès que l’accusé ou le message de réponse est rattaché au lot. Il n’existe pas de bouton « marquer comme traité » : ce serait inventer une réponse que le partenaire n’a pas donnée. Suspendre la ligne suspend aussi son alerte — on ne relance pas un fournisseur qu’on a mis en pause.

Les flux

Un flux décrit une interface : son sens, son format, le partenaire concerné, et la fréquence à laquelle vous l’attendez.

Le sens est signalé par une icône et un mot, jamais par la couleur seule : entrant et sortant n’ont pas les mêmes conséquences, et cette distinction doit rester lisible pour tout le monde.

L’état normal ne se signale pas. Chaque ligne tient en deux lignes : le nom du flux, puis le sens, le format en clair et, pour un catalogue reçu, le menu « Profil » qui en règle la lecture. Les codes (du flux, du format, du partenaire) apparaissent en infobulle. Un flux actif ne porte aucune pastille ; un flux suspendu ou en brouillon le dit à côté de son nom. La couleur est réservée à ce qui demande d’agir : rouge pour une panne ou un retard, ambre pour une décision à prendre.

On filtre par sens depuis l’entonnoir de la colonne Flux, par partenaire depuis le sien, et par état depuis les alertes. La colonne Silence compare les jours sans lot à la cadence attendue (« 12 j sur 30 j ») ; sans cadence, elle reste vide. La colonne À traiter réunit ce que le flux attend de vous : Muet, N écarts (qui mène aux lots où ils se tranchent) ou N en retard.

La colonne Dernier lot dit ce que le flux a transporté en dernier : sa référence — qui ouvre le lot —, sa date, puis son état et ce qu’il apporte (« Confronté · 12 créa. · 3 maj », « Produit · 57 lignes »). Un flux qui a servi hier ne fonctionne pas pour autant si ce lot a échoué, ou si sa lecture a été refusée : « Lecture refusée » s’affiche alors en rouge, le motif en infobulle. « N lots » ouvre l’onglet Journal, filtré sur ce flux ; cliquer le nom du flux fait de même.

Le journal des lots

Il a son onglet, et se lit par pages de cinquante lots. Il rend les deux cents lots les plus récents — et le dit quand il y en a davantage : pour remonter plus loin, ouvrez-le depuis un flux (« N lots »).

Un lot est un fichier déposé sur un flux. Il traverse quatre états, et aucun ne peut être sauté :

1. Reçu — le fichier est déposé, rien n’a été lu.
2. Confronté — son contenu a été comparé à votre référentiel. Rien n’est encore écrit.
3. Décidé — vous vous êtes prononcé, ligne par ligne ou par groupe.
4. Appliqué ou rejeté.

La volumétrie est détaillée, jamais résumée en un total : « 40 lignes » ne dit rien, « 12 créations, 3 mises à jour, 25 inchangées » vous dit tout de suite si le lot apporte quelque chose ou s’il est un rejeu.

Déposer un fichier reçu

Sur chaque flux entrant — dans le tableau des flux comme dans l’onglet « Échanges » de la fiche du partenaire —, le bouton « Déposer » envoie le fichier que vous avez reçu. Le lot s’ouvre, se lit, et son écran s’affiche avec ses écarts.

Si le fichier ne peut pas être lu (mauvais format, colonne introuvable…), le lot existe quand même, à l’état « Reçu », et le motif y est écrit : c’est là que vous lirez quoi corriger, avant de déposer à nouveau.

La reprise — l’écran qui compte

C’est votre surface de travail réelle. Une ligne par entrée du lot, avec pour chacune :

• l’opération proposée : création, mise à jour, inchangé, conflit ;
• par quoi le rapprochement a été fait — le référentiel et la valeur. « Il a matché sur quoi ? » est toujours la première question quand un écart surprend ;
• la comparaison champ par champ : valeur actuelle, valeur proposée, côte à côte.

Deux partis pris d’affichage :

• les conflits remontent en tête, systématiquement. Deux lignes du même lot qui visent le même objet ne se tranchent pas au fil de l’eau ;
• les lignes inchangées sont repliées. Sur un catalogue rejoué, elles sont la quasi-totalité du lot : ce n’est pas de l’information, c’est du bruit.

Les quatre degrés de décision

Corriger un champ ouvre une saisie pré-remplie avec la valeur du partenaire : neuf fois sur dix, on part de la sienne et on la retouche, on ne repart pas d’une page blanche.

Ce que l’écran vous dit sans que vous le demandiez

La dernière est la plus importante des trois. Sans elle, une mémoire d’arbitrage vous ferait rater une correction du constructeur : vous auriez écarté sa valeur il y a un an, il l’a corrigée depuis, et vous ne le sauriez jamais.

Ce qu’un lot ne change jamais sur un article existant

Le fabricant, l’unité, le type d’article et le suivi à l’exemplaire se posent à la création de l’article, puis vous appartiennent. Si le fichier en dit autre chose, le champ est cité, grisé — il n’est jamais proposé :

• le fabricant est la moitié de la clé de l’article ;
• l’unité exprime chaque quantité en stock : la changer ferait mentir tous les soldes ;
• le type classe l’article chez vous, pas chez le fournisseur ;
• le suivi à l’exemplaire porte la traçabilité de chaque pièce déjà reçue.

Les modifier reste un geste de votre part, sur la fiche de l’article.

Les anomalies de lecture

Un lot lu affiche ce que le fichier n’a pas permis de faire. Ce ne sont pas des écarts de données, ce sont des constats sur la qualité de l’échange :

• un champ que le partenaire refuse de partager, ou qu’il ne connaît pas ;
• une grandeur donnée en fourchette, dont aucune borne n’a été retenue ;
• une durée dans une unité qui ne se convertit pas sans arrondi arbitraire ;
• une identité supplémentaire lue mais non rattachée.

Rien de tout cela n’est deviné. Quand une valeur ne peut pas être reprise fidèlement, elle n’est pas proposée du tout, et la raison est écrite. Un champ inventé au jugé se découvre trois lots plus tard, quand il est déjà recopié partout.

Les articles que vous avez saisis à la main

Un article créé à la main n’a jamais reçu l’identifiant de votre partenaire. Le lot le retrouve quand même, par sa référence et son fabricant — la clé qui le désigne sans ambiguïté dans votre catalogue. La ligne arrive alors comme une mise à jour, avec la mention « Réf. + fabricant » : vous voyez les écarts, vous décidez comme pour toute autre ligne.

À l’application, l’identifiant du partenaire est posé sur l’article : le lot suivant le retrouve directement. Une ligne refusée, elle, ne pose rien.

Quand une ligne est bloquée

Deux refus peuvent se présenter, et tous deux ont une action claire :

« Champ(s) manquant(s) » — le lot ne porte pas de quoi créer l’objet. C’est fréquent quand le partenaire ne partage pas la désignation : notre modèle en exige une, la création s’arrête plutôt que d’inventer un nom.

« Un objet de même clé existe désormais… » — l’article a été créé après la lecture du lot, par une saisie ou un autre lot. Déposez le fichier à nouveau : la ligne sera rapprochée de cet article au lieu d’être créée.

Dans les deux cas, le reste du lot s’applique quand même. Une ligne fautive n’emporte jamais les autres.

La couverture des identités

Elle a son onglet, Couverture. La question qu’on se pose avant d’ouvrir une interface, pas pendant : « est-on prêt à échanger avec ce partenaire ? »

Pour chaque référentiel, l’écran donne la proportion de vos objets qui en portent déjà l’identifiant. « 76 % des partenaires portent un NCAGE, aucun objet ne porte de code de module » se lit en une seconde et dit exactement quel échange est tenable aujourd’hui.

Pourquoi toutes les barres ont la même couleur

Parce que personne ne peut dire ce qu’est un bon taux dans l’absolu. Un taux de NSN de 5 % est catastrophique si vous devez commander auprès d’un service de codification, et sans la moindre importance si vous n’échangez qu’avec un constructeur qui travaille sur ses propres références.

Colorer en rouge sous un seuil inventerait une doctrine que personne n’a écrite. L’écran donne la mesure ; c’est vous qui savez ce que vous visez.

« Colonne dédiée »

Quatre référentiels — NSN, NCAGE, CSN, ISN — ne vivent pas dans la table générique des identités : ils ont leur propre colonne et leur propre écran de saisie. Leur couverture est donc calculée là où les valeurs se trouvent réellement.

Sans cette distinction, ils afficheraient tous 0 % — c’est-à-dire l’inverse exact de la réalité, puisque ce sont les mieux couverts. Un écran qui se trompe dans ce sens-là est pire que pas d’écran du tout : il ferait renoncer à un échange parfaitement faisable.

« Aucune identité posée »

Ce n’est pas une barre vide, c’est une phrase — parce qu’une barre à zéro se manque, et que c’est justement le constat le plus actionnable de l’écran : tout échange qui repose sur ce référentiel est hors de portée aujourd’hui.

Le catalogue article en tableur (Excel ou CSV)

Le catalogue d’un constructeur ou d’un fournisseur arrive encore, le plus souvent, dans un tableur. Déposé sur un flux entrant de format « Catalogue article — tableur (CSV ou XLSX) », il suit exactement le chemin d’un catalogue S2000M : confrontation, écarts, votre décision, application. Et un second dépôt du même fichier ne change rien.

Le fichier exemple

Sur la ligne d’un flux tableur, le bouton « Fichier exemple » télécharge un classeur à remplir, ou à transmettre à votre fournisseur :

• l’onglet Catalogue, à remplir : une ligne par article, sous l’en-tête ;
• l’onglet Exemple : trois articles, pour voir à quoi ressemble un fichier correct — il n’est jamais lu ;
• l’onglet Mode d’emploi : chaque colonne, ce qu’elle alimente, si elle est exigée, et les valeurs admises (unités et types d’article compris).

Il est produit à la demande, avec les colonnes que ce flux lit : il ne peut pas être en retard sur le lecteur. Quand le partenaire du flux a un code NCAGE, les exemples le portent déjà.

Les colonnes lues

Chaque colonne est reconnue sous son nom français ou anglais, sans tenir compte des majuscules ni des accents. L’ordre des colonnes n’a aucune importance, et celles que vous ajoutez sont ignorées.

• Référence — toujours. C’est la clé : un second dépôt retrouve l’article par elle.
• Désignation, Unité — pour créer un article. L’unité s’écrit par son code, son libellé ou son symbole.
• Code CAGE fabricant — le fabricant doit exister dans vos partenaires avec ce code NCAGE. Vide, c’est le partenaire du flux : un fournisseur n’écrit presque jamais son propre code dans son catalogue. Le rapport du lot le dit, et un code écrit mais inconnu n’est jamais remplacé.
• Type d’article — vide : Rechange.
• Description, Chapitre ATA (deux chiffres), Réparable, Certificat de conformité exigé (oui / non).
• Suivi à l’exemplaire — « Oui » pose le suivi par numéro de série, à la création seulement. « Non » ne propose rien : il ne dit pas si l’article est suivi par lot ou en quantité.
• Péremption (mois) — une durée rend l’article « à péremption ».
• Classe ONU, Masse (kg) — virgule ou point décimal.

Ce que le lecteur fait seul, et ce qu’il ne devine jamais

• Il trouve la ligne d’en-tête, même sous des lignes de titre, et l’onglet qui la porte. Pour un CSV, il reconnaît l’encodage et le séparateur — y compris le point-virgule d’un Excel français.
• Il ne devine rien. Une unité inconnue, un « oui / non » illisible, une erreur de formule (#N/A, #REF!) ne proposent rien et sont signalés avec la ligne et la colonne de votre fichier : c’est là que vous, ou votre fournisseur, irez corriger.
• Une même référence du même fabricant présente deux fois : aucune des deux lignes n’est proposée, puisque rien ne dit laquelle est juste.
• Une cellule vide ne modifie jamais un champ : l’absence d’une valeur n’est pas une valeur.

Les fichiers refusés

Un ancien classeur Excel (.xls), un classeur protégé par mot de passe, un fichier OpenDocument (.ods) ou un PDF sont refusés en disant quoi faire : l’enregistrer au format .xlsx ou .csv. Plafonds : 20 Mo par fichier, 50 000 lignes d’articles.

Un fournisseur qui a son propre fichier : le profil de colonnes

Un fournisseur qui envoie son tableau — « P/N », « Desc. », « U/I » — n’a pas à le refaire : un profil de colonnes dit comment le lire, une fois pour toutes. Sur la ligne du flux, le menu « Profil : Modèle standard » propose « Créer un profil depuis un fichier du fournisseur ». Un lot dont la lecture a été refusée le propose aussi, avec « Créer un profil depuis ce fichier ».

L’écran part d’un vrai fichier reçu et se lit en trois temps, visibles ensemble :

1. Le fichier du fournisseur — l’onglet et la ligne d’en-tête sont trouvés seuls, même sous des lignes de titre ; ses colonnes s’affichent avec leurs premières valeurs.
2. Les colonnes — pour chaque champ d’Envergure, la colonne qui l’alimente, proposée d’après son nom (« P/N » pour la référence, « Poids (lb) » pour la masse en livres) : vous la confirmez ou la changez. Vous dites qui fait foi quand le fichier et votre base divergent — le fournisseur, vous, ou à trancher à chaque lot —, et vous traduisez ses valeurs que le lecteur ne reconnaît pas (« KT » → une unité, « R » → réparable).
3. Ce que le fichier proposera — les premières lignes telles qu’elles arriveront, et chaque anomalie avec sa ligne et sa colonne, avant d’enregistrer quoi que ce soit.

Une proposition d’après le nom n’est pas une lecture : le lecteur ne lit « P/N » comme la référence que parce que le profil enregistré le dit.

Un profil se versionne, il ne se réécrit pas. Enregistrer une modification crée une nouvelle version, et vous choisissez les lignes qui la liront. Une ligne que vous ne cochez pas garde la version qu’elle lisait ; l’ancienne version reste l’explication des lots qu’elle a lus. Le bouton « Fichier exemple de ce profil » donne au fournisseur un classeur à ses propres colonnes.

Un lot refusé avant le profil n’est pas à redéposer : revenez sur son écran et lisez-le à nouveau.

Recevoir un catalogue S2000M : le profil de réception

Un catalogue S2000M — l’approvisionnement initial (pnoipd) ou la liste de rechanges (splinf) — arrive sur un flux entrant et suit le chemin de tout lot. Mais la norme ne porte ni votre type d’article ni vos unités : sans profil de réception, un article nouveau ne peut pas être créé. Un article déjà connu, lui, se met à jour sans eux.

Sur la ligne du flux, le menu « Profil : Aucun profil » propose « Créer un profil depuis un message reçu ». L’écran part du dernier message déposé sur la ligne, ou d’un autre que vous choisissez :

• Ce que le message apporte — désignation, réparabilité, péremption, masse, classe ONU… avec leurs premières valeurs et, pour chaque champ, qui fait foi quand le message et votre base divergent. La référence est l’identité de l’article ; le fabricant, l’unité et le suivi à l’exemplaire se posent à la création seulement ; le NSN est lu, mais pas encore repris.
• Pour créer un article — le type d’article posé à la création (Rechange est proposé), et les unités de délivrance du message, chacune traduite vers une de vos unités. Quand un code ressemble à l’une d’elles (« EA » → À l’unité), l’écran le propose par un bouton : rien n’est traduit sans votre clic. Deviner une unité fausserait toutes les quantités en stock.
• L’aperçu des premiers articles et des remarques du lecteur, avant d’enregistrer quoi que ce soit.

L’enregistrement suit la règle du tableur : une nouvelle version, et vous choisissez les lignes qui la liront.

Le résultat de codification

Une demande de codification part en lot sortant (message codReq). La réponse du bureau de codification — le message codRes — se dépose sur un flux entrant de format « S2000M — résultat de codification », comme n’importe quel fichier reçu.

• Les articles sont retrouvés par leur référence et leur code CAGE : c’est la clé que votre propre demande a émise. Ils n’ont pas besoin d’identité externe.
• Le NSN attribué est proposé en ajout, à l’écran de reprise : la liste des NSN de l’article, augmentée du nouveau. Un NSN que l’article portait déjà n’est jamais retiré.
• Ce que le bureau refuse est dit aux anomalies de lecture, avec son observation — le motif, le plus souvent. Un résultat qui ne rattache aucun NSN est refusé au dépôt, en disant pourquoi.
• Une fois accepté et appliqué, le NSN est inscrit comme s’il avait été saisi à l’onglet NSN : même trace au journal d’audit, plus le lot qui l’a apporté.

Le changement de référence du constructeur

Un constructeur annonce qu’une référence en remplace une autre, ou qu’elle a une alternative, sous une autorisation de modification : c’est le message pncinf. Déposé sur un flux entrant de format « S2000M — changement de référence », il propose des règles d’interchangeabilité — celles de l’onglet Interchangeabilité de la fiche article.

• Le sens est respecté. « A remplacée par B » devient une règle à sens unique : B peut tenir la place de A, jamais l’inverse. Deux alternatives croisées (A pour B et B pour A) deviennent une seule règle réciproque.
• Quand le message se contredit, la règle la plus restrictive l’emporte, et l’écart est dit aux anomalies de lecture. Une règle trop large ferait accepter une pièce que la norme refuse ; une règle trop étroite fait seulement chercher une pièce de plus.
• L’autorisation devient la référence d’approbation de la règle. La remarque du constructeur, s’il en donne une, devient sa condition — que la machine n’évalue jamais : c’est à vous de la lire.
• Les articles sont retrouvés par leur référence et leur code CAGE. Un lien vers une référence absente de votre catalogue est dit, jamais créé : l’article s’importe d’abord, par le catalogue du constructeur.
• Une règle que vous aviez déjà saisie est mise à jour, pas doublée — même saisie à l’envers, quand elle est réciproque.

Ce message ne porte pas le code d’interchangeabilité par repère de catalogue (l’ancien code ICY) : celui-là vit sur les points d’emploi de la configuration applicable, et voyage par un autre message.

Contester une ligne d’un catalogue : les observations

Une ligne d’un catalogue reçu vous paraît fausse — une masse, un prix, un NSN absent ? Refuser la ligne à l’écran de reprise protège votre référentiel, mais le constructeur n’en sait rien. Une observation, elle, lui est adressée : c’est le message S2000M obsinf.

1. Sur l’écran de reprise d’un lot reçu, cliquez Observation sur la ligne de l’article. Rédigez le constat et, si vous le souhaitez, une recommandation. L’article n’est pas ressaisi : il vient de la ligne, avec sa référence et son CAGE — même s’il n’a pas encore de fiche chez vous, ce qui est justement le moment où l’on conteste.
2. L’observation prend un numéro (OBS-00001) et reste ouverte. La ligne affiche désormais ce numéro à la place du bouton.
3. Produisez un lot sur le flux sortant « observations » du constructeur : il emporte ses observations ouvertes, et seulement les siennes. Elles passent émises, dans ce lot. Une observation émise ne se modifie plus : le constructeur l’a entre les mains, sous son numéro.
4. Sa réponse arrive par le même message, sur un flux entrant : chaque observation revient sous votre numéro, avec sa décision. Acceptée à l’écran de reprise, elle passe décidée.

L’onglet Observations du cockpit rassemble tout : le constat, la recommandation et la décision l’un sous l’autre, le lot d’où vient la ligne et celui qui l’a emportée.

Un numéro que vous ne connaissez pas dans la réponse — une observation que le constructeur ouvre de lui-même — est dit aux anomalies de lecture, avec son texte. Il n’est pas créé.

L’avis d’expédition du fournisseur

Une fois votre commande envoyée, le fournisseur peut annoncer ce qu’il expédie : le message shipmentinf. Déposé sur un flux entrant de format « S2000M — avis d’expédition », il complète l’arrivage attendu que l’envoi de la commande a ouvert.

• Il ne crée jamais d’arrivage. C’est l’acheteur qui en engage un, en envoyant la commande. Un fichier fournisseur ne doit pas pouvoir en inventer : le magasin attendrait des colis que personne n’a commandés. Quand aucun arrivage attendu ne correspond, l’avis est refusé en disant pourquoi.
• La quantité retenue est celle des colis, pas celle de la commande. Le fournisseur expédie ce qu’il a : trois pièces sur cinq commandées, c’est trois que le magasin va recevoir. La ligne attendue est corrigée en conséquence — après votre décision.
• La date annoncée et la référence d’expédition remontent sur l’arrivage : vous savez quoi attendre, pour quand, et sous quel numéro d’envoi le colis se présentera.
• Un exemplaire sérialisé annoncé est repris : son numéro de série est posé sur la ligne attendue, et se confirme au quai.
• Rien n’est écrit avant votre décision, comme pour tout ce qui entre : les écarts passent par l’écran de reprise.

Ce que la norme sépare, et qu’il faut savoir pour la lire

Dans le message, une ligne d’expédition nomme une ligne de commande et un colis — sans aucune quantité. Les quantités et les numéros de série vivent dans le contenu des colis. C’est l’article de votre ligne de commande qui dit lequel des contenus la concerne, lorsqu’un colis en groupe plusieurs.

C’est aussi pourquoi un avis peut être parfaitement valide et ne rien apporter : s’il désigne un colis qu’il ne décrit pas, la quantité expédiée reste inconnue, et l’écart est signalé plutôt que deviné.

La dernière révision fait foi

Un fournisseur qui corrige son envoi ajoute une révision. La lecture retient la dernière : préparer un arrivage d’après une version qu’il a lui-même remplacée ferait attendre le mauvais colis.

La réponse de commande du fournisseur

Une fois votre commande envoyée, le fournisseur peut vous répondre : ce qu’il confirme, pour quand, et pourquoi il s’écarte de ce que vous avez demandé. Déposée sur un flux entrant de format « S2000M — réponse de commande », la réponse complète la commande que vous avez envoyée, et l’accepter l’accuse — exactement comme si vous aviez saisi l’accusé de réception à la main.

• C’est le même message que la commande, dans l’autre sens. La norme 8.0 n’a pas de message « réponse de commande » : le fournisseur renvoie un orderinf, comme la confirmation de réception renvoie un shipmentinf. Un fichier déposé sur le mauvais flux est refusé en disant ce qu’il est.
• Elle ne crée rien et n’augmente rien. Une réponse complète des lignes qui existent, dans la limite de ce qui est commandé. Une ligne qu’elle confirme au-delà du commandé est écartée, et l’écran vous dit pourquoi ; une ligne que vous n’avez pas commandée aussi.
• Ce qu’elle propose : la référence d’accusé du fournisseur sur la commande ; par ligne, la date promise quand il confirme toute la quantité à une date, ou un échéancier — plusieurs tranches datées — quand il fractionne ou ne confirme qu’une partie. Huit pièces confirmées sur douze, c’est une tranche de huit ; les quatre qui manquent n’ont pas de tranche, et c’est ce que vous voyez.
• Le motif du fournisseur est sous vos yeux, jamais écrit. Un avis d’état rattaché à une ligne (code de la norme et texte libre) s’affiche dans l’écart comme « remarque du fournisseur », pour décider en connaissance. Il n’est mémorisé nulle part ailleurs que dans le lot.
• Accepter, c’est accuser. Ce qui est accepté s’applique par le service d’accusé de réception : la commande passe « accusée », avec la même trace d’audit qu’une saisie manuelle. Une seconde réponse qui corrige la première est proposée de la même façon : la commande reste accusée, ses dates changent.
• La réponse rattachée lève l’alerte « réponse en retard » dès sa lecture, avant même votre décision : le fournisseur a répondu, c’est ce que l’alerte surveillait.
• Rien n’est écrit avant votre décision, comme pour tout ce qui entre.

Comment un échéancier se lit dans le fichier

La norme ne prévoit pas de tranche : le fournisseur répète la ligne (orderEntry de même rang) autant de fois qu’il a de dates, chacune avec sa quantité. La lecture les regroupe par ligne. Une seule entrée avec toute la quantité vaut une date ferme ; plusieurs entrées, ou une quantité inférieure, valent un échéancier.

Les lots déposés depuis le portail fournisseur

Un fournisseur qui passe par le portail — sans système S2000M — ne vous envoie pas de fichier : il saisit sa réponse de commande ou son avis d’expédition sur son espace, et le portail produit le fichier S2000M à sa place. Ce fichier est déposé sur le flux entrant du partenaire dont le canal est « portail », et suit strictement le même chemin qu’un fichier reçu : lecture, zone de reprise, votre décision, application.

• Rien n’est écrit sans vous. Une proposition du portail est un lot « reçu » dont les lignes attendent votre décision, comme un fichier. Le fournisseur voit que sa proposition attend ; il ne voit pas vos données.
• Le fichier fait foi. Il est archivé comme l’original du lot, avec son empreinte : c’est la preuve du fournisseur, identique à ce que son système aurait envoyé.
• Une seule proposition à la fois sur une commande. Tant que vous n’avez pas décidé, le fournisseur ne peut pas en envoyer une autre ; après votre décision, une nouvelle proposition est une correction.
• Un avis d’expédition corrigé est une révision du même envoi, jamais un écrasement — comme pour un fichier.
• Ce que le fournisseur ne peut pas faire : confirmer plus que commandé, annoncer plus qu’il ne reste à livrer, viser une commande qui n’est pas la sienne, déposer sur un message que vous n’avez pas ouvert par le portail sur sa fiche.
• Le lot dit qui l’a déposé. Dans le journal et sur le lot, une pastille « Portail · Julie Marchand » nomme le compte du portail qui a saisi la proposition. La fiche du partenaire les liste aussi, avec leur auteur, dans « Propositions reçues par le portail ».

Les pièces jointes à l’avis d’expédition

Depuis le portail, un fournisseur peut joindre des pièces à son avis d’expédition : un certificat de conformité, un EASA Form 1, ou un autre document.

• Elles se voient sur la page du lot, avant votre décision. Chaque pièce y affiche son type, son nom et sa taille, et se télécharge depuis là.
• Si vous appliquez le lot, elles sont automatiquement rattachées à l’arrivage : le magasinier les retrouve sur la fiche de réception, et au moment de saisir la référence du certificat.
• Si vous rejetez le lot, elles restent rattachées au lot seul — rien n’est transmis à un arrivage qui n’a pas eu lieu.
• Une pièce déposée par le fournisseur ne peut pas être détachée du lot : c’est sa preuve de dépôt.

Votre décision revient au fournisseur

Quand vous appliquez ou rejetez un lot du portail, le fournisseur qui l’a déposé en est prévenu par courriel, et le lit sur son espace : l’état de sa proposition — acceptée, acceptée avec modifications si vous avez écarté ou modifié des lignes, refusée — et, pour un refus, le motif que vous avez saisi. Rien d’autre ne lui est montré : ni vos lignes, ni votre référentiel, ni vos notes internes.

• Rejeter un lot du portail demande un motif. Il part au fournisseur : dites ce qui ne convient pas et ce que vous attendez à la place, sans rien citer de votre référentiel. Pour un fichier reçu du système du fournisseur, la note reste interne et facultative.
• Un refus est toujours notifié ; c’est quelque chose à refaire. Le fournisseur peut, sur son compte, choisir de ne pas recevoir les courriels d’acceptation.
• Un lot appliqué dont toutes les lignes ont été écartées est un refus pour le fournisseur : vous avez décidé ligne à ligne, mais rien n’a été pris. Le courriel le dit ainsi, sans motif si vous n’en avez pas donné.
• Un lot que le portail a refusé au dépôt (fichier qu’il n’a pas pu rattacher) n’envoie pas de courriel : le fournisseur a lu le motif à l’écran, à l’instant.

La confirmation de réception au fournisseur

Quand la marchandise est arrivée, vous pouvez le confirmer au fournisseur : c’est le même message shipmentinf, dans l’autre sens. La norme 8.0 n’a pas de message « réception de marchandises » — c’est la livraison qui porte la date de réception (rdt), et c’est elle qui confirme.

• Elle se déclenche depuis l’atelier Exporter / comparer : message « Confirmation de réception », puis l’arrivage ; le bouton « Confirmer au fournisseur » ouvre le lot sortant et produit le fichier en une action. Seuls les arrivages de commande dont quelque chose est effectivement arrivé sont proposés.
• Le canal est celui du fournisseur. Le produit cherche un flux sortant actif au format « S2000M — confirmation de réception » qui nomme ce fournisseur ; à défaut, un flux sans partenaire déclaré sert de canal générique. Si aucun n’existe — ou si plusieurs sont candidats — l’écran le dit et ne choisit pas à votre place.
• Elle ne confirme que ce qui est constaté. Un arrivage que rien n’est venu remplir est refusé : sans quantité reçue ni date, le message serait un mensonge poli. La date est celle du certificat de service fait — celui de l’arrivage que vous confirmez.
• Une livraison partielle se confirme aussi, et c’est le cas qui compte le plus : l’arrivage reste « attendu » tant qu’un reliquat est dû, et le fournisseur apprend ce qui manque au lieu de l’apprendre par une relance.
• Chaque écart part avec son motif en clair, rattaché à la ligne de commande : « Ligne 1 (RA-11450) : 2 reçu(s) sur 5 annoncé(s). », un surplus, ou un état constaté — inutilisable, rebut, en cours de réparation. Le fournisseur solde sa ligne sans rien deviner.
• Le canal de remise reste le vôtre : le fichier se télécharge depuis le lot, comme tout ce que vous émettez.

Deux codes de la norme que nous laissons vides

Le statut de remise (hos) et le code d’avis (sac) existent dans le schéma, mais la norme ne publie pour eux aucune valeur exploitable : le premier n’a qu’une valeur d’exemple, le second ne parle que de commandes et de factures, jamais de marchandise reçue.

Nous ne les émettons donc pas, et disons l’écart en texte, là où la norme le permet. Un code inventé serait refusé par votre partenaire — ou pire, accepté et compris de travers.

Les lots sortants

Recevoir et émettre ne se ressemblent pas, et l’écran ne fait pas semblant du contraire.

Recevoir, c’est confronter puis décider : un partenaire propose, vous tranchez. Émettre, c’est écrire puis vérifier : il n’y a pas d’écart à trancher quand c’est vous qui écrivez.

Un lot sortant suit donc trois étapes, sans écran de reprise :

1. Ouvert — vous avez déclaré ce que vous vouliez envoyer. Le fichier n’existe pas encore, et l’empreinte non plus.
2. Produit — le fichier est écrit, déposé, et son empreinte calculée. Il se lit sur l’écran du lot, et s’y télécharge.
3. Émis — vous l’avez remis au partenaire.

Ouvrir et produire se font en un geste, dans l’atelier Exporter / comparer : on y choisit le message, l’objet s’il en a un, et le flux quand plusieurs le portent. Marquer émis se fait sur l’écran du lot.

Les messages que vous pouvez émettre

La commande parle d’un acte, les configurations d’un aéronef ou d’une configuration applicable ; les autres parlent d’articles ou de règles. C’est pourquoi ces trois-là seulement demandent de désigner quelque chose : reconstituer des lignes de commande à partir d’une sélection d’articles produirait un document bien formé et faux. L’écran refuse plutôt que d’inventer.

Une commande émet ses lignes vivantes seulement — une ligne annulée n’est pas commandée, et l’envoyer ferait livrer ce qu’on a renoncé à acheter.

Pourquoi « produit » et « émis », et pas « appliqué »

Parce que rien n’est appliqué chez vous quand un fichier part chez l’autre. Réutiliser le vocabulaire de la réception donnerait un lot affichant « reçu » alors que vous êtes l’émetteur — et quiconque relit la base des mois plus tard serait trompé.

Le canal de remise n’est pas dans le produit

Un exploitant remet ses fichiers par le canal que son marché impose : portail d’autorité, messagerie chiffrée, support physique en environnement isolé. Prétendre les couvrir tous produirait une intégration qui ne servirait à personne.

Ce que le produit garantit, c’est la traçabilité : quel fichier, quelle empreinte, quand, et par qui. « Marquer émis » enregistre cet acte ; le transport reste le vôtre.

Ce que vous n’émettez pas

Un lot produit affiche ses anomalies d’écriture — ce que votre référentiel n’a pas permis de transmettre fidèlement :

• un article sans code CAGE, que le destinataire ne pourra pas rattacher à un industriel ;
• un article suivi par lot, notion que la norme ne distingue pas — l’annoncer « non suivi » serait faux ;
• une valeur dont la norme attend un code propre au programme, là où vous avez autre chose.

Rien n’est inventé pour combler un trou. Quand une valeur ne peut pas être transmise fidèlement, elle n’est pas émise, et la raison est écrite.

Ce que vous émettez quand vous n’avez pas la valeur

Trois réponses sont possibles, et elles ne disent pas la même chose à votre partenaire :

Le défaut est d’omettre, parce que c’est la seule des trois qui n’affirme rien — donc la seule qui ne peut pas dire faux. Les deux autres se déclarent au profil de correspondance, champ par champ : ce sont des engagements vis-à-vis d’un partenaire précis, pas des propriétés du champ.

Le fichier est vérifié contre le schéma du partenaire

Avant d’être déposé, le fichier produit est confronté au schéma officiel de la norme — celui que publie l’organisme, pas notre lecture de celui-ci. S’il est refusé, le lot n’est pas produit : rien n’est déposé, rien n’est téléchargeable, et le lot reste ouvert pour que vous corrigiez la donnée fautive et recommenciez.

Les fautes s’affichent sur l’écran du lot, rangées par article : chacune nomme la référence en cause, le champ refusé et sa valeur, puis la faute brute du schéma. Vous savez donc quelle fiche corriger, même dans un message de plusieurs centaines d’objets — le fichier refusé, lui, n’est déposé nulle part. Une faute qui ne concerne aucun article (l’en-tête du message, la commande elle-même) s’affiche telle quelle, sans être attribuée à personne.

Pourquoi ce refus est un service, et non une gêne : envoyer un fichier invalide à une autorité technique coûte plus cher que de ne rien envoyer. Il est rejeté sans être lu, et il met en doute tout ce que vous enverrez ensuite.

Le schéma est le vôtre

Il n’est pas figé dans le logiciel. Vous déposez les schémas de vos partenaires sur le serveur, et chaque profil de correspondance nomme celui qui s’applique. Une autre édition de la norme, une extension propre à votre programme, une norme que nous n’avions pas prévue : c’est un fichier à déposer, pas une évolution à demander.

Quand aucun schéma n’est déposé

Le lot est produit quand même — bloquer empêcherait toute installation neuve de travailler — mais il porte la mention « non vérifié », à l’écran comme dans la piste d’audit. Une garantie qu’on croit avoir sans l’avoir est pire que pas de garantie du tout.

C’est aussi pour cela que la piste d’audit enregistre, pour chaque fichier produit, s’il avait été vérifié et contre quel schéma. Des mois plus tard, c’est exactement la question qu’on se posera.

Un lot vide est refusé

Produire un lot sans objet n’est pas une réussite : ça ferait travailler le destinataire pour rien, et masquerait que votre sélection était mauvaise. L’écran refuse et dit pourquoi.

Les accusés de réception

Un accusé de réception dit ce qu’un message est devenu : reçu sans erreur, reçu avec des erreurs mineures, ou rejeté. C’est la réponse technique que la norme prévoit (message msgCntrlResponse), et elle voyage dans les deux sens.

Un message peut demander un accusé. Quand un partenaire le fait, l’écran du lot vous le dit — vous n’avez pas à ouvrir le fichier pour le savoir.

Ce qu’un accusé ne dit pas

Il parle du traitement du fichier, pas de ce que vous avez retenu de ses données. Un accusé « reçu sans erreur » sur un catalogue ne promet pas que vous en avez accepté un seul écart : ce que vous décidez se dit dans un autre message, quand la norme en prévoit un. Confondre les deux ferait croire à votre partenaire que vous avez adopté ce qu’il propose.

L’accusé du partenaire, sur un lot que vous avez émis

Le partenaire vous renvoie un fichier. Vous le déposez sur le lot concerné, dans le panneau « Accusé du partenaire ».

• Il n’est rattaché que s’il désigne ce lot. Un accusé cite le message auquel il répond ; s’il en cite un autre, ou aucun, il est refusé en le disant. Sans ce contrôle, un fichier rangé sous le mauvais envoi ferait croire celui-ci accepté — et personne ne s’en apercevrait avant la relance.
• Il ne concerne qu’un lot remis. Marquez le lot « émis » d’abord : un accusé sur un fichier que vous n’avez pas encore envoyé n’a pas de sens.
• Un rejet se lit depuis le journal des lots, sans ouvrir les lots un par un : une pastille s’affiche à côté de l’état. Un envoi refusé est un envoi à refaire, et c’est la seule question qui compte ici — lequel de mes envois a été refusé ?
• Le même fichier redéposé ne change rien. Un second accusé, différent, est refusé : demandez au partenaire lequel fait foi.

Votre accusé, sur un lot que vous avez reçu

C’est vous qui l’écrivez, et l’écran annonce ce qu’il dira avant que vous cliquiez.

• Un lot pas encore lu n’a pas d’accusé : l’accusé dit ce que la lecture a donné. Lisez le lot d’abord.
• Une lecture refusée pour une raison qui tient à VOTRE référentiel — un code CAGE que vous ne connaissez pas, un article absent du catalogue — ne produit pas de rejet. Ce n’est pas la faute du partenaire, et le lui renvoyer comme telle l’enverrait chercher une erreur qui n’est pas chez lui. Corrigez, relisez le lot, puis accusez réception.
• Le fichier produit est vérifié contre le schéma avant d’être déposé, comme tout ce que vous émettez.
• Le canal de remise reste le vôtre : l’accusé se télécharge depuis le lot, et part par où votre marché l’impose.

Le refus de lecture reste affiché

Quand la lecture d’un lot est refusée, le motif ne disparaît plus avec la notification : il s’affiche sur l’écran du lot, sous « Dernière lecture refusée ». C’est lui qui dit s’il faut redemander le fichier au partenaire ou corriger votre référentiel — et c’est lui que votre accusé renverra.

Un fichier tronqué ou mal fermé est refusé comme tel, avec la ligne où le XML cesse d’être valide. Il n’est pas lu à moitié : un catalogue coupé en plein transfert, confronté comme s’il était complet, ferait passer quatre cents articles manquants pour quatre cents suppressions.

Lire le fichier d’un lot

Le fichier d’un lot se lit directement sur son écran, sans le télécharger : lignes numérotées, balises en couleur, lignes longues repliées pour éviter le défilement horizontal.

• Un lot sortant l’affiche d’emblée. C’est ce que vous allez remettre : vous relisez une référence ou une quantité à l’endroit même où vous décidez de l’émettre.
• Un lot entrant le garde replié. Votre travail se fait dans l’écran de reprise ; le fichier brut sert à comprendre ce que le partenaire a réellement écrit. Il n’est chargé que si vous le dépliez.

Les numéros de ligne sont ceux du fichier lui-même : ce sont eux que vous citerez à un partenaire pour désigner un passage.

Un gros fichier n’est montré qu’en partie — ses premières lignes — et l’écran le dit. Le fichier complet se télécharge en haut de page. Pour la même raison, le bouton Copier n’apparaît que lorsque le fichier est affiché en entier : une copie partielle, collée dans un courriel, passerait pour le fichier complet.

L’empreinte du fichier

Chaque lot porte l’empreinte du contenu déposé, et elle est revérifiée avant l’application. Si le fichier a changé entre le moment où vous avez décidé et celui où vous appliquez, l’application est refusée : vos décisions portaient sur un contenu qui n’est plus celui qu’on écrirait.