Four systems, one flow: EDI integration with Ongoing WMS and Fortnox
The grocery chains require EDI. The warehouse – often a third-party logistics provider – works in Ongoing WMS. The accounts are kept in Fortnox. Three systems that each do their job well, but were never built to talk to each other. That is everyday life for many growing food companies, and it was the situation at several of our customers before CloudOffice® became the hub that ties everything into a single flow.
In this article we show how one EDI integration ties four systems together – and count how many times someone has to type the order in by hand. The answer is zero.
The starting point: a zoo of systems
Hardly anyone deliberately chooses to run three disconnected systems. It just happens. The chain – ICA, Dagab/Axfood or Coop – requires EDI before you are allowed to deliver at all. The warehouse picks its WMS based on its own needs, and Ongoing is common among Swedish 3PL warehouses. Fortnox has been there since the company started, and the accountant would like to keep it that way.
In the best case there is a link between Ongoing and Fortnox. But the EDI orders land with someone who has to key them in manually – into Fortnox, into the warehouse system, or both. Delivery notes and invoices are created by a person comparing printouts. When the warehouse picked 47 cases instead of the 48 ordered, the difference is discovered only when the chain rejects the invoice.
EDI itself is rarely the problem – the message exchange as such can be solved in many ways. The chains run their own supplier portals, as ICA and Coop do, and there are independent EDI services where you receive orders and send confirmations, despatch advices and invoices through a web interface. What they have in common is that a person handles the documents by hand: reads the order in the portal, keys it into the warehouse system and into Fortnox, and then types the delivery and the invoice back in. The messages are electronic – the work is not. What is missing is not EDI but the orchestration: making sure order, picking, delivery and invoice stay connected across all systems without manual intervention.
One flow – from store order to bookkeeping
With CloudOffice as the hub, the same order looks like this. Each step is triggered by the previous one, and no information is entered twice.
Step | Where it happens | What CloudOffice does |
|---|---|---|
1. The store orders | EDI (ORDERS) | Receives the order, creates a sales order and sends an order acknowledgement (ORDRSP) back to the chain. |
2. The order goes to the warehouse | Ongoing WMS | Transfers the order to the warehouse automatically – directly or via Fortnox, depending on the setup. |
3. The warehouse picks | Ongoing WMS | Retrieves quantities, batch numbers, best-before dates and pallet numbers (SSCC) from the warehouse. |
4. The delivery is confirmed | EDI (ORDRSP, DESADV) | Adjusts the sales order to what was actually picked, sends the order confirmation and the despatch advice with full pallet information. |
5. The invoice is created | Fortnox + EDI (INVOIC) | The invoice is created in Fortnox on the delivered quantities and sent as an EDI invoice to the chain. |
6. Credits | Fortnox + EDI | A credit note in CloudOffice becomes a credit invoice in Fortnox referencing the original – and a credit INVOIC to the chain. |
Even the small details travel the whole way. The Swedish bottle deposit (pant) is a good example: it is part of the order from the chain, goes on to Fortnox and ends up on the invoice – without anyone adding it by hand.
What is delivered is not always what was ordered
This is where most integrations fall apart. Sending an order from A to B is easy. The hard part is everything that happens afterwards: a batch runs short, a case is damaged, a best-before date is too close. The warehouse picks what is there.
In the flow above, the warehouse's reality is what counts. When Ongoing reports what was actually picked – per article, batch and pallet – CloudOffice updates the sales order and creates the delivery from that. The order confirmation (ORDRSP) to the chain shows the real quantities, the despatch advice (DESADV) carries pallet numbers, batches and dates, and the invoice in Fortnox is reconciled against the delivery before it goes out as an INVOIC.
The result is that the chain's goods receipt, the delivery note and the invoice all say the same thing. It sounds obvious, but for many suppliers rejected invoices and credit-note carousels are a recurring item at month-end.
Same principle, different setups
The flow above is one of several variants we run in production. At one customer the sales order goes to Fortnox first and from there on to Ongoing, because the warehouse already had a link in place. At another, the order goes straight from CloudOffice to Ongoing, and Fortnox only receives the invoices. Which chain is ordering matters less – ICA, Dagab or someone else – as long as the communication runs over EDI.
Nor do the orders have to arrive only via EDI. In several projects the EDI flow is complemented by AI that reads incoming order emails and creates sales orders. The end result is the same: a sales order in CloudOffice that follows the same path to warehouse, chain and bookkeeping.
What makes this possible is that CloudOffice is built to be the hub – with ready-made EDI profiles for the Swedish chains, a ready-made Fortnox connection and an open API for warehouse and other systems.
When nothing happens, that is a good sign
The goal of the setup is for the system to run itself. Orders come in, go to the warehouse, are confirmed, advised and invoiced – without anyone having to open an application. In practice it works like a black box.
Users log in to CloudOffice when something needs a decision: an article the chain ordered that is not in the assortment, a delivery that has to be split, a credit that needs approval. Then the whole chain of documents is in one place – sales order, delivery, freight document, invoice – traceable to both the EDI message and the warehouse report.
How EDI integration works in CloudOffice
The EDI connection to ICA, Dagab/Axfood and Coop is included as standard, supporting ORDERS, ORDRSP, DESADV and INVOIC according to the chains' specifications. The Fortnox integration synchronises sales orders and/or invoices depending on how you want to work. Ongoing WMS is connected via API, and the same principle applies to other warehouse and transport systems – or to CloudOffice's own warehouse management if you run the warehouse yourself.
Five questions to ask about your own flow
How many times is an order typed in before it is invoiced?
What happens when the warehouse picks fewer cases than ordered – who updates the order confirmation, the delivery note and the invoice?
Do batch numbers, best-before dates and SSCC from the warehouse flow automatically into the despatch advice?
Does the invoice in your accounts match what was actually delivered, or what was ordered?
Can you switch warehouse or add a new chain without rebuilding the whole flow?
Want to see the whole flow in practice?
We are happy to show how an EDI order travels from store to bookkeeping in a real environment – starting from your warehouse and your Fortnox setup.
Company details and references are available on request.