You are on page 1of 35

Multi Org Precondition Definition

Final Report

Final
Multi Org Precondition Definition

Final Report

Final

Utrecht, February 14, 2000

Ing. E. Nijlant MBA, Drs. M.C. Regtien

Doc: 365750636.doc
Contents

1 Introduction

2 Organisational model
2.1 Libertel structure
2.2 Intercompany relations

3 Multi Org Set-up


3.1 Definitions
3.2 Libertel Multi Org Set-up
3.2.1 Libertel Multi Org Set-up Phase 1
3.2.2 Libertel Multi Org Set-up Phase 2
3.3 Accounting
3.3.1 Purchasing
3.3.2 (Sub)inventory movements and revaluation
3.3.3 Sales
3.3.4 Intercompany corrections
3.4 Set-up Consequences LNO
3.4.1 Order Entry, Accounts Receivable
3.4.2 Purchasing, Accounts Payable
3.4.3 Orderflow iZi
3.4.4 Existing Customisations
3.5 Set-up Guidelines for customisations
3.5.1 Multi org technical basics.
3.5.2 Developing customisations

4 Sharing Master Data


4.1 Customers & Suppliers
4.1.1 Procedures
4.2 Items
4.3 Accounting Flexfield Values
4.4 Currencies and rates
4.5 Employees
4.6 Summary of Responsibilities
4.7 Set-up changes
4.8 Set-up documentation
4.9 Database Management

5 Security
5.1 Users and responsibilities
3

5.2 Security rules


5.3 Cross validation rules

6 Application Support and DBA Support


6.1 Support procedures
6.2 Patching

7 Action points

Enclosure
I Environments Libertel

Ernst
4

1 Introduction

Libertel prefers to have one instance of Oracle Applications installed corporate


wide. In order for one instance of Oracle Applications to be able to support the
different organisations within Libertel, the set-up of Oracle Applications needs to
be changed in such a way that it supports multiple organisations (Multi Org Set-
up).

Since the Oracle Applications Multi Org Set-up touches business decisions
(including strategic direction) which are out of scope of the running Oracle
projects like iZi and Kolibri, Libertel has decided to install a task force which
will define the preconditions for the Oracle Applications Multi Org Set-up for
Libertel corporate wide. These preconditions are needed as input for other
Oracle projects like Kolibri Logistics and LVS and LCP Finance but also for
impact Oracle projects that are already live, like iZi.

This report describes the organisational model, the Multi Org set-up and set-up
consequences for LNO, the framework for procedures for sharing data within
one instance, the procedures for Application support and control and gives
guidelines for the current projects within Libertel.

Input for this preconditions report were various interviews and information
provided by Libertel. A key document in the design of the Oracle organisational
model is the memo drafted by Michel Boots, dated December 24th 1999.
The following company abbreviations will be used throughout this document.

Abbreviation Company
LNV Libertel NV / Libertel Group
LNO Libertel Network Operations bv
LVS Libertel Verkoop & Services bv
LBP Libertel Business Point bv (profit centre of LVS)
LCP Libertel City Point bv
LDA Libertel Data
LIN Libertel Interactive
SCMO Libertel Supply Chain Management Organisation (cost centre
of LNV)
SY Syntrack
ME Mobile Exchange

Fig. 1. Company abbreviations

Ernst
5

2 Organisational model

The first step in modelling the Multi Org set-up is describing the desired
organisational structure and the intercompany transactions between the Libertel
companies.

2.1 Libertel structure

As of the first of April 2000 a new business unit will be operational (Supply
Chain Management Organisation) which will perform all logistic handling for the
Libertel companies. This business unit will be part of Libertel NV and will not
own any inventory.

The following companies reside under Libertel Group:

Libertel Network Operations bv;


Libertel Verkoop & Services bv;
Libertel Business Point bv (profit centre of LVS) ;
Libertel City Point bv;
Libertel Data;
Libertel Interactive;
Libertel Supply Chain Management Organisation (cost centre of LNV);
Syntrack;
Mobile Exchange.

2.2 Intercompany relations

The new logistic organisation SCMO will change the way logistics are handled
within Libertel. Basically, SCMO will be the only Libertel Company that can
issue purchase orders to suppliers besides operating unit specific or non-logistic
procurement. All other companies order their requirements from SCMO.

The following intercompany flows can be distinguished:


1. Central Procurement (SCMO) and decentralised receipt;
2. (Sub)inventory transfers (buying from each other);
3. LCP buys from LVS with shipment from LNO warehouse (iZi).

Ernst
6

1. Central Procurement (SCMO) and de-central (Adm.) receipt

Forecast / MRP

Purchase Libertel Network Libertel Verkoop & Libertel Business


Requis itio n Libertel City Points
Operations Services Points

Libertel Supply
Chain Management Manage Inventorie s

Organisation

INV IN V IN V IN V
LNO LVS LBP LCP

Payments In voice Purchase Order Receipt

Adm. In ventory

Physical In ventory
INV
Supplier
SCMO

Fin ancial
Intercompany
Transaction

Ernst
7

2. (Sub)inventory transfers (buying from each other)

Libertel City Points

INV
LCP

Libertel Supply
INV Chain Management
LVS

Libertel Verkoop & INV


SCMO
INV Libertel Network
LVI LNO
Services Operations

INV
LVC

INV
LBP

Libertel Business Financial


Intercompany
Points Transaction

Ernst
8

3. LCP buys from LVS with shipment from LNO warehouse by SCMO

Purchase Order

Shop IN V
LCP Libertel City Points
AP &
AR In
vo ic es

Libertel Verkoop &


n al Services
ur
Jo
y Adm. Inventory
IN V or
nt
LCP ve
In
Libertel Network
Operations
Physic al Inventory

Financial
Sale s Order Intercompany
IN V Transaction
LNO

Purchasing Sales Order


Receipt Shipment

Libertel Supply IN V
LNO
Chain Management

Ship ment to LCP


shop

Ernst
9

3 Multi Org Set-up

3.1 Definitions

Before describing the Multi Org set-up we need to explain the Multi Org entities
that Oracle uses in modelling the business.

Business Group: Represents the highest level in the structure. The consolidated
enterprise or a major division of a company. Currently Business Group has no
other purpose but to segregate HR information. If you request a list of
employees (in any module) you will only see those employees in the Business
Group of which your Operating Unit is a part. Multiple Legal Entities can
relate to a single Business Group.

Set of Books: This is the highest level at which the financial entities are
segregated. Any entity that has a particular chart of accounts structure,
functional currency or calendar must be a separate Set of Books.

Legal Entity: A Legal Entity relates to a single Set of Books. Currently


Legal Entity has very limited functionality.

Operating Unit: Any autonomous organisation which uses Oracle Receivables,


Oracle Payables, Oracle Order Entry and Oracle Purchasing. An Operating Unit
is associated with a single Legal Entity. Information is secured by Operating
Unit in the above products with some shared information (for example customer
and supplier names with sites being specific to each Operating Unit).

Inventory Organisation: An Organisation for which you track inventory


transactions and balances. Oracle Inventory, Bills of Material, Engineering, Work
in Progress, Master Scheduling / MRP, Capacity and Purchasing (receiving)
secure information by Inventory Organisation. Inventory Organisations may
be related to any Operating Unit within the same Set of Books. The
relationship between Inventory Organisation and Set of Books is used for
financial purposes only (creating requisitions and replenishing supplies).

Responsibility: This is a grouping of functionality and system data often related


to a job role or responsibility. Responsibilities are associated with a Set of
Books, Operating Unit and Inventory Organisation where appropriate
through profile settings (for example. MO: Operating Unit defines the
Operating Unit for that Responsibility).

Balancing Segment: This is a segment in the Accounting Flexfield structure


(usually the Company segment) at which all accounting entries must balance.

Ernst
10

There may be multiple companies within the same structure, each of these must
balance within itself. All required inter-company entries will automatically be
created within the Set of Books to ensure companies could never get out of
balance.

Security Rules: Security rules limit (by responsibility) the values of a Flexfield
which the user will see. For example a user will only see the Department values
in the Accounting Flexfield which they have authority to see.

3.2 Libertel Multi Org Set-up

Based on the organisational structure and the intercompany relationships the


future Multi Org design will be modelled through two phases:

1. Incorporate SCMO in current LNO operations, LVS & LCP Finance start
each in their own Operating Unit;
2. Exclude LNO, LDA and LIN from current Operating Unit into a new
Operating Unit.

Phase 1 is feasible to implement when Kolibri and LVS&LCP Finance go live.


Phase 2 is a possible option that can be implemented later, depending on future
developments.

Implementing phase 2 directly is not feasible for a number of reasons. A new


Operating Unit of SCMO (LNV) requires additional set-up of Accounts Payable
and Receivable. Data conversion will therefore be more complicated and time
consuming since the LNO Suppliers need to be added (sites) to the new
Operating Unit.
When LNO iZi logistics need to be integrated into the SCMO operations, it is
more efficient to keep using the LNO Operating Unit. A new SCMO Operating
Unit would require a full manufacturing set-up, since an existing Inventory
organisations can not be moved to a new Operating Unit.

Since LNO is currently processing the financial accounting of the logistic


operations (and will remain doing so for SCMO) it is recommended to use the
LNO Operating Unit for the time being until the SCMO operations are fully
operational (including LNO iZi logistics). After that LNO can be excluded from
the current Operating Unit, leaving SCMO (LNV) behind as single owner.
SCMO can then benefit from the existing full functionality of the current LNO
implementation. Creating a new LNO Operating Unit is much easier since this
will be a non-logistics Operating Unit.

Ernst
11

3.2.1 Libertel Multi Org Set-up Phase 1

3.2.2 The following Multi Org structure is proposed for phase 1.

Libertel Groep
Business Group

Set of Books Libertel Groep

SCMO LNV LNO LDA LIN SY ME LVS LBP LCP

ies
an
omp
C

Legal Entity SCMO, LNV, LNO, LDA , LIN, SY, ME LVS / LBP LCP

Operating Unit SCMO, LNV, LNO, LDA , LIN, SY, ME LVS / LBP LCP

Inventory Organisation
LNV LNO

Subinventory LNO BOS NEL Financial


In vento ry
Transactio ns

Subinventory LNV LNO LVS LVS-C LVS-I LBP LCP

Figure 1: Multi Org Set-up Phase 1

To create maximal flexibility for Libertel all Libertel companies will work within
one Business Group and one General Ledger (Set of Books). A new Set of
Books can be created later for consolidating purposes.

Ernst
12

The Company segment within GL determines the balancing segment for financial
reporting.

The legal entity has no functionality (yet). We propose to keep the existing legal
entity for LNO, LNV, LND, LIN, SY and ME (one legal entity). For LVS and
LCP a new legal entity will be created.

LNV, LNO, LND, LIN, SY and ME will share one operating unit for the
subledgers (AP, AR, PO, OE, INV) but will report to their own company code.
LVS/LBP and LCP will have their own operating unit, reporting to their own
company code. Integrating LVS and LCP into one Operating Unit will give
operational disadvantages and accounting problems for encumbrances
(purchasing) and inventory.

We have chosen to integrate the SCMO Operations into the existing LNO
Operating Unit because this will require no new financial implementation and
data conversion for SCMO. A new Operating Unit for SCMO would require the
implementation of PO, AP and GL.
Furthermore it will not endanger the current LNO operations (for example iZi
and WEB) since these will remain in there own Inventory Organisation yet
shared within one Operating Unit. Finally the new WEB functionality of the
LNO Operating Unit can also be used (in a next phase) by SCMO.

The existing LNO Inventory Organisation (iZi) will be extended with an extra
inventory organisation (LNV) within the same Operating Unit. This new
Inventory Organisation will handle all Libertel logistics, except iZi.

As a start, SCMO will have six subinventories: LNO, LVS, LVI (LVS Indirect),
LVC (LVS Corporate), LBP and LCP. LNO will keep its current subinventories
for Nelipak (NEL), Bosman (BOS) and Libertel.

Minimally the following modules and functionality will now be available per
company.
Libertel NV Libertel Libertel Libertel City Libertel Data,
Network Verkoop & Points Interactive,
Organisation Services Syntrack, Mobile
Exchange
GL GL GL GL GL
PO PO PO PO PO
AP AP AP AP AP
OE OE OE AR AR
AR AR AR
INV INV
WIP WIP
BOM BOM
MRP MRP

All logistic transactions will be processed within the LNO Operating Unit by:
The LNO unit within the LNO Inventory Organisation (iZi);

Ernst
13

The SCMO unit within the SCMO Inventory Organisation (Other logistics).

LVS and LCP will only use PO and AP for internal inventory purchases (by
SCMO) and non inventory external purchases (expenses).

3.2.3 Libertel Multi Org Set-up Phase 2

3.2.4 Phase two can be implemented when the SCMO group is fully operational and
takes over the LNO logistic operations (iZi). The current LNO Operating Unit
will be operated by SCMO (LNV). The same situation for LNO will then be
created as for LVS and LCP in phase 1 (own Operating Unit).

Libertel Groep Financial


Business Group Inventory
Transactions

Set of Books Libertel Groep

SCMO LNV LNO LDA LIN SY ME LVS LBP LCP

an ies
mp
Co

Legal Entity SCMO LNV, LNO, LDA , LIN, SY, ME LVS / LBP LCP

Operating Unit SCMO LNV, LNO, LDA , LIN, SY, ME LVS / LBP LCP

Inventory Organisation SCMO

Subinventory LNV LNO NEL BOS LVS LVS-C LVS-I LBP LCP

Figure 2: Multi Org Set-up Phase 2

The remaining part of this report will only cover the implications of phase 1.

Ernst
14

3.3 Accounting

As shown in the figures 1 and 2, Oracle Applications generates journals based on


account settings from the subinventories (material account). The following
figure indicates at which level accounts can be set (inventory, subinventory or
item), and therefore determines which accounting possibilities are available.
Inventory
Master Invent ory
Organisation
Organization
(LNV or LNO)

Costing Information (INV):


* Material
* Outside Processing Purchasing Options (PO):
* Material Overhead * Expense APAccrual
* Overhead
* Resource
* Expense
Receiving Options (PO):
WIPAccounting (WIP): * Receiving Accrual
* Material
* Material Variances
* Material Overhead OtherAccounts (INV):
* Resource * Purchase Price Variance
* Resource Variances * Invoice Price Variance
* Outside Processing * Inventory APAccrual
* Outs. Proc. Variances * Encumbrance
* Overhead * Sales
* Overhead Variances * Cost of Goods Sold
* Standard Cost Variances

Sub Sub
Sub
Inventory Inventory
Inventory 1
2 3

Accounts: Accounts: Accounts:


* Material * Material * Material
* Outside Processing * Outside Processing * Outside Processing
* Material Overhead * Material Overhead * Material Overhead
* Overhead * Overhead * Overhead
* Resource * Resource * Resource
* Expense * Expense * Expense
* Encumbrance * Encumbrance * Encumbrance

Master items Organization Items

Accounts: Accounts:
* Cost of Goods Sold * Cost of Goods Sold
* Encumbrance * Encumbrance
* Expense * Expense
* Sales * Sales

Figure 3: Set-up of Accounts

Ernst
15

The Material Account on the subinventory is the inventory balance account. This
account is set for the full Accounting Flexfield, including company segment.

The following tables explain the journals made per process step (purchasing,
inventory transactions and sales). Also it indicates which accounts are used and
where they are retrieved.

3.3.1 Purchasing

Process GL Journal Calculation Set-up per:


Step
Purchase Encumbrance Account # ordered * order price Item
Order
A/ Reserved for Encumbrance # ordered * order price Set of Books

Receipt Receipt for Inspection:


Receiving Accrual #receipt * order price Inventory Org.
A/ Inventory AP Accrual #receipt * order price Inventory Org.

Receipt in inventory:
Material account #receipt * VVP1 Subinventory
(A/) PPV #receipt * (VVP-order price) Inventory Org.
#receipt * order price
A/ Receiving Accrual Inventory Org.

Reverse encumbrance: #receipt * order price


Reserved for Encumbrance #receipt * order price Set of Books
A/ Encumbrance Account Item
Invoice Inventory AP Accrual #invoiced * order price Inventory Org.
BTW BTW Supplier Site
(A/) IPV #invoiced * (order price - Inventory Org.
invoice price)
A/ Creditors #invoiced * invoice price + Supplier Site
BTW

1
Vaste Verreken Prijs: fixed cost price per item at which the inventory of this item is valued
during a certain period.

Ernst
16

3.3.2 (Sub)inventory movements and revaluation

Process GL Journal Calculation Set-up per:


Step
Movement Material Account #moved*VVP Subinventory
A/ Material Account #moved*VVP Subinventory
Revalu-ation Material Account #stock * VVP-new VVP Subinventory
#stock * VVP-new VVP
A/Revaluation Inventory Per revaluation
run

3.3.3 Sales

Process GL Journal Calculation Set-up per:


Step
Sales Order No journals
Shipment Cost of Goods Sold #ship*VVP Item
A/Material Account #ship*VVP Subinventory
Invoice Debtors #invoiced*Sales price+ Set of Books
BTW
A/Sales #invoiced*Sales price Item
A/BTW BTW Customer Site

3.3.4 Intercompany corrections

Whenever a journal is out of balance for a specific company, GL will


automatically create an intercompany transaction to correct this.

For example a purchase transaction of 100 items for NLG 240,= by SCMO
(company 2).
The item is ordered for LVS (Company 3), which owns the inventory.
The VVP of the item is NLG 250,= and the invoice price is NLG 260,=

The accounts are mentioned as [Company].[Account];


D = Debit, Cr = Credit

Ernst
17

Process GL Journal Account Amount NLG


Step
Purchase Encumbrance Account 2.30600 24.000 (D)
Order
A/ Reserved for Encumbrance 2.27010 24.000 (Cr)

Receipt Receipt for Inspection:


Receiving Accrual 2.25380 24.000 (D)
A/ Inventory AP Accrual 2.30410 24.000 (Cr)

Receipt in inventory:
Material account 3.30401 25.000 (D)
(A/) PPV 2.30140 1.000 (Cr)
A/ Receiving Accrual 2.30410 24.000 (Cr)

IC Journal 2.14510 25.000 (D)


A/ IC Journal 3.14510 25.000 (Cr)

Reverse encumbrance:
Reserved for Encumbrance 2.27010 24.000 (D)
A/ Encumbrance Account 2.30600 24.000 (Cr)
Invoice Inventory AP Accrual 2.25380 24.000 (D)
BTW 2.12000 4.550 (D)
(A/) IPV 2.30411 2.000 (D)
A/ Creditors 2.16000 30.550 (Cr)

Note that the intercompany journals are created on the same account for all
companies (14510). Also the intercompany amount is based on the VVP of the
item purchased. Any price or invoice variances will be assigned to SCMO.
Special transfer pricing (other than VVP) can only be implemented when the
transactions are based on an internal requisition and sales order (refer to the
described intercompany flow 3 in paragraph 2.2).

3.4 Set-up Consequences LNO

When implementing Phase 1, the existing LNO implementation needs to be


evaluated for the new situation.

Ernst
18

3.4.1 Order Entry, Accounts Receivable

The following parameters on the Customer Header need to drop down to the bill
to site (bill-to business purpose detail) since the Multi Org functionality will
separate customer sites per Operating Unit.

Order type;
Transactions types;
Sales reps;
Tax exemptions;
Batch sources;
VAT taxes;
Tax codes and rates.

3.4.2 Purchasing, Accounts Payable

3.4.3 The following parameters on the Supplier Header need to drop down to the
Supplier Site since the Multi Org functionality will separate Supplier Sites per
Operating Unit.

Purchasing
Control functions/groups;
System parameters;
Position controls;
Account distributions.

Payables
Distribution sets;
Bank accounts;
Tax names and groups;
Expense report types;
System options.

Bank Accounts
Bank Account for SCMO;
Link SCMO Supplier Sites to separate paygroup or payment method.

OE: Valueset rule


Values defaulting from customer header should now be defaulted from site or
bill-to business purpose detail.

Ernst
19

Possibly related functional areas:


Wholesale billing;
Eurobill interface.

Item set-up

The SCMO organisation will purchase inventories from external parties.


Obligations, commitments and invoices must be registered under LNV. This
implies that the encumbrance account for items currently in the LNO inventory
organisation should be changed to reflect this need.

3.4.4 Orderflow iZi

To maximise the benefit of Multi Org, orders for iZi products should be entered
at the Operation Unit who owns the sales order. For example: Free Record Shop
will order its iZi products at LVS; so the sales orders for LVS exists in the
Operating unit LVS. This means that address details of Free Record Shop will
also reside in the LVS operating unit. Currently the address details reside with
LNO operating unit. The existing Web application, currently used by LVS to
place orders at LNO, can be used for LVS customers for order entry (Corporate
clients).

3.4.5 Existing Customisations

All existing customisations need to be verified before the actual Multi Org
conversion. For each customisation the following points should be addressed as
a minimum:
Generic compatibility with Multi Org;
Compatibility with intercompany flows as described in this document;
Ability to use system without customisation.

3.5 Set-up Guidelines for customisations

3.5.1 Multi Org technical basics.

The rationale of Oracle Applications Multi Org is that access (to data) is
restricted to the data belonging to the Organisation you are assigned to when
you log into Oracle Applications. For example, if two organisations (Operation
Units) have been set up owning data as in the example below:

Ernst
20

Organisation 1 Organisation 2
Invoice No 123 Invoice No 456
Invoice No 678 Invoice No 901

If a user, logging into Oracle Applications, is assigned to Organisation 1 and


attempts to retrieve all invoice information, they will only retrieve details of
invoices No 123 and No 678, while a user loggin into Oracle Applications is
being assigned to Organisation 2, performing the same operation, will retrieve
details of invoices No 456 and No 901.
This control of data access is implemented in Oracle Applications by the use of
database views on underlying tables, where the underlying tables contain all data.
For example, AP invoice information is stored on a table called
AP_INVOICES_ALL, which in the above case would contain four rows, one
for each invoice. This table will also contain a column called Org_Id, which is a
unique number assigned to each organisation.
In our example assume Organisation 1 has an Org_Id of 111 and Organisation 2
has an Org_Id of 222. Then the data in AP_INVOICES_ALL would be :

Invoice No Org_Id
123 111
456 222
678 111
901 222

When a user logs into Oracle Applications Multi Org their responsibility links
them to a particular organisation. Thus a particular Org_Id value - in our
example a user whose responsibility links them to Organisation 1 would have an
Org_id of 111 associated with them, while a user whose responsibility links
them to Organisation 2 would have an Org_id of 222 associated with them.
Thus, if the user linked to Organisation 1 created a new invoice, the Org_Id of
that invoice would be 111, and if the user linked to Organisation 2 created a new
invoice, the Org_Id of that invoice would be 222. It is this association with an
Org_Id value that enables Oracle to create database views that restrict data
access. The Org_Id associated with a user is returned by a built in function -
USERENV(CLIENT_INFO). For example calling this function as the user
linked to Organisation 1 would return a value of 111, calling this function as the
user linked to Organisation 2 would return a value of 222. A database view can
therefore be created as follows (continuing with our example) :
-CREATE
VIEW AP_INVOICES AS
SELECT Invoice_No,
Org_Id
FROM AP_INVOICES_ALL
WHERE Org_Id = USERENV(CLIENT_INFO)
The view name is AP_INVOICES for example the underlying table name
without the _ALL extension. Due to the WHERE clause restricting the selection

Ernst
21

of data to that where the Org_Id on the AP_INVOICES_ALL table matches that
returned by the USERENV(CLIENT_INFO) function, selecting data from this
view as the user linked to Organisation 1 will only retrieve details of invoices No
123 and No 678, while selecting data from this view as the user linked to
Organisation 2 will retrieve details of invoices No 456 and No901.

3.5.2 Developing customisations

Whenever the need for customisations arise, it should be verified with


application support if:
customisations have been applied within the scope of the proposed
customisation;
customisations are currently being developed that may conflict.

Application control will keep record of all customisations are taking place.
Customisations can only be applied in production environment when the
customisation has been approved by and (initial) documentation has been handed
to application support.

Ernst
22

4 Sharing Master Data

For each master data element that is controlled by the operating unit, the current
LNO procedure can be used as a start. Existing procedures were also used as a
starting point for data which is shared across operating units. For both types of
data we propose to use a template for each data element before it is entered in
the system.

4.1 Customers & Suppliers

Within one instance customer and suppliers are shared on header level. The sites
can be defined per Operating unit, including the parameters (for example
payment terms). This functionality provides:
Libertel Group overview of activities per customer and supplier;
Flexibility for the Operating Units to define their own sites and manage the
parameters.

Customers & Suppliers

The headers are


Header accessible by all
Operting Units

The sites are


Site 1 Site 2 Site 3 protected per
Operating Unit

Manage sites
Parameters Parameters Parameters per Operting
Unit

Figure 4: Customer and Supplier Security

Ernst
23

4.1.1 Procedures

As a minimum the following issues need to be addressed in the current


procedures to maintain customers. Customer headers and sites will be
maintained by the Operation Units for the following reasons:
LVS customer headers and addresses will be loaded from Andromeda (LVS
Billing system) via an automated interface;
LNO will maintain the customer headers manually.
A procedure should be established for customers and addresses used for
deliveries by Bosman. These sites cannot be added modified without notification
to Bosman and co-ordination with Application Support for the Q-manager.

4.2 Items

All items handled by SCMO will be centrally maintained by the SCMO item co-
ordinator. For the following areas a procedure needs to be established.
Financial attributes including cost control and accounts;
Logistic attributes including planning, inventory, purchasing and production
attributes;
Item coding (legacy system dependencies, customisation dependencies);
Status control;
Item costing.

Sales pricing and discounting will be done separately by the pricing co-ordinator
for each operation unit.

For all items a general item maintenance procedure and template will be
developed.

4.3 Accounting Flexfield Values

All accounting segment values will be maintained centrally. Authorisation of


Company and Account changes will be performed by Group Finance. Other
segment changes can be authorised by the company finance itself.

Ernst
24

Accounting Flexfield
Segment Length LNO Others
Bedrijf 1 X X
Reknr 5 X X
Afdeling 5 X X
Project 4 X X
Abonneeh. 3 X -
Tarief 3 X -
Bestemming 1 - -
SP/Land/RP 3 - -
Piek/Dal 1 X -
Reserve 1 4 - -
Reserve 2 4 - -
Figure 5: Use of Accounting Flexfield Libertel

All companies (except for LNO) will only use the first four segments of the
Accounting Flexfield.

4.4 Currencies and rates

All currencies and daily rates are maintained centrally by LNO Finance and can
be used by all other companies

4.5 Employees

Maintenance of the employee table within Oracle needs to be co-ordinated


between the subsidiaries since all employees are defined on Business Group level
(Libertel Groep). The employee table is used for Purchasing Hierarchies and
Expense payments through Accounts Payable.

Ernst
25

4.6 Summary of Responsibilities

Table Field(s) View Update


Customer Fields on header All ALL (templates)
Fields on sites OU OU (templates)
Supplier Fields on header All ALL (templates)
Field on sites OU OU (templates)
Item (SCMO) Master item fields ALL SCMO (templates)
Org item fields OU OU (templates)
Item (other) Master item fields ALL OU (templates)
Org item fields OU OU (templates)
Accounting Flexfield Company, Account ALL Group Finance
Values
Other segments ALL Company Finance
Currencies and rates All fields All LNO
Employees All fields All TBD
Other tables All fields OU OU (set-up)

Fig. 2. Responsibilities for shared data Application Control

4.7 Set-up changes

Set-up changes to the production database can only be made by Application


Support. Application Support will test any changes first in a test environment, if
necessary with help of the key users. Changes to set-ups will be documented in
the set-up documentation.

4.8 Set-up documentation

Application Support is responsible for gathering, storing and maintaining the


following documentation for the Production-environment:
Set-up documentation;
Procedures & Manuals;
Test scripts / Business scenarios;
Customisations;
Users and responsibilities.

The documentation will be stored in a protected area on the network with write
access for Application Support and read-only access for others. The
documentation will be managed with version-control.

Ernst
26

4.9 Database Management

Libertel currently operates three databases:


Libertel Production;
Libertel APPA (Development);
Libertel Training.

The current structure does not provide an exact copy of the production database
for testing. Also the APPA database is not a recent copy from production. This
causes two problems:
Development in APPA can not be applied to Production without checking if
the set-up in both systems (APPA is an old copy of production which is used
for development);
There is no test database which is completely identical to production. This is
a requirement for patch testing and training new users.

In the near future it is advisory to have the following databases:


Libertel Production (PROD);
Libertel Development: which is a recent copy (or copies) of production
before starting a new project(s) (DEV);
Libertel Test: an identical copy of production used for testing new patched
and training new users. After patching Production a new copy needs to be
made (TST).

Refer to appendix 1 for the planned database environments.

Ernst
27

5 Security

5.1 Users and responsibilities

The maintenance of users, responsibilities and menus will be handled by


Application Support. Adding and changing of new users and responsibilities will
only be done after approval from Company Finance or Logistics. Any updates
are documented in the appropriate documentation by Application Support.

5.2 Security rules

Security rules are linked to responsibilities and determine which segment values
can be used by the users within the responsibility. This needs to be done for all
existing responsibilities (LNO) and new responsibilities (LVS, LCP, SCMO).

Security rules can also be used for the account segment. For instance the
Intercompany account used by the system (14510) should not be used for
manual transactions.

Ernst
28

Security Rules Example

Responsi- Company Cost Center


Users Segment
bilities Segment
Values: Values:

Users SCM PO LNV A


B
GL LNV
C
1
D
2
E
AP LNV
Users LNV

3
F
AR LNV
4
G
5
H
6
Users LNO GL LNO

I
7
Users LVS GL LVS
8
9
Users LCP GL LCP

Figure 6: Security Rules

5.3 Cross validation rules

Cross validation rules determine which combination of accounting Flexfield


values are valid. This functionality can be used to determine for which accounts
a cost centre and/or project is mandatory. Cross validation rules are set per Set
of Books. The existing cross validation rules need to be evaluated for the new
GL implementations (LVS and LCP).

Ernst
29

6 Application Support and DBA Support

6.1 Support procedures

The following slide indicates (in general) how to organise the Application
Support procedures. An action has been set out to develop a more specific
Libertel support model.

Application Support

Functional Oracle
Issue
Oracle Users Manager Customer
(Key User) Support
Request
Log, Update Issues TAR
Issue

Log, Update
Support Issue
Technical
Application
Functional
Management
Log

Request DBA
Support
Log, Update
Issue
Technical
Management
(DBA)

Figure 7: Application Support

The Key Users per functional area (Logistics, Finance) are responsible for
addressing issues within their area either by solving those issues themselves or
requesting assistance from Application Support. In both cases the Key User
will update the Support Log.
Application Support will try to solve the issue and (if necessary) request help
from Oracle Customer Support (TAR) or the DBA. In both cases the Support
Log is updated by Application Support.

Ernst
30

The Support Log is a central spreadsheet which is stored in a protected area


on the network, with access rights for the Key Users, Application Support
and the DBA.
A separate spreadsheet will be used for projects and for EDI-related issues.

6.2 Patching

A specific support issue might require a patch. This patch will be sent by Oracle
Customer Support to the DBA. The patch-requestor (Application Support or
Key User) will inform the DBA that a patch is on its way and on which database
this patch needs to be applied to. If the Key User requested the patch, the Key
User will also inform Application Support. The Patch-requestor will update the
Support log.

The patch procedure is visualised below.

Patch Management

Technical / Technical /
Functional Functional
Key user DBA Support Key user DBA Support
Application Application
Support Support

Execute testplan by
Patch requested requestor

Document
Develop Patch Testresults
request and test
plan

Review patc h for Patc h accepted Yes


impact on
customis ations
No Apply Patch in
Prod

Assess patc h level


database
Update applied
Decide on further
patches document
Action
for Prod env.
Apply Patc h in
patch envir onment

Update applied
patches document
for patch env.

Figure 8: Patch Management

Ernst
31

7 Action points

Based on the underlying document the following action points can be identified.

Action Action Co-ordinator Together with


Multi Org conversion and set- Ronald Koenders
up LNO database before 1
March 2000
Check Multi Org Ronald Koenders
consequences for LNO data
(for example customers,
suppliers, customisations,
security rules)
Develop Customer & Supplier LVS Kolibri project team LNO Finance
entry templates and LVS & LCP Finance project
procedures team
Develop Item entry templates LVS Kolibri project team LNO Item co-ordinator
and procedures
Develop single chart of Grace Vita LNO Finance
accounts for all Libertel LVS & LCP Finance project
companies team
Group Finance
Determine company codes for Grace Vita LNO Finance
Libertel companies
Define cost centres and LVS & LCP Finance team LNO Finance
projects for LVS and LCP

Set-up security rules for LNO LNO Finance


and LNV
Set-up Security rules for LVS LVS & LCP Finance project
and LCP team
Set-up Cross Validation rules LVS & LCP Finance project
for LVS and LCP team
Determine responsibility for Grace Vita
maintenance of employee
table
Put Application Support in Mark v.d. Pas
place for all Libertel
companies and projects
Document Users and Application Support LNO
Responsibilities

Fig. 3. Action Points Multi Org

Ernst
Enclosure I 1

Appendix to:

Multi Org Precondition Definition


Final Report

Enclosure
I Environments Libertel
Enclosure I 1

I Environments Libertel

7 JAN 14 JAN 21 JAN 28 JAN 21 FEB 28 FEB 24 MRT 31 MRT 23APR 30APR

WEB1 Live LNO MO Live LV S/LCP Fin Live Kolibri Live

LNO LNO LNO LNO LNO LNO Li bertel Libertel Libertel Libertel Libertel
hqdb08/09

Produc- Produc- Produc- Produc- Produc- Produc- Produc- Produc- Produc- Produc- Produc-
tio n ti on tio n tion tion ti o n tion ti on ti o n tio n ti o n
Copy
Copy Copy Setup LNO Copy Setup LVS/LCP Copy
Setup WEB1 Setup Kol ibri Copy
Multi Org Financi als

LNO LNO LNO


LNOTest LNOTest LNOTest LNOTe st LNOTest LNOTest LNOTest LNOTest
APPA APPA APPA
hqtst03

Test environment for Test envi ronment for Test envi ronment for Test environment for
Traini ng Setup &Test Test envi ronment for
Funct.Acc.Ts t WEB1 Training WEB 1 Project Training WEB1 Producti on Production Production Production
WEB 1 Proje ct LNO Multi Org Production

DEV 1 DEV 1 Cu DEV 1 DEV 1 DEV 1 DEV 1 DEV 1 DEV 1 DEV 1


st &
Inte
rf
Setup WEB1 Techn.Acc.Ts t
Acc.Ts t Financi als Traini ng Financials
Cust & Interf. Kol ibri WEB1
Server
New

DEV 2 DEV 2 DEV 2 DEV 2 DEV 2 DEV 2 DEV 2 DEV 2

Setup Kol ibri & Add Cust & Interf. CRPKoli bri & Development Koli bri Development Koli bri Acc.Ts t Kolibri
Financials (m ulti org) Koli bri Fi nancial s
Enclosure I 1

You might also like