On Thu, Mar 28, 2013 at 11:40 AM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> On 03/28/2013 07:01 AM, Raphaël Valyi - http://www.akretion.com wrote:
>  > I started coding a patch adding a contact_id at least in the account
>  > module, but not finished yet sorry.
>
> In your solution, have you decided on a way to make the contact info
> available
> in all search views, reports, etc?


Yes indeed, we should still patch a few things absolutely! You should have
thought to this before enabling selecting contacts everywhere in the wild
in v7 codebase, instead refusing now to fix things beyond the surface just
because it looks as a change now.

BUT:

   1. as for manual search (not existing code logic), searching the name of
   the company will also propose the contacts. Whereas if your partner_id is a
   contact, search the name of a contact doesn't bring the company. So I
   consider it much better partner_id to be the company.
   2. eventually you could make selecting a just contact an opt-in thing:
   business object by business object or using some opt-in context key you
   could reuse in the res.partner search
   3. rationale: in 6.1 and before you could already not select a contact
   for many documents, so if you cannot select a contact in partner_id at
   least it's not a regression: it's just may be the absence of a new feature.
   I claim regressions like that should be avoided at all costs before trying
   to enable new features. A mixin as Holger Brunn suggested would be the
   right abstraction to encaspulate that possible type generalization that
   IMHO should be done case by case after ensuring upfront that the code can
   accept it and that loosing the "commercial entity" key isn't a big deal
   (generally it is) instead of done in the wild in the middle of a claimed
   stable release.



> Because if the contact automatically carries
> the company info, the opposite is not true. So if your strategy is to
> force the
> `partner_id` field to contain the "commercial party" of the contact, and
> add a
> second `contact_id` field to store the contact, the rest of the system will
> still be using `partner_id`. So the contact chosen by the user will
> disappear
> everywhere else.


This sounds all convincing on the surface BUT:

   1. we ALREADY have this problem after that "full contact v7 innovation".
   Because at least you forced payments and account moves to be related to the
   commercial entity instead of the contact (so they already mismatch the
   contact who lead to them).
   2. and more than that: as you see, in many countries, invoicing a
   contact is illegal (Spain Brazil, but I guess there is a gazillon of them).
   So we will also already have a mismatch between contacts and invoice
   partner_id (without any built'in way to carry the invoice contact anymore
   by the way).



> Won't that be rather confusing for the user and make the
>

Sure it's bringing some confusion. But I claim you should have thought to
this before enabling contacts everywhere, not now 100 days after the
release because we, the bad guys, are daring to comply about B2B been
broken in the wild.
I claim this is much better to at least preserve the "commercial entity"
unicity on partner_id in all the mission critical ERP scope: sales,
purchase, account, stock, while this is perfectly OK if you experiments
with contacts in the messaging or lunch modules.


> contact_id a useless field, defeating the whole purpose of the 7.0 model?
>

Not exactly.
Now, thanks to the v7 approximation to the Party Pattern (may be not on
purpose but thanks god you got that right), we can now add a unique
contact_id field in business documents that can point indifferently to a
coommercial entity or a contact of it (and properly set the related
partner_id based on it).
If contacts and partners had no common super type as in 6.1 and before, you
could not do that.
So I consider this is indeed a huge improvement for the ERP simplification
for the masses (the SaaS thing to fire up investor dreams and raise money
thing etc.. this can all be made compatible fortunately)
BUT I consider you are doing it wrong by suddenly wanting to allow contacts
in partner_id without extreme upfront care and loosing the "commercial
entity" SQL key.

Accepting contacts is what I would call "type generalization".
Suppose you wrote a nice maths lib that is parsing expressions offering
many maths functions.
Now, in the new version you say "hey both real numbers and imaginary
numbers are numbers, so I will now allow to pass imaginary numbers
everywhere without any upfront care". This is exactly how I see this
change: no upfront care to ensure it work AND we are also loosing that
precious SQL "commercial entity" key (partner_id), for no usability benefit
at all.


>
>
>  > Meanwhile, here are some more quick examples of things that won't work
> > as claimed if you keep enabling contacts in partner_id on business
> > documents:
> >
> > Sale module: sale/sale_view.xml:                            <field
> > name="project_id" context="{'partner_id':partner_id,
> > 'default_pricelist_id':pricelist_id, 'default_name':name, 'default_type':
> > 'contract'}" groups="sale.group_analytic_accounting"
> >
> > So basically this context will automatically create the analytic account
> > (yah project_id is an analytic account ;-) according to the partner_id of
> > the sale order. That is, you will now create as many analytic accounts as
> > contacts for the same customer on v7. Very smart...
>
> This looks like a bug that already existed in previous versions of
> OpenERP: the
> context should probably be corrected to: `'default_partner_id':
> partner_invoice_id`, so the analytic account is properly created for the
> invoicing partner: either the one you manually choose or the one
> automatically
> chosen by the system based on the partner `type`, as described in Part C.
>

All right, this is because Sale Order already has a built'in double
partner_id and contact_id keys system thanks to the
invoicing_partner_address key. But I assume you understood the point: many
business documents don't have this double key in v7: invoices, purchase
orders, pickings... So no in many places in the core and in the community
module without that "commercial entity" key which used to be partner_id,
such bugs won't be easily fixable at all.
And again if it's for re-adding a key, let's add contact_id, don't attempt
to swap all the variables semantic for nothing.

>
>
> > purchase/stock_view.xml:                    <field name="purchase_id"
> > domain="[('invoice_method','=','picking')]"
> >
> context="{'search_default_partner_id':partner_id,'default_partner_id':partner_id,
> > 'default_invoice_method':'picking'}"/>
> >
> > Here it allows to create an incoming shipment and link it to some
> existing
> > purchase order with some default filtering. But now, with v7 contact
> > "innovation", you may totally miss purchase orders related to the right
> > supplier but related to a different contact. You may also fail to look at
> > the parent_id if you selected a contact in the picking instead...
>
> That seems the expected behavior when you manually create an incoming
> shipment
> and choose a supplier contact as the Supplier. First, the system will
> allow you
> to link it to a PO from any partner because the domain does not restrict
> it -
> and auto-completion will work.


Sure but is that kind of awkwardness a usability improvement? Aren't we
really reducing here the amount of training and support required for people
to use OpenERP?


> Secondly: if you open the full search view or
> try to create a PO on-the-fly the system will simply copy the selected
> Supplier
> in the Supplier field, as expected. You can change it if you want but if
> you
> selected a contact as Supplier it's probably because you meant it - a
> question
> of granularity.
>

No, I disagree.
If you choose the a given contact of the supplier, it's not just because
you want it, it's because you need it.
You need to keep a pointer to the right contact at your supplier for this
PO and you have no other choice than using partner_id for this in v7.


> And as a reminder, the system is taking care of creating the appropriate
> incoming shipments when you create a purchase order, so these cases should
> be
> exceptions.
>

It really depends on the business you do. Here in Brasil one customer
working as a supplier for Wolkswagen use to buy many things. As we have
electronic invoices here, so instead of manually checking the dozens of
items one by one against the picking generated by the PO, we import the
electronic file of the delivery to generate the incoming shipment and match
it against the PO.
Such a process could be done manually or using other electronic formats
(EDI etc..). But it happens and it was just a random example among so many.

In any case, this is exactly what I want to avoid: we don't we we go
blindly for what I call a broken modeling and then spend literally years to
debate around bugs and litigious cases.
Our 5 years OpenERP experience is that getting a bug fixed in OpenERP
official codebase takes around 3 months on average and that only 50% of the
bugs we report get fixed, even when community provides a patch, this even
with an Enterprise contract as we are kind enough to sell to most of our
customers (read http://people.via.ecp.fr/~alexis/openerp/ for details) And
no sorry to say it, there have been no improvement at all recently.
So we are really not happy to foresee dozens of regressions (something that
you and you customer takes for granted but doesn't work anymore) related to
that way of "fixing things".



> It's really a question of granularity: in 7.0 a contact is now considered a
> valid representative entity for her company. However there's no reason to
> believe that users will be forced to use contacts when they don't want to.
>

Our 5 years integration experience also convinced us that you can not just
rely on users to just do the right thing to warranty data integrity. There
are always bad users doing bad things and simplifying OpenERP certainly
means putting constraints to avoid users spoil the data integrity. Sorry,
our experience is that we have to forbid users to create a new location
with the same name instead of selecting an existing one, we have to forbid
them to create a new city in the address instead of selecting the fucking
city.
We aren't an editor. An editor can always say "hey you damned user did a
mistake it's your fault, you had a way to achieve it", no, for us
integrators, thigs have to just work, we live in the real world.
So ERP integration is Murphy law at work and we should deal with it ;-)


> If I am talking to Sylvie Lelitre from Agrolait on the phone and I create
> a SO
> for her, it is natural that I will choose her as Customer. And the
> Invoicing
> Partner will be automatically set to "Agrolait" because Sylvie is a contact
> with type "contact", not "invoicing" (part C of the solution). So the
> invoice
> will be created for "Agrolait". And I will be interested to see "Sylvie
> Lelitre
> (Agrolait)" as a first-class entry in the Sales Orders reporting, while the
> accounting department will only care about seeing "Agrolait" as a whole in
> the
> Invoice Analysis report.
> On the other hand if I always receive generic orders for "Agrolait", I will
> naturally use "Agrolait" as the SO Customer, and will only care about
> seeing
> only "Agrolait" in the reporting everywhere.
>

As I always told, for the sale module (the SO), we nearly don't have the
problem. The reason we don't have this problem is exactly because a sale
order (SO) has the two keys: partner_id and contact_id!
They are in fact called here partner_id (contact) AND partner_invoice_id
(the commercial entity).

Instead of discrediting the solution of having two keys, this is in fact
proving exactly the contrary: we have no problem when (and only when) we
have two keys: the contact AND the commercial entity.

So again, I still desperately advocate for keeping our pointer to the
"commercial entity" untouched in business documents as the partner_id key
(don't forget SQL based reporting too) AND add a contact_id key.


best regards.