If i manually try to reduce stock lower than the on hand quantity, i get an error message as per the screenshot below. Which is great.
However, if it is not a “user” or “manual” transaction, the system seems to let you fall into negative stock.
It seems to happen when a PI count adjustment is done and posted by the system itself.
Lets say for eg…the stock is frozen for a PI count and the on hand qty is 10
Lets then say 5 are counted, so the stock needs to be reduced by 5 to be correct.
However, whilst the PI count was happening more transactions have been done for that part and the actual on hand qty fell to say 2.
The PI adjustment of -5 is then later posted, and sure enough the stock falls to -3…we all know you can’t have negative stock so how can i prevent this from happening?
I’m not versed in E9 but I assume you could make a BPM that fires before
transaction, do the math check and cancel the transaction (and pop up a
warning) if needed
Hi, i have reviewed the “part class maintenance” negative Qty setup and for the part in question the class was correct and set to “stop”.
I also agree a BPM of some kind would probably be the best way forward…is a data directive or method directive the best approach? Has anyone got one already setup where they could attach screenshots?
I need to revisit this…the “error” message appears when you go less than zero, but it doesn’t prevent the transaction from happening. Its almost like its missing a STOP action of some kind.
Any help with writing the method directive for this would be much apprecited.
i’m not sure of the correct method code / business object etc.
So, just to recap…I need a BPM that triggers an error message to say “This transaction will send the On Hand Quantity of the bin to less than zero.”
AND it actually stops the transaction from occuring.
This is a verified bug in Epicor. I assume that you contacted them already and received an answer similar to mine… silence. Apparently they don’t want to fix it.
Any BPM I would write would respect the configuration concerning this while fixing the bug… I would advise the same for you.
Also, writing a method directive only affects those transactions performed with that directive. You’ll probably have to write dozens if not hundreds BPMs to cover this… hence Epicor’s reluctance to fix it. I would write a data directive; it covers all changes.
Hi Jim,
I sense your frustration!
Your right, i did contact epicor and they advised i wrote a bpm, although they didnt warn me how many.
I’ve written the below and its awaiting testing…in terms of epicor providing a fix, i don’t think they will now as they have said to us they will only provide fixes for E10.
