Home · Solutions · Sales & marketing · The new wholesale price list in the ERP before stations open
Solution · Sales & marketingA producer’s 6 a.m. price change no longer means a day of selling on yesterday’s margins
The new wholesale price list in the ERP before stations open
A robot collects the morning price lists, updates replacement costs in the ERP, recalculates margins per station and product and drafts retail price proposals under your policy; the pylon change goes out after a human’s approval.
Executive summary
Producers publish wholesale prices every morning. A network that retypes them sells half the morning at stale costs, and pricing decisions ride on yesterday’s margin.
Price lists come down automatically right after publication, replacement costs update in the ERP, and margins per station and product are recalculated before opening.
Retail price proposals under a written policy await a human’s approval; once given, the change spreads to station systems with a full trail: who, when, on what recommendation.
producers’ price lists and quotations; costs and margins in the ERP; proposals and approvals in Microsoft Teams; station price systems
Business problem
Half a morning on yesterday’s costs
Wholesale fuel prices change daily, sometimes sharply. Producers publish their lists early in the morning, each in its own format and place. For a station network or a wholesaler these numbers are the replacement cost of stock: only against them is today’s real margin known, per product and per station.
Where the lists are retyped by hand, the morning always looks the same: someone logs into portals, copies numbers into a spreadsheet, recalculates, pastes into the ERP, then computes margins and sends recommendations around. By the time they finish, the stations have been selling for two hours, and each of those hours went out on margins computed against yesterday’s costs.
Pricing decisions suffer twice. First from delay: the recommendation arrives after the morning fuelling peak has passed. Second from consistency: with dozens of stations and a manual process, some sites get prices per the policy and some per the hurry, and afterwards nobody can say why a given station stood where it stood.
On days of large price moves this process can be the most expensive hour of the month: sales flow at full stream while the company is the last on its own market to learn its new replacement cost.
How it works today
Below is what the work looks like before anything is automated.
- PersonEvery morning someone logs into producers’ portals one by one and downloads the lists
- PersonNumbers are retyped into a spreadsheet and pasted into the ERP, product by product
- Risk of errorA typo in one purchase price distorts a whole product group’s margins for the day
- WaitingStations sell from opening, but the current margin is known only after the retyping ends
- PersonRetail recommendations go out by email or phone, station by station
- Risk of errorSome stations reprice per the policy, some per the hurry; no trail of decisions exists
Why the current process costs more than it appears
The bill that never shows up in a budget.
- Hours of selling at a stale replacement cost on up-move days: a margin that looks fine till noon and turns out an illusion by evening.
- Network inconsistency: two stations in similar micro-markets stand at different points of the policy because the recommendation reached one and not the other.
- A retyping error that corrupts the margin reports for a day and undermines trust in the numbers altogether.
- Daily, sterile morning work that creates no decision and only moves numbers from place to place.
Cost of inaction
The middle row counts only selected mornings: days when wholesale moved hard and retail found out late. Twelve such days a year is a cautious assumption; their cost depends on morning volume and the size of the move, which is why the model multiplies exactly those two variables.
The third row is left without an amount because today there is no way to compute it: there is no trail of which station repriced when and by what. That in itself is an audit finding.
A model organisation with realistic proportions – the numbers exist so you can run the same maths on your own data; they are not a client result.
A forty-station network with a wholesale arm: purchases from two producers, retail prices set centrally with local corrections, SAP as the ERP, a station price management system, Microsoft 365.
Two producer price lists a day, some 90 product-station positions to recalculate, the morning sales peak between 6:30 and 9:00.
One person at head office starts at 7:30 with portals and a spreadsheet; recommendations leave around 9:30; on holidays a stand-in takes over, with varying results.
On big-move days the network sells the whole morning peak at yesterday’s costs; the pricing policy exists as a document but not as a mechanism.
The robot collects the lists at publication, updates costs in the ERP, recalculates margins per station and product, drafts proposals under the written policy and posts them for approval; approved prices flow to station systems with a full trail.
In the modelled case the pricing morning ends before the stations open, and the pricing policy works for the first time as a rule rather than an intention. Model numbers, not anyone’s ledgers.
Proposed solution
First we write the pricing policy down so it can be executed: positioning against competitors per micro-market, minimum margins per product, roundings, station exceptions. It is a document with an owner and versions; the automation executes it but never changes it.
The robot collects producers’ lists the moment they are published, in whatever formats they come, and updates replacement costs in the ERP. It immediately recalculates the running margin per station and product and builds retail price proposals under the policy, with a justification at every line: the cost, the competitive position, the rule applied.
Proposals wait in Microsoft Teams for the pricing owner’s approval; they can be accepted in bulk, corrected point by point or rejected. Once approved, changes spread to the station price systems, and the trail remains: who, at what time, which proposal, with what correction. Days without approval by the cut-off hour have a clear escalation path.
UiPath Orchestrator: publication triggers, per-producer queues, retries and an audit trail; UiPath Integration Service connector for Microsoft Teams; UiPath Action Center approvals; a Microsoft Power BI margin board
The written pricing policy as versioned executable rules, list collection, ERP cost updates, margin recalculation, justified proposals, approvals with corrections and distribution to station systems
Producers’ portals and price files; costs and materials in SAP via documented interfaces; the station price system via its interface; optionally the competitor price source you already use
How the automated process works
- SystemA producer’s price list publication starts the run within minutes
- AutomationReplacement costs update in the ERP; the running margin is computed per station and product
- AutomationRetail proposals are built under the written policy, with a justification at every line
- PersonThe pricing owner approves in bulk, corrects point by point or rejects in Microsoft Teams
- SystemApproved prices spread to station systems; the decision trail lands in the register
- PersonThe margin board shows the network in one view: cost, price, margin, position against policy
Human-in-the-loop model
Automation handles
- Collecting the lists at publication and updating ERP costs without retyping
- Margin recalculation and proposal building strictly under the written policy, with justifications
- Distribution of approved prices and a complete decision register
People decide
- The pricing policy and every change to it, with a version and a date
- The daily approval, correction or rejection of proposals
- Decisions on unusual days: price wars, outages, promotions
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- producers’ price lists and quotations
- costs and product materials in the ERP
- the written, versioned pricing policy
- optionally competitor prices per micro-market
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- updated replacement costs in the ERP
- proposals and approvals in Microsoft Teams
- prices in station systems and the decision register
Human touchpoints: UiPath Action Center approvals in Microsoft Teams; the margin board as a Teams tab; a policy review at the rhythm agreed with sales
Technologies used
publication triggers, per-producer queues, retries, audit
Aproposals, approvals and escalations on the sales channel
Aapproving the pricing day in one action, with point corrections
Acost updates and material reads via documented interfaces
Athe margin board: cost, price, margin and policy position per station
AHow we deliver this
From this description to a running process
We deliver this solution through our process automation service: first we measure the process on company data, then we build, test and maintain the robots. SAP integration is handled by our SAP team.
Industries
Case studies
Delivered client work is described under Case studies.
Illustrative economic model
Numbers you can check against your own data.
The second line depends on two things we cannot know for you: morning volume and the number of big-move days. The model takes cautious values; the calculator alongside accepts your own. The automation does not raise the margin as such; it shortens the time in which no pricing decision could be made because the numbers were not there.
Run the numbers on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- Replacement costs are in the ERP before the stations start selling, every day, holiday stand-ins included
- Proposals execute the policy, so the network stands where management decided, not where the phone got to
- Every pricing decision leaves a trail, so the policy effectiveness conversation runs on a register, not on memory
- Retyping errors disappear together with the retyping
- Sharp-move days stop being blind-selling days
The management view
- The pricing policy becomes a mechanism with an execution register rather than a document of intentions
- The network’s margin is visible live per station and product, against today’s costs, not yesterday’s
- Pricing competence stops being hostage to one person and their morning
Board-level KPIs
time from list publication to ERP update · share of stations priced per policy · running versus planned margin per station · manual proposal corrections and their effect · days with a complete pricing decision trail
Security and governance
The automation has exactly the permissions it needs. Not one more.
- The robot changes only replacement costs in the ERP, within a defined scope; retail prices reach stations only after a human’s approval
- Every proposal records its inputs, the policy version and the justification; the decision register is complete by construction
- The pricing policy is versioned; only its owner on the sales side changes it
- No personal data is involved; the process deals in products, stations and prices
- Proposals and registers stay in your Microsoft 365 tenant, and the robots run in the EU region of UiPath Automation Cloud
Why now
Wholesale price volatility is durably higher than a decade ago, and every hour of delay on a move day costs real margin on real volume.
Pressure on retail margins leaves no room for blind-selling days: networks that react in the morning collect the margin of those that react in the afternoon.
All the pieces already exist: lists are published electronically, the ERP holds costs, station systems have interfaces. What is missing is the process that joins them before 6:30.
Relevant executive roles
The network executes the pricing policy every morning, with a register showing where the policy works and where it needs changing
A running margin computed against today’s costs ends the era of reports that correct the morning in the evening
Instead of retyping numbers they manage rules and exceptions; the morning starts with an approval, not with portals
Common questions and objections
And you are not handing it over: the automation executes your policy and prepares proposals, and every retail price passes through a human’s approval. The edge stays in the policy and the decisions; what disappears is the retyping and the delay.
Which is why the policy is per micro-market and per station, with exceptions written out. If those differences live today in one person’s head, writing them down is a value in itself: they survive a holiday and a personnel change.
From the source you already use, if you use one: the process consumes them, it does not create them. Without competitor prices the policy runs on costs and minimum margins; the positioning module switches on when a source exists.
When this is not the right solution
- Retail prices imposed entirely by a franchise brand: what remains is the cost update, still sensible but of smaller weight
- A few stations and one list a day: morning discipline will do, the automation will not pay back
- The expectation of automatic price changes without approval: we deliberately do not do that until the policy has matured in the decision register
A question for the next management meeting
At what time did today’s replacement cost reach our ERP, and how much had we sold before it got there?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- A written, executable pricing policy with versions and an owner
- Automatic list collection and ERP cost updates within minutes of publication
- Justified price proposals and approvals in Microsoft Teams
- Distribution to station systems and a complete decision register
- The margin board in Power BI, and a parallel run through two weeks of mornings
We need from you
- Access to producers’ price lists and a month of their history
- Your current pricing principles in any form, and a policy owner on the sales side
- Technical access to the ERP and the station price system
Stages
Discovery
Two weeks of mornings reconstructed from history: lists, timings, decisions, drifts against the policy
Rules
The pricing policy written as executable rules with exceptions, approved by sales
Build
Collectors, the ERP update, the proposal engine, approvals, distribution and the register
Parallel run
Two weeks: the robot proposes, the current process runs, differences discussed every morning
Go-live
Switch to approving the robot’s proposals, policy review after a month
A quick win. Effort depends on the number and form of producers’ lists and on the station price system’s interface; the pricing policy tends to be the biggest work, and the biggest value.
Wholesale went up four cents at 6:00. The stations sold the old way until 9:30, on the best morning of the week.
Send us a month of producers’ lists and your retail prices for the period. We return a morning-by-morning analysis: when costs actually reached decisions, how long executing the policy took, and which days cost the most.
See your pricing morning in numbersThe neighbouring process usually has the same problem
The biocomponent share is visible after every month, while it can still be steered.
See the solution Finance & accountingEvery station’s takings reconciled each morningTills, terminals, cash and the courier line up by themselves.
See the solution Finance & accountingFleet cards reconciled, anomalies visible at onceA fill-up 300 km off route stops waiting for month-end.
See the solution