# Inbound process

An inbound process maps all processes around incoming goods in a store or warehouse. This can include delivery of goods but also interfacility transfers or similar processes. Whenever a purchase order or a receipt is created, a corresponding inbound process is automatically created as well.

An overview of all inbound process can be found in the [inbound view](https://docs.fulfillmenttools.com/documentation/backoffice/facility-view/inventory/inbound) of Backoffice and in the [inventory app](https://docs.fulfillmenttools.com/documentation/apps/inventory-app). The process of checking and accepting incoming goods is represented via [receipts](#receipt).

The inbound process has sub-entities, which can be created and modified as part of the inbound process, or alternatively via their own endpoints.

## Sub-entities of inbound process

### Purchase order

A purchase order represents an order of goods for a facility. It is created by the ordering facility and contains information about the planned delivery date, the type, quantity and characteristics of the ordered items, as well as the name of the supplier. This information is represented by the below properties:

* `facilityRef`: reference of the ordering facility
* `requestedDate`: can be either set to "ASAP" (if the delivery is expected to arrive as soon as possible) or to a specific date & time
* `requestedItems`: contains information on the ordered items. Information on expiry dates or batch number can be specified in the [stock properties](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/stock/stock-properties).
* `supplier`: holds the name of the supplier. Displayed in the [inbound view](https://docs.fulfillmenttools.com/documentation/backoffice/facility-view/inventory/inbound) of Backoffice and in the [inventory app](https://docs.fulfillmenttools.com/documentation/apps/inventory-app).

After a purchase order has been created, [expected stock](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/stock/stock-availability) for the requested items is created. When desired, the expected stock can already be [used for incoming customer orders](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/stock/expected-stock-in-availability).

### Receipt

A receipt represents the acceptance of goods in a facility. It contains information on the time of receipt and on accepted and rejected items. This information is represented by the below properties:

* `facilityRef`: reference of the receiving facility
* `receivedItems`: contains information on accepted and rejected items. Information on expiry dates or batch number can be specified in the [stock properties](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/stock/stock-properties).
* `comment:` can optionally contain information on received items

After a receipt was created, stock for the received items is created. If there were reservations on the expected stock, they are shifted to stock in the facility.

{% hint style="success" %}
**Rejected items in receipt**

Rejected items can be marked separately during goods receipt. The stock created from rejected items receives the condition "defective" and is not marked as "pickable" and "accessible". Thus, it will not be available for sale.
{% endhint %}

## Status of the inbound process

The inbound process itself as well as its sub-entities can have different status. Our clients show the status that are most relevant to the user in the [inbound view](https://docs.fulfillmenttools.com/documentation/backoffice/facility-view/inventory/inbound) and in the [inventory app](https://docs.fulfillmenttools.com/documentation/apps/inventory-app).

The inbound process status is a calculated status that depends on the status and content of its sub-entities.

| Status             | Meaning                                                                                                                                                                                                               | Entity           |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| `OPEN`             | Delivery has not arrived yet                                                                                                                                                                                          | `inboundProcess` |
| `PARTIAL_DELIVERY` | Items in the delivery were missing                                                                                                                                                                                    | `inboundProcess` |
| `CLOSED`           | All items that were announced via purchase order have arrived (either as accepted or rejected quantity) or purchase order was canceled.                                                                               | `inboundProcess` |
| `ON_HOLD`          | Inbound process should be paused for now. Can be set manually via Backoffice or via [REST API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#patch-/api/inboundprocesses/-inboundProcessId-). | `inboundProcess` |
| `OPEN`             | No functional meaning.                                                                                                                                                                                                | `purchaseOrder`  |
| `CANCELED`         | No further deliveries are expected. Can be set manually via Backoffice or via [REST API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#patch-/api/purchaseorders/-purchaseOrderId-).          | `purchaseOrder`  |
| `OPEN`             | Goods have arrived in a facility or will arrive soon.                                                                                                                                                                 | `receipt`        |
| `IN_PROGRESS`      | Goods receipt for (one part of the) delivery has been started.                                                                                                                                                        | `receipt`        |
| `FINISHED`         | Goods receipt for (one part of the) delivery has been finished.                                                                                                                                                       | `receipt`        |

## Validation in inbound process

### Measurement unit validation in inbound processes <a href="#unit-validation-in-inbound-processes" id="unit-validation-in-inbound-processes"></a>

If there is a [measurement unit](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/measurement-units) key defined for a [listing](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/listing) that is part of the inboundProcess, each new line item in the requested items of the purchase order and in the received items of the receipt is validated against it: All quantities must match the unit of the listing.

This means that when creating an `inboundProcess` with a purchaseOrder with unit "xyz" and changing the listing.measurementUnitKey to something else ("qwe") the `inboundProcess.purchaseOrder` must now be patched/replaced to reflect the correct unit again before a receipt can be created. This is intentional and ensures the consistency of new stock levels in the facility.

{% hint style="warning" %}
In general, it's not advised to change the unit of a product in a facility without careful consideration. However, in some cases it might be desired to start with no unit on the listing (= no validation) and transition to stricter rules later.
{% endhint %}

{% hint style="info" %}
See the [Measurement units article](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/measurement-units) for more information.
{% endhint %}

### Stock property validation in inbound processes <a href="#unit-validation-in-inbound-processes" id="unit-validation-in-inbound-processes"></a>

If there are [stock properties](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/stock/stock-properties) defined for a [listing](https://docs.fulfillmenttools.com/documentation/by-pillar/global-inventory-hub/listing) that is part of the inbound process, each new line item in the requested items of the purchase order and in the received items of the receipt is validated against it. The validation for requested and received items behaves slightly different as it is not expected that the exact properties of all items are known before they have arrived.

#### Validation for requested items

* All stock properties that are part of the requested items must also be defined in the stockProperties of the listing.
* Not all stock properties that are part of the listing must also be present in the requested items.
* This means, it is allowed to create a purchase order without stock properties in the requested items even though the included listing has stock properties defined.

#### Validation for receivedItems

* All stock properties that are part of the received items must also be defined in the stock properties of the listing.
* Not all stock properties that are part of the listing must also be present in the requested items. Only stock properties defined as **required** in the listing need to be present in both listing and receivedItems. This is because creating a stock without providing a value for a required property is forbidden and will fail.

## Create an inbound process

An `inboundProcess` maps all processes around incoming goods in a store or warehouse. The inbound process has the sub-entities `purchaseOrder` and `receipt`, which can be created and modified as part of the inbound process, or alternatively via their own endpoints. Whenever a `purchaseOrder` or a `receipt` is created, a corresponding `inboundProcess` is automatically created.

Create an `inboundProcess` by executing the following POST call with the JSON body:

```http
POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/inboundprocesses
```

{% code title="Request body (JSON)" %}

```json
{
  "facilityRef": "CGN-01",
  "scannableCodes": ["12345"],
  "tenantInboundProcessId": "AB-01"
}
```

{% endcode %}

If the request is successful, you receive a `201 CREATED` response with a body like this:

{% code title="Response (201 Created)" %}

```json
{
    "created": "2025-03-12T14:15:39.683Z",
    "facilityRef": "CGN-01",
    "id": "d9f76e9f-6105-4286-b054-1bfbf8eebe77",
    "lastModified": "2025-03-12T14:15:39.683Z",
    "receipts": [],
    "status": "OPEN",
    "version": 1,
    "tenantInboundProcessId": "AB-01",
    "onHold": false,
    "inboundDate": [],
    "origin": [],
    "scannableCodes": [
        "12345"
    ],
    "anonymized": false
}
```

{% endcode %}