openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Ray (and others)

thanks for investigating. Well that one from the CRM is just the top of the
iceberg really.
Well if you follow the default process as described, it will end up
invoicing the contact of the company it will have created (here "Joe" see
exact scenario un bug report).

But in many situations (if not all), you cannot invoice a contact, because
a contact doesn't carry any of the fiscal, accounting or financial data of
the company it belongs to, trivial examples are a contact isn't expected to
carry the fiscal position, neither is it supposed to carry payment
conditions or credit limit. More tricky scenario would be: for instance I
believe in the USA you should collect taxes according to where you sell.
Well what probably matters here is where the company you are selling is
located not where the contact you had on phone is. But this happens also
with intrastat sales across Europe. In countries such as Brazil, missing
the fiscal parameters in a sale order will even lead you to pick the wrong
VAT's and show wrong amounts.

Furthermore, invoicing a company contact can even be illegal in some
countries (basically you can put nothing from a contact on an invoice, it's
the case at least in Spain (after Ana Juaristi or Brazil where we have
electronic invoicing and everything specified from the company, not a
contact).


This is a quick patch, but SA saying it's expected to invoice a contact in
v7 is what I really call the top of the iceberg.


As a consequence, they started changing the code to at least associate the
accounting moves to the company and not to the contact. Well, as a
consequences, invoices and there moves and payments don't belong to the
same partner_id (and have no other key in common either). So it required
customization of the reconciliation process too, with some missing issues:
https://bugs.launchpad.net/openobject-addons/+bug/1151900
But chances are this will mess with overdue payments and cash management
prevision.
Here
https://www.evernote.com/shard/s158/sh/40828d76-d94a-4f44-bdb5-9c0336f55a52/fe43fe77c401e9f3bdf95982a4b0a878
Nhomar
is analysing "6.A.- Inconsistency, and bad approach, the partner_id in the
invoice MUST be the same of the account move line." Which is just a
consequence of letting picking a contact in invoices and then changing
partner_id in the accounting.


So after I reported that, in
https://bugs.launchpad.net/openobject-addons/+bug/1160365 OpenERP started
to propose us the following fix: copy data such as fiscal position from a
company to all its child contacts. Notice that Olivier Dony proposed that
solution one week after telling Ana Juaristi base_contact module was to be
ported to v7. I would be be very happy to understand how you can have a
contact belonging to two companies (base_contact) but still copy fiscal
data from its parent company to it (so which one and what you do in the
other cases?). When I read such plans, sorry, it raises suspicion if they
even know what they are doing...
And the proposed solution goes as far as duplicating accounting properties
from the properties table to the contact. Hum data duplication, record
duplications, what a nice solution...

But mostly, the proposed fix they planned totally fails to address many
issues that are minimized instead:

1) Once your business documents like invoices can have partner_id pointing
to any contact of a company, how accurate are your financial report grouped
by supplier or by customer? Same things with sale an purchase previsions.
Which B2B company isn't interested knowing purchases by supplier? in
comparing prices between supplier (and not facing contact ids artifacts
inside)?

2) *The problem isn't just in invoices. It's everywhere!* In many place in
OpenERP, a document has a partner_i field (which can now be a contact) and
propose to select a many2one record which belongs to the same partner_id.

Consider that obvious case: you deal with Return Material Authorization
such as with modules like that one: https://launchpad.net/openerp-rma you
create some picking related to some customer. Later you want to relate that
picking to a CRM claim. by default the domain will be taking the partner_id
found in the picking form and filtering crm.case based on it. What about
all the other claims from the same partner but where partner_id has been
set to a contact instead of it? Well you will just miss them as if there
were none. What if you put a contact on the picking instead of the company
instead? Even harder to relate the right business documents despite they
belong to the same company.
What if the code automatically creates a crm.claim if it finds none for the
provided partner_id ?
There are such cases such may be more subtle all over the place in the in
the official addons...

And no, these pointers, you cannot duplicate them the contacts... A record
that is linked as: partner one2many recods such as a CRM claim cannot point
to the other contact ids of that partner because it should do that with
only one foreign key (a many2one).

This is no paranoia, for instance a partner can also have many banks. Well
currently they will be matched only against the company. What happens when
partner_id is a contact now?

So basically OpenERP SA is telling us "fear not". If such cases
are identified (they exist right today), we will fix them by changing the
code. from my 5 years of OpenERP experience, a regression takes on average
3 months to be fixed and is fixed in the common branch only 50% of the
times. So even if that's only 50 hidden functional regressions on the core
related to that choice to allow contacts everywhere in partner_id, *yes I
do fear, and not just a little*. But it's not just about the core, it's
also about all the hundreds of community module that have never been
designed so that partner_id can randomly be a company or any of its contact.

An other case we identified just yesterday is access rules. Imagine you say
a salesman can only see and write the documents related partners of its
portfolio (so hard to imagine really?). Well, are you sure you will
properly define what is the portfolio for every companies and all these
contacts, even these added later? Will you not forget to give access rights
to the contact parents now that data will be supposed to be duplicated
between a company and its children?

Are we really making things simpler by doing that???

Now consider instead (what I called option B):
Why the hell can we not say: everywhere we have a partner_id field. The
OpenERP ORM adds a contact_id field automatically. In any form were there
is a partner_id field, the fields_view_get method automatically hides
partner_id an show contact_id with all the same labels and view modifiers
taken from partner_id.
The user cannot see any difference.

Now when contact_id is changed, an onchange event automatically sets
partner_id with the related company or the same id in case of a physical
person partner. Then partner_id is exactly what the code as always been
expecting. Then records of same and different nature that belong to the
same company all have the same partner_id again. Reporting just works again
exactly as expected. And if we want to say "sorry SAP, we are social and
flashy now", you still have that contact_id you can send the mail to or
search with.

Isn't that a much less risky, much less invasive solution than the "fear
not" from the ostrich policy?
An early prototype of such a thing is available for tests here:
https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27
of course, that would have been cleaner if OpenERP SA did it in the core
instead of a monkey patch. And if my concerns had met more understanding,
probably even the naming choices would have been more tolerant.


Now if you paid attention to the reasoning:
you will probably agree that an ERP cannot live with business document
having no key pointing to their related commercial/legal entities (because
no grouping, no matching). Then we need that key. And yes, we ALSO need a
key to the contact that is something much more random.
*It means we need two keys, not just one.*
*So do we really want changing all the semantic of partner_id and fixing
all the code everywhere to make sure it continues to work when partner_id
is suddenly a contact? And in the future what? to avoid dying OpenERP would
then add a new "commercial_entity_id" key pointing again to the
commercial/legal entity deterministically?*
*isn't it smarter to add that contact_id key right now just for contact
(anything) and leave partner_id untouched with a code that is battle tested
to just work like that?*
*
*
Also, forbidding contacts just on some documents instead of systematically
wouldn't seem a really good idea. Because every time two business documents
belonging to the same company don't have the same partner_id, then we are
making the code and reporting brittle for nothing. Instead it's just better
to ensure they all have the same partner_id always, and that most of
documents can have an additional contact_id, even if it's not used. At
least the user still see only one field to field, so
no usability difference with today.


Sorry, but the direction taken by OpenERP SA on that is beyond any logic
for me and quite a few folks. And yes, that's an important topic, a
critical one even.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com







On Fri, Apr 5, 2013 at 2:28 PM, Ray Carnes <rcarnes@xxxxxxxxxxxxxxxxxxx>wrote:

> Hello Gustavo and Raphael,
>
>
>
> I just spent some time looking at this – clearly there is something I
> don’t understand.  I have posted my experience at
> https://bugs.launchpad.net/openobject-addons/+bug/1155679
>
>
>
> I get the right partner_id associated with the sale and invoice and no
> accounting problems.    What am I missing?
>
>
> Can I impose on you to outline a reproducible case that I can follow?  We
> have many customers on OPW and could have each of them log the same bug if
> I could understand it and reproduce it.
>
>
> Ray.
>
>
>
> *From:* openerp-community-bounces+rcarnes=
> ursainfosystems.com@xxxxxxxxxxxxxxxxxxx [mailto:
> openerp-community-bounces+rcarnes=ursainfosystems.com@xxxxxxxxxxxxxxxxxxx]
> *On Behalf Of *Gustavo Adrian Marino
> *Sent:* Tuesday, March 26, 2013 11:35 AM
> *To:* Raphael Valyi
> *Cc:* openerp-community
> *Subject:* Re: [Openerp-community] IMPORTANT: OpenERP v7 and company
> contacts management
>
>
>
> Raphael:
>
> I totally agree with your position. The position of OpenERP will lead us
> to uncountable problems without any benefit.
>
>
>
> Let me add that there are many countries that do not allow a contact as
> reference of a commercial document. In all cases a legal entity is required
> (a company or a documented person, someone with a legal ID). In that sense,
> a contact is not a party. It is no secondary issue, it is in fact the main
> an only difference between partners and contacts!
>
>
>
> I strongly believe the proposal of Olivier is no more than whishfull
> thinking. He is underestimating the consequences of the faulty proposed
> strategy and trying to hide the foresable problems just not to accept that
> OpenERP should fix the problem in the current version. It is clear that
> this is more a dogmatic issue than an attempt to look for the best for the
> comunity.
>
>
>
> I totally agree with you in the fact that the faulty process in testing
> before v7.0 release and the lack of discusing about philosophy of
> res.partner's changes early enough is probably the root of the problem.
> Nevertheless, now it is time to solve the issue, even if we have to change
> some rules in order not to damage the commercial success of OpenERP.
>
>
>
> It is not a minor issue. That's the way rules evolve, when you change them
> once you realize they are no longer valid!
>
>
>
> I encourage you not to abandon your effort to convince OpenERP which is
> the right thing to do.
>
>
>
> My 2 cents.
>
> Gustavo Marino
>
>
>
> 2013/3/26 Raphael Valyi <rvalyi@xxxxxxxxx>
>
> Hello community,
>
>
>
> I think this threads totally deserves your attention:
>
> https://bugs.launchpad.net/openobject-addons/+bug/1160365
>
>
>
> Basically in OpenERP v7, business documents such as invoices can now have
> their partner_id field pointing to a company contact res.partner record
> while in previous versions of OpenERP it had to point to company partner or
> to a physical person partner. Note that this is note about debating moving
> the res.partner.address into the same res.partner table which I find a good
> move that is making us closer to the Party industry standard pattern. This
> is more about how we are allowed to use these records in OpenERP v7.
>
>
>
> I claim the current codebase doesn't handle the case where partner_id is a
> company contact and many bug are related to that (many not reported one by
> one yet). This has just been partially acknowledged by OpenERP SA in the
> bug tracker, but IMHO the problem is deeper than what is acknowledged (I
> explained why in the tracker).
>
>
>
> Basically there are two ways of fixing this:
>
>
>
> A)
>
> making everything required to have contacts suddenly a be "first class
> business documents citizen". Me and several people claim that this
> "everything required" actually involves many many things that may take
> years to get right again if you accept to look deeply at the issue and that
> it's not reasonable to go this way withing the v7 "stable" release.
>
> But this is this way that OpenERP SA planed to go and is apparently still
> planing to go...
>
>
>
> B)
>
> there would be an other way that would be adding contact_id fields on
> business documents (sale/purchase orders, invoices...) and putting an
> on_change to set the existing partner_id field with the same id in case of
> a physical person or the related parent company in case of a company
> contact. That would preserve the existing partner_id semantic within the
> core and community codebase which took nearly a decade to consolidate the
> way it was on 6.1, avoid taking useless risks, allow fine grained by
> contact analysis while not breaking the by company reporting.
>
> I think this is about a 50 lines patch at most. No risk taken... Why on
> earth try to go with A)?
>
>
>
> So I suggest experts carefully read this thread and give their thoughts
> when they understand the problem:
>
> https://bugs.launchpad.net/openobject-addons/+bug/1160365
>
>
>
> Thank you for your attention. Meanwhile, if you are using v7, it works
> quite well for B2C and can work for B2B provided you don't put company
> contacts in partner_id fields of business documents if you are interested
> in accounting, fiscal or financial correctness.
>
>
>
> In my opinion, the problem isn't that much the 50 lines of patch of
> solution B) that everyone could put in place right now, the problem is
> instead the hundreds of lines of code I forsee if we keep trying to do A)
> that may lead to slower and more complex code with no functional benefit
> IMHO and making people not applying the B) patch facing regressions
> possibly for years.
>
> So let's say that's diverging way of fixing the problem, quite diverging
> ways and we need this to keep working as contact management is an important
> feature that was supposed to work in the core.
>
>
>
> Please comment on the bug tracker (not here) if you want to comment the
> proposed solutions.
>
>
>
>
>
> Best regards.
>
>
>
> --
>
> Raphaël Valyi
>
> Founder and consultant
>
> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>
> +55 21 2516 2954
>
> www.akretion.com
>
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
>
> --
>
> Gustavo Adrian Marino
>
> Mobile: +54 911 5498 2515
>
> Email: gamarino@xxxxxxxxx
>
> Skype: gustavo.adrian.marino
>
>
>
>
>