Supply Chain Plan Cross-Instance Planning

This chapter covers the following topics:

• Overview of Cross-Instance Planning
• Instances
• Collections
• Cross-Instance Supply Chain Modeling
• Cross-Instance Planning
• Global Available to Promise
• Cross-Instance Execution
• Cross-Instance Data Considerations
• Purchase Orders and Sales Orders Across Instances

Overview of Cross-Instance Planning

This explains cross-instance planning and available-to-promise in Oracle Advanced Planning. Cross-instance planning is defining, running, and executing a single plan across multiple source instances. It is a key feature for companies that use a hub-and-spoke planning model.

Instances

The Oracle Advanced Planning can plan a single instance or multiple instances. An instance is a database and a set of applications.

There are several types of instances:

• Source instances hold source information, for example, items, bill of materials, orders. Source instances are Oracle Applications instances and legacy systems.

• The destination instance (APS planning server) holds planning information. Planners use the planning server to store information collected from the source instances; run, analyze, and simulate plans; and implement planned orders.

Collection from an Oracle Applications source instance are standard functionality; from legacy systems, develop a customized collection.

The diagram shows four source instances (S11, ABC, TR1, and S07) feeding a planning server.

Instance example

To set up cross-instance planning, the system administrator:

• Establishes a database link between the source instances and the APS planning server.

• Registers the source instances: Use the Application Instances form (Setup > Instances) to set parameters about each source instance that planning should consider, for example, base currency and time difference.

Collections

Before running plans on the planning server, you collect the source data (planning related data and transactional data). In the situation depicted in the instance example, you run a collections concurrent process to collect from each source instances. You can run the collections concurrent processes in parallel.

You can process collections in any of the following methods:

• Complete: Use this method to collect all data and overwrite the data from previous collections.

• Net change: Use this method to collect only new and changed data since the previous collection.

• Targeted: Use this method to collect selected data in a complete refresh.

For more information, see Collection Methods.

Cross-Instance Supply Chain Modeling

Cross-instance supply chain planning involves planning organizations that are in different instances in one planning process. The organization are:

• Shipping organizations: Organizations that ship material

• Receiving organizations: Organizations that receive material

Sourcing rules, bills of distribution, and assignment sets specify how the planning engine should source across instances.

The rectangles in this diagram shows five instance-organization combinations that share material. The characters before the colon of each instance-organization represent the instance and the letters after the colon of each instance-organization represent the organization within the instance. For example, for instance-organization ABC:S1, the instance is ABC and the organization is S1.

Sourcing rules example

To model a cross instance supply chain, model cross-instance:

• Lead-times

• Sourcing relationships

• Customers and suppliers

Modeling Cross-Instance In-transit Lead-times

You define cross-instance intransit lead-times on the planning server in the Transit Times form (Setup > Transit Times).

Use this form to set up transit times between two organizations in the following cases:

• One organization is an Oracle Process Manufacturing (OPM) organization and the other is a discrete manufacturing organization.

• The two organizations are in different instances.

To set transit times between two discrete manufacturing organizations that are in the same instance, use the Oracle Inventory Shipping Networks form (Setup > Organizations > Shipping Networks). Populate the From Org and To Org fields there, then navigate Tools > Ship Methods and populate the ship method. Then, collect the information to the destination instance.

To view, create, and maintain cross-instance lead times

1. Navigate to the Transit Times form (Setup > Transit Times).

2. In Organization, select an instance-organization.

3. To see the existing shipping network, in Scope, select a value and click Find. View information in the Shipping Networks and Ship Methods regions.

   In the From Org query, you can see all of your organizations. In the To Org query, you can see only organizations that are from another instance.

4. In the Shipping Networks region, select a From Org (shipping organization) and To Org (receiving organization) pair.

5. In the Ship Methods region, enter or change the shipping methods that you use between the two locations. Click Ship Methods Lookup to view the available shipping methods.

   For each shipping method, enter or change Transit Time in calendar days.

   For the shipping method that you use most often, click Default Method.

6. Save your work.

Defining Cross-Instance Sourcing Relationships

To set up sourcing rules:

• Specify the sourcing for cross-instance planning on the planning server; use the Sourcing Rule window (Sourcing > Sourcing Rules) and the Bills of Distribution window (Sourcing > Bills of Distribution)

  This table shows the sourcing rules needed to set up a sourcing rules example.

  Sourcing Rule/Bill of Distribution	Receiving Org	Shipping Org	Allocation %	Intransit lead-times
  SR100	S11:M1	TR1:M2	25%	3
  SR100	S11:M1	S07:M3	75%	10
  SR200	ABC:S1	TR1:M2	60%	1
  SR200	ABC:S1	S07:M3	15%	5
  SR200	ABC:S1	S07:S1	25%	10

• Assign sourcing rules in an assignment set; use the Sourcing Rule/Bill of Distribution Assignments window (Sourcing > Assign Sourcing Rules) to assign sourcing rules and bills of distribution to:

  • Items

  • Item in an organization

  • Categories of items in organizations

  • Organization

  • Instances

    For more information, see Setting Up the Supply Chain.

Modeling Cross-Instance Customers and Suppliers

In each shipping organization, set up each receiving organization that it ships to as a customer. The customer appears on sales orders between the two. For example:

• Instance-organization TR1:M2 supplies instance-organization S11:M1.

• In TR1:M2, set up a supplier CUST_S11_M1. CUST_S11_M1 represents instance-organization S11:M1.

In each receiving organization, set up each shipping organization that supplies it as a supplier and supplier site. The supplier appears on purchase orders between the two. If a supplying organization supplies multiple receiving organizations, set up the same supplier name in all the receiving organizations. For example:

• Instance-organization S11:M1 receives from instance-organization TR1:M2.

• In S11:M1, set up supplier SUP_TR1_M2 and supplier site Hong Kong. Supplier SUP_TR1_M2 represents instance-organization TR1:M2.

After setting up suppliers that represent cross-instance shipping organizations:

• Collect the suppliers to the planning server. This relates the shipping organizations and their supplier names for all instance-organizations.

• Run concurrent process Create Instance-Org Supplier Association in each shipping organization.

  See Create Instance-Org Supplier Association.

For example, in shipping organization TR1:M2, run concurrent process Create Instance-Org Supplier Association with parameter values:

• Instance Code: TR1

• Organization: Instance: TR1:M2

• Modeled Supplier: SUP_TR1_M2

• Modeled Supplier Site: Hong Kong

• Accept demands from Unmet PO: No

When you release planned orders in receiving organizations for items sourced from cross-instance shipping organization, TR1:M2, Planner Workbench creates an external purchase requisition against supplier SUP_TR1_M2, supplier site Hong Kong.

This diagram shows the cross-instance supplier-customer modeling process just described.

Cross-Instance Customer-Supplier Modeling

To delete an instance-organization supplier association, run concurrent process Create Instance-Org Supplier Association with only parameters Instance Code and Organization: Instance.

You can also use the concurrent process with the same steps to create an instance-org supplier relationship for an organization that models a supplier. When you release a planned order for this organization, the planning engine creates an external purchase requisition, not an internal requisition.

Cross-Instance Planning

To define a plan that spans multiple instances, specify the following in the plan options (Supply Chain Plan > Options):

• All instance-organizations. For the instance example, select the five instance-org combinations along with their demand and supply schedules.

• The assignment set with the cross-instance sourcing relationships.

For more information on defining plans, see Overview of Defining Plans.

The combination of sourcing rules/bill of distribution, bills of material, and routings create a supply chain bill. The planning engine:

• Explodes independent demand through the entire cross-instance supply chain

• Creates planned supply for each component at each level of the supply chain bill, if needed.

For example, as the instance example plan runs, the planned orders generated in instance-organization S11:M1 and instance-organization ABC:S1 may have instance-organization sources TR1:M2, S07:M3, or S07:S1 according to the sourcing rules and bill of distribution that you defined and assigned to the plan.

The planning engine creates planned orders and recommendations for all instances and organizations in the day and time scheme of the plan owning organization.

Global Available to Promise

The available-to-promise calculation uses the supplies generated in a cross-instance plan to evaluate availability. If there is a need for more supply, the capable-to-promise calculation uses the supply chain bill from cross-instance sourcing to evaluate the capability and returns a valid availability date.

Cross-Instance Execution

After a cross-instance plan completes, you see planned orders and reschedule/cancel recommendations in the planner workbench with sources from different instances-organizations. If you act on these, the APS planning server passes the information to the source instances.

Before releasing planned orders from the plan owning organization to multiple instances, perform the following set up:

• Set up the same user name in both source instances

• Tie the user name in each source instance to a manufacturing responsibility

The troubleshooting indication for this setup is that planned orders for make at items in the non-owning organization instance show in Planner Workbench with Imp Qty = 0.

This table shows the assignment set for the instances example. The:

• Receiving organization is the organization with the planned order (the ship-to organization)

• Shipping organization is the organization that supplies the planned order (the ship-from organization)

  Item	Receiving Organization	Shipping Organization
  A	S11:M1	TR1:M2
  B	S11:M1	S07:M3
  C	ABC:S1	TR1:M2
  D	ABC:S1	S07:M3

As you release a cross-instance planned order or recommendations in the receiving organization, the Planner Workbench creates an external purchase requisition there and references the supplier that represents the shipping organization. For example:

• A planned order in the receiving organization S11:M1 shows supply source TR1:M2 in Planner Workbench.

• The release process creates the external purchase requisition with supplier SUP_TR1_M2.

You:

• Create a purchase order in the receiving organization.

• Create an external sales order in the shipping organization and reference both the purchase order number in the receiving organization and the customer that represents the receiving organization, for example, CUST_S11_M1. If you do not reference the purchase order number, the purchase order and sales order do not peg. You can use the Order Import concurrent process to create sales orders against purchase requisitions that need them.

The collections process brings the sales orders into the planning server for display, including pegging.

You:

• Perform shipment transactions in the shipping organization.

• Perform receiving transactions in the receiving organization.

This diagram shows the cross-instance execution process.

Cross-Instance Execution

Oracle Applications does not convert financial data to the base currency of each organization.

Cross-Instance Data Considerations

In the example of multi-instance data collection, there are four source instances. Oracle recommends that you pay detailed attention to data values. The collection process must collect data entities from the four source instances, eliminate duplicate values, and produce a combined, consistent set of values (data cleansing or data scrubbing).

Data cleansing involves:

• Eliminating duplicate values that are common in the source instances

• Adjusting source values ensuring consistent values for the same business entities (such as the same item) across instances.

For more information on data cleansing techniques, see My Oracle Support.

Constraint Violations

Duplicate data values do not affect the behavior of the planning process. However, the collection process may issue warnings. This often occurs with data that is not instance specific, such as unit of measure codes.

For example, the collection process:

• Collects unit of measure code EA from instance S1

• Collects unit of measure code EA from instance ABC

• Issues ORA-00001: Unique Constraint Violation

Since unit of measure EA is collected, you can safely ignore this warning; it does not cause collections or planning to fail. To eliminate it, delete the duplicate data from the staging tables for the remaining instances. Data types affected by the unique constraint include:

• Unit of measure code

• Unit of measure class

• Unit of measure conversions

• Category set name

Text Differences with Conversions

Data with the same meaning may be in different source instances with similar codes and Oracle Applications provides conversions.

For example, these source instances have these unit of measure codes that all represent the unit of measure each:

• S1: EA

• ABC: ea

• TR1: Ea

• S07: EA

After collections, the planning server contains unit of measure codes EA, ea, and Ea. The planning process considers these as different units of measure. Before launching the planning process, you should make sure to have unit of measure conversions among these unit of measure codes

Text Differences without Conversions

Typically, Oracle Applications achieves unique data values in the operational data store for data entities through data entity ID's--internally generated numeric values. However, there are exceptions in which Oracle Applications uses text unique indices to achieve unique data values.

In these cases, data with the same meaning may be in different source instances with similar text and Oracle Applications does not provide conversions.

For example, these source instances have these item codes that all represent the item Oak Desk:

• S1: Oak Desk

• ABC: OAK Desk

• TR1: OAK DESK

• S07: oak desk

After collections, the planning server contains item codes Oak Desk, OAK Desk, OAK DESK, and oak desk. The planning process considers these as different items. Before launching the planning process, you should make sure to develop a data cleansing process to eliminate the conflicts by adjusting the different values to reflect the same value. You can:

• Pull items from instance S1 to staging tables

• Load items from the staging tables to the operational data store

• Pull items from instance ABC to staging tables

• Run a SQL script to update OAK Desk to Oak Desk in the staging tables.

• Load items from the staging tables to the operational data store

• Repeat the pull to staging tables, SQL script, and load to operational data store for source instances TR1 and SO7.

These are the data entities in which Oracle Applications uses text unique indices:

• Item name

• Item category

• Customer

• Customer site

• Vendor

• Vendor site

• Bottleneck resource group

• ABC class

• Demand class

• End item substitution set

• Global approved supplier list

• Currency

• Product family

Purchase Orders and Sales Orders Across Instances

In a multi-organization structure, the supplier in the source instance provides supplies to the destination instance against a purchase order. When you release a purchase order from the destination instance to the source instance, the supplier creates a sales order and releases it from the destination instance to the source instance.

The planning engine treats transactions across instances as external requisitions. Variations in demand within the destination instance influence the sales order demand in the source instance. The planning engine plans to supply schedule across instances. When you run collections, the planning engine pegs the external purchase order to the external sales order.

Cross Instance Pegging Logic

In specific situations, this is how pegging works:

• If the quantity in the sales order is same as the quantity in the purchase order, the sales order is pegged to the purchase order.

• If the quantity in the sales order is less than the quantity in the purchase order, the purchase order creates a planned order demand with quantity equal to the difference of quantities in purchase order and sales order in the supplier's organization. The supplier can accept the excess demand as a planned order demand in the organization and later convert the planned orders to sales order manually. This behavior is determined by the value set for the flag Accept Demands from Unmet PO (set while mapping a supplier to an organization). If the value for this flag is set to Yes, the supplier has an option to accept demands from unmet purchase orders. The supplier should be modeled as the organization that is included in the plan. However, if the value for this flag is set to No, the excess demand is not pushed to the supplier's organization.

• If multiple lines in the sales order map to a single line in the purchase order, each line in the sales order is pegged to the same purchase order line.

• If the quantity in the sales order exceeds the quantity specified in the purchase order, the sales order is pegged to the amount specified in the purchase order. The rest of the quantity is pegged to In-Excess.

• If inaccurate purchase order details or item details are specified in the sales order, the sales order is not pegged to the purchase order.

Cross Instances Pegging Criteria

Pegging works when specific conditions are fulfilled:

• Sales orders across instances can be pegged against purchase orders having a single shipment per line. Purchase orders having multiple shipments per line are not considered.

• A single sales order line cannot be pegged to multiple purchase order line numbers because a single purchase order number is associated with a sales order.

Cross Instances Pegging Process

Perform these steps to peg purchase orders and sales orders across instances:

1. Ensure that you have defined cross instance sourcing in the destination organization instance.

2. Run the Create instance-org Supplier Association concurrent program to designate the supplier organization as an external supplier organization. This results in creating sourcing rules.

3. Generate a cross instance supply chain plan.

4. Release a purchase order from the destination instance to the source instance.

5. Supplier needs to manually create an external sales order against the purchase order and specify the purchase order number and the purchase order line number in the source organization instance.

6. After you run data collections and launch and launch the supply chain plan, navigate to the Planner Workbench to view whether or not the purchase order in the destination instance is pegged to the sales order in the source organization instance.

Designating Supplier Organization As External Supplier Organization

If you want a supplier in an organization to be available to other organizations, you need to designate the supplier organization as external. This enables the planning engine to peg across instances. As part of the setup for designating a supplier organization, you need to run the Create instance-org Supplier Association concurrent program. Perform these steps to run the concurrent program:

1. Navigate to the Submit Request window.

2. In the Name field, select Create Instance-Org Supplier Association.

   The Parameters window appears.

3. In the Instance Code field, specify the user-defined 3-character short-form for the instance to be planned.

4. To associate the supplier with the specified instance, specify the supplier in the Modeled Supplier field.

5. Select a specific supplier site in the Modeled Supplier Site field and click OK.

6. Click Submit in the Submit Request window to submit the concurrent program.