POST /PurchaseOrders

GENERAL INFORMATION

Purpose

This endpoint is used for creating purchase orders and updating them with the correct status and quantities.

How the data is used

The purchase order data enables Wallie to give a proposal for the initial distribution of this purchase order. Without the purchase orders the initial distribution cannot be done, making it a mandatory dataset if the business wants to use the initial distribution functionality of Wair.

Additionally we use the open purchase orders in our redistribution module. Via a setting you are able to exclude styles from automatic/manual redistribution, if they have an open purchase order on it. This is to avoid redistributing styles that will be replenished soon due to new stock coming in.

Best practices

1. Wallie only needs the purchase orders who have yet to be delivered. It is not necessary to also send the historical purchase order data of already received/cancelled purchase orders.

2. We only show open purchase orders in our customer portal which are expected to arrive in the near future, which is determined by the orderDueDate field, so make sure this date is a real expected due date. An open purchase order is determined by the quantityOutstanding on the orderlines and/or the completelyReceived field on the order, more about this below.

3. We have 2 quantities in the purchase order lines, make sure to implement them in the correct manner:

   a. quantity > the quantity that is ordered from the vendor.

   b. quantityOutstanding > the quantity that still remains to be received from the vendor (i.e. quantity ordered minus quantity already received)

4. To summarize; we need updates on the purchase orders in the following scenario’s:

   a. Purchase order is cancelled/deleted > set the completelyReceived to true and the quantityOutstanding on the lines to 0 or delete the purchase order using DELETE /PurchaseOrders

   b. Purchase order is delayed > update the orderDueDate with the new expected due date.

   c. Purchase order is partially received > update the quantityOutstanding (see point 4 for detailed explanation).

   d. Purchase order is fully received > update the completelyReceived to true and update the quantityOutstanding to 0.

5. When updating the purchase order, always send the entire purchase order to this endpoint, as it is a POST endpoint.

6. When buying in prepacks, make sure to also send the prepack definition to the POST /Prepacks endpoint and correctly assign the prepack as a SKU in the POST /Items endpoint.

7. Assign the correct locationId on the purchase order if you for example create purchase orders to be delivered directly to specific locations like stores or a warehouse (in case you have multiple warehouses).

Common pitfalls

1. Not aligning the skuId with the skuId you send to the POST /Items endpoint, also applies to seasonId, collectionId, vendorId (POST /Vendors) or the locationId (POST /Locations).

2. Also sending the entire historical purchase order data, which is not needed.

3. Using a line number for purchaseOrderLineId. This does not work because the lineId needs to be unique across all purchase orders.

Example use cases

1. As a buyer I want Wallie to make an initial distribution proposal for a purchase order which will be delivered to our warehouse in the coming days.

2. As a buyer I do not want to see purchase orders who have already been received or cancelled.

TECHNICAL INFORMATION

Authentication

Bearer token, information on page POST /Token

Headers

QueryParameters:

Body example:

{
  "purchaseOrders": [
    {
      "purchaseOrderId": "2bf1f924-fc37-43b6-9ab3-715ef6080e8f",
      "code": "PO2025-01",
      "collectionId": "e84c4cd6-9902-4acc-8941-ceabd3301024",
      "seasonId": "7bf4f374-a738-4ee8-b275-330ea32bdcea",
      "vendorId": "8d9b41e3-d37d-4bee-896c-c9dabb3ccff4",
      "locationId": "cb15e20e-f91c-4028-87fe-cdf4c6e55a6f",
      "currencyCode": "local"
      "completelyReceived": true,
      "orderDate": "2025-11-06T08:59:43.009Z",
      "orderDueDate": "2025-12-06T08:59:43.009Z",
      "purchaseOrderLines": [
        {
          "purchaseOrderLineId": "f3a60b15-146e-424e-9a16-1a7d0ef60e23",
          "lineNumber": 0,
          "skuId": "12b45773-1839-4bb1-b82a-5ea3ff9d7508",
          "quantity": 10,
          "quantityOutstanding": 10,
          "quantityToReceive": 10,
          "unitCostLocalCurrency": 5.0,
          "vatPercentage": 0,
          "plannedReceiptDate": "2023-10-06T08:59:43.009Z"
        },
        {
          "purchaseOrderLineId": "cffee920-646f-43c2-abcb-0e31f6fb9d2b",
          "lineNumber": 1,
          "skuId": "918a86bd-f81b-4f56-9754-ba2959ef2660",
          "quantity": 50,
          "quantityOutstanding": 50,
          "quantityToReceive": 50,
          "unitCostLocalCurrency": 7.5,
          "vatPercentage": 0,
          "plannedReceiptDate": "2023-10-06T08:59:43.009Z"
        }
      ]
    }
  ]
}

Field information:

RESPONSE

StatusCodes:

200 = OK

401 = Unauthorized, which means an expired/missing/invalid token

400 = Bad request, see body of the response to check which validation errors have occured

500 = System error, see body of the response to check which error has occured or contact integration support

Body Example:

No body in the response