Validating, enriching, and routing of payments
When a payment enters the Financial Transaction Manager for ACH System, it goes through a process of validation, enriching, and routing to its final destination. This payment process is described in this chapter.
The gateway server performs validation by using internal code and by calling business rules process server to perform other validation. When items are pulled from the warehouse, the gateway engine performs validation and enrichment by calling the business rules process server again.
As part of the enrichment, additional information is assigned to the batch and items that includes the clearing date, inbound product, billing information, banking codes, and settlement accumulators.
The routing ensures that the payment is sent to the appropriate destination, which is referred to as the receiving point in Financial Transaction Manager for ACH. This receiving point can be a back-office system, an ACH operator, another financial institution, or an authorized third party.
Those steps and their configuration are explained in detail in this chapter.
This chapter includes the following sections:
3.1 Validation configuration
This chapter provides an overview of gateway validation and data validation and how both are configured in the Control Center and by using the data setup utility (DSU).
The validation of payments consists of two parts:
•Gateway validation
•Data validation
In the first step, the Gateway Server checks whether the incoming transmissions and batches are valid.
In the second step, the data is validated against the NACHA standard validation rules.
3.1.1 Gateway validation
The gateway validation criteria can be configured by a user with the appropriate administrative privileges either in the Control Center or the DSU. The validation is configurable on two levels: The transmission level and the batch level.
Transmission rule set configuration in Control Center
To change the configuration of the gateway validation, enter the Control Center and click Configuration → Validation Rules → Rule Sets.
You are now able to select the rule sets either on the transmission level or the batch level.
For the transmission level, Figure 3-1 shows the details that can be configured.
Figure 3-1 Edit transmission rule set window
On the transmission level, the gateway performs validations in the following ways:
•Transmission Threshold Level
Defines on which level the transmission threshold is applied. Possible selections are None, Batch, and Transaction
•Transmission Error Threshold
Sets the minimum percentage or number of errors in the defined threshold level for the transmission to be rejected. The batch or the transaction can be rejected for any reason, such as content validation, context validation, duplicate, or being out of balance. If both a minimum number and percentage have a value input, then both conditions must be met to reject the transmission. No input in either of the two fields means that this rule is not used.
•Maximum Transmission Size
This field defines the maximum transmission size (including the configured value) in MB.
•Format check
The administrator can chose to validate that each transmission has one of the supported formats: EBCDIC or ASCII.
•Transmission Duplicate Detect
This option enables checking for a duplicate transmission.
•Transmission Out of Balance
Performs a check whether the sum of the Batches trailing records equals the Transmission trailing record total. The totals are compared to the values in the FIle Control Record (record type 9).
•Sending point is defined
Checks whether the sending point is defined and authorized to send in the transmission. The sending point is defined in the File Header (record type code 1 -> Immediate Origin, field 4).
•Sending Point is Authorized for Originator
Checks whether the sending point is authorized to send in batches for this Originator (ODFI).
•Originator is defined
Whether to check if the Originator (ODFI) is defined and authorized to send in the transmission.
•Product is defined
Whether the inbound product is defined. The inbound product identifier is defined by the customer per a gateway user exit.
•Originator is Authorized for Product
Whether the Originator (ODFI) is authorized to have a batch for that inbound product.
•Originator is Authorized for Destination
Whether the Originator (ODFI) is authorized to have a batch for that destination, which is defined in File Header (record type code 1) > Immediate Destination (field 3).
Transmission rule set configuration with data setup utility
Configuring the Transmission Rule Set with the DSU requires validation and updates in several files that are distributed with Financial Transaction Manager for ACH. The following list notes the default names of the files to be validated and updated:
•installDir/shared/v300/pfs/DSU/importexport/cmd/AchSharedImport.properties
•installDir/shared/v300/pfs/DSU/importexport/xls/SharedMap.xls
•installDir/shared/v300/pfs/DSU/importexport/xls/SharedXREF.xls
•installDir/shared/v300/pfs/DSU/importexport/xls/SampleAchConfiguration.xls
Verify that the workbook reference tags in the properties file (AchSharedImport.properties) have the correct file names for the Cross Reference, Map, and Configuration Data workbooks. If the workbook names are different than the defaults, update the designated files according to the instructions under the default name.
In the Map workbook (default SharedMap.xls), validate that the Transmission Rule Set tab has the correct mapping of column names to database table columns. It is unlikely that this file will need to be modified or updated.
In the Cross Reference workbook (default SharedXREF.xls), on the Import tab, ensure that the row defining Inbound Transmission Rules contains the value Y in the Import column and the Mode column is set to InsertUpdate.
In the Configuration Data workbook (default SampleAchConfiguration.xls), open the Inbound Transmission Rules tab and add or edit an entry in the spreadsheet. The columns are named as the fields in the Control Center in most cases. See the explanations above for each of the columns.
After everything has been configured as wanted, import the new configuration using the DSU import command in installDir/shared/v300/pfs/DSU/importexport/cmd or installDir/shared/v300/pfs/DSU/importexport/cmd64:
dsu import AchSharedImport.properties
or
dsu64 import AchSharedImport.properties
The DSU tool will log the results of the command to a log file for later inspection. The log file is in installDir/shared/v300/pfs/DSU/importexport/cmd or wherever the properties file specifies in the logFileLocation tag.
Additional information about the Data Setup Utility can be found in 1.5, “Importing and exporting system configuration” on page 20.
Batch Rule Set Configuration in Control Center
On the batch level, select the following parameters as shown in Figure 3-2.
Figure 3-2 Edit Batch/ICL Rule window
•Batch (ICL) Threshold Level
Defines on which level the batch threshold is applied. Possible selections are None, Segment, and Transaction. Note that Segment does not apply for Financial Transaction Manager for ACH.
•Batch (ICL) error threshold
Sets the minimum percentage or number of errors in the defined threshold level for the batch to be rejected. The batch or the transaction can be rejected for any reason, such as content validation, context validation, duplicate, or being out of balance. If both a minimum number and percentage have a value inputted, then both conditions must be met to reject the transmission. No input in either of the two fields means that this rule will not be used.
|
The following list notes scenarios about how this setting can be used:
•If the customer only wants a batch rejected when there is a minimum number of items rejected, regardless of the batch size, then only configure the minimum number. For example, if the minimum number is set to five, then a four item batch with four rejected transactions is not rejected. However, a five item batch with five rejected items is rejected, and a hundred item batch with five rejected transactions is rejected even though five is a small percentage of the total number of transactions.
•If the customer only wants a batch rejected based on a percentage, then only configure the percentage number. This can prevent batches with a larger number of transactions from being rejected if only a few of the transactions are rejected. For example, if the percentage is set to 50 percent, then a hundred item batch with five rejected transactions is not rejected, but if there are 50 or more rejected transactions the batch is rejected. A two item batch is rejected if one transaction is rejected.
•The reason you would want to configure both numbers is to prevent batches with a few transactions from being rejected when the minimum percentage is configured. For example, if the percentage is set to 50 percent, then to prevent a two item batch that only has one rejected transaction from being rejected, set the minimum number to two.
|
•Batch (ICL) Duplicate Detect
This option enables the check for a duplicate batch.
The check is performed if the number of transactions in the Batch equals or exceeds the Batch minimum count if Batch duplicate detection is enabled.
The check is also performed if the total dollar amount of the Batch equals or exceeds the Batch minimum amount if Batch duplicate detection is enabled.
•Batch (ICL) Out of Balance
Performs a check whether the sum of the transactions trailing record total equals the Batch trailing record total.
•Segment Error Threshold
This does not apply to Financial Transaction Manager for ACH. It sets the minimum percentage or number of errors in the segment for the batch to be rejected. If both a minimum number and percentage have a value input, then both conditions must be met to reject the transmission. No input in either of the two fields means that this rule is not used.
•Segment Duplicate Detect
This does not apply to Financial Transaction Manager for ACH. This checks whether there are any duplicate segments.
•Segment Out of Balance
This does not apply to Financial Transaction Manager for ACH. Check whether the sum of the transaction records equals the segment trailing record total.
•Future Date
Determines whether transactions are dated too far in the future and allows you to specify the number of days in the future allowed. This is defined in the Batch Header (record type code 5) -> Effective Entry Date (field 9).
•Past Date
Determines whether transactions are dated too far in the past and allows you to specify the number of days in the past allowed. This is defined in the Batch Header (record type code 5) -> Effective Entry Date (field 9).
•Transaction Type
Determines whether the transaction types that are associated with the batches are defined.
•Message Type
Determines whether the originator (ODFI) is authorized the Message type, which is configured in Partner → Authorized Message Type.
•Return Window
Determines whether returned transactions are beyond the service level agreement (SLA) return window.
•Image Rule Set Name
This does not apply to Financial Transaction Manager for ACH. This is the name of a rule set that contains the image validation attribute configurations. This rule set name is passed to the Image Compliance product for validating the image.
|
Note: Some of the batch validation rules do not apply to ACH. For example, Image and Segment rules are only used with Check, not with ACH. If a Segment or Image rule is configured for ACH, this rule is ignored.
|
Batch Rule set configuration with data setup utility
Configuring the Batch Rule Set with the DSU requires validation and updates in several files that are distributed with Financial Transaction Manager for ACH. The following list notes the default names of the files to be validated and updated:
•installDir/shared/v300/pfs/DSU/importexport/cmd/AchSharedImport.properties
•installDir/shared/v300/pfs/DSU/importexport/xls/SharedMap.xls
•installDir/shared/v300/pfs/DSU/importexport/xls/SharedXREF.xls
•installDir/shared/v300/pfs/DSU/importexport/xls/SampleAchConfiguration.xls
Verify that the workbook reference tags in the properties file (AchSharedImport.properties) have the correct file names for the Cross Reference, Map, and Configuration Data workbooks. If the workbook names are different from the defaults, update the designated files per the instructions under the default name.
In the Map workbook (default SharedMap.xls), validate that the Inbound Products tab has the correct mapping of column names to database table columns. It is unlikely that this file needs to be modified or updated.
In the Cross Reference workbook (default SharedXREF.xls), on the Import tab, ensure that the row defining Inbound Transmission Rules contains the value Y in the Import column and the Mode column is set to InsertUpdate.
In the Configuration Data workbook (default SampleAchConfiguration.xls), open the Inbound Batch Rules tab and add or edit an entry in the spreadsheet. The columns are named as the fields in the Control Center in most cases. See the list in “Batch Rule Set Configuration in Control Center” on page 57 for information about each of the columns
After everything has been configured, import the new configuration by using the DSU import command in installDir/shared/v300/pfs/DSU/importexport/cmd or installDir/shared/v300/pfs/DSU/importexport/cmd64:
dsu import AchSharedImport.properties
or
dsu64 import AchSharedImport.properties
The DSU tool logs the results of the command to a log file for later inspection. The log file is in installDir/shared/v300/pfs/DSU/importexport/cmd or wherever the properties file specifies in the logFileLocation tag.
Additional information about the Data Setup Utility can be found in 1.5, “Importing and exporting system configuration” on page 20.
Error Code Configuration
For all the performed validations, an error code can be assigned to be able to determine the failing checks. For those error codes, the administrator can either use the defaults or create new specific error codes. To do this, click Configuration → Rule Sets → Error Codes.
Figure 3-3 shows the menu icons in the Error Code tab. Click the Plus icon to add an error code.
Figure 3-3 Error Codes window
The new window that opens is shown in Figure 3-4. The Error Code should be unique in the system and can be any alphanumeric value that is no longer than 24 characters.
Figure 3-4 Add Error Code window
The Description is provided in feedback messages, and should contain useful information about the error code.
The Reject level allows you to select what level should be rejected in case of an error. The possible values are as follows:
•Transaction
This selection f indicates that the rejection is at the Transaction level.
•Segment
This entry does not apply for Financial Transaction Manager for ACH.
This selection indicates that the rejection is at the Bundle/Segment level.
•Batch
This selection indicates that the rejection is at the Batch level.
•Transmission
This selection indicates that the rejection is at the Transmission level.
•Warning
This selection indicates that there is no rejection. Instead, a warning is assigned to the error code.
•Informational
This selection indicates that there is no rejection. Instead, some information is assigned to the error code.
The Override button indicates whether this error can be overridden.
The Acknowledgment option indicates whether to include this error number in acknowledgment messages.
The Error category defines to which category this error is assigned. Categories are defined in Add Error Categories window.
3.1.2 Data Validation
In the second part of the validation, the data is checked using the file standard validation rules.
File Standard Validation Rules
Business Rules can be used to validate the content and structure of batches imported by Gateway. This functionality is provided as a set of Business Rules nodes that are called from the Business Rules workflow. The validation node types are as follows:
•Content
Content validation verifies that the fields in a record contain valid values. It checks the values for type, format, justification, and for specific content. Content validation also checks that required fields are present and verifies that two fields from different records have the same value.
•Context
Context and envelope context validation work together to check the structure of the incoming transmission.
– Context
Context validation verifies that records are in the correct order by analyzing the current and previous record types to determine whether the pairings of these record types are valid.
– Envelope Context
Envelope context validation verifies that the record type pairs that contain, or envelop, some number of other records appear properly. For example, File Header Record (record type code 1) and Batch Header Record (record type 5) are followed by their respective trailer records: File Control Record (record type code 9) and Batch Control Record (record type code 8).
•Collectors
Collectors validation uses a value that is calculated from the preceding records to verify the value of a specific field. As a file is processed, records are counted and field values are summed. These accumulated values are then used to validate the specified fields. For example, batch records (type 5) can be counted and compared with the batch count found in field 2 of the type 9 record.
This node also checks for unique values. For example, the batch number (field 13 of the type 5 record) field in each record in the file must have a unique value.
As for the gateway validation, error codes can be assigned to each of the validation types.
Business rules provides sample rule sets for several file standards. The validation rule sets are unique for each standard. Each level in a standard has its own set of tables. Some predefined rule sets are:
•NACHA - 2014
•NACHA - 2015
The rule sets can be edited by using the Business Rules User Interface Editor.
Configuration with the Control Center
Two levels are used to define the Data Validation. For the first, open the Control Center and click Configuration → Inbound → Transmission Types.
The Manage Transmission Types window appears, as shown in Figure 3-5.
Figure 3-5 Manage Transmission Types window
This window shows all defined transmission types and the rules used by them. Click Where Used to configure where this specific transmission type is used.
Click View details to see the transmission type and get to the editing menu that is shown in Figure 3-6.
Figure 3-6 Edit Transmission Type window
When editing or creating a Transmission type, the following fields must be completed:
•Transmission Validation Rules
Contains the name of the transmission validation rule that is assigned to the particular transmission type. The configuration of these transmission validation rules is described in 3.1.1, “Gateway validation” on page 54.
•Batch / ICL Rule Set
This contains the name of the batch validation rule assigned to the particular transmission type. The configuration of these batch validation rules is described in 3.1.1, “Gateway validation” on page 54.
•Business Rule Workflow Name
The name of the workflow that is assigned to the particular transmission type.
•Send Acknowledgment
This setting allows you to configure whether an acknowledgment that the transmission was received and validated successfully or not is sent to the sender of the transmission.
•Acknowledgment Type
Defines what kind of acknowledgment is sent back to the sender.
Those settings can be overridden for each batch at the product level by clicking Configuration → Inbound → Products, as shown in Figure 3-7.
Figure 3-7 Edit Product window
If a Batch/ICL Validation Rule is selected, it overrides the selection in Configuration → Inbound → Transmission Types for this product.
Configuration with the data setup utility
Configuring the Transmission Types with the DSU requires validation and updates in several files that are distributed with Financial Transaction Manager for ACH. The default names of the files to be validated or updated are:
•installDir/shared/v300/pfs/DSU/importexport/cmd/AchSharedImport.properties
•installDir/shared/v300/pfs/DSU/importexport/xls/SharedMap.xls
•installDir/shared/v300/pfs/DSU/importexport/xls/SharedXREF.xls
•installDir/shared/v300/pfs/DSU/importexport/xls/SampleAchConfiguration.xls
Verify that the workbook reference tags in the properties file (AchSharedImport.properties) have the correct file names for the Cross Reference, Map, and Configuration Data workbooks. If the workbook names are different from the defaults, update the designated files according to the instructions under the default name.
In the Map workbook (default SharedMap.xls), validate that the Transmission Types tab has the correct mapping of column names to database table columns. It is unlikely that this file will need to be modified or updated.
In the Cross Reference workbook (default SharedXREF.xls), on the Import tab, ensure that the row defining Transmission Types contains the value Y in the Import column and the Mode column is set to InsertUpdate.
In the Configuration Data workbook (default SampleAchConfiguration.xls), open the tab Transmission Types and add or edit an entry in the spreadsheet. The columns are named as the fields in the Control Center in most cases. For more information about the columns, see “Configuration with the Control Center” on page 63.
After everything has been configured, import the new configuration using the dsu import command in installDir/shared/v300/pfs/DSU/importexport/cmd or installDir/shared/v300/pfs/DSU/importexport/cmd64:
dsu import AchSharedImport.properties
or
dsu64 import AchSharedImport.properties
The DSU tool logs the results of the command to a log file for later inspection. The log file is in installDir/shared/v300/pfs/DSU/importexport/cmd or wherever the properties file specifies in the logFileLocation tag.
Additional information about the Data Setup Utility can be found in 1.5, “Importing and exporting system configuration” on page 20.
3.2 Enrichment
During Enrichment, the following values can be added to payments in these nodes:
•PaymentMethodOutNode
Determines:
– Payment standard and message type out values
– Item's endpoint
– Same day endpoint for transit items
– Whether the item is on-us or not
•BusinessDayItemNode
Determines the date that the item will settle
Determines the business day of the item
•CurrencyOutNode
Determines the outgoing currency code
•SettlementAccumulatorsNode
Determines three settlement accumulators:
– OfsetSettleId
– AccumId
– AccumId2
•BillingNode
Sets the item's deposit billing code
The configuration of Enrichment is explained in this book with the example of Settlement.
3.2.1 Same Day Settlement
The implementation of Same Day Settlement is accomplished in two nodes:
•PaymentMethodOutNode
This node determines the endpoint that is assigned to an item. As part of that process, it also determines whether an item is eligible for same day settlement. For details about the endpoint assignment part of the flow, see 3.3, “Routing and Endpoints assignment” on page 70.
•BusinessDayItemNode
This node uses the batch entry date to determine the distribution and the settlement dates for an item.
PaymentMethodOutNode
The determination of whether an item is eligible for same day settlement is accomplished by using a series of four lookup tables:
•SameDayOriginatorTable
This table contains the keys Partner and Product ID.
Business Rules builds the lookup table with the view shown in Example 3-1. Other tables have similar type views. The keys are the table columns whose values are used to look up a match. If a match is found, the other columns are the payload values that are assigned to the payload variables. These payload variables are what are returned, and can then be used as keys for subsequent table look ups.
Example 3-1 Viewing rules
CREATE
VIEW RULES.Same_Day_Originator _V(
relid ,
ibmValDepositorId ,
ibmValProductId
) AS SELECT
R.RELID ,
DSS.DEPOSITOR ,
DSS.PRODUCT_CODE
FROM
DEPOSITOR_SUB_SERVICES DSS ,
RELEASE R
WHERE
DSS.SERVICE_TYPE = ‘Same day settlement’
•SameDayAchSecCodeTable
This table contains the key AchSecCode.
•SameDayRoutingTransitTable
This table contains the key RoutingTransit.
•SameDayDeadlineTable
This table contains the keys Forward Return Indicator and File Arrival Time. It is used to confine eligibility to a time of day range.
Only the SameDayDeadlineTable has a payload that is associated with it: the Same Day Endpoint. The Same Day Endpoint is read into an internal data field: ibmIntSameDayEndpoint.
The same day process picks up in the BusinessDayItemNode, which determines whether the item has been received in time or is late. If received in time, the endpoint (ibmNprEndpoint) is updated with the same day endpoint.
BusinessDayItemNode
This node uses the batch entry date to determine the distribution and the settlement dates for an item. This is the date that the originator is requesting this item to be settled with the RDFI. For ACH, this is the Effective Entry Date field in the batch record.
In more detail, the Effective Entry Date (ibmEntryDate) is used by the BusinessDayItemNode to determine the distribution date (ibmNprBdDate) and the settlement date (ibmNprDateDistSettles).
This node also sets the date that the originator would like to settle (ibmIntNormalizedRequestedDate), which is used exclusively downstream in SettlementAccumulatorsNode. The ibmIntNormalizedRequestedDate is set to the Entry Date, unless it is late. In that case, it is set to the distribution date.
Additionally, the Endpoint is changed to the Same Day Endpoint (if established in the PaymentMethodOutNode) given that it is on time.
The business date as determined in the Business Day Workflow (FtmBusinessDayWorkflow) and as called for each batch, can be adjusted by this node. This is done by first running it through a deadline table. BusinessDayItemNode calls the item deadline table (DepositProductDeadlineItemTask), this time including the endpoint as part of the key to the lookup (in addition to the Product Id and File Arrival Time). Therefore, this node must run after the endpoint has been established (PaymentMethodOutNode in the Financial Transaction Manager for ACH Sample).
After setting the distribution date, the Distribution Day Offset is looked up. This is used to calculate the settlement date. There are three tables in the sample reference implementation that is used to configure this input: SttlCutoffEndpointTable, SttlCutoffMsgTypeTable, and SttlCutoffMsgStandardTable. They are called in turn until one of them has a successful lookup. The payloads are the same for each: The Preferred Distribution Day Offset, the Latest Distribution Day Offset, and the Error Code to assign should the item be late. The keys are noted in the following list along with the elements they contain:
•SttlCutoffEndpointTable:
– Endpoint
– Msg Standard Out
– Msg Type Out
– Credit Flag
•SttlCutoffMsgTypeTable:
– Msg Standard Out
– Msg Type Out
– Credit Flag
•SttlCutoffMsgStandardTable:
– Msg Standard Out
– Credit Flag
A detailed example of this flow can be found in 3.4, “Troubleshooting” on page 73.
3.2.2 SettlementAccumulatorsNode
This node sets the date to settle with the originator (ibmNprDateOriginatorSettles) and assigns settlement accumulators (ibmNprAccumId, ibmNprAccumId2, and ibmNprAccumOffsetSettleId).
Originator Settlement
The date to settle with the originator is normally the same as the entry date, which has been normalized to a valid date in BusinessDayItemNode (ibmNprDateDistSettles). However, this can be changed for preferred partners. By setting the Service Type to Settle when requested, the selected partners are eligible to receive settlement on an earlier date. In this example, information is in Partner Subscribed Services in SampleAchConfiguration.xls (typically in installDir/shared/v300/pfs/DSU/importexport/xls) as shown in Figure 3-8.
Figure 3-8 Partner Subscribed Services
Business Rules builds the lookup table with the view shown in Example 3-2.
Example 3-2 Build lookup table
CREATE
VIEW RULES.Sttl_Sub_When_Requested_V(
relid ,
ibmValDepositorId ,
ibmValProductId
) AS SELECT
R.RELID ,
DSS.DEPOSITOR ,
DSS.PRODUCT_CODE
FROM
DEPOSITOR_SUB_SERVICES DSS ,
RELEASE R
WHERE
DSS.SERVICE_TYPE = 'Settle when requested'
If the partner qualifies, ibmNprDateOriginatorSettles is set to ibmIntNormalizedRequestedDate (which is determined by BusinessDayItemNode). The setting of ibmNprDateOriginatorSettles is accomplished through a combination of assignment statements in the task descriptor and a lookup in the SttlSubWhenRequestedTable, as shown in Example 3-3.
Example 3-3 Setting ibmNprDateOriginatorSettles
<?xml version="1.0" ?>
<taskDescriptor name="SttlSubWhenRequestedTask" type="TABLE">
<assignments>
<assignment field="ibmNprDateOriginatorSettles" type="field" value="ibmNprDateDistSettles" executionPoint="onEntry"/>
<assignment field="ibmNprDateOriginatorSettles" type="field" value="ibmIntNormalizedRequestedDate" executionPoint="onExit" results="SUCCESS"/>
</assignments>
<dataName>SttlSubWhenRequestedTable</dataName>
</taskDescriptor>
The other task of the SettlementAccumulatorsNode is to assign the settlement accumulators. Therefore, there are two basic types of accumulators: Accumulators and Offset Accumulators.
The offset accumulator types are Ingest offset G/L (General Ledger) (ibmNprAccumId2) and Offset settle (ibmNprAccumOffsetSettleId). The settings for both are also done in the SampleAchConfiguration.xls in the Partner Subscribed Services tab, as shown in Figure 3-9.
Figure 3-9 Partner Subscribed Services 2
Two Business Rules tables determine the accumulators: SttlSubCreateBalOriginatorTable and SttlSubCreateBalSendPointTable. They are built in the same way as SttlSubWhenRequestedTable as shown in Example 3-3. A hit in either table enables the offset accumulators to be set. A miss in both results in the offset accumulators not being set. The keys are noted in the following list:
•SttlSubCreateBalOriginatorTablePartner
– Product Id
•SttlSubCreateBalSendPointTable
– Sending Point, Msg Standard Out
Tables are used to do the actual accumulator assignment: SttlAccumOffsetOriginatorTask, SttlAccumOffsetSendPointTask, and SttlAccumOffsetProductTask. The first one that has a successful hit is used. The following keys are available:
•SttlAccumOffsetOriginatorTable
– Partner
•SttlAccumOffsetSendPointTable
– Immediate Destination Routing Transit, Sending Point
•SttlAccumOffsetProductTable
– Product Code
The standard accumulator type is Ingest G/L (ibmNprAccumId). There is no Partner Subscribe Service requirement to do this assignment.
There are two tables: SttlAccumDistAccountTask and SttlAccumDistEndpointTask. The first one that has a successful hit is used.
The keys are for these tables are as noted in the following list:
•SttlAccumDistAccountTable
– Endpoint, RT, and Account
•SttlAccumDistEndpointTable
– Endpoint
3.3 Routing and Endpoints assignment
The routing of payments in Financial Transaction Manager for ACH is configured by using Endpoints. An endpoint defines how work being exchanged between two trading partners is financially settled. Endpoints specify the receiving point of the work. For example, a bank can send a single file to Bank A, but the file can contain work for multiple banks.
The creation of an Endpoint is described in 7.3, “Configuring an endpoint” on page 191.
In Partner Profiles, when an endpoint is defined, it is always associated with the partner to which it belongs. Multiple endpoints can be defined for the same partner. Transmission definitions and building options must be created before endpoints can be created.
To manage endpoints in the Control Center, click Configuration → Partners → Endpoints. The resulting window shows all the available endpoint records in the system as shown in Figure 3-10.
Figure 3-10 Manage Endpoints window
The columns can be filtered by these criteria:
•Endpoint ID
•Receiving point
•Transmission definition
•Product code
•Collection type
•Building options
•Replication endpoint
At this window, Endpoints can be added or edited, as described in 7.3, “Configuring an endpoint” on page 191.
In the Business Rules component, the endpoint is assigned by the Payment Method Out Node. This node also determines the Message Standard and Message Type Out values and the On-Us flag. It consists of a series of lookup tables that determine the endpoint based on different key field combinations. They are called in a hierarchical process until a successful lookup is reached, at which time it moves to the Same Day Settlement section. Same Day Settlement can then override the endpoint in when all criteria are met.
The Payment Method Out Node is described in Figure 3-11.
Figure 3-11 Payment Method Out Node
If all criteria are met, the green boxes represent the table lookups. The pink box shows that the Standard Out and Message Type Out take on the values of their incoming counterparts if the node failed to set them.
To see one of the tables in the UI, click Configuration → Validation Rules → Releases. Scroll down the list and select PayMethodOutOnusTable (Component Type is Data). This window shows the first forward table.
|
Note: The Distribution feature is required for this function.
|
3.4 Troubleshooting
To locate the cause of errors or problems with Financial Manager for ACH, the component traces are the first place to look.
As described in previous chapters, the Business Rules component is used during ingestion for data validation, assigning data enrichment values, and for endpoint assignment. When a warehoused processing batch is being processed, Business Rules are used again in case anything has changed, for example the endpoint assignment. If you receive error codes resulting from Business Rules processing, or data enrichment values are not correct, which affect subsequent processing, first inspect the Business Rules trace to determine what is causing the problem. To turn on tracing in Business Rules, use these commands:
•Use trace all from the console for validation issues
•Use trace detail from the console for any other problems during configuration
The Business Rules trace is informative and straightforward. The output of the trace all command is extensive, so use it only for validation problems.
The following example of the Business Rules trace in Figure 3-12 shows the Settlement flow described in 3.2.1, “Same Day Settlement” on page 66. In the trace example, the current date is 4/23/2015 and the entry date is 4/24/2015. Red text marks points of interest. Gray numbers mark the annotations.
Figure 3-12 Trace example
Annotations:
1. This date is effectively the same as that determined in the Business Day Workflow in most cases.
2. This partsays that the selected day is a normal business date. If it had been a holiday or weekend, the trace would say that the date was adjusted to a valid business date.
3. The minimum cutoff offset is two.
4. This part informs you that the item was late, which has consequences for the settlement day.
5. Because the item is late, it must be processed the same day. If the entry date had, for example, been 4/27/2015, the ibmNprBdDate would still be 4/23/2015.
6. This value is set to two business days in the future.
If the error cannot be found in the Business Rules traces, inspect the ITS and Gateway trace.
To prevent issues during Configuration or to help find issues quickly, consider the following tips:
•Delay running the JSE apps (ITS, Gateway, Business Rules) as services until late in the development stage. As soon as these apps begin running as services, customers handicap themselves in diagnosing repeatable issues by having to use the UI to look at and parse console messages.
•Use small test files. Generally all the information is contained on the console. Larger files tend have information that scrolls off the window.
•Configure consoleLevel = all in the config files so that when the trace is turned on, it is displayed on the console (by default the consoleLevel is set to info).
•Configure all JSE apps to obtain snapshots. This streamlines pulling the necessary information together for IBM Level 2.
|
Note: The measures identified in this section are helpful if the problem occurs within Financial Transaction Manager for ACH. Make sure that the problem does not lie in one of the prerequisite programs. For example, database unavailability can cause errors in Financial Transaction Manager for ACH. For information about troubleshooting the prerequisite products, see their respective documentation. For IBM prerequisite products, see the IBM Knowledge Center.
|
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.