WIP Report Negative Costs

We are seeing strange issues with costs recently and are not sure what has suddenly changed. On this particular job, we are seeing a negative cost in WIP on the WIP report. When I look at the transactions on Job Tracker, I do not see any further transactions after the MFG-STK transaction. We use lot average cost and this job was split from a previous job. On the problem jobs, they typically have a job split involved so we are thinking it could be related to the split.

It could be a date issue when running the report. Below is a WIP report run from 5/1/23 to present for a job.

Then if I change the date to 7/1/23 to present I get the negative as the labor trans occurred prior to the start date if the Transaction Date Range.

Check that, my help. :face_with_monocle:

I had not considered that, but that did not make any difference. I normally have been running this report without a start date, but went ahead and selected a date just before any job activity and got the same results.

Hmmm. I’ve got a shot in the dark here. Run the Inventory/Wip Reconciliation Report for that job and see if there are any date mismatches between the Apply Date and System Date. Maybe something will pop up there?

@JYount I would think your first inclination of the split causing an issue is probably correct. Depending on how far you were into the job before it got split that can be a messy calculation.

Our accounting admin seemed certain this had something to do with the job splits. They are seeing this issue primarily in one building and on certain parts.

I do not have an accounting background, but trying to learn how all this works. Where would be a good resource to see how the job splits are calculated?

Looking at the Inventory/Wip Reconciliation report, $10,072.33 was credited to the WIP-Labor account on the receipt to inventory, but only $8,487.69 was debited. Seems like the job split did not move enough costs over. This aligns with the $-1,584.64 on the WIP report.

I have not really studied the process, but if you look at the job tracker assemblies transactions tab you will see the ADJ-MTL from the original to the new job. I don’t know how the labor is shown.

Debit : $8,487.69 actual cost of materials and labor applied to job (Material issuance, labor entry)
Credit : $10,072.33 Cost relieved of the top level part in Epicor after receipt to stk or shipment

$-1584.64 favorable mfg. variance. once the job is closed or capture run, this should move to the variance account from WIP.

Possibly this is related, but the reason accounting was alerted to this issue was because of the negative cost in WIP was not moving to the variance account on close. They said they had tried several things but could not get those costs to move. In our test database, I had unchecked WIP Cleared, reopened the job, and closed but costs still did not move.

Just out of curiosity, where did you Uncheck “WIP cleared”? I don’t see that option for me in Job entry. i could see it in Job Tracker (read only) and it’s automatically checked when Capture is run for month end closing.
When you ran the WIP reconciliation report, was the job closed then? or only the job was completed (received to stock) but still open for accounting? I know the variance does not move from WIP to variance account until the job is closed.
In the WIP recon report, what account do you see the $1584.64 applied against?

In your test database maybe you could test out doing the Capture and see if it clears the variance from WIP account. But this is strictly an Accounting function, so i would cordinate with them before hand.

> WIP Cleared Definition:

"Jobs are not automatically removed from WIP when they are closed. Instead, a closed job is relieved from WIP after you run the Capture COS and WIP Activity program. This lets you close jobs as they are finished, since these closed jobs will still appear on your WIP report until they have been cleared.

If you reopen a job that has already been relieved from WIP, the WIP Cleared option will remain selected until you post additional costs to the job."

The checkbox is on the Job Closing screen.

The Job was already closed when I ran the WIP reconciliation report.

I don’t see the $1584 anywhere on the report, but for the account 1351-05\WIP-Labor, the labor transactions total $8,487.69 in Debits but $10,072.31 in Credits from the MFG-STK transaction. I don’t quite understand why these values would not match.

When accounting ran the Capture COS and WIP on the 1st this month, there is a MFG-VAR transaction for only $0.03 for this job.

I’ll try running the capture COS and WIP in the test database.

Just thinking out loud i would if the job was closed in a previous month but was re-opened by someone after the capture was done. You could check the job audit log / change log in job tracker to see what took place.
Also, if you’re running capture in test database, check the box that states “Capture outdated transactions”. this will include in the capture and from prior months (based on from/to date defined) that did not get posted.

Ran the Capture COS/WIP process including capturing outdated transactions and no change. Based on the change logs, the receipt to inventory occurred on 8/30 and then the job was closed soon after. The Capture COS/WIP process ran on 9/1. When I looked at the production detail report initially, I did not see any unposted transactions.
I do also see for one operation, the reported quantity on the labor transactions was much higher, around 8500 pieces when most other operations before/after are around 4500 pieces. Not sure if this would cause this though. This was not the final operation.

When I look at the JobAsmbl table, the costs seem to match up with what was received to inventory. So where does the “To Date” line come from on the WIP report?

The “To Date” is the actual cost on the job so far to date.

From JobAsmbly table:
TLAMaterialCost + TLALaborCost + TLABurdenCost + TLASubcontractCost + TLAMtlBurCost +
LLAMaterialCost + LLALaborCost + LLABurdenCost + LLASubcontractCost + LLAMtlBurCost
= Total Actual Cost to Date

TLA = This level assembly costs
LLA = Lower level assembly costs (if subAssemby exist on the job)

I appreciate the help. This is what I figured, but not sure why my “To Date” costs are lower for labor and burden. My JobAsmbly table shows 10,072.31 for TLALaborCost but my “To Date” line is 8,487.69 which is why it’s showing the $-1,584.64 on the WIP line. Closing the job again has not moved those costs to the variance account.

I would ask you to check the Production detail report but the standard report is too convoluted and too busy to look at.

I could give you a BAQ you could download and import into BAQ and then analyze the “To date” labor cost. The query consist of the labor portion of the component material costs and the actual labor costs from the job operations.

Took another look at the production detail report and compared against the labor transactions and was able to narrow the issue down to a specific operation. For some reason, this operation is showing 92.50 actual setup hours when there is only a single Setup labor transaction for 9.78 hours. Any idea on where I can find out where these additional hours came from?

The difference between the Labor/Burden costs on the production detail report and the sum of the labor transactions for this operation matches with the $-5058 that was shown on my WIP report.

You could look at the job tracker to see which operation has these additional setup hrs.

Go to job tracker > Enter job number > Job Details tab > Operations tab > List

You might have to scroll to the right to find the actual setup and actual production hrs. i have mine setup this way below.

Also, you could highlight the operation with high setup hrs. and then click on the “Labor Transaction” tab and click retrieve to get the details of that operation from labor entry.

Here is the line from the production detail report.

And here are my labor transactions for that operation:

Not sure where the extra Setup hours come from or whether or not this is contributing to the additional 5,058 in costs shown on the production detail.