Let's consider an aged partner balance with a period of 30 days as of
2019-02-08. The specific dates used in the report are:
``` python
bisou = datetime.strptime('2019-02-08', "%Y-%m-%d").date()
for x in [0, 1, 30, 31, 60, 61, 90, 91, 120, 121]:
print(x, bisou + relativedelta(days=-x))
0 2019-02-08
1 2019-02-07
30 2019-01-09
31 2019-01-08
60 2018-12-10
61 2018-12-09
90 2018-11-10
91 2018-11-09
120 2018-10-11
121 2018-10-10
```
However, the current periods generated are incorrect:
```
{'name': '0-30', 'stop': '2019-02-08', 'start': '2019-01-09'}
{'name': '30-60', 'stop': '2019-01-08', 'start': '2018-12-09'}
{'name': '60-90', 'stop': '2018-12-08', 'start': '2018-11-08'}
{'name': '90-120', 'stop': '2018-11-07', 'start': '2018-10-08'}
{'name': '+120', 'stop': '2018-10-07', 'start': False}
```
There is a clear inconsistency between the name of the period and the
date used. Moreover, the name is misleading: 0-30 includes the -0 date,
while 30-60 doesn't include the -30 date.
After the fix, the name and the periods are consistent. We also change
the first period to 1-30 since including 0 would mean to include amounts
which are not due yet.
```
{'name': '1-30', 'stop': '2019-02-07', 'start': '2019-01-09'}
{'name': '31-60', 'stop': '2019-01-08', 'start': '2018-12-10'}
{'name': '61-90', 'stop': '2018-12-09', 'start': '2018-11-10'}
{'name': '91-120', 'stop': '2018-11-09', 'start': '2018-10-11'}
{'name': '+120', 'stop': '2018-10-10', 'start': False}
```
opw-1886633
closesodoo/odoo#27294
Before this commit, the test aged report crashed on date Year/07/16 (and probably after, too) because:
- we create a partial reconcile today (create_date = Year/07/16) when making the payment to the invoice
- the report date is set as Year/07/15, so, the partial reconciliation, if tested after that date, always appears in another period,
which is not the use case we test, hence the crash of the test
After this commit, we force the create date of the partial reconciliation to *before* the report is called,
thus, no error occurs
closes#25785
Company is in USD
Do an invoice in EUR with a specific rate (and post it)
Do a payment on this invoice with another rate (and post it)
revert the payment's move
Before this commit, the move_lines of the original/reverted move pair were not reconciled
to one another
This could cause problems in some reports (aged reports for example)
After this commit, the lines in the original/revert move pair are reconciled
provided that they *can* be reconciled
Which is either belonging to a reconciliable account, or to an account of type liquidity
OPW 1861273
closes#25592
This is essentially a backport of 7544c22de9
and
4f40c9da7b
Company is in USD
Do an invoice in EUR with a specific rate (and post it)
Do a payment on this invoice with another rate (and post it)
revert the payment's move
Before this commit, the move_lines of the original/reverted move pair were not reconciled
to one another
This could cause problems in some reports (aged reports for example)
After this commit, the lines in the original/revert move pair are reconciled
provided that they *can* be reconciled
Which is either belonging to a reconciliable account, or to an account of type liquidity
OPW 1861273
closes#25600
Backport of 5f105d144d from v11.0
Commit 45c5a07d89 deals with displaying on the aged balance reports
the lines that zero out each other: an invoice and a payment of the same amount for the same partner
However, that commit overlooked that when there is a chain of reconciliation
that puts the report line to zero, it was displayed as well.
This present commit corrects this by making sure there are amls that detail the report lines
OPW 1857860
closes#25421
Commit 45c5a07d89 deals with displaying on the aged balance reports
the lines that zero out each other: an invoice and a payment of the same amount for the same partner
However, that commit overlooked that when there is a chain of reconciliation
that puts the report line to zero, it was displayed as well.
This present commit corrects this by making sure there are amls that detail the report lines
OPW 1858963
closes#25359
Make one Payment
Reverse the entry of this payment.
Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports
After this commit, the four lines are reconciled two by two, even in the liquidity
account
OPW 1816641
closes#25026
Module account_lock has been introduced by:
https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf
A new constrains appears on the lock dates: their must not be set
after the last day of the previous month.
Then, it breaks the test on closed period that set the lock date 'yesterday'.
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
- Create a SO for a customer of 100 $
- Create Invoice for the Sales Order and Register the payment
- Create a Refund Invoice, Validate it and keep it in "Open" state
- Create a second SO for 5 $
- Create an invoice for this order and validate it
- It will show you outstanding payments
- Apply the credit and the invoice will be fulfilled => Now you have a
credit left for 95 $
- Create a third Sales order for the same customer for 5 $
- Create an Invoice for it
- It will show you outstanding credit (95 $)
- Apply the credits
- Now 90 $ are left
- In the same invoice, the credit which you applied, Unreconcile it
- It should have shown you 95 $, but it shows you 100 $ which means it
removed the credit which we applied to second SO
The unreconcile process does not filter the partial reconciliations of
the selected invoice. All partial reconciliations on the AML are
removed instead.
opw-1819602
The previous commit forbids to change the currency of a company having accounting entries, but there are some created by demo data and some tests were trying to set a different currency (to set up a fix environment). So in order to allow that in tests, we do it via a SQL query directly
Due to this commit: 3267e76520
Steps to reproduce the bug:
When registering a payment for a customer invoice in an other currency than
the company currency and marking it as fully paid, it raised an error:
"Wrong credit or debit value in accounting entry !".
Reason: counterpart_aml['debit'] and counterpart_aml['credit'] were both incremented
and it violated the constraint credit*debit=0
opw:815465
Before this commit, when a localization defined default payable or receivable
accounts on partners (like l10n_do does)
The reconciliation tests that involve an invoice on the one hand and a payment on the other hand
broke just because the accounts of the payment and the one of the invoice did not match
After this commit, we force the receivable or payable account to be the partner's (if available)
and the tests do not break
Nicolas Martinelli