Hello Fabien, in #50 you said:

That's probably the biggest misunderstanding and the reason why we are
> not aligned with the best solution.
>
> If you read carefully the proposition of Olivier:
>
>   - We do not plan to allow invoicing to contacts (in the meaning of
>     the person who purchased, or a contact person)
>   - We allow invoicing ONLY on "Valid Invoicing Entities"
>
> Be sure you understood the two lines above as it's the biggest
> misunderstanding in all our discussions.
>

Wait a minute, in the CRM example that made me discover the issue, you
spent around 10 answers explaining us my bug report was invalid and that it
was perfectly expected to invoice the contact created in the CRM as the
default flows does.
https://bugs.launchpad.net/openobject-addons/+bug/1155679

It's a bit intelectually dishonest you now accuse us of speaking loud and
not understanding your proposal while 2 weeks ago you were writing this
yourself:
https://bugs.launchpad.net/openobject-addons/+bug/1155679/comments/8
That is that is was perfectly expected to invoice a contact, that I was
wrong, and that you already adapted OpenERP to generate the correct
financial moves even when you invoice a contact...

So now, with the proposed change
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576
in account/account_invoice_view.xml line 46 (search
"account_invoice_view"), you are now back pedaling half way and arbitrary
forbidding to select a contact in an invoice directly. That is you are just
making OpenERP inconsistent: depending on the flow you can invoice a
contact or not!

If a flow allows to invoice a contact in some way, believe us, the user
WILL do it and we WILL have the trouble.

Also, we may not invoice the contact anymore after that
strange inconsistent change, for large companies, we would still need a
contact to know where to send the invoice...

AND in any case, I we said, the problem is not at all with just the
invoices. It's with all OpenERP objects, not even just main business
documents. Indeed, if somewhere two OpenERP objects of a given business
flow belong to the same customer or supplier but have a different
partner_id just because in some it can be a contact and in the other one it
cannot, then this kills the possibility to properly relate these objects,
that is that kills usability and that makes OpenERP a bad system to analyse
your business data once you recorded business facts with it. So, we don't
need a halfway solution, we need the two keys in all objects (unless you
completely drop contact management but that would be a bad fatal regression
too).


So while you are claiming we don't understand (strange all the most
experiences OpenERP integrators don't understand), you are telling us in
comment #38:

  - Quickbooks (94.2% of the market share in U.S. !):
>     http://www.axonware.ie/catalog/images/quickbooks-invoice.jpg
>   - Sage:
>
> http://na.sage.com/sage-payment-solutions/products-services/sage-50-ca-fr/~/media/site/sage%20payment%20solutions/images/landingpages/ssa/ss_2_choose_method_fr.jpg
>   - Microsoft Dynamics:
>
> http://dynamicsgphelp.com/wp-content/uploads/2011/06/SalesTransactionEntry.png
> If the most used accounting software in the world do that, they can not
> all be wrong.


That is you are using picture to prove of something about a data model
which isn't correct as Alexandre and Guewen said.

But mostly, that's you my friend who didn't understand our proposal:
because if you take 5 minutes to test my proposal here:
https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27
You can take screenshots of all business documents, You will see only ONE
FIELD just like you did in version 7, it has exactly the same label even!

So sorry, the one who didn't understand the proposal is you my dear Fabien,
not us.

So please investigate that proposal instead of making us these inconsistent
proposals which make OpenERP v7 an ERP less good than 6.1 to manage B2B,
which is may be what fuel 80% (in turnover) of your end customers really
using OpenERP in production.

Regards.