So, everything is said. Problem is that you still think that correct
granularity level is contact, since people all over the world think that
correct level is partner.
IMHO i still think it is a big mistake changing level of granularity,
giving priority to a secondary entity as it is contact instead of first
level granularity entity as it is company.
But sentence has been written and it seems there will not be strategy
change. So there is nothing more we can do. It is a pity.
Thank you for your time and detailed explnations.
El 11/04/2013 20:31, "Olivier Dony (OpenERP)" <email address hidden>
escribió:

> Some more precisions regarding Joël's questions...
>
> On 04/11/2013 12:18 PM, Joël Grand-Guillaume @ camptocamp wrote:
> > A) When making a SO, choosing Camptocamp as the Customer, it set Joel as
> > Invoice address and Guewen as shipping one. That means I can invoice Joel
> > from here and not from the accounting menu... That seems strange IMO,
> what
> > do you think ? If SO can make an invoice for "Joel (Camptocamp)", why I
> > can't invoice Joel as well from the accounting menu... => this is a bug I
> > think and can be fixed allowing to invoice Joel in Invoice (mean allow to
> > invoice "invoicing" partner"), you agree ?
>
> Yes, that was inconsistent in the proposed solution and in comment #50. The
> domain change was reverted on invoices.
>
>
> > B) When making a SO to Camptocamp with "invoice from delivery", confirm
> it,
> > confirm deliver and invoice it => it invoice Camptocamp not "Joel"
> selected
> > on the offer as the invoicing contact... That is not good. We need to be
> > consistent... I expect to invoice Joel in that case right ? => This is a
> bug
> > and can be fixed, you agree ?
>
> Yes that was clearly a bug as well. It existed in previous versions (the
> invoice address was not copied but instead reset), but was only apparent if
> using an invoice address that was not the default one selected by the
> onchange.
> This is fixed in the sale_stock module.
>
>
> > C) In the case invoice are related to "Joel (Camptocamp)", the sales
> > turnover for Camptocamp is not correct (from Reporting -> Invoice
> analysis
> > menu, not from grouping invoices,...).
>
> This is handled by the extra "account_report_company" module, to be merged
> in
> account in trunk, and which will allow grouping and analyzing invoices per
> "Commercial Entity".
>
> We only need this in Invoices because the contact-level granularity is
> explicitly overridden on the Journal Entries, and because Invoices are a
> key
> reporting area in any business. For all other cases we think the
> contact-level
> granularity will be correct and expected.
>
> As Fabien mentioned, there can be cases where it will be useful to allow
> search
> criterions on "Partner" to also match the contacts (child_of), but these
> should
> only be for usability purposes.
>
> Performance-wise, the "child_of" operator used for a Partner criterions
> only
> depends on the depth of the partner hierarchy, not the number of business
> documents. For very deep hierarchies it can even be made O(1) by enabling
> _parent_store on res.partner, if ever needed.
>
>
> > D) We still cannot invoice a specific address of a specific company... We
> > have (and others too) some complex structure to invoice, like the states,
> > big university and even with those corrections, we do not solve this
> major
> > issue. You have:
> >    - Group Company XY
> >       - Company A
> >           - Department A, Contact 1
> >           - Department A, Contact 2
> >       - Company B
> >           - Department B, Contact 3
> > => This is mandatory that you can invoice Company A, for submission to
> > "Department A, Contact 1" or "Department A, Contact 2". We do need two
> > fields on the invoice... Because even if properties are correctly set
> (the
> > only bug you saw and correct here), we can still make invoice addressed
> to
> > Contact 1 or 2 depending on the project (cause they are they people to
> > validate the invoice internally), but still, the invoice belong to
> Company
> > A, will be paid by Company A and the turnover belong to Company A not
> > invoicing Contact 1 or 2 !!! Using group by must show this as it was in
> > previous version.
>
> Invoicing "Department A, Contact 1" or "Department A, Contact 2" should
> work
> fine with the updated proposal, and the Invoice analysis and group by will
> behave as expected on "Company A" or "Company B".
>
>
> > E) Now migration (done by your service). We get strong trouble because
> > before migration, those WERE good, and aren't any more:
> > - Turnover by company is right because based on partner_id (through
> analysis
> > or whatever group by)
> > - Invoices to various department/contact for the same partner/company
> based
> > on contact_id can be done
> > - External link to other systems that are based on the 6.1 data model...
> > => How will you keep this information correct / backward compatible in
> the
> > migrated instance without having 2 fields on the invoice (or other
> objects)
> > I think it is just impossible. How will you handle that ?
>
> As points C and D are covered the result of the migration should be
> immediately
> correct. As for external links to other systems it will be trivial to fix
> with
> the "account_report_company" module, even though a proper migration should
> still be planned, just like for everything else.
>
>
> >   F) Another trouble for migration (still done by you):
> >
>
> > Before migration: Invoice open to Company A, Contact M. Martin => Invoice
> > printed and sent to M. Martin in Switzerland while Company A is in
> Sweden.
> >
> > After Migration (and you've done it): Invoice open to Company A, no more
> > contact => Print out the invoice, and send it to... Company A in Sweden
> > !!??!?
> >
> > => Again, if you do not store 2 fields, you cannot guarantee backward
> > compatibility here right ? Or what solution do you have ?
>
> That looks like an error in the migration, the Invoice after migration
> should
> have been issued for "M. Martin in Switzerland", contact of "Company A in
> Sweden" - which still only needs one field. The second field is only needed
> when you want Invoice grouping and reporting for "Company A".
>
>
> > G) All modules in standard addons or community or whatever will have to
> be
> > rebuild them to use what you suggest with your "commercial_entity_id" so
> why
> > not using the Raphaël's way that keep backward compatibility, while still
> > keeping you DB schema and views simpler as you liked to have ? => Any
> > concrete reasons or facts on that ? I mean in both cases there is work
> to be
> > done, just the solution you suggest need more... Or I may be missing
> > something?
>
> On the contrary, very few changes are required in community modules, just
> like
> very few were needed in official addons. The contact level of granularity
> is
> correct and it would be an error to change all community modules to use the
> "commercial entity" instead. Even for modules that handle
> accounting/invoicing
> data, our proposed solution takes care of delegating the relevant fields
> from
> contact to company.
> So unless a module deals with very low-level accounting data and partially
> bypasses the generation of Journal Entries of the core accounting, no
> change
> should be needed.
>
> Porting a module from OpenERP 6.1 to OpenERP 7.0 still requires a real
> review/migration, and fortunately the community is better organized now to
> perform those reviews efficiently and with shared resources. (thanks to
> you!)
>
> This point is critical and must be very clear, especially for contributors
> who
> will take part in porting/reviewing modules for v7.0!
>
>
> As for Raphael Valyi's proposed module, it is a clever piece of OpenERP
> magic
> but it looks like the wrong option for 2 main reasons:
>   1. It goes in the opposite direction model-wise: in 7.0 the level of
> granularity for partners is "contact" by default everywhere, and "company"
> is
> the exception for Journal entries. Yes this is a big change, and some of
> the
> consequences were missed during the design and test phases, but we still
> think
> this is the way to go. The solution he proposes goes backwards and only
> shows
> contacts on the surface, while keeping a "company" level of granularity
> everywhere. All reporting/group-by/propagation would still be based on the
> "company" level, the "contact" info would be lost and become the exception
> rather than the rule, so that will also break any new feature that expects
> contact-level granularity to be the default. That's exactly the opposite of
> what 7.0 wanted to achieve.
> 2. The way that solution is implemented is dangerous, and it might even be
> worse than whatever issues it hopes to cure. It creates hidden fields and
> hidden behaviors everywhere in the system, affecting all modules in a way
> that
> developers can easily miss during their developments, and adding possibly
> hard-to-detect side-effects. Moreover, it does not have any escape plan:
> if you
> install it there is no easy way to go back, short of deciding to add an
> extra
> field and an extra on_change method on *every* model of *every* module you
> will
> ever use (be it community or official). And we explicitly do *not* want
> that to
> happen everywhere, as explained. So if you use it you'll either have to
> stay
> with some amount of ORM magic/hidden behavior forever, or to
> migrate/opt-out
> all your models/tables one by one to drop the extra fields, eventually
> ending
> up with the same result we have now.
>
> So yes, there might be a few remaining cases we missed (like those you
> spotted,
> thanks!), but there shouldn't be many because this is the exception, not
> the
> rule. And it's definitely better to fix these few cases than trying to go
> backwards for fear of the changes, ending up with a mixed model that is not
> consistent and no clear way of improving it.
>
>
> > H) You said :
> > """
> <SNIP>
> > Note also that "partner_id, address_id" is not exactly the same than
> > "partner_commercial_id, partner_id". The semantic really changed, it's
> > not just a switch in field names.
> > """
> > About what you're speaking here ? V8.0 ? No such a fields
> > (invoice_commercial_ids) are present today on the partner, nor the
> foreign
> > key on the invoice...
>
> Fabien spoke of v7, and the FK is added by "account_report_company" for
> reporting purposes. The "invoice_commercial_ids" would be the virtual
> reverse
> o2m relationship, but it does not necessarily have to be materialized, as
> the
> FK key is only present for reporting purposes.
> Similarly, the "partner.invoice_ids" fields did not really need to be
> materialized, it is not used anywhere in official addons as far as I can
> see.
>
>
> >   * Why the hell is it so difficult to make an exception in the release
> > policy when you break something so badly (mainly F, G & H).
>
> The question of making an exception to the release policy is not very
> important, we can patch DB schema using new modules if we really need it
> (like
> what "account_company_report" does), without breaking compatibility with
> existing 7.0 modules or production deployments. It's a question of doing
> the
> right thing for the product, and we think this is the best course both for
> 7.0
> and for the future.
> We would have done the same thing if those issues had been detected before
> the
> 7.0 release (without needing an extra module of course), and we're very
> sorry
> that they were not.
>
> Thanks a lot for taking the time to thoroughly test and analyze the
> proposed
> solution in an open-minded way!
> We *do* want to be sure we cover all cases as they should be, based on the
> 7.0
> model, while preserving the correct level of granularity everywhere now
> and in
> the future.
>
> --
> 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
>