Hi Pieter, Thank you for your comments. I hope you will accept the clarifications below. On 05-05-11 17:11, Pieter J. Kersten (EduSense BV) wrote: > 1. The domains in the forms are too restrictive in its current form. The 'suitable_bank_types' method in account_payment can return more than just 'bank'. After installing base_iban, it can also return 'iban', which is a valid bank account type for ABF too. There can be more. So instead of using a hard coded domain, I suggest extending the form with suitable bank types (hidden? context?) and setting the domain to this list ('type','in',types_list) My notion here is that you may be mislead by the domains for journals which I have modified. OpenERP 6 separated cash and bank journals by introducing a new type 'bank' in addition to 'cash'. I have modified the code accordingly. As for suitable bank types, I took a shortcut and had done away with them at all as I was trying to find out the current status of the payment_order module. It seemed to be blocking all payment orders because its method suitable_bank_types() returned no bank types at all under any condition. I modified it to always return all bank types, which seemed to solve the problem that no bank account was ever selected for the payment order lines. Having another look now, the real cause appears to be the pretty awful implementation of line2bank() in the original payment_order module which initializes all keys in the dictionary to False and then only provides a meaningful value if a key is not in the dictionary. That insight gives me with the key to implement the notion of suitable bank types in this branch after all. I will have a go at that in the next couple of weeks. > 2. I can see how changing state on payment orders during testing of ClieOp can mess things up, but not being able to save it at all is a bit too restrictive for me. Preventing switching states when saving test batches should do just fine. That was exactly my intent, and if I am not mistaken the code does just that. Files are available for download in the wizard and afterwards in the list of generated clieop files. > 3. Instead of using a catch all bank, I prefer to have an optional relationship between res_partner_bank and res_bank. This way you can relax requirements. The current layout of res_bank is too biased for Belgian and German usage anyway - a bank code is required, which is not even known in some countries, including the Netherlands. You could add a constraint to require a valid bank when code is filled in order to prevent regression for bankcode-users. As the res.bank on res.partner.bank is required in the base module, it is reasonable for developers to expect this field to be defined on the object. Such code already lives in the module l10n_ch. I would hate to introduce instability by creating resources of type res.partner.bank without a res.bank. Note that, in a previous mail, we ourselves agreed to apply defensive object browsing only to complement requiredness of fields. As such, I would rather not follow your suggestion. Kind regards, Stefan. -- Therp - Maatwerk in open ontwikkeling Stefan Rijnhart - Ontwerp en implementatie mail: