Dynamics 365 Commerce DOM: Configure Cross-Legal-Entity Fulfillment in Version 10.0.49

Microsoft is dismantling that wall in Dynamics 365 Commerce with Cross-Legal-Entity Fulfillment Optimization for Distributed Order Management (DOM). Tracked under Microsoft 365 Roadmap ID 576770 with general availability slated for December 2026, this capability allows the DOM engine to look past single-company constraints, evaluate inventory across multiple participating legal entities, and automatically generate the complex web of intercompany accounting transactions required to ship the goods.

For enterprise IT administrators, solution architects, and retail operations teams running Dynamics 365 Finance and Operations (HQ), this update transforms DOM from a single-entity routing tool into a genuine enterprise-wide fulfillment broker. Here is a complete breakdown of how the architecture works, the exact version requirements, and how to configure and troubleshoot it in your environment.

From Inventory Lookup to Automated Execution​

To understand why this update matters, it helps to distinguish between simply seeing inventory and actually routing it.

In Dynamics 365 version 10.0.47, Microsoft introduced Cross-Legal-Entity Inventory Lookup for Point of Sale (POS), which allowed store associates to check stock levels in nearby or cross-border stores belonging to other legal entities. While helpful on the sales floor, visibility alone does not move boxes or satisfy the tax authorities.

As detailed by Dynamics 365 product managers Yufei Huang and Anupama Raju on the Microsoft Dynamics 365 Blog, the new DOM capability completes the operational loop: see inventory across legal entities, optimize fulfillment across legal entities, and execute fulfillment across legal entities. Following an earlier enhancement in version 10.0.46 that brought DOM support for advanced warehouse-enabled items (aligning warehouse work, loads, and inventory statuses with DOM strategies), cross-entity fulfillment represents the next major step in unifying fragmented supply chains.

Version Timelines and Rollout Scope​

While Microsoft’s high-level roadmap and 2026 Release Wave 1 plan listed an initial preview target of May 2026 and a general availability target of December 2026, Microsoft's technical product documentation and August 2026 engineering blog pin the actual deployment to specific application releases:

• Dynamics 365 version 10.0.48 (Private Preview): Requires administrators to log an incident (ICM) with their environment details to request flight enablement from the product team.
• Dynamics 365 version 10.0.49 (Public Preview): Administrators can self-enable the capability directly through the Feature Management workspace without raising a support ticket.
• General Availability: Scheduled for December 2026 across Worldwide (Standard Multi-Tenant) cloud instances.

It is also critical for architects to note the current boundaries of the feature. In its initial release, Cross-Legal-Entity Fulfillment Optimization is a headless capability provided by Dynamics 365 Commerce inside Dynamics 365 Finance and Operations. It supports Commerce sales orders across POS, e-commerce, call centers, and headless orders flowing through the Commerce Scale Unit (CSU), provided those orders are created in or synchronized to Finance and Operations.

What is not included yet? Broader Supply Chain Management (SCM) sales order scenarios are not supported in the initial release, nor is customer-facing cross-legal-entity inventory visibility on e-commerce storefronts. According to Microsoft's product team, both areas are currently under evaluation for future roadmap iterations, and standard preview disclaimers apply.

Section Summary: Cross-legal-entity fulfillment builds on version 10.0.47’s POS inventory lookup by automating the back-end routing and intercompany paperwork. It is available via self-service Feature Management starting in version 10.0.49 ahead of a planned December 2026 GA, and currently targets Commerce sales orders rather than native SCM sales orders.

Under the Hood: The Synchronized Transaction Chain​

Why can’t an optimization engine simply tell a warehouse in Entity B to ship an order placed in Entity A? Because corporate accounting, value-added tax (VAT), and transfer pricing rules require an audit trail whenever goods cross legal ownership lines.

When DOM evaluates a sales order and decides that the optimal fulfillment node—based on stock availability, proximity, cost, and configured business rules—resides in another legal entity, it orchestrates a three-document synchronized chain:

1. Original Sales Order (OSO): Created in the source (ordering) legal entity where the customer made the purchase (via POS, web, or call center).
2. Intercompany Purchase Order (IC PO): Automatically generated by DOM in the source legal entity, ordering the item from the sister company.
3. Intercompany Sales Order (IC SO): Automatically generated by DOM in the target (fulfilling) legal entity, instructing that entity's warehouse or store to fulfill the demand.

[Customer]
    │
    ▼
[Source Legal Entity (e.g., Germany)]
  ├── 1. Original Sales Order (OSO)
  └── 2. Intercompany Purchase Order (IC PO)
            │
            ▼ (Automated Intercompany Sync)
[Target Legal Entity (e.g., France)]
  └── 3. Intercompany Sales Order (IC SO) ──► Pick, Pack & Ship to Customer

Once those documents are generated, warehouse workers and store associates in the fulfilling entity do not need to learn a new workflow. They process the Intercompany Sales Order using their standard pick, pack, and ship routines (including POS store fulfillment, where orders routed from other legal entities appear with accurate customer details). Direct delivery fulfillment methods are also supported. When the fulfilling entity ships the order, the status propagates backward through the IC PO and marks the customer's Original Sales Order as fulfilled.

How the Engine Handles Real-World Exceptions​

Anyone who has worked in retail IT knows that the "happy path" only happens on architecture slides. In the warehouse, boxes get damaged, stock counts drift, and customers cancel orders. Microsoft’s Learn documentation outlines four specific lifecycle scenarios that administrators must validate during testing:

Section Summary: DOM bridges corporate boundaries by automatically generating and synchronizing an Intercompany Purchase Order and Intercompany Sales Order alongside the Original Sales Order. Fulfilling teams use standard pick-pack-ship tools, while partial shipments, rejections, and cancellations cascade automatically across all three linked documents.

Step-by-Step Admin Guide: Configuring Cross-Entity DOM​

Setting up cross-legal-entity fulfillment requires coordination between finance administrators (who control intercompany trade relationships) and retail administrators (who manage DOM rules and profiles). According to Microsoft Learn’s official setup guide, four foundational prerequisites must be met before you begin: the DOM configuration key must be enabled, intercompany trading relationships must exist between participating entities, products must be released across all participating entities, and all warehouses must have valid geographic coordinates (latitude/longitude) or Azure Maps enabled.

Here is the ten-step configuration procedure inside Dynamics 365 Finance and Operations:

1. Enable the DOM Configuration Key​

• Navigate to System administration > Setup > License configuration.
• On the Configuration keys tab, expand the Retail node, check the Distributed Order Management box, and select Save.
• Admin Note: Toggling license configuration keys requires your environment to be in maintenance mode, which must be enabled via Lifecycle Services (LCS).

2. Configure Azure Maps for Distance Resolution​

DOM relies on Azure Maps to calculate the real-world distance between your fulfillment nodes and the customer's delivery address.

• Navigate to Retail and Commerce > Headquarters setup > Parameters > Commerce shared parameters.
• Select Azure Maps in the left pane, set Enable Azure Maps to Yes, enter a valid Azure Maps key, and click Save.

3. Configure DOM Parameters and the Production Solver​

• Go to Retail and Commerce > Distributed order management > Setup > DOM parameters.
• Under the General tab, set Enable distributed order management to Yes and Confirm Azure Maps usage for DOM to Yes.
• Configure your organization's Fulfillment data retention period, DOM logs retention period, and Rejection period (in days).
• Switch to the Solver tab and set the Solver type to Production Solver.
• Critical Requirement: You must use the Production Solver. The Simplified Solver does not support intercompany order creation.
• Under the Number sequences tab, assign valid number sequences to all required DOM entities.

4. Establish Intercompany Trading Relationships​

For every pair of legal entities that will share inventory, you must link an intercompany customer and vendor record:

• In the fulfilling (selling) entity: Go to Accounts receivable > Customers > All customers. Create or select the customer record representing the ordering entity. On the General FastTab under Intercompany, set Intercompany to Yes and configure the sales order policies (including automatic sales order creation and direct delivery settings).
• In the ordering (source) entity: Go to Accounts payable > Vendors > All vendors. Create or select the vendor record representing the fulfilling entity. On the General FastTab under Intercompany, set Intercompany to Yes and configure purchase order policies to allow automatic purchase order creation.

5. Map DOM Intercompany Vendors​

Next, tell DOM which vendor account to use when it needs to generate an intercompany purchase order:

• Navigate to Retail and Commerce > Distributed order management > Setup > DOM Intercompany vendor mapping and select New.
• Select the Source legal entity (where the customer order lands), the Target legal entity (which fulfills the order), and the Intercompany vendor account in the source entity that represents the target entity.
• Repeat this mapping for every participating legal entity pair and select Save.

6. Build Multi-Entity Fulfillment Groups​

• Go to Retail and Commerce > Channel setup > Fulfillment groups and create a new group.
• Use Add line or Add lines to include warehouses and stores from multiple legal entities, designating whether each location supports Shipping, Pickup, or both.
• Pro Tip: This uses the exact same fulfillment group architecture as POS cross-company inventory lookup, allowing you to maintain a unified list of shipping-capable warehouses across your enterprise.

7. Define Cross-Entity DOM Rules​

• Navigate to Retail and Commerce > Distributed order management > Setup > Manage rules.
• Configure your operational guardrails, which can now span corporate boundaries:
  • Fulfillment location priority rule: Rank locations across different legal entities.
  • Maximum distance rule: Cap how far an order can be routed.
  • Minimum inventory rule: Ring-fence safety stock at local stores or warehouses so cross-border orders don't wipe out local walk-in inventory.
  • Partial orders rule: Control whether DOM is allowed to split a single customer order across multiple locations or multiple legal entities.

8. Assemble the DOM Fulfillment Profile​

The fulfillment profile binds your entities, rules, and delivery modes together:

• Go to Retail and Commerce > Distributed order management > Setup > Fulfillment profiles and click New.
• Set Auto apply result as desired.
• On the Legal entities FastTab, add every legal entity that will participate. (If an entity is omitted here, DOM will ignore its warehouses even if they are in the fulfillment group.)
• Link your rules on the Rules FastTab and optionally assign your Fulfillment group.
• On the Action Pane's Setup tab, configure Modes of delivery and Sales order origins by adding combinations for each participating legal entity.
• Set Enable profile to Yes and click Save.

9. Configure Cost Factors (Optional)​

• If you want DOM to weigh financial friction rather than just distance and stock levels, go to Retail and Commerce > Distributed order management > Setup > Cost configuration.
• Here you can assign shipping costs, handling fees, and intercompany transfer costs to specific locations or groups so the solver optimizes for margin preservation.

10. Schedule the DOM Processor Batch Job​

• Finally, go to Retail and Commerce > Distributed order management > Batch processing > DOM processor job setup.
• Select your newly built Fulfillment profile, assign a Batch group, configure the recurrence schedule, and click OK.

Troubleshooting Common Deployment Pitfalls​

Even seasoned Dynamics 365 administrators can hit snags when connecting multi-company tax and trade policies to an automated optimization solver. When validating your setup in a sandbox environment, watch out for these five common failure points documented by Microsoft:

• DOM ignores warehouses in other legal entities: Double-check both your Fulfillment profile and your Fulfillment group. Even if a warehouse is added to the Fulfillment group, DOM will completely skip it during optimization if its parent company isn't explicitly listed on the Legal entities FastTab of the Fulfillment profile.
• DOM assigns the location, but Intercompany PO/SO documents fail to generate: Inspect DOM Intercompany vendor mapping to verify that a mapping exists for that exact source-and-target entity pair. Then verify that the linked intercompany customer and vendor records have trading policies enabled for automatic order creation.
• The DOM batch job crashes with solver errors: Verify that Production Solver is selected in DOM parameters and properly licensed. Leaving the system on the default Simplified Solver will break cross-legal-entity runs.
• Distance calculation errors during optimization: Confirm that Azure Maps is enabled in both Commerce shared parameters and DOM parameters, and verify that every participating warehouse address resolves to valid latitude and longitude coordinates.
• Rejected order lines are not being reassigned: Check the Rejection period (in days) setting in DOM parameters. If a location rejects a line, DOM will not attempt to reassign the line back to that same location until the rejection period expires.

Strategic Analysis: What IT Leaders Should Consider Before Flipping the Switch​

From an enterprise architecture standpoint, Microsoft’s move to automate cross-legal-entity fulfillment addresses one of the most persistent headaches in global omnichannel retail. European retailers operating separate country subsidiaries—and North American conglomerates managing distinct brand entities under one corporate umbrella—have long struggled to justify the cost of custom ERP extensions just to let Company A ship a parcel for Company B. Baking this orchestration directly into the standard DOM engine eliminates a massive source of technical debt.

However, based on general industry experience with multi-entity ERP deployments, automating the software workflow is only half the battle. Before turning this on in production, IT leaders should sit down with their finance and logistics counterparts to work through three practical questions:

1. Have you modeled the intercompany transfer costs? Just because a warehouse in another country is physically closer to the customer doesn't mean it is cheaper to ship from there. Cross-border shipments can trigger customs declarations, higher carrier tariffs, and internal transfer-pricing accounting overhead. Make full use of Step 9 (DOM Cost Configuration) so the Production Solver accounts for intercompany transfer costs rather than blindly routing orders by mileage.
2. What happens during a return? Fulfilling an order across legal entities is a forward-logistics triumph, but omnichannel retail lives and dies by reverse logistics. If a customer in Germany receives a package fulfilled by the French entity and walks into a German brick-and-mortar store to return it, how do your store associates and finance teams reconcile that inventory? Ensure your returns and credit-note workflows are tested alongside forward fulfillment.
3. Are your item master data and unit-of-measure setups strictly aligned? Because products must be released and active in all participating legal entities, any drift in product variants, inventory dimensions, or units of measure between companies will cause intercompany order creation to stall.

For organizations already running Dynamics 365 Commerce on version 10.0.49, spinning up Cross-Legal-Entity Fulfillment Optimization in a sandbox environment via Feature Management is well worth the afternoon. If your business relies heavily on native Supply Chain Management sales orders alongside retail channels, keep a close eye on Microsoft's release notes heading into the December 2026 general availability window as the product team evaluates expanding this architecture across the wider Dynamics 365 portfolio.

Planning a Dynamics 365 update or wrestling with multi-entity configurations in Finance and Operations? Head over to our Enterprise IT and Microsoft Dynamics discussions here on WindowsForum.com to share your deployment strategies with fellow admins.