What is your costing method on the part? Does it match your system configuration? If they are different say your company config is AVG and the part is STD it will not update and you will need to do it manually.
We use AVG, so Qty Bearing parts are forced to use that Cost method.
This is a part we wouldn’t normally stock, and would ship right from WIP. But unfortunately, this needs to go to another site to be bundled with items there. So to do a Transfer Order, we must receive the part into stock here.
Here’s the order of things (steps 1-3 are all in site ‘A’)
Job created, with make to stock (qty of 3)
Mass issue parts to make all 3 to the job
Finish 1 unit and receive into stock
Issue Transfer Order to to ship to Site ‘B’
TO Receipt at site ‘B’
Running the Part Trans History for the item shows just 2 trans.
MFG-STK - Qty 1, at zero cost
STK - PLT - Qty 1, at zero cost
Running the production detail Report for the job shows that material was issued to job, prior to receipt of job to stock.
Start at the bottom, and also evaluate costing of COSTED BOM and the JOB Prod-detail-report (est and Act)
evaluate parts on the MOM… Cost method and the costing within the cost table
the details of the costs at the time of transaction will be in Part Transaction History table
Cost Method ~ some folks have STD-COST on Purchased parts, but NEVER update the STD-COST of a purch-part, or the part is new… is added to a MOM thru eng-wkbench and cost is never rolled!
Similarly, LAST or AVG cost will be zero on a virgin part, until received… so if the job is Released/scheduled prior to raw receipt… last and avg cost = zero… subsequently, the actual costs will hit job and be higher than estimate.
Part trans history will also help with sequence(especially if laborers are not transacting in a timely manner)
DUH… the raw stuff is sitting on the loading dock, not transacted into receiving (but inv quantity can be driven negative based on company config). Material gets issued to job (cost is ZERO) and qty goes neg… then the receiving tran occurs.
MOST LIKELY the finished GOOD part may be STD-COSTED!
Was the std-cost roll for this part done? Were all the costs properly loaded for all MOM parts. (see virgin part mentioned above)
If there was a virgin part on a STD-COST finished good that had no cost on it… then the mtl-cost (per std-cost roll) would be zero!
Transactions of parts off the job(ref trans being done out of sequence).
MES labor of prior OPS was not entered… the final OP is visual inspection (w/o labor).
Final op is transacted, before MES detail trans are input. (labor entry could also be delayed if using Time and Expense, but MTL is transacted prior to collecting labor.
Audit a few of the suspect JOBs thru Part Trans history and you will most likely solve the dilemma.
PDR (Production Detail Report) is quite valuable if you look into details on the report.
What are the EST values on the report? Material Labor Burden?
What are the Actuals??? " " "
Also run the COSTED BOM report
Costed BOM and PDR EST amounts should be equal!
When a JOB is Engineered/released/scheduled it is locking in the MOM per that REV "at the time of JOB Engineering.
The PDr will show detailed transactions (if you clk top 3 boxes on right of the rpt-gen-screen).
The details on the PDR are the actual trans in Part Tran History file!
Use a BAQ to restrict extraction to this specific job and REPORT ALL FIELDS !
The audit of these things (although has a lot of detailed data) will provide the insight you seek.
The MFG-STK trans will DEBIT WIP and CREDIT INVENTORY.
If the WIP values were ZERO… then the INV values will be ZERO (and if WIP values were not ero, then the INV values wil lnot be zero).
I would believe you have already reviewed the GL CONTROLS aligned to these raw parts… and the FG part to ensure the correct accounts are getting hit???
Is the top level part coded as “Non-stock” under part maintenance? I know before in Epicor version 9.xx that we tried to receive a non-stock part into stock and the transaction disappeared. In your case, at least you’re showing that MFG-STK transaction exist but at $0. Anyway, check the part table to see if it’s coded as non-stock. Maybe that would have something to do with it, if trying to received a part that is coded as non-stock.
Our qty “Completed” is always incorrect compared to actual production qty because multiple employees work on same operation throughout the days and may report qty completed (multiple people) by accident to same operation or not report qty completed at all. I know before i close all the jobs for accounting, i usually fix all the qty completed to match Run qty. But the jobs were received to stock or shipped to customer before i made any changes and they were always costed correctly (we’re using std cost mainly). A while back when we were in E9, i asked in Epicor forum if the “Qty completed” have any financial impact? The response was there is no impact. If anything, it has something to with scheduling. The qty completed is whatever labor qty reported against the last operation on the job.
How do you report Qty complete for a Job? We don’t track labor, so we never setup Shop employees, shifts, etc…
We do have MES (purchased WAY back with Vista 4 (circa 1997), but was never implemented.
I have played around with setting up a Shop Employee and using Office MES to enter production qtys, but that is so incredibly painful (at least compared to doing nothing).
OK, i looked up an average costed job that is shipped but not yet closed with Prod. Qty of 1 and “Qty Completed” of 0.
The results were similiar to yours. It looks like it is using the “Qty Completed” field to calculate cost. I use a modified version of Prod.detail report, so i never saw this before. re-wrote the whole report in crystal reports in Epicor 9 and carried it over to E10. but it seems like the SSRS report in E10 IS using Qty Completed to calculate Unit Cost.
Formula for Unit Cost from Production Detail report: if {JobHead.QtyCompleted}=0 then 0 else {#Job@TotalActCosts}/{JobHead.QtyCompleted}
Labor Qty procedure to correct the qty completed
Go to Job Management > Setup > Employee
We setup an dummy employee called “QTY Adjustment” with $0 labor rate.
Go to Job Management > General Operations > Time and Expense Entry.
enter the employee id then go to new Time detail from drop down
Then enter the job number, Asm, Operation (last opr on job) and Qty to be completed.
MAKE sure labor hrs and burden hrs are 0 since you dont want to add hrs but only complete the qty.
you need to run the Production detail report/Inv Wip report in order to calculate the cost prior receiving into Stock.
there is flag in Parttran called Costed.
So you are saying that if the Production Detail and WIP/Recon reports were run after issuing materials to the job, but before receiving part of the job into stock, it would have costed properly?
That doesn’t sound right. As far as I know, those two reports are strictly reports and don’t cause any updates to the db.
Costing is based on transactions on the job when the material is moved (unless it is stk-cost).
As far as COST reporting:
Once a MOM (part-rev) is moved out of Eng-Wkbench
Run a Costed BOM and the value here should be the same on the following…
Go to Quote workbench, import MOM and generate a COSTED worksheet for a QTY of 1
Since the MOM came from the approved Eng-wkbench MOM, costs are the same!
Create a JOB… run the PDR… the EST cost should be the same as long a QTY is the same!
Remember, set-up costs will be spread across increasing quantity of production, lessening UNIT COST
The cost “SHOULD” be representative of:
a) WHEN the PART-tran transaction to move material off the job was done… since any material and labor trans reported to the job would increase WIP (as per Product Group Accounts)
b) The PDR will show the actual costs, at the time the PDR was run!
Therefore, running the PDR now is somewhat meaningless, without consideration to exactly when the part came of the job via a MFG-STK or MFG-CUS transaction. Ergo… part transaction history tracker is vital! Comparing the PDR now (presuming labor trans and material trans to the job have been updated) and done so after the part was moved off the job will drive someone crazy w/o detail review of Part tran history.
CAPTURE routine: the capture routine will POST to the GL accounts!
But the accounting is already in-place! Why?
Think stk-status report… which can be run with an as-of date and will be correct, showing Inventory… as the mtl-cost was taken into WIP! Labor gets entered and the PDR can be actively ran… showing Actual $'s.
The associated GL accounts will not update until Capture, and post!
So there are differing areas of the DB that get updated as transactions take place, and as the Capture is posted.
I don’t think running PDR or WIp Recon report have any impact on costs in Db. They are just reports. The PDR “estimated cost” is determined based on what the cost in system was at the time of job creation. The “actual Cost” in PDR is based on the cost of components at time of material issuance. So estimated and actual material cost should be the same unless the component cost was updated after job creation but before material issuance to the job, then issued to job@new cost. The labor/burden costs for estimates are based on their method. The actual labor/burden cost is based on labor/burden costs of components issued + actual labor/burden costs entered via labor entry.
The WIP Recon report just shows you want transactions are going to be posted when you run Capture. just running the WIP recon report has no bearing on costs, it’s just a report showing what is to be posted when you run Capture. The WIP recon report do show something that does not show up in part tran. The MFG-VAR transaction of each job is shown in WIP recon report but not in part tran till the Capture is run at month end and transactions are posted.
Also, when i mentioned above on earlier post, even though the PDR calculated cost using “Completed Qty”, that is only on the report. On the part tran, the cost is calculated based on Qty transacted (Mfg-stk, mfg-cus, etc) of top level part of Job using the costing method assigned to top level part.
