The FlagInventory and LocalInventory components, discussed in the section on Inventory and Backordering, are strictly informational components. This means that while they provide notification that a given item is out of stock, they assume that the product table column that identifies the number of items in stock has been maintained by some other process.
Usually, this process involves including the ReduceLocalInventory or SQLItem components in the Accept stage of the purchase pipeline. Both of these components are designed to execute a query that you provide, and that decrements the value stored in the product table column that indicates how many of a given item are in stock.
Suppose, however, that a situation arises in which two customers are contending for an item of which there is only one in stock. As the OrderForm of each customer passes through the plan pipeline, the Inventory components indicate to both that the product is in stock. This is correct behavior, because the number that indicates how many items of a given SKU are in stock has not yet been reduced to zero (0) by an Accept stage component.
However, when the first customer runs the purchase pipeline, the SQLItemADO or ReduceLocalInventory component will reduce the in-stock value to zero (0). When the second customer runs the purchase pipeline, the SQLItemADO or ReduceLocalInventory component will reduce this value to a negative integer. In this scenario, back-ordering will effectively have been permitted, even though the site’s plan pipeline may have been configured to disallow backordering.
There are several ways to address this problem.
One solution to this problem is to include at the beginning of the Accept stage a SQLItemADO component that checks to ensure that number of items in stock for a given SKU is larger than zero (0). If no items for a given SKU are in stock, the SQLItemADO component can simply place the items on backorder (by initializing the _inventory_backorder name/value pair) or can raise the _pur_out_of_stock error.
A second solution is simply to include an instance of the appropriate inventory component (FlagInventory, for example) in both the Inventory stage (plan pipeline) and in the Accept stage (purchase pipeline). Following this component, you would include a ReduceLocalInventory component. This component would execute the query to decrement the in-stock value for the item.
The use of SQLItemADO is preferred in MtsTxPipelines. SQLItemADO supports transacted behavior, and ReduceLocalInventory does not.