Warning! PO release for “Other” ignores Part GL code

Well this was a swift kick in the pants today. It’s fully documented, but wow I did not expect this at all. Ready?

So, general rule in any kind of transaction is:

  1. If there is a GL on the Part, use that first
  2. Otherwise look for a GL on the Part Class
  3. Then look other places

All normal so far, right? OK great.

I have a part (920457) that

  • Is non-quantity-bearing
  • Has a GL control on the Part itself
  • Has a GL control on the Part Class also

Here is what actually happens with these transactions:

:white_check_mark: Ship 920457 to a customer (UKN-CUS): Part GL if any, then Class GL
:white_check_mark: Issue 920457 to a job (STK-MTL): Part GL if any, then Class GL
:bulb: (There is no UKN-MTL, by the way; STK-MTL is used even for non-QB)
:x: Buy 920457 on a PO (PUR-UKN): Ignore Part GL and start with Part Class

Well isn’t that something else. We are buying this part into a different accounting bucket than we are issuing it from. #LearnedThatTheHardWay

(FYI, PUR-STK looks at Part GL, then Part Class. :man_facepalming:)

I guess I’ll report this (@hasokeric would want me to have that fun with support), but like I said, it’s totally documented as being this way, so it’s as designed, of course.

I try to avoid this word, but this is just flat-out stupid. Really.

Here are the docs (Expand it):


Good Luck :partying_face:


I agree, that this really is not an enhancement, but instead a consistency issue. However, I believe it would be possible to change your posting rules to get the part first.

1 Like

@hasokeric You’ll like this Idea: https://epicor-manufacturing.ideas.aha.io/ideas/ERP-I-684

I am fed up today. I made the masochistic mistake of looking at “My Problems” (can’t not laugh at that) in EpicCare. Years of reporting bugs that never get resolved. And PRB tickets that just disappear from EpicCare.