| 2013-03-26 13:28:47 |
Olivier Dony (Odoo) |
bug |
|
|
added bug |
| 2013-03-26 13:36:44 |
Olivier Dony (Odoo) |
bug task added |
|
openobject-server |
|
| 2013-03-26 13:40:57 |
Olivier Dony (Odoo) |
openobject-server: importance |
Undecided |
High |
|
| 2013-03-26 13:40:57 |
Olivier Dony (Odoo) |
openobject-server: status |
New |
In Progress |
|
| 2013-03-26 13:40:57 |
Olivier Dony (Odoo) |
openobject-server: milestone |
|
7.0 |
|
| 2013-03-26 13:40:57 |
Olivier Dony (Odoo) |
openobject-server: assignee |
|
OpenERP's Framework R&D (openerp-dev-framework) |
|
| 2013-03-26 13:52:25 |
Stefan Rijnhart (Opener) |
bug |
|
|
added subscriber srsubscrmgr |
| 2013-03-26 14:12:24 |
Lorenzo Battistini |
bug |
|
|
added subscriber Lorenzo Battistini - Agile BG |
| 2013-03-26 14:20:59 |
Paulius Sladkevičius @ hbee |
bug |
|
|
added subscriber Paulius Sladkevičius |
| 2013-03-26 14:23:20 |
Cédric Krier |
bug |
|
|
added subscriber Cédric Krier |
| 2013-03-26 14:50:35 |
Erwin van der Ploeg (BAS Solutions) |
bug |
|
|
added subscriber Erwin van der Ploeg (Endian Solutions) |
| 2013-03-26 16:06:47 |
Olivier Dony (Odoo) |
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 |
== 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 |
|
| 2013-03-27 02:10:33 |
MonExodus |
bug |
|
|
added subscriber MonExodus |
| 2013-03-27 06:26:00 |
digitalsatori(Shine IT) |
bug |
|
|
added subscriber digitalsatori |
| 2013-03-27 07:34:52 |
Maik Steinfeld |
bug |
|
|
added subscriber Intero |
| 2013-03-27 09:01:01 |
Eckhard Schwarzat |
bug |
|
|
added subscriber Eckhard Schwarzat |
| 2013-03-27 13:33:33 |
Dušan Laznik (Mentis) |
bug |
|
|
added subscriber Dušan Laznik (Mentis) |
| 2013-03-28 02:57:39 |
Maxime Chambreuil (http://www.savoirfairelinux.com) |
bug |
|
|
added subscriber Maxime Chambreuil (http://www.savoirfairelinux.com) |
| 2013-03-28 08:26:11 |
Attila Tatár |
bug |
|
|
added subscriber Attila Tatár |
| 2013-03-28 16:31:48 |
Stéphane Bidoul (Acsone) |
bug |
|
|
added subscriber Stéphane Bidoul (Acsone) |
| 2013-03-31 12:27:24 |
Pedro Manuel Baeza |
bug |
|
|
added subscriber Pedro Manuel Baeza |
| 2013-03-31 20:45:13 |
Goran Kliska |
bug |
|
|
added subscriber Goran Kliska |
| 2013-04-01 11:57:33 |
Maxime Chambreuil (http://www.savoirfairelinux.com) |
branch linked |
|
lp:~akretion-team/openobject-addons/akretion_b2b_unfck |
|
| 2013-04-05 12:43:57 |
Antony Brugger @ Eezee-It |
bug |
|
|
added subscriber Antony Brugger @ Eezee-It |
| 2013-04-08 01:55:45 |
Launchpad Janitor |
branch linked |
|
lp:~openerp-dev/openobject-server/7.0-fix-contact-company-handling |
|
| 2013-04-08 03:01:11 |
Launchpad Janitor |
branch linked |
|
lp:~openerp-dev/openobject-addons/7.0-fix-contact-company-handling |
|
| 2013-04-08 09:30:02 |
Daniel Reis |
bug |
|
|
added subscriber Daniel Reis (SECURITAS SA) |
| 2013-04-09 00:53:10 |
Mario Arias |
bug |
|
|
added subscriber Mario Arias |
| 2013-04-10 09:27:26 |
Michael Döderlein |
bug |
|
|
added subscriber Michael Döderlein |
| 2013-04-11 19:32:32 |
Pierre Lamarche (www.savoirfairelinux.com) |
bug |
|
|
added subscriber Pierre Lamarche (www.savoirfairelinux.com) |
| 2013-04-13 06:24:22 |
Fabien (Open ERP) |
attachment added |
|
sc00.png https://bugs.launchpad.net/bugs/1160365/+attachment/3642735/+files/sc00.png |
|
| 2013-04-13 14:58:35 |
Denis Barbot |
bug |
|
|
added subscriber dbarbot |
| 2013-04-15 12:20:34 |
Nicolas Clavier |
bug |
|
|
added subscriber Nicolas Clavier |
| 2013-04-15 15:13:13 |
asoler |
bug |
|
|
added subscriber asoler |
| 2013-04-15 17:55:37 |
Nicolas JEUDY |
attachment added |
|
wrong_analytic_account.tiff https://bugs.launchpad.net/openobject-addons/+bug/1160365/+attachment/3644893/+files/wrong_analytic_account.tiff |
|
| 2013-04-16 17:53:15 |
Brendan Clune (Logic Supply) |
bug |
|
|
added subscriber Brendan Clune (Logic Supply) |
| 2013-04-17 06:56:51 |
Launchpad Janitor |
branch linked |
|
lp:~akretion-team/openobject-server/contact-id-solution-for-v7-contact-management |
|
| 2013-04-17 08:19:27 |
Launchpad Janitor |
branch linked |
|
lp:~akretion-team/openobject-addons/contact-id-solution-for-v7-contact-management |
|
| 2013-04-19 11:43:35 |
Dominique Chabord |
bug |
|
|
added subscriber Dominique Chabord |
| 2013-04-20 03:06:27 |
Olivier Dony (Odoo) |
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 |
== 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 cannot be easily 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.
More details on the rationale: http://bit.ly/118HrZ0
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 Sales Orders issued to any contact from Agrolait will be found when searching for "Partner: Agrolait".
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.
G) The order of Partner records will be modified so that a Company always comes right before its contacts, in a way that matches the display labels. The display label of contacts will be changed to "Company, Contact" in order to make very clear that selecting it includes selecting the Company (contact always acts on behalf of Company).
This will ensure that all search results, including auto-completion of partner names and "group by" views will always be consistent and have all the company documents next to each other.
H) As a special case to the above, an extra module "account_report_company" will be added in the official 7.0 addons in order to add an explicit "Company" granularity in the Invoice list and Invoice Analysis (by adding a denormalized hidden field used for reporting only).
== 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 C, D & H, an appropriate invoicing partner should always be selected on all invoices, regardless of who what the contact to which the SO/PO was issued, and the Company level of granularity will be available in Invoice reporting.
There will be other 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)
And when a "Company" level of granularity is desired, part G of the solution ensures that the results are already grouped by Company (all related rows next to each other), making sure the data is easy to find and aggregate.
== 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 |
|
| 2013-04-20 03:42:55 |
Launchpad Janitor |
branch linked |
|
lp:~openerp-dev/openobject-server/7.0-check-recursion |
|
| 2013-04-20 03:43:00 |
Launchpad Janitor |
branch linked |
|
lp:openobject-addons/7.0 |
|
| 2013-04-20 04:16:12 |
Olivier Dony (Odoo) |
openobject-addons: status |
In Progress |
Fix Released |
|
| 2013-04-20 04:16:35 |
Olivier Dony (Odoo) |
openobject-server: status |
In Progress |
Fix Released |
|
| 2013-04-20 18:00:40 |
Launchpad Janitor |
branch linked |
|
lp:ocb-server |
|
| 2013-04-20 18:40:34 |
Launchpad Janitor |
branch linked |
|
lp:ocb-addons |
|
| 2013-04-21 23:10:54 |
Launchpad Janitor |
branch linked |
|
lp:~ocb/ocb-addons/rs-ocb-70 |
|
| 2013-04-21 23:12:36 |
Launchpad Janitor |
branch linked |
|
lp:~ocb/ocb-server/rs-ocb-70 |
|
| 2013-04-22 08:33:59 |
Fabien (Open ERP) |
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 cannot be easily 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.
More details on the rationale: http://bit.ly/118HrZ0
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 Sales Orders issued to any contact from Agrolait will be found when searching for "Partner: Agrolait".
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.
G) The order of Partner records will be modified so that a Company always comes right before its contacts, in a way that matches the display labels. The display label of contacts will be changed to "Company, Contact" in order to make very clear that selecting it includes selecting the Company (contact always acts on behalf of Company).
This will ensure that all search results, including auto-completion of partner names and "group by" views will always be consistent and have all the company documents next to each other.
H) As a special case to the above, an extra module "account_report_company" will be added in the official 7.0 addons in order to add an explicit "Company" granularity in the Invoice list and Invoice Analysis (by adding a denormalized hidden field used for reporting only).
== 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 C, D & H, an appropriate invoicing partner should always be selected on all invoices, regardless of who what the contact to which the SO/PO was issued, and the Company level of granularity will be available in Invoice reporting.
There will be other 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)
And when a "Company" level of granularity is desired, part G of the solution ensures that the results are already grouped by Company (all related rows next to each other), making sure the data is easy to find and aggregate.
== 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 |
== 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 cannot be easily 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.
More details on the rationale: http://bit.ly/118HrZ0
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 Sales Orders issued to any contact from Agrolait will be found when searching for "Partner: Agrolait".
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.
G) The order of Partner records will be modified so that a Company always comes right before its contacts, in a way that matches the display labels. The display label of contacts will be changed to "Company, Contact" in order to make very clear that selecting it includes selecting the Company (contact always acts on behalf of Company).
This will ensure that all search results, including auto-completion of partner names and "group by" views will always be consistent and have all the company documents next to each other.
H) As a special case to the above, an extra module "account_report_company" will be added in the official 7.0 addons in order to add an explicit "Company" granularity in the Invoice list and Invoice Analysis (by adding a denormalized hidden field used for reporting only). We may add such a module for others objects where a group_by feature is required on commercial_id.
== 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 C, D & H, an appropriate invoicing partner should always be selected on all invoices, regardless of who what the contact to which the SO/PO was issued, and the Company level of granularity will be available in Invoice reporting.
There will be other 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)
And when a "Company" level of granularity is desired, part G of the solution ensures that the results are already grouped by Company (all related rows next to each other), making sure the data is easy to find and aggregate.
== 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 |
|
| 2013-04-24 11:38:10 |
Michael Karrer |
bug |
|
|
added subscriber Michael Karrer |
| 2013-04-30 12:18:38 |
Isaac Richter |
bug |
|
|
added subscriber Isaac Richter |
| 2013-05-21 14:02:44 |
David Diz |
bug |
|
|
added subscriber David Diz |
| 2013-10-04 10:01:32 |
Marie-Noelle Iltis |
bug |
|
|
added subscriber Marie-Noelle Iltis |
| 2024-04-18 07:43:08 |
tueddel |
bug |
|
|
added subscriber tueddel |
