So I just want to see if the logic in my head for the help files makes sense. The help file shows as below. We sometimes have problems with the order of transactions in which the parts ordered for a job are not received before the operations are completed and the inventory backflushed. We average cost most everything, and so if we have never bought an item before, or never purchased it to inventory, the average cost is 0 (we are custom engineered so it happens quite often). What I’m thinking about doing is a periodic DMT of anything in the system with 0 average cost, but has an open PO with a line cost on it. I would make the average cost the same as the PO cost. For these parts, we have no inventory so there should be no effect on the GL, and if I am reading the help right, when the new transaction comes in, since there is no Prev Qty, it ends up basically being a last cost right? So there should be no harm in putting in an average cost on a part with no inventory, with the benefit of if something gets issued before it’s received we don’t have 0 cost transactions on the job messing with job costs, margins and future average costs. Any holes in this plan that you can see?
it’s a real problem, In the past I’ve overcome this by including that step in new part setup workflows. So whomever the stakeholder is for setting up new purchase parts, part of the procedure is to enter some expected value for the first receipt. Should that individual not have security rights, then it becomes a task for someone that does. Just an idea. This should not be made to be an IT task.
Like Rob says, this shouldn’t be an IT function. If accounting wants average costs then there needs to be some discipline around it. Our solution is a BPM to block receipt of inventory parts with no cost on the PO. Usually by receipt, they know what they’re going to be charged. And something is better than nothing…
Brandon, when you create a new part, average costed, do you use Cost
Adjustment screen to use as a starting point at least for that part cost?
You will see an adj-cost transaction the first time with no inventory
valuation because it is a new part. At least in that way your estimated
cost on your Job BOM’s would show, then as you actually receive materials
the average cost would then takeover based on the quantities being
received, issued to jobs, etc
Haha, I’m not IT. I’m a manufacturing engineer (and basically manage the ERP system with our IT guy, enter engineering data, in charge of job costing etc). Glad I can I fake it enough to fool you guys though.
We do not, that’s basically what I going to be doing. Being a custom engineered company we make a lot of new parts all of the time. So that’s where the DMT paired with a dashboard to feed in the information will help manage the quantity of adjustment that we have to do.
I’m glad I’m not the only one that has had this problem and it sounds like what I am planning on doing is the same solution other have used, which is create the cost adjustment ahead of time.
I made an updateable baq with security for the initial costing since as soon as you have a parttran record a part can’t be deleted. Every typo or duplicated part was stuck.
So you are saying that if you do it that way, it populates the costing without creating a PartTran record? I like that idea.
One of the things that will make it so that isn’t quite as much of a problem is that I am using an open PO line to get the cost. If it was erroneously created, there won’t be a PO for it, and I won’t have the issue of making PartTran record. But if I can avoid that I would still rather do that.
It’s probably a little dangerous, but can I theoretically map the baq fields so that when I run the BAQ it updates the average costs to what I’ve calculated (the PO unit price)? Obviously judicious filtering would be required, but that would help with the not having to change a huge list manually. Although, if we keep on top of it, may not be that unmanageable.
You are correct per your issue… transactions in the right sequence, to capture the proper costs… and PO’s for NEW parts (ergo no Last or Average Cost in the system), which makes QUOTING (Quote worksheet and cost evaluation) and a costed BOM report quite difficult!
BAQ for any part on PO where Last and/or Average cost = zero. (smart to adjust with DMT or SQL not with a real part-tran ADJ-cost as the record dis-allows part deletion)
Business process… “ANY” new top-level or sub-asm part MUST have a COSTED-BOM report generated to ensure valid cost-data
This would include OSP costing!!!
the formula you showed is accurate! When you have NO inventory, but you did load-in a cost for a part… since the current inventory would be zero when you actually receive the parts, the new cost for last and average will become the unit cost of the PO! [ERGO - accurate PO costs are beneficial]
Manufactured parts and un-timely production transactions.
4a) Prod-transactions after items shipped or moved to inventory ~ YIKES~
4b) Job for 100… 75 completed and moved to inventory yesterday at 2:00PM, before all prod-trans were entered at 3:00PM (avg-cost would be low)
Today… finish the 25, which picks up the transactions as of 3:00PM yesterday
transact the 25 off the job
subsequent transactions processed
Result: AVERAGE COSTs not representative of the actual costs.
IF you could ensure all prod-trans were done (and accurate - ha ha) before moving qty off job… life would be better!
We are average cost. most of our manufactured parts are produced to order. if i never do a job receipt to inventory, i am shipping from the job. will the system post a cost to the part?
if i do the stk-mfg transaction prior to shipping via mass issue to manufacturing.
report a job quantity complete through T&E entry.
No, and it shouldn’t. Epicor uses the Average Cost field to calculate the value of parts IN inventory. If something happens outside of inventory, that should not affect the cost of the parts in inventory. That would be an accounting nightware.
Would it be nice to have an Average Make Cost (and an Average Purchase Cost)? I know many users might like to see that. But even that’s a bit tricky. Do I want to include ALL jobs/POs in that calculation? Maybe not. I would think that it would not be too difficult of a BAQ to do once you know your company’s criteria though.
