Catalog of Requisition API calls

OpenLMIS v2 endpoints:

Requisition table:

Endpoint	Parameters	Return	Method
/requisitions	@RequestParam("facilityId") Long facilityId, @RequestParam("programId") Long programId, @RequestParam("emergency") Boolean emergency, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	POST
/requisitions	RequisitionSearchCriteria criteria, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	GET
/requisitions/{id}	@PathVariable Long id, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	GET
/requisitions/{id}/skipped	@PathVariable Long id, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	GET
/requisitions/{id}/save	@PathVariable("id") Long id, @RequestBody Rnr rnr, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	PUT
/requisitions/{id}/submit	@PathVariable("id") Long id, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	PUT
/requisitions/{id}/authorize	@PathVariable Long id, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	PUT
/requisitions/{id}/approve	@PathVariable Long id, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	PUT
/requisitions/lossAndAdjustments/reference-data	-	ResponseEntity<OpenLmisResponse>	GET
/requisitions-for-approval	HttpServletRequest request	ResponseEntity<OpenLmisResponse>	GET
/requisitions-for-convert-to-order	@RequestParam(value = "searchType", required = false) String searchType, @RequestParam(value = "searchVal", required = false) String searchVal, @RequestParam(value = "page", required = true) Integer page, @RequestParam(value = "sortBy", required = false) String sortBy, @RequestParam(value = "sortDirection", required = false) String sortDirection, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	GET
/logistics/periods	RequisitionSearchCriteria criteria, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	GET
/requisitions/{id}/print	@PathVariable Long id	ModelAndView	GET
/requisitions/{id}/comments	@PathVariable("id") Long id, @RequestBody Comment comment, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	POST
/requisitions/{id}/comments	@PathVariable("id") Long id	ResponseEntity<OpenLmisResponse>	GET
/requisitions/delete/{id}	@PathVariable("id") Long rnrId	ResponseEntity<OpenLmisResponse>	POST
/requisitions/skip/{id}	@PathVariable("id") Long rnrId, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	POST
/requisitions/reject/{id}	@PathVariable("id") Long rnrId, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	POST
/requisitions/reopen/{id}	@PathVariable("id") Long rnrId, HttpServletRequest request	ResponseEntity<OpenLmisResponse>	POST

RNRTemplate Table:

Endpoint

Parameters

Return

Method

/program/{programId}/rnr-template

@PathVariable("programId") Long programId

RnrTemplateForm

GET

/rnr/{programId}/columns

@PathVariable("programId") Long programId

List<RnrColumn>

GET

/program/{programId}/rnr-template

@PathVariable("programId") Long programId,

@RequestBody RnrColumnList rnrColumnList,

HttpServletRequest request

ResponseEntity<OpenLmisResponse>

POST

OpenLmis v3 Requisition endpoints

Requistion endpoints:

Endpoint	Parameters	Return	Method
/requisitions	@RequestBody Requisition requisition	ResponseEntity<?>	POST
/requisitions	-	ResponseEntity<?>	GET
/requisitions/initiate	@RequestBody Requisition requisitionDto	ResponseEntity<?>	POST
/requisitions/{id}/submit	@PathVariable("id") UUID requisitionId @RequestBody Requisition requisition, BindingResult bindingResult,	ResponseEntity<?>	PUT
/requisitions/{id}	@PathVariable("id") UUID requisitionId	ResponseEntity<?>	DELETE
/requisitions/{id}	@PathVariable("id") UUID requisitionId	ResponseEntity<?>	GET
/requisitions/{id}	@PathVariable("id") UUID requisitionId @RequestBody Requisition requisition,	ResponseEntity<?>	PUT
/requisitions/search	RequestParam(value = "facility", required = false) Facility facility, @RequestParam(value = "program", required = false) Program program, @RequestParam(value = "createdDateFrom", required = false) LocalDateTime createdDateFrom, @RequestParam(value = "createdDateTo", required = false) LocalDateTime createdDateTo, @RequestParam(value = "processingPeriod", required = false) Period processingPeriod, @RequestParam(value = "supervisoryNode", required = false) SupervisoryNode supervisoryNode, @RequestParam(value = "requisitionStatus", required = false) RequisitionStatus requisitionStatus	ResponseEntity<?>	GET
/requisitions/{id}/skip	@PathVariable("id") UUID requisitionId	ResponseEntity<?>	PUT
/requisitions/{id}/reject	@PathVariable("id") UUID id	ResponseEntity<?>	PUT
/requisitions/{id}/comments	@PathVariable("id") UUID id, @RequestBody Comment comment, OAuth2Authentication auth	ResponseEntity<Object>	POST
/requisitions/{id}/comments	@PathVariable("id") UUID id	ResponseEntity<Object>	GET
/requisitions/{id}/approve	@PathVariable("id") UUID requisitionId	ResponseEntity<?>	PUT
/requisitions/requisitions-for-approval	OAuth2Authentication auth	ResponseEntity<Object>	GET
/requisitions/submitted	-	ResponseEntity<?>	GET
/requisitions/{id}/authorize	@PathVariable("id") UUID requisitionId @RequestBody Requisition requisitionDto, BindingResult bindingResult,	ResponseEntity<?>	PUT

Requistion line endpoints:

Endpoint	Parameters	Return	Method
/requisitionLines	@RequestBody RequisitionLines requisitionLines	ResponseEntity<?>	POST
/requisitionLines	-	ResponseEntity<?>	GET
/requisitionLines/{id}	@PathVariable("id") UUID requisitionLineId	ResponseEntity<?>	DELETE
/requisitionLines/{id}	@PathVariable("id") UUID requisitionLineId	ResponseEntity<?>	GET
/requisitionLines/{id}	@PathVariable("id") UUID requisitionLineId @RequestBody Requisition requisition,	ResponseEntity<?>	PUT
/requisitionLines/search	@RequestParam(value = "requisition", required = true) Requisition requisition, @RequestParam(value = "product", required = true) Product product	ResponseEntity<?>	GET

Requistion template endpoints:

Endpoint	Parameters	Return	Method
/requisitionTemplates	@RequestBody RequisitionTemplates requisitionLines	ResponseEntity<?>	POST
/requisitionTemplates	-	ResponseEntity<?>	GET
/requisitionTemplates/{id}	@PathVariable("id") UUID requisitionTemplateId	ResponseEntity<?>	DELETE
/requisitionTemplates/{id}	@PathVariable("id") UUID requisitionTemplateId	ResponseEntity<?>	GET
/requisitionTemplates/{id}	@PathVariable("id") UUID requisitionTemplateId @RequestBody Requisition requisition,	ResponseEntity<?>	PUT
/requisitonTemplates/search	@RequestParam(value = "program", required = false) Program program	ResponseEntity<?>	GET

OpenLMISv2 endpoints and corresponding endpoints in OpenLMISv3

	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: Retrieve requsition with the ID provided in the endpoint Get the full supply line items of that requsition Return those line items that are not skipped 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 - No audit in v3 - No calculations (stock in hand, quantity dispensed, etc.) in v3 - also mentioned in Requisition epic status 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 - No audit in v3 - No calculations (stock in hand, quantity dispensed, etc.) in v3 - also mentioned in Requisition epic status 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 OLMIS-751 - Getting issue details... STATUS . So Stock on hand calculations will be added in the "Configure Stock on Hand" ticket, total losses/adjustments in "Configure total losses / adjustments" and so on. 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 - No calculations (cost, packs to ship) in v3 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 ( OLMIS-1050 - Getting issue details... STATUS ) since these validation are during the 'approve' screen/step versus the 'create'.
9.	/requisitions/lossAndAdjustments/reference-data	GET	-	-		Will be addressed in OLMIS-380 - Getting issue details... STATUS
10.	/requisitions-for-approval	GET	/requisitions/requisitions-for-approval	GET
11.	/requisitions-for-convert-to-order	GET	-	-		Will be done in OLMIS-988 - Getting issue details... STATUS
12.	/logistics/periods	GET	/requisitions/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: Will be updated in OLMIS-997 - Getting issue details... STATUS 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

Legend:

Has corresponding endpoint in V3

Does not have corresponding endpoint in V3

OpenLMISv3 endpoints that don’t have corresponding endpoints in OpenLMISv2

Endpoint	Method
/requisitions/submitted	GET
/requisitionLines	POST
/requisitionLines	GET
/requisitionLines/{id}	DELETE
/requisitionLines/{id}	GET
/requisitionLines/{id}	PUT
/requisitionLines/search	GET
/requisitionTemplates	GET
/requisitionTemplates/{id}	DELETE
/requisitionTemplates/{id}	GET
/requisitionTemplates/{id}	PUT