US20190172003A1

US20190172003A1 - System and method for iterative improvements to re-count inventory rules

Info

Publication number: US20190172003A1
Application number: US16/212,062
Authority: US
Inventors: Robert Taylor; Justin Smith; Smita Sharda; Jyoti Malik; Megan Humphreys; Joshua Ridgeway
Original assignee: Walmart Apollo LLC
Current assignee: Walmart Apollo LLC
Priority date: 2017-12-06
Filing date: 2018-12-06
Publication date: 2019-06-06
Also published as: GB202010202D0; GB2583303A; WO2019113316A1; GB2583615A; US11138556B2; CA3085061A1; CA3085179A1; WO2019113314A1; US20190172004A1; GB202010207D0

Abstract

Systems, methods, and computer-readable storage media for providing adequate instructions to conduct an inventory of a store, and specifically a how to provide an accurate inventory of difficult to count items. As a store is performing an inventory, instructions to perform re-counts of specific items are sent. As the re-count begins, videos, text, or other materials needed to perform a complete re-count are distributed to the store associate performing the re-count task. If the re-count is outside pre-defined thresholds, an additional task to re-count the item may be assigned. Based on these actions, the set of rules used to identify when the re-count should occur can be modified.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This present patent application claims priority benefit from U.S. Provisional Patent Application Nos. 62/595,387 filed on Dec. 6, 2017, and 62/595,382 filed on Dec. 6, 2017, the entire content of which are hereby incorporated herein by reference.

BACKGROUND

1. Technical Field

The present disclosure relates to inventory systems, and more specifically to iterative improvements to re-count inventory rules.

2. Introduction

Taking inventory over a large store can be a time consuming process. Often, taking a complete inventory of a store can require working during off hours, hiring a third party to perform the inventory, and/or devoting multiple personnel to performing the inventory. Even with these efforts, the rushed nature of taking full inventory of a store makes taking a complete and accurate inventory difficult. Often, the amounts recorded are incorrect, resulting in a chain of problems such as customers not being able to find desired products, additional orders not being placed when they should be placed, or even improperly paying an inventory service for conducting an accurate inventory when the inventory was incorrect.

SUMMARY

A method of performing concepts disclosed herein can include: receiving, at a server, historical inventory amounts for individual stores in a plurality of stores; receiving, at the server, a store type for each store in the plurality of stores; receiving, at the server and from a store in the plurality of stores, product data for each product sold in the store, the product data comprising, for the each product: a product type; at least one product location; and at least one fixture type for the at least one product location; while an inventory of the store is being conducted: receiving, at the server, a current inventory count for each of the products sold within the store; identifying products within the store which need to be recounted by comparing the current inventory count for each product to: the historical inventory amounts for the each product across the plurality of stores; the historical inventory amount for the each product at the store; and inventory rules which take into account the product type, the store type, the at least one product location, and the at least one fixture type, to yield re-count tasks; transmitting, from the server and to the store: the re-count tasks; and store specific instructions for each of the re-count tasks, the store specific instructions based on the product type, the at least one product location, and the at least one fixture type; and receiving, from the store and in response to transmission of the re-count tasks and the store specific instructions, re-count inventory amounts for the products inventoried within the specific store which require the recount; and generating a finalized inventory based on the current inventory count for each of the products sold within the store and the re-count inventory amounts for the products inventoried within the specific store which require the recount.
A system configured according to this disclosure can include: a processor; and a computer-readable storage device having instructions stored which, when executed by the processor, cause the processor to perform operations comprising: receiving, at a server, historical inventory amounts for individual stores in a plurality of stores; receiving a store type for each store in the plurality of stores; receiving, from a store in the plurality of stores, product data for each product sold in the store, the product data comprising, for the each product: a product type; at least one product location; and at least one fixture type for the at least one product location; while an inventory of the store is being conducted: receiving, at the server, a current inventory count for each of the products sold within the store; identifying products within the store which need to be recounted by comparing the current inventory count for each product to: the historical inventory amounts for the each product across the plurality of stores; the historical inventory amount for the each product at the store; and inventory rules which take into account the product type, the store type, the at least one product location, and the at least one fixture type, to yield re-count tasks; transmitting, from the server and to the store: the re-count tasks; and store specific instructions for each of the re-count tasks, the store specific instructions based on the product type, the at least one product location, and the at least one fixture type; and receiving, from the store and in response to transmission of the re-count tasks and the store specific instructions, re-count inventory amounts for the products inventoried within the specific store which require the recount; and generating a finalized inventory based on the current inventory count for each of the products sold within the store and the re-count inventory amounts for the products inventoried within the specific store which require the recount.
A computer-readable storage device configured according to this disclosure can have instructions stored which, when executed by a computing device, cause the computing device to perform operations such as: receiving historical inventory amounts for individual stores in a plurality of stores; receiving a store type for each store in the plurality of stores; receiving, from a store in the plurality of stores, product data for each product sold in the store, the product data comprising, for the each product: a product type; at least one product location; and at least one fixture type for the at least one product location; while an inventory of the store is being conducted: receiving a current inventory count for each of the products sold within the store; identifying products within the store which need to be recounted by comparing the current inventory count for each product to: the historical inventory amounts for the each product across the plurality of stores; the historical inventory amount for the each product at the store; and inventory rules which take into account the product type, the store type, the at least one product location, and the at least one fixture type, to yield re-count tasks; transmitting to the store: the re-count tasks; and store specific instructions for each of the re-count tasks, the store specific instructions based on the product type, the at least one product location, and the at least one fixture type; and receiving, from the store and in response to transmission of the re-count tasks and the store specific instructions, re-count inventory amounts for the products inventoried within the specific store which require the recount; and generating a finalized inventory based on the current inventory count for each of the products sold within the store and the re-count inventory amounts for the products inventoried within the specific store which require the recount.
Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system architecture;

FIG. 2 illustrates a first exemplary data flow between devices and systems;

FIG. 3 illustrates a first example method embodiment;

FIG. 4 illustrates a second exemplary data flow;

FIG. 5 illustrates a second example method embodiment; and

FIG. 6 illustrates an example computer system.

DETAILED DESCRIPTION

Various embodiments of the disclosure are described in detail below. While specific implementations are described, it should be understood that this is done for illustration purposes only. Other components and configurations may be used without parting from the spirit and scope of the disclosure.
To conduct a full inventory of a store is generally a human-intensive operation, particularly for hard-to-count items. Because of time constraints on the day of the full-inventory, as well as the inaccuracy inherent in humans counting items, some items may be incorrectly counted. Rather than a human being looking at the data and using intuition to determine if any of the items need to be recounted, the disclosed systems and methods improve on the re-count process by using systems and computing devices to determine when re-counting should be performed. Consider the following example. A system, such as a computer server or other computer device, can receive information about a store undergoing an inventory process. With this information, the system can compare the counted quantities received to predicted inventory numbers and, when the counted quantities are outside predicted thresholds, assign a re-count task. In situations where multiple items need to be re-counted, re-count assignments can be made because particular items are of more interest/value to the system based on shelf-life or value than other items, or because certain items are further outside the predicted ranges than other items.
The list of re-count tasks to be accomplished can be received by the store manager or store management, who can then assign re-count tasks to store associates. The store associates can then receive, on their individual mobile devices (smart phones, MC40s, etc.), the task assignment as well as particular instructions on how to best accomplish the task. These particular instructions can include, for example, directions to the location for the task, a picture of the item to be re-counted, instructions/warnings on how to best conduct the actual counting, a modular hierarchy of the item to be counted (i.e., department>shelving area>modular area).
Consider the following example. The manager of a store receives a list of tasks to accomplish while the full-inventory is occurring. These tasks can be generated and sent from a central computing system to multiple stores. The generation of the tasks may be based on store type, such that the list of tasks varies from store-to-store, region-to-region, based on the types of products and capacities of the individual store types. The list of tasks can include re-count inventory tasks which are prioritized based on cost, value, and/or discrepancy. The tasks may likewise be generated by the system based on the location of the physical goods to be counted (i.e., trailer, stock room, bin, modular, etc.). The manager can assign the tasks, which appear on the store associate's mobile device at the appropriate time for the store associate to perform the task.
Upon selecting to perform a re-count task (or being assigned the re-count task), the associate moves to the product location identified in the instructions. To perform the re-count task, the store associate can scan the item (or more precisely, a bar-code associated with one of the items), and follow the instructions provided on their mobile device. In some cases, these instructions can provide illustrations of the item to be counted, text instructions particular to the product, illustrations or video of how to perform the actual re-count, etc. Upon completing the counting, the store associate enters the re-count of the inventory into the system using their mobile device (or other computing device).
The system then compares the re-count of the product to various metrics to determine if the re-count is outside of certain thresholds, which would cause the re-count to need to be performed yet again. For example, the metrics can include the shelf limit for the product, the previous shipment quantity, historical averages, sales data, the first count, etc.
Whereas in previous solutions human beings were required to evaluate such features based on feelings (i.e., does this seem right?), the present disclosure relies on a set of rules which allow a computer to evaluate if the initial count (or a re-count) is trustworthy. These rules are then updated and modified based on iterative machine learning. More specifically, when the inventory analysis, based on the set of rules, identifies a particular product's quantity as needing to be re-counted, the system will then receive a new count of the product. Based on that new count and the original count, as well as the other data (shipment information, in-store sales, etc.), the system can modify the set of rules. For example, if the re-count of the re-counted item indicates that the audit (or recounting) of the item was not needed, and the original count was correct, the system can modify the set of rules such that in future iterations the re-count would not have been initiated. However, likewise, if the re-count indicated that the original count was incorrect, the system will likely not modify the set of rules, as the rules correctly identified an item as needing to be re-counted.
The determination as to whether an item should be audited/recounted can, in some configurations, be based on a weighted equation with factors such as:

- quantity of items
- sales since last inventory
- shipments sizes since last inventory
- most recent shipment
- shelf limit
- end-cap amounts
- store type

When the system determines that modification to the system rules needs to occur, the system can modify the code containing the re-count rules, thereby modifying the amounts at which certain thresholds are triggered and the re-counting of the initial count is tasked. Similarly, if using a weighted equation, the system can modify the code which sets the weights applied to any given factor. In other words, modification to the rules can include modifying the code such that when a processor or other computing device executes the rules the rules execute modified code and (possibly) provide a distinct result.
The results of the full inventory can be stored and shared in a cloud-based system, such that as the inventory is made the results are automatically transmitted from the worker's mobile device to the cloud and, if necessary, additional instructions can be sent to the store manager. When a re-count needs to be conducted, the manager would make the assignment based on a task received from the central system. However, in this case, to avoid misconduct, the task can block the store associate/worker who conducted the initial count from being the same associate/worker who conducts the re-count. To ensure this occurs, the manager's software can explicitly block the first associate (or inventory service worker) from being selected for the re-count. In yet other tasks, the manager may be required to perform the audit themselves
When items are located in a store which are not typically in the system inventory for that store type or location the system can create a temporary inventory of that item. This can include, for example, regional/seasonal items which are returned to a store, forgotten/left-over items, etc. When the inventory is initiated, the system can task re-counts for these temporary/non-standard items as well as standard items, based on information contained within the inventory system.
When the full-inventory is conducted, the values from the re-count tasks which have been uploaded into the system are automatically incorporated into the full-inventory. For example, if a full report is being generated based on the full-inventory, the re-count values will be used in producing the full report.
Storage of information, both before, during, and after the counting process, occurs in the cloud, which has multiple technical advantages over node-based or store-side data storage and processing. Specifically, node-based or store-based data storage and processing can lead to processing bottlenecks, slow processing speed, store system failures, etc., whereas cloud-based systems can ramp data storage and processing up or down, based on real-time demand. In addition, for other store processes and functions, the most critical in-store function is that the cash registers at the point of sale are able to correctly process customer baskets, accept payment, etc. Store-based processing of the data, as disclosed herein, could impair those register sales from being correctly processed. Specifically, tests have shown that executing rules such as those disclosed herein have resulted in store systems slowing and multiple services being impacted. Moving such rules to the cloud mitigates such risk. In addition, having cloud based processing mitigates the risk of the failure of any single server's crash, which could otherwise disrupt completion of the processes disclosed herein. Thus, embodiments of the invention structure applications to selectively run on remote locations, such as the cloud, instead of at store locations. This structuring allows the systems to correctly process in-store transaction more quickly and accurately.
The rules used to configure tasks, assignments, timing of messages, instructions, etc., can be modified using artificial intelligence (AI) algorithms. In some configurations, these AI algorithms can automatically modify the rules as needed, or on a periodic basis, whereas in other configurations the AI algorithms can make recommendations which are reviewed by human supervisors. For example, in one configuration, the suggestions produced by the AI are reviewed by a human supervisor every three months, every week, or every day, before being finalized (i.e., before overwriting the original rule with a new rule). In some configurations, these rules are run on a server side such that any rule changes (such as when to initiate a recount), are reflected immediately.
Exemplary factors to evaluate the effectiveness of a rule can include the number of recounts/discrepancies generated; the amount of work generated, based on specific or average task completion time; quantity or amount of recounts that resulted in a discrepancy; difference between inventory service counts (3^rdparty counts) and store counts (counting performed by store associates), in terms of quantity and financial difference; counter accuracy, both specific and general for multiple counters, and which may be for a single store or multiple stores; and item characteristics (department, category, hazard class, value).
The disclosure now turns to FIG. 1. FIG. 1 illustrates an example system architecture 100. In this architecture 100, once a worker 102 is assigned to count inventory within a store, the data associated with the worker's 102 tasks is uploaded from a central server or other to a mobile device 104 belonging to the worker 102. This task information provides details which the worker 102 can use to be perform the assigned task, such as information regarding the type of item to be counted (i.e., travel items 106), fixture types (i.e., end caps 108 or free-standing displays 110), or locations of the items.
The worker 102 performs the assigned task (counting the number of items in a bin, etc.), then enters the quantity into their mobile device 104. The mobile device 104 transmits the data to an inventory system 112, which records the quantity within a non-transitory memory device. The inventory system 112 or another computing system then apply rules 114 to the counted quantity to identify if the amount recorded by the worker 102 is outside a predicted range, and therefore needs to be recounted. These rules can rely on historical data 116, such as store sales, shelf limits, shipping information, previous quantity, etc., in making the determination if the amount should be re-counted. Exemplary rules can include:
If pre-count quantity>shelf limits, re-count the item
If pre-count quantity>shipment quantity, re-count the item
If dollar value of pre-count items<predicted dollar value, re-count the item
If the absolute value of (predicted quantity minus pre-count quantity)/predicted quantity>threshold percentage, re-count the item
If the absolute value of (predicted quantity minus pre-count quantity)>threshold, re-count the item.
The results of counts (pre-counts and re-counts) can be shared among the retailer, third parties, multiple stores, etc., using a cloud based real-time data system. APIs (Application Programming Interfaces) can be used to share the data, and the Content Management System can analyze the results of the counts to determine which additional tasks to order and when to order those tasks. In some cases, the system allows for specific areas of the store to be counted, then tasks/counts from those areas can be delivered and/or received as a batch.
If the product needs to be re-counted, a new task is assigned to a different store associate 118 or worker by sending the task to the store associate's mobile device 120. At this point the second store associate 118 performs the task (i.e., re-counting the number of products at the designated location) and sends 122 the second count to the inventory system 112. If the first and second counts of the product match, the inventory system can conclude that the count is correct, and if necessary, can cause the rules 114 to be updated 124, such that the code for implementing the rules is overwritten/modified. In some instances, the counts may not match, and depending on the disparity, management or other personnel may be assigned to confirm the actual quantity of the items.
FIG. 2 illustrates a first exemplary data flow between devices and systems. In this example, a content management system (or other computing device) coordinates the assigned tasks to be completed during a full-inventory of a store. The content management system can, in some configurations, be configured to make assignments between multiple stores based on the specifics of that store (i.e., when the inventory is going to be performed, location, region, etc.) and the type of the store. The content management system can load data associated with an inventory assignment onto a mobile device of an associate (an associate device 208). This data can, for example, include an item file 202 describing aspects of the product, a tag assignment 204 identifying the product to be counted, and a store zone assignment 206 indicating the location (department, aisle, etc.) of the product to be counted. As the worker completes the counting task, the data is uploaded from the associate's device 208 to the inventory service 210.
The inventory service 210, in this example, acts as a data repository, and serves only to hold the data and relay the data to a server 214 where the data can be analyzed and processed. In other configurations, the inventory service 210 performs the analysis and processing which, as described here, is performed by the server 214. The inventory service 210 can, when necessary, distribute iterative updates 212 to the server 214, the updates modifying how the server identifies which items merit a re-count. The server 214 executes rules (or a rules engine 216) which determines if the counted inventory fits within predicted ranges. If not, the server 214 can determine that a recount of a particular product is necessary, and issue a re-count task. The server can transmit this re-count task to a manager's device 220, where the manager can confirm the re-count item 222 for the task, and can assign the re-count to an associate.
To aid the manager in making the assignments, information such as the store aisle locations of the individual products, the fixture types (end-cap, side counter, stack base, etc.), type of product, value of the product, etc., can be loaded into the manager device 220 from the content management system, the server 214, or another database. The manager assigns the re-count tasks, resulting in the assigned tasks being communicated to the associate's device 224. The associate's device 224 receives data from the manager's device 220 and/or the server 214, and the associate performs the assigned re-count 226.
As the associate performs the re-count 226, the quantities entered by the associate into their mobile device 224 are uploaded to the inventory service 210. These adjustments are sent 228 to the inventory service 210, which compares the re-count to historical data using a rule set, allowing the inventory system 210 to determine if the re-count matches (or is within a threshold range) of an amount predicted. In instances where the re-count does not match, the inventory system 210 sends an additional task to the manager device 220 to initiate an audit or recount of the product which was just re-counted. In some cases, the inventory system 210 or the server 214 can randomly decide to recount items, even if within predicted thresholds.
In some cases, initiating the re-count/audit 218 can include the manager themselves counting and inventorying the item, whereas in other cases the manager can assign a different associate to perform the recount than the associate which performed the re-count. When necessary, an update to the rule set can occur, such that the updated rule set is used in future iterations when comparing the re-count to predicted inventory amounts.
The updates to the rule set can be based on a particular item, or can be based on distinct items. For example, if a rule is modified regarding when travel deodorant should be re-counted after a re-count, the system can likewise modify the rule for when travel shampoo should be re-counted. In this example, the reason for the rule change across distinct item types is a common category—travel items. Location, size, product type, shelf life, and price are additional examples of areas where modifying the rule for one product may result in modification of rules associated with other products.
FIG. 3 illustrates a first example method embodiment. In this example, the home office sends an assigned task to initiate an inventory (302) of a store. The store receives the tasks identifying items to be counted (304), and the manager assigns the tasks (306) to store associates. For example, the home office can be a server which automatically sends out inventory assignment/tasks when an approaching inventory is within a threshold date range, and the store can receive the inventory tasks on a store-specific server or computing system. Alternatively, the store may receive the inventory tasks by the tasks being directly sent to a store computer, the manager's computer, the manager's mobile device, etc.
The manager can then populate the possible tasks (308), meaning the manager can assign tasks to specific associates which they manage. In other configurations, the manager may not need to make assignments, and instead the associates can self-select tasks to which they want to be assigned. From the tasks which associates are currently assigned (or which they have selected), the associate selects an active task (310). The system uploads information about how to accomplish the task to the associate's mobile device, which can include information regarding the location of the product which is going to be inventoried, a video showing the associate how to best conduct the counting of the inventory, etc. When the associate arrives at the location of the product to be counted, the associate scan the item (312), allowing the system to know that the correct item has been located. The associate counts the number of items, and enters the item quantity (314) into their mobile device. The associate's mobile device transmits the item quantity to an inventory service (or other computing system) configured to record the inventory numbers and determine if the count is within a predicted range. Submitting the item count also allows the associate to print a label (330), indicating that the full-inventory of the product has been performed.
The inventory service, or other computing device which records the inventory quantities, executes inventory specific rules to determine if the amount counted by the store associate was within a predicted range. This analysis can trigger an assignment to perform an audit (316) on the item which was just counted. The system (meaning the inventory service which performed the rules analysis, or the home office) assigns a new task to perform a re-count of the item. The manager can make the assignment to perform the task, different associates may choose the task, or the manager themselves may be assigned to complete the task. The assigned individual would then select the active audit task (318) from that individual's assigned tasks, and repeat the scanning (320) and entering of quantity (322) steps.
Once the re-count has been entered, the system determines if there is a mismatch (324) between the first count and the re-count. If there is not, then the system can accept the entered quantity as verified. If there is a mismatch, the system can take steps to correct the discrepancies (326). These steps can include yet another re-count, sending a manager or other trusted individual to count the items, accepting the second count as within a predicted range of inventory quantity, etc. The system can also update the audit rules (328) based on the results of the second (or subsequent) re-counts of the re-count, such that future iterations will be more accurate in determining when to initiate the re-counts of counted items. The system also records the re-count data (332) and identifies the inventory of that item as complete.
FIG. 4 illustrates a second exemplary data flow. This example illustrates how the analysis of the re-count quantity operates in conjunction with machine learning/iterative improvements to the analysis. Data such as historical data 402, inventory records 404, current inventory rules 406, store type 408, and the fixture type 410 where the products are stored are combined to determine if the amount counted by the store associate during the re-count is likely to be accurate. If not, the audit process 412 is initiated, ensuring an accurate inventory 414 is taken.
The combined data is also used to enable an iterative machine learning 416 process. This machine learning process uses particular data, such as historical data regarding sales of the product between the last inventory and the current re-count, shipment information, shelf capacity, storage room capacity, re-stocking assignments, the store type, the fixture type where the product is displayed and stored for sales, etc. Each iteration of the inventory process results in additional information which can be used to update 418 the inventory rules 406 which, when combined with the other data 402, 404, 408, 410, determine if an audit/re-count needs to occur. In some configurations, each iteration can cause an update to the inventory rules 406 via the machine learning 416. In other configurations, the system can record data from multiple iterations of the inventory/re-count process, then update the inventory rules 406 using the machine learning 416 on a periodic basis. These iterations can, for example, be from a single product, store, or location, or preferably, are shared between stores, store types, and products based on relationships between products. For example, re-count inventory rules for travel shampoo in a first store may be modified based on iterations of re-counts for travel conditioner in a second store.
Modification of the inventory rules can include, for example, modifying the code which performs the analysis as to whether the product should be re-counted. In the past, humans determining if a re-count of counted items needed to be performed simply decided if the count “seemed right,” and did not perform the analysis, or modification of that analysis, as described herein. By contrast, the automatic analysis, and iterative modification of the code to perform that automatic analysis, improves (over time) the computer's ability to predict when that re-count should occur.
FIG. 5 illustrates a second example method embodiment, and is performed by a server executing concepts as disclosed herein. The server receives historical inventory amounts for individual stores in a plurality of stores (502). The server also receives a store type for each store in the plurality of stores (504) and, from a store in the plurality of stores, product data for each product sold in the store, the product data comprising, for the each product (506): a product type (508), at least one product location (510), and at least one fixture type for the at least one product location (512). Exemplary fixture types can include a stackbase, an endcap, and a sidecounter, and exemplary product locations can include an aisle number, a department area, and a room type. The type of store can be one of a plurality of types of stores, each type of store having defined predefined departments associated with product locations.
While an inventory of the store is being conducted (514): the server receives a current inventory count for each of the products sold within the store (516), identifies products within the store which need to be recounted by comparing the current inventory count for each product to (518): the historical inventory amounts for the each product across the plurality of stores (520), the historical inventory amount for the each product at the store (522), and inventory rules which take into account the product type, the store type, the at least one product location, and the at least one fixture type, to yield re-count tasks (524).
The server then transmits, to the store (526): the re-count tasks (528), store specific instructions for each of the re-count tasks, the store specific instructions based on the product type, the at least one product location, and the at least one fixture type (530). The store specific instructions can include, for example, multi-modal instructions, wherein the multi-modal instructions comprise at least two of: images, text, and video.
The server then receives, from the store and in response to transmission of the re-count tasks and the store specific instructions, re-count inventory amounts for the products inventoried within the specific store which require the recount (532). The server then generates a finalized inventory based on the current inventory count for each of the products sold within the store and the re-count inventory amounts for the products inventoried within the specific store which require the recount (534).
In some configurations, a re-count of a product can be initiated based at least one of: a difference between the current inventory count and the historical inventory amounts across the plurality of stores exceeding a first pre-defined threshold; and a difference between the current inventory count and the historical inventory amount for the each product at the store exceeding a second pre-defined threshold. In such a configuration, the first pre-defined threshold and the second pre-defined threshold can be based on a value of inventoried product available.
In some configurations, the illustrated method can be augmented to further include estimating, via the processor on the server, prior to the transmitting of the re-count tasks and the store specific instructions and based on the re-count tasks, a risk of inventory error; and in real-time as the re-count inventory amounts are received, updating, via the processor on the server, the risk of inventory error based on the re-count inventory amounts.
Another exemplary way in which the method can be further augmented can include modifying the inventory rules, via the processor on the server and based on the re-count inventory amounts, such that future re-count tasks and store specific instructions are generated in a distinct manner.
With reference to FIG. 6, an exemplary computer system includes a general-purpose computing device 600, including a processing unit (CPU or processor) 620 and a system bus 610 that couples various system components including the system memory 630 such as read only memory (ROM) 640 and random access memory (RAM) 650 to the processor 620. The system 600 can include a cache of high speed memory connected directly with, in close proximity to, or integrated as part of the processor 620. The system 600 copies data from the memory 630 and/or the storage device 660 to the cache for quick access by the processor 620. In this way, the cache provides a performance boost that avoids processor 620 delays while waiting for data. These and other modules can control or be configured to control the processor 620 to perform various actions. Other system memory 630 may be available for use as well. The memory 630 can include multiple different types of memory with different performance characteristics. It can be appreciated that the disclosure may operate on a computing device 600 with more than one processor 620 or on a group or cluster of computing devices networked together to provide greater processing capability. The processor 620 can include any general purpose processor and a hardware module or software module, such as module 1 662, module 2 664, and module 3 666 stored in storage device 660, configured to control the processor 620 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 620 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.
The system bus 610 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM 640 or the like, may provide the basic routine that helps to transfer information between elements within the computing device 600, such as during start-up. The computing device 600 further includes storage devices 660 such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive or the like. The storage device 660 can include software modules 662, 664, 666 for controlling the processor 620. Other hardware or software modules are contemplated. The storage device 660 is connected to the system bus 610 by a drive interface. The drives and the associated computer-readable storage media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computing device 600. In one aspect, a hardware module that performs a particular function includes the software component stored in a tangible computer-readable storage medium in connection with the necessary hardware components, such as the processor 620, bus 610, display 670, and so forth, to carry out the function. In another aspect, the system can use a processor and computer-readable storage medium to store instructions which, when executed by the processor, cause the processor to perform a method or other specific actions. The basic components and appropriate variations are contemplated depending on the type of device, such as whether the device 600 is a small, handheld computing device, a desktop computer, or a computer server.
Although the exemplary embodiment described herein employs the hard disk 660, other types of computer-readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs) 650, and read only memory (ROM) 640, may also be used in the exemplary operating environment. Tangible computer-readable storage media, computer-readable storage devices, or computer-readable memory devices, expressly exclude media such as transitory waves, energy, carrier signals, electromagnetic waves, and signals per se.
To enable user interaction with the computing device 600, an input device 690 represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 670 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device 600. The communications interface 680 generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. Various modifications and changes may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.

Claims

We claim:

1. A method comprising:

receiving, at a server, historical inventory amounts for individual stores in a plurality of stores;

receiving, at the server, a store type for each store in the plurality of stores;

receiving, at the server and from a store system in the plurality of stores, product data for each product sold in the store, the product data comprising, for the each product:

a product type;

at least one product location; and

at least one fixture type for the at least one product location;

while an inventory of the store is being conducted:

receiving, at the server and from at least one associate device, a current inventory count for each of the products sold within the store;

identifying products within the store which need to be recounted by comparing the current inventory count for each product to:

the historical inventory amounts for the each product across the plurality of stores;

the historical inventory amount for the each product at the store; and

inventory rules which take into account the product type, the store type, the at least one product location, and the at least one fixture type, to yield re-count tasks;

transmitting, from the server and to a manager device associated with the store:

the re-count tasks; and

store specific instructions for each of the re-count tasks, the store specific instructions based on the product type, the at least one product location, and the at least one fixture type,

where the re-count tasks and the store specific instructions are transmitted from the manager device to an alternative associate device upon a manager associated with the manager device assigning the re-count tasks; and

receiving, from the alternative associate device and in response to transmission of the re-count tasks and the store specific instructions, re-count inventory amounts for the products inventoried within the specific store which require the recount; and

generating a finalized inventory based on the current inventory count for each of the products sold within the store and the re-count inventory amounts for the products inventoried within the specific store which require the recount.

2. The method of claim 1, wherein a re-count of a product can be initiated based at least one of:

a difference between the current inventory count and the historical inventory amounts across the plurality of stores exceeding a first pre-defined threshold; and

a difference between the current inventory count and the historical inventory amount for the each product at the store exceeding a second pre-defined threshold.

3. The method of claim 2, wherein the first pre-defined threshold and the second pre-defined threshold are based on a value of inventoried product available.

4. The method of claim 1, wherein the at least one fixture type comprises one of a stackbase, an endcap, a sidecounter; and

wherein the at least one product location comprises one of an aisle number, a department area, and a room type.

5. The method of claim 1, wherein the store specific instructions comprise multi-modal instructions, wherein the multi-modal instructions comprise at least two of: images, text, and video.

6. The method of claim 1, wherein the type of store is one of a plurality of types of stores, each type of store having defined predefined departments associated with product locations.

7. The method of claim 1, further comprising:

estimating, via the processor on the server, prior to the transmitting of the re-count tasks and the store specific instructions and based on the re-count tasks, a risk of inventory error; and

in real-time as the re-count inventory amounts are received, updating, via the processor on the server, the risk of inventory error based on the re-count inventory amounts.

8. The method of claim 1, further comprising:

modifying the inventory rules, via the processor on the server and based on the re-count inventory amounts, such that future re-count tasks and store specific instructions are generated in a distinct manner.

9. A system comprising:

a processor; and

a computer-readable storage device having instructions stored which, when executed by the processor, cause the processor to perform operations comprising:

receiving a store type for each store in the plurality of stores;

receiving, from a store in the plurality of stores, product data for each product sold in the store, the product data comprising, for the each product:

a product type;

at least one product location; and

at least one fixture type for the at least one product location;

while an inventory of the store is being conducted:

receiving, at the server, a current inventory count for each of the products sold within the store;

the historical inventory amount for the each product at the store; and

transmitting, from the server and to the store:

the re-count tasks; and

store specific instructions for each of the re-count tasks, the store specific instructions based on the product type, the at least one product location, and the at least one fixture type; and

receiving, from the store and in response to transmission of the re-count tasks and the store specific instructions, re-count inventory amounts for the products inventoried within the specific store which require the recount; and

10. The system of claim 9, wherein a re-count of a product can be initiated based at least one of:

11. The system of claim 10, wherein the first pre-defined threshold and the second pre-defined threshold are based on a value of inventoried product available.

12. The system of claim 9, wherein the at least one fixture type comprises one of a stackbase, an endcap, a sidecounter; and

13. The system of claim 9, wherein the store specific instructions comprise multi-modal instructions, wherein the multi-modal instructions comprise at least two of: images, text, and video.

14. The system of claim 9, wherein the type of store is one of a plurality of types of stores, each type of store having defined predefined departments associated with product locations.

15. The system of claim 9, the computer-readable storage device having additional instructions stored which, when executed by the processor, cause the processor to perform operations comprising:

estimating prior to the transmitting of the required re-count tasks and the store specific instructions and based on the required re-count tasks, a risk of inventory error; and

in real-time as the re-count inventory amounts are received, updating the risk of inventory error based on the re-count inventory amounts.

16. The system of claim 9, the computer-readable storage device having additional instructions stored which, when executed by the processor, cause the processor comprising:

modifying the inventory rules, based on the re-count inventory amounts, such that future re-count tasks and store specific instructions are generated in a distinct manner.

17. A computer-readable storage device having instructions stored which, when executed by a computing device, cause the computing device to perform operations comprising:

receiving historical inventory amounts for individual stores in a plurality of stores;

receiving a store type for each store in the plurality of stores;

a product type;

at least one product location; and

at least one fixture type for the at least one product location;

while an inventory of the store is being conducted:

receiving a current inventory count for each of the products sold within the store;

the historical inventory amount for the each product at the store; and

transmitting to the store:

the re-count tasks; and

18. The computer-readable storage device of claim 17, wherein a re-count of a product can be initiated based at least one of:

19. The computer-readable storage device of claim 18, wherein the first pre-defined threshold and the second pre-defined threshold are based on a value of inventoried product available.

20. The computer-readable storage device of claim 17, wherein the at least one fixture type comprises one of a stackbase, an endcap, a sidecounter; and