Transition from SOAP to REST for Order Management Integration

Service Logistics UIs and APIs create sales orders for parts sales, returns, exchanges, and depot repair logistics, as well as for field service and depot repair billing. In this release, the Order Management SOAP APIs that Service Logistics used to create sales orders have been replaced with Order Management REST APIs. 

These REST APIs have privileges that need to be assigned to your job roles.  Before 25C, these privileges were assigned to the seeded Field Service Administrator and Depot Repair Manager job roles to enable use of the Update Order REST APIs.  The Update Rest APIs are used for the debrief/charges corrections functionality released in 23D.  In 25C, these privileges were also assigned to the seeded Field Service Technician duty role.

  1. Create Sales Order Requests (FOM_SALES_ORDER_REQUEST_REST_POST_PRIV)
  2. Delete Sales Orders (FOM_SALES_ORDER_REST_DELETE_PRIV)
  3. Get Sales Orders (FOM_SALES_ORDER_REST_GET_PRIV)
  4. Update Sales Orders (FOM_SALES_ORDER_REST_PATCH_PRIV)
  5. Create Sales Orders (FOM_SALES_ORDER_REST_POST_PRIV)

If you use custom job roles, then assign these privileges to them so you can continue to create sales orders from Service Logistics UIs and APIs.

In addition, you need to consider the following potential issues to see if they apply to your implementation.

  1. Order Line Item Definition Organization
    The OM REST APIs don't accept the Item Definition Organization when creating a order line.  As such, you must now setup Order Management (OM) Defaulting Rules to populate the Item Definition Organization, which are typically based on Business Unit.  In addition, if you have an OM extension that populates the item definition organization with a transaction organization (like the organization on the Debrief Line), you should consider populating the fulfillment organization on the OM Fulfillment table (doo_fulfill_lines_all) instead, as it is used downstream as the transaction organization. In a future release, the fulfillment organization may be populated by Service Logistics when creating bill-only OM Lines as is already done for shipping and return OM Lines.
     
  2. Return Order Line Payment Terms
    The OM REST APIs don't accept Payment Terms for return order lines, so in 25C, Service Logistics no longer creates return order lines with payment terms.  If you have a OM Extension that populates payment terms on return order lines, you must remove it.  In addition, you will need to create a OM Extension to remove payment terms from existing return lines when an order created before 25C is being updated. For example, when adding charges lines or additional parts.
     
  3. Order Header Ship-to Customer
    The OM REST APIs default the ship-to customer from the sold-to customer if it's not passed in by the calling program.  As such, the ship-to address must be valid for this sold-to/ship-to customer. 
    For field service charges, Service Logistics uses the debrief header service address (which is associated to the sold-to customer) to populate the the order header ship-to address, so there is no issue here for customers.
    For parts only and depot repair logistics, Service Logistics does not populate the ship-to customer or address on the OM Header.  Here customers must create an OM extension to set these fields (Ship-to Customer/Party,  Address, Ship-to Contact Point, Ship-to Contact) to null or populate them with valid values.  Customer, that create Sales Orders with the Service Logistics APIs, must pass a ship-to address that is associated to the sold-to customer as the Service Logistics APIs don't accept ship-to customer as an input.

  4. REST Extension with Validations
    OM REST currently creates a draft and returns a success response when an OM extension with validation fails at the submit event.  These order lines in draft status can get lost when another order change is processed.  This behavior differs from SOAP, which returned an upfront error and did not create a order draft.  As such, customers should move their OM extensions with validations to On Save from On Submit so draft order lines do not get created when a validation fails.

  5. Order Customer Relationships
    OM now has functionality to enforce relationships between sold-to, ship-to and bill-to customers.   These relationships are not enforced in the Service Logistics UIs and APIs.  As such, customers should set the OM Customer Relationship Type parameter to All Customers if they don't want this validation performed when creating sales orders from Service Logistics UIs and APIs.

Allows users to create sales orders from the Service Logistics UIs and APIs using the latest Order Management REST APIs instead of the SOAP APIs that a no longer being enhanced.

Steps to Enable

Assign the REST privileges to your job roles that create sales orders using Service Logistics UIs and APIs.  Make necessary changes to your OM extensions.

Access Requirements

Users need a job role with the following privileges to create and update sales orders in 25C:

  1. Create Sales Order Requests (FOM_SALES_ORDER_REQUEST_REST_POST_PRIV)
  2. Delete Sales Orders (FOM_SALES_ORDER_REST_DELETE_PRIV)
  3. Get Sales Orders (FOM_SALES_ORDER_REST_GET_PRIV)
  4. Update Sales Orders (FOM_SALES_ORDER_REST_PATCH_PRIV)
  5. Create Sales Orders (FOM_SALES_ORDER_REST_POST_PRIV)