10 min
- Discussion about a business case that would cause SOH be negative integer
- MJ: We also need to discuss the example of issuing stock when SOH is at zero at the time of issue.
Josh's thoughts and questions:
- a functional requirement here that lays out the first simple configuration: are negative SoH balances allowed as a result of adjustments or not. How, technically, will this be configured, how will this rule (aka policy) be enforced on the server-side and communicated to the client-side?
Longer term I think we should start thinking about:
- I would expect that whatever an implementation wants to do, the rule(s) (or policy) is defined once and shared for both the front and back-end. We need to start defining how that rule would be shared, and what the basic parameters are:
- is negative SoH even allowed: yes/no
- if negative is allowed, is the user prompted before syncing: yes/no
- how long can a negative SoH be allowed before alerts are sent (and to whom): is this a matter of hours? days? a function of the processing periods?
- what kind of scheduler would we need to send those alerts, and how would we use it with the negative SoH rule (policy)?
- After that I'd expect this rule to be configurable by perhaps Program, Facility, etc.
- I would expect that within a Program, the rule (or policy) could change over time, how would that be done (Fowler has a class diagram of how the active policy is found by date - likely the date a person says they did something to stock)
- I would expect that whatever an implementation wants to do, the rule(s) (or policy) is defined once and shared for both the front and back-end. We need to start defining how that rule would be shared, and what the basic parameters are:
Decision: bring to PC. Get decisions on the above questions. Share with team and start designing.
- What would be the permission for the read API
- Do we need the write API for source/destination configuration
Permission discussion
- Familiarize with RBAC
- Security
- Role based access control approach - user wants to create a stock event
Read API will be done first.
Questions: Should the write API support batch and individual sign in creation?
Decision: Need further discussion on the configuration of Sources/Destinations. How does a facility know who their valid sources and destinations? We should review and look into supply lines within requisitions. We know the hierarchy will be different than requisitions.
Approach: VR suggests creating the write API while doing the read API, however leave out the business logic and outline all the questions to be addressed for configuring the new facilities.
- All reasons belong to the full reason list, can we merge these two stories? Yes
- What would be the permission for the read API,
- Do we need the write API for source/destination configuration
Decision: create a new view right under the supervisory right type and a new view right under the general_admin right type
- As for an event which includes the facility type ID and program ID, do we need to check if that facility type supports that program ID?
Do we need to support the extensible for reason type and reason category? This request is coming from Fisheye review.
- Onboard materials for QA?
- Any defined QA process/test process we should follow?