Your SlideShare is downloading. ×
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Order to Activate Integrated Business Process Using AIA
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Order to Activate Integrated Business Process Using AIA

508

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
508
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Guidelines for Building an Order to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4 An Oracle White Paper June 2009
  • 2. Guidelines for Building an Order to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4. Copyright © 2009, 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.
  • 3. Guidelines for Building an Order to Activate Integrated Business Process 3 Table of Contents Guidelines for Building an Order to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4 .......................................................................................5 Getting Started ........................................................................................................................6 Business Benefits Drive Design Criteria ..............................................................................7 Order to Activate Business Process Flows..............................................................................8 Understanding the Order Capture Sub-Flow........................................................................9 Understanding the Deliver Customer Order Sub-Flow.......................................................10 Understanding the Qualify Customer Order Sub-Flow.......................................................12 Order to Activate Design Considerations...............................................................................13 Order to Activate Deployment Topology Design Considerations .......................................13 Product Definition and Mapping Design Considerations....................................................16 Order Update Design Considerations ................................................................................19 Revision Orders Design Considerations ............................................................................21 Billing Fulfillment Design Considerations...........................................................................24 Multiple Features Design Considerations ..........................................................................26 Order Management Integration Design Considerations.....................................................30 Order to Activate Integration Components ............................................................................32 Order to Activate Sample Use Cases....................................................................................39 Use Cases Setup...............................................................................................................39 Double Play Promotion First-Time Purchase.....................................................................46 Double Play Change Order................................................................................................50 Double Play Revision Order...............................................................................................54 Communications Orders Dictionary.......................................................................................60 Communications’ Orders - Order Header Component Attributes.......................................60 Communications Orders - Order Line Component Attributes.............................................66
  • 4. Guidelines for Building an Order to Activate Integrated Business Process 5 Guidelines for Building an Order to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4 This white paper provides design guidance for building an integrated Order to Activate business process based on the following components: 1. AIA for Communications Foundation Pack 2.4 2. AIA for Communications Order to Billing Process Integration Pack 2.4 3. Any Customer Order Management system 4. Any Service Order Management (also know as Provisioning) system We attempted to align this guidance with Oracle’s implementation of the Order to Activate Process Integration Pack (PIP) part of a future release of AIA for Communications. Oracle’s solution uses Oracle Order and Service Management (OSM) for both customer order management and service order management (provisioning). This white paper was authored while Oracle’s solution was being developed, therefore, we cannot guarantee 100 percent alignment. This white paper assumes basic knowledge of AIA, Siebel and Order Management functionality and terminology.
  • 5. Guidelines for Building an Order to Activate Integrated Business Process 6 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. 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 white paper 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. BRM-REZ (Residential) Provisioning VoIP Order Management (Central Fulfillment) Network Inventory Activation VoIP Provisioning UK DSL Network Inventory DSL Activation UK DSL Provisioning DSL Activation DSL CRM Order Capture Payment & Collections General Ledger BRM-BIZ (Business) Payment & Collections Payment & Collections Shipping PartnerInc Shipping InHouse WFM All CRM Service BRM-WLS (Wholesale) Payment & Collections General Ledger Payment & Collections Payment & Collections
  • 6. Guidelines for Building an Order to Activate Integrated Business Process 7 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 • Once identified, introduce more of the same commercial offerings within hours. • Once identified and the infrastructure is ready, introduce new services within days. Decouple commercial offerings and fulfillment flows. Enable product- and order-driven fulfillment flows. 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 experience Control fallout conditions. 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 white paper.
  • 7. Guidelines for Building an Order to Activate Integrated Business Process 8 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 white paper 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. 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.
  • 8. Guidelines for Building an Order to Activate Integrated Business Process 9 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. ORDER CAPTURE SUB-FLOW AIA for Comms: Order to Activate Functional Flow OrderLifecycle Management CRM Make Product Choices Run Credit Check Check / Create Account Pricing Product Validation Submit Order Schedule Appointment (WFM) Physical Good ATP Inventory Resource Reservation Technical Service Qualification Qualify Customer Order Deliver Customer Order AIA Based Integration Points Application Activity Legend Optional Application Activity Within Product 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.
  • 9. Guidelines for Building an Order to Activate Integrated Business Process 10 Understanding the Deliver Customer Order Sub-Flow The following chart illustrates a typical Deliver Customer Order flow: DELIVER ORDER SUB-FLOW AIA for Comms: Order to Activate Functional Flow Provisioning Provision Order: Transform & Enrich Order; Decompose Order and Provision Services OrderLifecycle Management Orchestrate Order: Transform / Enrich Order; Decompose & Route Order Components CRM Order Capture Activa- tion Network Inventory Billing Submit Order (New, Revision, Follow-on) Order Status Management Various APIsVarious APIs Sync Customer Order Status Management Design Service Various APIs Update Order & Status Transform / Enrich Order Deliver Service * Design Service Decompose Order Transform / Enrich Order Decompose Order, Route Order Components & Listen to Responses and Updates Sync Customer Initiate Billing Provision Order Fulfill Billing Manage Fallout Create/Update Trouble Ticket Update Order Update Order & Status * Deliver Service involves execution of a provisioning flow Sample Central Fulfillment Deliver Flow O2AO2B O2B O2B O2A O2A A+BA+B Create/Update Customer Assets Legend Application Activity Application APIs Flow Activity Optional Activity Within Product Flow SI Provided Point to Point Integrations AIA Based Integration Points Order To Bill & Order To Activate Common AIA Integration Point A+BO2A Order To Bill Integration Point O2B Order To Activate Integration 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 that are 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 that are part of Order To Activate, O2B for integration points that are part of Order To Bill and A+B for integration points that are 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.
  • 10. Guidelines for Building an Order to Activate Integrated Business Process 11 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. 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 white paper. 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.
  • 11. Guidelines for Building an Order to Activate Integrated Business Process 12 Understanding the Qualify Customer Order Sub-Flow The following chart illustrates a typical Qualify Customer Order flow: QUALIFY ORDER SUB-FLOW AIA for Comms: Order to Activate Functional Flow Provisioning Provision Order: Transform & Enrich Order; Decompose Order and Provision Services OrderLifecycle Management Orchestrate Order: Transform / Enrich Order; Decompose & Route Order Components Activa- tion Network Inventory BillingCRM Order Status Management Order Capture Decompose Order, Route Order Components & Listen to Responses and Updates O2A Design Service Order Status Management Provision Order O2A O2A Manage Fallout Sample Central Fulfillment TSQ Flow Update Order Technical Service Qualification (via submit order API) Transform / Enrich Order Update Order & Status Update Order & Status Create/Update Trouble Ticket A+B Design Service Decompose Order Transform / Enrich Order A+B Flow Activity Order To Activate AIA Integration Point AIA Based Integration Points SI Provided Point to Point Integrations O2AApplication APIs Within Product Flow Application Activity Legend Order To Bill & Order To Activate Common AIA Integration Point A+B 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 as 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 that are part of Order To Activate and A+B for integration points that are 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 is 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.
  • 12. Guidelines for Building an Order to Activate Integrated Business Process 13 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: 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. BRM-REZ (Residential) Provisioning VoIP Order Management (Central Fulfillment) Network Inventory Activation VoIP Provisioning UK DSL Network Inventory DSL Activation UK DSL Provisioning DSL Activation DSL CRM Order Capture Payment & Collections General Ledger BRM-BIZ (Business) Payment & Collections Payment & Collections Shipping PartnerInc Shipping InHouse WFM All CRM Service BRM-WLS (Wholesale) Payment & Collections General Ledger Payment & Collections Payment & Collections
  • 13. Guidelines for Building an Order to Activate Integrated Business Process 14 The Order Management system recognizes fulfillment systems by type. The following diagram overlays system types on the topology we are discussing: 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: BRM-REZ (Residential) Provisioning VoIP Order Management (Central Fulfillment) Network Inventory Activation VoIP Provisioning UK DSL Network Inventory DSL Activation UK DSL Provisioning DSL Activation DSL CRM Order Capture Payment & Collections General Ledger BRM-BIZ (Business) Payment & Collections Payment & Collections Shipping PartnerInc Shipping InHouse WFM All CRM Service BRM-WLS (Wholesale) Payment & Collections General Ledger Payment & Collections Payment & Collections BRM-REZ (Residential) Provisioning VoIP Order Management (Central Fulfillment) Network Inventory Activation VoIP Provisioning UK DSL Network Inventory DSL Activation UK DSL Provisioning DSL Activation DSL CRM Order Capture Payment & Collections General Ledger BRM-BIZ (Business) Payment & Collections Payment & Collections Shipping PartnerInc Shipping InHouse WFM All CRM Service BRM-WLS (Wholesale) Payment & Collections General Ledger Payment & Collections Payment & Collections 3 1 2 4 5 6789 10 1 3 7 8 9 21 3 7 8 9 2
  • 14. Guidelines for Building an Order to Activate Integrated Business Process 15 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: 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: 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. BRM-REZ (Residential) Provisioning VoIP Order Management (Central Fulfillment) Network Inventory Activation VoIP Provisioning UK DSL Network Inventory DSL Activation UK DSL Provisioning DSL Activation DSL CRM Order Capture Payment & Collections General Ledger BRM-BIZ (Business) Payment & Collections Payment & Collections Shipping PartnerInc Shipping InHouse WFM All CRM Service BRM-WLS (Wholesale) Payment & Collections General Ledger Payment & Collections Payment & Collections 3 1 2 4 5 6789 10 1 3 7 8 9 21 3 7 8 9 2
  • 15. Guidelines for Building an Order to Activate Integrated Business Process 16 Deployment Topology Guidance Summary This table summarizes this deployment topology consideration and guidance: Product Definition and Mapping Design Considerations The Product and Service Definition methodology has the greatest effect on time to market and on the cost of an Order to Activate deployment. Often, products and services are defined in different network, IT, and business departments to serve the best interests of individual departments. This approach creates a challenge for bridging the gaps at runtime. We recommend a balanced approach that would require departments to make calculated compromises that would result in simplified overall Product Life Cycle and Order Life Cycle business flows. The Product Model diagram aligns with TMF (Tele Management Forum) terminology and guidelines. This diagram takes a step further to provide guidance about the mechanics of achieving a balanced product definition model. 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. Commercial Offerings Customer Order Fulfillment ServiceOrder Fulfillment Commercial Bundle Commercial Offer Technical Service Resource Commercial Product Product Specification 0..1 0..n 0..n 0..n 0..n 1 1..n 1..n 0..n0..n Product Model 0..n 0..n 0..n 0..n Order Management should abstract fulfillment topology such that fulfillment flows and product specifications aren’t affected by common changes to fulfillment topology. Fulfillment Topology1 GuidanceConsideration# Order Management should abstract fulfillment topology such that fulfillment flows and product specifications aren’t affected by common changes to fulfillment topology. Fulfillment Topology1 GuidanceConsideration#
  • 16. Guidelines for Building an Order to Activate Integrated Business Process 17 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 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 white paper. Therefore, the sample use cases included in the following section do not reach this level of detail.
  • 17. Guidelines for Building an Order to Activate Integrated Business Process 18 The following diagram shows how the Order Management system takes advantage of the Product Model to map customer order lines to fulfillment flows. 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. Product Model Guidance Summary Identification: Order ID; Order Number + Revision Fulfillment Mode Order Priority Order Job Parent Order . . . Identification: Order Line ID Action Code Fulfillment Item Code Product Type Code Billing Type . . . Order Header Order Lines Identification: Order Line ID Action Code Fulfillment Item Code Product Type Code Billing Type . . . Order Fulfillment Design Time Metadata  Adopt a compatible product model.  Leverage Fulfillment Item Code for mapping Commercial Products to Product Specifications or vice versa.  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). Product Model has critical impact on sought Fulfillment business benefits 1 GuidanceConsideration#  Adopt a compatible product model.  Leverage Fulfillment Item Code for mapping Commercial Products to Product Specifications or vice versa.  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). Product Model has critical impact on sought Fulfillment business benefits 1 GuidanceConsideration#
  • 18. Guidelines for Building an Order to Activate Integrated Business Process 19 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 white paper for more information. # Functional Attribute Name Usage 1 Order Line / Status Provides high-level update of the current status of order line fulfillment to Order Management and CRM. 2 Order Line / Milestone The last reached fulfillment milestone. 3 Order Line / Status Context Provides details about the current status. An implementer can configure this 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 / Point-of-no- return Indicates if Siebel should allow revisions to an order line or submission of previously-created revisions to an order line. OSM Fulfillment flows allow 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 Order Line in OSM an update is issued to reflect the same in CRM. With AIA for Communications 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 / Status Updates CRM updated on the current status of order fulfillment at a high level. 6 Order Line / Actual Delivery Date Determines the date when the purchased product or service is considered available to the customer by the CSP. This may be the date physical goods 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 Assign. Customers can change this value if they amend the order. When
  • 19. Guidelines for Building an Order to Activate Integrated Business Process 20 # Functional Attribute Name Usage Delivery Date 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 / Status Context Provides details about the current status. The implementer can configure this value. When referring to order or order line status in this white paper, 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. 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.
  • 20. Guidelines for Building an Order to Activate Integrated Business Process 21 Order Update Guidance Summary: 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. 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.  Channel all updates through the provided single AIA service operation.  Map updates to common lifecycle, status and fallout conditions. Updates from Fulfillment Systems to Order Management 3  Avoid sending order data updates prior to point of no return  Make data updates with or before updating CRM with Complete order line status  Set the Order Changed Flag when order changes contravene customer intent. Update Order Data in CRM 2  Use the extended set of status attributes adopted by O2A FP.  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 Order Fulfillment Visibility in CRM 1 GuidanceConsideration#  Channel all updates through the provided single AIA service operation.  Map updates to common lifecycle, status and fallout conditions. Updates from Fulfillment Systems to Order Management 3  Avoid sending order data updates prior to point of no return  Make data updates with or before updating CRM with Complete order line status  Set the Order Changed Flag when order changes contravene customer intent. Update Order Data in CRM 2  Use the extended set of status attributes adopted by O2A FP.  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 Order Fulfillment Visibility in CRM 1 GuidanceConsideration#
  • 21. Guidelines for Building an Order to Activate Integrated Business Process 22 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 white paper 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. # Functional Attribute Name Usage 1 Order Header / Order ID Alphanumeric identifier for the order. This value is unique for each revision. The Order Management System should preserve this ID and pass it to fulfillment systems. 2 Order Header / Order Number Alphanumeric identifier for the order. This value does not change across revisions. This value and the Revision attribute are used to identify order revisions in Order Management. 3 Order Header / Revision Numeric identifier of order revisions made during the fulfillment process.
  • 22. Guidelines for Building an Order to Activate Integrated Business Process 23 # Functional Attribute Name Usage 4 Order line / Line Item ID Unique, auto-generated identifier of the order line across orders and order revisions. 5 Order line / Base Line Item ID Reference to the revised order line ID from the base order. Order Management uses this attribute to match order lines across revisions of the same order. 6 Order Header / Fulfillment Mode Fulfillment request type. The Cancel value is a special case used to cancel an entire order. Revision Orders Guidance Summary  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. Computing changes3  Adhere to order compensation specifications for BRM AIA interfaces.  Delegate revisions to Provisioning to avoid bringing technical knowledge to Order Management. Compensation5  Support four patterns:  Order level cancel (Fulfillment Mode = CANCEL)  Order line dropped  Order line’s Action Code reverts to no action  False updates Canceled order, order line4  Find alternatives to keeping more than one pending revision in Siebel. For AIA 2.4 this is blocked by Siebel. Staled revisions2  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. Point-of-No_Return (PONR)1 GuidanceConsideration#  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. Computing changes3  Adhere to order compensation specifications for BRM AIA interfaces.  Delegate revisions to Provisioning to avoid bringing technical knowledge to Order Management. Compensation5  Support four patterns:  Order level cancel (Fulfillment Mode = CANCEL)  Order line dropped  Order line’s Action Code reverts to no action  False updates Canceled order, order line4  Find alternatives to keeping more than one pending revision in Siebel. For AIA 2.4 this is blocked by Siebel. Staled revisions2  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. Point-of-No_Return (PONR)1 GuidanceConsideration#
  • 23. Guidelines for Building an Order to Activate Integrated Business Process 24 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. 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.
  • 24. Guidelines for Building an Order to Activate Integrated Business Process 25 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: # Functional Attribute Name Usage 1 Order Line / Usage Start Date Determines the date when usage events should start being rated. 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. 2 Order Line / Cycle State Date Determines the date when cycle charges should start being billed. 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. 3 Order Line / Purchase Date Determines the date when one-time purchase charges should be billed. 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 / Actual Delivery Date Determines the date when the purchased product or service are considered available to the customer by the CSP. This date may be when 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 / Requested Delivery Date A Null value means that the requested delivery date for the good or service is ASAP; otherwise, it is the specified date. This date is not guaranteed. 6 Order Line / Start Billing on First Usage When this value is set to Yes by CRM or Order Management, the request is passed along to BRM. In this case, Usage Start Date, Cycle Start Date, 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.
  • 25. Guidelines for Building an Order to Activate Integrated Business Process 26 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 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.  Support for single-phase and two-phase billing 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. Billing fulfillment patterns 1 GuidanceConsideration#  Support for single-phase and two-phase billing 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. Billing fulfillment patterns 1 GuidanceConsideration#
  • 26. Guidelines for Building an Order to Activate Integrated Business Process 27 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 Attribute Name Usage 1 Order Line / Depends On Line Item ID Order Line Item ID of a base order line item that is changed by this order. Used to establish dependency between order line on follow-on order and order line on base order. 2 Order Line / Depends On Order ID Order ID of an in-flight order. It is the basis for this follow-on order line item. 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 Attribute Name Usage 1 Order Header / Parent Order ID Establishes cross-order dependencies between a child and parent order. 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.
  • 27. Guidelines for Building an Order to Activate Integrated Business Process 28 This table describes Order Priority attributes and values: # Functional Attribute Name Usage 1 Order Header / Fulfillment Priority Relevant priority of order fulfillment across orders. A lower value 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. 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 Attribute Name Usage 1 Order Header / Job ID Uniquely identifies a job to the orchestration plan. This value should be long enough to 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 job, 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.
  • 28. Guidelines for Building an Order to Activate Integrated Business Process 29 Qualify Order Sub-Flow AIA for Communications 2.4 uses the order header Fulfillment Mode attribute to determine the characteristics of the fulfillment request. # Functional Attribute Name Usage 1 Order Header / Fulfillment Mode Qualifies the orchestration required for a particular sales order submission. As delivered, AIA for Communications 2.4 and Siebel extensions support Deliver, Cancel, and Get Provider values. See the Communication Orders Dictionary topic in this white paper 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 white paper. Multiple Features Guidance Summary  Extend Siebel and integration to support Technical Service Qualification, if required. Qualify Customer Order 6  Use Job Id to correlate identify individually submitted orders to a Job Order.  Support reporting and bulk actions on Job Orders. Order Priority and Job Orders 5  Support order cross-order-line dependencies to support follow-on orders. Follow-On Orders2  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). Order Priority4  Support order level (parent-child) dependencies.Cross-Order Dependencies 3  Compute fulfillment start date in Order Management.  Start fulfillment of an order ASAP, if the fulfillment start date is current or in the past. Future-Dated Orders1 GuidanceConsideration#  Extend Siebel and integration to support Technical Service Qualification, if required. Qualify Customer Order 6  Use Job Id to correlate identify individually submitted orders to a Job Order.  Support reporting and bulk actions on Job Orders. Order Priority and Job Orders 5  Support order cross-order-line dependencies to support follow-on orders. Follow-On Orders2  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). Order Priority4  Support order level (parent-child) dependencies.Cross-Order Dependencies 3  Compute fulfillment start date in Order Management.  Start fulfillment of an order ASAP, if the fulfillment start date is current or in the past. Future-Dated Orders1 GuidanceConsideration#
  • 29. Guidelines for Building an Order to Activate Integrated Business Process 30 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. 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.
  • 30. Guidelines for Building an Order to Activate Integrated Business Process 31 Order Management Integration Guidance Summary  Consume AIA Errors off AIA Error Handler into Order Management fallout handling.  Create Siebel Trouble Tickets for fallout incidents. Fallout Management2  Honors system interaction contracts for fulfillment functions, 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. Order Management System Interactions 1 GuidanceConsideration#  Consume AIA Errors off AIA Error Handler into Order Management fallout handling.  Create Siebel Trouble Tickets for fallout incidents. Fallout Management2  Honors system interaction contracts for fulfillment functions, 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. Order Management System Interactions 1 GuidanceConsideration#
  • 31. Guidelines for Building an Order to Activate Integrated Business Process 32 Order to Activate Integration Components Building Order to Activate to incorporate any Order Management system and any Provisioning system could leverage the AIA for Communications Foundation Pack along with the Order to Bill PIP components. Always use the latest AIA for Communications version, as newer versions are enhanced with richer objects and services. At a minimum, we recommend that you start with AIA for Communications 2.4, which is the latest release available at the time of authoring this white paper. Please refer to the AIA for Communications respective guides and documentation for general architecture and deployment-specific information. This section summarizes the various AIA components that are available to integrate Siebel and BRM to any Order Management system and to any Provisioning system.
  • 32. Guidelines for Building an Order to Activate Integrated Business Process 33 The following diagram shows the available integration resources. Tasks and details about the components are listed following the diagram. AIA for Comms 2.4: Order to Activate Integration Components AIAError Handling Prov- isioning OrderLifecycle Management Orchestrate Customer Order BillingCRM Sync Customer Update Customer Order & Status Initiate Billing Submit Order (DELIVER or QUALIFY : New, Revision or Follow-on) Provision Order Update Order & Status Sync Customer Order Capture Fulfill Billing Fulfill Billing Initiate Billing Provision Order Update Order Suspend Order Resume Order Cancel Order Create Trouble Ticket Legend Application APIs Flow Activity AIA Based Integration Points FP PIP ComponentsPIPFoundation Pack Components Create Trouble Ticket Error Queue Read AIA Errors Update Fulfillment Order Suspend Provisioning Order Cancel Provisioning Order Resume Provisioning Order PIPPIP PIP PIP PIP FP PIP FP FP FP FP
  • 33. Guidelines for Building an Order to Activate Integrated Business Process 34 The following AIA integration components are available to build Order to Activate. 1. Submit Sales Order from CRM to Order Management: System Component Type Component Name Outbound Payload Usage Remarks Siebel Queue AIA_SALESORDERJMSQUEUE SalesOrderABM Ready to use per Oracle methodology. FMW Consumer ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer SalesOrderABM FMW ABCS ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl ProcessSalesOrderFulfillmentEBM FMW EBS CommunicationsSalesOrderEBSV2.ProcessSalesOrderFulfillment ProcessSalesOrderFulfillmentEBM FMW Producer ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer CreateOrder Samples are specific to each Order Management system. Order Management Queue AIA_CRTFO_IN_JMSQ CreateOrder 2. Update Sales Order from Order Management to CRM: System Component Type Component Name Outbound Payload Usage Remarks Order Management Queue AIA_UPDSO_OUT_JMSQ UpdateFulfillmentOrder Samples are specific to each Order Management system.FMW Consumer UpdateSalesOrderOSMCFSCommsJMSConsumer UpdateSalesOrderEBM FMW EBS CommunicationsSalesOrderEBSV2.UpdateSalesOrder UpdateSalesOrderEBM Ready to use per Oracle methodology.FMW ABCS UpdateSalesOrderSiebelCommsProvABCSImpl SalesOrderABM Siebel Web Service NA NA Not relevant. 3. Sync Customer from Order Management to BRM and Response: System Compone nt Type Component Name Outbound Payload Usage Remarks Order Queue AIA_CRTCUST_OUT_JMSQ CreateFulfillmentOrder Samples are
  • 34. Guidelines for Building an Order to Activate Integrated Business Process 35 System Compone nt Type Component Name Outbound Payload Usage Remarks Managemen t specific to each Order Management system. FMW Consumer ProcessFulfillmentOrderBillingAccountListO SMCFSCommsJMSConsumer ProcessFulfillmentOrderBillingAccountListEBM FMW EBS CommunicationsBillingEBSV1.ProcessFulfil lmentOrderBillingAccountList ProcessFulfillmentOrderBillingAccountListEBM Ready to use per Oracle methodology.FMW EBF CommsProcessFulfillmentOrderBillingAcco untListEBF ProcessBillingAccountListEBM FMW EBS CommunicationsBillingResponseEBSV1. ProcessFulfillmentOrderBillingAccountListR esponse ProcessFulfillmentOrderBillingAccountListRes ponseEBM FMW Producer ProcessFufillmentOrderBillingAccountListR esponseOSMCFSCommsJMSProducer ReceiveFulfillmentOrderUpdate Samples are specific to each Order Management system. Order Managemen t Queue AIA_UPDCUST_IN_JMSQ ReceiveFulfillmentOrderUpdate 4. Initiate Billing and Fulfill Billing from Order Management to BRM and Response. Initiate and Fulfill are determined based on the value of the Fulfillment Mode attribute: System Compone nt Type Component Name Outbound Payload Usage Remarks Order Managem ent Queue AIA_CRTBO_OUT_JMSQ CreateFulfillmentOrder Samples are specific to each Order Management system. FMW Consumer CreateFulfillmentOrderOSMCFSCommsJMSCons umer ProcessFulfillmentOrderBillingEBM FMW EBS CommunicationsBillingEBSV1.ProcessFulfillment OrderBilling ProcessFulfillmentOrderBillingEBM Ready to use per Oracle methodology.FMW ABCS ProcessFulflilmentOrderBillingBRMCommsProvA BCSImpl Several opcodes
  • 35. Guidelines for Building an Order to Activate Integrated Business Process 36 System Compone nt Type Component Name Outbound Payload Usage Remarks BRM OpCodes Several Several responses FMW ABCS ProcessFulflilmentOrderBillingBRMCommsProvA BCSImpl ProcessFulfillmentOrderBillingResp onseEBM FMW EBS CommunicationsBillingEBSV1.ProcessFulfillment OrderBillingResponse ProcessFulfillmentOrderBillingResp onseEBM FMW Producer ProcessFufillmentOrderBillingResponseOSMCFS CommsJMSProducer ReceiveFulfillmentOrderUpdate Samples are specific to each Order Management system. Order Managem ent Queue AIA_UPDBO_IN_JMSQ ReceiveFulfillmentOrderUpdate 5. Provision Order from Order Management to Provisioning: System Componen t Type Component Name Outbound Payload Usage Remarks Order Manageme nt Queue NA NA Specific to each Order Management System. SI build. FMW Consumer NA ProcessProvisioningOrderEBM FMW EBS CommunicationsProvisioningOrderEBSV 1.ProcessProvisioningOrder ProcessProvisioningOrderEBM Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning System. SI build.Provisioning Queue NA NA 6. Cancel Provisioning Order from Order Management to Provisioning: System Componen t Type Component Name Outbound Payload Usage Remarks Order Manageme Queue NA NA Specific to each Order
  • 36. Guidelines for Building an Order to Activate Integrated Business Process 37 System Componen t Type Component Name Outbound Payload Usage Remarks nt Management System. SI build. FMW Consumer NA CancelProvisioningOrderEBM FMW EBS CommunicationsProvisioningOrderEBSV 1.CancelProvisioningOrder CancelProvisioningOrderEBM Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning System. SI build.Provisioning Queue NA NA 7. Suspend Provisioning Order from Order Management to Provisioning: System Componen t Type Component Name Outbound Payload Usage Remarks Order Manageme nt Queue NA NA Specific to each Order Management System. SI build. FMW Consumer NA SuspendProvisioningOrderEBM FMW EBS CommunicationsProvisioningOrderEBSV 1.SuspendProvisioningOrder SuspendProvisioningOrderEBM Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning System. SI build.Provisioning Queue NA NA 8. Resume Provisioning Order from Order Management to Provisioning: System Componen t Type Component Name Outbound Payload Usage Remarks Order Manageme nt Queue NA NA Specific to each Order Management System. SI build. FMW Consumer NA ResumeProvisioningOrderEBM FMW EBS CommunicationsProvisioningOrderEBSV 1.ResumeProvisioningOrder ResumeProvisioningOrderEBM Ready to use per Oracle methodology.
  • 37. Guidelines for Building an Order to Activate Integrated Business Process 38 System Componen t Type Component Name Outbound Payload Usage Remarks FMW Producer NA NA Specific to each Provisioning System. SI build.Provisioning Queue NA NA 9. Update Fulfillment Order from Provisioning to Order Management: System Componen t Type Component Name Outbound Payload Usage Remarks Provisioning Queue NA NA Specific to each Order Management System. SI build. FMW Consumer NA ReceiveFulfillmentOrderUpdateEB M FMW EBS CommunicationsFulfillmentOrderEBSV1. ProcessFulfillmentOrderUpdate ReceiveFulfillmentOrderUpdateEB M Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning System. SI build.Order Manageme nt Queue NA NA 10. Create Trouble Ticket from Order Management to Siebel: AIA TOPIC is configured part of O2B and comes with the consumer. An O2A implementer could use the consumer directly or push the message into a Queue for Order Management to consume. System Component Type Component Name Outbound Payload Usage Remarks Order Management Queue NA NA Specific to each Order Management System. SI build.FMW Consumer NA CreateTroubleTicketEBM FMW EBS CommunicationsTroubleTicketEBSV1.Create CreateTroubleTicketEBM Ready to use per Oracle methodology.FMW ABCS CreateTroubleTicketSiebelCommsProvABCSImpl TroubleTicketInsert_input Siebel Web Services NA Not relevant
  • 38. Guidelines for Building an Order to Activate Integrated Business Process 39 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 {parent line #} Relationship Type Cardinality (min, max, default) Name Price Type List Price Subject Type (computed during fulfillment) 1 Bundled Promotion {} On Top of the World Broadband-VoIP Offer 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
  • 39. Guidelines for Building an Order to Activate Integrated Business Process 40 # Siebel Object {parent line #} Relationship Type Cardinality (min, max, default) Name Price Type List Price Subject Type (computed during fulfillment) 17 .. Dynamic Class {16} Dynamic Class (1,1,1) VoIP Service Plan DClass 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 Month Free Discount MRC 100% Discount 23 SP {} Product (1,11) High Speed Internet Activation Discount OTC 100% 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 {parent line #} Name Price Type List Price Subject Type (computed during fulfillment) 1 Dynamic Class {} VoIP Service Plan DClass NA 2 .SP {1} Basic VoIP MRC $15 Product 3 .SP {1} VoIP w/ unlimited calls MRC $60 Product
  • 40. Guidelines for Building an Order to Activate Integrated Business Process 41 Internet Service Dynamic Class that includes the three high-speed internet alternative products is created for dynamic reusability: # Siebel Object {parent line #} Name Price Type List Price Subject Type (computed during fulfillment) 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: # Siebel Object {parent line #} Name Price Type List Price Subject Type (computed during fulfillment) 1 Dynamic Class {} Internet Modems DClass NA 2 .SP {1} Motorola Modem OTC $0 Product 3 .SP {1} Dynex Modem OTC $0 Product
  • 41. Guidelines for Building an Order to Activate Integrated Business Process 42 Typical Fulfillment Topology This diagram shows a typical fulfillment topology: 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 BRM-REZBDB (Residential Broadband) Provisioning VoIP Central Fulfillment Process Network Inventory Activation VoIP Provisioning UK DSL Network Inventory DSL Activation UK DSL Provisioning DSL Activation DSL CRM Order Capture Payment & Collections General Ledger BRM-BIZBDB (Business Broadband) Payment & Collections Payment & Collections Shipping PartnerInc Shipping InHouse WFM All CRM Service BRM-VOIP (VOIP Services)
  • 42. Guidelines for Building an Order to Activate Integrated Business Process 43 # Fulfillment System Type Provider Determinants 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 Action AIA Service Operation Fulfillment System Type Processing Granularity Milestones 1 SyncCustomer ProcessFulfillmentOrderAccountListEBF Billing Order Start, Complete 2 InitiateBilling ProcessFulfillmentOrderBilling (FulfillmentMode=”Initiate”) Billing Order Start, Complete 3 FulfillBilling ProcessFulfillmentOrderBilling (FulfillmentMode=”Fulfill”) Billing Subject Type = Service Bundle Start, Complete 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 Segment = “Residential” Any: otherwise Start, Planned, Shipped, Complete 9 UpdateSalesOrder UpdateSalesOrder CRMSales Any Start, Complete 10 UpdateSalesOrderStatus UpdateSalesOrder CRMSales Any Start, Complete 11 UpdateFulfillmentOrder ProcessFulfillmentOrderUpdate Orchestration Any Start, Complete
  • 43. Guidelines for Building an Order to Activate Integrated Business Process 44 Double Play Fulfillment Flow Sample Note: For quick reference, we call this the Nile flow. 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. NonService.OfferOffer (*) Service.CPE.VoIPVoIP Equipment Class Service.CPE.Broadband SpecialRating (*) Bundle (*) Discount (*) NonService.BillingItem Pricing Event Class Service.Install High-Speed Internet Installation Class Wireless Router Class Broadband Modem Class Internet Media Class High Speed Internet Service Feature Class Service.Broadband High Speed Internet Service Class VoIP Service Feature Class Service.VoIP VoIP Service Plan Class Product Specification Fulfillment Item Code or Subject Type (*) NonService.OfferOffer (*) Service.CPE.VoIPVoIP Equipment Class Service.CPE.Broadband SpecialRating (*) Bundle (*) Discount (*) NonService.BillingItem Pricing Event Class Service.Install High-Speed Internet Installation Class Wireless Router Class Broadband Modem Class Internet Media Class High Speed Internet Service Feature Class Service.Broadband High Speed Internet Service Class VoIP Service Feature Class Service.VoIP VoIP Service Plan Class Product Specification Fulfillment Item Code or Subject Type (*) Intended Fulfillment Flows
  • 44. Guidelines for Building an Order to Activate Integrated Business Process 45 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.
  • 45. Guidelines for Building an Order to Activate Integrated Business Process 46 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 Object {parent line #} Action Name Price Type List Price Prom ID Subject Type Remarks 1 Bundled Promotion {} ADD On Top of the World Broadband-VoIP Offer Billing Profile = VISA 2 CP {} ADD High Speed Internet Service ID (1) Bundle Billing Profile = VISA Service ID = Null* 3 CP {} ADD Internet Service ID (1) Service Bundle Billing Profile = VISA 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 Bundle Service ID = Null* 7 .SP {6} ADD Internet email MRC $0 ID (1) Product 8 .CP {3} ADD Internet Media ID (1) Service Bundle Service ID = Null* 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 =
  • 46. Guidelines for Building an Order to Activate Integrated Business Process 47 # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type Remarks 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 Cycle Start Date = Null Purchase Date = Null 18 ..SP{16} ADD VoIP Voicemail MRC $0.00 ID (1) Product Usage Start Date = Null Cycle Start Date = Null Purchase Date = Null 19 ..SP{16} ADD VoIP Caller ID MRC $0.00 ID (1) Product Usage Start Date = Null Cycle Start Date = Null 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 Discount MRC 100% ID (1) Discount Billing Profile = VISA 23 SP {} ADD High Speed Internet Activation Discount OTC 100% ID (1) Discount Billing Profile = VISA 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
  • 47. Guidelines for Building an Order to Activate Integrated Business Process 48 First Time Purchase Double Play Order Fulfillment Flow This diagram shows the order decomposition and Orchestration Plan that the Order Management system will generate: VoIP Adaptor (A) VoIP Phone (A) InitiateBilling [BRM-REZBDB] On Top of The World Broadband-VoIP (A) ProvisionOrder [DSL] Internet Service (A) High Speed Internet Basic (A) Internet Secure Firewall (A) Internet email (A) Internet email (A) Internet Media (A) Internet Content on Demand (A) Internet Video on Demand (A) Dynex Modem (A) Wireless Router (A) SyncCustomer [BRM-REZBDB] On Top of The World Broadband- VoIP (A) High Speed Internet Service (A) Internet Service (A) High Speed Internet Basic (A) Internet Secure Firewall (A) Internet email (A) Internet email (A) Internet Media (A) Internet Content on Demand (A) Internet Video on Demand (A) Dynex Modem (A) Wireless Router (A) High Speed Internet Installation (A) High Speed Internet Activation (A) High Speed Internet First Month Free Discount (A) High Speed Internet Activation Discount (A) VoIP Service Plan (A) VoIP Basic (A) VoIP Voicemail (A) VoIP Caller ID (A) On Top of the World Broadband-VoIP (A) High Speed Internet First Month Free Discount (A) High Speed Internet Activation Discount (A) High Speed Internet Service (A) FulfillBilling (BRM-REZBDB) ProvisionOrder [VOIP] VoIP Service Plan (A) VoIP Basic (A) VoIP Voicemail (A) VoIP Caller ID (A) VoIP Adaptor (A) VoIP Phone (A) Internet Service (A) High Speed Internet Basic (A) Internet Secure Firewall (A) Internet email (A) Internet email (A) Internet Media (A) Internet Content on Demand (A) Internet Video on Demand (A) Dynex Modem (A) Wireless Router (A) High Speed Internet Activation (A) ShipOrder [InHouse] Dynex Modem (A) Wireless Router (A) InstallOrder [All] High Speed Internet Installation (A) High Speed Internet Installation (A) ShipOrder [PartnerInc] VoIP Adapter (A) VoIP Phone (A) On Top of The World Broadband-VoIP (A) VoIP Recurring Discount (A) VoIP First Month Fee Discount (A) VoIP Service (A) FulfillBilling (BRM-VoIP) SyncCustomer [BRM-VOIP] On Top of The World Broadband- VoIP (A) VoIP Service (A) VoIP Service Plan (A) VoIP Basic (A) VoIP Voicemail (A) VoIP Caller ID (A) VoIP Adaptor (A) VoIP Phone (A) VoIP First Month Fee Discount (A) InitiateBilling [BRM-VOIP] On Top of The World Broadband-VoIP (A) VoIP Service Plan (A) VoIP Basic (A) VoIP Voicemail (A) VoIP Caller ID (A)
  • 48. Guidelines for Building an Order to Activate Integrated Business Process 49 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 parentheses 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.
  • 49. Guidelines for Building an Order to Activate Integrated Business Process 50 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 {parent line #} Action Name Price Type List Price Prom ID Subject Type Remarks 1 Bundled Promotion {} -- On Top of the World Broadband-VoIP Offer 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
  • 50. Guidelines for Building an Order to Activate Integrated Business Process 51 # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type Remarks 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 27 SP {} -- VoIP First Month Free Discount MRC 100% ID (1) Discount
  • 51. Guidelines for Building an Order to Activate Integrated Business Process 52 Change Order Fulfillment Flow The following diagram shows the order decomposition and Orchestration Plan that the Order Management system will generate:
  • 52. Guidelines for Building an Order to Activate Integrated Business Process 53 Describing the Change Order 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 parentheses 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 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. 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. 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.
  • 53. Guidelines for Building an Order to Activate Integrated Business Process 54 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: # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type Remarks 1 Bundled Promotion {} -- On Top of the World Broadband-VoIP Offer 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
  • 54. Guidelines for Building an Order to Activate Integrated Business Process 55 # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type Remarks 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.
  • 55. Guidelines for Building an Order to Activate Integrated Business Process 56 The following chart shows the change order 10030 fulfillment plan along with an overlay of immediate revision 4 effects:
  • 56. Guidelines for Building an Order to Activate Integrated Business Process 57 Describing the Double Play Revision Order 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 parentheses 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 starting the activity and ending the activity. 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.
  • 57. Guidelines for Building an Order to Activate Integrated Business Process 58 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.
  • 58. Guidelines for Building an Order to Activate Integrated Business Process 59 Describing the Revision Order 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 parentheses 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 starting the activity and ending the activity. 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. These considerations apply to this scenario: 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.
  • 59. Guidelines for Building an Order to Activate Integrated Business Process 60 Communications Orders Dictionary The following tables provide a snapshot of the Communications Orders Dictionary at the time this white paper 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 l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Order ID Uniquely identifies each order. NA No None Produces a unique identifier for all orders, including revision orders. Unlike Order Number, Order ID is different for revisions of the same base order. Used by AIA for cross-reference. SaleOrderEBO/Identification/BusinessCompon entID
  • 60. Guidelines for Building an Order to Activate Integrated Business Process 61 Functiona l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Order Number Identifies an order across revisions. NA No None A revision number >1 doesn't 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. <CommsOrder>EBO/Identification/ID Revision A revision sequence number that, together with the order number, represents the user key to an order. NA No None If an order is received with an Order Number equal to that of an in-flight order and the newly 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. <CommsOrder>EBO/Identification/Revision/Nu mber Success Dependen cy Declares if all order lines must fulfill successfully or else the whole order fails (all or 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. DEFAULT, ALL OR NONE No None <CommsOrder>EBO/PartialFulfillmentAllowedI ndicator
  • 61. Guidelines for Building an Order to Activate Integrated Business Process 62 Functiona l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Fulfillment Mode Qualifies the nature of orchestration required for submission of a particular sales order. * Get Provider supports the Get Target Fulfillment Provider through Order Management for use outside Order Management. * Cancel is a special case used when a revision intends to cancel an entire order. DELIVER, CANCEL, INITIATE BILLING, FULFILL BILLING, GET PROVIDER No None CSPs may extend support to other modes, such as Qualify for TSQ. Oracle is planning TSQ support part of a future release. Siebel is providing a mechanism to create a revision order to cancel an entire order by sending a revision with Fulfillment Mode = Cancel. OM is expected to honor 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. <CommsOrder>EBO/FulfillmentModeCode Customer Class Identifies type of customer: Residential, Business, and so on RESIDENTIAL BUSINESS No None <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountTypeCode Organizati on ID Identifies the organization/LOB generating the order. No cross- reference exists. NA No None No cross-reference .OM should use the application-specific ID if needed in any of the rules. <CommsOrder>EBO/BusinessUnitReference/ BusinessUnitIdentification/ID Sales Channel Identifies the sales channel. NA No None <CommsOrder>EBO/SalesChannelCode Job ID A string or number that uniquely identifies the job to orchestration. NA No None Track orders that belong to a bulk or batch job. <CommsOrder>EBO/ProcessingNumber Sequence in Job A number that identifies the order sequence within the job. NA No None Siebel is not providing a value in 2.4. <CommsOrder>EBO/ProcessingSequenceNu mber Job Type Identifies the type of job. This information identifies the threshold for creating a consolidated SR for Bulk or Batch Orders. This value is optional for orders whose Job Cardinality is 1. By default, this value is HETROGENEOUS. HETEROGEN EOUS,HOMO GENEOUS, 3RD PARTY HOMOGENE OUS, 3RD PARTY HETEROGEN EOUS, CORRELATE D No None Siebel is not providing a value in 2.4. <CommsOrder>EBO/ProcessingTypeCode Job Cardinality Indicates the total number of orders within the job. NA No None Siebel is not providing a value in 2.4. <CommsOrder>EBO/ProcessingQuantity
  • 62. Guidelines for Building an Order to Activate Integrated Business Process 63 Functiona l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Parent Order ID Order ID of another order that indicates the fulfillment for this order will not start before the parent order fulfillment completes. NA No None This attribute applies to explicit order-to-order dependencies and is not limited to follow-on orders. For example, in a B2B scenario, a 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. <CommsOrder>EBO/Parent<CommsOrder>R eference/<CommsOrder>Identification/Busines sComponentID Fulfillment Priority Indicates relevant priority of order fulfillment across orders. A lower value indicates a higher priority. Accepts values 0 to 9 in accordance with JMS Queue support. 0,3,5,7 No None EBM value: Siebel value 0: Urgent. Used for expedited orders. 3: High. CSP determines its use. 5: Medium. CSP determines its use. 7: Low. Recommended for job orders. <CommsOrder>EBO/FulfillmentPriorityCode Order Type Sometimes indirectly determines sales channel to drive compensation process. SALES ORDER No None <CommsOrder>EBO/TypeCode Requested Delivery Date Overall order level due date that provides the default due date at each line level. Can be overridden at each line. NA Yes None <CommsOrder>EBO/RequestedDeliveryDateT ime Status Reports aggregate order fulfillment status. (Canonical / Siebel): (OPEN / Open), (IN PROGRESS / In Progress), (FAILED / Failed), (CANCELLED / Cancelled), (COMPLETE / Complete) Yes None <CommsOrder>EBO/Status/Code
  • 63. Guidelines for Building an Order to Activate Integrated Business Process 64 Functiona l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Status Context Provides details about the current status. The implementer configures this value. NA Yes None OM can used this to track the milestone causing the status 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. <CommsOrder>EBO/Status/Description Owner Account ID Identifies the owner account. NA Yes None Cross-referenced. <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountIdentification/Business ComponentID Owner Account Name Identifies the Account Name. You can enter or derive this value from contact first name + last name of primary contact associated with the account. NA Yes None Required for network inventory tracking of service owner. <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountName Owner Account Number Identifies account number to customer. NA Yes None <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountIdentification/ID Account Contact ID Foreign key to contact record that holds personal and contact details of the customer/company representative who is placing the order and is the contact person for anything related to the order process. NA Yes None <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountContactIdentification/B usinessComponentID Account Contact Address (compone nt) Identifies the address used to communicate with the Contact ID. NA Yes None <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountContactAddressComm unication/AddressCommunication/Address Project ID Identifies project record if the order to be delivered is part of a project that contains related orders. Foreign key reference. No cross-reference. NA Yes None No cross-reference for 2.4. <CommsOrder>EBO/ProjectReference/Project Identfication/ID
  • 64. Guidelines for Building an Order to Activate Integrated Business Process 65 Functiona l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Fulfillment System Type For the Get Target Fulfillment Provider utility service, determines the logical identifier for appropriate target system instance among those serving this Fulfillment System Type. NA No None FulfillmentOrderEBO/FulfillmentSystemTypeCo de Target Instance For the Get Target Fulfillment Provider utility service returns the logical identifier for appropriate target system instance among those serving this Fulfillment System Type. NA No None FulfillmentOrderEBO/FulfillmentTargetSystemI D Order Changed Indicator OM sets this attribute to Yes if the order changed significantly such that CRM should make a copy of the customer order to preserve the customer intent before updating the working version of the order. TRUE, FALSE No None Allows Siebel to make a copy of the order if the order changed to the extent that the customer’s intent is compromised. <CommsOrder>EBO/OrderChangedIndicator Sales Represent ative ID CRM User ID that identifies the sales representative who entered the order. NA No None No cross-reference. Use the application ID. <CommsOrder>EBO/SalespersonPartyRefere nce/PartyIdentification/ID Owner Account Contact (multiple fields) Identifies if the address is used to communicate with the contact ID. Includes these fields: First Name, Last Name, Phone Number, and Email. NA No None <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountContact/FirstName <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountContact/LastName <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountContactPhoneCommu nication/PhoneCommunication/CompleteNumb er <CommsOrder>EBO/CustomerPartyReference /CustomerPartyAccountContactEmailCommuni cation/EmailCommunication/
  • 65. Guidelines for Building an Order to Activate Integrated Business Process 66 Communications Orders - Order Line Component Attributes Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Line ID Uniquely identifies the order line item across orders and order revisions. Automatically generated. NA No None Cross-referenced. Produces a unique identifier for all Order Lines, including revision Order Lines. <CommsOrder>EBO/<CommsOrder>Line/Identific ation/BusinessComponentID Base Line ID References base order line revised by this order line. NA No None Uses a cross-reference. <CommsOrder>EBO/<CommsOrder>Line/Original <CommsOrder>LineReference/<CommsOrder>Li neIdentification/BusinessComponentID Asset Integration ID Uniquely identifies an instance of a product that was or is being purchased. NA Yes AIA2.0 Cross-referenced Assumption: The Asset Integration ID will continue to be populated on all 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. <CommsOrder>Line/InstalledProductReference/In stalledProductIdentification/BusinessComponentI D Line Number Identifies the line with respect to its position in the line item tree. NA No None Line number establishes the parent child relationship between Order Lines of the same order, but it may vary across revisions. Therefore, do not rely on it for matching Order Lines across revisions. <CommsOrder>EBO/<CommsOrder>Line/Identific ation/ID Parent Line References parent order line in the line items tree instantiated as per the product model definition. Points to itself if the item does not have an associated parent item. NA No None <CommsOrder>EBO/<CommsOrder>Line/Parent <CommsOrder>LineIdentification/BusinessCompo nentID Root Line References the root order line in the line item tree instantiated as per the product model definition. Points to itself if the item is a root item itself. NA No None <CommsOrder>EBO/<CommsOrder>Line/RootPa rent<CommsOrder>LineIdentification/BusinessCo mponentID Related Line ID Links one-time charges to Suspend/Resume order lines. NA No None <CommsOrder>EBO/<CommsOrder>Line/Related <CommsOrder>LineIdentification/BusinessCompo nentID
  • 66. Guidelines for Building an Order to Activate Integrated Business Process 67 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Charge Parent Line ID BRM adaptors use to relate one- time charges to base line ID. NA No None <CommsOrder>EBO/<CommsOrder>Line/Charge ParentLineIdentification/BusinessComponentID Related Asset Integration ID Links Move-Add to Move-Delete line items. NA No None <CommsOrder>EBO/<CommsOrder>Line/Installe dProductReference/PriorInstalledProductIdentifica tion/BusinessComponentID Depends On Line ID Indicates order line item ID of a previous order line item that is changed by this order. Follow-on orders use this value to capture dependencies of the order line items in the follow-on order-to- order line items of original orders. NA No None Cross-referenced. <CommsOrder>EBO/<CommsOrder>Line/Depend ing<CommsOrder>LineReference/<CommsOrder >LineIdentification/BusinessComponentID Depends On Order ID Identifies order ID of an in-flight order, which is the basis for this follow-on order line item. NA No None Cross-referenced. <CommsOrder>EBO/<CommsOrder>Line/Depend ing<CommsOrder>Reference/<CommsOrder>Ide ntification/BusinessComponentID Promotion Line ID References an order line that represents the promotion/marketing offer under which the order line is being purchased. NA No AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/Promoti on<CommsOrder>LineReference/Promotion<Com msOrder>LineIdentification/Identification/Business ComponentID Promotion Asset Integration ID References an asset that represents the promotion/marketing offer under which the order line is being purchased. NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/Promoti on<CommsOrder>LineReference/InstalledProduct Reference/InstalledProductIdentification/Business ComponentID Product ID References product record based on which order line is instantiated. Foreign key reference. NA Yes None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/Identification/BusinessComponentID Quantity Identifies the quantity of the item requested by a customer. Default is 1. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/OrderQ uantity Action Code Specify action required to meet customer request NONE,ADD,UP DATE,SUSPEN D,RESUME,DE LETE,MOVE- ADD,MOVE- DELETE No None <CommsOrder>EBO/<CommsOrder>Line/Service ActionCode
  • 67. Guidelines for Building an Order to Activate Integrated Business Process 68 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Requested Delivery Date When Null, the requested date for delivery of the goods or service is 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. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/RequestedDeliveryDateTime Deliver To Address Address record that represents the delivery/service installation address. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/Service Address/Address Usage Start Date Determines the date when usage events should start being rated. The value for this attribute is populated by CRM, OM Fulfillment flows, or kept to Null for BRM default to the current date. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/ServiceUsageStartDate Cycle State Date Determines the date when cycle charges should start being billed. The value for this attribute is populated by CRM, OM Fulfillment flows, or kept to Null for BRM default to the current date as per previous patterns. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/CycleStartDate Purchase Date Determines the date when one- time purchase charges should be billed. The value for this attribute is populated by CRM, OM Fulfillment flows, or kept to Null for BRM default to current date as per above patterns. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/PurchaseDate Service Start Date Indicates effective start date of service. NA Yes None Initially computed by Siebel based on Due Date and then updated by Order Management based on Actual Delivery Date. Siebel support is planned for a future release. <CommsOrder>EBO/<CommsOrder>Line/Effectiv eTimePeriod/StartDateTime Earliest Delivery Date Identifies the date when the work associated to the order provision 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. NA No None <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/EarliestDeliveryDateTime
  • 68. Guidelines for Building an Order to Activate Integrated Business Process 69 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Service End Date Indicates the effective end date of service. Applies to services with a specified duration. NA Yes None Initially computed in Siebel and then updated by Order Management. Update is sent to Siebel. Siebel support is planned for a future release. <CommsOrder>EBO/<CommsOrder>Line/Effectiv eTimePeriod/EndDateTime Actual Delivery Date Determines the date when the purchased product or service is considered available to the customer by the CSP. This date may be when physical goods are shipped, delivered, or their receipt is acknowledged. For service- based products, the service is activated on this date. This date is computed in the OM Fulfillment flow as per previous patterns. NA Yes None BRM does not allow for starting any charges before the Purchase Date; therefore, the ABCS for BRM will always override the Purchase Date if it is later than any of the Cycle or Usage start dates. OM should facilitate calculation of Order Line level Actual Delivery Date as well as Order Line attributes for billing Usage Start Date, Cycle Start Date, and Purchase Date. <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/ActualDeliveryDateTime Expected Delivery Date Indicates the due date expected by the system as a result of Design and Assign. The default is the Order Due Date when the order is created by CRM. NA No None Computed by OM based on preconfigured time estimates on fulfillment actions. Used by OM to communicate to CRM changes to expected delivery date of specific Order Lines. <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/ExpectedDeliveryDate Status Updates orchestration and CRM as to the current status of order line fulfillment at a high level. In addition to statuses used during Order Capture: (Canonical / Siebel): (OPEN / Open), ( IN PROGRESS/ In Progress), (FAILED / Failed), (CANCELLED / Cancelled ), (COMPLETE / Complete) Yes None At the time CRM submits an order, the Order Line status is set to Open. An order will always be accepted; guaranteed delivery is mandatory, therefore, no need to track. After orchestration starts, OM updates CRM Status to In Progress and it stays so until one of the following conditions occurs: • Fulfillment is failed due to a given condition, such as insufficient data, administrative intervention, and so on. Status is updated to Failed with a Status Context indicating the milestone and context. • Order is cancelled either through 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. <CommsOrder>EBO/<CommsOrder>Line/Status/ Code
  • 69. Guidelines for Building an Order to Activate Integrated Business Process 70 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Milestone Fulfillment passes the last reached milestone into this field. NA No None <CommsOrder>/<CommsOrder>Line/MilestoneCo de Status Context Provides details about the current status of the order line. The implementer configures this value. NA Yes None OM could include the reached milestone (from the fulfillment system, 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 <CommsOrder>EBO/<CommsOrder>Line/Status/ Description Point-of-no- return Determines if Siebel should allow order line revisions to be submitted. NOT YET, HARD No None OM Fulfillment flows allow configuration of setting a hard PONR 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. <CommsOrder>EBO/<CommsOrder>Line/Revisio nPermissibleCode Billing Account References an account record that represents the bill payer or the branch of a company responsible for bill payment. This value may be a customer account or an account from the account hierarchy. NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/BillToPartyReference/Custom erPartyAccountIdentification/BusinessComponentI D Billing Profile References the billing profile record that holds the customer’s billing/payment preferences. This value may be associated to the customer account or to a separate billing account. NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/BillToPartyReference/BillingPr ofileReference/BillingProfileIdentification/Business ComponentID Payment Profile Identifies the Payment Profile. NA No None <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/BillToPartyReference/BillingPr ofileReference/PaymentProfileReference/Payment ProfileIdentification/BusinessComponentID
  • 70. Guidelines for Building an Order to Activate Integrated Business Process 71 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Service Account References an account record that represents a service user or the branch of the company where service is installed. This value may be customer account or an account from the account hierarchy. NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/OwnerPartyReference/Custo merPartyAccountIdentification/BusinessCompone ntID Owner Contact Represents a contact of the customer account or service account who should be contacted during fulfillment of the line if required. NA Yes None <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/OwnerPartyReference/Custo merPartyAccountContactIdentification/BusinessCo mponentID Shipping Contact Represents a contact of the customer account or service account who should be contacted for shipping purposes. NA Yes None <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/ShipToPartyReference/Custo merPartyAccountContactIdentification/BusinessCo mponentID Node Alphanumerically references the root order line that corresponds to access at site A of a connection. This value is relevant for network ordering only. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="Node "]/ValueText To Node Alphanumerically references the root order line that corresponds to access at site B of a connection. This value is relevant for network ordering only. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToNo de"]/ValueText Network ID Unique compound product number that represents the virtual network ID. Relevant for network orders. Provided by default from the order number and cascaded to network connection items. NA Yes AIA2.4 Identifies which Access and Nodes belong to the same network. This information may be of value to decomposition. <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="Netw orkID"]/ValueText Port Number Identifies the port number allocated to the access circuit connected to provide (starting) edge router during the fulfillment process. NA Yes AIA2.4 For new services, port number comes back from Network Inventory through provisioning. <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="PortN umber"]/ValueText To Port Number Identifies the port number allocated to the access circuit connected to provide (ending) edge router during the fulfillment process. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToPo rtNumber"]/ValueText
  • 71. Guidelines for Building an Order to Activate Integrated Business Process 72 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Service Address Prefix Identifies the area code/NPA for the access circuits on starting or two ends of the connection. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="Servi ceAddressPrefix"]/ValueText To Service Address Prefix Identifies the area code/NPA for the access circuits on the end of the connection. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToSer viceAddressPrefix"]/ValueText Access Circuit Provides the Common Language Location Identification (CLLI) for the access circuit on two sides or starting side of the connection. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="Acces sCircuit"]/ValueText To Access Circuit Provides the CLLI for the access circuit on ending side of the connection. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToAc cessCircuit"]/ValueText To Service Account ID Identifies the Service Account ID associated with the end side of a network. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToSer viceAccountID"]/ValueText From Service Address ID Identifies the Service Address ID for the starting point of a network. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="From ServiceAddressID"]/ValueText To Service Address ID Identifies the Service Address ID for the ending point of a network. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToSer viceAddressID"]/ValueText To Service Point ID References a dummy asset record that represents the access point to which the starting side of a network service will be connected on the customer’s premises. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="ToSer vicePointID"]/ValueText Service Point References a dummy asset record that represents the access point to which this service will be connected on the customer’s premises. For example, NTE for PSTN, Set top box for Broadband/Cable service. NA Yes AIA2.4 Expected to be mastered in network inventory and loaded in Siebel in batch. <CommsOrder>EBO/<CommsOrder>Line/Service PointCode Promotion Description Provides short description that will appear on the invoice. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/Description This is Promotion Description used for display purposes on customer invoice
  • 72. Guidelines for Building an Order to Activate Integrated Business Process 73 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Service ID Identifies the product/service instance allocated by the fulfillment (network service, physical item, 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. NA Yes AIA2.0 <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/<CommsOrder>ItemInstance/I dentification/ID Balance Bundle Identificatio n Identifies the Balance Bundle to which a service instance belongs. NA Not Used by AIA for Communications 2.0 or 2.4. <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/BalanceBundleIdentification/B usinessComponentID Line Description Provides additional description for an order line. For example, to indicate that a charge is being applied for a penalty. NA No None Not used by AIA for Communications 2.0 or 2.4. <CommsOrder>EBO/<CommsOrder>Line/Descrip tion Service Length Indicates requested service length in Service Length Unit of Measure. NA Yes Yes <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/ServiceTimePeriod/Duration Service Length Unit of Measure Indicates the service length unit of measure. NA Yes Yes <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/ServiceTimePeriod/Duration Fulfillment Mode Designates compensation operations for Initiate Billing. May be used in the future to provide explicit revision operations at the line level. DO, NOOP, REDO, UNDO No None <CommsOrder>EBO/<CommsOrder>Line/Fulfillm entModeCode Product Name Provides the name of the product. NA <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/Name
  • 73. Guidelines for Building an Order to Activate Integrated Business Process 74 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Compositio n Type Determines product composition granularity: PartialItem is an order line that 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. <no value> for NULL, PARTIAL ITEM, WHOLE ITEM No None Consult Oracle on usage. <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/FulfillmentCompositionTypeCode Product Type Classifies products into Products, Discounts, Bundles, Offers, and so on. PRODUCT, OFFER, BUNDLE No None Used part of fulfillment to determine the order lines Subject Type, which drives the mapping to Product Specifications. <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/TypeCode Billing Type Classifies products for Billing into Service Bundles, Subscriptions, Items, Discounts, and Special Ratings. SERVICE BUNDLE, SUBSCRIPTIO N, ITEM, DISCOUNT, SPECIAL RATING No None Used in conjunction with Product Type. <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/ClassificationCode [listID="BillingProductTypeCode"] Billing Service Type Specifies the service type so that when a corresponding product is created in Billing, it is associated to the specified service. NA No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/ClassificationCode [listID="PermittedTypeCode"] Service Flag Indicates the product of a service or non-service, for example, physical goods. TRUE, FALSE No None Used in conjunction with Product Type and may be used to parameterize fulfillment flows. <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/ServiceIndicator Vendor Identifies the vendor supplying the product when the product is supplied by a third party. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/SupplierPartyReference/PartyIdentification /ID Vendor Part Number Identifies the product part number to the vendor. NA Yes AIA2.4 <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/ItemIdentification/SupplierItemID
  • 74. Guidelines for Building an Order to Activate Integrated Business Process 75 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder Fulfillment Item Code Uniquely identifies the mapping of an Order Line Subject to a Product Specification. 1) Null 2) A unique code that identifies the Product Spec to OM No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/ClassificationCode [listID = "FulfillmentItemCode"] Item Class Name Determines business classification of a product. NA No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/PrimaryClassificationCode Success Dependenc y Declares if all order lines of a bundle or offer must fulfill successfully or else the whole bundle or offer fails (all or none). DEFAULT, ALL OR NONE No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/FulfillmentSuccessCode Start Billing on First Usage When set to Yes by CRM or OSM, passes the request along to BRM. In this case, Usage Start Date, Cycle Start Date, and Purchase Date should have no effect. TRUE, FALSE No None Not yet supported by integration. <CommsOrder>EBO/<CommsOrder>Line/StartBill ingOnFirstServiceUsageIndicator We have added BillingStartCode to ItemReference, if this requirement is at the item/itemReference level and not line level then BillingStartCode from ItemReference should be used. Smart Part Number Automatically generated based on a predefined scheme. Mainly, drives dynamic product configuration/pricing rules in CRM. The billing system may use it to dynamically derive a price/discount value. NA Yes None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/AlternateObjectKey [ContextID=SmartPartNumber] Network Product Flag Indicates if this is a network product, which helps determine which user-defined attributes to expect. TRUE, FALSE No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/NetworkIndicator Network Element Type Indicates if this network product represents a node, a connection, or a network. NA No None <CommsOrder>EBO/<CommsOrder>Line/ItemRef erence/NetworkItemTypeCode Charge Frequency Code Indicates charge frequency unit of measure, for example, monthly, quarterly, yearly. NA <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/<CommsOrder>ScheduleCha rge/Charge/ChargeFrequencyCode List Price Type Identifies price type. ONE-TIME, RECURRING, USAGE No None <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/<CommsOrder>ScheduleCha 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 Type Identifies price type. ONE-TIME, RECURRING, USAGE No None <CommsOrder>EBO/<CommsOrder>Line/<Com msOrder>Schedule/<CommsOrder>ScheduleCha rge/Charge/TypeCode
  • 75. Guidelines for Building an Order to Activate Integrated Business Process 76 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <CommsOrder> Variable for SalesOrder, FulfillmentOrder or ProvisioningOrder 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 Commit Type Indicates whether the pricing is Committed or Dynamic. Common/Siebel values are true/Dynamic, false/Committed . Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr der>Schedule/<CommsOrder>ScheduleCharge/C harge/DynamicPricingIndicator Dynamic Discount Method Indicates whether the discount is of type amount or percent. AMOUNT, PERCENT Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr der>Schedule/<CommsOrder>ScheduleCharge/C harge/DiscountMethodCode Discount Percent Indicates the percent by which the list price is discounted. NA Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr der>Schedule/<CommsOrder>ScheduleCharge/C harge/DiscountPercent Discount Amount Indicates the amount by which the list price is discounted NA Yes AIA2.4 <CommsOrder>/<CommsOrder>Line/<CommsOr der>Schedule/<CommsOrder>ScheduleCharge/C harge/DiscountAmount Member [0..N] Represents a member of a list by their phone number. NA No None Used for capturing membership to friends and family plans. <CommsOrder>EBO/<CommsOrder>Line/<CommsOr der>LineSpecificationGroup/SpecificationGroup[./nam e="ExtensibleAttributes"]/Specification[./name="Speci alRating"]/ValueText [0..N] User Defined Attributes Indicates attribute is common across all Specification components. NA Yes None UDA Name <CommsOrder>/<CommsOrder>Line/ItemReferen ce/SpecificationGroup[name="ExtensibleAttributes "]/Specification/Name User Defined Attributes Indicates attribute is common across all Specification components. ADD, UPDATE, DELETE Yes None UDA Action Code (Expected to change to a Service Action Code element to allow additional value NONE.) <CommsOrder>/<CommsOrder>Line/ItemReferen ce/SpecificationGroup[name="ExtensibleAttributes "]/Specification[name="<OrderLine.XA.Attribute>"] /@actionCode User Defined Attributes Indicates attribute is common across all Specification components. NA Yes has Previo us LIC Value UDA language-independent code Value <CommsOrder>/<CommsOrder>Line/ItemReferen ce/SpecificationGroup[name="ExtensibleAttributes "]/Specification[name="<OrderLine.XA.Attribute>"] /Value User Defined Attributes Indicates attribute is common across all Specification components. STRING, DATE, NUMBER Yes None UDA Data Type <CommsOrder>/Prior<CommsOrder>/<CommsOr der>Line/ItemReference/SpecificationGroup[name ="ExtensibleAttributes"]/Specification[name="<Ord erLine.XA.Attribute"]/DataTypeCode User Defined Attributes Indicates attribute is common across all Specification components. NA Yes None UDA language-independent code Prior Value <CommsOrder>/Prior<CommsOrder>/<CommsOr der>Line/ItemReference/SpecificationGroup[name ="ExtensibleAttributes"]/Specification[name="<Ord erLine.XA.Attribute>"]/Value

×