Next as MP (Platform Plus)

The purpose of this scope is to detail the requirements for connection with Platform Plus (custom platform for connection with Next’s website as to a Marketplace)

Documentation from Platform Plus can be found as an attachment below:

Dorothy Perkins Non-stocked supplier integration v1.pdf

The integration we are targeting is the SFTP connection via XML feeds and includes the following sections:

Stock Specification - this specifies the method of communicating for Stock updates from Hemisphere to Platform Plus - an XML needs to be created with the following specifications

1. Naming convention: “INV-MM-DD-HHMMSS.xml”
2. File path: files should be posted to “/transfer/inventory” on the required SFTP
3. Fields specification:

Not sure the best place for this but we need to make it in the way to easily through setup manage multiple future brands | | StockFeedName | Alpha / numeric | Y | Next require a specific predominantly based on Brand. For the first brand named “Dorothy Perkins” they need value “DOROTHYPSTK” | It is good to be managed from the account / seller / account_seller. Not sure the best place for this but we need to make it in the way to easily through setup manage multiple future brands | | DateTimeStamp | Date / time | Y | Date and time of creation of the feed | Format YYYY-MM-DDTHH:MI:SS (example: 2020-06-18T09:00:01) |

3. Example XML:

<?xml version="1.0" encoding="UTF-8”?>

4. Frequency of the files: We need to be creating a file with frequency not faster than every 15 minutes. We still want to keep the Delta updates (only changed values) running on that time period. Once every 24 hours instead of a Delta feed we need to create a feed with current values of all non closed products we have

5. Triggers - Stock update needs to be sent the following three options:  1) If we have update_quantity = ‘pending' AND item_closed = 0 then send the Value in the Quantity field; 2) If we have end_item = 1 then send Quantity = 0. We don’t care for any other values in this case; 3) If it is time for the full stock update if we have item_closed = 0 then send the Value in the Quantity field

**NEW:** A validation for adding a product to the feed is to be made. The check is to ensure we have all needed information to add successfully a product to the feed. In case we can’t we are to set update_quantity to “error” and end_item to 0. When sending Stock feeds we are to pick any products as per the above criteria besides such that are on update_quantity = “error”. The only exclusion from this rule is products with end_item = 1. In ANY case where we have end_item = 1 we should try to send 0 quantity. Meaning it doesn’t matter if it is a full stock update or delta updates through out the day if the flag end_item is set to 1 regardless of status we should try to send quantity 0. In case it hits a validation error we should just threat it again as usual - set update_quantity to “error” and end_item = 0

We don’t have any feedback for the read of the feed so the successful creation of the feed on the end SFTP is to be treated as successful operation meaning ‘pending’ flags are to be pushed to 'normal' or end_item flag to be set to 0

Order Specification - this specifies the method of communication of orders form Next’s platform to us

1. Naming convention: “Orders.xml” where the is the unique reference number provided by Next’s system Each order should be coming in a separate file
2. File path: files should be consumed from “/transfer/orders” on the required SFTP Once the orders are consumed the files should be moved to “/transfer/archive” on the same SFTP
3. Fields specification:

Note: As EAN currently is not Unique field we need to validate and in case there are multiple EANs SKU should be empty and an error should be stored on the order | order_item.item_sku | | Quantity | Numeric | Y | Expectation is this will be always “1” | order_item.item_quantity | | PromiseDate | Date / time | Y | The promised date by Next to the end buyer by which this order is to be delivered | N/A | | OrderExternalRef | Alpha / numeric | N | Marketplace order ID used by next for orders that are not handled by their warehouse | orders.sm_sales_rec_num | | Destination | Alpha / numeric | N | Where is expected for this order to be delivered as Next DC | At this point N/A | | DateTimeStamp | Date / time | Y | When the order was placed | orders.order_created_time |

3. Example XML:

<?xml version="1.0" encoding="UTF-8”?>

4. Frequency of the files: upon creation in Next systems. We should be polling for new orders every 5 or 10 minutes

5. Triggers - N/A

Additionally if the order has been successfully mapped for the above field we need to set it as “waiting_for_delivery”, calculate a total if possible (by getting the Price from the designated item_accounts) or set 0 if not possible, set Currency to GBP, set shipping_country_code to “UK”

Order Acknowledgement Specification - literally just providing acknowledgement we’ve received the order as expected

1. Naming convention: “OrderACK--.xml” where the ID is the provided unique ID reference from Next systems (orders.marketplace_order_id) Each order should be in a separate file
2. File path: files should be posted to “/transfer/acknowledgements” on the required SFTP
3. Fields specification:

3. Example XML:

<?xml version="1.0" encoding="UTF-8”?>

4. Frequency of the files - whenever an order has been received successfully. Can be running and checking every 5/10 minutes

5. Triggers - Whenever we have an order on Ready for shipping that has order_items, has corresponding order_item_lines, order_item_line.status = ‘' and both order_item.item_sku and order_item_line.mp_order_item_id have values it should be exported for acknowledgement. Upon successful export of an acknowledgement file we are to set the order_item_line.status = 'acknowledged’

(v1.1)Order Ship Status Specification - this specifies the method of post acknowledgement update to the Next system (Shipment). Status update is final, once a status update has been pushed with one or the other to Platform Plus a consecutive status update should not be sent

1. Naming convention: “OrderStatus--.xml” where is the unique reference ID provided by Next systems (orders.marketplace_order_id) and is the date of creation of the file in the format YYYY-MM-DD-MIHH (example: “2020-06-18-0900”)
2. File path: files should be posted to “/transfer/shipping” on the required SFTP
3. Fields specification:

ISO 8601 Format : YYYY-MM-DDThh:mm:ss | Orders > Order Created Time |

3. Example XML:

<?xml version="1.0" encoding="UTF-8”?>

4. Frequency of the files - whenever an order has been prepared for update. Can be running and checking every 5/10 minutes

5. Triggers - an order that has (update_shipping_pending = 1 and tool_status = ‘waiting_for_delivery' and order_item_line.status = ‘acknowledged'). Once we’ve determined we need to send an update we need to use the following:

Send a “Dispatched” update to Platform Plus.

Once we’ve successfully sent a Status update to Platform Plus we are to update the order to remove the update_shipping_pending flag (set it to 0), update the order_item_line.status field with the actual status we sent in the file (“Dispatched”) and update the tool_status.

(v1.1)Order cancellation specification - this specifies the method of post acknowledgement update to the Next system (Cancellation). Status update is final, once a status update has been pushed with one or the other to Platform Plus a consecutive status update should not be sent

1. Naming convention: “OrderStatus--.xml” where is the unique reference ID provided by Next systems (Order > Marketplace Order ID) and is the date of creation of the file in the format YYYY-MM-DD-MIHH (example: “2020-06-18-0900”)
2. File path: files should be posted to “/transfer/shipping” on the required SFTP
3. Mapping:

ISO 8601 Format : YYYY-MM-DDThh:mm:ss | Orders > Order Created Time | |

 Example XML:

<?xml version="1.0" encoding="UTF-8”?>

5. Frequency of the files - whenever an order has been prepared for update. Can be running and checking every 5/10 minutes

6. Triggers : as per our abstraction for preShipment refund , can be found [Refunds send general logic](https://www.notion.so/Refunds-send-general-logic-d643578dd9364d4faea0198cab5aa38e?pvs=21).

7. Validations: Once we’ve selected the refunds we want to make a check if Order Item Line > Status for all item lines participating are on an “acknowledged” status. If not, this means some one is trying to make an update to a line that is already Shipped or Dispatched and we want this to block the refund, setting it on Error and storing an Order Error with the message “Order item line for refund row line {{ID}} needs to be on status ”acknowledged”“ (**v1.3**)

Once we’ve determined we need to send an update we need to use the following:

Send a “Cancelled” status update for any of the ItemIDs in the refund rows.

If we fail to upload the file on the FTP we should :

1. Put the status of the Order Payment on “error”
2. Store a message with type “Refund” and severity “Error” in the table Order Error with the corresponding message too