Inventory is the lifeblood of many companies, and inaccurate inventory can cripple even the most profitable supply chain. Businesses of any moderate size employ counting processes to keep the inventory accurate, usually splitting them into Physical Inventories and Cycle Counts, as separate functions. Oracle Cloud offers comprehensive tools for both, but many implementers do not have extensive experience with both tasks on a real warehouse floor, or rely on clients, who take the shortcut option of a lift-and-shift instead of true optimization, to drive design.
Cycle Counts vs. Physical Inventories
There are many differences in these two approaches for counting inventory. Cycle Counts are a way to count a limited selection of inventory on a regular basis. The selection is based on a classification of inventory into groups or buckets, the amount of times per year you wish to count each bucket, and the on hand inventory in each bucket at the count sequence generation moment.
Physical Inventories are a way to count all of the inventory in one moment, often as part of an annual process which may involve a secondary audit that is performed outside of Oracle. In this secondary audit, the auditor may make a selection of the inventory randomly, with the sample size guided by AQL, to do a “floor to sheet” and “sheet to floor” audit. In the floor to sheet selection, they will randomly select inventory and compare the findings to the system record; while in sheet to floor they will select inventory records and compare the findings on the floor.
Practically speaking in Oracle, a Cycle Count requires you to
- generate the list of buckets, such as A, B and C
- select the bucketing method, such as on hand value or transaction quantities
- bucketize the inventory item codes based on the current data set and the settings for each bucket
The cycle count will generate the list of items and locations to count based on this selection criteria, as well as the current on hand inventory at the moment when the sequences are generated.
Whereas, a physical inventory uses a much more basic selection criteria: Everything in a given subinventory or group of subinventories.
Comparing System to Count Quantities
During the counting process, a cycle count allows you to continue to move inventory, as long as your physical and system transactions are occurring at the same time. That is to say, if you have inventory in Location 1 when the sequences are generated, but before you count them the inventory was moved to Location 2. When you go to Location 1 to count, you will report 0 quantity; Oracle sees that current expected quantity in Location 1 is now 0 as well, so no adjustment is performed and your inventory is 100% accurate.
However a physical inventory does not update expected quantities, and it will perform an adjustment to reduce inventory in Location 1 to 0; if you did the transaction in the system, then the system will take inventory negative or display an error, depending on how you have negative transactions configured at the inventory organization. And in Location 2, it will duplicate the on hand inventory, because it will create a positive adjustment for the quantity, as it expected 0. This means that during a physical inventory, all physical movements of inventory must be frozen; and this is typically a problem as urgent issues arise, and higher up’s order that production or receipts or shipments must continue
Counting
From a counting perspective, both counts direct a user to a location to perform a count, indicating the organization, subinventory, locator, item, lot, serial, etc. However, in a cycle count, users are only counting the locations that they were directed to, which may not include all locators in a subinventory. In a physical inventory, they would have a tag for every locator. The fact that a Physical calls it a Tag, where the Cycle Count calls it a Sequence, and the fact that the tag and sequence print outs may look slightly different, does not fundamentally change what data is being collected, it is very similar. Both exist as reports that may be modified; both accept API input and may be filled using a handheld device or spreadsheet connected via Visual Builder Add in for Excel.
Cycle Count Listing and Entry
Physical Inventory Tag and Entry
Approvals
There are differences in the approval and recounting processes. A cycle count sequence is approved individually, where a physical inventory is approved as a whole. This fact, combined with the fact that a physical inventory does not update the Expected On Hand Quantities when a transaction is performed, mean that all physical movements of inventory for any purpose must cease from the moment the snapshot is generated, to the moment that all adjustments are posted.
This often causes a problem during analysis ahead of approving an adjustment. Because you are changing the on hand inventory valuations, which has a financial and operational impact, it is common to analyze and determine the materiality of the adjustments. If you are missing a small dollar amount of material, both individually and in sum, and the quantities are unlikely to impact any operational plans, then you can easily approve and close the physical inventory. However, if you have any large adjustments, in either direction, your Finance team may require that you either locate or atleast explain the discrepancy prior to posting.
While it is possible to discard a tag and not perform the adjustment, many teams operate under a principle that a physical inventory must be complete, and they worry that discarding the count will result in those tags never being completed. Now, the Inventory Manager is operating under immense pressure. Already tired from potentially days of 24/7 counting, there is pressure from Finance not to proceed with closing the count until the discrepancy is eliminated or explained. Simultaneously, pressure from the CEO and Operations and Planning teams to post the counts and continue with production and shipping goods. Last but not least, pressure from Auditors to not discard the counts.
Cycle Count Task for PI
This is where you may consider abandoning the “Physical Inventory task” and using the Cycle Count task with settings that replicate the principles of a Physical Inventory. There are a few ways to accomplish something similar, but the overall idea is that you feed the system with parameters that cause it generate a Sequence for every inventory in the system.
For example, you could create an ABC Classification Set with a single classification, and set the valuation to include 100% of items. Or, after creating an ABC Classification Set with multiple classes, in the cycle count header settings, set the count frequency combined with the counts per year, so that if you have a weekly schedule, you set each class to count 52x per year. Finally, you could use a tool like Visual Builder Add in for Excel to update the Include in Schedule flag for all items to Yes, to force all items to get included on the count sequences.
A physical inventory is meant to count not just all items, but all locators, anywhere that inventory could be found, it should be counted. This is why many counters use a tag system, labeling inventory as it is counted so you can visually see all items and confirm they were included. Both the Physical Inventory and Cycle Count tasks allow you to add additional tags or sequences. In a Physical Inventory, you generate Blank Tags. In a Cycle Count, you set it up for Allow Manual Sequences.
Then, for this CC turned PI, you clearly instruct your teams that, while they may be following the sequences around the warehouse, they need to physically inspect all inventory. If you need “tags” to place on items, you can create a custom report that makes them in whichever style you prefer. Then, if you find items that aren’t on sequences, and aren’t tagged, you enter those as a manual count.
After counting is complete, we find our huge advantage: If the counts match or adjustments are non material, you post those by themselves, and those items may begin moving again for production. Of course, you could have continued to receive items during the count as well, as things are not frozen by a Cycle Count. And finally, if you have items with a large discrepancy, you can issue recount requests, and delay the recount, and you will only be impacting those specific items, not all production.
And the count will still be complete in the end, as you have reporting on any adjustments made during the cycle count, and can easily report on cycle count accuracy. It is the best of all worlds, and everyone wins. There is very little reason to ever use the Physical Inventory function and streamlining to just use one task also results in fewer test scenarios and training requirements.
Summary
- Before starting either count, make sure you have read my article on why we count: Creating Correct Cycle Count Culture
- Review the flowcharts below, which I use with every client as a guide more practical than Oracle’s documentation, to make sure you understand the process.
- Test your counting processes well in SIT and UAT, thinking practically: With real data, do these parameters generate a volume of count sequences that is aligned to our available manpower and time?
- Consider how Visual Builder Add in for Excel, plus custom reports for count sequences and count results, can help your business.
- When you need to count everything, consider using Cycle Count settings that mimic a Physical Inventory, and instructing your teams to apply a “count everything” mindset using manual count entries for items not on a Sequence.
- Finally, celebrate your successes and share with others how Oracle is helping your business keep inventory flowing!
- Bonus Item: Upvote my Idea in Oracle Cloud Customer Connect to officially merge the two tasks! Oracle Cloud Connect Idea: Combine PI and CC Functions
