NCS Circ Rapid Release: 2020-6.2

Product Information contained within this document, including technical information and functional specifications, is subject to change without notice, and Naviga reserves the right to make any changes to the information in this document at any time without notice. Naviga makes no warranty, representation, or guarantee regarding the suitability of its products and services for any particular purpose.

Introduction and Minimum Supported Configuration

Welcome to the NCS Circulation 2020-6.2 release. This release introduces enhancements and a variety of program changes to address issues from previous versions.

Changes have been implemented to prevent overlapping Temporary Stop and Move transactions, ensuring the correct processing order. Issues with GL account assignments for PayPal payments and declines of Credit Card AutoRenew Payments after Billing Changes have been resolved. Additionally, Circ API issues have been addressed, including handling of Billing Changes, tip amounts, postal code formats, and RateCode processing.

This release includes changes to iServices, SubscriptionLink, and MicroAPIs to prevent the creation of Vacation Stops on holidays or non-publishing days.

Minimal Requirements

• If using Naviga Pay for payments, a minimum Naviga Pay version of 2.2 is required for

  2020-6.2.

• If using Payment Authorization Service, a minimum PAS version of 8.11.61 is required for

  2020-6.2.

• A minimum Circulation version of 2020 is required to upgrade to the 2020-6.2 release.

Resolved Issues

Customer Service

• Previously, changes in NCS Circ prevented users from creating a Temporary Stop transaction if it overlapped with an existing Move transaction for the same subscription. This restriction has now been removed, allowing users to create Temporary Stop transactions even if they overlap with Move transactions. (CM2-11455, CM43#6750 - HM43#970)

Accounting

• When running the Auto Renew Notice Export for a single product with the ‘Renewal Type’ set to ALL, the Billing Group field only displayed options for Bank Draft. This issue has been resolved, and the Billing Group now displays all valid billing groups when the Renewal Type is set to ALL. (CM2-10249, CM43#6320)

Tools

• Previously, when running the Bonus Day Delivery, if the reason code selected in the Bonus Day transaction did not match the reason code defined in the Business Rule ‘What is the default reason code for bonus day transactions for subscribers who opted out of bonus day papers? (Customer Services section)’, the Bonus Day transaction would still get processed. However, when publishing ahead to the bonus date and running the final transaction processing, the Bonus Day transactions would be deleted. This issue has been resolved by removing the validation based on Reason Code and Receive Bonus Day settings that determined whether to delete Bonus Day transactions during final processing for the Product.

  Now, in the Bonus Day Delivery, if the Reason Code selected does not match the value set in the Business Rule, the transaction will still be processed and will not be deleted after the final transaction processing. (CM2-11335, CM43#6710)

• Character Utilities > System > View/Print > Run > Unearned Revenue Batch When running Unearned Revenue from Batch, if the batch file had an end date beyond the current publishing date, the process was previously completed without an error. This issue has been resolved. Now, if the batch file end date is beyond the current publishing date, an error message stating 'Publishing is not completed for product 'xx' on xx/xx/xx' will be displayed. Note:– This error message will only be shown when the 'All Accounts' field is set to Yes. (CM2-11536, CM43#6890)

Naviga Subscribe Integration

• A fix program has been created to ensure that the Default Answer and SaaS Default Answer for the Business Rule— ‘What is the default format for date type input and output parameters received and sent in Circ and Micro APIs? (Circ API section)’ are set to the ‘-d’ parameter in the startup.pf file. The error messages 615 and 616 in the Micro API getRateCodes will now reflect the policy answer of the above Business Rule. If the Business Rule answer is set to ‘mdy’:

  1. Error 615: ‘No value passed for required field - startDate. (MM/DD/YYYY)’

  2. Error 616: ‘Invalid value for parameter - startDate. (MM/DD/YYYY)’

  (CM2-10758, CM43#6120)

Payments

• The issue with Credit Card AutoRenew Payments being declined after a Billing Change is entered to update the existing AutoRenew information with a new Term or Length has been resolved. (CM2-9867, CM43#5070)

• Previously, when running the Transaction Processing before the Payment Processing, pending Auto Renew PayPal Payments were processed, resulting in a GL transaction with a blank GL account even though the PayPal Auto Renew setup existed in the Credit Card Account screen (Accounting > General Ledger > Credit Card Account). This issue has been resolved, and the GL transaction will now be created with the correct GL account. (CM2-10101, CM43#6070 - HM43#840)

Circulation (Circ) API

• When submitting a Billing Change using the Circ API with the RenewalType field set to Current for a subscription that is already on bank draft autorenew, an error was displayed. This occurred because the bank ‘Client Type’ field in the database was saved as blank while creating a bank draft autorenew subscription. Changes have been made so that the ‘ClientType’ field is no longer mandatory and can be left blank when entering a Billing Change with the RenewalType field set to Current. (CM2-10201, HM43#820)

• Previously, the BankType field was mandatory when entering a Billing Change using the Circ API with the RenewalType field set to Current, resulting in an error if the BankType was left blank. This issue has now been fixed. Changes have been made so that the BankType field is no longer mandatory and can be left blank when entering a Billing Change with the RenewalType field set to Current. (CM2-11437, HM43#940)

• The CreateSubscription Circ API was previously calculating an incorrect Start Date for Combo Subscriptions compared to Customer Services when the Carrier Entry Rule was applied. This issue has been resolved, and the Circ API now calculates the correct Start Date for Combo Subscriptions, in alignment with Customer Services. (CM2-10097, HM43#850 - CM43#6180)

• The issue with the ‘CreatePayment’ Circ API allowing tip amounts to be entered for mail or online subscriptions has been resolved. When using the ‘CreatePayment’ Circ API to create a payment with a tip amount on an online or mail subscription, the tip amount will now be added to the payment amount with the warning message “Warning! Tip amount is not applicable for online or mail subscriptions. Tip amount moved to the payment amount”.

  In addition, if a tip has been provided in the payment-related fields of other Circ APIs for an online or mail subscription, the provided tip amount will be ignored.

  (CM2-10563, CM43#6030 - HM43#830)

• When the Business Rule—’What is the default bank for subscription payments? (CMO – Subscriber > Payments Section)’ was set at the Publication level, the default BankID defined for products was not populating correctly in Payment transactions for subscriber bank draft payments made through the CreatePayment Circ API. This issue has been resolved. (CM2-11100, HM43#870)

• Previously, non-RateCode-related BillingChange transactions created through the Circ API were generating a RateChange child record with the subscriber’s current RateCode in both the Old and New RateCodeID fields. Additionally, if the rate was a promo, the next payments were being processed at the promo rate instead of the normal rate, even if a payment had already been made with the promo rate. This issue has been resolved. Now, if a promo RateCode is being used by a subscriber, no RateChange child record will be created for non-RateCode-related BillingChange transactions initiated from the Circ API, and the next payment will be processed at the normal RateCode.

  (CM2-11375, CM43#6820)

• Previously, when a subscriber on a promo RateCode made a payment, the next payment should have switched to the next RateCode. However, if the Renewal transaction from the first payment was still unprocessed, the second payment continued to use the promo RateCode. This issue has been resolved. Now, regardless of whether Renewal transactions are processed or not, payments switch to the normal RateCode for subsequent transactions after a payment has been made with the promo RateCode.

  (CM2-11381, CM43#6770- CMO43#780 - HM43#980)

• When the Business Rule— ‘What system do you use for Address Correction and Encoding software? (Address Cleansing section)’ is set to ‘QAS,’ the fields ‘QASAddressLine1,’ ‘QASDPID,’ and ‘QASScore’ will now be non-mandatory in the Add Address/Occupant Circ API. (CM2-11379, HM43#920)

• The error “Invalid value for parameter, Postal Code,” which was displayed when submitting Canadian Postal Codes in the format of 7 characters (FSA, a space, and LDU; for example, “L1E 3J4”) in the FindTax Circ API has now been resolved. Handling of Postal Code Input:

  1. FSA Only: If only the “FSA” (Forward Sortation Area) is provided in the input Postal Code, the first matching Zip and Zip City will be displayed.

  2. FSA and LDU: If both the “FSA” and “LDU” (Local Delivery Unit) are provided, the exact match will be displayed.

  3. No Exact Match: If an exact match is not found, an error will be returned.

  (CM2-11380, HM43#930)

• Previously, in the FindTax Circ API, if an FSA+LDU combination was provided and no exact LDU match was found but a valid FSA existed, the API would throw an error. Changes have now been made so that if an FSA+LDU combo is provided and the LDU has no exact match, the API will return the Primary City associated with the FSA and the valid FSA.

  (CM2-11443, HM43#950)

• The GetTax Circ API has been modified to accept the special character hyphen (-) in the parameter fields: Country, County, City, and State. (CM2-11464, HM43#1000)

• The CreatePayment Circ API has been updated to accept the special character space in the parameter field Authorization Number. (CM2-11502, HM43#1010)

Enhancements

iServices

• Previously, Vacation Stops were being created through the iServices on dates that were marked as holidays in NCS Circ. Changes have been made such that when creating the Vacation Stop using iServices, SubscriptionLink, or MicroAPIs, providing a holiday or non-publishing day as the Start or End date will now result in an error.

  

  (CM2-8658, CM43#6020 CMO43#730)

Circulation (Circ) API

• A new Business Rule— “What is the default username for the transactions created from Circ API?” has been introduced in the Circ API section, with the default value set to “MG2”.

  

  When creating a transaction using MicroAPIs, the value defined in this setting will be displayed in the "CreateUser" and "ModifyUser" fields under the Create/Modify tab (in the upper-right corner table of the Customer Service screen).

  

  This BR impacts the following MicroAPIs:

  1. updateVacation

  2. addVacation

  3. deleteVacation

  4. addVacationTransfer

  5. updateVacationTransfer

  6. deleteVacationTransfer

  7. createComplaint

  8. updateDeliveryDetail

  9. addPlacementMessage

  10. deleteCarrierDMMessage

  11. addUpdCarrierDMMessage

  12. addUpdSolicitation

  13. addModDemographic

  14. addDeliveryScheduleChg

  15. deletePaymentProfile

  16. addPaymentProfile

  17. addMoveTranDelSchedChg

  18. defaultPaymentProfile

  (CM2-10591, CM43#5830)

• In the CreatePayment Circ API, the PaymentSource field now accepts two new values: “ApplePayMPAN” and “ApplePay MPAN”, in addition to the existing non-blank values: “Applepay”, “Googlepay”, “Apple Pay”, and “Google Pay”. (CM2-11184, HM43#890)

• Changes in Circ APIs:

  1. ‘Add Address/Occupant’ Circ API: Increased the allowable character length of the OtherName field from 8 to 30 characters.

  2. ‘Update Occupant’ Circ API: Added a new field, OtherNameUsage, to provide details of the alternate name usage for the occupant.

  3. ‘Find Address/Occupant’ Circ API: Added two new fields, OtherName and OtherNameUsage, in the API response to return details about the alternate name and its usage associated with the occupant.

  (CM2-11243, CM43#6590 - HM43#910)