Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Which company a Shopware order belongs to is settled before it reaches Microsoft Dynamics 365 F&O, so a sale arrives in the legal entity that will invoice it rather than the one it was moved to later.
Microsoft Dynamics 365 F&O books everything into a legal entity. A Shopware storefront does not have one, so somewhere between the checkout and the sales order somebody decides which company the sale belongs to. In a group running two or three operating companies behind one shop, that decision often gets made a month later by a finance person moving entries between companies. Connecting Shopware and Microsoft Dynamics 365 F&O turns it into a rule applied at the order: what was bought, where it ships from and who it ships to decide the company, and the sale arrives in the one that will invoice it.
DATA THAT FLOWS BETWEEN THEM
Sales orders
Order lines
Legal entities
Customer accounts
Item availability
Delivery status
A Shopware order carries what was bought and where it ships from, and the rule you set turns that into the Microsoft Dynamics 365 F&O legal entity before the sale is created.
Nobody reposts Shopware sales between companies afterwards, because each was created in the right one, so the inter-company entries written to correct that stop existing.
A group does not need a Shopware storefront per company to keep Microsoft Dynamics 365 F&O tidy, because the split happens in the rule rather than in the shop the customer sees.
Stock and price published back to Shopware come from the Microsoft Dynamics 365 F&O company that would fulfil the order, so the shop never quotes from one that will not ship it.
When an order is placed in Shopware, Alumio resolves the legal entity from the rule you set and creates the sales order in that Microsoft Dynamics 365 F&O company, so nobody has to work out afterwards whose sale it was.
When an operating company joins the group, the same Shopware storefront starts feeding it by extending the rule rather than by building a second connection into Microsoft Dynamics 365 F&O, so the shop itself does not change.
When Microsoft Dynamics 365 F&O holds the same item in more than one company, Alumio publishes the position of the one that would ship to that customer, so the storefront shows a figure somebody can actually honour.
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.
Yes, and in a group the next system usually needs the same answer this one does. A warehouse or a PIM added later has to know which company an order belongs to before it can do anything useful with it. Alumio holds that connection alongside this one and the entity rule is already defined, so the second system inherits it rather than being given its own version to drift from.
Yes, with the entity resolved before anything is written. Alumio creates each Shopware order in the Microsoft Dynamics 365 F&O company the rule returns, and sends availability, price and delivery status back on the schedule you set for each. What can be created that way is whatever Microsoft Dynamics 365 F&O exposes for it, so that is the thing to confirm first.
No. The entity rule is configuration like everything else: which Shopware field or shipping condition points at which Microsoft Dynamics 365 F&O company is an entry you can read and change, which matters because that rule changes whenever the group does. Where the split depends on something configuration cannot phrase, the Code Transformer expresses that one rule.
Nothing in the order itself, which is why it has to be decided on the way. A Shopware checkout knows the items, the delivery address and the shipping method, and the rule you configure turns those into a company: a brand sold only by one entity, a country served by another, a warehouse that belongs to a third. Alumio applies that rule and creates the sales order in the company it returns, so the answer is made once rather than per order.
The failure worth catching here is not a missing order but one posted to the wrong company, because it looks successful and surfaces at consolidation. Alumio monitors each transfer live and records the entity it resolved alongside the order, so the decision is auditable rather than assumed. An order Microsoft Dynamics 365 F&O refuses raises an alert naming the order and the reason, retries run where configured, and nothing is dropped silently.
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)
