Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Excerpt

Aspenware Commerce’s Inventory feature can be used to control the quantity number of sales allowed for a given day for a specific product or product variant based on Inventory configured in the resort POS. Inventory supports cart locking as well, so when an inventoried product is added to the cart, that available inventory spot will be reserved for them until they check out or their lock expires.

Tip

This feature is supported for: RTP Inventory Pools , and Siriusware Max4Sale

Warning

This feature is NOT supported for : Sirusware Points4Sale

Key Terms

Excerpt

Inventory Function

RTP|ONE Inventory pool slots and Siriusware Max4Sale slots are synced to Aspenware Commerce inventory tables by an Azure function. The sync timer is configurable and is defaulted to every 5 minutes. 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 DCI configured in Aspenware Commerce’s Inventory Pool administration.

Inventory Locking

When a customer adds to the cart, they “lock” in their inventory and are guaranteed their spot for as long as the lock for the product they added to the cart is configured for. If a guest tries to checkout after their lock time expires, the system attempts to get a new lock. If their lock expires and the product in their cart is still available, they will obtain a new lock and be able to check out. If the product in their cart sells out between the time their lock expires and they check out, they will be prevented from buying that product. Locking prevents another guest from “stealing” inventory if they are faster at checking out. Locking also eliminates the possibility that inventory can over sell oversell if the order processor is delayed.

Inventory Pools

The term in RTP is used for inventory control. In RTP inventory is pooled, meaning multiple product headers can pull from a common inventory pool and all decrement the same inventory, so if the inventory pool is sold out for a date, it will be sold out for all products using that inventory pool.

Max4Sale

One of two inventory control mechanisms in Siriusware, the other being Points4Sale which Aspenware does not yet support. In Siriusware Max4Sale inventory is per product, meaning multiple product headers cannot pull from a common inventory pool and all decrement the same inventory. Each DCI has its own Max4Sale allotment, and when its it's sold out for a date, only that single DCI will be sold out.

Feature

...

Description

If a product should be limited from being sold on dates when Inventory in the POS is sold out, then set up Inventory in Aspenware Commerce. Based on this setup, 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 “warning” thresholds are configured by the resort. When a shopper 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 (drawing from the most recently synced inventory). If in the rare case that a guest adds a product to their cart, their cart lock expires, and that product becomes sold out between the time of add to cart and their checkout, inventory for the products in their cart are checked again before the guest completes their order. 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 be setup set up to check 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. To ensure that this inventory sync doesn’t result in POS performance slow downs slowdowns when it runs several optimizations have been made.

While the inventory limits available on the shop rely on POS available inventory in RTP or Siriusware, it is not called every time a guest navigates to an inventoried product, but rather on a configurable basis. This approach ensures optimial 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 POS (based on the last sync which runs every N minutes) and active items that are in carts where the lock is not expired and items that are in orders that are completed but not “processed” through to the POS.

Because inventory calls can be taxing to the POS db DB 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 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 for. If today’s date is outside of the season, only dates within the upcoming season are called for. And finally, 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 reasonable reasonably sell out.

This inventory architecture also enables inventory locking functionality, which locks inventory at configurable - the default is a 15-minute lock (or 900 seconds), but lock time is configurable by product. When a customer adds to the cart, they “lock” in their inventory and are guaranteed their spot for as long as the lock for the product they added to the cart is configured for. If a guest tries to checkout after their lock time expires, the system attempts to get a new lock. If their lock expires and the product in their cart is still available, they will obtain a new lock and be able to check out. If the product in their cart sells out between the time their lock expires and they check out, they will be prevented from buying that product. Locking prevents another guest from “stealing” inventory if they are faster at checking out. Locking also eliminates the possibility that inventory can over sell oversell if the order processor is delayed.

...

By utilizing this feature, resorts have control of capacity across whichever products they wish to limit sales on. In turn, this will promote increased control and allow resorts to prepare for upcoming arrivals to ensure proper staff. In the case of COVID-enforced limitations, resorts can ensure they are adhering to capacity limitations.

...