This adapts the old bank.payment.line records to account.payment records
according the new approach, taking into account if you come from v14
with the refactoring applied.
The previous approach creates manually the journal entries and does all
the hard work, plus not being 100% compatible with the bank statement
reconciliation widget (requiring a patch on OCB to see blue lines).
That decision made sense on the moment it was done (v9), where the
native payment model (account.payment) was very limited, and wasn't able
to store all the needed information for the bank transaction.
Now that the limitations are gone, we can get rid off this extra model,
and generate instead `account.payment` records, using both the native
model + methods to perform the same operations.
This serves also to workaround the problem found in #966.
All the code, views and tests of main module have been adapted to this
new approach in this commit. Later commits will adapt the rest of the
modules of the suite, and add migration scripts to transit from the
previous approach to this new one.
TT39832
- Add a hook method to retrieve communication type and communication
- Improve normal communication if there is a credit note
If there is a credit note that partially cancel an invoice, the payment communication
should be the combination of the invoice reference and the credit note one.
- Remove not needed assert as parameter is required
- Use the 'payment_reference' field if filled in
- Add existing payment references to communication
If some movements have been reconciled with the original invoice,
their references should be added in communication too.
e.g.: Manual credit notes
- Don't duplicate communication reference
create_account_payment_line() is supposed to returned a form view for a
single payment order and a tree view for multiple payment orders. Before
this fix, it would return a tree view if you were payment more than 1
invoices while generating a single payment order, because the list
result_payorder_ids would contain several time the same ID.
Don't set reference_type field on account.move required=True, because it
causes a lot of problems in other modules that don't depend on this one.
Setting it as required in the view is enough.
Update move line generation to get transfer account from bank journal
Update payment mode configuration accordingly (3 fields removed)
Several improvements in payment order tree and form view
Case:
The bank account isn't set properly in the payment order lines, because the bank account is only got from account.move.line or the first bank account in the partner_id, but never from the invoice (account.move).
Solution:
With this fix, the bank account will be get from account.move when matching the criteria.
Steps to reproduce
------------------
* Create a payment mode with "Link to Bank Account" = "Variable".
* Select several journals.
* Create a payment order with that payment mode.
* Save.
* Go to other menu and come back to payment order.
* Try to select a journal: the list is empty.
Fixes#544
* Removed deprecated YAML tests.
* Removed document dependency, as now there's no attachment dropdown.
* Switched deprecated `compute` method of res.currency.
* Restored missing field `reference_type` in invoices.
* Fixed call to `message_post`.
* Added missing description in model.
Adds 'structured' to the invoice_reference_type2communication_type ans the 'structured' type is added by the module itself in account_invoice but breaks the account_move_line.py as explained here: https://github.com/OCA/bank-payment/issues/495
- when manually encoding a payment line, get company currency as default currency
- Search on payment order numbers
- Direct search on bank journal name in payment orders
- remove widget="selection" on account.payement.mode : this object is rarely modified, so widget='selection' is not a time saver, but we miss the HTML link, which can be pretty convenient to check the configuration.
When adding to a payment order from invoices, the payment mode
considered is the one in the invoice, but once you have confirmed it,
you can't change it, so if you change the payment mode in the journal
items, it doesn't make the difference.
With this change, this is taken into account for adding to the
payment order(s) properly.
context of payment orders, she should ocus on the amount that
is due to be paid. In this method we are forcing to display both
the amount due in company and in the invoice currency.
We then hide the fields debit and credit, because they add no value.
