The Intercompany Order Chain in D365: Synchronisation, Direct Delivery, and What You Can Change

In the trade setup article I stopped at the moment the trading relationship exists and the policies are saved. Nothing has been ordered yet. Today I want to follow one order all the way through the chain, because the setup only makes sense once you have watched what it does: which document is created from which, which fields travel in which direction, what confirmation really does, how direct delivery pulls the original customer order into the picture, and, the question I get asked most, what you are still allowed to change once the chain exists.

THE THREE DOCUMENTS AND WHO CREATES THEM

A full intercompany chain in D365 has up to three documents. The buying legal entity (I will call it entity A) raises a purchase order to a vendor that is flagged as intercompany. The moment that purchase order is saved, D365 creates an intercompany sales order in the supplying legal entity (entity B) against the customer account that is paired with A. That pairing is the trading relationship from the previous article; without it you get an ordinary purchase order and nothing on the other side.

The third document is optional and sits in front of the other two: the original sales order. When A is selling to an external customer and wants B to supply the goods, the chain starts with A's sales order to that customer, and the intercompany purchase order is created from it, either by a direct delivery action or by master planning firming a planned intercompany order. In that case the intercompany sales order in B carries a reference to the original sales order and, if you choose, to the original customer, so B can see who the goods are ultimately for.

Two points about creation. First, the intercompany sales order is created on save, not on confirmation. Second, the sales order number in B follows the numbering policy on the relationship: it can be B's own sequence, the same number as A's purchase order, or A's company code plus the purchase order number. I argued last time for the company plus number option; in the chain the reason is obvious, because both entities end up talking about the same number.

FIELD OWNERSHIP: WHICH SIDE IS THE MASTER OF WHAT

The cleanest way to think about synchronisation is ownership: each field has one document that owns it, and D365 copies the value to the other. Fight the ownership and you create the differences that surface at reconciliation.

The purchase order in A owns the demand side: the item and variant, the quantity, the unit, the requested receipt date, the delivery address and the mode of delivery, the external item number, line text, and the purchase order reference itself, which lands on the sales order as the customer requisition. Change any of these on the purchase order line and it flows to B. Requested receipt date on the purchase side becomes requested ship date on the sales side after the transport days between the two sites are subtracted, so a date that looks wrong by two days is usually transport time, not a bug.

The sales order in B owns the supply side: the confirmed ship and receipt dates, the shipment itself (packing slip quantities and dates), and, depending on the pricing policy, the price. When B confirms a different date than A requested, the confirmed dates flow back to the purchase order. When B posts a packing slip, A gets a product receipt. When B posts an invoice, A gets a vendor invoice, either posted automatically or parked as a pending invoice depending on the posting policy you chose in the setup.

Price deserves its own sentence because it is the one field where the direction is configurable. If price and discount search is active on the intercompany sales order, B's trade agreements decide the price and the result is written back to A's purchase order line. If it is not active, the price entered on A's purchase order line is copied to B's sales order as is. Both are legitimate designs; the mistake is letting users edit the price on the side that does not own it, so my default is to lock the non-owning side with the price edit policies.

WHAT CONFIRMATION ACTUALLY DOES

Confirmation on an intercompany chain is a handshake, not a formality. When B confirms the intercompany sales order, D365 confirms A's purchase order as well, and the confirmed dates travel with it. That is the moment the demand in A is considered firm supply: master planning in A now sees a confirmed purchase order rather than an open one, and master planning in B sees a confirmed sales order it must fulfil. When planning runs across both entities, this handshake is what stops the two plans from second-guessing each other.

Because the confirmation is mutual, I recommend a simple operating rule: B confirms, A does not. If A confirms first, the confirmation carries A's requested dates as if they were promised, and B has to reconfirm to correct them. Two confirmations on one line are not harmful, but they make the confirmed date column untrustworthy.

DIRECT DELIVERY: WHEN THE END CUSTOMER JOINS THE CHAIN

Direct delivery is where the chain touches a real customer. A has a sales order to an external customer and, instead of receiving the goods and shipping them again, uses the direct delivery action on the sales order line, which creates an intercompany purchase order to B with the customer's delivery address on it. B's intercompany sales order therefore inherits the external customer's address and delivers straight to it.

The document flow changes accordingly. When B posts the packing slip on its intercompany sales order, D365 posts the product receipt on A's purchase order and, because the line is a direct delivery, posts the packing slip on A's original sales order as well. Inventory in A is received and issued in the same instant, so A's on-hand never changes. Whether the original sales order packing slip posts automatically or waits for a user is a policy on the relationship (post original sales order automatically); a companion setting lets the original customer receive one summarised packing slip or invoice when B ships in parts.

Invoicing is where people expect magic. B invoices A through the intercompany chain, and that invoice can post A's vendor invoice automatically. A invoicing the external customer is a separate step on the original sales order, at A's price, and it is never posted by B's actions unless you have explicitly configured it. Keep them in your head as two events; the margin between them is the transfer price topic for later in the series.

THE REFERENCES THAT HOLD THE CHAIN TOGETHER

Every document in the chain carries pointers to its neighbours. On the purchase order in A, the Intercompany tab on the action pane opens the linked sales order in B directly. On the sales order in B, the same tab opens the purchase order in A, and the customer requisition field holds A's purchase order number. If the chain started from an original sales order, B's sales order also shows the original sales order number and, where configured, the original customer account and the customer's reference.

I add the intercompany purchase order and original sales order columns to the sales order list page in the supplying entity. It makes internal orders a filter, and it is the fastest way to spot a broken chain: an intercompany customer order with no purchase order reference is either a hand-keyed order or the remains of a chain deleted on one side only.

WHAT YOU CAN AND CANNOT CHANGE AFTER CREATION

Now the practical part. The answer depends on how far the chain has progressed.

• While the chain is only created, almost everything on the demand side is still open. Change quantity, dates, address, or mode of delivery on the purchase order line and watch it flow to B. Add a line on either side and the counterpart appears; delete a purchase order line and the sales order line goes with it. The one thing you cannot do is change the item on a linked line: delete it and create a new line.

• After confirmation, quantity and date changes still synchronise, but every change now invalidates a promise. Reconfirm on B's side so both documents carry the same confirmed dates again, and treat any price edit as a change request rather than a quick fix, because the two entities have already agreed a value.

• After a packing slip or invoice, the shipped quantity is fixed on both sides. You can still reduce or move the remaining quantity, and the remaining quantity will follow the usual rules, but the address and the price on the shipped portion are history. Corrections at this stage are not edits; they are returns and credit notes, which is a chain of its own and gets its own article.

The rule I ask every intercompany team to agree on is in the first diagram: change the chain where it started, and let the change flow. If the demand changed, change the purchase order (or the original sales order for a direct delivery, whose changes flow forward into the purchase order before it is confirmed). If the supply changed, change the sales order. The moment two people "fix" the same fact on two documents, the synchronisation has nothing sensible to do, and you will meet the result at month end.

WHAT GOES WRONG

• The sales order is not created. Nine times out of ten the vendor is not actually flagged as intercompany, the trading relationship is inactive, or the item is not released to entity B. In the last case the purchase order saves and the failure sits in the notification centre nobody reads.

• Dates differ by a fixed number of days on every line. That is the transport time between the two sites doing its job. If the offset is wrong, fix the transport days on the site or the mode of delivery, not the individual orders.

• Prices disagree between the two documents. Somebody edited the price on the non-owning side, or price and discount search is active on one relationship and not on the paired one. Decide which entity owns the price and lock the other side.

• Direct delivery ships but A's original sales order shows nothing delivered. The post original sales order automatically policy is off, so the original packing slip is waiting for a user in A. Either switch the policy on or make sure someone owns that step.

• The chain was deleted on one side. Deleting a purchase order line removes the sales order line, but a sales order that was deleted or cancelled in B directly leaves A with a purchase order that will never be fulfilled. Cancel from the purchase order side, always, and cancel any orphan you inherit explicitly.

• Confirmed dates flip back and forth because both entities confirm. Agree that the supplying entity confirms and the buying entity reads.

Next time I will look at intercompany master planning: how planned intercompany demand appears in the supplying entity, why the sequence in which you run the plans across legal entities matters, and how the downstream and upstream planning settings on the trading relationship decide whether one plan run or several are needed.

In this series: previous article Intercompany Trade Setup in D365: Trading Relationships, Order Policies, and Defaults