The "add" button shown in the outstanding credits menu in the
button right corner of a payment wasn't shown in green like the
other clickable elements.
opw-1907342
closesodoo/odoo#28908
When we print or post_message of an invoice it is set as sent.
But when we multiprint, we do not use each invoice post_message but
create directly mail.mail then send them in batch.
Thus the invoices are not set as "Sent".
With this change we make a special case.
opw-1910937
closes#28852
The "sent" field on an invoice indicates if it has been sent to
customer or not.
When the invoice is sent to a customer from a form view the sent was
set, but when it was sent from the "Send" action on the list view,
it was not updated which seems wrong.
opw-1910937
closes#28796
Install the accounting module, create a new payment for a customer
go to payment matching, reconcile the payment for the account
'Account recievable' and select a tax. There is a traceback
because of a incomplete implementation of the tax computation.
This commit complete the implementation and add the missing tests.
opw-1903172
closesodoo/odoo#28591
Create an invoice for a day, and register a payment right away
BUT choose a date in the future for that payment
Imagine a French Check. You write it, and tell your partner to cash it in
10 days later
You would enter that transaction as a temporary payment
in your own books
OPW 1893646
Before this commit, the line of the partner did not appear in the aged
report after if the report was for the date just after the invoice date
After this commit, it does
closesodoo/odoo#28728
Have a company that do not have a logo.
Try to print a "PDF report" from the accounting module
Before this commit, the simple company form popped up
with the purpose of force setting a company logo
After this commit, we assume it is not necessary to have a company logo on the reports
Note, because of 733ce266ef, we cannot do a save and print
OPW 1904764
closesodoo/odoo#28617
The `context.company_ids` variable seems mostly empty in the case of the
Manual Reconciliation widget. Therefore, we fetch the current company of
the user in the session.
Complement of e5c8071484Fixes#28270
opw-1904475
closesodoo/odoo#28541
When loading the Reconciliation Widget, all reconciliation models are
retrieved. This is not correct: only the one matching the company and
the journal should be retrieved.
Fixes#28270
opw-1904475
closesodoo/odoo#28474
This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.
//Scenario to reproduce the issue (from customer ticket 1903497):
(for a company with USD as base currency)
1. Create a new bank journal for EUR payments
2. Create a new customer invoice for 90€
3. Create a new tax for the reconciliation model, price-included and amounting to 15%
4. Create a new reconciliation model using this tax
5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.
6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.
7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.
What is the current behavior that you observe?
Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.
Steps to reproduce the bug:
- Create a credit note for an amount of 100$
- Validate it and register a payment
- Let's pay an amount of 90$ and mark this credit note as fully paid
Bug:
An error message was raised saying: Wrong credit or debit value in accounting entry !
The field residual_company_signed must be positive for out_invoice and in_refund and
negative for in_invoice and out_refund. In this way, the correct writeoff amount
can be computed in function _create_payment_entry.
PS: In function _compute_payment_amount, the field residual_signed and residual_company_signed
are already signed, that's why it was wrong to multiply a second time on it with MAP_INVOICE_TYPE_PAYMENT_SIGN
opw:1893570
closesodoo/odoo#28148
Christophe Simonis