The diagram that keeps failing
The diagram looks reasonable. Storefront asks ERP for a price. ERP returns the price. Storefront renders it. Accurate by definition, the architects say, and the room agrees because nobody wants to argue against accuracy.
The diagram fails at three predictable points. Concurrency, because the ERP was sized for a finance team and an order entry desk, not for a category page with two hundred SKUs. Latency, because the ERP pricing engine was never built to answer in eighty milliseconds. And failure mode, because when the ERP is slow the storefront is slow, and when the ERP is down the storefront is down.
A hybrid model, in plain terms
The pattern that holds up looks like this. The ERP remains the source of truth for the price. A pricing service sits in front of the storefront and holds a denormalised view of the contract prices for each customer or customer group. That view is updated by the ERP on a schedule and on event, not pulled on demand.
The storefront reads from the pricing service. The pricing service reads from a cache that is warmed from the ERP and invalidated by events. When the storefront needs an answer the ERP would refuse to give in time, the pricing service gives it from the cache and logs the gap for reconciliation.
This is not novel. It is the same pattern that retail learned in the early 2000s with stock. The only reason it is still controversial in B2B is that the ERP team rarely owns the storefront and the storefront team rarely owns the integration. The pattern requires one team to own the seam.
"Your ERP is a system of record. Treat it like a high-concurrency web service and it will eventually decline the invitation."
The SAP and Dynamics specifics
On SAP, the right hook is usually the condition technique with a middleware that listens for changes to the relevant condition records. S/4HANA helps, ECC is workable. The mistake is to expose the pricing BAPI directly to the storefront. It works in testing and degrades under real load in ways that are hard to model.
On Dynamics 365 Finance and Operations, the data entities are reasonable and the event framework is usable. The pitfall is the trade-agreement journal, which is rarely posted on the schedule the storefront needs. Plan for a reconciliation job that catches the gap and a clear ownership rule for who fixes the price when the journal and the cache disagree.
What to measure, and who should care
Two numbers matter. The pricing accuracy rate, measured by sampling completed orders against the ERP price at the moment of order placement. And the pricing service latency at the ninety-fifth percentile, measured at the storefront, not in the middleware.
The first number belongs to finance. The second belongs to engineering. If only one team owns both, the integration drifts. In larger organisations the most useful artefact is a monthly pricing reconciliation report that both teams sign. It is unglamorous and it prevents most of the arguments.
