@cristian.

28 +    def _commercial_id_compute(self, cr, uid, ids, name, args,
context=None):

Here:

https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577

Answer you the question, I am testing yet with some more deep PoC but I
think it is bringing good approach, I am fear yet in other models, as Raph
says but in invoices it is shown like it is working pretty well.




2013/4/15 Cristian Salamea (Gnuthink) <email address hidden>

> On Mon, Apr 15, 2013 at 6:15 PM, Fabien (Open ERP) <email address hidden>
> wrote:
>
> > >
> > > 1) scenario 10: What about invoice to walt Disney but send it to john
> do
> > > that as to validate it because he is in charge of want should be done
> > > and has role to verify that the invoice is correct ? You have this with
> > > company and international office for example. The man "accounting
> > > manager" of ACME is the contact of all invoice for FR office, BELGIUM
> > > Office, but invoice is linked to fr office, BELGIUM office  .. I may be
> > > wrong but I have two customer that do this actually and I don't know
> how
> > > to setup this in v7. With rapahel branch I just have to set contact to
> > > "accounting manager" and partner to fr Office for example. But yes we
> > > have to link openchatter, email and commication to contact_id instead
> of
> > > partner id. Like you said rename partner_id by contact in module take
> > > 10min ;)
> >
> > Like in v6.1: you create several accounting manager, one for each
> > company. (or you install base_contact) Please note that it does not work
> > for raphael branch too.
> >
> > Side note: Your use case is very strange, I don't think I ever saw an
> > accounting soft that do that. (I never saw an accounting software that
> > prints two addresses on an invoice, one for the real company, another
> > one for the company that should receive it. When there are a second
> > address on invoices, it's for delivery address)
> >
> >
> > > 2) Invoice issue and task on timesheet.
> > >
> > > - Create a contract (annual support contract) with company ACME. You
> > define that support cost 60 EUR / hours.
> > > - Check task and issue on this contract and invoice on timesheet.
> > >
> > > Now a man (or woman !) call me because he/she has a problem. I create
> an
> > > issue assigned to me, and contact Miss Anna who want to have adresse on
> > > openerp in different tables. I work on it and record my work time. As I
> > > can have more than one open project with ACME, and as OpenERP set it to
> > > mandatory, I need to record my time on a project/analytique account.
> But
> > > as my previous screenshot show, you have no analytic account in
> many2one
> > > widget because they are filtered on contact, and contact has no project
> > > on it, this is ACME that has this.
> >
> > It's a bug. (the first we found that requires to change addons/business
> > documents)
> > Should be fixed by Olivier.
> > We should grep "domain.*partner_id.*=.*partner_id" in the code.
> >
>
> Just to clarifiy @Fabien, documents has partner_id (as contact) and linked
> to company ACME, where i get fiscal data ? partner ? company ?
>
> Regards,
>
> >
> > > I think contact_id is the right granularity for end user guy (person
> > that use openerp and record some data), but company (partner_id) is the
> > right granularity for business document. If you want to have what you
> > code in V7 juste set partner_id to invisible and add the onchange
> > function to set the correct partner_id. no data duplication, no problem.
> > The only data replication you have is when contact and partner are the
> > same, but it will be "rare" enough,  because in real world you speak
> > with contact (person, department, etc ..) about business object of a
> > company he belongs to.
> >
> > We are convinced that the current solution is the right one.
> >
> > We may find a few bugs because all objects/views have been changed in
> > v7, but not that much. (note that this one is the very first we found on
> > addons related to the partner issue, all others have been fixed on the
> > partner object)
> >
> > >
> > > I really like the simplicity of what as be done, but to be honest, we
> > > are losing consistancy and stability just because you choose to connect
> > > / fusion contact and partner and think I not so simple ...
> >
> > No, the new model is more consistent that the old one. In the old one, we
> > could have inconsistencies like that, printed as an address of an
> > invoice/SO:
> >     Company X
> >     Address of Company Y
> > The consistancy is guaranteed by the fact that there are no double
> > information for the same thing as commercial_id is a function field.
> >
> > I agree about the maturity, even if the new approach already fixed
> > several issues of v6.
> >
> > The transition requires some effort, but the future with the v7 model is
> > much simpler and clean. (less fields on objects, no unnecessary
> > on_change, less lines of code, more use cases handled, easier for the
> > end user, better reflects the reality).
> >
> >
> >
> >
> > >
> > > --
> > > 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