Winter '23 Changelog
This is a list of every change made in the Winter '23 release of Nimble AMS.
Nimble AMS Staff View
What's new?
Improvements to NU.ShippingService ship method.
Single ship method can now apply to multiple shippable products in an Order. (AMS-12761)
This affected you if you:
• Use ship method for customers
• Have shippable product
What areas in my system have changed? Shipping method
Defects Fixed
Payment Method selection in order process made defect free.
Error making payment with Stored Payment Methods due to conflicting Payment Method Name. (AMS-12700)
This affected you if you:
• Process ACH Debit Card Payment
• Process E-Check Payment
• Make Payment using E-Check Stored Payment Method, in Staff View & Association Member in Community Hub
Original System Design: Stored Payment Methods (regardless of Payment Method name) should be used to successfully make payment without failing.
Solution: Order process (Order API) has been updated to process using Record Type on Payment Method instead of Payment Name (Ex: an eCheck payment method with a name of “Cash” would be selected when using the eCheck method of payment).
What areas in my system have changed? Orders, Accounting, Payment
Transfer payment on a cart item now processes only once.
When staff clicks the Transfer button multiple times to transfer the balance from canceled to active cart items, the payment transfer processed multiple times, resulting in numerous payment lines/overpayments. (AMS-12703)
This affected you if you:
• Edit Orders to move payment
• Transfer Payments from one cart item to another
Original System Design: Transfer payments should only process one time for the specific cart item in an order, even if staff clicks the ‘Transfer’ button multiple times.
Solution: Transfer payment logic has been updated to ensure that transfer payment on an order is processed only once, regardless of the number of times the Transfer button is clicked.
What areas in my system have changed? Accounting, Payment Transfer
Updated the system to keep record count of schedules that ran and failed.
Once staff runs a schedule and it fails with an error: “No recurring eligible products that match the frequency was found for the order item associated with this schedule”, the system did an indefinite re-try of schedule runs, even when the staff is no longer performing deliberate actions to run the schedule. (AMS-12793)
This affected you if you:
• Run schedules
• Have a failed schedule run
• Have recurring schedule runs
Original System Design: There should be an incremental record count of schedules that run and fail, so that it does not automatically run indefinitely.
Solution: The system was updated to keep incremental record of retries for failed schedules, before generating the order items
What areas in my system have changed? Scheduled payments
Non-shippable products can now be added to orders.
Community Hub (CH) users were unable to submit orders if they had only non-shippable products (For example: Membership, Registration) in their order. They received error: “Cart must have at least one shippable cart item”. (AMS-12778)
This affected you if you:
• Have users who use CH to place orders on non-shippable cart items
• Tried to process an order for non-shippable product on behalf of CH user
Original System Design: Order submission in Staff view or CH should process successfully, even if the cart item consists of only non-shippable items.
Solution: System updated to allow order processing of products that are shippable or non-shippable.
What areas in my system have changed? Order, Cart Items, Checkout page in CH
Scheduled jobs for one-time business events updated to process once.
An organization’s customization could sometimes create orders from scheduled jobs (batch jobs), preventing Staff from enabling Business Events. This could cause duplicate jobs to run and require staff to manually clear the job (AMS-12786).
This affected you if you:
• Create custom job batches.
• Offer Event(s)
• Use Order API
Original System Design: Staff should be able to enable business events, even when their system has customizations to create orders from batch jobs.
Solution: The scheduled job process, relative to one-time business events, has been configured to be removed from the schedule job page after execution.
What areas in my system have changed? Event, Order, Schedule jobs
Transaction reference group numbers now generate individually.
Incorrect reference group numbers could be generated when multiple orders was created at the same time. (AMS-12711)
This affected you if you:
• Perform Intercompany transactions
• Have Multiple Entities
• This could potentially affect GL Accounts, GL Export.
Original System Design: Unique reference numbers should be generated for each transaction, even across multiple orders, that is; no 2 transactions should have the same reference numbers.
Solution: Order Process and Transaction API was updated to ensure unique reference numbers are generated.
What areas in my system have changed? Accounting; GL Export, Payment Transaction
Coupon on an order can now be applied only once.
Community Hub (CH) users could reapply one coupon multiple times on an order, resulting in accounting impact and reconciliation issues. (AMS-12770)
This affected you if you:
• Apply coupon to orders
• Open cart items on multiple tabs and apply coupon
Original System Design: Coupon application should process only once on an order.
Solution: Developed SOQL query to check cart items for previously applied coupon and if one exists, the system ignores re-application of that coupon.
What areas in my system have changed? Accounting, GL, Order, Cart Items
Payment processing errors have been fixed.
Duplicate transaction(s) are recorded in Order Processor when staff clicks ‘Save’ multiple times on payment, so association members are charged for the payment of one order multiple times. (AMS-12755)
This affected you if you:
• Process orders in Staff view of Nimble AMS
• Use Stored Payment to perform an order transaction
• Process Accounting entries
Original System Design: Only one payment transaction should be recorded for one order.
Solution: Once the first payment is approved in order processor, other payments are ignored, even when you click ‘Save’ multiple times.
What areas in my system have changed? Review Payment transaction
Payment for Taxable/Non-shippable products have been fixed.
Payment on Registration or Digital product(s) generates an error, "Tax needs to be recalculated" (Tax column shows $0), in staff View of Nimble AMS. This error occurs because taxes and shipping are calculated on the digital product, but only tax should be calculated on a digital product. (AMS-12775)
This affected you if you:
• Use Advanced Taxation feature
• Process orders for Registration or Digital product
• Run Billing History
Original System Design: Staff can process order on a digital/registration taxable(non-shippable) product(s) and pay taxes (Taxes column should be > $0), without paying for shipping.
Solution: Tax calculation is no longer processed in Staff View.
What areas in my system have changed? Orders, Accounting. For example: In your Order/Accounting details, ‘Total Tax’ and ‘Total shipping and Tax’ fields should now have the sale $ amount)
Updated shipping method to reflect only shippable Products.
Shipping fees applied to non-shippable (registration, digital) products, causing shipping fees to be applied on digital products. (AMS-12750)
This affected you if you:
• Staff or association Members buy shippable and non-shippable products in one order
Original System Design: Shipping method should be applicable only to shippable products
Solution: Our system has been updated to ensure that Ship Method is only applied to shippable products in cart.
What areas in my system have changed? Orders, Tax & Shipping
Updated ScheduleLineProcessor to enable manual job run.
Manual ScheduleJob method was not visible and accessible to staff. (AMS-12717)
This affected you if you:
• Have an auto scheduled job (scheduled payment) that runs at a time zone that excludes some scheduled customer payment or recurring memberships.
• Would like to choose a time to run your scheduled job/payment.
Original System Design: ScheduleJob method was not visible to Staff.
Solution: Introduced a new global constructor to provide visibility for ScheduledJob
What areas in my system have changed? ScheduledJob processor, scheduled payments
Updated Deferred Schedules to honor end date of transaction regardless of the user’s time zone.
Registration Orders that have Deferred Revenue Method (DRM) would sometimes create deferred schedules with different start and end dates, depending on the time zone. (AMS-12713, AMS-12767)
This affected you if you:
• Use Deferred Revenue Method (DRM)
• Have Registration products for users outside of the organization’s time zone
• Have users who run Deferred Schedules on different time zones
Original System Design: Deferred Schedules should honor the organization’s end date for a registration product, regardless of users’ time zone
Solution: Deferred Schedule process updated to acknowledge Organization’s start and end date, as the same start and end date for registration products.
What areas in my system have changed? Deferred Revenue, Deferred Schedule, Registration
Using Cancel Membership Mid-Term now shows the correct transaction date.
The transaction date on a mid-term membership cancellation was generating the original date of membership order. (AMS-12736)
This affected you if you:
• Process mid-term membership cancellation
Original System Design: Mid-term membership cancellation should generate the date the membership was cancelled not the date of membership order.
Solution: System was updated to recognize the date of membership cancellation as the transaction date.
What areas in my system have changed? Cancel Membership
Improved limitation on the use of One Payment on Cross-entity orders transactions that have multitude of transaction lines.
‘Payment Failed’ error when using One Payment to process cross-entity orders with multitudes of transaction lines. (AMS-12739)
This affected you if you:
• Attempted payment for multiple transactions with products from different entity
• Attempted payment for multiple transactions when Order entity is different from product entity
Original System Design: ‘Payment Failed’ error when using One Payment to process cross-entity orders with multitudes of transaction lines.
Solution: Updated the product to generate transaction group reference numbers before generating transactions for the payment lines
What areas in my system have changed? One Payment Wizard (Payments on multiple cross-entity orders can be made with no error)
Cancel Membership Mid-Term now supports Hosted Credit Card payment type.
‘Refund Failed’ error when users cancel memberships (mid-term) and request a refund back to the Hosted Credit Card the membership Payment was made. (AMS-12752)
This affected you if you:
• Made Payment using a Hosted Credit Card and canceled the membership (and requested refund) using the Cancel Membership Mid-term.
Original System Design: Cancel Membership and Refund should process successfully
Solution: The Cancel Membership Mid-term feature has been updated to support Hosted Credit Card Payment type
What areas in my system have changed? Cancel Membership Mid-Term (Refund failed error will no longer persist)
Added error message to display when a used coupon is reapplied.
Association members can apply a coupon multiple times for a single order, if they have multiple tabs of their cart, open. (AMS-12738)
This affected you if you:
• Use Coupons
Original System Design: Coupons should only be applied once, on an order. If that coupon has been applied once by a member, it should not be reapplied again.
Solution: Updated the product to validate that a coupon is only used once, and an error is generated if an already used coupon is reapplied.
What areas in my system have changed? Order, Cart, Coupon
Added a new column to Deferred Schedule.
Cancel Membership Mid-Term was generating inconsistent transactions. (AMS-12595)
This affected you if you:
• Use Deferred Schedule
Original System Design: Deferred Revenue should account for the period of active membership when a mid-term cancellation happens.
Solution: Added a new column to distinguish revenue type for Actual, Forecast or Forecast Catchup. This inconsistent transaction will still appear on your Deferred Forecast Detail but can be identified using the ‘Type’ column.
Note:
Actual: This is revenue received for that accounting period (month)
Forecast: This is revenue that is forecasted for future receipt
Forecast Catchup: This is revenue recognition for the period when membership duration was active.
What areas in my system have changed? Deferred Forecast Detail
Users can now cancel their membership in the current month and consecutive months.
When staff user tries to cancel membership in the current month, by using the Manage Membership button, they get error: ”Value Provided is invalid….. ”, which hinders them from a successful membership cancellation. (AMS-12602)
This affected you if you:
• Use Cancel Membership
• Use Cancel Membership and Proceed to Refund
Original System Design: Membership cancellation should be possible in the current month or consecutive months after.
Solution: We have implemented a system that allows membership cancellation possible in the same month of transaction.
What areas in my system have changed? Cancel Membership, Cancel Membership and Proceed to Refund
Deferred Forecast Detail configured to sort by transaction date (oldest to newest).
Transactions on Deferred Forecast detail could be out of order. (AMS-12632)
This affected you if you:
• Use Deferred Forecast Detail
Original System Design: Transactions on Deferred Forecast Detail sorted by ID
Solution: Improved the view on Deferred Forecast Detail to sort transactions by date
What areas in my system have changed? Deferred Forecast Detail
Fixed Shippable product issue on Order Item Lines.
When using Express Payment, the 'Shippable' checkbox on Order item (Shippable Product) would sometimes become unchecked, marking it as non-shippable product. (AMS-12638)
This affected you if you:
• Make Order payments using Express Payment
Original System Design: The checkbox on ‘Shippable' products in Order Item line should remain checked on all shippable products, regardless of the payment method.
Solution: Enabled system validation to ensure products on order item lines (regardless of payment method) have:
‘Shippable’ checked on shippable products
‘Shippable’ unchecked on non-shippable products
What areas in my system have changed? Orders, Cart Items
Deactivated Delete option for carts with Hosted Credit Card payment.
Staff delete carts (after payment has been stored) for different reasons, but this caused discrepancy with the Hosted Payment Method(s) (BluePay), because transactions sometimes appeared as paid in Bluepay but would not have a corresponding record in Nimble AMS. (AMS-12633, NC-6234)
This affected you if you:
• Place orders using Carts
• Deleted cart orders
Original System Design: Once payment has been entered for a cart, staff cannot delete the cart and should continue with the transaction and process payment, to avoid financial discrepancies.
Solution: Introduced a trigger to display an error letting Staff know that the cart cannot be deleted, and payment can be voided after processing.
What areas in my system have changed? Cart, Order, Cart item, Account
Event Badge will remain linked to the event registration while using coupons.
In some instances, after editing an event badge, the badge would become linked to the coupon rather than the event registration, making it inaccessible to the registration process. (AMS-12683)
This affected you if you:
• Applied coupon on an event badge
• Modified an event badge
Original System Design: Event Badges should remain linked to the registration, and not the coupon, after editing.
Solution: Configured our system to ensure event badges remain linked to the registration even if the badge was edited or coupon was applied.
What areas in my system have changed? Event badge, Coupon
One Payment Wizard now applies the batch date on transactions for manual batch.
When One Payment is used with a manual batch, the current date (date of manual batch run) is used on the payment record, instead of the original creation date on the batch transaction. (AMS-12653)
This affected you if you:
• Use One Payment
• Use Manual Batches
Original System Design: Applying One Payment to a Manual Batch should generate transactions for original batch date.
Solution: Changed the One Payment wizard to use the Transaction Date of the selected Manual Batch
What areas in my system have changed? Accounting, Batches, One Payment
Registration count now updates each time a user registers for an event.
Registration Counts for events were not updating correctly when the Sync with LMS checkbox on event record was checked, resulting in additional registration even after maximum registration for the event has been exceeded. (AMS-12861)
This affected you if you:
• Have a set maximum registration your event
• Use Sync with LMS
Original System Design: When users are registered for an event, registration count should update accordingly.
Solution: Updated logic to ensure that the record for each event registration is counting toward the maximum event registration count.
What areas in my system have changed? Event, Event Registration, Sync with LMS
Coupons can now be applied on product-specific order items.
Staff is unable to apply a coupon on a product that is a part of multiple order items in a cart or order. (AMS-12861)
This affected you if you:
• Applied a coupon for a specific product and there are other items in that order
Original System Design: Coupon application on specific products should be successful, even when there are other items on the cart or order.
Solution: updated the product to correctly apply product specific coupons
What areas in my system have changed? Coupon, Order, Cart
Scheduled job processing can now run without error, even on weekends.
Sometimes, when staff users process Scheduled Jobs, they would encounter an error “Your request was running for too long…” in ScheduleLinesProcessorJob (Apex job). (AMS-12665)
This affected you if you:
• Use ScheduleLinesProcessor
• Process schedules on weekends
Original System Design: ScheduleLinesProcessorJob should run without error at any time.
Solution: Updated system to ensure Flexible Payment jobs utilize selective SOQL queries, which limits the count of record retrieved, and ensured that Scheduled job processing ran without error.
What areas in my system have changed? Scheduled Job
Stored Payment has been integrated between cross-entities for Recurring Payment.
Recurring payments fail because the payment attempt is made to the order's entity (which has no stored payment method). (AMS-12604, AMS-12600, AMS-12594, AMS-12579)
This affected you if you:
• Use cross-entity order
• Process recurring payment
Original System Design: Recurring payment should be made with the original stored payment method, the user authorized at the beginning of the recurring payment (membership).
Solution: Recurring payment process will first check the order entity for a stored payment method (SPM). If SPM is unavailable, the process will then use the original stored payment method the user authorized at the beginning of the recurring payment.
What areas in my system have changed? Orders, Carts, Cash Billing, Recurring Payment
Synchronization of cart count and related carts for batch record.
Manual adjustment on batch records does not update the new records, resulting in inaccurate cart count. (AMS-12676)
This affected you if you:
• Manually adjusted batches
Original System Design: Cart count should automatically refresh when a batch is adjusted manually.
Solution: Included functionality to refresh cart count based on carts that were manually adjusted.
What areas in my system have changed? Batch
Improved Scheduled Payments job to suit Pacific Time zone.
In some organizations, the nightly "Process Scheduled Payments" Job ran at 2 am, which represents the previous day for Pacific Time users. This resulted in those users' payments not processed at the scheduled time (AMS-12654)
This affected you if you:
• Use Scheduled Payments
• Process scheduled payments for users on pacific time zone
Original System Design: Scheduled payments should be processed at the organization’s scheduled time, regardless of user’s time zone.
Solution: Configured the Process Scheduled Payments Job to accommodate pacific time zone, without throwing off scheduled date.
What areas in my system have changed? Scheduled payments
Removed error message on voided payments screen.
Voided payments on credit card transactions generated an error, if payment was voided before payment was charged. The voided payment goes to a queue process and remains stuck there due to voided payment. (AMS-12657, NC-6233)
This affected you if you:
• Voided Payments
Original System Design: Once a payment is voided, the queue process should be clear and free of error
Solution: Clearing queue process for voided payments and ensuring that ‘Pending capture’ checkbox is unchecked on the payment record.
What areas in my system have changed? Payment, Voided Payment, Credit Card
Allow payment processing on recurring cart items, even after Stored Payment method has been deleted.
Staff receives error “entity is deleted“, when they attempt to submit a cart item marked for autorenewal, if the stored payment method was deleted. (AMS-12531)
This affected you if you:
• Submit order for recurring items
Original System Design: If a stored payment is referenced in an existing recurring cart item, the order submission should be successful even if the stored payment gets deleted.
Solution: Developed solution to allow Staff process carts on recurring cart items.
What areas in my system have changed? Cart Item, Submit Order, Recurring payment
Improved Custom Profile compatibility with Membership functionality.
Staff users added to custom profiles that allowed them to create carts or orders, sometimes did not have permission to Product Frequency object, causing them to encounter error. (AMS-12705)
This affected you if you:
• Use Custom Profile
Original System Design: Error should not occur for users with custom profile where Product Frequency is assigned.
Solution: Configured permission to only throw error when recurring payments toggle is on and permissions for Product Frequency Link is not assigned to the user’s custom profile.
What areas in my system have changed? Custom profile, Product Frequency Link
Community Hub
Defects Fixed
Card view made error free for orgs with 1000+ objects.
Community Hub users, affiliated with organizations that have over 1000 objects in a list, encountered error when they click on a card name to open, modify the card or create a new card. (NC-6240)
This affected you if you:
• Have over 1000 objects in a list in your Nimble AMS org
• Have users who process payment in Community Hub
Original System Design: Users should successfully modify existing card or add a new card to their interface without error, regardless of the object list on an organizations system.
Solution: Improved card interface to accommodate user card modification without error.
What areas in my system have changed? Community Hub Checkout
Join or renew page now captures changes made on Recurring Donations.
Changing a recurring donation to a one-time Donation from the myCheckout page, while editing the cart, did not update the donation on the Join/renew page. (NC-6105)
This affected you if you:
• Have users who use donations in Community Hub
• Have users who change donation from recurring to one-time
Original System Design: The Join/renew page should automatically reflect and update any change on the donation that a Community Hub user has made.
Solution: Updated the capturing process of donations to ensure that the Join/renew page captures any update to the donation.
What areas in my system have changed? Donation
Seasonal Permission Changes
See the Winter '23 Permission Changes in the Security section.