Simon Lejeune
9439f6aa55
The approach we tried with the current implementation lead to a replay of all the next moves since a move had to be corrected, and posting an account entry with the valuation difference. This proved to be slow and complicated, and moreover the resulting account entry could be very difficult to understand and justify. So we moved away from this strategy and implemented the following points: For FIFO * If a move goes into negative (sent more than availabale, we do not counterpart directly at the next in move: we valued it at the last fifo price and only when running `_fifo_vacuum` (which is called at every openning of the valuation report), we use some units currently in stock and post an account entry with the difference between the fake value and the real one used. * When editing a done move and increasing its quantity, the new quantity is available now and will be used at the next move out. We do not try to replay the history to make the new values go away directly. * When editing a done move and decreasing its quantity, it acts as a return to the supplier at the price unit of the move. On average price: * Don't replay anything, if we fall under the negative stock usecase, value at the last average price. We restore the previous code that set the average price on the standard price and we slightly patch it to continue to update the average price if quantity in stock is negative. We also add a link between stock moves and account moves. A stat button on the stock move's form redirect directly to them. It's therefore a little easier to understand what happened. We remove the separate fifo and average price fields that were added in saas17, we keep the single standard price (that should be renamed cost_price for consistency). In the same idea, remove the cumulated value that was stored on the move. If we need it, just recompute it (it's not a frequent operation). We remove last_done_move_id, last_done_remaining_qty and last_done_qty that were added in saas17 to help in the replay method, as we just got rid of it. We also remove the code that compensate the negative stock directy at the next in. What the fifo vacuum does is essentially the same thing as what an out move do: find a candidate and take units from it. In this case, the candidates are newer than its concerned stock move. We stored on the concerned stock move the value at which we sent it (remaining_value) and post the difference with the real value on a real product.
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, Purchase Management, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
If you are a developer you may type the following command at your terminal:
wget -O- https://raw.githubusercontent.com/odoo/odoo/master/setup/setup_dev.py | python
Then follow the developer tutorials
For Odoo employees
To add the odoo-dev remote use this command:
$ ./setup/setup_dev.py setup_git_dev
To fetch odoo merge pull requests refs use this command:
$ ./setup/setup_dev.py setup_git_review