NCS Circ Maintenance Release: 2025-3.0
This release is currently in Beta.
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
Welcome to the NCS Circulation 2025-3.0 release. This release delivers enhancements and program changes across Accounting, Setup, Reporting, Naviga Pay, and payment-vendor workflows. These updates enhance payment processing, improve data accuracy across reporting and conversions, and provide more consistent behavior across multiple modules in NCS Circulation.
With this release, Moneris has been added as a new payment vendor, and the system now provides full support for Moneris payments and refunds. The Payment Information screen displays Issuer ID when Moneris is selected, and all Moneris transactions now store and pass TransactionCode values for improved traceability. New authorization messages and enhanced handling of PaymentAuthorizationVendor and PaymentAuthorizationMessage values strengthen payment processing. In addition, new Business Rules allow users to bypass the Hosted Order Page (HOP) and manually enter vault details for Subscriber Payments and Account Payments when required.
Naviga Pay has been updated to remove split-payment processing (originally introduced with Fluid Pay). The system now sends a single consolidated payment amount—including the base amount, tip, donation, processing fee, and tax—to Naviga Pay. All transactions are processed as a single payment, and split-payment parameters are no longer included in the workflow.
The Export/Import Subscription Rates screen now includes a File Delimiter field with multiple delimiter options, and the NCS Conversion File Export has been enhanced with country-level tax authority fields and improved performance by filtering expired publications earlier in the workflow.
Four new Menu Security IDs strengthen access control across the application. The re-tokenization program for vendor changes now supports both one-token and two-token vendor formats for improved compatibility.
This release also ensures accurate handling of canceled adjustment amounts in the Subscriber Payment Journal and improves reporting accuracy in Unearned Revenue and Grace Due so that subscribers are included or excluded correctly.
🖥️ Minimum System Requirements
If using Naviga Pay for payments, a minimum Naviga Pay version of 2.2 is required for 2025-3.0.
If using Payment Authorization Service, a minimum PAS version of 8.11.61 is required for 2025-3.0.
A minimum Circulation version of 2025 is required to upgrade to the 2025-3.0 release.
📝 Installation Notes
After upgrading to 2025-3.0, you must recreate/resave any input files for the:
Setup > Accounting > Subscription Rates > Export/Import Rates
If using PostWare, run all of your postal reports through the current publishing date before applying this batch.
🛠️ Resolved Issues
💼 Accounting
When subscriber payments with adjustments were canceled through Payment Cancel, the detailed section of the Subscriber Payment Journal displayed both the payment amount and the canceled adjustment. However, the Cancels By Type section of the Summary Recap did not reflect the adjustment and displayed the Non-Cash Adjustment and Cash Adjustment fields as 0.00. This created inconsistencies between the detailed and summary sections.
The issue has been resolved. The Cancels By Type section in the Summary Recap now correctly displays canceled cash and non-cash adjustment amounts. (CM2-12210, CM44#990)
📊 Reporting
Previously, Comp subscribers with no balance appeared in the Unearned Revenue and Grace Due reports because of the premium amount defined in the Bonus Day setup. Additionally, the Unearned Revenue Report did not include Non-Office Pay subscribers with balances—particularly those who transitioned from Office Pay to Comp or Third Party while retaining an available refund.
These issues have been resolved.
Current Functionality:
Comp Subscribers
Comp subscribers with a $0 balance, Bonus Day = No, and a future Premium Day in the Bonus Day setup no longer appear in the Unearned Revenue or Grace Due reports when the billing method is not Office Pay.
Comp subscribers now appear only when they have an actual balance—for example: residual unallocated funds, unreimbursed premium day amounts, and balances carried over after transitioning from Office Pay.
Unearned Revenue Report Includes:
Non-Office Pay subscribers with a valid balance and payment before the publishing date.
Office Pay subscribers with balances or refunds who have transitioned to Comp.
Excludes future-dated payments where the payment date is after the publishing date.
Grace Due Report Includes:
Office Pay subscribers who are in a Grace period or have Grace Owed and are transitioned to Comp.
(CM2-9581 – CM2-12754, CM44#1030 – CMO44#80)
The performance issue encountered when running the NCS Conversion File export has been resolved. The system now applies Publication End Date filtering earlier in the process, ensuring that subscriptions linked to expired publications are skipped before subscription processing begins. This change eliminates unnecessary processing and improves execution performance.
The NCS Conversion File export now supports detailed logging. When debugging is enabled for the export, the system generates detailed log messages throughout the export process.
(CM2-12614, CM44#880) (CM2-12626, CM44#820)
💠 MicroAPIs in support of Naviga Subscribe Integration
The GetSubscriptionInfo MicroAPI has been updated to correctly return the next RateCodeId during a subscription restart. This update ensures that the appropriate Rate Code is applied automatically and prevents rate code assignment errors.
(CM2-12655, CM44#1010)
🚀 Enhancements
⚙️ Setup
Setup > Accounting > Subscription Rates > Export/Import Rates
A new File Delimiter field has been added to the Export/Import Subscription Rates screen. This enhancement resolves a previous limitation where only tab-delimited files were supported, which restricted file management outside the system.
Users can now select a preferred delimiter for both Import and Export operations from the File Delimiter drop-down list. Supported delimiters include:
Comma (,)
Tab (↹)
Semicolon (;)
Pipe (|)
Space ( )
Notes:
After upgrading to version 2025-3.0, users must recreate or resave import files to ensure compatibility with the updated file structure.
The File Delimiter field is mandatory when the Action field is set to Import or Export.
(CM2-12027, CM44#600)
Setup > System > Security > Menu Security Four new Security IDs have been introduced to improve access control and maintain security compliance. The following menu items are now secured with these newly assigned IDs:
Reports > Subscriber > Fee Analysis — M121100
Reports > Subscriber > Fee Writeoff — M121000
Utilities > Import > Demographic Answer — M121200
Accounting > Vindicia Payments > Send Payments — M119400
(CM2-12525, CM44#980)
📊 Reporting
The NCS Conversion File exports have been enhanced to include two new fields from the SubscriptionTaxAuthority table: CountryTaxAuthorityID and CountryExemptReasonCode.
Previously, only City, County, and State Tax Authority fields were exported. With this enhancement, Country-level Tax Authority information is now included, ensuring consistent Tax Authority data across export records.
These new fields are appended at the end of each export record to maintain the existing field sequence while maintaining backward compatibility. (CM2-12722, CM44#960)
🔄 Naviga Subscribe
Setup > Rules > Business Rules The Business Rule — “What is the Paper code used for Subscribe Webhook?” (Subscribe section; QuestionID: WebhookPaperCod) has been updated from a Character datatype to a Logical datatype, with available values Yes and No. The default value is Yes. This change is now reflected in the Push Notification feature.
If WebhookPaperCod is set to No, the system does not create a Convert record for the Start transaction, and no push notification is generated.
If WebhookPaperCod is set to Yes, the system creates a Convert record for the Start transaction, and a push notification is generated.
For successful push-notification processing, the WebhookPaperCod Business Rule should remain set to Yes.
(CM2-12653, CM44#930)
💳 Naviga Pay
Previously, the system sent two separate amounts to Naviga Pay—one for the transaction amount (including the base amount and processing fee with surcharge) and another for the split amount covering tips, donations, or cash adjustments. This caused Naviga Pay to process two independent transactions for a single payment event.
With the latest update, support for split payments (introduced with Fluid Pay) has been removed. NCS Circ now sends a single consolidated amount that includes the base amount, tip, donation, processing fee, and tax. Naviga Pay processes this as a single transaction. (CM2-12721, CM44#1040)
🏦 Moneris Payment Vendor
A new payment vendor, Moneris, has been introduced in the Naviga Pay suite for payment processing. NCS Circ has been updated to support this vendor by adding Moneris as a valid option in the Business Rule — “Which hosted page credit card authorization service do you use?” (Pymt Auth – General section).
(CM2-12658, CM44#1020)
The Payment Information screen in Customer Service has been updated to support the Moneris payment vendor. The following updates have been implemented:
On the Payment Information screen, the Customer ID field label has been renamed to Issuer ID when Moneris is the selected payment vendor.
The Issuer ID is displayed correctly along with other payment details.
When a transaction is processed, the Issuer ID is stored in the Convert Record.
During payment processing, the Issuer ID is passed through Naviga Pay, ensuring that payment information is captured and reflected across integrated systems.
Note: The Issuer ID field label applies only to Moneris. For all other payment vendors, the field label remains Customer ID.
(CM2-12660, CM44#1060)
NCS Circ has been updated to support Moneris payment and refund workflows in Naviga Pay. The following updates have been implemented:
When a Moneris payment transaction is initiated, the Issuer ID is included when payment information is sent to Naviga Pay.
After the payment is processed, the system stores the TransactionCode for future reference.
The Issuer ID and TransactionCode are retained and transmitted across subsequent operations such as payments, refunds, and related workflows to maintain data accuracy.
During refund processing, the system retrieves the TransactionCode from the original payment and includes it in the refund request sent to Naviga Pay, linking the refund to the corresponding payment.
If a refund request is sent to Naviga Pay without a valid TransactionCode, it is rejected.
(CM2-12661, CM44#1070 – CMO44#90)
Enhancements have been made to Moneris payment processing in NCS Circ to improve authorization tracking and reporting accuracy. The following updates are included:
The system now records PaymentAuthorizationVendor and PaymentAuthorizationMessage details for all Moneris transactions.
Five new authorization messages have been added for the following error codes:
416 – Life Cycle Declines
421 – Closed Account
422 – Stop Payment Order
423 – Verification Data Failed
481 – Credit Card – Decline
All other existing authorization messages remain unchanged and continue to function correctly.
These updates support consistent recording of Moneris transaction responses for reconciliation and reporting. (CM2-12662, CM44#1050)
The re-tokenisation program for vendor changes (tkn2tknchng.p) in NCS Circ has been enhanced to support additional token-handling scenarios. Previously, the program supported re-tokenisation only between single-token payment vendors. It now supports transitions between one-token and two-token vendor formats, enabling token migration across multiple payment configurations.
The program continues to use a comma-delimited (.csv) input file that maps old and new token values. Based on the scenario, both Vault ID and Customer ID values are updated. The values shown in parentheses represent the required field sequence in each input file record.
Supported re-tokenisation structures include:
1-token → 2-token: (OldVaultID, NewVaultID, NewCustomerID)
2-token → 1-token: (OldVaultID, OldCustomerID, NewVaultID)
1-token → 1-token: (OldVaultID, NewVaultID)
2-token → 2-token: (OldVaultID, OldCustomerID, NewVaultID, NewCustomerID)
Validation has been added to confirm that tokens are regenerated correctly and securely stored. The updated tokens continue to function correctly in subsequent payment and refund transactions.
(CM2-12663, CM44#1100)
Setup > Rules > Business Rules Two new Business Rules have been added to support manual vault entry when processing Subscriber Payments and Account Payments. These rules allow users to bypass a payment vendor’s Hosted Order Page (HOP) and manually enter vault details when required—for example, when the HOP is unavailable or when direct token-based processing is preferred.
Subscriber Payments
Business Rule: Should the Hosted Order Page be allowed to be bypassed for vault details of Subscriber Payments?
Section: Pymt Auth – General
QuestionID: ManualVaultEntry
Default Value: No
Available Level(s): Business, Company, Publication
Applicable Areas (GUI):
Customer Service > Billing Change
Customer Service > New Start (Single and Auto Payments)
Customer Service > Payment
Account Payments
Business Rule: Should the Hosted Order Page be allowed to be bypassed for vault details of Account Payments?
Section: Pymt Auth – General
QuestionID: AManualVaultEntry
Default Value: No
Available Level(s): Business
Applicable Areas (GUI):
Accounting > Account Payments > Payment Entry
Route Service > Setup > Account Services > Billing tab
These Business Rules share the following functionality:
When the rule is set to Yes, the system displays a confirmation pop-up window asking whether the user wants to bypass the HOP.
Selecting 'Yes' in the pop-up window opens the Payment Information window, where users can manually enter token details such as Vault ID and Issuer ID/Customer ID, depending on the payment vendor.
Selecting 'No' in the pop-up window continues the standard HOP workflow.
When the rule is set to No, the system follows existing behaviour and does not display the pop-up window. (CM2-12765, CM44#1110) (CM2-12836, CM44#1120)
Enhancements have been implemented in the CircAPI – Create Payment and CS API – Single Payment to support the Moneris payment vendor and provide consistent handling, validation, and storage of the Transaction Code in the database.
The following updates have been introduced:
A new input field, Transaction Code (TranCode), has been added to both APIs.
The Transaction Code field accepts up to 40 characters.
Input validation allows only letters, numbers, hyphens (-), and underscores (_), consistent with validation for the Transaction ID (TranID) field.
Blank Transaction Code values are allowed in both APIs.
The Transaction Code is stored for all payment vendors in the database, ensuring consistent data management.
Note:
This enhancement applies only to the Moneris payment vendor.
In the CS API – Single Payment, when both the Transaction ID and Authorization Number are passed, these values are not stored in the database; therefore, the Transaction Code is also not stored in this scenario.
(CM2-12781, CM44#1080 – HM44#140 – CMO44#100)
Last updated