Comment 16 for bug 1155679

@Nhomar, I think we need to move that discussion out of that specific bug thread because it's so general.

But for the record and in a very synthetic way, for us the two options are:

A)
======================================
we try to fix every one of the hundreds of issues one by one and possibly with smarter things like computed+stored company_entity_id field on res.partner and also overwrite read and write to deal with the proper parent_id record wherever it makes senses and finally fix the rest of the code with case by case patches. Hopefully with support form OpenERP SA rater than denial that would force us even more to work in a parallel branch with all the forking risks that represents.

But that supposes a blind faith in the new model to refactor everything to meet that new model
A faith that is missing today in a some people at Akretion at least. Specially as the new data model is rather insulting Codd theory and pre-existing art like the party model.

B)
======================================
other option is, for fields where it's very critical because it could break accounting, fiscal or financial features, we can also kind of reject the new model at least temporarily and put a domain on partner_id like the one of the invoice to prevent it to point to the contact of a partner instead of pointing to the partner record (and that means considering this bug valid also).

I won't go into the detail now, but think for a minute how badly things are broken now because OpenERP code tries to read these field in the contact instead of the parent partner record (via the partner_id field):
fiscal position, payment term, credit limit, pricelist, payment conditions, accounts, country etc...
A company contact isn't supposed to carry any of these!

Like may be it's ok to have partner_id point to an address in the CRM or even in a picking provided we get back the right partner record in the invoice. But sorry to say it, a quick scan of partner_id occurrences in the account module shows that if partner_id now designate a contact address record instead of the partner record, then out of the box, almost everything related to it is broken! In fact what works like the journal entries here is rather the exception (where it has been fixed specifically already) rather than the rule.

I would say until we have confidence in the new model or even a new one or until we have confidence A) can be done without facing regressions for 2 years all over the place, it's safer to go with option B).
now yes that mean that in some case like invoices, we should bring back a kind of contact_id field to deal with the invoicing contact when it's different from the invoicing address. And again it's all about assuming choices because if Akretion fixes it that way and OpenERP SA continue to assume an invoice contact is to be taken from that partner_id field, then yes, we have an ever growing list of discrepancies.

Conclusion ======================================
So for us it's between A) and B) with a preference for B) so far. And yes this is a very critical choice and possibly a one way choice. I'm very disappointed to have to discover myself the depth of the issue 3 months after the release is claimed stable and 1 year after it has been prototyped. To say it straight I think OpenERP is kind of attempting suicide with such non assumed experimentation in version expected to be stable (oh even LTS sorry...).

At this stage we are still discussing between partners to evaluate A) and B) and make some recommendation and propose possible fix in the core and as complementary modules.

But yes people it's time to wake up. v7 is gorgeous, but this address thing is badly broken indeed. I'm sorry that I didn't release the depth of the issue myself until that bug was declared as invalid which made me release OpenERP SA considers it possible and normal to have an invoice partner_id now pointing to a partner contact in v7, which is something very dangerous and broken today.