WIP Recon uses the GL posting engine to determine what accounts would be hit by the various transactions. But the GL posting engine will not create a transaction that would have a zero dollar debit and credit. If the Cost of the shipped part was zero when it was shipped, then the MFG-CUS parttran record would have a zero cost. So it wouldn’t appear on the WIP Recon.
Before we try to make a BAQ, Open the Job in Job Tracker. Then run the Production Detail Report (Actions->Print->Production Detail). Make sure the Print Material Transactions box is selected.
Check that the Ship Date (in the SHIPPING ACTIVITY section), is after the Date in the Material Transactions section… In the following example, The job was shipped on 9/26/2019, which was before the material was issues on 9/27/19. Therefore the job had no cost at the time it was shipped.
Note that even if the dates are the same, the order could have been
- Create packer and mark as shipped. At this point the job has no cost.
- Issue Materials to the Job.Now costs have been added to WIP, but the job has already shipped.
And at the bottom of the Prod Detail Report:
@ABertier - Much simpler way to determine if costs are still in WIP. Just run the WIP report in Prod Mngmnt -> Job Mngmnt -> Reports. Use the filter tab to add your specif job number.
It will show value of WIP in the job. If you see something like:
That shows that costs are in the job and not COS. If this is the case, you’ll need to close the Job. This will create a MFG-VAR transaction. And that will show on your WIP Recon for the job in question. Accounting can then do a GL to move the cost from the Variance account, to the desired COS acct.
Yes, from all of these areas you’ve suggested, this is the case. It still sits in WIP. Now I have to figure out why the WIP report has slightly different numbers than IV/WIP. UGH this system is soooo messed up.
The value shown in the Material column of thw WIP row, (on the WIP Report), should equal the value of the STK-MTL trans on the WIP Recon Report.
I’d bet on the original problem being the packer was created before the material was issued.
If you have access to the BAQ Designer, you can import the attached BAQ. It will prompt you for a Job Number., and then return all the Parttran records with that Job num. It sorts by transaction number, which indicates the order the transactions happened in.
In my example:
Note that the MFG-CUS transaction happens before any of the STK-MTL transactions. That is a clear indicator that the packer was processed first.
Here’s the BAQ: E10H-TranGLC-Packer.baq (14.8 KB)
Thank you for trying to help! I’ve since found out that it was due to the Part being set up with a Costing Method of STD versus Last.