Radial Integration | 2016
This page covers the implementation guidelines and illustrations necessary to implement and use the Ship-to-Store (STS) and In-Store Pickup (ISPU) product offering of Radial. Although the technical guidelines are the same for all partners, certain parameters will vary among partners. You should implement prior settings from Radial before starting the testing phase.
The Ship-To-Store fulfillment feature is an offering that fulfills an item from a warehouse or other store and delivers it to a store location specified in the order information. The implementation differs from a regular Ship-to-Home workflow in that it has additional events that connect the Order Management System with the Store Fulfillment system. These events track the progress of fulfillment from creation to fulfilled status. To harness all the features provided, you must implement the following steps while building the order message.
This implementation exposes the Schema that gathers the Storefront Location information at Order Line level. This ensures that the store information is captured on the line in OMS. Following is the X-Path and sequence, after which a set of given tags needs to be implemented.
OrderCreateRequest -> Order -> OrderItems -> OrderItem -> (Insert after the ShippingMethod tag.)
Ensure that you send all the following tags at the preceding X-path. Be sure to remove the StoreEmail tag in this sequence. (This tag is removed based on the Fraud team’s guidelines, which state that unless an order delivers an e-gift card, the address should not have any email address.)
<StoreFrontDetails> <StoreFrontLocation> <StoreCode>2032</StoreCode> <StoreName>SHOE CARNIVAL STORE KING OF PRUSSIA</StoreName><StoreEmail>gnaz@scvl.com</StoreEmail><Address> <Line1>160 N GULPH RD</Line1> <Line2>SUITE 1309</Line2> <City>KING OF PRUSSIA</City> <MainDivision>PA</MainDivision> <CountryCode>US</CountryCode> <PostalCode>19406</PostalCode> </Address> </StoreFrontLocation> </StoreFrontDetails>
The next step is to send the store information at the destination level. Supplying the Store information at the shipping level ensures that this order is a Ship-to-Store implementation. The destination level holds a set of addresses and, based on the references provided, the underlying system maps to any set of addresses given. Therefore, be sure to supply the store location at this level.
OrderCreateRequest -> Order ->Shipping -> Destinations -> (Insert after MailingAddress tags.)
Be sure to send all the following tags at the preceding X-path. In addition, remove the StoreEmail tag in this sequence. (This tag is removed based on the Fraud team’s guidelines, which state that unless an order delivers an e-gift card, the address should not have any email address.)
<StoreLocation id=”address_2032”> <StoreCode>2032</StoreCode> <StoreName>SHOE CARNIVAL STORE KING OF PRUSSIA</StoreName><StoreEmail>gnaz@sapient.com</StoreEmail><Address> <Line1160 N GULPH RD </Line1> <Line2> SUITE 1309</Line2> <Line3> - Optional <City>KING OF PRUSSIA</City> <MainDivision>PA</MainDivision> <CountryCode>US</CountryCode> <PostalCode>19406</PostalCode> </Address> <Phone>1234567890</Phone> </StoreLocation>
Do not send StoreEmail if it is the same across all stores. A redundant value in this tag across many orders will trigger fraud lag during Fraud validation, causing the orders to get stuck and requiring manual intervention to release them.
While this step is not a part of a Ship-to-Store or ISPU implementation, the Order API can handle multiple fulfillment types in the same order. To take advantage of this ability, the following illustration shows how to add a Ship-To- Home destination address to a Ship-to-Store or ISPU order.
OrderCreateRequest -> Order ->Shipping -> Destinations MailingAddress (This mailing address should be the first mailing address tag in the Destinations set.)
<MailingAddress id="dest_1"> <PersonName> <LastName>Kumar</LastName> <FirstName>Amit</FirstName> </PersonName> <Address> <Line1>630 Allendale Rd </Line1> <Line2>Suite 1309</Line2> <City>King of Prussia</City> <MainDivision>PA</MainDivision> <CountryCode>US</CountryCode> <PostalCode>19406</PostalCode> </Address> <Phone>5554441212</Phone> </MailingAddress>
If a Ship-to-Store or ISPU order has no Ship-to-Home requirements, you can skip this child element.
In this step, you refer the mailing address elements that you issued in the preceding steps to a Ship Group. The shipping group is a match between a list of item ID references and a Destination address. Understanding this structure is crucial in submitting an order with multiple Fulfillment types.
OrderCreateRequest->Order->Shipping->ShipGroups ->ShipGroup->DestinationTarget@ref
<DestinationTarget ref="address_2032"/>
<ShipGroups> <ShipGroup chargeType="FLATRATE" id="shipGroup_1"> <DestinationTarget ref="address_2029"/> <OrderItems> <Item ref="item_1"/> </OrderItems> </ShipGroup> </ShipGroups>
Ref attribute should be mapped to the id attribute of StoreLocation or MailingAddress id attribute.
The preceding reference means that the item that is tagged under this Ship Group will be mailed to the referred destination address.
The Item ref attribute illustrated in the preceding table maps to the item line ID attribute in an Order Create API. In this way, you can map selective line items to a destination address. The Shipping method at line level provides the needed service and carrier information to the fulfilling system.
If the Webstore supports Proxy pick up for a Ship-to-Store or ISPU order, you can collect the Proxy information and send it to Warehouse and Fraud net at Radial. You only need to implement this optional step if the Webstore provides a form to collect Proxy information.
OrderCreateRequest -> Order -> OrderItems -> OrderItem -> (Insert after StoreFrontDetails from Step 1.)
<ProxyPickupDetails> <PersonName>Proxy Person Name</PersonName> <FirstName>First</FirstName> <LastName>Last</LastName> <Email>proxyemail@example.com</Email> <Phone>555-555-1234</Phone> <Address> <Line1>935 1st Ave</Line1> <City>King of Prussia</City> <MainDivision>PA</MainDivision> <CountryCode>US</CountryCode> <PostalCode>19460</PostalCode> </Address> <Relationship>Sibling</Relationship> </ProxyPickupDetails>
Note: If the Webstore does not support Proxy pick up, you can ignore this step.
The email should be the email address of proxy who will pick the order up from store. Gather the relationship of the person in the Relationship element.
Partners normally choose to send an identifier along with order data, which is then broadcasted back to the downstream feeds. In this way, they can reconcile a POS file across each of the fulfillment types in a systemic way. If you choose to provide an identifier, implement the following functionality as a part of order submission workflow.
OrderCreateRequest -> Order -> CustomAttributes (Insert after the DashboardRepId element.)
<CustomAttributes <Attribute> <Key>OrderType</Key> <Value>Ship_To_Store</Value> </Attribute> </CustomAttributes>
This optional element is used as a pass-through function. Anything sent is sent back to the partner in the artifacts. If you use this element, be sure to confirm the string that needs to go in the Key and Value pair with the partner.
Note: The data provided here is for illustration purposes only.
Most of the Fulfillment offerings are distinguished with unique a shipping method, which can change based on the business requirements. The following illustration is a theoretical example; the actual Shipping Methods would be created and handed over once the configurations are made in the downstream Order Management System.
OrderCreateRequest -> Order -> OrderItems -> OrderItem -> ShippingMethod
As a part of a Ship-to-Store implementation, Store Fulfillment expects a Pickup SLA from the Webstore. To supply this information back to the Store Fulfillment system, you must send the Pickup SLA information along with the order submission information. Because a partner can choose to send an order with multiple fulfillment types, the Radial API has extended attributes both at the line level and order level. Assuming that an order can support multiple fulfillment types (for example, ship to a home, Ship-to-Store, or In-Store Pickup), Radial recommends supplying the Pickup SLA at the line level in the order data. If the partner is certain that all lines in an order will be shipped to a store, you can choose to supply this information at the order level. You should then confirm the level chosen with the Store Fulfillment team for your implementation.
The following elements should be added to an order data either at line level or at order level, based on your business requirement.
<CustomAttributes <Attribute> <Key>PickupDate</Key> <Value>20160510</Value> </Attribute> <Attribute> <Key>PickupTime</Key> <Value>101500</Value> </Attribute> </CustomAttributes>
The data should be supplied by the integrating Webstore. The Key shown here was provided by the Store Fulfillment team. The Key and Value format should be resolved before populating these fields. The Radial Order Management System broadcasts this data AS-IS to the Store Fulfillment system. The Key and Value orchestration should be agreed upon between Store Fulfillment and the partners.
If a partner chooses to send different fulfillment types in the same order, be sure to specify each order line fulfillment type. This keyword is a driving factor in identifying fulfilment types once they enter the Order Management System. Supply the information AS-IS along with order lines as a part of the Ship-to-Store and ISPU implementation.
OrderCreateRequest ->Order -> OrderItems -> OrderItem ->FulfillmentChannel (Insert after StoreFrontDetails.)
Add the following elements to an order data at line as stated in the X-path.
<FulfillmentChannel>SHIP_TO_STORE</FulfillmentChannel>
Valid values are:
The linked file sts-ispu-order-illustration.xml contains a sample Order Create API structure that illustrates this Fulfillment type. The order has all the three fulfillment types enabled. Wherever possible, the annotations provide explanations.
This implementation document provides a hands-on illustration on how to create order submission data. All of the illustrated steps may not be applicable to all partners; therefore, ensure that you understand the requirements before starting the design phase.
Copyright © 2017 Radial. All rights reserved.