POST /Transfers

GENERAL INFORMATION

Purpose

Use this endpoint to create and update transfers. By transfers we mean every upcoming stock movement.

How the data is used

We use this information to establish the (upcoming) unavailable/available stock by the following logic:

Stock on hand plus/minus the transit stock equals available stock.

Stock on hand = current stock sent either through /Stock or /StockMutations endpoint

Transit stock = quantities to ship/receive in open transfers sent to this endpoint.

We also use this data to track the progress of the transfers created by Wair to show the progress to the users in our portal.

Best practices

1. No historical data is needed when sharing the Transfers. Only open transfers is enough.

2. It's needed to update the transfer information, particularly the  “open”, “quantityShipped“, “quantityReceived”, values once a transfer is either shipped or received or altered in any way. You can do an update by doing another POST call to this endpoint with the entire transfer as payload.

3. We need to be aware of both the status of the transfer (if it is still open or not) and the quantities to enable us to always calculate the correct available stock at all time. Therefore we recommend to create/update the transfers as fast as possible.

4. We recommend to share upcoming stock movements of all processes, especially if they put an allocation on the stock of locations/warehouses managed by Wallie. Below are some examples for upcoming stock movements we advise to send as transfers:

   a. A replenishment is created for replenishing a store from the warehouse.

   b. A product is redistributed, creating transfers for stores to send some of their products to other stores, while also receiving new products.

   c. A store calls another store and asks to send some goods to his/her store.

   d. A B2B sales order is created from a B2B portal, where stock from the warehouse will be sent to a reseller.

5. When sending B2B sales orders as transfers, both the fromLocationId and toLocationId needs to be present in the Wair system, which means they need to be sent to the POST /Locations. We advise to send your B2B customer/reseller locations to the locations endpoint to ensure the locations are created in Wair.

6. If you have stock movements where either the fromLocationId/toLocationId is still unknown (for example; the fulfilling warehouse is not yet decided) you can assign it to a virtual location, but when using this method, also send the vertical location to the POST /Locations endpoint.

7. If there is a cancellation of a transfer, send an update to this endpoint and set the “open” field to false.

8. There are cases where the source system has the possibility to delete the transfer (or B2B sales order), but does not register this in a way that allows you to send the delete to the DELETE /Transfers endpoint. Check if this applies to your case too, if so, you can work-around this issue by submitting a fullLoad of all open transfers on a regular interval.

9. We ask for a transfer type, if you do not have this in your source system you can use code 98 unknown.

Common pitfalls

1. Not aligning the skuId with the skuId you send to the POST /Items, same goes for the fromLocationId/toLocationId to the POST /Locations endpoint.

2. The transferLineId needs to be unique across all transfers. If you do not have an id on this level, only a row number, we advise to combine the transferId and rownumber (seperated by dash -) to make the id unique.

3. Do not generated a random id for the transferId field in the integration, only use id’s that are fixed in the source system, allows you to update them correctly using the fixed id.

Use cases

1. As a merchandiser I do not want to create replenishments using the stock in my warehouse that has already been allocated to B2B sales orders.

2. As a merchandiser I do not want to replenish a SKU of a location where the SKU is already being transferred from another location

3. As a merchandiser I do not want to create a VMI replenishment for a SKU if my B2B customer/reseller already ordered it himself using our B2B portal.

TECHNICAL INFORMATION

Authentication

Bearer token, information on page POST /Token

Headers

QueryParameters:

Body example:

{
  "transfers": [
    {
      "transferId": "guid01",
      "code": "TRANSFER01",
      "fromLocationId": "guid01",
      "toLocationId": "guid02",
      "type": 1,
      "creationDate": "2023-09-08T12:51:35.447Z",
      "open": true,
      "transferLines": [
        {
          "transferLineId": "guid01",
          "skuId": "guid01",
          "quantity": 10,
          "quantityShipped": 10,
          "quantityReceived": 0
        },
        {
          "transferLineId": "guid02",
          "skuId": "guid02",
          "quantity": 15,
          "quantityShipped": 15,
          "quantityReceived": 15
        }
      ]
    }
  ]
}

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.