Marketplaces / Myer / Myer Outbound (POA, ASN, INV)

Myer Outbound (POA, ASN, INV)

The purpose of this document is to detail the 3 Outbound flows with Myer through IPT systems, specify their file mappings and cases when we need to provide them and what to do when unsuccessful

POA

The POA (Purchase Order Acceptance) is a standard flow in any EDI communication which refers to a confirmation or “acceptance” of a placed (requested) order from a buyer to the seller. Through POAs we can accept or reject orders or quantities within an order. Our flow will go the following way:

  1. Acceptance - once we have a successfully created order in Hemisphere we want to automatically send an Acceptance POA to the FTP for all available items. To send the POA the order has to be in Ready for Shipping status and it shouldn’t be accepted so far (Once an order is accepted it can be set to “marketplace_status” = “accepted” as well to help with the check) - Acceptance should be sent for all lines that are as “created” status
  2. Rejection - if an order is still not “Shipped” and someone has recorder a refund for a full qty of a product we should send a follow up Rejection POA to the FTP. If the refund is not for a full price of a product quantity we should set it to error (Note: I will add the rejection example later this week, expectation is it is the same as the accept but with specifying “rejected” quantity). To send the POA the order needs to be in Ready for Shipping or Incompleted status and the line we are trying to reject should be in a “created” or “accepted” status

Example file:

{
  "order_number": "CC4500624308D000",
  "response_type": "POA",
  "items_purchased": [
    {
      "barcode": "5025155041406",
      "accepted_qty": 1
    }
  ]
}

Mapping:

Field Name WAP Mapping WAP Notes
order_number Orders > Marketplace Order ID
response_type “POA” Hardcoded
items_purchased N/A Products specific section
barcode Order Item > ChannelItemID
accepted_qty Order Item > Item Quantity

Once we’ve successfully created the POA on the IPT FTP we should update the status on the order_item_lines with “accepted” or “rejected” based on the type of POA we’ve sent

In case of unsuccessful creation on the FTP we should write an error on the order. If it is due to us unsuccessfully creating the file we should just write a POA error and stop any tries. If it is connectivity to the FTP we should retry for the next X hours when running the script to allow for any connectivity issues to be removed and then stop retrying. X should be determined from the config of the integration

Note: if it is a “rejection” POA all that communication should be stored on the payment record

If we have all order_item_lines on rejected we should set the order as Cancelled (again - rejection can occur only for products that are still not “dispatched”)

ASN

The ASN (Advance Shipment Notification) is another standard EDI communication that we are translating through JSON files. It is essentially just a shipping update. In EDI communication as it is developed as a much more warehouse oriented flow there are capabilities to specify pallets, cartons etc. In our case as we are shipping orders one by one any such is always the same

An ASN file should be produced once we have update_shipping = 1 and should include all products that are on an “accepted” status. In case there are no such products an error should be added to the update_shipping_error field as a “ASN” error. This way if there has been a POA error from before it won’t be lost and those will be properly differentiated - after changing the error field may be this is deprecated?

Example file:

{
  "order_number": "CC4500624308D000",
  "response_type": "ASN",
  "carrier": "AUSPOST",
  "tracking_number": "2FC6053806",
  "tracking_url": "https://auspost.com.au/mypost/track/#/search",
  "items_purchased": [
    {
      "barcode": "5025155041406",
      "shipped_qty": 1,
      "carton_id": 1
    }
  ]
}

Mapping:

Field Name WAP Mapping WAP Notes
order_number Orders > Marketplace Order ID
response_type “ASN” Hardcoded
carrier Orders > Shipping Carrier
tracking_number Orders > Shipping Track Num
tracking_url Orders > Shipping Tracking URL

OR

Courier > Courier URL | If there is no URL provided in the order itself we are to map via the name of the courier to an existing Courier in Hemisphere and take the URL from there. Additional is that we can have mapping in the courier url - {ShippingTrackingNumber} if we get it from courier table. | | items_purchased | | N/A | Products specific section | | | barcode | Order Item > ChannelItemId | | | | shipped_qty | Order Item Lines - number of “accepted” lines | This will need to be calculated based on the “accepted” lines per product instead of being directly picked from the Order Item > Item Quantity field | | | carton_id | “1” | Hardcoded |

Once we have successfully created an ASN on the FTP we should put all “accepted” lines to “dispatched” and remove the shipping flag and update tool status to dispatched.

In case of an unsuccessful creation to the FTP we should store the relevant error. If it is connectivity to the FTP we should retry for the next X hours when running the script to allow for any connectivity issues to be removed and then stop retrying (remove the shipping flag). X should be determined from the config of the integration

INV

The INV communication is a very clean and minimised form of Stock update that we need to provide to Myer via the IPT FTP translation. We are not required to do any recons or anything specific, meaning we send a stock update only when there is a trigger. Triggers for this communication should be the standard Stock updates as per any MP integration:

  1. update_quantity = pending - Should simply pick what is calculated in the Quantity field. Should not work if the item is closed. We want standard flow - once we pick it we set it to sent, if successfully created on the FTP set it to normal, if not - error. There are no retries for the stock
  2. end_item - In the case of end item we want to send 0. It should work all the times and if there is this flagged raised we should overpower whatever else is to happen with the inventory and send quantity update of 0

Example file:

{
  "response_type": "INV",
  "items": [
    {
      "barcode": "5025155019702",
      "available_qty": 0
    }
  ]
}

Mapping:

Field Name WAP Mapping WAP Notes
response_type “INV” Hardcoded
items N/A Products specific section
barcode Item > EAN
available_qty Item Account > Quantity

OR “0” | Depending on the End Item flag |

Note: While for the POA and ASN we are to send single orders per file for the INV we want to add as many items as possible. IPT are charging us by number of transactions so as a start we want the timing of this to be set to work every hour

Is this article helpful?
0 0 0