A former constraint made it impossible to import bank statements with lines = 0.
The task #2403369 removed that constraint.
But the user could no longer reconcile Bank Statement Lines = 0.
Drawbacks :
- The user is then blocked when setting a lock date.
- The bank statement remains endlessly in Status Processing
A previous fix made a bank statement line = 0 immediately reconciled.
Closes task #2449127.
closesodoo/odoo#65359
X-original-commit: ee4f7df8d34593bdde3fc6f9bd062f6dad238fcb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When the suspense account is not reconcilable, 'suspense_lines.reconciled' always gives 'False' leading to a not reconciled statement line.
closesodoo/odoo#65290
X-original-commit: 73ddcfbcc58b7a6542ced4bd8b20dd67c9f446ee
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When reconciling a statement line with multiple lines in a multi-currency environment, it could lead to a rounding issue due to the currency rates. It could lead to an auto-generated open-balance of 0.01 amount to auto-balance the journal entry but the result is wrong since the partner has an open amount left on the receivable/payable account.
closesodoo/odoo#64636
X-original-commit: 4d4e6e588d14742f153a1c6b67d510e0c21e5d64
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This reverts commit 9d4b22fbf6469ada08c28bc2afcd5b5492eac52a.
We don't want to support this use case, as this kind of configuration change in the middle of creating an invoice is a very narrow corner case that can be avoided easily. Supporting it for tax exigibility would mean we also need to support it for repartition lines, amounts, affect base, ... This would be a lot of overhead for nothing.
closesodoo/odoo#64580
X-original-commit: ec414a5bb785375d13ea324f345c1eaf5747ddfa
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When posting an account move before the tax lock date, Odoo will
automatically set its accounting date to the lock date + 1.
This can cause the chronology to be broken, which is not something we
want when automatically setting the date.
This will change that behavior to set the accounting date to today in
such case.
Task id #2411150closesodoo/odoo#62787
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When the name of a partner contains a regular expression operator, such
as grouping parenthesis, +, *, brackets... the resulting regexp may
match wrong names or worse be invalid and lead to an exception.
With this commit, we create a regular expression from only the words
formed from at least 3 of [a-zA-Z0-9], ignoring all other characters,
including those who may have a meaning in a regular expression.
This avoids these issues:
- regexp injection (security issue)
- punctuation resulting in erroneous regular expression ("ABC + SPRL"
resulted in "(?=.*ABC.*)(?=.*+.*)(?=.*SPRL.*)" which is invalid at
the ".*+" part)
- false positives due to words that are too small (\b were added, and
the minimal matching word size is 3)
- accentuation mismatch (both sides are filtered through unaccent)
- special cases in unicode that have a special behavior with lower().
See the discussion on odoo/odoo#63145 for a detailled explaination about
these issues.
OPW-2360687
closesodoo/odoo#64510
X-original-commit: 3c5296863f0030acc5d3dba0ff73a6f1b42d1255
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Reconciliation models can now create partial payment on invoices. Because of that, the default behavior is not anymore to fully pay the invoice and create an open balance write off.
In some cases, though, this is what we want (exchange difference, ...). The solution for that is to create a reconciliation model with write off lines (telling it it must only apply if there is a 90% percent match on the amount, for example), and then create another one not checking the amount to just match the things to reconcile partially by using the partner.
However, as it is now, reconciliation models always bypass the check made on the amount in case the statement line's label matches the invoice's payment reference exactly. This can lead to cases where we are matching elements we shouldn't with the rule doing the write off.
Example:
- use only two 'invoice matching' reconciliation models, in the following application sequence:
- model 1, matching partner if with amount matching percentage is 90%, and doing a write-off for the unmatched amount
- model 2, matching partner with no amount matching percentage, and no write off
- create an invoice with payment refrence INV1 for partner A, amount: 100
- create an invoice with payment refernce INV2 for partner A, amount: 200
- create a statement with two lines:
- line 1, with 99 for partner A, label= INV1.
- line 2, with 1 for partner A, label= INV2.
- Open the reconciliation widget
==> Before the fix:
model 1 is applied on both statement lines, as their label match payment references. This is what we want for line 1, but probably not for line 2, which will create a write off of 199, while we'd have wished for a partial payment, leaving the invoice with 199 open.
==> After the fix
The behavior is the same unless the config_parameter is set. If it is:
- line 1 will be matched by model 1 (as 99 - 9,9 < 100 < 99 + 9,9). INV1 will be paid with a write off of 1.
- line 2 will not be matched by model 1 (as 200 is not between 1 - 0,1 and 1 + 0,1), but it will be by model 2 (since line 2 and INV 2 share the same partner). So, INV2 will be partially reconciled with line 2.
OPW 2419030
closesodoo/odoo#64504
X-original-commit: ed023e208736e58d14649aa2fd91fb00510f20c1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before that, write-offs were simply never created in this case ; only an open balance. This was (obviously) wrong.
Also, the partner set on the statement line was not modified, and kept empty. We fix that so that, when a statement line without is reconciled with lines sharing the same partner, this partner is also assigned to the statement line.
Task 2423231
closesodoo/odoo#64253
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create an invoice for 100
- Create a bank statement for 95
- Setup your reconciliation model so that it will match them and create a write-off for the remaining 5. Make it auto_reconciled.
=> Doing that, we expect the bank journal move to be created like this:
- 100 on payable/receivable, reconciled with the invoice
- 95 on the bank account
- 5 on the write-off account
This wasn't the case. Instead, Odoo created the following (correct from an accounting point of view, but weird):
- 95 on payable/receivable, reconciled with the invoice
- 5 on payable/receivable, not reconciled
- 95 on the bank account
- 5 on the write-off account
=> So an open balance of 5 was actually created. This was weird, and also caused an additional bug, as only the first payable/receivable line was reconciled with the invoice, making it only partially paid.
This commit restores the expected behavior.
In the bank reconciliation widget, allow matching a payment (blue lines) owned by another bank journal as the statement line one if both journal are sharing the same outstanding account.
It implies to remove the constraint preventing such accounts sharing.
The purpose is the following.
Suppose you are working with payment acquirers generating payments on a bank journal A.
At the end of the month, the bank journal B is debited to pay the payment acquirer.
At this point, you get a statement line on journal B you need to match with payments generated on A.
closesodoo/odoo#64115
X-original-commit: 8d34e1606f930deaa148563ffd40c69457650305
Related: odoo/enterprise#15577
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a new sales journal;
- Start creating a new invoice using the new journal (the name/sequence
will be editable) and before saving, change the journal to the
old one;
Before this commit, the invoice will be on the old journal and will have
the new journal name/sequence and after validate the invoice all the new
invoices on the old journal will have the new journal name/sequence.
Now, when you change to the old journal the name of the invoice came
back to 'Draft'.
opw-2415975
closesodoo/odoo#64146
X-original-commit: 3b64640076af472b64a72c7061696772d0e118de
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
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
John (jol)