AIM

BP.080 FUTURE PROCESS MODEL

Bausch & Lomb Eyecare India Pvt. Ltd
General Ledger

Author: Srinivas Jorige

Creation Date: September 10, 2005
Last Updated: September 10, 2005
Document Ref: BP040.GL1.2-B&L
Version: 1.0

Approvals:

Sandeep Arora

Anand Aluru
BP.080 Future Process Model Doc Ref: Error: Reference source not found
Error: Reference source not found

Document Control

Change Record
1

Date Author Version Change Reference

10-Sep-05 Srinivas Jorige Draft 1a No Previous Document

Reviewers

Name Position

Harsh Basal, Sunil Sharma ERP Core Team

Anand Aluru Project Manager – Satyam

Distribution

Copy No. Name Location

1
Library Master Project Library
2 Anand Aluru Project Manager
3
4

Note To Holders:

If you receive an electronic copy of this document and print it out, please write your
name on the equivalent of the cover page, for document control purposes.

If you receive a hard copy of this document, please write your name on the front
cover, for document control purposes.

General Ledger Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. Error: Reference source not found)
Company Confidential - For internal use only
BP.080 Future Process Model Doc Ref: Error: Reference source not found
Error: Reference source not found

Contents

Document Control...................................................................................................................ii

Event Catalog...........................................................................................................................1
General Ledger..................................................................................................................1
Process Listing and Process Descriptions............................................................................2
General Ledger..................................................................................................................2
Journal Process..................................................................................................................3
Budgeting...........................................................................................................................4
Journal Approval..............................................................................................................5
Revaluation Process.........................................................................................................6
Period Close Process........................................................................................................7
Function Hierarchy..................................................................................................................8
General Ledger..................................................................................................................8
Process Step Catalogs..............................................................................................................9
Journal Process..................................................................................................................9
Budgeting...........................................................................................................................9
Journal Approval............................................................................................................10
Revaluation Process.......................................................................................................11
Period Closing Process..................................................................................................11
To-Be Activities......................................................................................................................12

Open and Closed Issues for this Deliverable....................................................................30

Open Issues......................................................................................................................30
Closed Issues...................................................................................................................30

General Ledger Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. Error: Reference source not found)
Company Confidential - For internal use only
 Doc Ref:

Event Catalog
This component lists all events to which the business responds.

General Ledger

Event ID Name Type Description Frequency

GL.E.1.0 CSN Transactions Internal Transaction entered for CSN transactions As and when required
GL.E.2.0 Month End Provisions Internal Provision journals entered in the application As and when required
GL.E.3.0 Journals from the feeder Internal Journals imported from the feeder modules such Periodically
modules as AP, AR, INV and FA
GL.E.4.0 Reversal Journal Internal Reversing the journals of the previous periods Monthly
GL.E.5.0 Operation Plan Internal Preparation of Operation plan Periodically
GL.E.7.0 Approval of journal Internal Journals approved required for the JVs entered in As and when required
the system
GL.E.8.0 Month end Closing Internal Closing the books of accounts Monthly
GL.E.6.0 Month end reporting Internal For month balances reporting Monthly
balances

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Process Listing and Process Descriptions

General Ledger

Process ID Event Process Title Description of Process Output

GL.P.1.0  Journals from Journal Process This process would describe the complete journal Journal are entered in the
feeder modules entry cycle from entering the JV, approval and general ledger and
 Month End posting the journals. approved as per the
Provisions authority matrix and posted.
 CSN Transaction
 Reversal
Journals
 Outsourced
services journals
GL.P.2.0  Operation Plan Budgeting Process Budgeting Process The approved budget would
be entered in the system and
subsequently forecasts
prepared
GL.P.3.0  Approval of Journal Approval Journal Approval Process Journal approval as per the
journal authority matrix
GL.P.4.0  Monthly Revaluation Process The revaluation process would revaluate the Foreign currency balances
Reporting foreign currency denominated balance in to the revaluated
equaling functional currency amounts using the
revaluation rate specified.
GL.P.5.0  Monthly closing Period Closing Period Closing The general ledger period
would be closed

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Journal Process

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Budgeting

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Journal Approval

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Revaluation Process

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Period Close Process

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Function Hierarchy

BLEIPL Function Owner: Date:

Function: General Ledger Sandeep Arora 01-Dec-05
Description:
General Ledger

General Ledger

Function
ID # Function Description Function Owner Type Notes

GL.F.1.0 Journals Finance Manager

GL.F.2.0 Budgeting and forecast preparation MIS analyst
GL.F.3.0 Revaluation of balances MIS analyst
GL.F.4.0 Period closing Finance Manager/MIS analyst
GL.F.5.0 Financial reporting Finance manager
GL.F.6.0 MIS reporting MIS analyst

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Process Step Catalogs

Journal Process

ID Description Frequency Notes Agent Automation

GL.P.1.1 Import journals from the feeder modules Periodically The journals would be imported from the feeder Finance Manager and MIS executive Computer
modules Aided
GL.P.1.2 Create journals for month end provisions and outsourced On need basis Month end provisions would be created Finance Manager / CNS outsourced Computer
services agent Aided
GL.P.1.3 Generate reversal journals Monthly Reversal journal would be generated which were Finance Manager Computer
marked as reversal in the previous period. Aided
GL.P.1.4 Review the journals in journals workbench On need basis Finance Manger Manual
GL.P.1.5 Submit journals for approval Always The sub process of the journal approval would be Finance Manager Computer
submitted Aided
GL.P.1.6 Journal Approval Process Always It will undergo the approval process as per the Finance manager Automated
approval authority
GL.P.1.7 Mark journals fro reversals if the same is for provisions On need basis Any journals, which are to be reversed in the next Finance Manager Manual
month, would be marked.
GL.P.1.8 Get the journal voucher printed Always Finance Manager Manual
GL.P.1.9 Post the journal Always Posting the journal updates the balances of the Finance manager Computer
accounts Aided

Budgeting

ID Description Frequency Notes Agent Automation

GL.P.2.1 Define the master budget for the year Periodically As per the approved operation plan a master MIS analyst Manual
budget in oracle general ledger would be
defined
GL.P.2.2 The range of accounts to which budgetary control is Periodically With this the budgetary organization would MIS Analyst Manual
specified would be identified be defined
GL.P.2.3 Budgetary controls would be defined for the budget On need Budgetary controls such as none, advisory and MIS Analyst Manual
organization basis absolute would be defined
GL.P.2.4 The budget worksheet would be uploaded into oracle On need This would be done using the ADI utility MIS analyst Computer
general ledger basis Aided
GL.P.2.5 Review the budget journals imported through ADI Always MIS analyst Manual
GL.P.2.6 Post the budget journals imported and reviewed Always MIS analyst Computer
Aided

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

ID Description Frequency Notes Agent Automation

GL.P.2.7 Define the forecast Periodically The forecast would be prepared basing on the MIS analyst Manual
3+6,6+6 and 9+3 intervals
GL.P.2.8 Upload the budget and post the budget journals Always MIS analyst Computer
Aided
GL.P.2.9 Run the budget vs. actual analysis On need These reports would be designed to compare MIS analyst Computer
basis the budgets and forecast with the actual Aided
balances for the period

Journal Approval

ID Description Frequency Notes Agent Automation

GL.P.3.1 Define the employee and supervisor relationship On need basis This hierarchy would be defined in the HRMS Finance Manager Computer
module Aided
GL.P.3.2 Specify the approval limits for each user in the hierarchy On need basis Finance Manager Computer
Aided
GL.P.3.3 The journal approval process would be submitted Always This process verifies the approval authority of the Finance Manager Automatic
user submitting the journal for approval and
accordingly routes the notification
GL.P.3.4 Notification is sent to the employees as per the hierarchy Always Finance Manger Automatic
GL.P.3.5 Journal gets approved as per the authority matrix Always Finance Manager Computer
Aided
GL.P.3.6 Approved journals would be available for posting Always It will undergo the approval process as per the Finance manager Computer
approval authority Aided

Revaluation Process

ID Description Frequency Notes Agent Automation

GL.P.4.1 Update the currency master Monthly Define the period end rates for the purpose of Finance Manager Computer
revaluation Aided
GL.P.4.2 Run the unrealized gain/loss report in sub ledgers Monthly The sub ledger reports provide the effects of the Finance Manager Computer
revaluation process Aided
GL.P.4.3 In General Ledger, specify the accounts to be revalued Monthly The accounts specified in the revaluation would be Finance Manager Manual
considered for this process

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

ID Description Frequency Notes Agent Automation

GL.P.4.4 Run the process of revaluation in general ledger Monthly Finance Manger Computer
Aided
GL.P.4.5 Mark the revaluation journal created by the system for Always This journal should be reversed automatically in Finance Manager Computer
reversal the next period Aided
GL.P.4.6 Post the revaluation journal Always This would updates the foreign currency balances Finance manager Manual
and the same would be used for reporting

Period Closing Process

ID Description Frequency Notes Agent Automation

GL.P.5.1 Complete the interfaces of all feeder modules and external Monthly This process would be repeated till all the journals Finance Manager Computer
systems imported to GL Aided
GL.P.5.2 Close the sub ledger period in the sequence mentioned the to Monthly Finance Manager Manually
be activities
GL.P.5.4 Run the process of revaluation in general ledger Monthly As explained above, this process revaluates the Finance Manger Computer
foreign currency balances Aided
GL.P.5.3 Post all pending journals I.e. journals from the feeder Monthly This would update the balances of the accounts Finance Manager Computer
modules and journals directly entered in GL Aided
GL.P.5.6 Change the general ledger period to ‘Close’ Monthly As the GL period is closed, no additional journals Finance manager Manual
would be entered in applications for that period

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

To-Be Activities

This component provides details of the activities to be carried out as part of the
process flow.

With a view to replace the disparate systems being currently in use and centralize
the financial, Distribution and manufacturing applications across the organization,
Bausch & Lomb Eyecare India Pvt. Ltd is in the process of deploying Oracle
financials, Oracle Distribution and Oracle manufacturing suits of Oracle
applications.

Having understood the current business processes and desired requirements of

BLEIPL as stated in Current Process model, this Future Process model document
aims at presenting the processes to be adopted exploiting the functionalities
supported by the General Ledger module.

Terminology Used:

Terms used in the convention GL system and as referred in Oracle General Ledger
may be different. Hence, a brief explanation of the ‘Oracle General Ledger’
terminology is provided. These terms are used in Oracle applications and have been
used in documenting ‘Future Process Model’ and are recommended that various
users of the system get acquainted with the same.

Accounting flexfield is the code used to identify a general ledger account in an oracle
financial application. Each combination of accounting flexfield values represents a
single account.

Chart of accounts the combination of various segments used to form part of

accounting flexfield, which is shared across all the modules.

Calendar is the accounting period of the company, which comprises of different

accounting periods.

Functional currency is the currency used by the company for its operations.

Set of books is the combination of chart of accounts, calendar and functional

currency, which decides the various functionalities of general ledger.

Budgetary Control is the process of recording the budget data and tracking the actual
balances against budget balances.

Funds Checking is the feature of budgetary control that helps checking the funds
available online before processing the transaction. Depending on the level of
controls, budgetary control facilitates overspending of budgets.

Recurring journals are defined facilitates creation of journals of repetitive nature.

Financial Statement Generator is the report-writing tool of oracle general ledger that
enables users to define and maintain custom reports with out programming.

Value Sets determines the attributes of the segment and the repository of the
segment values.

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Configuration of General Ledger

The financial impact of all transactions is stored in a Set of Books in general ledger.
Set of books is the combination of

 Chart of Accounts

 Calendar

 Currency

Two sets of books would be defined for BLEIPL, one for statutory purpose and the
other for MIS reporting. The rationale of defining two sets of books is the accounting
period for statutory books is month where as the accounting period for MIS follows
4/4/5 pattern.

Chart of Accounts

The following factors considered for designing the chart of accounts for Bausch &
Lomb Eye care India Pvt. Ltd

Chart of account structure is designed in line the budgeting requirements.

Management Information Systems reporting requirements

Statutory reporting requirements

Future Requirements

In the view of the above, the following chart of accounts structure has been
proposed to BLEIPL, which represents various business dimensions:

 Company

 Cost Center

 Account

 Line of business

 Product

 Future Use

For entering any transaction, it is mandatory to select values combination from all
the segments. General Ledger reporting can be done at each of the segments.

Company:

This segment represents the company values of BLEIPL. General Ledger uses this
segment to balance the debit and credit for all journals. This segment would be
qualified as ‘Balancing Segment’ and would be 2 in character size.

Cost Center:

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

This segment represents the various cost centers being identified for BLEIPL. The
values defined would facilitate generation of cost center wise report. This segment
would be qualified as ‘Cost Center’ and would be 4 in character size.

Account:

This segment represents the actual financial accounts. Hierarchical design of the
account segment value would facilitate reporting at the desired levels. This would
be qualified as ‘Natural Account’ segment and would be 6 in character size.

Line of Business:

This segment represents the various lines of businesses of BLEIPL such as vision
care, surgical and CSN. Under CSN line of business, detailed values would be
defined to facilitate center wise analysis and would be 3 in character size.

Product:

This segment represents the various brands that are currently being used by
BLEIPL. This facilitates tracking the expenditures such as marketing and
distribution expenses brand wise and would be 4 in character size.

Future Use:

This is a buffer segment defined for the future use of BLEIPL. This is to capture any
additional dimension that might arise in future. This segment would be 4 in
character size.

Calendar:

Monthly calendar would be defined for statutory set of books starting for April to
March with one adjusting period. For MIS books, 4/4/5 pattern calendar would be
defined with one adjusting period in the year-end. An adjustment period at the end
of the fiscal year is required to facilitate year-end and audit adjustments. The
naming convention of the periods would be MMM-YY (Apr-05). The process for
controlling of periods is discussed subsequently in the document.

Currency:

The functional currency for both the sets of books would Indian Rupee (INR).
However, Transactions can be entered in any currency with the relevant exchange
rate with INR.

Journal Process:

Journal entries in oracle general ledger would arise out of the following:

Outsourced services entries like salary processing

Transactions entered in CSN centers

Month end provisions in MIS books

Reversal journals of previous periods

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Journals imported from feeder modules such as AP, AR, FA, PO and INV

Journal Approval:

The journals entered in General Ledger and imported from the feeder modules can
be subjected to an Approval process before being posted if required. Specific
employees could be provided approval limits in equivalents of Functional Currency
Value. However, as mentioned earlier this approval limit is not based on Natural
account or based on Journal Total. The approval limit is validated with the highest
journal line value and if the line value is within the approval limits, the whole
journal can be approved irrespective of the account being impacted and the total
value of the journal batch.

The following Journal approval process is suggested for BLEIPL.

Journals from Feeder Modules will not be subject to any approval in General
Ledger. This is due to the fact that all the feeder module transactions will be
approved in the respective module itself and additional approval in General
Ledger will not result in any value addition. All journals created manually in
General Ledger (Identified by the Journal Source) will be processed through an
approval action. The routing of the journals would be based on the Employee-
Supervisor relation

Every journal entered in the system should be duly approved as per the authority
matrix. Journal approval process would be enabled in the system. Any journal batch
exceeding an amount of 0.25 millions dollar equaling Indian rupee amount would
be notified to GM-Finance for approval. The user entering the journal can approve
the journal batch if the same does not exceed the amount specified above. However,
the journal posting access would be restricted as per the security matrix.

Journal Import:

Journal import process should be invoked to import the journals from the feeder
modules. Wherever possible in the sub ledgers, it would be set as ‘Automatic
journal import’ and hence no separate step to be performed for the same. However,
Journal entries from Inventory module would be an exception for automatic journal
import. In such case, journal import process should be performed in general ledger.

CSN Transactions:

It is identified that no supplier balance would exist at CSN centers as the purchases
made by CSN are charged off. These transactions would be entered as a journal in
oracle by respective CSN centers. The journal entry for these transactions would be
as follows:

Expense account Dr

CSN Imprest cash Cr

For any valid reasons, if the CSN centers are not given access to Oracle and continue
with the legacy, these transactions would be sent to HO by CSN centers in the
specified excel format. This would be uploaded in oracle using ADI (Application
Desktop Integrator)

Similarly, all collections transactions would be entered as a journal in Oracle.

Inventory transactions are interfaced with the PMS software, which used at CSN

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

centers and this section would be discussed in detailed in Inventory future process
model.

Month End Provisions:

Month end provisions would be entered on a monthly basis in MIS books. In

statutory books, provisions are made at the year-end. The basis of arriving at the
provision amounts would be discussed in detailed in the respective sub ledger
future process model. Journal entries for the provisions should be marked for
reversal in the next month.

Accruals and provision entries can be classified into two parts viz. Automatic
creation of accruals and manual creation of accruals. In the case of transactions from
Procurement application where an expense/liability has to be recognized on receipt
of goods/service, system would automatically create such accrual entries based on
creation of GRN in the system.

However, other provisions and accruals would have to be manually passed based
on calculations performed outside the system. Alternatively, recurred journals could
be defined for such accruals if the accrual amount is either fixed or can be derived
based on a formula or value stored in the system. The majority of the accrual entries
are passed through ADI (Application Desktop Integrator).

Reversal Journals:

Journals entered in Oracle General Ledger can be reversed on need basis in any of
the future periods. Few of the journals, which are created by the system, are
automatically marked for reversal for the next period as a standard functionality.
E.g. Period-End accrual journals for expense item purchases, Revaluation Journals.
Where manual journals need to be reversed, it could be either achieved by defining
an Auto reversal criteria based on Journal Categories or by manually generating the
reversal journal.

In order to create reversal journals, the original journal, which needs to be reversed,
should exist in the system. The period in which the journal has to be reversed
should be of status Open or Future.

To generate reversal journal, the original can be marked for reversal at the time of
creation itself by specifying the period in which it has to be reversed and the
method of reversal viz. Changing of Debits to Credits and vice versa or changing
the signs of the amount from Positive to Negative and vice versa. Alternatively, the
original journal can be queried subsequently and then marked for reversal

The reversal journals can then be generated either from the journal entry form itself
or through a separate form where journals pending reversal can be queried and
reversal journal created or through a scheduled program to automatically generate
reversal journals based on the period reference.

The description of the reversal journal would be automatically entered as the

reversal journal with the original journal reference. The reversal journal would
belong to the same category as the original journal.

Where certain adjustment entries are entered as part of the month closing review
process, the same will have to be marked for reversal if required and the reversal
JVs generated.

Entries from outsourced services:

Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

The transactions services such as salary processing, which are outsourced would be
entered as a journal in General Ledger. A consolidated journal for the salary
payments would be entered using ADI as the outsourced agent maintains the
employee wise details. However, where ever employee wise details required for
certain transactions like imprest account would be maintained in Accounts Payable
and would be detailed in AP future process model.

Journal Posting:

The journals entered in General Ledger and imported from the feeder modules will
be posted as detailed below

Accounts Receivable: Posting will be at detail level. Account code wise distribution
will be available in AR. Journal Entries Report in AR by Posted date will provide
detailed distributions. Journal import should also be submitted along with the GL
Transfer.

Accounts Payable: Posting is suggested at detail level with audit mode, which will
ensure transfer of transaction references to the General Ledger. Posted Invoices and
Posted Payments reports of AP will provide detailed distributions for a given date
range with GL batch details. Journal import should also be submitted along with the
GL Transfer.

Inventory: Posting should be at summary level. The details will be maintained in

the Inventory module and can be reviewed using ‘Material Account Distribution
summary/detail report. This report can be generated for every independent GL
batch. Periodically, these journals would have to be imported using the Journal
Import function of GL.

Purchasing: Posting of journals for receiving transactions will be done automatically

for each transaction. Encumbrance entries will be set to post automatically. Period
end accrual journals would have to be imported after generation of such accruals in
Purchasing through automated program.

Fixed Assets: Journals will have to be created through a standard process, after
running final depreciation. These journals will be automatically grouped based on
the transaction type and distinct account code and transferred to General Ledger.
They can be reviewed subsequently and posted in General Ledger.

General Ledger: Journals will be entered in General Ledger in a batch mode and
posting will also be done on a batch basis after appropriate approval. It is suggested
that standard batch naming conventions be followed to facilitate easy identification
of journals by the creator/by date or any other convention.

Revaluation Process:

Revaluation is the process of restating the balances arising out of Foreign Currency
transactions in the Balance Sheet accounts in tune with the current exchange rates
instead of the original transaction’s exchange rates. This is performed to comply
with the IAS requirements.

In Oracle Applications, the Revaluation process is primarily performed in General

Ledger. This process would automatically restate the Foreign Currency balances
based on the Period-End exchange rates defined in the system for the chosen period.

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

This Revaluation process also calculates the Unrealized Exchange Gain/Loss based
on the Period End exchange rates and the exchange rate used in the open
transactions.

On completion of the revaluation process, the system generates a Journal Entry in

the currency whose balances are being revalued with source and category as
Revaluation. The accounts whose balances are being revalued will be
debited/credited for the net difference in the functional currency balance and the
compensating entry would be passed to the Unrealized Gain/Loss account. In all
the revaluation Journals the Foreign Currency value would be zero while the
exchange difference would be accounted in the Functional Currency.

As mentioned earlier, the Revaluation is performed in General Ledger only and it

does not restate the balances against each of the transactions that are being revalued
in the Feeder Modules. Hence, to the extend of revaluation, there would be
difference between the total of open transaction balances in the feeder module and
the underlying account balances in the General Ledger (subject to no entries are
processed into these designated accounts from other sources)

However, each of the feeder modules (AP and AR) provides an Open Items
Revaluation Report to report the revalued balances against each open transaction.

Chart of Accounts Maintenance

All the valid values for each segment of the Chart of Account would be held in an
Independent Value Set. This will ensure that the values entered during transaction
entry are valid values and are controlled by a separate master and users will not be
able to enter any value which is not pre-defined in this master, while recording
transactions. Access to this Value Set values master would be controlled and only
few users would be able to define new values in a value set.

Before a new value is created in the system, all the pre-requisites that are manual
and hence performed outside the system such as Request for a new value creation,
workflow based authorization by an appropriate authority

Assign an appropriate Code to the new value required in alignment with the code
conventions followed for the segment. Ensure that the new code is with in the
appropriate range of accounts to facilitate easier maintenance of various range-
based rules such as Cross Validation, Parent - Child relationship, budgetary control
etc. For each value, record the code and the description on the system along with
the other applicable profiles such as Whether Posting is Allowed/Budgeting
allowed etc. Where the new value to be created is similar to an existing value, query
the same and use the copy function to create a new value.

In case of new nominal to be added, also specify the account type as to whether it is
an Asset/Liability/Owner’s Equity/Revenue/Expenditure based on the nature of
the account.

Attach the new value to the appropriate Parent value. This would be automatically
achieved, where a range based relationship is followed.

Access controls would be put in place to ensure that the chart of accounts master is
updated by only designated few users.

Currency Master:
Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Oracle Financials provides a seeded list of all ISO currencies as part of the system.
However, the required currencies in which transactions are expected to be
accounted, needs to be enabled at each of the installation, so that those currencies
can be used. Similarly, where required new currencies could also be defined with
other relevant information. This process covers the activities to be performed as part
of the currency master configuration and maintenance.

If the new currency code to be created is part of the ISO Currency, query the
relevant currency code, update all relevant information such as Precision, Minimum
accountable unit and enable the currency for usage.

In case of Non ISO Currency code to be defined, enter the appropriate currency
code and all other information and then enable the same for usage.

In case of Euro Currency or Euro derived currency, select appropriate currency

derivation type

In case of Euro derived currency, enter the derivation factor and the effective date
from when the derivation factor would be effective.

Access controls would be exercised to ensure that only select users can
enter/amend records in the currency master.

Exchange Rate Master:

Indian Rupee is the functional currency of the Bausch & Lomb Eyecare India Pvt.
Ltd BLEIPL uses different types of exchange rates such as Corporate and BOE Rate
for currency conversion while transacting in foreign currencies. The daily exchange
rates for each currency to INR and vice versa are defined as part of the exchange
rate master and maintained. This process discusses the activities involved in
updating the exchange rate master and all other related activities.

In order to update the exchange rate masters for various currencies, the currencies
should have been enabled in the Currency Master and the exchange rate
information (one way) should have been computed outside the system. These rates
could be computed based on various sources such as rates published by Agencies
like Reuters, Rates given by the Bankers etc.

The different types of exchange rates used by the BLEIPL should have been defined
as Conversion Types in the system.

The daily rates would be entered in the system manually for a date range or for a
specific date.

Once an Exchange Rate is uploaded into the system, users with appropriate access
rights can subsequently amend these rates. However, these amendments would
only have prospective effect and would not affect transactions already entered using
the specific date’s exchange rate.

There would be no system-based controls in this Exchange Rate Master process.

However, Manual controls should be exercised to perform sanity checks.

Calendar maintenance

One of the important dimensions of accounting in Oracle Financials is the

accounting Period. These Financial periods are defined as part of the Financial
Calendar and these calendars are unique for each Set of Books.
Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

The Financial Calendar defined in the General Ledger and attached to the concerned
Set of Books would be shared by all the feeder modules, which are linked to this Set
of Books. Balances are held in General Ledger only by the Financial Periods defined.
Hence, the all the feeder modules would share the monthly calendar attached to
statutory books.

The master Fiscal calendar would be defined as part of the initial system
configuration. When needed, additional periods can be added to the calendar
subject to the design in terms of Number of Periods per year.

Appropriate naming convention would be followed while defining calendar

periods.

The access to the Calendar definition would be controlled. Once defined, this
calendar is shared across modules, which share the same Set of Books. The calendar
definition is different than the period status control (Opening/Closing of periods),
which is controlled by the respective modules.

Other Masters Configuration

Security Rules:

Security Rules helps controlling of Access to certain segment values for data entry
and also inquiry. Appropriate Security Rules would have to be defined as part of
the production set-up and attached to the relevant responsibility to prevent users
with the responsibility from recording transactions or inquiring transaction lines
with the controlled segment values.

Security rules would be configured for BLEIPL to restrict the unauthorized

access to the segment values by various CSN centers and for the users as per the
responsibility matrix

Cross Validation Rules:

Cross Validation Rules help in defining the relationship between various segment
values of the Chart of Accounts Structure. Cross validation rules are defined at the
COA Structure level and is applicable to all set of books using the same COA
Structure. Hence, the cross validations rules defined, would be effective for both
Statutory and MIS books.

To ensure that invalid combinations does not get created from transactions,
extensive Cross Validation Rules would have to be defined prior to commencement
of transaction recording in the system.

To facilitate ease of definition and maintenance, it is necessary to ensure that the

segment values follows a proper range based on their nature.

Whenever a new account code combination is being created, system would validate
the same against the Cross validation rules defined as above.

Both Security rules and Cross Validation rules would have to be defined with a
Global include first (allowing access to all values) followed by specific exclusions.

Document Sequencing:

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Document sequences uniquely numbers each document generated by oracle

applications. Document sequences can be implemented at both general ledgers and
as well as at feeder modules where ever applicable. The document categories on
which the document sequences defined vary across the modules. In General Ledger,
journal category is the document category. The sub ledger document categories and
sequences would be detailed in the respective modules.

Automatic document sequencing would be enabled for journals in General Ledgers

and would be a 1 up numbering. Additional user defined journal categories would
be defined on which the document sequencing would enabled such as BL Payroll,
BL Provisions and BL conversion etc.

Document sequences would have a start date of 01-Jan-06 for BLEIPL and month
wise document sequences would be followed. It is suggested that month wise
document sequencing would cause for maintaining the sequence master but BLEIPL
would like to maintain the sequence numbers on the monthly basis for easy
identification of the transactions by the voucher number. The sequence numbering
convention would have first two digits representing year and the next two digits
represent the month like YY-MM-00001.

However, document sequences would be enabled for the conversion journals and
would follow a separate sequence. Sequencing for conversion would be enabled in
General Ledger only and not in any feeder modules.

Reports

The General Ledger module of Oracle Applications provides various standard

reports to facilitate analysis of balances and transactions recorded or transferred to
General Ledger. Additionally few bespoke reports are also being developed both for
transaction analysis and exception reporting.

Additionally, the online enquiry functionality as provided by Oracle Applications

could also be used where felt relevant. These enquiries facilitate drilling down
online to the source transactions in majority of transactions where the transaction
originates from the Feeder Modules of Oracle Applications.

In the case of reports from Oracle Applications, these reports can be scheduled to
run on a given date or on specified frequency. Those reports, which are Date
Parameter based, could also be scheduled to increment the date parameter values
supplied in alignment with the report submission schedule.

However, those reports, which are based on GL Periods or Period Ranges, do not
facilitate automatic changing of period names based on the schedule. Where reports
need to be generated for different periods, they need to submit manually at the end
of the concerned period. Similar reports where parameters could be shared can be
grouped and a request set can be defined and submitted together. Many of the
General Ledger reports including the reports defined using Financial Statements
Generator based reports would provide data subject to access controls as defined by
Security Rules on segment values.

The design for the bespoke reports as listed in the requirements document and
subsequently agreed upon are documented in the High Level design document for
the Bespoke Requirements with the appropriate deliverable IDs.

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

During submission of the reports, the User to whom a notification has to be sent can
be defined and intimation to the effect of completion of the report along with the
access path would be intimated to the User as part of his Applications workflow
notification. This notification would not be sent by an MS-Outlook mail.

The reports could be copied to the desktop and saved. Where majority of the reports
in General Ledger are submitted through the ADI function, they could be saved as
an MS-Excel file and distributed.

Financial Statement Generator:

General Ledger provides a user-friendly report tool called Financial Statements

Generator (FSG) to generate any of the Financial Statements with desired grouping
of accounts and balance columns.

The FSG Reports could be defined as and when needed and these reports would be
reporting on the account balances (Actual, Budget and Encumbrance) held in the
system. These balances are held as per the GL Accounting Calendar which is month
based. Hence any of the reports through FSG would be period based and would not
be on date range basis.

Each of the FSG Report could have the following components

Row Set: Represents the rows required in the report. This is a mandatory
component and normally used for assigning account ranges whose balances are to
be reported.

Column Set: Represents the columns required in the report. This is a mandatory
component and normally used for assigning the Balance Types, period and currency
reference of the balances that need to be reported against the accounts assigned as
part of the Row Set.

Content Set: Represents the contents of the report and is a further definition of the
Row Set. This is an optional component and is used where separate reports with
same parameters are to be taken for different segment values say Profit & Loss
report by each cost centre where the format and account codes are the same and the
Cost Centre values would keep changing for each report.

Display Set: Controls the columns and rows whose values are to be displayed or not
to be displayed. This is an optional component.

Row Order: Controls the order in which the rows are displayed and also facilitate
the display of segment values and descriptions whose balances are being displayed.
This is an optional component.

On completion of the report components, reports could be defined by establishing

the relationships with the various report components. These reports could be then
submitted through the Financial Statements submission) with appropriate
parameters such as the Period name etc. to provide the desired output.

The FSG Reports automatically inherits the restrictions as enforced by the Security
Rules to segment values that are assigned to the responsibility submitting the FSG
Report.

Selective access to FSG Reports cannot be enforced. In other words, any user having
access to FSG Report submission can submit any of the FSG Report including the
Financial Statements. However, proper definition and assignment of Security Rules
Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

would facilitate control on accounts that could be verified and reported by the
users.

Budgeting & Budgetary control:

The budgeting and budgetary control process of General Ledger will be used to
effectively monitor and control the actual account balance against the
projected/budgeted account balances.

It can also prove to be an effective management and decision making tool for
performance evaluation and detecting of variations and aberrations. Thus helping in
formulating corrective course of action.

Oracle Applications uses a tool called ‘Funds Checker’ to verify the budget
availability whenever a transaction is booked against budgeted account. Different
levels of budgetary control (Such as Absolute, Advisory and None) can be used to
control various transactions based on the control requirements. These controls will
determine how the transaction is processed.

In Oracle Applications, budgets are entered against the account codes at full
combination level consisting of values for all the 6 segments in the Chart Of
Accounts structure. It is to be noted that budgetary control exercise by the system is
on accrual basis and not on cash basis.

Budgetary control in Oracle Applications

Any number of budgets can be entered in the General Ledger against an account
code combination. However, funds verification and online funds control will be
against only one budget specified as the Funding Budget for the range.

A range of account code combination can have only one Funding Budget.

The online Funds verification and Control will take place only in the Functional
Currency (INR). However, budgets can be entered in any of the enabled foreign
currency and used for comparison purposes - both online and through financial
reports.

The differential budgetary control levels such as Absolute, Advisory or None are set
at the account range level and will apply to all the account code combinations
falling with in the range. Also, the calculations of budgeted funds are controlled at
the account range level.

Budget types and Entering of Budget amounts

As discussed in the previous pages, Budgets in Oracle General Ledger are classified
as Funding Budget and Non-Funding Budget. Those budgets, which are marked as
‘Require Budget Journals’, can be used as Funding Budget. In other words, the
amounts for the Funding Budget, which will be used for online funds verification,
will have to be entered through Budget Journals.

Budget amounts entry can be either through the standard forms provided by the
General Ledger module or through a Desktop Integrator Tool known as ADI
(Application Desktop Integrator) or through the Budget Interface. The ADI will be
using the Excel spreadsheet functionality and facilitate upload of the data in the
General Ledger module.
Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

The funding budget amounts can be entered/uploaded through the ADI through
Budgetary journals. Also, the budgetary amounts could be uploaded through GL
Interface from an external system with the appropriate balance class and the budget
name.

Budget creation process in General Ledger

The budget creation process in General Ledger with reference to BLEIPL would
have the following steps

Budget Definition: A Budget defines the period for which it would hold the budget
amounts and also the method of creating the budget amounts viz. Requires budget
journals or not. The end period of the budget can be modified once the last period
mentioned in the budget has been reached. However, BLEIPL would define new
budget at the beginning of the fiscal year. The budgets created in the system would
have ‘Require Budget Journals’ check. The period specified for the budget definition
would have start and end periods of the fiscal year.

Budget Organization: Budget Organization groups the account code combinations,

which would undergo budgetary control. For each of the range of account
combinations, the level of funds checks viz. Absolute, Advisory or None should be
mentioned.

Along with the budgetary control levels, the boundary and period types which
control the calculation of funds availability would have to be defined and the name
of the budget, which will control the transactions against this range of accounts.
Only one budget can be designated as Funding Budget for a range of accounts.

In case of BLEIPL, funds check level would be specified as ‘Advisory’ for all the
account ranges included in the budget organization. Accordingly, the period limit
would be specified as QTD and boundary as Period. This would facilitate using the
remaining funds of the previous month in the quarter and having a control of the
budget for the period.

Where the budgetary control level is set to ‘Advisory’, no alert message could be
sent to any user. An online warning would be provided by the system to the person
who is creating the record and the same user can ignore the warning and proceed
with the transaction until it’s logical completion

Subsequently, budget amounts could be entered/uploaded against the above

combinations against appropriate budget names.

Budget Upload Process

As mentioned earlier, the ADI is a tool, which enables upload of certain data from
Microsoft Excel worksheet to the Oracle General Ledger. Only approved budgets
would be entered in the system. The budget approval process would be done
outside the system.

Both Journal Data and Budget data could be created in an Excel sheet and uploaded
into the GL using certain standard processes provided by the ADI tool. In both the
cases, ADI provides standard templates where information can be captured. This
standard template includes all relevant columns as available in the standard forms
of General Ledger.

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

After completion of budget entry in the excel spreadsheet, the ‘Upload to Interface’
process will have to be used to upload the budget data to GL. This process will
transfer the spreadsheet data into an Interface Table.

Import of the data into the actual tables can also be performed along with the
Upload process or can be performed through a separate process called ‘Import
Budget’ Process.

Encumbrance Accounting

Encumbrance Accounting is the functionality by which the act of funds reservation

against various documents results in creation of an accounting entry with the
balance class of Encumbrance. This would facilitate online inquiry of Funds
available based on the Budget, Actual and Encumbered balances.

In the case of Purchasing, Funds reservation against budgets can be enforced at

Requisition or Purchase Order level as may be appropriate for the BLEIPL. This
action of funds reservation will result in creation of encumbrances on the budgeted
amount. The accounting entries that will be created by the Encumbrance Accounting
process are detailed below.

Purchase Orders & Receipts

Against each Requisition/Purchase Order line, the system will automatically build
Charge A/c, Budget a/c and certain other accounts using a system provided feature
known as Account Generator.

When funds reservation and approval is performed on the document, encumbrance

journals are created and posted automatically by the system. These entries are
created by the background-processing mode and they will not be visible. The
budget account built in the said document is debited and an account designated as
‘Reserve for Encumbrance a/c, will be credited by the amount of funds reserved. If
reservation is done at the Requisition level, the same entry is generated at
Reservation level and reversed on conversion to PO. A new encumbrance entry also
gets created for the PO Amount.

This encumbrance will be relieved when goods are received and delivered to its
final destination against the relevant purchase Order or when the purchase order is
cancelled/finally closed. During this action, the system creates a reversal journal
entry from the Inventory module based on the PO encumbrance distribution and the
same can be reviewed in GL.

In the case of Standard PO the reservation takes place at the time of approval and in
the case of blanket purchase agreement, at the time of issuing the Blanket release.
For Planned PO, reservation is performed on approval of the document and then
relieved and recreated at the time of schedule release.

Vendor Invoices

In the case of PO matched vendor invoices, the system creates encumbrance journals
automatically for Invoice Price Variance (IPV) if any, at the time of validation of the
invoice. The same is relieved at the time of posting of the invoice to the General
Ledger through an encumbrance journal.

In case of non-PO matched invoices, encumbrance is created at the time of

validation and relieved when the invoice is posted. The encumbrance is created and
reversed against the account codes mentioned in the Invoice distribution lines. In
Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

both the above cases, the balancing amount will be posted to Reserve for
Encumbrance A/c

General Ledger Encumbrance

Encumbrance entries can also be manually created and relieved in General Ledger
through journals with balance type of Encumbrance, if needed.

Encumbrance Posting

All encumbrance creation & reversal entries will be posted automatically. This will
be in tune with the Auto Posting policies of General Ledger and the GL Transfer
policies of the feeder modules. Both of the above activities are expected to be daily
activities.

Period Closing Process

The accounting periods in Oracle Applications are primarily driven by the

accounting calendar attached to the set of books to which the financial entries are
transferred. All the feeder modules such as AP, AR, FA etc derives their accounting
period based on this calendar defined in General Ledger.

The periods in each of the feeder modules can have any of the following status -

Never Opened-The period is prior to the first open period for the set of books or has
not been opened as yet

Future- Transactions can be entered for the period. However no posting can be
performed.

Open-Current/Active period. Transactions can be entered and posted

in/transferred to General Ledger for the period

Closed-Period is closed. No transactions can be entered for a closed period neither

can existing transactions be posted into the closed period. However, a closed period
can be re-opened if required.

Permanently Closed-The period is permanently closed and cannot be re-opened. As

in closed period, no new transactions can be entered for a permanently closed
period neither can transactions be imported for this period.

The Closing and Opening of periods process in Oracle Applications is specific to

each of the feeder modules and are achieved by changing the period status. Also
each of these modules has various rules that govern the period closing activity.

The sequence in which, the feeder modules to be closed is follows:

 Inventory

 Purchasing

 Payables

 Receivables

 Fixed Assets

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

 General Ledger

Access to period close function would be restricted using function security. It is

proposed that period control access should be restricted to only one user who is
designated for the same. It ensures that any transactions to be entered after closing
the period, should be informed to the designated user in order get the period
reopened.

A detailed activity checklist for month closing for all the modules in Oracle
Applications would be provided as a separate document and would form part of
the annexure to the Standard Operating Procedure (SOP) document.

Reconciliation Process:

The reconciliation process covers the activities to be performed in Oracle

Applications to ensure that the Feeder modules transactions are properly
transferred to General Ledger and balances in these modules are same.

Where certain related transactions are performed in different time zones (say in
different periods) or in different systems, a clearing account may be used to route
the transactions. This clearing account would ideally reach zero balance on
completion of the related activities. The balance in this account would represent
uncompleted transactions, which would be identified as part of reconciliation.

Reconciliation of Control Accounts:

This process explains in detail the various reports and activities to be performed to
validate that the balances as shown by the General Ledger are as per the balances as
reported by the relevant Feeder Modules against the control accounts declared.

While few of the modules support backdated (as on any given date) reconciliation
with the General Ledger balances, the reconciliation would primarily be performed
based on real time balance.

Prerequisite

Prior to the reconciliation, all the transactions in the feeder module pertaining to the
period, which is being reconciled, should be transferred to the General Ledger and
the journals should be posted.

If the period is not closed, it is suggested that the period be closed in the respective
module prior to reconciliation. This would ensure that no new transactions are
entered during reconciliation affecting the balance pertaining to the period, which is
being reconciled.

Activity

Using the standard ‘Account Analysis - 132 Char’ or other similar reports,
transactions in control accounts can be sorted by Sources to group transaction lines
in GL by the source. This would facilitate arriving at the total balance in each
account by source. This report would also provide the balance in the given account
combination for the chosen period range.

Inventory: - Inventory generates accounting entries for various Stock related

transactions. The following reports of Inventory could be utilized to reconcile the
Process Listing and Process Descriptions 2 of 32
File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

balance in GL against the Stock account with the Stock value as reported by
Inventory. All the below reports are specific to an inventory organization and hence
for reconciliation, needs to be submitted for each inventory organization.

Sub Inventory Value Report: - For an inventory organization, this report provides
the closing balance of stock and it’s value as at the current date. Though this report
does not provide the account code information, given that only one
nominal/combination would be used for each of the Inventory Organization, online
comparison with the nominal balance could be performed for reconciliation.

Transaction historical Summary Report: - This report provides the closing balance as
at any given date (including past date) with Quantity and Value for each Sub
inventory with in an organization.

Period Close Value Summary Report: - This report provides the closing stock value
as at any period end date for all sub-inventories with in an Inventory Organization.

Material Account Distribution summary: This report provides summary of

accounting distributions for each of the code combination during the given date
range.

Purchasing: - Purchasing generates accounting entries with actual balance class

primarily for accruals. Accruals for stock items are generated on receipt of goods
and reversed when an invoice is booked against the concerned PO/Receipt. For
Non-stock items, the accruals are generated during the Period-End process based on
the uninvoiced goods received. The following report would facilitate reconciliation
between Purchasing and General Ledger

Receiving Account Distribution report: Provides details of transactions where

receiving accrual has been generated and reversed on delivery.

Accrual Reconciliation Report: Facilitates reconciliation of Accrual account balances.

Account Payables: - Payables generates accounting entries for all invoice and
payments related transactions. Some of the key accounts that would need to be
reconciled in General Ledger with details from Accounts Payable are the Supplier
Liability and Supplier Advance (Prepayments) balances. Some of the reports given
below would facilitate such reconciliation.

Accounts Payable Trial balance: This report provides the balance pending against
suppliers against invoices by the liability account as at any given date.

Prepayment Status Report: - This report provides the detailed listing of all pending
prepayment invoices with the account distribution. This would facilitate
reconciliation of supplier advances.

Receivables: - Receivables generates accounting entries for all customer based

transactions and other miscellaneous receipts. Some of the key accounts that needs
to be reconciled based on details from the Accounts Receivable module are the
control accounts of type Receivable, Unapplied Cash, Unidentified Cash and On-
Account Cash. Some of the reports that would facilitate such reconciliations are
listed below. The reconciliation could be in the form of confirming that all the
account entries as reported by the AR Module has been faithfully transferred to
General Ledger and also could be in the form of validating that the Receivable
balance shown by the General Ledger is the same as the customer balance reported
by the Receivables module.

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

AR Reconciliation Report: This report summarizes all customer, receipt, transaction,

and account balances for the period you specify to simplify the internal
reconciliation process. The report uses the following formula to help you reconcile
any outstanding receivable amounts:

Totals for Period – End of Period Balance = Difference

Journal Entries Report: This report provides the detailed and summarized version
of entries generated by Accounts Receivable module on account of various
transactions and groups them by the transaction type.

Aging - 7 Buckets - By Account Report: Provides Aging details of Customer

balances classified by the Receivable account code combination of the Open
documents.

Fixed Assets: - Fixed Assets generates accounting transactions for all asset related
activities such as Addition, Adjustments, Depreciation, and Retirement etc. The
journals created from out of these activities are posted in General Ledger. The Fixed
Assets module provides various reports to facilitate all major reconciliation
requirements. Some of these reports are listed below

Cost Summary Report: Provides summary of all transactions affecting the Asset
Cost account due to various activities such as Additions, Retirements, and
Reclassifications etc during the given period range. This report provides cost details
for each of the Balancing segment and for each Cost Centre and Nominal under the
balancing segment.

CIP Summary Report: Similar to the above, this report provides summary of
transactions against CIP Cost Account

Reserve Summary Report: This report provides summary of transactions against the
Depreciation Reserve account (which would get credited against depreciation
expenses generated by the depreciation process)

Similarly for all the above reports, Detail reports are also available to provide
further detailed information. FA also provides certain Mass Additions related
reports to facilitate reconciliation of any of the clearing accounts.

In the case of Fixed Assets, the balance in the clearing accounts represents those
transactions where only one part has been completed, e.g. invoice booked but asset
not capitalized. These accounts could be reconciled as per the reconciliation process
discussed as part of the Fixed Assets solution design.

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Open and Closed Issues for this Deliverable

Open Issues

ID Issue Resolution Responsibility Target Date Impact Date

Closed Issues

ID Issue Resolution Responsibility Target Date Impact Date

Process Listing and Process Descriptions 2 of 32

File Ref: 602588670.doc (v. )
Company Confidential - For internal use only