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>
The price_reduce field is not shown to the users, and was not useful for
business computations because of its digits specification (losing decimal data
when we only want to round the total amounts, not the price before taxes).
This commit removes the field to reduce the table size, remove useless computation,
avoid misuses of the field and clean code.
Task-3018371
closesodoo/odoo#103611
Related: odoo/upgrade#3977
Signed-off-by: Victor Feyens (vfe) <vfe@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
This time, for good
closesodoo/odoo#102506
X-original-commit: 464883bccab539b747e938aef7851c6917fee57c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This test is failling during nightly mainly when executed arround 23
The most likely reason for that is because of the freezetime rounding
the day and creating an error between 23 and 00.
The freezetime only wraps the create but the compute will be triggered
only after that. Adding all assertions inside the freezetime may be
enough to fix this issue.
closesodoo/odoo#101989
X-original-commit: 98693d5543e3c0b4f8f51a05e026fce8ddb77a51
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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>
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>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) Invoicing wizard refactoring
* reduce the use of context in the business logic,
store the orders being invoiced
* factorize invoice creation values, using the correct method from
the sale.order model
* switch from default fields to computed fields, and avoid computing
unnecessary fields when the wizard is opened to invoice multiple
orders together (most fields are only used for down payments)
* Rely on python constraints instead of error messages scattered
accross business methods to notify the user that the invoice cannot be
created.
* Clean the code to make it easier to follow, understand and maintain
2) Distinguish Down Payment Invoice lines from standard ones
(with a dedicated field)
Allows to stop relying on the dumb property,
not specifically reliable, e.g. if the down payment product is modified
in the settings after down payments orders were already created.
closesodoo/odoo#98600
Related: odoo/enterprise#30653
Related: odoo/upgrade#3799
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
make it clear it's expected to be called from the frontend, prefixing it
with action_.
Also split the method to have an utilitary method recomputing all prices,
to use in the tests and/or business code (without the chatter message).
Part-of: odoo/odoo#98068
Until now, there was no way on a given sales order to distinguish
draft, cancelled and posted down payments.
This commit makes sure the down payments state is clearly
shown as draft or cancelled when the linked invoice is
in the corresponding states.
Also remove those draft and cancelled down payments from the sale
portal & report as it can be confusing for customers to see line(s)
of down payments they never heard of.
Lastly, follow the existing behavior of invoices, where the down
payments were shown in a separate section. Now a dedicated section
will be added to the sales order and propagated to the invoice,
if there are down payments to deduct.
Task - 2702407
closesodoo/odoo#82376
Signed-off-by: Victor Feyens (vfe) <vfe@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>
Steps to reproduce:
- Create a quotation
- Add a product that is invoiced on "ordered quantities" and set the
quantity to a negative number.
- Leave 'delivered' to 0
- Confirm the quotation
- Create the Invoice and validate it.
- Go to the SO list view (Orders > Orders)
You should see that the Invoice Status of the order you just created is
'Upselling Opportunity', which is not correct.
Why this is happening:
Here's an explanation on the 'Upselling Opportunity' state (found in
the code):
" upselling: this is possible only for a product invoiced on ordered
quantities for which *we delivered more than expected.* "
In our case, the invoice line's state is set to 'upselling'
because we have a negative ordered quantity and a zero delivered
quantity (i.e. we delivered more than expected)
opw-2895218
closesodoo/odoo#97830
X-original-commit: 5f10583336bf39430a304e2c47dfd0310ee4fa3d
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
New common based on new common infrastructure (base, uom, product, sales
team).
* Conversion of existing tests to use the common
* Remove invoicing tests common dependency when not needed (overkill
setup for most tests)
* Move tests to the correct test file.
* Rename test_sale_pricelist into test_sale_prices and add tests to
improve coverage of price computation.
* new file test_controllers to regroup all tests covering the routes.
* Speed up tests setup by creating records in batch
* Reduce tests setups and use more the common tests data.
Part-of: odoo/odoo#96791
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
Before this commit, orders were not confirmed when there was more than
one transaction linked to them, regardless of their state.
As of now, we check if there is only one confirmed transaction (meaning
that the state of the transaction is either 'authorized' or 'done').
Fix 4d2b04a843
task-2906040
closesodoo/odoo#95443
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When `sale` is installed alone,
the test fails because it changes the field `product_uom`
which is invisible in the view because the user executing the test
doesn't have the appropriate group.
```
FAIL: TestSaleOrder.test_fiscalposition_application
Traceback (most recent call last):
File "/data/build/odoo/addons/sale/tests/test_sale_pricelist.py", line 292, in test_fiscalposition_application
line.product_uom = uom
File "/data/build/odoo/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```
closesodoo/odoo#95910
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Steps to reproduce:
1- install sale, invoicing
2- create a product p with price pr
3- create a new Sales Order SO with p and edit the price
to any other price than pr
4- create an invoice
5- go to SO, reduce quantity to 0 ( customer returns the item )
6- the unit price is set back to pr and there is no way to edit it
Bug:
in 836f463c97 the `_compute_price_unit`
method was changed from onchange to depends which caused the edits now
to be commited to memory.
While it can be beneficial for other flows, for this specific use case,
it is not
Fix:
make an exception for lines with already invoiced quantities
OPW-2830824
closesodoo/odoo#94482
X-original-commit: b77346926f634f2f06fe1b06b68835a360ae91c5
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Rework and code cleanup of automatic invoice and auto-confirm order
flows.
task-2541188
closesodoo/odoo#72368
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
During the payment pocalypse, new tests common were introduced. Those
commons were split into different classes to be as modular as possible
but we noticed during the following months (/year) that they weren't so
easy to understand and use.
Therefore, this commit aims to simplify those commons by removing the
core PaymentTestUtils common, integrating it in the base PaymentCommon,
and making the HttpCommon depend on the core PaymentCommon, instead of
using only the utils.
This doesn't require much changes in the tests since they all used
either the PaymentCommon or both PaymentCommon and PaymentHttpCommon.
Task - 2848326
Part-of: odoo/odoo#90716
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, when cancelling a SO, the wizard opened only when
there were draft invoices or delivered picking in the order.
In order to complete the notification flow of the SO and avoid
unexpected cancellation of orders, the user must now confirm
cancellation and gets to possibility to send an email notification.
task-2660895
Part-of: odoo/odoo#81569
Have the taxes:
- [Ftax] any% included in price
- [TAX1] 15% not included price
- [TAX2] 15% included in price
Apply [Ftax] and [TAX1] to a product having product price [PRI]
Have a fiscal position mapping [TAX1] to [TAX2]
Make a SO with the fiscal position, add in a line the product
The unit price will not be [PRI] but will increment. This occur because
when doing the mapping we apply the computation for incl->* mapping
when just one tax is included in price
opw-2797237
closesodoo/odoo#90804
X-original-commit: 290e5a6a411ad193ab5695eba02cc4142b3a48fe
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Create a 15% tax [TaxA] *not* included in price
Create a 15% tax [TaxB] included in price
Create a fiscal position mapping TaxA to TaxB
Create a customer and assign this fiscal position
Create a product :
Price = 100€
Tax = TaxA
Create a SO with this customer and this product
We have this situation
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 115 | TaxB| 100 |
While it should be
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 100 | TaxB| 86.96 |
after tax mapping, as it was before
https://github.com/odoo/odoo/commit/625486a8382fde9033b73e2a4b4e7713cf4131c1
opw-2811596
closesodoo/odoo#89361
X-original-commit: 1a5b2b44c63afb302a2d6fc1e841e4ef3af46df5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Enable discounts
Have a price included tax 10%
Have a product with sales price 100$
Make a SO adding the product, the price incl. tax and a 1% discount
Open the portal page of the quotation
In the left recap sidebar the price before discount is reported to be
100.10 while it should be 100.0
opw-2759804
closesodoo/odoo#87418
X-original-commit: db6994c2ac991822014d168022c854ba75f3095f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
If applied, this commit will fix the following bug by changing the
price used in the discount calculation equation to be the real price.
the two prices differs when mapping a tax inculded price to a tax
excluded price
Steps to reproduce:
1- install sales - accounting
2- create a product p with customer tax t
3- create a fiscal position for a country (belgium for example) that
maps t to a lower value tax.
3- create a pricelist pl with discount d
4- create a new SO, add a customer from belgium, add p, then select pl,
click on update prices
5- the discount is not d, it is calculated based on
(p price - customer tax)
in comparison to:
4- create a new SO, add a customer from belgium, select pl first, add p
5- the discount is d.
Bug:
the wrong price is being used for discount calculation
Fix:
calculate and use the correct price similar to the normal behavoir when
the pricelist is selected first
OPW-2745421
closesodoo/odoo#87882
X-original-commit: 43f938627ad91bab2ec233756041d5712ee29323
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Feyens Victor (vfe-odoo) <vfe@odoo.com>
Use case
--------
Field computed with precompute=True at creation get the value
of the float without beeing rounded this can lead to rounding
issue where the value computed at creation is different from
the value computed later.
This can lead to the following issue
A so line is create with a unit price of 192 and a discount of
74.246 the price subtotal it thus 49.45
Later a invoice is created based on the same unit price and a discount
rounded at 74.25 and thus a subtotal 49.44
Solution
--------
Since the issue is not fixed (yet) in the orm, we have to format the
provided discount before the record creation (and precomputation)
to make sure the decimal precision is properly applied and that
no incoherence is introduced in the final record values.
closesodoo/odoo#87661
X-original-commit: 2257ac71596033d8d9f1deaf642071124817de3f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
How to reproduce the issue
--------------------------
Set the quantity of a sale order line to 0.0
then change the product_uom of the line
it triggers the computation of the product_uom
and the quantity is changed to 1.0
After this commit
----------------
The default value is not embedded in the compute anymore
The value do not change each time the compute is triggered
if the value was 0.0
closesodoo/odoo#87166
X-original-commit: 9015d25617b3992b0129547a1bec8887d6462bc5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Create a 21% tax included in price
Create a 6% tax included in price
Create a fiscal position that will replace the 21% tax included by the
6% tax included
Create a customer and assign this fiscal position
Create a product :
Price = 121€
Tax = 21% tax included
Create a SO with this customer and this product
Create an invoice (from scratch) with this customer and this product
SO : the unit price is 100,00€
Invoice : the unit price is 106,00€
Fix by creating a common method to calculate the price_unit
opw-2699793
closesodoo/odoo#86514
X-original-commit: 8ab56af6827a640a3f41a87905778432b3786c00
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The aim of this commit is to correct the compute_all calculation
when it is dealing with an article with 0.00 price and having a fixed
tax included in it.
In this situation, this means the tax is directly taken as an expense
by the company that offers it to its client.
This also solves the situation in which we have a 100% discount because
discount is applied before calling `compute_all` by changing the
unit_price.
Before this commit:
Creating an invoice with a line having a price at 0 or a 100% discount
and a fixed tax price_include resulted in a really weird behavior: the
company had to reimburse the customer for the amount of the tax.
(what a lucky customer :D )
After this commit:
Customer is sad, he only gets the product for free.
The base is calculated as negative, resulting in a debit amount on the base
income line.
The tax is then counterbalance by it.
The form is displaying a negative untaxed amount, a positive tax and the
total is 0.
closesodoo/odoo#86223
Ticket: 2660808, 2637512
Community-pr: https://github.com/odoo/odoo/pull/85747
X-original-commit: 727d19cb4e012e9a24d94640987ac5ea6f452a2e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
Steps:
- Create an Analytic Account AA
- Create an Analytic Default Rule : when Product P > AA
- Create a Quotation including P, confirm and invoice
Issue:
- AA is not set for the invoice line of P
Cause:
- AA is computed on the invoice line when the product is added,
but it is recomputed afterward from cache, where it is None
Fix:
- Not allow it to be recomputed afterward.
opw-2714340
closesodoo/odoo#82639
X-original-commit: 34b7c834cb67e1dc1f3727f103489e084c4788bf
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the issue:
- Install eCommerce module
- Go to Settings
- Ensure `Product Prices` is set to 'Tax included'
- Create a new Product as storable
- Set `Sales Price` to $1.0 and `Customer Taxes` to 10.00 %
- Under `Variants` tab add an Attribute with 2 values
- Set "Price Extra" to $2.0 to one of the variants
- Go to the Shop and select the product
Issue:
The extra price badge does not include the taxes
($2.0 instead of $2.2), however the final price does.
Cause:
The price_extra field from ptav (used in the badge) does not include
the taxes.
However, when calculating the final price, we do first the sum of all
prices (including the extra prices) and then apply the taxes.
Solution:
In the template, for each 'variants', we call `_get_combination_info`
to get the variant.price_extra with taxes included/excluded
depending the `Product Prices` setting.
opw-2669871
closesodoo/odoo#81949
X-original-commit: 6f04935d14d595faa3bb8dd6ba9e0dcf1d694886
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Prior to this commit, the company of the invoices generated through the use
of the `sale.advance.payment.inv` wizzard were not forced to the one of the
related sales orders. From the compute method on account.move the company would
then be either the one of the journal or the current company.
It seems that context_keys were used 'at least in industry_fsm_sale' in order
to ensure that the company was correctly set (although the one of the task
was used instead of the one of the SO).
This commit ensures that invoices created through the wizzard now takes the company
of the SO they are generated from.
Finaly this commit adds a multicompany test in the sale module in order to ensure
that the `sale.advance.payment.inv` wizzard is not impacted by the multicompany.
task-2608812
Closes: #79926
Cache the pricelist rule used for price computation in a dedicated non
stored field, since it is used both for the price_unit and the discount
computation.
This divides by 2 the number of pricelist requests/queries when
discounts computation is enabled.
Steps to reproduce:
- Install and launch sales
- In settings: activate price lists and discount; price list based on advanced rules
- Create a new price list; based on percentage (54%)*; applicable on all products; show discount
- Make sure the Public Price List has show discount activated
- Create a new quotation
- Select the Test pricelist
- Select a product (price 0.03 eur/$/other)*
- Change the price list to Public price list
- update the prices
- change the price list to Test price list
- update the prices
-> The Discount shown is not the one defined in the price list (66.67%)*
*(values for my example)
Solution:
Use the real price and not the a posteriori-rounded price for the computation of the discount in the `update_prices` method.
opw-2677884
closesodoo/odoo#81395
X-original-commit: 986dbc20952caae9d5a1b4b7ee34cfb994dea077
Signed-off-by: yosa-odoo <yosa@odoo.com>
Denis Ledoux