Transaction Validation and Initial Price Item Determination (Specific to Financial Services Domain)

This process includes the following three sub-processes:

  • Transaction Validation - In this sub-process, the transaction records are validated. The transaction level validations are done to check the integrity of the data. During the transaction validation, the system checks whether:

    • Transaction source is defined in the system.

    • Transaction record type is defined for the transaction source in the system.

    • Division and currencies are defined in the system.

    • The account with the specified account identifier, account identifier type and division exists in the system.

      Note: This validation is done when the Transaction Detail Account Validation option type of the Feed Management (C1_​FM) feature configuration is set to Y. If you set the Transaction Detail Account Validation option type of the Feed Management (C1_​FM) feature configuration to N, the system overrides the transaction's account identifier type, account identifier, and division with the first derived account's account identifier type, account identifier, and division, respectively.

    • User ID (if available in the transaction information) is defined in the system.

    • The value other than ‘Y’ or ‘N’ is not specified in the Manual Switch column.

    • The value other than ‘+’ or ‘-’ is not specified in the Credit/Debit Indicator column.

    • Transaction Amount is specified when Transaction Currency is specified, and vice versa.

    • Additional Amount 1 is specified when Amount 1 Currency Code is specified, and vice versa.

    • Additional Amount 2 is specified when Amount 2 Currency Code is specified, and vice versa.

    • Additional Amount 3 is specified when Amount 3 Currency Code is specified, and vice versa.

    • Additional Amount 4 is specified when Amount 4 Currency Code is specified, and vice versa.

    • Additional Amount 5 is specified when Amount 5 Currency Code is specified, and vice versa.

    • Additional Amount 6 is specified when Amount 6 Currency Code is specified, and vice versa

    • Additional Amount 7 is specified when Amount 7 Currency Code is specified, and vice versa

    • Additional Amount 8 is specified when Amount 8 Currency Code is specified, and vice versa

    • Additional Amount 9 is specified when Amount 9 Currency Code is specified, and vice versa

    • Additional Amount 10 is specified when Amount 10 Currency Code is specified, and vice versa

    If the transaction information is invalid or incorrect (for example, division is invalid), the status of the transaction is changed to Error (EROR). But, if the transaction information is not available, the status of the transaction is changed to Invalid (INVL).

  • Initial Price Item Determination - Once the transaction records are validated, the account which will bear the charges for the transaction and the price item and variance parameter or price item parameters to which the transaction will be mapped are determined using certain business rules. These business rules are invoked through a rule type. Depending on the transaction record type, a rule type is invoked for each transaction. The effective rules with the specified rule type are executed, starting with the rule having highest priority, until a rule is satisfied. For example, a rule with the priority 10 will be executed before a rule with the priority 20.

    Note: The system determines rules which are effective based on the Processing Date for Transaction Feed Management characteristic defined for the division to which the transaction belongs. The system uses the Processing Date for Transaction Feed Management characteristic which is effective on the transaction date. If the Processing Date for Transaction Feed Management characteristic type is set to BATCH_​DT, the system executes rules which are effective on the batch business date. However, if the Processing Date for Transaction Feed Management characteristic type is set to TXN_​DT, the system executes rules which are effective on the transaction date. Note that the transaction date must be earlier than or equal to the batch business date. And, if the Processing Date for Transaction Feed Management characteristic is not defined for the division to which a transaction belongs, the system, by default, executes rules which are effective on the transaction date.

    Each rule contains one or more conditions or criteria. For example, Rule A states that if the transaction record type is R001 and the division is New York, then set the following output parameters:

    • ACCT_​NO1_​Val - Account 1

    • DIVISION1_​VAL - D1

    • PRODUCT1_​1_​Val - Price Item X

    Here, Transaction Record Type = R001 and Division = New York are two conditions. If these two conditions in the rule are satisfied, then set three output parameters - ACCT_​NO1_​Val, DIVISION1_​VAL and PRODUCT1_​1_​Val. Now, when this rule is executed and the transaction satisfies this criteria, the transaction is mapped to Price Item X and Account 1 which belongs to D1 bears the charges for the transaction. In case, the rule has four output parameters (ACCT_​NO1_​Val set to Account 1, DIVISION1_​VAL set to D1, PRODUCT1_​1 Val set to Price Item X, and PRODUCT1_​2_​Val set to Price Item Y), the transaction will be mapped to both the price items (i.e. Price Item X and Price Item Y) and Account 1 which belongs to D1 bears the charges for the transaction. A transaction can be mapped to one or more price items or to one or more price item and TOU (variance parameter) combinations. If the multi parameter based pricing feature is enabled, you can map a transaction to one or more price item and price item parameters combinations. Let us understand this with the help of an example.

    Rule B states that if the transaction is performed in US and the transaction amount exceeds 1000 USD, then set the following output parameters:

    • ACCT_​NO1_​Val - Account A

    • DIVISION1_​VAL - D1

    • PRODUCT1_​1_​Val - Price Item X

    • PCD1_​1_​1_​VAL - Country

    • PVL1_​1_​1_​VAL - US

    • PCD1_​1_​2_​VAL - Currency

    • PVL1_​1_​2_​VAL - USD

    • PRODUCT1_​2_​Val - Price Item Y

    • PCD1_​2_​1_​VAL - Country

    • PVL1_​2_​1_​VAL - US

    • PCD1_​2_​2_​VAL - Currency

    • PVL1_​2_​2_​VAL - USD

    Now, when this rule is executed and the transaction satisfies the criteria, Account A which belongs to D1 bears the charges for the transaction which is mapped to the following price item and price item parameters combinations:

    • Price Item X, Country - US, Currency - USD

    • Price Item Y, Country - US, Currency - USD

    More than one account can bear the charges for a transaction and each account can belong to a different division. You can map a transaction to one or more price items, to one or more price item and TOU (variance parameter) combinations, or to one or more price item and price item parameters combinations. The system allows you to map price items for each account. For example, Rule C states that if the transaction is performed in UK and the transaction amount exceeds 1000 USD, then set the following output parameters:

    • ACCT_​NO1_​Val - Account A

    • DIVISION1_​VAL - D1

    • PRODUCT1_​1_​Val - Price Item X

    • PCD1_​1_​1_​VAL - Country

    • PVL1_​1_​1_​VAL - UK

    • PCD1_​1_​2_​VAL - Currency

    • PVL1_​1_​2_​VAL - USD

    • PRODUCT1_​2_​Val - Price Item Y

    • PCD1_​2_​1_​VAL - Country

    • PVL1_​2_​1_​VAL - UK

    • PCD1_​2_​2_​VAL - Currency

    • PVL1_​2_​2_​VAL - USD

    • ACCT_​NO2_​Val - Account B

    • DIVISION2_​VAL - D2

    • PRODUCT2_​1_​Val - Price Item A

    • PCD2_​1_​1_​VAL - Country

    • PVL2_​1_​1_​VAL - US

    • PCD2_​1_​2_​VAL - Currency

    • PVL2_​1_​2_​VAL - USD

    Now, when this rule is executed and the transaction satisfies the criteria, the transaction is mapped to the following price item and price item parameters combinations:

    Charges Borne By Division to which the account belongs... Price Item Country Currency
    Account A D1 Price Item X UK USD
    Account A D1 Price Item Y UK USD
    Account B D2 Price Item A US USD

    You can limit the maximum accounts that can bear the charges for a transaction, maximum price item that can be mapped to a transaction, and maximum parameters that can be used with each price item to determine price item pricing. For more information, see Defining a Transaction Record Type. You can also define rules to ignore transactions based on the transaction attributes. If the rule returns the IGNORE_​SW equal to Y, the status of the transaction is changed to Ignored (IGNR) and no further processing takes place on the transaction.

    You can use the following output parameters while defining rules in the system:

    Output Parameter Naming Convention Example Description
    Account Identifier ACCT_​NOX_​Val ACCT_​NO1_​Val, ACCT_​NO2_​Val, ACCT_​NO3_​Val, .... Used to indicate the account which must bear the charges for the transaction.
    Account Identifier Column Name ACCT_​NOX_​Col ACCT_​NO1_​Col, ACCT_​NO2_​Col, ACCT_​NO3_​Col, ... Used to indicate the column from where the account identifier corresponding to the transaction (in the transaction details) must be picked.
    Account Identifier Type ACCT_​NO_​TYPEX_​Val ACCT_​NO_​TYPE1_​Val, ACCT_​NO_​TYPE2_​Val, ACCT_​NO_​TYPE3_​Val, ... Used to indicate the type of account identifier.
    Account Identifier Type Column Name ACCT_​NO_​TYPEX_​Col ACCT_​NO_​TYPE1_​Col, ACCT_​NO_​TYPE2_​Col, ACCT_​NO_​TYPE3_​Col, ... Used to indicate the column from where the account identifier type corresponding to the transaction (in the transaction details) must be picked.
    Account Division DIVISIONX_​VAL DIVISION1_​VAL Used to indicate the division to which the account belongs.
    Account Division Column Name DIVISIONX_​COL DIVISION1_​COL Used to indicate the column from where the division corresponding to the transaction (in the transaction details) must be picked.
    Price Item Name PRODUCTX_​Y_​Val
    Note: Here, X represents the account and Y represents the price item.
    		 PRODUCT1_​1_​Val, PRODUCT2_​1_​Val, PRODUCT2_​2_​Val, .... Used to indicate the price item to which the transaction must be mapped.
    Price Item Column Name PRODUCTX_​Y_​Col
    Note: Here, X represents the account and Y represents the price item.
    		 PRODUCT1_​1_​Col,, PRODUCT2_​1_​Col, PRODUCT2_​2_​Col, ... Used to indicate the column from where the price item corresponding to the transaction (in the transaction details) must be picked.
    TOU TOUX_​Y_​Val
    Note: Here, X represents the account and Y represents the price item.
    		 TOU1_​1_​Val, TOU2_​1_​Val, TOU2_​2_​Val, ... Used to indicate the variance parameter which you want to use along with the price item for price determination.
    Note: This output parameter appears when the Multi Price Parameter option type of the Multi Parameter Based Pricing (C1_​PPARM_​FLG) feature configuration is set to False.
    TOU Column Name TOUX_​Y_​Col
    Note: Here, X represents the account and Y represents the price item.
    		 TOU1_​1_​Col, TOU2_​1_​Col, TOU2_​2_​Col, ... Used to indicate the column from where the variance parameter corresponding to the transaction (in the transaction details) must be picked.
    Note: This output parameter appears when the Multi Price Parameter option type of the Multi Parameter Based Pricing (C1_​PPARM_​FLG) feature configuration is set to False.
    Parameter Code
    Note: At present, the system does not support the Parameter Code Column output parameter.
    		 PCDX_​Y_​Z_​VAL
    Note: Here, X represents the account, Y represents the price item, and Z represents the parameter.
    		 PCD1_​1_​1_​VAL, PCD1_​2_​1_​VAL, PCD2_​1_​1_​VAL, ... Used to indicate the parameter which you want to use along with the price item for price determination.
    Note:

    This output parameter appears when the Multi Price Parameter option type of the Multi Parameter Based Pricing (C1_​PPARM_​FLG) feature configuration is set to True.

    You must not specify any special character except underscore (_​) in the parameter code. Otherwise, the status of the transaction is changed to Error (EROR).
    Parameter Value PVLX_​Y_​Z_​VAL
    Note: Here, X represents the account, Y represents the price item, and Z represents the parameter.
    		 PVL1_​1_​1_​VAL, PVL1_​2_​1_​VAL, PVL2_​1_​1_​VAL, ... Used to specify the value for the parameter.
    Note:

    This output parameter appears when the Multi Price Parameter option type of the Multi Parameter Based Pricing (C1_​PPARM_​FLG) feature configuration is set to True.

    The parameter value must not contain the equal to (=) and tilde (~) symbols. Otherwise, the status of the transaction is changed to Error (EROR).
    Parameter Value Column Name PVLX_​Y_​Z_​COL
    Note: Here, X represents the account, Y represents the price item, and Z represents the parameter.
    		 PVL1_​1_​1_​COL, PVL1_​2_​1_​COL, PVL2_​1_​1_​COL, ... Used to indicate the column from where the parameter value corresponding to the transaction (in the transaction details) must be picked.
    Note:

    This output parameter appears when the Multi Price Parameter option type of the Multi Parameter Based Pricing (C1_​PPARM_​FLG) feature configuration is set to True.

    The column from where the parameter value is picked must not contain the equal to (=) and tilde (~) symbols. Otherwise, the status of the transaction is changed to Error (EROR).
    Processing Date Type PRCS_​DTX_​Y_​TYP
    Note: Here, X represents the account and Y represents the price item.
    		PRCS_​DT1_​1_​TYP, PRCS_​DT1_​2_​TYP, PRCS_​DT2_​1_​TYP, ... Used to indicate the date type using which you want to determine the effective price item parameters, pricing, and exchange rate. The valid values are:

    • TXN_​DT - Used when you want to determine price item parameters, pricing, and exchange rate which are effective on the transaction date.

    • Batch_​DT - Used when you want to determine price item parameters, pricing, and exchange rate which are effective on the batch business date.

    Note: Based on the Processing Date for Transaction Feed Management characteristic defined for the division to which a transaction belongs, the system determines the rules, price item parameters, pricing, and exchange rate which are effective on the transaction or batch business date. The price item parameters, pricing, and exchange rate which are effective is determined for all account and price item combinations to which the transaction is mapped. If you want to use a custom processing date for a particular account and price item combination to which the transaction is mapped, you need to set the PRCS_​DTX_​Y_​TYP output parameter. In other words, the PRCS_​DTX_​Y_​TYP output parameter helps you to override the processing date for a particular account and price item combination. However, the overridden processing date is used only while determining effective price item parameters, pricing, and exchange rate.
    Processing Date PRCS_​DTX_​Y_​VAL
    Note: Here, X represents the account and Y represents the price item.
    		PRCS_​DT1_​1_​VAL, PRCS_​DT1_​2_​VAL, PRCS_​DT2_​1_​VAL, .... Used to specify a custom date on which you want to determine the effective price item parameters, pricing, and exchange rate.
    Note:

    The custom date must be a date other than the transaction or batch business date.

    Based on the Processing Date for Transaction Feed Management characteristic defined for the division to which a transaction belongs, the system determines the rules, price item parameters, pricing, and exchange rate which are effective on the transaction or batch business date. The price item parameters, pricing, and exchange rate which are effective is determined for all account and price item combinations to which the transaction is mapped. If you want to use a custom processing date for a particular account and price item combination to which the transaction is mapped, you need to set the PRCS_​DTX_​Y_​VAL output parameter. In other words, the PRCS_​DTX_​Y_​VAL output parameter helps you to override the processing date for a particular account and price item combination. However, the overridden processing date is used only while determining effective price item parameters, pricing, and exchange rate.
    Ignore Transaction IGNORE_​SW Used to ignore transactions based on the transaction attributes. The valid values are:

    • Y

    • N

    Once the transaction satisfies any rule (invoked through the rule type), one transaction leg is created for each account, division, price item, and variance parameter or price item parameters combination. Let us understand this with the help of an example. The following table lists the accounts and price items to which T1, T2, and T3 are mapped:

    Transaction Charges Borne By Division to which the account belongs... Price Item Variance Parameter Price Item Parameters
    T1 A1 D1 P1 - Country - US, Currency - USD
    T1 A1 D1 P2 - Country - Germany, Currency - USD
    T1 A2 D2 P3 USD -
    T2 A1 D1 P1 - Country - US, Currency - USD
    T2 A2 D2 P2 USD -
    T3 A1 D1 P3 - Country - Germany, Currency - USD

    In such case, the system will create three legs for T1, two legs for T2, and one leg for T3. Each transaction leg will have its own status. The status of the transaction legs and transaction is changed to Initial Price Item Determined (INPD). However, if a transaction does not satisfy any rule, the status of the transaction is changed to Error (EROR).

    Note:

    During this sub-process, the system validates the following:

    • Whether the price item parameters specified in the output parameters are effective for the price item on the processing date.

    • Whether the mandatory price item parameter which is effective on the processing date is specified in the output parameter.

    • Whether the parameter value is specified for all mandatory price item parameters which are effective on the processing date.

    If any of the above validation fails, the status of the transaction is changed to Error (EROR) and no transaction legs are created.

  • Parameter Group Creation - Once the transaction legs are created, the price item parameters of each transaction leg are grouped. For example, when a transaction is mapped to the following price item and price item parameters combinations, the system creates three groups - Group A, Group B, and Group C:

    • Account A, Price Item X, Country - US, Currency - USD

    • Account A, Price Item Y, Country - Germany, Currency - USD

    • Account B, Price Item X, Country - England, Currency - USD

    Group A contains Country - US, Currency - USD; Group B contains Country - Germany, Currency - USD; and Group C contains Country - England, Currency - USD.

    A set of price item parameters are grouped when the multi parameter based pricing feature is enabled. A group is used to determine the price item pricing. A unique group ID is generated for each group. If a group with a set of price item parameters already exists in the system, a new group is not created. Instead, the existing group is used for determining the price item pricing.

You can execute this process through a multi-threaded batch named Validate Transaction and Derive Price Item (C1-TXNIP). You can specify the following parameters while executing this batch:

Parameter Name Description Mandatory (Yes or No)
Batch Business Date Used to identify the transactions for which you want to perform validation and determine price item. The system considers the transactions whose transaction date is earlier than or equal to the batch business date.
Note:

If you do not specify any date, the batch business date is set to the current date.

The batch business date used while executing the C1-TXNIP batch is stamped in the database. It is then used while executing all other consequent batches in the transaction aggregation cycle.

 No
Transaction Header ID Used when you want to validate and derive price item for the transactions which are received in a particular transaction feed. No
Transaction Source Used when you want to validate and derive price item for the transactions which are received from a particular transaction source. No
Division Used when you want to validate and derive price item for the transactions belonging to a particular division. No
Shuffle Work Unit Used to indicate whether you want to shuffle the work units across threads to correct the uneven thread processing time. The valid values are:

  • Y

  • N

Note: By default, the parameter value is set to N.
 No
Chunk Size Used to specify the number of transactions you want to execute in each work unit. Yes
Maximum Batch Count Used to specify the maximum number of transactions after which the data must be transferred to the database. Yes
Thread Pool Name Used to specify the thread pool on which you want to execute the batch. No

A log is generated if the Logging Rules for Transaction Feed option type in the Rule Engine (C1_​RLENG) feature configuration is set to True. This log indicates the rules that were executed for each transaction and whether each rule passed or failed during the execution.

Note:

You can aggregate transaction legs in a billable charge using aggregation parameters other than account ID, price item code, variance or price item parameters, aggregation start date, and aggregation end date. The additional aggregation parameters can be stamped in the form of aggregation parameter group ID while performing post-processing activities for each transaction leg. This aggregation parameter group ID will be used in subsequent batches during the transaction aggregation cycle. If you want to perform some post-processing activities on the transaction legs, you need to attach a post-processing algorithm on the TFM - Price Item Derivation Post-Processing algorithm entity in the Algorithms tab of the Division screen. Note that the system invokes the algorithm which is attached on the division to which the transaction belongs. This algorithm is triggered only for transactions which are in the Initial Price Item Determined (INPD) status. It is triggered before the price item parameter group is created.

A sample post-processing algorithm type named C1_​PRDR_​POPC is shipped with the price item. It does not have any business logic. If you want to undertake some post-processing activities for a transaction leg, you need to create custom algorithm type and attach the respective algorithm on the Feed Management Price Item Derivation Post-Processing algorithm spot of the respective division. You can refer to the C1_​PRDR_​POPC algorithm type to understand the input parameters that must be passed to the custom algorithm type.

Once the Validate Transaction and Derive Price Item (C1-TXNIP) batch is executed, the processing date is stamped against each transaction leg in the database. If a custom processing date is specified for a particular account and price item combination, the custom processing date is stamped against the respective transaction leg. Otherwise, the processing date defined for the division to which a transaction belongs is stamped against the legs of the respective transaction. The processing date which is stamped against a transaction leg in the database is used while executing all subsequent batches in the transaction aggregation cycle.

Related Topics

For more information on... See...
Rules Engine Rules Engine
How to define a rule Defining a Rule