I no longer want to lay every supplier invoice next to Exact line by line.
Show me only what is wrong, and put the rest in.
That was the question from a drinks wholesaler with its own shop. They work with Exact Online, buy from about ten regular suppliers and sell to hospitality, to resellers and in their own shop. A month later a custom app is running that takes over most of the purchasing work, plus an order portal for their hospitality customers.
This is what was built, in which order, and what we would do differently. The client stays anonymous and there are no amounts, prices or margins here.
The starting point: everything side by side by hand
Every supplier sends an invoice in its own layout. On it are new items that do not yet exist in Exact, prices that are slightly different from last time, surcharges that only appear in the footer, and free bottles that are settled on a line of their own. Someone laid that next to Exact line by line, created new items by hand and retyped the purchase order.
On top of that there were tens of thousands of customer price agreements in Exact that nobody checked any more. Whether a customer was buying below cost price, you only knew if you happened to see it.
First a prototype of four days
The first version was a small script that could read three suppliers and only read from Exact. It ran for four days. Enough to see that it was possible, and to find out where the real difficulties were.
After that the app was set up again, with a real database, two-step login, roles and notifications. The results of the prototype became the test set for the new app: every invoice the script read correctly, the new app had to read just as well. So the rebuild did not start from zero, but from a bar.
What is running now
Reading invoices and checking the sums. PDF or UBL from ten suppliers, each with its own reader. Every invoice is recalculated line by line; about 97 percent adds up to the cent. What does not add up is shown at the top with the line next to it. Mailing invoices to an address of their own per supplier, after which the app collects them itself, is now running on a test domain.
New items. A product that is not yet in Exact becomes a proposal: a name in the style the wholesaler itself uses, supplier item, purchase price and a sales price. Once approved, it is in Exact.
Purchase order from the invoice. After checking, the invoice goes to Exact as a purchase order, with returns as a negative quantity. A busy API or a timeout is retried automatically, but only after the app has checked that the order is not there yet.
Price lists and margins. All price agreements are in a copy of their own. Red is a customer price below cost price, orange a margin below the minimum that the wholesaler sets itself.
Stock and till. Stock per warehouse comes in every quarter of an hour. The till of the shop supplies a weekly export; that becomes one transfer from the wholesale warehouse to the shop warehouse in Exact.
Order portal. Hospitality customers order themselves against their own price list, see what they ordered before and get an email when something is back in stock. Once approved, the order goes to Exact, and Exact calculates the price.
Notifications. An invoice that does not add up, an item without a supplier number, a price below cost price. Configurable per employee, with a daily overview by email.
The numbers
| Suppliers with their own invoice reader | 10 |
| Invoices that add up to the cent | about 97% |
| Purchase invoices from three years of archive read | more than 1,800 |
| Named write actions to Exact | 8 |
| Time between two stock levels | 15 minutes |
| Automated tests | more than 1,900, in about 35 seconds |
Those three years of archive are not just for the history. They were the toughest test we could give the readers: every old layout, every credit note, every exception came by. What could not be read is in a list under the numbers, so you know how complete they are.
How it was built
In small steps, with the owner looking along. Every change only goes live when all tests are green, and then within a minute. That makes it possible to hear a wish on a Tuesday and show it on Wednesday.
Writing to Exact was added step by step. The prototype only read, and every write action in the new app has been a job of its own, with a test of its own that guards against one being added unnoticed. How that works is in eight write actions and no ninth. The development environment never talks to Exact, only to a copy.
What is still to come
The till per receipt instead of per week: the webhook that the till sends after every sale works on our own test till. Further: counting with the phone, printing shelf labels from the app, and notifications also through Telegram. Those are planned, not finished.
Common mistakes in a project like this
Starting with the whole system. Start with the bottleneck that comes back every week. For this client that was the purchase invoice. Everything after that built on the same integration.
All suppliers at once. Every supplier has its own quirks. Start with the three largest, get those right, and add the rest one by one.
Letting it write everything straight away. Start with reading and add write actions one by one, each with its own approval. You learn how the data really fits together, and the owner learns to trust the app before it may book anything.
Testing with three invoices. The real exceptions are in old layouts, credit notes and scans. An archive of a few years is the best test set there is.
More about what an Exact integration can do is on connecting Exact Online. About the building blocks behind this app we wrote earlier in beyond invoices.