The document discusses two proposed solutions for managing contacts and companies in OpenERP v7. The "contact_id solution" proposed by Raphaël Valyi uses separate contact_id and partner_id fields to distinguish between contacts and companies. The alternative solution proposed by OpenERP SA uses partner_id for both and adds a commercial_entity_id field. The document argues the contact_id solution is cleaner and avoids issues caused by semantically changing fields, and that adopting it would help unify the ecosystem rather than fragment it. It also aims to address several "myths" raised against the contact_id solution.

1. OpenERP v7 contacts
management. Why the
"contact_id solution" is the
best one
by Raphaël Valyi - Akretion.com
v0.9.0

2. backed unanimously by
all the OpenERP experts
bug https://bugs.launchpad.net/openobject-
addons/+bug/1160365 gathered more than 210 posts in a
month from the most experienced OpenERP implementers
around the world, including many prominent partners.
● all said they want the contact_id + partner_id solution
● none defended OpenERP SA solution to use just one
key
● none prefered OpenERP SA idea to finally leave
partner_id for contacts but add a new field
commercial_entity_id that points to the legal entity
again, because it's a semantic permutation of all
what have been done on OpenERP the last 8 years...

3. which alternatives are we
talking about?
remember: problem technical description: http://www.slideshare.
net/RaphalValyi/open-erp-v7-contacts-issue?
utm_source=ss&utm_medium=upload&utm_campaign=quick-view
our "contact_id" solution:
https://code.launchpad.net/~openerp-community/openobject-server/contact-id-
solution-for-v7-contact-management/+merge/159316
https://code.launchpad.net/~openerp-community/openobject-addons/contact-id-
solution-for-v7-contact-management/+merge/159320
OpenERP SA's solution:
https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-
company-handling/+merge/157577
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-
company-handling/+merge/157576

4. Myth 1: "Raphaël's branch is
buggy"
one may question why OpenERP SA ignored community
and made a mean caricature of a POC that should have
been their job to have investigated once everybody said it
was the right data model to fix the problem.
But anyway, now we are 100% green on all the tests
they tried to prove us we were wrong:
https://docs.google.com/spreadsheet/ccc?
key=0AhmEftWbRs4sdHJqY2lfeU1HR3hwQm85QS1hQTV
Mcnc#gid=0
That is more green than them on their own test suite...
But we will have ours...

5. seeing is believing
scenario 1 - all green:
http://www.youtube.com/watch?
v=TjouFdPnn2Y&list=PLDo85hjMzeJPT2JzEt3wUSLWHLT
o4SQIg&index=1
scenario 2 - all green:
http://www.youtube.com/watch?v=B4-JNlwxZ-
w&list=PLDo85hjMzeJPT2JzEt3wUSLWHLTo4SQIg
We are already green on the other scenarii, videos are
coming to prove it for these who would like to spread FUD.

6. Myth 2: "Raphael's branch is
more invasive"
-> Our fix has 10x less code! than theirs just
to fix their own test suite:
https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576
https://code.launchpad.net/~openerp-community/openobject-server/contact-id-solution-for-v7-contact-
management/+merge/159316
https://code.launchpad.net/~openerp-community/openobject-addons/contact-id-solution-for-v7-contact-
management/+merge/159320
number lines
of patch
partner_id +
commercial_entity_id
contact_id +
partner_id
server (+441/-93) 3 files modified +148/-0) 2 files
modified
addons (+335/-38) 26 files modified 33/-29) 17 files
modified

7. Myth 3: "OpenERP innovated in
version 7.0, contact_id is refusing the
innovation"
● we also think moving persons/contact and company in
the same table was great
● the thing is despite contact could be anything we never
believed an ERP could work without also maintaining a
key to the related legal entity of a business document
● we also have only one contact field in the user
interface
● user can see NO DIFFERENCE with OpenERP SA in
term of record edition usability
Seeing is believing:
http://www.youtube.com/watch?
v=TjouFdPnn2Y&list=PLDo85hjMzeJPT2JzEt3wUSLWHLT
o4SQIg&index=1

8. Myth 4: they "tested it for 12 months
OpenERP has been made for mixing
persons and companies in a single key"
● probably the social features developed over the last
months were done for partner_id being a contact. Well
we don't touch them an pass them contact_id at the few
required spots to ensure social things work the same.
● But in any case, one thing is these few shiny social
features developed by OpenERP SA alone over the last
months VS the collective construction of the
mission critical ERP features of OpenERP these
last 8 years in association with hundreds of experts
from the community.

9. Myth 4: they "tested it for 12 months
OpenERP has been made for mixing
persons and companies in a single key"
No sorry the fix they are now making wasn't something
"designed" at all. I rather call that an urgent and ugly duct
tape to avoid telling the truth and taking care about guys in
productions.
2 months after the release, invoicing a picking was still
creating financial moves toward the address instead of the
company:
http://www.linkedin.com/groups/B2B-related-question-all-Fans-165657.S.214411619
http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/8810
Also the critical severity of the the "contacts" bug
discovered as generalized 3 months after the LTS release
shows that things weren't planned properly. It wasn't
"designed" to fully work this way.

10. My interpretation:
OpenERP SA did the mistake to "believe" only one key to the
contact would be enough (you can infer the compay from the
contact, no?). So they thought they could drop the other key
and use only partner_id as a contact, that would be simpler!
But now under the pressure, they finally released that two
keys in the data model were actually needed for B2B ERP
features.
So since they already started using partner_id both for
persons and companies, they now want that the legal entity is
carried by a key called commercial_entity_id instead of
partner_id. That is it has permuted what kind of record a
partner_id in the same code means!

11. Myth 5: "OpenERP SA's
solution is a serious solution"
It's not!!!
So now that they finally released that some code expecting a
company now receives a person randomly in partner_id, in
order to fake that a person can now behave like company,
they now propose to:
● hard copy fiscal and accounting company data over all
its contacts. Duplicating their properties records.. (see
server patch)
● reading and writing company data to persons may work
on the surface. But in term of cardinality it introduce
many hidden regression in the official and third party
code base.
● it still means a semantic permutation of two fields, it's
why their patch is so huge (to fix just the invoice object)

12. Our contact_id solution is
clean instead!
OpenERP SA's solution: permutation
Our contact_id solution: preserved
semantic
person legal entity
v6.1 address_id partner_id
v7 partner_id commercial_entity_id
person legal entity
v6.1 address_id partner_id
v7 contact_id partner_id

13. Our contact_id solution is
clean instead!
That is our solution repairs things before entering the
code: it repairs the user interface directly so that the user
selects a contact but under the cover, it properly sets the
related partner_id and the existing codebase receives
exactly what it expects: a legal entity.
If we want to do social features with the contact, we can still
use contact_id!

14. Myth6: It's not a matter of
variable name!!
No because we aren't dealing with just an isolated piece of
code where we could just replace the variable names.
fields names are all inter-dependent from:
● data from databases
● foreign keys in the schema
● variables passed back and forth to the user interface in
very complex manner
● functions in a galaxy of third party modules calling
themselves and injecting determined variables only

15. Myth6: It's not a matter of
variable name!!
It means that we have a problem with cardinality
essentially.
That is when we iterate over all records linked to a
company. If instead we iterate over records related to a
mere contact of this company, results are very unexpected
(we miss records essentially).
Same thing happens when searching if things pointing to a
given person or company exist or not.
My other slides give more details examples about this chaos
http://www.slideshare.net/RaphalValyi/open-erp-v7-contacts-issue?
utm_source=ss&utm_medium=upload&utm_campaign=quick-view

16. Our contact_id solution is
still social...
● we can still search both by contact or by company
● auto-completion works
● we can group both by contact or by company (they
cannot)
● we can relate both by contact or by company (they
cannot)

17. Myth 7: "impact on third
party module is similar"
No!! Absolutely not and this is the main catch!
If you don't understand this yourself you should absolutely
get in touch with the people who understand the problem,
don't be abused with that.
With the refusal to integrate our 200 code lines
patch, that would endup forcing the community to
literally review and change the logic of hundreds of
thousands of lines of code globally!
Let's explaining why...

18. Myth 7: "impact on third
party module is similar"
Indeed: porting from 6.1 to 7.0 is already some work, but
it's a bit mechanical.
Now, if instead the partner_id semantic is permuted,
people will have to be very careful about the cardinal
discrepancies in their code, they may need to
● rewrite their iterations over records related to
companies
● rewrite "domains" and search for related records
● rewrite their SQL reports
● introduce new keys to the company (missing else) and
pass them back and forth in the user interface...
All that should be done by people with deep functional
understanding instead, probably some regressions only
detected in production...

19. Myth 7: "impact on third
party module is similar"
data copy and duplication from the company to its contacts
definitely helps to hide some issues for reading company
data on person records.
But it doesn't come free either: people have to think what
data they will get duplicated or not. For instance you hardly
can copy the company country to the contact country. But
your code may now read it from a contact..
And it only hides the issue at the price of a very ugly non
CODD canonical data model. That is: one day, to have a
clean normalized data model again, all that will have to
be rewritten anyway, reading things on the right entity:
the company

20. Not adopting the contact_id solution
will fragment the ecosystem!
1. If OpenERP SA drops his solution. No fork will be
created to absolutely duplicate data and permute the
semantic because nobody approves that...
2. But in the contrary option. Some will see our solution is
much easier to migrate existing codebase to and that it
doesn't blindly trust semantic permutation will have a
very limited impacted only (eg functional regressions for
years). So some of us will use that branch anyway.

21. Not adopting the contact_id solution
will fragment the ecosystem!
Illustration: Akretion Brazil: we already migrated 15 000
lines of localization alone to v7.0 but assuming
partner_id was still a legal entity.
We have 5 customers in production in 7.0 waiting for a
solution for contacts quickly.
We aren't going to rewrite again these 15 000 lines
of code overnight to make it work with partner_id as a
contact, just because OpenERP SA did a mistake they don't
want to assume it.

22. Not adopting the contact_id solution
will fragment the ecosystem!
Instead, using that branch is much less risky for us: we can
use v7 already with the same robustness as 6.1. We don't
need to have to rely on anybody hypothetically fixing or not
in the future the regressions they are just introducing now
by assuming the semantic permutation.

23. Is it a fork?
good question.
Well at least for no this is not the objective.
We still have some hope to maintain a synergy in the
OpenERP ecosystem.
Our objective is simply to be able to keep doing large B2B
projects with OpenERP without to have to put too much
faith in overnight big bang rewrite neither too much faith
SA will some day fix all the advanced B2B bugs they are
introducing now with the permutation.
Then what the f*ck is it?

24. Today it's a tracking branch
proposal
● ideally merged weekly from OpenERP SA's branch just
like OCB branch
● ideally THIS would be the OCB branch. Let's see if we
can agree on that
● merging will require some manual work. But not as
much as you could think:
○ if no 'partner_id' is detected in a diff, then merge will
be automatic!
○ else (5-10% of addons merges?) then yes, some
simple manual work will be required to avoid doing
crap.

25. Today it's a tracking branch
proposal
● because OpenERP SA still accepts that partner_id can
be a company (it can be a person or a company in their
model). Their code will in fact largely works in
our code: if we take the commercial_entity of a
company, it will be the same id, it will still work!
● So the risk is very limited: the risk is basically only
to loose the contact record somewhere because we
used their partner_id instead of contact_id. Well not
mission critical, easy to fix! That's what we said
since the beginning: I prefer sending a mail to a
company instead of a contact rather than screwing
predictive cash flow reporting because ids don't match
anymore.
● instead our code will likely need some adaption to work
in OpenERP SA world.

26. Where does it bring us?
In fact, migrating a database back and forth from our
branch or to the permuted OpenERP SA branch is mostly
some 15 SQL commands to rename 2 columns for some ~6
entities:
partner_id <-> contact_id
commercial_entity_id <-> partner_id
And also trigger the data duplication to the contacts on
OpenERP SA's branch (and cry silently with your teddy
bear).

27. where does it bring us?
So we are doing this to keep being able to be successful with
OpenERP v7 during 2013.
After 6 months or one year, it may take these directions:
● OpenERP SA merge to our solution again
● may be OpenERP SA will have fixed B2B contacts issues
in general and we could migrate to OpenERP SA branch
by rewriting our modules to match the permutation (at
least no need to do it now).
● It can keep being a tracking branch if that's the easiest
solution
● Else, yes, that can be a fork. In any case we aren't going
to fork alone like crazy. So that doesn't depend on just
us.

28. Where does it bring us?
In the meantime, thanks to these bijective 15 lines SQL
scripts we could still revert decisions.
We could even still take advantage of Enterprise
contracts: migrate to the permuted OpenERP SA be,
version, apply the script and be back in the non permuted
world for which we adapt our modules.
Now of course, that doesn't mean we would love to keep
selling them if that's us who should do editor's job, but
that's another story.

29. What's next?
● keep trying pressuring OpenERP SA to take what we
think is the right decision
● prove automatic merge is easy by simulating it from the
past (get an estimate how automatic it is)
● prove SQL columns renames can take us back and forth
from the two worlds.
● give attention to our projects again with this branch
● see who is with us if we aren't with OpenERP SA
● put at work a rotation to do the merge tracking job and
merge from OCB if we aren't OCB (you are with us
Stefan, right?)
● keep elaborating organization so that we can keep
moving this forward with or without OpenERP SA.
● right now: get some sleep ;-)