KNOWLEDGE

ORMB Functional Understanding

Prepared by: Murty Pantula

Creation Date: 15th January 2019
Last Updated: 8 May 2019
Document Ref: Version 2

TCS Internal - ORMB Functional Understanding #1 | P a g e

TABLE OF CONTENTS
1. Functional Overview............................................................................................................................................. 3
2. Functional Features ............................................................................................................................................... 4
2.1 Understanding Framework Concepts ........................................................................................................... 5
2.2 Pages and Menus in ORMB ............................................................................................................................ 7
2.3 ORMB Algorithms / Plug-ins .......................................................................................................................11
2.4 ORMB Functional Process ..............................................................................................................................13
2.5 ORMB Definitions ...........................................................................................................................................15
2.6 GL Distribution String implementation .......................................................................................................24
3. Functional Setup Manager ..................................................................................................................................27
3.1 Configuration and Maintenance (Installation Options) .............................................................................28
3.2 Configuration and Maintenance (Invoice Generation) ..............................................................................30
3.3 Configuration and Maintenance (Payment Processing) ............................................................................35
4. Rules Engine ..........................................................................................................................................................39
5. Write Off Process ..................................................................................................................................................41
6. Accruals .................................................................................................................................................................45
7. Transaction Feed Management ..........................................................................................................................47
8. Case Study .............................................................................................................................................................49

TCS Internal - ORMB Functional Understanding #2 | P a g e

1. Functional Overview
• Oracle Revenue management (ORMB) is a single system for:
• Enterprise pricing
• Calculation
• Sub Ledger
• Settlement needs etc...
• ORMB offers a highly flexible architecture allowing customizations to address typical customer business
requirements
• ORMB is built on technology that quickly adapts to future legislative and policy changes.
• ORMB provides a web-based platform with unmatched integration capabilities.
Three layers of ORMB System:
1) OUAF 2) Revenue Management and Billing 3) Customer release
• OUAF: Oracle Utilities Application Framework. OUAF is shared with associated Oracle Products. OAUF
provides base service to ORMB layer to support
• Entity lifecycle (BOs)
• UI framework (portals, Zones and UI maps)
• Algorithm Plug-in was supporting with scripting.
• ORMB: Revenue Management and Billing. Provides specific revenue management functionality
• Customer Release – Provides customer data and configuration setup specific to customer business
requirements

TCS Internal - ORMB Functional Understanding #3 | P a g e

2. Functional Features

ORMB is offering following Functionality

TCS Internal - ORMB Functional Understanding #4 | P a g e

2.1 Understanding Framework Concepts
ORMB is four tire application and Supports four tire Architecture.
1) IE (User interface, Internet Explorer)
2) Web server
3) Application Server
4) Database Server

TCS Internal - ORMB Functional Understanding #5 | P a g e

Data architecture outlines logical data relationships. Normally in parent-n-child table relationships, Parent will have
few columns, and parent table key columns will be carried to Child table so on. Here Parent (Grand Parent or 1st
parent will have only one key field, and the child will carry only the key field. An example of Person and Person's
details in below table
No Recurring Groups
Recurring groups of columns are not found in a typical database. Child tables “normalize” the relationship so each
implementation may accommodate as many entries as required.
• Person table does not contain two columns:
1) One for SSN 2) Driver’s license
• Rather, a Person’s various ID’s are kept in Person ID table where each entry references an identifier
type
• Same is true for a person’s phone numbers, names, and address. You will find this pattern
throughout the System.
Primary Keys
• Prime key of many “non admin” tables is a system assigned a random number.
• Prime key of most “admin” tables is a user assigned mnemonic.
• “Child” tables frequently have concatenated prime keys
• Prime and foreign keys can be viewed in Application Viewer
• There is NEVER redundant data (not even a column on Account that holds its balances)
• Individual financial transactions are accumulated to derive an account’s balance, and these balances
are dynamic

Example

Business Rules and MOs Encapsulate Core Business Rules

• MOs have core business rules (Validation logic)
• Business rules are written in Java
• These core business rules can be extended by any implementation team.
• Core Business Rules cannot be changed or removed.
• New Core Business Rules may be extended (adding).
• The code is available for viewing in Application Viewer

TCS Internal - ORMB Functional Understanding #6 | P a g e

2.2 Pages and Menus in ORMB
When logging into ORMB the following Banking control Home page opens up.
This page called is Control Central Page or Home page for ORMB. This is where ORMB configuration is executed.

Following are the different terminology of the page.

Set-ups in Admin Menu are one-time setups and do not need daily maintenance.

TCS Internal - ORMB Functional Understanding #7 | P a g e

Day-to-day maintenance and modifications can be found under Main Menu.
Every menu will have Heading Menu, Menu Bars and Action.

Main Menu screen

Admin Menu
Admin Menu: Admin menu runs with Alphabetic order and can be driven with alphabets. All these are part of security
and admin work. Right-hand side box is called Dashboard or Zones or Time Savers and contains 4 to 5 high-level tabs.
In each screen, menus offer Menu Bars and Action Items. Below an example: Main Menu screen
1. Current Contest: Provides Current Page information and associated details
Example: Vendor, the page provides details about that customer
2. Favorites Links: Right-hand side box called a Dashboard or common usage links or Favorites.
Regular accessing links and shortcuts will be available.
3. Alerts: Pending actions that require immediate attention like Payment Due, Customer rating, & any
Configured Alerts. Additionally, the Payment voucher is waiting for approvals.
4. Financial Statements
5. Book Marks
6. To-do lists

TCS Internal - ORMB Functional Understanding #8 | P a g e

Right-hand side box called a Dashboard or Zones or Time Savers and may contain 4 to 5 high-level tabs. Moreover, this
Table also has menus that are known as Personal Menus.
1) Current Contest
This will give current Page information and other related details. Example: If you open a vendor,
then this page will give you all the details about that customer, which is not available on that page.
2) Favorites Links
Right-hand side box called a Dashboard or common usage links or Favorites.
Regularly accessing links and shortcuts will be available.
3) Alerts
In this, it will show what kind of things are pending, Payment Due, customer rating and other
configured alerts. Payment voucher is waiting for approvals.
4) Financial Statements
5) Book Marks
6) To-do list
There are two types of pages
1) Fixed pages: These are data entry or actual pages. Examples; Product page, Customer maintenance page
2) Portal pages: These are a group of pages or Different zone pages. Examples; Dashboards and Home Page.

TCS Internal - ORMB Functional Understanding #9 | P a g e

TCS Internal - ORMB Functional Understanding #10 | P a g e
2.3 ORMB Algorithms / Plug-ins
ORMB provides opportunities to design, develop and integrate custom Algorithms (plug-ins or functions).
Plug-In = Algorithm
• Business Processes and Business Objects have their logic controlled by Metadata objects and are referred to
as plug-ins in ORMB
• At run-time, ORMB system interrogates metadata to determine appropriate plug-in to invoke and then
invokes then. The terms algorithm and plug-in are synonyms
• Algorithms can be viewed in the Application Viewer
Algorithm Example

• Problem: Consider implementing different logic to calculate an insufficient funds charge.

• When a payment is canceled due to insufficient funds, the system invokes Levy NFS Charge Algorithm
that’s plugged-in on the account type admin object.

Script Types
ORMB provides a vast number of scripts and the ability to integrate custom scripts.
• BPA Scripts: BPA Scripts run in client’s browser and guides end user through business processes.
• Service Scripts: Scripts are executed in Application Server to perform server-based processing for BPA scripts
& zones.
• Plug in Scripts: Plug-in scripts run in Application Server
• Unlike service scripts, their APIs are controlled by plug-in spot’s “hard parameters,” and plug-in “drivers can
only invoke them.

TCS Internal - ORMB Functional Understanding #11 | P a g e

 Base Package Plug-Ins or Write your Own (custom plug-ins)
• During an implementation use either a base package algorithm(s) or develop custom new algorithms in
Java or high-level scripting language
• Reference desired algorithm(s) on account type admin object.
A feature allows different account types to have different logic

Service Scripts: Service scripts are nothing more than common routines that have been developed using any scripting
language (Java or COBOL). The main reason to set up Service Scripts (plug-in scripts and by other service scripts) is to
encapsulate commonly used logic.
Plug-in Scripts: Before the advent of plug-in scripts, there were two types of programs that could be specified on an
algorithm type COBOL and Java. Now, the choice of a third language if a related plug-in spot has been “Java enabled.”
There are Java and plug-in scripts released with the base package and Implementers can develop their own.
User –Defined Fields Extend: User-defined characteristics:
Person = Birth Date – 12/10/64 (MM/DD/YY) and Address = County Parcel Id = A234567
There are Four Types of Characteristics: Each characteristic’s char type defines its category and is as below:

TCS Internal - ORMB Functional Understanding #12 | P a g e

2.4 ORMB Functional Process
Following is the ORMB Billing/Invoice generation System functional flow

Deriving Transaction Bill Generation

Input into Staging Pre Processing required Steps in
System Validation sequential
1A Rules Engine
Manual Transaction
Entry Get Account Get Products
Drive/ Process Drive/ Process
User intervention
Get Account Get Product Price Calculation
Validate Staging data before

Parameters Parameters
Yes
Drive/ Process Drive/ Process Processing
Rules and Billing and

Price Before Billing

Generate Bill and
Validation Process

Billing
Yes Requirement Yes (PBB)
Required
Yes
bill segments
sending into

Data Populated? Required

Payment

NO
Staging Area

Aggregate
Transaction
Get Pricing
Drive/Process NO
1B
3rd Party Systems
Or Billing Not Required
Update Generate bill
Bulk Upload status to I
Get Contract
Drive/Process

NO
NO

Following is ORMB Payment Processing functional flow

Apply Payments
In Bound Receivable/Payment Process

1A
Electronic Payment Lockbox
Uploads / Lockbox Processing
Receipt Write-Off
Automatic

1B Receipt/Payment Accounting
Remittance / Creation Apply Payment
Entry Staging

Direct Debit Process

Manual
Receipt Adjustment
1C
Banks Receipt
Process

TCS Internal - ORMB Functional Understanding #13 | P a g e

Following is the ORMB Accrual Processing functional flow:
ORMB – HIGH LEVEL ACCRUAL PROCESS FLOW

Account’s Eligibility Check

for Accrual Accrual Calculation Accrual Creation Accrual Reversal

ORMB – HIGH LEVEL ACCRUAL PROCESS FLOW

Historical Data
Accounting
Bill Level Entry Staging

Actual Data

Accrual Calculation
Historical Data
Bill Segment Accounting
Level Entry Staging

Actual Data

TCS Internal - ORMB Functional Understanding #14 | P a g e

2.5 ORMB Definitions
A. DIVISION: Division is an entity that models a part of the organization with unique Business rules. This
also can be called as a geographic entity like a Branch. A division is associated with a jurisdiction. A
jurisdiction is a geographic-oriented entity with unique business rules. It adds another dimension in
modeling some of the business rules.
A division
- Allows a single division organization to operate one set of rules
- Multi-division allows an organization the flexibility to operate rules and processes in place for
different divisions
- Provides multi-division billing capabilities
Divisions are created (configured) soon after the Installation Options.
• A division is part of the contract, configured on contract types.
• A division is a mandatory field and referenced when defining ‘Account.’
• A person is generally associated with a division
B. Customer: A person/Organization + Person/Organization details + Account are known as Customer
in ORMB.
Person / Customer is associated with demographic information
• Name
• Aliases
• Mailing Address
• Phone numbers
• Person Identifiers (SSN, FEIN, DL)

C. Account (Person/Customer Account): Person Account associated with financial information

• Contracts
• Financial Transactions
An account references one or more persons:
• One of these persons must be defined as the ‘Main Customer.’
• One account can have multiple contracts
Bills are produced for accounts and are sent to accounts persons
• Bills are always sent to the main customer. Alternatively, we can indicate which of the other
persons receive a duplicate bill(s)
Additional account details can be stored by adding account characteristics
Account never expire, they go dormant when they have no active contract
If one account is associated with multiple customers or one customer the basic requirement I for
each account on primary customer / Main customer needed. When invoice generated by default
invoices/bills will be sent to the main customer, if the Business requirement is another customer
which are associated with the customer should get a copy for information purpose then we can

TCS Internal - ORMB Functional Understanding #15 | P a g e

 configure the system saying send a copy. If there are no contracts associated with the customer
then, we cannot make any financial transaction with that customer.
D. Contracts: A contract contains the terms and conditions controlling how ORMB system calculates
charges for a specific service supplied to a customer
• Contracts are associated with a contract type
• Contract type dictates Business Rules and Contract behaviors (handling)
• A contract is always linked to an account and person (either is active or inactive status)
E. Contract Type: A Contract type is a term used to signify differences in contract structure.
Contract type determines what service type the contracts are linked to
• Financial Services
• Healthcare
• Insurance
• GL Division, Revenue class is configured on the contract types
• Additional aspects controlled by the contract type
 Adjustments Profile
 Characteristics
 Algorithms
 Billing details
 Billable charge template
F. Invoice: An invoice is a document issued by the seller to the buyer that indicates the quantities and
costs of the products or services provided (by the seller)
G. Invoice Grouping: Invoice group allows combining the charges for multiple accounts into one bill for each
Billing Period. Invoicing group consists of the following
• Master Account: This is the group level account that controls Billing, i.e., all the bills of the
sub-accounts are clubbed together, or bills are aggregated at the group level
• There is no restriction to the number of accounts that may be combined in an Invoicing
Group
• The account can belong to different customers and different currencies. So far as they
belong to the same Division and Customer hierarchy.
• If a Member account has a different billing currency from a Master account, the member
account's charges will be converted to the currency during the billing
• Balances are maintained at the master level account. Bills add-up to master accounts
balances, and payments subtracted from that balance. However, charges can be traced
back to originating member accounts

TCS Internal - ORMB Functional Understanding #16 | P a g e

 H. Consolidated invoice: When creating a consolidated invoice:
• Identify and create one of the accounts as Master account
• Rest of the account as a member accounts
• When you say master account, this account always at the time of bill generation all the
charges at customer 2 level applies to individual account as well as Master account.
• Invoice grouping can be done only when
• 1) Customers exist should in the Same Hierarchy 2) Division also should be in the same
Hierarchy

Following points need to be considered when using consolidated invoicing or Invoice grouping.
• Relationships between member and Master accounts are bound by start and end dates so that
member accounts can be added and removed from Invoicing groups as and when required
• Payment is made to the Master account

TCS Internal - ORMB Functional Understanding #17 | P a g e

 • During the period when an account is not a Member of any Invoice group, it will be billed
individually with its charges appearing on its bill

I. Product: The Product is a good, idea, method, information, object, or service created as a result of a
process and serves a need or satisfies a want. It has a combination of tangible and intangible attributes
(benefits, features, functions, uses) that a seller offers a buyer for purchase.
• Financial Institution offers Product as a service to customers
• Customers opting for a particular product will be charged based on the Product Type and its
price assignment
• Consumption of services/product as received in the transaction feed form of services quantity
identifier as configured by the system
• There are two types of products available in ORMB
o Bundled
o Non-bundled
• Bundled products are three types
o Regular Bundle
o Phantom Bundle
o Ratio Bundle

J. Product Bundle: A group of Products is packaged into One group called Product group.
• Financial institution often offers a set of services that are grouped. Such are typically either
o Supplementary to the main service like checkbook service and overdraft for the current
account
o Proceed together to offer customer preferred pricing based on overall utilization of
complementary service.
• Products that are grouped for pricing are referred to as Pricing Bundle
K. Rates: Rates are another prerequisite in ORMB for transactions. This setup will be part of the Admin
Setup.
• Rates Includes
 Rates: 1) Rate Schedules 2) Rate Versions and 3) Rate Components
 Rate Check
 Bill Factor
L. Rate Schedule
• A rate Schedule is set up forever type of rate that is offered to the customer
• Rate Schedule defines the basic parameters for pricing, i.e., proration frequency, currency, etc.
• Rate Schedule is not complete without Rate versions and Rate components. Rate Schedule
contains the following information:
 Rate Schedule Code
 Description

TCS Internal - ORMB Functional Understanding #18 | P a g e

  Service Type
 Frequency
 Currency Code
 Allow RV proration
 RV Selection date
o Accounting Date, Bill Start Date, Bill End Date
M. Rate Versions
• A rate version defines Effective Date of calculation rules as defined in its rate components
• A rate Schedule will have multiple rates version of it is calculation rules (i.e., its rate
components) change over time
• Every rate schedule has at least one rate version
• Multiple rate versions exist when something about the rules changes (and it's important to keep
the prior versions to calculate bills in the historical period
• Once a rate version is created, rate components can be added to it
• A rate schedule's effective-dated calculation rules are stored in a rate version
 Every rate schedule has at least one rate version
 Multiple rate versions exist when something about the rules changes (and it's
important to keep the prior versions to calculate bills in historical periods)
 Rate components are contained inside a rate version which consists of the actual rules
for the deriving a rate
• Number of rate components linked to rate version is dependent on the complexity of rate
calculation rules
N. Rate Component
• Rate components are the fundamental building blocks of the bill calculation algorithms
• They define how a particular price is defined in the system
• A rate component is always linked to a rate version which in turn is linked to a rate schedule
• A rate schedule is referenced when a price is defined for a product
• While defining a rate component, the user shall be able to reference the rate version to which it
belongs
• The user can also specify the sequence in which the calculation in rate components needs to be
executed
O. Summary Rate Components: Summary Rate component is a group of components when Customer has
multiple rate components, and all the Rate Components are impacting the pricing and all need to be
applied; in that case, the summary rate component will be defined and attached for pricing. This
Summary rate component is a group of rate components.
This configuration page will have multiple tabs and each tab will validation, distributions, Characteristics,
and eligibility.
P. Work Calendar: Used to indicate days on which this division operates. This calendar is used to ensure
that ORMB system calculated dates (for example, bill due date, credit, and collection event dates, etc.)
fall on a working day.

TCS Internal - ORMB Functional Understanding #19 | P a g e

 Q. Bill Cycle: Define Billing cycles. Used to specify the billing cycle. The billing cycle of the account for which
the bill is generated. It is retrieved from the bill.
R. Price list: Price list from where the pricing for offered product services should be obtained.
• Services offered by banks to its customers are referred to as products. Banks will charge fees or
would pay charge interests for various services
• Pricing is the process whereby a business sets the price at which it will sell its products and services
S. Price List and Pricing: Price Management - This service (Price Management) allows to define prices that
customers pay for products and services offered to them.
• Pricing is arrived at after defining products, optionally defining trailing criteria. Creating pricelist for
these products and assign these at various levels in Customer Hierarchy.
Pricing can be assigned at various levels
 Attach at Price list level (this is rate card having multiple products)
 Attach at Customer Level
 Attach at the Account level.

TCS Internal - ORMB Functional Understanding #20 | P a g e

 T. Pricing Inheritance: If Pricing for a Product is available at the Parent Customer level, then all child
customer and accounts in the customer hierarchy will inherit that price in case there is no pricing
agreement at the child customer or accounts for that product. If they have the lowest (leaf level), that
will be executed/applied
Domestic
Wire Transfer
Price is 0.20
MPA Corp LLC Cents per
Transaction
Corporate (Parent)

MPA US LLC MPA UK LLC MPA CA LLC

Account Account Account

1 2 3

In the above scenario, the price of the domestic wire T/R defined at Parent (Corp) relevels as 0.20
cents per $ transaction. The price would be inherited by the customer MPA US, UK, CA and their
Accounts 1, 2, 3
U. Pricing Methods: ORMB offers the following Pricing Methods:
1) Flat Rate method: This means whatever quantity it may be for each transaction the Price is
constant. Flat Rate refers to a pricing structure that charges a single fixed fee for a service,
regardless of usage, i.e., fixed charge/flat charge. Example: Monthly Account maintenance fee:
This is a simple application of (price * Volume pricing) which is known as flat service quantity based
on ORMB pricing.
Product Transaction Volume Price
ACH 100 1
Flat charges = $1 * 100 = $100

TCS Internal - ORMB Functional Understanding #21 | P a g e

 2) Per Transaction / Service Quantity: This means in each transaction or per quantity; this will be
calculated. Example:

Product Transaction Volume Price

ACH 1 - 100 4
ACH 101- 200 3
ACH 201- 300 2
ACH 301 > 1

Customer A transacted 200 transactions; Customer B transacted 300 and Customer C

transacted 400. Now billing is as follows:
 Customer A = 200* 3$ = $600
 Customer B = 300* 2$ = $600
 Customer C = 400* 1$ = $400
Total Revenue = $1,600 (600 + 600 + 400)

3) Ad Valorem: This means % Percentage calculation

Product Minimum Maximum Transaction Rage Commission

Amount Amount %
ACH 99 9999 1 – 5000 1
5001 > .1 Above 50000 all transaction will be
calculated

A customer made transaction 6000000. Now pricing is as follows:

Case 1 for Ad Valorem:
1-50000 = 50000 * 1% = 5000
50000 > = 10000 * 0.01% = 5500
Total Billing = 10,500 (In this customer will be charged 10,500)

Case 2 for Ad Valorem and Tiered

In this customer has min and max range so will be charged 9999 (Calculated amount is
greater than the maximum amount to the maximum amount will be charged)
V. Price Tiering: This is nothing but allocating ‘Special Price Ranges’ if they transact more business. This
option is created if standard flat pricing is not sufficient to meet the business needs. Below is an example
of Price Tiering. Criterion is the number of wires transfers since the fee to be charged depends on a
number of transfers. Using the above example:
• MPA Global Corp uses wire transfer services provided by a large bank. Up to 1000 transfers, the fee
charged by the bank will be $5 per Transfer. If the company initiates more than 1000 transfers, the
fee charged will be $3 per transfer.
W. CUSTOMER CLASS: When setting up an account, assigning it a customer class is mandatory. It contains
various business rules for every division.
X. ALGORITHM: Many functions in the system are performed using a user-defined algorithm.
Y. DISTRIBUTION CODE: Distribution codes simplify the process of generating accounting entries by
defining valid Combinations of the chart of account field values.
Z. SQI Rules: Most of the time's Service quantity and Pricing quantity are always the same. In some cases,
there are any depreciation or transportation leakages will be eliminated before calculating the price.
Attaching SQI Rules to the service quantity means manipulating or updating or making changes to Service
quantity based on business rules for pricing.

TCS Internal - ORMB Functional Understanding #22 | P a g e

 AA. Summary Rate Component: Summary Rate component is a group of components when a customer has
multiple rate components and all the Rate Components are impacting the final pricing and all need to be
applied; in that case, the summary rate component will be defined and attached for pricing. This
Summary rate component is a group of rate components. This configuration page will have multiple tabs
and each tab will validation, distributions, Characteristics, and eligibility.
BB.

TCS Internal - ORMB Functional Understanding #23 | P a g e

2.6 GL Distribution String implementation
The Chart of Accounts (COA) is the complete set of values used by the Organization to record financial transactions in
the general ledger. A chart string consists of multiple segments with a total of 25 digits. This structure assists in the
consistent posting and reporting of financial transactions. The COA records financial transactions; identifies resources
that are available for the Organization use; provides financial data for analysis and monitoring of account balances,
and allows budgeting for Organization programs. The diagram below depicts the Example segments of the
organization chart string.
Example:

Segment Definition # of digits

Entity Who? What Business Unit or Company? 4

Org What department/Divisions/Responsibility Center? 7

Natural Class What are the expenses and revenues? 9

What are the assets and liabilities?

Activity How is the money spent and received? 5

Sub-activity (Open to department use) 3

Funding Where does the money come from? 4

ORMB uses distribution codes to map sub-ledger transactions back to General Ledger accounts. As part of ORMB
setup, it is assumed that distribution codes correctly mapped to General Ledger chart of accounts.
If some of the ORMB transactions must not be integrated to General Ledger, you must configure a separate General
Ledger Division for these transactions. You must then configure the integration product to distinguish which General
Ledger Division must NOT be integrated with General Ledger.
The following table lists the major financial events, their standard accounting, and the source of distribution codes
used to
Derive the GL accounts sent to your general ledger.
Financial event GL Accounting Source Of Distribution Code Define At
Create a normal financial services bill Debit: Contract Type
segment. Bill Segment FT Algorithm is Accounts Receivables
Payoff Amt = Bill Amt / Current Amt = Amt Credit: Rate Component
Due Revenue / Taxes Payable
Create a bill for company usage. Bill Debit: Contract Type
Segment FT Algorithm is Payoff Amt = 0 / Company Usage Expense
Current Amt = 0 Credit: Rate Component
Revenue / Taxes Payable
Create a bill for charity. Bill Segment FT N/A - charity bills have no N/A
Algorithm is Payoff Amt=0 / Current Amt = effect in the GL
Bill Amt
Create a payment segment for a normal Debit: Bank Account on the Tender Source of the
financial services contract Cash or Bank Tender Control for the Payment Segment's
Tender.
Credit: Contract Type
A/R

TCS Internal - ORMB Functional Understanding #24 | P a g e

 Create a payment segment for a charitable Debit: Bank Account on the Tender Source of the
contribution contract Cash Tender Control for the Payment Segment's
Tender.
Credit: Contract Type
Charity Payable
Create a payment segment for auto-pay at Debit: Cash Bank Account on the Tender Source on the
bill completion time Auto-pay Route Type of the Auto-pay Source.
Credit: A/R Contract Type

Canceling a payment Debit: A/R Contract Type

Credit: Cash Bank Account specified by the user on the
cancel tender page. Note that this defaults to
the original tender's bank account.
Create an adjustment to levy a charge Debit: A/R Contract Type
Credit: Revenue Adjustment Type

The bottom line is as follows:

 If a bill segment has a financial effect, the distribution code to debit comes from the distribution code on the
contract type, the distribution code to credit comes from the rate component(s) used to calculate the billing
segment.
 Payment segments always have a financial effect; the distribution code to debit comes from the bank account
on the tender source of the tender control of the tender, the distribution code to credit comes from the
contract type.
 If an adjustment has a financial effect, the distribution code to debit and credit comes from the contract type
and adjustment type. If the adjustment is positive (i.e., the customer owes your organization more money),
the distribution code to debit comes from the contract type; the distribution code to credit comes from the
adjustment type. Vice versa if the adjustment is negative.

Chart of Account Segments Example

COA Values Example

Account
CO RC AC PROD GEO IC RR FUT Description
Servicing Fees Billed –
2001 7870061 180203100 61110 215 0000 000 000000
Revenue
2001 7870061 420202100 61110 215 0000 000 000000 Accounts Receivable
Value Added Tax / Sales
2001 7870061 250203120 61110 215 0000 000 000000
Tax Payable

Accounts Receivable GL Distribution String for ORMB Example

TCS Internal - ORMB Functional Understanding #25 | P a g e

 • 2001.7870061.420202100.61110.215.0000.000.000000 - Accounts Receivable String
• 2001.7870061.250203120.61110.215.0000.000.000000 - Value Added Tax / Sales Tax Payable
• 2001.7870061.180203100.61110.215.0000.000.000000 - Servicing Fees Billed – Revenue
EBS Journal Accounting Entry

CO RC AC PROD GEO IC RR FUT Debit Credit Line Description

2001 7870061 180203100 61110 215 0000 000 000000 413.00 Debit Servicing Fees Billed
2001 7870061 420202100 61110 215 0000 000 000000 333.00 Credit Service Fee Income
2001 7870061 61110 215 0000 000 000000 80.00 Credit Sales Tax Payable
250203120

ORMB Journal Accounting Entry (Billing)

CO RC AC PROD GEO IC RR FUT Debit Credit Line Description

2001 7870061 180203100 61110 215 0000 000 000000 (313.00) Servicing Fees Billed – Revenue
2001 7870061 420202100 61110 215 0000 000 000000 313.00 Credit Service Fee Income

2001 7870061 180203100 61110 215 0000 000 000000 (80.00) Servicing Fees Billed – Revenue
2001 7870061 61110 215 0000 000 000000 80.00 Credit Sales Tax Payable
250203120

TCS Internal - ORMB Functional Understanding #26 | P a g e

3. Functional Setup Manager
Functional Setup Manager is a One Stop Shop which integrated End to End Application setup and
Administration process which helps the organization to use the application with the full offering for their
day to day operations.
Following is the Life cycle of the Functional Setup Manager.

Functional Setup Manager

This Initial Setup guides you through the

1) Planning: Planning of what to implement and what offers you need for
Business and other planning’s related to Implementation,
2) Opt-in: Based on Planning what Functional offering/services/ areas we
need to opt in ‘s need to be enabled for best fits for business needs.
3) Setup: Once Planning and Opt-in are finalized, they will setup the
functionality according to opt in’s
4) Deploy: Once setup is completed and validated then these setups need to be
deployed from one environment to another environment for end users to use
the systems for their day to day operations
5) Maintain: Once setup and deployments are completed then an ongoing
basis these functionalities need to be maintained on a day to day needs

The Setup is divided into another two setups

1) Installation Setup/Options 2) Business functionality Setup

TCS Internal - ORMB Functional Understanding #27 | P a g e

3.1 Configuration and Maintenance (Installation Options)
Following are mandatory configurations on base Installation:
Main Tab:
Alternate Representation: It should be set as “none” unless the Organization uses multiple character sets for a
person’s main name

Person Tab: Identifies ID (Person, Business, Group, and Broker) options: Each form of Identification has an
Identifier type

Account TAB: Class Options: (Person, Business Account Relation Type Code)

Billing Tab: Billing segment Freeze Option: It controls when a contract's balance and the general
ledger is affected by bill segments and certain types of adjustments.

TCS Internal - ORMB Functional Understanding #28 | P a g e

 Bill Correction Option: It controls whether to use credit note or correction note

Financial Transaction TAB:

G/L Batch Code: To define the batch process that is used to interface FT with GL

TCS Internal - ORMB Functional Understanding #29 | P a g e

3.2 Configuration and Maintenance (Invoice Generation)
Following are base setup sequencing order for simple Invoice (Bill) generation:

S.no Steps Navigation Remarks

1 Account identifier type created from Admin Admin
2 Work Calendar
3 Bill Cycle Admin
4 Bill segment type needs to create Admin
5 Product Menu Pricing
6 Price list Menu
7 Business Object
8 Division created
9 Person created
10 Person Account created and bill cycle assigned
11 Customer class Menu The division should be added to customer
class control for the existing customer class

12 Distribution code
13 GL Division
14 BILL PERIOD
15 Contract type Menu Receivable Account GL dist String
16 Rate Schedule Menu
Initially in progress once attached to
17 Rate Version Menu component then this will finish
18 Rate Component Menu Revenue Account GL dist String
19 debt class Menu
20 Contract created Menu Debt class and write off class should be
defined, this will enable the Payment
processing
21 Rate Definition Rate Schedule is not visible while defining
Rate Definition

22 write-off debt
23 Manage Tiering Criteria Main Menu Navigation: Main menu  Pricing
Management Manage Tiering Criteria

Configuration workbook.

Config_Workbook.
xls

TCS Internal - ORMB Functional Understanding #30 | P a g e

 Account identifier type: Account identifier type will be created from the Admin Menu.

Work Calendar: Work Calendar every financial transaction references an accounting date and its contract.
Every contract references a contract type. Every contract type references a GL division. Every GL division
references an accounting calendar. The accounting calendar contains the cross-reference between the
accounting date specified on the financial transaction and related accounting period in your general ledger.
This will be created from Menu and below is Some Basic Setup.

Bill Cycle: Bill Cycle It defines the financial period(s) to which the bills will be booked in your general ledger.
This will be created from Admin Menu and below is Some Basic Setup

TCS Internal - ORMB Functional Understanding #31 | P a g e

 Bill segment type: This will be created from Menu and below is Some Basic Setup

Algorithms:
BSTNEFT-
bill segment algorithm for NEFT charges
BSBF-LO - Payoff Amt = Interest / Current Amt = Principal
BSGC-SP-DFT - Get bill segment consumption from SA's SP(s)
BSAXERLIME - Cancel old bill segments due to bad estimates

Product: This will be created from Admin Menu and below is Some Basic Setup

TCS Internal - ORMB Functional Understanding #32 | P a g e

 Price List Price Items Assignment

Division: Following is the sample Division page: Create other Tabs – Main – Access Group – Price Item – Price
List – other relevant to Divisions

Person: Following is the sample Person page, Enable the last checkbox for the customer – next page opens

for ID

TCS Internal - ORMB Functional Understanding #33 | P a g e

General Ledger Division: Following is the GL Division screen

Contract Type

Rate Schedule

Payment Request

TCS Internal - ORMB Functional Understanding #34 | P a g e

Account:

3.3 Configuration and Maintenance (Payment Processing)

Following are the base setup sequencing order to apply payment/simple applies for payment against
invoice or bill process:

S.no Steps Navigation Remarks

Make a sure Debit class and write off class defined in contract
1 Payment request type Admin definition
2 Payment segment type Admin
3 BANK ACCOUNT Admin
4 Tender source
5 Tender Type created
6 Deposit control
7 Tender control
8 Payment event
9 Match Type
10
11
12

TCS Internal - ORMB Functional Understanding #35 | P a g e

Payment request type

Payment segment type created

Bank Account

TCS Internal - ORMB Functional Understanding #36 | P a g e

Tender source

Tender Type

TCS Internal - ORMB Functional Understanding #37 | P a g e

Deposit Control

Tender Control

Payment Event

TCS Internal - ORMB Functional Understanding #38 | P a g e

4. Rules Engine
A rules engine executes one or more business rules in a runtime production environment. It allows you
to define, execute, and maintain these business rules separately from the application code. You can then
use these business rules in any program to facilitate operational decisions at runtime. For example, you
might use business rules in the Collection module to decide the collection strategy or in the Banking
module to derive charges codes or price items for the transaction.
A rules engine allows you to classify these rules using the rule type. It also allows you to define the
relationship between two or more rules and set the priority for each rule. When a calling program
invokes these rules using the rule type, all effective rules with the specified rule type are executed,
starting with the rule having the highest priority. For example, a rule with the priority 10 will be executed
before a rule with the priority 20. Each rule contains one or more criteria. Depending on whether the
criteria is satisfied, the system either executes the next criteria or indicates whether the rule is true or
false. The rules engine allows you to define what should happen when the rule is true or false. In both
cases, you can enforce the system to either:
• Execute any dependent rule
• Execute a rule with the same rule type having lower priority
• Return the output parameters and their values to the calling program
You can define criteria for a rule only using the input parameters that are defined for the rule type. Also,
when the rule is true, you can only return the output parameters that are defined for the rule type to the
calling programs.
Therefore, in case you want to use any field in the rule, you have to associate it with the rule type as an
input or output parameter. A rules engine also allows you to execute preprocessing and post-processing
algorithms. A preprocessing algorithm is triggered before executing any criteria in the rule. It pre-
processes the input parameters and then returns processed values against which the criteria is validated.
A post-processing algorithm is triggered after executing all criteria in the rule. It post-processes the
output parameters and returns the updated values to the calling programs or dependent rules.
Oracle Revenue Management and Billing provide you with the Rule Check utility. It allows you to validate
whether rules defined with a specific rule type get executed as expected. On validating, it indicates the
sequence in which the rules were executed, the total execution time, and displays the output parameters
of the rule that was successfully executed.
Normally, in the Transaction Feed Management feature, the transaction legs are created using the
output parameters of the rule where the criteria returns Are True and the rule true action is set to
Success. Oracle Revenue Management and Billing also enable you to accumulate the output parameters
of all rules where the criteria return Rule Is True irrespective of whether the rule true action is set to
Next Dependent, Next Rule by Priority, or Success. This accumulation process continues until a rule is
executed where the criteria return Rule Is True, and the rule true action is set to Success. Once the
output parameters are accumulated, the transactions legs are created using these accumulated output
parameters. You can enable the rule output accumulation feature for the Transaction Feed Management
module by setting the Rule Output Accumulation option type in the C1_FM feature configuration to true.
There might be situations when duplicate transaction legs are created through the rule output
accumulation process. The system enables you to indicate whether duplicate transaction legs must be
created during the transaction aggregation cycle through the rule output accumulation process. If the
Remove Duplicates from Accumulated Rule Output option type in C1_FM feature configuration is set to
true, the system does not create duplicate transaction legs during the transaction aggregation cycle.
Following are the 3 Key components need to be configured Or created part of the Rules Engine.
• Rule Type

TCS Internal - ORMB Functional Understanding #39 | P a g e

 • Rule
• Rule Check
Rule Type: Used to indicate whether you want to search rule types which are used for defining rule-based
auto pay Instructions or which are used for defining business rules for mapping transactions with the price
items.
The valid value is: • Auto Pay
A rule type can be used for defining rule-based auto pay instructions or business rules for mapping
transactions with the price items. If you want to use the rule type for defining rule-based auto pay
instructions, you must set the Rule Type Usage field to Auto Pay. However, if you want to use the rule type
for defining business rules for mapping transactions with the price items, you must leave the Rule Type Usage
field blank.

Prerequisites: To define a rule type, you should have: • Values defined for the C1_RULE_USAGE_FLG lookup
field

Defining Rule
• Input and Output Parameters - Used to define input and output parameters for the rule type.
• Rule Criteria Characteristic Entities - Used to indicate the entities whose characteristics you can use
while defining rule-based auto pay instructions using the rule type.
• Rule Criteria Derivation Algorithms - Used to attach algorithms which you want to use for deriving the
following from the financial transaction:
 Values of all those fields (such as, policy number, plan number, or price item) which are selected
in the rule type as the input and output parameters
 Characteristics of all those entities which are selected in the rule type as the rule criteria
characteristic entities

The Main section contains the following fields:

Field Name Field Description Mandatory (Yes or No)
Rule Type Used to specify the rule type. Yes

Field Name Field Description Mandatory

(Yes or No)
Rule Type Used to specify the rule type. Yes
Rule Type Usage Used to indicate whether you want to use the rule type for defining rule- Yes
based auto pay instructions or for defining business rules for mapping
transactions with the price items. The valid value is:
• Auto Pay
If you want to use the rule type for defining rule-based auto pay
instructions, you must set the rule type usage to Auto Pay. However, if you
want to use the rule type for defining business rules for mapping
transactions with the price items, you must leave this field blank.
Description Used to specify the description for the rule type. Yes
Maximum Rule Used to indicate the maximum number of rules that can be defined when No
Count the rule-based auto pay instruction is created using the rule type.
This field appears only when you select the Auto Pay option from the Rule
Type Usage list. The maximum rule count cannot be less than or equal to
zero.

Enter the required details in the Main section.

TCS Internal - ORMB Functional Understanding #40 | P a g e

5. Write Off Process
A write-off is a reduction of the recognized value of something. In accounting, this is a recognition of the reduced or
zero value of an asset. In income tax statements, this is a reduction of taxable income, as a recognition of certain
expenses required to produce the income.

When you write-off unpaid debt, you shouldn't book it all to a write-off expense account. Why? Because the debt that
you're writing off typically contains both revenue and liabilities. At write-off time, you typically want to:

 Book the written off revenue to a write-off expense account, and

 Reduce the liabilities (you don't owe the liability if you don't get paid).

Consider the following example of a simple electric contract with two financial transactions:

Event GL Accounting

A/R 1000
Revenue <900>
Customer is billed State Tax Payable - Taxing State - California <80>
City Tax Payable - Taxing City - San Francisco <20>
A/R 50
Customer is levied a late payment charge Late Payment Revenue <50>
After these two financial transactions are booked, the customer has a debt of $1050. Of this $1,050; $950 in revenue
and $100 is a liability (money you owe the taxing authorities).

If the customer doesn't pay, you will eventually have to write-off this debt. Most organizations would issue the
following types of financial transactions to do this:

Event GL Accounting

Write-off Expense 900

State Tax Payable - Taxing State - California 80
City Tax Payable - Taxing City - San Francisco 20
Write-off the bill
A/R <1000>

Write-off Expense 50
Write-off the late payment charge A/R <50>
Notice in the above transactions, the two separate revenue accounts are written off by booking to an expense
account. However, liability accounts are reversed. Why is revenue treated differently from liabilities at write-off time?
There's a good reason for it (if you're an accountant), for the time being, accept that this is how it works.

Moreover, finally, we need to worry about what happens if the customer eventually pays off his written off debt. If this
happens, most organizations will pay off the write-off first, and, if there were still money left, they'd reimburse the
taxing authorities. If we assume the customer pays off the entire written off debt, the following financial transactions
would be issued:

Event GL Accounting

Cash 900
Pay off the written off debt
Write-off Expense <900>

TCS Internal - ORMB Functional Understanding #41 | P a g e

 Cash 100
State Tax Payable - Taxing State - California <80>
Reinstate the liabilities City Tax Payable - Taxing City - San Francisco <20>

While the reinstatement of liabilities at payment time is possible in the system, the ramifications of doing such make
this approach impracticable (the ramifications are a) if the check bounces, we would not be able to reduce the
liabilities, and b) if there was a partial payment of the liabilities, the remaining unpaid amount could get written
down). Therefore, when a write-off is paid the following financial transactions should be issued:

Event GL Accounting

Cash 900
Pay off the written off debt Write-off Expense <900>

Cash 100
Reinstate the liabilities Reinstated liabilities <100>

Notice that rather than reinstating the individual liabilities, we simply reinstate all liabilities into a single account. This
means your accountants will have to distribute this money to the appropriate liabilities manually.

So, how do we achieve the above in the system? This explanation is a little complicated, but it'll make sense if you
keep the above financial transactions in mind:

 First of all, you'll need two different contract types - one to hold the written off revenue and another to hold
the reduced liabilities.
 On the contract type that holds written off revenue, indicates that it is not billable, indicate that it cannot
have excess credits, and give it a high payment distribution priority. The distribution code on this contract
type should reference your Write-off Expense account.
 On the contract type that holds the reduced liabilities, indicates that it is not billable, indicate that it cannot
have excess credits, and give it a high payment distribution priority. The distribution code on this contract
type should reference a "reinstated liabilities" GL account.

Next, you need to understand how the system's standard write-off logic works:

 The system accumulates the distribution codes from GL details associated with recent financial transactions
linked to the contract being written-off.
 When the system has accumulated enough distribution codes (i.e., where the amount associated with the
distribution code equals or exceeds the amount to write off), the debt will be transferred to a new or existing
write-off contract(s). The number and type of contracts to which the bad debt is transferred are defined on
the distribution codes. Refer to Setting Up Distribution Codes for how to define the type of write-off contract
associated with a distribution code. In our example, we'd need the two contract types described above - one
for the revenue accounts, the other for the liability accounts.
 At write-off time, for those distribution codes associated with revenue, the system will create a transfer
adjustment from the normal contract to the write-off revenue contract. This will reduce (credit) the
receivable on the normal contract and increase (debit) the expense account defined on the write-off revenue
contract.
 However, if we do the above for the distribution codes associated with liabilities, we have a problem. The
problem is a bit hard to explain unless you understand tax accounting, but it comes down to this - if we simply
transfer the portion of the receivable balance associated with the liabilities to the write-off liability contract,
we will always be debiting the distribution code defined on the contract type. This isn't correct because we
want to debit the liability account (and reference the characteristic type and value from the original credit)

TCS Internal - ORMB Functional Understanding #42 | P a g e

 when we reduce the liability. So how do we do this? For those distribution codes associated with liabilities,
you need to indicate that you want to override the distribution code on the "transfer to" side of the transfer
adjustment with the distribution code / characteristic type / characteristic value that was originally booked.
Refer to Setting Up Distribution Codes for how to indicate you want to override the distribution code at write-
off time. If you do the above, then at write-off time the transfer adjustment will reduce (credit) the receivable
on the normal contract and increase (debit) the original liability accounts from the original financial
transactions.

If you followed the above, you'd see that we now have everything debited and credited appropriately. Moreover, if a
payment materializes for the written off debt, we will simply debit cash and credit the distribution code on the
respective contract (either Write Off Expense or Reinstated Liabilities).

Following are the base setup sequencing order to apply payment/simple applies for payment against invoice or bill
process:

S.no Steps Navigation Remarks

1 Write Off Event Type
2 Write off process template Admin
3 Write Off Control Admin
4 Write Off Process This is Transaction entry

TCS Internal - ORMB Functional Understanding #43 | P a g e

TCS Internal - ORMB Functional Understanding #44 | P a g e
6. Accruals
Oracle Revenue Management and Billing enables you to calculate and create accrual for accounts. An accrual
allows an entity to record expenses and revenues for which it expects to expend cash or receive cash,
respectively, in a future reporting period. The accrual is an adjustment which is created for the following:
• Revenues that have been earned but are not yet recorded in the books of accounts.
• Expenses that have been incurred but are not yet recorded in the book of accounts.
The system also enables you to reverse the accrual for accounts. You need to define whether the accounts
belonging to a division are eligible for accrual or not. If a division is eligible for accrual, by default, all accounts
belonging to the division are eligible for accrual. However, you can exclude an account from accrual, if
required. To enable the accruals feature, you need to define the following:
• Accrual Cycle – You must specify the following information in the accrual cycle:
• Dates when accrual should be calculated and created for the accounts where the accrual cycle is
defined.
• Accrual reversal period for each accrual date.
If a division is eligible for accrual, you need to specify the accrual cycle for the division. By default, all accounts
belonging to a division will inherit the accrual cycle of the division. However, you can override the accrual
cycle of an account
• Accrual Type – You must specify the following information in the accrual type:
• Type of the accrual object that you want to create for posting the accrual amount. At present, the
product enables you to create adjustments to record accruals for accounts in the system.
• Whether you want to calculate the accrual based on the historical or actual data. If you want to
calculate the accrual based on the historical data, you need to specify the number of historical bills
that you want to consider for accrual calculation. The system will only consider the completed
historical bills during the accrual calculation. Besides specifying the historical bill count, you also
need to specify the type of day (i.e., Business Day or Calendar Day) which is used to calculate the
accrual amount. However, if you want to calculate the accrual based on the actual data, you need to
specify whether the trial bill or unbilled pass through billable charges
Created through the Transaction Feed Management process should be considered to calculate the accrual
amount.
• Whether you want to calculate accrual at the bill or bill segment level.
• Cancel reason that you want to use while reversing the accrual
• Algorithms that you want to use during the accrual calculation, creation, and reversal
• Whether any objects, such as adjustments created using a particular adjustment type, bill segments
created for a particular price item, or adjustments’ or bill segments’ financial transactions where a
particular distribution code is used, must be excluded during the accrual calculation.
• Divisions to which you want to associate the accrual type. The accrual process includes the following
sub-processes:
• Accrual Calculation – In this process, accounts that are eligible for accrual will have its accrual
amount calculated by the accrual type configuration.
• Accrual Creation – In this process, by the calculated accrual amount and information configured on
the accrual type, the accrual adjustment will be created.

TCS Internal - ORMB Functional Understanding #45 | P a g e

 • Accrual Reversal – In this process, reversal of accrual adjustments will be done to prevent double
posting of revenue, once billing is done. By the accrual reversal schedule, an account with accrual
adjustments will be selected for accrual reversal processing. For every frozen adjustment, a
cancellation is done to reverse journal entries. During the accrual process, an accrual goes through
various statuses in its lifecycle. You can execute the accrual process either using user interface (UI),
or batch. For more information about the accrual statuses, see, Accrual Created through UI (Without
Approval Workflow) Status Transition
Accrual Created through UI (With Approval Workflow) Status Transition, Accrual Created through Batch
(Without Approval Workflow) Status Transition, and Accrual Created through Batch (With Approval
Workflow) Status Transition
Note: The lifecycle of accrual is driven by the business object using which the accrual is created. An accrual
business object named C1_ACCRUALS is shipped with the product. The accrual feature explained in this
document is articulated based on the lifecycle and logic defined in the C1_ACCRUALS business object. The
following figure graphically indicates how an accrual created from the user interface moves from one status
to another when the approval workflow is off.

TCS Internal - ORMB Functional Understanding #46 | P a g e

7. Transaction Feed Management
Oracle Revenue Management and Billing’s ‘Transaction Feed Management (TFM)’ system enables the
processing of transactions covering details of product usage by Customers. This process involves
importing product charges and SQI calculation from transaction data received into the system by
executing batch programs.
While processing the batches, if any configuration is changed then run ‘Disaggregation’ batch for all
transactions.
ORBM provides various controls on batch processing.
• Rollback Batch - This is an optional batch and is required to be run when you want to rollback ERROR
or IGNR transactions To UPLD.
• Flush All Batch - This batch clears complete application cache. This is a single-threaded batch.
• Header Validation Batch - This batch validates header of the transactions
• Initial Product Determination Batch - Validate the batch processing for Products and Pre-Validations
• Product Pricing Verification Batch - This batch derives price assignment for each of the Account Id –
Product – TOU combination.
• Update Status Batch -This is error handling batch which marks the transactions in error or ignores
status if the pricing is not available or ignore switch is Y respectively.
• SQ Calculation Batch - This batch checks for SQIs configured and calculated the SQ for a given
frequency.
• Mark Completion Batch - This batch marks the transaction either into COMP (i.e., COMPLETE) or
ERROR (i.e., ERROR) status if the transaction has been processed successfully by all the batches or
failed during SQI calculation batch respectively.
• Clean Up Batch -This batch is used to clean up or recalculate the billable charges if the transaction is
marked in ERROR while running the C1-TXNCM batch. This batch is mandatory to run.
• Billing Batch - The bill cycle process creates bills for accounts with an "open" bill cycle.

Batch Sequence Batch Control Description

2.1 C1-TXNRB Rollback Batch

2.2 F1-FLUSH Flush All Batch

2.3 C1-TXNHV Header Validation Batch

2.4 C1-TXNIP Initial Product Determination Batch

2.5 C1-TXNVP Product Pricing Verification Batch

2.6 C1-TXNEX Update Status Batch

2.7 C1-TXNSQ SQ Calculation Batch

2.8 C1-TXNCM Mark Completion Batch

TCS Internal - ORMB Functional Understanding #47 | P a g e

 2.9 C1-TXNCU Clean Up Batch

2.10 BILLING Billing Batch

2.11 C1-DISTG Disaggregation Entry Batch

2.12 C1-TXNDA Disaggregation Batch

2.13 C1-TXCNC Cancellation Batch

Batch Execution Sequence

Following Sequence must be followed when you run the TFM batch.
• For aggregation, run the batches from 2.2 to 2.8 (F1-FLUSH, C1-TXNIP, C1-TXNVP, C1-TXNEX, C1-TXNSQ, C1-
TXNCM, C1-TXNCU) in the sequence.
• For rollbacking the ERROR or IGNR transactions, run the 2.1 (C1-TXNRB) batch. It will change the transaction
status to “UPLD” status.
• For disaggregation, run 2.10 to 2.11 (C1-DISTG, C1-TXNDA) batches together in sequence.
• For cancellation of the transaction, run 2.12 (C1-TXCNC) batch. After running cancellation, run the all the
batches for aggregation from 2.2 to 2.8 (F1-FLUSH, C1-TXNIP, C1-TXNVP, C1-TXNEX, C1-TXNSQ, C1-TXNCM,
C1-TXNCU) in the sequence. This batch can be run at any point in time.
• Do not run any batch twice in the sequence. If any batch is run twice, then please run the disaggregation
batch for all the transactions. This should be followed by complete aggregation process 2.2 to 2.8 (F1-FLUSH,
C1-TXNIP, C1-TXNVP, C1-TXNEX, C1-TXNSQ, C1-TXNCM, C1-TXNCU) in the sequence.
While running the batches, if any configuration is changed then run the disaggregation batch for all the transactions

TCS Internal - ORMB Functional Understanding #48 | P a g e

8. Case Study
Following is the Case study for Lab Practice.

ORMB Sample Case

study and Model lab sessions.pptx

TCS Internal - ORMB Functional Understanding #49 | P a g e