Date

25 Oct 2016

4pm-5pm PDT

Attendees

Meeting link

https://www.uberconference.com/richmagnuson

IP audio, or Dial-in: 1-716-293-9263, meeting PIN: 60307

Goals

Discuss the Beta release - this is the last call before Beta is published
Provide feedback on extensibility
Discuss where 3.0 planning is and how this committee wants to be informed

Discussion items

Time	Item	Who	Notes

Notes

A productive discussion on Extensiblity, Beta and our current plan for a useful extension example occurred. Out of that discussion Elias shared a real scenario to ask how these mechanisms and the community would be utilized to avoid a fork. The scenario:

There are two organizations supplying commodities in country: MSL (ministry) and CHAZ (charity). Of these most of the commodities in a requisition will be supplied through MSL. However for a few of these commodities (5-6), and only at some facilities in the country, CHAZ will actually supply those commodities. The requisitioning facility will fill out one Requisition and submit it and have it authorized. When the district supervisor goes to approve it however, they will essentially be creating two orders: 1 for MSL which will fulfill the regular commodities, and 1 for CHAZ which will fulfill just a few of the commodities.

This workflow introduces a number of important changes:

- the concept of a Supplying Partner is introduced to distinguish MSL supply lines and commodities from CHAZ supply lines and commodities.
- an Approver would want to see in the UI what quantities they we're approving based on the Supplying Partner that will fulfill them
- an Approver is essentially creating not 1 order, but potentially many (or 2 in this case)

In briefly discussing how the mechanisms would apply, we thought:

a new entity would need to be introduced
the UI would need updating: showing supplying partner for commodities (what gets fulfilled by whom), config, etc
would need to use extra data on facility/product to indicate supplying partner responsibility
convert to order would need to allow 1 requisition to end up as multiple orders

How this is actually addressed should be fleshed out and discussed in future meetings.

Action items

Elias Muluneh to go over notes on the scenario and ensure the detail is enough and correct
Josh Zamor (Deactivated) to organize how the architecture would address the scenario and lead discussion on findings at next call - I've added a ticket for this: OLMIS-1234 - Getting issue details... STATUS
Josh Zamor (Deactivated) to create a new calendar invite
Josh Zamor (Deactivated) to either amend existing ticket or create a new one that puts out documentation on timing
Darius Jazayeri (Unlicensed) to talk to community members in China about participation, times and potential for including team in Poland