Ship to Store Process

The Ship to store (STS) functionality allows clients to optimize their inventory across different sources for in store pick up (ISPU) orders. The ability to move stock from one source to another enables clients to manage orders with out-of-stock products at the collection point and request a source to ship them to the destination source for customer collection.

STS process

This diagram illustrates the basic STS process

STS process

The STS process, in which orders are imported into the system, occurs in three major steps—Processes A to C.

• Process A:
  • Source engine define who will play the Source A role
  • Shipment request is generated to Source A
  • Complete pick, pack, ship process
• Process B:
  • Source engine allocate items to Source B
  • Shipment request is generated to Source B with details of items “Pending Arrival”
• Process C:
  • Receive items from Source A
  • Complete pick, pack, ship process of full order

STS fulfillment flow

SFS flow (ISI) *

ISPU flow (ISI) **

Inventory implications

STS stock movements are tracked at the order line level to identify if an item is in progress for a source or is in transit (see flow above). Inventory will be updated to ensure there are no synchronization issues when integrating with other systems.

This diagram shows how the stock will be updated based on the store actions on each source:

STS inventory flow

SFS flow (Source A) *

ISPU flow (Source B) **

To synchronize stock with other systems they must integrate with the shipment message (customer_shipment_done) to identify when an item has been shipped/collected from a source. The shipping method will identify if the shipment is a SHIPTOSTORE shipment, which means that the items have been transferred to another source.

The line_confirmed message will be triggered once a line has been accepted/confirmed within a source, and it will allow other systems to update stock accordingly.

Configuration

In order to have STS active you must add following configurations:

Key values

To identify different entities and events within the STS process there are a set of key values used on different messages as follows:

Key Value	Message	Description	Sample
Pickup Location	magento.sales.order_management.create	The pickup_location field indicates where the customer is expecting to collect his order. It must be defined for each line of the order. If the shipping method of the order is ISPU and the pickup_location is missing the order won’t be imported in OMS.
Force Source Location (optional)	magento.sales.order_management.create	With the order creation is possible to pre-define the source location that will be providing the stock to the final pickup location. The source engine will force the sourcing to this specific source and will ignore other available options.
Shipping method	logistics.warehouse_management.request_shipment	The shipping method identifies how the products are expected to be shipped, and in this case it will be SHIPTOSTORE to highlight that is an internal movement of products between two sources.
Address type	logistics.warehouse_management.request_shipment	The address type is used to identify that the address where the shipment will be done is another source not the customer address.
Method	logistics.fulfillment_management.customer_shipment_done	The method identifies how the products have been shipped, on this case it will be SHIPTOSTORE to highlight that it was an internal movement of products between two sources, not a shipment to the customer.

Orders will be sourced only to sources that have the capability defined to ship stock to another source.

To configure such capability use the following field from the magento.inventory.source_management.update spec (see the Specifications section for more details.):

"capabilities": {
        "fulfillment": {
          "can_ship_to_source": "boolean"
        }
      }
....

Or, you can accomplish this directly in the OMS Admin in the Source view: