When I run the Inventory / WIP Recon to get the activity for our 4 inventory GL accounts, the total activity for the period doesn’t equal the change in value on the month-end stock status reports. For instance, In April, Our semi-finished inventory had net activity of ($95,225.48) in April but the difference between the 4-30-20 and 3-31-20 stock status report for semi-finished had a change of ($80,157.81). The capture had been done through 4-30-20 and the period closed. There are no unposted entries for April. Any ideas?
Right, Epicor has documented that the SSR is not a subledger to the GL. See KB0034343. And backdating it is also just for curiosity. It’s not designed for perfect accuracy. It can’t. Things like changes in standard costs and qty-bearing (mid-month) will make it confusing, to say the least.
The article is pretty explanatory and Mindy, the author, is an excellent support rep.
The SSR is only accurate for QOH, and not the cost. The current cost is always used, regrdless of what date you specify when running the SSR.
WIP Recon will show either the Transaction Date (date when the system was told it happened) or the System Date (the date the transaction was created). The Capture COS/WIP process my assign a different date for the GL transaction created (the “Periodic Posting Process”)
The only time I’d expect them to match would be right after running the Capture COS/WIP process, and before any part transactions were performed. And even then, there’s quite a few scenarios where they wouldn’t match.
As long as there are no back dated trans (that force being captured into a period different from their tran date), the WIP Recon will match the changes to the GL. It had better - as its the same source that the Capture COS/WIP uses to make the GL trans.
The only way to use SSR for reconciliation with the Inventory GL, is if you run SSR right after the next period begins (aka 12:01 AM on May 1st). This will give you the opening value of stock for the upcoming period. And then compare this value to the report that was run on 12:01 AM on April 1st.
Again, this assumes that all transactions since 4/1 have apply dates of 4/1 or later.
The worst thing that accounting can do is to “correct” the Inventory GL with Journal Entries. Because whatever they think was missed, will eventually corrected by the system. Then they’ll just have to undo whatever their JE did.
I agree that reconciling to the Inventory / WIP Recon is the thing to do. The only problem is our bank and auditors would like a list of inventory that ties to the GL. How do I get an inventory listing that ties to the Inventory / WIP Recon and GL?
That’s where capturing the inventory by running the SSR report at 12:01 AM on the first day of the new period comes in. I just created a Schedule in the System Agent, set to run at 12:01 AM on the first day of each month (our FP’s match calendar months).
Then I run the report, but select the “12:01 AM First of the Month” for the schedule, and mark the “recurring” check box. Now instead of printing or previewing, I use the Email option. This way it goes right into my inbox. I’d suggest changing the format from PDF to Excel, so you could actually work with the data if you needed to. Your accountants might want a more “read only” copy, so maybe run the report twice. Once for PDF format, and the other for Excel format.
If your system isn’t set to send emails, then Choose an archive period of a week or more, and use the “Submit” (as opposed to Printing, Previewing, or Emailing). Then at 12:01 on the first, the report would appear in the System Monitor (Reports tab). And from there you could preview or print it.
edit
If running the SSR on a schedule using 12:01 on the first day of the period, make sure to set the SSR date on the form to “Dynamic” and “Yesterday”. Because you want the SSR value at 23:59:59 of the day before.
I agree that reconciling to the Inventory / WIP Recon is the thing to do. The only problem is our bank and auditors would like a list of inventory that ties to the GL. How do I get an inventory listing that ties to the Inventory / WIP Recon and GL?
As others have pointed out… the BEST way is to capture the reports in “real time”… the OLD School Way… Print the report at midnight and save it off. That will give the banks something to look at that will be an accurate snapshot of what it looked like at cutover. Anything else is a backwards recalculation, taking current real time values, and subtracting every transaction that happened since that point in time.
The SSR will be accurate, as it uses the Qty’s from Part Transactions, were are captured in real time. But it can “tricked” by a later back dated transaction. If it was run at 12:01 AM on May 1st, and then someone entered a PO Recpt on May 2nd, but dated the receipt as 4/30, that would make the SSR you ran at 12:01 on May 1st differ from running it on May 2nd, with an SSR date of 4/30.
The Capture COW/WIP, takes those part trans, summarizes them by GL acct and posts them to the GL.
Also, SSR looks at company part settings, even though transactions are actually based on the site. Quantity-Bearing is a big one to make the report maddening.
Also I learned the other day that the SSR ignores Sales Kits.A few things wrong with that. (1) Kits can have inventory, even if they shouldn’t. And (2) if you are like us the part is a kit in one site but not another.
Well, one simple way is to have inventory of it and then change it to a kit. Not a good idea, but I just tried it and it works. That was the site setting. And the company setting can be anything at any time.
I wonder if there is QOH of the Kit, and you go to ship one, if it reduces the QOH of the Kit part, or still does the components. Or worse case … Both.
I just did a test of a Transfer Order from site A to Site B (the SK part is Qty Bearing in each).
There is an Epicor Ideas ticket open to have a Inventory vs GL Reconciliation. it is Idea 4194. Perhaps if we can get everyone to go out and vote to make this a priority, we can get better inventory reporting that can be used for audits. Please go to the gL link below to vote.
