The main idea of this new implementation is that stock.quant is now a
cache of the quantity per location/lot/pack/owner key. We removed every
identity per record, such as `history_ids` or `inventory_value` so that
we can now avoid the linear creation of stock.quant records and are able
to work with only one record per key.
The algorithms to retrieve the quantity per key are made to work with
multiple records, this way we can implement strategies to workaround
postgres locks if concurrent transactions try to work on the same quant
row.
Quants will not be linked to moves anymore, this is in order to be able
to edit stock moves more easily/freely. We removed the links with this
commit and wipe out the `action_assign` on stock move. This will be
implemented in a followup commit, once the relations between stock.move,
stock.pack.operation and stock.quant are clarified.
This commit seems to have unecessary diff, but it was done in order to
run tests on the new implementation.
We adapt the views by removing the fields not present anymore in the
model. This include the complete removal of the inventory valuation
view, as the implementation of stock valuation will be refactored and
moved on stock.move in a following revision.
We wipe out `action_cancel`, `recalculate_move_state`,
`move_quants_by_lot_v10` and `quants_unreserve`.
* `get_removal_strategy` moved from `stock.move` to `stock.quant`
Stock quant model:
* qty renamed to quantity
* history_ids: because the quants are not moved
* inventory_value: implementation moved to stock.move
* packaging_type_id: doesn't seem to be used (in filters?)
* propagated_from_id: because we do not split forced quants
* reservation_id: because the reservation are not linked to
the stock.move.line
We remove the `lot_ids` computed field, as it depended on the link
between stock moves and quants and could be replaced by a related
to the move lines once the new relation between stock.move,
stock.pack.operation and stock.quant is clarified in a further commit.
Furthermore, the field was not displayed to the user.
Steps to reproduce:
Let's consider product P tracked by serial number
P has a manufacture BOM B with Q as componenent
- Produce P with serial number SN(with MO)
- Send P with SN to a customer A(with SO and DO)
- Force availability on P to a customer B(with SO and DO)
- Return P to stock for customer A.
Bug:
The tracability for P removed the component Q(consumed_quant_ids)
when reconciling the negative quant(generated for B) with the returned
quant from A.
opw:744424
- Set a user with 'User' access rights in Manufacturing and Inventory
- Create 2 products tracked by lot (A and B)
- Receive some quantity of B, define the lots.
- Create a BOM for A, depending on B. The BOM must use routing with at
least one workorder
With the unprivileged user:
- Create a MO for 1 unit of A
- Update quantity to 3
- Plan the MO
- Go in workorders, start working and set the lot numbers for A and B.
- Finish the WO => Access Error
opw-748825
This fix 2e18070a66595a72a9a626a196c97a689832f667 has been done in stable and some customers
wants to keep the button "Post Inventory" available all the time.
Now the button is just visible in developper mode.
opw:748347
In case you have multiple warehouses and/or multiple manufacturing
locations (procurement routes), the same sequence is taken for the
created manufacturing order no matter where it is finally produced.
Closes#17681
opw-748344
Let's consider 4 products P0, P1, P2 and P3 where:
- P0 depends on P1, P2 and P3
- P1 depends on P2 and P3
- P2 depends on P3
NB: "x depends on y" means that there is a phantom BOM for x where
y is in a line.
With this example, before the fix, when creating a MO for P0,
the function "explode" raised a user error saying that there
was a recursion error.
Even if in this case there was no recursion.
Now to check if there is a recursion, a graph of the dependencies of
the bom is created while exploding the boms and a function "isCyclic"
is applied on the graph to verify that there is no cycle which means
no recursion in the dependencies.
The algorithm was taken from this site: http://www.geeksforgeeks.org/detect-cycle-in-a-graph/
opw:745453
Currently, all the methods that start with `get_default_` and `set_` are called on a res.config.settings loading or saving.
This commit purpose is to replace all the occurences of `get_default_foo` and `set_foo`. As these methods won't be called anymore, a warning is logged to notice its deprecation.
The generic method `get_default_fields` and `set_fields` could be improved too. The method names and API are not so good:
Why "default" fields? What you ask for is the current value of the stuff, shown as fields in the model. The values are fed as default values in the wizard, but that's an implementation trick.
Why "fields"? What you ask for are configuration parameters, and such things.
Why passing a list of fields? Its value is never used.
We should further simplify the API of both methods to something like
def get_values(self):
return {}
def set_values(self):
pass
Method `get_default_fields`
===========================
Currently all the methods beginning by `get_default` are used to fetch their default values, usually by looking in the ir.config_parameter table.
As several methods `get_default_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Method `set_fields`
===================
Currently all the methods beginning by `set_` are used to set their values, usually in the ir.config_parameter table.
As several methods `set_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Methods `get_default_foo` and `set_foo`
=======================================
This commit deprecates the method starting with `get_default_` or `set_` in the res.config models. A warning is raised in that case.
Also, correctly reset manufacturing lead time
Settings now correctly use an ir.config_parameter telling whether to
use or not manufacturing lead time. An onchange is added in order to
ensure that lead time is not still used by code although the settings
is unchecked.
When several user run a production on a workorder, things go awry.
For example the end of the "productive" production is computed based on
ProductiveStartTime + DurationExpected - Duration
so if the duration was bigger than the time expected, we easily get a
productive end before the start, and start of the "reduced speed" before
the production actually happened.
eg:
productive time is 30 minutes
user A: start production at 10:00
user B: start production at 10:10
production is set to done at 10:50
=> result before the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has been productive from 10:10 to 10:00
user B has not been productive from 10:00 to 10:50
this is totally erroneous.
=> result after the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has not been productive from 10:10 to 10:50
this is a measure of right, we could argue about wether one or the other
should be productive or not but this is anyway an edge case.
In master we are considering only allowing one user to run a production
at a time but we prefer not to change such a behavior in stable version.
opw-709223
closes#17528
Let's consider P1, P2 and P3 with a cost=1$, three stockable products where
P1 and P2 are in the same product category PC1 with a Stock valuation
account = SVA1 and P3 is in the product category PC2 with a Stock valuation
accout = SVA2. PC1 and PC2 are set with costing method in real price and
Inventory valuation = perpetual(automated).
Steps to reproduce this issue:
-Create a BOM where P3 is composed by 1 P1 and 1 P2
-Create a PO for P1 and P2 with a cost of 5$ for each one
-Create a MO to produce 1 P3
-Check availability
-Insert manually the consumed product(1 P1 and 1 P2)
-The button "Post Inventory" appeared, clicked on it
-Check the general ledger, two moves with debit=5$ has been created
for P1 and P2 in PC1(it's ok)
-Produce the MO and click on "Post Inventory" again
-Check the general ledger, two moves have been created, one with a credit of 2$
on PC1 and one of debit of 2$ on PC2(it was wrong)
The expected moves for the last step is:
a credit of 10$ on PC1 and a debit of 10$ on PC2 because the purchase price must be
considered as P1 and P2 are in real price.
NB: Everything is ok if the button "Post Inventory" is clicked after the production.
opw:741748
The mrp.unbuild model creates a name based on a sequence if no name is
given in the value dictionary. This was fine before the new views,
because the field name (in the form view) was marked readonly, so the
value 'New' was not actually sent to the server.
However, this was changed with the new views: readonly fields are always
sent on create/write operations, if they have been modified. This is a
problem for the mrp.unbuild model, because this means that each new
record as effectively the same name: 'New'.
So, we simply always use the sequence-based names in the create
operation, when the name is 'New', instead of the value given as parameter.
When calculating the cost price or the traceability between the consumed
and produced quants in a production order, we need to take into account
the extra moves that are added in the action_done (move_validate)
opw-715541
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Rev[0] and [1] introduced a versioning on product's attachments through an
ECO creation or through a stat button on the product form view. These revisions
added some fields on the ir attachment model: a many2one and a boolean field
with a default value, and due to concerns over the migration of databases with a
lot of ir.attachment records (like ours), we adapted the implentation in rev[2][3].
We deemed reasonnable to remove the "active" field, as adding an active field not
in the “base” module of the model could impact other modules that did not took into
consideration this field. Also, this field only had a meaning when mrp_plm is
installed, and ir.attachment is used in various places in contexts across Odoo.
So, rev [2] and [3] changed the implementation of the versioning to only link
ir.attachment to an ECO record, forgetting the functionality of archiving directly
through the product form view stat button (without an ECO).
To introduce back this behavior, we chose to create a model to handle the mrp
attachments (named “mrp.document”) which inheritS ir.attachment. This way, we keep
the behavior of ir.attachment and we do not alter the original table.
This commit moved the priority field already set on ir.attachment to mrp.document
and adds the active field that will be used in mrp_plm to archive/versioning purposes.
linked commit:
[0] https://github.com/odoo/enterprise/commit/99138b6711760a7562cb9559663aef6a4208a48f
[1] https://github.com/odoo/enterprise/commit/4f88eb409776c1c4bc8f8d71d845b913c3604a54
[2] https://github.com/odoo/enterprise/commit/7e1c73cfc84cd23b6ba87dab713c3078de16568d
[3] https://github.com/odoo/enterprise/commit/ee1c4b29b8872dac9c525fcc6acdf80b5ef73131
Simon Lejeune