Contribution Confirmation and Meeting Reminder

Hello Folks,

Chris George and I have been having a back and forth on the new contribution of the rejected status to core (see the following email exchange for details). To further clarify the contribution please review
this diagram
depicting the requisition workflow with the rejected status. Contact me as soon as possible if there are any other concerns. We plan to move forward with the contribution to core.

Reminder, we have a Product Committee meeting tomorrow. Please let me know if you have any suggested agenda items. Draft agenda is here.

Regards,

Mary Jo

···

From: Christopher George [mailto:cgeorge@thoughtworks.com]

Sent: Thursday, June 15, 2017 5:49 PM

To: Mary Jo Kochendorfer MaryJo.Kochendorfer@OpenLMIS.org

Subject: Re: New Contribution Confirmation

Hey Mary Jo,

Great diagram, thanks for sending the link to that. I had misunderstood one thing, in that rejection only can occur during the ‘In Approval’ state, which makes sense knowing the initial vetting of a requisition happens within the store b/w the storeroom manager and store manager.

But yes, I think the main point is around whether adding a new ‘Rejected’ status adds any significant behavioral changes to the requisition itself, since it seems to just fall back to acting just like an Initiated requisition, minus the need to make it visible to the user that this requisition was rejected. I think it’s useful to know that a requisition has been rejected, and the system should know whether a requisition has been rejected or not (e.g. for display purposes), but I’m not sure this needs to translate into adding a whole new status in the requisition lifecycle.

Yes, please feel free to share the back and forth with the larger audience. I just wanted to run it by you first as you’ve been involved with most, if not all, of the conversations around this change, and I haven’t. Just to note, I’m not vehemently against the addition of the ‘Rejected’ status, I just wanted to include in another angle for people to think about when making this decision.

Cheers,

Chris

On Fri, Jun 16, 2017 at 4:06 AM, Mary Jo Kochendorfer MaryJo.Kochendorfer@openlmis.org wrote:

Chris,

Thank you for raising the questions and perspectives. I brought it up on the PC meeting last week and the only question which came up was from Ashraf on reports. I looked into reports and found it wouldn’t be impacted.

I appreciate your point about looking for other solutions to improve usability. Internally the team discussed various options on how to do that as well.

  • One thing I noticed is that the changes involved in creating this new Rejected status pretty much just line up it up with everything that the Initiated status requires. It seems that maybe ‘Rejection’ is a tangential state of the requisition that is separate from its overall lifecycle state. An initiated requisition is one that may have been rejected or may not have been.*

Yes, rejection is a tangential state.

  • I guess one thing that maybe I don’t have as much context on is what actually happens when someone rejects a requisition? It seems that there should be a next step that would require a resolution of the rejected requisition before it can be submitted. Submitting a requisition that is in a rejected state seems amiss to me. Also, later on in the requisition lifecycle, there is also the ‘In Approval’ and Approval statuses. Doesn’t the possibility of rejection (or maybe not approving) happen here as well?*

We don’t have “strict” handling of the rejected state. For example, right now it is just getting the requisition again and they would need to call or read the overall comments to understand the why it was rejected and determine how to ‘fix’ it. The system does not specifically point to the cell(s) which an approver may want updated or changed. There are many reasons a requisition may be rejected (over budget, approver knows there isn’t any more stock of something so rejects to have the creator change their order to something else, approver knows there was a stock out but the creator didn’t fill that field out, etc.). Once an approver (in the In_approval or authorized state), rejects (via a button) it sends the requisition back to “initiated” but the proposal is that it would go to “rejected”. I’ve also created this diagram
to provide more detail and the proposed ‘reject’ status. Does that clarify?

Can we share this back and forth with the larger group? I think your questions are useful and I want to make sure we are considering all options.

Thanks!

Mary Jo

From: Christopher George [mailto:cgeorge@thoughtworks.com]

Sent: Wednesday, June 14, 2017 6:31 PM

To: Mary Jo Kochendorfer MaryJo.Kochendorfer@OpenLMIS.org

Subject: Re: New Contribution Confirmation

Hey Mary Jo,

Hope your week is going well …

I did want to chime in a bit on this …

Have you had any dissension around this idea so far? My concern is that the creation of the Rejected state is being driven by improving usability for the users. I think there are alternative ways to improve the usability for the users (i.e. knowing when a requisition has been rejected) that don’t translate to creating a new requisition lifecycle status.

One thing I noticed is that the changes involved in creating this new Rejected status pretty much just line up it up with everything that the Initiated status requires. It seems that maybe ‘Rejection’ is a tangential state of the requisition that is separate from its overall lifecycle state. An initiated requisition is one that may have been rejected or may not have been.

I guess one thing that maybe I don’t have as much context on is what actually happens when someone rejects a requisition? It seems that there should be a next step that would require a resolution of the rejected requisition before it can be submitted. Submitting a requisition that is in a rejected state seems amiss to me. Also, later on in the requisition lifecycle, there is also the ‘In Approval’ and Approval statuses. Doesn’t the possibility of rejection (or maybe not approving) happen here as well?

I know that the team has probably prepared the changes for this change and introduction of the Rejected status already. I just wanted to make sure the VR team (and maybe others in the community) have looked at potential alternatives to doing this as well. If they have, and have agreed that this is the best route, then that works for me.

If any clarifications needed on the above, or if it’s better to post this somewhere on the wiki or elsewhere, please let me know. Cheers,

Chris

On Wed, Jun 14, 2017 at 8:11 AM, Mary Jo Kochendorfer MaryJo.Kochendorfer@openlmis.org wrote:

Dear PC,

In the last meeting, I briefly noted a potential contribution back to the core requisition service. The Malawi team brought up the desire to add a new status, “rejected” to the requisition lifecycle. The proposal is below. We also have notes on what impact the change would have.

Please let me know by 6/15 if you have any concerns with the proposed contribution. I see this change as improving usability for the users by providing useful information to users on where the requisition draft is in its lifecycle. Right now the only way to know if a requisition has been rejected is to look into the comments. We believe this change would allow for more clarity of the true state of the requisition. If I do not hear back, we will merge this contribution.

Proposed Contribution:

Add a status to the requisition draft called “REJECTED” (see the following screenshot which would show the requisition status as rejected). This would be displayed on the “Create/Authorize” screen when the table of periods is displayed. Within the table, it would say the status of the requisition is “REJECTED” if it was rejected. The current status for a requisition draft now are “Initiated”, “submitted”, “authorized”, “In_approval”, “Approved”. This contribution would add an addition status. The impacts of making this change are detailed below.

A list of changes/affected places:

backend:

· submit now allows the requisition to be both in initiated and rejected state

· reject now marks the requisition as rejected, not initiated

· delete requisition allows deletions of rejected requisitions

· periods for initiate include requisitions with the rejected state as well now

· permission checks were updated such that they allow user to work on rejected requisitions if they have initiate/submit rights

· skipping the entire requisition is possible both for the initiated and rejected status (if enabled)

· two error messages were updated to reflect the new requisition status

UI:

· skip period button is visible for the rejected state now (if enabled)

· when display periods for initiate, the UI also looks for rejected requisitions

· submit button on the requisition form is now displayed for rejected requisitions

· delete requisition button is now displayed for requisition in rejected state

· skip requisition button is now displayed for requisition in rejected state

· sync with server button is now displayed for requisition in rejected state

No impact on

· Audit logs behaves the same way it did, the only difference being the ‘REJECTED’ status being displayed, rather than ‘INITIATED’ for rejected requisitions.

· Reports since reports are run on requisitions in the “Approved” stated. We have yet to identify a report were we’d see an impact with this new status. @Ashraf please do let us know if we missed a report in our analysis.

You received this message because you are subscribed to the Google Groups “OpenLMIS Product Committee” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis_product_committee+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis_product_committee@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis_product_committee/DM5PR02MB237752F6F9410ADD5E9906E581C30%40DM5PR02MB2377.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

Chris George | ThoughtWorks | Skype: cfgeorge

Chris George | ThoughtWorks | Skype: cfgeorge