Raphaël's solution seems better than risking referential integrity by 
depending on duplicating company's  attributes into contacts....

Just one piece of code where this duplication is missed, and we are all 
doomed...


I think that's one of the the points in using databases instead of plain 
files, isn't it ?


Regards,
-Mario

On 04/12/2013 01:30 PM, Raphaël Valyi - http://www.akretion.com wrote:
> Again,
>
> this is a monkey patch because I don't have commit right in the core, but
> eventually that could be done in the core, just like you add say a
> write_date/create_date automatically and patch the view just like you use
> to transform XML attributes int javascript modifiers. That wouldn't shock
> me any more than that.
>
> May be we will get these 5 people here...
>
>
> On Fri, Apr 12, 2013 at 2:51 PM, Fabien (Open ERP) <email address hidden> wrote:
>
>> For lazy people, here is the most interesting file:
>>
>>
>>
>> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/view/head:/akretion_b2b_unfck/akretion_b2b_unfck.py
>>
>>
>>
>> On 04/12/2013 07:47 PM, Fabien Pinckaers wrote:
>>> Common Raphaël,
>>> Let's be serious.
>>>
>>> Is there anyone on this list that read Raphaël's code [1] and that can
>>> seriously tell me he would like this code to be merged in OpenERP?
>>>
>>> I am ready to pay a pack of beer to Akretion at the community meeting,
>>> if they are 5 people in this list that can reply and write *honestly*:
>>>
>>>    I read Raphaël's code and I think this should be merged in OpenERP.
>>>
>>>
>>>
>>> [1]
>>>
>> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck/
>>>
>>>
>>>
>>> On 04/12/2013 04:23 PM, Raphaël Valyi - http://www.akretion.com wrote:
>>>> 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
>>>>
>>>
>>
>> --
>> Fabien Pinckaers
>> CEO OpenERP
>> Chaussée de Namur 40
>> B-1367 Grand-Rosière
>> Belgium
>> Phone: +32.81.81.37.00
>> Fax: +32.81.73.35.01
>> Web: http://openerp.com
>>
>> --
>> You received this bug notification because you are a member of OpenERP
>> Drivers, which is subscribed to OpenERP Server.
>> 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
>>