EDI Makes it to Demand Entry, but locks header with no errors and doesn't generate sales order

The EDI file gets processed, doesn’t error out and get sent to demand workbench but stays in demand entry with “Header Locked” but there are no errors to be found (that I can see) as to why it locked it and why it didn’t just process it into a sales order like the rest of the files.

Anything I should be looking at???

Thanks in advance for any help y’all.

:pray:

1 Like

Process any demand that is in the Workbench, clear out Demand Entry, and then try to reprocess it.

when you say clear out demand entry, just make sure it’s all posted yeah?

Either posted, rejected, deleted. Basically, process it as would be done normally. Anything that is ‘stuck stuck’ in there you may just have to delete (if there is anything).

Following that, reprocess (Import) what was previously getting stuck and see if it goes through this time.

So what I found is that they had a part in the file that was not set up on the contract, but the odd part is, it goes all the way to demand entry and nothing comes up anywhere, demand mass review, demand workbench, nowhere in the ERP does it show the line that was the actual error.

The only place I can find the error was in the import log on the server where it says:

09/30/24 10:07:59 (Machine:localhost PID:1368 Database:----------) Import Process - Creating Demand Detail. Part: , Rev: , Cust. Part: custompart, Cust. Rev:
09/30/24 10:07:59 (Machine:localhost PID:1368 Database:-----------) Invalid Unit of Measure

You should have been able to see that log entry in Demand Entry > Actions > Schedule > Log (or is it Actions > Line > Log ?)

We don’t have the EDI module(s) enabled here, so I can’t open the menu to verify any of what I am thinking.

Demand Workbench/Entry can be a little tough to work through sometimes. We “pre-translate” in EDIHQ as much as we can…and let Demand Management just handle the basics. We occasionally get demand header locks if there’s an issue with one or more line items…the only common hard error at the header level is usually an invalid ship-to.

At the line level, biggest pain point is an invalid part. In our case it usually comes in as NOT_FOUND, which points back to EDI HQ and a missing crossreference number under that customer. We needed to externalize it because of variations in ordering UOMs.

Generally speaking we sell/ship in case quantities. We have customers that order in cases. Easy peasy. Then we have customers that order in eaches…so we convert quantity/price to case levels before it hits Demand Management. And we have customers that order in eaches but it represents a case selling unit on their end.

1 Like

So how are you handling this? And when you mean “externalize” do you mean, put the part cross reference logic in EDIHQ? I feel like that’s a huge redundancy cause you’re already defining it in demand contract entry and customer part cross ref in Epicor, would you then be doing it all over again in EDIHQ? Sounds hard to administer.

Yes, we have the primary part crossref translation in EDIHQ. It’s actually been easier to manage there because of the UOM conversions required inbound and outbound. We even have some customers with invoices in eaches and ASNs in cases. I believe our demand contract entry records are being created on the fly…and as long as the EDIHQ crossref is in place, all of our docs seem to flow in both directions without any trouble.

1 Like

wow, pretty wild!

Not gonna lie…we do get the occasional NOT_FOUND lines…but they aren’t day-to-day occurrences.

Most common reason is the periodic planogram reset for a retail trading partner. They pick up new SKUs, they place their initial orders, the orders fail out if we don’t get a heads-up from the salesrep/broker that handles the customer. If it happens - nuke the entire order in Demand Workbench (and/or delete from Demand Entry if it gets as far as “demand header locked”)…add the customer/part to the EDIHQ conversion table…remap the orders.

Second most common is a riff on the first…customer X decided to change the casepack on one of their private label items.

1 Like

Do you use advanced UOM john?

Yes - our parts are pretty simple structure-wise. We employ CT as our base unit across the board on stocking parts…that’s how we sell/manufacture/forecast. Also have EA for the casepack (5,6,10,12,whatever), PL for the per-pallet count (40,64,80,whatever).

1 Like

So you do use advanced unit of measure?

Do you do anything in area or length at all? For the semifinished or raws?

We do have L/W/H dimensions set up at the CT level for cubic feet (as some partners want volume calculated)…raw components are usually either LB (raw paper) or EA (cartons, lids, labels).

1 Like

Thanks, were you always on Epicor or are you new to the ERP?

We’ve been live on Kinetic for about a year and a half…but I’ve been doing EDI stuff since prehistoric times.

Thanks, were you on Epicor before that or a different ERP system?

We were on ASW from Iptor (fka IBS)…used Cleo/Extol EEI for our EDI integration. And BPCS before that.

Now I’m getting a headache from trying to remember things that old.

1 Like

Sorry, don’t think too hard on my behalf!

Why did your company purchase advanced UOM, what benefits has it given you that the base product didn’t?