Issue:
-------------------
When creating invoices for two sales orders with the same customer the field amount_to_invoice is wrongly calculated and it shows a negative value when it should be zero
Steps to reproduce:
-------------------
1. Go to Sales -> sale orders
2. Create two sale orders with the same customer
3. Confirm the SO’s and delivery the items
4. Create the invoices for both SO’s
5. The field amount_to_invoice is negative
Cause:
-------------------
The method _compute_amount_to_invoice considers the value of all sale orders without any filter, but in this case we have two different sale orders and we only have to consider the value for the respective SO.
OPW-3437237
closesodoo/odoo#132859
X-original-commit: e2ec9e6c86949f5781d03a7dbb1065ef8af3196a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The salesperson is not added to the following list of invoice that is generated from a sales order.
1. Create a sales order by assigning a salesperson.
2. Confirm the order and generate the invoice.
Current Behavior:
The salesperson is not added to the message following list of invoice.
Expected Behavior:
The salesperson should be in the message following list of invoice.
OPW-3439198
closesodoo/odoo#130930
X-original-commit: d9cb66e22fc9f8cfa1c00a2808294fe1178ffaa1
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
Summary
-------
Currently, the credit limit feature does not correctly take currencies
into account.
Steps to reproduce
------------------
* install `sale_managment`
* enable 'Sales Credit Limit' in the settings
* on a partner's form view, in the accounting tab, enable
`Partner Limit` and set a limit of 50
* have a currency `C` that's weaker than your company currency (we'll
call it `Q`). Let's say that here, `1 Q = 10 C`.
* have a price list in currency `C`
* create a quotation using the partner and price list mentioned above
* add a product with a price of 5, and no tax.
You should be met with a warning indicating that the customer has
reached his credit limit.
opw-3441361
closesodoo/odoo#130652
X-original-commit: f57653a6dcea04f0bca4e5ca73df3e1075e0fe98
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
To reproduce:
- Create a Distribution model, with an analytic distribution
and an effect on Partner A
- Create a Sale Order, for Partner A
- Confirm it
- Add a line on this Sale Order
=> The new line does not get the distribution of the model
It couldn't be done before 16.0 because a compute would trigger when posting the sale order, because date_order was used for the default rules, and so would trigger it at wrong times.
Distribution Models don't use this date anymore, so the compute won't happen at wrong times.
task-3355886
closesodoo/odoo#130597
X-original-commit: 22fd34b0d8b944a7afd031b894d750a8291d0aba
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
The test test_product_quantity_rounding fails when the currency
of the company rounds to the unit (decimal places = 0).
This commit makes sure the test doesn't fail with that setup.
Cf runbot build error 20612
closesodoo/odoo#130285
X-original-commit: fae7beacd950fcc349728f98681b6aa281572aa4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The test verifying the values of the sale report in a multi-comp & multi-curr
environment relies on the fact that the main company is by default in USD.
Nevertheless, the test fails when a localization is installed (if it changes
the currency of the main company).
This commit makes sure the tests always works, and resurrects the right tool
for that, which was dropped in commit 3752b3166e.
Cf runbot build error 22351
closesodoo/odoo#130201
X-original-commit: a73b5fce4fb02eefc681c55eab8f57cd35105226
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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>
Since 7bd93cc64b, we add the amounts to
invoice from sales order to the credit limit warning. When looking at
the credit amount on a partner from an accounting perspective, it is
not correct though that sales orders to invoice are considered as well.
In this change we split the credit amount from invoices and from sales
orders to invoice. On the partner we only show the credit amount from
invoices. In other places we add both.
task-3375260
closesodoo/odoo#128158
X-original-commit: 94eae9b73995dbf2175ecee65548ace5a382f5f8
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue:
The `_compute_amount_to_invoice` computation wasn't taking
into account the fact that invoices have a direction (i.e. either
going outbound(+) or coming inbound(-) (cf. `_compute_direction_sign`)).
This, in turn, makes the value of `amount_to_invoice` incorrect
for sales order with a credit note.
Solution:
In `_compute_amount_to_invoice`, multiply the value of
`invoice_amount_currency` with the opposite of the
`direction_sign` of the invoice, to account for the invoice direction.
opw-3360439
X-original-commit: 06ef17f2eefe89abfca64721185ac053fa8de820
[FIX] sale: fix amount to invoice for credit notes
Issue:
The `_compute_amount_to_invoice` computation wasn't taking
into account the fact that invoices have a direction (i.e. either
going outbound(+) or coming inbound(-) (cf. `_compute_direction_sign`)).
This, in turn, makes the value of `amount_to_invoice` incorrect
for sales order with a credit note.
Solution:
In `_compute_amount_to_invoice`, multiply the value of
`invoice_amount_currency` with the opposite of the
`direction_sign` of the invoice, to account for the invoice direction.
opw-3360439
closesodoo/odoo#127914
X-original-commit: d258774f120fb470d969e68c05cf0d8da0c4557a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
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
It's not a specific state, it should be considered separately,
as a boolean.
This allows to reduce code complexity (flows should not rely (much) on
the locked logic) and to have a clearer flow.
Task-3163931
Part-of: odoo/odoo#115871
Before this commit the reports in sales and associated app suffered from a confusion between
multiplicative and divisive rates for currency conversion. After this commit this will no longer be
the case.
There are several models with their own currencies that are involved in computing the amount of a
sale order:
- the order's company currency `order.company_id.currency_id`
- the order's pricelist currency `order.pricelist_id.currency_id`
- the product's currency for each product in the sale order `product.currency_id`
In the case of a report we need also to take into account the current user's company currency:
`self.env.company.currency_id`.
The `sale_order.currency_rate` is the **multiplicative <u>rate</u>** to convert from the company
currency into the SO currency.
Any product added to a sale order follow the next conversion. Let `conversion_rate` be the conversion
rate between the product's currency and the order's company currency, then:
```python
product_amount_converted = product.list_price / conversion_rate
order.amount_total += product_amount_converted * order.currency_rate
```
The rates returned by `_get_query_currency_table()`, on the other hand, are computed as the
**multiplicative <u>ratio</u>** to convert from each company currency into the current user's
company currency.
Any order that is to be analysed on a *report* follow the next conversion. Let `current_company_currency_rate`
be the conversion rate between the order's company currency and the current user's company, then:
```python
order_amount_in_cmp_currency = order.amount_total / order.currency_rate
report.order_id.price_total = order_amount_in_cmp_currency * current_company_currency_rate
```
What follow is a numerical example. Suppose you have the following multi-company and
multi-currency environment.
|order.id|order.company |line.subtotal|order.currency|order.currency_rate|
| ------ | ----------- | ----------- | ------------ | ----------------- |
|1 |BE Company (EUR)|1000 |INR |89.46 |
|2 |BE Company (EUR)|2000 |USD |1.09 |
|3 |BE Company (EUR)|3000 |EUR |1.0 |
|4 |US Company (USD)|4000 |USD |1.0 |
If we try to convert all of this for reporting in the US company, the currency table returned by
`_get_query_currency_table()` will give this (company currencies vs USD):
|currency_table.company|currency_table.rate|
| -------------------- | ------------------ |
|BE Company (EUR) |1.09 |
|US Company (USD) |1.0 |
Finally, in order to convert each amount into USD, applying the formulae listed above should give
the following result:
|order.id|order.company|display_price_usd |
| ------ | ----------- | -------------------------- |
|1 |BE Company |1000 / 89.46 * 1.09 = 12.18 |
|2 |BE Company |2000 / 1.09 * 1.09 = 2000.00|
|3 |BE Company |3000 / 1.0 * 1.09 = 3270.00 |
|4 |US Company |4000 / 1.0 * 1.0 = 4000.00 |
|Total (USD): 9282.18|
Task - 3277006
closesodoo/odoo#125402
X-original-commit: e8f7a692eaf6b87ccf4a8d95b7a46146b1199bf2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
It's currently not possible to know which `pos.order` is linked to a
`sale.report`
Solution:
Add a field `order_reference` on model `sale.report`. This field refers
to either a "sale.order" or a "pos.order" record.
The field `order_reference` is used to count the number of distinct
orders. We cannot simply use count_distinct on the `order_id` because
there can be multiple sale.report with the same `order_id` but related
to different models (sale or POS order).
Part-of: odoo/odoo#116830
Description of the issue/feature this PR addresses:
simplification of the credit note wizard
Current behavior before commit:
First users select reverse option (3 radio buttons):
1) refund
2) cancel
3) modify
The reverse action is triggered when the users clicks on the "reverse" button
After commit:
radio button are removed. There is now two buttons that trigger directly the reverse action with the desired option (refund or modify, cancel is not available anymore)
Also, for refund, posting the draft reverse move will also reconcile with reversed move.
task id: 3244377
closesodoo/odoo#117961
Related: odoo/enterprise#40919
Related: odoo/upgrade#4667
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to propagate the analytic breakdown on the accrued
entries that user can already create from the PO/SO list views.
task-3096126
closesodoo/odoo#120864
X-original-commit: d4d92029bf7c2a2c6a670170d3207b457dda5c68
Signed-off-by: William André (wan) <wan@odoo.com>
When using a different invoicing address for a partner on a sale order,
an error is thrown up. This is caused by checking the wrong partner in
the access token.
opw-3298228
closesodoo/odoo#120822
X-original-commit: bd76e9d6174d2154f8685dbaa2c8dcf1678ac175
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
- create an expense product, re-invoice: "at cost"
- create a sale order with the product and set an analytic account
- create a purchase order with the expense product and the same analytic account
- create the bill
-> a new line on the SO is created with the same "Quantity Delivered" as the "Quantity Invoiced" for the purchase order
- for the bill, create a Credit Note of x unit
-> the purchase order has the Quantity Invoiced diminished of x
Issue:
- the Sale Order has not taken into account the new quantity after refund
- Since the line is an "analytic" one, the quantity delivered cannot be changed even if we wreate a credit note for the invoice
Solution:
During the processus of creation of new analytic lines, instead of creating new so lines we adapt the analytic line
closesodoo/odoo#120660
X-original-commit: 5258e2ce7d2df915eff02218636aa3272a7d9faf
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
In the case of transaction linked to sales orders it is
more appropiated to use the invoice partner related to the
sale order than its main partner.
After this fix the invoice partner of sale orders will be
used for transactions linked to it.
opw - 3212748
closesodoo/odoo#119962
X-original-commit: 6eaf11d1ac0d9fc3cd9d458e6ee1f27159216d40
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
When converting a quotation to an invoice with a fixed down payment
amount and the total amount of the quotation is zero, a float division by
zero error occurs. This is because the total amount is zero, and it tries
to divide the fixed amount by the total amount.
This commit solves the above issue by dividing a fixed amount
by one when the total amount is zero and added the test case.
sentry-4079147910
closesodoo/odoo#119957
X-original-commit: 41d3bf23770ef1716e9d34e7930adad58a17c7de
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
The computation of `use_in_tax_closing` was overlooked when refactoring[^1]
the CoA templates. Since it was using a `onchange` with an extra code in
`create` of the `account.tax.repartition.line.template`, it didn't work on
its own after the refactoring.
[^1]: 5125748616closesodoo/odoo#119440
X-original-commit: e51ffcb01be3238338f23946b75f7e034032cf37
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Create a Field Service Task
Assing a customer, in Timesheet tab add a line with Hours Spent 00:20
Mark as Done
Sale Order will be created with a sale order line
Total of the line and Total of the order will not match
This occurs because the sale order line has been created with an
unrounded quantity of 0.333333
opw-3184468
closesodoo/odoo#118628
X-original-commit: ca72697042687e205fb288a97ec4717a97c89664
Related: odoo/enterprise#39799
Signed-off-by: Grazioso Andrea (agr) <agr@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>
Before this commit when in a multi-company environment an user
could assign a company to the sale order and use taxes related
to a different company for the sale order lines.
This is a functional error and also provoques that taxes are not
shown for some users when in a multi-company environment.
After this commit a ValidationError will be raised whenever the
company of the taxes in the sol and the so do not match.
opw - 3117352
closesodoo/odoo#115162
X-original-commit: 295c408568bb623f0b0ead3f18493ba339b87161
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
The goal is to take into account the confirmed
and un-invoiced sales orders in the total receivable of a client.
It will be useful in the scope of the credit limit trigger.
This is broken down in 3 steps:
1. Add the Remaining Amount to Invoice (RAI) in the
Invoice creation wizard of the Sales Order and store this data.
2. Add the RAI in the Total Receivable of the client.
3. The Remaining amount to invoice goes to optional="hide"
in the list view of "Orders to invoice" list view.
task-3122390
closesodoo/odoo#112905
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit the public user did not have access to tokens or the
possibility of saving payment methods.
When receiving a link to pay the customer (even if not logged in) should
be able to use tokens saved by the parter of the document and also save
new payment methods. This is intuitively correct: as the possesor of the
link, the customer have rights to pay with tokens linked to the partner.
After this commit tokens linked to the partner of the document will be
visible to the public user and also the possibily to save payment
methods.
Task - 2799296
closesodoo/odoo#104472
Related: odoo/enterprise#34792
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For the moment, the price unit of the down payment line on the sale
order is not always correctly computed. If the price unit is updated on
the down payment invoice, it is not updated on the sale order; or if a
regular invoice is created, the price unit of the down payment is set to
zero on the sale order.
This commit corrects the behavior by using the unit price of the invoice
line.
opw-3140740
opw-3160406
opw-3160420
closesodoo/odoo#114304
X-original-commit: 755c517fcab89df51e8b0ee4529894372b4d4ec1
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Sale Analysis report shows prices in company currency, converting foreign currency into the company currency according to the currency exchange rate.
Currently, the currency conversion is done incorrectly.
For example let's say 1 EUR = 25 CZK OR 1 CZK = 0.04 EUR.
Sales order: 39 EUR = 975 CZK.
Sales Analysis report shows 1.56.
This is because we are trying to multiply the order amount by 0.04, while it should be divided.
It used to be divided up until 16.0.
This commit changes the operator to convert the currency correctly.
opw-3167522
closesodoo/odoo#113525
X-original-commit: ef57d53866dc1d404138809132176c79d60a3b51
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Since 4d2b04a843, invoices
auto-generated on Sales Order payment were not sent to
customers.
Invoices are only marked as 'posted' in the override
of `_reconcile_after_done` in account_payment which means
`_send_invoice` must be called after the super call s.t.
the invoices are correctly posted before being sent.
opw-3158620
closesodoo/odoo#113229
X-original-commit: 82c53dd3404992b14d1db331c37b6d03c9f0ace1
Signed-off-by: Victor Feyens (vfe) <vfe@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>
Break down payments down per tax. When creating a down payment for a sale order, create one line per tax instead of one line for the enire order.
[Sale Order]
Product Qty Unit price Tax Subtotal
Product1 1 1000 10% 1000
Product2 1 1000 5% 1000
====
Untaxed 2000
Tax 150
====
Total 2150
Make a 50% (1000) down payment :
[BEFORE]
Product Qty Unit price Tax Subtotal
Product1 1 1000 10% 1000
Product2 1 1000 5% 1000
Down pay 1 1075 0
====
Untaxed 2000
Tax 150
====
Total 2150
[AFTER]
Product Qty Unit price Tax Subtotal
Product1 1 1000 10% 1000
Product2 1 1000 5% 1000
Down pay 1 500 10% 0
Down pay 1 500 5% 0
====
Untaxed 2000
Tax 150
====
Total 2150
closesodoo/odoo#105177
Task: 2678531
Related: odoo/enterprise#36331
Signed-off-by: Laurent Smet <las@odoo.com>
SO/PO accrued entries date should be the last day of the previous month since it necessarily concerns a bygone period.
closesodoo/odoo#111535
Task: 3045028
X-original-commit: 1dacb28a3f2a3f66572e693dfda81ceaf87696c9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Allow the feature activation by company instead of database.
It wasn't logical to specify the days by company but enable/disable
the feature by database.
task-2880950
Part-of: odoo/odoo#97565
Because of the M2M relation, an account.move.line can be linked to
several sale.order.lines, making the cardinality of sale_line_ids
superior to 1.
Even if it is not possible to obtain this result with standard code,
a custom module could create this situation and posting the invoice
would result in a "ValueError: Expected singleton" exception.
This commit prevents this exception by checking whether the line is
linked to at least one downpayment SO line in the method action_post.
The test also checks that the methods button_draft and button_cancel
behave properly (spoiler alert: they will fail too in 16.0).
closesodoo/odoo#111686
X-original-commit: a2344a4cd9283e3a74caf454ce218eecf5855de0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
Sale module has setting `Lock Confirmed Sales`, which particularly doesn't allow
order line modification. However, the application does modify special lines for
Down payment: it changes name from `Down Payment: 09 2001 (Draft)` to `Down
Payment`.
Fix it by excluding down payment lines from the constrain.
Also, this commit fixes access error when user doesn't have read access to
`ir.model.fields` model.
STEPS:
* Create user with only BILLING (group) access in accounting App.
* Now Logged in with Admin user
* Create any SO, Confirm, Validate the delivery order.
* Create an invoice with Down payment (%) as 10.
* Now do Logged in with BILLING user
* Open the draft invoice which gets created by SO.
* Confirm the invoice.
opw-3134083
closesodoo/odoo#110788
X-original-commit: b9cd677b7e20579b9fb0d59a2d24ae5d2e11fb72
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce
* Create an analytic plan with the domain as `invoice`
* Create an analytic account for the above plan
* Create an analytic distribution model and include condition as account prefix (4000), and product.
* Create a sale order, confirm and create an invoice
Issue
During the conversion from the Sale Order to the Invoice, the
analytic plan is not applied
Cause
The analytic distribution is set even where there is none. Therefore,
the compute is not trigger
opw-3109003
closesodoo/odoo#110202
X-original-commit: fd5249ea8687f24e7c9c2a2a3bcbb8cc14333efd
Signed-off-by: William André (wan) <wan@odoo.com>
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
Since https://github.com/odoo/odoo/commit/3752b3166ec6bbb5c6ea55f96bb521381bf2b2d9,
the currency of the test architecture is not fixed anymore to USD (but is by default).
Therefore, the nightly runbot tests of the localization (l10n_* modules) all fail
when verifying the company currency is USD (because the localization sets the company
currency to the country one).
This commit adapts those checks to stop enforcing the USD currency as base,
only enforcing that the currency used is the company one.
closesodoo/odoo#109807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When run on new year, the test fails because the created
currency rate (for the test) conflicts with the one in
the demo data.
closesodoo/odoo#109483
X-original-commit: 5a62eb7a25a05c7e779866824e0c1308d558f64a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Current behaviour:
Changing the package quantity may change the package type,
leading to an incoherent product quantities in the SOL.
(For ex: 20 uom in 2 packages of 20)
Expected behaviour:
When setting the package quantity, don't change the
package type. If the user wants to change the package type
they can do it by manually setting it or changing the product_uom.
Steps to reproduce:
- Install Sale and Inventory
- Activate Packages in settings
- Create 2 package types for a product of choice, one of 10, another of 20
- Create a new SO with that product
- Set the quantity to 10 (a new package_qty=1 and packaging type of 10 should appear)
- Save
- Edit package_qty to 2
- Observe that we have 20 units of the product, 2 packages of 20,
instead of 2 packages of 10
Reason for the problem:
When setting the `product_packaging_qty`, the `product_uom_qty` compute is triggered.
When `product_uom_qty` changes, it triggers `product_packaging_id`'s compute.
When `product_packaging_id` is computed, it doesn't trigger `product_package_qty`,
because it is protected, since we are writing to it.
Fix:
When we are writing the `product_packaging_qty` and the `product_uom_qty`
we remove the compute for `product_packaging_id`.
Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3010703
closesodoo/odoo#106924
X-original-commit: acfa94b7aeea9f8efdc1886b094697ae3f0f1d2a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit, the auto-invoice flow did not consider `sale order`
lines with negative quantities. It led to partially paid invoices.
Now, invoices generated by the auto-invoice flow are considered final.
This will allow `sale order` lines to be invoiced, even with negative
quantities.
task-2887019
closesodoo/odoo#104277
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The image for the sample product was updated in 76141b0d which made the
'Sample quotation' onboarding step hang for databases without any
`product.product` record.
A simple unit test for `_get_sample_sales_order` is included.
Technically, it wasn't possible to add it to the existing onboarding test class
because these tests are run post_install, and would fail on ENT builds because
of pos_loyalty preventing archiving `product.product`s.
--Additional note for 15.3 fw-port:
As logic moved from pos_loyalty to loyalty, which is installed before sale on
runbots, the problem described above resurfaces. We chose this cross module but
simple and limited-impact fix to avoid it.
Task-3045287
closesodoo/odoo#105339
X-original-commit: 0698388aab821e21309cbb2dd2411dac60f71be6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Matheus Leal Viana (malv)