Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[IMP] stock, mrp, purchase_stock: Orderpoint #41115
More details could be find in each specific commit.
Move the code from stock warehouse to its own file. [MOV] stock: adapt warehouse and orderpoint files
- lead_days: number of days to add from today in order to define the procurement request date. - lead_type purpose is to define if supplier delays should be added to procurement request date. Those fields are problematic with the onboarding. The purpose is to replace them with an automatic computation. Task 1849912
Orderpoint reference are only set on the first object that is created from the procurement request. However sometimes we would like to access it from further object or define another behavior if we come from an orderpoint. Now that the we propagate the orderpoint_id, it's important to ignore po line with an orderpoint AND a chained stock move, else the quantities will be counted twice by the orderpoint in a 2 steps receipt scenario Task: 1849912
Currently when a procurement fail it will raise a user error. Some function as run in stock_rule catch the errors and merge them in a single error. Also since commit a2a6b09 procurements are executed in batch and in some cases, we would like to have more information about the error. For example in orderpoint we would like to know which orderpoint is responssible for which error. It would also be possible to return an object with the details but procurements pass through a lot of different method that already have their own return signature and a simple exception is easier to manage. Task: 1849912
Currently orderpoint run one request at a time. However it's not efficient since compute are some private methods could be executed one time in batch instead of record by record. Instead of a call to run each time a procurement request is ready, append it to a list and call run with the list of procurements. Task: 1849912
When the scheduler runs, each orderpoint will check the forecast stock for an infinite time. As example, if we plan a receipt of 10 products in 4 months and need to deliver 5 products next month, procurement will not be launched since we have a forecasted quantity of 5. In order to improve it, the orderpoint will compute the total lead days from rules, suppliers/production delays, security days,... Those lead days will be added to today in order to know at which date the forecast stock should be checked and trigger the replenish document for today in order to be delivered at the correct date. Task: 1849912
Create RFQ with an order by date in futur. It will allow to discuss RFQ before validate them and to be in time for the need. today Order by Sheduled date of receipt |_______________|___________________|_____________________| days to purchase vendor LT security days Task: 1849912
When the user set the schedule date and then the moves. The default date expected on the move is today. However two inverse function on picking are trigger. _set_move_without_package and _set_scheduled_date. In the case where _set_scheduled_date is trigger first it will not write the date on the stock_move and the stock_move will be created afterward. In this case the move will have today as date and the picking date will remains in the future. That could be confusing for the user and problematic for the forecast report that are focus on the move date. In order to fix it, set a default_date on move that is equals to the schedule date on its picking. It remains an issue that _set_scheduled_date could trigger after _set_move_without_package and would erase all the manual date from the user. However it could not be fix without involve existing feature nor adding a new button. Task: 1849912
_log_next_activity was on stock.rule and should have been @api.model. So it should rather be on product template but it's probably not necessary to have a function for it since it's only used by orderpoint process.
Since this function become more and more usefull not only through the interface but in backend too. A refactor is needed in order to avoid a wizard creatin in order to modify the quantity.
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments.