Uploaded image for project: 'mod-orders'
  1. mod-orders
  2. MODORDERS-103

Implement receiving flow for physical-only

    XMLWordPrintable

    Details

    • Template:
    • Sprint:
      ACQ Sprint 57, ACQ Sprint 58
    • Story Points:
      5
    • Development Team:
      Thunderjet

      Description

      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)
        • 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

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                siarhei_hrabko Siarhei Hrabko
                Reporter:
                pavelk-epam Pavel Korolenok
                Tester Assignee:
                Siarhei Hrabko Siarhei Hrabko
                Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases