ERP-integrated customer ordering platform for a wholesale distributor
A wholesale distributor in Cyprus took orders by email, chat, attachment, and photo, keyed each line into its ERP, and checked stock in two systems. ZingZee integrated the warehouse system, the sales tool, and a new ordering platform, so one stock figure serves every channel.
Client A wholesale distributor in Cyprus importing branded food, drink, toiletry and household lines from the United Kingdom and mainland Europe.
At a glance
The distributor ran an ERP and a warehouse system that showed two different stock figures, and ZingZee built one ordering platform between them.
A wholesale distributor in Cyprus that imports branded food, drink, toiletry and household lines from suppliers in the United Kingdom and mainland Europe and sells them across the island to supermarket chains, cash and carry outlets, independent grocers and other wholesalers.
The engagement was to put the distributor's customer ordering on one system.
The distributor imports branded grocery and household lines by the container and sells them on a margin of a few cents a unit, so an order keyed wrongly, or a promise made on stock already sold, costs more than the line earned.
An ordering platform that reads live stock from the warehouse system, reads customers, prices and pending orders from the ERP, computes one availability figure, and writes each order back into the ERP as a structured record, where the link that already existed carries it to the warehouse for picking.
Outcomes
One availability figure for every product, live warehouse stock less orders still awaiting approval, where the two systems had shown two numbers.
Orders placed in the app, by scan or photograph, by dropping a PDF or spreadsheet, or by email all reach the ERP as structured lines with no re-keying.
A customer with an agreed price orders without waiting; only a line with no agreed price, or a queried price, stops for the owner's decision.
Out-of-stock lines are held on the order and released for picking when the goods are received, with the in-stock quantity shipped in the meantime.
Every product a customer asked for that the distributor did not hold is recorded in a demand pool and matched against incoming stock.
Supplier offers arriving by email are assessed against the last price paid, the stock on hand, the sales rate and the margin before the reply goes.
The challenge
Orders arrived by email, attachment, photograph and telephone, none of them structured, and the two systems showed two different stock figures.
Goods arrive by the container and leave by the pallet, the layer or the carton, and the margin on a unit is measured in cents, so the business earns on volume and on accuracy. An ERP holds the products, customers, price lists, orders and invoicing, and a separate warehouse management system holds the physical stock by location, with expiry dates and pallet configuration. The two are joined by database interfaces set up years ago. The owner runs purchasing and pricing himself, and a sales team takes the orders.
Its situation is the common one in wholesale distribution: the ordering channel, the ERP and the warehouse each kept their own count, and the sales side wrote orders against whichever count it could see.
The order desk
A supermarket buyer emailed a PDF purchase order with the buyer's own prices typed on it. A cash and carry sent a spreadsheet. A grocer wrote the order on a sheet of paper, photographed it and sent the picture over WhatsApp, or telephoned a sales rep who wrote it down again. Each of these was read by a person and keyed into the ERP line by line, and a 20-line order carried 20 chances of a wrong product code, a wrong quantity or a wrong pack size. The owner's own summary of what he wanted from a new system was that he did not want to make any more mistakes.
Customer pricing was held by the owner alone. Each customer had its own price for each product, set on relationship and volume, and the ERP held only the list price, so a rep quoting from the list was often wrong and an order from a customer with no agreed price waited until the owner had looked at it. Customers put their own price on their purchase orders, and the negotiation ran back and forth by email until both sides agreed, order by order and line by line. A supplier price rise reached the selling price only when someone remembered it. A product bought at EUR 2.00 at the start of the year and rebought at EUR 2.50 in the summer was still being sold on the old price, and on a margin of cents that meant selling below cost with nobody noticing.
Stock questions came by phone. Before confirming an order a rep asked the office whether the product was there, the office looked in one system and then the other, and the answer depended on which screen was open. Supplier offers were judged from memory of what was paid last time, and the reply was typed by hand. The owner described the email side of the business as a headache, and everything, from orders to offers to price disputes, ran through it.
The warehouse
The distributor ran two systems that each held part of the record. The ERP held the master data, the customer orders and the invoices. The warehouse management system held the physical stock by location, with expiry dates and pallet configuration, and it was the only place the live count existed. The two were connected by database interfaces installed years ago: an approved order in the ERP flowed to the warehouse for picking, and the warehouse replied when the pick was complete so the ERP could raise the invoice. Nothing else passed between them, neither system offered an API, and the warehouse software had not been updated in over a year.
The two systems therefore showed two different stock figures. The warehouse system showed what was physically on the racks and the floor: two pallets of 130 cases and 62 cases in the picking location, 322 cases in all. The ERP showed a figure net of every order it held, including orders still waiting for the customer to approve a price or a waybill, and for a busy line it displayed a negative quantity that nobody could explain from the screen. The owner used the warehouse figure to check expiry dates and palletisation and did not trust it for selling, because it knew nothing about the orders still pending. He used the ERP figure for selling and did not trust that either, because it lagged the warehouse. His own diagnosis was that the pending orders were the one thing making the software inaccurate.
Inbound stock added a third lag. A purchase order was entered in the ERP, the container was received in the warehouse by scanner over several days, and the ERP was not updated until receiving was complete, so goods physically on the floor were invisible to the sales side for days. Expected and received quantities differed by a case or a kilo, and only the warehouse knew which figure was right.
The consequences
Two stock counts and a hand-keyed order desk cost the distributor in sales, in margin and in the owner's time.
At the order desk
- 01
Order entry took a person's time for every order, so the number of orders the business could take in a day was capped by the hours available to key them.
- 02
Orders were confirmed against stock already promised to another customer, and the shortfall was discovered at picking, or when the customer rang to ask where the rest of the delivery was.
- 03
A customer who asked for a product the distributor did not stock was told no, and nobody recorded that the demand existed.
- 04
Price approvals held orders for hours or days, and a customer who waited a week for a price sometimes found the stock had gone in the meantime.
- 05
Two people in the same office could quote the same customer two different prices for the same product on the same day.
- 06
The owner was the bottleneck on every price, every offer and every exception, and the business slowed to a stop whenever he was away from his desk.
In the warehouse
- 01
A rep could sell 200 cases the warehouse showed but the ERP had already allocated, or refuse an order for cases the ERP showed as negative that were sitting on the floor.
- 02
Stock that had landed but not been fully received could not be sold for days, on lines where the margin depended on turning the container quickly.
- 03
Nobody could tell a customer that a product was on the way, so the customer bought it from another importer.
- 04
Back-orders lived in memory and in email, and a short shipment was usually found by the customer before it was found by the office.
- 05
The servers running both systems were beyond their vendor's support, which ruled out installing anything new on them.
The distributor now sells from one availability figure, and the ERP remains the system of record.
One availability figure for every product, live warehouse stock less orders still awaiting approval, where the two systems had shown two numbers.
The solution
ZingZee kept both existing systems and built the platform between them.
The ERP remains the system of record for products, customers, prices, orders and invoices, and the warehouse system remains the record of what is on the shelf. The platform reads from both, computes one availability figure, prices the order and writes it into the ERP, where the existing link carries it to the warehouse for picking. ZingZee did not modify either system, and the platform writes to only one of them.
Integration and the ordering engine
One stock figure
The warehouse vendor built a live stock view for the platform over the locations the distributor chose, with the damaged and expired locations excluded. The platform reads that view, reads the ERP's orders still at pending status, and subtracts the second from the first. That result is the availability figure for every product on every channel. A rep confirming an order and a customer checking a shelf now read the same figure, and the call to the office to ask whether a line is there has no reason to happen.
Availability without quantities
Customers see whether a product is in stock, out of stock or on the way, never how many cases are held, so a competitor holding a customer login learns nothing about the distributor's position. The owner and the sales team see the full quantity, by location where the warehouse data supports it. The distributor can put the app in front of every customer, including those who also buy from its competitors, without disclosing its stock position.
The price engine
Every customer has its own price for every product, held per customer and applied without anyone's involvement when that customer orders. Prices are structured by customer category and product subcategory, with unit, carton and pallet prices on the products that carry them. Under every price sits a floor anchored to the latest purchase cost of the product plus the distributor's minimum margin. A category change, such as five percent on all wholesalers, that took an afternoon of edits is now one action, and a supplier increase moves the floor the day the new cost is posted.
Ordering at the best price
Where a customer has an agreed price, the order goes through at that price with no one involved. Where a customer has none, or has queried the price and stated what it would pay, the platform holds that line and puts it in front of the owner with the customer's offer, the customer's last price, the current stock and the resulting margin on one screen, so a counter or an approval is one tap. Where he does not want one customer to take the whole holding of a line, he offers a smaller quantity and the remainder stays available for others. A held line is re-checked against stock at the moment it is approved. The owner now sees only the lines that need him, and an order on agreed prices reaches the warehouse without a decision from anyone.
The ERP write-back
Approved orders are written into the ERP through the ERP vendor's API as structured order records, through a reconciled queue, so a dropped connection cannot lose an order or post it twice. The ERP's existing link picks the order up, the warehouse picks the goods, and the reply comes back to the ERP for invoicing exactly as before. The order desk stopped keying: an order confirmed on the screen is in the ERP as it stands, with the codes, quantities and pack sizes the customer entered.
Procurement
Supplier offers arriving by email land in a procurement queue, where each offer is shown against the last price paid for that product, the stock on hand, the recent sales rate and the margin at the offered price. The owner counters or accepts, and the reply email is drafted for him. An offer is answered the same day with a counter based on the last invoice rather than a recollection of it, and an offer for a product customers have been asking for is flagged from the demand pool instead of missed.
The customer app and fulfilment rules
Customers order on a phone. The app runs in the browser, installs to the home screen and works on any handset, and every customer sees only its own catalogue, its own prices and its own order history.
Scan or photograph
A customer points the phone at a barcode and the product is on screen with the customer's price and its availability. Where there is no barcode to hand, or the barcode differs because the same product came from a different supplier, the customer photographs the product and image recognition matches it against the distributor's catalogue, asking for a confirmation when it is not sure. A buyer walking a stockroom builds a 40-line order without a laptop, and the codes on it are the distributor's own, so nothing is translated at the other end.
Browse, search or drop the file
The full catalogue is searchable, with images, pack details and the customer's price on every line. A customer who has already prepared a purchase order drags the PDF or the spreadsheet into the app, or photographs the handwritten list, and the platform builds the cart line by line, flagging any line that is out of stock before the customer submits. The customer's own purchase order becomes the distributor's order without being retyped, and a short line is settled before the order is placed.
Email as a channel
Orders that still arrive by email, with a PDF, a spreadsheet or a photograph attached, are read by the same parser and enter the same pipeline as app orders: priced, checked against stock and written to the ERP. An enquiry email asking whether a product is in stock is answered from the live figure. A customer who never opens the app is served from the same stock figure at the same price, and the order desk reads a matched order rather than an attachment.
Held lines and partial shipment
When an order includes a line that is out of stock, the in-stock lines and any in-stock quantity of the short line are released to the warehouse for picking and delivery, and the shortfall is held on the order rather than dropped. When the goods are received into the warehouse, the held quantity is released for picking without anyone re-entering it, and the customer is told the balance is on its way. A short line is a delayed delivery instead of a lost sale, and the warehouse picks the balance from the order that was already there rather than from a reminder.
The demand pool
Everything a customer scans, searches for or requests that the distributor does not stock is recorded, de-duplicated and ranked by how often it is asked for. Incoming stock is matched against the pool as it is received. Purchasing sees which products customers wanted and did not get, in order, instead of hearing about them by chance.
The dashboard and the assistant
The distributor's own view shows orders, approvals, the demand pool, procurement and stock risk in one place, with the last price each customer paid for each product beside every quote. An assistant answers questions in plain language from the live data, such as what a customer is charged for a product or what was sold yesterday, and applies a price change on instruction after a confirmation step. A question that took a search across two systems and an email thread is answered from one screen or one sentence.
How it was delivered
- 01
Discovery.
The platform depends on data held by two vendors, so ZingZee obtained the product catalogue and stock lists, mapped where each fact lived, and confirmed with both vendors which system was authoritative for what.
- 02
The app and the dashboard.
The customer app and the owner's dashboard were built next, against the real catalogue, so the distributor could walk through the ordering flow on a phone before either integration was connected.
- 03
Integration.
The integration approach was settled on a single call with the distributor and both vendors. Orders are written to the ERP only, through the ERP vendor's API under a signed agreement, and the warehouse system picks them up through the interface it has always used. The warehouse is never written to by the platform. Live stock is read from a view the warehouse vendor built for the purpose, over a read-only database connection, and pending orders are read from the ERP. The availability rule, live warehouse stock less ERP orders still pending, was agreed in the same conversation, with the distributor deciding which locations count and what customers may see. No interface that existed before the build was changed.
- 04
Go-live and aftercare.
Go-live with a month of aftercare closed the build.
The data rules were set before any screen was designed. The customer-facing system never holds a purchase cost, so no configuration error can expose a margin. Every query is scoped to the customer making it. The platform keeps its own copy of the catalogue, prices and stock, refreshed from the two sources, so the ordering app never queries the live ERP and the distributor's own systems are never slowed by customer traffic. An order submitted while the connection is down is queued on the device and posted when it returns.
The platform runs on a new Linux server on the distributor's own network, alongside the existing servers, which were left as they were, and it can be lifted to cloud hosting without a rebuild if the hardware becomes the limit. It holds what neither existing system had: the availability figure, the per-customer price history, the approvals, the demand pool and the customer's own view of its orders.
What was hard
Three problems took longer than the screens did.
- 01
Which pending orders to subtract.
An approved order is deducted from the warehouse count when it is picked, not when it is approved. Subtracting every open order from the warehouse figure double-counted the ones already picked; subtracting only pending ones missed approved orders waiting for a pick. The fix reads the warehouse's own pick status alongside the ERP status and subtracts an order only until the warehouse reports it picked, refreshing every minute, with a short reservation held on the platform while a customer is in checkout so two customers cannot both take the last pallet.
- 02
Recognising a product from a shelf photograph.
The catalogue images are packshots on white; a customer's photograph is a shelf under strip lighting, at an angle, with the neighbouring product in frame. Matching on the image alone put the wrong product in the cart too often to be used unchecked. The platform now indexes the packshots and every customer-confirmed photograph, reads the text on the pack as a second signal, and puts a match below the confidence threshold to the customer as a question rather than into the cart.
- 03
What a partial shipment is allowed to be.
A customer who ordered a pallet does not always want 60 cases, and a pallet price does not apply to 60 cases. The rules were settled with the distributor: short shipment is the default, a customer or a line can be marked full-quantity-only, the price break of the ordered quantity is kept for the held balance, and held lines are released in the order the original orders were placed.
The results
The distributor sells from one availability figure, and an order placed on a phone at a customer's shelf reaches the warehouse as a pick list without passing through the office.
Availability, per-customer pricing, the write-back to the ERP, the release of held lines and the demand pool now run without anyone in the office setting them up.
The ERP remains the system of record.
What's next
The next phase adds the tools the owner asked for on the purchasing side. Product weights derived from the pack descriptions will feed a container planning tool that shows how a proposed order fills a container and what the freight is likely to cost, drawn from the quotes already in the inbox. Stock on the water will appear to customers as a pending basket they can order against, so a product that is three weeks away is a sale rather than a refusal. Requests for quotation across suppliers, with a comparison of their prices, will move onto the same platform behind the distributor's own network. The same platform can sit between any ERP and any warehouse system with this shape, reading from both and writing orders to one.
