Hello Fabien.

Reading better your comments, I think here we have Just one more issue.


2013/4/9 Fabien (Open ERP) <email address hidden>

> On 04/09/2013 01:19 AM, Raphaël Valyi - http://www.akretion.com wrote:
> > 1) as Joël said, we need two keys because we absolutely need to be
> > able to consolidate business documents by companies (not just by
> > contacts). I also want to be able to compare my purchase prices
> > by supplier, not by supplier contact (unless I really want to)...
>
> That's probably the biggest misunderstanding and the reason why we are
> not aligned with the best solution.
>
> If you read carefully the proposition of Olivier:
>
>   - We do not plan to allow invoicing to contacts (in the meaning of
>     the person who purchased, or a contact person)
>   - We allow invoicing ONLY on "Valid Invoicing Entities"
>
> Be sure you understood the two lines above as it's the biggest
> misunderstanding in all our discussions.
>
> That's what Olivier calls the valid level of granularity for invoicing
> operations.
>
>
> With the default configuration:
>
>   - The "Valid Invoicing Entity" is the company itself (Camptocamp),
>     not the person (Joël, Camptocamp)
>   - So, All invoices will be entitled to Camptocamp, not Joël of
>     Camptocamp in the default configuration. Whether it comes from
>     a sale order or a manual invoice, the behaviour must be the same.
>     Invoices are only entitled to Camptocamp by default.
>
> The great improvement with the v7 approach is that we are also able to
> manage hierarchies of partners. (we had hierarchies in v6.1, but it was
> not used anywhere, so not useful at all)
>
> So, if you want to define hierarchies of companies:
>
>   - Camptocamp Group             [is company]
>       - Camptocamp Switzerland   [is company]
>           - Joël
>       - Camptocamp France        [is company]
>           - Marc
>           - Cécile, Accounting Department
>
> With Olivier's proposition, by default, OpenERP allows invcoing to C2C
> Group, C2C Switzerland, C2C France. Not to the 3 others contacts. This
> is the expected behaviour.
>
>
> But, if the user wants (only if he explicitly configure OpenERP to allow
> it), he can also say that "Accounting Department" is a "Valid Invoicing
> Entity" by setting it's address type to 'Invoicing'. (which is not the
> default).
>

Can you explain better this configuration please, with some tests?, I cant
see them explicitally in any place.

>
> In this case, we think that the "Valid Invoicing Entity" is the right
> level of granularity for most reporting.
>
> Please note also that there is usually only one "Valid Invoicing Entity"
> per company. So all invoices to Camptocamp France will be entitled to
> "Camptocamp France, Accounting Departement".
>

Well, If you are in countries with Strong Fiscal Rules, this is not the
ususally, this is just the common ground Just in little companies, with
middle business models B2B the history is different.

>
> You will not have problems of several lines in your group_by reports,
> unless you manually decide to have two "Valid Invoicing Entities" for
> the same company AND you create a manual invoice for the other. (which
> is a rare situation and, if you do so, you probably expect this level of
> granularity in your invoices and invoice reports)
>
>
>
I put some comments regarding this in the merge proposal, can you tell us
in this terms, because, i continue having the same reporting __group_by__
issues, or are you telling you __will__ include this considerations in the
core... exactly what you mean please.


>
> Several notes to answer others confusions:
>
>   - We do agree that adding a partner_id field on the object for the
>     legal entity (not on the view) linking to the main company is a
>     good improvement. It's even in our proposition. (read Olivier's
>     proposal)
>

I am sorry here, all Legal Documents, must be hard linked, because the
traceability will be lost if you dont do in this way.

>
>   - But for the future version because: according to my explanation
>     above, the "Valid Invoicing Entity" is the right level of
>     granularity AND we prefer to respect our strict policies for stable
>     versions (do not break the schema) --> and this can be easily done
>     by another module if you think it's mandatory.
>

I think it must be done now, because, we will be having some problems
without this field,
and when i say __some__ i think we are talking about a lot of issues, IMHO
we should brake this rule this time, for 2 reasons.

1.- Technically who support this is you, and pot this feature in an extra
module will become a big problem in terms of include all the variants,
remember this is not a matter of data model, it is a matter of Business
process too!

2.- If you domain the migration scripts by your own, our customers will
feel mor confortable if you do this in your OPW model, Now, the start up of
SorrySAP campaign you know start a big step in big implementations, and I
continue thinking the second approach is really difficult to avoid, if you
left by our own, it will become in a lot of hour in our side.

3.- It is not a misunderstanding other point bellow.

>
>   - v7 improves the partner model because, compared to v6.1, it
>     perfectly handles all hierarchies. (search on C2C, you get all
>     contacts (child_of), clean definition of Invoicing Address)
>
>   - Olivier's proposition works with base_contact
>
>
Ok Good, but I think with base_contact we need to review all approach too!,
because the Business Logic must be consistent.


>   - There are still bugs in Olivier's implementation. (according to
>     Joël, I did not tested) Olivier is on holliday today so I guess he
>     tried to deliver something quickly yesterday, before leaving.
>
>
I see and put my comments, can you verify them.


> Hope it clarifies a bit,
>
>
Thanks for your answers, i expect, it can be better explained with more
business cases explicitally with documents and some tests, now my fear is
going down, but is in Level Orange yet.

IMHO without change the data schema this time will be so difficult and you
are externalizing the responsability in us (we must give the feature to our
customers always)



>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>
> --
> 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