Remove inherit of sale.advance.payment.inv: no need to inherit
_prepare_invoice_values() because it calls _prepare_invoice() from the
sale.order object
Steps to reproduce the problem:
- Set a payment mode with fixed journal and set the journal with bank account A.
- Create a sales order and put bank account B.
- Create invoice.
- Bank account in invoice is A instead of B.
Into the normal process of the invoice creation from a sale order by odoo, the onchange_partner is called. In some case, this call will reset the specific payment_mode and/or partner_bank_id set on the sale_order.
To fix this issue, we must override the _finalize_invoices method, take a snapshot of these values before the call to super and restore these values if these are changed.
fixes#536
* Migration and enhancement of all modules involved in SEPA
* Remove duplicated files
* Check if payment mode is set in the propagation
* Clean files
* account_payment_sale_stock: Split for removing stock dependency on sale
* Remove old translations templates
* Reorder on folder structure
* Translation template files
* Translations to spanish
* Use sale_ok and purchase_ok instead of tweaking payment type
* Add sale_ok and purchase_ok filters in partner/sale/purchase form views
* Use widget=selection for payment_mode_id fields
* Update demo data
- account_payment_partner
- account_payment_sale
- account_payment_sale_stock
- account_payment_purchase
Filter the selection of invoices per payment type.
Add active field on payment.mode and payment.mode.type.
Add menu entry for Payment Types.
The computation of partner_bank_id has not been migrated properly
since the move from account.invoice to account.move.
Before, we had an onchange on partner_id that did the following:
- If no partner or no company, remove payment mode
- If type = in_invoice, remove partner_bank_id as well
- If partner and company,
- If type = in_invoice, set payment mode from partner
- if payment mode's payment method has bank account required,
set the partner_bank_id to the commercial partner's bank
- else set partner_bank_id to False
- If type = out_invoice, set payment mode from partner and
do not assign partner_bank_id
We also had an onchange on payment_mode_id that did the following:
- If payment mode and its payment_type=outbound and its payment method
has bank account required, set partner_bank_id to False
- If no payment mode, set partner_bank_id to False
Now that partner_bank_id is a computed field, we shouldn't set its value
to False if the move is not a vendor bill or doesn't have a payment mode.
The computation of partner_bank_id must instead reflect the conditions we
used to have, that is:
- If we don't have a payment_mode, set value to False
- If we have a payment mode
- If type=in_invoice and payment mode's payment method has not bank
account required, set partner_bank_id to False (as setting the bank account
from the partner is done in the call to super)
- If type=out_invoice
- if payment mode's payment method has bank account required
- set partner_bank_id to the bank account linked to the fixed journal
of payment mode if defined
- do not set anything if that isn't the case since setting the bank account
from the company is done in the call to super)
- if payment mode's payment method does not have bank account required,
set partner_bank_id to False
Closes: #1091
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
