On 10/07/11 16:37 +0200, Albert Cervera i Areny wrote: > A Diumenge, 10 de juliol de 2011 13:52:34, Cédric Krier va escriure: > > Any way for me, it will be a bad design message to put party in the compute > > method of payment term because it is the payment term that is linked to > > party and not the other way. > > Wouldn't this apply to product price lists too? product.price_list's compute > function also receives the party as a parameter. By the way, in this case the > the parameter is not used in product_price_list module itself, so it looks > very similar to what we're discussing here. (Might be missing something, > though..)
Ho yes, you are right we should remove the party of the list price method compute because we must be able to compute a price without a party. > > > So if you want to have this, you should go with context. It is doable right > > now but I must say we could have a better design for it like we have for > > price list or tax rule. > > So a patch that will add a method to return the context for calling payment > > term compute method on invoice, will be welcome. > > Ok. So if I understand it correctly I should add a "def > _get_context_payment_term(self, party)" to account.invoice and then use it in > account.invoice's create_move function? Except that it should not receive the party but the invoice. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpChEHvYpTWS.pgp
Description: PGP signature
