[7.0][trunk][crm] regression: sale order created from prospect through opportunity related to wrong address/partner

[Raphaël Valyi - http://www.akretion.com]

Hello,

How to reproduce
-------------------------------

<a href="https://odoo.com">Odoo New Website</a>
[https://www.odoo.com|odoo]

runbot + sale_crm module installed.

Create a new prospect like this:
subject: 'new project'
company name: 'CompanyX'
contact name: 'Joe'

convert the lead it to an opportunity with the default settings (eg create new partner).

By default the opportunity is related to the new contact Joe, who has been correctly created as a contact of CompanyX.
But notice this is debatable whether it's good or not to link the opportunity to Joe instead of CompanyX. Indeed, CompanyX may have many contacts and this makes it hard to manage your opportunities by the companies behind the contacts.

But there is worse:
Now convert the opportunity to a new quote using default settings.

By default: the new quote will be related to Joe, not CompanyX!!
That is if you continue the flow, who will be invoiced will be Joe, not CompanyX, that is the accounting with CompanyX is going to be all wrong.

Expected behavior
-------------------------------
1) at the very least, in such case, the default address/company for the quote conversion should be the parent CompanyX instead of contact Joe.
2) eventually, the opportunity could be related to CompanyX too instead of Joe. Eventually this could be an option and eventually the opportunity would be related to CompanyX but mentioning in some field the Joe contact.

Hope to see this fixed. I think today the CRM acts as a "discover OpenERP" channel, it can not be that broken. And behavior was correct in 6.1 at least, so this is a regression and regressions aren't good.

[Fábio Martinelli - http://zupy.com.br (androidado)]

This is why I don't use the prospect phase

[Ana Juaristi Olalde (ajuaristio)]

@fabio, that's not the point.

@rvalyi: It's again same conceptual mistake about different entities. Partner(company or individual) and contacts inside this partner are different concepts so they should be implemented in different entities as it has been always.

IMHO: Changing and unifying those concepts is going to cause more problems in several areas that benefits it gives.

My 2cents.

[Amit Parik (amit-parik)]

Faced the same issue as rvalyi posted.
But agreed with ana.

Better lets take discussion over it then will decide which behavior would be fine for this.

Thank you!

[Fábio Martinelli - http://zupy.com.br (androidado)]

when converting, its mandatory to define a contact

I agree that in several cases most B2C it will be OK, but in a B2B scenario its all wrong

So there should be an option like to choose if it's a new or existing partner
To relate the opportunity to the company or the contact

And more, if it's for a company, show the respecting contact in a field somewhere

[Ana Juaristi Olalde (ajuaristio)]

+1 CRM objects should have Partner link + contact link.
One Claim for instance, it's related to a customer but it's reported by a contact related to that customer.

[Ana Juaristi Olalde (ajuaristio)]

I see 2 possible solutions:

First one: With actual aproach
    .- step1: include new many2one link to "everything" object.
    .- step2: use the actual many2one as "partner" to make order or invoice and second many2one as "contact" (informative field)

Second one: With older aproach
    .- Include many2one link to contact object (domain addresses of that partner, or related contact field partner_id)
    .- Let the proccess as they were.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello

this merge proposal should do the trick in the less invasive possible way, implementing solution 2) as it has been suggested by several (also on Twitter).
https://code.launchpad.net/~rvalyi/openobject-addons/crm-fixes-opportunity-regression-1155679/+merge/153960
Time to see if merge proposal review promises are any true...

[Fabien (Open ERP) (fp-tinyerp)]

I do not agree with the proposed solution. It looks like you want to use OpenERP in the wrong way. The issue is not related to the business opportunity but to the way the sale order is designed to be used.

So, let's start by the sale order. On the sale order, you have 3 fields (many2one, res.partner):
  - the contact of the sale order (the one who purchased)
  - the invoicing address
  - the delivery address
By default, only the first one is visible and you have to activate an option to show the three fields on the sale order form.

Suppose I do a sale order, this would give the following data:
  - Sale Order to "Camptocamp, Luc Maurer" (=the main contact, the person that purchased)
  - Invoicing to "Camptocamp, Accounting Department"
  - Delivery to "Camptocamp, Warehouse X"

The first one is usually choosed by the salesperson from the UI or come automatically from the opportunity, pos. The two others fields come from the default address types of the Camptocamp customer.

It looks like you want to label all your sales order to "Camptocamp" and not to "Camptocamp, Luc Maurer". OpenERP accepts this, but in the real life, salesperson used to send their quotation to someone "Camptocamp, Luc Maurer" and not only to "Camptocamp".

In the real life, the email address of the "Camptocamp" company is something like <email address hidden> and the email address of luc maurer is something like <email address hidden>. If you send your quotation to <email address hidden>, there is a chance that the contact of your salesperson (Luc Maurer) never receive your quote. If you send your quotation/sale order by regular mail (the poste) to Camptocamp, ..., Switzerland there is also a big chance that Luc Maurer never receives it.

So, in my opinion, the behaviour of OpenERP 7 is correct and the one you want to do is wrong.

I'd like to understand why you want to put only companies as the contact persons of your sales order and not the real contacts as the contact person of your SO? Can you detail the real reasons why you want to do that?

I can see different reasons:
  - You want the ability to easily search all Sales Order of Camptocamp. This is a real regression that we have to fix. The solution is just to put "child_of" instead of "=" on the partner_id field of the search view of the sale order (and invoice)
  - You think invoicing data are wrong because they are labelled to the wrong partner. This is wrong. The invoice is corrrectly labelled to the invoice address "Camptocamp, Accounting Department". If no invoice address is defined for this company, the invoice is labelled to the sale order contact "Camptocamp, Luc Maurer" which is correct. (for the same reason than the SO, you will not send your invoices to <email address hidden>. You will probably send your invoices to your contact person at the company)
  - You think Journal Items are wrong because they are labelled to "Camptocamp, Luc Maurer". This is wrong. All accounting entries (journal items) are linked to "Camptocamp", and not to the invoice contact "Camptocamp, Luc Maurer". So, this is correct as all accounting reports are per company and it works for reconciliations, bank statements, ...

The misunderstanding is not on the oppor...

[Fabien (Open ERP) (fp-tinyerp)]

> Time to see if merge proposal review promises are any true...

We improved merge proposals review but we can not promise to review everything in a few days/hours (we don't have enough qualified dev resources for this). Our promise is more to code review and check everything to ensure we avoid commiting regressions. (quality vs speed)

[Fabien (Open ERP) (fp-tinyerp)]

Please note that the current behaviour is not a regression but what you propose is a regression:

  - in v6.1, you could create an opportunity to "Luc Maurer", "Camptocamp" and quote to "Luc Maurer", "Camptocamp"
  - in v7, you could create an opportunity to "Luc Maurer", "Camptocamp" and quote to "Luc Maurer (Camptocamp)" which is exactly the same than in v6.1 (we just avoided the redundancy of data on the company)
  - with your merge proposal you can create an opportunity to "Luc Maurer", "Camptocamp" but you can not quote anymore to "Luc Maurer, Camptocamp" --> you quote to "Camptocamp" only and loose the information about who is your contact. So, I think your proposition is a regression for this reason.

[Fabien (Open ERP) (fp-tinyerp)]

So, in order to be constructive, I propose to discuss/check what are your issues of using "Luc Maurer (Camptocamp)" as a contact of the sale order or invoice. What's the reason why you want to quote to Camptocamp instead of "Luc Maurer (Camptocamp)"

[Olivier Dony (Odoo) (odo-openerp)]

Long story short, the behavior of the sale_crm module seems consistent with what was happening in 6.1 and with the way contacts are used when creating Sales Orders manually. As explained in comment #8, The journal entries of the SO invoice will be linked to the Contact's company, as was also discussed on bug 1151947.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello,

well in my first comment I proposed 1) and 2) but nobody from OpenERP SA answered so I implemented 2) after advice from community.

That's true, the journal entries were taken correctly even if the quote and invoice were linked to the Joe contact.

Now, us and several people still find it very cumbersome to manage your opportunities, orders and invoices BY COMPANY if they point to some company contacts instead.
Say you take a list of opportunities|orders|invoices in OpenERP list view and do some group by partner, it won't aggregate things by companies. It makes all reporting a lot more cumbersome as you should look for some potential parent company.

As Ana and me suggested, we would have preferred to have the opportunity related to the company, still also mentioning the contact.
Without guidance from OpenERP SA, my change tried to stay minimalist and avoided touching the schema, say to have more chances to get into the stable branch.
That's why I didn't add a contact_id field to the opportunity entity (you still have the contact details in the 'prospect' tab anyway). But for me the best solution (may be not compatible with inclusion into stable then) would have been to add such contact_id field and propagate it to the created quote as the quote contact where the invoice is mailed also.

So in a word, yes, unlike what I said journal entries aren't screwed, but still we think putting the company as the partner_id at least for the quote and invoice would easy the management by companies later. So a solution could also be to extend my solution to also propagate the contact to the quote in order to avoid losing it, but still assigning the partner_id to the company. What do you think?

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hum,

so actually it really seems you intend to use the contact in partner_id in the order or the invoice, as many I didn't even expect that was the intended behavior in v7. Even if we forget about reporting issues I mentioned, there are many other open issues with such approach today. Hopefully I will find time to post about it in the accounting expert list in the very next days. All I can say is beware things seems heavily broken today if you use it this way.

[Nhomar - Vauxoo (nhomar)]

Hello all

To be constructive, i think, we must build a matrix of casuistic, regarding to 4 main process affected in a good or bad way with this change:

Purchase | Sale | Invoicing | Stock Moves(yeah we have issues here) | CRM

Being deeper, we should select all models with partner_id in them, and analyze the correct behaviour expected, even HR probably have problems, with partners that are employees and not customers, by default.

In our case, we just redevelop our user manuals for customers, and we are trying to comply with the same features than V6.1, but in the middle some things should be just reveiwed-corrected, but I don't face any issue __yet__ not capable to be solved with new structure.

@Fabien - @Odony, did you this analysis when you decided introduce this new feature?

IMHO : We are doing this analysis, but it should be really great if you as designer, make a big matrix with impact of changes, and when we find together a new case, just refill the matrix and take care with OPW or Community merges with solutions.

If we can not view all the matrix, it will be a no ended discussion for the real needs.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@Nhomar, I think we need to move that discussion out of that specific bug thread because it's so general.

But for the record and in a very synthetic way, for us the two options are:

A)
======================================
we try to fix every one of the hundreds of issues one by one and possibly with smarter things like computed+stored company_entity_id field on res.partner and also overwrite read and write to deal with the proper parent_id record wherever it makes senses and finally fix the rest of the code with case by case patches. Hopefully with support form OpenERP SA rater than denial that would force us even more to work in a parallel branch with all the forking risks that represents.

But that supposes a blind faith in the new model to refactor everything to meet that new model
A faith that is missing today in a some people at Akretion at least. Specially as the new data model is rather insulting Codd theory and pre-existing art like the party model.

B)
======================================
other option is, for fields where it's very critical because it could break accounting, fiscal or financial features, we can also kind of reject the new model at least temporarily and put a domain on partner_id like the one of the invoice to prevent it to point to the contact of a partner instead of pointing to the partner record (and that means considering this bug valid also).

I won't go into the detail now, but think for a minute how badly things are broken now because OpenERP code tries to read these field in the contact instead of the parent partner record (via the partner_id field):
fiscal position, payment term, credit limit, pricelist, payment conditions, accounts, country etc...
A company contact isn't supposed to carry any of these!

Like may be it's ok to have partner_id point to an address in the CRM or even in a picking provided we get back the right partner record in the invoice. But sorry to say it, a quick scan of partner_id occurrences in the account module shows that if partner_id now designate a contact address record instead of the partner record, then out of the box, almost everything related to it is broken! In fact what works like the journal entries here is rather the exception (where it has been fixed specifically already) rather than the rule.

I would say until we have confidence in the new model or even a new one or until we have confidence A) can be done without facing regressions for 2 years all over the place, it's safer to go with option B).
now yes that mean that in some case like invoices, we should bring back a kind of contact_id field to deal with the invoicing contact when it's different from the invoicing address. And again it's all about assuming choices because if Akretion fixes it that way and OpenERP SA continue to assume an invoice contact is to be taken from that partner_id field, then yes, we have an ever growing list of discrepancies.

Conclusion ======================================
So for us it's between A) and B) with a preference for B) so far. And yes this is a very critical choice and possibly a one way choice. I'm very disappointed to have to discover myself the depth of the issue 3 month...

[Bojan Markovic (bmarkovic)]

As per Fabien Pinckaers request here is my reason (in as much detail as I feel is needed) why I think current design is wrong:

You are not allowed, as per legal norms in my country, and I'm pretty sure it's the same in many other jurisdictions, to title proforma/quotation or invoice to a person in a company. It must legally be adressed to the company or a division of one, as the company/division and not the contact is your customer, and if you want to make sure it reaches a certain person you're free to wrap it (envelope it) and adress the envelope to that person.

There is a clear distinction between a legal (and often legally binding) accounting/business document and business correspondence. With what you did in v7 you effectively nix that distinction. I don't know what's the case elsewhere, but invoice and a proforma is subject to legal regulation (and audit) here, not just your accounting i.e. journal entries.

Perhaps in your country it's different, and perhaps in some future it will be so in others, but I wonder why you would insist on hard-wiring a design that clashes with legal requirements to achieve functionality that could have been achieved by other means, and quite frankly, seems rather unimportant and cosmetic.

In the end, global software should have provisions to meet requirements of various legislatures, a design should not insist on a headstrong way of doing things that clash with such requirements.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello Bojan,

all the OpenERP partners I talked with don't caution invoicing a company contact instead of a company. A contact company is never expected to carry the legal fiscal, accounting and financial data of the company it belongs to. And today the code in the account module will mostly try to read these information on the contact only if partner_id happens to be a contact like with this bug.
Apparently OpenERP SA tried to work a bit around it by at least finding back the right company accounts for the journal entries. But this is broken for almost every other field that the account module will now try to read on the contact instead of the company partner, like: payment term, payment condition, credit limit, fiscal position, pricelist...

So IMHO the two options are:

A)
try to make it possible to invoice a company contact by fixing everything else (but there is A LOT OF WORK) and I don't think it's a work in the right direction at all. There are several other very severe functional regressions with the new address design which fails to normalize data. So I'm really not sure we should change a lot of functional code to meet that new suspect data model. May be it's more constructive to change the partner data model again quickly for a v7.1 or v8 version instead.

OR

B)
Forbid to invoice a company contact, with a domain on partner_id for instance. In this case this big should be dealt with and work should be done to have an invoicing contact again on the invoice object.

From our quick investigation we have at least the same problem with purchase orders. As for sale orders, as there is already an independent invoicing address, it can more easily be worked around (still if we fix that kind of bug here).

I should say I believe many OpenERP profesionnals and may be OpenERP SA themselves didn't understand yet the gravity of this regression. I'm extremely disappointed to see such regressions, still totally minimized today while IMHO this should be addressed among the very to priorities before saying the version is stable.

[Fabien (Open ERP) (fp-tinyerp)]

@Bojan,
Where are you from?
I was not aware of a country where it's illegal to put the name of a contact on an invoice labelled to a company. Can you find a link to a legal document explaining this?

We have to check if it's a legal requirement or just a best practice in the country. We also have to decide if we do that in your country localisation or not. (do others countries have such a constraint?) I guess your concern is only about invoices; sale orders are usually sent to a contact in the company?

@raphael
You are right, we have to improve something in order to avoid having to put the fiscal position/accounts/pricelists on the contact of a company. The value of those fields should come from the company itself in some situations. I do not know if we should qualify this as a bug or not (it's ok to have to put the pricelist/fiscal position on the contact) but we will do that in v7. Olivier will do something similar to what we did for addresses (that are shared amongst all contacts). Nothing complex, it's a ~20 lines fix; no other object than res.partner should be changed.

Note that your proposition B is not good; it's important to be able to invoice to physical persons who have no company.

[Nhomar - Vauxoo (nhomar)]

@Fabien.

Dont forget,

If the contact has a parent_id, and this parent is a company, all
accounting information should com from parent itself,

Just contact without a parent that is_company==True should take them own
information, with this kind of behaviour you will be consistent with what
all fields mean.

Regards, and thank for the answer.

PS: I think yet we will find a lot of mor logic features regarding to other
models but i think with this options we will mantain consistency with terms
and normal features.

2013/3/23 Fabien (Open ERP) <email address hidden>

> @Bojan,
> Where are you from?
> I was not aware of a country where it's illegal to put the name of a
> contact on an invoice labelled to a company. Can you find a link to a legal
> document explaining this?
>
> We have to check if it's a legal requirement or just a best practice in
> the country. We also have to decide if we do that in your country
> localisation or not. (do others countries have such a constraint?) I
> guess your concern is only about invoices; sale orders are usually sent
> to a contact in the company?
>
> @raphael
> You are right, we have to improve something in order to avoid having to
> put the fiscal position/accounts/pricelists on the contact of a company.
> The value of those fields should come from the company itself in some
> situations. I do not know if we should qualify this as a bug or not (it's
> ok to have to put the pricelist/fiscal position on the contact) but we will
> do that in v7. Olivier will do something similar to what we did for
> addresses (that are shared amongst all contacts). Nothing complex, it's a
> ~20 lines fix; no other object than res.partner should be changed.
>
> Note that your proposition B is not good; it's important to be able to
> invoice to physical persons who have no company.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1155679
>
> Title:
> [7.0][trunk][crm] regression: sale order created from prospect through
> opportunity related to wrong address/partner
>
> Status in OpenERP Addons (modules):
> Invalid
>
> Bug description:
> Hello,
>
> How to reproduce
> -------------------------------
>
> runbot + sale_crm module installed.
>
> Create a new prospect like this:
> subject: 'new project'
> company name: 'CompanyX'
> contact name: 'Joe'
>
> convert the lead it to an opportunity with the default settings (eg
> create new partner).
>
> By default the opportunity is related to the new contact Joe, who has
> been correctly created as a contact of CompanyX.
> But notice this is debatable whether it's good or not to link the
> opportunity to Joe instead of CompanyX. Indeed, CompanyX may have many
> contacts and this makes it hard to manage your opportunities by the
> companies behind the contacts.
>
> But there is worse:
> Now convert the opportunity to a new quote using default settings.
>
> By default: the new quote will be related to Joe, not CompanyX!!
> That is if you continue the flow, who will be invoiced will be Joe, not
> CompanyX, that is the accounting with CompanyX is going to be all wrong.
>
>
>...

[Ana Juaristi Olalde (ajuaristio)]

2013/3/23 Nhomar - Vauxoo <email address hidden>

> @Fabien.
>
> Dont forget,
>
> If the contact has a parent_id, and this parent is a company, all
> accounting information should com from parent itself,
>
> Just contact without a parent that is_company==True should take them own
> information, with this kind of behaviour you will be consistent with what
> all fields mean.
>
Contact without a parent that is_company, it's a company itself.
I mean in spain Pepe Lopez Sanchez who is invoicing himself, can have a
company name as "autos pepe" even if he is alone and his company fiscal
identity is individual instead company fiscal identity that has got
different format for individuals and companys.

And yes... in spain is not legal invoicing to a contact of a company. I
doubt that this is legal in other countries. Contacts in companies must be
even allowed legally to buy in the name of company. That is, noone can buy
goods in the name of a company but people named for that inside the company
(administrators or purchase mangers or so on)

Actual aproach is complicating and making silly issues regarding addresses,
contacts and partners just because you lost normalized definition for every
concept.
Partner: Entity (individual or company) you are going to invoice or receive
invoice from, where you set filscal data and other valuable data as tarifs,
comercial name or other data related to saling or purchasing.
Contact: Always individuals related to Partners in several ways
Address: Address. Nothing more than address.

My 2 cents.

>
> Regards, and thank for the answer.
>
> PS: I think yet we will find a lot of mor logic features regarding to other
> models but i think with this options we will mantain consistency with terms
> and normal features.
>
> 2013/3/23 Fabien (Open ERP) <email address hidden>
>
> > @Bojan,
> > Where are you from?
> > I was not aware of a country where it's illegal to put the name of a
> > contact on an invoice labelled to a company. Can you find a link to a
> legal
> > document explaining this?
> >
> > We have to check if it's a legal requirement or just a best practice in
> > the country. We also have to decide if we do that in your country
> > localisation or not. (do others countries have such a constraint?) I
> > guess your concern is only about invoices; sale orders are usually sent
> > to a contact in the company?
> >
> > @raphael
> > You are right, we have to improve something in order to avoid having to
> > put the fiscal position/accounts/pricelists on the contact of a company.
> > The value of those fields should come from the company itself in some
> > situations. I do not know if we should qualify this as a bug or not (it's
> > ok to have to put the pricelist/fiscal position on the contact) but we
> will
> > do that in v7. Olivier will do something similar to what we did for
> > addresses (that are shared amongst all contacts). Nothing complex, it's a
> > ~20 lines fix; no other object than res.partner should be changed.
> >
> > Note that your proposition B is not good; it's important to be able to
> > invoice to physical persons who have no company.
> >
> > --
> > You received this bug notification because you are subscribed ...

[Erwin van der Ploeg (BAS Solutions) (erwin-bassolutions-deactivatedaccount)]

Hello, I really don't get it. If I make a company and create a contact for that company. The contact is automatically a customer? That is not ok. You don't want to invoice on the customer. If you do that, the invoice analyses will split up the turnover on 2 customers? It is 1 customer!

I thought i uncheck the option "Customer" on the contact (it is strange that it is set automatically, but anyhow). But also if i uncheck that option, i can make invoice on contact! That should not be possible.

I think a contact should never be automatically be customer. If you want that, you can check that box later. Now you can create invoice on contact and that is not what we want.

I agree on Nhomar:
*Partner: Entity (individual or company) you are going to invoice or receive
*invoice from, where you set filscal data and other valuable data as tarifs, comercial name or other data related to saling or purchasing.
*Contact: Always individuals related to Partners in several ways
*Address: Address. Nothing more than address.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

> @raphael
>
> [...]
> Note that your proposition B is not good; it's important to be able to
> invoice to physical persons who have no company.

@Fabien, please read carefully. My proposition B is not about preventing to
invoice a final customer at all.
It it about to put a domain like you already did for bank statements for
instance to be able to selection only a commercial entity that is:
a company OR a final customer BUT NOT a contact company.

Look at the party model carefully (at least the top of the page):
http://www.tdan.com/view-articles/5014/

Now in v7 you made companies, contacts and final customers all subclasses
of a "party" (res.partner now) which seems good to me so far. (provided you
do the address object extraction via _inherits to be able to share
addresses then).

BUT because they are subclass of Party, it doesn't mean they can be
exchanged anywhere!
It is like if you have a python function requiring a number, you can pass
it a floats or an integer, no problem. Like may be you can have a pinking
in OpenERP pointing to any kind of party (and may be not, that
generalization should be allowed case by case very carefully), fine.
BUT you may have a python function requiring an integer and not a float.
And I claim the way it is your account module requires that partner_id can
only be a commercial entity (that is a company OR a final customer I mean)
BUT NOT a company contact!

So my recommendation is not to change all the code of the account module
(and all community related modules, and at least the same for the purchase
module) but instead to make that "subtype" restriction explicit via a
domain, just like you did already for the bank statements. AND you also
need to introduce some sort of contact_id to manage the invoicing contact.

Additionally, going solution A) instead (that is change all the code of
account and other modules to accommodate to partner_id now being a company
contact eventually) you would screw all the reporting tools about your
invoices in a very bad way. No more simple groud_by partner_id to find your
sales to per companies (or final customers), you would now at least join
with the res_partner table and eventually join again over the res_partner
table on the parent_id... Much more cumbersome and many existing reports
totally broken!

As for localizations. Well our localization in Brazil won't work if
partner_id can be a contact company instead of the company. That is as a
workaround we already assumed that for our v7 projects (that is I applied
my patch even if better can still be made).
But it's worse than that, if OpenERP SA view is to allow company contacts
everywhere for partner_id, well I'm not sure we would follow OpenERP next
versions because it sounds extremely wrong and dangerous to us.

So I hope we see solution B) assumed and implemented.
I'm not the only one thinking that. See also
https://bugs.launchpad.net/openobject-addons/+bug/1112507/comments/4

Regards.

[Fabien (Open ERP) (fp-tinyerp)]

I am not sure about the fact that the contact name should not be on the invoice. When I google "invoice template" in Google Images, nearly all templates have [Name] + [Company Name] in the invoice.
@ana @bojan Can you check in others software from your country?

@raphael
Not sure you understood my proposition:
To avoid having to put the fiscal position/accounts/pricelists on the contact of a company. The value of those fields will come automatically from the company itself. We will do something similar to what we did for addresses (that are shared amongst all contacts). No other object than res.partner should be changed. This means all contacts of the compay will always have the right pricelist/accounts/...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@raphael

> Not sure you understood my proposition:
> To avoid having to put the fiscal position/accounts/pricelists on the
> contact of a company. The value of those fields will come automatically
> from the company itself. We will do something similar to what we did for
> addresses (that are shared amongst all contacts). No other object than
> res.partner should be changed. This means all contacts of the compay will
> always have the right pricelist/accounts/...

@Fabien,
Wouldn't that be by kind of "overriding the read of res.partner" to read
the value from the parent_id in case of a company contact as I described in
A) ?

Basically I see only a A) and a B) solutions which are again:

   - A) you try to keep accepting companies contacts in partner_id and try
   to do whatever required to make it work this way (I come back on this)
   - B) you say partner_id in business documents can only be a company OR a
   physical person as in previous version of OpenERP BUT not a company contact
   (WTF!). So you add a contact_id field in business documents and possibly
   show only that contact_id field if you want to market yourself as the ERP
   for the masses and put a fucking on_change to set the appropriate
   partner_id with the same ir or with the parent_id in case contact_id is a
   company contact. Done!

Now I strongly recommend against trying A) because even with fixing reading
the values you will still have the generalized following regression all
over the codebase:

   1. the reporting - GROUP BY partner_id - will still be totally unusable
   and hard to fix. Same issue for reports joining company data like partner
   country or partner category etc...
   2. any OpenERP domain or Select involving partner_id is mostly broken in
   case partner_id is now suddenly a contact
   3. in OpenERP views, partner_id can be passed to be used in attrs, in
   form domains or context. This is a place where no extra logic on parent_id
   can be performed (client-side) and it will often be broken

Thinking further about trying to implement A):
the only decent way to unfuck the reporting would then be to add a new
computed stored field like commercial_entity_id on business documents that
would be either the related company or physical person.
BUT wouldn't commercial_entity_id then be exactly what partner_id has been
all these years? It would!
So it means after facing hundreds of hidden regressions in the core and
community modules during probably 2 years, you would finally implement a
solution that would be equivalent of doing B) now, except that you would
have made all the code more complex and slower. With functionally no
benefit at all.

We talked between several partners and all came to this conclusion: the
only decent solution is B) unlike what OpenERP SA started doing by fixing
the accounts even in case of invoicing a contact, or making reconciliation
work.
In fact, I talked with Luc Maurer this morning who described me exactly the
same solution as I was advocating even before I gave him my solution
(independently if you like) AND he also told me he detected this issue 4
months ago and said to Quentin de Paoli to fix it the B) way.
So I'm a bit surp...

[Sébastien BEAU - http://www.akretion.com (sebastien.beau)]

@Fabien

Having only 1 field on invoice for contact instead of having 2 fields (one for the contact and one for the company/physical person) can introduce huge problem.

Indeed look at this simple case:

Scenario
I have 2 company A and B
I have Mr. Dupont as contact in company A
I invoice Mr.Dupont
then Mr.Dupont find a better job in B company so now he works at company B

Then ALL of the invoice of company A is now linked to company B ! (but the move line are correct because the move are linked directly on company B)

The only solution I see to fix this issue is two having 2 fields on a invoice ( contact and partner_id). So if your contact change of company you don't care because the invoice will be still linked to the correct company.

The solution proposed by Raph is good because for simple user you can hide the field partner_id and fill it with a onchange, and for advanced user you can show the field. Also reporting will still be easy because you just have to group by partner_id, and all accounting will work without patching everywhere.

What do you think?

My 2 cents

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@Fabien,

just illustrating if that's still not clear. You claim all you need is changing res.partner a bit. And I claim not at all.

Look at the following sample code from account/account_invoice.py:

pay_pro_id = property_obj.search(cr,uid,[('name','=','property_account_payable'),('res_id','=','res.partner,'+str(partner_id)+''),('company_id','=',company_id)])

now consider that partner_id is suddenly the id of a company contact not carrying the account data as allowed by OpenERP v7.
Well you will never find your property with such a search/domain unchanged! And patching all the code would also force you to do more browses on res.partner or that is make OpenERP even slower for nothing.

So really it would take years and hundreds if not thousands of lines of to patch all the codebase (consider also all the community modules, localizations...). Meanwhile B) is only 50 lines of patch, no risk taken and one day of work if assumed now...

[Olivier Dony (Odoo) (odo-openerp)]

Please note: bug 1160365 has been created to specifically discuss generic issues with the 7.0 partner model. Feel free to post comments there if not directly related to the current bug report (which is closed as invalid)
Thanks for your patience and your constructive feedback!

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@Olivier,

I'l comment in the new thread about the generalized issue. But notice that because the CRM select the company contact as the invoicing party by default and because this doesn't work today and because I explained this not going to work in the foreseeable future, I very much consider this CRM bug valid...

[Fabien (Open ERP) (fp-tinyerp)]

@Sebastien
If Mr. Dupont starts working for company B, you have to create a Mr. Dupont for Company B (instead of moving mr. dupont from company a to company b) like you would do for any subsidiary. So, you have Mr. Dupont working for company A (<email address hidden>, phone: companya+dupontsuffix, ...) that you can desactivate if you want and mr. dupont working for company B who are two different persons.

But, if you want to manage one persone working for several companies, you can install base_contact. It allows to manage data related to persons (Mr. Dupont) and not only to their role within their company. With the new base_contact module (7.0-base-contact-xal on runbot) you can handle it without problems. It will work perfectly: 1 person Mr. Dupont, 2 contacts (Mr. Dupont Company A & Mr. Dupont Company B)

@raphael
> Wouldn't that be by kind of "overriding the read of res.partner" to read the value from the parent_id in case of a company
> contact as I described in A) ?

No, overwriting the create and write, so that all contacts have the right data in the DB.

[Ray Carnes (rcarnes)]

What am I missing? Is this fixed?

I just tested your workflow Rafael, (Revisions: Server: 4906 Addons: 8920 Web: 3865) and got exactly what I would expect:

1. Create a new LEAD. Subject "HOT LEAD". Company Name "URSA". Contact Name "RAY".

2. Convert to an OPPORTUNITY. Conversation Action "CONVERT TO OPPORTUNITY". Related Customer "CREATE A NEW CUSTOMER". I observe URSA is created as a company. Is a Company is checked. RAY is listed as a Contact of URSA. I observe the opportunity is created for RAY (URSA) which takes me to RAY the contact if I click the 'Customer'. But really behind the scenes the partner of this opportunity is URSA (I checked in crm_lead table and the partner_id was for URSA).

CONCLUSION: The opportunity is NOT linked to RAY, but to URSA.

3. Convert to a QUOTE. I observe the quote is created for RAY (URSA) which takes me to RAY the contact if I click the 'Customer'. But really behind the scenes the partner of this quote is URSA (I checked in sale_order table and the partner_id was for URSA). When I generate the PDF, I see it is addressed to RAY at URSA.

CONCLUSION: The quote is NOT linked to RAY, but to URSA.

4. Confirm the SALE, Complete the DELIVERY, Create and Validate the INVOICE. I observe the Invoice is created for RAY (URSA) which takes me to RAY the contact if I click the 'Customer'. But really behind the scenes the partner of this Invoice is URSA (I checked in account_invoice table and the partner_id was for URSA). When I generate the PDF, I see it is addressed to RAY at URSA.

CONCLUSION: The invoice is correctly created for URSA, not for RAY.

5. Check the Aging. URSA shows up, RAY does not. Check the Accounting tab of RAY - Total Receivable is $0. Check the Accounting tab of URSA - Total Receivable is $1000.

CONCLUSION: AR is correctly created for URSA, RAY owes nothing.

6. Record a payment. When I select "RAY (URSA)" as the Customer, no outstanding Invoices are shown. When I select "URSA" as the Customer, the outstanding Invoice is shown and can be paid.

CONCLUSION: Payments can be correctly recorded from URSA.

Why am I not encountering any problems? This seems like a big deal - something I should be letting my customers know about but something is eluding me in my understanding or my use of OpenERP.

I would really appreciate you letting me know what I don't understand or what I am not doing properly in the software - I have several customers migrating to 7.0 as we speak and don't want them to run into any problems.

[Ray Carnes (rcarnes)]

I was wrong. I mixed up the ID's.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

So and in any case the problem wasn't the receivable parts
which surprisingly are correctly related to the company despite the invoice
being related to the contact. Or it could be that partner_id of receivable
is different from the one of the invoice then which leads to other problems
described by Nhomar here
https://www.evernote.com/shard/s158/sh/40828d76-d94a-4f44-bdb5-9c0336f55a52/fe43fe77c401e9f3bdf95982a4b0a878

Thanks for having investigated anyway.

On Fri, Apr 5, 2013 at 6:53 PM, Ray Carnes <email address hidden>wrote:

> I was wrong. I mixed up the ID's.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1155679
>
> Title:
> [7.0][trunk][crm] regression: sale order created from prospect through
> opportunity related to wrong address/partner
>
> Status in OpenERP Addons (modules):
> Invalid
>
> Bug description:
> Hello,
>
> How to reproduce
> -------------------------------
>
> runbot + sale_crm module installed.
>
> Create a new prospect like this:
> subject: 'new project'
> company name: 'CompanyX'
> contact name: 'Joe'
>
> convert the lead it to an opportunity with the default settings (eg
> create new partner).
>
> By default the opportunity is related to the new contact Joe, who has
> been correctly created as a contact of CompanyX.
> But notice this is debatable whether it's good or not to link the
> opportunity to Joe instead of CompanyX. Indeed, CompanyX may have many
> contacts and this makes it hard to manage your opportunities by the
> companies behind the contacts.
>
> But there is worse:
> Now convert the opportunity to a new quote using default settings.
>
> By default: the new quote will be related to Joe, not CompanyX!!
> That is if you continue the flow, who will be invoiced will be Joe, not
> CompanyX, that is the accounting with CompanyX is going to be all wrong.
>
>
> Expected behavior
> -------------------------------
> 1) at the very least, in such case, the default address/company for the
> quote conversion should be the parent CompanyX instead of contact Joe.
> 2) eventually, the opportunity could be related to CompanyX too instead
> of Joe. Eventually this could be an option and eventually the opportunity
> would be related to CompanyX but mentioning in some field the Joe contact.
>
>
> Hope to see this fixed. I think today the CRM acts as a "discover
> OpenERP" channel, it can not be that broken. And behavior was correct in
> 6.1 at least, so this is a regression and regressions aren't good.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/1155679/+subscriptions
>

[Sergio Corato (icsergio)]

@fabien #24
In Italy there is no one invoice template that I saw that shows contact name (search 'fattura' in google images).
The only one I saw until now is from a French company of oil, and my solution was to delete the name in the pdf file before printing it (it was too annoying to have my name in it). It was like the second form below.

Even all the 'invoice templates' in Google images shows first the company, company address, and after the contact, as a bit of more information, not an essential one. I don't know if there are other ERP that show in an invoice's form:

John Doe (IBM Corp.)
Street
ZIP City

and not like it:

IBM Corp.
att. John Doe
Street
ZIP City

It's a good thing invent something new, but not breaking a policy or a rule accepted everywhere.
My 2 cents.