In forceDecided on 11 October 2026 · Ref. RF-079
Free-delivery threshold has a single source
- What the tool does
- A supplier's free-delivery threshold (amount, basis, currency) is entered in one place only, the transport screen. The supplier record shows it read-only, with the date and author of the value in force and a link to the entry screen. With no threshold entered, the record shows “not provided”, never 0.
- Why
- One piece of data, one source: two entries of the same value always end up contradicting each other, and nobody knows which to trust.
- Where to see it
- Supplier record
- Transport over a period
In forceDecided on 11 October 2026 · Ref. RF-082
Contract deadline alerts, based on the notice period
- What the tool does
- A contract deadline alert is based on the notice deadline (end date minus the termination notice), not on the end date: a task for the supplier's buyer 90, 60 and 30 days before that date; for a certification, 60 days before it expires. With no notice period entered, the alert is based on the end date and says the notice period is missing, never assuming a zero notice. A ticked alert does not come back, and replaying creates no duplicate. Horizons are set per type of deadline.
- Why
- A tacit renewal is decided at the notice date: an alert based on the contract end arrives too late to terminate or renegotiate.
In forceDecided on 12 October 2026 · Ref. RF-093
Transport terms on the supplier record
- What the tool does
- The transport terms of the record are chosen from closed lists (customs and insurance, terms below the free-delivery threshold, delivery days, packaging, handling below the minimum order). The record proposes a value based on the Incoterm (duties paid by the seller only under DDP; insurance paid by the seller under CIF and CIP), but this proposal is never saved until the buyer enters it; a declared value that contradicts it is flagged, never corrected. An ambiguous separator (“1.500”) is rejected.
- Why
- A free-text field cannot be compared or checked. Proposing from the Incoterm avoids inconsistent entries without deciding for the buyer, who may have negotiated something else.
In forceDecided on 11 October 2026 · Ref. RF-050
Transport period used
- What the tool does
- When several transport periods exist for an item, the one covering the reference date applies (a period with no site covers all sites); failing that, the most recent one ending before that date, and the result says so.
- Why
- An average or the latest period would mix costs that do not concern the order being looked at.
In forceDecided on 11 October 2026 · Ref. RF-051
Transport allocation basis
- What the tool does
- No default basis: the transport share is calculated on the basis the supply planner declared when entering the period (weight or value today; volume and per-order remain uncalculated for lack of data, with their reason).
- Why
- Choosing a basis on behalf of purchasing would change the cost price without anyone having decided it.
In forceDecided on 11 October 2026 · Ref. RF-053
Period quantities and items sharing the transport cost
- What the tool does
- The ERP only provides 12-month quantities: an item's quantity over a period is estimated pro rata to the days, an assumption written on every result. The cost is shared among all items bought from the supplier for the period's sites. If even one of these items lacks the required data (weight, or price and volume), no share is calculated, with the reason; never an estimate. Landed costs already declared are not added to the transport share: an alert flags the double count.
- Why
- Without quantities per period, the only defensible allocation assumes regular purchases; stating it prevents it from being taken for a measurement.
In forceDecided on 11 October 2026 · Ref. RF-054
Several transport periods on the same date
- What the tool does
- When several periods cover the same date for the same supplier and site (different lanes or modes), their costs add up, each calculated on its own days and sites. They must share the same basis and currency; otherwise no share is calculated, with the reason.
- Why
- An item is not attached to a lane in the tool; adding costs of the same kind gives the full cost without inventing an allocation.
In forceDecided on 11 October 2026 · Ref. RF-077
Origin and provenance, two separate data
- What the tool does
- Origin is the country of manufacture: it sets customs duties. By default it is the country of origin read in the price list; a buyer's entry takes precedence, with a reason, and any disagreement with the price list is shown. Provenance is the country of dispatch: it is used for transport. It comes from the supply planner's or buyer's entry, otherwise from the price list's provenance column; otherwise it stays empty with its reason, and is never inferred from the origin. The price list country, which sets the scope of discounts, is a third piece of data.
- Why
- Duties follow the country of manufacture and transport follows the country of dispatch: an item made in China and shipped from the Netherlands pays Chinese-origin duty and transport from the Netherlands.
Decided, to be deliveredDecided on 11 October 2026 · Ref. RF-078
Comparing suppliers on full landed cost
- What the tool does
- Decided, not yet delivered: suppliers will be compared on full landed cost (net price + transport + insurance + customs duties + clearance + other non-recoverable taxes, import VAT excluded). Amounts actually paid will take precedence; otherwise duties will be estimated and labelled as such. If a component is missing, the cost will be “incomplete” and that supplier will never be shown as the cheapest. Today the purchase price, the transport share and estimated duties exist; insurance, clearance and other taxes are not entered, and rankings remain on net price.
- Why
- A lower net price can cost more once delivered; showing as cheapest a supplier whose cost is partly missing would lead to a choice made on a wrong figure.
In forceDecided on 12 October 2026 · Ref. RF-100
Customs duties estimated under the EU rule
- What the tool does
- Customs duties are calculated under the default EU rule, approved by finance: customs value = price + transport + insurance up to entry into the Union. Duties follow the origin, never the provenance. An 8- or 10-digit customs code is mandatory; the rate comes from a table kept by the purchasing manager and the administrator; a preferential rate is stored but never applied. Without a rate, a code, an origin or a known payer, the duty stays empty with its reason, never 0. Each amount is labelled “estimated (default EU rule, approved by finance)” and its assumptions are shown. Sites outside the Union are not covered. A setting can switch this calculation off.
- Why
- Without a written rule, non-EU suppliers would stay “incomplete” forever; the EU rule is the general rule. Labelling makes the estimate visible, and a missing rate or code never becomes a false zero.
In forceDecided on 16 October 2026 · Ref. RF-114
The group panel: every supplier is group, tolerated or exotic
- What the tool does
- The purchasing manager decides each supplier's status: group (a panel partner), tolerated or exotic. The status is set for the whole supplier, or for one product family, which then takes precedence: a supplier can be a partner for adhesives and exotic for everything else. A supplier without a status stays “unknown status”: it is never counted as exotic or as group. Each decision carries a reason, a date and an author; it can be withdrawn or cancelled, and the history stays readable.
- Why
- The purchasing team validates its partners. Counting a supplier not yet qualified as exotic would inflate off-panel purchasing out of a mere missing decision.
In forceDecided on 16 October 2026 · Ref. RF-116
A task to reduce exotic purchasing, above a threshold your purchasing team can adjust
- What the tool does
- When the exotic spend in a buyer's portfolio exceeds €10,000 or 20% of their spend (either one, over twelve months), a task appears in their list, with the spend at stake. Both thresholds are adjusted for your company. Estimated purchases of sites without orders count, and the task says so. Exotic purchases from suppliers without a buyer go to the purchasing manager.
- Why
- A threshold puts action where the stake is real; adjusting it per company avoids a useless alert on a small spend, or a large one going unnoticed.
Decided, to be deliveredDecided on 16 October 2026 · Ref. RF-117
Accords annuels fournisseurs (BAF) — conditions chiffrées, validation par le responsable achats, preuve partiellement ERP, base de chiffre d'affaires au choix
- What the tool does
- A year-end agreement carries its conditions, recorded on the supplier record, dated, versioned and cancellable like the record itself. The conditions are quantified: each carries a percentage of the agreement — ten common visits are worth 0.5 %. They are triggered by a threshold: the percentage is only earned once the number of criteria is reached, and that threshold and percentage belong to the agreement, entered per supplier. The gain is validated by the purchasing manager, never by the buyer: it stays conditional until validated, becomes earned on validation, and is never counted twice with savings. The evidence comes partly from the ERP, from the figures; the purchasing manager may override with a reasoned waiver when the threshold is close and the supplier agrees to let the point go. The revenue basis is chosen per supplier: invoiced or ordered.
- Why
- Les conditions d'un BAF sont chiffrées et cumulatives : un pourcentage qui ne se déclenche qu'à partir d'un nombre de critères se calcule sur les deux, sinon l'acheteur lit un acquis là où il n'y en a pas.
La validation revient au responsable achats et non à l'acheteur, pour qu'aucune personne ne valide son propre gain.
La dérogation est nécessaire parce qu'un chiffre ERP est une mesure, pas une preuve d'accord : si le fournisseur accepte de laisser le point, l'écart est réel mais il n'appartient plus à l'acheteur. Refuser la dérogation reviendrait à réclamer un montant que le fournisseur a déjà lâché.
La base facturé / commandé dépend du fournisseur : l'un tient ses engagements sur ses commandes, l'autre sur ses factures.
In forceDecided on 16 October 2026 · Ref. RF-118
The convergence rate, measured on orders
- What the tool does
- The share of spend with panel suppliers is measured on the ERP orders over the last twelve months: in total, by entity, by family and by buyer, with its month-by-month and year-by-year trend. Each purchase keeps the supplier's status at its date; the "current panel" view applies today's statuses to the whole history. An order with no price, no price base or no currency is not valued: it is counted apart, never as zero. Exotic purchases are listed by stake: spend, number of references, entities buying.
- Why
- Orders are dated and carry the supplier on every line: they show month after month whether purchasing is moving towards the panel. Relating the rate to spend of known status keeps a supplier not yet qualified from skewing the measure.
In forceDecided on 16 October 2026 · Ref. RF-122
The supplier's status at the date of purchase, and a separate estimate for sites without orders
- What the tool does
- Each status decision carries an effective date: a purchase is classified with the status in force on the day it was made, and a cancelled decision never counted. Action lists, on the other hand, say what is exotic today. When a site does not send its orders, its spend is estimated from its last twelve months of volumes multiplied by its purchase prices, and marked "estimated": it has its own columns, is never silently added to orders, and a line that cannot be valued stays empty with its reason.
- Why
- A supplier joining the panel must not rewrite history; a site without orders must not vanish from the measure, but an estimate mixed with orders would skew the rate.
In forceDecided on 16 October 2026 · Ref. RF-123
Convergence objectives per site or per family, checked on their date
- What the tool does
- The purchasing manager sets, for a site or a family, a target convergence rate and a date. The measured rate is shown next to it, today and on the target date; if the objective is not reached on that date, or cannot be measured, a task is handed to them with the gap in euros. Each objective can be replaced, withdrawn or cancelled, without erasing anything.
- Why
- An objective without a check on its date stays a wish; the automatic check recalls the gap when it matters.
In forceDecided on 16 October 2026 · Ref. RF-124
Each ERP's supplier codes matched to your suppliers
- What the tool does
- An ERP may write a supplier with its own code. A correspondence table links, site by site, that code to the tool's supplier; it is kept by the purchasing manager or the data referent, every decision is traced and can be cancelled, and the spend is recomputed at once. Codes that nothing matches are listed with their spend, so that no purchase stays attributed to an unknown supplier.
- Why
- Without correspondence, the spend of a panel supplier coded differently would remain of unknown status and wrongly lower the rate.
In forceDecided on 16 October 2026 · Ref. RF-119
Your suppliers' new items, qualified by your buyers
- What the tool does
- An item is new when it appears in a supplier's price list without having appeared there before, or when it shows up in your purchases for the first time. Each buyer qualifies the new items of their own suppliers: to be created in the management system, or refused. An item already attached to a price list is read from that attachment and is not qualified by hand. The tool then prepares a pre-filled creation request — price from the price list, customs code, supplier status, entities concerned — and produces it as an import file, which a person injects into the management system: the tool never writes to it itself. A dry run produces nothing at all. Every decision, every version of a request and every produced file stay traceable and can be cancelled, and the follow-up tells you whether the item appeared after the injection.
- Why
- Qualifying a new item commits the buyer on their own perimeter, and a management system is not written to from the tool: a person injects the file. Keeping the trace of every decision shows what was requested, what was injected and what was dropped; cancelling a production does not delete the file, it says the file must no longer be used.
In forceDecided on 16 October 2026 · Ref. RF-121
Replacing an item from an off-panel supplier: proposed, never applied alone
- What the tool does
- For each item bought from an off-panel supplier, the tool proposes the items of group suppliers it knows to be identical: same master reference, or exactly the same characteristics. The price gap is only computed once brought to the same unit and currency; otherwise it stays empty with its reason, never zero. The buyer decides for their suppliers, the purchasing manager everywhere; each decision is recorded and can be undone. A validated substitution remains a proposal: nothing is ordered or written into the ERP. With no equivalent, the tool gathers what is needed to ask the partner manufacturer for help.
- Why
- A substitution decided by the tool alone would commit the company to an equivalence nobody validated; proposing it with a price compared at the same unit, and leaving the recorded decision to the buyer, speeds up rationalisation without creating false gaps.
In forceDecided on 17 October 2026 · Ref. RF-125
Asking the partner manufacturer for help when no group item fits
- What the tool does
- When the computation finds no equivalent item in the group for an item bought off-panel, the buyer opens a request for help to the partner manufacturer: one thread per item, dated, signed, motivated, undoable, carrying the file of the item to replace. The request stays inside the tool: nothing is sent to the manufacturer, nothing is written into the ERP. As long as no request is open, the task list reminds the buyer; it disappears once opened. Without a computation nothing is deduced: the absence of an equivalent is only known once the tool has looked.
- Why
- Without an equivalent in the panel, asking the partner manufacturer used to stay informal and untraceable. A recorded thread tied to the item file makes the approach readable and measurable, without the tool ever writing to the manufacturer or into the ERP.
In forceDecided on 17 October 2026 · Ref. RF-126
Cross-manufacturer equivalences in a dedicated basis, always validated by a person
- What the tool does
- A dedicated basis records that one manufacturer's reference is the equivalent of another manufacturer's reference for the same need — tape against tape, even when the catalogues look nothing alike. The buyer proposes the equivalence for the suppliers of their portfolio, the purchasing manager validates it — it commits the whole group. Each article link is then validated one by one in the arbitration queue, never as an automatic batch: validating the equivalence proposes the equivalent reference on the same master product as the article already linked, and withdrawing it closes the proposals still pending, without ever breaking an already validated link. An equivalence can be symmetric or one-way ("A replaces B"), the criteria are a closed list, and the dimensions comparison is displayed as an aid, never blocking. A table of equivalences supplied by a manufacturer is imported from a file: each row creates an equivalence that is only proposed, never validated, and a couple already known is never duplicated. A closed request for help with no equivalence recorded triggers a reminder to enter it for the buyer, and an "Equivalences" screen lists the proposed, validated, rejected and withdrawn equivalences, every gesture requiring a reason.
- Why
- To compare competing suppliers on the full delivered cost of the same need and to propose an alternative — for instance replacing an exotic reference with a partner supplier's one. Nothing is ever applied on its own: every step is traced, cancellable, and decided by a person.
In forceDecided on 19 October 2026 · Ref. RF-129
The provenance zone is entered, never guessed; the transport norm is read per family and per zone
- What the tool does
- The dispatch zone of an article (European Union, Asia, United States…) is entered in one move, for one article or for a whole supplier, in bulk with a preview, each entry kept with its author and reason, cancellable. The zone list belongs to the company: one settings line adds a zone, with no technical work. No zone is ever deduced from a country. The transport share of each article, as a percentage of its purchase price, is then compared with the median of its family, then with that of its provenance zone: the buyer reads "within the norm", "outside the norm, but the provenance explains it", "outside the norm, unexplained", or "not assessable" when a figure is missing or the sample is too small, always with the figures.
- Why
- So that a buyer knows whether a transport overcost is normal for the zone the article comes from or deserves attention, without a threshold or a zone being imposed on their behalf: the thresholds are set with purchasing and, until they are, nothing is classified.
In forceDecided on 18 October 2026 · Ref. RF-133
The customs duty base is limited to what you buy, is updated by hand and says "no rate" when it does not know
- What the tool does
- The purchasing manager declares the families and countries actually bought; only those enter the Union's customs duty base, and only the basic duty (no preference, no quota). At each publication of the customs tariff, a manager or an agent supplies a file: the tool first shows what would change, then writes only on confirmation, in one operation that can be cancelled in a single step. It connects to no outside service. A rate that has not changed is not rewritten, a rate that changes becomes a new version, nothing is ever erased, and each import keeps the reference and date of the publication used. The customs code is typed or imported, never proposed by the tool. A coverage report gives, for each declared code and origin, the rate in force or "no rate: —", with the date of the source.
- Why
- A missing rate is not a zero rate: showing 0 would suggest duty-free goods. And a wrong code gives a plausible, wrong duty, which is why the tool does not classify articles in the buyer's place.
In forceDecided on 19 October 2026 · Ref. RF-135
Annual agreements are entered and read by command, a preview writes nothing, and an agreement's gain is never added to tariff savings
- What the tool does
- A supplier's annual agreement, its conditions and the counted visits or campaigns are entered by command, with an author and a written reason. Everything is versioned and cancellable, nothing is deleted, and a preview writes nothing. The command and the screen read the same rows. An agreement's gain is counted separately: it is never added to tariff savings. Progress computed on revenue is described separately; bulk import will come later.
- Why
- Agreement rights on one side, tariff on the other: the same euro must never be counted twice, and a figure must not differ depending on where it is read.
In forceDecided on 19 October 2026 · Ref. RF-136
A counterpart is measured against its threshold: below it nothing is earned, and with no counter the cell stays empty
- What the tool does
- For a counterpart of an annual agreement (joint visits, campaigns), the tool compares the entered count with the agreement's threshold, counting only events within the period. Below the threshold nothing is earned and the gap "N missing" is shown, with no pro rata. At the threshold, the agreement's percentage is earned. When nothing was entered, the cell is empty with its reason and never zero. A threshold's revenue achieved is read in the ERP purchases.
- Why
- Showing 0.5% earned where nothing is earned would mislead the buyer, and a zero in place of an absence would say the supplier owes nothing, which the data cannot support.
In forceDecided on 19 October 2026 · Ref. RF-138
An agreement's progress is read on the real ERP purchases, invoiced or ordered as the agreement says, and an absence stays empty
- What the tool does
- For each annual agreement, the tool adds up the supplier's purchases recorded in the ERP over the agreement's period: the invoices or the orders, depending on the base chosen for that supplier, converted to euros at the rate of the line's day. For each threshold it says whether it is reached, whether it will be at the pace observed since the start of the period, or whether it is out of reach, with the amount missing or the excess. Below the threshold nothing is earned and there is no pro rata. A line that cannot be valued is counted apart with its reason, and when there is no purchase to read, the cell stays empty with the reason, never zero. The calculation is redone at every reading, by the command or by the screen, with the same figures.
- Why
- To know before the end of the year what is missing for the negotiated threshold and whether it will be reached. A lack of data is not a zero purchase: a zero would say the supplier owes nothing, which the data cannot support.
In forceDecided on 19 October 2026 · Ref. RF-137
The transport cost of each item, split by value or by weight as the supplier chooses
- What the tool does
- For a shipment, the tool finds the carrier attached to the entity's lane, takes the transport amount (the invoice or quote, otherwise the grid estimate) and splits it over the items: by line value by default, or by weight when the weight is known for every line. The supplier picks the mode for their shipment; the manager sets the default mode and the allowed modes for each carrier and lane. Shares are to the cent and add up exactly to the amount.
- Why
- To know what transport adds to each item's price without guessing: a missing weight rules out the split by weight (the tool says so and splits by value), an unknown cost stays empty and is never read as zero. A purchase transport cost is shown only to those entitled to it.
In forceDecided on 19 October 2026 · Ref. RF-139
The "Transport by lane" screen: see the lane attachments and the cost of each article and set the split, with no calculation or write done by the screen itself
- What the tool does
- The screen shows which carrier serves which lane for each entity, computes the transport cost of each article of a shipment (given or estimated amount, split by value or by weight) and lets the manager set the default mode. Each share is shown to the cent, with the sum, equal to the amount. Attaching a lane, remembering the mode of a shipment or setting the default needs the matching right, and everything goes through the engine.
- Why
- So that supply, the buyer and the manager read the same figure as the engine, with no calculation hidden in the screen. When a weight is missing the screen says so, shows the value split applied instead, and a line with no figure keeps its reason: never zero. A purchase transport cost is shown only to those entitled to it.
In forceDecided on 19 October 2026 · Ref. RF-145
A declared loss completes the ERP scrap, is never counted twice, and proves "delivered short" only with both dates and a guarantee
- What the tool does
- The supply planner declares a loss (reference, date, quantity, reason, and ideally the lot and the expiry and reception dates), on screen or in a file. If the ERP already has a scrap row for the same article, the declaration is matched to it, by the lot or failing that by the date when there is no doubt, and completes it without changing its quantity or reason: the loss is never counted twice. Otherwise it counts on its own. The shelf life left at reception is compared to the supplier's guarantee to say whether the lot was delivered short, with no verdict when a date or the guarantee is missing. The value is the one entered, otherwise an estimate at the purchase price of the reception date, flagged as such. Only an expiry feeds the volume advice, and the section stays internal: it is never in the request sent to the supplier.
- Why
- ERP scrap rarely says why a product was thrown away, and does not exist everywhere. The supply planner knows the lot and the dates, which are the evidence for the supplier. Since the ERP scrap prevails, nothing is counted twice, and an estimate is never shown as an entered value.
In forceDecided on 19 October 2026 · Ref. RF-146
The "Declared losses" screen: declare a loss or import a file, with a preview before writing, with no calculation or write done by the screen itself
- What the tool does
- The screen lists the declared losses with, for each one, the "delivered short" verdict or the absence of verdict and its reason, the match with the ERP scrap (by the lot, by the date without lot "to be checked", confirmed by the buyer, or autonomous loss with its reason) and the entered or estimated value. It lets the user declare a loss or import a file: a preview first says what will be written and each refused row with its reason, then the person confirms. The buyer can confirm or undo a match there. Declaring needs a right granted by the administrator; cancelling is reserved to the author or a manager. Everything goes through the engine.
- Why
- So that the supply planner, who only views everything else, can declare losses without being able to act elsewhere, and everyone reads the same figure as the engine. An estimated value carries the mention "estimated", and an absence stays a dash with its reason: never zero.
In forceDecided on 19 October 2026 · Ref. RF-152
With no lot on the ERP scrap, a declared loss is matched by date only when there is no doubt, and the buyer confirms or undoes
- What the tool does
- ERP scrap rows probably carry no lot number, so a declared loss is matched to a scrap row by reference, entity and nearby date. The tool says so soberly: "matched by date, without lot: to be checked". It only does so when there is no doubt: never when the declared quantity exceeds the scrap row's, never beyond the scrap quantity when several declarations share one row, and when several scrap rows fit it does not choose: the loss is counted on its own and the buyer decides. The buyer can confirm a match or undo it, with a reason; every decision is recorded and can be cancelled. The ERP scrap keeps its quantity, value and reason.
- Why
- When the lot is missing on the ERP side, the date is the only clue. It must not make a loss count twice, nor attach it at random: when in doubt, the person who knows the floor decides.
In forceDecided on 20 October 2026 · Ref. RF-156
An ERP supplier the group does not use is classed "not used" by the purchasing manager: it leaves the analyses without ever disappearing
- What the tool does
- When a company's ERP contains a supplier the group does not manage (no supplier record, no filed price list, no assigned buyer), the tool proposes it as "to classify" and warns the purchasing manager. He or she, or the administrator, declares it "not used": a reason of at least 10 characters is required, a preview of the volume set aside is shown before anything is written, and the decision is traced and can be cancelled. A "not used" supplier then leaves the analyses, tasks, alerts, assignment lists, ERP anomalies and coverage indicators, but stays visible in a dedicated screen with its volume and its last movement, and can be reopened at any time. If it becomes managed (a price list is filed, a buyer is assigned), it is no longer set aside. For a managed supplier, nothing changes.
- Why
- So that the analyses, tasks and alerts only speak of what the group really buys, without a supplier vanishing from the figures unnoticed: the decision binds the purchasing manager, it is reasoned, visible and reversible, and the tool never takes it in his or her place.
In forceDecided on 23 October 2026 · Ref. RF-175
A supplier known only by its record is a supplier like the others: the screen shows it, the alert counts it, and its ERP code is not proposed for classification
- What the tool does
- A supplier can be known to the group by its record alone, without having filed any price list and without being assigned to anyone. The tool then treats it like an ordinary supplier: the Portefeuilles screen shows it in the "Sans affectation" (unassigned) section, the "N supplier(s) without holder" alert counts it, and an assignment task is derived for it. It enters no portfolio, no objective and no total: it is worked on, not counted. On the ERP side, a record makes the code a managed code, like a filed price list or an assignment: its code is therefore not proposed for classification, and a code already declared "not used" that gains a record comes back on its own into the ERP readings, its history kept. For a supplier that already has a price list or an assignment, nothing changes.
- Why
- The tool must say the same thing everywhere: a supplier the engine knows must be the one the screen shows. A supplier absent from the "unassigned" section and from the alert, and proposed for classification although it is managed, gives the purchasing manager a false alert and a task that makes no sense.
In forceDecided on 21 October 2026 · Ref. RF-163
An equivalence links two different manufacturers — two references of the same manufacturer are refused
- What the tool does
- An equivalence states that a reference of one manufacturer is the equivalent of a reference of another manufacturer, for the same need: the two sides are two different manufacturers. Proposing an equivalence between two references of the same manufacturer is refused before anything is written, with a clear reason that names both references and the common manufacturer: nothing is written, neither in the equivalence basis nor in an imported table file, whose rows are then all refused. It is a business decision, not a crash: the command stops with the same return code as the other refusals. The dimensions comparison, on the other hand, is displayed as an aid and never blocks: an equivalence between two competing manufacturers is compared, it is not declared against the engine.
- Why
- Two references of the same manufacturer are not two equivalents, but two items of the same range: the equivalence basis exists to compare competing suppliers on the same need. The engine used to crash on this case instead of refusing it; it now refuses, with a readable reason.
In forceDecided on 22 October 2026 · Ref. RF-170
An ERP supplier code stands for a single supplier of the tool, and every purchase-price reading follows that link
- What the tool does
- For a company, an ERP supplier code stands for a single supplier of the tool, never several. The correspondence is posed, withdrawn and cancelled as before (same profiles, written reason, full trace, cancellation possible) and remains the only source of the link. Every ERP purchase-price reading follows it: the linking, the price control, the savings and their history of readings, the transport share and the transport norm, the purchase-price history, the watch of the new references, the ERP export and the stock at risk, as well as the supplier filter of the synchronisation. A reconciled code is found under the name of the tool's supplier and is no longer read under its own code. Without a correspondence the code is compared as it stands, exactly as before: a supplier with no correspondence sees its readings unchanged. A code that is not reconciled is never attributed to a supplier: its price lines stay without a supplier of the tool and it stays in the convergence list of codes to reconcile. The reverse can also be read, the tool's suppliers that no ERP code stands for, without attributing anything to them.
- Why
- When the supplier is the same on both sides, the ERP's supplier and the tool's supplier are matched first, and an ERP code stands for only one supplier. Until now the correspondence was read only by the convergence: a reconciled code was not found by the purchase-price readings, which compared the code letter for letter.
