Data exchanges

Reference data is never fed by you alone. A manufacturer delivers a catalogue, a codification service returns numbers, a technical authority expects your feedback. Each of them sends you data you did not produce.

The exchange cockpit is where those flows are steered — and above all, where you decide what gets in.

The rule that governs the whole screen

A partner file never overwrites your reference data. It proposes, you decide.

That is not a formality, it is what makes interoperability sustainable. A manufacturer sending the wrong revision, a file extracted at the wrong moment, a designation changed for commercial reasons: without a human decision between the file and the database, each of these damages your reference data without leaving a trace.

The engine therefore refuses to apply a package as long as a single one of its rows awaits your decision.

Three tabs, and alerts that filter

The cockpit has three tabs: Flows (the one that opens), Package log and Coverage. The tab and the flow the log is filtered on are in the page address: a “this flow’s packages” link can be shared, and the back button returns to the flows table.

Below the tabs, alerts only show when there are some — an alert at zero is not an alert:

Clicking an alert filters the table on the flows it counts; a second click shows them all again. With no alert at all, the cockpit says so: flows are up to date.

Why “silent” deserves its own alert

It is the most frequent interface failure, and the least visible: nothing breaks. No error, no alert, no failed file — simply nothing happens any more. You notice it the day you look for data that never arrived, often months later.

A flow is only declared silent if it has an expected cadence. A daily interface silent for three days is a failure; a yearly interface silent for three days is normal. Without a declared cadence there is no silence — only an absence, and the screen does not cry wolf.

Overdue responses: the other alert

Silence says “nothing arrives any more”. An overdue response says something else: this specific package you sent is still waiting for what the partner owes you — the acknowledgement of an order, the result of a codification request.

It only fires when the partner’s exchange line declares a response delay (partner record, Exchanges tab) and the message calls for a response. The count starts when the package is handed over, in calendar days. An “Overdue responses” section lists the packages concerned below the flows — only when there are some —, with the due date and the delay; the package itself repeats it at the top of its page, and the flow’s row says so in its To handle column.

There is nothing for you to clear. The alert disappears by itself as soon as the acknowledgement or the response message is attached to the package. There is no “mark as handled” button: that would invent a response the partner never gave. Suspending the line also suspends its alert — you do not chase a supplier you have paused.

Flows

A flow describes one interface: its direction, its format, the partner involved, and how often you expect it.

Direction is carried by an icon and a word, never by colour alone: inbound and outbound do not have the same consequences, and that distinction must stay legible for everyone.

The normal state does not signal itself. Each row fits in two lines: the flow’s name, then its direction, its format in plain words and, for a received catalogue, the “Profile” menu that governs its reading. Codes (of the flow, the format, the partner) show as tooltips. An active flow carries no badge; a suspended or draft flow says so next to its name. Colour is kept for what calls for action: red for a failure or a delay, amber for a decision to take.

You filter by direction from the Flow column’s funnel, by partner from its own, and by status from the alerts. The Silence column compares the days without a package with the expected cadence (“12 d of 30 d”); without a cadence it stays empty. The To handle column gathers what the flow expects from you: Silent, N differences (which leads to the packages where they are decided) or N late.

The Last package column says what the flow carried last: its reference — which opens the package —, its date, then its status and what it brings (“Compared · 12 new · 3 upd.”, “Produced · 57 lines”). A flow used yesterday is not working for all that if that package failed, or if its reading was refused: “Reading refused” then shows in red, with the reason as a tooltip. “N packages” opens the Package log tab, filtered on this flow; clicking the flow’s name does the same.

The package log

It has its own tab and reads in pages of fifty packages. It returns the two hundred most recent packages — and says so when there are more: to go further back, open it from a flow (“N packages”).

A package is a file dropped on a flow. It goes through four states, and none can be skipped:

1. Received — the file is dropped, nothing has been read.
2. Compared — its content has been compared with your reference data. Nothing is written yet.
3. Decided — you have ruled, row by row or by named group.
4. Applied or rejected.

Volume is broken down, never summarised into a single total: “40 rows” says nothing, “12 creations, 3 updates, 25 unchanged” immediately tells you whether the package brings anything or is a replay.

Uploading a received file

On every inbound flow — in the flows table as well as in the “Exchanges” tab of the partner record — the “Upload” button sends the file you received. The package opens, is read, and its screen opens with its differences.

If the file cannot be read (wrong format, missing column…), the package exists anyway, in the “Received” state, and the reason is written on it: that is where you read what to fix before uploading again.

Review — the screen that matters

This is your real working surface. One line per package entry, each showing:

• the proposed operation: creation, update, unchanged, conflict;
• what the match was made on — the scheme and the value. “What did it match on?” is always the first question when a difference surprises you;
• the field-by-field comparison: current value and proposed value, side by side.

Two display choices:

• conflicts come first, always. Two rows of the same package targeting the same object are not settled as they come;
• unchanged rows are folded away. On a replayed catalogue they are nearly the whole package: that is not information, it is noise.

The four degrees of decision

Overriding a field opens an input pre-filled with the partner’s value: nine times out of ten you start from theirs and adjust it, you do not start from a blank page.

What the screen tells you unasked

The last is the most important of the three. Without it, an arbitration memory would make you miss a manufacturer’s correction: you set their value aside a year ago, they have fixed it since, and you would never know.

What a package never changes on an existing part

The manufacturer, the unit, the part type and serialized tracking are set when the part is created, then they are yours. If the file says otherwise, the field is listed, greyed out — it is never proposed:

• the manufacturer is half of the part’s key;
• the unit expresses every quantity in stock: changing it would make every balance lie;
• the type classifies the part in your system, not the supplier’s;
• serialized tracking carries the traceability of every piece already received.

Changing them remains your decision, on the part’s record.

Reading anomalies

A package that has been read shows what the file did not allow. These are not data differences, they are findings about the quality of the exchange:

• a field the partner refuses to share, or does not know;
• a quantity given as a range, from which no bound was taken;
• a duration in a unit that cannot be converted without an arbitrary rounding;
• an additional identity read but not attached.

None of this is guessed. When a value cannot be taken faithfully it is not proposed at all, and the reason is written down. A field invented on a hunch surfaces three packages later, once it has already been copied everywhere.

Parts you entered by hand

A part created by hand never received your partner’s identifier. The package still finds it, by its part number and manufacturer — the key that designates it unambiguously in your catalogue. The row then arrives as an update, marked “Part no. + manufacturer”: you see the differences and decide as for any other row.

When the package is applied, the partner’s identifier is attached to the part: the next package finds it directly. A rejected row attaches nothing.

When a row is blocked

Two refusals can come up, and both have a clear action:

“Missing field(s)” — the package does not carry enough to create the object. This is common when the partner does not share the designation: our model requires one, so creation stops rather than inventing a name.

“An object with the same key now exists…” — the part was created after the package was read, by hand or by another package. Upload the file again: the row will be matched to that part instead of being created.

In both cases, the rest of the package still applies. One faulty row never takes the others with it.

Identity coverage

It has its own tab, Coverage. The question you ask before opening an interface, not during: “are we ready to exchange with this partner?”

For each scheme, the screen gives the share of your objects that already carry its identifier. “76% of partners carry an NCAGE, no object carries a data module code” reads in one second and says exactly which exchange is workable today.

Why every bar has the same colour

Because nobody can say what a good rate is in the absolute. A 5% NSN rate is disastrous if you have to order through a codification service, and completely irrelevant if you only exchange with a manufacturer working on their own references.

Colouring red below a threshold would invent a doctrine nobody wrote. The screen gives the measurement; you are the one who knows what you are aiming for.

“Dedicated column”

Four schemes — NSN, NCAGE, CSN, ISN — do not live in the generic identities table: they have their own column and their own entry screen. Their coverage is therefore computed where the values actually are.

Without that distinction they would all show 0% — the exact opposite of reality, since they are the best covered. A screen that is wrong in that direction is worse than no screen at all: it would make you give up on a perfectly workable exchange.

“No identity attached”

Not an empty bar, a sentence — because a bar at zero is easy to miss, and it is precisely the most actionable finding on the screen: any exchange relying on this scheme is out of reach today.

The part catalogue as a spreadsheet (Excel or CSV)

A manufacturer’s or supplier’s catalogue still arrives, most of the time, as a spreadsheet. Uploaded on an inbound flow of format “Part catalogue — spreadsheet (CSV or XLSX)”, it follows exactly the path of an S2000M catalogue: comparison, differences, your decision, application. And uploading the same file again changes nothing.

The example file

On the row of a spreadsheet flow, the “Example file” button downloads a workbook to fill in, or to send to your supplier:

• the Catalogue sheet, to fill in: one row per part, below the header;
• the Example sheet: three parts, to see what a correct file looks like — it is never read;
• the Instructions sheet: every column, what it feeds, whether it is required, and the accepted values (units and part types included).

It is generated on demand, with the columns this flow reads: it cannot lag behind the reader. When the flow’s partner has an NCAGE code, the examples already carry it.

The columns read

Each column is recognised by its French or English name, regardless of case and accents. Column order does not matter, and columns you add are ignored.

• Part number — always. It is the key: a later upload finds the part by it.
• Designation, Unit — to create a part. The unit is written as its code, label or symbol.
• Manufacturer CAGE — the manufacturer must exist in your partners with this NCAGE code. Empty means the flow’s partner: a supplier almost never writes its own code in its catalogue. The package report says so, and a code that is written but unknown is never replaced.
• Part type — empty: Spare.
• Description, ATA chapter (two digits), Repairable, Certificate of conformity required (yes / no).
• Serialized — “Yes” sets serial-number tracking, at creation only. “No” proposes nothing: it does not say whether the part is tracked by batch or by quantity.
• Shelf life (months) — a duration makes the part shelf-life managed.
• UN hazard class, Weight (kg) — decimal comma or point.

What the reader does on its own, and what it never guesses

• It finds the header row, even below title rows, and the sheet that carries it. For a CSV, it recognises the encoding and the separator — including the semicolon of a French Excel.
• It guesses nothing. An unknown unit, an unreadable “yes / no”, a formula error (#N/A, #REF!) propose nothing and are reported with the row and column of your file: that is where you, or your supplier, will fix it.
• The same part number from the same manufacturer twice: neither row is proposed, since nothing says which one is right.
• An empty cell never changes a field: the absence of a value is not a value.

Refused files

An old Excel workbook (.xls), a password-protected workbook, an OpenDocument file (.ods) or a PDF are refused, saying what to do: save it as .xlsx or .csv. Limits: 20 MB per file, 50,000 part rows.

A supplier with its own file: the column profile

A supplier who sends their spreadsheet — “P/N”, “Desc.”, “U/I” — does not have to redo it: a column profile tells how to read it, once and for all. On the flow’s line, the “Profile: Standard template” menu offers “Create a profile from a supplier’s file”. A package whose reading was refused offers it too, with “Create a profile from this file”.

The screen starts from a real file you received and reads in three parts, shown together:

1. The supplier’s file — the sheet and the header row are found on their own, even below title rows; its columns are shown with their first values.
2. The columns — for each Envergure field, the column that feeds it, proposed from its name (“P/N” for the part number, “Weight (lb)” for a weight in pounds): you confirm or change it. You say who is authoritative when the file and your data differ — the supplier, you, or to be decided on each package — and you translate the values the reader does not recognise (“KT” → a unit, “R” → repairable).
3. What the file will propose — the first rows as they will arrive, and every anomaly with its row and column, before anything is saved.

A proposal from a name is not a reading: the reader reads “P/N” as the part number only because the saved profile says so.

A profile is versioned, never rewritten. Saving a change creates a new version, and you choose the lines that will read it. A line you leave unticked keeps the version it was reading; the previous version remains the explanation of the packages it read. The “Example file of this profile” button gives the supplier a workbook with their own columns.

A package refused before the profile existed does not need to be deposited again: go back to its screen and read it again.

Receiving an S2000M catalogue: the reception profile

An S2000M catalogue — initial provisioning (pnoipd) or spare parts list (splinf) — arrives on an inbound flow and follows the path of any package. But the standard carries neither your part type nor your units: without a reception profile, a new part cannot be created. A part you already know is updated without them.

On the flow’s line, the “Profile: No profile” menu offers “Create a profile from a received message”. The screen starts from the last message deposited on the line, or another one you choose:

• What the message carries — designation, repairability, shelf life, weight, UN class… with their first values and, for each field, who is authoritative when the message and your data differ. The part number is the part’s identity; the manufacturer, the unit and serialized tracking are set on creation only; the NSN is read, but not taken yet.
• To create a part — the part type set on creation (Spare is proposed), and the message’s units of issue, each translated to one of your units. When a code looks like one of them (“EA” → Each), the screen proposes it with a button: nothing is translated without your click. Guessing a unit would falsify every stock quantity.
• The preview of the first parts and of the reader’s remarks, before anything is saved.

Saving follows the spreadsheet rule: a new version, and you choose the lines that will read it.

The codification result

A codification request leaves as an outbound package (message codReq). The codification bureau’s reply — the codRes message — is dropped on an inbound flow with the format “S2000M — codification result”, like any file received.

• Parts are found by their reference and CAGE code: the key your own request sent. They need no external identity.
• The assigned NSN is proposed as an addition on the review screen: the part’s NSN list, extended with the new one. An NSN the part already carried is never removed.
• What the bureau refuses is stated among the reading anomalies, with its observation — usually the reason. A result that attaches no NSN is refused on drop, saying why.
• Once accepted and applied, the NSN is recorded as if it had been entered on the NSN tab: same audit trail entry, plus the package that brought it.

The manufacturer’s part number change

A manufacturer announces that a part number replaces another, or that it has an alternate, under a change authorization: this is the pncinf message. Dropped on an inbound flow with the “S2000M — part number change” format, it proposes interchangeability rules — the ones on the Interchangeability tab of the part record.

• Direction is kept. “A replaced by B” becomes a one-way rule: B may stand in for A, never the reverse. Two crossed alternates (A for B and B for A) become a single two-way rule.
• When the message contradicts itself, the most restrictive rule wins, and the discrepancy is reported under reading anomalies. A rule that is too broad would accept a part the standard refuses; a rule that is too narrow only sends you looking for one more part.
• The authorization becomes the rule’s approval reference. The manufacturer’s remark, if any, becomes its condition — which the system never evaluates: it is yours to read.
• Parts are found by their part number and CAGE code. A link to a part number missing from your catalogue is reported, never created: the part is imported first, through the manufacturer’s catalogue.
• A rule you had already entered is updated, not duplicated — even entered the other way round, when it is two-way.

This message does not carry the interchangeability code per catalogue item (the former ICY code): that one lives on the employment points of the applicable configuration, and travels in another message.

Disputing a row of a catalogue: observations

A row of a received catalogue looks wrong — a mass, a price, a missing NSN? Rejecting the row on the review screen protects your reference data, but the manufacturer never hears about it. An observation is addressed to them: this is the S2000M obsinf message.

1. On the review screen of a received batch, click Observation on the part’s row. Write the finding and, if you wish, a recommendation. The part is not re-entered: it comes from the row, with its part number and CAGE — even when it has no record on your side yet, which is precisely when one disputes.
2. The observation gets a number (OBS-00001) and stays open. The row now shows that number instead of the button.
3. Produce a batch on the manufacturer’s outbound “observations” flow: it carries their open observations, and only theirs. They become sent, in that batch. A sent observation can no longer be changed: the manufacturer has it, under its number.
4. Their answer comes back through the same message, on an inbound flow: each observation returns under your number, with their decision. Accepted on the review screen, it becomes decided.

The cockpit’s Observations tab gathers everything: the finding, the recommendation and the decision one under the other, the batch the row came from and the one that carried it.

A number you do not know in the answer — an observation the manufacturer opens on their own — is reported under reading anomalies, with its text. It is not created.

The supplier’s shipping notice

Once your order has been sent, the supplier can announce what they are shipping: the shipmentinf message. Dropped on an inbound flow of format “S2000M — shipping notice”, it completes the expected delivery that sending the order opened.

• It never creates a delivery. The buyer commits to one by sending the order. A supplier file must not be able to invent one: the warehouse would wait for parcels nobody ordered. When no expected delivery matches, the notice is refused and says why.
• The quantity kept is the parcels’, not the order’s. The supplier ships what they have: three pieces out of five ordered means three will reach the warehouse. The expected line is corrected accordingly — after your decision.
• The announced date and the shipment reference land on the delivery: you know what to expect, when, and under which shipment number the parcel will show up.
• An announced serialized item is picked up: its serial number is set on the expected line, and is confirmed at the dock.
• Nothing is written before your decision, as with everything that comes in: differences go through the review screen.

What the standard separates, and what you need to know to read it

In the message, a shipment line names an order line and a parcel — with no quantity at all. Quantities and serial numbers live in the parcels’ contents. It is the item on your order line that says which content concerns it, when a parcel groups several.

That is also why a notice can be perfectly valid and bring nothing: if it names a parcel it does not describe, the shipped quantity stays unknown, and the gap is reported rather than guessed.

The last revision stands

A supplier correcting a dispatch adds a revision. The read keeps the last one: preparing a delivery from a version they replaced themselves would make you wait for the wrong parcel.

The supplier’s order response

Once your order has been sent, the supplier can reply: what they confirm, for when, and why they depart from what you asked. Dropped on an inbound flow of format “S2000M — order response”, the response completes the order you sent, and accepting it acknowledges the order — exactly as if you had entered the acknowledgement by hand.

• It is the same message as the order, in the other direction. Issue 8.0 has no “order response” message: the supplier returns an orderinf, just as the receipt confirmation returns a shipmentinf. A file dropped on the wrong flow is refused, and says what it is.
• It creates nothing and increases nothing. A response completes lines that exist, within what was ordered. A line it confirms beyond the ordered quantity is set aside, and the screen tells you why; so is a line you never ordered.
• What it proposes: the supplier’s acknowledgement reference on the order; per line, the promised date when they confirm the whole quantity for one date, or a schedule — several dated tranches — when they split it or confirm only part of it. Eight pieces confirmed out of twelve is one tranche of eight; the four missing ones have no tranche, and that is what you see.
• The supplier’s reason is in front of you, never written. A status advice attached to a line (a code of the standard and free text) shows up in the difference as a “supplier remark”, so you decide knowingly. It is stored nowhere but in the package.
• Accepting is acknowledging. What you accept is applied through the acknowledgement service: the order becomes “acknowledged”, with the same audit trace as a manual entry. A second response correcting the first is proposed the same way: the order stays acknowledged, its dates change.
• The attached response lifts the “late response” alert as soon as it is read, even before your decision: the supplier has replied, which is what the alert was watching.
• Nothing is written before your decision, as with everything that comes in.

How a schedule reads in the file

The standard has no notion of tranche: the supplier repeats the line (an orderEntry with the same rank) as many times as they have dates, each with its quantity. The read groups them by line. A single entry with the whole quantity is a firm date; several entries, or a smaller quantity, are a schedule.

Packages filed from the supplier portal

A supplier who goes through the portal — with no S2000M system — does not send you a file: they enter their order response or shipping notice in their own space, and the portal produces the S2000M file on their behalf. That file is dropped on the partner’s inbound flow whose channel is “portal”, and follows strictly the same path as a received file: read, review area, your decision, application.

• Nothing is written without you. A portal proposal is a “received” package whose rows await your decision, like a file. The supplier sees that their proposal is pending; they do not see your data.
• The file is the proof. It is archived as the package’s original, with its fingerprint: the supplier’s evidence, identical to what their system would have sent.
• One proposal at a time on an order. Until you decide, the supplier cannot send another one; after your decision, a new proposal is a correction.
• A corrected shipping notice is a revision of the same shipment, never an overwrite — as with a file.
• What the supplier cannot do: confirm more than ordered, announce more than remains to deliver, target an order that is not theirs, or file a message you have not opened through the portal on their record.
• The package says who filed it. In the journal and on the package, a “Portal · Julie Marchand” chip names the portal account that entered the proposal. The partner’s record lists them too, with their author, under “Proposals received through the portal”.

Attachments on the shipping notice

From the portal, a supplier can attach files to their shipping notice: a certificate of conformity, an EASA Form 1, or another document.

• They show on the package page, before your decision. Each attachment lists its type, its file name and its size there, and downloads from that same page.
• If you apply the package, they are automatically attached to the delivery: the storekeeper finds them on the reception record, right when entering the certificate reference.
• If you reject the package, they stay attached to the package alone — nothing is carried over to a delivery that never happened.
• An attachment filed by the supplier cannot be detached from the package: it is their proof of filing.

Your decision goes back to the supplier

When you apply or reject a portal package, the supplier who filed it is notified by email, and reads it in their workspace: the state of their proposal — accepted, accepted with changes if you set aside or changed rows, refused — and, for a refusal, the reason you entered. Nothing else is shown to them: not your rows, not your repository, not your internal notes.

• Rejecting a portal package requires a reason. It goes to the supplier: say what does not fit and what you expect instead, without quoting anything from your repository. For a file received from the supplier’s system, the note stays internal and optional.
• A refusal is always notified; it is something to redo. The supplier can, on their account, opt out of acceptance emails.
• An applied package whose rows were all set aside is a refusal for the supplier: you decided row by row, but nothing was taken. The email says so, without a reason if you gave none.
• A package the portal refused at filing time (a file it could not attach) sends no email: the supplier read the reason on screen, right away.

Confirming receipt to the supplier

Once the goods have arrived, you can confirm it to the supplier: it is the same shipmentinf message, the other way round. Issue 8.0 of the standard has no “goods receipt” message — the delivery carries the receipt date (rdt), and that is what confirms.

• It is triggered from the Export / compare workshop: message “Receipt confirmation”, then the delivery; the “Confirm to supplier” button opens the outbound package and produces the file in one action. Only purchase-order deliveries where something has actually arrived are offered.
• The channel is the supplier’s. The product looks for an active outbound flow of format “S2000M — receipt confirmation” naming that supplier; failing that, a flow with no declared partner serves as a generic channel. If none exists — or if several are candidates — the screen says so and does not choose for you.
• It only confirms what has been observed. A delivery nothing has filled is refused: with no received quantity and no date, the message would be a polite lie. The date is the one on the goods-receipt certificate — the one for the arrival you are confirming.
• A partial delivery is confirmed too, and that is the case that matters most: the delivery stays “expected” while a balance is due, and the supplier learns what is missing instead of learning it from a chase-up.
• Every gap leaves with its reason in plain words, attached to the order line: “Line 1 (RA-11450): 2 received out of 5 announced.”, a surplus, or an observed condition — unserviceable, scrap, under repair. The supplier settles their line without guessing.
• The delivery channel stays yours: the file downloads from the package, like everything you send.

Two codes of the standard we leave empty

The hand-over status (hos) and the advice code (sac) exist in the schema, but the standard publishes no usable value for them: the first has only an example value, the second speaks of orders and invoices, never of goods received.

So we do not send them, and state the gap in text, where the standard allows it. An invented code would be refused by your partner — or worse, accepted and misunderstood.

Outbound packages

Receiving and sending are not alike, and the screen does not pretend otherwise.

Receiving is comparing then deciding: a partner proposes, you rule. Sending is writing then checking: there is no difference to settle when you are the one writing.

An outbound package therefore has three steps, and no review screen:

1. Opened — you declared what you wanted to send. The file does not exist yet, and neither does its hash.
2. Produced — the file is written, stored, and its hash computed. It can be read on the package screen, and downloaded from there.
3. Sent — you delivered it to the partner.

Opening and producing are one action, in the Export / compare workshop: you pick the message, its object if it has one, and the flow when several carry it. Marking as sent is done on the package screen.

The messages you can send

The order speaks of an act, the configurations of one aircraft or one applicable configuration; the others speak of parts or rules. That is why only these three ask you to designate something: rebuilding order lines from a selection of parts would produce a well-formed, false document. The screen refuses rather than invent.

An order carries only its live lines — a cancelled line is not ordered, and sending it would have you delivered what you chose not to buy.

Why “produced” and “sent”, not “applied”

Because nothing is applied on your side when a file goes to someone else. Reusing the receiving vocabulary would show a package as “received” while you are the sender — and anyone reading the database months later would be misled.

The delivery channel is not in the product

An operator delivers files through whatever channel their contract imposes: an authority portal, encrypted mail, physical media in an isolated environment. Pretending to cover them all would produce an integration nobody uses.

What the product guarantees is traceability: which file, which hash, when, and by whom. “Mark as sent” records that act; the transport stays yours.

What you do not send

A produced package shows its writing anomalies — what your reference data did not allow to be transmitted faithfully:

• a part with no CAGE code, which the recipient cannot attach to a manufacturer;
• a part tracked by batch, a notion the standard does not distinguish — calling it “not tracked” would be false;
• a value where the standard expects a programme-specific code and you hold something else.

Nothing is invented to fill a gap. When a value cannot be transmitted faithfully it is not sent, and the reason is written down.

What you send when you do not have the value

Three answers are possible, and they do not say the same thing to your partner:

The default is to omit, because it is the only one of the three that asserts nothing — and therefore the only one that cannot be wrong. The other two are declared on the mapping profile, field by field: they are commitments towards one specific partner, not properties of the field.

The file is checked against your partner’s schema

Before being stored, the produced file is checked against the official schema of the standard — the one the issuing body publishes, not our reading of it. If it is rejected, the package is not produced: nothing is stored, nothing is downloadable, and the package stays open so you can fix the offending data and start again.

The errors appear on the package screen, grouped by part: each one names the part at fault, the rejected field and its value, then the schema’s raw error. You therefore know which record to correct, even in a message of several hundred items — the rejected file itself is stored nowhere. An error that concerns no part (the message header, the order itself) is shown as is, attributed to no one.

Why this refusal is a service, not a hindrance: sending an invalid file to a technical authority costs more than sending nothing. It is rejected unread, and it casts doubt on everything you send afterwards.

The schema is yours

It is not hard-wired into the software. You place your partners’ schemas on the server, and each mapping profile names the one that applies. Another edition of the standard, an extension specific to your programme, a standard we had not anticipated: that is a file to drop in, not a change to request.

When no schema has been provided

The package is produced anyway — blocking would stop any new installation from working — but it carries the “not checked” marker, on screen and in the audit trail. A guarantee you believe you have without having it is worse than no guarantee at all.

That is also why the audit trail records, for every file produced, whether it had been checked and against which schema. Months later, that is exactly the question that gets asked.

An empty package is refused

Producing a package with no item is not a success: it would make the recipient work for nothing, and hide that your selection was wrong. The screen refuses and says why.

Acknowledgements

An acknowledgement says what became of a message: received without errors, received with minor errors, or rejected. It is the technical answer the standard provides for (the msgCntrlResponse message), and it travels in both directions.

A message can request an acknowledgement. When a partner does, the package screen tells you — you do not have to open the file to find out.

What an acknowledgement does not say

It speaks of how the file was processed, not of what you kept from its data. An acknowledgement saying “received without errors” about a catalogue does not promise you accepted a single one of its differences: what you decide is said in another message, where the standard provides for one. Conflating the two would make your partner believe you adopted what they proposed.

The partner’s acknowledgement, on a package you sent

The partner sends a file back. You drop it on the package concerned, in the “Partner’s acknowledgement” panel.

• It is attached only if it names this package. An acknowledgement cites the message it answers; if it cites another one, or none, it is refused and says so. Without that check, a file filed under the wrong dispatch would make that one look accepted — and nobody would notice before the follow-up.
• It only concerns a package that was handed over. Mark the package “sent” first: an acknowledgement of a file you have not sent yet makes no sense.
• A rejection reads from the package log, without opening packages one by one: a chip shows next to the status. A refused dispatch is a dispatch to redo, and that is the only question that matters here — which of my dispatches was refused?
• The same file dropped twice changes nothing. A second, different acknowledgement is refused: ask the partner which one stands.

Your acknowledgement, on a package you received

You write this one, and the screen announces what it will say before you click.

• A package not yet read has no acknowledgement: the acknowledgement says what the read produced. Read the package first.
• A read refused for a reason that lies with YOUR reference data — a CAGE code you do not know, an item absent from the catalogue — does not produce a rejection. It is not the partner’s fault, and sending it back as such would send them looking for an error that is not theirs. Fix it, read the package again, then acknowledge.
• The produced file is checked against the schema before being stored, like everything you send.
• The delivery channel stays yours: the acknowledgement downloads from the package, and leaves by whatever route your contract imposes.

A refused read stays on screen

When a package’s read is refused, the reason no longer disappears with the notification: it shows on the package screen, under “Last read refused”. It is what tells you whether to ask the partner for the file again or to fix your reference data — and it is what your acknowledgement will send back.

A truncated or badly closed file is refused as such, with the line where the XML stops being valid. It is not read halfway: a catalogue cut off mid-transfer, compared as if it were complete, would make four hundred missing items look like four hundred deletions.

Reading a package’s file

A package’s file can be read directly on its screen, without downloading it: numbered lines, coloured tags, long lines wrapped to avoid horizontal scrolling.

• An outbound package shows it straight away. It is what you are about to deliver: you check a reference or a quantity at the very place where you decide to send it.
• An inbound package keeps it folded. Your work happens in the review screen; the raw file is there to understand what the partner actually wrote. It is only loaded when you unfold it.

Line numbers are those of the file itself: they are the ones you will quote to a partner to point at a passage.

A large file is only shown in part — its first lines — and the screen says so. The full file is downloaded at the top of the page. For the same reason, the Copy button only appears when the file is shown in full: a partial copy pasted into an email would pass for the complete file.

The file hash

Every package carries the hash of the content that was dropped, and it is re-checked before applying. If the file changed between the moment you decided and the moment you apply, applying is refused: your decisions covered content that is no longer what would be written.