(refactor) Stock distribution

[DedrickEnc]

TO PATIENT

1. Strange behavior when the user provide a bad patient code or name (mostly related to the component it self)

2. the code is ambigious, can't we find the good translation?

3. The module should load only lot which are not empty

4. The expiration date should be presented as a moment to help user guess easily

5. Is the amount necessary?

6. If the quantity is exagerated, the amount content desapper and no way to submit but no message (confusing)

7. No need of descritption on the receipt paper, because it for intern use the patient don't care about it

8. Instead of gestionnaire stock, let's use just pharmacy because this operation can be performed by an employee who is working at the pharmacy during this specific time. (???)

TO SERVICE

1. No description is needed for the receipt, it is for an internal use

2. Use pharmacy in signature field (???)

3. the expiration date should be a moment and not a date

TO DEPOT

1. The two big actions of sending and receiving should be clearly separated and implemented in the system to avoid errors or mistakes. a distribution between depot X and Y should happen like this :

• The depot X user send items to depot Y and update his own depot state (decreasing his stock only)

• The depot Y user see the transfer and confirm/ignore/update(?) it, so that, his own depot state is updated by him self (increasing stock only or nothing)

N.B :

• The sender (depot X) can cancel the transfer until the depot Y user has accepted it.
• As consequence, no sent items can be used at the destination depot before an explicit confirmation of the depot Y user.

2. Changing the unit price and reloading the page after, breaks the module.

PERTE

1. after using this module, I have found some negative number in the stock

These points can be discussed to find which point to focus on

[sfount]

Regarding transfers from depot to depot - I agree that this action should be clearly separated into an entrance and an exit.

For the most basic version I propose that we simple allow generic exits and entries of stock to 'Depots' - without the need to tie these together into movements.

This would involve:

• Adding a 'Depot' option to the stock entry module - this will allow separate stock entry from stock exit. For the first version this does not have to link the exit from another depot - this link between exit and entrance could be added by specifying the ID of the exit in the future.
• Removing the implicit entrance to the second depot from a stock exit to depot. This movement will now just be an exit.

I think with these two changes we can effectively separate stock movement into an exit and an entry - allowing the enterprise to have two clear documents and only adjusting stock levels when items actually arrive in the depot.

[DedrickEnc]

This is how the transfer depot to depot can be performed :

Stock Exit from depot A

Main goal : The depot A should only update his stock

User Interface : The user interface should not change

Technical Information : The operation performed from the depot A for the transfer, will add record (s) to the movement table, these records will be there just to signal the exit of stock from depot A.

Shadow Zone : Will we allow the transfer discard?
Output : A receipt (Bon de sortie) to confirm the exit of stock from depot A to depot B

Stock Entry from depot B

Main Goal : The depot A will be responsible of updating his stock him self, and the user from the depot should record physical stock quantity received.

User Interface : An option should be added to the stock entry page (Transfer Reception for example), when clicked by the user :

• A dialog should appear with the list of uncompleted movement from depot X (where X is a depot different than depot B) to depot B
• Filter can be added to see uncompleted movement in different way
• A user will choose one movement at time and submit
• The full information of a selected uncompleted movement will be filled in the grid of the main interface to let the user do some eventual modification
• The user will submit the grid

Technical Information :

• The operation performed by the user from the depot B, will add record(s) to the movement table, to signal the reception of stock in depot B.
• Each movement has a document Id so, this document should be the same for the reception

Output : A receipt must b printed (PV de reception) to confirm the stock reception from depot X (where depot X is different than depot B) to depot B.

Any thought ?

[sfount]

@DedrickEnc This proposal sounds good to me - separating the entrance and the exit will allow enterprises to run this system much more flexibly.

For the first version I do not think we need to have an idea of a 'uncompleted' movement - we could just show all of the movements to that depot with an option to show all movements to all tables. As long as the date and the ID of the movement is clearly shown users should be able to select the correct one.

In the future we could potentially allow users to mark movements as 'complete'.

This proposal sounds good to me 👍

[jniles]

@DedrickEnc,that was very well-written proposal!

Just to be clear, between the comments by @sfount and @DedrickEnc ... can we still transfer an amount X into depot Y, even if no previous exits exist?