Comment 25 for bug 1155679

@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.