On certain v16 instances, although the partner bank account that is
being pre-set in the account.payment creation values dictionary:
https://github.com/OCA/bank-payment/blob/fc7783669f40d85/account_payment_order/models/account_payment_line.py#L206
it's being marked as dirty (it's a computed writable field), and thus,
being recomputed before being saved, getting an invalid value (on
direct debits, the company's bank account).
The triggers that lead to this situation are unknown due to the low
level where it's happening and the tons of interactions being taken in
place, so the best way to deal with this is to override the compute
method that computes this value, so even if the field is recomputed, it
gets the correct value.
Let's be pragmatic...
TT50804
Compatibility with https://github.com/OCA/bank-payment/pull/1304
The payment (account.payment) and the account entry (account.move) are defined with today's date,
but the "important" date is the date of the line, therefore the payment_line_date field is created.
The modules account_banking_sepa_sepa_direct_debit + account_banking_sepa_credit_transfer
to use the payment_line_date field.
TT49988
In v13 the existing behavior was defined with today's date the Transfer Move, therefore, we define
that behavior by default without configuration since it is the expected behavior.
https://github.com/OCA/bank-payment/pull/805/files
TT49582
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
- allow add to order from invoice if order exists
- payment line creation from move line
Benefits of the batch creation of Odoo 12.0
The method returns the created payment lines
- split generate_move method
- only payment order option on payment methods
New option on payment methods: payment order only (unchecked by default) allowing to enforce the use of payment orders for some payment methods
