Design issue: stock cards are not aware of Requisition data until final approval

This ticket is to revisit a design issue for how Requisition and Stock services connect.

Background
During the Connecting Stock and Requisition Phase 1 work in 3.2.0, we changed the plan to have the Requisition service only send data to the Stock Service at the final approval of the requisition and not before. This is because of a few current limitations:

• you can only have one draft physical inventory at a time (for a given facility and program)

• once a physical inventory goes from draft to submitted, there is no way to correct/revise it

• emergency requisitions can be initiated at any time, even while regular requisitions are still awaiting approvals

The current design (waiting until final approval) has a few drawbacks:

1. Users cannot use the Stock UI to make changes to draft physical inventory data being collected on a Requisition form If a user goes into the Stock UI, none of their physical inventory data from their recent (un-approved) requisitions is shown there. It does not appear on the stock card until weeks later when the final approval has happened. (And even if it were shown there, and further more even if they were allowed to make edits there in Stock UI, there is no mechanism for the changes to be reflected on the Requisition form.)

   1. Ideally, as soon as a requisition is initiated, that would also create a draft Physical Inventory, and users could update that draft either from the Stock UI or the Requisition form.

   2. Also ideally, implementations could be using the Stock UI for transactional record-keeping while also using the periodic Requisition form. Currently, that is not feasible with the Phase 1 implementation.

2. A Technical design issue is that the Stock Service does not fully "own" the stock portion of the Requisition form. The Requisition form is essentially making a "copy" of stock data, collecting and storing it in the Requisition service until final approval when it pushes this data into the stock service. But the long-term vision is for the Stock service to truly own this data start-to-finish. That means when a requisition is initiated, the requisition form should really be two inter-linked "documents", the requisition part and the stock part, and both documents can be edited and go through their workflows with data owned by each respective service.

This discussion definitely has considerations for:

• offline UI (stock has no offline UI currently)

• reversal/corrections to stock records (we may need to allow reversals/corrections if stock data goes from draft to submitted earlier than the final approval status)

• rejection workflow (if requisition is rejected, the requisition "document" part might start over in its workflow but it does not make sense to re-do the stock part)

• change which Requisition status creates a Draft Physical Inventory (maybe the stock data should go from draft to submitted when the Requisition form is authorized, since after that it will not change unless there is a rejection; alternatively, maybe draft physical inventory data should appear as "pending" on the stock card views)