Inbound Process
Summary
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 purchaseOrder or a receipt is created, a corresponding inboundProcess is automatically created as well.
An overview of all inbound process can be found in the inbound view or in the inventory app. Incoming goods can be accepted via the inbound section of our inventory app. The event of checking and accepting incoming goods is represented via Receipts.
Sub-Entities
The inbound process has sub-entities, which can be created and modified as part of the inbound process, or alternatively via their own endpoints.
Purchase Order
A purchase order is issued when new stock is ordered for a store or warehouse. It includes the following information:
Creating an inbound process with a purchaseOrder
Mandatory values:
facilityRef
: facility for which the order is destinedpurchaseOrder
:orderDate
: time and date on which order was placedrequestedDate
: time and date on which order is expected to arriverequestedItems
:tenantArticleId:
unique identifier for itemquantity:
quantities and units of ordered items (maximum of 200 items can be processed)
Optional values:
tenantInboundProcessId:
unique identifier for inbound used in the customer systemsonHold
: Setting an inbound process on hold means that it should be paused for now. Can be set manually via Backoffice or via API. By setting the flag totrue
, the inboundProcess status is set toonHold
.scannableCodes
: scannableCodes such as barcodes that are relevant in the inboundProcess, e.g. , barcode of the delivery notecustomAttributes
: can be used to carry custom information that might be of interest to connectors or services outside of fulfillmenttools. For more information see custom attributes.purchaseOrder
:requestedItems:
stockProperties
: information on stock properties of requested items such as expiry date
cancelled
: If no further deliveries are expected, a purchaseOrder can be cancelled by an admin via Backoffice or via API. This is also possible, if several items have already been accepted. By setting the flag totrue
, the inboundProcess status is set toclosed
.supplier
: information on supplier of delivery (name)customAttributes
Receipt
After a goods receipt was performed and goods have been accepted, a receipt is issued that adds the stock to the facility. It includes the following information:
Adding a receipt to an inboundProcess
Mandatory values:
receivedDate
: date when the order was accepted in the facilityreceivedItems
: for each item that was announced via purchaseOrder the following information can be provided:tenantArticleId:
unique identifier for itemacceptedQuantity
: quantity that was accepted in the goods receiptrejectedQuantity
: Quantity that was rejected in the goods receipt (due to being, e.g., broken).comments
: information relevant for that specific lineItem such as comments, photos, or other attachments
comments
: information relevant for that specific delivery such as comments, photos, or other attachments
Rejected items are not a subset of accepted items and are not booked to the facility as stock.
Optional values:
asnRef:
can be used to store the reference to an internal advanced shipping notereceivedItems
: for each item that was announced via purchaseOrder the following information can be provided:storageLocationRef
: the storage location on which the item was placedstockProperties
: information specific to that lineItem such as expiry date or batch number
comments
: information relevant for that specific deliverystatus
: If a goods receipt has been started via inventory app, the status of the receipt changes toIN_PROGRESS
and then toFINISHED
after the process was completed in the app.customAttributes
: Attributes that can be added to the receipt. These attributes cannot be used within fulfillmenttools' processes, but can be used to carry custom information on receipt.
Status
The inboundProcess 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.
Validation in inbound process
Unit validation in inbound processes
If there is a measurementUnitKey defined for a listing that is part of the inboundProcess, each new line item in inboundProcess.purchaseOrder.requestedItems and inboundProcess.receipts.receivedItems is validated against it: All quantities MUST match the unit of the Listing.
Attention: 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 created in the inventory app. 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, but 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 measurementUnits, click here.
Stock property validation in inbound processes
If there are stockProperties defined for a listing that is part of the inboundProcess, each new line item in inboundProcess.purchaseOrder.requestedItems and inboundProcess.receipts.receivedItems is validated against it. The validation for requested and received items behaves slightly different as we do not expect systems to know the exact properties of all items before they have arrived.
Validation for requestedItems
All stockProperties that are part of the requestedItems must also be defined in the stockProperties of the listing.
Not all stockProperties that are part of the listing must also be present in the requestedItems.
This means, it is allowed to create a purchaseOrder without stockProperties in the requestedItems even though the included listing has stockProperties defined.
Validation for receivedItems
All stockProperties that are part of the receivedItems must also be defined in the stockProperties of the listing.
Not all stockProperties that are part of the listing must also be present in the requestedItems. Only stockProperties where
required
is true need to be present in both listing and receivedItems. This is because creating a stock without providing a value for arequired
property is forbidden and will fail.
For more information on stockProperties on listing, click here.
Api Documentation
Inbound Process
Purchase Order
Receipt
Last updated