One of the ways that Oracle decides which new features to focus on, is by general community input in their Cloud Connect Community “Idea Lab.” Anyone can submit an idea, and anyone can vote for ideas that they prefer–including the ability to vote against an idea. I recently shared an idea for simplifying and improving inventory management in Oracle Fusion Cloud by combining two different counting tools into one.
Currently, Oracle has two ways to count inventory, Cycle Counting and Physical Inventory. There are some pretty big differences.
Physical Inventory is the older of the two, and it shows in everything from the menu structure to the simple ID values used in the rest api. Usually abbreviated as PI, this is a tool to count 100% of the items in a physical area. Usually performed rarely, like once a year, and during a complete business shutdown where all hands are on deck to count before it can be opened back up for business, you can’t even close the count until you have posted every single “tag” that was generated for the PI. And, during the PI, you cannot process any inventory transactions, because the system doesn’t know about transactions that happen after the snapshot.
Cycle Counts require you to set up support for “ABC,” a way to classify inventory. In reality, you can name the groups anything you wish, and you can have more than 3 of them, but the concept is that some inventory is expensive, some is cheap, some moves fast, some moves slow, etc. This makes sense even if you don’t normally run a warehouse. Imagine that you own a retail shop that sells jewelry. You probably check to make sure that no diamonds or gold jewelry are missing, more often than you check to make sure that all of the imitation costume jewelry is still there.
The Cycle Counting system uses the ABC classification rules you set up and the number of times per year you wish to count each class, compared to the current inventory situation at each sequence generation, to generate a small segment of stuff to count. If you have 100 pallets of goods in an area of your warehouse, the PI would direct you to count 100 pallets and you would have a big group of people counting all 100 as quickly as possible. The Cycle Count will tell you to count a small portion, say 5 pallets, and you would use a smaller team to count them. Even better, if you need to use 1 pallet for production between the time you generate the sequences, and the time you count them, the system knows that now, the expected on hand quantity is only 4 pallets. When you count 4 pallets, the system says the inventory is accurate and doesn’t adjust it. In a PI situation, the system would adjust out 1 pallet because the count of 4 is 1 less than the snapshot of 5.
During an implementation, having 2 methods to count, each of which require setup details and have different processes to run and different report layouts to learn, means a lot of extra effort is spent on conversion, configuration, change management, and testing. Oracle is currently working to change the existing pages from being based on ADF framework, to the Redwood framework, and combining the two features would mean they don’t need to migrate PI functions to Redwood, nor do they need to maintain two counting tools in the long term.
It could be as simple as this
- Rename “Cycle Counting” to simply “Counting”
- Add a flag within the count header to select whether the count style is Cycle or Physical, similar to how you can currently select to count by ABC or Categories
- If Cycle, keep the same settings and train stops as currently exist
- If Physical, disable access to the Item Categories and ABC Assignment train stops, similar to how you currently only have access to one train stop depending on if you select to count by ABC or by Item Category
- If Physical, disable the count frequency settings
- Add a new flag for “Post All Adjustments at Same Time” which would control whether you can approve individual adjustments or only post adjustments when all are approved
Ideally, with Physical selected, we would still have a way to manually control what items are listed, similar to how we do on Cycle Counting today. This would help with edge cases like manufacturers that store product for their customers, and their customers request an inventory of those items. The PI option under Counting would normally select 100% of items in a subinventory and organization, but with the ability to manually list items, users could override the selection of all items and list the individual items. This would be slightly superior to the other option, to create Manual Schedules.
If you think this sounds like a good idea, please go give an upvote and share your support! If you think it’s not fully baked yet and want to weigh in with your own thoughts, please do that, as well! One of the strengths of Oracle is how it supports such a wide variety of industries and this means features that work for everyone.