Oracle FLEXCUBE uses Spend Analysis to track the Debit transactions of a customer. By tracking the debit transaction of an account the customer can manage all the debit transactions in a more effective way.
This chapter explains the spend analysis feature of Oracle FLEXCUBE and various maintenances and operations associated with it.
This chapter contains the following sections:
This section contains the following topics:
Spend analysis feature of Oracle FLEXCUBE supports the following actions:
Oracle FLEXCUBE classifies the debit transactions from a customer account under different spend classes.
A spend class refers to the classification of debit transactions made from a customer account for a specific purpose. Based on the type of expenditure from the account, Oracle FLEXCUBE will classify the debit transactions under different spend classes.
This classification is available only for the respective customer. It helps the customer to get the details of the money spend from the account under each spend class.
Consider the examples.
Mr. Sharma is a customer of the bank. He has access to the internet banking system (in this case the Oracle FLEXCUBE Direct Banking System) to view the breakup of all transactions involving debits from his account.
The transactions are already grouped under different spend classes based on certain rules either pre-defined or maintained in Oracle FLEXCUBE.
Mr. Sharma’s debit transactions from September 01, 2013 to September 20, 2013 are given below:
Date |
Currency |
Amount |
Categorization |
01-09-2013 |
INR |
40000.00 |
CHome Loan EMI |
08-09-2013 |
INR |
500.00 |
Swisscom Mobile Bill |
10-029-2013 |
INR |
312000.00 |
Citbank Credit Card Bill |
12-09-2013 |
INR |
6000.00 |
Electricity Bill |
Based on the spend rules, the system classifies the transactions under different Class Codes and Sub Class Codes as follows:The system thus classifies the debit transactions from the account based on the bank defined class codes and sub class codes..
Date |
Currency |
Amount |
Categorization |
|
Class Code |
Sub Class Code |
|||
01-09-2013 |
INR |
40000.00 |
Loan |
Home Loan |
08-09-2013 |
INR |
500.00 |
Mobile Bill |
Swisscom Mobile Bill |
10-09-2013 |
INR |
12,000.00 |
Credit Card Bill |
Citbank Credit Card |
12-09-2013 |
INR |
6,000.00 |
Electricity Bill |
|
After a week, Mr. Sharma views the breakup of his transactions from September 01, 2013 to September 20, 2013.
He observes that the transactions are classified under different spend classes as follows:
Date |
Currency |
Amount |
Categorization |
|
Class Code |
Sub Class Code |
|||
01-09-2013 |
INR |
40,000.00 |
Loan |
Home Loan |
08-09-2013 |
INR |
500.00 |
Mobile Bill |
Swisscom Mobile Bill |
10-09-2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12-09-2013 |
INR |
6,000.00 |
Electricity Bill |
|
14-09-2013 |
INR |
5,000.00 |
Cash |
|
17-09-2013 |
INR |
2,000.00 |
Cash |
|
Mr. Sharma knows that he has withdrawn INR 5000 and INR 2000 from his account through an ATM transaction. He then used that amount for car servicing and medicines respectively. Also, he is aware that he has paid the Electricity Bill for BESCOM.Now, by seeing the transactions he has re-categorized the transactions based on his spending nature.
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
- |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
Mr. Sharma finds that there is no specific “Sub Class Code” available to categorize the car servicing under Repair and Maintenance Class Code which has been defined by the bank. Hence, he adds a new “Sub Class Code” called “Car Servicing” under the bank defined “Class Code” Repair and Maintenance and re-categorizes the transaction of INR 5000 to “Car Servicing”.
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
Car Servicing |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
On September 23, 2013 Mr.Sharma logs in to his account and views his transactions from 01-September-2013 to 23-September-2013. In this period, he noticed that two or more transactions are made in the account as shown below:
20-September-2013: He has a made a funds transfer of INR.3000 to his friend Mr.Akshay within the same bank. It has been classified as “Other Expenses” in spend class based on the bank defined rules.Mr.Sharma re-categorizing the above transaction as follows:
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
Car Servicing |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
20/09/2013 |
INR |
3,000.00 |
Other Expenses |
- |
For INR.3, 000, he created a new ‘Class Code’ called ‘Funds Transfer’ new “Sub Class Code” called “To Akshay”, and then he re-categorized the transaction.
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
Car Servicing |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
20/09/2013 |
INR |
3,000.00 |
Funds Transfer |
To Akshay |
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
Car Servicing |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
20/09/2013 |
INR |
3,000.00 |
Funds Transfer |
To Akshay |
Mr.Sharma logs into the system and feels that he does not require specific “Sub Class Code” for car servicing and that he has deleted the “Sub Class Code -Car Servicing”. Here, Car Servicing is under the “Class Code -Repair and Maintenance”. Though the transactions are assigned to the “Sub Class Code - Car Servicing” the system allows the user to delete the user defined sub class codes and assigns the transaction automatically to its parent class code “Repair and Maintenance”.
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
- |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
20/09/2013 |
INR |
3,000.00 |
Funds Transfer |
To Akshay |
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
- |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
20/09/2013 |
INR |
3,000.00 |
Funds Transfer |
To Akshay |
Mr.Sharma logs into the system and feels that he does not require the Class Code “Funds Transfer”. While he is trying to delete this class code, the system display an error message stating that the “Class Codes which has underlying transactions cannot be deleted”.
Since the class code “Funds Transfer” has a “Sub Class Code - To Akshay” and it has an underlying transaction, the system does not allow the user to delete the user defined class code. User need to re classify the underlying transaction to any other “Class Code/Sub Class Code” to delete the Class Code “Funds Transfer”.
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/9/2013 |
INR |
40,000.00 |
Loan |
Home Loan |
8/9/2013 |
INR |
500 |
Mobile Bill |
Swisscom Mobile Bill |
10/9/2013 |
INR |
12,000.00 |
Credit Card Bill |
CITI Bank CC |
12/9/2013 |
INR |
6,000.00 |
Electricity Bill |
BESCOM |
14/09/2013 |
INR |
5,000.00 |
Repair & Maintenance |
- |
17/09/2013 |
INR |
2,000.00 |
Medical Bills |
- |
20/09/2013 |
INR |
3,000.00 |
Funds Transfer |
To Akshay |
The following transactions are made by a customer whose name is Mr.Ajay. He has the access to internet banking system (in this case the Oracle FLEXCUBE Direct Banking system) and he will be able to view the breakup of all the transactions involving debits from his account using spend analysis facility.
His transactions (only debits) from 01-November- 2013 to 20- November-2013 involve the following:
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/11/2013 |
INR |
40,000.00 |
Loan |
- |
8/11/2013 |
INR |
500 |
Mobile Bill |
- |
10/11/2013 |
INR |
12,000.00 |
Credit Card Bill |
- |
20/11/2013 |
INR |
10,000.00 |
Cash |
- |
Mr.Ajay realized that he has withdrawn cash from an ATM and used it for multiple purposes like Purchasing Medicines, Groceries and Pizza. Hence, he splits the cash transactions into three and assigns to 3 “Sub Class Codes” created by him. N.
For INR.5, 000, he has created three new “Sub Class Codes” called “Medical Bills”, “Groceries” and “Pizza” under the “Class Code - Cash” and then he re-categorizes the transaction.
Date |
Currency |
Amount |
Categorization |
|
|
|
|
Class Code |
Sub Class Code |
1/11/2013 |
INR |
40,000.00 |
Loan |
- |
8/11/2013 |
INR |
500 |
Mobile Bill |
- |
10/11/2013 |
INR |
12,000.00 |
Credit Card Bill |
- |
20/11/2013 |
INR |
5,000.00 |
Cash |
Medical Bills |
20/11/2013 |
INR |
3,000.00 |
Cash |
Groceries |
20/11/2013 |
INR |
2,000.00 |
Cash |
Pizza |
Every debit entry can be classified under a spend class based on certain attributes held by the transaction.
Based on the rules defined in the ‘Spend Rule Maintenance’ screen, these attributes decide the classification of a transaction.
The following entries will be taken up for classification:
An entry has the following attributes:
Field Name |
Description |
Spend Class |
The Spend Class to which the entry/transaction is mapped to. |
Source |
The Source Code of the Internal/External System |
Module |
The Module encompassing the entry in consideration |
Transaction Reference |
The Reference Number of a transaction |
Event Code |
This would identify the purpose for which the transaction had been triggered |
Event Code Description |
The description of the event code used to identify the purpose of the transaction. |
Branch Code |
The branch from which the entry was triggered. |
Transaction Date |
The date on which the transaction had occurred. |
Customer |
The Customer for whom the transaction had occurred. |
Account Number |
The account number for which the transaction was triggered. |
Amount |
The amount which was transacted |
Currency |
Currency of the above mentioned Amount |
Additional Information |
Additional information about the transaction detailed in the preceding statement narrative which is to be passed on to the account owner. |
External System User ID |
The User ID mapped to the External System. |
Channel User ID |
The User ID used to access the Channel from which the transaction was initiated. |
Instrument Code |
Instruments like Cheques issued can be captured here. |
Applied Rule |
The rule which has been applied to arrive at the Spend Class mapped to this entry. |
Each entry considered for spend analysis is subject to a rule-application logic, which takes the entry through each rule arranged in ascending order of priority. Once a rule succeeds in its execution, the spend class associated with that rule is assigned to the entry and the rest of the rules are not executed. This process is repeated for the rest of the entries.
In case of a reversal entry, either the FCY amount/LCY amount is negative or the event is reversal-specific or both.
A reversal entry is considered if the following attributes match the original entry:
Field name |
Description |
Module |
The Module encompassing the entry in consideration |
Value Date |
The value date of the Transaction |
Transaction Reference |
The Reference Number of a transaction for all modules except Loans |
Related Account |
For Loan Modules |
Branch Code |
The branch from which the entry was triggered. |
Account Number |
The account number for which the transaction was triggered. |
Amount Tag |
The amount tag used |
Currency |
Currency of the above mentioned Amount |
The reversed entry is matched with the original entry by searching spend entries. If the entry is found, the original entry and reversed entry are uncategorized. The process status is updated as ‘Deleted’ so that the entries are not considered for spend analysis. The corresponding entry in spend entry group is also updated.
If a match for a reversal entry is not found in the original entry, then the system applies the normal categorization process based on rules.
A transaction can be split into multiple amounts and classified into class codes or sub class codes. If a transaction has been split already and the user wants to change the splitting of the transaction, then the original splitting needs to be reversed completely.
For example: a transaction of USD 11,000 has been split into USD 5,000, USD 4,000 and USD 2,000. After some time, the user wants to split the transaction into USD 6,000, USD 3,000 and USD 2,000 then the earlier splitting needs to be reversed and the user can begin splitting the transaction as desired.
If the original transaction has been reversed in UBS, then the entire split amounts will be reversed and there will not be any record available against the “Class Code” or “Sub Class Code” to which it was assigned.
This section contains the following topics:
Multiple sub class codes for a specific class code can be maintained by a bank user in the ‘Spend Class for Bank’ screen. You can invoke this screen by typing ‘ITDSPCBK’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.
Specify the following details in this screen:
Class Code
The class code is system generated.
Description
Specify a description of the system generated class code.
Sub Class Code
The default sub class code is system generated.
Description
Specify a description of the sub class code.
The following operations can be performed in this screen:
You can view a list of class codes maintained by the bank user in the ‘Spend Class Summary’ Screen. You can invoke this screen by typing ‘ITSSPCBK’ in the on the field at the top right corner of the application toolbar and click the adjoining arrow button.
You can search for a record by entering details in the following fields:
Click the search button and the following fields will populated with values based on your search parameters:
This section contains the following topics:
The following activities can be done in this screen:
To invoke this screen, type ‘ITDSPCLS’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.
Specify the following details:
Class Code
The system generates a unique spend class code. This will be a unique identifier of the spend class that you maintain. However, you cannot modify the class code.
Description
Enter a brief description of the spend class that you maintain.
Customer Number
The value in this field is auto populated when the channel user is creating a Class Code from the channel. This field is not be applicable when the “Sub Class Code” is added to a bank defined “Class Code” by the customer.
Note
If a Customer No is associated with a spend class, then the spend class is available only for this particular customer.
Customer Name
Based on the customer number selected, the system displays the name of the customer. This field is not be applicable when the “Sub Class Code” is added to a bank defined “Class Code” by the customer.
Internal Class Code
Specify the internal class code for bank reference. When a customer creates a spend class through other modes, you can map that class code to an internal class code. This helps the bank identify and classify customer created spend classes.
Description
The system displays the description of the internal class code.
Once you have captured the above details, save the maintenance.
Note
Sub Class Code
The value in this field is defaulted based on the selection of the class code. All valid class sub codes defined under the selected class code is displayed.
A channel user can add a sub class code to the existing bank defined class code or channel user defined class code. The option list adjoining the ‘Class Code’ field lists the class codes as maintained by the bank user and the class codes as maintained by the channel user. The channel can select a class code to map the sub class code.
Description
Specify a description of the Sub Class Code.
Customer Number
The customer ID is defaulted when the Class Sub Code is added by a channel user. If customer id is assigned then that particular sub class code is applicable to that customer only.
Customer Name
The customer name is defaulted here. This field is not applicable when the “Sub Class Code” is added to a user defined “Class Code” by the customer.
You can view a slist of all the class codes created by the bank user and the channel user. To invoke this screen, type ‘ITSSPCLS’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.
You can search for the spend class records based on one or more of the following parameters:
Once you have set the search parameters, click ‘Search’ button. The system displays the spend class maintenance records that match the search criteria.
This section contains the following topics:
Oracle FLEXCUBE classifies the debit transactions into different spend classes based on the spend rules. These rules can be setup only for branch defined class codes and sub class codes.You can define new spend rules using ‘Spend Rule Maintenance’ screen. To invoke this screen, type ‘ITDSPRLM’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.
Specify the following details:
Bank Code
The system displays the bank code.
Priority
Specify the priority of the spend rule sequence. You can set the priority in any random order (1, 100, 91, 888 etc.).
The system considers the priority of a rule while classifying transactions.
Condition
Specify the condition to be used in the rule. You can define a condition using the ‘Expression’ button.
For further details on defining conditions using expressions, refer to the section ‘Creating Expressions’ in this chapter.
If a debit entry satisfies the condition and result, the system will classify that entry under the spend class mapped to the rule.
Result
Specify whether the condition is expected should be met or not. You can choose one of the following results from the drop-down list:
If a debit entry satisfies the condition and result, the system will classify that entry under the spend class mapped to the rule.
Class Code
Specify the class code to which you need to map the spend rule. The option list displays all the system defined spend class codes maintained in the system. Choose the appropriate one.
Description
The system displays the description of the spend class.
Negative Points
The system displays the negative points that the rule sequence has. The system displays zero as the default value when you define the rule.
The system adds a negative score only when an entry classified based on this condition is reclassified later under a different system defined spend class.
When the negative points accumulated by a rule exceed a threshold limit set at Interactions Preferences, the system brings down the priority of the rule. The system considers the priority of a rule while classifying transactions. As the rule priority goes down, the system is less likely to consider the rule while classifying transactions.
Sub Class Code
Select the sub class code from the adjoining option list. All bank defined sub class codes as maintained in the system are displayed here.
Description
The description of the sub class code is defaulted.
You can build the conditions with expressions for the spend rule conditions using ‘Expression’ screen. Click ‘Expression’ button on ‘Spend Rule Maintenance’ screen.
You need to specify the following details to create the expression.
Condition
Based on the element, operators and logical operators that you select in the below fields, the system displays the condition.
Elements
Select element based on which you need to build a condition for spend rule. The following elements are applicable to spend rules:
Element |
Field |
Description |
$SOURCE |
Source |
The source code of the internal/external system |
$MOD |
Module |
The module encompassing the entry in consideration |
$TRNREF |
Transaction Reference |
The reference number of the transaction |
$EVENT |
Event Code |
The purpose of triggering the transaction |
$AMOUNT |
Amount |
The amount transacted |
$CCY |
Currency |
Currency in which the amount is represented |
$ADDLINFO |
Additional Information |
Additional transaction details from the preceding statement narrative which will be passed on to the account owner |
$EXTSYSUID |
External System User ID |
The user ID mapped to the external system |
$CHANNELUID |
Channel User ID |
The user ID used to access the channel from which the transaction was initiated |
$INSTMTCODE |
Instrument Code |
Code of the instruments such as cheques |
$TRNCODE |
Transaction Code |
Transaction code |
$TRNDESC |
Transaction Description |
Transaction description |
$AMTTAG |
Amount Tag |
Amount tag |
Functions
Specify the mathematical function for building the condition. The drop-down list displays the following functions:
Choose the appropriate one.
Operators
Select the operator for building a condition for spend rule. You can use multiple elements, in conjunction with the functions and arithmetic operators. The drop-down list displays the following operators:
Choose the appropriate one.
Logical Operators
Select the logical operator for building a condition for spend rule. The system uses the logical operators in combination with the elements for creating derivation rules. The drop-down list displays the following logical operators:
Choose the appropriate one.
Once you have created the condition, save it.
The system will classify each debit transaction under different spend classes based on the rule-spend class mapping set here. You can also create a rule to classify the transactions that do not qualify any of the rules maintained in the system. These rules can be defined for a bank user defined class code and sub class code.
You can view the details of customer spend entries and transactions using ‘Spend Analysis’ screen. To invoke this screen, type ‘ITDSPQRY’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.
You can search for the spend classification details based on the following parameters:
Customer ID
Specify the CIF of the customer whose spend analysis you wish to view. The option list displays all valid customer numbers maintained in the system. Choose the appropriate one.
Based on the customer number, the system displays the name of the customer.
Account Currency
Specify the currency code. The system will display the customer spend analysis for the currency specified here.
Based on the currency code specified, the system displays the account description.
Click ‘Spend Entries’ tab to view the spend entries for the selected customer and currency.
You can view the following details of each customer spend entry.
Click ‘Transactions’ tab to view the spend transactions for the selected customer and currency.
You can view the following details of each spend transaction under the ‘Transactions’ tab.
A channel user can reclassify an already defined spend class to some other class code or sub class code. The following actions are possible:
This can be achieved through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.
Redundant class code and sub class codes can be deleted. This functionality can be used by a channel user as well as a bank user. Channels users can close or delete the “Class Code”/”Sub Class Code” created by him/her. Similarly, the bank user close or delete the “Class Code” or “Sub Class Code” created at the Bank level.
The class codes can be closed or deleted by a channel user provided there are no underlying transactions associated with the class code or sub class code associated with it. When a Class Code is closed, then the underlying sub class code becomes invalid. The channel user cannot re-classify a closed class code. A channel user can close a class code through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.
A channel user can re-open a closed class code which pertains to him or her. A channel user can reopen a class code through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.
A channel user can delete a sub class code that is created by him or her. A channel user can delete a sub class code even when it is associated with a bank defined Class Code as well. A sub class code can be deleted only if its parent class code is in ‘Open’ status. When a sub class code is deleted, then all underlying transactions associated with the sub class code is then mapped to the parent class code. A channel user can close a sub class code through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.
A bank user is allowed to delete a sub class code associated with the bank defined class code. When a sub class code is deleted, then all underlying transactions associated with the sub class code is then mapped to the parent class code. A bank user will not be allowed to delete a channel user defined class code or sub class code.
A channel user can split a transaction and classify it into multiple class codes and sub class codes. A transaction can be split into multiple amounts and these amounts can be classified into multiple class code and sub class codes. The channel user has a choice to reclassify an already split amount to another class code or sub class code. If the original transaction is reversed in the FCUBS system, then the entire split amount is reversed and no record will be associated with the assigned class code or sub class code. When the earlier splitting is reversed then the whole transaction will be shown against the “Class Code” or “Class Sub Code” to which it was originally associated with before splitting.
The split amount is displayed in the ‘Spend Analysis’ (ITDSPQRY) screen, instead of the original amount. The total split amount should be equal to the original transaction amount or else the system displays an error message. A transaction which is already split, cannot be split further. However, if the splitting has to be done differently, then the transactions can be reversed. A channel user can split transaction through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.