When creating a new invoice by giving it an invoice_line_ids list for
which the last line is a note, the tax line may be created wrongfully
without partner_id, which is totally wrong.
To reproduce :
Create a SO
Set a customer
Insert a product with tax
Insert a note
Deliver the product
Invoice the SO and confirm the invoice
The partner_id is not set on the created tax line
While the issue only arises in 15.0, it brings to light that the partner
is not in the grouping keys while it should, so it will be changed in 13.0+
opw-2750851
closesodoo/odoo#83999
X-original-commit: 2ce994d279126aa0356b86d3fa38b699e9035e54
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Storno accounting is the term used to described the process of recording
a reverse action as a negative amount on the same site instead of a
positive amount on the opposite site of the credt/debit.
For instance, when one creates a credit note for an invoice, the values
of debit and credit will be kept in the same column with negative signs
instead of swapping columns like in non-Storno accounting.
It is a business practice commonly used in Eastern European countries.
Countries where Storno accounting is mandatory or considered as best
practice would be :
Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine, Croatia,
Bosnia and Herzegovina, Serbia, Romania, China, Russia, Slovenia
It is available as an option in the settings and is automatically
activated for some countries which use this type of accounting.
otask-2064899
closesodoo/odoo#79581
Related: odoo/upgrade#3212
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: qdp-odoo <qdp@odoo.com>
When creating automatic entries for multiple moves on different dates with the automatic entry wizard, the wizard would reconcile all the lines on the accrual account of the destination move with the lines on the accrual account of each accrual move. As this would imply reconciling the same lines multiple times, it triggers a reconciliation error.
What must be done is, for each accrual move, reconcile it’s lines with only the related lines on the destination move.
closesodoo/odoo#83732
Task: 2717578
X-original-commit: 502003ac548d6620374dfbab4fb7be6dee3c1bf5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
In master, the tax template consistency test
is broken since 8fb53c53c3
Fix this to make sure we add an exception for
that new computed field as it should not be in
the template.
closesodoo/odoo#83724
Signed-off-by: Florian Gilbert <flg@odoo.com>
To reproduce:
1- Configure a 0.05 cash rounding modifying the tax amount
2- Create an invoice using this rounding, for 3€, with a 21% tax (configured with some tags related on tax repartition; a Belgian one for example). => This will create a 0.02 tax rounding move line, for a total tax amount of 0.63 + 0.02 = 0.65
3- Check the tax report => Only 0.63 appears
This is wrong and leads to inconsistencies with the tax closing (which will consider 0.65 because of the tax account used), or the generic tax report (which only considers tax_line_id field, not tag_ids). The tags should be copied from the line we intend to modify the tax amounts of.
OPW 2714411
closesodoo/odoo#83091
X-original-commit: e8e4b0fe3913aadb0c8e1f958b65a24543e6fd9d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Steps to reproduce:
Have a 0% Tax
Make an invoice with it
Open tax report
The 0% tax is not present in the report because there is no tax lines generated for them because the resulting balance is zero.
Since the tax details is making a mapping between tax lines and base lines and the tax report is using them to compute the report, the tax report is not able to compute the tax base amount for such taxes.
Explanation:
Until now, the tax line with a zero amount wasn't generated because considered as noisy journal items.
Now we must be able to groupby on the base tax account on the tax report, we are forced to use the tax details.
Injecting dynamically the 0% tax on the tax details sub-queries is really complicated and leads to a huge performance drop.
For that reason, we start to generate the tax lines for 0% tax even the balance is zero.
However, since there is nothing creating the missing lines in the past, it should be fixed case by case if needed.
opw-2711432
closesodoo/odoo#82971
X-original-commit: 65b5ec4ad65f798b1d647978b5b42a49e760139a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
HttpCase.base_url() was introduced with ded278b9c2 but many tests were
using the name attribute already. The tests have been adapted to use the
new method.
closesodoo/odoo#82910
Signed-off-by: Julien Castiaux <juc@odoo.com>
Steps to reproduce :
- Create an invoice for a customer (ex $100)
- Create a payment for the invoice (ex $100)
- create a bank statement with a line item for $200
- In reconciliation, add either another journal entry or a manual operation without partner to reconcile the remaining $100
Issue:
All lines receive the partner from the invoice
opw-2691196
closesodoo/odoo#82517
X-original-commit: 6cda0780fdccf666f5a3fb0f39db59fcb0bd45c8
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
The aim of this commit is to allow EDIs to create and save account move
even if a supplier reference is duplicated.
This is achieved by delaying the moment to which the constrains is
triggered.
Before this commit:
A user can only upload a bill once. (xml ubl format for instance)
If he needs to upload it a second time, he will be forced to find a
workaround.
After this commit:
User will be able to upload as many bill as he wants but will receive a
ValidationError when trying to post the invoice if the reference is
duplicated.
The user will be able to post the bill very easily by changing the
reference a bit if he wants to pursue.
closesodoo/odoo#82303
Community-pr: https://github.com/odoo/odoo/pull/81748
Enterprise-pr: https://github.com/odoo/enterprise/pull/23255
Task: 2612299
X-original-commit: 200614876e62192e1a5ce2f30ec7aa8a1de77672
Related: odoo/enterprise#23281
Signed-off-by: William André (wan) <wan@odoo.com>
When reversing the CABA entry, the CABA tax account was replaced by the transition tax account if not set on the repartition line.
To reproduce:
Set up a CABA tax with ACC1 as transition tax account and ACC2 as tax account.
When creating the CABA entry, there is a line on ACC1 and another on ACC2.
When reversing the CABA entry, both lines are now on ACC1.
Introduced by https://github.com/odoo/odoo/pull/79556closesodoo/odoo#82004
Issue: 2718413
X-original-commit: 2f6a35eb73978ce0638765fd0981c7e95d9df696
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- Create an account group for a range for example from 100000 to 200000
- Now edit the group to have a range from 100000 to 150000
Issue:
The accounts with code > 150000 are still in the account group
Solution
Adding an other intermediary table to the query in order to take into
account the accounts which have no group_id
opw-2695533
closesodoo/odoo#82023
X-original-commit: 05c3cb8dbb7a9bf0f438d5ee687b92e8d934f26b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Steps to reproduce:
- Create two bank journals Bank-1 and Bank-2
- Create one Oustanding Payments and one Outstanding Receipts account for each bank journal
- Create and confirm an internal tranfer from Bank-1 to Bank-2 for 100$
- A second payment is created
Issue:
The account on the line in the second payment is the Outstanding Payments account of Bank-1,
it should be the Outstanding Receipts account of Bank-2.
After this commit, the second payment will take into account the account set on bank journal,
and if not set, the one set on company. Otherwise, an error is raised.
opw-2711252
closesodoo/odoo#81938
X-original-commit: 51b5a9d4e56d8d2300cf1ee91f8030c57a41a856
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Consider this example:
- Create a 42% tax, price-included, with two tax repartition lines doing +100 -100
- Create an invoice of 100€ using this tax, and look at the move lines generated
==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line.
This is wrong, as we'd expect to see:
- 100 in payable/receivable
- 100 for the base line
- 42 for the +100 tax repartition line
- -42 for the -100 tax repartition line
The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff.
OPW 2716083
closesodoo/odoo#81771
X-original-commit: 9d24e3cf002bacb09d6e955b26124dda09c15f18
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.
This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.
As an example, consider the following case:
1) setup an invoice-matcing reconciliation model as such:
- Partner Is Set and Matches = False
- Match Invoice/bill with = Reference
2) Create an invoice with payment reference 123, for 100€
3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.
4) Try to reconcile the statement line
=> not match is found
OPW 2701729
X-original-commit: 74894b0da82f5f71cd22a3c9bb405696f908ef5c
Part-of: odoo/odoo#81730
Renamed the 'Other' account type into 'Non Trade' to enhance clarity and coherence
Changed the filtering system in the accounting search view to improve coherence with the filtering system available in the reports.
It is now possible to filter the trade/non trade accounts in the accounting views.
This change may be overriden by default selections already in place.
Renaming Receivable/Payable to Trade Receivable/Trade Payable could have turned out to be confusing for accustomed users.
They are now renamed Receivable/Payable, though the Non-Trade option is still present.
task-2669128
closesodoo/odoo#79752
Related: odoo/enterprise#21773
Related: odoo/upgrade#3004
Signed-off-by: Laurent Smet <las@odoo.com>
Have an MX database set up
Activate multicurrency (MXN and USD)
Have several rate for USD
- yesterday 0.047939098170
- today 0.048486729180
Make an invoice, dated yesterday for USD 116, tax 16% (cash basis)
Create a received payment dated today, for USD 116
Reconcile invoice and payment
Jounal items will be created for the invoice, for the exchange
difference and for the cash basis entries, but there are redundant
entries addressing the tax.
This occur because when reconciling the payment with the invoice the
system create the cash basis moves and reconcile them. During this inner
reconciliation exchange difference move are created (1) just for the tax
line.
Then the outer reconciliation flow continue and compute the exchange
difference moves, considering all cash basis items created before. A new
couple of journal items will be created to account for the difference in
tax, but this is redundant since it was already covered before (1)
opw-2685570
closesodoo/odoo#81624
X-original-commit: 03bf311bfde98f28a9b8e73953869a42b828c5e3
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Current behavior:
Invoices report had a wrong average price when invoice had credit note
Steps to reproduce:
Create a db with accounting
Create a customer C and a Product P
Create an Invoice for C for 10 pieces of P
Create a Credit note for C for 1 P
Go to Reporting > Invoice Analysis
Open the pivot view, in the Measures, display the Average Price, the Product quantity and the Untaxed Total
The Total multiplied by the quantity is not equals to the average.
opw-2557420
closesodoo/odoo#81238
X-original-commit: ef26467e288a12571c37d4c133b44f08d99cc702
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When paying an expense, we should take the bank accounts from partner instead of the ones set on the company.
Also, the computation of the partner bank account is different on the wizard and the payment.
To unify both models, the 'available_partner_bank_ids' should also be put on account.payment.
see https://github.com/odoo/odoo/pull/79737closesodoo/odoo#81236
X-original-commit: 89d8c0a1ea03919e9f3085ea0d05aa80ad443ff7
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Before this fix, all moves of type “entry“ were considered as misc operations in regard to repartition tags and the tax report. And only moves of type “out_refund” and “in_refund” were considered refunds.
Now reverse entries with sale/purchase taxes get their tags set accordingly to repartition lines.
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 0 1000 21% +03
451000 T.V.A. à payer 0 210 +54
400000 Clients 1210 0
Was reversed to:
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 1000 0 21% +03
451000 T.V.A. à payer 210 0 +54
400000 Clients 0 1210
Is now reversed to:
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 1000 0 21% +49
451000 T.V.A. à payer 210 0 +64
400000 Clients 0 1210
closesodoo/odoo#80427
X-original-commit: a337d5d5b3886eabbdc8de95eb615dffc91d5d8e
Related: odoo/enterprise#22532
Signed-off-by: Olivier Colson <oco@odoo.com>
- Create a partner with 2 bank accounts: BNK1 and BNK2
Wrong flow with vendor bill:
- Create an vendor bill => BNK1 is set by default
- Change BNK1 to BNK2
- Register a payment
=> BNK1 is proposed by default instead of BNK2
Wrong flow with customer invoice:
- Set BNK3 on your company
- Create a customer invoice
- Register a payment
=> BNK1 is suggested instead of BNK3
closesodoo/odoo#80175
Issue: 2683197
X-original-commit: ec0d807b2b6ff3596d9b591bd8ec7d8889d41d8a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@openerp.com>
Steps to reproduce:
- Create a journal with a custom currency
- Create a statement line
- Create a reconciliation model button putting the residual to a random account
- Reconcile the statement line using the button
=> The amount lands inside the debit/credit instead of amount_currency
Introduced by:
https://github.com/odoo/odoo/commit/5ad660877f485d741a0120e07eb73178f59d2dfc#closesodoo/odoo#80173
X-original-commit: fc9b8dc6611d761f2c8778254dcbad52091404dc
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@openerp.com>
Steps to reproduce:
- On a company with multi currency
- Set the company currency rate to 1, and the foreign currency
to 0.273748
- Create a vendor bill
- Set first the foreign currency, then select a product with a
tax to 21% and a price unit of 155.32
- Go to 'Journal Items', the 'tax paid' line debit is computed to 119.15
- Reselect the foreign currency on form.
- Now the 'tax paid' line debit is computed to 119.16
The total is also impacted as the tax changed.
Explanation:
Before this commit, the taxes was both computed in foreign currency and company currency. However, when setting a new currency or changing the date, the taxes wasn't recomputed but the new conversion rate was applied.
This commit is fixing the issue by applying the same logic as in 14.0: the taxes are always computed only the foreign currency, then the conversion rate is applied to get the accounting balance.
opw-2569668
closesodoo/odoo#79618
X-original-commit: 11f5fcfb577b117b279f5d96095e9c0798d78bbd
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Reproduce :
1. Add a default analytical rule: if Coin Gourmand partner then Administrative analytical account
2. Create a PO at the Coin Gourmand supplier, add a product, and select the Internal analytical account.
3. Bill for this product.
Result :
Internal analytical account has disappeared from the invoice line. It has been replaced by Administrative.
Issue :
AccountMove.create() computes an account in the move and this causes the analytic account to be reset at its default value from the rule.
Fix :
Since the account pocalypse in 13.0, account.move is making magic things during the creation of the invoice to create dynamically the invoice lines like account.invoice did before this huge refactoring.
The create is making a 'New' record to simulate the onchange but this code is a hack triggering unexpected recomputation like the analytic account.
To avoid that, we ensure to assign the minimum number of fields to preserve fields like the analytic account.
closesodoo/odoo#79321
X-original-commit: 876e2d1073312fe65cb6b2e3038235aeaa082c8a
Related: odoo/enterprise#22074
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce:
- On bank journal set the outstanding payments accounts and the
outstanding receipts accounts, respectively to 101403 and
101402
- In Accounting > Configuration > Settings > Default Accounts,
let the two outstanding accounts empty.
- Customer > payment > create a payment : payment type "Receive",
amount 5 for example. Save it.
- Edit the payment and change the payment type to "Send".
- Click on Save.
Issue
Got an UserError "Cannot create unbalanced journal entry"
Since the payment_type has changed, the computed outstanding_account_id on the payment is recomputed.
When splitting journal items using the _seek_for_lines() method, odoo is not able to retrieve the liquidity lines since outstanding_account_id has changed.
opw-2620046
closesodoo/odoo#78866
X-original-commit: 865c5d7741ca1bf003b4181d06484cc4ecaf8fcb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
- Create a statement line for partner A, amounting to 90€
- Make 5 invoices for partner A, of 10, 50, 100, 500 and 100 €
- create a reconciliation model (make sure it's the only one active for testing), with
>>> "invoice matching" selected
>>> "payment tolerance" disabled
>>> "partner should be set" enabled
>>> "same currency" enabled
>>> "auto-validate" disabled
Try to reconcile your statement. The reconciliation model associates your statement line to the 5 invoices, showing a partial match of 30 for the line of 100€, as only 30€ remain after matching 10 and 50. The following lines (500 and 100) are useless in the reconciliation and confusing for the user. They shouldn't be there.
After this commit, no useless line will be proposed anymore. In our example, only lines 10, 50 and 100 will be proposed.
Task 2652915
Part-of: odoo/odoo#77801
Armageddon tax being created should include mandatory country_id,
which should be the fiscal country of the test company.
closesodoo/odoo#77295
Related: odoo/enterprise#21208
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before, the taxes assigned by the reconciliation models in their write-offs weren't mapped by fiscal positions. This could cause confusion, and essentially required the user to always fix by hand the cases that weren't matched.
Task 2645280
closesodoo/odoo#77204
X-original-commit: e75184459a7d47df86aa72efa36c06462d7ee9ea
Related: odoo/enterprise#21187
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In order to prevent holes in the sequence, a constraint is checking that
only the last number of the chain is removed.
This commit extends that to a batch of records by checking that:
* the last number of the sequence is part of the batch
* the batch is sequential (there are no holes in it)
closesodoo/odoo#76870
X-original-commit: 7883900e3b615c632dab2b02c792f6d8c1045a15
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue: When changing the bill date (invoice_date) of a vendor bill,
the due date (invoice_payment_term_id) is not updated correctly
Steps to reproduce :
1) Install Accounting, Purchase
2) Create a vendor bill
3) (debug) Edit the view, remove the invisible attr for the div with
label invoice_payment_term_id
4) For the vendor bill, in that order, set the Vendor, then the due date
to 30 days, then bill date, then add a product
5) Due date is now set to 30 days after the bill date
6) Change the Bill Date
-> Due Date stays unchanged
Thanks to @smetl for writing the test !
opw-2627686
closesodoo/odoo#76736
X-original-commit: d15e0a678b021d842b96bce9c8880ed28f7fff77
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
To reproduce:
1) Create a foreign VAT fiscal position fpos (so: assign it a different country than your fiscal country, and set a value to its foreign_vat field)
2) Create a cash basis tax in the same country as fpos
3) Make an invoice using this tax and fpos
4) Try registering a payment to your invoice. => Traceback
closesodoo/odoo#75990
X-original-commit: cefcdfb7b88d899779de65b4ac1376445cb67c73
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Go to Accounting
- Create an invoice:
- select a `invoice_payment_term_id`
- Add product on “account.move.live”
- Save and duplicate it.
Problem:
The `invoice_payment_term_id` field will be duplicated on the second invoice, but not the `invoice_date_due` field
Solution:
The `invoice_date_due` field is set in the `_recompute_payment_terms_lines()` function when adding an `account.move.line`.
As in the duplicate invoice we also have an `account.move.line` we can therefore call this function so that the field is set
https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L1043
opw- 2628333
closesodoo/odoo#76045
X-original-commit: aa2e4b9a90d4b67a8b65542ece37ced9b1460557
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
On payment creation, when changing twice the payment's journal, if the
first journal already has some lines and the second one doesn't have any
lines, the payment name will be incorrect.
To reproduce the error:
1. (If present, delete all payments)
2. Create and save a payment P01:
- Journal: Bank
3. Create a second payment P02 (do not save it):
- Journal: Bank
4. Change P02's payment: Cash
5. Change P02's payment: Bank
6. Save P02
Error: The name of P02 is "CSH1/2021/08/0001", which would be correct if
it was a Cash payment. This error has a consequence: suppose the user
creates a third payment (journal: Bank) and confirms it, its name will
be "CSH1/2021/08/0002" (again, name linked to the incorrect journal)
On step 4, when changing the journal to Cash, since the latter hasn't
any payment, the server returns a new name ("CSH1/2021/08/0001"). Then,
on step 5, when changing back the journal to "Bank", since the latter
already has a payment (P01) and since the current record already has a
name ("CSH1/2021/08/0001"), the server doesn't change it and the
`onchange` response doesn't contain anything. As a result, when saving
the payment from the client side, the wrong name is included in the data
("CSH1/2021/08/0001"). Regarding the consequence: later, when creating
and confirming a third payment, the server will take the name of the
previous one in the same journal and will increment it
("CSH1/2021/08/0002").
OPW-2601668
closesodoo/odoo#75986
X-original-commit: 2024ff2b344d841cf775dbb14da9cc9e1e4c05e9
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The tax_exigible field of account.move.line made it impossible to mix 'on_payment' and 'on_invoice' taxes on the same invoice line, as the base line couldn't be be tax exigible and non-tax exigible at the same time. However, this use case is needed by some countries in order to implement withholding taxes.
To solve that, we totally remove the tax_exigible field from account.move.line and instead compute it on the fly with a domain (also passed to the query_get for SQL queries). An 'always_tax_exigible' stored computed field is also added on account.move, in order to still allow (like before) putting cash basis taxes on a miscellaneous operation without any payable/receivable line and still see it become exigible without needing any payment.
[IMP] account: improve cash basis traceability
A smart button is now available on invoices generating cash basis entries, so see them all at once. The move originally creating cash basis entries is also shown as a field on them.
Task: 2457374
Part-of: odoo/odoo#74138
This task aims to both explain supported reconciliation cases and improve the reconciliation model form view.
The form improvement is mainly about label wording and make the options more self speaking.
Also, disable bypass of the matching amount we do in case the statement line's label exactly matches the payment reference.
It can be replaced by just making a final model that is applied whatever the amount and will do the partial reconciliation on everything that wasn't matched by others.
That's cleaner, as users can way more predict what models can do and debug their config.
closesodoo/odoo#73043
Task: 2427089
Related: odoo/upgrade#2729
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
[FIX] account: tax details: correct taxes computation when using taxes affecting base with repetition
1) Let's consider then following taxes
- tax 1, 42%, affecting the base
- tax 2, 10%
2) Create an invoice with the following lines, and post it:
- price=100, taxes=tax1
- price=100, taxes=tax2
- price=100, taxes=tax1+tax2
=> The tax details should compute the following amounts:
- base amount of tax 1: 200
- tax amount for tax 1: 84
- base amount of tax 2: 242
- tax amount for tax 2: 24.2
Before this fix, the base amount for tax 1 wasn't computed properly, and gave 300 instead of 200. This was because the same tax line (the one from tax1 with no tax_ids) was matching two different base lines: the one with tax1 and tax2, and the one with only tax1.
closesodoo/odoo#75317
Related: odoo/enterprise#20356
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This reverts the following commits:
- 164409b00106a5f91d8b84ac698f4cf2aebedb91
- f11c807217cccd96fa18fe24c0cbb436bb1830d1
- c92ebc91e261827dfafa602eae5408de2a072609
The fix we initially made did not cover every possible scenario,
and applied to every fiscal position, which was not required.
It requires a more in depth rework that is under way
and will come in a future PR.
closesodoo/odoo#75284
X-original-commit: d470f2b4fbc7440d19d07268980394909c47ee22
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In some reports, we need to detail the taxes for each journal items.
This is the case of all EDIs, the SAFT-report, l10n_in etc.
This task adds an SQL view mapping each tax lines with their corresponding base lines and computing the tax_amount and base_amount.
closesodoo/odoo#70866
Task: 2352524
Related: odoo/enterprise#18344
Related: odoo/upgrade#2686
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This tests should be part of the basic l10n test to ensure that the UI
is valid and can be opened.
closesodoo/odoo#74605
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
A tax line affecting the base of subsequent taxes is a line having some values in 'tax_ids' & 'tag_ids'.
When creating a refund, tags was wrongly computed in this case.
closesodoo/odoo#74307
Issue: 2596368
X-original-commit: 49d1dbbb74ea97e4337fe1af3b8074dc9146143c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Explain the situation when a manual change has been done to the sequence
of `account.move`. This was needed because some user didn't realize that
they changed the sequence, and when they realized it, it had polluted
multiple numbers after that.
closesodoo/odoo#74326
X-original-commit: 56f7afb253da6560cddae121f5b6cdab3e3b1c6e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Nicolas (vin)