Hello Olivier,

a few remark about your MP. You already know my position about the semantic shift contact_id, partner_id to partner_id, commercial_entity_id and I already know OpenERP SA wants to keep this shift from now on. So please keep in mind I'm NOT talking about this as we may adapt to the shift once the addons codebase is adapted to it in a credible way (not too far finally even if there are still a few open regressions about this).

So my point in your MP is:

1) I think a crm.claim object also deserves such a commercial_entity_id.
Until 6.1, you could filter claims by commercial entity. I think there is no reason you couldn't not do it anymore in v7. Adding the field in crm.claim you would be on par with what I did in the RS-OCB branch (except I preserved the partner_id semantic).

2) I think this is not good to put the commercial_entity_id at save time. I think that in many situations you want to have the commercial entity BEFORE saving a new record to allow you filtering other fields of the form.
For example you create a new incoming picking and you want to relate it to a claim (RMA situation). Before your picking is save, you may want to select the claim related to the proper commercial entity. Doing that if commercial entity is set at save time is really cumbersome.

3) Instead I suggest to set commercial_entity_id when the contact (partner_d in your case) is changed in the form. This is what I do in the RS-OCB tracking branch for instance here: 
https://github.com/akretion/openerp-server/blob/rs-ocb-7.0/openerp/addons/base/res/res_partner.py#L209
You could very well do it in a simpler way when you ca refactor the addons (talking about v8 which is what matters anyway). My point is that instead of doing it an arbitrary way, if you use some on_change (you should), then you should implement the on_change in a mixin. This way we know deterministically that all documents including this mixin support both a contact field (called partner_d in your case) and a commercial_entity_id and support it consistently.

This is like Java programs would implement a HasContact "interface" or Ruby programs a HasContact "module". This is the idea of "design by contract" http://en.wikipedia.org/wiki/Design_by_contract
Something that I think is required when you build an ERP and that is currently missing too much in the OpenERP culture, leading to brittle code breaking from customization to customization and from version to version. At the end of the road this lack of architecture largely explains why OpenERP market has its growth limited by its slow learning curve, both for us partners and for you OpenERP SA.

4) In the same idea of consistence, I think that in v8, these fields should NOT come from such arbitrary patchy extra modules but these fields should be present natively.
The risk with these fixes in modules is that 3rd party modules won't deal with them consistently and this is really hard to build a sustainable eco-system this way. For instance, in current v8 you would present that BI module filter tour sale orders or purchase orders by customer or supplier. But this is not, this is by contact. Some module will not notice the issue and will be incompatible with module being strict on this.

5) I think having the commercial entity set at on_change time instead of save time is better for base_contact compatibility because it makes it straightforward to manually force a commercial entity of a different company when you need to.


Hope you consider this feedback. Again, I can help if you want to set such on_change in a mixin (on v8).

Regards