Open GaryWilletts opened 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.
@mark-prins we have done a lot of work in OG to stop user errors - @ujwalSussol can fill you in on that.
@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 :
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....Ci
had stock that had hadn't been received yet --- i.e the Ci
had future stock.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.
@craigdrown @mark-prins @GaryWilletts : I have updated the Agreed Solutions
: https://github.com/msupply-foundation/open-msupply/issues/3672#issue-2261522683
@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.
15 developer days + buffer
It sounds like there are a few things to consider from product design persepective. I think the following questions should be considered.
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
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
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)
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)
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
@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
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.
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
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.
@andreievg
All clear with your conclusions 👍🏻
@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.
@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).
@mark-prins @andreievg I need an approximate delivery date please, PLM are asking.
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
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 💌
Moneyworks Jobcode 🧰