openerp-community team mailing list archive

[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