Hello — the Dynamics 365 community, live

In my first article in this series I walked through the four roads out of D365 Finance and Operations for BI: OData, the entity store, BYOD, and the Synapse and Fabric links. I promised to come back to BYOD, because it is still the road most existing warehouses on F&O sit on, and because it is the one that fails most quietly. A BYOD feed rarely crashes. It keeps running green every hour while the numbers in the warehouse drift a little further from the ledger. Today I want to explain how BYOD really works under the covers, how I set it up, and why an incremental export can miss rows without ever reporting an error.

WHAT BYOD ACTUALLY IS

Bring your own database is not a replication service. It is the Data management framework, the same engine you use for imports and exports of files, pointed at an Azure SQL Database that you own instead of at a file. Every BYOD table you see in your database is the output of a data entity, exported by a data project, running as a batch job on the F&O batch servers. That one sentence explains almost every behaviour you will meet:

• The unit of export is the data entity, not the table. You get the entity's denormalised shape, with its joins, its computed columns, and its field names, not the raw AxDB tables.

• Exports consume F&O batch capacity. A heavy BYOD schedule competes with posting, master planning, and every other batch job on the same environment.

• Incremental export depends on SQL change tracking on the AxDB tables behind the entity. What change tracking is told to watch is exactly what incremental export can see, and nothing more.

Microsoft's direction for new builds is clearly the Synapse Link and Fabric route, which I will cover next. But BYOD is supported, it works with ordinary SQL tooling, and a well run BYOD feed is perfectly respectable. The trick is running it well.

SETTING IT UP: THE TARGET DATABASE

Start with an Azure SQL Database in the same Azure region as the F&O environment. Cross region exports work, but every row crosses the wire, and a large full push across regions turns a twenty minute job into an hour. Size the database for the write burst, not for the steady state: the busiest moment of a BYOD database is a full push of the general ledger or inventory transactions entities, and an undersized tier throttles the export, which in turn holds an F&O batch thread for longer.

In the Data management workspace, under Configure entity export to database, you register the target with an ADO.NET connection string and validate it. Two options matter at this point. Creating clustered columnstore indexes on the target tables is the right choice for almost every reporting workload, because BYOD tables are wide and your queries read a few columns across many rows. Enabling triggers in the target database lets triggers you create on the BYOD tables fire during the bulk insert; I only switch it on when I have a specific downstream reason, because it slows every export.

Then you publish the entities you need. Publishing creates the table in the target with the entity's columns, named after the entity's staging table. Publishing is also how you pick up schema changes after an update adds fields to an entity, and that has a consequence I will return to in the failure section: republishing drops and recreates the table.

In the pricing article I left the transfer price sitting on the intercompany sales order line and the matching cost on the purchase order line. That is where most projects stop paying attention, and where the finance team's problems begin. Today I follow the chain through posting: how the invoice in the selling company creates the invoice in the buying company, where each side lands in the ledger, why the due to and due from accounts are not where you reconcile trade, and what period end has to do before anyone can eliminate anything.

TWO INVOICES FOR ONE DELIVERY

An intercompany delivery is one physical movement and two commercial documents. In the selling company the intercompany sales order (the ICS order, in the naming from the order chain article) is packing slip updated and invoiced like any other sales order: inventory is issued, revenue and cost of goods sold post, and the intercompany customer gets an open transaction. In the buying company the intercompany purchase order (the ICP order) needs a product receipt and a vendor invoice, and D365 can create both for you.

The automation lives on the trading relationship from the trade setup article. The purchase order policies hold the two switches that matter: post the product receipt automatically when the intercompany packing slip posts, and post the vendor invoice automatically when the intercompany sales invoice posts. A companion option lets the product receipt carry the packing slip number and the vendor invoice carry the sales invoice number. Switch it on: it turns reconciliation from a hunt for matching amounts into a join on a document number.

The automatic posting runs in the buying company in the context of the user who posted the sales invoice. That sentence explains a surprising number of support tickets: the user needs rights in the buying legal entity, the fiscal period there must be open, and the vendor posting profile and inventory posting for the intercompany vendor must be complete, or the sales invoice posts and the purchase side quietly does not. The first symptom is a customer balance in one company that nobody can find in the other.

WHAT EACH SIDE POSTS

• Seller, invoice: debit the intercompany customer summary account from the customer posting profile, credit revenue, debit cost of goods sold, credit inventory at issue cost. Transferred charges post as charge revenue here too.

• Buyer, product receipt: debit inventory, credit the purchase accrual. An unmatched receipt therefore shows up as an accrual balance, not a vendor balance.

I have spent most of my career on the other side of the ERP: not configuring Dynamics 365, but getting numbers out of it that finance, operations and leadership can trust. This article opens a series on exactly that. Over the coming posts I will work through Dynamics 365 from the BI, data warehousing and database point of view: how the data is shaped, how to extract it, how to model it, and how to make the figures in a report tie back to what the ERP says. My colleagues here write about how the processes run inside D365; I want to write about what those processes leave behind in the database and how to turn it into reporting.

The first question on every BI workstream for Finance and Operations is the same: where do we read the data from? Teams arriving from on-premises AX are used to pointing SSIS at the production database and getting on with it. In the cloud that road is closed, and the replacements each have a very different character. This article is the map I wish I had been handed the first time: the four ways out of the F&O database, what each one is really for, and how I decide which to use.

THE STARTING POINT: AXDB AND WHY YOU CANNOT TOUCH IT

Underneath every F&O environment is a transactional Azure SQL database, still called AxDB in development and tooling. It is a classic OLTP schema: several thousand tables, heavy normalisation, every row keyed by RecId, company data separated by a DataAreaId column, and a Partition column that is almost always the same value but still sits in every index. Enumerations are stored as integers, financial dimensions are stored as RecId references into DimensionAttributeValueCombination rather than as readable strings, and date and time fields are stored in UTC while pure date fields are not converted at all.

In production you have no direct SQL access to this database, and that is deliberate. Microsoft runs it as a managed service and protects the transactional workload from heavy analytical queries. In a tier 2 sandbox you can request just in time read access for diagnostics, and on a developer box you have the whole database locally, which is invaluable for learning the schema. But neither is a production BI source. I treat the AxDB as something to study, not something to query, and every extraction design starts from that rule.

ROAD ONE: DATA ENTITIES OVER ODATA

The planning article ended with planned purchase orders firmed into an intercompany chain. From that moment a number appears on the intercompany sales order and on the intercompany purchase order that nobody typed: the transfer price. In my experience it is the least understood field in the chain: supply chain assumes finance owns it, finance assumes it falls out of the trade agreements, and whoever built the trading relationship in the setup article clicked past the price search policy. This article covers where that number comes from, three ways to decide what it should be, and what each choice does to the margin in each legal entity.

WHY THE TRANSFER PRICE IS NOT JUST A NUMBER

Within one legal entity, moving stock between warehouses is a transfer order with no revenue or cost of sales involved. Across legal entities the same movement is a sale in one company and a purchase in the other, and D365 treats it as exactly that. The selling company books revenue at the transfer price and cost of sales at its own inventory cost. The buying company receives at the transfer price, which becomes its inventory cost and later its cost of sales. So the transfer price does three jobs at once: it splits group profit between two entities, it sets the cost basis of the receiving company, and it is the number a tax authority may one day ask you to justify.

WHERE THE PRICE IS ACTUALLY SEARCHED

When the intercompany purchase order is created in the buying company, the intercompany sales order is created in the selling company and the two documents exchange fields through the synchronisation described in the order chain article. Price is one of the synchronised fields, but only one side is allowed to find it; the other side copies it. Which side searches is decided by the price and discount search setting in the purchase order policies of the intercompany vendor in the buying company. The default is the intercompany sales order: the selling company runs its normal sales price search for the intercompany customer, finds the price in its sales trade agreements, and the result is written back onto the purchase order line. The alternative points the search at the intercompany purchase order, so the buying company's purchase trade agreements for the intercompany vendor decide and the sales order copies the result. A third option, original sales order, applies to direct delivery chains and carries the external sales price onto the intercompany documents, which is only right when the group wants the transfer price to equal the external price.

The first two articles in this intercompany series dealt with documents: the trading relationship and its policies, and then the order chain that those policies produce once a purchase order is confirmed. Today I want to go one step earlier in time, to the point before any order exists, because this is where most intercompany implementations quietly underperform. The selling entity plans, sees it needs stock from the sister company, and creates planned purchase orders. The supplying entity plans and sees nothing, because nobody has firmed anything yet. Intercompany master planning exists to close that gap: what it does, how to set it up with Planning Optimization, why the run order matters, and what still goes wrong.

THE PROBLEM: EACH LEGAL ENTITY PLANS ALONE

Master planning in D365 is scoped to one legal entity. It reads one company's demand, supply, and coverage settings and creates planned orders in that company. To the engine, an intercompany supply chain is two or three independent planning problems. The selling entity's plan output is planned purchase orders on an intercompany vendor, and in the supplying entity those do not exist. The only demand the supplier sees from its sister company is the demand that has already been turned into intercompany sales orders, which, as I showed in the order chain article, only happens when the planned purchase order downstream is firmed and the resulting purchase order synchronises a sales order upstream.

The consequence is a planning horizon that shrinks as you move upstream. The sales entity may plan twelve months out, but the factory only sees the slice that has already been firmed into orders, typically a few weeks. Beyond that the factory covers demand with a forecast of its own, built by a different team on different assumptions. Two forecasts for the same end demand, in two companies, is the most common root cause of both excess stock and shortages in intercompany groups.

PLANNED INTERCOMPANY DEMAND: WHAT THE FEATURE ACTUALLY ADDS

Intercompany planning solves this by letting the supplying entity read the planned purchase orders of the selling entity before they are firmed. When the upstream plan runs, every unfirmed planned purchase order in the downstream company whose vendor is the intercompany vendor representing the upstream company becomes a demand line in the upstream company's net requirements. The reference type is planned intercompany demand, carrying the downstream company, planned order number, quantity, and requirement date. The upstream engine treats it like any other demand: it nets it against on-hand and existing supply and, if there is a shortfall, creates planned production orders, planned purchase orders, or planned transfers according to the item's default order settings and coverage group upstream.

I've been quietly enjoying the fact that the ERP MCP server has form tools, not just data tools. Data tools are the obvious half: read, create, update, delete. Fine. But form tools let an agent do the other thing — open a page, set a control, click an action — the way a person would, with all your posting logic and validation firing exactly as designed. No parallel API surface to build. That still feels slightly magical to me.

What I hadn't thought about until this week is that "drive the form like a user" means the agent has to find your controls. By name. And that puts a design decision I made three years ago, half-asleep, directly in the critical path of an AI workflow.

The bit that got me

Buried in the 10.0.49 platform notes is a set of form-tool fixes that are much more interesting than their one-line summaries suggest:

• Group option button controls — your FrameOptionButton = Radio and Check groups — were a control family the agent couldn't read or set at all. Not "worked badly." Couldn't touch. If a required step on your form is a radio group, that flow just didn't work.
• Control resolution hardening: find-by-name, grid group resolution, and a preference for non-lookup controls when setting a value. That last one is the tell — if you've got a lookup and a plain field with similar names, the agent was picking wrong and failing ambiguously.
• Menu item label resolution (including via search), plus document upload and viewer support.

So a whole class of "the agent kind of works on this form, sometimes" was really just naming collisions and one blind spot.

Why I care, and what I'm doing about it

This is the first time control naming has had a functional consequence for me. FormStringControl1 never hurt anyone before — it does now. Vague, duplicated, or near-identical control names are the difference between an agent completing a task and giving up in a way nobody can debug.

My takeaway: if you're building agent flows over custom forms, the fix isn't in the agent. Get onto PU73 PQU-1 (7.0.8199.29+; it's backported to 10.0.48 and 10.0.47 too), then go read your own form designs out loud. Would you know which control to click from the names alone? If not, neither will the agent.

I've got a PurchTableExt form I'm suddenly not proud of. Tomorrow's problem.

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.

With the asset management thread wrapped up in the asset analytics article, I am starting a new series on a subject that touches almost every multi-entity D365 implementation and is still set up badly more often than well: intercompany trade in Finance and Supply Chain Management. Over the coming articles I will walk the order chain, planning, pricing, accounting and reconciliation, returns, warehouse flows, and the failure patterns. Today is the foundation: what a trading relationship is, how the intercompany customer and vendor pair works, what the order policies do, and where the values on an intercompany order come from. Get this layer right and the rest of the series is about behaviour; get it wrong and every later article becomes a troubleshooting guide.

WHAT INTERCOMPANY TRADE MEANS IN D365 TERMS

Two legal entities in the same D365 environment trade with each other. The selling entity sees the buying entity as a customer; the buying entity sees the selling entity as a vendor. Intercompany trade ties those two master records together so that a purchase order in the buying entity produces a matching sales order in the selling entity, and so that documents posted on one side (confirmation, packing slip, invoice) update the other side without anyone retyping anything. It is not a consolidation feature, not a transfer order, and not a substitute for intercompany accounting in the general ledger, which comes later in the series. It is a document synchronisation mechanism between a customer and a vendor who happen to be the same group, and because both live in one database, D365 can create the counterpart order and post documents in both companies from a single action. Those conveniences are what the setup governs.

THE PREREQUISITES PEOPLE SKIP

Before you touch the intercompany form, four things need to be true.

• The products are released in both legal entities with the same item number. Intercompany does not translate item numbers; the two sides must agree on the product identity, its dimension groups, and its unit of measure.

• The buying entity has a warehouse with a real address. The intercompany sales order takes its delivery address from the purchase order, which takes it from the receiving warehouse (or from the original customer in direct delivery). Warehouses without addresses produce orders without addresses.

• Number sequences exist on both sides and you have decided how intercompany orders should be numbered (more below). If both entities share one sales order sequence, some options will collide.

• Currency, exchange rates, sales tax groups, and posting profiles are in place on both master records. If the vendor has no payment terms, the intercompany purchase order has none either, and the invoice fails at the end of a chain that otherwise worked.

CREATING THE CUSTOMER AND VENDOR PAIR

Start with the master records. In the selling entity, create a customer that represents the buying entity with a proper customer group, currency, and terms. In the buying entity, create a vendor that represents the selling entity in the same way. I name both records after the legal entity they represent and put the entity ID in the account number, because in a group with ten entities and forty relationships you will otherwise spend your life hovering over account numbers.

Then open the Intercompany action on either record. The form is the same from both sides, and once saved it appears on both records. On the trading relationship tab you mark the relationship active and point the record at its counterpart: from the customer you choose the vendor company and the vendor account that represents this selling entity there; from the vendor you choose the customer company and customer account. Save, and you have a trading relationship.

Every maintenance article I have written in this series ends at the same point: the work order is ended and the cost posts. In the work orders article I made the case that ending orders promptly is a discipline, not a formality, because the ledger only sees the cost at that moment. Today I want to follow that cost after it posts, because the whole reason to run maintenance through D365 instead of a spreadsheet is what the history lets you do afterwards: see what an asset has really cost over its life, see how often it fails and how long it stays down, and decide with numbers rather than instinct when it is time to stop repairing something and replace it.

WHERE THE COST GOES AFTER THE ORDER ENDS

Three cost types flow through a maintenance work order: labour hours priced at the worker's cost price, spare parts issued from inventory at their inventory cost, and expenses such as external services or vendor invoices attached to the order. While the order is open, these sit as posted journals against the work order. When the order is ended, D365 posts the ledger side and, just as importantly for this article, stamps the cost into the maintenance cost history of the asset the order was raised on.

That history is what the cost control inquiries read. Asset management offers cost control views at three levels: per asset, per functional location, and per work order. The asset view is the one I use most, because it lets you pick a period and see the split between hours, items, and expenses for one asset, and compare it against a budget if you have created one. The functional location view rolls up every asset installed underneath it, which is why I keep saying that the hierarchy you designed in the functional locations article is not just a filing system: it is your cost roll-up structure. If a packaging line is a functional location with six assets under it, the line's cost is one click, and it is correct without anyone building a report.

Two practical points here. First, cost history is only as good as the ending discipline: an asset with five open orders looks cheap until the month someone closes them all at once and the trend jumps. Second, if you move an asset between functional locations, the cost follows the asset, but the location roll-up changes from the move date onward. That is usually what you want, but it surprises people who compare a location's cost across a year in which equipment was shuffled.

BUDGETS GIVE THE NUMBERS SOMETHING TO BE COMPARED AGAINST

Every company wants real time visibility into their supply chain. Fewer companies actually trust that visibility enough to act on it.

I've noticed this pattern again and again around Dynamics 365 Supply Chain Management implementations. The system is set up, inventory is tracked, demand forecasting is running, planners have a dashboard that shows exactly what's on hand, what's in transit, and what's projected to be needed next month. And yet, in a lot of warehouses and planning offices, someone is still keeping a personal spreadsheet, still calling a supplier directly to double check a number, still adjusting the system's forecast based on gut feel built up over years on the job.

That gap between what the software shows and what people actually rely on is worth paying attention to. It rarely comes from the technology being wrong. Dynamics 365 Supply Chain Management can genuinely pull together procurement, inventory, warehouse, and manufacturing data in a way that legacy point systems never managed. The gap comes from trust, and trust in supply chain data is earned slowly and lost quickly. One bad forecast during a demand spike, one inventory count that didn't match reality during a physical audit, and a planner remembers that moment for years. After that, the system becomes a reference point instead of a decision maker, and the spreadsheet on the side quietly becomes the real source of truth.

This matters more now than it used to, because supply chains have spent the last several years absorbing shocks that made careful planners even more cautious. Disruption after disruption taught a lot of supply chain professionals that clean historical data does not always predict what happens next, and that lesson does not disappear just because a new planning engine got implemented. So the honest challenge for any Dynamics 365 Supply Chain Management rollout isn't only technical configuration. It's proving, transaction by transaction, that the numbers hold up when it counts, and that takes longer than any go live date usually allows for.

There's also an organizational layer to this. In many companies, the people closest to physical inventory, warehouse staff, floor supervisors, receiving teams, are the ones whose daily actions determine whether the data in the system stays accurate. If those teams see data entry as a task imposed on them rather than something that protects their own planning decisions later, small inaccuracies creep in constantly, and no amount of forecasting sophistication can fix data that was wrong at the source.

The demo always goes the same way. Someone types "create a purchase requisition for 200 units of the steel bracket from our usual vendor and route it for approval" into a chat pane, and the AI agent finds the item, picks the vendor, fills the form, and submits the workflow. But three weeks later, that agent is in production, and the questions start: Why can this thing see payroll? Who approved it, touching the ledger? It just edited a record nobody asked it to; was that allowed?

I've now deployed enough Copilot agents for Dynamics 365 Finance & Operations to say the quiet part out loud. Building the agent is only 20% of the journey. The remaining 80%, which entails deploying, governing, monitoring, and running it safely at scale, is where the real complexity begins. This article is about the 80%.

The Demo Problem

Demos optimize for the happy path. A scripted prompt, clean data, one user, no edge cases, and a presenter who knows exactly what the agent will do because they rehearsed it. Production is the opposite of all of that. You get prompts nobody anticipated, users with wildly different permissions, dirty data, and an agent that's now allowed to act, not just answer.

The business challenge isn't "can the agent do the task?" It demonstrably can. The challenge is ownership: who is accountable for what the agent is permitted to see and do, who watches it, who gets paged when it misbehaves, and who can prove to an auditor that it stayed inside its lane. That's an operations discipline, and it's one most teams haven't built yet because the technology only made autonomous action practical very recently. 

What Actually Changed 

If you wired an agent to F&O over the last year, you probably used the static Dynamics 365 ERP MCP server, a fixed set of 13 tools built on the Dataverse connector framework. It worked, but it was rigid, and Microsoft is retiring it during the 2026 calendar year. The replacement, the “dynamic” Dynamics 365 ERP MCP server, went generally available in February 2026.

Instead of a frozen tool list, it exposes living tool categories: data tools for create/read/update/delete against entities, action tools that invoke business logic, and metadata tools the agent uses to discover your schema, including custom entities and extensions. Per Microsoft's documentation, this surfaces hundreds of thousands of ERP operations across tens of thousands of forms, without a custom connector or bespoke API. The data tools also moved off chatty form-level interactions toward direct, optimized entity operations, which is why agent responses got both faster and more reliable.

Here's the line from Microsoft Learn that matters more than any of that: when you add the MCP server to an agent, it gets access to data and business logic that matches the agent's security role and environment context. This means it gets exactly the permissions you assign it, no more, no less. 

The conversation in the Dynamics world has changed. Nobody is asking whether to adopt AI anymore. The question on every project board is how to put agents to work without breaking what already runs the business. 

Two years ago, Copilot in Dynamics 365 was essentially a helpful colleague who could summarize a record or draft an email. Useful, certainly, but nobody would have trusted it to act on its own. The 2026 release wave 1 marks the point where that changed. Microsoft now ships agents across Sales, Customer Service, Finance and Supply Chain that do not simply answer questions. They take a business goal expressed in plain language, break it into concrete steps, and carry those steps out inside the system. 

The clearest example is the Contact Center, which Microsoft is turning into a fully agentic environment. Cases get triaged, routed, drafted and in many instances resolved before a human ever opens them. Containment rates, the share of inquiries handled entirely without human involvement, have become a headline metric in customer service projects. On the finance side, the new autonomous Payflow Agent takes over payment processing tasks that used to consume hours of accounts payable time every week. 

What this changes for implementation work 

Anyone who has sat through a Dynamics implementation knows the traditional shape of the work: requirements, configuration, data migration, training, support. Agents add a layer that behaves differently from anything consultants have deployed before. An agent is not a workflow. It does not follow a fixed path, and its behavior depends on the quality of the data and knowledge it can reach. 

That has practical consequences. Data hygiene, long treated as a cleanup task to squeeze in before migration weekend, is now a precondition for the headline features working at all. An agent drafting customer responses from a knowledge base full of outdated articles will confidently produce outdated answers. Teams that skipped the unglamorous work of curating their content are discovering that the bill has arrived. 

Scoping also changes. Clients increasingly arrive with expectations set by consumer AI tools and assume the same fluency will appear in their ERP on day one. Part of the consultant's job in 2026 is expectation management: being clear about what agents do well today, where they still need human review, and which processes are genuinely ready to hand over. 

Augmentation, not replacement 

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion that is a missed opportunity, because the operational problems holding back charging networks today are exactly the kind of problems this platform was designed to solve. I believe integrating Dynamics 365 into the EV world would shape it in a clearly positive way, and this article explains why.

The industry has an operations problem, not a technology problem

EV charging has grown fast, and the software behind it has not kept up. Most operators run on a patchwork of systems. Asset records sit in one platform, fault tickets in another, contractor management in a spreadsheet, and customer support somewhere else entirely. None of these talk to each other properly.

The result is familiar to anyone who has dealt with public charging. A charger goes down, nobody notices until a driver complains, an engineer is sent out with the wrong information, and the fix takes days instead of hours. Every one of these failures’ chips away at public confidence in EVs. If drivers cannot trust that a charger will work, they hesitate to switch from petrol. So poor operations are not just a cost issue, they slow down the energy transition itself.

One view of the asset changes everything

The core value of Dynamics 365 in this industry would be a single view of every asset. One record per charger that holds its installation details, maintenance history, fault patterns, contractor visits and customer complaints. Today that information is scattered, and decisions suffer for it.

With a unified view, an operator can spot that a particular charger model fails twice as often in coastal locations, that a certain contractor closes jobs faster than others, or that a site with repeated complaints also has a grid connection issue. These insights exist in the data already, they just cannot surface when the data lives in five places.

Field service is where the biggest gains sit

Field work is one of the largest cost centres for any charging operator, and slow charging makes it worse. The assets are cheap and spread across hundreds of small sites, so a single wasted site visit can wipe out months of revenue from the unit it was meant to fix.

What actually happened

The 2026 pattern for this is the "AI tool" (Microsoft's word for it — you'll also hear "AI plugin"). You write a normal X++ class, deploy it, and decorate it with a couple of attributes. AIPluginOperationAttribute marks the class as something an agent is allowed to call. CustomAPIAttribute ties it to a Dataverse Custom API. Your inputs and outputs are just data contract members with plain-language descriptions:

X

[CustomAPIRequestParameter('The customer account number', true),
    DataMember('accountNumber')]
public CustAccount parmAccountNum(CustAccount _accountNum = accountNum)

That description string is the part I want you to notice. It's not a comment — the orchestrator actually reads it to decide when to call your action and how to fill the parameter from someone's messy sentence. You're basically writing prompt hints in your method signatures now. Weird. Kind of great.

Why this matters to you and me

Here's the shift. These are headless operations — no form context, no client. Once your class is deployed with the right menu-item security, the Dynamics 365 ERP MCP server picks it up automatically through its find_actions / invoke_action tools. Same code, reachable from the in-app sidecar, from a custom Copilot Studio agent, or from any agent speaking MCP. You write the logic once; the surface area is enormous.

The honest catch: it's still preview, you need the unified developer environment, and there's Dataverse plumbing (the Custom API, request params, response props) plus the classic flush the cache with SysFlushAOD or nothing works gotcha that cost me twenty minutes.

My takeaway: stop thinking of your X++ classes as things only a form can call. Pick one small, useful calculation you already trust — a balance, an eligibility check, a status lookup — wrap it as an AI tool, and let Copilot reach it. It's the most direct line I've found from "code I already have" to "AI that does something real."

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion that is a missed opportunity, because the operational problems holding back charging networks today are exactly the kind of problems this platform was designed to solve. I believe integrating Dynamics 365 into the EV world would shape it in a clearly positive way, and this article explains why.

The industry has an operations problem, not a technology problem

EV charging has grown fast, and the software behind it has not kept up. Most operators run on a patchwork of systems. Asset records sit in one platform, fault tickets in another, contractor management in a spreadsheet, and customer support somewhere else entirely. None of these talk to each other properly.

The result is familiar to anyone who has dealt with public charging. A charger goes down, nobody notices until a driver complains, an engineer is sent out with the wrong information, and the fix takes days instead of hours. Every one of these failures’ chips away at public confidence in EVs. If drivers cannot trust that a charger will work, they hesitate to switch from petrol. So poor operations are not just a cost issue, they slow down the energy transition itself.

One view of the asset changes everything

The core value of Dynamics 365 in this industry would be a single view of every asset. One record per charger that holds its installation details, maintenance history, fault patterns, contractor visits and customer complaints. Today that information is scattered, and decisions suffer for it.

With a unified view, an operator can spot that a particular charger model fails twice as often in coastal locations, that a certain contractor closes jobs faster than others, or that a site with repeated complaints also has a grid connection issue. These insights exist in the data already, they just cannot surface when the data lives in five places.

Field service is where the biggest gains sit

Field work is one of the largest cost centres for any charging operator, and slow charging makes it worse. The assets are cheap and spread across hundreds of small sites, so a single wasted site visit can wipe out months of revenue from the unit it was meant to fix.

Over the last two articles I built the asset management picture from the ground up: first the foundation of functional locations, assets, and asset types, then the preventive side, where maintenance plans, rounds, and triggers project a forecast of work. I kept making the same promise at the end of each one, that the work order is the thing that finally posts cost when it is ended, and I kept deferring the detail. Today I pay that debt. I want to follow a maintenance work order all the way through execution and into money: where it comes from, how it schedules against the people and the equipment, how it picks up labour hours and spare parts from the same inventory the shop floor draws on, and the exact moment the cost becomes a financial fact that finance can see.

WHERE THE WORK ORDER COMES FROM

A maintenance work order in Dynamics 365 has two parents. The first is preventive: the forecast I described last time generates work orders from due plan lines, so a calendar trigger or a counter reading quietly turns into a scheduled job without anyone typing it in. The second is corrective: something breaks or someone notices a problem, a maintenance request is raised, and that request is converted into a work order. Either way you land on the same object, and that is the design intent. Whether the work was planned a year out or reported five minutes ago, it flows through one consistent lifecycle so the maintenance team has a single backlog to schedule and a single place where cost accumulates. A work order carries one or more work order jobs, and each job names a job type and a trade, exactly the controlled vocabulary the plan lines use, which is why the taxonomy decisions from the foundation article keep paying off here.

THE WORK ORDER LIFECYCLE

The work order moves through a sequence of lifecycle states, and the states are not cosmetic. They gate what you are allowed to do and, crucially, when cost is recognised. A new order is created, then scheduled, then it goes in progress while the work is actually done, then it is completed when the technician is finished on the floor, and finally it is ended. That last transition is the one that matters financially. Until the order is ended, the hours and parts on it are estimates and commitments; they show you what the job is expected to consume and they let you plan, but they have not yet hit the ledger. Ending the order is the act that posts the real cost. I labour this point because it is the single most common source of confusion I see: people look at an in-progress order, see numbers, and assume finance has them, when in fact nothing has posted until the order reaches the ended state.

In my last article on the Asset Management foundation I laid out the structure that everything in Dynamics 365 Asset Management hangs from: functional locations as the stable places, assets installed into them, asset types as the maintenance taxonomy, and the work order as the thing that finally posts cost when it is ended. I closed with a promise to go a level deeper into the preventive side, and that is where I want to spend today. Preventive maintenance is the part of the module that earns its keep, because it is the difference between equipment that fails on its own schedule and equipment that gets attention before it fails on yours. I will walk through maintenance plans and maintenance rounds, the two ways preventive work is defined, how time-based and counter-based triggers actually generate a forecast of work, and how to keep that forecast from either burying your technicians or quietly drying up.

WHY PLAN PREVENTIVE WORK AT ALL

Corrective maintenance is reactive: something breaks, someone raises a request, a work order follows. It is necessary, but if it is all you do then your maintenance team lives in a permanent state of firefighting and your production schedule inherits every surprise breakdown as an unplanned gap. Preventive maintenance flips the timing. Instead of waiting for failure, you decide in advance that a given asset needs a given task at a given cadence, and Dynamics 365 projects those tasks into the future as a forecast you can see, resource, and schedule. The payoff is twofold: fewer unplanned outages, and a maintenance workload you can level and staff for rather than one that arrives in unpredictable spikes. The whole preventive apparatus exists to turn "we should probably service that every so often" into a concrete, dated, costed stream of work orders.

MAINTENANCE PLANS: THE BUILDING BLOCKS

The maintenance plan is where preventive work is defined. A plan is attached either to an asset type, so it applies to every asset of that type, or to an individual asset when something is special enough to deserve its own rules. Attaching to the asset type is the move that scales: define the plan once for "hydraulic press" and every press inherits it, which is exactly why the asset type taxonomy from the foundation article matters so much here. A plan that is too granular, written asset by asset, becomes a maintenance burden in its own right.

Inside the plan sit one or more plan lines, and the line is where the real configuration lives. Each line names a maintenance job type (the controlled vocabulary I argued for last time: inspection, lubrication, calibration, replacement), the trade or worker capability the job needs, an interval that says how often, a start date that anchors the cadence, and the trigger rule that decides whether the interval is counted in calendar time or in usage. One plan can carry several lines, so a single press might have a monthly visual inspection, a quarterly lubrication, and an annual overhaul all defined together and all forecast from the same plan.

TIME-BASED AND COUNTER-BASED TRIGGERS

The trigger is the heart of the whole thing, and there are two kinds. A time-based trigger fires on the calendar: every 30 days, every quarter, every twelve months. It suits work that has to happen on a fixed rhythm regardless of how hard the asset is run, such as statutory inspections, safety checks, and anything driven by a regulation or a manufacturer's calendar recommendation. A counter-based trigger fires on usage instead, read from a counter you maintain on the asset: operating hours, machine cycles, units produced, distance travelled. It suits wear-driven work, where a machine running flat out should be serviced sooner than one that sits idle half the week. Counter-based triggers are only as good as the counter readings behind them, so part of the design is deciding how those readings get into the system, whether by manual entry, by import, or by a feed from the equipment itself.

I am stepping sideways from master planning for a few articles, at Joni's request, into a corner of Dynamics 365 Supply Chain Management that production-heavy shops lean on but that gets far less airtime than manufacturing or warehousing: Asset Management, the module Microsoft used to call Enterprise Asset Management. If you run lines, presses, ovens, conveyors, or any equipment that has to keep running, this is where Dynamics 365 tracks what you own, where it sits, what condition it is in, and the maintenance work that keeps it alive. This first article lays the foundation, the structure everything else hangs from, because almost every problem I see in an Asset Management rollout traces back to the structure being rushed.

WHY ASSET MANAGEMENT EARNS ITS PLACE

Maintenance is the quiet partner of production. A finite-capacity schedule is only honest if the resources it schedules are actually available, and a resource that is down for an unplanned repair makes a liar of the plan. Asset Management gives you a structured way to record assets, plan preventive maintenance so failures happen less often, capture corrective work when they happen anyway, and post the cost of all that work where finance can see it. It is fully inside Supply Chain Management rather than bolted on, so a maintenance asset can be tied to the same resource your production orders consume, and the maintenance work order can draw spare parts from the same inventory your shop floor draws from. That integration is the reason to use it instead of a standalone CMMS, and it is also why getting the structure right matters: the structure is what connects maintenance to the rest of the system.

THE ASSET HIERARCHY: FUNCTIONAL LOCATIONS AND ASSETS

There are two foundational objects, and people constantly blur them. A functional location is a place in your operation where an asset can sit: a site, an area, a production line, a cell, a room. Functional locations are arranged in a parent and child hierarchy, so a line sits under an area, which sits under a site. An asset is the physical thing itself: the specific pump, the specific press, the specific forklift. The asset is installed at a functional location, and that relationship is the hinge of the whole module.

The reason to separate the two is that places outlast equipment. A pump fails for good and you replace it; the slot on the line where it lived does not change. If you have built your history around the functional location, you can ask "how much has this position on the line cost me over five years" across every asset that has ever occupied it, and you can swap the physical asset in and out without losing that thread. Build everything around the asset alone and you lose continuity every time you replace a machine. So I model the places first, as a stable skeleton, and then install assets into them.

A question I get from finance and operations alike is some version of "what does this item actually cost us once it is sitting on our shelf?" For domestically sourced goods the purchase price is close enough. For anything imported it is not, because freight, insurance, customs duty, brokerage and handling can add up to a large fraction of the product price, sometimes rivalling it. Carrying inventory at the bare purchase price quietly overstates your margin and distorts every decision downstream. Today I want to walk through landed cost in Dynamics 365: the dedicated Landed Cost module that captures these charges against a shipment, and, just as important, how that cost actually lands in your inventory valuation depending on the costing method you run. The first part is configuration; the second is where finance either trusts the numbers or does not.

WHAT LANDED COST ACTUALLY MEANS

Landed cost is the fully burdened unit cost of getting an item to your location and ready to sell or consume. It is the product price plus every incremental cost incurred along the way: ocean or air freight, inland haulage, marine insurance, import duty, customs brokerage, port handling, demurrage, and agent fees. The goal is simple to state and harder to do well: take all of those charges, attach them to the goods that incurred them, and spread them fairly across the units so that each unit carries its true cost. Once you have that, your inventory value is honest, your margin reporting is real, and your sourcing decisions (make versus buy, this vendor versus that one, near versus far) are made on the right numbers.

THE LANDED COST MODULE: VOYAGES AND JOURNEYS

The dedicated Landed Cost module in D365 is built for import-heavy operations and introduces a vocabulary worth learning. The central object is the voyage, which represents a physical shipment, typically a container or a consolidation of purchase order lines travelling together. A voyage groups the goods that share the same transport and therefore should share the same transport costs. A journey template describes the route and the legs that voyage travels (for example origin port, ocean leg, destination port, inland leg), and it carries the structure that drives which costs apply and when milestones are expected. You set up the templates once to mirror how your goods actually move, then create voyages against them as shipments happen, attaching the relevant purchase order lines.

In my last article on static and dynamic master plans I settled where master planning writes its results and why most setups run two plans. I closed with a promise to follow the planned orders forward: how you turn those suggestions into real purchase and production orders, and how to read the action and futures messages that tell you what to reschedule before the warehouse ever feels it. That is today. The planned order is the most underrated object in D365 planning, because it is the hinge between a calculation and a commitment, and the habits a team builds around firming and messages decide whether planning is a tool people trust or a list they ignore.

WHAT A PLANNED ORDER ACTUALLY IS

A planned order is a suggestion and nothing more. When master planning runs, it nets demand against supply for each item and, where it finds a shortfall, it proposes an order to cover it: a planned purchase order for a bought item, a planned production order for a manufactured one, a planned transfer order to move stock between warehouses, or a planned kanban depending on your setup. None of these touch the real world yet. They carry no purchase order number, they place no demand on a vendor, and they consume no shop floor capacity beyond the plan. The crucial consequence of this is that planned orders are disposable. On the next regeneration the engine throws them away and recreates them from scratch, so anything you change on a planned order that you do not firm is lost. That disposability is a feature, not a flaw, but it catches people who spend an hour tidying planned orders and then watch the overnight run erase the lot.

Because planned orders are tied to the plan, the question of which plan you are looking at, from the previous article, matters here. You firm from the static plan of record, not the dynamic plan, precisely because the static plan holds still long enough for the firming decision to mean something.

FIRMING: TURNING A SUGGESTION INTO A COMMITMENT

Firming is the act of converting a planned order into a real order. When you firm a planned production order you get an actual production order with a number, a BOM and route attached, and a real claim on capacity. Firm a planned purchase order and you get a purchase order ready to confirm and send to the vendor. The moment of firming is the moment planning stops being advisory and starts creating obligations, so it deserves a deliberate process rather than a reflex click.

There are three broad ways to firm. The first is manual, one order at a time, from the planned orders list page: you review a suggestion, you agree with it, you firm it. The second is selective and batched: you mark a set of planned orders, often filtered to a buyer or a production unit or a date window, and firm them together. The third is automatic, governed by the firming time fence. Inside that fence the engine treats near-term suggestions as reliable enough to firm without a human in the loop, which is sensible for stable, fast-moving items but dangerous if applied blindly to everything. My general rule is to automate firming only where the demand signal is trustworthy and the cost of a wrong order is low, and to keep human review on long lead time, high value, or capacity-critical items.

Last time I wrote about coverage groups and the core planning parameters, the per-item settings that decide how master planning turns demand into planned orders. I promised to keep going with master planning, and before we follow planned orders forward into firming and messages, there is a structural question worth settling: the plan itself. When you run master planning, what is it writing into, and why do almost all real setups run not one plan but two? The answer is the difference between a static plan and a dynamic plan, and getting it right is the difference between a planner who trusts the plan and one who watches it change every time someone enters a sales order.

WHAT A MASTER PLAN ACTUALLY IS

A master plan in D365 is two things at once. It is a named configuration, a header that carries settings about how the run behaves, and it is the container that holds the results of the run: the planned orders, the action messages, and the futures messages. So when I say "the static plan" I mean both a set of parameters and the body of suggestions sitting under it. You can have several master plans defined, and you nominate which ones play which role in the Master planning parameters. Two roles matter: the current static master plan and the current dynamic master plan. Those two nominations are the quiet decision that shapes everyone's daily experience of planning.

STATIC VERSUS DYNAMIC PLANS

A static plan is the plan of record. It is recalculated on a controlled schedule, typically a full regeneration in an overnight batch, and then it sits still until the next run. That stillness is the point. A planner can open the static plan in the morning, see a coherent set of planned orders, and work through them (reviewing, adjusting, firming) without the ground shifting because someone three desks away just keyed a large order. The static plan is stable precisely because it does not react to every transaction the moment it happens.

A dynamic plan is the opposite by design. It updates continuously as supply and demand change, so it always reflects the very latest picture. The moment a sales order line is entered, the dynamic plan rebalances net requirements for that item. This is exactly what you want behind order entry and delivery date promising, where the business needs an up-to-the-minute answer to "if I sell this today, when can I have it." The dynamic plan is volatile, and that is fine, because nobody is firming orders from it; they are reading availability from it.

WHY MOST SETUPS RUN TWO PLANS

For two weeks I have been deep in the warehouse: wave templates, cycle counting, replenishment, inbound flows, and last time the mobile device menu in the operator's hand. I promised at the end of that article to step back from the floor and into planning, because everything the warehouse moves has to be made or bought first, and the thing that decides what to make and buy, and when, is master planning. This is the first of a few articles on it, and I want to start where the behaviour actually lives: the mobile device menu was the doorway to warehouse work; coverage groups are the doorway to planning. Get them right and the plan is sensible. Get them wrong and you spend your days explaining strange planned orders.

WHAT MASTER PLANNING IS ACTUALLY DOING

Strip master planning down to its core and it is a comparison. On one side it gathers demand: sales order lines, the demand forecast, transfer and production requirements, and any safety stock you have asked it to hold. On the other side it gathers supply that already exists: on-hand inventory plus open purchase, production, and transfer orders. It nets the two together, item by item and warehouse by warehouse, across the timeline, and wherever demand outruns available supply it raises a planned order to cover the gap. Those planned orders are suggestions, not commitments, until somebody firms them into real purchase, production, or transfer orders. That loop is the whole engine. What makes two companies running the same engine get completely different plans is the configuration that decides how the gap gets covered, and that configuration is mostly the coverage group.

COVERAGE GROUPS: WHERE THE BEHAVIOUR LIVES

A coverage group is a reusable bundle of planning settings that you attach to items so the engine knows how to treat them. You do not configure planning item by item from scratch; you build a handful of coverage groups that describe the patterns you have, then point each item at the group that fits. A fast-moving stocked component, an expensive made-to-order assembly, and a cheap consumable each want different treatment, and a coverage group is how you express that difference once and reuse it. The single most important field on the group is the coverage code, because it decides how individual requirements get grouped into planned orders and therefore how many orders you get and how much buffer they carry.

THE FOUR COVERAGE CODES

There are four coverage codes, and choosing among them is the first real decision you make for any item.

In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Management. Menu items, work classes, and how to design handheld flows that the floor will actually use without fighting the device. Every piece of physical movement I have written about in this series, picking, replenishment, cycle counting, receiving, put-away, reaches the operator through one screen: the mobile device menu. You can have immaculate work templates and location directives behind the scenes, but if the menu the picker sees is a deep, confusing tree of half-relevant options, the floor will be slow, error-prone, and quietly inventing workarounds. The menu is where all that back-end design either becomes usable or gets in the way.

WHAT THE MOBILE DEVICE MENU ACTUALLY IS

The warehouse mobile device menu is the tree of options an operator navigates on the handheld, from the top-level menu down through submenus to the individual actions they tap to do a job. Each leaf in that tree is a mobile device menu item, and each menu item is a small piece of configuration that decides exactly what happens when the operator selects it. Menus can contain other menus, so you can group actions by function and keep any single screen short. The whole structure is assigned to operators through their work user setup, which means different roles can see completely different menus: a receiver does not need to scroll past picking and packing options, and a picker should not be one mis-tap away from a counting flow. Designing the menu well is mostly about two questions: what is each menu item, and how is the tree arranged.

TWO MODES: WORK AND INDIRECT

The single most important setting on a menu item is its mode, and there are two. A work-mode menu item drives warehouse work: it either processes work that already exists (an operator picks up directed picking or put-away work) or it creates work as the operator acts (receiving a purchase order line generates the put-away work). Work-mode items are the ones wired to the work templates and location directives I covered in the two tables that run your warehouse; the menu item is simply the doorway through which that work reaches the floor.

An indirect-mode menu item is for everything that is not warehouse work: an item or location inquiry, a pause or break, a cleaning task, switching the active user. These do not create or process work; instead each maps to an indirect activity code, which is what lets you measure how much of the shift was spent off productive work. Getting the mode right is the first decision, because almost everything else about the item follows from it. The mistake I see most often is people reaching for complex configuration when the real problem is simply that an action was modelled as the wrong mode.

In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Management. Menu items, work classes, and how to design handheld flows that the floor will actually use without fighting the device. Every piece of physical movement I have written about in this series, picking, replenishment, cycle counting, receiving, put-away, reaches the operator through one screen: the mobile device menu. You can have immaculate work templates and location directives behind the scenes, but if the menu the picker sees is a deep, confusing tree of half-relevant options, the floor will be slow, error-prone, and quietly inventing workarounds. The menu is where all that back-end design either becomes usable or gets in the way.

WHAT THE MOBILE DEVICE MENU ACTUALLY IS

The warehouse mobile device menu is the tree of options an operator navigates on the handheld, from the top-level menu down through submenus to the individual actions they tap to do a job. Each leaf in that tree is a mobile device menu item, and each menu item is a small piece of configuration that decides exactly what happens when the operator selects it. Menus can contain other menus, so you can group actions by function and keep any single screen short. The whole structure is assigned to operators through their work user setup, which means different roles can see completely different menus: a receiver does not need to scroll past picking and packing options, and a picker should not be one mis-tap away from a counting flow. Designing the menu well is mostly about two questions: what is each menu item, and how is the tree arranged.

TWO MODES: WORK AND INDIRECT

The single most important setting on a menu item is its mode, and there are two. A work-mode menu item drives warehouse work: it either processes work that already exists (an operator picks up directed picking or put-away work) or it creates work as the operator acts (receiving a purchase order line generates the put-away work). Work-mode items are the ones wired to the work templates and location directives I covered in the two tables that run your warehouse; the menu item is simply the doorway through which that work reaches the floor.

An indirect-mode menu item is for everything that is not warehouse work: an item or location inquiry, a pause or break, a cleaning task, switching the active user. These do not create or process work; instead each maps to an indirect activity code, which is what lets you measure how much of the shift was spent off productive work. Getting the mode right is the first decision, because almost everything else about the item follows from it. The mistake I see most often is people reaching for complex configuration when the real problem is simply that an action was modelled as the wrong mode.

In my last article on replenishment I closed with a promise to turn around and face the other direction: inbound flows in D365 Advanced Warehouse Management. Purchase order and load-based receiving, license plate receiving on the mobile device, and how put-away location directives decide where received stock actually lands. Outbound gets most of the attention because it is where the orders ship, but everything outbound depends on inbound having done its job. If receiving puts stock in the wrong place, or records the wrong quantity, or leaves a license plate stranded with no put-away, then every wave, every replenishment, and every cycle count downstream is working from a lie. Inbound is the quiet half of the warehouse where inventory accuracy is either won or lost.

THE TWO WAYS STOCK ARRIVES

D365 gives you two main entry points for inbound stock, and the right choice depends on how much you know before the truck arrives. The first is purchase order receiving. You receive directly against the lines of a purchase order, item by item, and the system already knows what was ordered, so it can validate quantities against the expectation. This is the simplest model and it suits operations where receiving is driven straight off the PO and there is no separate advance notice from the supplier.

The second is load-based receiving. Here an inbound load is created, often from an advance shipping notice (ASN) sent by the supplier, and the load carries the expected contents ahead of the physical arrival. Receiving then happens against the load rather than the raw PO. Load-based receiving is the better fit when you want to plan dock and labour around known arrivals, when one shipment spans several purchase orders, or when the supplier sends structured ASN data you want to receive against. The mental model is the mirror image of the outbound load I wrote about in the outbound wave and load strategy article: a load is just a planned container of work, and inbound loads let you treat receiving with the same discipline you give shipping.

Both routes converge on the same next step. Once stock is received, the warehouse no longer cares whether it came from a PO line or a load line; it cares about the license plate that now exists and needs to be put away.

THE LICENSE PLATE IS THE UNIT OF RECEIVING

In my last article on cycle counting I promised to come back to replenishment in D365 Advanced Warehouse Management: minimum and maximum replenishment, demand-based and load demand strategies, and how to keep pick faces stocked without burying the warehouse in unnecessary moves. Replenishment is the quiet engine behind a fast pick operation. Get it right and pickers walk short distances to locations that are always stocked; get it wrong and they either stand waiting for stock to arrive or the warehouse spends half its labour shuffling pallets that nobody needed moved. It is the same balancing act I keep coming back to in this series: the system will happily create work, and the skill is in creating only the work that earns its keep.

THE PICK FACE AND THE RESERVE

Almost every efficient warehouse splits storage into two roles. Bulk or reserve locations hold inventory in its most compact form: full pallets and license plates, stacked high, optimised for density rather than access. Pick faces, often fixed picking locations assigned to a specific item, hold a small working quantity at floor level where a picker can reach it quickly. Outbound picking should pull almost entirely from the pick faces, because that is where the travel is short and the work is predictable. Replenishment is simply the discipline of moving stock from the reserve to the pick face before the picker needs it, so that the fast path stays fast. Everything that follows is about deciding when that move happens and how big it is.

THREE WAYS REPLENISHMENT GETS TRIGGERED

D365 gives you three practical mechanisms, and a mature operation usually runs more than one of them at once.

• Min/max replenishment. The workhorse for fixed pick locations. You define a minimum and a maximum quantity for the location, and a scheduled batch job tops it back up to the maximum whenever on-hand falls below the minimum. It is wave-independent: it does not care what orders are in the system, only that the pick face should never run dry. This is what keeps your high-velocity items permanently stocked.

• Wave demand replenishment. Configured as a step on the wave template, this looks at the actual demand in a wave and, if the pick locations cannot cover it, creates replenishment work as part of wave processing. It is demand-based and precise: it only moves what the orders in front of you actually require. This is the safety net for items that do not warrant a permanent min/max, or for demand spikes that outrun the scheduled top-up.

• Load demand replenishment. Triggered for a specific load, this stages the stock a known shipment will need ahead of releasing the work to the floor. It suits operations that plan in loads and want the pick faces primed before a big outbound run, rather than discovering shortfalls mid-wave.

THE REPLENISHMENT TEMPLATE

I closed the cost to complete article with a promise to come back to the warehouse: cycle counting in D365 Advanced Warehouse Management. Inventory accuracy is one of those metrics nobody talks about until it is bad, and by then every downstream process is paying for it: master planning ordering material you already have, waves releasing picks against stock that is not in the location, and month-end variances nobody can explain. A well-built cycle counting program is the cheapest insurance the module offers, and Dynamics gives you everything you need; the catch is that the pieces are scattered across half a dozen forms and only behave well together if you set them up as one system.

WHY CYCLE COUNTING INSTEAD OF THE ANNUAL COUNT

The traditional wall-to-wall count has three problems: it stops the operation, it is staffed by tired people counting unfamiliar stock at speed, and the accuracy it buys starts decaying the morning after. Cycle counting inverts the model: count a small slice of the warehouse continuously, with the people who work in it, while it runs. Errors get caught weeks after they happen instead of months, which means the root cause is still findable. And in most jurisdictions auditors will accept a robust cycle count program in place of the full physical count, provided you can demonstrate coverage: every item and location counted at a defined frequency, with documented variance handling. That word, demonstrate, drives a lot of the setup decisions below.

THREE WAYS COUNT WORK IS BORN

Everything in this process produces the same object: warehouse work of type cycle counting, queued and routed like any other work, which is why the work template and work pool plumbing I covered earlier matters here too. The differences are in the trigger.

1. Cycle count plans. The scheduled backbone. A plan holds selection criteria for locations and items, a maximum number of counts to generate per run, and the number of days that must pass before a location or item is counted again. A batch job executes the plan on its schedule and creates the work. This is the instrument that gives you provable coverage.

2. Cycle count thresholds. The opportunistic counter. A threshold watches on-hand in a location, by quantity or by percentage, and when a pick drops the location below the limit, the system creates count work for it automatically. The logic is simple economics: the best moment to count a location is when it is nearly empty, because the count takes seconds and is hard to get wrong.

3. Spot counting. The judgement call. A supervisor who distrusts a location creates count work for it directly, or a worker initiates a spot count from the mobile device. No schedule, no trigger, just suspicion, and a healthy program leaves room for it.

So I went to add a tool to one of my agents last week and Microsoft Learn quietly informed me that the static Dynamics 365 ERP MCP server is being retired this calendar year. My first reaction was, honestly, mild panic — I have agents in production leaning on that thing. My second reaction, after actually reading what's replacing it, was: oh, this is better. A lot better.

What's actually changing

If you connected an agent to F&O over the last year, you probably wired it to the static MCP server — a fixed set of tools, pointed mostly at OData. It worked, but it was rigid. You got what you got.

The new dynamic ERP MCP server is the replacement, and the word "dynamic" is doing real work here. Instead of a frozen tool list, it exposes three living categories — data tools, action tools, and metadata tools — that let an agent do nearly anything a user can do through the UI. No custom connector, no bespoke API, no glue code you'll be maintaining at 2am.

The part that made me sit up: the data tools are moving operations off OData and onto SQL under the hood. If you've ever watched an agent grind through a chatty OData query against a big table, you know exactly why that matters. Faster responses, and — this is the underrated bit — better responses, because the agent can navigate ERP data intelligently instead of guessing its way through entity relationships.

Why you should care this week

Two reasons. One, if you've got anything pointed at the static server, the clock is ticking — migrating to the dynamic server isn't optional, it's a "do it before it's an incident" item. Put it on the board now.

Two, and more fun: agents can now open the actual record or attachment behind a Copilot response. That sounds small. It isn't. It's the difference between an agent that asserts something and an agent that shows its work — and trust is the whole ballgame when you're letting AI touch financial data.

Takeaway: Go check whatever you built on the static MCP server, plan the move to the dynamic one, and while you're in there, lean into the SQL-backed data tools. The migration is a chore. What you get on the other side genuinely isn't.

I ended the ETO projects article with a promise: the money side. Fixed-price estimates, revenue recognition, and the cost to complete number that drives what the customer, the auditor, and your own management see. This is the point in an engineer-to-order implementation where the supply chain consultant and the finance consultant have to sit at the same table, and the part most often configured on autopilot and regretted at the first year-end audit.

WHY FIXED-PRICE CHANGES THE QUESTION

On a time-and-material project the accounting is almost trivial: cost goes in, you bill it with a margin, and revenue follows the invoice. Fixed-price work breaks that link. The customer pays agreed milestones on agreed dates, and those dates have very little to do with how much of the job you have actually done. If you recognised revenue whenever you invoiced, the P&L would show a spectacular month every time a milestone lands and ugly losses in between. So the real accounting question becomes: how complete is this job, defensibly, right now? Everything below is machinery for answering that question every period and posting the result.

THE BUILDING BLOCKS

Five pieces of setup decide how the whole process behaves, and all of them exist before the first estimate is posted.

• The project forecast. Hours, items, expenses, and fees forecast against the project, held in a dedicated forecast model. This is the denominator of everything: total expected cost and total contract value. If the forecast is fiction, every number downstream is fiction too.

• The revenue recognition method. The project group decides whether the project runs on completed percentage (revenue recognised progressively as the job advances) or completed contract (everything held as WIP and recognised at the end). For long ETO jobs, completed percentage is usually the only method that gives management a usable monthly P&L.

• The estimate project. A fixed-price project carries an attached estimate project, which is where completion is calculated and estimates are posted. Several fixed-price projects can share one estimate project when they are commercially one deliverable and should be assessed together.

• The cost template. The most underrated object in the module. It groups project cost lines and decides two things: which cost categories count toward completion, and whether the completion percentage is calculated automatically from cost or entered manually. Almost every revenue distortion I have been asked to diagnose traces back to this object.

• The period code. How often estimates run. Monthly, aligned with the financial close, is the sensible default.

COST TO COMPLETE: THE NUMBER EVERYTHING HANGS ON

The completion percentage in a cost-based setup is a simple ratio: actual cost to date divided by total expected cost, where total expected cost is actual cost plus cost to complete. Actual cost is a fact; cost to complete is a judgement, and that judgement is the single most important number in fixed-price accounting. Dynamics gives you several ways to derive it when you create an estimate: take the remaining forecast (total forecast minus actuals), carry the previous estimate forward and adjust it line by line, or set it to zero for the final estimate. Whichever method you choose, the discipline matters more than the option: cost to complete must be re-examined every period by someone who actually knows the state of the job, not rolled forward mechanically from the original bid.

ETO adds a specific trap here. Engineered jobs are usually material-heavy, and the big material receipts land early. If material categories count toward completion, the arrival of the main steel or the long-lead drives can push calculated completion to 40 or 50 percent while engineering will tell you the job has barely started. The fix lives in the cost template: exclude or separate long-lead material lines from the completion basis, drive completion from hours only, or switch to manual completion based on assessed physical progress. This is the project-world cousin of the timing discipline I described for standard cost recalculations: the numbers are only as good as the moment you choose to measure them.

In my last article I walked through engineering changes and how to get a revision into BOMs and production orders cleanly. I ended on a promise: the costing side. Because every BOM change is also a cost change, and if engineering and finance do not coordinate their cutovers, the result is a month of variance analysis meetings where nobody can explain the numbers.

This article is about standard cost specifically. If your manufactured items run on moving average or FIFO, BOM changes flow into cost through actual consumption and you have a different (easier) life. Standard cost is where timing discipline matters.

HOW STANDARD COST GETS BUILT

A manufactured item's standard cost in D365 is not entered; it is calculated. The BOM calculation rolls up component costs from the item cost prices, labor from the route (run time and setup against cost categories), and overhead through the costing sheet's indirect cost nodes. The result lands in a costing version as a pending cost with an effective date, and it does nothing until someone activates it.

That separation between pending and active is the whole control mechanism. You can calculate as often as you like, review the calculation details level by level, and only the activation moves the number that values inventory and measures production.

Three configuration points worth checking on your costing version setup before any of this matters: the blocking flag (prevents accidental activation), the fallback principle (where the calculation finds component prices that have no pending cost themselves), and whether your costing version records cost by site, because multi-site manufacturers with different routes per site need site-specific standards.

A BOM CHANGE DOES NOT CHANGE COST (UNTIL YOU MAKE IT)

Here is the point people miss: activating a new BOM version changes what production consumes. It does not change the standard cost of the parent. The standard stays whatever was last activated, calculated from the old structure. From the moment the engineering cutover happens until the moment a new standard is activated, you are deliberately running with a standard that no longer matches the build.

That is not automatically a problem. It is a measurable, explainable state, as long as you know what it does to variances.

THE VARIANCE MECHANICS

When a production order on the new BOM finishes and you run end-of-order costing against the old standard, the difference between what the order actually consumed and what the standard says it should contain shows up as production variances. The useful ones to watch in this scenario: