SAP Business One integration
Real SAP documents for every business event, posted exactly once and reversible.
CertiPOS treats SAP Business One as the book of record. Every ticket becomes an A/R Invoice and an Incoming Payment; every return a credit memo and an outgoing payment; every count, receipt and transfer an inventory document. All of it goes through the Service Layer, never the DI API, never the company schema.
WORKS WITH
SAP Business One10.0
DatabaseHANA or SQL Server
InterfaceService Layer, pooled sessions
Fieldsprovisioned once from the portal
Posting modeper ticket, or daily roll-up
Documents
What posts, and what reverses it.
| Business event | SAP documents | Reversal |
|---|---|---|
| Cash sale | A/R Invoice, Incoming Payment (one per cash currency) | Credit memo based on the invoice, payment cancelled |
| Return or exchange | A/R Credit Memo based on the invoice, Outgoing Payment | Mirrored documents |
| Deposit or down payment | A/R Down Payment Invoice, Incoming Payment | Credit memo, payment cancelled |
| On account | A/R Invoice open on the business partner | Credit memo |
| Cash in / out, over / short, tip payout | Journal entries and payments on the mapped accounts | Journal cancelled |
| Foreign cash | Payment in the tendered currency, exchange journal through a clearing account | Journal cancelled first |
| Gift cards, store credit, loyalty | Item line for the sale; transfer means on the liability accounts; accrual and expiry journals | Mirrored |
| Receipts, issues, transfers, counts | Goods Receipt, Goods Issue, Inventory Transfer or Request, Inventory Counting | Mirrored by a second document when Cancel is refused |
| Orders and deliveries | Sales Order, Delivery Note, invoice based on the order drawing the down payment | Cancelled or closed |
| Daily roll-up | One invoice and payment per company and day; ticket detail in @CP_TICKETS / @CP_TICKETLINES | Credit memo |
How it stays correct
The posting engine is built for the days SAP is slow, down or strict.
Exactly onceEvery ticket and every mutating event carries a client ULID; every posting job and chained follow-up has its own idempotency key. A retry can never create a second invoice.
Chained and crash-safeThe invoice posts, its DocEntry is persisted, then the payment posts based on it. A crash between the two resumes at the right step.
Readable failuresThe raw payload, SAP’s answer and the timing sit on the job; SAP errors map to a catalogue code with a next action; parked jobs raise an alert.
Fields and tables provisionedUser-defined fields for the ticket, register, promotion and coupon, and the roll-up tables, are added by a portal action; an existing definition is never changed.
Master data in both directionsItems, prices, barcodes, units, partners, price lists, tax codes, accounts, serials and rates sync by delta every minute and in full daily; SAP events arrive by polling or a signed webhook.
Signed off liveEvery posting flow is accepted only after a real document posted to a live company and was reversed. Mock SAP is never used as evidence.
Reaching SAP
The server reaches the Service Layer directly, or through the Connect Agent.
DirectThe CertiPOS server sits where it can reach the Service Layer: next to SAP on your LAN, or on a VM with a route to it. Sessions are pooled per company and re-logged on expiry.
Connect AgentWhen the server is hosted elsewhere, the same binary runs in agent mode next to SAP, opens an outbound-only channel to the server, and relays the Service Layer calls. SAP is never exposed.