Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Article codes, sales prices and pack details move from AFAS into Pimcore as products become sellable, so a catalog stops listing things the business is not yet able to invoice anybody for.
Pimcore is where a product gets built up long before it can be sold, and AFAS is where it becomes an article with a price, a unit and a tax treatment. Unconnected, the two disagree about when a product exists: a page goes live for something with no article behind it, an order arrives that cannot be invoiced, and finance finds out from the exception rather than from the launch plan. Connecting AFAS and Pimcore settles the order of events, so a product reaches the catalog when the commercial detail behind it is real instead of when the content happened to be finished.
DATA THAT FLOWS BETWEEN THEM
Article codes
Sales prices
Units of measure
Pack quantities
Tax treatment
Product objects
A Pimcore product is only published once the AFAS article behind it carries a price, a unit and a tax treatment, so the catalog and the order process agree on what can be bought.
The AFAS article code travels with the product into Pimcore and out to every channel reading from it, so an order coming back matches an article without anybody translating it.
A price changed in AFAS reaches the Pimcore product on the schedule you set, so the catalog stops quoting a figure the business withdrew and nobody remembered to update downstream.
Pack quantities and units of measure arrive from AFAS with the product, so a customer ordering by the box is not quietly invoiced by the piece and found out through a credit note.
When an AFAS article has the fields that make it sellable, Alumio creates or updates the matching Pimcore product object, so preparation continues in Pimcore while only complete products reach the channels reading from it.
A price or tax change entered in AFAS is read on the schedule you set and written to the Pimcore product, so the figure a customer sees moves with the one the business will actually invoice rather than trailing it by a week.
Units of measure and pack quantities are mapped once from AFAS to Pimcore attributes, so a product sold by the box carries that everywhere it appears and the difference between ordering units stops being discovered at invoicing.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
A trade customer asks for a declaration before they will place the order, and nobody can find it, which is where the third connection tends to come from. Businesses running AFAS with Pimcore most often add the source their compliance documents live in, because Pimcore can hold the reference and AFAS has no reason to. Alumio holds that connection and reuses the Pimcore mapping already built, so the document arrives attached to the product it belongs to.
A product travels once it has the fields that make it sellable, and deciding which fields those are comes before anything is configured. Alumio reads the AFAS article data you nominate, a code, a price, a unit and a pack quantity, and creates or updates the matching Pimcore object only when those are present. Products still being prepared stay in Pimcore, invisible to the channels reading from it.
No, and the work is a list of decisions rather than a build. Which AFAS field is the source for each Pimcore attribute, what happens when a price changes, whether a missing pack quantity blocks a product or only flags it: those are set once in Alumio's interface. Pimcore classes are defined per implementation, so where a business has modelled its products unusually, custom logic remains available through the Code Transformer.
Pimcore usually comes first and AFAS decides when the product counts. A product is drafted, photographed and described in Pimcore while it is still an idea, and it becomes an article in AFAS at the point it can be priced, taxed and invoiced, which is later. Treating the AFAS article as the gate means the catalog only publishes what the business can sell, without slowing down the work of preparing it.
Pimcore refusing the object is the good outcome here, because the alternative is a half-built product on a live page. Alumio monitors each update in real time and records what it sent from AFAS, so an article Pimcore will not accept, usually for a missing required attribute, raises an immediate alert naming the article and the reason. Retries run automatically where configured and the previous version stays in place, so nothing publishes half-formed.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
