Good... Well to work in verify all of them.... 2013/4/16 Fabien (Open ERP) > Nicolas, > > Just a note to say that these scenario "group_by" have been identified and > reported in the spreadsheet with all scenario (it's even in the description > of this bug): > http://bit.ly/10WPN5S > > We did scenario on a few objects (invoices, SO) but scenario 1..6 can, > of course, be duplicated for every object. (when something is identified > due to the principle, they are chances that it appears on all documents) > > We just didn't do it as the spreadsheet would become very big. What we > can do is to take a decision on which object we absolutly need to add a > fields.related > > Sent from my iPad > > On 16 Apr 2013, at 01:23, Nicolas JEUDY wrote: > > > Contract test: > > > > Group contract by parnter: > > > > -> > > > http://www.youtube.com/watch?v=DDZWQxFI3xE&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=5 > > > > How can I manage contract and contact on contract ? who will receive > > contract document ? where can I encode this ? Sorry but you need two > > fields, or can you say how I can manage this ? > > > > -- > > 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 ". > > - 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 > 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 ". > - 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: