@raphael > Not sure you understood my proposition: > To avoid having to put the fiscal position/accounts/pricelists on the > contact of a company. The value of those fields will come automatically > from the company itself. We will do something similar to what we did for > addresses (that are shared amongst all contacts). No other object than > res.partner should be changed. This means all contacts of the compay will > always have the right pricelist/accounts/... @Fabien, Wouldn't that be by kind of "overriding the read of res.partner" to read the value from the parent_id in case of a company contact as I described in A) ? Basically I see only a A) and a B) solutions which are again: - A) you try to keep accepting companies contacts in partner_id and try to do whatever required to make it work this way (I come back on this) - B) you say partner_id in business documents can only be a company OR a physical person as in previous version of OpenERP BUT not a company contact (WTF!). So you add a contact_id field in business documents and possibly show only that contact_id field if you want to market yourself as the ERP for the masses and put a fucking on_change to set the appropriate partner_id with the same ir or with the parent_id in case contact_id is a company contact. Done! Now I strongly recommend against trying A) because even with fixing reading the values you will still have the generalized following regression all over the codebase: 1. the reporting - GROUP BY partner_id - will still be totally unusable and hard to fix. Same issue for reports joining company data like partner country or partner category etc... 2. any OpenERP domain or Select involving partner_id is mostly broken in case partner_id is now suddenly a contact 3. in OpenERP views, partner_id can be passed to be used in attrs, in form domains or context. This is a place where no extra logic on parent_id can be performed (client-side) and it will often be broken Thinking further about trying to implement A): the only decent way to unfuck the reporting would then be to add a new computed stored field like commercial_entity_id on business documents that would be either the related company or physical person. BUT wouldn't commercial_entity_id then be exactly what partner_id has been all these years? It would! So it means after facing hundreds of hidden regressions in the core and community modules during probably 2 years, you would finally implement a solution that would be equivalent of doing B) now, except that you would have made all the code more complex and slower. With functionally no benefit at all. We talked between several partners and all came to this conclusion: the only decent solution is B) unlike what OpenERP SA started doing by fixing the accounts even in case of invoicing a contact, or making reconciliation work. In fact, I talked with Luc Maurer this morning who described me exactly the same solution as I was advocating even before I gave him my solution (independently if you like) AND he also told me he detected this issue 4 months ago and said to Quentin de Paoli to fix it the B) way. So I'm a bit surprise the regression is widely open today, not even acknowledged (is it well understood at least?) and that B) seems to have been forgotten on the way... I would take it easy if we were at beta version or even a RC2, but hell we are 3 months after a magic LTS that was supposed to kick SAP's ass I mean... And as for 7.1 or 8.0, there is still no roadmap nor timeframe published, so I mean why would one expect quality to improve if software engineering stays as amateurish... So now you understood that B) is not about forbidding to invoice B2C physical persons, so what is the big deal with B)? By default you show only that contact_id field, set partner_id as before with the same semantic it ever had all these years and generate no regression at all. This is probably 50 lines of patch at most... Why on earth keep with A) ? Sorry we don't understand. Thank you for your time, but it's worth it because this problem is important.