In this release, we’re happy to announce many improvements to inventory management.
...
Eliminated duplicate API calls
The primary cause of performance issues in RTP were the calls to the RTP stored procedure, proc_publicGetProductInventoryPoolInventory. Previously, the sync may have unnecessarily called this stored procedure multiple times with the same criteria on each sync. Now, this stored procedure is only called once for each combination of InventoryPoolCode and InventoryPoolLocationCode.
Eliminated syncs for past dates
Previously, inventory for prior dates in the same season would be updated on each sync. We’ve modified the function in the release as follows: Prior to the start of the season, inventory is synced for the time period between the store-wide “Season Start Date” and “Season End Date” settings. After the start of the season, inventory is only synced for the current date through the “Season End Date”.
Removed DeleteGuests schedule task
The DeleteGuests ScheduleTask has been removed from the database so it cannot inadvertently be set to Active. The DeleteGuests function, which removes temporary records created by users of the site who never create an an account, has been moved to an Azure function which runs on a scheduled basis (typically once a day, at midnight local time).
New Inventory Frequency Setting
Some inventory pools may have high availability and therefore do not need to be synced as often as products with only a few slots available. For example, if your inventory for lift tickets has 50,000 slots available each day, there’s no need to sync it every 5 minutes. Reducing the amount of inventory that needs to be synced with each execution of the function helps reduce the performance impact on the POS database server.
...
IMPORTANT: If more than one row in Aspenware Commerce Inventory Pools administration maps to the same combination of InventoryPoolCode and InventoryPoolLocationCode, and one is set to Once Daily and the other is not, both will sync every time the function runs, and the Once Daily setting will be ignored. The sync will always choose the most frequency syncing option for that combination of InventoryPoolCode and InventoryPoolLocationCode.
New Setting to configure a buffer between when the inventory sync runs and the order lock is removed
The following setting is set in Azure on the Inventory Function ‘OrderLockRemovalBufferInSeconds’. This should be set to the amount of time it takes for the inventory function to run in your environment. The default is 60 seconds.
Improved Sold Out messaging on Add to Cart
Two configurable language strings will appear in a toast message on the PDP whenever a guest attempts to add inventory to cart when this is none available. The toast message will appear as follows:
...
The Language strings are:
ResourceName | Default ResourceValue |
|---|---|
product.availability.outofstock | This product is not available. |
shoppingcart.quantityexceedsstock | Your quantity exceeds stock on hand. The maximum quantity that can be added is {0}. |
Scenarios in which inventory could be oversold
There are a few scenarios, some of which may be found only in testing, in which inventory could be oversold.
...
Scenario 3: This scenario was found in internal testing, and is also rare. If product A and product B both map to the same inventory pool in the POS, and a shopper adds the last slot for product A to the cart, waits for the lock to expire, and then adds product B to the cart (thereby taking that same last slot from inventory), that guest’s order for Product A and Product B will succeed, thereby overbooking inventory. A guest cannot successfully checkout with 2 slots for product A when only 1 remains, but a guest could overbook for that same slot if it’s configured on both product A and product B.
Scenarios where a guest could add to cart, but not be able to check out with an inventory product
Scenario 1: If a shopper books the last remaining slot in inventory when only 1 slot remains for a inventory pool for the selected date, checks out, and returns to the shop to buy that product for the same date again before the order is processed and the lock expires, the shopper might see that date/slot as available and add it to cart, but be unable to check out with that product, if the lock has expired by the time he attempts to complete the order.
...