Currently the standard price for products with FIFO as cost_method, show
the price of the next product to go out. It could be confusing on the
report page because the standard price * quantity is different than the
stock value. Another issue, is the margin, they are only computed on the
last piece even if we sell multiple ones.
For example:
MOVE IN 5 units @ 10$
MOVE IN 5 units @ 20$
If we do an order for 10 units at 30$ each we will have a margin of
200$ (30$ - 10$)*10. And the report page will be 10*10$ --> 150$.
The purpose of this task is to have always a report correct. For the
margin it will not be always true because it's depending the number of
pieces that we sell. In the above example:
- if we sell 9 units, the margin will be better with this patch
135$/130$ with this commit and 90$/130$ without
- but if we sell 6 units it will be closer to reality with the old patch.
90$/70$ and without 60$/70$
It has other implications: the inventory adjustement and edition of
moves will now takes the AVCO values and not the next to go out.
With the upper example if we add 10 units following an inventory
adjustement (10 * `standard_price`):
- With this commit: 150$
- Current behavior: 100$
Globally it will be closer to reality for products with a price having
a lot of variance and it won't change for the other.
Task-2918885
closesodoo/odoo#108468
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
STEPS: Create a Pricelist with price rule discount-based on parent product
category. Result: the price rule discount is not applied if the product is not
directly attached to a parent category.
Fix it by correcting domain in `_get_applicable_rules_domain`.
Also, update tests: use parent category in the pricelist.
https://github.com/odoo/odoo/commit/dc8db07ba718a2de845455efc6e265213537eedf
opw-3080836
closesodoo/odoo#107769
X-original-commit: ce44c045f6b75fa64962625baad322632a9c2979
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
In pricelist form view and product form view, pricelist rules are now invisible if referring to an archived product or an archived pricelist.
task-2920563
closesodoo/odoo#105112
Related: odoo/enterprise#33910
Related: odoo/upgrade#4028
Signed-off-by: Arnaud Joset <arj@odoo.com>
Prior to this commit, the image placeholder lacked contrast and wasn't
readable in small size (eg. in the kanban view).
This commit improves this placeholder.
task-2760590
closesodoo/odoo#105296
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
For the sale scope, we added a new 'pricelist_item_id' field, caching
the pricelist rule used for the price_unit and discount computation.
This feature uses the new `_get_pricelist_rule` method, which only returns
the pricelist rule matching the SOline values.
But the `_get_pricelist_rule` method still does all the price computation
for 'nothing'.
This commit skips the price computation (and the search of sub-rules if
the rule found is based on another pricelist).
closesodoo/odoo#103629
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
After this commit, the settings of coupons, promotions,
gift cards and loyalty cards are now managed under a
single one field in PoS Settings configuration. Moreover,
this settings field is "global" and shared between the
eCommerce and Sales app.
task-2959620
closesodoo/odoo#99060
Related: odoo/upgrade#3842
Signed-off-by: Masereel Pierre <pim@odoo.com>
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Reproduction:
1. Create a dynamic attribute "dyn_att" with a couple of values
2. Create a product template "dyn_prod" with those attribute values
3. Create an order for "dyn_prod", this will trigger creating a variant
4. Make sure to check Variant Grid Entry in Sales Settings
5. Open variant form view of dyn_prod and edit it to allow duplication
6. Duplicating it leads to an error
Reason: copying the variant is not possible and disabled here:
https://github.com/odoo/odoo/pull/38303 For future convenience, maybe
it’s better to give a temporal working solution. The function
_create_first_product_variant is used in the product module but only
defined in its child module website_sale
Fix: copy the product template, create and return its first possible
variant. Added test for dynamic variant copy. change the definition
place of _create_first_product_variant to module product
opw-2790543
closesodoo/odoo#98809
X-original-commit: 34a2948d3d6e0f597c1b5d65f9f118e891c07cc4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
- Merge `_check_barcode_unique` and `_check_barcode_uniqueness`.
- Simplify the code and avoid costly read_group
- Add missing index on barcode of `product.product` (before there was an
unique constraint)
(Note that the constraints isn't transactional safe because it is not an
SQL contraints)
closesodoo/odoo#96043
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Steps to reproduce the product:
- Create a new product:
- Select “Service” type
- Go to the Sales tab:
- Select "Create a task in an existing project" in the `service
tracking` field
- the `project` field becomes visible
- Change the Type of the product to “Consumable”
- Try to save
Problem:
The field `project` remains visible and as it is a required field,
we have to fill it in before being able to save the product.
While it is a feature only for service-type products
Solution:
- The `project` field is based on the `service_tracking` field
to become invisible or not. So when the product is not of service type,
we must remove the tracking service so that the project field
becomes invisible.
- Prevent the user from changing the type of products already used in
a sale order
opw-2858064
closesodoo/odoo#93804
X-original-commit: 102951140e3f35ced8653d4bedb82b63bb2c963f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When filtering on product templates with a negative operator, the
result
is incorrect
To reproduce the issue:
(Need mrp)
1. Create two products P_compo, P_finished:
- Internal Reference:
- P_compo: 123
- P_finished: 456
2. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
3. Manufacturing > Master Data > Bills Of Materials
4. Remove search filters and apply this custom one:
- "Product doesn't contain 456"
Error: P_finished's BoM is still in the list, but '456' is the internal
reference of P_finished, so this BoM should not be displayed
The filter is applied on the field `product_tmpl_id` of the BoM, which
leads to the override of `_name_search` in `product.template`. In this
method, a call to the `_name_search` of `product.product` is executed:
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L456
which is a good thing because the version of `product.product` handles
the case of the Internal Reference (`default_code`)
https://github.com/odoo/odoo/blob/1e8982e4cf6b604e4da2773f10bdf6cf94c7e683/addons/product/models/product.py#L532-L538
So, the call to this `_name_search` will not return P_finished. However,
later on in the `_name_search` of `product.template`, we call the
`_name_search` of `super` with the same domain (i.e., 'not 456 in name')
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L474-L485
This is the issue: it leads to the `_name_search` of `BaseModel`, which
is the classic version: it does only consider the record's name. So,
this call will return P_finished.
In the `_name_search` of `product.template`, there are actually two
calls to `super`. Considering the commits [1] and [2], it seems that the
goal is the same in both cases: find the `product.template` that do have
any variant yet. However, in the first commit, the domain given to
`super` excludes the templates that have at least one variant, which is
not the case with the second commit (the "problematic" one).
Since both codes have the same goal, we should merge them by keeping the
best idea of each one. From [1], we keep the idea of restricting the
domain: we only look for templates that do not have any variant.
However, this domain needs to be improved: we need to include the
templates whose all variants are archived. From [2], we keep the idea of
looking for the templates outside the `while True` loop. This allows us
to do the search only if required.
[1] 21ae503
[2] 99bae2c
OPW-2791255
closesodoo/odoo#90248
X-original-commit: 942814844e982cbaec2329709c6ba9dd810d0c3f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create a product attribute “PA”:
- Variants Creation Mode: Never
- Value: “PA1”
- Create a storable product “test”:
- Add the attribute “PA“ and the variant “PA1”
- Save
- Archive the product and then remove the attribute from the product
- Unarchive the product
So the product has no longer the attribute line but if we check the
attribute itself, it is still having the product as a related one.
Problem:
When we remove the line attribute, the `_compute_products` is called,
but as the product “test” is archived, when we try to access the
related products of the product attribute, it returns an empty recordset
because the ORM only returns active records.
Since the attribute `product_tmpl_ids` seems empty and we try to update
it with an empty value, the ORM considers there is no change and so, it
does not update the field value in the DB.
Solution:
We must use `active_test=False` when accessing the related products, so
the ORM returns all records, active or archived.
And since there is indeed a linked product and we are trying to
overwrite it with an empty recordset, the change will be effective.
opw-2806316
closesodoo/odoo#90166
X-original-commit: 7d304078b4ed97d23ec84609e6aea137e8500a18
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, Barcode was not displayed on template
when related product variant is archived.
Here we are making sure that even when a product is
archived, its barcode is still visible in template.
closesodoo/odoo#89363
X-original-commit: f0c7cde3938c01df5fc10bb8dcd72fd3bb18afdb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit adds an higher flexibility to pass optional args through the
price computation methods.
Those optional kwargs offer the opportunity to tune the price
computation, especially to tune the price_compute method on
ProductProduct and ProductTemplate.
On sale order line models, one can define some fields that should be
passed to the price_compute method in order to tune it.
task-2382027
Co-authored-by: Victor Feyens <vfe@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
Prior to this commit archived variants would not appear as disabled
in the shop, the different options will now be greyd out if selecting
them would result in an archived variant.
TaskId-2762122
closesodoo/odoo#84711
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously, product barcodes uniqueness was enforced
by a SQL constraint, resulting in a generic error message.
The SQL constraint has been replaced by a Python check,
which allows the listing of conflicting barcodes in the
error message, including those resulting from batch edits.
Task: 2654703-7
Part-of: odoo/odoo#84056
Steps :
Install Sale / E-commerce.
Create product P (price = 100).
Create price list L.
Create price rule R (product = P, price = 50).
Go to product P > Price Rules > archive R.
Create a quotation. / Website > click 'Go to website' > Shop.
Select price list L.
Create a SOL with product P. / Search for product P.
Issue :
Price is 50.
Cause :
Archived price rules are included in the 'search' of
_compute_price_rule_get_items().
Fix :
Exclude them.
opw-2752184
closesodoo/odoo#85811
X-original-commit: d5e8308492ac8955ad76fd8d9f3781266dee76f6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since 4911a26d2c, `_check_barcode_uniqueness`
flush the default `_order` of `product.product` models (via many2one in the `_order`
of `product.packaging`). It creates a bottleneck (take > 10 minutes ) when we populate
(medium size) the `product.template` during `set_barcode_variant`.
Force the order to be trivial and simplify the domain with a 'in' instead of
multiple OR.
closesodoo/odoo#85687
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Step to reproduce:
- create a unit of measurement (UoM) and set it's rounding to 1.000
- create a product that uses this UoM
- create two packaging for this product
- create a sales order and in the sales order line set the created product
- you can already see the packaging is set, but anyways set a quantity to near the defined in the package
- the quantity will be updated
Current behaviour:
- Packaging always update to bigger package even if it doesn't fit
Behaviour after PR:
- Packaging update to the biggest package which is a full divider of the qty
- If no package fit, then no package are applied
opw-2718146
closesodoo/odoo#85351
X-original-commit: ad047434a802abfc9f4203897aec9cda149dd43b
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Prior to this commit the price in the product dynamic filter was not
correctly computed since the pricelist was not available in the context.
This commit provides a fallback on request website pricelist in order to
display a non-zero price if it exists.
task-2765828
closesodoo/odoo#85507
X-original-commit: 88bfd8a60cefac45e73cd032204c9b90a862ee6c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* query pricelist filters/domains directly for the correct company
instead of relying on context/session/... content
* pass the record instead of the id to avoid useless browse calls
* also clearly highlight sudoed partner record
Part-of: odoo/odoo#82374
* order fields, methods according to guidelines
* fix some typos
* rename methods according to guidelines
* remove useless field attributes and class specifications in super()
calls
Part-of: odoo/odoo#82374
Steps to repoduce:
- Go to Sales - products
- Create a product
- Add variants (3 attributes and 2 values each) Total is 8 variants.
- onfigure variants: Select 1 attribute and exclude it for 1 variant (for example: exclude for size 12x12)
-> the number of variants remains at 8. The one that is excluded is still visible in the Product variants tab.
Solution:
When an exclusion is created, archive all the not-possible-combination.
OPW-2729329
closesodoo/odoo#84883
X-original-commit: 91642f4e29beb89d110084a20443fb300ee26530
Related: odoo/enterprise#24512
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce:
1) create a product with, the "Product Type" as
"Storable Product" + A "Product Category" with a "Costing Method"
set in "FIFO" mode and the Inventory Valuation in "Automated".
2) create a Purchase Order for 1 unit of that product and set the unit
price to 10.00. Confirm Order -> Receive Products -> Validate
(the delivery) -> Apply
3) create a second Purchase Order for 1 unit of the same product but
set the unit price to a different price, like 20.00. Confirm Order ->
Receive Products -> Validate (the delivery) -> Apply
4) create a Sales Orders for 1 unit -> Confirm -> Smart button
Delivery -> Validate -> Apply
5) check the cost on the product form of that product.
On the V13 it will be $10, so its the last unit that left the stock
On V14 and upper, it will be $20, so the next product that will leave
the stock.
The help popup for the field "standard_price" doesn't reflect the
correct behavior. It's the standard price for the next unit instead
of the last one.
closesodoo/odoo#84289
X-original-commit: 9e0a529b603302653dac2a8fb692472fc500c147
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
write call on product.template.attribute.line with an active value specified
will trigger cache invalidation & flush even if no record is specified in
the call.
_create_variant_ids is called on multiple places, including the unlink
of product.template.attribute.line records. In this flow, self might
be an empty recordset, and there is no need to trigger early flushes and
cache invalidation if self is empty.
Part-of: odoo/odoo#84055
With GS1 nomenclature, products and packagins use the same pattern.
Therefore, we need to ensure the uniqueness between products' barcodes
and packagings' ones.
closesodoo/odoo#82883
Related: odoo/enterprise#23550
Related: odoo/upgrade#3180
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Currently, product.name_get goes through
each product in the record set
before calling _get_combination_name
on its attribute values.
This can lead to some slowdowns when the recordset
starts to grow (> 100 products). The reason for
that is that _get_combination_name
filters the recordset twice.
This commit speed-up _get_combination_name
by "resetting" prefetch_ids to self._prefetch_ids,
i.e. the prefetch_ids of the whole recordset.
opw-2624261
closesodoo/odoo#83563
X-original-commit: 2065c53a6e0c3f1c363f5b2bea401782a1f4b31b
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps to reproduce the bug:
- Have company A and B
- Create a pricelist A with company A and pricelist B with company B
- Select company A as current company and B as allowed company
- Create contact A without linked company
Problem:
You can select pricelist B while the current company is A, this causes an access error if you save and only select company A in the selector.
It also causes an error when you open a new POS session.
This contact is not linked to a company, so it should be accessible from all companies.
Solution:
Add a domain to allow the user to only select the pricelist linked to the current company or a pricelist that are not linked to a company
opw-2745267
closesodoo/odoo#83537
X-original-commit: 9f79c62fa56a1bb92ea3fc79fd82431bf9041d5c
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Activate packaging in inventory configurations
- set the product UOM digits to more than 2 decimals
- Create a storable product:
- Go to inventory tab > Packaging > Add a line
- Change the contained quantity to a value with more than 2 decimal places
Problem:
It will round it to 2 decimal places regardless of the set digits.
Because the formatFloat function does not receive the digits in parameter, so it uses 2 as default value
Problem:
opw-2723068
closesodoo/odoo#83411
X-original-commit: 144761f07c9de53aaeb7e1468e017eee17cbacd2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Some aggressive cache invalidation in the middle of method write() where
the model has children models (in the _inherits sense) causes very nasty
errors that are hard to fix.
Consider two models A and B, where B inherits from A. Also consider two
fields a1 and a2 on A, which are thus both inherited by B. Now take a
record from model B, and update both fields as:
record.write({'a1': ..., 'a2': ...})
As both fields appear as related fields on model B, the method write()
puts all values in cache, then it proceeds to call the inverse method of
both fields. The inverse method of a1 is called, and this writes on the
parent record. Now imagine that some override on A invalidates the
whole cache. When the inverse method of a2 is called, the field's value
on B has been invalidated, and this therefore writes the value False on
the record's parent.
This patch removes and adapt such cache invalidations:
- Since 4b1cb41cf7, the cache invalidation
in method write() of product.product is no longer necessary.
- The cache invalidation in method write() of product.pricelist.item
has been removed as well, since field that needs to be recomputed no
longer exists.
Fixes#76946, #77042closesodoo/odoo#82958
Opw: 2657461
X-original-commit: 5a73a8a3697c0f2685471efa252e5eb1af738e83
Signed-off-by: Raphael Collet <rco@odoo.com>
Arnold Moyaux