Manage planning issues with stock quantity

Feature
1

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

2

This sounds like a very interesting feature!

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?

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).

3

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?

4

I find that the name do not convey well what the module does.
What about stock_supply_issue_detection ?

5

I think it is good to keep track of the issue and who worked or solved.

It will just make the issue as solved. But this can only be done if all the moves have a non-negative quantity.

I do not think it is a useful information. User will use this date just to prioritize the work.

It is not related to supply modules.

Maybe but I think it could also be the base for future issues like capacity issue.

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.

6

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.

7

The information are on the stock.product_quantities_warehouse.move.

The current planned date is already the earlier possible because it is what was agreed at the sale.

8

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.

9

Does it make sense to show (or at a relate) to allow the user to easly see where the problems are from the issue?

10

I do not see what you want to show more than stock.product_quantities_warehouse.move ?

11

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.
1 Like
12

Here is the implementation Issue 9944: Reports stock quantity issues - Tryton issue tracker

13

This topic was automatically closed after 12 days. New replies are no longer allowed.