I have been asked to look at getting all rework labour to go to a specific GL account. Currently if we clock off any rework it posts to the same gl accounts as normal production labour. I thought that by changing the gl control code of the rework reason code, when you started/stopped rework activity, any labour costs would post to the rework gl - what is happening for us is that the costs post to the same gl as normal production labour.
We are trying to come up with a really simple means of catching internal rework costs for products being reworked BEFORE they go to the customer - for example we paint the product and the paint does not adhere properly meaning we need to repaint - we do not want to go through the DMR process just quickly systematically capture the labour costs of doing the rework - from there we would be able to report rework costs by reporting against the GL account.
We are obviously missing something - does anyone have any ideas of things we can check?
Perhaps consider customization of the GL CONTROL
When Capture is run, the transactions will look for the Product Group per WIP and COS.
Presuming the REWORK check box is on the part_tran record, then ‘flip’ the GL account.
If you want to Identify REWORK costs prior to sending items to the customer…
When is CAPTURE RUN per transaction on the shippable parts?!
If Capture is delayed, then the labor-trans will not be evaluated per re-work until after the item is out the door!
Is it simpler to BAQ/Dashboard all labor records and report any that are re-work… by JOB/OP, showing part Num? If Make-Direct?? then the link from Job to So to Customer will provide the data. Depending on who needs to know the details of re-work done (prior to shipping), then leverage the scheduled-ship date/need-by dates.
You may still want to drive Re-work costs to a different GL acct, but knowing in-process re-work per the dashboard may be best.
Suggest filtering to include ANY re-work labor for any un-shipped Job, or Job shipped within last 5-7 days.
Joe thanks for the reply. In terms of reporting this does not need to happen before shipment. All we want to do is have an easy way of capturing and identifying rework in any given period - non-conformity and dmr’s are too time consuming for us - example would be we paint a part on our automated paint line - operator notices it needs to be touched up or done again - they immediately either do the touch up work or put round the paint line - we want to capture the labour cost of this kind of rework quickly and easily without the need for non-conformance/dmr’s to be processed.
I had been messing about with this in test and have not shipped or closed or shipped the job. Would it be that if I ship and/or close this job the costs will be posted correctly in the GL.
A couple of thoughts, for large rework jobs we setup a job and use product group “rework”. The product code is tied to an account. We can add materials to the rework job as well as labor charges. It’s a bit simplistic but works to segregate accounting for rework.
One other thought, there’s the ability to check an operation on a job as an “added operation”. Now I guess this wouldn’t segregate the accounting of the additional work but would flag that it was added and you could segregate on your own for unexpected labor.
On end activity we added a qty passed for collecting quick quality data. If the qty passed is not equal to the qty completed then a rework operation is added to the job referencing the original operation. The add operation is based on a video @josecgomez made. We collect all of the time and cost for those rework operations by job, team and assembly.
