Subtle Conditions

The flexibility of the payment validation rule node and table relationship introduces several conditions that are important to understand. Construction of the tables requires careful consideration as to payload fields used as key in subsequent tables downstream in the workflow.
  1. Multiple tables have the same payload fields that are used in a downstream node as a key and these fields may or may not be set. The use of these fields are more complicated with the use of the values to ignore the loading of the payload.

    For example, consider the following workflow through three nodes: routing transit, account, and process control, in that order. The process control table has ibmIntPcPrefix as one of its keys. This is a payload field in the routing transit and account tables. With both the routing transit and the account’s value set to all blanks (meaning to ignore it), and when the process control node is executed, the ibmIntPcPrefix’s value has not been set. At this point, the process control node returns success without performing the lookup.

    Now, let the routing transit node have a valid value and the account node still has all blanks. The routing transit lookup sets this field and the account lookup ignores it because it is all blanks. When the process control node is executed, it uses the routing transit’s value and attempts the lookup in the process control table instead of returning success without performing the lookup.

    Normally tables would not be configured this way but, if they are, this is the effect.

  2. Character (char) type payload fields in the tables are automatically trimmed of trailing blanks.
  3. A record must exist in the process control table to assign record IDs for a successfully validated treasury item. The suggested range values for the process control low and /high key is 010100 and 123199, with a unique process control Prefix. This guarantees that each record is found for all successfully validated dates and assigns a Record ID.
  4. When running a document sorter against a PVR workflow, the ibmNprControlDoc field being sent by the client is ignored. The Record Type field (ibmNprRecordType) is what defines the type of control document. Only four values are supported: 244–Batch, 245–Block, 246–Divider, and 247–Tracer.
  5. Programming Note: The dataTypes of the individual fields are fixed and no automatic conversion is performed. All the fields that begin with ibm are reserved fields. User exits can read data from and write data to them, but their dataTypes are predefined to either character or byte types.

    Character types identify string data and byte types are for binary values or arrays. If a data field is a byte type and a DecisionDataField.SetData (string) function is called, for example, an exception is shown.

    One exception to this is that both GetDataAsBoolean and SetData (boolean) allow a single character to be used: Y or N.

  6. The first validation that fails for a given field skips the remaining checks. For example, if the item would fail both the digit check and the length, the digit validation is performed first; therefore, its validation is applied. All seven fields are validated or at least attempted (must have a record defined) and, if more than one MICR field fails, the last one’s error field ID is applied. The first field checked is the amount and the last field checked is AuxOnUs.