...
Endpoints used in OpenLMISv2 | Corresponding endpoints in OpenLMISv3 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Nr | Endpoint | Method | Endpoint | Method | Has corresponding | Notes/ Next Steps | ||||||||||
1. | /requisitions | POST | /requisitions + /requisitions/initiate | POST | ||||||||||||
2. | /requisitions | GET | /requisitions/search | GET | ||||||||||||
3. | /requisitions/{id} | GET | /requisitions/{id} | GET | ||||||||||||
4. | /requisitions/{id}/skipped | GET | - | - | Mary Jo Kochendorfer (Deactivated) This endpoint returns all the line items for a requisition of the provided ID, that are NOT marked as skipped. Do we have a requirement to be able to display that? If yes, we should have a ticket for this. Sebastian Brudziński I'm not sure if this relates to skipping a period altogether or skipping certain products once selected to be skipped (used during the authorization or approval piece). Can we discuss this further please so I can make the call. Mary Jo Kochendorfer (Deactivated) To clarify - this does not trigger any action in the system. This only returns the requisition lines that were not skipped. So the flow is:
Sebastian Brudziński to your last point, is "skipped" based on the previous requisition? For example, if I fill out a requisition and select skip for specific products → does the next requisition skip showing those products? Is there a way to "unskip". Perhaps we should have a call so I can make sure I understand how the system is currently working around this feature. Mary Jo Kochendorfer (Deactivated) I've taken a detailed look at the v2 UI. This endpoint is called from the "View" page (Requisitions → View) that allows you to display all requsitions for the given facility, prorgram and between the specified date range. Once you click on the requisition a detailed view is shown and it only contains the line items for that requisition that were not skipped. Sebastian Brudziński Ok. The View screen can be done after beta. | |||||||||||
5. | /requisitions/{id}/save | PUT | /requisitions/{id} | PUT | Mary Jo Kochendorfer (Deactivated) The endpoint in v2 keeps track of the last user that has saved the requisition. Do we need that in v3? It could be a part of some more generic ticket related to auditing changes, if we have one. Most of the requisition endpoints in v2 do some auditing, so it's not an issue just in this one place. Sebastian Brudziński we will need auditing and are looking into options in OLMIS-597. Let's circle back to this. | |||||||||||
6. | /requisitions/{id}/submit | PUT | /requisitions/{id}/submit | PUT | - Regimen validation is not yet implemented in v3 Sebastian Brudziński Regimen should be addressed in program data. Audit will need to happen eventually. We do need the data entry validations. Could a QA help out and check them all in v2 and write them up in OLMIS-818? Mary Jo Kochendorfer (Deactivated) Do you mean those regimen validations? I can do that. Sebastian Brudziński, no. I mean validations like visually depicted in the jpegs on OLMIS-818. I'd like the underlying validation checks to be implemented if they aren't already. Like, you cannot submit if certain fields aren't fulfilled. I can outline all the 'visual' ones. Mary Jo Kochendorfer (Deactivated) Oh, gotcha. So this is partially connected with calculations as well. I can go over the v2 code and write down all the checks I can find in OLMIS-818. Then I can assign OLMIS-818 to one of the QAs to excersise v2 to make sure I haven't missed any. Does that sound OK? Sebastian Brudziński yes, ok. Thanks. | |||||||||||
7. | /requisitions/{id}/authorize | PUT | /requisitions/{id}/authorize | PUT | - Regimen validation is not yet implemented in v3 Sebastian Brudziński same as above. Sebastian Brudziński I think we have a plan to address this now. Mary Jo Kochendorfer (Deactivated) Introducing the missing calculations is a part of the tickets remaining in Requisition-Configuration epic
Concerning regimen and audit, do we want to address it now as well? Audit seems to be covered by OLMIS-597. Sebastian Brudziński regimen we can put aside for now. In terms of auditing, we do have a ticket. I'm not clear on what we've been doing to date, but I think we can prioritize after the beta. | |||||||||||
8. | /requisitions/{id}/approve | PUT | /requisitions/{id}/approve | PUT | - Some simple validations of line items are not yet implemented Sebastian Brudziński we do need these eventually. Mary Jo Kochendorfer (Deactivated) should we include v2 validation rules for requisition line items in OLMIS-818 as well? Sebastian Brudziński, um let's make a new one (
| |||||||||||
9. | /requisitions/lossAndAdjustments/reference-data | GET | - | - | Will be addressed in
| |||||||||||
10. | /requisitions-for-approval | GET | /requisitions/requisitions-for-approval | GET | ||||||||||||
11. | /requisitions-for-convert-to-order | GET | - | - | Will be done in
| |||||||||||
12. | /logistics/periods | GET | /processingPeriods/searchrequisitions/periods-for-initiate | GET | This endpoint is used in v2 for initiating the requisition for a selected period. It is possible to filter the periods by facility (my or supervised), program and type (regular/emergency). Our current search endpoint only allows to filter them by date. Mary Jo Kochendorfer (Deactivated) I suggest that we have a ticket to extend the period search endpoint with the missing criteria. Sebastian Brudziński I see that Pawel created OLMIS-997, could you add these remaining pieces to that story or should we create another new one? Mary Jo Kochendorfer (Deactivated) Pawel's story concerns the validation of the created requsitions, to make sure they are created for the latest available period. What we want here is to even be able to display those periods for the selected facility, program and type. I'd suggest a new ticket. UPDATE: We have extended OLMIS-997 with the ability to search periods by the missing fields. So:
Please note that I have updated the corresponding endpoint in v3. The previous endpoint was located in the reference data and it displayed ALL the periods for the given facility and program. For initiate, we need to filter out periods that have already been "used" - that is they have an authorized or approved requisition and therefore do no longer appear on the create/authorize requisition page. The endpoint has been introduced in OLMIS-997. | |||||||||||
13. | /requisitions/{id}/print | GET | - | - | Mary Jo Kochendorfer (Deactivated) this is used to generate a PDF from the requisition, but I was not able to make it work on v2 demo server. Looking at the code, it should display a table for full supply items, then for non-full supply (if any), then for regimen (if any) and finally include a summary. If we don't have a ticket yet, we should have one, if we want to print requisitions. Sebastian Brudziński yes, we want to print them and should use the 'printing (pdf generating) service' used for POD to do so. Right? See OLMIS-1009 that I just created. Mary Jo Kochendorfer (Deactivated) Yes. Looks good to me. | |||||||||||
14. | /requisitions/{id}/comments | POST | /requisitions/{id}/comments | POST | ||||||||||||
15. | /requisitions/{id}/comments | GET | /requisitions/{id}/comments | GET | ||||||||||||
16. | /requisitions/delete/{id} | POST | /requisitions/{id} | DELETE | ||||||||||||
17. | /requisitions/skip/{id} | POST | /requisitions/{id}/skip | PUT | v2 also marks all line items as skipped. Should we? Sebastian Brudziński We do need to be able to skip a period (and all products associated with that period) however I'm not sure it all needs to be saved to the DB ... the technical design of how a period is skipped is unknown to me. However, being able to skip is important for business reasons. How should we move this forward? There was a ticket on this... OLMIS-218 Mary Jo Kochendorfer (Deactivated) Since OLMIS-740 will introduce the ability to skip only selected line items, I think it might make sense to mark all line items as skipped, when the whole period is. I suggest reopening OLMIS-218 and adding the requirement to additionally mark all line items as skipped. Alternatively this requirement can be added to OLMIS-740. Sebastian Brudziński let's re-open OLMIS-218. However, let's start this after the beta. We aren't showcasing skipping so we can wait. | |||||||||||
18. | /requisitions/reject/{id} | POST | /requisitions/{id}/reject | PUT | ||||||||||||
19. | /requisitions/reopen/{id} | POST | - | - | Mary Jo Kochendorfer (Deactivated) This does exactly the same as the "reject" endpoint, but additionally it marks all of the full supply line items as NOT skipped. I couldn't really match it with any requirement so not exactly sure if and where we need it. Sebastian Brudziński I will need to look into this to understand it more. Kevin Cussen (Deactivated) have you heard of this behavior? Sebastian Brudziński let's come back to this after beta. | |||||||||||
20. | /program/{programId}/rnr-template | GET | /requisitionTemplates/search?program={programId} | GET | ||||||||||||
21. | /rnr/{programId}/columns | GET | /requisitionTemplates/search?program={programId} | GET | This returns a list of columns for the given program. It seems to be related to tying templates with actual requisitions. I'd put it on hold for now as we are in progress with decision about tying templates with requisitions and it may be done as a part of that work. Sebastian Brudziński ok, let's make sure it gets done though. Would be good to know what the end decision is here. Mary Jo Kochendorfer (Deactivated) I've taken a look at it again. Template columns are simply a part of a requisition template, therefore they are returned together with a template (API #20). We do not need a separate endpoints for templates and columns. Sebastian Brudziński Thank you for taking another look. perhaps we should check in with Josh Zamor or Chongsun Ahn (Unlicensed) to make sure it is or isn't needed and that #20 is sufficient. | |||||||||||
22. | /program/{programId}/rnr-template | POST | /requisitionTemplates | POST | ||||||||||||
...