Live SAP mirror and replenishment tool for a stationery retailer
A stationery and office-supplies retailer in Cyprus ran two shops and a warehouse on manual stock checks and the standard SAP reports. ZingZee mirrored SAP Business One to a cloud server and built replenishment and live reporting on the mirror, with SAP as the system of record.
Client A stationery and office-supplies retailer in Cyprus, trading from two shops and a main warehouse on SAP Business One.
At a glance
Two shops and one warehouse carrying 95,000 SKUs now run on one live mirror of SAP.
A stationery and office-supplies retailer in Cyprus, trading from two shops with a stockroom behind each and a main warehouse that holds the full range and serves offices and schools on account.
ZingZee was engaged to solve two problems at once: shop stockrooms that ran out because replenishment depended on a manual check, and a business the owners could only see through the reports their SAP system offered.
ZingZee mirrored the SAP Business One database to a cloud server on a live two-way sync and built the warehouse tool and the dashboard on the mirror, with a mobile app for both, leaving SAP as the system of record.
The stockrooms are now restocked from the main warehouse each morning from a pick list the system writes itself and confirms with one scan, and the owners see sales and slow stock live as the tills ring.
Outcomes
Replenishment confirmed with one scan per pick list, where every item had been scanned in by hand.
Stockroom replenishment from a half-day manual check per shop to under an hour from a pick list written overnight.
Stock-outs on fast-moving lines from around 8% to under 1%.
Around EUR 45,000 of cash released from slow stock in the first four months.
A new report or question answered the same day, from months and a fee per template.
Every sale in SAP reflected on the dashboard within 30 seconds, counted net of returns.
The challenge
The owners saw the business only through the reports that shipped with SAP, and the stock loop depended on manual checks.
The range runs to roughly 95,000 SKUs, from pens and paper to office furniture. It is a trade of small margins on a long tail: most lines sell a few units a week at a low price, so a stock-out costs the whole basket rather than one item, and dated stock such as diaries loses its value within weeks of the new year. Demand peaks at the return to school and again at the year end. SAP Business One is the system of record for stock and sales.
Seeing the business
The owners had no financial oversight beyond the reports that shipped with SAP. Any question the standard reports could not answer meant a request to the SAP partner for a new template, which took months to arrive and was paid for on top. Daily numbers did not exist, and the owners learnt how a month had gone weeks after it ended.
One example shows the cost: the owners wanted to know which lines had sold in one shop but not the other over the previous quarter. SAP could report sales by item and stock by warehouse, but not the two together over a period, so the question went to the SAP partner. The answer arrived after the next quarter was half gone. By then the question had changed and the template was never run again.
The stock loop across three tiers
- The shop floor
- The shop floor was topped up from the stockroom behind it when a member of staff saw a gap on the shelf, often hours after the last unit sold.
- The stockroom check
- A member of staff walked the stockroom with a printed list and wrote down every line that looked low. It took around half a day per shop and happened when someone had time, typically once or twice a week.
- The request to the main warehouse
- The request went to the main warehouse as a written list. The warehouse picked it the following morning, which took two to three hours because the list was in no useful order for aisles laid out by supplier.
- Receiving
- Receiving was the longest step. Every item on the delivery was scanned into the shop's stock one unit at a time, around 200 scans on a typical run, and the receiving staff lost most of a day to it.
- The SAP transfer
- The transfer was posted in SAP only after the scanning finished, so SAP's stock figure for each shop trailed the physical move by up to a day.
From a line running low to the same line back on the shelf took two to four days, and a customer who wanted a pen today bought the whole basket elsewhere.
The consequences
The manual loop and the missing numbers carried a cost across the business.
- 01
Nobody could say which lines were selling and which were not, so purchase orders were placed on habit and the main warehouse filled with stock that did not move.
- 02
Cash sat in slow stock for years because no report identified it.
- 03
The owners could not see that the two shops were growing at different rates until the month's reports were run.
- 04
A line running low took two to four days to get back on the shelf, and the customer bought the whole basket elsewhere in the meantime.
- 05
A question the standard reports could not answer took months and a fee, and was often out of date by the time it was answered.
ZingZee continues to run the platform for the retailer and will extend it as the online shop goes live.
Replenishment confirmed with one scan per pick list, where every item had been scanned in by hand.
The solution
SAP Business One stayed as the system of record, and ZingZee built everything else on a mirror of its database.
The mirror is a copy of the SAP database on a cloud server, kept in step by a two-way sync that runs every 30 seconds, so the mirror is never more than half a minute behind the tills and a stock transfer confirmed in the app is back in SAP on the next cycle.
The sync and the mirror
The sync worker reads more than twenty SAP tables through a read-only database user over an encrypted connection. Sales and stock levels refresh on the 30-second cycle, and each night the worker verifies the whole mirror against SAP and repairs any row that has drifted. The dashboard never connects to SAP directly, so a fault in our software cannot reach the client's accounting system. The stock count on a phone in the aisle is the count SAP holds, half a minute old at most, without a query touching the SAP server.
The replenishment engine
Target levels set from sales
For every line in each shop, the tool sets a target level from what that shop has sold and restocked over the preceding weeks and recalculates it every night. The target is the highest stock level the shop held for two or more consecutive days, so a one-day delivery spike does not inflate it, and a line that sells out keeps its target so it stays on the list. Staff can override any line, and a group-level dial tightens the trigger for a whole category ahead of the school term. Each stockroom is held at the level its own sales justify.
The pick list
The tool compares each stockroom against its targets from the live mirror and writes a pick list for the main warehouse grouped by supplier, in the order the aisles are walked. The list filters by supplier or product group, exports as a PDF or a spreadsheet, and is produced as a report at 07:00. The warehouse starts picking at opening time from a list nobody had to write.
The one-scan receive
The warehouse picks the list, the stockroom receives it, and one scan of the list confirms the whole transfer and posts it to SAP through the sync. The shop's stock figure is right on the next cycle, and the receiving staff are back on the shop floor within the hour.
Short picks and returns
When the warehouse has less of a line than the list asks for, the picker records the quantity that moved and the shortfall stays on the next morning's list. A customer return goes back into the shop's stock within 30 seconds and the sale is netted off.
Anomalies
Lines whose stock sits well above target, or has not moved despite sales, are listed separately so a stock error is caught on the day rather than at the year-end count.
Overselling protection
A short stock hold is placed on a unit while a sale is being completed, so the same unit cannot be sold twice through two channels.
Live business oversight
An AI dashboard sits over the mirror. Takings by shop, margin, returns and best sellers update within 30 seconds of the sale, and sales are counted net of returns. Sales are split by channel, the shops as cash trade and the main warehouse as sales on account, so a large trade order does not hide a quiet day on the shop floor.
The dashboard is ready for the owners at 09:00 with yesterday's takings by shop against the same day last year, the month to date against last year, returns and margin, a strip of lines close to running out, and the morning's pick list already waiting for the warehouse. The month is known on the morning of the first.
Anyone with access can put a question to the data in plain language and get the answer the same day, without a template or a fee. The assistant has more than 40 analysis tools covering sales, stock, customers, suppliers and replenishment, and gives the SAP source for every number it returns. It builds a report on any synced data as an on-screen table or as a branded PDF of up to 20 sections, with a spreadsheet export on every view. The question that once took a quarter is now asked in a sentence and answered in under a minute.
Access is by role. Owners see cost and margin, operators see quantities and sales without them, and the server strips the financial fields before the page is sent. A warehouse supervisor can be given the pick list and the stock pages without seeing the margin on a single line.
Ordering data and slow stock
Ordering data
A view of what is selling and what is not, by line and by supplier for each shop, so purchase orders are placed on sales rather than habit.
Slow stock
Lines with no sale in 90 days, or selling well below their stock cover, are listed with their cost value and refreshed nightly, so the owners move them to the front of the shop or discount them and release the cash. Dated stock reaches the list in January, before it would otherwise be found unsold on the shelf in March.
The mobile app
The pick list, the scan, the dashboard and the slow-stock view all run on a phone. The replenishment pages were rebuilt for a phone screen after the first weeks showed the warehouse team read the list on a handset in the aisles. The warehouse confirms a transfer without going back to the office.
SAP was not modified, and the mirror and the app run on a cloud server ZingZee manages.
What was hard
- 01
Finding what changed among 95,000 items every 30 seconds.
SAP's stock table records the date a row last changed, not the time, so the sync could not tell which rows had moved in the last cycle without reading all of them. We split each table into buckets and keep a digest of every bucket on the mirror. Each cycle compares digests and reads only the buckets that differ. The cycle held at 30 seconds through the return-to-school peak.
- 02
Verifying 13 million invoice lines overnight.
The nightly check of the mirror against SAP overran its window on the largest tables. We gave each table a time budget and scan the big tables in ranges by transaction number, so every night makes progress from where the last one stopped. A row that drifts is repaired within two nights, and the dashboard marks a figure that has not been verified.
- 03
Holding stock the tills cannot see.
A hold placed on the mirror while a trade order is being completed is invisible to SAP, and a till sale in the 30 seconds between cycles could sell the held unit. We hold against the mirror's sellable quantity and re-check it on the next cycle before the order is confirmed. A hold expires after fifteen minutes.
How it was delivered
The work ran in four phases over four months, from a demo in May 2026 to a platform the client's team used daily by July.
- 01
The demo.
ZingZee took read-only access to a copy of the SAP data and built a working pick list and a question-answering assistant against it in three weeks. The owners saw their own stock and sales in the demo, and commissioned the build.
- 02
The cloud server and the sync.
A hardened server was provisioned and the SAP partner opened one firewall rule for it. The sync worker ran for two weeks against the live system before anything was built on top, and the nightly verification was added after the first full runs showed where SAP and the mirror could drift.
- 03
The dashboard and the replenishment tool.
The demo was rebuilt from scratch for production: a mobile-first front end, multi-user login with roles, the audit log, the report engine and the replenishment model agreed with the owners on weekly calls.
- 04
The security gate.
Before the client was given a login, an independent reviewer audited the server and the data path: one open port, key-only access, every service bound to the server itself, a read-only SAP user with forced encryption, rate-limited logins, and financial fields stripped on the server. The findings that remained, a stable address for the platform and the owners' accounts, were fixed the same week and checked again.
SAP kept everything it already did: the item master, pricing, invoicing at the tills, purchase orders and the ledger the accountant works from. The platform reads all of it and writes back only the stock transfers the warehouse confirms, so there was no downtime for the client at any point in the build and the tills never stopped.
The dashboard went live first alongside the manual check, so the owners could compare the two. When the two agreed for a fortnight the manual check was dropped, and the one-scan receive replaced the item-by-item scan on the next delivery. Each deliverable came with 30 days of aftercare, and the two requests the owners made in that period, a supplier filter and the phone layout, shipped within a day of the call.
The results
The retailer runs its stockrooms from the morning pick list and its trading from the dashboard.
Target levels, the pick list, the transfer posting to SAP, the daily numbers and the slow-stock list now run without anyone in the office setting them up.
The retailer was ZingZee's first paying client, and the platform has run in production since July 2026.
What's next
Purchase orders will be proposed from the ordering data, so a supplier order is drafted when a line is forecast to run out before the next delivery. The same stock data will feed an online shop, already in build, with the overselling protection in place and orders written back into SAP. The mirror and the dashboard can run for any retailer on SAP Business One with the same shape.
