Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Web orders, the work each one creates and the hours booked against it move between Shopware and AFAS, so an installed sale is costed from what it actually took rather than from what was quoted.
Plenty of businesses sell something through Shopware that somebody then has to go and fit. The order is the easy part. What follows is a visit, a few hours, sometimes a second trip, and AFAS is where those hours are recorded because that is where the business runs its people and its projects. Left unconnected, the hours are booked against a general code and the margin on installed work becomes a guess that always looks better than it was. Connecting Shopware and AFAS gives the work a place to be booked and the order something to be measured against.
DATA THAT FLOWS BETWEEN THEM
Web orders
Order lines
Project records
Booked hours
Customer records
Sales invoices
A Shopware order that needs fitting creates the AFAS project the hours will be booked to, so cost lands on the job rather than on a general code somebody chose at the time.
Because hours arrive against the order that caused them, margin on installed work is a figure per sale instead of a monthly total that hides which jobs lost money.
The customer created from the web order is the customer the project belongs to, so an invoice, a site visit and a follow-up call all point at the same single AFAS record.
Nothing about pay or employment travels anywhere; the hours reach AFAS as cost against one specific job, and what is done with them afterwards stays inside AFAS.
When a Shopware order includes work to be carried out, Alumio creates the AFAS project or work record it needs, so whoever carries out the visit books their time against the order instead of against a general catch-all code.
Hours recorded in AFAS are written back against the Shopware order they belong to, so the cost of fitting sits beside the revenue on that order rather than being discovered inside a monthly labour figure a quarter later.
The customer detail from the web order creates or matches the AFAS record the project sits under, so a second visit, an invoice and a query all resolve to the same customer without anybody re-entering the same details twice.
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.
Who in the business is not served yet is the right question, and on installed work it is whoever is not on the payroll. A subcontractor timesheet portal is the common addition, because AFAS records the hours of people it employs and a fitter working for a subcontractor puts their time somewhere else. Alumio holds that connection alongside this one, so the cost of a Shopware job includes the labour the business hired in.
Hours and cost are the direction that matters, and the order has to exist first for them to land anywhere. Alumio creates the AFAS project from the Shopware order, then reads booked hours back and writes them against that order. What travels is time and cost against work, chosen when the route is configured, and nothing from the employment side of AFAS goes anywhere near the web order.
No, and the boundary is worth setting explicitly rather than discovering. Which Shopware order lines create AFAS work, which project type they use, and which hour types come back are settings in Alumio's interface, and the employment and payroll side of AFAS is simply not in the mapping. Where a business books hours through an unusual structure, custom logic remains available through the Code Transformer for that step.
Work, and that is the half most integrations skip. A Shopware order for something that has to be fitted implies a visit, and AFAS is where the hours for it are recorded, so an integration that creates only an invoice leaves the cost of delivering the sale untracked. Creating the project alongside the invoice means the hours have somewhere correct to go before anybody needs them to.
Hours booked against a job that was closed, or against nothing at all, is the failure worth catching, because the time is real and the cost lands somewhere arbitrary. Time is watched as it moves and kept with the Shopware order it belonged to, an alert names the AFAS project and the reason at once, and retries run where configured. Unmatched hours stay listed, so no job is worked without a record and no hours go missing.
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)
