Using group of taxes with type_tax_use='none' children messed up the sign of the tax_base_amount and line tags.
closesodoo/odoo#63479
X-original-commit: 3642c429899c4d5def27c9ba10ae76c763a8a566
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This reverts commit 7e3e99adb4.
Usability of that new wizard was too poor. We revert it for now; it'll make a comeback eventually.
closesodoo/odoo#63436
X-original-commit: 1d75786b8b45fd4f6b08d726165b60875b62b1e7
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before that, using an auto-validate reconciliation model to match an invoice with a statement line with a lesser amount resulted in the creation of an payment entry with which the invoice got fully reconciled, and the difference amount was fowarded to the suspsense account in an additional line. This wasn't correct, as we expect the invoice to be only partially paid in that case (with an amount equal to the statement line's).
closesodoo/odoo#63303
X-original-commit: 7393aa3ebcea7b80762b729315f1c890bc677efb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
1) in this commit, improved portal chatter for messaging. when the user sends a
message, the new message is updated in history without reloading page.
instead of submitting a form which reloads page to send message we added rpc call
to send message.
2) rating on courses is implemented by extending portal chatter, applied changes in
website_slides to do reviews without reloading page
3) refactoring: cleaned or removed code
eg. removed form and some input fields as data is not submitted as form anymore,
introduced some methods to avoid duplication of code
task-2054662
Closes https://github.com/odoo/odoo/pull/47746closesodoo/odoo#47746
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Co-authored-by: ktr-odoo <ktr@odoo.com>
Co-authored-by: Siddarth Gajjar <sga@odoo.com>
Porting the tests from commit b501105d9d0b08395b993bcae1957ee5a1a1fb23
(the behavior was already correct on version 14.0)
Note:
- also added unit test for the use case of 226a1155124e890d00e33968feb43b9fd6b99fa5
opw-2371745
closesodoo/odoo#62688
X-original-commit: 902d2d9a91f9a1167fd1f51ad71c021cc1e6bfc1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287
closesodoo/odoo#62536
Related: odoo/enterprise#15031
Related: odoo/upgrade#1983
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
when a Vendor bill in an inactive currency is created (via an an EDI or the OCR,
or when the user create the invoice in an active foreign currency, then desactivate it)
it should not be possible to validate it.
Task ID: #2289537closesodoo/odoo#54096
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Activate multicurrency:
* EUR with rate 1.0
* USD with rate 100.0
Have a company in currency USD
Create an invoice (in USD)
* invoice line of 12.15, no tax
Save, post and register payment
In the payment widget change currency to EUR.
The amount will be automatically converted in 0.12
Register payment
Invoice will be still marked to paid as the amount paid is 12.0.
This occur because the system does not check if the amount to be paid,
expressed in payment currency, is what has been paid.
opw-2376336
closesodoo/odoo#62238
X-original-commit: 967a2ab323e273c853aee0edd5ce404f4d14e6ab
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this fix, the prefix was detected as `045-0` and the year as `1`
instead of no year with prefix `045-001`.
opw-2381351
closesodoo/odoo#61931
X-original-commit: e1b4521e82af1c865d69e9e0cf637713d0b94480
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Create a tax as follows:
* Tax Computation: Percentage of Price Tax Included
* Tax Scope: Purchase
* Amount: 100%
* Included in Price
* Affect Base of Subsequent Taxes
Create a vendor bill with the tax on the line
Change unit price
The total does not change
This occur because when having 100% tax debit/credit are unchanged.
So the onchange `_onchange_mark_recompute_taxes` is not triggered and
the tax lines are not updated, thus not changing the
total (as in this case the invoice total is just the tax value)
opw-2370861
closesodoo/odoo#61555
X-original-commit: 9e203cc016b45875f699ffab24fe3f8382a97303
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
We need to ensure the name stays consitent with the journal_id and the
date when we try to change one of those fields.
X-original-commit: 634aaeeac36d2371743338536466a0bcc9ad6c69
Use case:
1) Create an invoice matching reconciliation model, matching 90% percent of the amount, with a write-off line applying a 100% write-off of the remaining amount.
2) Create a 100€ invoice
3) Create a bank statement with a 90€ statement line whose payment reference corresponds to the one of the invoice
4) Click 'reconcile' on the bank statement
On enterprise, this crashes when preparing the data to give to the reconciliation widget, as the write_off_vals key is not set properly by the call to _apply_rules.
OPW 2367754
closesodoo/odoo#61265
X-original-commit: 1dd6199519b4ad5b5b17dfa17965ededcecb6da4
Related: odoo/enterprise#14563
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before that, even though the code contained something about it, the duplication of account.journal objects handled their code field pretty poorly (as it was trimmed to 5 characters), leading to situations where journals could have the same code, leading to possibility for account moves to have the same name.
This commit improves the SQL constraint testing journal codes so that they must now be unique per company. We also recompute the code in a more advanced way so that journal duplications works as smoothly as possible.
Task 2346404
closesodoo/odoo#59791
Related: odoo/enterprise#14447
Related: odoo/upgrade#1880
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Some tax_base_amounts checks were missing
- The type of repartition used to generate tax lines was not tested; it made the test confusing (as in this case, sales taxes invert their tag, given here the impression the wrong repartition was used, and potentially shadowing a bug)
closesodoo/odoo#60966
X-original-commit: c703b3a2f5a2d4d8bfbf0bc14203dde1b1bdec23
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this, misc operations always used the balance of the base line as the tax_base_amount of the tax line. This was inconsistent with the invoices, for which we invert its sign when making a sale invoice or a purchase refund (as for those operations, positive amounts are put in credit). This commit should make everything behave in the same way.
closesodoo/odoo#60912
X-original-commit: 2ca3158ce2de596526067dbd86da2ef7d4ae85bd
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
* Analytic defaults keep their old value
* The date_maturity is non-sense, it isn't set on lines needing analytic
* Analytic default should work for misc. operations too, but only for
product/service lines on invoice documents.
closesodoo/odoo#60904
X-original-commit: 4d2b8dd1bef40c592215728fab6c31f192176e93
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
When switching immediate payment term to 30% advance then back to immediate payment term, the receivable line is back to its previous value.
This is due to the '_get_fields_onchange_balance' that is not updating correctly the business fields since price_subtotal == amount_currency.
So, when `writing`, debit/credit are removed from the dictionary because the values are the same as before. However, `price_unit` hasn't be updated with the new value and remains as its previous value.
It leads to a recomputation of accounting fields regarding the business fields and then, trigger the unbalanced journal entry.
closesodoo/odoo#60654
X-original-commit: 18b5ad16a442404061b1028c2ffd82f179beaba3
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Behavior before the fix:
- if you create a sales order for a customer invoice address (a child
partner record), then create the invoice for that order, the partner_id
is not consistent between the move_line (some get the child partner id,
some get the commercial partner id = the parent partner id)
- if you create the invoice directly from the accounting app for a
child partner, the commercial partner id is used consistently for all
move lines (the invoice itself keeps the child partner id)
Behavior after the fix:
- when an invoice is created from a sales order, the partner id is set
using the commercial partner id, consistently for all lines (in this way
the behavior is consistent with that of the accounting app)
It is more appropriate to use the commercial_partner_id for this purpose
as it is used pretty consistently in the account_move file
opw-2347878
closesodoo/odoo#60302
X-original-commit: cd299518ae45f2732d47788869b013be16b814e8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
- Create a tax:
5%
Included in price
- Set the company currency to USD
- Set the currency rounding of CHF to 0.05
- Set the rate for CHF to 0.654065014
- Create the following invoice in CHF:
Set a payment term
Prod 1, 1 unit, 5.0 CHF, tax 5%
Prod 2, 1 unit, 10.0 CHF, tax 5%
Prod 3, 1 unit, 50.0 CHF, tax 5%
It is not possible to save the invoice because of an unbalanced journal
entry.
Indeed, the Receivable line is $99.30 while it should be $99.29. This
happens because we round the `total_balance` with the rounding precision
of the invoice currency while it is in the company currency.
closesodoo/odoo#58798closesodoo/odoo#60035
X-original-commit: dad5e2a575448b68cc1b59880fecfe48dbe30a4e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a tax:
5%
Included in price
- Set the currency rounding of the company to 0.05 (e.g. CHF)
- Create the following invoice
Prod 1, 1 unit, 5.0 CHF, tax 5%
Prod 2, 1 unit, 10.0 CHF, tax 5%
Prod 3, 1 unit, 50.0 CHF, tax 5%
The total amount of the invoice is 64.95 CHF instead of 65.00 CHF, even
in a 'Round per line' configuration.
It happens because `compute_all` rounds the amounts following the number
of digits of the currency instead of using the `rounding` field.
Note that there is a discrepancy between the POS computation and the
Account computation: the POS already uses the `rounding` field instead
of the number of digits:
https://github.com/odoo/odoo/blob/80073c5430f0ab562dfc27572c108114161ebb25/addons/point_of_sale/static/src/js/models.js#L1855-L1991
opw-2341566
X-original-commit: 94353ebd6b47a286157f0559b194ff03ea49ff68
To reproduce the issue before this fix:
1. Create accounts ACC TAX A, ACC TAX B, with reconcile = True, internal_type = other
2. Create Tax B, with tax_exigibilty = on_payment and account_id = ACC TAX B and cash_basic_account_id = ACC TAX A, 20%
3. Create invoice B, account_id = Tax B, unit_price = 1000, Valide invoice,
4. Register a payment of 600 for invoice B (so, that's half the invoice, when including the taxes). The cash basis tax creates a miscellaneous operation MISC A, containing a line on ACC TAX A.
5. Create a mis operation MISC TVA, like this:
line 1 : account_id = ACC TAX A, credit = 100
line 2 : account_id = 401100, debit = 100
6. Reconcile the following move lines:
line of MISC A with account ACC TAX A (100)
line of MISC TVA with account ACC TAX A (100)
==> The lines should be fully reconciled
To solve that without breaking the fix made here https://github.com/odoo/odoo/commit/c43acc34b873dc70cf792675fe1d58d8b0e116b1 , we rely on the tax_exigible field of account move lines. When all the reconcile lines are exigible, it means we're not reconciling the transition line of a cash basis entry, and so we can directly full reconcile.
Fixes https://github.com/odoo/odoo/issues/58996
OPW 2350494
X-original-commit: b8ab3c78ff9354091f5154bb03a716c32a609de2
It's needed only on using skipTest in SavepointCase.setUpClass.
From docs https://docs.python.org/3/library/unittest.html#unittest-skipping:
> Skipped classes will not have setUpClass() or tearDownClass() run.
This may lead to running out of available sql connections. It mostly happens in
odoo.sh, which has max connections set to 16, while default value is 64
Fixes#56636
opw-2345762
closesodoo/odoo#59388
X-original-commit: b7f922050217634cdf85d15cae62b78fa3ce1834
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not round the unit price when calculating the company currency price
used to calculate the tax. This avoids rounding errors when the company
currency amount has been calculated based on a converted (and rounded) unit
price.
Corrects a regression bug introduced in 13.0. The behavior has been
corrected in 14.0 by a more extensive rework of the accounting module
(commit id 419d4bbee0 among others).
This fix seeks to correct the bug with minimal impact.
In version 12.0, the tax amount was calculated strictly based on the
total amount, which avoided compounding the rounding issue but had some
other problems (see https://github.com/odoo/odoo/issues/35358).
In version 14.0, the problem does not exist. This commit only includes
the unit test.
Current behavior before PR:
For example: 20000 @ 2.82 with a rate of 1.1726 gives a
tax amount in foreign currency of 11844, which is 10100 in company
currency. But if the company currency amount is calculated
based on a unit price of 2.4 (rounded converted amount of 2.82), the
calculated tax amount will only be 10080 in company currency.
Desired behavior after PR is merged:
Tax amount is calculated based on the total amount in the foreign
currency, not the amount based on the rounded unit price.
opw-2340933
closesodoo/odoo#59365
X-original-commit: 14c86a020429dfc6b545b65b89cbc7e3828dc557
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Before that, making a misc operation with cash basis taxes always set the move lines as tax_exigible=False (or at least, it was supposed to, see below). This was wrong, as if the move did not contain any payable/receivable account, it would result in no cash basis move being ever created, and so the entry would never affect the tax report.
Additionnally, the tax line was wrongly managed for cash basis taxes on misc entries, as vals.get('tax_ids') returned an ORM command, so a non-False value, even when the tax_ids field was empty. this caused the condition to execute and to reassign taxes to an empty list, which then caused tax_exigible not to be set to False, even when it should.
X-original-commit: https://github.com/odoo/odoo/commit/2437eb0691d07f92094152b84c96a2149c8f4fd8
[FIX] account: make tax exigible correct in cases where the move lines are created separetely from the move.
Additional fix on top of https://github.com/odoo/odoo/commit/02fe997932070cc101a96eb869023702c224318b
Also, add tax_exigible to the form view of account.move.line, as it will not be computed automatically anymore when modifying a single line in draft state through its form view. It now needs to be manually changed in case the user wants to change something having an impact on it through this form (note that this is absolutely not a typical use case).
closesodoo/odoo#58260
X-original-commit: 867797e4983b704599be7943490fc6f071d8c0b7
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The SELECT FOR UPDATE clause stopped concurent executions but did not
prevent from writing on other rows.
By doing a real UPDATE, we now have the desired behaviour with a
SerializationFailure error.
closesodoo/odoo#58118
X-original-commit: ba6ee0b75d66d6f22a592b1b6a7c5158461bec41
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Solves https://github.com/odoo/odoo/issues/56803
Use case:
1) Create accounts ACC TAX A, ACC TAX B, with reconcile = True, internal_type = other
2) Create Tax A, with tax_exigibilty = on_invoice and account_id = ACC TAX A, 20%
3) Create Tax B, with tax_exigibilty = on_payment and account_id = ACC TAX B and cash_basic_account_id = ACC TAX A, 20%
4) Create invoice A, account_id = Tax A, unit_price = 1000, Valide invoice
5) Create invoice B, account_id = Tax B, unit_price = 500, Valide invoice,
6) Register full payment for invoice B. The cash basis tax creates a miscellaneous operation MISC A, containing a line on ACC TAX A.
7) Create a mis operation MISC TVA, like this:
line 1 : account_id = ACC TAX A, credit = 300
line 2 : account_id = 401100, debit = 300
8) Reconcile the following move lines:
line of MISC A with account ACC TAX A (300)
line of invoice A with account ACC TAX A (200)
line of MISC TVA with account ACC TAX A (100)
==> When doing that, not full reconcile object was created between the reconciled lines, while it should have been.
X-original-commit: ff35a49
[IMP] account: reintroduce a test that should have been forward-ported …
This test was made together with a bugfix by https://github.com/odoo/odoo/pull/51529 . The fix did not need to be forward-ported to 13.0, but the test should have been, so that we are sure it does not break again in the future.
closesodoo/odoo#58072
X-original-commit: 5d00592f7d803888d8d5befd5a8cd1b096067860
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before that, write-off rules with partner mapping did not work properly, as the partner they selected got lost when passing the values to the widget, which later made a second rpc call to fetch the write-off details. Now, we pass all the values directly, including the selected partner. This way, we remove the need for a second rpc call when processing the results for the reconcile models, and the partner is handled properly.
X-original-commit: d74db80d11e603719eefa5799ac1f8ac2afa2540
Task 2327599
* The date is not copied on duplicate of account.move
* Do not throw traceback if we remove the invoice date of an
invoice/bill
* Add extra triggers in account_tour to ensure it is done in the right
view
* Update the position of some tour indicators
* Move the Product Categories in the Management menu
* The accounting onboarding is only visible on customer invoices list
view
* Switch the position of banc and bic
closesodoo/odoo#57420
Related: odoo/enterprise#13122
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The peformances were bad when posting a lot of moves at the same time.
This is because a SQL query was executed for each document to retrieve
the last sequence used to build the new one.
By batching the documents to sequence, we can reduce drasticaly the
number of SQL queries done.
X-original-commit: ff26e093c98a5b933620642e242530a8931c1471
Added edi.documents representing an electronic document for a move and an edi.format.
A format can be asynchronous if it needs to call a web-service to generate the document, it will then be generated by the CRON (otherwise it's generated in post).
The formats can support payments if needed (can be generated immediately or by the CRON).
Added support for errors and related views.
Setting defaults format on a journal can be done automatically (based on a hook).
Added tests : xml comparaison with diff and helpers to test a EDI import/export
--task: 2247368
The browser itself would get mostly cleaned up between tours, but the
session object would not get cleaned, and apparently in some cases
that could lead to an incoherent session: a tour would add data to the
session which the next tour (logging in as a different user) would
not (fully) override, leading to a session inconsistency and a Session
Expired exception during the tour.
Fix by not storing the session on the test object, the session is
created during authentication then set on the opener & browser.
Task 2292368
Bundle
https://runbot.odoo.com/runbot/bundle/master-reconcile-model-boost-wan-60105
* Search in Notes and References, not only in the statement's
communication.
* Activate the partner mapping for Suggest Counterpart models
* Always show the Amount Matching field
* Do not block the deletion of models with a partner mapping
* Allow to archive models
* Add a button to get back to Processing state from Validated state on
bank statements.
closesodoo/odoo#55031
Related: odoo/upgrade#1619
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
There are inconsistencies in the m2o accounts create & edit behavior.
New off-balance account type was not correctly filtered
This change correct those two issues
Task ID: #2288757closesodoo/odoo#54626
Related: odoo/enterprise#11920
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- Create Tax 0:
Percentage
Amount: 0
Tax Included
Tax Group 0
- Create Tax 8:
Percentage
Amount: 8
Tax Included
Tax Group 8
- Create a customer invoice with one line
Quantity: 8.0
Price Unit: 15.55
Taxes: Tax 8, Tax 0 (order is important)
The tax amounts are:
Tax 8: 9.22
Tax 0: -0.01
If the taxes are inverted, the tax amounts
Tax 8: 9.21
Tax 0: 0.00
The difference is due to the rounding of the 8% tax done differently. In
the second case, the computation of the 8% tax goes through:
https://github.com/odoo/odoo/blob/8c5cd335a57c20ed5faa6b7c7630c296c1f2a5cf/addons/account/models/account.py#L1480
In the first case, the amount is recomputed in:
https://github.com/odoo/odoo/blob/8c5cd335a57c20ed5faa6b7c7630c296c1f2a5cf/addons/account/models/account.py#L1483
The rounding is different in both cases, leading to an inconsistency.
When the tax amount is zero, there is no need to save the amount in
`total_included_checkpoints`.
opw-2306676
closesodoo/odoo#55812
X-original-commit: e2776e188070221ef465a864bd2cb8dcfc971e14
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Change ValidationError to RedirectWarning, RedirectWarning is usefull to redirect user to
the problem. For the lock date, we can redirect user to unposted entries or unreconciled bank statement lines.
Task ID: 2297407
The problem of using fields.Date.today() instead of
fields.Date.context_today() arose with the recent changes in the
account.move._post() method used in the POS tests, around 1 am.
This commit changes all occurences of today to context_today.
closesodoo/odoo#55511
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Thanks to this setup, we will be able to run the tours independently to any demo data.
To do so, the HttpSavepointCase is born to do the same as HttpCase but with a setUpClass.
--task: 2290120
Jigar Vaghela