These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
The _xmlid_lookup cache contains the id of the ir.model.data with is
unused, making cache pupulation and usage more complex than needed.
Removing this id in prevision of the next commit
Part-of: odoo/odoo#129029
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Receiving a kit's component will fail in AVCO + multi-uom
To reproduce:
1. Create a product category PC
- Costing Method: AVCO
2. Create two products P_compo, P_kit
- P_kit:
- In Units
- P_compo:
- In L
- Storable
- Category PC
3. Create a BoM
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
4. Create and confirm a PO with 1 x P_kit
5. Process the receipt
Error: When validating the receipt, a user error is displayed: "The
unit of measure L defined on the order line doesn't belong to the
same category [...]"
When processing the SM, we create the in-SVL. To do so, at some
point, we need the unit price of the SM, and here is where the error
comes from:
https://github.com/odoo/odoo/blob/708c3d063482e365e49a04f633c83e90e6fa4356/addons/purchase_stock/models/stock_move.py#L39
`self.product_id` is P_component, but `line.product_id` is P_kit,
hence the error with the UoM1
And there will be some similar errors with the `if` block, L40 (we
compare some SM quantities and some POL quantities: we are mixing
components and kit)
For now, in case of a kit, we will always use the `else` block (i.e.,
the unit price of the POL). This will be improved in master
OPW-3357685
closesodoo/odoo#128386
X-original-commit: 3a81eb79cad7f25843315e39da421efa2c34aaf1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
when the user removes the company_id and add a line in the purchase order
then the issue is generated.
Steps to reproduce:
- Create a new purchase order.
- Remove the company_id in the Purchase order.
- Now add a line in PO. Select a product with the consumable product type.
- Traceback will be generated.
Applying these changes will resolve this issue.
Sentry-4215579151
closesodoo/odoo#124035
X-original-commit: 75edec6f73b70c4b9b86ad67bc838f468c2574b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
AssertionError: convert amount from unknown date
The problem occurred when removing the default value of 'Order Deadline' and
selecting a product before saving the record.
After applying this commit will fix this issue.
sentry-4175826548
closesodoo/odoo#123224
X-original-commit: 0314edf028acf7365804028f0f3ef6123b6ae321
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.
The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.
The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase
closesodoo/odoo#122720
X-original-commit: b31f1ad789e92c84f85654b67e6730e413f0e06b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
qty_received_method is not recomputed if the product type change, and can lead to issues on existing purchases when trying to generate a Vendor Bill.
# HOW TO REPRODUCE:
- Create product P, type: Service, Control Policy: 'On Received Qty'
- Create PO for 1 unit of P (do not confirm)
- Update type of P to Storable
- Confirm PO, Receive Products
=> Qty Received is 0, not able to generate Bill
closesodoo/odoo#122409
X-original-commit: fcc1e8e325e6d9f4782b2f82769e1200b7b9a0c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Fesquet David (dafr) <dafr@odoo.com>
Currently, automatically PO is generated in that PO buyer field is empty.
So in this commit, we added buyer field in partner form view, when rfq is
generated automatically and vendor has a specific buyer then at creation
of rfq, the PO buyer field will be set according to that.
TaskID - 3151213
closesodoo/odoo#113709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
# Steps to reproduce
* create two 17% sales taxes. We'll call those taxes `17a` and `17b`.
* set rounding method to global
* create a SO with the following 2 lines:
* Price = `50.4`, Taxes = `17a`
* Price = `47.208`, Taxes = `17b`
* note that the total tax amount on the SO is `16.59`
* confirm and invoice the SO.
You should see that the total tax amount on the invoice is `16.60`. The
invoice and SO should have the same tax amount.
opw-3179228
closesodoo/odoo#120224
X-original-commit: 715d0e269c3d42a5e25f8ddf648d275069354aaa
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Co-authored-by: Yolann Sabaux <yosa@odoo.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
1:/
- Select the company A
- Create a purchase order:
- product: “P1”
- vendor: “V1”
- confirm the PO
The vendor “V1” is added to the supplier list of “P1”
2:/
- Select the company B
- Create a purchase order:
- product: “P1”
- vendor: “V2”
- confirm the PO
Problem:
The vendor “V2” is added to the list but “V1” is deleted from the list
in company A
The “seller_ids” field is in the “product.template” model, we try to
modify it in the “_add_supplier_to_product” function from the
“product_id”(product.product) field which inherits from the
“product.Template” model:
https://github.com/odoo/odoo/blob/3b88ed5ea458a37ee4d440f83bab45bd0fb13845/addons/purchase/models/purchase.py#L531-L532
So the function “inverse_related” will be called, in which the function
“__set__” will be triggered: In the values, the command for the create
will be added but the command for the set will be added as well while
it shouldn't. So in the `write_real` function a search will be done to
get all `product.supplierinfo` with the same product_tmpl_id:
https://github.com/odoo/odoo/blob/36544651f2049bcf18777091dbf02c9631b33243/odoo/fields.py#L4415-L4417
but as we are in sudo, those of company “A” will also be recovered, so
they will be unlinked since they are not in the command.set
opw-3251941
closesodoo/odoo#117985
X-original-commit: 78f803f3c1963711e2a5541f913f030da4f06fb7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
When you create a contact and a delivery adress for this contact. If you
add the delivery adress as a vendor to a product, and purchase this
product from the delivery adress, the contact will be added to the
product vendor list.
Steps to reproduce:
- Create contact C
- Create delivery adress D for C
- Create product P
- Add D as a vendor to P
- Create PO for P from D, and confirm it
- Go to P, and check the vendor list (C is there)
opw-3177309
closesodoo/odoo#117902
X-original-commit: 67031d2b3d7d52297d18a69c76b4f747b17142e3
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
With Rounding Method set to 'Round Globally'
Create a Quotation with 2 lines:
- Price 6.7, Tax 15%
- Price 6.7, Tax 15%
Total is 15.41, Tax amount 2.01
When sending the quotation via email or in list view the amount total
shown is 15.42.
This occurs because:
- order total is computed as sum of the lines `price_total` field,
which, defined as Monetary, store already rounded values
- line total is computed via `_compute_taxes`, where
tax amount is always rounded per line
opw-3113851
closesodoo/odoo#113026
X-original-commit: c677f45dcb050ce7e6f755b71e56c9b9120bf613
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit fixes the case where portal_customer is not added in the
recipients group by the portal mixin.
Steps to reproduce:
- Go on a purchase
- Log a note and tag a user who handles notification by email
- Traceback:
```
File "/home/odoo/src/odoo/addons/purchase/models/purchase.py",
line 346, in _notify_get_recipients_groups
customer_portal_group = next(group for group in groups if group[0] == 'portal_customer')
StopIteration
```
Current Behavior:
- Traceback StopIteration
Expected Behavior:
- Log a note with the tagged (boomer) user.
See odoo/odoo@f879cf2867closesodoo/odoo#112465
X-original-commit: 7b9dd53a5573141275d41436189c782bccb96c3d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Create an analytic plan with the domain as a Bill
- Create an analytic account for the above plan
- Create an analytic distribution model and include condition as account prefix, and product.
Issue:
The analytic distribution model doesn't apply to the bill created via purchase order
Solution:
Make sure we set the analytic_distribution only if present in order
to trigger the compute during invoice creation.
opw-3160041
closesodoo/odoo#111717
X-original-commit: ce5cae1da3f453ce1aad0915189e0e305d7e55e0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Currently notification process called notably by message_{post,notify} does
not notify message's author by default. Rationale is that as he typed the
message he is already aware of it.
However in some cases we want to skip this step, notably when messages are
generated in the name of the author and when we want him to be notified if
he should.
This is currently controllable through a context key 'mail_notify_author'.
In this commit we add an explicit parameter propagated through the notify
process, allowing to remove some context key usage and instead use real
parameters.
Note that all context keys usage cannot be removed as it is not always
possible to propagate this parameter.
Followup of odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Steps to reproduce:
- increase price_precision in decimal accuracy (in debug mode)
- create a product with multiple digits
- create a PO with that product
- unit price is rounded to 2 digits (currency pricision)
Bug:
in previous versions conversion was only done if currency
was different
Fix:
do not round during conversion and round to the highest digits
(alternatively we could revert to only converting if currecy is
different and accept the loss of precission in that case)
the wrong currency was used also for the conversion
opw-3050044
closesodoo/odoo#111223
X-original-commit: 2e46bf073c2251ce3d3ab5d5184feceb741df6db
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The tax totals computation requires a currency to be provided. When a user removes the currency deliberately and tries to add a line, an uncaught error is thrown.
The currency_id is required, and the user will not be able to save the move anyway.
To reproduce:
New Invoice or Purchase
Clear the currency field
Add a line
Stack Trace
After this PR:
tax totals are computed based on the journal currency or company currency when not available
No task, discovered thanks to #110920closesodoo/odoo#111021
X-original-commit: f74f9bc04ed8f18746eb509f3c8dc598b1618230
Signed-off-by: William André (wan) <wan@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
Steps to reproduce the issue:
- Create a product P
- Enable packaging on Purchase
- Create a packaging PA such as 1 PA of P = 70 P
- Create a PO with P and set a quantity of 250 with PA as packaging
Bug:
A Warning was raised saying that we should purchase 280, PA was removed and a
quantity of 249.9 was set.
PS: PA was removed because the quantity was changed and function _onchange_suggest_packaging was triggered
opw:3007165
closesodoo/odoo#105065
X-original-commit: a9514d69006c8a389b64550dbcbf30b19160c300
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, when the quantity of a PO line is changed, its unit
price is recomputed, which means it will be set to 0 if there is no
compatible vendor price for the selected partner/product.
It can be annoying because if the price unit was set manually by the
user, this info is lost.
To avoid that, we don't recompute the unit price if the PO line matches
the following conditions:
- The PO line has already a price unit;
- There is actually no vendor price list for the partner (in such case,
we prefer to avoid to stick to a price who doesn't match that list);
- The UoM wasn't changed, because if the UoM was changed, the price
should obviously recomputed (the price unit for 1 unit is not the same
than for 1 dozen).
How to reproduce:
- Install Stock and Purchase modules;
- In purchase settings, enable "Purchase Agreements";
- Create a product and in its vendor price list (in "Purchase" tab), add
a price for Partner A (e.g. 10$);
- Create a PO for Partner B, add a PO line for the created product and
set the `price_unit` higher than the created vendor price (e.g. 15$);
- Confirm the order and go in the "Alternatives" tab;
- Click on "Create Alternative" and select Partner A as the vendor;
- Click on "Compare Product Lines" and choose the line for Partner A;
- Go back in the first created PO (with Partner B as vendor)
-> the PO line's quantity is to 0, which is good, but its unit price
is also set to 0 which is annoying.
Additionnaly, in `_get_stock_move_price_unit`, `float_round` the value
just before it was returned because previously, the rouding was done
before the multiplication by the UoM's factor which can cause some
rounding issue if the rouding is not done after that.
closesodoo/odoo#104206
X-original-commit: f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
"mail_notification_paynow" mail template layout has been renamed to
"mail_notification_responsible_signature_layout" as it now only differ by the
signature. It allows to use it more widely.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
Steps to reproduce:
- create two products
- create two analytic accounts
- create two new analytic rules by assigning an account to a product
- Create a new PO and select on of the product
- On the same line, change the product to the other one
Issue:
- The analytic account won't be updated
Cause:
Bypass of the `account_analytic_id` whenever there is already on defined
Solution:
For the `Sale` fix, I added the `line.state == 'draft'`.
The reason? Because the compute is triggered after confirmation of the order due to:
https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L931-L935
Therefore, the compute won't also be triggered after confirmation of the SO.
opw-2948950
closesodoo/odoo#99858
X-original-commit: 61604e18128c1cfd0e6d4e510852f780491d6e4e
Signed-off-by: William André (wan) <wan@odoo.com>
To Reporduce
=============
- Create RFQ and send it by mail
Problem
=======
The received mail contains the amount which we don't want to show when it's just a RFQ
Solution
=========
to solve the issue a condition was added to show the amount only on Purchase Order
opw-2955758
closesodoo/odoo#99684
X-original-commit: 6c3c2ce3c8deb5a04a97efb82d1d3ab6acbb81ae
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Steps to reproduce:
- Install purchase
- Go to Settings and activate `Variant Grid Entry`
- Create a new Requests for Quotation
- Add a customer and add a product that has a variant min 2 variant
- Wizard should ask for the variant
- Select 1 variant by increasing quantity in the grid and confirm
- Confirm order
- Add again a product variant with the wizard
Issue:
Price unit is not set on the new line.
Cause:
In `_onchange_quantity` (triggered by the purchase_product_matrix
module), we do not update price unit if order line
is in state `purchase` or `done`.
Solution:
Replace condition to not perform `_onchange_quantity` if order line
has an invoice line.
opw-2956755
closesodoo/odoo#99522
X-original-commit: 8f92146b2d4996be724213345567291f045aad85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a sale order with a product that's invoiced on delivered
quantities.
- Set delivered quantity (partial delivery) and create an invoice based
on the delivered quantity. Set the "Invoice Date" to sometime in the
past.
- Go to the settings and set "Invoicing Switch Threshold" to any date
in the future (so that the invoice you created has a date BEFORE the
new threshold)
- The invoice will get the label "invoicing app legacy".
- Go back to the sales order and change the delivered quantity.
You should see that the invoiced quantity is automatically set to 0.
A similar behavior can be observed with purchase orders.
Why this is happening:
When a new “Invoicing Switch Threshold” is set, all posted invoices
before the threshold are marked as `canceled`. In v15, changing the
delivered quantities triggers the invoiced quantities to be
recalculated as well. However, computing invoiced quantities doesn't
take into account invoices that are marked as `canceled`. This mean
that the newly computed invoiced quantities won't include invoices
posted before threshold.
opw-2896797
closesodoo/odoo#98909
X-original-commit: cc979734bd7ef3f2a94b411cb7b4f3e782b7ddab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
By observing the slowest queries in our servers, we find some indexes
to add (and verify the pertinence of each) :
- Add a index on `sale_id` of `stock_picking` because, it has a one2many inverse highly used.
- Add a index on `product_id` of `purchase_order_line` because, it has a one2many inverse in purchase_stock and there are some search with it (in `_compute_purchased_product_qty`).
- Add a index on `product_id` of `sale_order_line` to improve the `sale.report` view and it is also called by `_compute_sales_count`.
- Add a index `btree_not_null` on `created_purchase_line_id` of `stock.move` because its one2many inverse `move_dest_ids` is highly used.
- `key` on `ir_ui_view`: Backport of https://github.com/odoo/odoo/pull/97478closesodoo/odoo#99130
X-original-commit: da55c8d88b846d9d1841712b6bd96799e2768a5b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Add a new subtype_id for 'RFQ Sent' state. This removes
the need to join on mail.tracking.value when computing
'all_sent_rfqs'. Since mail.tracking.value is usually
a big table, removing this join leads to a substantial
speedup when loading the purchase.order dashboard on big
databases.
closesodoo/odoo#96921
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Gorash