POS and ERP
POS to ERP: sales, stock and prices kept in step
Sales and returns posted from every store, stock and price changes sent back, and end-of-day totals reconciled.
Blueprint
Scroll sideways to see the whole drawing.
POS to ERP: every sale posted once
Sales flow from the tills to the ERP as events, and prices and stock flow back. A store that goes offline keeps selling and catches up. A posting that fails is retried, then handed to a person.
- Primary flow
- Asynchronous
- Exception path
The flow, step by step
- From POS terminals to Store or POS cloud server: Sales, returns and voids (primary flow).
- From Store or POS cloud server to Integration layer: Sales events and end-of-day totals, through an event queue, over REST/JSON (asynchronous).
- From Integration layer to ERP: Sales and stock movements posted, over OData · REST/JSON (primary flow).
- From ERP to Integration layer: Prices, promotions and item data, by API or file export, over REST/JSON (primary flow).
- From Integration layer to Store or POS cloud server: Price and stock updates, over REST/JSON (primary flow).
- From Integration layer to Retry queue: Posting failed (exception path).
- From Retry queue to Integration layer: Retried (exception path).
- From Retry queue to Store operations team: Still failing: alert with the details (exception path).
Overview
This is the flow between the tills in your stores and the ERP behind them. Sales, returns and voids travel up to the ERP. Prices, promotions, item data and stock travel back down. When the two drift apart, stores sell at the wrong price, stock figures stop being trusted and finance spends the month-end reconciling.
The reference design sends every store transaction as an event through an integration layer with a queue. The layer maps each event to the ERP’s sales and inventory documents and posts it exactly once. In the other direction, changes in the ERP are sent to the stores that need them, so every till works from the same data.
Stores lose their connection, and the design expects it. The store or POS cloud server keeps selling and catches up when the line returns. A posting that fails is retried, and one that keeps failing is handed to a person with the details, rather than disappearing.
How the flow works
- 01
Sell at the till
Each sale, return and void is recorded on the POS terminal with a unique identifier, the store, the till and the time.
- 02
Hold at the store
The store or POS cloud server collects the transactions and sends them on as events, holding them safely while the store is offline.
- 03
Post to the ERP
The integration layer maps each event to sales and stock movements and posts it to the ERP, checking its identifier so nothing is posted twice.
- 04
Send prices and items
Item data, prices and promotions are published from the ERP when they change, with the date and stores each change applies to.
- 05
Update every store
The layer delivers each change to the stores it applies to, and records which stores have confirmed it.
When something fails
A posting fails
Temporary faults are retried with increasing delays. A posting that still fails goes to a dead-letter queue, and the store operations team is alerted with the transaction and the error.
A store goes offline
The store keeps trading on its local data. Transactions are held and sent in order when the connection returns, and a store that stays silent too long raises an alert.
A transaction arrives twice
Every transaction carries a unique identifier. The layer recognises a repeat and ignores it, so a resend after an outage never doubles a sale.
Store and ERP totals differ
End-of-day totals from each store are compared with what the ERP received. A difference opens a review with the missing or extra transactions listed.
Standards and systems
- Data and analytics
- Apache Kafka
- ERP systems
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integration
- REST
- Webhooks
- RabbitMQ
Questions and answers
Should sales post in real time or in batches?
Usually as events close to real time, because stock and sales figures are then current during the day. Some ERPs or licences make frequent postings costly, so the layer can also group events into summaries per store and period. We choose with you based on what decisions need current data and what the ERP handles well.
Link to this questionHow are end-of-day totals reconciled?
Each store sends its end-of-day totals by payment type and department. The layer compares them with the transactions the ERP received for the same store and day. If they agree, the day is closed. If not, the review lists the missing or extra transactions, so your team can fix the cause instead of posting an adjustment.
Link to this questionCan promotions and price changes be scheduled in advance?
Yes. Each price or promotion change is sent with the date and the stores it applies to, ahead of time, so the tills switch at the right moment without anyone in the store acting on it. The layer records which stores confirmed the change, and flags any that did not.
Link to this questionHow do you roll this out across many stores?
We start with a pilot in a few stores and compare their totals with the current process every day. Once the totals agree, we roll out in groups, at a pace your store operations team can support. The old process stays available for each store until its new flow is proven.
Link to this questionWhich POS and ERP systems does this work with?
The design works with any POS that can export transactions through an API, events or files, and with ERPs such as SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central and Odoo. We confirm the interfaces of your specific POS and ERP at the start. Naming a product does not mean a partnership with its vendor.
Link to this questionWho deals with failed postings once it is live?
That is agreed before go-live. Usually your store operations or finance team handles business errors, such as an unknown item, from a review list, and the technical team handles faults in the flow itself. We can provide that technical support as part of an ongoing agreement, with the runbook shared with your team.
Link to this questionTell us what you need to build or connect.
Describe the systems, the timeline and the constraints. The right engineers take it from there.
- Our team will call you within 24 hours during your preferred time slot
- Our team is available 24/7