search

msupply-foundation / mobile

Open source mobile app for medical inventory control
http://msupply.org.nz/mobile
Other
43 stars 27 forks source link

Program based Customer Requisitions #3128

Closed josh-griffin closed 3 years ago

josh-griffin commented 4 years ago

Is your feature request related to a problem? Please describe.

JSI Require program-based customer requisitions. Problem is, they're not implemented, yet.

Describe the solution you'd like

Main tasks overview:

Google sheet for columns spec: https://docs.google.com/spreadsheets/d/1sEiR9BTVQJ52kLPoVjMGOi8EghRRSTHkDlYkkNUDV20/edit#gid=0

Implementation issues:

josh-griffin commented 4 years ago

@craigdrown @andreievg

First question before moving forward anymore: Is this for normal customer based requisitions, or program based also?

craigdrown commented 4 years ago

@joshxg program based, as need to access MOS targets from program data

craigdrown commented 4 years ago

@joshxg The requirement for a "date created" field: suggest we use requisition.date_stock_take (which is correct- that's the date that is relevant, seeing the form is a stocktake). Default to today, but editable. Thanks. (n.b. There is another "Date requisition entered" field that is not editable and auto-populated)

josh-griffin commented 4 years ago

@craigdrown @andreievg

program based, as need to access MOS targets from program data

Of course, thanks.

Assumptions from this, correct me if wrong:

When creating a program based customer requisition, select:

Next question:

craigdrown commented 4 years ago 
* Don't exclude _any_ name (Thought this would be Customer names types who are not patient)

@joshxg that was implied ;-) - so yes, any visible customer who isn't a patient. Order type: default to normal until there's been a normal order already in the period, then default to emergency?

andreievg commented 4 years ago

A program [Found through [name] -> [name_tag_join] -> [name_tag] -> [list_master]programSettings.storeTag]

Also, only use list_master linked to the name.

Are we implementing the ability for all users to create a normal customer requisition, if there are no programs defined?

I don't see this being a use case for JSI requirements (name should still be selectable but message that no programs are linked to the name)

For Ivory Coast we are allowing response/customer requisitions being made for name that are also stores, I feel ify about this. Would suggest 'yes' but with a visible warning.

josh-griffin commented 4 years ago

Thanks!

The requirement for a "date created" field: suggest we use requisition.date_stock_take (which is correct- that's the date that is relevant, seeing the form is a stocktake). Default to today, but editable. Thanks. (n.b. There is another "Date requisition entered" field that is not editable and auto-populated)

This will be newly added to mobile: "Today" being the date the requisition is first created? Is there validation on valid dates? (Not before 'today'? Not before 'date requisition entered'?)

Do we want to add migration code to update all past requisitions? (Assume: No)

Order type: default to normal until there's been a normal order already in the period, then default to emergency?

👍

I don't see this being a use case for JSI requirements (name should still be selectable but message that no programs are linked to the name)

Still not clear on the behaviour for when there are no programs defined (Current supplier requisition: Add requisition has two behaviours dependent on if there are any programs defined: Open program modal to create a program-based requisition, or not. Current customer requisition: can't create at all) at all (Behaviour for our existing users) - able to create non-program based now? Or, if you don't have programs defined, still can't create?

name should still be selectable but message that no programs are linked to the name

Sure, can do. Just FYI: for supplier requisition there is a toggle on the modal: Program/General, and you select the program first. So, the supplier would not show up, you would have to go to the General tab.

For Ivory Coast we are allowing response/customer requisitions being made for name that are also stores, I feel ify about this. Would suggest 'yes' but with a visible warning.

So, when creating a customer requisition for a [name] which is both a customer and has a related [store] record (Is there some other field which indicates this?), show some sort of warning note: mobile does not currently store [Store] records

josh-griffin commented 4 years ago

Questions from email: Re: UNFPA Mobile Work by 30 November 2020

Months in period: technically (Days in period / Days in month) - I think we’ve standardised on “365/12” for days in a month?

Mobile uses 30 days for a month.

Possible options:

josh-griffin commented 4 years ago

@andreievg @craigdrown @Chris-Petty

Trying to conclude/summaries meetings/discussions/specs/requirements/whatever:

Main task list:

Customer Requisitions Page [List of all customer requisitions]

CHANGES:

Button

Table

Additional Column:

By Program Modal

Customer Requisition Page

NAVIGATION

SYNC

Table

Row Press

Filtering

Toggle

Columns

Buttons

Page Info

Modals

Finalizing

Desktop Upgrade:

NOTE: Will need to retest Supplier Requisitions Page, By program modal specifically to ensure behaviour is the same with the small refactors to using name_tag

andreievg commented 4 years ago

Thanks for that Josh, it's looking good, a few comments, what do you think ?

Customer Requisitions Page:

By Program Modal

NAVIGATION

Can navigate to this page through the customer requisitions page (clicking on a row) when the customer requisition has a PROGRAM related

Not sure what this means, can currently navigate to customer requisition when clicking on a row (why the extra `when the customer requisition has a PROGRAM related ?)

Toggle

Toggling between the column sets correctly displays values/rows (enter a quantity in a row for a column, then toggle the column set and toggle back - the value should still be set)

I would imagine toggle will just be toggling visibility ? i.e. rows position etc will still be the same ?

Toggle and extra columns view only visible when requisition is program requisition ?

Column set A: [Item Name, Item Code, Current Stock, Their Current Stock, Monthly Usage, Suggested Quantity, Requested Quantity]

Column set B: [Item Name, Item Code, Supply This Invoice, Days out of Stock, Opening Stock, Closing Stock, Adjustments, Receipts, Consumption]

My vote is to keep existing 'view' and add another 'toggle' view for extra bits (probably start with extra bits for program requisitions ?) https://docs.msupply.foundation/en:mobile:user_guide:customer_requisitions, requested quantity editable.

Thus the extra view becomes: [Item Name, Item Code, Opening, Incoming, Adjustments, Issue, Closing, DOS, Requested]

THIER STOCK = closing balance

Columns

Current Stock

Header name: Our Current Stock

Just Our Stock Right ?

Their Current Stock

Header Name: Their Current Stock

Maybe :

Their Stock
(Closing)

Also not editable (calculated)

Supply This Invoice

Just FYI shouldn't need to make any changes here

Receipt

Default: Sum of all TransactionBatch.totalQuantity where TransactionBatch.transaction === 'customer_invoice and TransactionBatch.transaction.otherParty === the customer for this requisition

This would be for the period of the requisition ?

Consumption

Desktop Upgrade:

All [store] records

Hmm not sure why

The [name]

Would assume this is the name of the mobile store ? Was wondering why.

Also I am not 100% sure how programs are 'integrated' in sync, so would just want to add that if only mobile stores's program setting are currently integrated, we would need to change that and would need to

NOTE: since we are changing to name_tag throughout the app for programSettings, would suggest, adding logic to check storeTag and nameTag on program settings. (i.e. if/when we move to programSettings.nameTag, no extra work would be required on mobile).

Data Entry Validation:

We want to restrict negative closing stock calculation (starting + incoming -/+ adjustments - issue = closing), this would mean restricting input on starting, incoming, adjustments, issue. How do we warn user about it ? M

Do we have ability to enter negative numbers btw ? Would it be easier to have two columns for adjustments ?

Editable non editable

I was hoping that the normal column set (exist one), would still remain as is, there is an editable column there though 'requested', was wondering if it's bad UI practice to allow it being editable in one place and not the other.

So the idea was to have editable fields in the 'first' toggled column set, this is basically the part where users goes through and inputs data from the paper based form, they then can switch to second column set and do the issue part.

Calculations

The reason to put closing balance in the first column set was to show the calculation of closing stock while data entry happens (and to help them with validation issues). This would mean the toast for validation error might need to say the formula, and the numbers that are used.

AMC calculation won't be visible anywhere, would be great to help user see the AMC calculation when row is pressed (in a modal)

josh-griffin commented 4 years ago

Was wondering if we need a way to distinguish between Requisitions entered vs received via sync

We don't for any other page. I think it's a good idea but a little out of scope for this feature?

Not sure what this means, can currently navigate to customer requisition when clicking on a row (why the extra `when the customer requisition has a PROGRAM related ?)

Not sure either. Oops

I would imagine toggle will just be toggling visibility ? i.e. rows position etc will still be the same ?

This is what I am trying to describe in the test case - to be tested for: Ensuring we are not losing values entered when toggling between

Toggle and extra columns view only visible when requisition is program requisition ?

Cool, yup

Thus the extra view becomes: [Item Name, Item Code, Opening, Incoming, Adjustments, Issue, Closing, DOS, Requested]

Cool - I think I got a little confused :)

Just Our Stock Right ?

oops, thanks

Maybe : Their Stock (Closing) Also not editable (calculated)

Cool

This would be for the period of the requisition ?

Yup. Adding clarity, thanks

All [store] records The [name]

Also I am not 100% sure how programs are 'integrated' in sync, so would just want to add that if only mobile stores's program setting are currently integrated, we would need to change that and would need to

Not 100% sure on what this means, but we store programSettings as a string on every master list record, and we have all master lists on mobile

We want to restrict negative closing stock calculation (starting + incoming -/+ adjustments - issue = closing), this would mean restricting input on starting, incoming, adjustments, issue. How do we warn user about it ? M

Yeah this is tough - my only suggestion is Toasts at the moment!

Do we have ability to enter negative numbers btw ? Would it be easier to have two columns for adjustments ?

Negatives will be fine

was wondering if it's bad UI practice to allow it being editable in one place and not the other.

I think for preferences, where the user will not really know of 'the other way' it is OK?

This would mean the toast for validation error might need to say the formula, and the numbers that are used.

Sure - although the toast doesn't show up for that long, to fully understand I think it will have to do, for now, and we can try to think of better solutions..?

AMC calculation won't be visible anywhere, would be great to help user see the AMC calculation when row is pressed (in a modal)

Can do

josh-griffin commented 4 years ago

Tried to make this easy to read.. I didn't know what platform to use. It's a lot of information, so it's hard. Might be easier to edit this comment -> copy + paste into VSCode - it seems more nicely formatted there or a pdf..: reqs.html.pdf .... or a google sheet: https://docs.google.com/spreadsheets/d/1sEiR9BTVQJ52kLPoVjMGOi8EghRRSTHkDlYkkNUDV20/edit#gid=0

🤷

Updated columns:

For saving values:

Column Column Set Header Editable Validation rule Default calculation aligned Mobile field Desktop field comment
Our Stock A Our Stock No N/A N/A Sum of all the underlying items item batch numberOfPacks * packSize right N/A N/A
Their Stock A Their stock No N/A N/A open + incoming + outgoing + adjustments right RequisitionItem.stockOnHand [requisition_line]stock_on_hand
Monthly Usage A Monthly Usage No N/A N/A Consumption / (Days in period / (365/12)) * (Days in Period / (Days in Period-Days out of Stock) ) right RequisitionItem.dailyUsage (Divided [requisition_line]daily_usage Multiply by 365/12 when displaying in the UI
Suggested Quantity A Suggested No N/A N/A Math.ceil(Math.max(this.dailyUsage*daysToSupply - this.stockOnHand, 0) right N/A [requisition_line]suggested_quantity This is calculated at sync time
Supplied Quantity A Supply This Invoice Yes - Not finalised - Positive integer - Cannot exceed the amount of available stock. 0 N/A right RequisitionItem.suppliedQuantity [requisition_line]actualQuan
Opening Stock B Opening Yes - Not Finalised - Positive Integer - Must be >= (incoming + outgoing + adjustments) Equal to the Closing Balance of the most recent requisition in the last* period N/A right NEW RequisitionItem.openingStock [requisition_line]previous_stock_on_hand Guessing the mSupply column.
Days out of Stock B Days out of Stock Yes - Not Finalised - Positive Integer - 0 >= DoS <= number of days withing period.endDate - period.startDate 0 N/A right NEW RequisitionItem.daysOutOfStock [requisition_line]DOSforAMCadjustment Is that camel case? hehe
Receipts B Incoming Yes - Not Finalised. - Postive Integer - Must be >= opening + outgoing + adjustments Sum of all TransactionBatch.totalQuantity where TransactionBatch.transaction === 'customer_invoice and TransactionBatch.transaction.otherParty === the customer for this requisition for all TransactionBatch where TransactionBatch.transaction.confirmDate >= requisition.period.startDate and TransactionBatch.transaction.confirmDate <= requisition.period.endDate N/A right NEW RequisitionItem.outgoing [requisition_line]Cust_stock_order Guessing!
Consumption B Outgoing Yes - Not Finalised. - Positive Integer. - Must be <= (opening + incoming + adjustments) 0 N/A right NEW RequisitionItem.consumption [requisition_line]adjusted_consumption Guessing!
Adjustments B Adjustments Yes - Not Finalised. - Positive/Negative Integer - Must be >= (opening + incoming + outgoing 0 N/A right NEW RequisitionItem.adjustments [requisition_line]Cust_loss_adjust Guessing.
Closing Stock B Closing No N/A open + incoming + outgoing + adjustments right RequisitionItem.stockOnHand [requisition_line]stock_on_hand Duplicate of Their Stock column
Requested Quantity B Requested Yes - Not Finalised - Positive Integer 0 N/A right RequisitionItem.requiredQuantity [requisition_line]Cust_stock_order
josh-griffin commented 4 years ago

Sorry - it's all just clicking now - been doing temperatures and vvm status' for too long:

Have:

Opening: 20 Incoming: 10 Outgoing: 30 Closing: 0

If I edit opening: Opening: 2 Incoming: 10 Outgoing: 30 Closing: -18

Will need to 0 out opening, incoming and outgoing - or, at least outgoing, but that's a bit weird isn't it? Probably just 0 them all out and be done with it..!

josh-griffin commented 4 years ago

const daysToSupply = ((monthsLeadTime || 0) + (maxMOS || 1)) * 30;

A little unsure on behaviour here for customer requisitions.

andreievg commented 4 years ago

Was wondering if we need a way to distinguish between Requisitions entered vs received via sync

We don't for any other page. I think it's a good idea but a little out of scope for this feature?

The only reason was to make sure program requisitions that are coming from other stores, can't be edited (apart from the usual supply quantity). We did something like this originally fort supplier invoices (when they come through sync can't delete lines), not sure if it's there still.

Threshold MOS: Does this play a role with customer requisitions? Should it be saved to the thresholdMOS field and we introduce a toggle, or leave it out?

I think leave it out for now, not part of JSI requirements, but does introduce some inconsistency in how we do it in mobile/desktop and supplier/customer, maybe we can just make an issue to flag it as something to look at later. Same with months lead time.

Will look at the spreadsheet soonish

andreievg commented 4 years ago

As per telegram chat:

Validation

Auto validation would be hard to get right, so maybe allow negative closing stock, but have an indication on the row that it's wrong and don't allow finalisation (maybe in finalisation error modal can show more info about rows/formula).

Indication on the row

andreievg commented 4 years ago

Are we needing to implement Indicators?

Regimen data ? Nope

josh-griffin commented 4 years ago

Have played around this as an implementation - will also validate when trying to finalize. All good?

validation

josh-griffin commented 4 years ago

Also: looking for better names for columns/data entry!

andreievg commented 4 years ago

very cool!