A food manufacturer — 12 people, in-house warehouse, wholesale customers across Poland. Three systems describing the same reality in three different languages every single day. Four months later only two were left, quietly talking to each other in the background. The team got back twelve hours every week and document errors dropped by 70%.
Context: three systems from three different eras
The client manufactures food products under their own brand and as a private label for retail chains. The team is twelve people — three sales reps, an order desk, the warehouse manager, accounting and production. We started working together in mid-2025 after a referral from a packaging supplier we had helped a year earlier on a similar integration.
What we found was the typical SME setup we have been seeing for over a decade: Comarch Optima as the main ERP (invoicing, accounting stock, master data), a separate warehouse management system (barcode-based WMS, bought five years earlier for a specific tender) and a Google Sheet in which the order desk recorded orders from regular customers. Each of those three systems was correct in its own world. The problem started where one world ended and the next one began — i.e. on every order.
Starting point: 12 hours a week of manual re-entry
The daily routine looked like this: an order came in by email or phone, the desk typed it into the Google Sheet. In the afternoon two people copied the orders from the sheet into Comarch Optima as reservation documents. They printed a list and walked it over to the warehouse. The warehouse operator entered the issues into the WMS. Once the goods went out, a note travelled back to the desk — by email or on a sticky note — and someone issued an invoice in Optima. The Optima stock level was refreshed twice a week, whenever someone got around to it.
The consequences were predictable. Orders vanished between the sheet and Optima — about two a week. Stock in Optima did not match the physical shelves, so sales reps promised customers goods that were not there. Invoices went out late, sometimes to the wrong address, because the customer record in the sheet was not the customer record in Optima. Resolving complaints meant cross-referencing three systems and an email archive.
We measured this before starting the work. The team was losing about 12 hours a week to manual re-entry and error correction. Faulty documents (wrong quantity, wrong customer, wrong SKU) ran at around 80 a month on a baseline volume of 1,200 orders.
What we considered and what we ruled out
The board's first instinct was "let's move everything to a single, modern system". We costed that scenario: migrating away from Optima meant three months of accounting work, the risk of losing document history (Comarch stores data in a specific format) and tens of thousands of zlotys for a new ERP licence that nobody on the team knew. We talked them out of it.
The second option was iPaaS — Make (formerly Integromat) or Zapier. That works well for simple flows, but Comarch Optima has no native connector, and we needed two-way synchronisation with transactional guarantees — an order had to land in Optima in full or not at all, no in-between states. Make does not guarantee that.
We chose option three: a dedicated middleware written in .NET, running as a Windows service on the client's server, talking to Optima through the Comarch ERP XL/Optima API (BIS) and to the WMS through its REST API. We replaced the Google Sheet with a small order intake form integrated directly with the middleware.
Solution: how it works under the hood
Architecture at a glance:
Step by step
- Validates data
- Maps SKUs
- Retries on failure
- Logs every step
Flow: an order arrives through the form, the middleware validates it (does the customer exist? are the SKUs active? is the credit limit not exceeded?), creates a Customer Reservation document in Optima and a picking task in the WMS at the same time. The warehouse operator confirms the issue with a scanner, the WMS sends a message back to the middleware, which closes the reservation in Optima and issues an invoice.
Three technical decisions worth highlighting:
- Queue and retry. Optima can stall on long operations. The middleware never calls the API synchronously — everything goes through a queue with retry and exponential backoff. If Optima does not respond, the order waits, it does not disappear.
- SKU mapping. Wholesale customers use their own product codes. We built a simple mapping table — the sales rep sees the customer code, Optima and the WMS see the internal code.
- Audit log. Every state change of an order is stored with a timestamp, user and payload. Complaints that used to take 30 minutes of digging now resolve in 2.
Rollout: four months, one cut-over weekend
We worked iteratively. The first six weeks — analysis, process mapping, Optima integration on a test environment (the Comarch BIS API has a few quirks, like session limits and specific error codes you need to know). The next six weeks — WMS integration and the order intake form. The last four weeks — staging tests with real traffic running in parallel with the existing process.
The cut-over happened over one weekend. For the first week, the team worked alongside one of our engineers on-site (one of our people sat in the client's office and answered questions in real time). Small fixes went in as they came up. By week three after cut-over we moved to remote support.
Results six months after go-live
Numbers are one side of it. The other side is harder to quantify: sales reps stopped promising customers stock that was not there, because they see the actual warehouse in real time. The order desk shifted from re-entering data to handling complaints and onboarding new customers. The warehouse manager no longer has to explain to accounting why something was, once again, recorded incorrectly.
The hardest part of the project was not the technology. The hardest part was showing the team that we were not taking work away from them — we were taking the worst part of their work away.
What's next
After go-live we keep the system on an SLA — 24/7 monitoring, monthly log reviews, quarterly updates against new Comarch Optima releases. In 2026 we plan to onboard a second warehouse (the client is opening a branch near Wrocław) and extend the order form into a B2B portal where regular wholesale customers place orders themselves.
This is a good example of how our projects work. We do not replace everything. We do not buy new systems. We take what you already have and make it behave as one whole.
Got a similar setup? Comarch Optima, a warehouse system, a few Excel files? Let's talk for 30 minutes — no commitment — and see whether this is something we can sort out for you.
Book your free consultation →