On Tue, Mar 26, 2013 at 12:50 PM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> On 03/26/2013 04:03 PM, Raphaël Valyi - http://www.akretion.com wrote:
> > So are you YES or NO actually going to add new contact_id fields on
> > business documents? (like we were referring as the B) solution in the
> > original bug) ?
>
> No, the proposed solution doesn't include that. The idea of unifying the
> partner structure in 7.0 is that a contact is a first-class partner. It can
> sometimes delegate some of its properties to a parent entity (or copy
> them),
> but for most purposes it can be used directly.
>

The refactor of v7 is nearly good. Indeed it's interesting to have a
"Party" super type now.
But because you now have contacts and companies being both sub-types of the
res.partner or "Party" super type, it doesn't mean you
can exchange them anywhere as if they were the same things.
As I said, I think it's like some python functions can work with numbers,
that is both integer or floats. But some functions require an integer and
not a float.
I claim today OpenERP business document codebase only work if partner_id is
a company or a physical person, but not if it's just a contact. I think
this is an abuse to try to quickly opt for having to change an undefined
amount of code to try to adapt the code to make it work with that new
contact semantic in the middle of what was announced as a stable release
while nothing has been anticipated here.

Now, yes, some non business documents can now transparently use a contact
or a company. For instance it's cool you can send a message to a company or
to a contact in a transparent way. Some views are simpler too. All this is
positive.
But IMHO without anticipation and absolute care, type generalization should
be the exception rather than the rule! But here it rather seems that
debugging these regressions is rather an afterthought after by luck the
community spotted them in your LTS 3 months after official release.


> > You says "A) Let the "commercial party" for a partner be the person or
> > company that is used as reference for all invoicing/accounting matters"
> Is
> > that supposed to be the existing partner_id field or a new field (stored
> or
> > not) ?
>
> It's not a stored field, it's a definition. It could be a new stored field
> in
> the future, as I mentioned in the "Further refinements" section, but
> that's not
> planned for 7.0.
>

That would be interesting to have it stored, wouldn't it?
For reporting, for making SQL base reports by company work again...

But wait a minute: wouldn't that be stupid to add it as a NEW stored field
instead of using that partner_id with the same semantic it always had and
the low level of bugs it took nearly a decade of tireless community
debugging to achieve?
If it's for getting reporting right, isn't it smarter then to add new
contact_id field instead to store the contact and keep partner_id untouched
with no risk taken?

>
>
> > How that Olivier?
> > Look at the following piece of code in the account/account_invoice.py
> file
> > (there are dozens of such cases if not hundreds considering also the
> sale,
> > purchase, stock and main community modules):
> >
> > pay_pro_id =
> >
> property_obj.search(cr,uid,[('name','=','property_account_payable'),('res_id','=','res.partner,'
> > +str(partner_id)+''),('company_id','=',company_id)])
>
> This (rather ugly) code will work just fine with the proposed solution
> AFAICS.
> If the account_payable property was explicitly set on the parent company,
> it
> will be copied to its contacts (that's part B), so this code will find it.
> If
> not, it will fall back to the default for the property in both cases.
>

So you would duplicate these properties from the parent to the contact?
Should we really go for data duplication? Isn't adding contact_id fields a
lot more saner than going duplication?

And very well, here the code is looking for one of the accounting
properties you spotted after community yield at it. But what if the code
does say a sale.order or a project.project search based on the partner_id?

Will you properly copy relational fields too? How will you do that one we
have res.partner one2many other.entity ? How will a record of other.entity
point both on the parent company record and on all the contacts with a
single foreign key? How please?

How can you always warranty us you will always have coherent results now
that partner_id can one time be the company and another time be  just a
contact?
But more importantly: did you really consider adding contact_id fields o
business documents? Is it really worth taking all these risks blindly sorry
to day it? For what benefit?


>
> > You can make a contact inherit whatever you want form its parent
> company: if
> > partner_id is suddenly allowed to be just the id of the contact record,
> that
> > property search will fail to find the property attached to the company
> > record one. But this is just a quick example: any search/domain involving
> > partner_id will not work out of the box at all and lead to regressions
> very
> > hard to spot.
>
> We think it will work in most cases, and we will be searching for possible
> issues before finalizing the solution. If some can be identified we'll
> have to
> examine the options.
>

Olivier, the problem is that OpenERP v7 is already broken today if you set
a contact in the partner_id of a business document.
We aren't statuting for v9 or v12...
We need a simple solution that is guaranteed to work quickly with a
predicable behavior.

I would have no problem if you put in v9 roadmap to do whatever required to
have a "contact to be a 1st class citizen" as you say and if you can prove
us it work BEFORE doing the release.
But I cannot afford putting faith in doing that as an afterthought telling
us more or less "guys subscribe your OPW's if there will be bugs we will
fix them one by ones" while refusing to anticipate there will be dozens or
hundreds of regressions while IMHO you get no benefit at all over adding
contact_id fields.

>
>
> > Also, I would like to insist that reading accounting/financial/fiscal
> data
> > isn't limited to the account module. For instance, in many situations
> > (specially sales bewteen sovereign states such as international commerce
> or
> > inside federal countries), you may need to read fiscal data right from
> the
> > sale order to find out the right taxes to display. So for instance if
> > partner_id can be a contact in a sale order or a purchase order, well all
> > the fiscal-rule framework (a pillar for our localization but also used in
> > international e-commerce) is broken
> > https://launchpad.net/openerp-fiscal-rules
>
> By default all invoicing/accounting-related data will be copied/synced by
> the
> res.partner model itself; the account module will simply extend the list of
> fields to sync. If extra partner fields are added by other modules they can
> presumably extend the list of fields to sync, just like account would do
> it.
>
> Could you explain with a specific example what would not work based on the
> proposed solution?
>

Well if you want concrete examples here. It's a quick and totally random
code scan:

1) account_invoice.py line 343 node.set('domain',
"[('partner_id.ref_companies', 'in', [company_id])]")  will ref_companies
be properly be copied on contact record?

You'll copy it, right?
But wait ref_companies is defined this way: 'ref_companies':
fields.one2many('res.company', 'partner_id'..
that is a ref_companies item can point only to ONE partner_id.
How in general do you claim to ensure such one2many items pointing to a
company partner_id will also be pointing to all of its contacts against
which the search might be performed?

2) account_invoice.py line 360
                elif context['type'] == 'out_refund':
                    node.set('domain', "[('partner_id', '=', partner_id)]")
How will the matching work if a refund can be with the company and the
invoice with a contact?

3) account/report/account_report.py line 191
        cr.execute("""create or replace view report_invoice_created as (
            select
               inv.id as id, inv.name as name, inv.type as type,
               inv.number as number, inv.partner_id as partner_id,
So you will group sometimes by partner and sometimes by contacts?
Nice! wait for accountant feedback about that...

4) account_followup/account_followup.py

_get_followup_overdue_query line 370: not a chance that overdue SQL query
to compute overdue by partner any good anymore...

5) report intrastat: inv_address.country_id is used in the query line 115.
Will you copy country_id too on the contact? How will you determine the
exact list of fields to copy or not. How will that deal with fields added
by modules?

6) purchase/purchase.py check_supplier_info line 1023

            if user.company_id and user.company_id.partner_id:
                if partner.id == user.company_id.partner_id.id:
                    raise osv.except_osv(_('Configuration Error!'), _('The
product "%s" has been defined with your company as reseller which seems to
be a configuration error!' % procurement.product_id.name))

How will the partner.id == user.company_id.partner_id.id matching work for
any contact of the partner company?


Really Olivier, the list is just way too long. And it's the same in all
community modules, localizations...
Yesterday with Luc Maurer we were talking about it and both estimate that
it would literally talke YEARS to find all related regressions and get them
fixed in the core.


But mostly?
Why?

Why would you play with fire this way? What is the benefit? Please what is
the benefit of doing it this way?

Did you seriously considered adding contact_id fields on business documents
+ put an on_change to properly set the existing partner_id with the proper
commercial entity as OpenERP is known to work with after nearly a decade of
debugging it?

OK, it forces to change the schema. Well the problem is that the release
cycle was bad: no schedule, no RC releases, not enough confidence from the
community. As a results things are tested lately and regressions found
lately. So in fact regressions are here today and there is no absolutely
clean solution to it. The problem isn't the no schema change policy the
problem is all the engineering cycle before. So I say between 2 non perfect
solutions, take the simplest and safest one.


Were my points clear? Could you please detail the advantages of your
solutions vs adding contact_id fields and setting partner_id right?


Regards.