Partners

A partner is an organisation you exchange with: a supplier, a manufacturer, a workshop, an authority, a customer. The referential keeps its identity — code, name, type, address, contacts, identification codes (NCAGE, SCAC, SIREN…) — and, from the record, the exchange agreement: which channel you talk through, which messages you exchange, what it must answer and within what delay.

The list

Partners lists the known organisations, filterable by type and by role. The pencil edits a record without leaving the list; the name opens the record.

A partner can only be deleted while nothing cites it: as soon as an order, a flow or a part references it, the action is refused and the record stays. That is deliberate: deleting a supplier that delivered means deleting where a part came from.

Type and roles

The type says what the partner is — Manufacturer, MRO, Squadron, Regulator, Customer, Supplier, Other — chosen from the type referential. It is unique: only one at a time.

The roles say what it is to you: supplier (you buy from it), customer (you sell to it), both, or neither yet. Unlike the type, they combine — a manufacturer that sells you parts and buys back used ones carries both roles at once.

Existing roles were picked up automatically from your purchase and sales documents; from then on, the record keeps them up to date.

The record

Two tabs for every partner; three more for a partner carrying the supplier role. A single record, reachable from Organisation as well as from Procurement — what used to live scattered across the Procurement menu (approvals, derogations, catalog, activity) joins it instead of staying spread across five screens.

Details — what the referential knows about the partner, read-only. Only the fields that are filled in are shown: a half-empty record used to drown the two or three values that matter under a dozen blanks. One line says how many fields are filled and how many are empty, and “Show empty fields” unfolds them all (a dash then marks each blank) — handy right before completing the record. Bank details get their own card: an IBAN does not belong among registration numbers. The “Edit” button opens the same dialog as the list.

Approvals (suppliers only) — read-only: its approvals (reference, validity, covered scope — a part, a category or an ATA chapter —, and a badge that says at a glance whether it is approved, expiring within 60 days, or expired), then, below, its derogations — an off-approval purchase authorised anyway, with its reason, who approved it and until when. “Open the approvals screen” leads to the approvals screen to declare, renew or grant a derogation: nothing is settled from the record.

Catalog (suppliers only) — read-only, what it can sell you: the part, its own reference, the price (always with its currency), the lead time, the minimum order. “Open the supplier catalog” leads to the catalog screen to add or edit a line.

Exchanges — the exchange agreement, in three parts.

The channel and the instructions

How messages travel with this partner: File (their system produces and reads S2000M files) or Supplier portal (they enter their responses in the workspace you open for them, and the portal produces the file on their behalf). One channel per partner for now. Delivery instructions are free text: agreed drop location, contact, file naming — what the operator must know to hand over a package, and that nothing else in the application carries.

Two counters next to it: active lines, and overdue responses — the packages you sent this partner for which it has not yet returned what it owes you.

The portal accounts

Right below the channel, when the supplier portal is enabled on your instance: the list of accounts you have opened for this partner, and the “Invite a person” button. You, the customer, invite — never the supplier itself. Each account is personal, tied to this partner, with a role you choose.

Four roles, with no preselection when inviting: a choice is required.

• Sales administration: view everything, acknowledge an order, announce a shipment, file an invoice.
• Logistics: view everything, announce a shipment.
• Billing: view everything, file an invoice.
• Read-only: view everything, without sending anything.

The invitation sends an email with a personal link, valid for 7 days by default. The account stays “invited” until the person has chosen a password. “Resend the invitation” issues a new link and invalidates the previous one: there is never more than one valid link at a time.

Suspending cuts off access on the person’s next action; you can reactivate the account afterwards.

An invitation never accepted is withdrawn: the link no longer works, and the address becomes free again — handy after picking the wrong supplier or address. An account that has been used is deleted: it is final, it can never sign in again, what it deposited keeps its author in the history, and its address stays attached to it (it cannot be invited again). For a temporary stop, suspend rather than delete.

Like the rest of the partner record, inviting, editing, suspending and deleting an account require the administration key.

If the supplier portal is not enabled on your instance, the section only shows a note: no account can be invited until it is.

Exchanged messages

One line per message and per direction: the order we send, the shipment notice they send back, the codification result we expect from them. Each line is a flow of the exchanges cockpit, seen from this partner’s side; what you configure here shows up there.

The status button follows the cycle: Activate a draft, Suspend an active line, Reactivate a suspended one. Suspending leaves the packages untouched — they stay readable — but pauses the overdue-response alert: you do not chase a supplier you have paused. Nothing is deleted: an exchange history is never erased, it is suspended.

The pencil configures the line: label, status, acknowledgement required, delay, notes. The format and the direction are frozen — you do not “change” a message, you add another one. The code, derived from the partner and the format, can be edited until a package cites it; then it is frozen, and the dialog says which package cites it.

Proposals received through the portal

When the partner goes through the supplier portal, a section lists what their accounts have filed: the package reference (clickable, it opens in the exchanges cockpit), the message and the targeted order, who filed it — the portal account’s name and address —, when, and where your decision stands. A deleted account leaves the trace, with “Account deleted” in place of the name: a package never loses its history.

Nothing is configured here. The decision is taken on the package, in the cockpit, row by row; the supplier is notified by email and reads it in their workspace.

Messages not configured

Below the lines, the list of what the application can read and produce and this partner does not exchange yet. Each entry says its direction and, when relevant, the response it calls for. “Add” creates the line as a draft, to activate once the agreement is ready. Nothing is ever created without that action: a new supplier immediately sees what it could exchange, and exchanges nothing until you decide so.

The response delay can only be set on a message that calls for a response. On the others the field is absent — a delay on a message that expects nothing would be an alert that never clears.

Activity (suppliers only) — three counters (orders in progress, invoices awaiting decision, active derogations) and its five most recent purchase orders: code, sent date, line count, amount, status. Read-only, to see at a glance what is going on with it without leaving its record — the orders themselves are opened and managed in Procurement.

What comes next

The overdue-response alert is read in the exchanges cockpit, with the package concerned.