Capture COS/WIP for incorrect Period

Our Finance Team accidently ran the Capture COP/WIP and didn’t change the Period back to November so everything got posted to December.

What are the ramifications on this and is there anything you would advise that we can do?

Review the Inventory/WIP Reconciliation report for the period that was posted to make sure everything looks correct. Any labor entries that were submitted and approved for the period will be locked and you won’t be able to change them. All other part transactions (material issue, customer shipment, PO receipt) should be able to still be backed out if needed. The only transactions that are locked down that I’m aware of are labor entries.

Some part trans will be locked if there was invoicing performed against them:

  • MFG-CUS or STK-CUS on a packer that has been AR Invoiced
  • PUR-STK, PUR-MTL, etc… - on a receipt that has an AP invoice applied against it.

And are you really sure that November trans got posted to Dec? Unless Nov was closed, the transactions would be applied to the Nov FP. The “Periodic Posting Process” (PPP GL tran) entries will be dated using the original tran date, unless the FP is closed. And if it was closed, it moves them all to the 1st day of the current FP, so they would all be in PPP GL trans actions dated 12/1.

If the user forgot to change the date on the capture screen, it would have defaulted to posting the current period’s transactions, so the transactions should have been December transactions that got posted to December, while there are still November transactions that are unposted because of the mistake.

1 Like

Yeah, I forgot that in E10, the Starting Date is automatically determined by the Ending Date. Based on the settings in the screen shot above, unposted November transactions (actually, any transaction prior to 12/1/2020) would remain unposted.

But the V8 settings slightly different.

image

I forget what happens to old/outdated trans in V8

It looks to me like it should still just do the current period, but I never worked with V8 so you’re probably right. Without seeing the GL transactions/ Inv/WIP report after the capture I can’t say for certain that the V8 capture wouldn’t have done something weird with November’s transactions.

I thought it (V8) would warn you when unposted outdated trans exist, and force yo to fix them. That might have been V4 (Yes we ran Vista 4, with its FoxPro DB)

Thank you much for your reply.

How can I identify the GL transactions that got posted during the Capture COS/WIP process?
Nov. is still open.
Epicor has recommended that we need to do manual JE’s to reverse the cost.

Run the Inventory WIP Recon report. Play with the “Posted”, “Unposted”, and “Both” setting, as well as the dates. I believe you can also specify the FP and FY to limit the range of transactions (but only shows posted ones)

The JE’s is really the way to go. You should be able to get the JE’ necessary from the Summary at the end of the report.

I don’t recall if V8 has it, but in E10, you can specify a GL Code and line to find out the transactions that made up the “Periodic Posting Process” entries in the GL.

edit

Found an old image of the Inv/WIP Recon report form from V8

To see the details of a “PPP” entry, enter the Year and JrnlNum in the upper right fields. I believe most other fields will become disabled.

I have a BAQ going against the GLJrnDtl table. I see the transactions with “Periodic Posting Process” and have JE Dates in Nov and Posted Date of Dec. are these the one’s?

image

Yes. If you enter the FY and the JournalNum in the Inv/WIP Recon report (2020 and 191 in your example), it will give you the details of what makes up that GL Entry. It won’t be limited to a specific GL acct, it will show all the Part Transactions that were summarized together to make the Journal Number.

Thank you. The Inventory WIP Recon report helped give our team a clearer picture.

I made this mistake just Wednesday and accidentally ran 7/1/22-7/6/22 when I meant to run 6/1/22-6/30/22. Now I can’t run 6/1-6/30 because it says the date of 6/1 is earlier than the allowed earliest apply date of 7/1. Anything that can be done? We still have a ton of transactions to get in through 6/30 and I have to be able to run it 6/1-6/30.