This chapter contains the following:
Processing of orchestration orders within Oracle Fusion Distributed Order Orchestration is automated. A sales order enters Distributed Order Orchestration and is transformed into an orchestration order, using business rules defined by an administrator. Business rules are used to assign an orchestration process to one or more fulfillment lines. The orchestration process is a business process defined by an administrator that coordinates the orchestration of physical goods and activities within a single order and automates order orchestration across fulfillment systems. The forward and backward planning of the orchestration process is used to automatically identify the exceptions and spot potential problems. Changes are also processed automatically, in accordance with the change processing rules that were set up by your organization.
Changes are processed automatically using a process called change management. Changes can occur anytime, from a variety of sources: Order Orchestration work area, external fulfillment system, or order capture system. Change management often is automatic and mostly invisible, but you might see some signs of change management in the Order Orchestration work area.
In all cases, processing constraints are used to determine whether a change is allowed. If the change is allowed, then it is considered accepted and Oracle Fusion Distributed Order Orchestration determines whether to adjust the orchestration process to accommodate the change. (Adjustments are not made in response to changes from fulfillment systems.) During this determination, the application checks which orchestration process steps were executed already and which need to be adjusted. When the application begins the adjustments to compensate for the change, the initial status of tasks that were executed before the change and of the orchestration process is Change Pending. When the compensation request is accepted by the fulfillment system, one by one the status of each task changes to a normal status, such as Completed. Tasks in the Gantt chart in the Order Orchestration work area could appear to be canceled, but it is because tasks that are adjusted sometimes are canceled first and then redone.
An event is raised when compensation is completed or if an error occurs during compensation.
Order Capture services receive requests from integrated order capture applications and transform the requests into a structure that is recognized by Oracle Fusion Distributed Order Orchestration. The requests are for information about fulfillment lines.
The Order Capture services perform the following:
Get order details.
Get order shipping details.
Apply a hold.
Release a hold.
Check for availability.
The following services request information from order capture applications and transform them into a structure that can be successfully fulfilled through multiple fulfillment systems
This service communicates status information or order details back to the order capture application that requests it. The service can provide information about the entire sales order or a desired set of order lines.
You can get details about an order that originated in any other integrated source system. You can define a source system, which constrains the query to that system. Alternatively, you can choose not to specify a source system, in which case matching order numbers from any source system are returned.
This service communicates shipping details back to the order capture application that requests it. The response in this service is organized by shipments, rather than by fulfillment lines. The shipping details provided by this service are: current schedules, status of each schedule, and schedule details such as warehouse and shipping method. Because each sales order line in order capture may have multiple related fulfillment lines in Distributed Order Orchestration the response to order capture contains information about all the lines. The service can return details of all the sales order lines of a sales order or for a specific set of sales order lines.
This service routes a request for a hold from an order capture system to the Hold task layer. This service allows multiple holds to be requested, each for a single sales order or for multiple sales order lines in that order.
This service routes a request to release an existing hold from an order capture system to the Hold task layer.
This service sends requests to Distributed Order Orchestration inquiring about the availability of product for a given date and source organization. Distributed Order Orchestration responds to these requests by sending the order capture application detailed information about the product, available quantity, and source organization.
The Oracle Fusion Distributed Order Orchestration task layer is the logical module that holds the services that are requested by other Distributed Order Orchestration modules or by external modules. In some cases, the task layer service performs a service internal to Distributed Order Orchestration. In other cases, the task layer calls a fulfillment system as part of its behavior when a service is requested of it. For example, when the task layer service Create Shipment Request is called, the service sends an outgoing Create Shipment Request to the external interface layer Create Shipment Request. The Distributed Order Orchestration external interface layer then directs this request to the appropriate fulfillment system.
This figure shows the progression of fulfillment activity. The steps of an orchestration process take place in the orchestration module, until a service needs to be called. Then a call is made to the task layer. After the service is called, the request goes to the external interface layer, where it is routed to the correct fulfillment system, for example, invoicing, shipping, activity, or receiving.
The shipment task layer service is responsible for initiating communication with shipping systems and interpreting the responses and updates from those systems. Most shipping task layer services originate in the orchestration module.
The shipment task layer service performs the following:
Sends requests to the shipping fulfillment system
Consolidates and sends shipment set and model lines to the shipping fulfillment system
Receives information and status updates from the shipping system
Splits fulfillment lines, shipment sets, and models when partial shipment occurs
The shipment task layer service sends a request to the fulfillment system where the actual shipment request will be created. When a change order is received, the task layer service changes or cancels the shipment request, if necessary. If Hold on Running Task is selected and the running task is Shipping, then when a shipping hold is applied, the task layer service makes a request to the shipping fulfillment system to hold the in-progress shipment request.
The shipment task layer service consolidates the fulfillment lines of a shipment set and sends them to the shipping fulfillment system together. The task layer service treats models as shipment sets; the shippable fulfillment lines of a model are sent to the shipping fulfillment system together.
The shipment task layer service receives fulfillment line details and status updates that come from the shipping system and updates the appropriate business objects in Distributed Order Orchestration. Before ship confirm when status updates occur in the shipping system, fulfillment line details, such as freight cost, tracking number, and way bill number, may be sent any time from the shipping system to Distributed Order Orchestration. Distributed Order Orchestration produces the status updates after interpreting the update from shipping. The predefined statuses picked, backordered, packed, and shipped are provided. After the delivery lines are shipped, the shipment taks layer service continues to interpret updates from the shipping system and provide Distributed Order Orchestration with the relevant information from the update. If costs appear in multiple currencies in the shipping system, then they are converted before the update is sent to Distributed Order Orchestration. If the shipping unit of measure is different from the ordered unit of measure, then the fulfillment systems convert the unit of measure back to the ordered unit of measure before communicating the shipped quantity to Distributed Order Orchestration.
The shipping task layer service performs a split when partial shipment occurs. If only partial quantity of a fulfillment line is shipped, then the task layer service splits the line into a line with the quantity that was shipped and a line with the unshipped quantity. If only some fulfillment lines of a shipment set are shipped, then the task layer service removes the unshipped lines from the shipment set. If half of the fulfillment lines of a model are shipped, then the task layer splits the model into a shipped model and an unshipped model. If the split is non-proportional, then you get a remnant.
The schedule task layer service contains the requests from Oracle Fusion Distributed Order Orchestration to order promising. The task layer service includes requests to automatically schedule an order, to unschedule an order, and to check availability of product. The schedule action applies to fulfillment lines that are waiting for manual scheduling and also to fulfillment lines that fail scheduling in the automated or manual process. The schedule action works for only unscheduled lines. No automatic rescheduling is allowed from the Order Orchestration work area.
The reservation task layer service contains the requests for managing reservations of supply from Oracle Fusion Distributed Order Orchestration to an inventory fulfillment system. A reservation acts as a guarantee of material supply for a specific order line.
The invoice task layer service is responsible for initiating communication with billing systems and interpreting the responses and updates from those systems. This task layer service sends a request to the billing system where the actual invoice or credit transactions are created. After the request is sent to the billing system, no changes are allowed on those fulfillment lines. Most of the data that is required for billing is passed from upstream order capture systems and downstream fulfillment systems and stored in Distributed Order Orchestration. Distributed Order Orchestration routes the billing request to the appropriate system.
The invoice task layer service performs the following:
Initiates billing for sales orders and returns.
Initiates billing for shipment sets and models.
Receives status updates and additional information from the billing system.
Invoices cannot be updated through adjustments from the feeder system like Distributed Order Orchestration. Changes to invoices are expected to come in the form of credits from corresponding return orders or due to application of prepayments rather than cancellations.
The invoice task layer service sends eligible fulfillment lines to the billing system using the Create Billing Lines request. The billing information from the original sales order or return, such as price amounts, discounts, charges, payments, and sales credit and fulfillment details, is passed to the billing system.
Each time a fulfillment line is eligible for billing, the unit list price, unit selling price, discounts, and charge information are passed from the fulfillment line. Discounts at the header level are not supported. Header-level charges are supported and are sent to the billing system with the fulfillment line that is fulfilled first. Payment information is passed from the fulfillment line, if it is present. Otherwise, it is sent from the header. Prepayment information that is stored at the header is passed for every fulfillment line that is sent for billing. Sales credits are passed from the fulfillment line, if they are present. Otherwise, it is passed from the header.
Tax attributes are passed from the fulfillment line.
Fulfillment details that come from fulfillment systems also are routed to the billing system.
For return lines, the invoice line reference to the original sales order line is also sent to the billing system, along with the return reason and received and delivered quantities.
The invoice task layer service sends fulfillment lines in a shipment set or model to the billing system together. If only some lines in the shipment set or model have been fulfilled, then only the fulfilled lines are passed on to the billing system.
Once the data that is routed to the billing system is processed, the invoice task layer service receives and absorbs invoice and credit memo information, including billing amount, billing date, invoice or credit memo date, number, and legal entity information, from the billing system.
The invoice task layer service receives status updates from the billing system. The following statuses are used:
The Pause task layer services pause an orchestration process until a specified condition is met. Pause task layer services can be used to create a waiting period between tasks and to define when the pause is released and the next task of the orchestration process is allowed to begin.
You might want to use a Pause task in scenarios such as:
Layaway Orders: Pause the orchestration process until the customer finishes paying for the item. The release condition, known as the Start-After Condition, is configured to release the pause when payment is complete.
Pre-Orders: Pause an orchestration process until a specified date before releasing pre-orders. The Start-After Condition is configured to release the pause when the date arrives.
Shipping System That Cannot Handle Early Requests: Shipping system can handle requests for orders that are scheduled to ship within only 2 days. Pause the orchestration process so that requests are not sent to the shipping system until 2 days before the ship date.
Conditional Manual Review: If the scheduled date is beyond the requested date, then conditionally wait for manual review and approval.
The holds task layer service contains the requests for controlling holds within Oracle Fusion Distributed Order Orchestration. Holds can be communicated to external fulfillment systems, for example, a service called HoldShipmentRequest originates in Distributed Order Orchestration and requests a hold in the shipping fulfillment system. Holds to external fulfillment systems are contained by that task layer service, in this case, the Shipping task layer service.
The activity task layer service is responsible for initiating communication with fulfillment systems and interpreting the responses and updates from those systems. An activity represents a human task that must be performed as part of the fulfillment process. The activity request is sent to the activity fulfillment system, where the activity is created and fulfilled. Usually, an activity task is not fulfilled immediately. A wait service is provided to allow the orchestration process to wait for the completion of the activity.
An activity can be associated with one or more fulfillment lines. Each activity comes with attributes, such as subject, activity type, earliest start date, due date, scheduled and actual durations, percent completion, and assignees.
Activity is a predefined task type. You can create new activity task types to accommodate your organization's business needs. You can extend activities through extensible flexfields.
Partial fulfillment is not supported. An activity step must be completed in full before it can move to the next step.
The activity task layer service performs the following:
Sends requests to the activities management system.
Receives and absorbs activity status updates.
Enables creation of new activity task types and activity defaulting.
The activity task layer service sends a Create Activity request to the activities management system where the actual activity will be created. When a change order is received or an order is canceled, the task layer service changes or cancels the activity as necessary. When a hold is applied to an order, the task layer service requests the activities management system to hold the activity that is in progress.
You can schedule a process to obtain an activity status periodically.
You can create new activity task types to accommodate your organization's business needs. You can also enable activity defaulting at either the task type or process step level. The subject of the activity is defaulted from the process step name, unless the default value is set for either task type or process step. By defaulting activity type, you can categorize activities, so that the activities management system can perform the designated business logic and validation based on the activity type. An activity template is a blueprint for an activity. Some activities management systems allow you to create activity templates to address the various requirements of a human task. To use this advanced feature in the activities management system, when defining task types and orchestration processes, specify the designated activity template for a task type or process step to create the activity according to the predefined template.
The return task layer service is responsible for initiating communication with receiving systems and interpreting the responses and updates from those systems. Some of the requests originate in Distributed Order Orchestration and involve the creation, update, or cancellation of an receipt advice in the receiving system.
The return task layer service performs the following:
Support simple return.
Support returned models.
Receive status updates from the receiving system.
Split fulfillment line due to partial delivery or return to customer.
The return task layer service sends a create receipt advice request to the fulfillment system where the actual receipt advice will be created. If any changes to the original returned sales order are received, then the task layer service requests a change to the existing receipt advice. The request may include one or more attribute updates, such as an increase or decrease in the expected receipt quantity or a change in non-quantity attributes. When items are returned, the task layer service creates a change receipt advice or cancel receipt advice, as necessary. If the original returned sales order line is completely canceled, then the task layer service cancels the receipt advice. Generally, cancellation is allowed until the returned items are received. If the expected delivered quantity is greater than the actual delivered quantity on the receipt advice, then partial cancellation can be requested for the remaining quantity.
The return task layer can process partial receipts, such as the return of only some items of a model.
The return task layer service receives and absorbs status updates from the receiving system for selective triggering events. For example, the receipt of goods on the receiving desk triggers creation of the receipt advice.
The following events in the receiving system can trigger status updates in Distributed Order Orchestration:
Receipt of goods on the receiving deck, when the actual receipt is created.
Delivery of goods into inventory.
Return of goods to a customer.
Correction after a receipt transaction. (Deliver transactions cannot be returned.)
If only part of the expected returned quantity is received, then the return task layer splits the fulfillment line into a line with a status of Delivered for the expected returned quantity and another line with the undelivered expected quantity. A model or kit group is split into two orchestration groups, one group that will have received fulfillment lines and the other group that has nonreturnable fulfillment lines and unreceived fulfillment lines.
The template task layer is a Web service wrapper that makes it possible to create and use your own task types, while maintaining data integrity in Oracle Fusion Distributed Order Orchestration. Use the template task layer to extend the business functionality of Distributed Order Orchestration beyond the seeded task types. The result of maintaining data integrity within Distributed Order Orchestration is that the task type that you create appears throughout the relevant areas of the application, for example, in the Order Orchestration work area. In addition, using the template task layer ensures correct behavior of the following functionality: Status update, wait steps, forward planning, jeopardy, holds processing, split processing, change management, and error recovery.
Custom services that are created using the template task layer function the same way as predefined task layer services.
For more information about implementing the template task layer, see DOO: Oracle Fusion Distributed Order Orchestration White Papers (1536633.1) on My Oracle Support at https://support.oracle.com.
Use the template task layer for:
Creating custom tasks and services.
Validating mandatory Distributed Order Orchestration attributes.
Preprocessing the outbound service request.
Postprocessing the inbound service response.
Determining which Distributed Order Orchestration transaction data to update.
Implementers can define new fulfillment task types, fulfillment tasks, and services that can be called in an orchestration process definition.
Implementers can enable the service to determine whether all of the mandatory data is present in the service data object.
Implementers can add preprocessing logic to the actions built into the template task layer service. Your organization might want to add preprocessing logic that defaults data onto the outbound request or validates the data.
Implementers can add postprocessing logic to the actions that are built into the template task layer service. Your organization might want to add postprocessing logic that defaults logic onto the inbound request, validates the inbound response, or interprets any attributes or messages that are returned by the fulfillment system that might indicate the need for split processing.
Implementers can determine which of the Distributed Order Orchestration transaction tables must be updated as a result of the external service call.
Fulfillment order task layer services are designed to enable Oracle Fusion Distributed Order Orchestration to integrate with an Enterprise Resource Planning (ERP) system. In most ERP systems, fulfillment tasks are closely coupled with an order management system and open-ended interfaces through which Distributed Order Orchestration can connect are not available. With the fulfillment order task layer service, you can leverage existing ERP systems.
The fulfillment order task layer services primarily support the following functions:
Sends fulfillment requests to an ERP system.
Aggregates fulfillment lines from a single order across orchestration groups and sends them in a single request.
Receives updates from downstream ERP systems as the fulfillment activities are executed.
Fulfillment order task layer services send fulfillment requests to the ERP system. Requests are for: Creating, updating, or canceling an order in the downstream ERP order management system; placing or releasing a hold on an order in the ERP system; and updating the status of an order. The fulfillment order task layer sends updates to the ERP system every time a change order is accepted that affects the fulfillment of the orchestration order.
Fulfillment order task layer services aggregate and store requests that are bound for the ERP system. You express the aggregation criteria as a rule. You can base the criteria on a time limit or the total number of lines that must be aggregated based on implementation-specific conditions. After the aggregator receives some requests, the aggregator publishes the information from each related request as a single aggregated request. Aggregating the requests minimizes issues with the timing of the requests.
The aggregator uses a combination of timeout and estimated number of fulfillment lines within an orchestration order to determine when to send the single aggregated request. The timeout determines how long the aggregator must wait before it sends whatever it has currently aggregated. When the time expires, the aggregator publishes whatever requests have been accumulated. If an order has several fulfillment lines and the lines complete the task before the timeout occurs, then all requests are sent as soon as the task is completed.
The aggregation is limited to once per system per order. After fulfillment lines are aggregated to a system, no further aggregation is done to the requests that are delivered to the system subsequently. The lines are sent individually.
The default timeout is five minutes. You can set your own timeout using business rules. The timeout must be expressed in minutes.
Note that when you use the aggregator for external interface routing rules you can use one or both of the following parameters:
AGGREGATOR_MAX_FLINES: The external fulfillment system is called only after the number of pending requests exceeds the number specified.
AGGREGATOR_WAIT_TIME: The external fulfillment system is called only after time elapsed from the first request processed exceeds the wait time.
When you specify both attributes, the external system is called when either of the conditions is met.
Fulfillment order task layer services receive interim and final status updates from an ERP system. The responses are not delivered right away. They are delivered as the fulfillment activities are executed.
After an original sales order or change order enters Oracle Fusion Distributed Order Orchestration, the order is decomposed and transformed, using business rules, into an orchestration order. The orchestration order and orchestration order lines that result from the transformation do not necessarily mirror the original sales order and sales order lines. For example, the number of orchestration order lines may exceed sales order lines, or orchestration order lines may appear in a different sequence.
The differences between sales orders and orchestration orders arise because orchestration orders are configured for fulfillment requirements, while sales orders are configured for sales requirements. The following figure shows an orchestration order that has one more line than the sales order. The orchestration order line contains a region-specific AC adapter, which is not relevant to the sales order.
In some cases, a sales order might not be transformed to an orchestration order. Transformation can fail for several reasons: Transformation rules were not set up correctly in Distributed Order Orchestration, mandatory attributes were not sent with the sales order, or a validation failure occurred. The order administrator must examine the error messages to determine the exact reason.
An activity is an event that takes place outside Oracle Fusion Distributed Order Orchestration. For example, an orchestration process might include an activity task type to configure a network router. An activity contains the details needed to complete the task. Completion of the activity is reported to Distributed Order Orchestration.
After a sales order enters Oracle Fusion Distributed Order Orchestration, it is transformed to an orchestration order with one or more fulfillment lines. The application then attempts to assign an orchestration process to a fulfillment line or group of fulfillment lines. An orchestration process might not be assigned due to a system failure or a problem with the process assignment rules. For example, a rule that applies to the orchestration order data set might not exist; if a default orchestration process is not designated, then an orchestration process cannot be assigned. You can determine the reason for the process assignment failure by viewing the messages in the Order Orchestration work area. If you have the Error Recovery Manager role, then you can select Assign Lines to Process. If that does not work, then an administrator might need to edit the process assignment rules.
You might find that when you search for the results of a mass action by querying by user request number and status that the results are not as you expect because the request might not have completed on some fulfillment lines. For example, you might search for user request number 123 and user request status Completed. The search results will show the fulfillment lines that are completed, but you might see the Processing user request status icon on some of the fulfillment lines because a later user request is processing these fulfillment lines.
Pause tasks can be released manually or automatically so that the orchestration process can resume. A scheduled process can release all pauses automatically, so that the orchestration process can resume. To release a Pause task manually, you must have the Order Orchestration Error Recovery Manager role. Click the Release Pause Task button on the Orchestration Process details page.
The Release Pause Tasks scheduled process and Release Pause public service can be set up to release a Pause task automatically.