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.
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
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.
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.
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.
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).
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).