- 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>
Improve usability of payments. Allow selecting multiple Vendor Bills AND Refunds
and pay them all together in one single payment.
E.g. When running server action “Register Payment” for :
- one 100€ Vendor Bill
- one 50€ Vendor Bill
- one 80€ Refund
Previous result = one 150€ outgoing payment + one 80€ incoming payment
New result = one 70€ outgoing payment
closesodoo/odoo#69578
Task: 2475598
Related: odoo/enterprise#19902
Signed-off-by: William André (wan) <wan@odoo.com>
In the first days of the month, many of the previous month's invoices
could still to be posted since the lock date is not yet set to the last
day of the previous month. To avoid the user having to modify the
default accounting date on each such bill, detect whether the conditions
allow the invoice to be posted on the very last day of the oldest
possible month, and then adapt the accounting date to the last day of
that month.
task-2575560
closesodoo/odoo#73701
X-original-commit: 2c5c1a4478505688f35e47ca20e7977b134d0fdb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
For data quality purposes and bug prevention, when I reverse an entry,
the reversal should always be postable on a journal having the same type
as the initial Journal Entry's journal.
closesodoo/odoo#72431
Task: 2497529
Related: odoo/enterprise#19543
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
PURPOSE
Align default sequence numbering on customer's expectation per journal.
Because of some feedbacks received, we acknowledge that most users will
want an annual sequence on sales documents and a monthly sequence for
the rest.
SPECIFICATION
By default, on customer invoices/credit notes (the default sequence
should be annual.)
We don't want an option and therefore, we make a decision ; user can
change it by resequencing if he doesn't like it.
task-2591145
closesodoo/odoo#73278
Related: odoo/enterprise#19565
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
To reproduce:
- Create a cash basis tax
- Make an invoice with two lines, a positive and a negative one (the positive having a higher value), both using this tax
- Post the invoice and register a payment for it
===> It crashes when registering the payment. The SQL constraint ensuring debit/credit consistency fails when creating the cash basis entry.
This is because we were not grouping debit and credit values together on the lines sharing the same taxes; we were summing them separately. The cash basis entry then received line values with both credit and debit set, which is forbidden by the SQL constraint. We now compute the balance first, and set either debit or credit depending on its sign.
closesodoo/odoo#72383
X-original-commit: 896496d84413e7bb5e5df582e2b67eae2583671b
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit fixes the case when the reconciliation never ends due to an infinite loop.
This happens when we attempt to reconcile two journal items having differents foreign currencies but an amount_residual = 0.0.
In that case, partials are created everytime with zero amount, zero debit_amount_currency and zero credit_amount_currency.
We don't need to handle such reconciliation because exchange difference journal items are always created using the same foreign currency as the originator line.
The way the reconciliation is made for reversal moves is also edited by this commit to avoid reconciling lines on the same moves but with different currencies.
closesodoo/odoo#72266
X-original-commit: 1231d54b8c2084db6ffb9551af7ed4ee9e31a95a
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Consider the following example:
1) Create tax ONE, 10%, include_base_amount=True
2) Create tax TWO, 20%, is_base_affected=False
Create an invoice with just one line of 100€, with taxes ONE and TWO (in this order).
The journal entry then contains:
- The payable/receivable line => 130
- The base line => 100
- The tax line for ONE => 10
- The tax line for TWO => 20
The bug this commit fixes concerns the tax_ids set on tax lines. In our example, none should be set, since tax TWO is not affected by ONE. But tax line for ONE actually had tax_ids=TWO, hence impacting TWO's base. This was wrong; the base for TWO is 100, not 110.
closesodoo/odoo#72063
X-original-commit: ff2d1728c835e7d43638502d69245291d0fa3c59
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The accounting date must be today by default and changing the bill date
must not affect that.
Kind of followup after this change of behavior fcaa54939e9a4f0dd5e47cd0ccffe7aa24bd451c
task-2550985
closesodoo/odoo#71977
X-original-commit: c63af09774414a004ef34644b4f38b4fdb1d12bd
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Open Accounting>Reporting>Invoices
Add measure 'Average Price'
The reported amount will be wrong, as it will not consider the quantity,
making an average of the price subtotal
opw-2522621
closesodoo/odoo#71862
X-original-commit: 978012b38abb941c88fe85f1befa2ac659545915
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
- Enable cash basis (Accounting>Settings>Taxes)
- Enable analytic accounting (Accounting>Settings>Analytics)
- Have a sale tax:
- Based on payment (Account 10100 Current Assets)
- Included in Analytic Cost
- Create a [DEMO] product with such tax
- Create an invoice with 2 lines:
- One line with product DEMO and whatever analytic account
- One line with product DEMO but no analytic account
-Confirm and receive payment
CABA entry will consider only 1 tax line, because the
2 entries are equal beside the analytic account which is not considered
in the grouping keys
opw-2507417
closesodoo/odoo#71556
X-original-commit: 2a8f777c04bdbdce77dc44d92e099612f158cbef
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Original issue:
Create a payment like follow:
Payment type: receive money
Partner type: customer
Destination account: whatever receivable
Amount: define an amount (i.e. 90.00)
On Save, open the draft jounral entry created.
Lower the liquidity or counterpart amount and add a writeoff
Go back to the payment, change the amount and save.
The journal entry writeoff will swap from debit to credit at every
change made to the amount. This occur also when changing currency on the
payment
opw-2475223
Otherwise, this fix is not covering all cases:
inbound with write-off in debit
inbound with write-off in credit
outbound with write-off in debit
outbound with write-off in credit
closesodoo/odoo#70903
X-original-commit: 01b9bff35e85fafb1a50bb0819123d186acf4925
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Since the payment refactoring, the structured reference of a payment is stored in its ref field, not payment_reference like for invoices. This caused payments never to be matched with highest priorities, as payment_reference_flag was always false, and only communication_flag could match.
To reproduce:
- Have a reconcile model with match_total_amount=False.
- Create a statement line with communication a1b2c3 for 1000
- Create 3 payments:
> 500, with memo a1b2c3
> 500, with memo a1b2c3 (so, the same one)
> 500, with memo d1e2f3
- Open the reconciliation widget for your statement line
===> The 3 payments are matched, while only the two first ones should have been, as they were exact matches for the communication, and should hence have received higher priority.
closesodoo/odoo#70394
X-original-commit: b5800c9d2088df2bb9c4fbe0fed91c7ef24299c5
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Create an invoice with an empty fiscal position
- Create a line with a product having 100.0 as sale price and 21.0% price-included tax
=> price_unit equals 99.99
This is because 100 / 1.21 ~= 82.64 but 82.64 * 1.21 ~= 99.99 != 100.0.
The bug only appears when managing a fiscal position because the code is trying to adapt the product price_unit to the newly computed taxes.
closesodoo/odoo#70276
X-original-commit: 3470a3c94e06d92afcd8a8129f80e4dfea14efe4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When the same sequence is used in different journals (i.e. BNK1 in two
different companies), a clash might happen in the grouping optimization
of the `_compute_name`
closesodoo/odoo#70152
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, such configuration wasn't allowed.
However, in some countries, this is mandatory, when dealing with eco-tax for example:
Suppose t1, t2 being taxes where:
- t1 is include_base_amount, price_excluded, fixed tax of 10 (eco-tax)
- t2 is include_base_amount, price_included, percent of 21%
The computation on 1210 should be:
price_excluded: 1210 / 1.21 = 1000
price_included: (1000 + 10) * 1.21 = 1222.1
closesodoo/odoo#69449
X-original-commit: 2bb9e68b546db191b2a88b787a865548d8107bcd
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When an auto-validating reconciliation model is defined for matching
bank statement lines to invoices, it was possible to get a traceback
when the bank statement lines were in a certain order and matched in a
certain way.
In particular, if the first bank statement line is priority 3
(communication_flag True) and the amount is an exact match with the
invoice, it will be instantly reconciled. If there's a second line
that's a priority 5 match, it crashed because _filter_candidates didn't
take into account that candidates_by_priority could be empty if the
candidates were already reconciled.
Instead we just return an empty list of candidates and priorities when
this happens.
closesodoo/odoo#69331
Ticket: 2507189
X-original-commit: e9538d9cee092e034b85187a2eae857349f42ce7
Signed-off-by: William André (wan) <wan@odoo.com>
Beforehand, users could configure an account as non reconcilable
even when it was configured as a payment credit or debit account
in a journal. This prevented journal items to be reconciled
Now, when a user tries to set an account as non reconcilable,
we check if there is no journal with a payment credit or debit account
set to this particular account. If there is at least one journal,
then we display an error message stating the journals names and ids
that the user would have to modify before changing the account
configuration.
closesodoo/odoo#69317
X-original-commit: 87c207f3a408abb93d9b8378ef4aa1744935d86d
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
Beforehand, if two users independently opened a draft
invoice on their respective sessions, then both of them
clicked on the "Post" button, then the invoice was
posted twice.
On a more general aspect, the view currently "prevents" users
from posting moves several times, but technically speaking,
nothing stops users from posting moves several times.
Now, after checking that the user indeed has the right to post
a move, the next check is about verifying that the move is
not already posted.
opw-2479201
closesodoo/odoo#69178
X-original-commit: b7db7db283d7b9d167201b791e6282b022d59c40
Related: odoo/enterprise#17658
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
oco-odoo