Status Updates

This document will cover both sections - Very to Supplier and Supplier to Very

Very to Supplier

Post order creation we are expecting to receive order status updates connected with cancellations from Very. Those can be the following:

Field Names and Specifics

“R” = Reselect Tag may also be blank or not present. See * below. | Order Claim > Type (Cancel) | In case we are creating a claim | | Guaranteed Request | X(1) | /STATUSES/STATUS/GUARANTEED | “N” or “Y”. See * below. (This field is only sent in files where Cancel / Reselect Indicator = “C”) | Order Claim > Marketplace Reason | In case we are creating a claim | | Status | 9(4) | /STATUSES/STATUS/STATUSCODE | See values below | N/A | | | Supplier Code | A999 | /STATUSES/STATUS/ORDER/SUPPLIER/BUYERREFERENCE | | N/A | | | Order Number | X(8) | /STATUSES/STATUS/ORDER/ORDERNUMBER | | Order Claim > Marketplace ID | In case we are creating a claim | | Order Date | YYYY-MM-DDThh:mm:ss | /STATUSES/STATUS/ORDER/ORDERDATE | | N/A | | | Status Date | YYYY-MM-DDThh:mm:ss | /STATUSES/STATUS/DATE | | Order Claim > Marketplace Date | In case we are creating a claim | | Status Time | hhmmss | /STATUSES/STATUS/TIME | Tag may also be blank or not present. See below. | N/A | |

• If we have blank fields (especially for “/STATUSES/REVISIONNO“) we should treat the request like we’ve received it with value “C” - in other words just create the request and set the Type to “cancel”

Example XML:

Actions:

1. In case of status code 16 we need to create a new claim. This claim needs to:
   1. Map the above mentioned fields and also set:
      1. Initiated by = Marketplace
      2. Marketplace status = pending - to be able to track what will be the outcome of this Claim
   2. Map the claim rows for the corresponding Order ID associated products
   3. Create on Account Very a section that allows for automatic decision making. Based on a selected value it should store a value in Action and potentially Status to automate the Acceptance or Rejection. Values and action from the in Account Very
      1. Empty value (Default) - manual processing of claims, nothing to store
      2. Accept - automatically put Action to “Accept” and Status to Pending to accept the marketplace claim
      3. Reject - automatically put Action to “Reject” and Status to Pending to reject the marketplace claim
   4. Last but not least we need to do some validations:
      1. If a claim already exists for the same order ID and Order Error should be stored
      2. If a Cancellation Request is being made for an order that is Cancelled an Order Error should be stored
2. In case of status code 17 we need to update an existing claim that is still pending/sent or in case there is no claim create new claim with all mapped fields plus Initiated by = Marketplace, Marketplace Status = completed and Status = completed. Furthermore every order_item_line affected should receive an mp_status “cancelled” update to identify that those have been affected Last but not least in case of storing a new completed claim or marking a claim we’ve initiated as Accepted we should also create an order payment record + refund rows or update an existing one that has originally created the claim by us.
   1. In case we are creating a new claim, not existing in the DB we need to create an order payment with:
      1. Payment date - same as claim Marketplace date
      2. Transaction ID - same as claim Marketplace ID
      3. Total - the total value of the affected products (count quantity as well)
      4. Type - refund
      5. Status - completed
      6. Refund type - partial
      7. Refund note - Claim ID: (text included)
      8. Refund Rows for each SKU with its value
   2. In case we are updating an existing claim as Accepted by the MP we need to update the status of the refund based on a connection (either via the Refund note where we should store the Claim ID or a proposed by Devs method)
3. In case of status code 14 we need to update an existing claim that it has been rejected, complete it, fill the marketplace date as per the mapping above and close it off. Additionally we need to go to the originating payment record and update the refund to error (and set payment date to be same as marketplace date on the claim) as realistically it has not been processed on the MP (see right above for connection options to payment record)

File Name and Limitations:

1. File name from Very is to be in the following naming convention: “nnnn.stupd.mmddyy.” where ‘nnnn’ is the 4 alphanumeric supplier code, mmddyy is the month day and year the transaction was produced and is an incrementing number for each file type per day
2. No specific file limitations are to be considered

<v1.6> Note: Expectation as per conversations and documentation is that files will be XMLs or with no extension at all so we should aim at working with files that are either .xml or with no extension. </v1.6>

Supplier to Very

Once we’ve stored the order in our system we need to track its progress via status updates. The updates we can send are the following:

Field names and Specifics:

Example XML:

Actions:

1. Acknowledgement - every order that we successfully record in our system we should automatically acknowledge back to Very. This, if successfully creates a file, should also put the order_item_line marketplace_status fields to “acknowledged” so we can have a proper traceability. As per the orders download documents every recorded order should be on a Ready for Shipping status with said marketplace_status filed on “pending”. This should also be the queue for this function to send its status update
2. Dispatch - every order in Hemisphere that is marked with update_shipping_pending we should try and send a dispatch status update to Very. As there are the options for multiple orders in one Hemisphere order we should track what is still “acknowledged” and if there is anything that is “cancelled” and send a “dispatch” status update only for the “acknowledged” orders. Once a file has been successfully produced the order tool status should be moved to Dispatched as well.
3. Request Cancellation - When someone creates a Refund for an order the following steps should be made
   1. If the refund is NOT for a full order it should be marked as Error with the corresponding message
   2. If the refund is for something that is already dispatched or cancelled it should be marked as Error with the corresponding message
   3. If there is no reason the refund should be marked as Error with the corresponding message
   4. If the refund is passing validations a new Claim record should be stored with the following parameters:
      1. Marketplace Date - empty, to be filled in when reading the Request response (please see “Very to Supplier > Actions > In case of status 17 code OR In case of status 14”)
      2. Type - Cancel
      3. Initiated by - Seller
      4. Status - pending (so it can be picked and sent)
      5. Marketplace ID - Order ID (the more specific one that we are storing on order_item level in case it is a multi order)
      6. Action Reason - Out of Stock or Other based on the refund reason
      7. Store all needed Claim rows with their respective order_line_ids
      8. Once a claim is successfully created we need to store its ID (for future reference) in Refund Note and mark the Refund as Sent
4. Accept / Reject Cancellation - On a claim that is created as pending from the marketplace based on a taken action - Accept or Reject - we need to send the corresponding status update to Very
   1. <v1.7>If the claim is accepted, we need to create a refund row as well, containing the products that we are accepting the cancellation for. As we don’t have a response from Blujay on this flow we treat it as “Successfully Accepted” at the moment of successfully finishing the flow on our end (exporting and storing the file on the designated Blujay integration ftp). Same should be treated as for the Reject step too - if successfully exported we should treat it as done and follow the final steps for the claim as “completed” communication flow</v1.7>

File name and Limitations:

1. The only thing specific for the naming convention is that every file needs to be unique. Proposed naming is “OSU_toVery{timestamp}.xml“
2. File limit is set to 500kb which allows around 1500 Status Updates at a time. Proposed Limit is 1200 on our side
3. An order ID must be present only once in a file. Meaning we should not be sending multiple different statuses for an order at a time. Based on our logic we are not expecting any such to happen still a validation will be good
4. Again if a status for Acknowledgement or Despatch needs to be sent only one of the OrderIDs in that MO should be enough. Very will treat all associated orders with the same status. Cancel updates are to be on an order by order basis even within the MO