It is a Make To Order part that doesn’t have an entry in the part master. So you can’t use Part Trans History Tracker
But here is a query of the PartTrans table. This is everything that happened on the date in question (It’s in the test company, so no other part trans occurred)
the 1st line is the receipt of the Buy To Job
the 2nd is the issue of the material from stock
the 3rd is the first partial shipment of 5 of the 10 from the job
the 4th is the final shipment (with total shipped equaling the job’s Prod Qty)
Granted this example doesn’t have any variance, but that’s not the point. The main issue is that COS is not determined until the Job is completely shipped, or it is closed.
This holds true for Job to Stock parts - in an Average Costing environment. We’ve seen the first receipt go into stock with zero cost, and the later go in with a cost equal to the whole job. It causes problems when some of the initial receipt is shipped out (or even transferred to another site), because they happen at zero cost.
This thread would have been about two feet shorter if I’d known there was no part master setup for the part you are manufacturing. I must have missed that somewhere.
I am not a fan of using non-standard parts (parts without part masters) because you lose so much functionality and visibility. If you had set up WIDGET999 as a part, set it to both MTO and Quantity Bearing, set the costing method to average, you would get the results you want and a lot more traceability and sales reporting as a result. Any MTO part with a part master can have whatever BOM and Routing (MOM) you want to use and can be unique each time. You definitely wouldn’t use Standard Costing for a misc part number like WIDGET999.
I don’t have any companies using non-standard parts to ship to customers so I’d have to play around with it to see if there’s a setting that would allow it to pull costs for partial shipments like it was being average costed.
But given what you have now, I’d recommend you split the job for the partial quantities so the ship quantity and job prod qty (of the split job) is the same and the cost moves with it. I’ve not tested that, but based on your testing, that should solve your problem.
Otherwise, you should set up generic misc part numbers and use those instead on order entry like I described above.
