Tesco Integration Phase 1 Scope

Purpose

The purpose of this document is to describe the specifics in the Phase 1 integration between the Hemisphere software and the Tesco marketplace. The purpose of the integration is to enable sellers using Hemisphere to expand their online activities and to offer their products for sale on the Tesco marketplace. The phased approach is due to aiming for finalising the integration in a stable and robust way that will provide the Pentagon Managed Services clients access to the Tesco platform with all necessary methods and workflows to be able to properly expand and offer their products. Phase 2 of this project is yet to be finalised as a scope but will be  more focused towards a standalone model for the software to be offered including Tesco Account management specifications and requirements

The document is split into two sections:

1)      Hemisphere workflows

2)      Tesco API methods and specifications

Hemisphere workflows

Every flow below is explained as viewed by Hemisphere and how this resonates with the Tesco integration. Every flow has every step that it takes with the Tesco API in sequential order as subpoints

1)       Product Create/Update – this is a standard flow in the Hemisphere software that provides the experience of one button listing to the Marketplace. This logic is also applied in the development of the Tesco marketplace integration. Internal Hemisphere statuses will be used to mark validation of different flows. In the case of a Product Update, the whole cycle of points b,c,d,e below is executed

1. Product Listing – Hemisphere is to try a listing step initially when a new product is to be pushed to Tesco. This is required so additional steps of Induction and Image sending can be skipped in the case of the product already existing on the Tesco marketplace and move directly to Update Stock
2. Product Induction – In the case of product not available on the Tesco marketplace or an already created product needing content update, a Product Induction is to be sent. Product information from Hemisphere is to be validated against the category relevant XML Schema before sending information to the Tesco marketplace
3. Image Upload – After a successful product induction Images are to be sent to the Tesco marketplace
4. Product Listing – After a successful Images upload a new Listing flow is to be initiated
5. Inventory Update – On Listing Success, Quantity Update is to be sent for relevant products

2)      Update Stock – using the standard dynamic recalculation - factoring in warehouse quantity, open orders, stock rules and thresholds – Hemisphere is to ensure the most up to date stock availability is sent to the marketplace

1. Inventory Update – For every product listed successfully on the Tesco marketplace stock changes are to be tracked in Hemisphere and sent accordingly to the quota availability, using the Inventory Update call

3)       Update Price – using the standard price update functionality in Hemisphere tracking for changes and pushing them to the marketplace

1. Product Listing – For every product listed successfully on the Tesco marketplace price changes are to be tracked in Hemisphere and sent accordingly

4)      End Listing – using the standard functionality of Hemisphere to zero out products

1. Inventory Update & Product Listing – every product marked for delisting is to be sent with a zero-stock Inventory Update (no matter the currently available quantity) and sequentially a Suspension is to be sent in a Product Listing call

5)       Get Orders – as standard, Hemisphere is capturing all orders in specific timeframe, using slight overlapping to ensure nothing is missed. If available from the marketplace, Hemisphere always uses a last updated date to capture any changes that might occur on orders from the marketplace (example: manual update on the marketplace, marketplace order cancelling, etc.)

1. Retrieve Orders – Hemisphere is to download all newly released orders from Tesco on regular, slightly overlapping intervals, to ensure no Order is to be missed

6)      Accept Orders – the standard “accept” flow in Hemisphere, when a Marketplace requires this function, is a twostep verification. For orders automatically cleared for fulfilment we send the acknowledgement. For orders not cleared for fulfilment (insufficient stock), an accept/reject option is allowed. Depending on marketplace requirements this is customisable but the flow in Hemisphere is the same

1. Acknowledge Orders – As agreed with Tesco, Hemisphere is to Acknowledge all successfully downloaded orders (successful order is based on required fields data validation that is standard check for the Hemisphere software)

7)       Ship Orders – using Hemisphere standard shipping update and tracking capturing information

1. Shipment Update – Send ready for shipping orders to Tesco with the required tracking information

8)      Cancel / Refund Orders – Hemisphere has a standard Cancel / Refund functionality in which required SKUs from selected order are passed for cancellation or refund.

1. Cancel Orders – Tesco MP is to have a pre-shipment cancellation. In the case of receiving a cancellation request, the order status will be checked. If order is not shipped, a Cancel call is to be sent for the selected SKU using one of the Tesco’s Cancel reasons
2. Return / Refund orders – In the case of having a Return/Refund request for an order, the order status will be checked. If the order is shipped, a Refund call is to be sent for the selected SKU using one of the Tesco’s Refund reasons

Notes:

• Every Hemisphere flow has its own data validations and errors based on required fields, missing information, SEO requirements etc.
• Every outbound Hemisphere feed is to track quota availability based on Tesco API restrictions described in Tesco API documentation point 2.12

Tesco API methods and specifications

****This section contains every Tesco API method to be used in the integration with spec notes and agreements Hemisphere team has to have in mind while working on the development

1)       Product Induct

1. Variation Parents present as a concept – non-sellable product that holds the generic information for the listing besides variant specific information
2. Both Variation Parent and Variation Child products are taken in consideration for the restrictions numbers quota
3. When listing/updating a Parent SKU a Child should always be present as well
4. Verification against XML Schemas based on relevant categories
5. XML Schemas are rarely changed – if any changes are to be made this is communicated from Tesco in advance

2)      Image upload

1. Images can be added on every SKU level (Single, Variant Parent, Variant Child)
2. Concept of Main image and Alternative Images almost the same as in Hemisphere
3. Format: ‘jpg’ or ‘png’
4. Updating Alternative images will only add new ones, removing Alternative images needs Tesco Account management assistance

3)       Product Listing

1. To include ‘Fulfillment Types’ (predefined shipping methods/templates in the Tesco account) and ‘Time to Dispatch’ days
2. Listings work with Start and End dates (for initial testing future start dates are required)

4)      Inventory Update

1. Straight forward – requires SKU and Qty on hand

5)       Retrieve Orders

1. Tesco releases only completed, paid orders
2. Orders can be retrieved by start/end dates and status
3. Acknowledged orders will be dropped from the list

6)      Acknowledge Orders

1. Acknowledge
   1. Simple acknowledgement of successful downloading of the order
   2. Is done on order line level
2. Reject
   1. Simple rejection of downloaded order
   2. Is done on order line level
   3. Requires reason – Tesco enumeration value

7)       Shipment Update

1. One shipping per order in a file
2. Tracking not required for Home Delivery option

8)      Returns Refund Orders

1. Only one refund per order is allowed at the moment. Sequential refunds are to be performed by TAM
2. For multiple qty return repeat ReturnLines / For multiple products repeat the whole Return element
3. Requires reason – Tesco enumeration value