Request for feedback on R&R Rejection Reason Feature implementation in OpenLMIS

In Tanzania project to upgrade eLMIS version 2 to OpenLMIS version 3, there is a requirement to capture reason(s) why Requisition was rejected. This is a configurable feature it can be turned on and off. More details on this feature can be found on this page https://openlmis.atlassian.net/wiki/spaces/TZUP/pages/1059520533/Capture+Reasons+for+Rejecting+an+R+R+Specification

Since the idea is to merge this feature back to the core Requisition service, I would like to ask for any feedback from this forum.

I have also attached schema design

Hello @ian,
thanks for sharing the ERDs and designs.

On ERDs - will the author of the rejection ever be different than the user who rejects the requisition? Can we have one user set the rejection reason and another user actually clicking the reject button? In other words, will the authorid ever be different in status_changes and rejections?

On UI designs - it seems that it would be easier if the rejection reason dropdown appeared after clicking on the “Reject” button. Then the user could optionally choose the reason. Currently, the designs introduce a new, separate button, that ultimately is also used to reject the requisition - this creates unnecessary inconsistency.

Does the rejection reason appear anywhere on the UI when the user opens the requisition? The confluence page is only showing the e-mail message that contains this information.

How are rejection reasons and rejection reason categories configured? Are there any new admin screens that allow to set them up? Are they predefined/preloaded?

Best regards,
Sebastian

Hello Sebastian,

Thank you for the response, my response

On ERDs - will the author of the rejection ever be different than the user who rejects the requisition? Can we have one user set the rejection reason and another user actually clicking the reject button? In other words, will the authorid ever be different in status_changes and rejections?

(Thank you for noting this mistake, it will be the same user who click reject button and choose the reason, I will drop authorid)

On UI designs - it seems that it would be easier if the rejection reason dropdown appeared after clicking on the “Reject” button. Then the user could optionally choose the reason. Currently, the designs introduce a new, separate button, that ultimately is also used to reject the requisition - this creates unnecessary inconsistency.

(As you suggested currently our design is the screen will appear after user click reject button, the other “Reject” button that appear on rejection screen will be renamed to “Submit”)

Does the rejection reason appear anywhere on the UI when the user opens the requisition? The confluence page is only showing the e-mail message that contains this information.

(On our currently design there is no other place in the system where this information appears, we only send email, but you have raised a very good point, do you have any suggesting on how best to show this information in the system?)

How are rejection reasons and rejection reason categories configured? Are there any new admin screens that allow to set them up? Are they predefined/preloaded?

(We have created a screen for admins to configure both rejection reasons and rejection reason categories))