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
When invoicing from dropshipping, the same picking serves for both
invoicing sale and purchase orders. The OCA module
stock_dropshipping_dual_invoice makes that this happens, but
as the picking is the same, it contains both the sale and the
purchase reference, making that the resulting invoices don't have
the correct payment mode. This is harmless for the rest of
operations, as the dictionary query is provided with the proper
default value. On v9, dropshipping dual invoice has been merged
into core, so this patch for sure will be welcome in that version
(if the used method is the same).
