Increases, history and savings

Classification and coverage of increases, quarantine, price history, the price in force by condition, intercompany gains and the volume proposal (to be delivered).

19 rules in force1 decided, to be delivered

In forceDecided on 1 October 2026 · Ref. RF-030

Alert levels of an increase

What the tool does: Each price change is classified: information, “to watch”, “alert”, “strong alert”, against configurable thresholds. Each boundary belongs to the higher class (exactly 5 % is an alert), using exact decimal arithmetic. Beyond an implausible increase or decrease, the line is quarantined.
Why: An approximate calculation classified an exact 5 % decrease as “to watch”.
Where to see it: Price lists received (see the capture)
Strong-increase thresholds

In forceDecided on 10 October 2026 · Ref. RF-031

Quarantine

What the tool does: A quarantined line (implausible increase or decrease) is excluded from averages, amounts and savings; it remains visible in the detail with its reason.
Why: A single line with a price multiplied by ten is enough to distort the savings shown.
Where to see it: Price lists received (see the capture)
Savings by supplier
Savings — overview (see the capture)

In forceDecided on 10 October 2026 · Ref. RF-032

Coverage of the weighted increase

What the tool does: The weighted increase counts only the lines whose volume is known and convertible. Its coverage (the share of comparable lines) is shown next to it, with the excluded lines by reason and their own change.
Why: An increase concentrated on items without a convertible volume would make the average too low without saying so.
Where to see it: Price lists received (see the capture)

In forceDecided on 11 October 2026 · Ref. RF-074

24-month price chart, only when the history supports it

What the tool does: The timeline of a reference (price list, net price due, ERP purchase price, special prices) is drawn as a chart only if the last 24 months hold at least 4 dated prices spread over at least 6 months. Below that: the list only, with the sentence “history too short for a chart”. Above: steps (a price holds until the next one), with no smoothing, trend or extrapolation, in a single unit; special prices are points. Each real price can be hovered: date, value, source.
Why: Two points always make a slope and three can line up by chance: a chart over a short history suggests a trend the data does not support.
Where to see it: Purchase price history (see the capture)

In forceDecided on 11 October 2026 · Ref. RF-076

Intercompany gains are never added to savings

What the tool does: The gain of a formalised intercompany opportunity (buying through company B at B's special price rather than at A's list price) is a separate category, shown next to savings. It is never included in realised savings, conditional savings, or any supplier, portfolio or group total.
Why: On consolidation, the internal margin between two group companies is eliminated: what A gains, B gives up. Adding it would count the same saving twice. Rule approved by finance.
Where to see it: Intercompany opportunities
Savings by supplier
Savings — overview (see the capture)

In forceDecided on 12 October 2026 · Ref. RF-094

Intercompany opportunities: formalising a gain and tracking it

What the tool does: A supply planner only sees opportunities for the companies their account is attached to. Before formalising a gain, the box “supplier consulted: B's special price applies to this volume and to an intra-group resale” is mandatory and logged. Both prices are converted at the reference rate of the calculation day, frozen in the decision; without a rate, the line is rejected with its reason. Only the same supplier on both sides is compared. The formalised gain is then tracked down to the price actually ordered and then invoiced; the gap is shown next to the gain, without changing it or entering any total.
Why: A calculated gain is not an obtained gain. B's special price is tied to a volume and a customer: only the supplier knows whether it applies to a resale to another group company.
Where to see it: Intercompany opportunities
Accounts

Decided, to be deliveredDecided on 11 October 2026 · Ref. RF-080

Volume proposal: only the surplus over MRP needs, writing nothing

What the tool does: Decided, not yet delivered: the quantity proposed to the supply planner ahead of an increase will be the quantity on top of the need the MRP already covers (stock, open orders and planned orders deducted). The supply planner will decide; if they accept the proposal, they will create the order in the ERP themselves. The tool will not create, change or close any order. Missing data will never be read as zero: the quantity will remain a ceiling, with its reason.
Why: Deducting only the stock would order twice what the MRP already plans. A forward purchase must remain a separate, dated decision.
Where to see it: New supplier

In forceDecided on 12 October 2026 · Ref. RF-092

Future ERP purchase price: shown separately, never taken as current

What the tool does: The current ERP purchase price is the most recent one whose effective date is not in the future. A price dated after today enters no calculation (matching, price checks, savings, export, transport, stock): it is shown separately as an “upcoming price”, with its date, and becomes current on that date. A reference that only has future prices has no current price: empty, never zero.
Why: Taking a price that does not apply yet as today's price distorts the gap to the price list, the impact and the order checks; ignoring it would hide an announced increase.
Where to see it: Purchase price history (see the capture)

In forceDecided on 13 October 2026 · Ref. RF-101

Price in force: chosen by condition, never at random

What the tool does: When an item has several prices depending on conditions, every screen that reads “the price in force” applies the same rule. If the condition is known, only that condition's line counts. Otherwise: a single condition, its line; several including an unconditional price, the unconditional price, with the reason listing the others; several without an unconditional price, no line, with the reason. In price checks, the highest offered price is used as a ceiling; in the ERP export, these lines stay to be checked; in the group best price, ranking is done condition by condition.
Why: A reference with several conditions has several true prices. Picking one at random would pass off a commitment price as the price due, or export two prices for the same item.
Where to see it: Price checks (see the capture)
Savings by supplier
Special prices
ERP export
Group best price (see the capture)
Forward buying

In forceDecided on 18 October 2026 · Ref. RF-127

The transfer price between group companies, shown in “Best price of the group”

What the tool does: For an item, the purchasing manager and the administrator also see what each company would pay by buying from another group company that buys it: that company's purchase price, plus the margin, plus a shipping cost. The margin is the one set for the pair of companies, otherwise the default margin; the shipping cost is the per-line amount of the pair's rule, otherwise the default shipping cost set by the manager. These lines are labelled “intercompany transfer”: they are never ranked and never mixed with supplier prices, whose ranks do not change. With no usable margin the line stays without a figure; with no shipping cost declared it says so instead of counting a zero; a shipping cost in another currency is converted at the day's rate, otherwise the line is refused with its reason.
Why: A transfer price is sensitive: it is shown only to those who set the conditions. A missing margin or shipping cost is never read as zero: a line without a figure is better than a wrong price.
Where to see it: Intercompany prices
Group best price (see the capture)

In forceDecided on 19 October 2026 · Ref. RF-128

Volume proposals: open orders and planned orders count only when they are known

What the tool does: Open orders and the planned orders of the MRP now come from the ERP; files given to the command remain possible as a fallback. When this information is missing, the proposal says so ("ERP data missing: planned orders", "ERP data missing: open orders") and the quantity stays a ceiling: missing information is never read as zero. A planned order is only deducted if it carries a date within the retained coverage; without a date it is not deducted and the proposal points it out. A quantity given for the whole group is spread according to each entity's share of the twelve-month sales; the number of customers is shown alongside and does not enter the calculation.
Why: So that the tool does not invent a need it cannot see, nor deduct orders that fall outside the covered period. The supply planner keeps control of the firm order: the tool writes nothing in the ERP.
Where to see it: Forward buying

In forceDecided on 19 October 2026 · Ref. RF-143

Volume proposals: planned orders and quantities still to receive come from the ERP; without them, a preview and no task

What the tool does: The planned orders of the MRP, with their date of need, and the quantity still to be received on each open order are supplied by the ERP connection, refreshed like stock and sales. A connection that does not supply them keeps working. When this information is missing for a company, the volume proposal can still be calculated as a preview, with a ceiling, but no task is sent to the supply planner for that company; the reason "ERP data missing: planned orders" is shown. The other companies of the same supplier are not affected. An order whose quantity still to receive is empty is not deducted: its line stays a preview, never read as zero.
Why: So that the supply planner does not receive a task based on a need that ignores what the MRP and the orders already cover, and so that this information no longer has to be prepared by hand.
Where to see it: Forward buying

In forceDecided on 26 October 2026 · Ref. RF-177

The stake of a stock at risk valued in a foreign currency is converted to euros at the rate of the reading day; with no rate, it stays empty

What the tool does: When the purchase price of a lot of stock at risk is in a foreign currency (pounds, zlotys...), the value at risk is converted to euros to become the stake of the task, which then counts in the euro total. The tool divides the value by the exchange rate (units of the currency per euro) that is the latest dated on or before the reading day, never a rate dated after it nor older than the maximum age of rates (10 days by default, as for the annual agreements), and the reason of the stake states the original amount, the date of the rate and the rate. With no usable rate for the currency (missing, too old, or latest rate zero), the stake stays empty, with its reason: never zero, never a default rate. The rate used is always the latest one: if it is zero, the tool does not fall back to an older rate. The stock-at-risk screen still shows the value in the local currency.
Why: A value in a foreign currency has a euro equivalent as soon as a rate is declared: it must count in the total of the tasks, without ever inventing a figure when the rate is missing.
Where to see it: My tasks (see the capture)
Forward buying

In forceDecided on 19 October 2026 · Ref. RF-142

The intercompany transfer price also applies outside the comparison, but only to companies already buying through the group, and the source of the price is always stated

What the tool does: When a company has decided to buy a product through another company of the group, the price-gap analysis, the savings calculation and the price check recognise the agreed transfer price: if the ERP purchase price, the order or the invoice is that price, it is judged against it and not against the supplier's price list. Every result states whether the price comes from the supplier or is a transfer price. A company without that decision, or whose purchases do not follow it, gets exactly the results it got before.
Why: So that an increase is never counted twice and a supplier is never blamed for a gap against a price it never granted. The gain made through the group stays apart and enters no acquired saving; the margin and the shipping charge are set by the purchasing manager and shown only to those entitled to see them.
Where to see it: Price checks (see the capture)
Savings by supplier
Matches to resolve (see the capture)

In forceDecided on 19 October 2026 · Ref. RF-148

Packaging scale control: the price per litre of the same product sold in several containers is compared, and an inversion is flagged as information

What the tool does: When the supplier record says how to recognise the containers of one product (a shared reference root), the tool proposes the group to the buyer, who validates it once. The price per litre of each container is then compared: if a larger container costs more per litre than a smaller one, beyond 2% by default, the gap is shown in the price-list analysis and repeated among the arguments of the negotiation file. Nothing is ever grouped on the resemblance of designations.
Why: So that the right question can be put to the supplier ("why does the 5 L cost more per litre than the 1 L?") without ever comparing different products. A container whose volume is unknown has no price per litre, and that gap is stated rather than replaced by zero. It is information: it never blocks a price list.
Where to see it: Price lists received (see the capture)
Interpretation questions

In forceDecided on 19 October 2026 · Ref. RF-153

Packaging choice: the cheapest per litre that is consumed before expiry, costs included, and whether to buy the small pack or repackage

What the tool does: For a group of containers of one product that the buyer has validated, the tool recommends, site by site, the container that is cheapest per litre among those consumed before expiry, counting handling and storage costs when they are declared (otherwise the recommendation says so). The yearly gain is computed on the litres actually consumed. A task is created for the buyer only above a minimum gain that the buyer has declared: without that minimum, the recommendation stays a plain view. For a product repackaged in-house, the mention "repackaged product" appears as soon as a bill of materials exists, without waiting for any validation; once the group is validated, the supplier's price for the small container is compared with the material cost per litre plus the declared repackaging cost; without that cost there is no comparison.
Why: So that a better packaging can be proposed without ever advising a container that would expire before being consumed, and without inventing a cost, a minimum gain or a repackaging cost that nobody has decided. Unknown data gives no recommendation with its reason, never a zero.
Where to see it: Price lists received (see the capture)

In forceDecided on 19 October 2026 · Ref. RF-144

Bulk product repackaged into bottles: its consumption and material cost are deduced from bottle sales, site by site, from the ERP bill of materials

What the tool does: When a bulk product is resold in bottles, the tool reads in the ERP how many litres of bulk and which packaging make up a bottle, then deduces the bulk consumption each month from the bottle sales, taking the yield (the share actually packed) into account. This consumption is computed site by site, never added across sites (unless one site explicitly declares it repackages for another), and feeds the anticipation purchase and the volume advice. The tool also gives the material cost of the litre sold (bulk and packaging) and the effect of a rise in the bulk or in a packaging item, beside the margin without changing it, as well as the bottle losses brought back to the bulk. A missing yield counts as 1 with a mention; an invalid yield is refused with its reason.
Why: A bulk product is never sold as such: without this calculation, the anticipation purchase sees no consumption at all. Nothing is guessed: without a bill of materials in the ERP, no link is assumed between a drum and a bottle, even if their names look alike, and a component without a price makes the cost partial instead of counting it as zero.
Where to see it: All screens

In forceDecided on 19 October 2026 · Ref. RF-151

A site can repackage for another, but only if declared: the bulk consumption is then counted at the site that repackages, with its source

What the tool does: When one site fills bottles that another site sells, the manager or the administrator declares it once: "site A repackages for site B", with a reason and their name. The bulk consumption of the bottles sold by B is then counted at A, which buys and opens the drum, and the tool shows where it comes from ("own" or "repackaged for B"). A's anticipation purchase and volume advice read it. The declaration is made on the command line, with a preview that writes nothing, is withdrawn in one step (the consumption goes back to B) and keeps its history. It is refused, with its reason, if a site is unknown, if both sites are the same or if it would form a chain; a component of B with no validated equivalent at A is set aside with its reason.
Why: Without a declaration, the bulk consumed by one site for another site's bottles distorts both sites: the first is understated, the second overstated. Nothing is guessed: the tool never moves a consumption from one site to another unless someone declared it, and without a declaration two sites are never added.
Where to see it: All screens

In forceDecided on 21 October 2026 · Ref. RF-167

An alert says where better conditions can be found in the group; the transfer price is seen only by profiles entitled to it

What the tool does: For an item bought within their scope, the reader receives an alert when another group company can supply it for less than they pay (inter-company transfer price, margin and carriage included). The alert says where: the company and the supplier. The reader's scope bounds what they buy, never the "where": the buyer only receives items from the suppliers of their portfolio, the supply planner only those of their company or companies (an account with no company receives nothing and no longer reads the whole group), the purchasing manager and the administrator the whole group. The transfer price only appears if the profile is entitled to it: the purchasing manager and the administrator always see it, finance, the architect and the commercial manager never, and the administrator sets the other profiles one by one (append-only, written reason, cancellable); with no setting, the buyer and management see it, the others do not. Without that right, the alert stays readable but carries no figure from which the price could be worked out: no saving, no percentage, no price of the other company, and the same goes for the inter-company purchasing opportunity lines. Never, in an alert, a counter, a view, a message or the log: a quantity, the purchase price of the supplying company, the margin, the rule or the carriage. The administration switch for opportunities also cuts the alert; nothing is written, neither to the ERP nor to the orders.
Why: Purchasing is split by buyer and by company, but the buyer is told that better conditions exist elsewhere in the group, with where. The transfer price is sensitive data: the administrator decides, profile by profile, who sees it, and a profile that does not see it must not be able to work it out from a saving or a percentage shown next to the price it pays.
Where to see it: Intercompany opportunities

In forceDecided on 22 October 2026 · Ref. RF-169

A profile that does not see the transfer price can ask for it; the request is traced and only an authorised person answers

What the tool does: When a "better conditions elsewhere" alert is read without the transfer price, the buyer or the supply planner can ask for it, with a written reason. The request takes the alert that the tool re-reads within the requester's scope: an invented alert, or someone else's, is refused and the refusal is journalled. It is addressed to the buyer who holds the targeted supplier today, or else to the purchasing manager, and creates a task in their "To do" list, with no figure at all, which disappears at the answer. Only an authorised person answers (the buyer of the targeted supplier, the purchasing manager, the administrator), never the requester themselves. The answer is not typed in: the tool re-reads the alert with its price and freezes it at that date, like a retained opportunity; only the requester, the person who answered, the purchasing manager and the administrator read it. The request is append-only, versioned and cancellable; nothing leaves the tool and no ERP is written.
Why: A supply planner from whom the administrator hides the transfer price sees the alert but must be able to ask a colleague in the other company, or purchasing, for it, in a traced way. The price stays sensitive data: it is never typed in by hand, never shown without the right, and nobody can answer their own request.
Where to see it: Intercompany opportunities

See these rules at work on your price lists

The demonstration runs on a fictitious data set, then, if you wish, on a real price list from one of your suppliers.

Try Buyvera Product tour