Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 55 Next »

Aspenware is happy to present Aspenware Commerce 2.13.0 - 2.13.2. In these releases, we’re introducing enhancements to voucher redemption, new functionality for AxessPUB reload for Siriusware resorts, waiver enhancements, inventory enhancements, and several priority bug fixes. Please also see the 3.8 Unity Release Notes Aspenware Unity release notes for additional enhancements and fixes.


Updates, Features, and Upgrades

Product discount and discount vouchers

Configurable waiver text for waiver signing

Inventory Pool Improvements

Siriusware/AxessPUB Reload Enhancements

Subscriptions - Admins can now update Next Payment Date


Resolved Issues


Known Issues


Things to Look Forward to

Unity Parity - Support for multiple taxes on one component (for RTP resorts using Unity without RTP|Connect)

Continued Performance enhancements

Affirm payment integration

1Risk Waiver Enhancements for Siriusware resorts


Features and Updates

Configurable waiver text

In this release, Aspenware has added several new configurable language strings for waiver labels. This allows the Aspenware Commerce admin to configure whatever is required for the resort’s risk management and legal requirements. For more information, please see the Aspenware Commerce 2.13 Release Guide - Configurable Waivers

Product discount and discount vouchers

Aspenware is excited to introduce new voucher features including product-discount vouchers and discount vouchers. Now, guests can input their product, product-discount, or discount voucher into the voucher banner and easily redeem each voucher format. They can also continue taking advantage of My Account vouchers features to view/print, email, and redeem their vouchers. Now, resorts can utilize and configure each voucher type according to their preferred use and outcome.

As with product vouchers, when a product-discount voucher is redeemed, the guest is taken to the appropriate product display page. Once a guest adds the product to their cart, the product-discount voucher automatically applies, showing the guest’s new discounted price. Alternately, discount vouchers can apply across any number of full-priced products. When a guest redeems a discount voucher, they receive notification that the discount will be applied to the highest-priced eligible product in their cart. As with previous functionality, once the order completes, used vouchers inactivate or decrement in RTP.

For more information see Aspenware Commerce 2.13 Release Guide - Product-discount and Discount Vouchers.

Inventory Pool Improvements

In this release, we’ve made several enhancements to inventory syncing from the resort POS systems (RTP and Siriusware) to Aspenware Commerce. Previously, in some cases, the sync from RTP to Aspenware Commerce was causing unacceptable performance impacts on the RTP database server. In this release, steps were taken to reduce the impacts. For more details on the enhancements, please see the 2.13 Release Guide - Inventory Enhancements. For more details on the fixes, please see Resolved Issues, below.

Siriusware/Axess Integration Enhancements

In this release, we’ve enhanced the Siriusware/Axess integration. This enhancement allows the admin to configure a new classification and a pass media mapping which allows the user to reload during checkout, on the media assignment step. It’s also now possible to map Siriusware department codes in Pass Media Assignment to set different reload eligibility rules for different types of products. For example, all lift tickets that roll up to department code TK-WINDOW could be configured to allow reload for only the current season, while a pass with department code TK-PASS could be configured to allow reload for the past 2, 3, or 4 seasons. Please see the 2.13 Siriusware/Axess Integration Enhancements Guide for more details.

Enhancement - Allow Admins to update NextPaymentDate in Subscription

Aspenware Commerce administrators can now update the Next Payment Date themselves in Subscriptions admin.

  1. for subscriptions where the status is active, the admin can change the next payment date only if it’s a date in the future.

  2. for subscriptions where the status is frozen or canceled, the admin can set the next payment date to a future date, even if the next payment date is in the past. After the admin changes the next payment date to a future date, the admin must then also change the enrollment status to Active.


Resolved Issues

Private Lesson Comments Longer than 255 characters caused order failures

Previously, if a guest entered a private lesson comment that exceeded 255 characters, the order would fail with the message ‘String or Binary Data would be truncated’. This issue has been resolved. Now, if a guest enters a long private lesson comment, it will be truncated to 255 characters so the order succeeds.

Waivers cannot be signed if the waiver doesn't have enough body text to scroll

For waivers that had very brief text in the body, or for guests who had very large monitors, a guest did not need to scroll to get to the I Agree section of the waiver. In this case, the guest could not view the signature form or I Agree checkbox, so it was not possible to sign the waiver. This issue has been resolved.

Mobile waivers - difficult to see/select Sign button

For guests trying to sign their enhanced waivers on mobile devices, it was difficult to view or select the Sign button, so users had to pinch/pull or use the Enter key on the mobile keyboard to sign the waiver, which was a difficult user experience on a phone. This issue is now addressed.

Guests could add to the cart using Quantity Available when inventory was not available for quantities greater than 1

There was an issue on inventory pool products which allowed a guest to add to cart for 2, 3, or higher quantities, even if there was not enough inventory available. For example, if a guest selected a quantity of 10, and there were only 3 slots remaining, the guest could still add to the cart. The guest couldn’t check out with this quantity but could add to the cart. This issue is resolved and guests will receive a ‘toast’ message on the PDP when adding to cart, explaining that no more inventory is available and the item will not be added to the cart.

Guests could add more slots than available by selecting Add To cart repeatedly

Previously, if guests continued selecting Add to Cart repeatedly, they could continue adding to cart to add more inventory than was available. They couldn’t check out (and received a message explaining that inventory was not available), but they could add to the cart. This issue is resolved and guests will now receive a ‘toast’ message on the PDP when they attempt to add more to the cart than is available.


Known Issues

In these release notes, and for future major releases, Aspenware will now include a summary of issues that are present in the release, and which have not yet been addressed. This summary is not an exhaustive list of every issue, but it includes both bugs Aspenware found in internal testing and bugs which have been reported but not yet addressed. Some issues described here are planned for near-term release, either in the next hotfix, or the next major release. Others, such as the scenarios that overbooking can happen are a result of the way that the inventory syncing to Aspenware commerce happens and are not planned to be mitigated in the near term.

Detailed error messages no longer displayed to admins in Order Queue

Previously, the Aspenware administrator could view detailed stack trace error messages for failed orders in the Aspenware Order Queue. These details exposed product setup issues to the admin, so he/she could correct those errors and set the orders to ready.

Voucher banner overlaps cart for some sites

This visual bug is present for some resorts using vouchers. The guest can still use his voucher, and check out with it, but it’s unattractive.

Customer not defined creates partial order in RTP|ONE

For some resorts, products that require assignment are sending some order lines to RTP, but not others. This results in an incomplete order in RTP|ONE, which causes reconciliation and fulfillment problems for the resort.

Default rental location only defaults if the cart contains rental products only

For resorts using the default rental location feature, there’s a reported problem with carts that contain non-rental products. In this case, the rental location selection and map are being displayed to the user when they should not be.

Guests can add more slots than available to the cart when initial locks expire but cannot successfully checkout with these

If a guest adds the last remaining spot to the cart, waits for the lock to expire, and adds that product to their cart again, they could add 2 to the cart when only 1 inventory spot is available. They would; however, be blocked from checking out with more than the available inventory in checkout.

Scenarios where inventory can oversell

Scenario 1: If the inventory is sold out or adjusted to 0 or unavailable in the POS and the sync to Aspenware Commerce has not yet run, then a guest could checkout on Commerce with the remaining inventory spot(s) that were available when the sync last ran. In this case, Aspenware may oversell the inventory available in the POS. To note is that with RTP|Connect order processing, the order may fail in the order queue. With Unity order processing, the order will process successfully, potentially overbooking the inventory.

Scenario 2: This scenario is rare and unlikely, but if two guests are competing for the same final inventory spot(s) and they both complete checkout within a few seconds of each other, both orders may succeed, thereby overbooking the inventory.

Scenario 3: This scenario is rare and unlikely, but if product A and product B both point to the same inventory pool and the same guest adds the last spot of product A to the cart, waits for the lock to expire, and then adds the last spot to the same cart again via product B and checks out, their order will succeed thereby overbooking inventory. A guest cannot successfully checkout with 2 spots for product A when only 1 remains, but they can successfully checkout with 1 spot via product A and 1 spot via product B.

Scenarios where inventory can undersell

  • No labels