Backlog prescription entry

GaryWilletts commented 4 months ago

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

This request has been raised by PLM in Sierra Leone. In some hospitals and other facilities, prescriptions are entered as a backlog, on a day different to when they were actually dispensed, either because staff are not available or because the number of people coming to the dispensary is too large to keep up. This can mess up reports and they get more messed up the bigger the time difference between when the prescription was dispensed and when it ws entered into the system.

Describe the solution you'd like 🎁

To be able to choose the confirmation date to be some date in the past, maybe with limits. But making sure that it doesn't cause ledger issues by using stock that wasn't in stock on the confirmation date - so some sort of checking required on confirmation date selection and on line added to prescription (or on OK button).

Describe alternatives you've considered 💭

Only the above.

Additional context 💌

PLM will pay for this work if it's a reasonable cost.

Agreed Solution 💌

Only allow stock to be issued that has arrived before the 'CI' (outbound :-) ) confirmed date.

Moneyworks Jobcode 🧰

GaryWilletts commented 4 months ago

@mark-prins I need some sort of cost for this for PLM to decide whether to proceed. Would that be possible? Let me know if you need more info to work out what you'll do.

craigdrown commented 4 months ago

@mark-prins we have done a lot of work in OG to stop user errors - @ujwalSussol can fill you in on that.

ujwalSussol commented 4 months ago

@mark-prins we have done a lot of work in OG to stop user errors - @ujwalSussol can fill you in on that.

Thanks @craigdrown

@mark-prins @GaryWilletts :

mSupply OG was perfect, it allowed users to enter backdated invoices...
For example for place holder lines, you could introduce them on a CI line and used a more recent suppliers to full-fill them at a later date....
Problem at certain points : mSupply showed calculate stock as negative as some Ci had stock that had hadn't been received yet --- i.e the Ci had future stock.
East Timor was one of the clients to complain.
Work done : CI can only be confirmed if the issued stock was received on the Confirm date or before.

On the Telegram comments : I think @mark-prins was planing to make sure that the issues stock has been received before the issued date .... so we are on the right track.

ujwalSussol commented 4 months ago

@craigdrown @mark-prins @GaryWilletts : I have updated the Agreed Solutions : https://github.com/msupply-foundation/open-msupply/issues/3672#issue-2261522683

GaryWilletts commented 3 months ago

@mark-prins bump: I need a cost for this for PLM to decide whether to proceed. Would that be possible? Let me know if you need more info to work out what you'll do.

andreievg commented 3 months ago

Quick summary

15 developer days + buffer

Intro

It sounds like there are a few things to consider from product design persepective. I think the following questions should be considered.

What if there is no stock at the backdated date, do we allow back dating of inbounds shipments, and or inventory adjustment and or stocktakes (there is also inbound and outbound returns, and repacks) ?
Apart from 'ledger' integrity, we also technically have stock info that can change, how importat is it for the historic stock info to be reflected in the invoice line (for the date it's created/finalised) ?
Do we need to help the user by showing which lines (and how much) can be issued (when invoice is back dated)

Minimum UI/UX

To give a ball park figure of estimates, we would need to consider the technical side of some minimum feature scope, which I assume would be: 1 - Able to change delivery and verified date of inbounds shipment (to introduce stock for back dated reduction) 2 - Able to change date picked date and shipped date of outbound shipment/prescription. 3 - Available quantity when searching for item in outbound shipment is adjusted to reflect the picked date 4 - Adjust batches and availability based on the shipment picked date

UI/UX considerations:

For 4, we may need some UI/UX to show current batches available quantities ? Or some way to show the user that some batches exists but can't be issued at that picked date ? (it's pretty real example, as per this issue: https://github.com/msupply-foundation/open-msupply/issues/3835)

For 1 and 2 there might be a need to move things forward rather then backwards, same example as above.

For 1 and 2 when setting to shipped or verified, would need to have a dialog to say when it's being verified/shipped ?

When changing date for existing shipment, and the batch is not available, how do we help the user reconcile this ? For this example I just assume the stock that can't be issue will turn to placeholder lines

Technical considerations:

Outbound/Presription line edit will need to be refactored, to reduce complexity and allow testability in prep for this modification, would suggest consumer based API approach taken in returns.

It's not quite as simple as just looking back and making sure that stock line existed at particular date. We need to double check that stock is available and that it's reduction would not create ledger discrepancy down the line. For example you may have 20in stock now, and the stock line was introduced 20 days ago, so you may assume that if we back date to 19 days it's ok to issue all 20, but stock may have been adjusted up and down, for example:

In this example it's ok:

Days Ago	In/Out	Quantity
20	+100	100
10	-80	20

New

Days Ago	In/Out	Quantity
20	+100	100
19	-20	80
10	-80	0

Here it's not OK

Days Ago	In/Out	Quantity
20	+100	100
15	-90	10
12	+90	100
10	-80	20

New

Days Ago	In/Out	Quantity
20	+100	100
19	-20	80
15	-90	-10
12	+90	80
10	-80	0

There is also some checks for inbound shipment dates that would need to be applied (although we can just dissalow it if stock was already issued)

Estimates

I would think it would take around 15 developer days to do this safely, including the above refactor and adding test cases for existing functionality (this 15 days should include our normal buffer)

Extra

Currently in omSupply I think it's actually possible to cause ledger discrepancy, due to a bug: https://github.com/msupply-foundation/open-msupply/issues/3829

andreievg commented 3 months ago

@ujwalSussol

Work done : CI can only be confirmed if the issued stock was received on the Confirm date or before.

I don't think it's that simple though, as per example in the description above, i managed to create a scenario where we can back data and mess up ledger further down the track

https://github.com/msupply-foundation/msupply/issues/14670

GaryWilletts commented 3 months ago

Thanks @andreievg . Your solution is more than we need here, PLM just need to be able to backdate a prescription while it's being created and not after it's been saved.

andreievg commented 3 months ago

Your solution is more than we need here, PLM just need to be able to backdate a prescription while it's being created and not after it's been saved.

@GaryWilletts oki

I am not sure where this issue goes after that comment, I think more questions. to identify which bits out of the solution are still needed.

1 - Do we still need to be able to introduce historic stock ? That's the inbound shipment back dating. What would be the work around to their workflow if it's not implemented ?

Like mSupply, open mSupply invoice/transact has three 'states', for outbound it's

'new/draft' -> sg (available stock is adjusted)
'picked' -> cn (total stock is adjusted)
'shipped' -> fn (locked for editing)

2 - Does backdate means picked/cn date ? 3 - Is set just once on creation and not edited after ?

If 2 = yes, 3 = yes then the only difference for the solution that we don't need to consider the following:

When changing date for existing shipment, and the batch is not available, how do we help the user reconcile this ? For this example I just assume the stock that can't be issue will turn to placeholder lines

Without the above it's probably 4 days less, 15 - 4 = 11 day(ish).

And then if we don't need to worry about verified/shipped/fn date (it's just set to match picked/delivered/cn date) then maybe another day off the estimate.

GaryWilletts commented 3 months ago

@andreievg

No. No workaround needed. User will only be allowed to select stock lines that were in stock on the date they have selected for the prescription.
Yes, picked date selectable.
Yes.

All clear with your conclusions 👍🏻

GaryWilletts commented 3 months ago

@mark-prins @andreievg Mark had done a separate estimate at 6.8 days for the simpler version of your proposal Andrei. You are both roughly aligned so I told PLM 8 days. Thanks for all the input everyone.

GaryWilletts commented 2 months ago

@mark-prins @andreievg Happy days, PLM have decided to go ahead with this development. Can you tell me which release it will be in please so I can let them know? (there's no hurry, when I said it could be 3 months away they were fine with that).

GaryWilletts commented 4 weeks ago

@mark-prins @andreievg I need an approximate delivery date please, PLM are asking.

mark-prins commented 4 weeks ago

I've got this in v2.3 and we're just coming up to the PR deadline for v2.2 Release date is September 25th for v2.3

msupply-foundation / open-msupply