Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
A Shopware order becomes three separate documents in SAP Business One before anybody is invoiced, and the order they are created in decides what the customer is told, and when they hear it.
SAP Business One works in a document chain. A sales order, a delivery and an invoice are three records, each created from the one before it, and each meaning something different to finance. A Shopware order is one event, so somebody has to decide which document it becomes and at what point the next one follows. Get the sequence wrong and a customer is invoiced for goods that have not left, or ships against an order nobody priced. Connecting Shopware and SAP Business One fixes the order of events, so the paperwork follows the goods instead of racing them.
DATA THAT FLOWS BETWEEN THEM
Sales orders
Deliveries
Sales invoices
Customer records
Item availability
Payment records
A Shopware order becomes the SAP Business One document you nominate, and the next one follows on the event you choose, so the chain runs in the order finance expects.
Invoicing waits for the delivery rather than the order, so a customer is not billed for goods still sitting in the warehouse and nobody issues a credit note to undo it.
The same field mapping serves the webshop and any second storefront, so adding a channel is a configuration change rather than a second integration to keep in step.
Finance stops correcting documents that were created in the wrong sequence, which is where most of the manual work in a webshop to ERP link actually sits, quarter after quarter.
When a Shopware order is placed, Alumio creates the SAP Business One sales order and leaves the delivery and invoice to follow on the events you choose, so the chain is never started from the wrong end of it by mistake.
The invoice is created from the delivery rather than from the order, so what a customer is billed for matches what actually left the building, and finance is not reversing entries a week later to correct it the following week.
A second Shopware storefront reuses the same mapping into SAP Business One, so the business gains a channel without gaining a second set of rules that has to be maintained alongside the first one for ever afterwards.
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.
Which side of the shop the third system serves is the question that decides it, and for most businesses the answer is the delivery rather than the storefront. A proof-of-delivery capture app is the usual addition, because SAP Business One records that a delivery document exists and only the driver knows whether anybody signed for it. Alumio holds both connections, so the Shopware order carries that too.
The document lifecycle is what gets configured, and it is the whole decision. Alumio creates the SAP Business One sales order from the Shopware order, then the delivery and the invoice on the events you nominate rather than all three at once. Availability and payment status travel the other way on the schedule you set, so the storefront reflects what the ERP has accepted.
No, and the useful way to see it is two shops, one mapping. Which Shopware field feeds which SAP Business One document field, and which event creates the next document, are entries in Alumio's interface, which is why a second storefront costs a configuration change rather than a rebuild. Where a business posts to an unusual document structure, the Code Transformer takes that step.
The sales order, in almost every case, with the delivery and the invoice following it. SAP Business One builds each document from the one before, so creating an invoice straight from a Shopware order leaves no delivery and no record of what shipped, and creating everything at once bills the customer before the goods move. Starting at the order and letting the chain follow the events keeps the paperwork honest.
An order that shipped before anybody priced it is the failure to catch, and the credit note is the only trace. Alumio posts each document in sequence and records what it created, so a Shopware order SAP Business One refuses stops the chain at that point rather than skipping ahead, alerts at once with the document and the reason, retries where configured, and stays listed so nothing is invoiced out of order or lost.
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)
