2017-05-23 Meeting notes

• Performance test report: https://docs.google.com/spreadsheets/d/1R9HcYBIAUki5KnM7pytRK3y4bdvhUEU8KvKuZLMosBA/edit#gid=0
• Performance bottleneck: caused by SOH calculation
• Performance benchmark
• Potential solution: doing the pagination at the back-end
• Potential solution: modifying the search to directly search the database versus the client cache
  
  • Client may be stressed because they wouldn't understand why they don't see all the products right away.

Potential Solution:
1) Remove the front-end validation, the validation only happens at the backend but the error message we display would be more exact. For example, it would tell user which product is incorrect. TW will go with option1 first.

2) Make the front end validation same as the back end. Whenever the user adds a new line in the table, we would call the backend API and do the backend validation. This solution might not only dramatically impact the performance as it would frequently communicate with the server but also cause the usability as it would load for doing the validation check.
3) Forbid user to choose past date when they are doing the inventory/adjustment/receive/issue instead there would be a new page for user to do the SOH correct. Refer to https://openlmis.atlassian.net/wiki/display/OP/Correcting+stock+movements

Brandon Bowersox-Johnson Could you help us design the correcting stock movements process.

• Deactivate Products Process
• Make an issue/receive