what AFAS makes easy.
AFAS exposes data through GetConnectors. They are flexible: you decide which fields you request, and that makes reading from AFAS straightforward in many cases. For fetching orders, customers, products or stock it is a strong starting point.
That flexibility has a flip side. What a GetConnector returns depends on how it is set up: the integration reads exactly the fields someone on your side has prepared. So whoever manages the GetConnectors is part of the project: a change there affects the integration directly.
where it gets hard.
There are two points where AFAS integrations are often more work than they look.
a webshop rarely gets by with one GetConnector.
One product in the webshop often comes from several GetConnectors in AFAS: article data, prices and stock separately. The webshop wants them as one whole, so those results have to be combined before an external system can use them, while the integration still has to be dependable.
Combining is harder than it sounds. The sources do not change at the same time, one request can fail while others succeed, and a half-finished product must never reach the webshop. That is why you store intermediate results before writing: each source is fetched and stored separately, and the combined record only goes through once all parts are complete. If a step fails, the last complete version stays. We use smart storage mechanisms for this.
writing to AFAS takes knowledge of the database.
Writing data back, an order for example, does not work without knowing the database tables and field names in AFAS. An order touches several tables at once: the header, the lines, the debtor and references to articles that must already exist. Every table has mandatory fields, and what the webshop stores as free text is often a code from a fixed list in AFAS.
A write that works with a tidy sample order breaks on the first order from a new customer, with an unusual VAT rate or an article that was just changed. That knowledge is the difference between an integration that works and one that has to be repaired again and again.
what to agree on up front.
Most problems after go-live come not from the technology but from agreements nobody made. Settle these before anything gets built.
- Which system owns which field. In many cases prices and stock come from AFAS and product copy and images from the webshop. A field with two owners gets overwritten sooner or later.
- Which direction each kind of data flows. Orders from the webshop to AFAS, stock from AFAS to the webshop, customers possibly both ways.
- Which fields are mandatory when writing back, and what happens when the webshop does not supply them: a default value, an error or an order put on hold.
- How quickly a change has to be visible. Stock every few minutes needs a different setup from prices once a night.
testing and go-live.
Never test writing to AFAS for the first time on production. Use an AFAS test environment and a fixed set of orders covering the awkward cases: a new customer, a different delivery address, a discount, several VAT rates, an article with no stock. After every write, check in AFAS itself that the result is correct, not just that the API returned no error.
Before go-live, compare the counts in both systems: products in the webshop against products AFAS should have delivered, orders sent against orders received. Agree on who watches the integration in the first weeks and what happens to an order that gets stuck. An integration that fails silently is worse than one that fails loudly.
which webshop do you have?
We have connected AFAS to Magento. We connect ERP systems to Shopify and Shopware regularly, and AFAS is familiar ground for us. If your combination is one of those, this is how it works: before we quote, we check technically whether your integration is possible. After that we give a fixed price for the agreed scope, and adjustments are on time and material with an estimate up front. The price depends on the types of systems, known or legacy, the number of routes and the overall complexity. You can read more about how we check in has this been done before?.
When we build on Alumio, the library connectors are the starting point. Almost every company, however, has process quirks that do not fit them. We solve those by configuring generic components to match your process.
what to find out up front.
- Which data has to go back and forth: orders, customers, products, stock, prices or invoices?
- Who manages the GetConnectors and the permissions in AFAS, and can that person make changes?
- Does anything have to be written back to AFAS, and which fields are mandatory?
- Which system owns which field, and is that written down?
- Is there an AFAS test environment we can write against?
- How quickly do changes have to show up in the webshop?
Want to know what this means for your situation? Tell us which webshop you use and which data you want to exchange, and we will tell you in one call what it involves.
