Method and system for tracking inventory

Methods and systems for optimizing item assortments are disclosed. One method includes receiving a request for an optimized assortment. Data relating to items within a selected initial item assortment and item universe is accessed. Constraints are applied to the items in the assortment to arrive at an optimized item assortment. Constraints include goals for optimization, lock in and lock out rules, and item attribute rules. The method may be performed by a system including one or more computing devices communicating via a network with one or more data storage devices.

TECHNICAL FIELD

The present disclosure relates generally to methods and systems for tracking inventory within a supply chain. More particularly, the present disclosure describes an event-based system architecture for tracking the inventory of items at multiple locations within a retail enterprise in real time.

BACKGROUND

In retail operations, inventory management is a crucial part of the business. It is important to monitor inventory levels and movements at multiple locations with a supply chain for the retail operation. Many crucial decisions for inventory management rely on accurate accounting of inventory levels. However, with enterprises of substantial size and managing a large and constantly-changing inventory, it can be difficult to determine at any particular time an inventory level for particular items across the enterprise. For example, items in transit may be credited as being positioned at neither or both of the source and destination locations depending upon the time at which stock counts are taken at those respective locations.

SUMMARY

In summary, the present disclosure relates to methods and systems for tracking inventory within a retail supply chain. Various aspects are described in this disclosure, which include, but are not limited to, the following aspects.

In one aspect, a system for tracking inventory across a supply chain is described. The supply chain includes a plurality of retail locations and a plurality of distribution locations. The system includes an inventory tracking engine comprising a computing system that includes a processor and a memory communicatively coupled to the processor. The memory stores instructions executable by the processor to: receive one or more inventory events; transform the one or more inventory events into separate inventory transactions for each item involved in the event; analyze the inventory transactions to determine how many units of each item moved to or from each location involved in the events; and record updated inventory counts in an inventory database.

In another aspect, a method of tracking inventory across a supply chain including a plurality of retail locations and a plurality of distribution locations is provided. An inventory event is received at a computing system. An inventory event may be a transfer order, a purchase order, a sale, or an inventory adjustment event. The inventory event is transformed into separate inventory transactions for one or more items involved in the inventory event. The computing system then analyzes the inventory transactions to determine how many units of each of the one or more items have moved to or from each location involved in the inventory event. Finally, an updated inventory count for each item and location is recorded in an inventory database.

In a further aspect, a system for tracking inventory across a supply chain including a plurality of retail locations and a plurality of distribution locations is disclosed. The system includes a computing system including a processor, and a memory communicatively coupled to the processor, the memory storing instructions executable by the processor to expose an application programming interface providing access to near-realtime inventory information and an inventory tracking engine. When executed, the instructions cause the computing system to: receive a data stream comprising a plurality of realtime inventory events, the inventory events comprising transfer orders, purchase orders, sales events, inventory adjustment events, and combinations thereof; atomize the data stream in realtime, the data stream including the plurality of inventory events into separate inventory transactions for each item involved in the event; analyze the inventory transactions to determine how many units of each item moved to or from each location involved in the events; record updated inventory counts in an inventory database, the inventory database maintaining near-realtime inventory information; receive, concurrently with the data stream, a query at the application programming interface from a user application; and in response to the query, provide access to near-realtime inventory levels reflected in the inventory database at an item level without requiring aggregation of inventory information from store-level inventory systems.

DETAILED DESCRIPTION

In general, the present disclosure describes inventory management systems and methods which track all inventory of items within a retail supply chain. Inventory transactions are monitored and can include sales events, purchase orders, transfer orders, and other inventory movements between nodes of the supply chain. Nodes can include warehouses, distribution centers, receive centers, flow centers, stock rooms, and retail stores. Individual item counts for each node are recorded in an inventory database. An inventory application programming interface (API) allows users to view current inventory information for all of the various items within the supply chain.

The methods and systems described herein are useable in conjunction with an event-driven architecture for real-time replenishment of inventory, tracked on a per-item basis. Demand forecasting is utilized to anticipate customer demand at each location for each item. The event-driven architecture allows for both a reduction in the amount of inventory that is stored at any time, both throughout an enterprise and at retail locations in particular, while also being able to reliably respond more quickly to customer demand. When used in that context, and in a manner unified with the supply chain management system, the inventory management systems described herein provide a near-realtime, accurate view of inventory positioning without requiring querying of various locations within the supply chain, thereby improving accuracy and efficiency in providing supply chain levels for reporting and planning purposes.

FIG. 1illustrates a schematic diagram100of an example supply chain for a retail enterprise. The diagram100illustrates the flow of inventory from vendor102to customer110. The inventory moves through various nodes to arrive at the customer. In this example, the nodes include a receive center104, two flow centers106a,106b, four retail stores108a,108b,108c,108d, and three customer residences110a,110b,110c. In practice, the supply chain could include many more nodes in different proportions. In some embodiments, there are not separate receive centers and flow centers. Instead, there may be one type of warehouse or distribution center for holding inventory before distributing to stores and customers. Arrows in the diagram indicate movement of inventory. Inventory will typically flow downward through the supply chain, but in some instances inventory may move between flow centers106or between retail stores108. In some embodiments, inventory may even move from a flow center106to a receive center104or from a retail store108to a flow center106.

Vendors102produce the items or products that will be sold by the retail entity. A purchase order is typically placed to request products from a vendor. In some instances, the vendor102will transport the ordered products to a receive center104. In other instances, the retail entity arranges for the products to be picked up from the vendor102and transported to the receive center104. Once at the receive center104, the products are prepared for transportation to one or more flow centers.

A variety of products are prepared for shipment to one or more flow centers106. The flow centers106are typically positioned to enable quick shipment to one or more retail stores108. Each flow center106may supply inventory to multiple retail stores108. In some instances, more than one flow center106will send inventory to a retail store108. For example, inFIG. 1, flow center106adistributes inventory to stores108a,108b, and108c. Flow center106bdistributes to stores108b,108c, and108d. In some instances, to the extent products received at a flow center106are not already broken down into individual units, the products may be broken down into individual units in order to distribute individual items to stores108, or optionally to fill online orders that will be delivered directly to customers from the flow center106or store108. In the example ofFIG. 1, products are shipped directly from flow center106ato a customer110aand from flow center106bto customer110c.

Once products arrive at the retail stores108, they are available for in-store purchases, pick-up orders, or local delivery. Depending on the location of a customer ordering products online, the shipments of products could come from one or more retail stores108. For instance, customer110bcould receive shipments of products from either store108bor store108c.

It is noted that, between receive centers108, flow centers106, and stores108, there may be preexisting, predetermined delivery routes established. For example, there may be daily or weekly transit routes between a receive center and one or more flow centers. The receive center can provide to the flow centers the selection of individual items that are needed by stores108serviced by the one or more flow centers proximate to and/or servicing those stores. The flow centers can also have daily or other periodic transportation routes established to stores that are serviced, thereby ensuring prompt replenishment of items at stores in response to item sales.

In addition, the predetermined delivery routes can be used for various purposes. For example, in some situations, the predetermined delivery routes can be used to deliver products in various forms. As explained in further detail below, items distributed via the supply chain are tracked on an individual (per-item) basis; as such, items can be delivered to stores108in any convenient manner. In some example embodiments, items are tracked on an individual basis, but may be grouped at a flow center106to simplify restocking of the store108, for example by placing together in a package a collection of individual items of different types but which may easily be stocked conveniently once those items arrive at a store108. For example, goods that are located in a common department, row, or shelf of a store can be grouped and packed together at the flow center106. Once those items reach the store108, a restocking operation can restock each of the items in that shelf, row, or department easily. Still further, because items are packed and tracked on an individual basis at the flow center and sent to stores based, at least in part, on demand signals received from stores, the item collections are based on the number of items sold and therefore the restocking operation can provide a package of items that will fit on store shelves, rather than requiring additional backroom stocking and storage.

In the context of the present disclosure, a supply chain management system is provided that assists in coordination of product shipments among nodes of the supply chain, and uses inventory models to automatically rebalance inventory within the supply chain of the enterprise to ensure predicted and actual item demand from customers of the enterprise is fulfilled to a predetermined threshold success rate. The supply chain management system allows for balancing of items across the supply chain based on inventory and demand models, as well as real time demand signals, and performs automated generation of purchase and transfer orders throughout the supply chain based on such demand and lead time calculations between paints both within and external to the supply chain. Accordingly, as noted below, substantial advantages are realized using the methods and systems of the present disclosure.

It is in this general supply chain retail environment that the following systems and methods operate. While the methods and systems are described in a retail environment having brick-and-mortar stores as well as online sales, additional applications are possible. For example, the systems and methods could operate in a supply chain of warehouses that only distribute products to customers in fulfillment of online orders.

FIG. 2illustrates a schematic diagram of an example system200for managing a supply chain. The key components of the supply chain management system200are an inventory management system202and a replenishment management system204. Together, the inventory management system202and replenishment management system204operate to monitor inventory levels across all nodes of a supply chain, determine if and when adjustments to inventory levels need to be made, and facilitate transport of inventory between nodes to respond to customer demand. An example supply chain management system is further described in copending U.S. patent application Ser. No. 15/898,837, filed Feb. 19, 2018, the disclosure of which is hereby incorporated by reference in its entirety.

The inventory management system202receives inventory requests from the replenishment management system204. In response to the inventory requests, the inventory management system202determines whether additional inventory is needed at one or more nodes within the supply chain to satisfy the request. Additional inventory may be transported to one node from another node if sufficient stock of the needed product(s) is available within the required timeframe within the supply chain. In such instances, transfer orders are issued to the transportation management system206. If the inventory management system202determines that there is not sufficient stock of the requested products at another node or that transporting the products within the supply chain would be too costly or time consuming, additional stock is ordered from one or more vendors102through purchase orders issued from the inventory management system202. The inventory management system202is further described with respect toFIG. 3.

The replenishment management system204receives demand signals from an online ordering system208, one or more point of sale systems210, and a demand forecast engine212. The demand signals can be proactive or reactive. Proactive demand signals come from the demand forecast engine212and are generated by predicting expected customer demand for individual products on a day by day basis. Reactive demand signals come from sales made at the point of sale system210or through the online ordering system208. The online ordering system208receives orders from customers110and coordinates fulfillment of those orders. The point of sale systems210record sales that are made at stores108. The replenishment management system204also receives inventory adjustments from the user interface214. Inventory adjustments are instructions received from a user to modify inventory levels at one or more locations or nodes within the supply chain. Inventory adjustments may be made for reasons other than expected or actual customer demand for particular items. The replenishment management system204is further described with respect toFIG. 3.

In some embodiments the supply chain management system200communicates with a computing device220through a network222. The network222can be any of a variety of types of public or private communications networks, such as the Internet. The computing device220can be any network-connected device including desktop computers, laptop computers, tablet computing devices, smartphones, and other devices capable of connecting to the Internet through wireless or wired connections. In some instances, the supply chain management system200also communicates with a finance system224through the network222.

FIG. 3shows a more detailed schematic of the inventory management system202and replenishment management system204. The inventory management system202includes an inventory tracking engine302, inventory movement analyzer303, a transfer order generator306, and a purchase order generator308. The inventory management system202also includes a processor340and memory342operatively connected to the processor340; the memory342stores the operative instructions organized into various operative components of the inventory tracking engine302, as well as inventory movement analyzer303, transfer order generator306, and purchase order generator308.

The inventory management system202receives inventory requests from the replenishment management system204. The replenishment management system204includes at least a proactive replenishment system316and a reactive replenishment engine318. The replenishment management system204also includes a processor344and memory346operatively connected to the processor344, which stores operative instructions executed by processor344including the proactive replenishment engine316and reactive replenishment engine318. The proactive replenishment engine316receives inventory adjustment signals from the demand forecast engine212and the user interface214. The reactive replenishment engine318receives demand signals in the form of sales from the online ordering system208and the point of sale system210.

In response to the inventory requests, the inventory management system202determines whether additional inventory is needed at one or more nodes within the supply chain to satisfy the request. The inventory tracking engine302determines the current inventory levels of each node and tracks movements of inventory throughout the supply chain. The inventory tracking engine302receives updates on every movement of inventory within the supply chain from the transportation management system206. The inventory tracking engine302updates the inventory data store314as inventory levels change in real-time. The inventory movement analyzer303utilizes the information in the inventory data store314to determine if any inventory needs to be moved within the supply chain as the inventory levels change at each node of the supply chain.

Additional inventory may be transported to one node from another node if sufficient stock of the needed product(s) is available within the required timeframe within the supply chain. In such instances, transfer orders are issued to the transportation management system206by the transfer order generator306. If the inventory management system202determines that there is not sufficient stock of the requested products at another node or that transporting the products within the supply chain would be too costly or time consuming, additional stock is ordered from one or more vendors102through purchase orders issued from the purchase order generator308.

The inventory movement analyzer303receives status updates from the inventory tracking engine302and analyzes the changing inventory levels at each node within the supply chain to determine if any inventory movements are needed. The inventory movement analyzer303receives inventory requests from the replenishment management system204, the inventory removal system224, and the returns management system226. Based on these inventory requests, the inventory movement analyzer303determines whether the inventory levels are at their preferred levels. The preferred levels are determined on a per-item basis for each day. The inventory goals could change from day to day for each item and node location. The inventory movement analyzer303evaluates the current inventory levels at each node and compares them to that day's goal and the following day's goal to determine if inventory movements need to be changed to redistribute inventory.

The inventory movement analyzer303determines how items should be moved between nodes of the supply chain, based on the inventory goals. If inventory is available within the supply chain to satisfy an inventory request and the costs are not too high to move the inventory, the inventory movement analyzer303will send a signal to the transfer order generator304. If the inventory movement analyzer303determines that there is insufficient supply of an item within the supply chain to satisfy an inventory request or that the cost of moving items outweighs the cost of ordering new stock, the inventory movement analyzer303sends a signal to the purchase order generator306.

The inventory removal system224and returns management system226provide inputs to the inventory movement analyzer303to request the movement of inventory within the supply chain. The inventory removal system224is responsible for removing items from the supply chain. In some instances, the items will be automatically removed after a period of time, for example, after a predetermined shelf life for perishable produce and other fresh grocery items. In other instances, the items are removed after the inventory removal system224receives a notification to remove one or more items from the supply chain. For example, one or more seasonal items may be removed at the conclusion of a particular shopping season. In another example, as discussed below, the items could be removed following a return if the items are no longer in condition for re-sale to another customer. Items may need to move to different nodes in order to be properly removed from the supply chain.

The returns management system226operates to determine how to redistribute items that have been returned by customers following a purchase. In some instances, the returned item or items are transferred to other nodes or remain where they were received from the customer. Those items are then made available for re-sale to another customer. In other instances, the returned item or items are not eligible for re-sale and are marked for removal from the supply chain by the inventory removal system224.

The transfer order generator306communicates with the transportation management system206to transfer stock of products from one node to another. Transfer orders are generated when the inventory management system202has received an inventory request and the inventory movement analyzer303has determined that the additional inventory can be moved from another node.

The purchase order generator308sends orders to vendors for additional stock of products. Purchase orders are generated when the inventory management system202has received an inventory request and the inventory movement analyzer303in conjunction with the cost analyzer322has determined that it would be more cost and/or time efficient to get the additional inventory from a vendor than from another node. Purchase orders are communicated to the transportation management system206in order for transportation of the products from the vendor to a receive center to be arranged.

The inventory tracking engine302includes an event receiver330, a transformation engine332, a transaction analyzer334, an inventory updating engine336, and an API338. The inventory tracking engine302communicates with an inventory data store314. In some embodiments, more than one inventory data store are in communication with the inventory tracking engine302. The inventory tracking engine302is further described in relation to the method500ofFIG. 5. The API338allows a front-end user interface to query the inventory data store314and/or inventory transaction temporary data store337to receive information regarding inventory levels at one, some, or all locations across the enterprise. Accordingly, via the API338, a user application can view near-realtime current inventory levels at a per-item level. Furthermore, because the inventory data store314is maintained up to date in a near-realtime basis, aggregation of inventory information from store-level inventory systems is not required to provide updated inventory levels to a requesting user or application.

Referring now toFIG. 4, an example block diagram of a computing system220is shown that is useable to implement aspects of the supply chain management system200ofFIG. 2. In the embodiment shown, the computing system220includes at least one central processing unit (“CPU”)402, a system memory408, and a system bus422that couples the system memory408to the CPU402. The system memory408includes a random access memory (“RAM”)410and a read-only memory (“ROM”)412. A basic input/output system that contains the basic routines that help to transfer information between elements within the computing system220, such as during startup, is stored in the ROM412. The computing system20420further includes a mass storage device414. The mass storage device414is able to store software instructions and data.

The mass storage device414is connected to the CPU402through a mass storage controller (not shown) connected to the system bus422. The mass storage device414and its associated computer-readable storage media provide non-volatile, non-transitory data storage for the computing system400. Although the description of computer-readable storage media contained herein refers to a mass storage device, such as a hard disk or solid state disk, it should be appreciated by those skilled in the art that computer-readable data storage media can include any available tangible, physical device or article of manufacture from which the CPU402can read data and/or instructions. In certain embodiments, the computer-readable storage media comprises entirely non-transitory media.

According to various embodiments of the invention, the computing system220may operate in a networked environment using logical connections to remote network devices through a network222, such as a wireless network, the Internet, or another type of network. The computing system220may connect to the network222through a network interface unit404connected to the system bus422. It should be appreciated that the network interface unit404may also be utilized to connect to other types of networks and remote computing systems. The computing system220also includes an input/output controller406for receiving and processing input from a number of other devices, including a touch user interface display screen, or another type of input device. Similarly, the input/output controller406may provide output to a touch user interface display screen or other type of output device.

As mentioned briefly above, the mass storage device414and the RAM410of the computing system220can store software instructions and data. The software instructions include an operating system418suitable for controlling the operation of the computing system220. The mass storage device414and/or the RAM410also store software instructions, that when executed by the CPU402, cause the computing system220to provide the functionality discussed in this document. For example, the mass storage device414and/or the RAM410can store software instructions that, when executed by the CPU402, cause the computing system220to receive and analyze inventory and demand data.

FIG. 5displays a flow diagram of a method500of tracking inventory within a retail supply chain. The supply chain includes a plurality of retail locations and a plurality of distribution locations. The supply chain may be structured like the example supply chain depicted inFIG. 1. In some embodiments, the method500is performed by an inventory tracking engine302such as the one depicted inFIG. 3.

At operation502, events are received at the event receiver330. Events include any movement, addition, or subtraction of inventory. Events may include purchase orders, transfer orders, sales events, and other inventory adjustment events. The event receiver330receives purchase orders from the purchase order generator308ofFIG. 3. Transfer orders are received from the transfer order generator306ofFIG. 3. Sales events are received from a point of sale system210or online ordering system208like those described inFIG. 3. In example embodiments, because the events are received as they are generated, the events can be received at the event receiver330from one or more data streams of inventory events reflecting a near-constant set of changes to inventory levels across the enterprise.

At operation504, events are transformed into inventory transactions by the transformation engine332. The transformation engine332converts each event into an individual transaction for each item (e.g., atomizing the events). An example schematic of this process is depicted inFIG. 6.

As shown in the schematic600ofFIG. 6, in an example embodiment, events are broken down by individual item and converted to inventory transactions. Purchase orders, transfer orders, sales, and adjustment events are broken down by individual item at step602. Each inventory transaction is then converted to one consistent format as part of the transformation process in step604. The consistent format of the general inventory transactions606allows for easier analysis of current inventory counts that are processed by the transaction analyzer334. Furthermore, breakdown of events into individual item events ensures inventory tracking is performed on a per-item basis across the enterprise, rather than having potential inventory mismatch due to use of different units (pallets, items, or multi-item packages).

Returning back toFIG. 5, at operation506, the inventory transactions are analyzed and reconciled with the current inventory counts at each location involved in the event. The transaction analyzer334receives the inventory transactions604from the transformation engine332. Each of the inventory transactions604, in their consistent format, are analyzed to determine which items and locations are involved in each transaction. This process is further described below in relation toFIG. 7. The transaction analyzer334ultimately determines how the count for each location and item is to be adjusted for record-keeping purposes. This information is then passed along to the inventory updating engine336.

At operation508, the updated counts for each item in each location are recorded in an inventory data store314by the inventory updating engine336ofFIG. 3. The inventory updating engine336determines which data to alter within the inventory data store314based on which locations had a change in inventory count for particular items. Accordingly, user applications can then query, e.g., via the API discussed above, to obtain near-realtime inventory levels across the organization, at a store, distribution center, or other location or set of locations within the enterprise.

FIG. 7displays a flow diagram of a method506of analyzing inventory transactions. Each incoming inventory transaction is analyzed by the transaction analyzer334to determine how the overall inventory counts for the supply chain should be modified.

At operation702, the inventory transactions are deduplicated to eliminate any transactions that were already processed. Any redundant transactions are identified by involving the same item and transaction ID. The deduping results in a list of inventory transactions that actually need to be processed by the inventory tracking engine302.

At operation704, the current counts for each location and item are accessed from the inventory data store314. The current counts are the status of the inventory before the current transactions were received. The inventory tracking engine302continually updates the inventory counts at each location for each item as new transactions are received. In some embodiments, the system only accesses the counts for the items and locations that are involved in the inventory transaction that is currently being analyzed.

At operation706, the inventory transactions are mapped to the current inventory counts. For example, inventory transactions are lined up with inventory counts based on transaction IDs and item IDs.

At operation708, an inventory cache is built. This provides temporary storage for the inventory counts at each location, including updated inventory counts based on received events.

At operation710, a running inventory is mapped to the inventory cache. The running inventory tracks inventory changes on a per-item basis as each inventory transaction is processed.

At operation712, counts are processed. A method of processing counts is further described in reference toFIG. 8.

At operation714, the counts are reconciled with the running inventory. The system ensures that all additions and subtractions from each item count are logical and have been processed in the proper order.

At operation716, adjustments are processed. A method of processing adjustments is further described in reference toFIG. 9.

At operation718, inventory adjustments are inserted into the running inventory count.

At operation720, the inventory is updated. The overall counts and adjustments have been calculated for each item in the inventory transactions received at the inventory tracking engine302. The inventory is updated by the inventory updating engine336by recording the new inventory counts in the inventory data store314.

Turning now toFIG. 8, a method712of processing counts is provided. At operation800, an inventory transaction is accessed. At operation802, it is determined if an item involved in the transaction is already in the inventory system. If the item already exists in the system, the method proceeds to operation804. If not, the method proceeds to operation806. At both operation804and operation806, the system determines whether the transaction has been counted for the first time. This checkpoint ensures that transactions are not counted more than once.

If the answer to operation804is yes, the method proceeds to operation808. If no, the method proceeds to operation810. If the answer to operation806is yes, the method proceeds to operation816. If no, the method proceeds to operation812.

At operation808, the system determines whether the event time is before the last count time. If so, the transaction is out of sync and the method proceeds to operation818. If the transaction is in sync, the method proceeds to operation814.

At operation810and812, the system determines whether the event time of the transaction is after the last count transaction event time. This inquiry ensures that transactions are processed in the proper order. This prevents transactions from conflicting with each other or being processed in an order that doesn't make sense (e.g. processing a sale for an item before a transfer of that item place enough inventory in a store to fulfill that sale). If the answer to operation810is yes, the method proceeds to operation824. If no, the method proceeds to operation820. If the answer to operation812is yes, the method proceeds to operation818. If no, the method proceeds to operation820.

At operation814, the system inquires whether the inventory quantity is equal to the inventory transaction as applied to the adjusted quantity for that item. It the inventory quantity can be reconciled, the method proceeds to operation822where the inventory transaction is reconciled.

At operation816, inventory transactions are not counted because the running quantity is equal to the requested quantity.

At operation818, the quantity of a particular item is adjusted.

At operation820, the item is added to the running count. Since the event time is not after a last count, the running count can simply be updated, rather than directly adjusting a quantity or reconciling inventory transactions.

At operations822and824, the inventory transaction is reconciled.

At operation826, it is determined whether reconciling an inventory quantity is the same as the transaction applied to an adjusted quantity. If so, the inventory transaction is reconciled at operation822; however, if not, the inventory transaction is not counted, at operation816.

FIG. 9displays a flow chart of a method716of processing inventory adjustments. At operation900, the inventory transaction being analyzed is accessed.

At operation902, the system determines if the transaction is out of sync. If the inventory adjustment is applied out of order, the method proceeds to operation904. If the adjustment is being processed in the proper order, the method proceeds to operation910.

At operations904and910, the system determines whether the item involved in the inventory adjustment already exists within the supply chain. If the answer to inquiry904is yes, the method proceeds to operation906and the inventory is not adjusted for that item. If the answer to inquiry904is no, the inventory is also not adjusted? If the answer to inquiry910is yes, the quantity is adjusted for that item at operation912. If the answer to inquiry910is no, the method proceeds to operation914and the item is only added to the inventory database at this time; subsequent encounters with that item will not cause addition of the item to the inventory database, since it will have previously been added (rather, a quantity will be adjusted, e.g., as in operation912).

The inventory tracking engine can be accessed by users within a retail enterprise to determine the current inventory levels on an individual item basis for each node in the supply chain (where nodes include receive centers, flow centers, and retail stores). In the example ofFIG. 10, a user wants to ensure that inventory is allocated to retail stores in a quantity large enough to satisfy expected demand for an upcoming promotion. In this example, the user at the retailer headquarters1002has submitted an inquiry804indicating that 100 units of Brand A Sunscreen needs to be stocked and available in each retail store. In this situation, Stores1-5are all serviced by the same flow center.

At the time of the user inquiry, the item count1006shows that the flow center does not have any stock of the product and each store has 15 or less units of the product. The inventory management system accesses information provided by the inventory tracking engine to determine the current stock levels of the product in each of the stores and then calculates the number of units of product that are needed to satisfy the request. In this example, the inventory management system determines that 463 additional units are needed. The inventory request is made to the replenishment management system, which determines where to obtain the additional units of product. In this example, the additional units are requested through a purchase order made to a vendor1008. Once the vendor has fulfilled the order1010for 463 units, the flow center1012receives the product.

The inventory tracking engine recognizes that the inventory has been added to the supply chain and that the additional units are now in the flow center. This is reflected in an updated item count1014showing that 463 units are at the flow center. Then, the inventory management system informs the transportation management system of the number of additional units of the product that are needed by each individual retail store. The transportation management system then distributes the product to the retail stores1016. The final item count1018indicates that each store is carrying the requested 100 units and the flow center's supply of Brand A Sunscreen has now been exhausted again.