Celeste library
How the ERP and the storefront should actually talk
Native connector, middleware, iPaaS or a decoupled build. Each page here takes one architectural decision and works it through with real sync behaviour, real failure modes and the point at which the cheap option stops being cheap.
Where should a B2B price be calculated: in the ERP, in the storefront, in middleware, or at request time?
In exactly one place, and for a distributor running Acumatica or Cin7 that place is normally the ERP, because the ERP holds the contract. The real choice is between pushing ERP-calculated prices into platform price lists on a schedule, which is what the native Acumatica connectors do, and asking the ERP at the moment the page renders, which buys correctness and spends page speed, cache complexity and a hard dependency on the ERP being awake.Batch sync or read live from the ERP: which one should your B2B storefront do?
Decide it field by field rather than for the whole integration. Product content and images belong in a batch sync because they change slowly and the storefront needs them for search and rendering; stock and credit position usually want a read-through or a very short cycle, because Cin7 Core’s documented sync cadence and Acumatica’s scheduled connector runs both mean a batched number is old by the time a buyer reads it.One ERP, many storefronts: where does the shared layer stop?
Three architectures serve several storefronts from one ERP: point-to-point, a shared commerce layer, and a copy of the data per brand. They differ in one number, which is what the fourth storefront costs given the first three exist. On Acumatica the ERP stops being able to tell the storefronts apart at the item, because entity mapping filters work per store on stock items and a template item pushes every child to every store it reaches.What should the storefront do when the ERP is unreachable?
Decide four things before launch and write them down: what price the storefront shows, what availability it claims, what it does about credit, and whether it can still take an order. The only one with a single correct answer is the last, because an order the storefront accepts and cannot store is revenue you have destroyed, so order capture queues and everything else degrades to a stated fallback.