Do Cycle Count variances create a GL Transaction anywhere?

Hi all,

Probably an easy question. We don’t have Epicor set up in it’s entirety unfortunately. We did start cycle counting recently; and i believe the way we handle part transactions at the moment (for GL purposes at least) is a “Usage” report is done, which is basically STK-UKN transactions * part cost; all those end up creating a journal entry manually and posting that.

Does the cycle counting hit a GL account automatically at the time of posting the cycle count variances? If so, where can I see that data? which tables are they stored in? Or are we stuck for now just creating manual journal entries based on that “Usage” report?


Yes. you can control what account it hits with GL control codes on your reason codes.
On your reason code you can specify which codes is a Count Discrepancy Reason. and on that code you can set a GL control and map the GL account you want.

It looks like we don’t have any GL Control Codes setup for any reason codes.

Am I correct in understanding we would need to use the WIP / Reconciliation report to view what hasn’t posted to the GL? I’m under the impression we don’t even use the WIP / Reconciliation and all of that is manual.

The Report shows you where the transaction will hit on the GL when you run the Capture COS /WIP activity.
If it were me, I would set up GL controls and run the capture wip process as opposed to doing journal entries, but im not a cost accountant. I just would rather set something up properly, then use the system to do the work for me.


1 Like

I agree; I think we’re running into an issue where Epicor was not properly implemented, so everything is done manually.

I need to do some more reading on the capture wip process, to see how we can begin to use the system properly.

The transaction guides from Epicor are really helpful and explain what happens to the GL when activities are conducted. Take a look at this document, review the ADJ-QTY section for Quantity Adjustments.

1 Like

Pretty sure that the “Posting” in Cycle count, only commits the counts entered, and creates Inventory Adjustments (PartTran type ADJ-QTY).

The GL isn’t actually hit until you run the Capture COS/WIP process.

You can see what the affect will be on the GL by running the WIP Recon report, and filter to just types ADJ-QTY.

At the end of the WIP Recon will be a table of the summarized GL Trans. You should just see two rows. One with the Debits and Credits to inventory GL, and another with the DB’s and CR’s for the offsetting account (most likely a variance account)

1 Like

@ckrusen, you are correct. All inventory transactions require the wip capture process to be run to impact the GL.

1 Like

I’ll take a look at the document, is the user guide a good reference for setting up inventory transactions?

Looks like we haven;t run the Capture COS process since 2009…

If you follow the guide, and review the transactions you conduct (you can see them in the wip capture), this will guide will let you know what accounts you need create for the each transaction.

Then your GL was probably fairly usless when it comes to Inventory related transactions.

In a nutshell…

  • Part Transactions (Receiving PO Receipts, Material issues, customer shipments, qty adjusts, etc …) Don’t create GL transactions. They are queued up to be summarized when the Capture process is run.
  • Posting the Capture COS/WIP process, posts those summaries to the GL

This is so that you don’t need have a GL transaction for every individual part transaction.

Use the Inventory WIP Recon report to see what GL transactions will be created(or were, if Capture COS was posted) It will list each transaction type, if it was posted, Job (if applicabple), Part Number, Debit Amt, Credit Amt, and transaction reference.

At the end, will be the summary of the GL transactions. These are the source of the “Periodic Posting Process” entries you see in the GL.

If you decide to run the WIP capture, since you havent ran it since 2009, you will move values to accounts that you have already moved with journal entries.

So; doing some reading and lookingat the GL Transaction Hierarchy document and other items I can find.

Is it possible to only run the Capture COS / Post for specific GL accounts? What we’re running into, is that we have an extremely manual process, and everything is done through different type of edit list. Is it possible we can automate some of these while working on other areas?

As an example; we receive parts into Inventory against a PO, and creates a PUR-STK transaction. We use the Issue Misc Material screen and a reason code (that isn’t tied to a GL control) to issue the material.These are parts used to fix machines as they break down. Accounting does a “Usage Report” and then manual create an Edit List to Debit / Credit specific GL accounts. Is it possible to automate that process and report against it?

the rest of our processes are similar and even further away from being implemented.

When we fisrt upgraded to V8 (from Vista 4), the GL posting engine threw lots of surprises at us. We didn’t even realize that the Capture Process had to be run.

For the longest time (and somewhat still), the accountants were their own worst enemies. They would do Journal Entries to “fix” errors like when the Inventory GL acct value didn’t match what they calculated based on receipts and issues.

Eventually the business action that was caused the “error” (like a PO Receipt being entered with a wrong date) would be corrected, and now the Inv GL account would be off by the amount of their earlier fix, and require a JE to undo their prior fix.

Back to your question …

You can’t run the Capture COS process for select part tran types. At least not without creating new posting rules - which would take you longer to implement than getting up to speed and using the system the right way.

You may be able to take advantage of the GL Controls to select which GL Accts are hit. And by separating where the costs go you can see which are from what process.

I strongly suggest finding a large whiteboard and making a chart like:

then you can follow the flow through the GL, based on business process.

Like how invnetory eventually flows to A/R