Create one customer details for an order

post

/fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub/{OrderKey}/child/shipToCustomer

Request

Path Parameters
  • Value that uniquely identifies the sales order. It can have the following formats.

    - Concatenation of SourceOrderSystem, a colon, and the value of SourceTransactionId. For orders created through the Oracle Fusion Cloud Order Management work area, the SourceTransactionId is same as the HeaderId. For example, if SourceOrderSystem is LEG and SourceTransactionId is R13_Sample_Order, the value of this attribute is LEG:R13_Sample_Order. This format of the OrderKey in the URL always returns the latest version of the sales order. When a draft exists, that becomes the latest version of the sales order. When invoking GET sales order using this OrderKey format, the URLs in the "links" section point to the latest version of the sales order and the corresponding child objects.
    Example: /salesOrdersForOrderHub/LEG:R13_Sample_Order points to the latest version of the order with SourceTransactionId "R13_Sample_Order" in the SourceOrderSystem "LEG".

    - Primary key of the sales order, which is HeaderId. This format of the OrderKey is useful when the order has multiple revisions because it helps in accessing either the older version or the latest version of the order. When there's a draft revision then HeaderId can be used to access the processing order. When invoking GET sales order using this OrderKey format, the URLs in the "links" section also point to that specific version of the sales order and the corresponding child objects. Only the Get operation is supported on older revisions of the order.
    Example: /salesOrdersForOrderHub/12345 points to an order with HeaderId 12345.

    When a q parameter or query finder is used to GET an order that has multiple versions then the latest version has the OrderKey in the format <sourceOrderSystem>:<SourceTransactionId> whereas reference orders have OrderKey in the format of HeaderId.
Header Parameters
  • If the REST API supports runtime customizations, the shape of the service may change during runtime. The REST client may isolate itself from these changes or choose to interact with the latest version of the API by specifying this header. For example: Metadata-Context:sandbox="TrackEmployeeFeature".
  • The protocol version between a REST client and service. If the client does not specify this header in the request the server will pick a default version for the API.
  • Contains one of the following values: true or false. If true, the server performs an Upsert operation instead of a Create operation. During an Upsert operation, the server attempts to find an existing resource that matches the payload. If a match is found, the server updates the existing resource instead of creating a new one. If not found or false (default), the server performs a Create operation. Note that the Upsert operation isn't supported for date-effective REST resources.
Supported Media Types
Request Body - application/json ()
Root Schema : schema
Type: object
Show Source
Back to Top

Response

Supported Media Types

Default Response

The following table describes the default response for this task.
Headers
  • If the REST API supports runtime customizations, the shape of the service may change during runtime. The REST client may isolate itself from these changes or choose to interact with the latest version of the API by specifying this header. For example: Metadata-Context:sandbox="TrackEmployeeFeature".
  • The protocol version between a REST client and service. If the client does not specify this header in the request the server will pick a default version for the API.
Body ()
Root Schema : salesOrdersForOrderHub-shipToCustomer-item-response
Type: object
Show Source
Back to Top