Raphaël, you could said it louder but not clearer. +1 to all your comments.
So.. Let's try again.

Imaging this case of use:

John Doe works for ACME, SA.
John Doe buys a good for ACME, SA.
Our company makes a sale order for John Doe working for ACME, SA.
We are sending goods after one month Jon Doe asked for those goods so we
will expend almost 1 month to send the invoice to John Doe. Curiously, John
Doe left ACME, SA and was contracted by CAEM, SA who casually is also our
customer.
How do we handle with this aproach on 7.0?
1. We have got to create John Doe for CAEM, or worst, change John Doe
company asigning now CAEM, instead of ACME. So.. if user does that... What
will be the company related to invoice? CAEM? ACME?
2. If we create both different John Doe contact... sameway first invoice is
going to an incorrect contact because John Doe is not  working more for
ACME.
3. If we just move company... I don't know what happens. I'm lost,
because... How this will affect to sale order? or pickings? Or statistics?

Now.. let me handle same aproach with 6.1
1. Sale order is in the name of ACME. Additionally (if we need) could set
John Doe as related contact for Acme.
2. If John Doe leaves... what happens? NOTHING at all. User does not need
being worried about correct contacts because nothing change.
3. Sale order will be always related to ACME, Pickings will be related to
ACME and Invoices will be related to ACME. Additionally if we want
correctly set John Doe is now working for CAEM... just change the contact
company on contacts... it's done.

I feel really silly trying to explain this to someone. I can not realize
how anybody can not see this aproach...





2013/4/12 Raphaël Valyi - http://www.akretion.com <
<email address hidden>>

> E few more protestations against what is being decided by Fabien and
> Olivier:
>
> 1)
> indeed: just like as Ana said, in an ERP, what matters the most are
> legal/commercial entities. Contacts may be interesting to store, but if I
> should choose between two keys of analysis and relating things, the
> commercial entity is definitely what matters the most. Loosing in general
> that key at the profit of of the contact and making the commercial entity
> the exception to have again is total nonsense for an ERP. This is all the
> more nonsense that during 8 years OpenERP has been made and tested this way
> vs not even tested once in production after this half un-assumed semantic
> change from the very last months of wild development. This kind of bug just
> proves it.
>
> 2)
> Olivier claims that OpenERP SA proposition is less invasive than the two
> keys one that one of my module at
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27that impacts every business object. Excuse me to say it: "this is
> bullshit". All right, my module adds a contact_id key that the developer
> may need to consider or explicitly opt out what a big deal for a contact
> field that has almost never been used critically before...
> My module adding a contact_id key automatically on all objects with a
> partner_id isn't something more difficult to handle than OpenERP ORM adding
> a create_date or a write_date on every object.
> The view customization to hide partner_id and show contact_id can be seen
> as just having a new "contact" widget setting both keys appropriately but
> hiding partner_id in easy edition mode.
>
> Hell what is more important: put in danger all the proven critical ERP
> features that made OpenERP reputation all these years till 6.1 included
> and totally rely on partner_id being the commercial/legal entity OR
> saying OpenERP SA should just review a bit the 4-5 new social eye candy
> features introduced in v7 (never tested well in production, hardly even
> wanted as a priority by OpenERP users)?
>
> What is more critical: not being able to consolidate, filter or relate
> any business any data by customer/supplier OR sending an email by
> mistake to the email of company instead of the email of a contact?
>
> 3) by refusing to apply a systematic solution to the problem: you are
> introducing a dangerous amount of entropy and inconsistencies all over
> the place. Indeed: some objects will have the 2 keys: a sale order
> historically  and now an invoice with your patch module after we
> complained mostly about invoicing specifically (we were just pointing
> the most obvious issue, it doesn't mean it's the only one, we have been
> clear about that). But for all other objects, the randomness if
> partner_id is a company or just a contact of it will continue with no
> guarantee you can consolidate, filter or relate on these chaotic
> partner_id keys.
>
> That means, by refusing to adopt a systematic solution, you are just
> moving the border between order and chaos a bit further where users
> didn't complained yet. But you are not fixing the problem at all! You
> are just moving the issue to a new random, inconsistent and moving
> place. As users and integrators will keep discovering bugs and
> complaining about these new places, chances are you will keep moving the
> border away, introducing new inconsistencies and forcing to
> progressively rewrite all the codebase to switch the partner_id semantic
> with a new field that stupidly isn't the contact one just as you already
> proposed to do in your main account module.
>
> 4) you seem to admit that when analysis matters, the commercial/legal
> entity key matters and that is why you created one for the invoices at
> least in that shitty patch module now.
> But you tell that this fields need to be a fields.related.
> And I say NO because:
>
> a) a fields.related kills the liberty to eventually pick a company that
> isn't the usual contact company (the base_contact concept of having a
> contact that can belong to more than one company).
>
> b) if you take the case where you have a form with many2one field where
> you will ask the user to relate a records that belong to the same
> customer/supplier, of course partner_id won't do it anymore because that
> will be just a contact eventually and you will need to add a new
> commercial_entity_id field on your own (so in every object eventually).
> but when you will do that, if you use a field.related, you won't be able
> to pass commercial_entity_id in a filter or an on_change before saving the
> record where field.relate is computed.
>
> That is in fact what you should use in forms is an on_change for
> automatically setting it, just as I did in my proposal at
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27
> (but adding the right contact_id key one).
>
> 5)  consequently, by refusing to fix the problem systematically, you will
> force all the implementers to gradually re-add all these
> commercial_entity_id second keys on all object where they will need a
> company granularity (that is most of the time as we said).
> And you will also force them to implement all these on_changes in a
> chaotic way (and also change all the partner_id logic as soon as they
> discover it doesn't work with contacts).
> That is, you will create a hell of incompatible modules each creating
> these keys and overlapping on_changes their own ways.
> And with the other guys like us that will keep assuming partner_id is a
> commercial/legal entity legal before because we see no way out of what you
> entered now and don't want to adapt all our localisations to that dead end
> model.
>
>
> Tell me again all that is less intrusive and safer than our 2 keys
> proposals with contact_id right now...
>
>
> Time to admit you just screwed it and work on the real solution for the
> goodness of everyone.
>
> My 2cts
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
>   [7.0] incorrect handling of contact/companies for invoicing and
>   related purposes
>
> Status in OpenERP Addons (modules):
>   In Progress
> Status in OpenERP Server:
>   In Progress
>
> Bug description:
>   == Problem Description ==
>
>   This issue is an attempt to formalize the various problems detected
>   with the res.partner refactoring that took place in OpenERP 7.0. Some
>   of the issues have already been discussed on bug 1151947, bug 1155679
>   and on help.openerp.com.
>
>   The main problems identified so far:
>
>   1) When a simple contact (type=contact) is selected as the reference
>   party for creating a business document (such as the customer on a
>   Sales Order), a proper invoicing partner (if any) should be selected
>   among the descendants of the "commercial party" to which the contact
>   belongs, instead of the contact itself.
>
>   2) Even when a simple contact is used as the invoicing partner for a
>   business operation (e.g. manually selected by the user as the invoice
>   address on a SO), all invoicing/accounting-related master data must be
>   taken from the relevant "commercial party" for that contact. This will
>   usually be the parent company.
>
>   3) When editing contacts/addresses, it is currently possible to view
>   and edit accounting/invoicing related data, while it should be clear
>   that this data is coming from the "related commercial party", usually
>   the parent company.
>
>   4) When searching though business documents for a company name, the
>   entries that were issued for one of the company's contacts/addresses
>   should be found as well.
>
>   5) It has been reported that in some countries it is not permitted to
>   issue invoicing documents for a contact, so the name of a relevant
>   invoicing must be used instead (Financial Department or parent
>   Company).
>
>   6) In "Analysis" reporting views, result that are grouped by partner
>   will not be automatically aggregated at company level.
>
>   == Proposed Solution==
>
>   The rationale for the proposed solution is based on the following points:
>   - We think the 7.0 partner model is appropriate and should not be
> considered the cause for these functional/usability problems
>   - We think the solution should be mostly handled by the res.partner
> model itself, so that it fixes most modules automatically.
>   - We think that in many cases, using a contact/address is the right
> level of granularity, and any reporting based on that is fundamentally
> correct. Invoicing/Accounting is specific for the reasons mentioned above,
> and automatically selecting the proper entity to use should make reporting
> provide the expected result.
>
>   Based on this, we propose the following solution. Parts A & B are
>   meant to solve the issue of using the right invoicing/accounting data
>   at all times (issues 2 & 3 mainly), while parts C, D & E  are meant to
>   improve the selection of invoicing entities and the related reporting
>   (issues 1, 4, 5 & 6):
>
>   A) Let the "commercial party" for a partner be the person or company
>   that is used as reference for all invoicing/accounting matters. The
>   "commercial party" is computed as: the first parent that is marked as
>   a company (is_company is checked) or is the root of the hierarchy if
>   there is no company. It can be the partner itself if it's a company or
>   if it has no parent.
>
>   B) The relevant invoicing/accounting data will only be editable on an
> "commercial party", and all contacts/addresses that are descendants of an
> "commercial party" will inherit those settings. This will be done as
> follows:
>   - when a partner is not an commercial party, the form view will be
> modified: the Accounting tab and the Invoicing section of the
> Sales&Purchases tab will be replaced by a note that says something like
> "Invoicing settings are controlled on <link to commercial party>".
>   - when writing() on a partner that is an commercial party, all the
> values of invoicing/accounting-related fields will be automatically copied
> to all descendants that are not commercial party themselves (e.g.
> pricelist, G/L accounts, payment terms, etc.). The list of fields to copy
> will be returned by a method on res.partner that can be overridden in other
> modules.
>   - when changing the parent of a partner causes a change of "commercial
> party", the same fields will be copied
>
>   C) When a contact/address is selected as the reference for a business
> document (SO/PO), the system should automatically select appropriate
> invoicing and delivery parties from the relevant "commercial party".  This
> is the responsibility of the res.partner.address_get() method (legacy name
> for backwards-compatibility), and it must be adapted for the new model.
>   The new algorithm should search in the whole hierarchy of the partner,
> stopping at the parent "commercial party", as defined in A. This will be
> used automatically by the on_change triggers on SO/PO/etc, and should
> ensure that the proper invoicing and delivery partners are always selected.
>
>   D) The res.partner.address_get() method considers the partner type
> "default" as a wildcard, so any partner with type "default" is seen as a
> match for any requested type. This is correct but unfortunately "default"
> is the default value, which would stop the lookup described in C at the
> first step. The "default type" for a partner will be changed to "contact",
> so that unless otherwise specified a simple contact cannot be used as
> "invoicing partner" or "delivery partner", unless it is itself a
> "commercial party".
>   Note: even if a simple contact has type "default" or "invoicing", the
> accounting/invoicing settings would still come from the relevant
> "commercial party". It will simply be seen as a possible choice for the
> "invoice partner"  (e.g. the partner_invoice_id field on a SO)
>
>   E) The search view of the main business documents will use the
>   "child_of" operator when matching contacts/partners. For example all
>   invoices issued to any contact from Agrolait will be found when
>   searching for "Partner: Agrolait".
>
>   UPDATE:
>   F) (Already implemented in 7.0) When booking journal entries for any
> partner, the system always links them to the "commercial party" related to
> the partner (the first parent company or root partner). This makes sure
> that reporting and reconciling Journal entries will always work properly.
>
>
>   == How does the solution solve the issues ==
>
>   Let's address the issues one by one:
>
>   1) When selecting a contact as the Customer for a Sales Order, a
>   proper "invoice address" and "delivery address" will now be
>   automatically selected, thanks to C & D.
>
>   2) Any code in business modules that deals with invoicing/accounting
>   related data should automatically use the data of the "commercial
>   party", thanks to B, because the data should always be in sync.
>
>   3) Directly addressed by B.
>
>   4) Directly addressed by E.
>
>   5) Thanks to C & D, an appropriate "invoicing partner" should always
>   be automatically set on SO/PO, in B2C and in B2B cases. So if you want
>   "Agrolait" to be displayed on all invoices that corresponds to SOs
>   issued for "Sylvie Lelitre (Agrolait)", just make sure that "Sylvie
>   Lelite" does not have "invoice" or "default" type, but has type
>   "contact" instead (which will be the default).
>
>   6) Due to the previous points (especially 5), an appropriate invoicing
>   partner should always be selected on all invoices, regardless of who
>   what the contact to which the SO/PO was issued. This will make
>   reporting behave as expected in most cases. There will be cases where
>   the contact granularity appears (e.g when grouping Sales Orders on
>   Customer), but this expected and correct. In general the same contact
>   will appear for most documents related to the same commercial party.
>
>   For all other case, such as domains, contexts, etc., contacts should
>   be a valid level of granularity, keeping in mind the major use cases:
>   B2B with 2 levels of hierarchy: company and contacts, and B2C with 1
>   level (normal case) or 2 levels of hierarchy (ecommerce/webshops with
>   multiple addresses for each customer)
>
>   == Further refinements ==
>
>   In trunk some extra things could be planned to further improve some
> aspects, such as:
>   - the "commercial party" field could become a stored function field on
> res.partner, so that it becomes very easy to add related fields on any
> document - making reporting per company even easier.
>   - other suggestions welcome
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/+subscriptions
>



-- 
CEO Avanzosc, S.L <http://www.avanzosc.es> : Office phone / Tfono oficina:
(+34) 943 02 69 02
Ana Juaristi Olalde <http://www.anajuaristi.com/>: Personal phone: 677 93
42 59. User/usuario skype: Avanzosc  a
www.openerpsite.com


*El contenido de esta comunicación y de toda su documentación anexa es
confidencial y se dirige exclusivamente a su destinatario. El uso no
autorizado de esta información está prohibido por la legislación vigente.
Si usted no es el destinatario le rogamos nos lo indique, no comunique su
contenido a terceros y proceda a su destrucción. Disculpe las molestias que
le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran
en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse
para ejercer sus derechos de acceso, rectificación, cancelación y oposición
en Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 -
<email address hidden> <email address hidden> *
* *

*Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta
hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu
egiten du bertan eskainitako informazioa baimenik gabe erabiltzea.
Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez,
guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu.
Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak
Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea
eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka
egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Julio
Urkijo, 32, 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 - **
<email address hidden> <email address hidden> *
*This message and all documents attached to it are confidential and
intended only for the person or entity to which it is addressed. Any use of
this information by unauthorised persons is prohibited under current
legislation. If you received this message by error, please advise us,
destroy it and refrain from communicating its contents to third parties. We
apologise for any inconvenience receiving this email improperly may cause
to you. Your personal data are included in a file owned by Avanzosc, S.L.
If you want to exercise your rights of access, correction, erasure and
objection you can contact the Controller at Julio Urkijo, 32, 20720,
Azkoitia (Gipuzkoa), T: 943 02 69 02 –
<email address hidden><email address hidden>
*