PO Line: receipt status

According to UIREC-10

The receiving button should only appear on open order
...
if Open order has PO Lines that do NOT have a receipt status of "Pending" or "Receipt not Required"

The composite_po_line.json schema defines 6 receipt statuses:

• Awaiting Receipt
• Cancelled
• Fully Received
• Partially Received
• Pending
• Receipt Not Required

None of these are handled yet. Also there is no any functional description in Acquisitions Interface Fields

Purpose:

• If the order is in pending state, if not specified, the receipt status should default to "Pending".
  Note: update composite_po_line.json and po_line.json schemas defining Pending as default receipt_status
• Once the order transitions to "Open", receipt status should transition to "Awaiting Receipt" if still set to "Pending". Otherwise, not change is made.
• During the receiving process, 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".
  Note: this can be handled as part of MODORDERS-103.
• Receipt status of "Cancelled" would only happen when closing an order under certain circumstances... details here are TBD. For now we can assume that this status will only be set manually
• If receipt status is "Receipt not Required" no receiving or check-in will be available for the POL
  Note: in this case no any record should created in the Inventory nor any piece record in the Orders storage - TBC dennisbridges: As we plan to allow the user to specify whether they want Inventory objects or not, I believe that should hold true regardless. However, if not receiving there is no need to create a piece record. If "receipt not required" the Item Status (If there is an item record created) would need to be set as 'Available' upon creation. cmcnally Could this be problematic?

Acceptance Criteria:

• The default/automatic receiptStatus transitions described above are implemented
• Unit test coverage on new code is 80% or higher
• API tests have been updated (May be addressed in a separate story or sub-task, but please add appropriate notes/links here)