Process Design Document

O2C Order Processing

Version: V0.1011

Date: 13th June 2012

UBM Core PID Private and Confidential Page | 1

Contents
Contents 2

1. Document version details 3

2. Introduction 4

3. Diagram Symbols 6

4. Application Scope 7

5. Process Integration Overview 11

6. Order Management processing 1416

UBM Core PID Private and Confidential Page | 2

1. Document version details
1.1 Approval status

Date Name Approval status

1.2 Change record

Date Author Version Change Reference

13th June 2012 Mandeep S Ahluwalia V0.1 First draft created

31-Jul-2012 Mandeep S Ahluwalia V0.7 2nd Draft (including changes based on 1st draft
feedback)
26-Sep-2012 Mandeep S Ahluwalia V0.8 Changes / new requirements captured during
crp2
01-Oct-2012 Mandeep S Ahluwalia V0.9 Added the process for managing the
conference revenue transactions
15-Nov-2012 Lynette Soares V0.10 Updates for business review comments.
10-Dec-2012 Lynette Soares V0.11 Updated for PDA review comments.

1.3 Reviewers
The following are required to both review and provide comments on this document to the approvers

Name Role

Lynette Soares O2C global process lead

Stuart Elis O2C UK regional process lead
Alison Lauder O2C UK SME

1.4 Distribution
The following have been included on the distribution for information purposes only

Name Role

UBM Core PID Private and Confidential Page | 3

2. Introduction
2.1 Background
This document provides both a high-level overview and detailed step-by-step definition for the Order
Management process.
This process is aligned to Project Core requirements and should align to standard R12 application configuration
where possible. This document is based on Deloittes key learning and experiences in the Financials and HR
and Supply Chain arena, and specifically, Deloittes experience in the design and build of Oracle eBusiness
Suite applications.
In addition to the processes contained within this document, the following process flows are currently
embedded within the Project Core solution:

General Ledger (Document Reference)

Accounts Payables (Document Reference)

Accounts Receivables (Document Reference)

Fixed Assets (Document Reference)

Cash Management (Document Reference)

Internet Expenses (Document Reference)

Purchasing (Document Reference)

I-Procurement (Document Reference)

Inventory (Document Reference)

Order Management (Document Reference)

HRMS (Document Reference)

2.2 Purpose of the Document

This process definition document (PDD) should be used to document the agreed design.
This document has the following characteristics:

The process definitions conform to Oracle R12 Key Business Flows

The process definitions encompass Deloittes key learning and experiences gained from implementing
Oracle R12 Supply Chain

They are scalable and flexible so as to be able to adapt to changing business needs and changing
technologies

The process definitions are mid-level i.e. detailed enough to describe all system processes but do not
detail all desk top procedures

This process definition document will be used in the following ways during the implementation:

UBM Core PID Private and Confidential Page | 4

 It has a key role during the Global design review phase of the project, during which the Deloittes
project team will review these documents with UBMs project team members. The objective of the
review is to both familiarise the UBM project team with the detailed process design, and to have
them validate and accept the process design components. During this review stage refinements to
the processes are completed, but these are anticipated to be minimal and conform to standard Oracle
configuration.

The process design definitions in this document can also be used to identify and review any changes
required in the current UBMs O2C business processes

This document explains the order entry process in scope of the Project CORE. The document
provides details on fields to be entered or defaulted on the sales order, mandatory fields on the sales
order, fields on the sales order that can be updated, holds that could be applied on the sales order,
the logic for credit check and Tax code derivation for the sales order lines.

This document will not contain the following information:

Any low level application information this will be contained in the Application Set-Up
documentation (BR100s)

Any training information this will be available in the related Training Guide

2.3 Document Users

This document will be used by both members of the Deloitte team and UBM, in order to review the agreed
design.

UBM Core PID Private and Confidential Page | 5

 3. Diagram Symbols
The diagramming convention used for the process maps is indicated below. All process flows are created in
Industry Print 5, Deloittes business process modelling tool.

AP-020-010

Enter Invoice with

PO Sub-process

AP-020-010-040
PO
Enter Invoice
Header information Task
into Oracle
Non-PO

Recurring No
AP-030

Payments
Process Interface
Self Billing
Yes Yes No
No No
Credit/Refund

PO Yes
Event

No Non-PO
Invoice Type?
RecurringRule Exclusive Or
XOR

Continue with requisition?

Self Billing
AND Rule - And
No
Credit/Refund

UBM Core PID Private and Confidential Page | 6

4. Application Scope
4.1 Application Diagram

Consolidatin data OBIEE Budget & Forecasts Final Long-term Plan

Other reporting data (e.g. KPIs)

Hyperion Financial Baseline Plan Hyperion Strategic

Management (HFM) Essbase Hyperion Planning data Finance (HSF)

Budget & forecast

data for consolidation

GL, AP, AR
information Data Relationship
COA data COA data
Management (DRM)
MI Systems (Hyperion Applications)

Budget /
Chart of Accounts
Forecast
Values & Hierarchies

2
E-Business Tax
GL Balances Revenue
Tax (EBT)
General Ledger 1
For consolidation Supplier costs Inter company Calculations
Recognition
Creditors (GL) transactions Tax returns
Debtors

Cleared banking
Bank Providers Payments Asset depreciation transactions Reminders Customers

Remitance
Suppliers Advice Fixed Assets Global Inter Receipts Bank Providers
(FA) Company
(AGIS)

Fixed
Accounts Asset PO Cash Accounts Debt information
i-Expenses costs Accruals
Advanced
Exps Payable Management Receipts Receivable / outstanding
(iE) invoices Collections
(AP) (CE) (AR)
2 1

Payments Customer
online access
iReceivables
Purchase Orders
Finance Systems (Oracle Financials) Orders & Returns

Order Pricing Advanced

Purchase Purchasing Information
Orders
Management Outbound
Pricing
(PO)
(OM) (QP)

Subscription
Requisitions based contracts Items /
Products

Service
Human Contracts Inventory
Approval i-Procurement
Teleservices Resource Hierarchies (SC)
(iP)
Management

Finance Systems HR Systems (Oracle Human Resource

(Other Oracle modules) Management) Finance Systems (Oracle Supply Chain Management)

Key
Standard
Interface
Oracle Oracle Oracle Oracle BI Other Oracle Hyperion External
Financials Custom
SCM HCM Analytics Modules Applications Parties
Interface

UBM Core PID Private and Confidential Page | 7

4.2 Order to Cash Process Flow
Order to cash functionality is divided into two processes: Order to Invoice and Accounts Receivable. The diagram given below demonstrates key sub-processes under each

of these processes:

UBM Core PID Private and Confidential Page | 8

4.3 Roles & Responsibilities
Each process flow is set out in swim-lanes, with each lane corresponding to a different Function. A complete
list of these Functions is listed below, along with their typical responsibilities.

Function Responsibilities

Sales Marketing

Manage prospects and fill sale pipe line

Maintain client relationship and expectations

Contract negotiation based on standard rate card or listed price

Correspond with in-house legal/Business manager/ Sales manager to

determine discounts allow (if applicable)

Work with billers to provide credit memos

Maintain contracts and individual sales volume/commission

Biller Identification of billing needs (work closely with the salesperson and
Business manager)

Ownership of sales orders

Creation and update of sales orders

Primary point of contact for all billing related queries

Business Responsible for defining new events

Manager/Brand Product
Manager Responsible for defining new Products / Brands

Defining billing schedule for the events/products

Determine Profit centres, sales account, and revenue recognition

schedule for the products, product types (like events, online, etc...)

Finance Analyst (UK Provide inputs to the Brand product manager for maintaining billing
specific) schedules, payment schedule

Provide inputs to the Brand product manager for maintaining product

revenue recognition schedule

Credit Manager (UK Activate new events

specific)
Manual invoicing and credit memos (e.g. for VAT related corrections)

Maintain updates on customer accounts (e.g. update billing address,

etc...)

Legal Analyst (UK Manage customer scrutiny function (outside oracle)

Specific)
Validate new customer account request

Apply and release legal holds on orders

UBM Core PID Private and Confidential Page | 9

 Credit Controller Accountable for tracking credit history of customers

Approval of credit control related holds

Finance Tax expert Provide Tax related inputs for new contracts

Maintain tax related information at the customer account level

IT Analyst Error monitoring on the invoice and receipts (lockbox) interface

Re-process error transactions

Setup and standing data maintenance

Customer Maintenance Responsible for maintaining new and existing customer data.

Apply customer level credit hold

Item Maintenance Responsible for maintaining new and existing product data.

Responsible for maintaining new and existing Item templates.

UBM Core PID Private and Confidential Page | 10

5. Process Integration Overview
5.1 Overview
The main Order Management processes and the interactions with other business activities can be summarised
as follows:
O2C Integration Overview:
Salesforce FatTail Artesia Ev2 Impoze Sendmyadd.com
CRM and Sales Production systems

Payment Portal EMS CARS Eventsforce ELCIPSNET

(UK) (ASIA) (UK) (UK) (UK)
ESOP ASOP IPSOP Other external
(UK) (UK) (UK) systems
External Sales Order Processing systems (SOP) (Banks)

Credit Order Lockbox

Items ** Orders Customers Receipts
Memos updates

Direct
Invoices
Inventory debit file
Item
Order Management

Advance Price
Collections
Pricing notes
Invoice

Accounts Receivables
Processes

Online
iReceivables VAT Payment
Collections
Processes

Journals Reconciliation
Advanced
Collections
Modules In-scope
for O2C
General Cash
E-Biz Tax
Ledger Managment

** Product information will be maintained manually in SOP and Oracle. No interface

As part of the project CORE, new global finance system (Oracle EBS R12) will be implemented. The new
finance system will be delivered in 2 phases. Legacy finance systems which are in scope of Phase 1 include:
JD Edwards - Tonbridge
Manhasset (Oracle 11iX)
ACCPAC UBM Asia

UBM Core PID Private and Confidential Page | 11

5.2 Order Import

5.2.1 Process Description

This process includes import of orders and return orders from different Sales Order processing (SOP) systems.
Orders (regular and return) will be imported into oracle from different SOP systems (like ESOP, ASOP, and
IPSOP). For US Manhasset, Orders will be entered manually in oracle but some of the ordering related
attributes (like opportunity id, square footage, booth number and size, etc) will be imported into oracle from
SFDC system - note that this is only for Canon orders.
In order to mitigate the dependency on the implementation and adoption of a single sales order processing
(SOP) platform, the point of integration have been classified under following six patterns:

UBM Core PID Private and Confidential Page | 12

Following SOP systems has been identified for the phase 1 of the project CORE:
Patterns of Integration

SOP System Division 0-A 0-B 1 2 3 4

Oracle OM Manhasset (US SSC Divisions)

ESOP Tonbridge (UK SSC Divisions)
ASOP Tonbridge (UK SSC Divisions, excluding UBM Aviation)
IPSOP Tonbridge (UBM Live)
CARS Tonbridge (BUM Built)
Phase 1

Events-force Tonbridge (UK SSC Divisions)

Eclipse-net Tonbridge (UBM Aviation - Rest of World)
EMS UBM Asia
AMS UBM Asia
Payment Portal Tonbridge (UK SSC Divisions)
Eclipse-net Tonbridge (UBM Aviation UK & NL)

5.2.2 Design Decisions

The following key system decision design decisions are en compassed in the Core solution:
Six patterns of integration are identified between the SOP systems and Oracle modules. These
patterns considers current SOP processes and their integration to finance systems, with the view that
these processes will not be re-engineered in the short term
Sales orders from the Sales Order Processing (SOP) system, completed and authorised for invoicing,
will be automated into Oracle; orders will maintain the originating system reference number to
facilitate easy reconciliation back to source
There will be a single standard Order import program developed for this purpose that will utilise
Oracle middleware to streamline and standardise the process to import sales orders into Oracle Order
management (pattern 0-B & 1).
A separate invoice import program will be developed to import invoices into Oracle receivables
(pattern 2 & 3) (Refer Receivables PDD for detail design for importing invoices in Receivables).
Also GL journal import program will be used to import the journals from the SOP systems into Oracle
general ledger module (pattern 4) (Refer the GL PDD for detail design of importing journals into
General ledger).
Order import interfaces will support import of regular sales orders and return orders (credit memo)
from SOP systems. For the open sales orders in Oracle (which are not yet invoiced), this interface will
also support import of order changes from SOP systems. For US Manhasset, the return orders / credit
memos will be created manually in Oracle.
Additional information will be available on the data extracted from SOP systems to identify the profit
centre and analysis segment at order line level. Other information required for invoice printing (like
billing instructions, AD titles, etc.) will also be provided from the SOP system.
Order cancellation in Oracle will be handled manually (no cancellation message will be received from
SOP systems).
For ASIA, invoices will be imported directly in Receivables. No sales orders will be created from ASIA
SOPs (EMS, AMS)

UBM Core PID Private and Confidential Page | 13

6. Order Management processing
6.1 Overview
Some of the business segments supported by the order processing functionality includes:

A. Events
Business manager/ Brand product manager will define the new Events in the SOP systems (like
ESOP, EMS, Events-force), or using custom Event maintenance function in Oracle Order
management (for US Manhasset only) and maintain billing related attributes (billing schedule, default
payment terms, etc.) for the event. Business manager/ Brand product manager will also be
responsible for requesting the creation of any new products - including capturing additional invoicing
related attributes. Note that it will be the Item Maintenance Team who are responsible for the actual
item setup in Oracle. Refer to the Item Maintenance PDD for details.
Contracts will be created by sales team (outside oracle) and once the contract is signed and events
are active, billing orders will be created (based on billing schedule).
Order to Invoice

Oracle External systems

(Sales-force)
Define events
Define products
(with billing schedule
(with applicable
and other invoicing
invoicing attributes)
attributes

On Receipt
When is invoice
of contract Create contract
created ?
Events US Process

Enter order/invoices
End of the month based on contract

Enter order/invoice Apply manual billing hold at line

transactions based on Bill in level based on billing schedule.
Yes
monthly spreadsheet (sent instalments ? Or book the order/ lines based on
by business office) the instalment date

Book the Auto-invoice

No
order the order / lines

External SOP system Oracle

Define events Define products
(with billing schedule and (with applicable
other invoicing attributes invoicing attributes)

Create Signed Enter order/invoices

contract contract based on contract
Events UK Process

Release the
Bill in order(based on
Yes
instalments ? instalment
dates)

No

Release
Book the Auto-invoice the
complete Import order
order order / lines
order/invoices

For US:
New products specific to an event will be defined in Oracle inventory management and same will be
used on the event orders entered in Oracle order management. The event code will be referenced to
the products, using item categories setup in item master.
Different billing terms/ schedules will be defined and agreed with customers for an event / product
and orders will be created manually in Order management based on the agreed billing schedule.

UBM Core PID Private and Confidential Page | 14

 Some examples for different billing schedules include:
For Tech-web, Game Developers conference events, the billing terms includes:
o 50% billed immediately, 50% billed 7 months before event with due date of 6
months before event.
For Tech-web, Black Hat Webcasts/ GDC Vault Recordings and Subscriptions events, the
billing terms includes:
o 100% billed immediately
For Channel, X-change Solution Provider/Midsize Enterprise Summit East events, the billing
terms includes:
o 10% billed immediately, 90% billed 60 days before event with due date of 30 days
prior to event
For Canon, 'Aero-con Texas' events, the billing terms includes:
o 10% billed immediately, 40% billed 9 month before the event, 50% billed 6 months
before the events.
Additional information will be maintained on the order line level (DFF) (like the event code (defaulted
from item categories), shows start and end dates, booth info, billing instructions, etc...).
Biller will manually initiate the billing of order lines by booking the sales orders. Biller will query the
order/lines for the specific issue date and do mass booking of the orders to initiate the billing for the
order lines. Biller will also be able to place orders / order lines on manual billing holds to defer the
invoicing of order/lines.
Revenue recognition period will be captured on the product setup, which will be used to control the
revenue recognition schedule for the invoice transactions.

For UK:
New products specific to an event will be defined only in the SOP systems (outside Oracle) and will be
referenced to a corresponding generic/homogenous product defined in Oracle (the generic product
will be used on the orders in oracle).
When an event is in active state, and the contract is in signed status, event orders/invoices will be
released from the SOP system based on the billing schedule.
Orders will be imported from the SOP systems (like ESOP) and will be automatically booked in Oracle.
Auto-invoice program will be used to create the invoice transaction in receivables.

Example An event contract will be created in the SOP system with the product Stand 10x10 sq m
and with the billing schedule as follows:
1st instalment of 50 % billed immediately
2nd instalment of 50% to be billed a month before the start of the event.
Other supplementary products also attached to the contract like registration feesinsurance
products with the billing schedule of 100% upfront (to be billed along with the first 50% of
stand cost)

Invoices are generally issued with 30 days payment terms attached. However there are two
exceptions to this rule:
o If the invoice is generated within the 45 days of the event start date, the payment terms
will be Payment Due Immediately. (This will be checked outside oracle and correct
payment term will be provided in the order data imported from external SOP).
o Cancellation of contracts Cancellation Invoices will also have payment terms due
immediately. For cancellation, Credit memo orders will be imported in Oracle and
applied against the original invoice to reduce the balance due.
(Also refer the appendix section for detail list of invoicing scenarios)

UBM Core PID Private and Confidential Page | 15

 B. Print
Business manager/ Brand product manager will be responsible for requesting the creation of any
new products - including capturing additional invoicing related attributes. Note that it will be the
Item Maintenance Team who are responsible for the actual item setup in Oracle. Refer to the Item
Maintenance PDD for details.
For the UK, billable orders are released from the SOP system (like ASOP) and interfaced into Oracle
based on the billing schedule. For Asia, invoices are passed direct to Oracle. For the US, orders are
manually entered and booked in Oracle based on the billing schedule.
Sales create contracts in SOP/ CRM system (like Sales-force) and once the contract is signed, insertion
orders will be released to finance system.
Order to Invoice

Oracle External systems External systems External systems

ITEM CODE FROM (Sales-force) (IMPOZE) (ARTESIA)
BUSINESS, SF OR FATTAIL. CLIENT NAME,
PRICE, SIZE, MATERIAL ATTN TO, BILLING ADDRESS,
INSTR, PLACEMENT, ORDRED BY, IO OR PO, INVOICE TYPE IO
SALESREP OFF OF IO/ CONTRACT,. OR CONTRACT #
CONTRACT. SALESFORCE OPP
NUMBER
Maintain Maintain
Enter Receive IO Sales creates
Line header
order Contract contract
details DFF
AD SIZES,
NAMES,
POSITION AND
Print US Process

No
ORDER # FROM
ORACLE.
Maintain
All ads entered
Line Yes
for the issue date?
DFF
Run IMPOZE Create
download new MAP
Edit MAP
(Note shell in
INSERTION ORDER,
IMPOZE#) impoze
SIZE, COMPANY
Issue date NAME , COLOR,
No Run IMPOZE
reached ? Send Page DELIVERY METHOD
upload
numbers to FOR AD, PRINTING
(Update Line
Oracle PLANT, SPEC
Yes DFF Page#)
INSTRUCTIONS
Open
Mass Book the
Artesia
orders (with same
(New form)
issue date)

Auto-invoice Artesia O/B- Rename AD files Pages

the order / for REPEAT by page number uploaded to
lines INFO(Line DFF from Oracle printing plant

External SOP system (ASOP) Oracle

Define products
(with applicable
invoicing attributes)

Enter order/
Create invoices
contract based on
contract
Print UK Process

Release the Hold order

Bill in order(based on line from
Yes booking
instalments ? instalment
dates)

No
No

Release
Charge copy Book the Auto-invoice the
complete Import order Yes
validated? order order / lines
order/invoices

For US:
Some of the print product used in this process includes:
Tech-web - Custom; Back of Book; Prod Charge; Barter; Other; Inserts; Display; Display-
Regional; List Rentals; Expense Reimbursement; Recruitment; Supplement; etc..
The orders will be manually entered into Oracle following the receipt of an approved insertion order
from the sales team. The Production team for print will use a report to identify all of the entered
orders for a particular issue date. Following their production activities, they will maintain the
additional information on the Order header and line level DFFs (descriptive flex-fields) that capture
additional billing related attributes.
This information is used while extracting the information for the IMPOZE system (external system to
maintain the AD maps details). Similarly, Page # information from the IMPOZE system will be
maintained at order line level.
Artesia system (database for AD Materials) is also integrated with Order management system (Oracle)
and information from Order line level DFF is extracted (Like page #, repeat info, etc...) and sent to
Artesia using a custom interface program.

UBM Core PID Private and Confidential Page | 16

 When the Production team have completed their production activities, they inform the biller that
they can book all of the orders for an issue. Using Oracle order organiser functionality, billers can
query for the orders with a specific brand and issue date (line level DFF) and can do mass booking of
orders and generate invoices in receivables.

For UK SOPs:
Orders will be imported in booked status and a charge-copy related hold will be applied (as required).
Authorised user (Biller) will be able to release the charge copy hold and book the order for invoicing
Some of the print product used in this process includes:
Classified Advertising, Colour Seps, Display Advertising, Editorial Related Advertising,
Recruitment Advertising, Cancellation charge, etc.
For the orders booked, auto-invoice program is used to create the invoice transaction in receivables.

C. Online
Business managers/ Brand Product manager will define the new products in the SOP system (like
ASOP, etc.) and maintain billing related attributes (billing schedule, payment terms, etc...)
Sales will create the contracts in SOP/ CRM system (outside oracle) and once the contract is signed,
insertion orders will be released to finance system (Oracle).

Order to Invoice

Oracle External systems (Sales-force)

ATTN TO, ORDRED CLIENT NAME,
ITEM CODE, PRICE, SIZE, BY OFF OF IO OR BILLING ADDRESS,
SALESREP OFF OF IO/ CONTRACT. PO, INVOICE TYPE
CONTRACT. SALESFORCE OPP OFF OF IO OR
NUMBER CONTRACT

Enter
lines for Maintain
Instalments Enter Receive IO Sales creates
billing Yes header
billing? order Contract contract
instalmen DFF
ts
Online US Process

No

Line with
100%billi Maintain All ads entered
No
ng line DFF for the issue date?
upfront

Yes
CAMPAIGN INFO,
NUM
IMPRESSIONS,RE Issue date
V MONTH, YEAR, No reached ?
etc...
Yes

Mass Book the orders

(with same revenue
month/ year)

Auto-invoice the
order / lines

External SOP system (ASOP) Oracle

Define products
(with applicable
invoicing attributes)

Enter order/
Create invoices
contract based on
contract
Online UK Process

Release the
Bill in order(based on
Yes
instalments ? instalment
dates)

No

Release
Book the Auto-invoice the
complete Import order
order order / lines
order/invoices

For US
Some of the online products used in this process include:
Banner Activity: Impressions of all banner positions across all sites; e-Newsletter
sponsorships;

UBM Core PID Private and Confidential Page | 17

 Custom Activity: Lead Generation programs, Micro-Sites, Tech-Centres, Blogs, etc.
Webcast Activity: Business manager creates a unique code for each Webcast for tracking
purposes
For US, the orders will be manually entered in Oracle and user can maintain the additional
information using the Order header and line level DFFs (descriptive flex-fields). These orders will be
invoiced during the month at campaign end date (identified based on the revenue month/year
maintained on the order line level customer request date field). Default Payment term for these
scenarios is Net 30 but can vary by client.
For some of the business segments (Tech-web/ Channel / Electronics) project bundle invoices will be
created with print and online products in the same order/invoice.
Billing process is initiated based on either sales confirmation or based on monthly spreadsheet from
the Business Manager (with inputs from Campaign Manager for banner and webcast/custom activity)
outlining what to invoice during a month for each program.
Using Oracle order organiser functionality, billers can query for the orders with specific revenue
month/year (Order line customer request date field) and can do mass booking of orders and
generate invoices in receivables.

For UK SOPs:
For UK SOPs, the billing invoices are released from the SOP system based on the billing schedule.
Some of the online products used in this process include:
Online Access Subs New ; Online Access Subs Renew; Online Exhibition Advertising; Online
Exhibition Sponsorship ;Online Newsletters; Online Prod Dir./Classified; Online Registration
Fee ;Online Registration ; Fee - OUT; Online Registration Fee - REV ; Other Online Exhibition
Revenue ;
Web - Survey Revenue ; Web - Video TV Revenue; Web / Online - Webinar Exhibit; Web /
Online Adverts - Business; Web / Online Adverts - ClasHol; Web / Online Adverts - display;
Web / Online Adverts - Exhibit; Web / Online Adverts - property; Web / Online Product -
Download; Web / Online Sponsor - Develop; Web / Online Sponsor - Newsletter; Web /
Online Sponsor - Seminar; Web / Online Syndication; Web Banner; Web Online Sponsor -
site, etc.
Orders imported from external SOP systems (ASOP) will be automatically booked and auto-invoice
program will be used to create the invoice transaction in receivables.

D. Intercompany

The intercompany sales orders will be entered in SOP (for UK) will be imported in Oracle. SOP will
send the reference to intercompany purchase order and Order import interface will validate the
purchase order reference on the intercompany sales order. If the purchase order reference is not
valid then order will be imported in entered status with an order hold to prevent billing.
Billers will monitor the orders on intercompany billing hold and once a valid PO reference is
available, biller will release the hold.
For US, intercompany orders will be entered manually in Oracle order management. New products
will be created for the intercompany orders with the required billing attributes (like Intercompany
sales account, profit centre, revenue recognition period, tax code, etc...). Custom validation will be
buildt to validate that valid PO reference is captured while booking the intercompany orders in OM.
Invoices for intercompany orders will be created via the Auto-invoice process and these invoices will
be communicated to payables entity (using delivery method / invoice to contact (Email) setup for the
intercompany customers).
Refer the detail process flow for the receivables functions for the intercompany commercial
transactions.

UBM Core PID Private and Confidential Page | 18

 Please note that this process is applicable only for the commercial intercompany transactions
between two legal entities. (Other intercompany transactions (like for cost allocations, Recharges,
etc...) will be handled through AGIS solution. Refer the PDD for A2R process)

Commercial Intercompany process

Request for
Intercompany
Order
Process
Payables

payment

Enter the purchase

requisition/order for
intercompany Intercompany
Payables
Business Manager

Create item with

billing attributes

Receive PO Import Print/ Email

Orders with Intercompany
details from Intercompany Intercompany
Enter Billing valid PO Y Receivables
requisitioner Orders invoices
Order in SOP reference
Sales

Process payment
Billing hold receipt
applied

Order ready
Biller

Coordinate with Y Release

Payables Manager to to release?
billing hold
resolve billing hold

Report for
Reconciliation (BSC)

Intercompany
Intercompany

reconciliation
Analyst

Legend Reconciliation
process

Transaction flow

E. Barter (Contra) Agreements

UBM utilises barter/contra arrangements (the terms are interchangeable) to trade for goods /
services by supplying a customer with services rather than paying them cash. Points to note:

1. Currently, in the US, barter transactions are accounted for with manual GL journals rather than
going through the relevant AP/AR subledgers. This process will be modified in the future such
that all barter transactions are processed through the subledgers.

2. The EU already processes these transactions via the subledger, but there is a complex
reconcilation process to ensure that AP/AR transactions are not settled and clear each other off
to reflect the value of the services provided/received. The EU SOP systems will continue to
interface their barter orders into Oracle OM.

3. Barter agreements will be setup usually for a limited time period and will not necessarily cover all
services provided to a particular customer for that period of time. As such, a method is needed
to distinguish barter transactions from transactions to be settled via cash. To allow this, specific

UBM Core PID Private and Confidential Page | 19

 transaction types will be setup in AR/OM to indicate transactions that are to be settled via barter
rather than cash.

4. Barter transactions are not settled via cash, however, it is still necessary to clear the AP/AR
transactions with payments/receipts (even though these are dummy payments/receipts as there
has been no cash movement). To support this, Oracle R12 provides functionality known as
Netting Agreements that can be used to link customer and supplier records in AR and AP
respectively. When setup, the netting agreement allows you to create a netting batch that
matches any open transactions in either subledger for linked customers. If the transactions
selected are related, Oracle will create dummy payments in AP and dummy receipts in AR (via a
shared dummy bank account). This clears the subledger balances without requiring cash
settlement. Please refer to the netting process flow in the AR PDD for details.

5. Netting agreements specify which transactions and customers are linked and can be netted. The
transactions that can be netted are restricted by:

a. Transaction type
b. Customer and optionally customer site
c. Supplier and optionally supplier site

6. As the barter agreements are only in place for the exchange of certain goods/services, and not all
transactions for a particular customer, it will be necessary to create additional customer/supplier
sites specifically for barter. This will ensure that any transactions raised in either subledger are
not inadvertently settled via cash.

7. To be able to account for these transactions correctly, specific Items will be created that account
for the revenue as barter, rather than cash settled, revenue. As we will have separate AR
transaction types for Barter, we can also utilise a separate AR debtor account to distinguish
Barter debtor balances in GL.

8. Barter transaction types in AR will have an alternative footer to be displayed on the printed
transaction that explains to the customer that the transaction is not to be settled via cash.

UBM Core PID Private and Confidential Page | 20

Below is the sales order management process overview:

The following sub processes exist in the Order Processing (OM-020) process:

OM-020-030: Manual Order Entry

This process includes the activities from receiving a sales request to creation of the order manually in
oracle and applying a manual hold on the order line to prevent booking. Once order line is ready for
billing order will be booked.

OM-020-090: Order Import

This process includes import of orders and return orders from different Sales Order processing (SOP)
systems. Orders (regular and return) will be imported into oracle from different SOP systems (like
ESOP, ASOP, and IPSOP). For US Manhasset, Orders will be entered manually in oracle but some of
the ordering related attributes (like opportunity id, square footage, booth number and size, etc) will
be imported into oracle from SFDC system.

OM-020-040: Book Order

This process includes the activities from booking a sales order (i.e... to confirm an order is a Firm
order) and to cover the process of releasing a hold on the order to control the progress of orders.

OM-020-050: Fulfil & Close Order

The process involves the activities and tasks to be executed to fulfil and close the sales order. This
includes process of interfacing the invoice data to Oracle receivables

OM-020-060: Order status inquiry and maintenance

This process covers the activities required to inquire an order and then perform maintenance /update
on the order.

OM-020-070: Cancel Order

UBM Core PID Private and Confidential Page | 21

 This process includes the activities involved in cancelling an order or order lines.

OM-020-080: Process Customer Return --

This process includes the activities to enter a customer return (manually) using various methods to
proceed to booking the return.

6.1.1 Design Decisions

The following key design considerations are identified for the order management solution design:

Sales orders from the SOP system(ESOP,ASOP and IPSOP) (completed and authorised for invoicing), will
be imported into Oracle based on agreed billing schedule; orders imported from external SOP system
will retain the originating source systems order reference number to facilitate easy reconciliation back
to source.

Price lists and associated discount modifiers will be created and maintained in Oracle. The ownership
of this data will remain local. Orders which are entered manually in oracle system will default zero price
on the order line and user need to manually enter the correct price on the order line. For UK SOPs
(ESOP, ASOP and IPSOP), the pricelist and discount information will be maintained in external SOP
systems and orders will be imported in oracle with the price information. These orders from UK SOPs
will not be re-priced in oracle.

For US Manhasset, Manual billing holds will be used to control the date when you raise the invoice for
a specific part of the order. Once the Orders / lines are booked it will be eligible for invoicing.

For the manually entered orders in Oracle, it should be possible to perform batch booking of orders by
querying the orders based on specific date (like issue date on line DFF) and then perform batch booking
for the set of orders.

The following key system decisions are encompassed in the Core solution:

Decision 1
ASIA SOPs will import invoice transactions

For Asia SOPs (EMS, AMS) transactions will be imported in Oracle as invoices. No sales orders will be imported
in Oracle from ASIA Sops (EMS, AMS)

Decision 2
Order status for interfaced orders
Based on the different SOP integration patterns, orders will be interfaced into the Oracle in entered or booked
status. Orders will be imported with booked status for UK ESOP, IPSOP and ASOP systems. For US Manhasset,
Orders will be entered manually in oracle but some of the ordering related attributes (like opportunity id,
square footage, booth number and size, etc) will be imported into oracle from SFDC system.

Decision 3
Deriving Tax on Sales Orders
For the UK, orders imported from the SOP systems (ESOP, ASOP), we will accept the tax code from SOP
systems and Oracle E-Biz tax setup will be used to derive the applicable tax rate.
For orders manually entered in Oracle, eBusiness tax will be used to derive the correct tax code and rate based
on the tax applicability of the item and the location of the supply and customer.

UBM Core PID Private and Confidential Page | 22

UBM Core PID Private and Confidential Page | 23
Example,

ESOP

Tax Code
Contract ASOP Order (Oracle will use the
Tax code to
Including calculated recalculate the tax
tax amount amount)
IPSOP

Customer Oracle
CARS

Tax Amount and

Eventsforce Code
Invoice Invoice (Oracle will accept
the provided tax
Eclipsenet amount)
Including calculated
tax amount
Payment
Portal

6.2 OM-020-030: Enter Order

6.2.1 Process Description

This process covers the activities from receiving a sales request to creation of the order (either imported or
manually created) with required validations where the order is then available to be booked.

6.2.2 Process Scope

The order entry functionality will support:

Entry of sales orders placed by sales for the purpose of regular sales of services to the customer
Entry of orders for generating invoices (debits) or credits
Maintenance of orders as per the contracts created for the customers. (contracts are entered outside
Oracle)
Entry of return orders for the purpose of capturing any corrections to the original orders and creating
credit memos
Business validations (through hold functionality) on sales order lines
Entry of applicable tax rate on the sales order lines

6.2.3 Process Controls

A Data Mapping spreadsheet has been provided in Appendix 1 containing the following properties of the fields
on the sales order:
Position of fields on sales order
Details of where a field can be found on a sales order form. The field can be at header level or line
level on a certain tab. For example, accounting rule for the sales order line is present at line level,
pricing tab.
Whether a field has to be entered manually or defaulted/derived
Using Data Mapping spreadsheet business user will be able to know whether a field is derived or
defaulted or has to be entered manually. For example currency at order header level will be taken
from the price list. If price list is not available then the currency will be defaulted from Set of Books
currency. Price list in turn will be defaulted from the item master level. Customer ship to and bill to

UBM Core PID Private and Confidential Page | 24

 location are defaulted from the customer master based on the manual entry of either the Customer
Name or Customer Number. Similarly unit selling price of the ordered item will be derived from
pricelist for US Medica (for other scenarios zero price will be defaulted on the order and manually
overwritten using the modifiers).
Mandatory fields
This document indicates the mandatory fields at header and line level. These mandatory fields will be
either entered by user or will be defaulted /derived.
Whether override/change is allowed after booking
The spreadsheet provides information on whether one can change the value of a field after an order
has been booked. For some fields, user is not allowed to change the value of fields after booking e.g.
in case of standard order, customer number cannot be changed after booking but price can be
modified (if the order line status is still open (say due to hold).
Change allowed till what order cycle stage
If the user is allowed to change the value of a field after order booking, the document indicates till
what stage of order cycle one can change the field value.
Rules for Defaulting/deriving values of fields
This document provides an insight on how fields are being defaulted /derived e.g. list price at order
line level will be defaulted from the price list present on the line.

6.2.4 OM-020-030: Manual Order entry Process Flow

Below is the OM-020-030: Manual Order Entry process flow:

Item Description
Sales Request
A Sales Request will be raised to create/update order and/or order lines.
Event
Customer details and requirements will be entered in an offline order sheet, which
will be made of one or more lines of sales information.

UBM Core PID Private and Confidential Page | 25

 Some key data elements of the sales request includes:
Order type - Type of order based on the line of business (Events, Data,
Online, Print, etc...)
Customer, customer address details Bill to , Ship to
Order Currency
Salesperson
Product
Price
Qty
Profit centre and analysis segment
Analysis/project
Billing date
Accounting rule Revenue recognition date
Other additional information for invoice printing (like billing instructions,
ad titles, size/shape, show start date, show end date, Booth #, size and
dimension, etc...)
Is it a new Customer?
Determine if the order is raised for an existing customer or a new customer. This
covers the following requirements:
Rules
- New Account
- New Address
- New Site
Process Interfaces Manual request for creation and amendment
(AR-010-010) Process of creating and maintaining customer records in Oracle.
Enter Order header data
Biller will enter the Sales Order header information in oracle based on the sales
request.
OM-020-030-020
Some of the information required for creating the order header will be defaulted
in the system (like pricelist, salesperson, accounting rule, etc...)

Create Sales Order Line

Biller will create Sales Order Line by selecting the items for the order. Some of the
required information will get defaulted on the sales order line level from order
OM-020-030-030 header, which can be updated at the line level). Billing and payment related
attributes will get defaulted from the item/product setup (like accounting rule,
profit centre, analysis segment, GL code, etc...)
(Refer the appended sheet in the appendix section for detail data field mapping)
Does item exist in item validation or master org?
System validates whether the item which is being entered on the order line is a
Rules valid item in the validation organisation or Item Master. If item is not defined in
the system then a new product needs to be setup

Create and Maintain Item

Process Interfaces The process includes the steps for creation and maintenance of the items in
OM-050-010 oracle. Items will be maintained in Oracle Inventory module and assigned to
respective item validation organisations.
Is item on the pricelist?
Rules System validates whether the item which is being entered on the order line is
existing on the pricelist. If not then the Item needs to be added on the pricelist
Create and Maintain Pricelist
Process Interfaces
The process covers the creation and maintenance of both Price and Discount Lists
OM-030-020
to support the order entry process.
Apply Price and Discounts
Biller will manually enter the price on the order line.
OM-020-030-040
System will default zero price on the order line and biller will manually enter the
correct price (using the price override modifier) on each order line.

UBM Core PID Private and Confidential Page | 26

 Price lists and associated discount modifiers will be created and maintained in
Oracle.

Enter/Update Additional Line Information

Biller will enter/Update Additional Line Information using line level descriptive
flex-fields.
For US Manhasset, canon orders some of the line level information (like square
OM-020-030-080 footage, booth number and size, etc) will be defaulted based on the opportunity id
entered at the header level. These additional details will be imported from SFDC
system and stored in custom tables.

(Refer the appended sheet in the appendix section for detail data field mapping, list
of DFFs and defaulting rule for these fields)
Is order information accurate and ready for billing?

Rules Biller will refer the date on the order (like issue date, instalment date, etc...) to
identify the billing schedule for the order/line. If the order is ready for billing then
the order will be booked.
Apply holds to order or line?
Biller will determine the need to apply a hold on the Order or Order Line(s) to
prevent billing of the order line?
Rules
This will be applicable for the scenario where only part of the order needs to be
billed. Then biller will apply manual billing hold on the order lines which are not
ready for billing.
Apply Holds to Order Header/Lines
OM-020-030-130 Biller will select the appropriate Hold to apply on the Order and apply a hold on
the order / line level.
Order status inquiry and maintenance
Process Interfaces
This process covers the activities associated with inquiry and maintenance of sales
(OM-020-060 )
orders throughout the lifecycle of the order.

6.3 OM-020-090: Order Import

6.3.1 Process Description

This process includes import of orders and return orders from different Sales Order processing (SOP) systems.
Orders (regular and return) will be imported into oracle from different SOP systems (like ESOP, ASOP, and
IPSOP). For US Manhasset, Orders will be entered manually in oracle but some of the ordering related
attributes (like opportunity id, square footage, booth number and size, etc) will be imported into oracle from
SFDC system.

6.3.2 Process Scope

This process covers importing orders from different SOP systems and automatically creating the sales orders in
oracle. Order data from different SOP systems will be populated in the custom staging table and any
additional information required to create an order will be derived before processing the data using standard
order import process.
All Tonbridge SOPs will be considered as a single interface and will be designed as a mapping of an
extract from Middleware into the designated tables in Oracle. It is assumed that the current
Middleware logic used to transform extracts from the various SOP systems will be retained in the
current or new Middleware. The responsibility for any redesign of Middleware logic is not the
responsibility of the CORE Finance Systems team

UBM Core PID Private and Confidential Page | 27

 It is assumed that any user functionality that currently exists in the Middleware will be retained or
redesigned in the new Middleware. The responsibility for any redesign is not the responsibility of the
CORE Finance Systems team. If a decision is taken to redesign this functionality within Oracle, this will
be considered as a new RICEW component
EMS & AMS are the only UBM Asia SOP systems in scope of integration with Oracle. Only Invoices (no
sales orders) will be imported from these SOP systems into Oracle receivables. (Refer AR PDD
document for further details)
For US Manhasset, all orders will be entered manually in Oracle order management. Additional order
related attributes (like opportunity id, booth info, etc...) will be imported from sales-force application
into Oracle custom tables. This information will be referenced while maintaining the additional details
on the sales order.

6.3.3 Process Controls

Orders will be imported from external SOP system for billing the customers. All Orders from SOP systems will
be validated and imported in order management in booked status (ready to be invoiced).
For the scenarios where manual control is required to manage the billing process, orders will be imported in
entered status and the biller will manually apply Manual billing hold on the order lines.

6.3.4 Sales Order Import Process Flow

Below is the Create Sales Order process flow:

Item Description

UBM Core PID Private and Confidential Page | 28

 Sales Request
A Sales Request is raised to create/update order and/or order lines. Customer
Event
details and requirements are entered into the on-screen order form, which will be
made of one or more lines of sales information.
Orders will be imported from external SOP systems (ESOP, ASOP and IPSOP). For
US Manhasset, order related attributes (like opportunity ID, square footage, booth
OM-020-090-100 number and size, etc...) will be imported in Oracle. Import Orders process captures
the process to validate and process the SOP order data into oracle. It also covers
processing of Credit Memo data from SOP system.
Monitor Error Records
This process includes activities to monitor any failed records in order import
OM-020-090-130 interface. Billers will be responsible for monitoring any error records in the order
import interface and will coordinate with IT analyst to resolve the error on the
failed records.
Modify records in interface table that has failed
This process includes activities to resolve any error records in order import
OM-020-090-110 interface table. IT analyst will be responsible for resolving/correcting any import
data related error records in the order import interface and will coordinate with
billers to resolve the error on the failed records.
Orders imported successfully
This process includes validation and defaulting of required information on the sales
orders imported in Order management.
Some of the validations required in order import includes:
1. Product information should be valid.
Product information will be maintained manually in SOP and Oracle
For UK, additional product mapping information will be provided on
the sales order data extract, to cross reference Oracle product
information with the actual products on the sales contracts in the
external SOP systems. Orders will be imported with generic products
defined in Oracle. Information for the specific products on the sales
contracts (in SOP) will be retained in order line level DFFs and these
products will NOT be defined in Oracle item master.
For US Manhasset, sales orders line details are entered manually and
specific products will be used. These products will be defined in
Oracle Item master.
2. Order types - Different order types will be defined in order management
to identify respective order header and line workflows and default other
OM-020-090-120 required information on the sales order ( like pricelist, warehouse, etc..)
Order import interfaces will support import of regular sales orders and
return orders (credit memo) from ESOP, ASOP and IPSOP systems.
Different order types will be defined in each OU and Line of Businesses
(like Events, Print, Data Services, Online, conference etc...)

(Refer the BR100 setup document for the list of order types)

SOP will send the separate order for the insurance products and it is
expected that SOP will never send the mixed orders with regular and
insurance products on the same order.
No additional validation will be built in the order import to split the orders
for insurance products.
The intercompany sales orders entered in SOP will be imported in Oracle.
SOP will send the reference to intercompany purchase order and Order
import interface will validate the purchase order reference on the
intercompany sales order. If the purchase order reference is not valid then
order will be imported in entered status with an order hold to prevent
billing. Billers will monitor the orders on intercompany billing hold and

UBM Core PID Private and Confidential Page | 29

 once a valid PO reference is available, biller will release the hold.

Contra (Barter) orders entered in SOP will be imported in Oracle with

Contra order types. These orders will be imported in booked status and
billed immediately. Contra transaction type will be defined in receivables
and additional setup will be maintained in receivables to manage AP-AR
netting process for the contra invoices. (Refer AR BR100 for the AP-AR
netting setup).

3. Order statuses will be used to control the billing schedule

For UK (ESOP, ASOP and IPSOP) orders will be imported in booked status
and will be billed immediately.

For US Manhasset, Orders will be entered manually and will be manually

booked by billers.

4. Price
For UK Tonbridge SOPs (ESOP, ASOP and IPSOP), orders will be imported
with sales price on the order line. Order lines will not be re-priced during
order import or in Order management.

For US Manhasset orders, lines will be entered manually and user will
manually enter the price on the order line. (Price override modifier will be
setup in oracle to allow the price update on the order line)

5. Tax code
For UK Tonbridge SOPs (ESOP, ASOP and IPSOP), orders will be imported
with tax code and tax rate will be calculated in oracle e-biz tax

For US Manhasset canon orders, lines will be entered manually and user
will manually enter the tax code on the order line and tax rate will be
calculated in oracle e-biz tax

6. Late charges --

This is applicable for UK ESOP a 2% Late charges needs to be applied on

the specific orders for Dutch UBMi BV customer orders. Only standard
order types for Dutch UBMi BV customers will have the late payment
charges but contra, prepaid, or intercompany invoices will not have the
2% late charges. A flag will be provided on the customer level to exempt
some key clients from the late payment charge. 2 % charges will be
calculated on the total amount (including the tax amount). Depending on
the country of the order (Event country for Event orders) an appropriate
tax code will be used to allocate the tax charges related to the late charge
line.

As per the Spanish tax requirement, all services performed for the
organization of events with commercial featuring, must be considered a
single supply of services for VAT purposes. Hence the Late payment
charges will be treated as ancillary to stands and therefore will be subject
to the general rules (i.e. taxed where the recipient belongs). Where the
customer is unable to provide a valid EU VAT number, we will charge

UBM Core PID Private and Confidential Page | 30

 them ES standard VAT.

Example,

Scenario 1: No VAT in the late payment charge for Countries such as

Holland

Goods VAT Total

Stand 10000 2000 12000
Late payment 240 0 240
10240 2000 12240

Scenario 2: VAT in the late payment charge for countries such as Spain,
Germany.

Goods VAT Total

Stand 10000 2000 12000
Late payment 200 40 240
10200 2040 12240

7. Revenue recognition
For transactions imported from SOPs (ESOP, ASOP, EMS, IPSOP), the
revenue recognition date will be derived based on the data from the
SOPs:

The revenue recognition date will be on the Order line level. If

only Month and Year is provided then will use 1st day of the
month.

For subscription orders (from IPSOP), subscription duration and

start date will be used to derive the revenue recognition date for
the instalments.

E.g. IPSOP Order data extract with subscription start date of 05th
MAR-2013 and duration of 3 months, will be mapped to revenue
recognition rule to have the revenue split in 3 equal instalments
i.e... With revenue recognition dates as 01-MAR-2013, 01-APR-
2013 and 01-MAY-2013.

For US Manhasset, Orders are entered manually in Oracle and revenue

recognition period and accounting rule will be defaulted on order line
based on product master setup.

Is the order status entered or booked?

<Rules> Orders will be imported in either entered status or booked. Depending the order
status order will be processed to the next stage

UBM Core PID Private and Confidential Page | 31

 Is order information accurate and ready for billing?

Rules Biller will refer the date on the order (like issue date, instalment date, etc...) to
identify the billing schedule for the order/line. If the order is ready for billing then
the order will be booked.
Book Order
Process interface
The process covers the booking of the order to initiate the fulfilment and closure of
OM-020-040
the order.
Fulfil and close order
Process interface
If the order is imported from external SOP in booked status then fulfil and close
OM-020-050
order process will be used to initiate the invoicing for these orders.
Order status inquiry and maintenance
Process interface Order status inquiry and maintenance process will be used to check if any updates
OM-020-060 are required on the imported orders.

Is the order ready for billing?

<Rules>
If the order is ready for billing then biller will submit the order for booking.

6.4 OM-020-060: Order status inquiry and maintenance

6.4.1 Process Description

This process describes the functionality available to search for an existing sales order. User can enter different
find criteria in the order organiser form and search for the specific orders. This process also covers the
functionality associated with making updates and changes on an existing order.

6.4.2 Process Scope

The order entry functionality will support:

Option to find an existing orders based on different search criterias
Ability to make changes on an open sales orders
Initiate cancellation of sales order

6.4.3 Process Controls

A Data Mapping spreadsheet has been provided in Appendix 1 containing the following properties of the fields
on the sales order:
Ability to make changes on an existing order. Please refer the data mapping sheet (Appendix 1) for
the list of data fields updatable at header and line level and provide information on whether one can
change the value of a field after an order has been booked. For some fields, user is not allowed to
change the value of fields after booking e.g. in case of standard order, customer number cannot be
changed after booking but price can be modified for the order lines which are booked but on billing
hold.

6.4.4 OM-020-060: Order status inquiry and maintenance Process Flow

Below is the OM-020-060: Order status inquiry and maintenance process flow:

UBM Core PID Private and Confidential Page | 32

 Item Description
Order status enquiry and maintenance
Biller will get a request to perform an order status enquiry and maintain the order.
Event
This request can come based on customer inquiry, or to initiate update on existing
orders.
Biller will use Order organiser functionality in oracle to find the order, allowing
OM-020-060-010 query orders by different order data elements (like order number, customer, item,
dates, etc..)
Does Order need Update?
Rules
Determine if the order or lines need to be updated or if this is pure inquiry mode.
Find and communicate status order/line
If no update is required, biller will view the status (of the entire order, or individual
OM-020-060-020
lines), and communicate to sales (if necessary). Communication will be done
outside the system (via email or call).
Is Cancellation required?
Rules Is the required amendment to cancel (fully or partially) the order as a whole or a
line or group of lines?
Cancel Order
OM-020-070 This process covers the cancellation of an order and/or order lines.
Biller will cancel the order / lines and communicate to sales (outside the system).
Is amendment type available?
Order Changes are restricted by user Responsibility and/or Order status. If the
biller is prevented from making the required changes then it should be
communicated to the requestor or if required order should be processed for credit
& re-bill process.
Change Order Information
Biller will make the requested changes on the order information and will provide
OM-020-060-040
the reason for the change. Once the order is booked and fulfilled (line is closed) it
will not be possible to make any changes on the order.
Is order information accurate and ready for billing?
Rules

UBM Core PID Private and Confidential Page | 33

 Biller will refer the date on the order (like issue date, instalment date, etc...) to
identify the billing schedule for the order/line. If the order is ready for billing then
the order will be booked.
Book Order
Process interface
The process covers the booking of the order to initiate the fulfilment and closure
OM-020-040
of the order.

6.5 OM-020-040: Book Order

6.5.1 Process Description

Biller will manually submit the orders for booking to initiate the invoicing. If a holds is applied on the sales
order lines then it needs to be released before the order can be booked. (For example, in US a manual billing
hold will be applied on the order lines to control the booking of order lines and hold will be released when the
order is ready to be invoiced)

6.5.2 Process Scope

In this process orders will be booked manually by billers. Orders from external SOP (ESOP, ASOP, and IPSOP)
can be imported either in entered status (for e.g.. from ESOP) or in booked status (for e.g.. print orders from
ASOP). If the order is imported in entered status then biller needs to manually submit the order for booking.

6.5.3 Process Controls

Biller will be authorised to submit the orders for booking to initiate the invoicing activity.

6.5.4 OM-020-040: Book Order Process Flow

Below is the OM-020-040: Book Order process flow:

UBM Core PID Private and Confidential Page | 34

 Item Description
Manual Order entry
Process Interfaces
This process will be called from Manual order entry process for the order lines
(OM-020-030 )
ready for billing.
Order Import
Process Interfaces
This process will be called from Order import process for the order lines which are
(OM-020-090 )
imported in oracle in entered status and which will be booked manually by biller.
Verify the Order Header/Line information
OM-020-040-010 Prior to booking the order make a final check against the order header and line
data on accuracy. If required run report.
Release hold required?
Rules Are there any holds that are applied or should there be any holds applied?

Release Holds to Order Header/Lines

When the order is ready to be invoiced Biller will release the holds that have been
applied against the order header and/or order line(s) either manually or
OM-020-040-060
automatically, running concurrent request.
E.g.... In US Manhasset, Manual billing hold will be released when the order line is
ready to be invoiced.
Book the order
Biller will submit the order for booking.
Biller can submit eligible orders for booking one at a time or can do mass booking
OM-020-040-040 by querying the orders using order organiser function in Oracle by billing schedule
date (issue date, instalment date line level DFF) and then select the records for
booking.
The order status will change from "entered" to "booked".
Process Interfaces Fulfil and close order
(OM-020-050 ) This process will be called when the line is successfully booked to initiate the

UBM Core PID Private and Confidential Page | 35

 activities and tasks to be executed to fulfil and close the sales order.

Order status inquiry and maintenance

Process Interfaces
This process covers the activities associated with inquiry and maintenance of sales
(OM-020-060 )
orders throughout the lifecycle of the order.

6.6 OM-020-050: Fulfill and close order

6.6.1 Process Description

This process covers interfacing the eligible order lines from order management to Accounts Receivables for
invoicing and accounting purposes. It also includes the functionality of releasing manual billing holds on the
eligible order lines which are ready to be invoiced

6.6.2 Process Scope

The order entry functionality will support:

Interfacing the eligible order lines to AR for invoicing
Releasing holds on the order lines

6.6.3 Process Controls

Following process controls will be defined for the Fulfil and close order function:
Holds will be released manually by the authorised users or can be released automatically based on
defined rules.
Auto invoice program will be scheduled to run to interface the eligible order lines to AR for invoicing.

6.6.4 OM-020-050: Fulfill and close Order Process Flow

Below is the OM-020-050: Fulfil and close Order process flow:

Item Description
Process interface Book Order
OM-020-040 Once the order line is successfully booked it will initiate the fulfilment and closure

UBM Core PID Private and Confidential Page | 36

 of the order.

Interface Orders to AR
Orders eligible for invoicing are interfaced from order management to Accounts
OM-020-050-020
Receivables for invoicing and accounting purposes.

Process interface Create transaction using auto-invoice

AR-030-060 Once the line is successfully fulfilled, order will be interfaced to receivables using
the Create transaction using auto-invoice process.

6.7 OM-020-070: Cancel Order

6.7.1 Process Description

Biller will initiate cancellation of an open sales order by querying an existing order in order management.
Order cancellation will be performed either at order header or line level. If an order header is cancelled then
all lines within that header are automatically cancelled.

6.7.2 Process Scope

Only open orders are allowed to be cancelled. This process will support ability to perform bulk cancellation of
orders / lines using order organiser functionality. Billers will query the orders based on order data elements
(like Order number, customer, bill to, dates, products, etc..) and then select multiple orders and do mass
cancellation of orders.

6.7.3 Process Controls

System performs specific validations to control which orders or order lines will be cancelled (for e.g. user
cannot cancel an already closed order / lines).
Additional processing constraints can be defined to prevent users from performing the operations of Cancel on
Sales orders and returns.

6.7.4 OM-020-070: Cancel Order Process Flow

Below is the OM-020-070: Cancel Order process flow:

UBM Core PID Private and Confidential Page | 37

 Item Description
Order cancellation required?
Event
Biller will confirm with sales/ customer if an order cancellation is required.
Has the order been invoiced?
Biller will check if the order is already invoiced or not. If the order is already
Rules
invoiced then it cannot be cancelled. If required biller will initiate the customer
return process to create credit memo.
Process Interface Order status inquiry and maintenance
OM-020-060 Billers will query the existing orders using the order status inquiry and
maintenance process and will initiate the cancellation process as required.
Process Interface Process customer returns
OM-020-080 Orders which are already invoiced, it will not be possible to cancel the orders. As
required, Biller will initiate the customer returns process to create credit memo.
User finds the order to cancel
Biller will query the existing orders using order organiser function and select the
OM-020-070-040
orders which need to be cancelled.

Cancel order in SOP

Event For the orders created in SOP, biller need to also cancel the order in SOP system
and then manually cancel the order in oracle
Cancel Order, Line, Partial Quantity Enter Reason Code
OM-020-070-030 Billed will be able to cancel Order / Line(s) fully or in part. Biller need to provide
the Cancellation Reason.
Is cancellation fee applicable?
Rule
Biller will identify if any cancellation fee is applicable for this cancellation request.
Order created in SOP?
Rule If the order which is being cancelled is created in SOP then the cancellation fee
order will be created in SOP
Enter cancellation order in SOP
Event Biller will enter a new order for cancellation fees in the SOP system. These orders
will be imported into oracle using Order import process (OM-020-090)
Enter cancellation order in Oracle
Event Biller will enter a new order for cancellation fees in the Oracle system using the
Manual order entry process (OM-020-030)

UBM Core PID Private and Confidential Page | 38

6.8 OM-020-080: Process customer returns

6.8.1 Process Description

Credit manager (UK) and Billers (US) will enter the return order for a correction (credit) for a previous sale. If
an original Invoice/Sales order reference is available, Credit manager (UK) and Billers (US) will use the Copy
order functionality to create the credit memo order from the original order in oracle. For the return orders
initiated in external SOP system, Credit manager (UK) and Billers (US) will provide the original order/ invoice
reference and the return orders will be imported in oracle with the reference to the original order.
If the original order reference is not available then Credit manager (UK) and Billers (US) will enter the credit
memo manually from the sales orders screen. In this case need to manually update the price on the sales order
line. While entering the information on the order, Credit manager (UK) and Billers (US) r has to specify the
appropriate reason for the credit memo order.
The price list on the order will be a multi currency price list and biller can select the currency on the order.
The user will book the credit memo order line to interface the order to receivables.
Any approval required for entering the credit memo order in Oracle will be managed outside the system and
once approved Credit manager (UK) and Billers (US) will enter the credit memo order in Oracle.

6.8.2 Process Scope

The order entry functionality will support:

Creation of return orders / credit memos with reference to original sales orders/ invoices
Creation of return orders/ credit memos without reference to sales orders / invoices

6.8.3 Process Controls

Credit manager (UK) and Billers (US) will be authorised to enter the return orders / credit memos in the
system.

6.8.4 OM-020-080: Process customer returns Process Flow

Below is the OM-020-080: Process customer returns process flow:

UBM Core PID Private and Confidential Page | 39

 Item Description
Customer return required?
Event Credit Manager will determine if any customer return is required? And will initiate
the request for processing the customer return/credit memo in the system.
Manual or automatic?
Determine how the return order is created, manual entry in Order Management
module or import from SOP system.
Rules For US Manhasset, the credit memos will be entered manually in Order
management by the Biller, and for UK SOPs (like ESOP, ASOP, IPSOP) credit
memos will be entered in the external SOP system and interfaced to Oracle Order
management
Order Import
Order Import process will be used to bring the return orders/ credit memo orders
OM-020-090 into oracle from external SOP systems (like ESOP, ASOP, IPSOP)
Return Orders will be imported in booked status and will be interfaced to
receivables immediately.
Copy?
Create return order using copy function?
Rules
If the original order/invoice reference is available, Biller will use the copy order
function in oracle to create the return order.
Create Return Order from Original by Copy
Biller will create the return order by copying the original order and changing the
OM-020-080-020
order type to a return type. Additional information will be entered on the order to
capture the reason for return
Create Manual Return
Biller will use the Manual order entry process to enter the return orders manually
in the system. This process will be used if the original order/invoice reference is
OM-020-080-030 not available and return / credit memo will be created without any reference to
original order/invoice. Enter Order Header and Order Lines for the return
(Refer the appended sheet in the appendix for the detail fields which will be
entered manually at header or line level)
Process interface Book Order
OM-020-040 Once the order line is successfully booked it will initiate the fulfilment and closure
of the order.

UBM Core PID Private and Confidential Page | 40

 Update & Validate Return Order
For return orders entered manually in Oracle, the Biller will review the return
order and lines, amend or update the return header or lines details before
OM-020-080-080
submitting the order for booking.
Review and make sure the products, price and reason for return / credit memo is
captured correctly.

UBM Core PID Private and Confidential Page | 41

Open / Closed Issues
Target
Sl. No. Issue Resolution Responsibility Status
Date

1 Derivation of divisions on the order header level Not required. Division will Closed
be maintained as attribute
for the profit centre and as
required will be derived
based on profit centre

2 Analysis segment at order line level. Will it maintain Analysis segment will have Closed
year and month for the revenue recognition month YYYYMM for the balance
and year or the campaign name? sheet account and project
code for the P&L revenue
account

3 Mapping details for additional order attributes from Interface will be build Closed
SFDC between SFDC and Oracle
R12

4 Pre-Paid orders No payment information captured UK IT Open

in SOP. Orders are imported like standard orders.
Confirm if the pre-pay payment term will be sent for
the pre-paid orders

5 Intercompany orders from SOP. Current SOP UK IT Open

interface is not processing any intercompany orders
from SOP. In order to automate the creation of
intercompany orders in Oracle, SOP Oracle
interface needs to be enabled

UBM Core PID Private and Confidential Page | 42

Appendix

Appendix 1: Data Mapping Spreadsheet

https://ubm.box.com/files#/files/0/f/419558490/Completed_for_Review

Appendix 2: Fields on sales order

Certain fields on the sales order need to be entered manually while others will be defaulted based on the fields
that have been entered manually.
Details on the fields that will be defaulted are discussed below.
Defaulting Customer Ship To and Bill To at order header level
Customer Ship To and Bill To will be defaulted from customer master information. Customer Master
information will be defined and maintained by the Customer Maintenance team (US) or interfaced into
Oracle for external SOPs (UK and Asia). For details refer PDD Customer Master Maintenance.
Defaulting Price List at order header level
Price List will be defaulted from Customer Ship To or Bill To in the same priority.
Defaulting currency at order header level
Currency will be defaulted from price list or set of book currency in the same priority.
Defaulting Request Date at order line level, main tab
Request Date will be defaulted from Customer Request Date present at sales order header.
Defaulting Line Type at order line level, main tab
Line Type will be defaulted from order type present at header level.
Defaulting Tax Code at order line level, main tab
Tax Code will be sent from SOP system. For manually entered orders Tax code will be entered manually
and Tax rate will be derived from E-biz tax.
Defaulting Sales-rep at order line level, main tab
Sales-rep will be defaulted from ship to at order line, addresses tab or Bill to at order line, addresses tab
in the same sequence.
Defaulting Price List at order line level, pricing tab
Price List will be defaulted from Customer Ship To or Bill To in the same priority.
Defaulting List Price at order line level, pricing tab
List Price will be defaulted from price list.
Defaulting Ship To and Bill To at order line level, addresses tab
Ship To and Bill-To will be defaulted from order header.
Defaulting Payment Term, pricing tab
Payment Terms will be maintained on the customer master. Credit manager will maintain payment
terms in the Payment terms screen for a Bill To of a customer. Payment term for SOP orders will be sent
from SOP system
Defaulting Accounting rule, pricing tab

UBM Core PID Private and Confidential Page | 43

 Accounting rules will be maintained on the item master. Finance user can request the creation of
specific accounting rules to a product in item master. These accounting rules can be changed at order
line level.

For orders imported from SOP system, Accounting rules will be derived based on the revenue
recognition date parameters from SOP (like issue date/instalment date, etc.)

UBM Core PID Private and Confidential Page | 44