Overview: Inventory

Key Terms

Feature Description

Aspenware products can sync with POS inventory. Inventory numbers in the POS will be checked at a configurable interval, blocking dates in the shop that are no longer available, or warning of low inventory if low-inventory thresholds are configured by the resort. When a guest selects inventory-controlled products and adds them to the cart, Aspenware Commerce locks the slot(s) of inventory on those products for a configurable period (default is 15 minutes), drawing from the most recently synced inventory. If a lock on a product expires before the guest checks out, the inventory is checked again. If the inventory is still available, the guest will be able to check out, but if the product is sold out, the guest will no longer be able to buy that product for that date.

Inventory can be checked for single-day products on the day of the product and also checked for multi-day products that are consecutive or non-consecutive. On multi-day products, inventory can be checked for every day of the reservation and will not enable booking if any day of the product is sold out.

RTP|ONE Inventory pool slots and Siriusware Max4Sale slots are synced to Aspenware Commerce inventory tables by an Azure function on a configurable basis. The sync timer is configurable and is defaulted to every N seconds. On this interval, the function obtains the latest inventory numbers from the POS and writes them to the Aspenware Commerce inventory table for each component code or Siriusware Max4Sale value (DCI, Department + Category, or Department) configured in Aspenware Commerce’s Inventory Pool administration.

While the inventory limits available on the shop rely on POS available inventory in RTP|One or Siriusware, it is not called every time a guest navigates to an inventoried product, but rather on a configurable basis. This approach ensures optimal shop performance and eliminates the possibility of overbooking inventory. The inventory that the shop reads from is fully contained within Aspenware and accounts for inventory from the following:

• POS (based on the last sync which runs every N minutes)

• Items that are in guest carts with an active lock

• Items that are in orders that are completed but not “processed” through to the POS

• Items that have been “processed” through to the POS but the inventory sync has not yet run to update the shop with the new POS inventory numbers

Because inventory calls can be taxing to the POS database when the sync runs, the following measures improve the performance of this sync when it runs against the POS database:

• First, redundant calls that could occur when multiple products point to a single RTP|One inventory pool and inventory location or Sirisuware Max4Sale pool are reduced to a single call.

• Second, only dates from today’s date through the end of the season are called. If today’s date is outside of the season, only dates within the upcoming season are called.

  • There is a ‘StoreId’ setting in the function app settings. This means if you have multiple stores, work with your Aspenware Representative to define which store’s season start and end dates the inventory function should use as parameters for dates that it gets inventory for. The current default is 0, which is “All Stores.”

• For products that do not need their inventory to be synced at regular intervals and have high availability, there is an option to only sync inventory for these once daily, which limits the regular syncs to only get inventory for products that could reasonably sell out.

• The function to Update Inventory Pool Codes, which looks for changes to the configuration in Aspenware Commerce inventory pools, can be set to run on a different frequency from the overall Inventory Sync function.

• The inventory sync function was re-written to use Azure Durable function architecture and function chaining to increase performance.

The inventory architecture is diagrammed below.

Open

By utilizing this feature, resorts have control of capacity across any of their products. In turn, this will promote increased control and allow resorts to plan proper staffing for upcoming arrivals. In the case of COVID-enforced limitations, resorts can ensure they are adhering to capacity limitations.

Inventory Display in Aspenware Commerce

On the PDP, If inventory is sold out the date will be displayed with a strikethrough and on mouse-hover a “sold out” message will show.

Open

If enabled, an inventory display threshold can set in Aspenware, the PDP will display available inventory once a date is selected and the available inventory is below that threshold.

The large calendar view will display a crossed-out date with “Sold Out” when inventory is at 0. And if an inventory display threshold is set in Aspenware, inventory below that threshold value will display on the large calendar.

When a guest attempts to add inventory to the cart and no inventory is available. A “toast message” pop-up will appear:

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 an inventory group 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.