@Stefan: About why I chose the level of payment.mode.type vs payment.mode : I first thought I would point to payment.mode, but, as I explained that in my email "Re: [Banking-addons-drivers] account_payment_extension" on 21/02/2014 12:40 Paris time, I found out that account_payment_extension points to payment.mode.type and I think I found the reason ; here is the explaination of my email :
<< if you consider that your company has 2 bank accounts A and B : they sometimes pay their suppliers from account A, sometimes from account B, depending on the situation of each bank account. As they have 2 bank accounts, they have 2 payment modes for wire transfer... but they could share the same account type "wire transfer". In this case, we would prefer to have the many2one fields point to account.type, so that it is independant from the bank account that will be used for the payment. Note : if the 2 banks use 2 different versions of SEPA PAIN, then we'll have 2 different payment types... bad luck ! But maybe we could change that in the future and have 1 payment type for "pain.001.001.xx" and store the xx on the payment.mode. >> About your other remarks : - I must say that I dislike the auto_install mechanism :) I don't think it would be a good idea to have it on account_payment_purchase and account_payment_sale, because you may want to have sale and account_payment_partner, but not to manage the payment type on sale.order, but only on partners and customer invoices. Same for purchase ; you may not want to manage the payment type on purchase.order, but only on partners and supplier invoices. So I have just added the auto-install option on account_payment_sale_stock, where I admit it can be a good idea :) - About filtering : I agree with you. We could imagine that, by default, you also get the invoices with no payment type set. - I always forget the do_merge stuff on POs ; I surely need to add that. - about the name of the modules : if we keep pointing to payment.mode.type, it may lead to confusion to put "payment_mode" in the name. - I think that the partner_bank_receivable is fully related to the other changes. On a customer invoice, the field partner_bank_id is a M2O to res.partner.bank and it designate the bank account of "your company" on which you would like to receive the money. We need to have the same field on sale.order and res.partner, and have the usual behavior : customer res.partner (partner_bank_receivable) -> sale.order (partner_bank_receivable) -> customer account.invoice (partner_bank_id) - I like your suggestion to show inactive payment types in tree view by default. I didn't knew it was possible with active_test : False. I just made the modification. -- https://code.launchpad.net/~akretion-team/banking-addons/70-fully-handle-payment-types/+merge/211283 Your team Banking Addons Core Editors is subscribed to branch lp:banking-addons. -- Mailing list: https://launchpad.net/~banking-addons-team Post to : [email protected] Unsubscribe : https://launchpad.net/~banking-addons-team More help : https://help.launchpad.net/ListHelp
