Set Up Orchestration Processes for Coverage Items

You can set up an assignment rule so it uses the same orchestration process instance to process the covered item and the coverage item.

You can also set it up so it uses one orchestration process instance to process the covered item and another orchestration process instance to process the coverage item, depending on your needs.

For details, see Coverages and Subscriptions in Sales Orders.

Use the Same Orchestration Process Instance

If you add the covered item and coverage item in the same sales order at the same time when you create or revise the sales order, then you can assign the same orchestration process instance to process the covered item and the coverage item together.

  • Make sure the orchestration process uses the same steps, in the same sequence, and at the same time for the covered item and for the coverage item.

  • Make sure processing for the covered item and coverage item remain synchronized, and make sure processing for the covered item doesn't get too far ahead or behind processing for the coverage item.

  • Order management assigns the same orchestration process number to the covered item and to the coverage item.

Try It

  1. Set up your orchestration process. Here's an example.

    Using the Same Orchestration Process Instance

    Note

    • A red step means the step doesn't apply to the item so the orchestration process skips the step. For example, you don't schedule, reserve, or ship a warranty, so those steps don't run for the warranty.

    • The covered item and the coverage item move together through the same steps, at the same time.

    • If a step applies to the covered item but not the coverage item, then the coverage item will be in a Not Started status, and remain in this status until it reaches a step that applies to the covered item and the coverage item.

      In this example, the Warranty for Computer coverage item is in the Not Started status all the way to the Invoice step because the Invoice step is the first step in the process that applies to the covered item and the coverage item.

  2. Set up an assignment rule to make sure Order Management uses the same orchestration process for the covered item and for the coverage item.

    You set up the rule one time during setup. The orchestration process instance that runs in the runtime environment is different for each sales order or fulfillment line.

    For details, see Assign Orchestration Processes.

  3. Set up an expression in the line selection criteria for each orchestration process step that must not run so the step doesn't call the fulfillment task service.

    The red steps in the diagram must not run.

    • You don't ship a coverage item, such as a warranty, so you set up an expression that prevents the shipping step from processing the coverage item. Add a line selection criteria that specifies to process only shippable lines. Add the criteria to a Scheduling task or Shipping task. Predefined orchestration processes already use this line selection criteria.

    • The Contracts step doesn't need to run for a covered item, so add a line selection criteria that specifies to run this step for each line only when the Sales Product Type specifies a coverage item.

    Learn how to set up an expression. For details, see Select Fulfillment Lines for Orchestration Process Steps.

This orchestration process is only for illustration purposes. You might need a different set up for your assignment rules and expressions.

Use Different Orchestration Process Instances

It might be necessary to use one orchestration process instance to process the covered item and a different orchestration process instance to process the coverage item. For example:

  • Your business requirements demand that you process them separately.

  • An assignment rule assigns separate process instances when creating the sales order.

  • You use the Revise Order action in the Order Management work area to revise the sales order, add coverage to an existing covered item, then submit the revision. Order Management assigns a separate orchestration process instance even if the assignment rule assigns the same instance that processes the covered item.

  • Order management assigns one number to the orchestration process instance that processes the covered item and a different number to the instance that processes the coverage item.

Try It

  1. Set up your orchestration process.

    Here's an example that illustrates how you can use a pause task to make sure the coverage item and covered item go to billing at the same time.

    Using Different Orchestration Process Instances

    Note

    • Orchestration process instance x can process the covered item independently of the coverage item.

    • Orchestration process instance y can process the coverage item independently of the covered item.

    • The coverage item will proceed directly to the pause task, then wait until the covered item finishes the Install Base step.

    • The Install Base step finishes, the orchestration process releases the pause on the coverage item, and then the covered item and coverage item move together to the Invoice task.

  2. Add a pause task.

    • If your orchestration process includes an invoice step, then make sure you do the billing step for the covered item and the coverage item at the same time.

      Fulfillment for the covered item is almost always behind fulfillment for the coverage item because the covered item goes through shipping but the coverage item doesn't. So, to do billing at the same time, add a pause step immediately before the invoice step in the orchestration process that processes the coverage item. This way, fulfillment for the coverage item pauses while it waits for fulfillment for the covered item to get to the billing step.

    • The pause task makes sure the orchestration process instance that processes the coverage item doesn't get too far out in front of the instance that processes the covered item. For example, the Contracts step must not process the coverage item until after the covered item ships and the Install Base step runs.

    • You can set the pause exit criteria to a condition, such as Shipped Quantity is greater than zero.

    • Order Management doesn't allow updates to the order line once billing starts. Adding a pause task makes sure that the orchestration can apply any actions you do on the covered item to coverage item, such as update, split, or cancel.

      • Assume you set the quantity on the covered item and the coverage item to 5, then submit the sales order.

      • Assume the coverage item proceeds immediately to billing.

      • You create an order revision, revise the quantity on the covered item to 4, and submit it.

      • The revision goes through fulfillment and proceeds to billing. However, the quantity for the coverage item is 5, its already in billing, so now the quantities for the coverage item and the covered item don't match, causing an error in the billing step. Pausing the coverage prevents this problem.

    • For details, see Pause Orchestration Processes for Events.

Here's an example If statement for the pause task.

example If statement for the pause task

Pseudocode for the If statement.

  • If the fulfillment line contains a coverage item, and if the fulfillment line that the coverage item covers is shippable but hasn't yet shipped

Here's an example Then statement for the pause task.

example Then statement for the pause task

The pause continues until actualShipDate contains a date, which indicates that shipping has shipped the covered item and the orchestration process can proceed to the billing step.

For details about the code that you see in this rule, see Pause Orchestration Processes for Events.