When using PO Suggestions today we get this for a small batch of parts:
This is a group of about 10 parts that it will not create a PO for. We can create it for other parts from the same vendor. They are formatted and setup the exact same way, nothing noticeably different. It is a part on a job BOM ordered for the job. The part itself is not in actually entered in Part Entry.
Anyone run into this before?
Thanks
Was the part number ever used on PO’s before? Perhaps the system is trying to use the GL Acct specified by a prior PO.
I’ve seen an issue where the UOM has problems if an On The Fly part was previously order with a different UOM class. Like the first time a pipe was ordered as 120 FT, and the next was 12 EA (for 10’ lengths of pipe).
It was not. When these on the fly parts are created it starts with the Job#, Then the name of what it is. There would never be the chance for a duplicate.
Your original post says “for a small patch of parts”. Taking that with your post about the “part number” being prefixed by the job num, is it the parts for one specific job?
It is. We have some systems that automatically create the jobs and add operations and material to it. These particular ones are on the fly parts created programmatically. There is a group of about 17 parts (across about 12 jobs) that PO Suggestions won’t work for. Yet, it will then work for a different job, same vendor, same type of on the fly part.
I have tried to compare JobMtl records between the ones that work, and the ones that don’t. It does not appear to have any differences (Except for the part number itself). Is there somewhere else I should be checking to see if there is something different?
After digging further I can manually create a PO with these parts, but there is one particular job where if I select “Get Default” for the G/L Account under the PO release, I get the same error. For a specific Job, or Job material, how does it assign the G/L account for a part on the fly?
One way to force a GL account would be to create a Part Class with that GL account assigned to it, and then write a BPM to populate that Part Class on all PO lines that use your POTF. Since you’re using job numbers in the POTF part number, I’m going to assume that the parts are Buy Direct to the job, so you could structure the BPM to look at those values and set the Part Class on the PO Suggestion accordingly.
They are buy direct. That makes sense. I think what I am more-so struggling with is I want to find the root of the issue versus creating a work around. I have narrowed it down to a couple of Jobs that are having the issue.
When I create a PO for a job material, how does it determine which G/L Account to use? Would this be tied to any information on the job itself? Trying to figure out why I would have 2 jobs from the same sales order, same vendor, same customer. I can get the G/L account for one line/release, but not for the other.
There is a document available on EpicWeb called “Inventory Transaction Hierarchy” that shows, for each transaction type, the path that it follows to determine both the Debit and Credit GL accounts. It’s pretty detailed and would certainly assist in your search.
Ah-ha! Finally found it! Thank you. Have been searching for hours. For whatever reason a couple jobs are being created without a product group. I added that in on Job entry and we are good to go. Thank you so much!
(if you could mark my answer as a solution I get brownie points. thanks!)
Already did 
Even without a product group set in job, there still should have been a default GL to use. Unless your accounting purposely didn’t want a default, in order to force people to enter one (hoping they’d enter the correct one), as opposed to just going with the default.
I would have thought Buy To Job would default to your WIP account.
Also curious why a Prod Grp would be the issue, when PG’s drive the sales end of things (like Revenue). Part Classes drive the supply end of things (like Inventory or Expense account)
I was following this hierarchy from the “Inventory Transaction Hierarchy” that Ernie pointed out:
With no PG specified, it should have defaulted to the WIP Material Acct from Company’s Inv, COS & WIP GL Control
