2.13 Commerce Release Guide - Inventory Enhancements

In this release, we’re happy to announce many improvements to inventory management.

Open

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.

A new column, Frequency Type, has been added to Inventory Pools administration. The default for this new setting is blank, which means existing sync frequency (every n minutes, where n is the value configured in the Azure function timer settings ) will be used. The other option is Once Daily. If you select Once Daily, it will execute the sync the first time the function runs after midnight daily, local store time.

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:

Open

The Language strings are:

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 1: If the inventory is sold out, or a resort admin manually changes slots to 0 for a date or date range, and the inventory sync to Aspenware Commerce has not yet run, a guest could checkout on Aspenware Commerce with the remaining inventory slot (or slots) recorded from when the sync ran last. This scenario could result in overselling inventory in the POS system.

*Important: For resorts using RTP|Connect order processing, in this scenario, the order may fail in the order queue. In this case, inventory will not be oversold, but the failed order will need to be handled. For resorts using Unity order processing, the Aspenware order will process successfully, which will overbook inventory for the applicable slot or slots.

Scenario 2: This scenario is rare, but if two guests are competing for the same final inventory slot or slots, and they both complete checkout within a few seconds of each other, before the lock is released for guest 1 or guest 2, both orders may successfully process to the POS, thereby overbooking the inventory.

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.