...
An Order object would be POSTed to this endpoint, with the following attributes:
- Requisition UUID (requiredoptional) - the requisition that is submitting this order (if there is one)
- Requesting Logistics Location UUID (required) - the location that is submitting this order
- Receiving Logistics Location UUID (optional) - the location that is receiving this order (if different from the requesting location). If this is not specified, the receiving location is the one that submitted the order.
- Order Line Items (required) - the individual line items that comprise this order
- Order Number (optional) - text to identify the order, not used by OpenLMIS for that purpose
- Quoted Cost (optional) - quoted cost of the submitted order
...
- Global Product UUID (required/optional) - the global product identifier for the item. At least one must be specified. If Open question about what to do if both are specified, Trade Item should be a type of Global Product.
- Trade Item UUID (required/optional) - the trade item identifier for the item. At least one must be specified. If Open question about what to do if both are specified, Trade Item should be a type of Global Product.
- Quantity (required) - the quantity of the product (in packs)
...
- It would introduce an idea of "range of estimate," rather than an "accurate estimate." An accurate estimate is more straightforward, "order 5 packs of 50 (pills)." But a range of estimate, "order 250 (pills)," may mean fulfilling with 3 packs, if packs only come in 100 pills. (This may not be a significant drawback.)
- Pricing would be more complex, as orders would be done in dispensing units, but costs are not tracked by dispensing units, but by packs. (Costs per dispensing unit may be determined eventually, but not at order or fulfillment time.)
Open Questions
- Can an Order Line Item have both Global Product and Trade Item specified? Are there scenarios where this makes sense? If so, the scenarios should inform the design proposal about what should be done if both are specified.