Implement receiving flow for physical-only

Purpose: Implement endpoint that provides capability of receiving items

High-Level Requirements:

• Implement POST /orders/receive endpoint that provides functionality for receiving items spanning one or more po_lines in the order according to the attached document. The request body: receivingCollection.json
• For each received piece:
  • Update the item record... if applicable (status, location, barcode)
    • The receivingCollection.json schema needs to be updated to include desired item's status
  • Update the piece record (status, received_date, etc) -- overlaps with check-in --
  • Update the POL record (receipt_status) -- overlaps with check-in --
    • If all pieces of this order line have been received, the receipt status should be "Fully Received". If more than one, but less than the total number of pieces have been received, it should be "Partially Received".

Notes:

• the document is pretty high-level so further thinking on how to handle various exceptional/edge cases is required
• there is a piece of logic related to updating piece record upon receiving that might be reused for check-in flow as well
• Inventory Beta - Metadata Elements - reference document for Inventory fields

High level dev approach:

1. mod-orders retrieves pieces from the mod-orders-storage based on the request body. The pieces might belong to different PO Lines so the request should contain query with piece id's limiting to e.g.15 GET /orders-storage/peices?limit=15&query=id==UUID1 or id==UUID2 or ... id==UUID15. The number of requests depends on number of items to be received
2. For those pieces which have item id specified mod-orders does following
   • retrieves items from inventory storage. The approach is same as above - set of requests per 15 items
   • updates item entities with barcode (if specified) and status Received
   • sends PUT requests to update items. In case any error happens, it should be just added to list of errors instead of failing entire operation
3. mod-orders updates piece records and sends PUT requests to mod-orders-storage. If error happened, just collect them.
   The following is expected to be update in piece:
   • receivingStatus: Received
   • locationId: from the request
   • receivedDate: new Date()
4. mod-orders retrieves all involved PO Lines and updates receipt_status based on requirements above. If the status is the same, do not send PUT request to mod-orders-storage
5. mod-orders prepares response to the client taking into account list of errors.

Open questions:

• According to UIREC-2 user will specify barcode (optional), location (required) and status (required). Taking into account item.json schema from mod-inventory-storage there are some unclear moments:
  • Location: schema has permanentLocationId. Should the logic update this one or work with holding (search for existing or create new one and update holdingsRecordId)? CAM: location should be used to find an item record in the appropriate holding. We don't need to explicitly set any location information in the item record at this point.
  • Status: status property does not have fixed enumeration. There are some defined in Inventory Beta - Metadata Elements. What statuses are expected to be processed? CAM: item status should be "On Order" and transition to "Received" upon receipt

Acceptance Criteria:

• receiving flow is implemented for physical orders
• unit tests are updated
• api tests are updated

See https://docs.google.com/spreadsheets/d/1se-a2owRfHLG5eaAZglx4vLvRClCKGp2wZCfD39ZJRY/view#gid=894044560 for complete API listing