EDI on the Street

Host 1

Imagine flipping the switch on a, well, a multi-million dollar Microsoft Dynamics 365 migration.

Host 2

Oh yeah.

Host 1

Your internal teams are celebrating. You know, the executive dashboard is live.

Host 2

Yay. The project managers are handing out those custom fleece zip ups to everybody.

Host 1

Exactly.

Host 2

Yeah. But out on the loading dock, a truck from one of your biggest retail customers is literally being turned away.

Host 1

Y and why?

Host 2

Because you’ve just been hit with a $50,000 chargeback. Your brand new state-of-the-art ERP system essentially forgot how to say hello in EDI.

Host 1

It happens so much more often than you’d think, right? The advanced ship notice never transmitted or maybe it transmitted with some fatal structural flaw and now I mean millions in revenue are just paralyzed. That scenario, uh, it plays out far more often than anyone in the enterprise software space really wants to admit.

Host 2

Yeah. You you undergo this massive internal transformation, right? You optimize your workflows, you train your staff, but you just fundamentally underestimate the fact that your external supply chain, well, it operates on a strict completely unforgiving set of legacy rules.

Host 1

Welcome to EDI on the street. We are your hosts representing GraceBlood and today we are unpacking all things EDI and supply chain.

Host 2

Absolutely. Our discussion today centers on one specific, I mean massive milestone, which is moving a company’s operations to Microsoft Dynamics 365.

Host 1

A huge undertaking.

Host 2

It is a monumental step for any business.

Host 1

Yeah.

Host 2

But there’s a hidden trap door built right into the migration process and it almost always gets ignored until it is entirely too late.

Host 1

Yeah. And that entire trap revolves around electronic data interchange, your EDI.

Host 2

Right.

Host 1

It’s the connective tissue between you and your trading partners. So the mission for our exploration today is singular. We are entirely focused on what happens to your EDI during a D365 ERP migration, which is a lot.

Host 2

It is. We are going to deconstruct what changes, what stays identical and, you know, how to prevent your go live from devolving into an excruciatingly expensive EDI fire drill.

Host 1

Right. For you, the listener, we want to establish right now why you cannot afford to back burner this.

Host 2

Please don’t. If you are sitting in the planning meetings for a D365 migration, the phrase we’ll deal with EDI later is the single most expensive sentence you can speak.

Host 1

Oh, absolutely, without a doubt. Because EDI isn’t just some background IT workflow. It is your actual tangible revenue. It’s the lifeblood of your customer demand, your physical shipments, your invoices.

Host 2

Yeah. If you think about the anatomy of an ERP migration, the core friction always stems from the conflict between internal transformation and external expectations, right? Internally, you are changing the very DNA of your business operations. You’re introducing new screens, entirely new data structures, uh, new ways of recognizing revenue and managing inventory.

Host 1

Basically tearing the house down to the studs.

Host 2

Exactly. But let’s look at the external reality. Your trading partners, you know, Walmart, Target, your raw material suppliers, your third-party logistics providers, right? They possess absolutely zero interest in your internal software upgrades, right? They are entirely indifferent.

Host 1

From a trading partners’ perspective, the Tuesday after your D365 go live must look indistinguishable from the Friday before it.

Host 2

Seamless.

Host 1

But, you know, I have to push back a little here because I think this is where the great illusion of the ERP migration begins.

Host 2

Okay, let’s hear it.

Host 1

If we look at this mechanically, translating EDI into a new ERP is often compared to a language translation.

Host 2

Sure.

Host 1

If an X12850 purchase order is coming in from a buyer, it’s highly standardized, right? The data is the data, right? So, if the structure is standard and D365 is a world class enterprise system, shouldn’t D365 have native out-of-the-box endpoints that just catch that standard data?

Host 2

You would think so. I mean, why is it such a catastrophic point of failure?

Host 1

It’s like changing the engine of a car while driving on the highway. The other drivers don’t care what’s happening under the hood. They just expect you to maintain your speed and stay in your lane.

Host 2

That’s a great analogy and it’s a completely fair question and honestly it it’s the exact assumption that gets companies into deep trouble.

Host 1

Oh yeah.

Host 2

To use your language analogy, translating legacy EDI into Dynamics 365 is not like swapping out vocabulary words one for one using a basic dictionary.

Host 1

Okay.

Host 2

It is akin to translating deeply complex idioms and like cultural nuances.

Host 1

Interesting.

Host 2

Dynamics 365 doesn’t speak native x12 EDI.

Host 1

It doesn’t.

Host 2

No, it speaks its own structural language via its data management framework or DMF.

Host 1

Oh, right. The DMF.

Host 2

Exactly. It utilizes specific data entities. So when that 850 arrives, the external document is indeed identical. The trading partner hasn’t altered a single ISA or ST segment in that file.

Host 1

Right? The outside wrapper is exactly the same, right?

Host 2

But the destination of that file and the processing logic required to digest it have been entirely rewritten.

Host 1

So if I’m translating an idiom literally, the entire meaning is lost.

Host 2

Exactly. Let’s break down exactly what that looks like in the data flow. When that 850 drops in, the outside is rock solid, but the inside is a totally different landscape.

Host 1

What is practically changing under the hood that causes this breakage?

Host 2

What changes are the invisible, highly specific business rules that govern your data ingestion?

Host 1

Okay.

Host 2

Migrations have this ruthless way of exposing years of undocumented configurations.

Host 1

Oh, I bet.

Host 2

Let’s trace an incoming purchase order in a legacy system, say an old AS400 or a legacy version of AX.

Host 1

Okay.

Host 2

Classic legacy setups, right? That PO doesn’t just fall into a table as flat text. It triggers a whole cascade, right? The incoming item number, maybe a buyer’s SDU, has to be translated to your internal part number using a specific cross reference table.

Host 1

Sure.

Host 2

The system evaluates the ship to address and applies logic to determine the correct warehouse code. It validates unit of measure conversions.

Host 1

Lots of moving parts.

Host 2

Exactly. And in Dynamics 365, every single one of those reference points has moved, structurally changed, or requires a different relational setup.

Host 1

Hang on, though. If a business has been running smoothly for 10, maybe 15 years, shouldn’t their IT department already have these business rules heavily documented?

Host 2

You’d think so, right?

Host 1

Why are we calling them invisible? I mean, an enterprise level company doesn’t just run on magic and guesswork.

Host 2

You would be shocked. I mean, truly shocked. I would argue that 80% of legacy supply chain integrations run on what we call shadow IT or, you know, historical band-aids.

Host 1

Shadow it. Wow.

Host 2

Yeah. Over the course of 15 years, an integration works silently in the background, but only because a developer who retired 5 years ago wrote a custom script.

Host 1

Oh no.

Host 2

Yeah. A script to truncate a specific customer ID field because the old ERP couldn’t handle the character length.

Host 1

That is terrifying.

Host 2

Or someone hardcoded a specific unit of measure override just for one retailer to prevent invoices from failing. Right? These rules aren’t documented in a neat binder. They are hardcoded into the actual translation maps themselves, just buried in the code, completely invisible to the current business analysts right up until the moment you point that data at Dynamics 365.

Host 1

And D365 being a modern, highly relational database is going to reject that data outright because it doesn’t meet its validation rules.

Host 2

Outright rejection.

Host 1

Yes, it is like trying to plug a three-prong industrial cable into a standard two-prong wall outlet. I mean the power source is the same but the connection architecture fundamentally rejects it precisely. Let’s look at customer account structures as a prime example of this.

Host 2

Okay.

Host 1

In a legacy system you might have one customer account for a retailer and 50 different shipping addresses attached to it in a flat file.

Host 2

Pretty common, right?

Host 1

But Dynamics 365 might require you to set up those locations using a complex customer hierarchy differentiating between invoice accounts and order accounts.

Host 2

Oh, I see. So if your EDI translation layer just tries to shove the old flat file logic into the new D365 data entity via O data or a REST API, the API is going to throw a fatal and then it crashes.

Host 1

The order never creates. Multiply that by thousands of orders a day and your business stops.

Host 2

Which means simply taking your existing EDI maps and repointing them to the new D365 endpoints is a complete fantasy.

Host 1

Total fantasy.

Host 2

You can’t just change the URL and hit save. This leads us directly to the required precursor for any successful migration. If repointing doesn’t work, you have to execute what I like to call the purge and the inventory. You have to figure out exactly what you are carrying.

Host 1

The inventory phase is absolutely non-negotiable.

Host 2

Yeah.

Host 1

Before a single developer writes a line of code or configures a data entity in D365, you need a forensic audit of your current integrations. And I want to be clear for everyone listening, this is far more rigorous than a spreadsheet listing. Customer A, customer B, customer C, right?

Host 2

It’s not just a checklist.

Host 1

No, you need to document transaction types, communication protocols. Are they AS2, VAN, API? You need mapping logic, item cross references, ERP touch points, customizations, and transaction volumes. But I’ll play the skeptic again here.

Host 2

Go for it.

Host 1

An ERP implementation already demands a colossal amount of resource hours. I mean, why spend hundreds of hours fully auditing 15-year-old EDI maps? Isn’t it faster to just extract the data requirements from D365, hand them to the trading partners, and ask them to test?

Host 2

It’s a very tempting shortcut, but it violates the core rule we established at the beginning.

Host 1

The trading partner does not care, and they will not do the work for you.

Host 2

Fair point.

Host 1

Furthermore, if you skip the inventory, you inevitably lift and shift decades of garbage into your new system. Right? I cannot stress this enough. Do not carry 15 years of bad decisions, duplicate maps, and manual workarounds into Dynamics 365.

Host 2

Keep the new system clean.

Host 1

The inventory is an incredibly powerful forcing function. It forces you to differentiate between a legitimate business requirement and historical baggage. Right? Just because that’s how the AS400 handled it, well, that does not mean it’s required for D365.

Host 2

That makes total sense. It’s basically the difference between remodeling a house versus moving into a new one.

Host 1

Yes.

Host 2

You don’t pack up your broken appliances, you know, the junk in the attic, the half empty paint cans, pay a moving company to box them all up and bring them into a pristine new home. You use the move to throw out the garbage.

Host 1

Exactly. And when you are conducting this inventory, you have to look well beyond the incoming orders.

Host 2

Okay.

Host 1

In my experience, outbound documents are where D365 migrations truly stumble and where the most significant financial penalties occur.

Host 2

Let’s get granular there because I think people hyperfocus on the 850, getting the order in the door because that feels like the start of the revenue cycle.

Host 1

They do.

Host 2

But getting the order into D365 is only half the battle, right?

Host 1

It’s barely a third of the battle, honestly.

Host 2

Wow. Really?

Host 1

Yeah. Getting an order into the system is structurally simpler than generating the complex outbound documents required to fulfill it.

Host 2

Okay, give me an example.

Host 1

Let’s analyze the anatomical nightmare of a ship notice for a major big box retailer.

Host 2

Oh, the dreaded ASN.

Host 1

Exactly. Requires an incredibly rigid hierarchical structure. You have the shipment level, the order level, the tare or pallet level, the pack level, and the item level.

Host 2

It’s like a Russian nesting doll of data.

Host 1

It really is. In a legacy environment, you might have had a custom job that forcefully stitched this hierarchy together based on some highly specific warehouse routing.

Host 2

Okay.

Host 1

Now, you introduced Dynamics 365 and its advanced warehousing module.

Host 2

Then D365 handles containerization and wave processing entirely differently.

Host 1

Completely differently. D365 relies heavily on license plating.

Host 2

Right. The warehouse worker picks the inventory using a mobile scanner, puts it into a specific license plate, and that internal license plate identifier now has to magically translate into a globally recognized SSEC18 barcode at the pack level.

Host 1

At the pack level of the outbound 856 EDI document, wow.

Host 2

If your EDI mapping logic doesn’t understand the D365 license plate architecture, your ASN generates without the proper packing hierarchy. So, what happens mechanically on the receiving end when that breaks?

Host 1

Well, the physical truck arrives at the retailer’s distribution center. The receiving dock scans the pallet barcode.

Host 2

The scan queries their system for the corresponding 856 ASN you were supposed to send. But because your ASN was structurally flawed, it threw an error in their EDI gateway and never posted to their warehouse system.

Host 1

So, the system doesn’t know what’s on the truck, right? The scanner beeps red. They cannot receive the goods. They reject the truck and you receive an automated five figure charge back for non-compliance.

Host 2

Yes.

Host 1

And suddenly that we’ll deal with EDI later.

Host 2

Yeah.

Host 1

Mentality becomes a literal blockade on your physical freight.

Host 2

Yeah. We also have to look at 3PL integrations. If you utilize a third party logistics provider, you’re dealing with the 940 warehouse shipping order and the 945 warehouse shipping advice.

Host 1

Absolutely. The 940 tells the 3PL what to ship. If your site, warehouse, and inventory status configurations in Dynamics 365 don’t map perfectly to the legacy logic your 3PL expects, the 940 fails.

Host 2

And then what?

Host 1

The 3PL doesn’t ship the product. The end consumer cancels the order and the revenue is gone.

Host 2

Gone.

Host 1

This is why the inventory process must evaluate business criticality. Not all integrations carry the same risk.

Host 2

You have to prioritize. You have to know precisely who carries the heavy chargeback risks and design the architecture around protecting those specific pipelines.

Host 1

So we’ve established the immense complexity of translating business logic, the necessity of purging the garbage and the highstakes reality of outbound documents like the 940. Right?

Host 2

If we are redesigning and cleaning up these integrations, evaluating all these moving parts, it brings up the massive issue of project management. When does this work actually start and who is actually holding the shovel?

Host 1

Timing and ownership. This is the exact intersection where the wheels usually fall off the wagon during an ERP migration. Any command yet?

Host 2

EDI must be brought into the D365 migration during the initial planning and design stages, not halfway through the build and categorically not 2 weeks before user acceptance testing.

Host 1

Let me stop you there and play the role of the skeptical executive again.

Host 2

All right.

Host 1

A company is already paying an absolute premium to a Microsoft partner to implement D365. They’re spending millions on licensing and implementation fees. Shouldn’t that implementation partner automatically handle all the data integrations? I mean, we’re paying them to install the ERP. Shouldn’t they inherently know how the data gets into it?

Host 2

It is a very common expectation, but it fundamentally misunderstands the technology ecosystem.

Host 1

How so?

Host 2

This is a critical distinction that executives need to grasp. ERP configuration specialization and B2B EDI specialization are two entirely different highly complex disciplines.

Host 1

Your D365 implementation partner might be world classics. They know the financial ledgers, the MRP engines, the advanced warehousing configurations inside and out, right?

Host 2

They know their software, but that absolutely does not mean they specialize in the esoteric nuances X12 specifications or the proprietary routing rules required by a specific automotive manufacturer.

Host 1

So, the Microsoft partner knows the destination deeply, but they don’t necessarily know the vehicle or the road it took to get there.

Host 2

Exactly. Let’s look at the ripple effect of a seemingly minor configuration choice. Suppose the ERP consultant optimizing for D365’s internal reporting decides to change how units of measure are abbreviated. Just a little drop down change, right? In the old system, each was EA.

Host 1

In D365, they configure it as PCS for pieces.

Host 2

Makes sense. Internally, from an ERP perspective, that is a minor, harmless configuration toggle.

Host 1

But from an EDI perspective, that is a nuclear bomb.

Host 2

It is because every single inbound 850 mapping and every single outbound 810 invoice mapping is explicitly coded to expect EA.

Host 1

Oh, wow.

Host 2

If the ERP team makes that change in a silo and doesn’t communicate it to the EDI architects, you’ll reach a point in testing where D365 technically works perfectly in isolation and the EDI platform technically works perfectly in isolation, but they completely fail to work together. The inbound orders will fail validation and the outbound invoices will be rejected by the trading partners, which means you have to aggressively define roles to avoid the danger of assumed ownership.

Host 1

Yes, assumed ownership is dangerous. If nobody explicitly owns the intersection between the two systems, everybody assumes somebody else is taking care of it.

Host 2

Exactly.

Host 1

What specific hard-hitting questions should a company be asking their Microsoft partner on day one of the project?

Host 2

You need to establish the architectural boundaries immediately.

Host 1

Okay? Like what?

Host 2

Ask them how specifically are external B2B integrations being handled in your proposed architecture. Are we using the data management framework or are we building custom O data endpoints, right? How will custom fields which we inevitably need for our specific industry be exposed to the integration layer? How are asynchronous processing errors going to be surfaced and monitored by business users?

Host 1

Those are great questions and you must ask them directly. How much dedicated legacy EDI mapping experience does your implementation team actually possess?

Host 2

That last question feels like it could be a bit confrontational, but I assume it’s just about establishing reality.

Host 1

It isn’t confrontational at all. It’s about risk mitigation. You need to know if you need to bring in external EDI specialists or leverage a managed service. You have to know who is physically writing the mapping logic and who is responsible for testing the end-to-end flow.

Host 2

Speaking of testing, that leads us to the most nerve-wracking high blood pressure phase of any migration.

Host 1

Testing the ugly path and executing the cut over.

Host 2

Oh, the ugly path.

Host 1

Yes, we’ve defined the rules. We purged the bad maps. We’ve built the architecture.

Host 2

How do we ensure it doesn’t just spectacularly crash on Monday morning?

Host 1

The secret, and it’s a difficult one because it requires immense discipline, is that testing must be truly end to end, and it must be ruthless. Ruthless.

Host 2

It is never enough to simply prove that an EDI file can successfully drop into D365. That is only step one, right? You have to prove the entire life cycle.

Host 1

This 30 drops in the sales order creates without errors. The business user can release it. The warehouse can wave and pick it following it all the way through.

Host 2

Yes. Yeah. Shipping notice generates with flawless packaging hierarchy. And finally, an invoice goes out with the exact financial totals, taxes, and freight charges expected by the partner.

Host 1

Okay. But let’s talk reality for a second. Migrations are almost always behind schedule and over budget.

Host 2

Almost always.

Host 1

The pressure from the C suite to just go live is immense.

Host 2

Let’s say a project team is under the gun. They skip the extensive exhaustive testing and only test the happy path.

Host 1

The perfectly sanitized scenarios exactly where every order is beautifully formatted, every item is perfectly in stock and quantities match exactly what actually happens in the production environment when the first exception hits.

Host 2

What’s fascinating about production environments is that they act as a relentless audit of your system.

Host 1

That’s a good way to put it.

Host 2

They will eventually find and exploit every single scenario you failed to test. Right?

Host 1

If you only test the happy path, your Monday morning go live immediately morphs into a crisis management exercise.

Host 2

I can imagine.

Host 1

Let’s say a trading partner sends an order with a completely missing N1 segment, which is the ship to address, or they request a quantity that forces a back order scenario.

Host 2

Because you didn’t test the exception handling, what does D365 do?

Host 1

It depends on the integration architecture and usually the outcome is bad.

Host 2

How bad?

Host 1

The order might silently fail in a middleware queue that no business user has access to monitor. So the customer thinks they placed an order but D365 doesn’t even know it exists.

Host 2

Oh, that’s terrible.

Host 1

Or worse, the integration forces the order through with corrupted or default data.

Host 2

So what happens then?

Host 1

Now the warehouse is trying to fulfill an order to a default dummy address. The shipping schedule is massively delayed and your IT staff is frantically trying to manually debug an EDI map while hundreds of live revenue generating orders are piling up behind it in the queue.

Host 2

And while it is debugging, the trading partners automated systems are tallying up chargebacks for every missed acknowledgement and every delayed ASN.

Host 1

Exactly. The financial bleeding starts immediately. This is why testing the ugly transactions isn’t just best practice, it’s financial protection.

Host 2

Absolutely. You have to throw the absolute kitchen sink at the system. Missing data, invalid items, incorrect units of measure, order cancellations, partial shipments.

Host 1

Precisely. You have to engineer failure to ensure the system handles it gracefully.

Host 2

Right. And this is where the strategy of parallel validation becomes your strongest asset.

Host 1

Parallel validation.

Host 2

Whenever practical, you run a parallel test. You take a live transaction from your legacy environment, process it through the new D365 environment, and compare the outputs side by side.

Host 1

Ah, I see.

Host 2

Does the D365 810 invoice produce the exact same total down to the penny as the legacy invoice?

Host 1

Are the tax and freight values behaving identically? Right?

Host 2

Are the allowances and charges mapped to the correct SAC segments? You must find these discrepancies before D365 becomes the system of record.

Host 1

And after all that testing, there is the cut over itself.

Host 2

The actual moment of truth. You can’t just flip a switch on a Friday at 5 p.m., send the team home for the weekend, and cross your fingers that Monday works out.

Host 1

No. Cut overs require military precision. You need a strict, heavily documented cut over plan. You have to define exactly what happens to transactions that arrive right in the middle of the cut over window. Do you queue them at the van? Do you cue them in the middleware?

Host 2

Right. Because business doesn’t stop.

Host 1

Exactly. And crucially, you need named individuals assigned to monitor the very first live transactions, like specific people.

Host 2

Yes, I don’t mean a vague, oh, the IT help desk will keep an eye on it. You want Susan from supply chain and David from IT actively watching the first 10850s hit the production system, watching it like a hawk.

Host 1

They need to verify that those specific orders flow all the way through to fulfillment and that the outbound documents are accepted by the trading partners network.

Host 2

It sounds exhausting but clearly necessary. Taking a step back from the granular mechanics of testing and mapping, all this effort naturally forces a much larger strategic conversation.

Host 1

It does.

Host 2

If you are doing a forensic inventory, purging legacy code, redesigning architecture, and engineering parallel tests I mean is your current EDI solution even worth keeping?

Host 1

That is the ultimate modernization question and it’s one every executive team needs to ask before they migrate. Right? If you are going through the immense organizational pain to migrate to Dynamics 365, you have to look critically at the vehicle you are driving your data in. Because if your current EDI environment is a patchwork of on-premise servers, outdated translation software, heavily manual processes, or if it was inextricably tightly coupled to the proprietary database structure of your old legacy ERP, which is very common, trying to drag that architectural dinosaur into the cloud native D365 era might be a catastrophic mistake.