When a payment reference (field `payment_reference`) is provided on the vendor bill, it should be used in priority over the vendor bill number (field `ref`).
One reason is that the `ref` field is different for each invoice of the same supplier (it is used in Odoo's standard duplicate warning),
but the payment reference maybe the same for all payments to the
same supplier. For instance some suppliers request that the customer
id is used on the payment communication and it is the same on
all their invoices.
Another reason is that some supplier use a structured payment communication scheme, and that one only makes sense in
the payment_reference field.
The payment line reference type takes its value from the invoice reference
type, and both fields must have the same options.
The missing option "structured" causes a bug during payment creation.
the test is modified to be able to reproduce the problem.
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
Example use case:
- Create a Supplier and set a bank account.
- Creating a purchase order with a Supplier Bank Account
- The payment method of the payment method must have the Bank Account Required box unchecked.
- Confirm the purchase order and create the invoice with the "Create Bill" button.
- The invoice must have the bank account empty.
TT46502
Steps to reproduce the problem:
- Have a partner without payment mode.
- Create a PO with such partner.
- No payment mode is filled.
- Now fill the payment mode in the partner.
- Create the invoice for the PO.
Current behavior:
The invoice has empty payment mode.
Expected behavior:
The invoice has the partner payment mode. Someone may think that having
no payment mode in the PO may prevail over the partner's payment mode,
or even their flows may consist in empyting the payment mode in the PO
for not binding it with anything yet, but that strategy has more holes
than the one implemented here, as the flow presented proves.
You can then use another one like having an extra payment mode
"Undetermined" or similar for doing such classification as a more
resilient strategy.
It includes a regression test that fails before the change and now is
correct.
TT38608
