EDI Imports Set Credit Hold on customer with CreditSource = WEREHOLD

This situation has been going for for quite a while. This is on Epicor 10.2.400.14. I logged a Epicor Support call about this in June of 2021, and again this year, but no success so far. They have come to the conclusion that we should examine our inbound BPMs for our EDI process. I checked this on the original call, but this will be my next step, unless someone on here has a better idea.

Our daily EDI imports for orders are causing random customers to go on credit hold with a Customer.CreditHoldSource = WEREHOLD . It now happens every time I import a batch of EDI orders, but to many different customers, not the same each time. It happened very infrequently (about one every several months) until lately. The change is that we have three customers who do send us EDI orders that we DO want on credit hold. Now, there is a minimum of one customer that goes on credit hold each set of imports, and often up to five different customers that go on hold. Typically, in other situations of credit hold the Customer.CreditHoldSource will be ORDERS if the customer exceeded their credit limit or MANUAL if we clicked the checkbox in Customers. Epicor help states that these and INVOICES or CONTRACTS are the only other valid values here. I haven’t found anyone who can explain the WEREHOLD source. If anyone could shed any light on this, it would be much appreciated. These are happening where the credit limit of the customer = 0, but I have tried a billion dollars, as well. We also tried to recalculate customer credit with no success.

So, this is now happens twice a day, so I’ve tried to build a BPM to fix each customer where this happens, and I have not succeeded in getting these to switch back to CreditHold = false . I can use my same data directive and switch them to false in my TEST db if the CreditHoldSource is Manual with no issues. However, it does not seem to work with either a data directive in-transaction or standard nor does it work with a Post-processing directive on Customer.Update. So, it works if it is clicked in the Customer menu UI, but it seems as though the Customer.Update process is not firing during EDI imports, despite the CreditHold getting updated.

I also confirmed it was EDI setting this from the change log. I use an EDI user to only import EDI from a schedule that runs every minute:
image

Here is the screen shot of the Data Directive that is working in TEST. I have the same in LIVE, except the manual is replaced with “WEREHOLD” The Set Field 0 is setting Customer.CreditHold = false .

I would love to find out why this is happening, but I also would love if someone could help me fix the symptom, at least. Thanks!

@Steika To be sure it is not in a bpm I would use @jgiese.wci’s code to check for WEREHOLD in any bpm.

I actually disabled all of the credit hold messages and only stop shipments if MANUAL.

Based on this thread. I run my EDI fixes in ImportEDIPostProcessDemand.

Greg,
Thanks for the help and suggestions. I did run the code checker to find WEREHOLD and it only exists right now in the BPMs I have created to try to fix this issue. Nothing in customizations, which makes sense since these are not going in through the menus. I had never heard of werehold and have no idea what it means prior to this happening. Epicor support seems to share my confusion.

How did you the stop shipments only on Manual? Did you set both Sales order and shipment to warn and then put in a BPM stop for MANUAL on shipment?

And yes, @hkeric.wci was a ton of help to me in that thread on fixing our PartDtl. We have several BPMs that go on the ImportEDIPostProcessDemand. I think that is the right idea on most imports.

To stop shipments I have a MD on CustShip.GetHeadOrderInfo that checks if the customer of the order has CreditHold = true and CreditHoldSource=MANUAL and stop the pack from being made.

All other credit messages are suppressed.

I have an EDI routine called Fix EDI stuff that cleans up after demand import is run. If I had this issue I would check for WEREHOLD there and clear it.

Old thread that I never completed here, as we still don’t fully know the cause. However, we did get some new information on this recently.

Whenever we have a customer that has Credit Hold set and we are actively importing EDI demand for them, we get a lot of these WEREHOLD credit holds on other customers. So Customer A has credit hold, we import EDI for them, and after the daily imports, Customers B,C, and D get Credit Hold with reason WEREHOLD. Once we take that EDI customer back off of Credit Hold, these disappear entirely. It doesn’t seem to be a specific import after the Credit Hold customer. I have checked the logs to see the next imported or next customer imported and have not found the pattern on it.

I created a BPM that emails a few employees whenever we get a WEREHOLD CreditHoldSource, and one of us clears it away. Luckily, we don’t have many of our EDI customers go on credit hold, so this is a serviceable work around for the short-term.