Fix Readme
Abstract
This document contains V3.2.2 release information for Financial Transaction Manager for Digital Payments for Multiplatforms. Included are known issues and changes from previous releases.
Content
Financial Transaction Manager for Digital Payments V3.2.2 Release Information
Described are known issues and changes from previous releases. Start with the section for the release version you’re currently working with and review each subsequent release for the changes.
Contents
Common Across Releases
3.2.2.1 Release
... 3.2.2.1 iFix 1
... 3.2.2.1 iFix 2
... 3.2.2.1 iFix 3
3.2.2.0 Release
... 3.2.2.0 iFix 1
... 3.2.2.0 iFix 2
... 3.2.2.0 iFix 3
... 3.2.2.0 iFix 4
... 3.2.2.0 iFix 5
- Currently at level fix pack 1 and upgrading to level fix pack 3, review the changes in fix pack 2 and fix pack 3.
- Currently at fix pack 1 / iFix 1 and upgrading to fix pack 1 / iFix 3, review the changes in fix pack 1 / iFix 2 and fix pack 1 / iFix 3.
| Back to top |
Common Across Releases
|
Known Issues
None.
Feature changes
Fix list and new feature summary
For the list of fixes, refer to Financial Transaction Manager for Digital Payments V3.2.2 Fix list.
Data Setup Utility
The following documentation describes the changes for the data setup utility (DSU) and the import and export workbooks:
DSUmigration_v3.2.2.pdf
DSUMigrationBR_v3.2.2.pdf
Which can be downloaded from Fix Central at 3.2.2-FTM-DP-MP-Documents .
Database migration
For database migration instructions, refer to the migration instructions in {Install location}\shared\vnnn\pfs\Database\db2\{os}\doc
Transaction Server Scheduler XML
The following documentation describes the changes to the scheduler XML for the Transaction Server component:
TransactionServerSchedulerChanges_v3.2.2.pdf
Which can be downloaded from Fix Central at 3.2.2-FTM-DP-MP-Documents .
General Instructions
Migration
Upgrade procedure
To upgrade an existing installation for a fix pack or interim fix (iFix), the following tasks need to be done:
Pre-installation
Note: Installation Manager won’t update a file that was modified after it originally installed that file.
- Ensure that the following components in the installation location aren’t running: RMI Service, Business Rules Distribution Manager, Business Rules Server, Gateway, Transaction Server.
- Ensure that your installation doesn’t have any updated files from test fixes or modifications that you made. The following known directories or files might have test fixes:
- Install location\shared\v322\pfs\BusinessRules\manager\lib\pdrmgrfx.jar
- Install location\shared\v322\pfs\BusinessRules\server\lib\pdrsvrfx.jar
- Install location\shared\v322\pfs\Gateway\lib\izxfix.jar
- Install location\shared\v322\pfs\ITS\lib\txfix.jar
Installation
- Start IBM Installation Manager.
- Add the location of the repository that contains the installation package:
- Select File > Preferences.
- Click Add Repository.
- Browse to the directory that contains the repository .zip file and select the file. Click Open and then OK.
- Click Test Connections and then OK.
- Click OK.
- Install the FTM product installation files to your installation directory:
- On the main pane, click Update.
- Select IBM Financial Transaction Manager for Digital Payments, IBM Financial Transaction Manager for Check Services, or IBM Financial Transaction Manager for Corporate Payment Services and then click Next.
- Select the fix pack or interim fix and then click Next.
- Follow the rest of the prompts.
- Confirm that the "Update packages" page shows success.
Deployment
- Do the database migration. Refer to the Database migration section in this document.
- Note: The runtime components can’t be running during the database migration.
- Note: Files can continue to be delivered to the Gateway inbound source folder.
- J2SE components: The installation overlays the J2SE applications, so no special migration instructions are needed. Restarting those applications updates them with the fixes.
- WebSphere Application Server (WAS) components: You can use the Automated Deployment Utility (ADU), manually upgrade (refer to the update instructions in each WAS component doc folder), or, in a WAS Network Deployment configuration, use the Deployment Manager.
- All WebSphere servers must be restarted after all the components were updated.
- For an interim fix, refer to the fix list for the modules to deploy. Note: Interim fixes are meant to be deployed on an existing WAS profile deployment. If you are using a new WAS profile and already installed the interim fix onto the prior installation, you must do two deployment passes. The first pass is to do the initial, full product deployment. The second pass is to do those components that are affected by the interim fix.
- Update your Transaction Server Scheduler.xml. Refer to the Transaction Server Scheduler XML section in this document. Note: Updating the scheduler file might not be required for your installation.
- Refer to the release-specific section for any changes that might affect your installation.
- Start your runtime components.
- If you are using the Data Setup Utility (DSU) worksheets capability for managing your data, update your worksheets. For more information, see the Data Setup Utility section in this document.
| Back to top | 3.2.2.1 iFix 3 |
None.
None.
None.
| Back to top | 3.2.2.1 iFix 2 |
None.
None.
None.
| Back to top |
3.2.2.1 iFix 1
|
Known Issues
APAR PH19462
Feature changes
None.
Migration
None.
| Back to top |
3.2.2.1 Release
|
Compatibility matrix
Because the development of releases and interim fixes (iFix) for maintenance is done in parallel, a later release might not contain every interim fix that was created for an earlier release. The following table shows you which releases and interim fix levels can be successfully upgraded to V3.2.2, Fix Pack 1.
In the table, the "If you're on version" column shows you the releases that can be upgraded successfully. The highest release or interim fix level that can be upgraded for each release is shown in the "To successfully upgrade to V3.2.2, Fix Pack 1, you must be no higher than version" column. If the release that you are upgrading from is at an interim fix level that is higher than the release or fix level that is shown in the right column, you can't upgrade the release without losing some changes. The upgrade needs to occur at the next release.
For more information about the individual changes in a release or interim fix, see the fix list for this version.
| If you’re on: | To successfully upgrade to 3.2.2.1, you must be no higher than: |
| 3.2.2.0 | 3.2.2.0 iFix 3 |
Known Issues
96831 (fixed at 3.2.2.1 with the SQL provided below)
When you attempt to activate a validation release and it fails with validation errors, the Digital Payments user interface and the Business Rules manager indicates that PayDirRemoteCommandImpl > RCI00020S: Failure building Payment Validation Rules Tables.
The issue is addressed by the following files:
Defect_96831.readme
Defect_96831.ddl
Which can be downloaded from Fix Central at 3.2.2-FTM-DP-MP-Documents .
Feature changes
87857
v2.9 Spec Update - distinguish consumer versus business
Implemented the changes necessary to support the TCH RTP Addition of Category Purpose / Proprietary codes to pacs.008 and pain.013 to identify the initiator of the message as either a consumer or a business.
These changes allow Business Rules to make decisions based on the new field ibmNprTxnCategory and additional limit change conditions for Risk limit monitors. Participant accounts can now be configured as consumer or business.
94512
On-us local process without TCH interaction
Within TCH RTP, it is possible that a bank's customer can pay another party that is also a customer of the same bank.
In this release, enhancements were added so that the bank can avoid the cost and effort of sending the payment to TCH and then having the payment sent back to the bank. In a previous release, only part of this process was available.
In this release, the process was enhanced as follows:
FTM for Immediate Payments creates a new, incoming transaction and passes it to FTM for Digital Payments to act as a proxy for the second half of the on-us process.
FTM for Digital Payments determines when an outbound payment is an on-us item and does outbound and inbound Risk checks on the initial payment. The proxy payment is always accepted.
94513
"Throttle" batch payments (to ensure that Real Time Payments are given highest priority)
Enhancements to ensure that RTP processing is given the highest priority
A new presentment group column holds the highest priority of the priority values for its batches. This priority value appears on the inbound transmissions grid and in the transmission hierarchy page.
All FTM for Digital Payments queues now have a default priority of 4 and are defined as priority order.
A new IBM MQ priority range table is loaded by using a new import sheet in the configuration workbooks. When this table is empty, all messages are put with each queue's default priority. If only a single row is present, that row’s IBM MQ priority is assigned to messages for transmissions, batches, and payments (payments that have presentments). If multiple rows are present, the starting range values for the lowest and highest IBM MQ priority determine whether the ranges are ascending or descending, and what IBM MQ priorities to use. Not all IBM MQ priorities need to be defined for use.
The sample business rules assign a priority of 80 for TCHI (Incoming TCH payments) and ZELR (Zelle Receipt) and 70 for TCHO and ZELO.
When ingesting FTM work, Gateway loads the technical priority from the FTM batch. The priority for the FTM transmission is used if the batch does not have a priority. This value seeds the batch priority and is passed to Business Rules during the business day workflow.
The Transaction Server scheduler has an option, jmsPriority, to specify the IBM MQ priority of an event. When present, it overrides priority from this story. For more information, see https://www.ibm.com/support/knowledgecenter/SSRH46_3.2.2/gpyizgdevtcfgmapigenparms.html.
Migration
Version 3.2.2, Fix Pack 1 modified the FTM for Digital Payments queues to be priority queues. To convert the queues, do the following steps:
- Open a command prompt and go to the FTM for Digital Payments installation folder: shared\v322\pfs\utilities\MQ\win\update.
- Run the following commands to delete the existing queues and re-create them as priority queues:
runmqsc your_QManager_name < MQQueues-DeleteReference.txt
runmqsc your_QManager_name < MQQueues-CreateReference.txt
runmqsc your_QManager_name < achQueues-DeleteReference.txt
runmqsc your_QManager_name < achQueues-CreateReference.txt
runmqsc your_QManager_name < cvpQueues-DeleteReference.txt
runmqsc your_QManager_name < cvpQueues-CreateReference.txt
Data Setup Utility
The following documentation describes the changes for the data setup utility (DSU) and the import and export workbooks:
DSUmigration_v3.2.2.1.pdf
DSUMigrationBR_v3.2.2.1.pdf
Which can be downloaded from Fix Central at 3.2.2-FTM-DP-MP-Documents .
| Back to top |
3.2.2.0 iFix 5
|
Known Issues
None.
Feature changes
None.
Migration
None.
| Back to top |
3.2.2.0 iFix 4
|
Known Issues
None.
Feature changes
None.
Migration
None.
| Back to top |
3.2.2.0 iFix 3
|
Known Issues
None.
Feature changes
None.
Migration
None.
| Back to top |
3.2.2.0 iFix 2
|
Known Issues
94596 (Fixed in V3.2.2, Fix Pack 1)
With web service ingestion of pain.013, Digital Payments creates the transaction and a transaction hierarchy (transmission/batch/transaction) record. The inbound transaction page currently displays both. The transaction hierarchy records do not get distributed and can be ignored.
92760 (Fixed in V3.2.2.0 iFix 3)
Validate incoming RFP messages against participant directory customers is failing.
88330
If an "Accept and Return" is initiated from the Digital Payments user interface, the pacs.008 associated with the return is not shown in the Digital Payments user interface.
Other issues are shown in the following list:
- Inbound transactions exported to a spreadsheet do not include all columns.
- When outbound payments are processed, FTM for Immediate Payments does a Digital Payments check. Sometimes, Digital Payments sends a response to Immediate Payments but it is not logged in the OAC. Immediate Payments then incorrectly indicates that a timeout occurred waiting for a response from Digital Payments.
Feature changes
None.
Migration
None.
| Back to top |
3.2.2.0 iFix 1
|
Known Issues
89857 (Fixed in iFix 2)
For the RFI and RORF transaction types, some fields in the Cognos reports are blank.
93738 (Fixed in iFix 2)
On the inbound transactions page, the link to view it as a spreadsheet is not displaying.
94596 (Fixed in 3.2.2.1)
With web service ingestion of pain.013, Digital Payments creates the transaction and a transaction hierarchy (transmission/batch/transaction) record. The inbound transaction page currently displays both. The transaction hierarchy records do not get distributed and can be ignored.
94652 (Fixed in iFix 2)
Incoming Remittance appears as duplicated in the OAC.
94644 (Fixed in iFix 2)
94653 (Fixed in iFix 2)
On a system that was migrated from V3.2.1.0 or later, it might not be possible to activate a new release of Business Rules by using the Digital Payments user interface. The release can be activated from the Business Rules Manager Command window by using the build table command.
If you try to use the Digital Payments user interface to change the approval rules and then to activate them, it might fail on a system that was migrated from V3.2.1.0 or later.
Feature changes
None.
Migration
94377
Added a new column to a database view
Use the following files to update the database view:
Defect_94377.readme
Defect_94377.ddl
Which can be downloaded from Fix Central at 3.2.2-FTM-DP-MP-Documents .
| Back to top |
3.2.2.0 Release
|
Known Issues
None.
Feature changes
89813
TCH RTP Status
The TCH SignOn/SignOff user interface page was moved from Administration > System > TCH sign-on/off to System Management > TCH Status. The title of the page was changed to TCH Status.
91270
Ingestion and Generation of NULL CPA files
New Participant Directory->Receiver->Endpoints/Sidepoints null file settings
The endpoints for a participant can now have a custom message standard when null files are generated. The custom message standard allows FTM workflows to support null files and is only applicable when the configured transmission definition of the endpoint has a channel that is an FTM workflow.
Additionally, endpoints can now opt out of specific distribution processing windows for null files. This option allows different sets of null files for each of the endpoints for a participant.
86288
Item Summary file per direct clearer per window
New Service Framework task - Summary of Data Delivered task
The Summary of Data Delivered task creates a Summary of Data Delivered report that contains detailed information for every outbound transmission that was processed by Distribution. This report is required by Canadian processing standards. To comply with these industry standards, the Distribution engine can generate these reports without user interaction by using the Service Framework architecture. Distribution can run this task when an outbound transmission is sent by placing a message on the queue that Services Framework listens on. When Services Framework receives the message, the task runs. The task can also be run manually from the user interface. The user interface provides a monitoring page that allows the Summary of Data Delivered task to be checked for failures and restarted when needed.
Canadian payment processing requires a summary of data delivered report to be sent for each outbound transmission. The task uses the configured working directory to create a set of files that contains information about the specific transmission. The files that are created are a text file, a route file, and an EOF file. The text file is an English-only, ASCII-encoded file that is the summary of data delivered report. The route file contains relevant information about the report in XML format. The EOF file is used to indicate that the processing is complete. When the outbound transmission is sent, all of these files are copied to the target directory that was configured.
Outbound Transmission page enhancements
A column was added to the outbound transmission page. The new column is a timestamp that indicates when the Summary of Data Delivered task ran successfully. If the task was successful, a green check mark is displayed for the corresponding outbound transmission. The hover help for this column displays the time that the task completed.
88155
Risk monitor updates for participant directory
A new Limit Monitors action was added to the row level action menu for each participant. If selected, the action displays a new FTM tab for Exposure Limit Monitoring that has its filter option set to "FTM Participant Id" equal to <the selected participant id>. The resulting list displays the risk monitors that exist for the selected participant.
The Limit Monitors action is available only to users that have the view activity monitor permission for Risk.
88715
WebSphere Message Broker to recognize 'Encoding' settings on transmission definition
Enhancements were made to the WebSphere Message Broker reference flow to recognize the encoding settings (ASCII or EBCDIC) on a transmission definition that is associated with the outbound transmission.
Examples are:
If the outbound file contains a transmission definition that is configured with EBCDIC encoding, the outbound CPA 005 file is generated with EBCDIC encoding.
If the outbound file contains a transmission definition that is configured with ASCII encoding, the outbound CPA 005 file is generated in ASCII.
Note: This encoding is only recognized during the processing and building of CPA 005 files. Each future output (such as ISO 20022) can ignore this setting because ASCII is the only supported encoding for these file types.
90853
Settlement date and distribution date calculations per CPA rules
Settlement and distribution date calculations
Added a set of business rules and participant configurations to demonstrate how FTM can calculate settlement dates for origination payments (credit transfers) destined for other financial institutions (Transit/Off-Us) items. Along with the settlement date calculations, the reference implementation shows how FTM calculates the distribution dates for each file to the destination FI based on the serviceability code of the exchange point. Serviceability codes represent the defined lead time (same day, 1 or 2 day) that is required to deliver credit items to the RDFI.
52764
Participant Directory - Risk Management > Account Rules > Authorization Filters support
The Authorization Filters Support page manages authorization filters for an account. Authorization filters are used to define those transactions that are to be accepted by the system. If a transaction does not match one of the authorization filters, it can either be rejected or held for review by the receiving point, depending on the override flag on the error code. If the account number for the receiving point has the authorization filter check enabled, the incoming transaction must match an authorization filter or it is treated as unmatched.
84881
FIF data - Bulk load of FIF data (add/update/delete)
The financial institution file (FIF) is distributed weekly by Payments Canada to its member institutions. The file contains a main list of Canadian financial institution names, addresses, and routing information. Institutions under the authority of Payments Canada are responsible for keeping their own records up-to-date with the FIF.
The FIF load task reads a financial institution file and uses it to update the information in the FTM database. When the task is configured, you must provide the exact name for the financial institution file, including its extension. You must also provide the full path name for the source, error, and processed directories.
When the task successfully processes a financial institution file, it moves that file to the processed directory and appends a timestamp to its name. If the task does not find a file in the source directory that matches the FIF name that was provided, it completes with a warning that the file was not found. When errors occur during processing, the task moves the file to the error directory and appends a timestamp to its name. If the task is restarted, it processes the timestamped financial institution file from the error directory.
The task can be scheduled or run manually.
90345
Updated the Requests for Return of Funds report to add the return reason and fraud indicator fields.
89887
Enhanced the participant directory web service to support filtering by role.
89836
More closely integrates the functions available in Digital Payments with those functions in FTM for Immediate Payments, which allows the Immediate Payments flow to have Business Rules decide how ISO payments are sent.
89783
A column was added to the inbound transaction, transmission hierarchy, and non-payment transaction hierarchy pages to indicate whether a transaction was originated (Origination) or received (Receipt) by the processing financial institution. A column was also added to the PAY_AND_NON_PAY_TXN_V used by the pages.
88211
Create a web service to support individual accept and return funds options for the return of funds (ROF). You can now separately accept a payment and then later return it. Previously, you could only 'accept and return' a payment for the corresponding Request for ROF. To be able to return a payment, a corresponding request for ROF must exist. Otherwise, a warning message is logged.
87854
Implemented extra address fields per the V2.9 spec
- A field (CtrySubDvsn) to identify State
• Existing ISO field added to all RTP messages that carry the Address element
– A single occurrence (AdrLine) of Address Line 1
• Existing ISO field added to all RTP messages that carry the Address element
Added support for these new fields in Digital Payments. Specifically, they were added to the ISF messages that are sent to Immediate Payments. Also, the parsing that is done for the ISF messages that are received from Immediate Payments was updated to retrieve these new fields. Minor user interface changes were done so that you can see and modify these fields where applicable.
87850
Implement a user interface where you can select multiple request reasons for the Request For Information and enter associated text for each reason.
85754
Cognos report to show the total time disconnected from the RTP Network across different intervals.
85753
Cognos report to display the “Number of Transactions Over x Seconds” for incoming and outgoing transactions, amounts, or both. The report is sorted by message type and by channel.
85752
Report that displays the average response time for incoming and outgoing transactions by message type and by channel.
84729
Enable the Create Request Return of Funds web service. The web service URI is [host]:[port]/ws/svc/reqretfunds
The new web service does user interface validation and additional web-service-specific validation.
The payment ID or transaction ID (base object ID) needs to be valid.
The lengths for the reason codes (8) and available information (525) must be valid.
If the transaction ID is used in the input request, the web service finds the corresponding payment ID to do the request return of funds. If no valid payment ID is found, an error is returned in the response.
84728
Enable the Create Request for Information web service. The web service URI is [host]:[port]/ws/svc/reqinfotrans/
The new web service does user interface validation and additional web-service-specific validation.
The payment ID or transaction ID (base object ID) needs to be valid. The length for the justification type needs to be valid.
For example, the narrative justification type can be up to 1400 bytes instead of 140 bytes. All justification types must be unique in the input request.
If the transaction ID is used in the input request, the web service finds the corresponding payment ID to do the request for information. If no valid payment ID is found, an error is returned in the response.
84727
Enable the Create Request for Payments web service. The web service URI is [host]:[port]/ws/svc/initiaterequestforpayment/
When valid pain.013 XML raw data is provided, the web service transforms it into the FTM Base ISF format.
The ISF format of the pain.013 data is processed by FTM for Digital Payments and sent to FTM Base to distribute as instructed.
Version 5 of the pain.013 is supported by FTM V3.2.2.0. Other versions fail.
84726
Enable the Create Request for Credit Transfer web service. The web service URI is [host]:[port]/ws/svc/initiateCreditTransfer/
When valid pain.001 XML raw data is provided, the web service transforms it into the FTM Base ISF format.
The ISF format of the pain.013 data is processed by FTM for Digital Payments and sent to FTM Base to distribute as instructed.
Versions 3, 8, and 9 of pain.001 are supported in FTM V3.2.2.0. Other versions fail.
Migration
Use the following file to migrate to 3.2.2.0:
FTM_DigitalPayments_v3.2.2.0_Migration.pdf
Which can be downloaded from Fix Central at 3.2.2-FTM-DP-MP-Documents .
Related Information
Was this topic helpful?
Document Information
Modified date:
01 July 2021
UID
ibm10882104