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)
Decision: bring to PC. Get decisions on the above questions. Share with team and start designing.
Do we need the write API for source/destination configuration
Familiarize with RBAC
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.
Which type of right are the above permissions? Requisitions is based off of program and facility. Admin are global rights. Please make sure to understand the different types so we are appropriately creating the stock management rights.
I haven’t added anything around authorizations here – the PC discussion concluded we might eventually want the ability for someone to audit/confirm a periodic physical stock count, but that none of the other movements need approvals. Since we’ve tabled that for later, I suggest we look at what the rights structure for that story would be while researching the story.
Ashraf had also mentioned sometimes large adjustments/stock movements needing extra information. I wonder if a “stock management_request info” right might be appropriate where the user has the right to send a message to the creator of the movement to provide additional information.
I assume any rights around notifications will be handled by that Epic.
Shiyu Jin (Deactivated), when making stories, please make sure to add the component "Stock Management". Also, let's make sure each story has a fix version indicating the desired release date. Thanks.