Inbound process

Introduction

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 or in the inventory app. The process of checking and accepting incoming goods is represented via receipts.

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

Please go to the developer docs for more information on managing inbound processes, purchase orders and receipts via REST API.

Sub-entities of inbound process

Purchase order

A purchase order is issued when new stock is ordered for a store or warehouse. It contains information on the ordered items and when the dates that the delivery is expected to arrive.

Receipt

After a goods receipt was performed and goods have been accepted, a receipt is issued that adds the stock to the facility.

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.

Status of 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 and in the inventory app.

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 cancelled.	inboundProcess
ON_HOLD	Inbound process should be paused for now. Can be set manually via backoffice or via REST API.	inboundProcess
CANCELLED	No further deliveries are expected. No real status, can be either true or false. Can be set manually via backoffice or via REST API.	purchaseOrder
OPEN	No functional meaning	purchaseOrder
IN_PROGRESS	Goods receipt for (one part of the) delivery has been started (via inventory app).	receipt
FINISHED	Goods receipt for (one part of the) delivery has been finished (via inventory app)	receipt

Validation in inbound process

Measurement unit validation in inbound processes

If there is a measurement unit key defined for a 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.

In general it is 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.

For more information on measurement units, click here.

Stock property validation in inbound processes

If there are stock properties defined for a 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.