Hello All.

We are working on analysis for some implementations in V7.0 deeper because
they are so big ones.

We made a first analysis regarding to this, trying to be as precise as i
can in terms of problems, this is now a Aork in Progress but i think it can
be usefull for Oliver to verify things i show there.

We will try this week put analysis like this and regarding to all models,
our most important one "Accounting" is here.

https://www.evernote.com/shard/s158/sh/40828d76-d94a-4f44-bdb5-9c0336f55a52/fe43fe77c401e9f3bdf95982a4b0a878

Thanks MY 2 cents.


2013/3/26 Olivier Dony (OpenERP) <email address hidden>

> Public bug reported:
>
> == 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".
>
>
> == 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
>
> ** Affects: openobject-addons
>      Importance: High
>      Assignee: OpenERP's Framework R&D (openerp-dev-framework)
>          Status: In Progress
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> 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
>
> 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".
>
>
>   == 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
>



-- 
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>
twitter @nhomar