2.13 Commerce Release Notes
Aspenware is happy to present Aspenware Commerce 2.13.0 - 2.13.3. 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.
A word on upgrade downtime: For resorts who are upgrading from Aspenware Commerce versions 2.12.3 (or older), downtime is required for upgrading to 2.13 or higher.
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
Enhancements to the Product Detail Page
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 Configuration: 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 Configuration: Vouchers.
Dedicated voucher validation page (2.13.2)
In addition to offering voucher validation through the new voucher banner as well as My Account, Aspenware Commerce now offers an optional dedicated voucher validation page. This page, which is unique from a PDP, can be linked to from anywhere. When a voucher ID is entered, the guest is navigated through the existing validation modal and, if successful, will be prompted to redeem their voucher. As with all voucher validation, in the case of a product or product/discount voucher the guest will be navigated to the appropriate PDP; in the case of a discount voucher, the guest will be prompted to carry on shopping in the case of a discount voucher. For more information, or to implement this feature see the article Creating a Dedicated Voucher Page.
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 Configuration: Pick Up Box 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.
for subscriptions where the status is active, the admin can change the next payment date only if it’s a date in the future.
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.
Billing Address Collection now supported with Square payments (2.13.3)
Previously, for resorts using Square payments, it was not possible to collect a full billing address on the payment step, or to save that address information to the POS. Aspenware’s integration to Square payments offers address verification for PostalCode/Zipcode only.
However, with this enhancement, it’s now possible to collect a Billing Address on the payment step, and that address will be sent to the POS (either Siriusware or RTP|ONE) and saved to that guest’s address in the POS. *IMPORTANT: When this feature is enabled, the guest must enter the postal code twice, because the postal code collected for Square uses hosted fields. The billing address fields (line 1, line 2, city, state, and postalcode), which save to the POS customer’s record, cannot use that same hosted PostalCode field. No changes were made to the Square integration for this enhancement. This feature can be enabled in Payment Method configuration in Aspenware Commerce Administration.
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.
Detailed error messages no longer displayed to admins in Order Queue
Previously in the 2.13 version, the Aspenware administrator could not view detailed stack trace error messages for failed orders in the Aspenware Order Queue. These details now expose product setup issues to the admin, so he/she can correct those errors and set the orders to ready.
Known Issues
In these release notes, and for future major releases, Aspenware will 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 reported issue, but it includes both bugs Aspenware found in internal testing and bugs which have been reported but not yet addressed. The known issues listed here are planned to be addressed in a near-term release, either in the next hotfix (planned for early February), or in the next major release (planned for early March).
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.
For resorts using Identity, newly created accounts are sometimes created with missing birthdates
Resorts who use Identity for authentication in Aspenware Commerce have reported an intermittent problem for some accounts. For some (not all), they’re being created without a birthdate. A birthdate can be added during checkout on the Assign Products step for accounts that are created in this state.
Guests can add more slots than available to the cart when initial locks expire but cannot successfully checkout with them
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. The guest cannot checkout with those two slots, the guest will receive an insufficient inventory message.
Inventory order lock is not removed on initial inventory sync (but it is on the next sync)
This release guide details what was changed about Aspenware Inventory for this version. In this guide, you’ll find an architecture diagram that explains how inventory locks work. This issue is that locks are not removed the first time inventory is synced from the POS. On the next sync, they are removed. This results in double-counting inventory for n minutes until the sync runs again. To restate another way, locks are being held for too long, since they are not removed the first time after the inventory sync from POS to Aspenware Commerce runs, but on the second sync after the order completes. So, a single slot can be counted twice for several minutes (1 from the order lock that was not immediately removed, and 1 from the updated inventory sync from the POS, which then has that slot decremented). This known issue can be mitigated by setting the inventory sync to run in pairs. First, figure out how long the inventory function takes to run in your environment (e.g., the function takes 2 minutes to run). Then, set the inventory function to run back to back on the interval it was configured to run before (i.e., if it was set to run every 15 min, and the function takes 2 minutes to run, set the inventory function to run every 13 minutes and every 15 minutes).