# Manage planning issues with stock quantity
**URL:** https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486
**Category:** Feature
**Tags:** stock
**Created:** [November 24, 2020, 5:17pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486 "2020-11-24T17:17:52Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [November 24, 2020, 5:17pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/1 "2020-11-24T17:17:52Z")
## Rational
We have the `sale_stock_quantity` module to check if the sold products are/will be available in stock. And we have the `stock_supply` modules to automatically supply the stock when needed. This works well until there is a delay somewhere in the supply chain (a supplier that does not deliver on time, the production that is blocked etc.).
The only tools we provide for now are:
- “Products by Warehouse”: provides an overview of where there could be problem but user need to change the date to see each forecast.
- “Product Quantities by Warehouse”: provides a fast way to detect stock level issue for the selected product.
- “Stock Moves by Warehouse”: helps to choose which moves of a product to reschedule.
As we can see, we do not help the user finding where are the problems. We provide only tools to analyze the problem.
So we need a tool to spot for the user which shipments or productions have issues with the stock level of the warehouse for their planned date.
## Proposal
We create a new module named `stock_quantity_issue`.
Checking if a shipment or production have enough stock level is an expensive operation and it will be very complex to make a searcher so we propose to have a scheduled task that will loop over each goods. For each good it will search for negative quantity on the warehouse up to the next supply date. For each move in the dates found, it creates an issue grouped per origin and include the move.
On each run the task will mark as solved all the previous non-solved records if possible otherwise it will use the issue to complete with possible new moves.
The user may mark a record as solved to clear it from the list if all the moves linked have a positive quantity.
The model `stock.quantity.issue`:
- origin: Reference of `stock.shipment.out`, `stock.shipment.in.return`, `stock.shipment.internal`, `production`
- planned\_date: Computed from the shipment or production
- moves: Many2Many to `stock.product_quantities_warehouse.move`
- state: `open`, `processing`, `solved`
- processing\_by: the employee who is trying to solve the issue
- solved\_by: the employee who marked the issue as solved
## Implementation
- [Reports stock quantity issues (#9944) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue9944)
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [November 24, 2020, 5:40pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/2 "2020-11-24T17:40:25Z")
This sounds like a very interesting feature!
> [@ced](#):
>
> On each run the task will mark as solved all the previous non-solved records if possible otherwise it will use the issue to complete with possible new moves.
I’m wondering if it won’t be better to just delete the `open` moves when recomputing the issues like we do por purchase and production requests. This will easy the regrouping but will also delete the issue if it has been fixed (for example by rescheduling the shipment to a date in the future) wihtout marking the issue as solved.
Solving the issue will perform any changes to the origin, or it will just mark the issue as solved?
> [@ced](#):
>
> planned\_date: Computed from the shipment or production
I’m wondering if we just need the date of the issue: As the planned date may be modified we may be interesting on knowing when the issue has raised (and probably also when and who has solved it).
---
### Author:  [@dave](https://discuss.tryton.org/u/dave)
#### Post date: [November 24, 2020, 5:49pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/3 "2020-11-24T17:49:22Z")
Is this module intended to just handle issues relating to supply and stock levels? If so I think it might be better if it was called `stock_supply_issue` or `stock_quantity_issue`.
Having stock that is falling apart is an issue with the stock, but I don’t think it is what this module is about?
---
### Author:  [@nicoe](https://discuss.tryton.org/u/nicoe)
#### Post date: [November 24, 2020, 5:50pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/4 "2020-11-24T17:50:39Z")
> [@ced](#):
>
> We create a new module named `stock_issue` .
I find that the name do not convey well what the module does.
What about `stock_supply_issue_detection` ?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [November 24, 2020, 6:39pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/5 "2020-11-24T18:39:16Z")
> [@pokoli](#):
>
> I’m wondering if it won’t be better to just delete the `open` moves when recomputing the issues like we do por purchase and production requests.
I think it is good to keep track of the issue and who worked or solved.
> [@pokoli](#):
>
> Solving the issue will perform any changes to the origin, or it will just mark the issue as solved?
It will just make the issue as solved. But this can only be done if all the moves have a non-negative quantity.
> [@pokoli](#):
>
> As the planned date may be modified we may be interesting on knowing when the issue has raised
I do not think it is a useful information. User will use this date just to prioritize the work.
> [@dave](#):
>
> Is this module intended to just handle issues relating to supply and stock levels?
It is not related to supply modules.
> [@dave](#):
>
> stock\_quantity\_issue
Maybe but I think it could also be the base for future issues like capacity issue.
> [@nicoe](#):
>
> What about `stock_supply_issue_detection` ?
It is not related to supply modules and it is not only about detection but also tracking and solving.
I though about `stock_shipment_issue` because it is mainly related to shipment. But we have also the production case which indeed is almost a shipment.
---
### Author:  [@2cadz](https://discuss.tryton.org/u/2cadz)
#### Post date: [November 25, 2020, 6:59am UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/6 "2020-11-25T06:59:58Z")
indeed, it is necessary to be able to indicate to the user where the problems are. I think we should also tell him if he can deliver faster. These are the two sides of the same question: on what real date will I be able to deliver?
Doing what is necessary to have the material on the scheduled date is essential, and being able to indicate whether it will be possible to deliver earlier is more than few software offers.
So for me the nub of the matter is the delivery date, knowing the most probable / possible delivery date (whether late or early) is an essential indication for the life of the company.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [November 25, 2020, 10:50am UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/7 "2020-11-25T10:50:38Z")
> [@2cadz](#):
>
> indeed, it is necessary to be able to indicate to the user where the problems are.
The information are on the `stock.product_quantities_warehouse.move`.
> [@2cadz](#):
>
> I think we should also tell him if he can deliver faster.
The current planned date is already the earlier possible because it is what was agreed at the sale.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [November 25, 2020, 11:00am UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/8 "2020-11-25T11:00:38Z")
> [@ced](#):
>
> The current planned date is already the earlier possible because it is what was agreed at the sale.
Indeed we could imagine having a similar module but for optimization. It would loop on waiting shipments and try to find an possible earlier planned date that works for all moves. And then it creates a record to propose the optimization. Of course there should be a check that the optimization is still valid before being applied.
But this is for another topic.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [November 25, 2020, 11:29am UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/9 "2020-11-25T11:29:21Z")
> [@ced](#):
>
> > [@2cadz](#):
> >
> > indeed, it is necessary to be able to indicate to the user where the problems are.
>
> The information are on the `stock.product_quantities_warehouse.move` .
Does it make sense to show (or at a relate) to allow the user to easly see where the problems are from the issue?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [November 25, 2020, 11:54am UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/10 "2020-11-25T11:54:23Z")
> [@pokoli](#):
>
> Does it make sense to show (or at a relate) to allow the user to easly see where the problems are from the issue?
I do not see what you want to show more than `stock.product_quantities_warehouse.move` ?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [November 25, 2020, 12:21pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/11 "2020-11-25T12:21:34Z")
> [@ced](#):
>
> > [@dave](#):
> >
> > stock\_quantity\_issue
>
> Maybe but I think it could also be the base for future issues like capacity issue.
I think I will go with this one because:
- capacity issue will have to be stored in a different model because it requires different data
- it creates a similarity with the name `sale_stock_quantity`.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [December 15, 2020, 6:00pm UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/12 "2020-12-15T18:00:07Z")
Here is the implementation [Reports stock quantity issues (#9944) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue9944)
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 24, 2022, 6:00am UTC](https://discuss.tryton.org/t/manage-planning-issues-with-stock-quantity/3486/13 "2022-10-24T06:00:08Z")
This topic was automatically closed after 12 days. New replies are no longer allowed.