1. Technical Guide
  2. System Operations
  3. Brokered Backorders
  4. Retail Pickup (including Ship-for-Pickup) or Delivery Orders

Retail Pickup (including Ship-for-Pickup) or Delivery Orders

Overview: Use the retail pickup or delivery options in the Order Orchestration Integration to receive orders from Order Orchestration in order to fulfill the orders in Order Administration.

  • If the order is a retail pickup order or a retail pickup order that originated as a ship-for-pickup order, Order Administration ships the merchandise to the customer-selected store location for pickup.

  • If the order is a delivery order, Order Administration ships the merchandise to the customer’s ship-to address.


The figure shows an example for a retail pickup order process.

If the originating location was Order Administration: If the Use OROB for Fulfillment Assignment (M31) system control value is selected or the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, the order may have originated in Order Administration and during Brokered Backorders processing, Order Orchestration determined that Order Administration was the best fulfilling location. In this situation:

  • Order Orchestration assigns the Order Administration location to the originating order in Order Orchestration as the Fulfilling location. See Brokered Backorders for additional processing information.

  • At defined intervals, the BROKER process in Work with Integration Layer Processes (IJCT) periodically sends a fulfillments request message to Order Orchestration to poll for newly assigned orders (those whose Fulfilling location is an Order Administration location). See Retail Pickup (including Ship-for-Pickup) and Delivery Order Processing for additional processing information.

  • When the BROKER process receives the order in the fulfillments response message, it looks at the values in the fulfillments response to determine the type of order to create.

    • The system creates a new delivery order if the transaction_type_id is DELIVERY.

    • The system creates a new retail pickup order if the transaction_type_id is RETAILPICKUP or SHIPFORPICKUP.

    See Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order for additional information.

  • In order to tie the originating order (the original order sent to Order Orchestration for fulfillment assignment) with the new sourcing order (the delivery or retail pickup order created to fulfill the original order), Order Administration stores the originating order number in the E-commerce order number field in the Order Header Extended table for the newly created sourcing order and prefixes the order number with the text ORIG#:. For example, the system updates the E-commerce order number with ORIG#: 9999-001, where ORIG#: indicates the order has been created as a result of Order Orchestration fulfillment assignment, 9999 is the order number, and 001 is the ship-to number. See Reviewing Retail Pickup (including Ship-for-Pickup) or Delivery Orders in Order Inquiry for additional information.

In this topic:

For more information: See Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration.

Retail Pickup (including Ship-for-Pickup) and Delivery Order Processing

Poll for orders? If both the Order Type for Orders Brokered for Delivery (K91) and Order Type for Retail Pickup Orders Brokered to OROMS (K92) system control values specify order types, the BROKER process in Working with Integration Layer Processes (IJCT) periodically sends a fulfillments request message to Order Orchestration to poll for newly assigned orders. The polling interval is based on the Outbound delay time specified for the BROKER process.

fulfillments request: Information in the fulfillments request message includes:

See the Fulfillments Request Message Sample (Retail Pickup, Ship-for-Pickup, or Delivery Orders) in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for an example.

The endpoint where Order Administration sends the fulfillments request message is specified in Working with Customer Properties (PROP).

Create order? When the BROKER process receives an order in the fulfillments response message, it:

Note:

  • Drop ship items are eligible to be fulfilled on a retail pickup or delivery order regardless of whether any units are currently stocked in the warehouse, provided they are not flagged with a soldout control value.

  • If a retail pickup or delivery order includes multiple order lines, and one of them is sold out, Order Administration still accepts the order. To avoid this situation, have integrating systems submit each order line as a separate order.

Multiple order lines? Submit each ordered unit to Order Orchestration as a separate order. Sending orders this way prevents any inconsistencies in order status that might occur if, for example, a multi-line order in Order Administration included a soldout item, but the other order lines could still be shipped from the warehouse, or if a multi-unit line was split across different warehouses for fulfillment.

Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order

The processing to build a new retail pickup or delivery order from the contents of the fulfillments response message is similar to that used by the generic order API. In addition to the system (company) and location (warehouse) sent in the fulfillments request message, the information used to build the order includes the following.

Header Information

  • order type: from one of the following system control values:

    The transaction_type_id in the fulfillments response message indicates whether the order is a retail pickup or delivery order.

    • DELIVERY displays if the order is a delivery order.

    • RETAILPICKUP displays if the order is a retail pickup order.

    • SHIPFORPICKUP displays if the order is a retail pickup order that originated as a brokered ship-for-pickup order.

  • order channel (Internet order): set to C. The transaction_channel specified in the fulfillments response message is not used.

  • alternate order number: from the order number in the originating system, passed as the order_id from the fulfillments response (the external system’s order number). The system stores this number in the E-commerce order number field in the Order Header Extended table. If the originating location is Order Administration, the system prefaces the alternate order number with ORIG#: 1234-001, where ORIG#: indicates the order was created as a result of OROB fulfillment assignment, 1234 is the order number, and 001 is the ship-to number.

    Note:

    The system identifies the originating location as Order Administration if the request_system_cd in the fulfillments response message matches the system code in the OROB System (K50) system control value.

  • order date: the current date.

  • entered date: the current date.

  • source code:

    • If the order did originate in Order Administration:

      • Use the Order Broker Source Code (K93), if specified; otherwise, if this system control value is blank,

      • Use the source code, if any, specified for the store cross reference record for the originating location, which is based on the Originating Location to Pass to OROB (M32) system control value; otherwise,

      • Use the source code passed in the fulfillments response message from Order Orchestration, which would be from the originating order.

    • If the order did not originate in Order Administration:

      • Use the source_code, if any, passed in the fulfillments response message from Order Orchestration; otherwise,

      • Use the source code, if any, specified for the store cross reference record for the originating location; otherwise,

      • Use the Order Broker Source Code (K93), if specified; otherwise, if this system control value is blank,

      • The order is created in error status because of the missing source code.

Customer Mapping and Updates

If the ORCE Customer ID in OROB Fulfillment (M72) system control value is NOT selected:

  • customer number:

    • if the customer_no passed in the fulfillments response is a valid customer number, then use this customer. For example, a customer_no of 13827 or 000013827 indicates sold-to customer 13827. Zero-filling the customer number is optional. Otherwise,

    • if the customer_no passed is invalid, or if no customer_no was passed, then Order Administration uses standard name and address matching. See Customer Sold To Selection, Creation and Update in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more background.

      Note:

      If the customer_no is invalid, the error is logged in Order Administration’s APP.log file, even though the order can still be created successfully using the name and address information in the message.

    Note:

    If the Sold to Email Update for Orders Brokered to OROMS (K96) or Sold to Address Update for Orders Brokered to OROMS (K97) system control values are selected, Order Administration updates the existing customer record with any changed information.

  • email address updated? The Sold to Email Update for Orders Brokered to OROMS (K96) system control value indicates whether to update the customer’s email address with the email address passed for the order.

  • sold-to phone numbers: the phone1 passed updates the customer’s daytime phone number and the phone2 passed updates the customer’s evening phone number if the Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97) system control value is selected. Any non-numeric characters passed in the phone numbers are stripped out.

If the ORCE Customer Integration (L37) system control value IS selected and the ORCE Customer ID in OROB Fulfillment (M72) is not selected:

  • customer number:

    • Matching customer number: if the customer_no passed in the fulfillments response is a valid customer number, then use this customer. For example, a customer_no of 13827 or 000013827 indicates sold-to customer 13827. Zero-filling the customer number is optional.

      • If the matching customer based on the customer number has an ORCE customer ID, update the customer and pass the update to Customer Engagement.

      • If the matching customer based on the customer number does not have an ORCE customer ID, update the customer and pass the update to Customer Engagement, then update the customer with the ORCE customer ID returned from Customer Engagement.

    • No matching customer number: if the customer_no passed is invalid, or if no customer_no was passed, then Order Administration uses standard name and address matching. See Customer Sold To Selection, Creation and Update in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more background.

    • Order Administration then passes the customer information to Customer Engagement, and updates the customer with the ORCE customer ID returned from Customer Engagement.

      Note:

      If the customer_no is invalid, the error is logged in Order Administration’s APP.log file, even though the order can still be created successfully using the name and address information in the message.

If the ORCE Customer Integration (L37) system control value IS selected and the ORCE Customer ID in OROB Fulfillment (M72) IS ALSO selected:

  • Matching customer based on ORCE customer ID: If the ORCE customer ID is passed as the customer_no, and a customer with same ORCE customer ID is found, update the customer record if needed but do not send an update to Customer Engagement.

  • No matching customer based on ORCE customer ID: If the ORCE customer ID is passed as the customer_no, but no matching customer based on the ORCE customer ID is found, call out to Customer Engagement to get the customer information based on the ORCE customer ID, and create the customer in Order Administration based on the response from Customer Engagement.

  • No customer_no passed: Order Administration uses standard name and address matching. See Customer Sold To Selection, Creation and Update  in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more background.

  • Order Administration then passes the customer information to Customer Engagement, and updates the customer with the ORCE customer ID returned from Customer Engagement.

Additional customer information updates if not matching based on ORCE customer ID:

  • sold-to name and address: the information passed in the fulfillments response message is used to create or update the customer; however, if the customer number passed in the fulfillments response is valid and the Sold to Address Update for Orders Brokered to OROMS (K97) system control value is unselected, the process does not update the customer information. If the customer does not already exist, the name is created in all upper case even if passed from Order Orchestration in upper and lower case.

  • apartment or address line 4:

    • If the apartment tag is passed, the first 10 positions are saved as the sold-to apartment number.

    • If no apartment tag is passed, but an address line 4 is passed, the first 10 positions of address line 4 are saved as the sold-to apartment number.

    • If both the apartment tag and address line 4 are passed, then the first 10 positions of the apartment are saved as the sold-to apartment number, as indicated above, and address line 4 is saved as the fourth address line for the sold-to customer.

  • email address updated? The Sold to Email Update for Orders Brokered to OROMS (K96) system control value indicates whether to update the customer’s email address with the email address passed for the order.

  • sold-to phone numbers: the phone1 passed updates the customer’s daytime phone number and the phone2 passed updates the customer’s evening phone number if the Sold to Address Update for Orders Brokered to OROMS (K97) system control value is selected. Any non-numeric characters passed in the phone numbers are stripped out.

Ship-to Information

  • ship complete? from the ship_complete setting passed in the fulfillments response message; otherwise, from the Ship Complete for Orders Brokered to OROMS (L01) system control value.

  • ship via: from the Order Broker Ship Via (K94) system control value if there is not a valid, numeric ship_via passed in the fulfillments response message. If the Order Broker Ship Via (K94) is blank, the Default Ship Via (A77) applies.

  • gift order? from the Gift Flag for Orders Brokered to OROMS (L03). This system control value overrides the setting passed in the fulfillments response message.

  • freight charges: from the freight_amount specified in the fulfillments response message, if any; otherwise, Order Administration calculates freight. If an additional freight charge is specified for the ship via, Order Administration adds it to the order.

  • tax: the total of the detail-level tax amount passed in the fulfillments response message for each item, plus any tax calculated based on freight and handling charges. The order-level tax amount passed in the message is not used to build the order.

  • freight tax override: always selected, regardless of the setting of the Tax on Freight (B14) system control value.

  • purchase order number: from the ref_transaction_no passed in the fulfillments response message. Displayed at the Display Order Properties Screen in standard order inquiry and at the Third Streamlined Order Inquiry Screen (Order Summary).

  • warehouse: If the Send Inventory by Warehouse to OROB (L06) system control value is selected, this is based on the OROB location for the warehouse sending the fulfillments request message.

  • delivery type (retail pickup or delivery): from the transaction_type_id specified in the fulfillments response message. SHIPFORPICKUP transaction types map to a retail pickup delivery type.

  • ship-to name and address: from the ship_to information for the first item on the order; the ship-to information for any additional item(s) is not used. Creates an Order Ship To Address record, which you can review at the Display Alternate Address Screen. The one-time ship-to phone number is from the phone1, if any, for the first item. If no phone1 is passed for the first item, then the phone2 for the first item is used. For a retail pickup order, the ship-to name and address should specify the name and address of the originating store location. The process creates a one-time ship-to address. If the customer does not already exist, the name is created in all upper case even if passed from Order Orchestration in upper and lower case.

  • store location and system:

    • location_cd: the location fulfilling the order. This is the fulfilling, or sourced, location. For delivery and retail pickup orders, this is always an Order Administration warehouse. This is the Store # for the Store Cross Reference record.

    • system_cd: Order Administration. This is the OROB System (K50).

    • request_location_cd: the location generating the order. This is the originating, or placed, location. This can be a store location or an Order Administration warehouse if the original order was from Order Administration and was brokered for fulfillment assignment. This is the Store # for the Store Cross Reference record.

    • request_system_cd: If the order originated in a store, this is the code identifying your POS system, from the System Code, if any, for the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09). If the order originated in Order Administration, from the System Code, if any, for the Store Cross Reference record; otherwise, from the OROB System (K50).

  • ship-for-pickup location and system:

    • location_cd: the store location where the customer picks up a ship-for-pickup order. This is the pickup location. From the Store # for the Store Cross Reference record.

    • system_cd: The code identifying your POS system, from the System Code, if any, for the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09).

Detail Information

The process creates an order detail line for each item passed in the fulfillments response message. Also:

  • price: the unit_price from the fulfillments response message. Order Administration does not recalculate the price.

  • price override reason code: from the Order Broker Price Override (K95) system control value.

  • requesting system line number: from the requesting_system_line_no passed in the fulfillments response message. Identifies the line number in the originating system.

  • quantity: the qty from the fulfillments response message.

  • gift wrap: from the order_line_gift_wrap flag setting passed in the fulfillments response message. The gift wrap charge specified in the Item Offer, multiplied by the unit quantity, is included in the Handling bucket.

  • order line messages: from the order_line_message passed in the fulfillments response message:

    • If the message passed exceeds the field length of 60 positions, the message is continued on an additional message line.

    • The Print flag for the message lines is set to B (both invoices and pick slips).

  • customization: customization is created for an order line only if:

    • the Item Offer associated with the source code on the order header specifies an additional charge code for a custom special handling format that includes a single line of customization instructions, and

    • the customizations element in the message specifies a customization_code and customization_message

      If:

    • there is no custom special handling format specified for the Item Offer, the information from the customization_code and customization_message are saved as Order Line Messages, with a Print flag of P (Picks), and the order is not suspended with an error.

    • the special handing format detail specifies any valid responses, and the customization message passed is not one of the responses, the order is suspended with an error of Input not valid response

    • the special handling format detail specifies a Max # characters, and the customization message passed exceeds this length, the order is suspended with an error of Exceeds max character

    Note:

    • Order Administration does not validate that the customization_code matches the Field label for the special handling format detail.

    • Custom special handling formats that include more than one detail line are not currently supported for retail pickup and delivery orders received from Order Orchestration.

    • Regardless of whether Order Administration creates custom special handling for an order line, any order_line_customization_charge is still applied to the Handling bucket on the order.

    • The Evaluate Special Handling Charges by Order Line (D67) system control value determines whether to multiply the customization charge passed in the message by the unit quantity.

  • Tax amount: from the tax amount passed for the item in the fulfillments response message. Order Administration does not recalculate tax for items.

Note:

Only the tax amounts passed at the detail level are added to the order in Order Administration; the transaction_tax from the fulfillments response message header level is not used.

Payment Information

  • pay type: from the Order Broker Payment Type (K98).

  • credit card number: From the description of this pay type.

  • suppress deposit flag: set to Y.

  • suppress refund flag: set to Y.

Note:

The tender information, if any, passed in the fulfillments response message is not used.

Order Messages

  • originating store location: written as an Order Message, for example: Originating Store: 317.

  • request ID: written as an Order Message, for example: OROB Request ID: 123456. This information is also saved in the Order Orchestration record.

  • special instructions: the special_instructions at the Order level from the fulfillments response message are written as an Order Message in capital letters, for example: ADD MONOGRAM HEB.

  • additional order messages: the order_message is written as one or more Order Message lines:

    • If the message passed exceeds the field length of 60 positions, the message is continued on an additional message line.

    • The Print flag for the message lines is set to B (both invoices and pick slips).

Note:

Special instructions passed at the item level in the fulfillments response message are not retained.

See the Fulfillments Response Message Sample in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for an example.

Additional Information on Mapping

If any of the information passed in the fulfillments response message exceeds the maximum field length in Order Administration, the information is truncated.

Order count and demand updates: If the originating location is Order Administration, the system does not increase the order count that is displayed on the About Application Screen or perform any demand updates for the delivery or retail pickup order.

Note:

The system identifies the originating location as Order Administration if the request_system_cd in the fulfillments response message matches the system code in the OROB System (K50) system control value. In this situation, the system prefaces the E-commerce order number in the Order Header Extended table with ORIG#: 9999-001, where ORIG#: indicates the order was created as a result of OROB fulfillment assignment, 9999 is the order number, and 001 is the ship-to number.

Not mapped: The following information is not mapped from Order Orchestration when creating the order in Order Administration:

  • order additional freight charges

  • order additional charges

  • the setting of the Under Review flag

  • order line extended freight

  • the setting of the order line Ship Alone flag

  • order line ship weight

  • item UPC or EAN codes

Response messages: After receiving the fulfillments response message, depending on whether it was able to create the order successfully:

  • order creation successful: The BROKER process sends a status update message with a status of Accepted.

  • order created on hold: The BROKER process sends a status update message with a status of Polled.

  • order in error: If the Re-Polling for Orders Brokered to OROMS (L04) system control value is:

    • selected: the BROKER process sends a status update message with a status of Polled

    • unselected: the BROKER process does not send a status update message

    Also, if the order is in error, it is assigned to the Order Broker Error Batch Number (K90).

  • order cannot be created: If the BROKER process cannot create the order in Order Administration, it sends a status update with a status of Rejected.

Order Orchestration record: The process creates an Order Orchestration record regardless of whether the order is in error. The initial status of the Order Orchestration record is New if there are any errors; otherwise, it is In process.

Canceled by originating system? If the order is initially created in Order Administration in error status and then corrected, Order Administration sends an inquiry request to Order Orchestration before changing the order’s status to open. If the response from Order Orchestration indicates that the originating system has canceled the order, Order Administration then puts the order on hold and writes an order transaction history message, such as: Order held - line[s] canceled in Order B.

Changing the order in batch order entry: If the order is suspended or in error, you can use batch order entry to make changes to the order, although you cannot add an order line. Once the order is in held or open status, the restrictions described under Maintaining Retail Pickup or Delivery Orders from the Order Orchestration apply.

Retail Pickup (including Ship-for-Pickup) or Delivery Processing after Order Creation

Checking for canceled or under review retail pickup or delivery orders during pick slip generation: Pick slip generation sends an inquiry to Order Orchestration for all retail pickup and delivery orders eligible for pick slips based on their current status, item availability, and the pick slip selection criteria, to determine whether an eligible order has been canceled in the originating system.

When the response indicates that an order is in canceled status, the program does not generate a pick slip for the order; instead, it puts the order on hold using the Order Broker Hold Reason (Cancel) (L02) system control value.

When the response indicates that an order is under review, the program does not generate a pick slip for the order; instead, it puts the order on hold using the AU hold reason (BROKER ORDER UNDER REVIEW).

Otherwise, Order Administration puts the Order Orchestration record into Picking status when the pick slip is printed and sends a status update message to Order Orchestration indicating that the order or line is in Picked status. Note that this occurs regardless of whether communication with Order Orchestration is successful when pick slip generation sends the inquiry.

Note:

Pick slip generation does not check that the sourcing location for the order is still set to an Order Administration location. For example, a user in Order Orchestration may have changed the sourcing location for the order to a location other than an Order Administration location. In this situation, Order Administration will still generate a pick slip for the order.

Which status request message? Pick slip generation uses the order inquiry status request only if the Use OROB Status Inquiry List Web Service (M05) system control value is set to NO or blank; otherwise, it uses the order status list request. See Use OROB Status Inquiry List Web Service (M05) for details on how Order Administration confirms whether to generate a pick slip for retail pickup and delivery orders.

Streamlined allocation? If there are any retail pickup or delivery orders eligible for pick slip generation, the program can use streamlined allocation only when it uses the status list request. See Use Streamlined Allocation (L63) for background.

Sample messages: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Shipment confirmation: Once the shipment is confirmed, the Order Orchestration record status changes to Intransit for a retail pickup order, or Completed for a delivery order. The corresponding statuses for the orders in Order Orchestration are Intransit and Fulfilled.

Status updates after shipment of a retail pickup order: Once the Order Orchestration record for a retail pickup is in Intransit Polled status, the order status in Order Administration is X (completed); however the requesting store location still needs to receive the order, notify the customer, and have the customer pick up the order.

Deactivating the payment method: When you ship a retail pickup or delivery order, the billing async job deactivates the payment method. Once the payment method is deactivated, you cannot process a refund against the order unless you add a new payment method.

Sending the ship via and tracking number to Order Orchestration: When you confirm shipment, the BROKER process sends a message to Order Orchestration. The information includes the description of the ship via used (even if it is different from the ship via on the order) and the tracking number, if available.

This information is available for review in Order Orchestration at the Order screen. The actual ship via used and tracking number used are displayed on the History tab.

Status inquiry: The BROKER process includes shipped retail pickup orders in order status inquiry list requests just once a day. The Order Orchestration record might be put in any of the following statuses:

  • Received: indicates that the originating store has received the transfer.

  • Completed: indicates that the customer has picked up the order.

  • Partially fulfilled: indicates that the customer has picked up part of the order.

See Setting the Daily Status Inquiry Time Window (all versions) for more information.

Other status updates after order creation:

Order Orchestration integration supports a business process in which only the originating location cancels a retail pickup or delivery order, since the customer is not necessarily aware that the distribution center can be involved in order fulfillment. As a result:

  • Sell out: If you sell out an order line, either in order maintenance or through the Process Auto Soldouts option, Order Administration sends a status update to Order Orchestration indicating the order or order line (based on whether you split orders) was Rejected. Order Orchestration then attempts to reassign the order or line to another location for fulfillment. The Order Orchestration record’s status in Order Administration changes to Rejected.

  • Cancel: If you cancel an order or order line, Order Administration changes the Order Orchestration record’s status to Canceled and sends a status inquiry request to Order Orchestration. If the order’s status in Order Orchestration is:

    • Canceled: Order Administration does not send a status update to Order Orchestration; otherwise,

    • If the order’s status in Order Orchestration is anything but Canceled, Order Administration sends a status update to Order Orchestration indicating the order was Rejected. In this situation, if Order Orchestration is configured to “reshop” the order and there are any other possible fulfilling locations, Order Orchestration reassigns the order to the next possible location based on the fulfillment rules set up in Order Orchestration, and the order returns to new order status; otherwise, if Order Orchestration cannot “reshop” the order, the order is assigned to the OROB Default Location Code for Unfulfillable Orders (K56), and the order status is unfulfillable.

    You cannot cancel a partial quantity of an order line on a retail pickup or delivery order.

    Note:

    Although Order Administration does not prevent you from canceling a retail pickup or delivery order, some business processes require that only the originating location can cancel an order. In this situation, if the customer contacts the call center to cancel the order, the operator notifies the originating store location and requests that the store perform the cancellation and trigger the status update to Order Orchestration. Using this process, Order Administration receives notification of the cancellation the next time it sends a periodic status inquiry on the order to Order Orchestration, and then holds the entire order (even if only one line was canceled) using the Order Broker Hold Reason (Cancel) (L02).

  • Voiding a pick slip for a retail pickup or delivery order: If the Cancel Reason (Pick In) (L86) system control value specifies a valid cancel reason or if a backorder cancellation reason code is specified in the CWPickIn XML Message, and you use the generic pick in API to void a pick slip for a retail pickup or delivery order, then Order Administration cancels the order and sends a status update to Order Orchestration to reject the order. Otherwise, if the system control value is blank, you need to use order maintenance to cancel the order and send the status update to Order Orchestration.

    For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

  • Rejecting the order: If you reject a batch that includes a retail pickup or delivery order, the BROKER process sends a status update rejecting the order; also, it deletes the related Order Orchestration and Order Orchestration History records.

Cancel reason sent? The status update message to reject a retail pickup or delivery order includes a cancel reason code and description if you:

  • cancel the order in order maintenance: the entered cancel reason is sent

  • void the pick slip: the Cancel Reason (Pick In) (L86) system control value is sent if a backorder cancellation reason code is not specified in the CWPickIn XML Message,

    For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

  • reject the batch that includes the retail pickup or delivery order: no cancel reason is sent

For more information: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for a sample of the information sent to Order Orchestration when you cancel a retail pickup or delivery order.


The figure shows a retail pickup or delivery order process flow.

Reviewing Retail Pickup (including Ship-for-Pickup) or Delivery Orders in Order Inquiry

In addition to reviewing information through the Working with Order Broker (WOBR) menu option, you can also use standard order inquiry. Your options include:

  • Finding the order number: Use the Order cross ref # at the Order Inquiry Scan Screen to find a retail pickup or delivery order based on the order number in the originating system. This number also displays as the Alt ord number at the Display Order Properties Screen. The system stores the originating order number in the E-Commerce order number field in the Order Header Extended table. If the originating system is Order Administration, the system prefaces the originating order number with the text ORIG#:. For example: ORIG#: 9999-001, where ORIG#: indicates the order originated in Order Administration, 9999 is the original order number in Order Administration, and 001 is the ship-to number.

    Note:

    To review all retail pickup and delivery orders whose originating system is Order Administration, you can enter ORIG#: in the Order cross ref # field and select OK to advance to the Scan by Order Cross Reference # screen where all orders whose E-Commerce order number in the Order Header Extended table begin with ORIG#: display.

  • Originating order message: If the E-Commerce order number in the Order Header Extended table begins with the text ORIG#:, indicating the originating system for a retail pickup or delivery order is Order Administration, the message This order is fulfilling another order: 9999-001 displays for the sourcing order, where 9999 is the originating order number in Order Administration, and 001 is the ship-to number. This message displays on the Order Inquiry Header screen (OIOM), Order Inquiry Detail screen (OIOM), and in Streamlined Order Inquiry (DORI) for the sourcing order.

  • Broker detail and history: Use the Display Order Broker Details Screen to review Order Orchestration Detail and Order Orchestration History, as well as other information such as the delivery type and the request ID.

  • Identifying the Order Orchestration type: In addition to the Display Order Broker Details Screen, you can also review the Broker delivery type at the Display Order Properties Screen and the Display Order Broker Details Screen to determine whether the order originated as a Retail Pickup or Delivery order.

  • Originating store, request ID, and special instructions: The originating store number and request ID are available for review at the Work with Order Messages Screen, for example:

    Originating Store: 317

    OROB Request ID: 70122

    Also, if any special instructions were passed for the order, this information is also available for review at this screen.

  • Order history: The Display Order History Screen displays activity related to sending status updates to and from Order Orchestration, such as:

    • Ln#: 1 Ready for Fulfillment: Written for each line received on a retail pickup or delivery order when the order is accepted and put into Open or Held status.

    • Ln#: 1 Selected for Fulfillment: Written for each line printed on a pick slip.

    • Ln#: 1 Fulfilled: Written for each delivery order line when you confirm shipment.

    • Ln#: 1 In Transit: Written for each retail pickup order line when you confirm shipment.

      Note:

      After you ship a retail pickup order, Order Administration checks for status updates on a daily basis, and writes a single Order Transaction History message for each status change until the order is fulfilled. See Setting the Daily Status Inquiry Time Window (all versions) for setup information.

    •  Ln#: 1 Store Received: Written after the originating store location has received a retail pickup order.

    • Ln#: 1 Customer Partial Pick Up: Written after the customer has picked up part of a retail pickup order.

    • Ln#: 1 Customer Picked Up: Written after the customer has picked up all units of a retail pickup order.

    • Ln#: 1 Cancel Acknowledged by Broker: Written when you cancel an order line in order maintenance or through Working with Backorders Pending Cancellation (WBPC).

    • Ln#: 1 Rejected for Fulfillment: Written when Order Administration rejects an order line because the item is soldout or backordered; if you reject the order when it is suspended; or when you sell out a line afterward in order maintenance or through Processing Auto Soldout Cancellations (MASO).

    • Order held - line[s] canceled in OROB: Written if Order Orchestration responds to a status inquiry indicating that any of the lines on the order were canceled. In this situation, Order Administration puts the order on hold using the Order Broker Hold Reason (Cancel) (L02).

Things to Note about Retail Pickup (including Ship-for-Pickup) and Delivery Orders

Both system control values required: You need to complete both the Type for Orders Brokered for Delivery (K91) and the Order Type for Retail Pickup Orders Brokered to OROMS (K92) system control values in order for Order Administration to request new orders from Order Orchestration, even if you do not process both order types.

In addition:

  • if the Use OROB for Fulfillment Assignment (M31) system control value is selected, you need to complete the Order Type for Delivery Orders Originating in OROMS (M33) system control value in order for Order Administration to assign the correct order type to delivery orders created as a result of the Brokered Backorders process assigning an Order Administration warehouse to fulfill a brokered backorder.

  • if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, you need to complete the Order Type for Retail Pickup Orders Originating in OROMS (M35) system control value in order for Order Administration to assign the correct order type to retail pickup orders created as a result of the Brokered Backorders process assigning an Order Administration warehouse to fulfill a brokered backorder on a ship-for-pickup order.

  • if the Send Inventory by Warehouse to OROB (L06) system control value is selected but the OROB location for a warehouse does not specify a valid location in Order Orchestration, the fulfillments request message is not generated.

Discounts: If the customer is eligible for a discount, such as one from a loyalty membership, Order Administration still applies the discount to a retail pickup or delivery order.’

Additional freight: If the ship via on the order is subject to additional freight charges, these charges are added to the order.

Gift flag: The setting of the Gift Flag for Orders Brokered to OROMS (L03) system control value overrides the setting of the gift flag passed in the fulfillments response message.

Outbound invoice message: If you generate the CWInvoiceOut message, the message is generated for retail pickup or delivery orders unless excluded based on trigger rules (for example, not including these order types).

Tax: The tax amount for each order detail line is passed as a tax override amount.

Customer matching: If the fulfillments response message from Order Orchestration does not specify a valid sold-to customer number, Order Administration uses its standard customer name and address matching to either select an existing customer or create a new customer.

Oracle Retail Customer Engagement customer integration: If you use the Customer Engagement Customer Integration, Order Administration may also new customer records in Oracle Retail Customer Engagement as part of creating retail pickup and delivery orders. See Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order for more information.

Order maintenance: The Maintain Brokered Fulfillment Orders (B20) secured feature controls the ability to maintain a retail pickup or delivery order. Even if you have authority under this secured feature, your ability to maintain the order is limited. For example, you cannot add or change an order line. See Maintaining Retail Pickup or Delivery Orders from the Order Orchestration for a discussion.

Creating the invoice for a ship-for-pickup order: The Invoice Ship For Pickup Order Once Intransit (M73) system control value controls whether to create the invoice for a ship-for-pickup order when Order Orchestration indicates that the order is now in transit or received. See that system control value for more information.

If the payment method expires: If the payment method for an order expires, the system sends an update to Order Orchestration indicating to put the order Under Review. Also, if a fulfilling retail pickup order was created for the originating order, the order goes on hold, and any open pick slips are canceled.

Processing returns: If the Suppress Returns for Retail Pickup/Delivery (L88) system control value is:

  • selected: You cannot process a return against a retail pickup or delivery order, or create a return authorization

  • unselected: You can process a return against a retail pickup or delivery order or create a return authorization; however, the Order Broker Payment Type (K98) is deactivated when you ship a retail pickup or delivery order. As a result, in order to process a return against the order, you need to add a new payment method.

Note:

Regardless of the setting of the Suppress Returns for Retail Pickup/Delivery (L88) system control value, you cannot process an exchange against a retail pickup or delivery order, enter an item with a negative quantity, enter a negative additional charge, or apply a discount to a shipped order line.

Order Administration does not send a status update to Order Orchestration when you process a return against a retail pickup or delivery order.

Membership items: You should not set up your Order Orchestration integration to include membership items on retail pickup or delivery orders, since the customer membership would not be created correctly in Order Administration. To prevent Order Administration from sending membership items to Order Orchestration as part of Order Orchestration’s Product, Product Location, and Incremental Inventory Import Process, do not flag them as OROB eligible.

Voiding or reprinting pick slips:

  • If you use Reprinting and Voiding Pick Slips (WVRP or WSVP) to void or reprint a pick slip for a retail pickup or delivery order, this activity does not produce a status update to Order Orchestration.

  • If you use the Generic Pick In API (Shipments, Voids, and Backorders) to void a pick slip for a retail pickup or delivery order and the Cancel Reason (Pick In) (L86) system control value specifies a cancel reason code, or if a backorder cancellation reason code is specified in the CWPickIn XML Message, Order Administration cancels the order using the specified cancel reason and sends a status update rejecting the order to Order Orchestration, including the cancel reason from the system control value.

    For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Important:

To prevent inconsistent updates to Order Orchestration for retail pickup and delivery orders:

  • Prevent Order Administration from generating multiple pick slips for a single retail pickup or delivery order:

    • Select the Ship Complete for Orders Brokered to OROMS (L01) system control value.

    • Do not create retail pickup or delivery orders for ship-alone items.

    • Do not select the Retain Backordered Lines Brokered to OROMS (K89) system control value.

  • Do not process void/unreserve transactions or partial backorders for these orders through the Generic Pick In API (Shipments, Voids, and Backorders); confirm or void the entire pick slip.

    For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Note:

Retail pickup and delivery orders that originate in Xstore include a single item.

Documents for store receiving: In order to support store receiving, you can generate the Pick Message from Order Administration (CWPickOut) or the PO Download XML Message (CWPurchaseOrderOut). Each of these messages includes details on the order, including the Order Orchestration request ID, the order number in the originating system, and the delivery type. See the Generic Pick Out API and the Generic Outbound Purchase Order API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.

For more information: See Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration.