Retail POS and Store Operations Connector

Retail breaks at the till, not in the back office. At 18:40 on a Saturday the line at store 7 drops, the queue keeps growing, and nobody in that shop cares that SAP Business One is running perfectly in the data centre. The next morning a manager re-keys yesterday's takings into a summary A/R Invoice, the cash in the safe does not match the tape, and the head-office stock figure for store 7 has been wrong since Thursday.

SAP Business One is a genuinely strong retail back office. It owns the item master, price lists, warehouses, business partners, costing and the general ledger. What it does not ship is a shop floor. There is no shift, no cash drawer, no float, no X or Z reading, no tender breakdown, no offline queue, and no structured way to prove that what the till says it took is what the bank received and what the G/L shows. Most chains bridge that gap with a nightly CSV, a spreadsheet and trust. That works until month end, or until one branch is quietly short every week and nobody can prove where the money went.

The Retail POS and Store Operations Connector is the layer that closes that gap. ECOSIRE builds it for your estate — your tender types, your chart of accounts, your branch structure, your till hardware — as an SAP Business One add-on and integration service. Nothing here is a ready-made download. We scope it, quote it, build it, and install it into your test company database before it goes anywhere near production.

Offline-tolerant transaction capture

Every till writes to a local durable queue first and to SAP Business One second. Each transaction carries an idempotency key made of store, terminal, shift and sequence, so when the connection returns the replay is exactly-once: a reconnect can never post the same sale twice, and a half-acknowledged batch resumes from the last confirmed record rather than the start.

Sales replay into SAP Business One through the Service Layer as A/R Invoices, A/R Credit Memos and Incoming Payments, or as Sales Orders and Deliveries where you want a picking step. Line-level detail is preserved — item, UoM, batch or serial where the item is managed that way, discount source, sales employee and store dimension — so nothing is flattened into a single daily journal line that finance cannot drill into. Documents that are rejected by SAP Business One validation land in an operator queue with the exact Service Layer error, not in a log file nobody reads.

Shift, cash-up and till reconciliation

A shift becomes a real object in SAP Business One, implemented as a User-Defined Object with its own authorisations. It records the opening float, mid-shift pick-ups and drops, the declared close by tender, and the X and Z readings. Once posted, the shift record is locked; corrections are made by a documented adjustment that keeps its own audit line, never by editing history.

The declared cash-up is reconciled against the system-calculated take per tender: cash, each card acquirer, wallets, vouchers, gift cards and store credit. Tender totals post as Incoming Payments against the correct store cash account and acquirer clearing accounts, so bank reconciliation matches settlement files rather than a lump sum. Any difference posts as a Journal Entry to a configurable over/short account with the reason captured on a User-Defined Field, and variances above your threshold route through an SAP Business One Approval Procedure before the shift can close.

Store stock the back office can trust

Stores are modelled as real warehouses, optionally with bin locations, so store stock lives in the same valuation and costing model as the distribution centre. Replenishment runs as Inventory Transfer Requests and Inventory Transfers with an in-transit warehouse, so goods that have left the DC but not yet been received at the branch are visible instead of missing. Store counts post through Inventory Counting documents and generate proper recount and difference postings rather than blind Goods Receipts and Goods Issues, which is what makes shrinkage analysis meaningful. Returns and exchanges are linked to the original document through the standard base-document reference, so a credit reverses the correct batch, serial and cost layer.

Pricing, promotions and customers

Head office keeps control of price. Price Lists, Special Prices, discount groups and period-and-volume discounts are pushed down to each terminal on an effective-date calendar, so a promotion starts when the store opens rather than whenever the sync last ran, and ends without anyone touching a till. Item master, barcodes, multi-barcode items, UoM groups and Business Partner Catalogue Numbers sync in the same channel.

Customers are identified at the till against Business Partners, with on-the-fly creation for new walk-ins under a numbering series you control. Loyalty accrual and redemption run on a ledger held in a User-Defined Table and post into SAP Business One as a discount line or A/R Credit Memo, so the liability is visible in the accounts instead of living only in the POS.

Multi-store control

Every document is stamped with store and cashier using Profit Centres or Dimensions and Sales Employees, so branch P&L, cashier performance, hourly take and basket analysis come out of standard SAP Business One reporting and query tools rather than a separate BI silo. A Crystal Reports pack ships with the build: Z-report, daily banking sheet, store stock ledger, transfer manifest and variance-by-store summary, printable from the SAP Business One client and from the store.

Who this is for

Multi-branch retailers, franchise operators and hybrid wholesale-retail businesses already running SAP Business One 10.0 who have more than one selling location, real cash handling, and a finance team that has to reconcile both. It is equally relevant to a single flagship store with high transaction volume where offline tolerance and shift discipline matter more than branch count.

How delivery works

1. Scoping call. We walk through your tender types, acquirers, chart of accounts, warehouse and branch structure, till hardware and peripherals, and the specific reconciliation your finance team needs. We ask for a copy of your document numbering and approval rules. 2. Fixed quote. You receive a written scope with the exact objects to be built, the reports included, the integration boundaries, the price and the lead time. Nothing starts until you approve it. 3. Build. Typically two to four weeks. We build against the Service Layer and DI API, define the UDFs, UDTs and UDOs, and develop on a copy of your data structures where you can share one. 4. Install in test. Deployment into your SAP Business One test company database, followed by a UAT window with a written test script covering offline replay, shift close, variance approval and transfer flows. 5. Install in production. A scheduled cutover with a documented rollback, run outside trading hours, followed by a supervised first cash-up. 6. Support. A 90-day defect warranty is included, with an optional ongoing support agreement afterwards.

What this deliberately does not do

This is a connector and store-operations layer, not a claim that we replace your till hardware or your card acquirer. Card authorisation stays with your payment terminal and acquirer; we consume the settlement result. We do not resell third-party POS software. And we do not pretend the product already exists on a shelf — it is built for your configuration after you approve a quote.