We are working on tracking our consumable/expensed inventory in Epicor. We’ve got a new part class and reason codes to make sure the expenses stay in the right GL accounts.
However, when we create a new PO for a part with this new part class from our PO suggestions, the default G/L Account for the PO release is a suspense account from some other GL Control, I think the default for AP Account.
When I receive this PO into inventory and then Capture COS/WIP to see which accounts get hit, the accounts specified in the Part Class’s GL control are the one’s getting hit. BUT, I see 2 transactions of 0.00 hitting that SUSPENSE account.
I would expect an account from the GL Control Code on the Part Class to get pulled in as the default for the PO release, but when I generate a PO manually and click “Get Default” it will still pull in that SUSPENSE account that is nowhere to be found on my part class’s GL Control Code.
I also looked through this post PO Release GL Default Account and it seems like I have the right expectations for the default account.
Our accounting department’s biggest concern with this project is making sure the expenses stay in the right accounts. So when this suspense account is getting pulled in on a PO, it doesn’t giving us the warm and fuzzy feeling we were looking for! We are still in the testing phase fortunately.
Any ideas as to how I can get the default account to pull in the one that’s on the part class?
I believe Part Class GL Control is rightly mapped the Expense GL against the “Inventory/Expense” context.
If, 1 is yes, then looks like the part in question is Stock item and Qty bearing setup. Moreover, in Company configuration you have enable the Invoice for Receipt tick box in AP module. Which means it first goes to clearing account (mapped at company level against AP GL Control).
Suggest to make the part as non-qty bearing (this will be treated as Other part type like services) and will pull expense account at the time of PO creation.
Thanks for the reply Rakesh. We are trying to get PO suggestions for these consumables/parts, so we need them marked as quantity bearing for that to work unfortunately.
Are the PO suggestions for these parts being driven by demand for a Job, or from Inv Minimums?
If for the Job, it might be trying to force the PO to be “Buy to Job” (which shouldn’t be able to happen for Qty Bearing parts). Check that the PO suggestion generated PO is buy to Inventory.
Another thing to double check is if the generated PO has the proper Part class. It should have been set to whatever the Part’s PC is. If it is a job component, is there something in the job that is messing with setting the PC in the PO?
edit
I assume that manually making a PO for the part flows as expected (Hits the Expense account set by the Part Class GL Control). That correct?
The suggestions are from Inv. minimums. This is a consumable that will be misc. issued eventually. The PO suggestion is pulling in the correct part class by the looks of it.
I’m by no means a finance guru, so this situation is really confusing me. Even though the default GL account on the PO pulls in a SUSPENSE account, whenever I receive the PO into inventory and Capture COS/WIP, it looks like it just hits the AP clearing and expense accounts specified in the part class. No sign of any SUSPENSE transactions in chart tracker.
BUT there were transactions on the TranGLC table for 0.00 on that SUSPENSE account. These don’t have a fiscal year or journal tied to them, so I was pretty confused why/how they were made in the first place. Since they don’t show in the chart tracker, I’m assuming they don’t do anything.
So I’m thinking this isn’t really causing any issues with posting, outside of what’s being displayed on the PO. I was just under the impression it would show the account on the part class as the default.
The Inv WIP Recon report will not show any zero dollar transactions.
If you manually create a PO for an On The Fly part, and select the Class used by your inventory part, does it automatically set the GL account properly? And if not automatically, does hitting Get Default set it to the acct specified by the PC GL Control?
No account is getting pulled in for an on-the-fly part PO (Buy for: Other). If I switch to another part class we use, it pulls in a default account. So I’m thinking something is wrong with how I’ve got the GL control set up maybe. Good thinking testing the part on the fly!
The way I had the GL control on that part class set up, it didn’t specify the division segment. From what I had seen from the posting process, the division segment gets selected based on the site the transactions are taking place. So I left it blank on the GL Control Code, thinking the segment would get filled automatically during the posting process. Apparently I was wrong for this case. It wouldn’t pull in the account to the PO release without having every segment defined on the control code.
So does each segment for an account on a GL Control Code need to be fully defined every time (see below)? Will it automatically change the division segment if it needs to?
And I don’t think it should be blank in the GL Control. The GL Acct should be fully specified in the GL Control. That way if the derived GL acct (from replacing the Div segment) doesn’t exist, it will use what is in the GL control.
We are still in the testing phase fortunately.
