Previous patch by Alexis created a co-dependency between
account_payment_order and account_banking_sepa_direct_debit, which is
not correct.
This patch avoids such problem and fix properly the test, although
the utility of some of them is debatible.
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
The test introduced in 7bdb286aa1 is not
valid, as its indentation made it to not be executed. Anyways, the
content and the tested things are also not correct.
This commit split the tests for outbound payment in a base inheritable class that
can be reused in other dependant modules, and the test of this module.
similar to 86bd1a2525
Add partner_bank_id column to avoid MemoryError on an existing Odoo
instance with lots of data.
partner_bank_id on account.move.line requires payment_order_ok to be True
which it won't be as it's newly introduced - again nothing to compute.
(see AccountMoveLine._compute_partner_bank_id() in models/account_move_line.py)
Add columns to avoid Memory error on an existing Odoo instance
with lots of data.
The payment_mode_id fields are introduced by this module and computed only
from each other or the also newly introduced supplier_payment_mode_id and
customer_payment_mode_id on res.partner, so they can stay NULL, nothing
to compute.
Complement of 998f8df6aa254266c015fab144ba290e1a386cf0
Extend the editability to the journal entry (account.move), taking
as criteria if there's no reconciliation made, which is the definitory
one.
It includes test for this new feature, both the mode propagation and
the editability check.
TT39850
This field was editable in previous version before invoice > move
refactoring, and it's logic to allow to change payment mode once the
invoice has been posted without the need of resetting it to draft.
Thus, the field has been changed to computed writable field, taking care
of the consequences at model level (compute) and view level (add the
field in views + proper attrs).
This commits adds tracking=True to the payment mode field as well to be
aware when and who the payment mode is changed in the invoice, no matter
if directly changed in draft, or through the change on the journal item.
TT39850
