Hello.

I think the Hypotesis is incomplete.

Hypothesis
ACME (is_company)
   - John Doe (Invoicing)
- Marc Levy (contact)
- Warehouse X (delivery)

Should be more complicated to cover all scenarios:

Hypothesis
ACME (is_company)
   - John Doe (Invoicing)
- Marc Levy (contact)
- Warehouse X (delivery)
   - Pedro Pérez (Invoicing)
#[To Know if from the link i am able to select both of them]
- Luis Ramirez (default)
#[To allow see what happen when a default is present]
- Warehouse Y (delivery)
#[To considere several Shipping address in some cases have more than one
need  a Question and not take the "contact@delivery[0]"]
- Peter landberg (is_company)
#[This is what we got in V6.1 when relate 2 partners, now for useabilities
reason some fields are hidden, and we lost this feature.]
  - Check Department (invoice)
- Warehouse W (delivery)
#[This is to understand a complex partner organization (what we have
dominated in México on 6.1)]


2013/4/16 Nhomar Hernández <email address hidden>

> @cristian...
>
> I am Totally agreed with you,
>
> did you read the second part of the Fabien's answer?
>
> Please support us, in the link the He shared he ask for the verification
> in all places we nee them mandatory.
>
>
> 2013/4/16 Cristian Salamea (Gnuthink) <email address hidden>
>
> On Tue, Apr 16, 2013 at 12:31 AM, Fabien (Open ERP) <email address hidden>
>> wrote:
>>
>> > > group task by partner_id :
>> > >
>> > > ->
>> > >
>> >
>> http://www.youtube.com/watch?v=ABcvCnEYhBI&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=4
>> > >
>> > > really great data model ...
>> >
>> > As we said, we think partner_id is the right granularity in a lot of
>> > objects for the group_by operations.
>> >
>> > If a user records 5 issues:
>> >   - 2 for "Acme, John Doe"
>> >   - 3 for "Acme, Marc Levy"
>> >
>> > We think it's normal that, if the user asks a group_by he gets a result
>> > consistent with what he recorded:
>> >   - 2 for "Acme, John Doe"
>> >   - 3 for "Acme, Marc Levy"
>> >
>> > Not only, it's sometimes what he wants in terms of reporting, but it's
>> > surely what he wants if he uses group_by to reorganize documents using
>> > drag&drop in the kanban.
>> >
>> > Having said that, we also agree that, for some objects you may want, in
>> > addition, another type of group_by, which is by commercial_id, not by
>> > partner_id. The implementation is trivial as it's just adding a
>> > commercial_id fields.related on the object, if you need that.
>> >
>> >
>> >
>> @Fabien, here is not "if we need it add it" a related field, IMO group by
>> ACME is most common action used, please ask users & partners.
>> or when you group by partner your partnerships sales you see now 2 for
>> Contact1, 3 for Contact2 ?
>> Most used feature wants to see by company not by contact.
>>
>> This happens in SO, PO, CRM, Invoices, etc. all business document, here
>> you
>> are telling us to group by ACME i need add related field in all objects  ?
>>
>>
>> Regards,
>>
>> >
>> > Fabien
>> >
>> >
>> > >
>> > > --
>> > > 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
>> >
>> > --
>> > 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
>> >
>>
>>
>> --
>> Cristian Salamea
>> @ovnicraft
>>
>> --
>> 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
>> 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
>>
>
>
>
> --
> --------------------
> 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
>



-- 
--------------------
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