Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Problem
---------
All fields in the tax definition are currently modifiable even after the
tax has been used. This raises some issues in tax reports and make
investigations difficult when things go wrong in tax report.
Objective
---------
Once an account tax has been used:
- Some fields in the account tax should not be modifiable anymore to
avoid tax report issues;
- Other fields should be logged when modified to ease debugging and
investigations.
Solution
---------
1. Add a logger to the tax form to track the modification of some fields
2. Track whether the task is being used in transactions or not. This is
done thanks to a compute field. In order to be flexible, the compute
function uses a hook function that other modules can override to easily
add transactions to computation of the field.
3. Make the fields that should not be modified anymore readonly when the
tax is being used.
4. In order to track the repartition line values, a tracked computed
field that stores the relevant value in a string is used.
Task-3450002
Part-of: odoo/odoo#130403
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
To reproduce
============
- create a purchase order and confirm it
- create a Bill, set its Bill date and Accounting date to different dates
to today
- save it, then choose the created PO in autocomplete field
the Accounting day will be changed to today
Problem
=======
when calling the autocomplete, some values will be updated on the record,
where `move_type` is one of them, and updating this field will trigger the
compute of accounting date.
Solution
========
if the value of `move_type` on the record is the same as the one of the update,
it should not be taken into account which will avoid uneeded recompute.
opw-3381530
closesodoo/odoo#136559
X-original-commit: 6abcac2025522e5e023d51c02f14c49044658b70
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
If the currency_id and cost_currency_id is different for a product, the cost in the purchase order is wrong. The purchase order should use cost_currency_id instead of currency_id.
Steps to reproduce on runbot:
-Set the currency of main company as Dollars (USD).
-Choose in runbot the company "My Belgian Company" as its currency is Euro.
- Add the currency rate of today between EUR and USD
- Take a product and edit the cost to 100 EUR - as the cost field is linked with the currency of the company
make sure on the tab purchase there is no information - so the vendor pricelist is not present.
- Go inside the purchase module and start a request for a quotation
leave the currency as EUR
- Select the product to purchase
Current Behavior:
The unit price will be (100*currency rate). If you do the same but take the currency as USD the product unit price on the purchase order line will be 100
Expected Behavior:
The unit price should have been 100 Euros. And when dollar is chosen as currency, the exchange should have been applied.
OPW-3460551
closesodoo/odoo#136298
X-original-commit: f9c66ff20f2e7d8d35b9bc775486bb62abd4c367
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 72a17bafba6e7 force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.
Instead, this commit patch the call to `_select_seller` to take at least
`today()`
closesodoo/odoo#134217
Opw: 3167094
X-original-commit: a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
Before the fix, when trying to autocomplete a bill with a PO using India localization, the invoice lines would not get the same currency as the autocompleted PO.
This is because with India localization, the journal_id gets updated at the same time of the currency_id, which recomputes and erases the currency set just before.
I propose to update the currency at the end to avoid all sort of recomputation it could be subject to.
opw-3374634
closesodoo/odoo#127657
X-original-commit: 7f37e523cffbe3d7d98fd7457b30e2fb93f453d5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Benjamin Boullé (bebo) <bebo@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>
Steps to reproduce:
1. Create a bill from document,
2. Fill in PO in auto complete, confirm, check the bills list.
3. The source document is not populated in the list.
What is the current behavior that you observe?
The source document is in the log, but does not show up in the dashboard.
What would be your expected behavior in this case?
The PO should show up in the source document in the list
OPW-3284992
closesodoo/odoo#122280
X-original-commit: e3289decaf95034f0ebba307350d3913a604eb8d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,
Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.
issue-121232
note fw 16:
The record must be saved in order to trigger the compute in
https://github.com/odoo/odoo/blob/5a256af35e5d612efed9ed8af1cf23fd62bd83f4/addons/account/models/account_move_line.py#L449-L457
in order to recompute the currency of the lines
closesodoo/odoo#122075
X-original-commit: d0109dc5d7b0012ad1a4c45e5204934ae481779b
Signed-off-by: Yolann Sabaux (yosa) <yosa@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>
Failing use case:
Create a vendor bill and use the auto-complete field to select a purchase order multiple times.
The purchase order gets added to the vendor bill multiple times, this doesn't happen in V15 and was never intended.
The reason is simply that the code was checking on self.line_ids which get only populated after the record is saved and its invoice_line_ids are synchronized. Before that, only the field invoice_line_ids is filled witht new_ids.
opw - 3196149
closesodoo/odoo#119758
X-original-commit: 29d5862d447dd369432b345e43d5875d3b2a4474
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- put the currency of the bill to eur
- change the partner with a partner with no purchase currency set
Issue:
The bill is re-set to usd
Note:
addendum to https://github.com/odoo/odoo/pull/116852
opw-3233527
closesodoo/odoo#119753
X-original-commit: 51ff9c6026b8f9079aba7c9e26891f62c782761d
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- company currency = USD
- set a partner P with a `property_purchase_currency_id` in EUR
- create a bill with Azure partner and set an bill line
- change to partner P
issue -> the currency of the line has not been change
- change to Azure
issue -> no change about the currency
Cause:
- We update the move.currency_id but not the line_ids.currency_id
- after setting Partner P, we try to set a partner that no `property_purchase_currency_id`, we do not enter in the condition
opw-3233527
X-original-commit: 213e22c63f6259e2e69193b7d6a7022d8b6eab20
Part-of: odoo/odoo#119753
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- adding a label 'last update' to the stat button in project form view.
- indicate 'my project' in the tab instead of 'project sharing view in portal' in project sharing.
- set the first non-folded stage of the project as default on newly created tasks.
- remove user confirming the SO as the default project manager.
- hide fields service_tracking, service_upsell_threshold if sale_ok is false.
- set purchase_method to purchase by default if product is of service type.
- remove the : next to the totals labels and decrease the font-size for values of 'total hours'
and 'remaining hours' in timesheets notebook in project task form view.
task-2897867
closesodoo/odoo#96548
Related: odoo/enterprise#29774
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Manisha Tulsiyani <matu@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>
The current algorithm to match vendor bills with purchase orders was written
while keeping in mind that the vendor bill data came from an OCR scan and was
thus not very detailed or totally reliable.
The current algorithm tries to match in this order:
1. Document reference(s) match(es) one or more purchase orders and the total
amounts of the bill and the purchase order(s) match as well.
2. Document reference(s) match(es) one or more purchase orders and the total
amount of the bill matches a subset of lines in the matched purchase order(s).
3. Document reference(s) match(es) one or more purchase orders but the amounts
do not match.
4. No document reference, but the vendor and total amount of the bill matches
exactly one purchase order.
When we generate a vendor bill from an EDI document (electronic invoice), we do
have very accurate information however and can also match line by line, since
our vendor bill will contain separate lines.
In this commit we add an extra algorithm specifically for EDI documents:
* We find all purchase orders matching the vendor bill reference(s)
* For every vendor bill line (having a unit price), we try looking in our
matched purchase orders' lines for the same unit price and a remaining
quantity higher than or equal to what is in the vendor bill. If multiple matches
are found, we check the name similarity and take the most similar line.
* We replace the vendor bill line with the purchase order line, changing the
quantity to the one on the original vendor bill line.
* Unmatched vendor bill lines remain untouched.
We also remove matching method 2 (see above) for EDI documents, in favor of the
new algorithm.
This approach makes that more purchase order lines will be able to get matched
when using EDI documents.
task-3140712
closesodoo/odoo#112684
Related: odoo/enterprise#37061
Signed-off-by: Laurent Smet <las@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>
When a vendor bill document is uploaded (EDI, PDF,..) the link with
the purchase order is often lost.
We want to reuse the purchase.order OCR' matching logic to enhance
vendor bill extracted from documents.
To sum up the logic;
- if we find a partner or reference match (invoice_origin)
AND the same amount, we use autocomplete and replace the line in the vendor
bill with the purchase order one.
- if we find a match with the reference and some line in the purchase order
sum up to the vendor bill total, we add those line in the vendor bill
but we set the qty to zero (the accountant can manually remove the XML
line and link the new one afterwards).
task-id: 2828521
[community](https://github.com/odoo/odoo/pull/109093)
[enterprise](https://github.com/odoo/enterprise/pull/35436)
update master: make _find_matching_subset_invoice_lines private
closesodoo/odoo#111491
X-original-commit: ebc8b007ecb375d20c566b6e6ecc3f6749ebaa2a
Related: odoo/enterprise#36545
Signed-off-by: Josse Colpaert <jco@odoo.com>
Xavier Morel