@JasonCampbell and @ckrusen, thanks for the info.
We are fine having the cost being solely in the expense account and NOT wrapped into the COS. Since this is the case, we can receive the PO, have it hit an expense account, but still keep the items in a BOM with a quantity (again, assuming they are non-quantity bearing but still stocked items)
And I think I understand the exception, and don’t anticipate ever doing that.
Cheers,
Alex
As long as you don’t actually issue those “pre-expensed” parts to the job they’d never get into wip or COS.
You’d have to give it more thought if you backflush, or use STD costing.
@JasonCampbell - There would be a variance if the parent part uses STD costing and is costed based on the BOM roll-up, which would include a cost for the expensed part. When all the materials are issued (except for the expensed part), there would be a difference. Thus a Variance generated.
I think the cleanest thing to do is
Typical flow would be like so:
Because this part isn’t inventory, and it’s QOH may not actually match the actual amount, a qty adj can be dine using the reason code created above. This will reduces the QOH, but cause no change to the GL (it would credit and debit the same account).
Exclude this part class when doing a Physical inventory or running Stock Status.
A good side affect of it being qty bearing, is that you’ll know if you have the parts to meet demand. As long as the Qty Adj is done regularly to make up for when the parts are used for non-system things (building maintenance, R&D, “government jobs”, etc…)
Thank you for the insight! I think we have a good path forward.
My two cents.
Agreed with everything said so far, but you all implement this far differently than we do.
Small nuts and bolts (etc.) are expense here. In setup, this means they are:
This means the cost goes to the jobs but the inventory quantity is always zero. It gives us (more) accurate job costing without managing the inventory.
Big disadvantage to me is that non-qty-bearing parts MUST be standard costed. Ugh. We wanted it to be last for expense parts. If we don’t even want to manage the inventory, why on earth would we want to micromanage the cost of items worth pennies?!
Does MRP or PO Suggestions create PO’s (of type PUR-MTL) for those non-qty bearing parts in BOM’s?
(edit: fixed tran type, as there is no PUR-MFG)
PUR-MTL, right? Well, we don’t buy direct, so I don’t actually know the answer to that. I would guess no, because I have ran into something like that before.
Our parts are non-stock = false; qty-bearing = false. We get no PO suggestions, but that’s obvious because you’d never know when you are out.
Just a small amateur accounting question:
If costs are expensed (hitting the Income Statement once) and then are issued to a job (job-cost), are you not double expensing when that costs are later flushed from WIP upon close (hitting the Income Statement a second time)?
If the GLC’s are setup right the Expense Account will get debited (or is it credited? - whatever is the opposite of what happens when the Job is costed)
I’d be interested in seeing the T-accounts for the three transactions that makes that work. It’s REALLY important to get those GL Controls right though!
PUR-UKN
STK-MFG
MFG-STK (or CUS)
Im not sure if the STK-MTL happens for non-qty bearing parts.
We have some parts that are “mostly” shop supplies, but some times used on jobs or orders. We have them marked as Qty Bearing, but have a part class that uses an expense GL Acct, instead of the standard Inventory Acct. We exclude these from inventory counts.
Purchases are “to stock” (PUR-STK), and are “expensed” upon receipt, by the fact that the shop supplies expense is hit.
If we include a shop supplies part on an order (or job), a STK-CUS (or STK-MTL) tran happens, and the shop supplies account is credited.
So then the costs are not going to the job like Jason was saying? This is what raised my eyebrow. As I said, I’m an amateur accountant so I could be completely wrong. Of course the best way to prove these things is with a Pilot Database and a little time…
It does. That’s what this pic is showing:
Epicor didn’t establish a UKN-MTL transaction; it’s just STK-MTL and you have to just know that it’s non-QB.
And those STK-MTL parttrans have the InventoryTrans field cleared?
edit:
and if you run WIP Recon report for a job that uses non-Qty Bearing parts, what GL account is credited when the WIP gets debited?
Part 800427, non-QB, has standard cost (of like $0.03).
Job Tracker:
Inv-WIP:
Part Tran History:
I’m not believing the Invty flag, though. Or it’s vague and meaningless…?
Edit:
I should have skipped the MFG-STK, as it confuses what you are looking at. That’s a normal, qty-bearing part.
But point is, 800427 has an “expense” part class that goes to the fasteners expense account. So it gets hit on the receipt and the issue (backflush).
Great test! Just a few more questions (because the devil is in the detail) 
Was the Expense Acct for P/N 800427 set on the Part, or Part Class (or something else)?
Does it matter the method for how the material was “issued” (back flushing, Mtl Issue, Mass Issue)?
And don’t feel necessary to run the tests. Those are questions that hopefully someone knows off the top of their head.
Part Class. But I’m sure Part would work, it’s in the hierarchy ahead of class.
I mean, we always backflush most everything (except for raw steel and serialized parts), but I don’t think it would matter.
The only oddball I have seen with issue vs. backflush vs. mass issue is in Epicor’s algorithm to calculate ABC codes. Apparently some populate Plant2 on the PartTran table and some don’t, and that skews the ABC codes to disfavor serialized parts for us who backflush everything. 
I think a request to allow non-qty-bearing parts to use cost method LAST is in order.
If I set the STD cost of the non-QB part to $1.25, and place a PO for it at $1.05, it makes a GL tran of $1.05 (per unit qty), and no variance is created.
Then when the STK-MTL occurs, the GL tran created is for $1.25 per.
I vote you do it, Calvin. I think I get on their nerves at support. Mindy and Leigh in Finance are pretty awesome, though.
FYI, another hurdle is that the last cost never gets updated on PUR-UKN receipts. Only quantity-bearing transactions will update last cost. A MFG-CUS transaction on a QB non-stock item does update last cost, though.
Calvin,
In your suggestion, can you confirm:
Don’t you want to set Qty Bearing = False (unchecked)?
Thanks!
I don’t recall all the details of this thread, But I think the reason I made it Qty Bearing, was so that it could use LAST or AVG method. Setting Qty Bearing to false automatically sets its cost method to STD.
