Whitepaper - OrderToCashSolutionAproach PDF

Oracle AIA for Communications –
Order to Activate Solution Approach
An Oracle White Paper

May 2012
Oracle AIA for Communications – Order to Activate Solution Approach.
Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,
license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.
Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf
of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical
data delivered to U.S. Government customers are "commercial computer software" or "commercial technical
data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the
restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable
by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial
Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA
94065.
This software is developed for general use in a variety of information management applications. It is not
developed or intended for use in any inherently dangerous applications, including applications which may
create a risk of personal injury. If you use this software in dangerous applications, then you shall be
responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use
of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of
this software in dangerous applications.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
This software and documentation may provide access to or information on content, products, and services
from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all
warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its
affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of
third-party content, products, or services.
This documentation is in prerelease status and is intended for demonstration and preliminary use only. It
may not be specific to the hardware on which you are using the software. Oracle Corporation and its
affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this
documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this
documentation.
The information contained in this document is for informational sharing purposes only and should be
considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement
only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in
making purchasing decisions. The development, release, and timing of any features or functionality
described in this document remains at the sole discretion of Oracle.
This document in any form, software or printed matter, contains proprietary information that is the exclusive
property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions
of your Oracle Software License and Service Agreement, which has been executed and with which you
agree to comply. This document and information contained herein may not be disclosed, copied,
reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is
not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or
its subsidiaries or affiliates.
Guidelines for Building an Order to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4 – An Oracle Whitepaper
Table of Contents
Oracle AIA for Communications – Order to Activate Solution Approach ..................................... 4
Preface ..................................................................................................................................... 4
Oracle AIA for Communications and Order to Cash Solutions ................................................ 4
Getting Started ......................................................................................................................... 6
Business Benefits Drive Design Criteria ............................................................................... 7
Order to Activate Business Process Flows .............................................................................. 7
Understanding the Order Capture Sub-Flow ........................................................................ 8
Understanding the Deliver Customer Order Sub-Flow ......................................................... 9
Understanding the Qualify Customer Order Sub-Flow ....................................................... 10
Order to Activate Design Considerations ............................................................................... 11
Order to Activate Deployment Topology Design Considerations ....................................... 11
Product Definition and Mapping Design Considerations .................................................... 14
Order Update Design Considerations ................................................................................. 17
Revision Orders Design Considerations ............................................................................. 19
Billing Fulfillment Design Considerations ........................................................................... 22
Multiple Features Design Considerations ........................................................................... 25
Order Management Integration Design Considerations ..................................................... 28
Order to Activate Sample Use Cases .................................................................................... 30
Use Cases Setup ................................................................................................................ 30
Double Play Promotion First-Time Purchase ..................................................................... 37
Double Play Change Order................................................................................................. 40
Double Play Revision Order ............................................................................................... 45
Communications Orders Dictionary ....................................................................................... 51
Communications’ Orders - Order Header Component Attributes ....................................... 51
Communications Orders - Order Line Component Attributes ............................................. 56
3
Oracle AIA for Communications – Order to

Activate Solution Approach
Preface
This guide provides a description of the approach used to implement the Order to Activate
business process through the Oracle AIA for Communications Order to Cash Process Integration
Packs.
This guide assumes basic knowledge of AIA, Siebel and Order Management functionality and
terminology.
Oracle AIA for Communications and Order to

Cash Solutions
Communication Service Providers (CSP) face numerous challenges today: increased
competition, rapidly changing market demands, pressure to launch more offers faster, control of
operational expenses, and strengthening customer relationships. One of the keys to successfully
navigating these challenges is to view them holistically while focusing locally on the highest
impact areas.
To help CSP with this challenging Oracle provides the most comprehensive Concept to Cash
solution offering for faster system implementation, enhanced customer experience, fast time to
cash, and operational cost savings.
Oracle AIA for Communications is an essential component of the Oracle Communications
Concept to Cash Solutions offering as it provides key extensible process integrations for the
Rapid Offer Design and Order Delivery (RODOD) solution and the Unified CRM and BRM (UCB)
solution.
Oracle Communications Concept to Cash Solutions offering also include the Rapid Service
Design and Order delivery (RSDOD) solution as its OSS solution component covering the service
fulfillment part of the Concept to Cash process.
The overall Oracle Concept to Cash solution offering is captured in the following diagram.
4
Oracle Communications Concept to Cash Solutions Offering

The RODOD solution enables service providers to rapidly design and introduce offers, capture
and fulfill orders efficiently and accurately, and provide visibility across the entire order lifecycle.
In order to enable its three key capabilities of offer design, order capture, and order delivery, the
RODOD solution leverages several AIA for Communications components: Foundation Pack
Extension for Communications, Communications Order to Cash PIP, and Product MDM PIP. The
Oracle applications on which the core solution is built are Oracle’s Siebel CRM, Oracle
Communications OSM, Oracle Communications BRM, Oracle Product Hub for Communications,
and Oracle Communications Design Studio.
Oracle Communications RODOD Solution

The UCB solution enables service providers to maximize customer value through unified
customer lifecycle management, personalized offers and interactions, and extreme business
flexibility to meet ever-changing market demands. The UCB solution leverages several AIA for
Communications components: Foundation Pack Extension for Communications, Communications
Order to Cash PIP, and Customer MDM PIP. The Oracle applications on which the core solution
is built are Oracle’s Siebel CRM, Oracle Communications BRM, and Oracle Customer Hub.
Oracle Communications UCB Solution

Both RODOD and UCB solutions have been certified by TM Forum as Frameworx compliant
solutions. Compliance results are available at
http://www.tmforum.org/ConformanceCertification/10660/home.html.
5
Getting Started
The Order to Activate business process is at the core of business and operational support
systems for any Communications Service Provider (CSP), and it directly affects the provider’s
bottom line. The process extends from the time a quote or order is created to the time when the
services and goods are delivered and properly billed. The Order to Activate process also has
strong ties to product and service life cycle management.
Within the Oracle Communications Order to Cash Solutions the RODOD solution enables the
Order Capture and the Order Delivery pieces of the Order to Activate business process. RODOD
also cover the product lifecycle management process while RSDOD covers the service lifecycle
management processes.
A central piece of the Order to Activate solution is the Order Lifecycle Management system.
Traditionally, CSPs deployed stovepipe BSS and OSS solutions with middleware-based custom
order orchestration solutions. Deployment consolidation for cost savings, convergent bundling,
and time to market demands are fostering increasingly complex requirements for the
orchestration solution. These requirements include sophisticated order mapping, order
decomposition, status composition, fallout management, changes to in-flight orders, future-dated
orders, and cross order dependencies, among others. All of these requirements cannot be easily
achieved through middleware-based custom solutions. Oracle, along with a large group of leading
CSPs, concluded that a prominent and distinct role exists for a commercial off-the-shelf (COTS)
Order Lifecycle Management solution. This concept is what this guide recognizes as the Order
Management solution responsible for the Central Fulfillment functionality.
The following chart illustrates a typical Order to Activate deployment topology. The Order
Management system is at the center of this topology.
General Ledger General Ledger

CRM Payment
Order
Payment
Payment &
Payment && Payment&&
Payment &
Collections
Collections Collections
Collections
Collections
Capture Collections
BRM-WLS BRM-REZ BRM-BIZ
(Wholesale) (Residential) (Business)
Order Management (Central Fulfillment)
Provisioning Provisioning Provisioning

VoIP UK DSL DSL
PartnerInc
Shipping
Shipping
InHouse
Service
WFM
CRM
Activation Activation Activation

All
VoIP UK DSL DSL

Network Network Inventory
Inventory DSL
6
The topology shown is typical of most CSPs, although many could include more fulfillment system
types and fulfillment system stacks. Order Management is at the center of the Order to Activate
Deployment with one or more Order Capture systems passing orders to the Order Management
system. The Order Management system decomposes the order into sub-orders, each of which
targets a particular fulfillment provider (that is, system instance); we call these order components.
The topology shown uses three billing providers based on customer segment: Wholesale,
Residential, and Business. It uses three provisioning stacks based on service family and
geography: VoIP, UK DSL, and DSL. It uses two SCM providers, one for in-house products and
another for partner supplier products. Finally, it uses one Work Force Management provider and
one separate CRM Service provider (for trouble ticketing).
Business Benefits Drive Design Criteria

Order to Activate design should match the sought after business benefits. Oracle’s extensive
work with customers and prospects revealed the following business drivers. The business drivers
are reflected directly in the design criteria adopted by Oracle.
Business Benefits / Driver Design Criteria

Fast time-to-market Decouple commercial offerings and
fulfillment flows.
• Once identified, introduce more of the same
commercial offerings within hours. Enable product- and order-driven
fulfillment flows.
• Once identified and the infrastructure is
ready, introduce new services within days.
Low-cost, agile deployment Decouple fulfillment topology and
fulfillment flows.
Superior visibility and experience Enable a configurable and
streamlined order fulfillment status.
Lower cost of fallouts and enhanced customer Control fallout conditions.
experience
Manage fallout incidents.
These business drivers vary in priority among CSPs as a reflection of deficiencies in current
deployments. The design criteria elements listed are described in detail in the Order to Activate
Design Considerations section of this guide.
Order to Activate Business Process Flows

Logically and for ease of understanding, the Order to Activate business process is described in
the following subsections:
 Understanding the Order Capture Sub-Flow
 Understanding the Deliver Customer Order Sub-Flow
 Understanding the Qualify Customer Order Sub-flow
This guide focuses on the elements of the Order to Activate business process flow that are
relevant to its integration with Order Management. It describes:
 Inbound and outbound integration points with Order Management for deliver and qualify
customer order sub-processes.
7
 Functional expectations for product model and product mappings to facilitate order
fulfillment.
 Functional methodology governing the distribution of roles across Siebel, Order
Management, and key fulfillment systems, primarily Billing and Provisioning.
 Available AIA assets to leverage for building the Order to Activate business process.
Understanding the Order Capture Sub-Flow

The following chart illustrates a typical Order Capture flow. This flow varies by CSP and may vary
by service family, customer segment, line of business, and others. Two important integration
points between CRM and Order Management are shown for Qualify Customer Order and Deliver
Customer Order. In Siebel, the Customer Order is known as the Sales Order. In general, order-
based system interactions between different BSS and OSS systems require that order
decomposition and orchestration go through the Order Management layer. For the Order to
Activate flow, at least two system interactions exist: Qualify Customer Order to validate the
availability of a service design and the capacity to fulfill the customer order; and Deliver Customer
Order to fulfill the products and services purchased by the customer.
AIA for Comms: Order to Activate Functional Flow

ORDER CAPTURE SUB-FLOW
Check /
Create
Account
Make Inventory Technical Schedule
Product Physical
Product Pricing Resource Service Appointment Submit Order
CRM
Validation Good ATP

Choices Reservation Qualification (WFM)
Run Credit
Check
Order Lifecycle
Management
Legend
Qualify Deliver
Optional AIA Based Within
Application
Application Integration Product Customer Order Customer Order
Activity
Activity Points Flow
How to read this Order Capture Sub-Flow chart:

This chart shows two swim lanes, one for CRM and another for Order Management. Each swim lane includes the
typical application activities and user interactions part of that application. Arrows between such activities represent
the typical sequence of events within the same application. Arrows across swim lanes represent system interactions
across applications. See the legend on the chart for other details.
A typical flow starts with creating new customers and updating existing customer information.
Depending on customer segment or line of business, among other considerations, customer
information may be captured earlier, for example when an opportunity or quote is created, and
then updated during order capture. Depending on its business policy, some customers may pass
through a credit check before starting the process of making product choices. While making
product choices and at other points in the process, such as while capturing an order, the CRM
system performs several validations. Selected products and product options are priced following
relevant pricing logic. When physical goods are involved, the order capture process typically
checks availability to purchase. For some services, resource reservation (for example, a phone
number) also occurs during order capture. Before an order is submitted and depending on the
business practices of the CSP, the order may need to pass a technical service qualification.
Some CSPs also require scheduling an engineer (when needed) at the time of order capture to
synchronize both the availability of an engineer and a customer. When an order is complete and
validated, it is submitted to start the delivery process.
8
Understanding the Deliver Customer Order Sub-Flow

The following chart illustrates a typical Deliver Customer Order flow:

DELIVER ORDER SUB-FLOW
Order Submit Order Create/Update Update Create/Update

CRM
Capture (New, Revision, Follow-on) Trouble Ticket Order & Status Customer Assets
A+B O2A A+B
Orchestrate Order: Transform / Enrich Order; Decompose & Route Order Components
Order Lifecycle
Transform
Management
Decompose Order, Route Order Components Order Status

/ Enrich Manage Fallout
& Listen to Responses and Updates Management
Order
Update
Order & Status
Sample Central Sync Initiate Provision Update Fulfill
Fulfillment Customer Billing Order Order Billing
Deliver Flow
O2B O2B O2A O2B

Billing
Sync Various APIs

Various APIs
Customer
O2A
Provision Order: Transform & Enrich Order; Decompose Order and Provision Services
Provisioning
* Deliver Service involves

Transform
execution of a provisioning Decompose Design Deliver Order Status
/ Enrich
flow Order Service Service * Management
Order
Inventory
Network
Legend
Design
Application Application Flow Optional O2A O2B A+B Service
Activity APIs Activity Activity Order To Bill
Order To Order To & Order To
SI Provided Activate Bill Activate
AIA Based Within
Activa-
Point to Integration Integration Common AIA

Integration Product
tion
Points Flow
Point Point Point Integration Various APIs
Integrations Point
How to read this Deliver Customer Order Sub-Flow chart:

This chart shows six swim lanes, one for each of the following applications: CRM, Order Management, Billing,
Provisioning, Network Inventory, and Activation. Each swim lane includes the typical application activities and user
interactions part of that application. Arrows between such activities represent the typical sequence of events within
the same application. Arrows across swim lanes represent system interactions across applications. The AIA
diamonds between swim lanes represent Oracle’s existing or planned AIA-based integration points. The diamonds
are labeled O2A for integration points part of Order To Activate, O2B for integration points part of Order To Bill and
A+B for integration points common to both. See the legend on the chart for other details.
There are three kinds of customer orders that an order management need to recognize:
1. New orders: orders for new purchases or changes to already delivered products. Already
delivered products are known as customer assets.
2. Revision orders: amended version of an already submitted to fulfillment order. Revision
orders can be submitted to fulfillment while the amended order is in a fulfillment state that
allow for order amendments.
3. Follow-on orders: orders that has fulfillment completion dependency on other orders.
This flow starts with a new order, a revision to an order, or a follow-on order submitted from CRM
to Order Management. Order Management performs these key functions:
1. Transforms and Enriches the Order. It maps order lines to fulfillment flows and enriches with
fulfillment metadata and other relevant data.
9
2. Decomposes and Routes the Order. It divides the order into sub-orders, called order
components, which have cross order component, cross order line and cross order
dependencies, to reflect the specific demands of the CSP. The outcome is an Order
Orchestration Plan that is executed at the computed Fulfillment Start Time to meet the
Requested Delivery Date. This chart shows a simple flow; a typical flow is more complex, as
shown in the Sample Use Cases section of this guide. The produced fulfillment flow
orchestrates fulfillment requests to different fulfillment providers using preconfigured
fulfillment functions, such as Sync Customer into Billing, Initiate and Fulfill Billing, Provision
Order, Ship Order, and Install Order. The Decompose and Route Order function of Order
Management also generates compensation plans associated with revision orders.
3. Manages Fallout: It provides for detection, reporting, and resolution of order fulfillment fallout
conditions such as system, validation, and fulfillment errors. Oracle’s approach creates
Trouble Tickets in CRM to take advantage of the rich notification, reporting, and management
capabilities of CRM.
4. Manages Status: It maps fulfillment function responses to common statuses, which are then
aggregated into order line statuses and order header status values. The status management
capability updates CRM with relevant customer status and milestone values. It also updates
CRM when order lines reach their point of no return to prevent the submission of new
revisions.
Understanding the Qualify Customer Order Sub-Flow

The following chart illustrates a typical Qualify Customer Order flow:

QUALIFY ORDER SUB-FLOW
Order Technical Service Qualification Create/Update Update

CRM
Capture (via submit order API) Trouble Ticket Order & Status
A+B O2A A+B
Orchestrate Order: Transform / Enrich Order; Decompose & Route Order Components
Order Lifecycle
Transform
Order Status
Management
Decompose Order, Route Order Components

/ Enrich Manage Fallout
& Listen to Responses and Updates Management
Order
Update
Order & Status
Sample Central Provision Update
Fulfillment TSQ Flow Order Order
O2A
Billing
O2A
Provisioning
Provision Order: Transform & Enrich Order; Decompose Order and Provision Services
Transform
Decompose Design Order Status
/ Enrich
Order Service Management
Order
Inventory
Legend
Network
Design
Flow
Application Application
Activity
O2A A+B Service
Activity APIs
Order To Order To Bill
Activate & Order To
SI Provided AIA
AIA Based Within Activate
Activa-
Point to Integration
tion
Integration Product Common AIA

Point Point
Points Flow Integration
Integrations
Point
How to read this Deliver Customer Order Sub-Flow chart:
10
This chart shows six swim lanes, one for each of the following applications: CRM, Order Management, Billing,
Provisioning, Network Inventory, and Activation. Each swim lane includes the typical application activities and user
interactions part of that application. Arrows between such activities represent the typical sequence of events within
the same application. Arrows across swim lanes represent system interactions across applications. The AIA
diamonds between swim lanes represent Oracle’s existing or planned AIA-based integration points. The diamonds
are labeled O2A for integration points part of Order To Activate and A+B for integration points common to Order To
Activate and Order To Bill. See the legend on the chart for other details.
This flow starts with a request to qualify the technical validity of a customer order submitted from
CRM to Order Management. Order Management performs the same four functions detailed for
the Deliver Customer Order with one key distinction: the metadata used and the fulfillment flow
produced are for qualifying the customer order rather than delivering the customer order. Of
course, Deliver Order and Qualify Order flows produce different order and order line status
updates.
Order to Activate Design Considerations

The following sub-sections provide general design considerations for choosing an Order
Management solution and for implementing an Order to Activate business flow. These design
considerations align with the design criteria and business drivers described in the Getting Started
section.
Order to Activate Deployment Topology Design Considerations

One key design criterion for the Order to Activate topology is to decouple fulfillment topology from
products and fulfillment flows. Thereby increasing the agility of the CSP solution, reducing costs
for maintaining fulfillment flows, and decreasing the time to market when introducing new
products. The following diagram shows a simplified but typical CSP fulfillment topology suitable
for this discussion:
11

CRM Payment
Order
Payment
Payment &
Payment && Payment&&&
Payment
Collections
Collections
Collections
Capture Collections

VoIP UK DSL DSL
PartnerInc
Shipping
Shipping
InHouse
Service
WFM
CRM

All
VoIP UK DSL DSL

Inventory DSL
The Order Management system must be able to recognize the source of the order and respond to
the source system with order status and data updates. In this diagram, the source system is the
CRM Order Capture system.
The Order Management system recognizes fulfillment systems by type. The following diagram
overlays system types on the topology we are discussing:

CRM Payment
Order
Payment
Payment &
Payment
Collections
Collections
Collections
Capture Collections

VoIP UK DSL DSL
PartnerInc
Shipping
Shipping
InHouse
Service
WFM
CRM

All
VoIP UK DSL DSL

Inventory DSL
For each fulfillment system type, the Order Management system recognizes the fulfillment
functions available for orchestration. The following diagram, overlays the fulfillment functions
(abstracted as numbers) and shows a sample fulfillment flow:
12

CRM Payment
Order
Payment
Payment &
Payment
Collections
Collections
Collections
Capture Collections
(Wholesale) 1(Residential)
2 (Business)

7
1 8 9 2
3
9 10 8 7 3
Provisioning 4 5
Provisioning 6Provisioning
VoIP UK DSL DSL
PartnerInc
Shipping
Shipping
InHouse
Service
WFM
CRM

All
VoIP UK DSL DSL

Inventory DSL
When executing the fulfillment flow, the system uses routing rules to route a fulfillment function
request to the relevant fulfillment system provider, as shown in the next diagram:

CRM Payment
Order
Payment
Payment &
Payment
Collections
Collections
Collections
Capture Collections
(Wholesale) 1(Residential)
2 (Business)

7
1 8 9 2
3
9 10 8 7 3
Provisioning 4 5
Provisioning 6Provisioning
VoIP UK DSL DSL
PartnerInc
Shipping
Shipping
InHouse
Service
WFM
CRM

All
VoIP UK DSL DSL

Inventory DSL
This approach abstracts the fulfillment topology such that fulfillment flows either are not affected
or only minimally affected by fulfillment topology changes that are bound to occur over time as a
result of deployment consolidation, transformation from legacy to new systems, mergers and
acquisitions, or spin-offs. This approach enables use cases such as these to be accomplished
with ease:
13
 Add a new fulfillment provider; such as adding a new IPTV provisioning stack.
 Collapse two or more fulfillment providers into a smaller number of providers; such as
collapsing billing systems for two service type or customer segments.
 Change the domain for a particular provider; such as limiting use for a legacy system to a
particular set of customers or set of services.
 Change the physical topology; such as switching from a legacy system to a new system.
Adding fulfillment system types and new fulfillment functions has the greatest effect on fulfillment
flows. If the additions are relevant to existing fulfillment flows, then flows would need to be
extended accordingly; however, this design approach is more efficient than any other known
approach. This is the case for example if workforce management was not orchestrated part of
fulfillment flows and it was decided to start orchestrating installation tasks through order
management. This constitutes the addition of a new fulfillment system type for the first time.
Adding a second workforce management system doesn’t constitute a different system type and
can be handled through simple configuration.
Deployment Topology Guidance Summary
This table summarizes this deployment topology consideration and guidance:
# Consideration Guidance
1 Fulfillment Topology Order Management should abstract fulfillment topology such that
fulfillment flows and product specifications aren’t affected by
common changes to fulfillment topology.
Product Definition and Mapping Design Considerations
The Product and Service Definition

Product Model
methodology has the greatest effect on
time to market and on the cost of an Order Commercial Offer
to Activate deployment. Often, products
and services are defined in different 0..n 1..n 0..n
Commercial
0..n
Offerings
network, IT, and business departments to

serve the best interests of individual Commercial Bundle 0..n
departments. This approach creates a 1..n
challenge for bridging the gaps at runtime.
We recommend a balanced approach that Commercial Product
would require departments to make
0..n
calculated compromises that would result
Fulfillment
1
Customer
in simplified overall Product Life Cycle and

Order
Order Life Cycle business flows. Product

Specification
The Product Model diagram aligns with
0..1
TMF (Tele Management Forum)
terminology and guidelines. This diagram 0..n 0..n
Service Order
takes a step further to provide guidance

Fulfillment
about the mechanics of achieving a Technical Service 0..n

balanced product definition model. 0..n
0..n
Resource
14
The Product Model, which is illustrated inside an hourglass shape, indicates the typical number of
each element in the model. The model shows Product Specification at the narrowest part of the
hourglass, and Commercial Offer and Resource are at the widest parts of the hourglass.
The Product Model shown covers the three TMF SID key entities: Product, Service, and
Resource.
The diagram maps the Product Model to the three layers that are relevant for the Order to
Activate process:
 Commercial offerings
 Product specifications
 Services and resources
Commercial Offerings
Commercial offerings represent the simple and compound product offerings available for
ordering. Commercial products are core sellable entities. Commercial Bundles and Commercial
Offers are a packaging of Commercial Products to achieve reusability and marketing goals.
Commercial bundles group products and discounts together either for direct sales or for reuse in
multiple commercial offerings. Commercial offerings group commercial products and commercial
bundles to create offerings bound by contract terms or time.
You can manage introduction of commercial offerings starting in Siebel or a PIM (Oracle product
master application).
Oracle’s adopted methodology is to associate commercial products with a product class in Siebel
or PIM. You do not need to associate offers, bundles, discounts, and other well-identified order
line subjects with a product class.
Product Specifications
Product specifications represent core product definitions and the anchor point for mapping order
lines to fulfillment actions and for mapping order lines to service specifications in the Service
Order Fulfillment layer. We recommend that you nest product specifications in a class hierarchy
for best optimization.
Oracle’s adopted methodology is to support Order Line to Product Specification mappings in
OSM based on a prepopulated Fulfillment Item Code attribute in the order line. The Fulfillment
Item Code attribute should be populated by the Product Administrator. For CSPs that adopt a
commercial to technical (top-down) mapping approach, the Fulfillment Mode can be populated
with a Product Class name. For CSPs that adopt a technical to commercial (bottom-up) mapping
approach, the Fulfillment Mode can be populated with a code reference to the Product
Specification in the Order Management system. When Fulfillment Mode is not populated,
mapping rules rely on the Product Type Code and the Billing Type attribute values to map
common order line subjects, such as offers and discounts, and pure billing products to respective
common product specifications.
To simplify mappings in the Customer Order Fulfillment layer, Oracle’s approach is that 0..n
product classes map to one and only one product specification.
Services and Resources
In the Service Fulfillment layer, a product specification can map to one or more technical
services. A technical service is composed of one or more technical services and resources. The
mapping from a customer order to a service order requires specific metadata modeled on
products, product specifications, and service and resource configurations.
Oracle’s adopted methodology is to leverage UIM, Oracle’s network inventory application, to host
15
service and resource configurations and capabilities to assist OSM Provisioning in the translation
process of a customer order to a service order. To facilitate this mapping, product specifications
should have attribution as to whether the product specification maps to an Access (Primary)
Service, Service Feature, Capacity, Network Access, Network Node, and so on. Customer order
lines include information about deterministic mapping between subjects of order lines and service
instances. Oracle’s approach is to leverage order line hierarchy and other attributes, such as
Service Instance Indicator (planned for a future release of AIA for Communications Foundation
Pack), Parent Order Line, and Root Order Line.
Details about the Service Fulfillment layer are not in the scope of this guide. Therefore, the
sample use cases included in the following section do not reach this level of detail.
The following diagram shows how the Order Management system takes advantage of the Product
Model to map customer order lines to fulfillment flows.
Order Header Order Fulfillment Design Time Metadata

Identification: Order ID;
Order Number + Revision
Fulfillment Mode
Order Priority
Order Job
Parent Order
...
PONR
Order Lines
Sync Initiate Provision Fulfill
Customer Billing Order Billing
Identification: Order Line ID
Action Code
Fulfillment Item Code
Product Type Code
Billing Type
...
PONR
Identification: Order Line ID Sync Ship Fulfill
Customer Order Billing
Action Code
Product Type Code
Billing Type
...
At runtime, order capture copies key commercial offering attributes to each order line. These
attributes include Fulfillment Item Code, Product Type Code and Billing Type. Order Management
uses these attribute values to determine the corresponding product specification. The order
header Fulfillment Mode attribute value determines the fulfillment requested type (e.g. Deliver,
Qualify). The intersection of a product specification and fulfillment request type determines the
fulfillment actions and dependencies involved. When combined for all order lines in an order, an
order fulfillment plan is generated dynamically.
16
Product Model Guidance Summary
1 Product Model has  Adopt a compatible product model.
critical impact on
 Leverage Fulfillment Item Code for mapping Commercial Products
sought Fulfillment
to Product Specifications or vice versa.
business benefits
 Use Product and Order Line attributes to determine the common
mappings.
 Keep Commercial Product to Product Specification mappings
simple (a product maps to a single product specification).
Order Update Design Considerations

Superior visibility and experience is a key business driver for the Order to Activate process. The
Order Management system should facilitate configurable and streamlined order fulfillment
statuses and propagation across the fulfillment systems and CRM. Decomposition of an order
into order components, as well as multiple fulfillment steps, place extra burden on the Order
Management system to manage the translation of Fulfillment Function responses to common
status attribute values. Each response may contribute to different order line and order header
status values, which is also the responsibility of the Status Management function of the Order
Management system.
A single status attribute is not sufficient to provide comprehensive visibility into the fulfillment
process. Oracle adopted the extended set of attributes shown in the following table as part of its
methodology to implement Order to Activate. See the Communications Orders Dictionary topic in
this guide for more information.
# Functional Usage
Attribute
Name
1 Order Line / Provides high-level update of the current status of order line fulfillment to
Status Order Management and CRM.
2 Order Line / The last reached fulfillment milestone.
Milestone
3 Order Line / Provides details about the current status. An implementer can configure this
Status Context value.
You can use Context Text to indicate:
Required Customer interaction
If delivery is expected to be delayed
Milestone/fulfillment function in which failure occurred
Cause or of a cancellation or who canceled an order
4 Order Line / Indicates if Siebel should allow revisions to an order line or submission of
Point-of-no- previously-created revisions to an order line. OSM Fulfillment flows allow
return configuration of setting a Hard Point-of-no-return when a condition is met for
a particular service. When a Hard Point-of-no-return is established for an
17
Order Line in OSM an update is issued to reflect the same in CRM.

With AIA for Comms 2.4 Siebel uses the Point-of-no-Return to block
submission of new revisions, but it doesn’t block creation of new revisions
yet.
5 Order Header / Updates CRM updated on the current status of order fulfillment at a high
Status level.
6 Order Line / Determines the date when the purchased product or service is considered
Actual Delivery available to the customer by the CSP. This may be the date physical goods
Date are shipped, delivered, or their receipt acknowledged. For service-based
products, this is the date the service is activated. This date is computed in
the Fulfillment flow.
7 Expected Provides the due date expected by the system as result of Design and
Delivery Date Assign. Customers can change this value if they amend the order. When
CRM creates the order, this value is provided by default. OSM uses this
date to communicate changes to specific order line dates to CRM.
8 Order Header / Provides details about the current status. The implementer can configure
Status Context this value.
When referring to order or order line status in this guide, we are referring to values for all of the
previous attributes. Some CSPs don’t realize the processing complexity that is introduced when
different fulfillment status values are used for different services. Users may need to configure
additional status values, but we recommend they use a streamlined set of status values across
Product Specifications. This practice has two advantages:
1. To enhance the CSR’s and the customer’s understanding.
2. To maximize fulfillment flow reusability and enhance the time to market.
In addition to using streamlined statuses, the Order Management system should optimize the
propagation of status changes as follows:
1. Not all status changes are relevant to the CSR or the Customer in CRM. Therefore, not
all changes should be propagated to CRM.
2. Not all status changes need to be reflected instantly, therefore, a throttling mechanism
should be provided. Some statuses, however, should be reflected instantly, such as
Point-of-No-Return being reached. Careful analysis is required to determine which status
changes require instant propagation and which can wait. Too many status updates may
cause performance and throughput problems.
Some Status attribute values drive specific logic in CRM and should be preserved. For Siebel,
these values are Complete and Canceled. Both affect the Asset Maintenance logic in Siebel. The
Complete status value drives the logic to create and update Siebel Assets. The Order
Management system should turn the status value to Complete for a parent order line only after
the order line and all of its subordinate order lines (within the order hierarchy) have completed
fulfillment successfully. A Canceled order status excludes the order from a Siebel calculation of
the future state of the asset when creating follow-on or future-dated orders.
18
When making data updates to an order line in CRM, Order Management should avoid sending
the data updates before the order line reaches the Point-of-No-Return. If a revision was created
before the data update was sent to CRM and then the revision was submitted, the data updates
may be lost. Fulfillment flows in Order Management should delay sending data updates as long
as possible but no later than when the Complete status value is sent to Siebel. If any data update
occurs after the Complete status value is propagated to Siebel, then the updated data would not
be saved on the Asset.
If significant changes made to an order during fulfillment compromise the customer’s intent, then
the Order Management system should set the Order Changed flag to signal Siebel to make a
copy of the customer order before updating it.
Order Update Guidance Summary:
1 Order Fulfillment  Use the extended set of status attributes adopted by O2A FP.
Visibility in CRM
 Streamline statuses across product specifications.
 Send updates that are significant to CSR or customer.
 Preserve Siebel significant statuses (such as Canceled, Complete).
 Establish Complete order line status for a parent line only after all
children order lines status is Complete
2 Update Order Data in  Avoid sending order data updates prior to point of no return
CRM
 Make data updates with or before updating CRM with Complete
order line status
 Set the Order Changed Flag when order changes contravene
customer intent.
3 Updates from  Channel all updates through the provided single AIA service
Fulfillment Systems to operation.
Order Management
 Map updates to common lifecycle, status and fallout conditions.
Revision Orders Design Considerations

The fulfillment of certain services may take days and weeks, and some B2B and infrastructure
projects may take months to complete. During this period, customers change their minds and
request changes to their orders that become revision orders in Siebel. In many cases, continuing
the base order when a revision is submitted is costly for the CSP, and sometimes the operation
cannot be fully undone. For these reasons, support for revision orders provides the following
benefits:
 Enhances customer satisfaction by allowing customers to change their orders within an
agreed-upon limit.
 Reduces the costs associated with fulfilling unwanted goods and services requests and
wasting system capacity, unrecoverable resources, acquired stock, and so forth.
 Reduces human intervention to manually retrofit data records when recovery cannot be
automated.
19
A CSP can attain these benefits by adopting a balanced order revision policy. A point-of-no-return
(PONR) must be established in the fulfillment flow of each service so that either an order revision
is technically impossible or the cost of doing so outweighs the benefit of allowing a revision.
Siebel allows order line revisions as long as the order line did not complete. With AIA for
Communications 2.4, Siebel was enhanced to block the submission of an order line revision when
it reached the PONR. Despite this enhancement, the possibility exists that a revision order is
submitted at the same time an order line reaches the PONR. The Order Management system is
required to reject revisions that violate the PONR, placing them in fallout.
To avoid problems associated with staled revisions (that is, revisions that do not progress in
Siebel and become out of sync with their underlying asset), Siebel was enhanced to allow only
one pending revision for each order.
A PONR should be configured in the fulfillment flow of each Product Specification and propagated
to CRM at runtime.
After a revision is submitted, the Order Management system should be able to recognize a
revision of an in-flight (being fulfilled) or pending order (waiting turn to be fulfilled), and it will
ignore older revisions that may be out of date because of slow messaging queues or system
outages. The Order Management system is responsible for suspending the revised order,
computing a compensation plan, and considering the revision order changes when fulfilling the
order.
The Order Management system should expect to receive a complete revision order, not a delta
order with changes from the original order. Revisions may include new order lines, modified order
lines, and cancelled order lines. The Order Management system should support these
cancellation patterns:
1. Cancel the entire order. Siebel will set the Fulfillment Mode order header attribute value to
CANCEL.
2. Drop an order line. When an ADD for a new product is dropped, Siebel will drop the order line
from the revision order.
3. Revert the order line Service Action Code to NONE. When a change to an existing asset is
reverted, Siebel will revert the order line Service Action Code.
4. Revert changes to an order line some times produces an Update order line that has no
changes. In other words this is a false update case.
For product attributes that are saved to the asset in Siebel (see the Communications Orders
Dictionary topic in this guide for information about assetable attributes), the order message
includes Prior Value for changed attributes. Order Management and fulfillment systems take
advantage of these attributes to determine the changes and to undo unwanted actions. The Order
Management system is responsible for maintaining correct Prior Values when attribute values
change during fulfillment. The Order Management system should pass Prior Values to systems
with the capability to process revisions.
Compensation for provisioning typically involves technical knowledge, and we recommend that
you keep that knowledge out of the Order Management layer. The Order Management system
should delegate to the Provisioning stack for any Provisioning-specific compensation by passing
the revision order component as is to the Provisioning system. The Provisioning system, in turn,
is responsible for computing delta changes, computing a compensation plan, and executing the
revision.
This table lists the Sales Order attributes that are used to identify revisions and order lines across
revisions. When a revision cancels an entire order, the Fulfillment Mode attribute CANCEL value
is used.
20
# Functional Usage
Attribute Name
1 Order Header / Alphanumeric identifier for the order. This value is unique for each
Order ID revision. The Order Management System should preserve this ID and
pass it to fulfillment systems.
2 Order Header / Alphanumeric identifier for the order. This value does not change across
Order Number revisions. This value and the Revision attribute are used to identify order
revisions in Order Management.
3 Order Header / Numeric identifier of order revisions made during the fulfillment process.
Revision
4 Order line / Line Unique, auto-generated identifier of the order line across orders and
Item ID order revisions.
5 Order line / Base Reference to the revised order line ID from the base order.
Line Item ID
Order Management uses this attribute to match order lines across
revisions of the same order.
6 Order Header / Fulfillment request type. The Cancel value is a special case used to
Fulfillment Mode cancel an entire order.
21
Revision Orders Guidance Summary
1 Point-of-No_Return (PONR)  Manage through a separate attribute.
 Propagate value from Order Management to Siebel to
enable Siebel and should be propagated to Siebel.
 Avoid side effect of possible race condition; Order
Management should validate revisions against PONR.
2 Staled revisions  Find alternatives to keeping more than one pending
revision in Siebel. For AIA 2.4 this is blocked by Siebel.
3 Computing changes  Send complete order revisions as opposed to
incremental changes to Order Management.
 Maintain Prior Values in Order Management to pass to
fulfillment functions as needed.
4 Canceled order, order line  Support four patterns:
 Order level cancel (Fulfillment Mode = CANCEL)
 Order line dropped
 Order line’s Action Code reverts to no action
 False updates
5 Compensation  Adhere to order compensation specifications for BRM
AIA interfaces.
 Delegate revisions to Provisioning to avoid bringing
technical knowledge to Order Management.
Billing Fulfillment Design Considerations

Billing fulfillment scenarios lead to one of two fulfillment patterns, each of which must be
supported by the Order Management system.
Two-Phase Billing
In this pattern, a service is interfaced to Billing twice:
1. Initiate Billing. The service and purchased products are interfaced in early in the fulfillment
flow and before actual delivery dates are known.
2. Fulfill Billing. Accurate billing dates are updated in Billing after the order is delivered and the
actual delivery date is known. Two scenarios require this pattern.
Billing Scenario #1: Phased for Time Latency

In this scenario, the CSP has these concerns:
 Operational or deployment conditions produce a time lag between the time a service is
made available for customer use and the time the service is interfaced into Billing. As a
result, usage records can go into error logs and the CSP may lose revenue.
 CSPs attempt to plan fulfillment of future dated orders to meet the requested delivery
date, often using a safe margin that produces a time lag between the time a service is
made available for customer use and the requested delivery date.
22
In these cases, the usage cycle needs to start sooner than the billing cycle date. The
fulfillment flow should be constructed such that the Usage Start Date is set to the current
date during Initiate Billing, and the Cycle Start Date is set to a distant future date. At the
time of Fulfill Billing, the Cycle Start Date is then reset to match the Actual Delivery Date
or Requested Delivery Date, depending on business practices and legal requirements.
Billing Scenario #2: Phased for Validation

In this scenario, the CSP has these concerns:
 Inadequate controls are in place to guarantee that valid orders interface to Billing. As
a result, the CSP faces a high rate of invalid orders.
 The costs associated with delaying order line validation for interfacing to Billing are
prohibitive.
In these cases, orders need to be interfaced to Billing early in the fulfillment flow to prove
that the order can be interfaced successfully. The fulfillment flow should be constructed
such that the Usage Start Date and the Cycle Start Date are set to a distant future date
during Initiate Billing. At the time of Fulfill Billing, the Usage Start Date and Cycle Start
Date can be reset to match the Actual Delivery Date or Requested Delivery Date,
depending on business practices and legal requirements.
Single-Phase Billing
In this pattern, a service is interfaced to billing through Fulfill Billing towards the end of the
fulfillment flow, after the order is delivered and the actual delivery date is known. Two scenarios
require this pattern.
Billing Scenario #3: All at Once (most common scenario)

In this scenario, the CSP does not have the concerns mentioned previously; interfacing to
Billing takes place after the service or product is made available to the customer. The
interpretation of made available may vary among CSPs, based on jurisdiction, and based
on whether the subject is a service or a physical good. For example, physical goods that
require no network activation or onsite installation might be billed immediately after the
goods are shipped. The exact timing is built into the fulfillment flows associated with the
underlying Product Specification through the Actual Delivery Date and other billing date
attributes.
Billing Scenario #4: On First Usage

In this scenario, the CSP predelivers certain types of services (typically IP-based
services), markets the availability of the services to the customer, and initiates billing only
at the time of first usage. Interfacing Order Line to Billing for this pattern is done in a
single phase, similar to the All at Once pattern except that billing starts only after first
usage of the service.
In all of the previous cases, BRM requires that the Purchase Date be set to the earliest Usage
Start Date or Cycle Start Date interfaced to Billing. The BRM ABCS enforces this constraint by
overriding the Purchase Date value.
For all of the previous cases, the Order Management fulfillment flow should maintain accurate
Prior Values for the date attributes.
This table lists the key attributes used to support Billing fulfillment patterns:
23
# Functional Usage
Attribute Name
1 Order Line / Determines the date when usage events should start being rated. The
Usage Start value for this attribute is populated by CRM, Order Management fulfillment
Date flows, or set to Null for BRM to provide the current date by default.
2 Order Line / Determines the date when cycle charges should start being billed. The
Cycle State value for this attribute is populated by CRM, Order Management fulfillment
Date flows, or set to Null for BRM to provide the current date by default.
3 Order Line / Determines the date when one-time purchase charges should be billed.
Purchase Date The value for this attribute is populated by CRM, Order Management
fulfillment flows, or set to Null for BRM to provide the current date by
default.
4 Order Line / Determines the date when the purchased product or service are
Actual Delivery considered available to the customer by the CSP. This date may be when
Date a physical good is shipped, delivered, or its receipt acknowledged. For
service-based products, this date is when service is activated. This date is
computed in the Order Management fulfillment flow.
5 Order Line / A Null value means that the requested delivery date for the good or
Requested service is ASAP; otherwise, it is the specified date. This date is not
Delivery Date guaranteed.
6 Order Line / When this value is set to Yes by CRM or Order Management, the request
Start Billing on is passed along to BRM. In this case, Usage Start Date, Cycle Start Date,
First Usage and Purchase Date should have no effect because the integration does
not support this attribute when first delivered; an extension to the BRM
ABCS is required.
Note that resetting the Usage Start Date, Cycle Start Date, or Purchase Start Date value requires
passing a corresponding Prior Value. The BRM ABCS uses Prior Values to determine appropriate
action and BRM API to use.
Billing Fulfillment Guidance Summary
1 Billing fulfillment  Support for single-phase and two-phase billing patterns.
patterns
 Determine Actual Delivery Date by Product Specification on
fulfillment flows to meet provider’s business needs or legal
requirements.
 Compute correct billing Cycle, Usage and Purchase dates based
on values provided in Siebel and Actual Delivery Date part of
fulfillment flow.
 Maintain and pass proper Prior Values for all changing attributes
when invoking Initiate or Fulfill billing.
24
Multiple Features Design Considerations

This topic describes design considerations for Order Management system features.
Future-Dated Orders
Future-dated orders facilitate convenient order capture and accommodate customer requirements
for activating or deactivating services while away. Support for future-dated orders ranges from a
necessity to a convenience for CSPs. It enables CSPs to comply with requested delivery, update,
move, or cancellation dates. It also enables CSPs to manage customer-initiated or CSP-initiated
periods of Suspend and Resume of services.
The Order Management system should accept orders with future Requested Delivery Dates at
any time after the order is captured in Siebel. The Order Management system is expected to
compute a fulfillment start time that allow for services and goods to be delivered as close as
possible to the requested delivery date. Determination of a fulfillment start time constitutes a time-
based dependency for the start of fulfillment flow.
Avoid creating multiple future-dated orders against the same asset. They create a complex future
asset state that is difficult for both the CSR and the customer to comprehend. We recommend
that only a trained CSR be allowed to enter multiple future-dated orders against the same asset
and only when required. When introducing an order line against the same asset with a Requested
Delivery Date sooner than another already created order, you should revise the latter to ensure
that the order is based on an updated future state of the asset.
Follow-On Orders
The fulfillment of some services may take days and weeks, and some B2B and infrastructure
projects may take months to complete. During this period, customers change their minds and
request order changes that become revision orders in Siebel if the subject order lines did not
reach the PONR or become follow-on orders otherwise. In many cases, not taking an order
pending the completion of in-flight orders is not acceptable; hence, Siebel simulates the future
state of in-flight orders and allows for the creation and submittal of follow-on orders that are
nothing more than change orders based on the projected future state of a customer’s assets.
Follow-on orders are change orders that involve a dependency on the future fulfillment of at least
one other order line in an order that is currently in-flight. The Follow-On order line may change
another in-flight order line that is beyond the hard PONR or that depends on the future asset state
of that line, as through an explicit dependency established in Siebel.
Follow-on orders are created and submitted to Order Management immediately, and Order
Management is responsible for managing the fulfillment dependency between the follow-on order
and other base orders. This responsibility is similar to the responsibility for determining the
correct processing time for future-dated orders.
This table lists the attributes through which follow-on orders can establish cross-order
dependencies at the order line level:
# Functional Usage
Attribute Name
1 Order Line / Order Line Item ID of a base order line item that is changed by this
Depends On Line order. Used to establish dependency between order line on follow-on
Item ID order and order line on base order.
2 Order Line / Depends On Order ID of an in-flight order. It is the basis for this follow-on order line
Order ID item.
25
Cross-Order Dependencies
In addition to follow-on orders, another kind of order produces a cross-order fulfillment
dependency: an explicit parent-child order hierarchy. For example, multi-site B2B projects
for which the customer and CSP agree on a project sequence that specifies that work on
one side will finish before work on the other side starts. In this case, the dependency is
captured through the following order header attribute:
# Functional Usage
Attribute Name
1 Order Header / Parent Establishes cross-order dependencies between a child and parent order.
Order ID The child order starts fulfillment only after the parent order fulfillment is
complete.
The Order Management system is expected to honor cross-order dependencies both at
the order line and order header levels.
Order Priorities
Order Fulfillment Priorities reflect business factors such as customer experience and
revenue recognition, as well as operational factors such as deployment throughput
capacity and fluctuation.
Order Fulfillment Priority is specified in CRM or provided by default in fulfillment, and it
should be honored by the Order Management system along with the entire fulfillment
deployment. Message queues should be configured to honor priorities.
When two orders with different priorities are submitted by CRM, we expect—whenever
the two orders are within the same system waiting for service—that the higher priority
order will be given precedence over the lower priority order.
This table describes Order Priority attributes and values:
# Functional Usage
Attribute Name
1 Order Header / Relevant priority of order fulfillment across orders. A lower value
Fulfillment Priority indicates a higher priority.
The Priority attribute takes a value between 0 and 9, with 0 being the
highest and 9 being the lowest priority, as follows:
0: Urgent (Use for expedited orders.)
1: Highest (Usage defined by CSP.)
2: Very High (Usage defined by CSP.)
3: High (Usage defined by CSP.)
4: Medium High (Usage defined by CSP.)
5: Medium (Usage defined by CSP.) This is the default.
6: Medium Low (Usage defined by CSP.)
7: Low (Usage defined by CSP.). Recommended for Job orders.
26
8: Very Low (Usage defined by CSP.)

9: Lowest (Usage defined by CSP.)
Job (Batch and Bulk) Orders

Job orders are of two types:
 A single-order job is a single order with a large number of line items that should be treated as
one job. For example, if a business customer wants to upgrade phone subscriptions for its
20,000 employees, then a single order is produced with 20,000 lines.
 A multi-order job is a single job with a large number of correlated orders. For example, a
campaign to add 100 SMS free messages to all subscribers whose date of birth is tomorrow
produces 25,000 orders.
Siebel bulk ordering was extended to tag orders within a job with a common Job ID. The Job ID is
passed on the EBM as follows:
# Functional Usage
Attribute Name
1 Order Header / Job Uniquely identifies a job to the orchestration plan. This value should be long enough to
ID allow reasonable coding of information into the ID, such as a campaign name. An ID
should be generated automatically and an override is allowed.
If no Job ID is provided for a single-order jobs, then it is treated like a regular order. The Job ID
allows Order Management to vary processing for job orders and to report on job orders. For
example, Order Management should allow for bulk Suspend or Resume of all orders included in a
job.
Qualify Order Sub-Flow

AIA for Comms 2.4 uses the order header Fulfillment Mode attribute to determine the
characteristics of the fulfillment request.
# Functional Usage
Attribute
Name
1 Order Header / Qualifies the orchestration required for a particular sales order submission. As delivered, AIA
Fulfillment Mode for Comms 2.4 and Siebel extensions support Deliver, Cancel, and Get Provider values. See
the Communication Orders Dictionary topic in this guide for details. The value TSQ is
planned for a future release of AIA for Communications and used to support the Qualify
customer order request.
The System Integrator must add the Fulfillment Mode value TSQ to the
ProcessSalesOrderFulfillment and ProcessProvisioningOrder EBMs. In addition, the System
Integrator must extend the Siebel user interface to include a TSQ button next to the Submit
button to enable order submission when the Fulfillment Mode attribute value is set to TSQ.
Note that TSQ relies on integration between the Provisioning system and the Network Inventory
system; this topic is not covered in this guide.
Multiple Features Guidance Summary
27
1 Future-Dated Orders  Compute fulfillment start date in Order Management.
 Start fulfillment of an order ASAP, if the fulfillment start date is
current or in the past.
2 Follow-On Orders  Support order cross-order-line dependencies to support follow-on
orders.
3 Cross-Order  Support order level (parent-child) dependencies.
Dependencies
4 Order Priority  Honor order priority values 0 to 9.
 Default order priority for job orders to 7 (Low in Siebel).
 Default order priority for expedited orders = 0 (Urgent in Siebel).
5 Order Priority and Job  Use Job Id to correlate identify individually submitted orders to a
Orders Job Order.
 Support reporting and bulk actions on Job Orders.
6 Qualify Customer  Extend Siebel and integration to support Technical Service
Order Qualification, if required.
Order Management Integration Design Considerations
System Interactions
The core orchestration activities of the Order Management system are System Interactions to
Fulfillment Systems. The Order Management system should honor the system interaction
contracts for all fulfillment functions, including the request and response messages, as applicable.
The Order Management System should also honor the compensation logic for each fulfillment
function.
A critical element of System Interactions is that it honors processing granularity for each
fulfillment function separately. Processing granularity determines the grouping of order lines that
should be processed together into a fulfillment function. This grouping preserves the minimal
context required by the fulfillment function and honors the business requirements. It may relate to
the number and frequency of system, engineering, and customer interactions.
When decomposing an order, the Order Management system must recognize and honor both
explicit and implicit order line hierarchies and relationships. For example, one-time charges, such
as Downgrade Charge and Early Termination Fee, have relationships (such as the cause for the
charge) to the order line. These should be considered as part of the order line when it is
processed through Billing.
An Order Management implementation of a System Interaction should also account for all
possible responses and should allow for multiple updates in the course of a single fulfillment
function, including mapping of responses to an order line and order status updates. Mapping of
errors to fallout conditions is also included.
28
The System Interaction should also account for two kinds of attributes on an EBM: First Class
Attributes (FCA) coded directly and explicitly on the EBM such as Product Name and User-
Defined Attributes (UDAs) such as Bandwidth. UDAs are equivalent to Siebel extended (XA)
attributes. UDAs are modeled as Name-Value pairs on EBMs in different places. UDAs also have
Action Codes for ADD, DELETE, and UPDATE. In addition to preserving Prior Values, the Order
Management system is expected to preserve Action Codes and set them properly if a UDA is
changed during fulfillment.
Order-based EBMs can become large and inefficient. To reduce the burden, EBMs should only
include required and populated optional attributes. Do not assume that the Order Management
and Fulfillment systems will receive all item or order line attributes. Similarly, update messages
should include key identification attributes along with changed attributes.
Fallout Management
Fallout conditions could arise as a result of internal conditions in Order Management and the
fulfillment flow, such as a validation error or unknown Product Specification, respectively. In
addition, AIA Error Handling is another channel for fallout conditions. It captures System
Interaction errors. The Order Management system must integrate with the AIA Error Handling
message queue and process such errors as fallout conditions.
Create Trouble Tickets in Siebel to facilitate automatic assignment, notification, reporting, and
management of fallout incidents across systems and departments.
Order Management Integration Guidance Summary
1 Order Management  Honors system interaction contracts for fulfillment functions,
System Interactions including compensation logic.
 Map system interaction responses to status and fallout conditions.
 Preserve minimal context for each fulfillment function when
decomposing an order.
 Support both explicit and implicit order line hierarchies and
relationships.
 Pass only changed attributes (relative to asset state) on AIA
messages.
 Maintain Prior Values and pass them as needed.
 Support UDAs and preserve their Prior Values and Action Codes.
2 Fallout Management  Consume AIA Errors off AIA Error Handler into Order
Management fallout handling.
 Create Siebel Trouble Tickets for fallout incidents.
29
Order to Activate Sample Use Cases
This section provides sample use cases for the Order to Activate business process. The sample use cases illustrate data modeling and
fulfillment solutions for real life order fulfillment scenarios.
Use Cases Setup

Broadband-VoIP Double Play Commercial Offering
# Siebel Object Relationship Cardinality Name Price List Subject Type

{parent line #} Type (min, max, Type Price (computed during
default) fulfillment)
1 Bundled On Top of the World Offer

Promotion {} Broadband-VoIP
2 CP {} High Speed Internet Service Bundle

3 CP {2} Product (1,1,1) Internet Service Service Bundle
4 .SP {3} Dynamic Class (1,1,1) Internet Service DClass NA
5 .SP {3} Product (0,1,0) Internet Secure Firewall MRC $0 Product
6 .CP {3} Product (1,1,1) Internet email Service Bundle
7 .SP {6} Product (1,1,1) Internet email MRC $0 Product
8 .CP {3} Product (1,1,1) Internet Media Service Bundle
9 ..SP {8} Product (1,1,1) Internet Content on Demand MRC $0 Product

10 ..SP {8} Product (1,1,1) Internet Video on Demand MRC $0 Product
11 .SP {2} Dynamic Class (1,1,1) Internet Modems DClass NA
12 .SP {2} Product (0,1,0) Wireless Router OTC $75 Product
13 .SP {2} Product (1,1,1) High Speed Internet Installation OTC $0 Product
14 .SP {2} Product (1,1,1) High Speed Internet Activation OTC $30 Product
15 CP {} VoIP Service Bundle
16 .CP {15} VoIP Service Plan Service Bundle
17 .. Dynamic Dynamic Class (1,1,1) VoIP Service Plan DClass
Class {16}
18 ..SP{16} Product (0,1,0) VoIP Voicemail MRC $0.00 Product
19 ..SP{16} Product (0,1,0) VoIP Caller ID MRC $0.00 Product
20 .SP {15} Product (0,1,0) VoIP Adaptor OTC $45.00 Product
21 . SP {15} Product (0,1,0) VoIP Phone OTC $50.00 Product
22 SP {} Product (1,1,1) High Speed Internet First MRC 100% Discount
Month Free Discount
23 SP {} Product (1,11) High Speed Internet Activation OTC 100% Discount
Discount
24 SP {} Product (1,1,1) VoIP Recurring Discount MRC $10.00 Discount
25 SP {} Product (1,1,1) VoIP First Month Free Discount MRC 100% Discount
The following tables provide product details about the dynamic classes shown in the double play offering in the previous table. Siebel dynamic classes
enable flexibility to reuse product alternatives across offering and update all offerings when the dynamic class changes to add or remove alternatives.
VoIP Service Plan DClass: Dynamic Class that includes two VoIP access alternative products is created for dynamic reusability:
# Siebel Object Name Price List Subject Type

{parent line #} Type Price (computed during fulfillment)
1 Dynamic Class {} VoIP Service Plan DClass NA
2 .SP {1} Basic VoIP MRC $15 Product
31
3 .SP {1} VoIP w/ unlimited calls MRC $60 Product
Internet Service Dynamic Class that includes the three high-speed internet alternative products is created for dynamic reusability:

1 Dynamic Class {} Internet Service DClass NA
2 .SP {1} Basic High Speed Internet - 1Mbps MRC $15 Product
3 .SP {1} Premium High Speed Internet - 3Mbps MRC $60 Product
4 .SP {1} Elite High Speed Internet - 15Mbps MRC $80 Product
Internet Modems Dynamic Class that includes the three high-speed internet alternative products is created for dynamic reusability:

1 Dynamic Class {} Internet Modems DClass NA
2 .SP {1} Motorola Modem OTC $0 Product
3 .SP {1} Dynex Modem OTC $0 Product
32
Typical Fulfillment Topology

This diagram shows a typical fulfillment topology:
General Ledger
Payment
Payment&&&
Payment
CRM Collections
Collections
Collections
Order Capture BRM-VOIP BRM-REZBDB BRM-BIZBDB
(VOIP Services) (Residential Broadband) (Business Broadband)
CRM
Service
Central Fulfillment Process

VoIP UK DSL DSL
Shipping Shipping
InHouse PartnerInc Activation Activation Activation
VoIP UK DSL DSL
WFM Network Network Inventory
All Inventory DSL
The following topics provide additional details about fulfillment system types and the fulfillment functions supported by each fulfillment
system type.
Common Fulfillment Topology Definition
This table details the fulfillment topology metadata required to define the previous topology:
# Fulfillment System Type Provider Determinants

Billing VoIP Order Header Customer Segment AND Product Specs Product Family
Residential Broadband
Business Broadband
2 Provisioning VOIP Order Line’s Service Address Country AND Product Specs Product Family
UK DSL
DSL
3 WFM ALL NA
33
4 SCM InHouse Vendor on order line’s Item Reference component

PartnerInc
5 CRMService ALL NA
6 CRMSales ALL NA
This table lists the Fulfillment system functions available for Orchestration:
# System Interaction AIA Service Operation Fulfillment Processing Granularity Milestones

Action System Type
1 SyncCustomer ProcessFulfillmentOrderAccountListEBF Billing Order Start, Complete
2 InitiateBilling ProcessFulfillmentOrderBilling Billing Order Start, Complete
(FulfillmentMode=”Initiate”)
3 FulfillBilling ProcessFulfillmentOrderBilling Billing Subject Type = Service Start, Complete
(FulfillmentMode=”Fulfill”) Bundle
4 ProvisionOrder ProcessProvisioningOrder Provisioning Order Start, Designed,
Complete
5 CreateTT CreateTroubleTicket CRM-Service Any Start, Complete
6 UpdateTT UpdateTroubleTicket CRM-Service Any Start, Complete
7 InstallOrder ProcessInstallOrder WFM Order Start, Planned,
Committed,
Complete
8 ShipOrder ProcessSCMOrder Shipping Order: when Customer Start, Planned,
Segment = Shipped, Complete
“Residential”
Any: otherwise
9 UpdateSalesOrder UpdateSalesOrder CRMSales Any Start, Complete
10 UpdateSalesOrderStatus UpdateSalesOrder CRMSales Any Start, Complete
11 UpdateFulfillmentOrder ProcessFulfillmentOrderUpdate Orchestration Any Start, Complete
34
Double Play Fulfillment Flow Sample

Note: For quick reference, we call this the Nile flow.

Product Specification Intended Fulfillment Flows
or Subject Type (*)
START
COMPLETE
VoIP Service Plan Class InitiateBilling FulfillBilling
Together OR
Service.VoIP COMPLETE COMPLETE
VoIP Service Feature
Class Service.Broadband.Access ProvisionOrder SHIPPED
Together OR COMPLETE DESIGNED
COMPLETE
VoIP Equipment Class Service.CPE.VoIP ShipOrder FulfillBilling
High Speed Internet

START COMPLETE
Service Class
FulfillBilling
High Speed Internet Service.Broadband

Service Feature Class COMPLETE
Internet Media Class ProvisionOrder

SyncCustomer
Broadband Modem DESIGNED SHIPPED

Class
Service.CPE.Broadband COMPLETE
ShipOrder FulfillBilling
Wireless Router Class
COMMITTED
PLANNED
High-Speed Internet COMPLETE
Installation Class
Service.Install InstallOrder FulfillBilling
START
COMPLETE
Offer (*) NonService.Offer InitiateBilling FulFillBilling
Pricing Event Class

START
Discount (*) FulFillBilling
NonService.BillingItem
Bundle (*)
SpecialRating (*) Hard Point of No Return
Describing the Double Play Fulfillment Flow
The first column shows the Fulfillment Item Code or Subject Type values for double-play offering subjects depending on which one is relevant. To
distinguish the two Subject Type values are followed by (*). Order Management uses the values in the first column to map order lines each to the
corresponding product specification on the second column.
35
The second column shows the product specifications that map to fulfillment flows in the third column. Each product specification and order type
(deliver, qualify) combination map to a single fulfillment flow.
The third column graphically shows the fulfillment flow associated with each product specification, including cross-product specification dependencies.
The fulfillment flow for a product specification represents an orchestration of fulfillment functions in a particular order.
For example, the VoIP Service Plan Class maps to the Service.VoIP product specification, which has the following fulfillment flow:
1. Sync Customer.
2. When complete Initiate Billing, unless the order line is part of an offer on the same order then wait for the offer to complete Initiate Billing.
3. When Sync Customer is complete and if the same order has a line that maps Service.Broadband.Access product specification and its provisioning is
complete, then start Provisioning.
4. When both Initiate Billing and Provision Order are complete, start Fulfill Billing.
36
Double Play Promotion First-Time Purchase

Sales Order 10000
Customer places an order for On Top of the World Broadband-VoIP (Double Play) offer as follows:
# Siebel Action Name Price List Prom Subject Type Remarks

Object Type Price ID
{parent line
#}
1 Bundled ADD On Top of the World Broadband-VoIP Offer Billing Profile = VISA
Promotion {}
2 CP {} ADD High Speed Internet Service ID (1) Bundle Billing Profile = VISA
Service ID = Null*
3 CP {} ADD Internet Service ID (1) Service Billing Profile = VISA
Bundle Service ID = Null*
4 .SP {3} ADD High Speed Internet Basic MRC $15 ID (1) Product
5 .SP {3} ADD Internet Secure Firewall MRC $0 ID (1) Product
6 .CP {3} ADD Internet email ID (1) Service Service ID = Null*
Bundle
7 .SP {6} ADD Internet email MRC $0 ID (1) Product
8 .CP {3} ADD Internet Media ID (1) Service Service ID = Null*
Bundle
9 ..SP {8} ADD Internet Content on Demand MRC $0 ID (1) Product
10 ..SP {8} ADD Internet Video on Demand MRC $0 ID (1) Product
11 .SP {2} ADD Dynex Modem OTC $0 ID (1) Product
12 .SP {2} ADD Wireless Router OTC $75 ID (1) Product
13 .SP {2} ADD High Speed Internet Installation OTC $0 ID (1) Product
14 .SP {2} ADD High Speed Internet Activation OTC $30 ID (1) Product
15 CP {} ADD VoIP Service ID (1) Bundle Billing Profile = VISA
16 .CP {15} ADD VoIP Service Plan ID (1) Service Usage Start Date =
37
# Siebel Action Name Price List Prom Subject Type Remarks

Object Type Price ID
{parent line
#}
Bundle Null
Cycle Start Date = Null
Purchase Date = Null
Service ID =
5551234567*
17 .. SP {16} ADD VoIP Basic MRC $15 ID (1) Product Usage Start Date =
Null
18 ..SP{16} ADD MRC $0.00 ID (1) Product Usage Start Date =
Null
VoIP Voicemail
19 ..SP{16} ADD MRC ID (1) Product Usage Start Date =
Null
VoIP Caller ID
$0.00 Purchase Date = Null
20 .SP { 15} ADD VoIP Adaptor OTC $45.00 ID (1) Product
21 . SP {15} ADD VoIP Phone OTC $50.00 ID (1) Product
22 SP {} ADD High Speed Internet First Month Free MRC 100% ID (1) Discount Billing Profile = VISA
Discount
23 SP {} ADD High Speed Internet Activation OTC 100% ID (1) Discount Billing Profile = VISA
Discount
24 SP {} ADD VoIP Recurring Discount MRC $10.00 ID (1) Discount Billing Profile = VISA
25 SP {} ADD VoIP First Month Free Discount MRC 100% ID (1) Discount Billing Profile = VISA
38
First Time Purchase Double Play Order Fulfillment Flow

This diagram shows the order decomposition and Orchestration Plan that the Order Management system will generate:
SyncCustomer InitiateBilling ProvisionOrder ShipOrder InstallOrder FulfillBilling
ProvisionOrder [DSL] ShipOrder [InHouse]

FulfillBilling (BRM-REZBDB)
Internet Service (A) Dynex Modem (A)
High Speed Internet Basic (A) Wireless Router (A) COMPLETED
SyncCustomer [BRM-REZBDB] Dynex Modem (A)
Internet Secure Firewall (A)
On Top of The World Broadband-
VoIP (A) Internet email (A) DESIGNED Wireless Router (A)
High Speed Internet Service (A) Internet email (A) InstallOrder [All]
COMPLETED High Speed Internet Installation (A)
Internet Service (A) Internet Media (A) High Speed Internet
Installation (A)
High Speed Internet Basic (A) Internet Content on Demand (A) Internet Service (A)
Internet Secure Firewall (A) Internet Video on Demand (A) COMPLETED High Speed Internet Basic (A)
Internet email (A) Dynex Modem (A) COMPLETED Internet Secure Firewall (A)
Internet email (A) COMPLETED Wireless Router (A)
Internet email (A)
Internet Media (A)
COMPLETED Internet email (A)
Internet Content on Demand (A) InitiateBilling [BRM-REZBDB]
Internet Video on Demand (A) On Top of The World Broadband-VoIP (A) Internet Media (A)
Dynex Modem (A) Internet Content on Demand (A)
Wireless Router (A) Internet Video on Demand (A)
High Speed Internet Installation (A)
High Speed Internet Activation (A) High Speed Internet Activation (A)
High Speed Internet First Month Free

Discount (A) On Top of the World Broadband-VoIP (A)
High Speed Internet Activation Discount High Speed Internet First Month Free
(A) Discount (A)
High Speed Internet Activation Discount
(A)
High Speed Internet Service (A)
FulfillBilling (BRM-VoIP)
ProvisionOrder [VOIP]
On Top of The World Broadband-VoIP (A)
SyncCustomer [BRM-VOIP] VoIP Service Plan (A)
VoIP Recurring Discount (A)
On Top of The World Broadband- VoIP Basic (A) COMPLETED
VoIP (A) VoIP First Month Fee Discount (A)
VoIP Voicemail (A)
VoIP Service (A) VoIP Service (A)
VoIP Caller ID (A)
VoIP Service Plan (A) COMPLETED
VoIP Adaptor (A)
VoIP Basic (A) DESIGNED VoIP Adaptor (A)
VoIP Phone (A)
VoIP Voicemail (A)
InitiateBilling [BRM-VOIP] VoIP Phone (A)
VoIP Caller ID (A)
On Top of The World Broadband-VoIP (A)
VoIP Adaptor (A) COMPLETED
VoIP Service Plan (A) VoIP Service Plan (A)
VoIP Phone (A) ShipOrder [PartnerInc]
VoIP Basic (A) VoIP Basic (A)
VoIP First Month Fee Discount (A) VoIP Adapter (A)
VoIP Voicemail (A) VoIP Voicemail (A)
VoIP Phone (A) COMPLETED VoIP Caller ID (A)
VoIP Caller ID (A)
39
Describing the First Time Purchase Double Play Fulfillment Flow
Each box represents an activity (fulfillment function) within the fulfillment flow. The first bold underlined line in each box indicates the name of the
activity. The activity name is followed by the name of the target fulfillment provider enclosed in square brackets. Note that, in the last column, the large
number of order components leaves little room for repeating the activity name as the first line for each activity; instead, it appears once, at the top and
outside of each group of activity boxes with the same target. Lines within each order component represent order lines with action code abbreviation
between parenthesis at the end of each line as follows: A for ADD, D for Delete, U for UPDATE, E for EXISTING (i.e. no action required).
The arrows represent a dependency for the start and end of the activities.
Dependencies are established at the Order Line level. For readability purposes, the flowchart combines all dependencies between two order components
into a single arrow. For the exact dependencies, please review the fulfillment flow definition.
These considerations apply to this scenario:
 Broadband and VoIP services are sent separately to ProvisionOrder because they go to different provisioning instances. VoIP services have a
dependency on InitiateBilling of VoIP services and ProvisionOrder of Broadband services. Notice that technical dependency is managed in
fulfillment when the dependency spans different fulfillment providers.
 FulfillBilling processing granularity is set to Service Bundle, which means that an order will be interfaced into Billing one Service Bundle at a time.
 Note that, despite processing granularity, only relevant order lines are sent to the target fulfillment provider. SyncCustomer takes all line items.
InitiateBilling takes only VoIP service-based order lines and Commercial Offer order lines. ProvisionOrder does not take billing only line items, but
it takes everything else in the domain of the target provisioning provider.
 The On Top of the World Broadband-VoIP commercial offer is applicable to both billing systems, and it is assumed to be defined in both.
Double Play Change Order

Sales Order 10030: Customer wants to change internet access from Basic to Premium, and VoIP from Basic to VoIP with unlimited calls, CSR
places the following change order:
# Siebel Object Action Name Price List Prom Subject Type Remarks
{parent line #} Type Price ID
1 Bundled -- On Top of the World Broadband-VoIP Offer
Promotion {}
40
2 CP {} -- High Speed Internet Service ID (1) Bundle
3 CP {2} -- Internet Service ID (1) Service Bundle
4 .SP {3} DELETE High Speed Internet Basic MRC $15 ID (1) Product
5 .SP{3} ADD Premium High Speed Internet MRC $25 ID (1) Product
6 .SP {3} -- Internet Secure Firewall MRC $0 ID (1) Product
7 .CP {3} -- Internet email ID (1) Service Bundle
8 .SP {7} -- Internet email MRC $0 ID (1) Product
9 .CP {3} -- Internet Media ID (1) Service Bundle
10 ..SP {9} -- Internet Content on Demand MRC $0 ID (1) Product
11 ..SP {9} -- Internet Video on Demand MRC $0 ID (1) Product
12 .SP {2} -- Dynex Modem OTC $0 ID (1) Product
13 .SP {2} -- Wireless Router OTC $75 ID (1) Product
14 .SP {2} -- High Speed Internet Installation OTC $0 ID (1) Product
15 .SP {2} -- High Speed Internet Activation OTC $30 ID (1) Product
16 CP {} -- VoIP Service ID (1) Bundle
17 .CP {16} -- VoIP Service Plan ID (1) Service Bundle
18 .. SP {17} DELETE VoIP Basic MRC $15 ID (1) Product
19 .. SP {17} ADD VoIP w/ unlimited calls MRC $60 ID (1) Product
20 ..SP{17} -- VoIP Voicemail MRC $0.00 ID (1) Product
21 ..SP{17} -- VoIP Caller ID MRC $0.00 ID (1) Product
22 .SP {16} -- VoIP Adaptor OTC $45.00 ID (1) Product
23 . SP {16} -- VoIP Phone OTC $50.00 ID (1) Product
24 SP {} -- High Speed Internet First Month Free Discount MRC 100% ID (1) Discount
25 SP {} -- High Speed Internet Activation Discount OTC 100% ID (1) Discount
26 SP {} -- VoIP Recurring Discount MRC $10.00 ID (1) Discount
41
27 SP {} -- VoIP First Month Free Discount MRC 100% ID (1) Discount
42
Change Order Fulfillment Flow

The following diagram shows the order decomposition and Orchestration Plan that the Order Management system will generate:
43
Describing the Change Order Fulfillment Flow
The arrows represent a dependency for starting the activity and ending the activity.
Dependencies are established at the Order Line level. For readability purposes, this flowchart combines all dependencies between two order components
into a single arrow. For the exact dependencies, please review the fulfillment flow definition.
 Broadband and VoIP services are sent separately to ProvisionOrder because they go to different provisioning instances. VoIP services have a
dependency on InitiateBilling of VoIP services and ProvisionOrder of Broadband services. Note that technical dependency is managed in
fulfillment when the dependency spans different fulfillment providers.
 FulfillBilling processing granularity is set to Service Bundle, which means that an order will be interfaced to Billing one Service Bundle at a time.
 Note that, despite processing granularity, only relevant order lines are sent to the target fulfillment provider. SyncCustomer takes all line items.
InitiateBilling takes only VoIP service-based order lines. ProvisionOrder does not take billing only line items, but it takes everything else in the
domain of the target provisioning instance.
 No components exist for install and ship orders because no equipment is required to ship or install for this change order scenario.
44
Double Play Revision Order

Customer calls on day following placing change order 10030, the customer calls with a change. Customer wants to add the optional VoIP
Laptop Phone product. The CSR creates the following revision order 10030-R4:
1 Bundled -- On Top of the World Broadband-VoIP Offer
Promotion {}
2 CP {} -- High Speed Internet Service ID (1) Bundle
3 CP {} -- Internet Service ID (1) Service Bundle
4 .SP {3} DELETE High Speed Internet Basic MRC $15 ID (1) Product
5 .SP{3} ADD Premium High Speed Internet MRC $25 ID (1) Product
6 .SP {3} -- Internet Secure Firewall MRC $0 ID (1) Product
7 .CP {3} -- Internet email ID (1) Service Bundle
8 .SP {7} -- Internet email MRC $0 ID (1) Product
9 .CP {3} -- Internet Media ID (1) Service Bundle
10 ..SP {9} -- Internet Content on Demand MRC $0 ID (1) Product
11 ..SP {9} -- Internet Video on Demand MRC $0 ID (1) Product
12 .SP {2} -- Dynex Modem OTC $0 ID (1) Product
13 .SP {2} -- Wireless Router OTC $75 ID (1) Product
14 .SP {2} -- High Speed Internet Installation OTC $0 ID (1) Product
15 .SP {2} -- High Speed Internet Activation OTC $30 ID (1) Product
16 CP {} -- VoIP Service ID (1) Bundle
17 .CP {16} -- VoIP Service Plan ID (1) Service Bundle
18 .. SP {17} DELETE VoIP Basic MRC $15 ID (1) Product
19 .. SP {17} ADD VoIp w/ unlimited calls MRC $60 ID (1) Product
20 ..SP{17} -- VoIP Voicemail MRC $0.00 ID (1) Product
45
21 ..SP{17} -- VoIP Caller ID MRC $0.00 ID (1) Product
22 .SP {16} -- VoIP Adaptor OTC $45.00 ID (1) Product
23 . SP {16} -- VoIP Phone OTC $50.00 ID (1) Product
24 . SP {16} ADD VoIP Laptop Phone OTC $50.00 ID (1) Product
25 SP {} -- High Speed Internet First Month Free Discount MRC 100% ID (1) Discount
26 SP {} -- High Speed Internet Activation Discount OTC 100% ID (1) Discount
27 SP {} -- VoIP Recurring Discount MRC $10.00 ID (1) Discount
28 SP {} -- VoIP First Month Free Discount MRC 100% ID (1) Discount
These considerations apply to this Revision Order 10030-R4 scenario:
 This revision incurs no additional charge, R4 is the first revision submitted, and change order 10030 was in-flight and did not reach the hard PONR.
 The CSR starts with Order 10030, and then selects the Revise action and ADD new line item VoIP Laptop Phone on VoIP Service Plan.
The following chart shows the change order 10030 fulfillment plan along with an overlay of immediate revision 4 effects:
46
Describing the Double Play Revision Order Flow
47
Dependencies are established at the Order Line level. For readability purposes, the previous flowchart combines all dependencies between two order
components into a single arrow. For the exact dependencies, please review the fulfillment flow definition.
A light blue flag and the text Revision Received identifies the time that a revision order was received.
The part of the fulfillment plan executed until revision cutoff is highlighted with a dashed red line and a flag on the same side as the Base Order Cut Off
text. Two vertical pattern (||||) stripes create an envelope for this section.
The balance of the base order fulfillment plan that would be cut off is dimmed and turned into light gray background. Two X pattern stripes create an
envelope for this part of the flow.
Revision Order Fulfillment Flow

The following diagram represents the order decomposition and orchestration plan that the Order Management system will generate.
Note: The following plan is different from others in that it overlays the revision plan over the base order fulfillment plan not affected by the
revision. This diagram shows the dependencies of a revision order plan on base order milestones.
48
Describing the Revision Order Fulfillment Flow
49
Dependencies are established at the Order Line level. For readability purposes, the previous flowchart combines all dependencies between two order
components into a single arrow. For the exact dependencies, please review the fulfillment flow definition.
The revision order plan is divided into two parts: a compensation part for deltas between already executed fulfillment steps for the base order and
required fulfillment steps for the revision order; and a part for the balance of the plan to complete fulfillment of the revision. The compensation part of
the fulfillment plan is highlighted with a dashed purple line and a flag on the same side as the Compensation text. Two forward slash (///) pattern stripes
create an envelope for this part. The balance fulfillment plan is shown on the opposite side of the compensation plan; it has two vertical line (||||) pattern
stripes that create an envelope for this part.
 The revision was received while the VoIP order component was still in provisioning; therefore, the compensation sends the revised order
component to provisioning because provisioning is assumed to be capable of computing its compensation.
 VoIP Laptop Phone (Software CD) will be shipped to the customer location through the ship order component.
50
Communications Orders Dictionary

The following tables provide a snapshot of the Communications Orders Dictionary at the time this guide was created. Communications
Orders include EBOs and Sales Order, Fulfillment Order, and Provisioning Order. We refer to any of the three orders using the token
<CommsOrder>.
To understand the following tables, you must be familiar with these terms:
 Assetable
This term indicates if an attribute value is saved on the corresponding asset in Siebel.
 Prior Value
This term indicates if, when the attribute changes, a prior value is also sent on the order message. Prior Values sometimes are used
to determine if a change occurred and sometimes used to roll back changes.
Communications’ Orders - Order Header Component Attributes

Functiona Attribute Usage (Semantics) Seeded Ass Prior Remarks EBO Structure X Path - Depends on Context
l Attribute Values et Value as Follows:
Name able Available <CommsOrder> Variable for SalesOrder,
FulfillmentOrder or ProvisioningOrder
Order ID Uniquely identifies each order. NA No None Produces a unique identifier for all SaleOrderEBO/Identification/BusinessCompon
orders, including revision orders. entID
Unlike Order Number, Order ID is
different for revisions of the same
base order.
Used by AIA for cross-reference.
51
Order Identifies an order across NA No None A revision number >1 doesn't <CommsOrder>EBO/Identification/ID
Number revisions. necessarily mean that this is a
revision order from OM Fulfillment.
You can create an order in Siebel
and revise it several times before
submitting it. If an Order Number
matches an already in-flight order,
then the order is treated as a
revision order.
When an order is revised, this
number stays the same. OM uses
this number to identify the base
order. If the same order number
with the same revision is
submitted, then OM would reject
the revision order and place it in
fallout.
Revision A revision sequence number that, NA No None If an order is received with an <CommsOrder>EBO/Identification/Revision/Nu
together with the order number, Order Number equal to that of an mber
represents the user key to an in-flight order and the newly
order. received order has a higher
revision number, then OM
assumes the order is a revision
order and proceeds to analyze the
Order Lines. If the revision number
is equal or lower than that of the
base order, the revision is rejected.
Success Declares if all order lines must DEFAULT, No None <CommsOrder>EBO/PartialFulfillmentAllowedI
Dependen fulfill successfully or else the ALL OR ndicator
cy whole order fails (all or none). NONE
When the order level Success
Dependency is set to All or None,
it takes precedence over Order
Line Success Dependency
designations because it is more
restrictive.
52
Fulfillment Qualifies the nature of DELIVER, No None CSPs may extend support to other <CommsOrder>EBO/FulfillmentModeCode
Mode orchestration required for CANCEL, modes, such as Qualify for TSQ.
submission of a particular sales INITIATE Oracle is planning TSQ support
order. BILLING, part of a future release.
* Get Provider supports the Get FULFILL
Target Fulfillment Provider BILLING, Siebel is providing a mechanism to
through Order Management for GET create a revision order to cancel
use outside Order Management. PROVIDER an entire order by sending a
* Cancel is a special case used revision with Fulfillment Mode =
when a revision intends to cancel Cancel. OM is expected to honor
an entire order. this mechanism, along with the
scenario, when a revision is
submitted with no line items or
when all line items have no
actions.
This attribute is also used for

Billing EBMs to determine the type
of Billing request: Initiate or Fulfill.
Customer Identifies type of customer: RESIDENTIAL No None <CommsOrder>EBO/CustomerPartyReference
Class Residential, Business, and so on BUSINESS /CustomerPartyAccountTypeCode
Organizati Identifies the organization/LOB NA No None No cross-reference .OM should <CommsOrder>EBO/BusinessUnitReference/
on ID generating the order. No cross- use the application-specific ID if BusinessUnitIdentification/ID
reference exists. needed in any of the rules.
Sales Identifies the sales channel. NA No None <CommsOrder>EBO/SalesChannelCode
Channel
Job ID A string or number that uniquely NA No None Track orders that belong to a bulk <CommsOrder>EBO/ProcessingNumber
identifies the job to orchestration. or batch job.
Sequence A number that identifies the order NA No None Siebel is not providing a value in <CommsOrder>EBO/ProcessingSequenceNu
in Job sequence within the job. 2.4. mber
Job Type Identifies the type of job. This HETEROGEN No None Siebel is not providing a value in <CommsOrder>EBO/ProcessingTypeCode
information identifies the EOUS,HOMO 2.4.
threshold for creating a GENEOUS,
consolidated SR for Bulk or Batch 3RD PARTY
Orders. HOMOGENE
This value is optional for orders OUS,
whose Job Cardinality is 1. 3RD PARTY
By default, this value is HETEROGEN
HETROGENEOUS. EOUS,
CORRELATE
D
Job Indicates the total number of NA No None Siebel is not providing a value in <CommsOrder>EBO/ProcessingQuantity
Cardinality orders within the job. 2.4.
53
Parent Order ID of another order that NA No None This attribute applies to explicit <CommsOrder>EBO/Parent<CommsOrder>R
Order ID indicates the fulfillment for this order-to-order dependencies and eference/<CommsOrder>Identification/Busines
order will not start before the is not limited to follow-on orders. sComponentID
parent order fulfillment For example, in a B2B scenario, a
completes. large order can be divided into a
number of smaller orders, with one
order acting as the root order for
all other orders and the remainder
of the orders chained using the
parent order ID attribute.
Fulfillment Indicates relevant priority of order 0,3,5,7 No None EBM value: Siebel value <CommsOrder>EBO/FulfillmentPriorityCode
Priority fulfillment across orders. A lower 0: Urgent. Used for expedited
value indicates a higher priority. orders.
Accepts values 0 to 9 in 3: High. CSP determines its use.
accordance with JMS Queue 5: Medium. CSP determines its
support. use.
7: Low. Recommended for job
orders.
Order Sometimes indirectly determines SALES No None <CommsOrder>EBO/TypeCode
Type sales channel to drive ORDER
compensation process.
Requested Overall order level due date that NA Yes None <CommsOrder>EBO/RequestedDeliveryDateT
Delivery provides the default due date at ime
Date each line level. Can be
overridden at each line.
Status Reports aggregate order (Canonical / Yes None <CommsOrder>EBO/Status/Code
fulfillment status. Siebel):
(OPEN /
Open),
(IN
PROGRESS /
In Progress),
(FAILED /
Failed),
(CANCELLED
/ Cancelled),
(COMPLETE /
Complete)
54
Status Provides details about the current NA Yes None OM can used this to track the <CommsOrder>EBO/Status/Description
Context status. The implementer milestone causing the status
configures this value. change along with context details
such as error message, cause for
cancel, etc.
One primary scenario that the
Order Header / Status Context is
populated: with revision orders that
cancels Order Lines by dropping
them from the revision and if the
revision is rejected. In that case
the orchestration system doesn’t
have a line on the revision order to
provide fallout status and context
for and the header level status
context is used to indicate the
base line the cause for the fallout.
Owner Identifies the owner account. NA Yes None Cross-referenced. <CommsOrder>EBO/CustomerPartyReference
Account ID /CustomerPartyAccountIdentification/Business
ComponentID
Owner Identifies the Account Name. You NA Yes None Required for network inventory <CommsOrder>EBO/CustomerPartyReference
Account can enter or derive this value tracking of service owner. /CustomerPartyAccountName
Name from contact first name + last
name of primary contact
associated with the account.
Owner Identifies account number to NA Yes None <CommsOrder>EBO/CustomerPartyReference
Account customer. /CustomerPartyAccountIdentification/ID
Number
Account Foreign key to contact record that NA Yes None <CommsOrder>EBO/CustomerPartyReference
Contact ID holds personal and contact /CustomerPartyAccountContactIdentification/B
details of the customer/company usinessComponentID
representative who is placing the
order and is the contact person
for anything related to the order
process.
Account Identifies the address used to NA Yes None <CommsOrder>EBO/CustomerPartyReference
Contact communicate with the Contact ID. /CustomerPartyAccountContactAddressComm
Address unication/AddressCommunication/Address
(compone
nt)
Project ID Identifies project record if the NA Yes None No cross-reference for 2.4. <CommsOrder>EBO/ProjectReference/Project
order to be delivered is part of a Identfication/ID
project that contains related
orders. Foreign key reference. No
cross-reference.
55
Fulfillment For the Get Target Fulfillment NA No None FulfillmentOrderEBO/FulfillmentSystemTypeCo
System Provider utility service, de
Type determines the logical identifier
for appropriate target system
instance among those serving
this Fulfillment System Type.
Target For the Get Target Fulfillment NA No None FulfillmentOrderEBO/FulfillmentTargetSystemI
Instance Provider utility service, returns D
the logical identifier for
appropriate target system
instance among those serving
this Fulfillment System Type.
Order OM sets this attribute to Yes if the TRUE, FALSE No None Allows Siebel to make a copy of <CommsOrder>EBO/OrderChangedIndicator
Changed order changed significantly such the order if the order changed to
Indicator that CRM should make a copy of the extent that the customer’s
the customer order to preserve intent is compromised.
the customer intent before
updating the working version of
the order.
Sales CRM User ID that identifies the NA No None No cross-reference. Use the <CommsOrder>EBO/SalespersonPartyRefere
Represent sales representative who entered application ID. nce/PartyIdentification/ID
ative ID the order.
Owner Identifies if the address is used to NA No None <CommsOrder>EBO/CustomerPartyReference
Account communicate with the contact ID. /CustomerPartyAccountContact/FirstName
Contact Includes these fields: First Name, <CommsOrder>EBO/CustomerPartyReference
(multiple Last Name, Phone Number, and /CustomerPartyAccountContact/LastName
fields) Email. <CommsOrder>EBO/CustomerPartyReference
/CustomerPartyAccountContactPhoneCommu
nication/PhoneCommunication/CompleteNumb
er
<CommsOrder>EBO/CustomerPartyReference
/CustomerPartyAccountContactEmailCommuni
cation/EmailCommunication/
Communications Orders - Order Line Component Attributes

Functional Attribute Usage (Semantics) Seeded Values Asset Prior Remarks EBO Structure X Path - Depends on Context as
Attribute and Value able Value Follows:
Name Type Availa <CommsOrder> Variable for SalesOrder,
ble FulfillmentOrder or ProvisioningOrder
56
Line ID Uniquely identifies the order line NA No None Cross-referenced. Produces a unique <CommsOrder>EBO/<CommsOrder>Line/Identific
item across orders and order identifier for all Order Lines, including ation/BusinessComponentID
revisions. Automatically generated. revision Order Lines.
Base Line References base order line revised NA No None Uses a cross-reference. <CommsOrder>EBO/<CommsOrder>Line/Original
ID by this order line. <CommsOrder>LineReference/<CommsOrder>Li
neIdentification/BusinessComponentID
Asset Uniquely identifies an instance of a NA Yes AIA2.0 Cross-referenced <CommsOrder>Line/InstalledProductReference/In
Integration product that was or is being Assumption: The Asset Integration ID stalledProductIdentification/BusinessComponentI
ID purchased. will continue to be populated on all D
Order Lines, regardless of the
Assetable state on the subject of the
Order Line or whether the Order Line
is for a new or existing service.
A revision should never change the
Asset Integration ID.
When a product is dropped as part of
one product hierarchy (CP or
Promotion) and then added through
another product hierarchy (CP or
promotion), the Asset Integration ID
for the two line items is different,
although for the same product.
Line Identifies the line with respect to its NA No None Line number establishes the parent <CommsOrder>EBO/<CommsOrder>Line/Identific
Number position in the line item tree. child relationship between Order ation/ID
Lines of the same order, but it may
vary across revisions. Therefore, do
not rely on it for matching Order Lines
across revisions.
Parent Line References parent order line in the NA No None <CommsOrder>EBO/<CommsOrder>Line/Parent
line items tree instantiated as per <CommsOrder>LineIdentification/BusinessCompo
the product model definition. nentID
Points to itself if the item does not
have an associated parent item.
Root Line References the root order line in NA No None <CommsOrder>EBO/<CommsOrder>Line/RootPa
the line item tree instantiated as rent<CommsOrder>LineIdentification/BusinessCo
per the product model definition. mponentID
Points to itself if the item is a root
item itself.
Related Links one-time charges to NA No None <CommsOrder>EBO/<CommsOrder>Line/Related
Line ID Suspend/Resume order lines. <CommsOrder>LineIdentification/BusinessCompo
nentID
Charge BRM adaptors use to relate one- NA No None <CommsOrder>EBO/<CommsOrder>Line/Charge
Parent Line time charges to base line ID. ParentLineIdentification/BusinessComponentID
ID
57
Related Links Move-Add to Move-Delete NA No None <CommsOrder>EBO/<CommsOrder>Line/Installe
Asset line items. dProductReference/PriorInstalledProductIdentifica
Integration tion/BusinessComponentID
ID
Depends Indicates order line item ID of a NA No None Cross-referenced. <CommsOrder>EBO/<CommsOrder>Line/Depend
On Line ID previous order line item that is ing<CommsOrder>LineReference/<CommsOrder
changed by this order. Follow-on >LineIdentification/BusinessComponentID
orders use this value to capture
dependencies of the order line
items in the follow-on order-to-
order line items of original orders.
Depends Identifies order ID of an in-flight NA No None Cross-referenced. <CommsOrder>EBO/<CommsOrder>Line/Depend
On Order ID order, which is the basis for this ing<CommsOrder>Reference/<CommsOrder>Ide
follow-on order line item. ntification/BusinessComponentID
Promotion References an order line that NA No AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/Promoti
Line ID represents the on<CommsOrder>LineReference/Promotion<Com
promotion/marketing offer under msOrder>LineIdentification/Identification/Business
which the order line is being ComponentID
purchased.
Promotion References an asset that NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/Promoti
Asset represents the on<CommsOrder>LineReference/InstalledProduct
Integration promotion/marketing offer under Reference/InstalledProductIdentification/Business
ID which the order line is being ComponentID
purchased.
Product ID References product record based NA Yes None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
on which order line is instantiated. erence/Identification/BusinessComponentID
Foreign key reference.
Quantity Identifies the quantity of the item NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/OrderQ
requested by a customer. Default uantity
is 1.
Action Code Specify action required to meet NONE,ADD,UP No None <CommsOrder>EBO/<CommsOrder>Line/Service
customer request DATE,SUSPEN ActionCode
D,RESUME,DE
LETE,MOVE-
ADD,MOVE-
DELETE
Requested When Null, the requested date for NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com
Delivery delivery of the goods or service is msOrder>Schedule/RequestedDeliveryDateTime
Date ASAP; otherwise, it is the specified
date. This date is not guaranteed.
Typically, it is a future date; if it is a
past date, then the default
behavior is the same as a Null
value.
58
Deliver To Address record that represents the NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/Service
Address delivery/service installation Address/Address
address.
Usage Start Determines the date when usage NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com
Date events should start being rated. msOrder>Schedule/ServiceUsageStartDate
The value for this attribute is
populated by CRM, OM Fulfillment
flows, or kept to Null for BRM
default to the current date.
Cycle State Determines the date when cycle NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com
Date charges should start being billed. msOrder>Schedule/CycleStartDate
The value for this attribute is
default to the current date as per
previous patterns.
Purchase Determines the date when one- NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com
Date time purchase charges should be msOrder>Schedule/PurchaseDate
billed. The value for this attribute is
default to current date as per
above patterns.
Service Indicates effective start date of NA Yes None Initially computed by Siebel based on <CommsOrder>EBO/<CommsOrder>Line/Effectiv
Start Date service. Due Date and then updated by Order eTimePeriod/StartDateTime
Management based on Actual
Delivery Date. Siebel support is
planned for a future release.
Earliest Identifies the date when the work NA No None <CommsOrder>EBO/<CommsOrder>Line/<Com
Delivery associated to the order provision msOrder>Schedule/EarliestDeliveryDateTime
Date can start. If a client goes on
vacation and needs to be at his
premises for the service to be
installed, then the start date can
be set to a later date.
Service End Indicates the effective end date of NA Yes None Initially computed in Siebel and then <CommsOrder>EBO/<CommsOrder>Line/Effectiv
Date service. Applies to services with a updated by Order Management. eTimePeriod/EndDateTime
specified duration. Update is sent to Siebel. Siebel
support is planned for a future
release.
59
Actual Determines the date when the NA Yes None BRM does not allow for starting any <CommsOrder>EBO/<CommsOrder>Line/<Com
Delivery purchased product or service is charges before the Purchase Date; msOrder>Schedule/ActualDeliveryDateTime
Date considered available to the therefore, the ABCS for BRM will
customer by the CSP. This date always override the Purchase Date if
may be when physical goods are it is later than any of the Cycle or
shipped, delivered, or their receipt Usage start dates.
is acknowledged. For service-
based products, the service is OM should facilitate calculation of
activated on this date. This date is Order Line level Actual Delivery Date
computed in the OM Fulfillment as well as Order Line attributes for
flow as per previous patterns. billing Usage Start Date, Cycle Start
Date, and Purchase Date.
Expected Indicates the due date expected by NA No None Computed by OM based on <CommsOrder>EBO/<CommsOrder>Line/<Com
Delivery the system as a result of Design preconfigured time estimates on msOrder>Schedule/ExpectedDeliveryDate
Date and Assign. The default os the fulfillment actions. Used by OM to
Order Due Date when the order is communicate to CRM changes to
created by CRM. expected delivery date of specific
Order Lines.
Status Updates orchestration and CRM In addition to Yes None At the time CRM submits an order, <CommsOrder>EBO/<CommsOrder>Line/Status/
as to the current status of order statuses used the Order Line status is set to Open. Code
line fulfillment at a high level. during Order An order will always be accepted;
Capture: guaranteed delivery is mandatory,
therefore, no need to track. After
(Canonical / orchestration starts, OM updates
Siebel): CRM Status to In Progress and it
(OPEN / Open), stays so until one of the following
( IN conditions occurs:
PROGRESS/ In • Fulfillment is failed due to a given
Progress), condition, such as insufficient data,
(FAILED / administrative intervention, and so
Failed), on. Status is updated to Failed with a
(CANCELLED / Status Context indicating the
Cancelled ), milestone and context.
(COMPLETE / • Order is cancelled either through
Complete) revision or administrative intervention,
and Status is updated to Canceled
with a Status Context indicating the
milestone and context.
• Fulfillment of Order Line and all of
its children are complete. Status is
updated to Complete.
Milestone Fulfillment passes the last reached NA No None <CommsOrder>/<CommsOrder>Line/MilestoneCo
milestone into this field. de
60
Status Provides details about the current NA Yes None OM could include the reached <CommsOrder>EBO/<CommsOrder>Line/Status/
Context status of the order line. The milestone (from the fulfillment system, Description
implementer configures this value. the cause for the status update that is
necessary because of dynamic
nature of fulfillment plan) and a
textual string for context per current
status as follows (canonical Status /
status context):
Submitted / NA
In Progress / <milestone>: context
text
Failed / <milestone>: reason text
Cancelled / <milestone>: reason text
Complete / NA
In Progress: Context Text could be

used to indicate any of the following
among others:
• Requires customer interaction
• Delivery is expected to be delayed
Point-of-no- Determines if Siebel should allow NOT YET, No None OM Fulfillment flows allow <CommsOrder>EBO/<CommsOrder>Line/Revisio
return order line revisions to be HARD configuration of setting a hard PONR nPermissibleCode
submitted. when a condition is met for a
particular service. When a hard
PONR is reached for an Order Line in
OM, a status update is issued to
reflect the same in CRM.
Billing References an account record that NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com
Account represents the bill payer or the msOrder>Schedule/BillToPartyReference/Custom
branch of a company responsible erPartyAccountIdentification/BusinessComponentI
for bill payment. D
This value may be a customer
account or an account from the
account hierarchy.
Billing References the billing profile NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com
Profile record that holds the customer’s msOrder>Schedule/BillToPartyReference/BillingPr
billing/payment preferences. ofileReference/BillingProfileIdentification/Business
This value may be associated to ComponentID
the customer account or to a
separate billing account.
Payment Identifies the Payment Profile. NA No None <CommsOrder>EBO/<CommsOrder>Line/<Com
Profile msOrder>Schedule/BillToPartyReference/BillingPr
ofileReference/PaymentProfileReference/Payment
ProfileIdentification/BusinessComponentID
61
Service References an account record that NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com
Account represents a service user or the msOrder>Schedule/OwnerPartyReference/Custo
branch of the company where merPartyAccountIdentification/BusinessCompone
service is installed. ntID
This value may be customer
account or an account from the
account hierarchy.
Owner Represents a contact of the NA Yes None <CommsOrder>EBO/<CommsOrder>Line/<Com
Contact customer account or service msOrder>Schedule/OwnerPartyReference/Custo
account who should be contacted merPartyAccountContactIdentification/BusinessCo
during fulfillment of the line if mponentID
required.
Shipping Represents a contact of the NA Yes None <CommsOrder>EBO/<CommsOrder>Line/<Com
Contact customer account or service msOrder>Schedule/ShipToPartyReference/Custo
account who should be contacted merPartyAccountContactIdentification/BusinessCo
for shipping purposes. mponentID
Node Alphanumerically references the NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
root order line that corresponds to der>LineSpecificationGroup/SpecificationGroup[./nam
access at site A of a connection. e="ExtensibleAttributes"]/Specification[./name="Node
"]/ValueText
This value is relevant for network
ordering only.
To Node Alphanumerically references the NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
root order line that corresponds to der>LineSpecificationGroup/SpecificationGroup[./nam
access at site B of a connection. e="ExtensibleAttributes"]/Specification[./name="ToNo
de"]/ValueText
This value is relevant for network
ordering only.
Network ID Unique compound product number NA Yes AIA2.4 Identifies which Access and Nodes <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
that represents the virtual network belong to the same network. This der>LineSpecificationGroup/SpecificationGroup[./nam
ID. Relevant for network orders. information may be of value to e="ExtensibleAttributes"]/Specification[./name="Netw
Provided by default from the order decomposition. orkID"]/ValueText
number and cascaded to network
connection items.
Port Identifies the port number NA Yes AIA2.4 For new services, port number comes <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Number allocated to the access circuit back from Network Inventory through der>LineSpecificationGroup/SpecificationGroup[./nam
connected to provide (starting) provisioning. e="ExtensibleAttributes"]/Specification[./name="PortN
edge router during the fulfillment umber"]/ValueText
process.
To Port Identifies the port number NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Number allocated to the access circuit der>LineSpecificationGroup/SpecificationGroup[./nam
connected to provide (ending) e="ExtensibleAttributes"]/Specification[./name="ToPo
edge router during the fulfillment rtNumber"]/ValueText
process.
62
Service Identifies the area code/NPA for NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Address the access circuits on starting or der>LineSpecificationGroup/SpecificationGroup[./nam
Prefix two ends of the connection. e="ExtensibleAttributes"]/Specification[./name="Servi
ceAddressPrefix"]/ValueText
To Service Identifies the area code/NPA for NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Address the access circuits on the end of der>LineSpecificationGroup/SpecificationGroup[./nam
Prefix the connection. e="ExtensibleAttributes"]/Specification[./name="ToSer
viceAddressPrefix"]/ValueText
Access Provides the Common Language NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Circuit Location Identification (CLLI) for der>LineSpecificationGroup/SpecificationGroup[./nam
the access circuit on two sides or e="ExtensibleAttributes"]/Specification[./name="Acces
starting side of the connection. sCircuit"]/ValueText
To Access Provides the CLLI for the access NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Circuit circuit on ending side of the der>LineSpecificationGroup/SpecificationGroup[./nam
connection. e="ExtensibleAttributes"]/Specification[./name="ToAc
cessCircuit"]/ValueText
To Service Identifies the Service Account ID NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Account ID associated with the end side of a der>LineSpecificationGroup/SpecificationGroup[./nam
network. e="ExtensibleAttributes"]/Specification[./name="ToSer
viceAccountID"]/ValueText
From Identifies the Service Address ID NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Service for the starting point of a network. der>LineSpecificationGroup/SpecificationGroup[./nam
Address ID e="ExtensibleAttributes"]/Specification[./name="From
ServiceAddressID"]/ValueText
To Service Identifies the Service Address ID NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Address ID for the ending point of a network. der>LineSpecificationGroup/SpecificationGroup[./nam
e="ExtensibleAttributes"]/Specification[./name="ToSer
viceAddressID"]/ValueText
To Service References a dummy asset record NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
Point ID that represents the access point to der>LineSpecificationGroup/SpecificationGroup[./nam
which the starting side of a e="ExtensibleAttributes"]/Specification[./name="ToSer
network service will be connected vicePointID"]/ValueText
on the customer’s premises.
Service References a dummy asset record NA Yes AIA2.4 Expected to be mastered in network <CommsOrder>EBO/<CommsOrder>Line/Service
Point that represents the access point to inventory and loaded in Siebel in PointCode
which this service will be batch.
connected on the customer’s
premises. For example, NTE for
PSTN, Set top box for
Broadband/Cable service.
63
Promotion Provides short description that will NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Description appear on the invoice. erence/Description
[Anila] [ToAdam]Is this a Promotion Description or
an ItemDescription or InvoiceDescription
[Adam] This is Promotion Description used for
display purposes on customer invoice
Service ID Identifies the product/service NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com
instance allocated by the fulfillment msOrder>Schedule/<CommsOrder>ItemInstance/I
(network service, physical item, dentification/ID
and so on) system during the
fulfillment process.
Updates Seibel as part of the order

updates received from the
fulfillment system during the order
fulfillment journey.
Supplied later for other order types

(action code other than Add) as
input to the fulfillment process.
Balance Identifies the Balance Bundle to NA Not Used by AIA for Comms 2.0 or <CommsOrder>EBO/<CommsOrder>Line/<Com
Bundle which a service instance belongs. 2.4. msOrder>Schedule/BalanceBundleIdentification/B
Identificatio usinessComponentID
n
Line Provides additional description for NA No None Not used by AIA for Comms 2.0 or <CommsOrder>EBO/<CommsOrder>Line/Descrip
Description an order line. For example, to 2.4. tion
indicate that a charge is being
applied for a penalty.
Service Indicates requested service length NA Yes Yes <CommsOrder>EBO/<CommsOrder>Line/<Com
Length in Service Length Unit of Measure. msOrder>Schedule/ServiceTimePeriod/Duration
Service Indicates the service length unit of NA Yes Yes <CommsOrder>EBO/<CommsOrder>Line/<Com
Length Unit measure. msOrder>Schedule/ServiceTimePeriod/Duration
of Measure
Fulfillment Designates compensation DO, No None <CommsOrder>EBO/<CommsOrder>Line/Fulfillm
Mode operations for Initiate Billing. May NOOP, entModeCode
be used in the future to provide REDO,
explicit revision operations at the UNDO
line level.
Product Provides the name of the product. NA <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Name erence/Name
64
Compositio Determines product composition <no value> for No None Consult Oracle on usage. <CommsOrder>EBO/<CommsOrder>Line/ItemRef
n Type granularity: NULL, erence/FulfillmentCompositionTypeCode
PARTIAL ITEM,
PartialItem is an order line that WHOLE ITEM
constitutes an indivisible element
of another order line. This type
typically denotes a piece of a
product.
WholeItem is an order line that

represents a self-contained
subject. A WholeItem may be
represented by a single line item
or a number of PartialItem order
lines.
May also assume no value

signified by a Null value or
absence of value.
Product Classifies products into Products, PRODUCT, No None Used part of fulfillment to determine <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Type Discounts, Bundles, Offers, and so OFFER, the order lines Subject Type, which erence/TypeCode
on. BUNDLE drives the mapping to Product
Specifications.
Billing Type Classifies products for Billing into SERVICE No None Used in conjunction with Product <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Service Bundles, Subscriptions, BUNDLE, Type. erence/ClassificationCode
Items, Discounts, and Special SUBSCRIPTIO [listID="BillingProductTypeCode"]
Ratings. N,
ITEM,
DISCOUNT,
SPECIAL
RATING
Billing Specifies the service type so that NA No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Service when a corresponding product is erence/ClassificationCode
Type created in Billing, it is associated [listID="PermittedTypeCode"]
to the specified service.
Service Indicates the product of a service TRUE, FALSE No None Used in conjunction with Product <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Flag or non-service, for example, Type and may be used to erence/ServiceIndicator
physical goods. parameterize fulfillment flows.
Vendor Identifies the vendor supplying the NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/ItemRef
product when the product is erence/SupplierPartyReference/PartyIdentification
supplied by a third party. /ID
Vendor Part Identifies the product part number NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Number to the vendor. erence/ItemIdentification/SupplierItemID
65
Fulfillment Uniquely identifies the mapping of 1) Null No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Item Code an Order Line Subject to a Product 2) A unique erence/ClassificationCode [listID =
Specification. code that "FulfillmentItemCode"]
identifies the
Product Spec to
OM
Item Class Determines business classification NA No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Name of a product. erence/PrimaryClassificationCode
Success Declares if all order lines of a DEFAULT, No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Dependenc bundle or offer must fulfill ALL OR NONE erence/FulfillmentSuccessCode
y successfully or else the whole
bundle or offer fails (all or none).
Start Billing When set to Yes by CRM or OSM, TRUE, FALSE No None Not yet supported by integration. <CommsOrder>EBO/<CommsOrder>Line/StartBill
on First passes the request along to BRM. ingOnFirstServiceUsageIndicator
Usage In this case, Usage Start Date, We have added BillingStartCode to
Cycle Start Date, and Purchase ItemReference, if this requirement is at the
Date should have no effect. item/itemReference level and not line level then
BillingStartCode from ItemReference should be
used.
Smart Part Automatically generated based on NA Yes None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Number a predefined scheme. erence/AlternateObjectKey
Mainly, drives dynamic product [ContextID=SmartPartNumber]
configuration/pricing rules in CRM.
The billing system may use it to
dynamically derive a price/discount
value.
Network Indicates if this is a network TRUE, FALSE No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Product product, which helps determine erence/NetworkIndicator
Flag which user-defined attributes to
expect.
Network Indicates if this network product NA No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef
Element represents a node, a connection, erence/NetworkItemTypeCode
Type or a network.
Charge Indicates charge frequency unit of NA <CommsOrder>EBO/<CommsOrder>Line/<Com
Frequency measure, for example, monthly, msOrder>Schedule/<CommsOrder>ScheduleCha
Code quarterly, yearly. rge/Charge/ChargeFrequencyCode
List Price Identifies price type. ONE-TIME, No None <CommsOrder>EBO/<CommsOrder>Line/<Com
Type RECURRING, msOrder>Schedule/<CommsOrder>ScheduleCha
USAGE rge/Charge/TypeCode
List Price Identifies base price of the item. NA Yes None <CommsOrder>EBO/<CommsOrder>Line/<Com
msOrder>Schedule/<CommsOrder>ScheduleCha
rge/Charge/UnitListPrice/Amount
Sale Price Identifies price type. ONE-TIME, No None <CommsOrder>EBO/<CommsOrder>Line/<Com
Type RECURRING, msOrder>Schedule/<CommsOrder>ScheduleCha
USAGE rge/Charge/TypeCode
66
Sale Price Identifies net price of the item. NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com
msOrder>Schedule/<CommsOrder>ScheduleCha
rge/Charge/UnitSalePrice/Amount
Pricing Indicates whether the pricing is Common/Siebel Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr
Commit Committed or Dynamic. values are der>Schedule/<CommsOrder>ScheduleCharge/C
Type true/Dynamic, harge/DynamicPricingIndicator
false/Committed
.
Dynamic Indicates whether the discount is AMOUNT, Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr
Discount of type amount or percent. PERCENT der>Schedule/<CommsOrder>ScheduleCharge/C
Method harge/DiscountMethodCode
Discount Indicates the percent by which the NA Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr
Percent list price is discounted. der>Schedule/<CommsOrder>ScheduleCharge/C
harge/DiscountPercent
Discount Indicates the amount by which the NA Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr
Amount list price is discounted der>Schedule/<CommsOrder>ScheduleCharge/C
harge/DiscountAmount
Member Represents a member of a list by NA No None Used for capturing membership to <CommsOrder>EBO/<CommsOrder>Line/<CommsOr
[0..N] their phone number. friends and family plans. der>LineSpecificationGroup/SpecificationGroup[./nam
e="ExtensibleAttributes"]/Specification[./name="Speci
alRating"]/ValueText [0..N]
User Indicates attribute is common NA Yes None UDA Name <CommsOrder>/<CommsOrder>Line/ItemReferen
Defined across all Specification ce/SpecificationGroup[name="ExtensibleAttributes
Attributes components. "]/Specification/Name
User Indicates attribute is common ADD, UPDATE, Yes None UDA Action Code (Expected to <CommsOrder>/<CommsOrder>Line/ItemReferen
Defined across all Specification DELETE change to a Service Action Code ce/SpecificationGroup[name="ExtensibleAttributes
Attributes components. element to allow additional value "]/Specification[name="<OrderLine.XA.Attribute>"]
NONE.) /@actionCode
User Indicates attribute is common NA Yes has UDA language-independent code <CommsOrder>/<CommsOrder>Line/ItemReferen
Defined across all Specification Previo Value ce/SpecificationGroup[name="ExtensibleAttributes
Attributes components. us LIC "]/Specification[name="<OrderLine.XA.Attribute>"]
Value /Value
User Indicates attribute is common STRING, DATE, Yes None UDA Data Type <CommsOrder>/Prior<CommsOrder>/<CommsOr
Defined across all Specification NUMBER der>Line/ItemReference/SpecificationGroup[name
Attributes components. ="ExtensibleAttributes"]/Specification[name="<Ord
erLine.XA.Attribute"]/DataTypeCode
User Indicates attribute is common NA Yes None UDA language-independent code <CommsOrder>/Prior<CommsOrder>/<CommsOr
Defined across all Specification Prior Value der>Line/ItemReference/SpecificationGroup[name
Attributes components. ="ExtensibleAttributes"]/Specification[name="<Ord
erLine.XA.Attribute>"]/Value
67

Whitepaper - OrderToCashSolutionAproach PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Whitepaper - OrderToCashSolutionAproach PDF

Transféré par

Droits d'auteur :

Formats disponibles

Oracle AIA for Communications –

Order to Activate Solution Approach

An Oracle White Paper

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Oracle AIA for Communications – Order to

Oracle AIA for Communications and Order to

Oracle Communications Concept to Cash Solutions Offering

Oracle Communications RODOD Solution

Oracle Communications UCB Solution

General Ledger General Ledger

Order Management (Central Fulfillment)

Provisioning Provisioning Provisioning

Activation Activation Activation

VoIP UK DSL DSL

Business Benefits Drive Design Criteria

Business Benefits / Driver Design Criteria

Order to Activate Business Process Flows

Understanding the Order Capture Sub-Flow

AIA for Comms: Order to Activate Functional Flow

Validation Good ATP

How to read this Order Capture Sub-Flow chart:

Understanding the Deliver Customer Order Sub-Flow

AIA for Comms: Order to Activate Functional Flow

Order Submit Order Create/Update Update Create/Update

A+B O2A A+B

Decompose Order, Route Order Components Order Status

O2B O2B O2A O2B

Sync Various APIs

* Deliver Service involves

Point to Integration Integration Common AIA

How to read this Deliver Customer Order Sub-Flow chart:

Understanding the Qualify Customer Order Sub-Flow

AIA for Comms: Order to Activate Functional Flow

Order Technical Service Qualification Create/Update Update

A+B O2A A+B

Decompose Order, Route Order Components

Integration Product Common AIA

How to read this Deliver Customer Order Sub-Flow chart:

Order to Activate Design Considerations

Order to Activate Deployment Topology Design Considerations

General Ledger General Ledger

Order Management (Central Fulfillment)

Provisioning Provisioning Provisioning

Activation Activation Activation

VoIP UK DSL DSL

General Ledger General Ledger

Order Management (Central Fulfillment)

Provisioning Provisioning Provisioning

Activation Activation Activation

VoIP UK DSL DSL

General Ledger General Ledger

Order Management (Central Fulfillment)

Activation Activation Activation

VoIP UK DSL DSL

General Ledger General Ledger

Order Management (Central Fulfillment)

Activation Activation Activation

VoIP UK DSL DSL

Product Definition and Mapping Design Considerations

The Product and Service Definition

network, IT, and business departments to

in simplified overall Product Life Cycle and

Order Life Cycle business flows. Product