Comment 34 for bug 1160365

Hi,

First of all, thank you for asking our feed-back ! I would have loved that you'll have made that before changing all this... But what's done is done..

After testing this on the runbot, I must say that part of the troubles we faced seems solved, but still I get a strange feeling on some points.

Configuration of my test partners:
----------------------------------------------------
  * Camptocamp (is_company : True)
    * Luc Maurer (Use Company Address : True, type: Contact)
    * Claude (Use Company Address : True, type: Contact)
    * Joel (Use Company Address : True, type: Invoice)
    * Guewen (Use Company Address : True, type: Shipping)
  * Camptocamp SAS (is_company: True)
  * Camptocamp Group (is_company: True)

Whats seems good:
------------------------------
 * Multi-level in complexe structure seems to be good (still need a bit of code to display the field parent_id if is_company is checked)

 * Going from the Accounting menu, we can not invoice "Joel" from Camptocamp. If I type "Joel" he founds nobody and suggest to create it. I MUST invoice Camptocamp.

 * Accounting properties are well respected (tax, accounts, fiscal position,..), from Invoice or Sales order (even when Joel is the invoicing contact, fiscal position is ok). We replicate the datas, which if not that good from technical side, but the functional part is ok.

 * Finding partner, contact and so based on company name is easy

 * Read-only on partner form when using "Use Company Address" is good

My questions/remaining troubles:
-----------------------------------------------------
 A) When making a SO, choosing Camptocamp as the Customer, it set Joel as Invoice address and Guewen as shipping one. That means I can invoice Joel from here and not from the accounting menu... That seems strange IMO, what do you think ? If SO can make an invoice for "Joel (Camptocamp)", why I can't invoice Joel as well from the accounting menu... That could be excepted as I asked for "Use company address" on Joel (but even if I remove it, I still can't invoice Joel from accounting menu).

 B) When making a SO to Camptocamp with "invoice from delivery", confirm it, confirm deliver and invoice it => it invoice Camptocamp not "Joel" selected on the offer as the invoicing contact... That is not good. We need to be consistent... I expect to invoice Joel in that case right ?

 C) In the case invoice are related to "Joel (Camptocamp)", the sales turnover for Camptocamp is not correct (from Reporting -> Invoice analysis menu)). I know, you say it is the expected behavior here. If you choose Joel, the turnover belong to him, not Camptocamp. What I want to raise is that it will be true for every relation (not only for analysis). Lets imagine you make various claim to Joel, Guewen and Camptocamp partner... You won't sea them all in the Camptocamp history tab. I mean, this is logical from a technical point of view... But all persons will expect to have somewhere "All trouble related to Camptocamp", "All invoices related to Camptocamp" and so on... this cannot passed through searching "Camptocamp" and having various lines when grouping by...

 D) We still cannot invoice a specific address of a specific company... We have (and others too) some complex structure to invoice, like the states, big university and even with those corrections, we do not solve this major issue. You have:
  - Company XY
     - Department A, Contact 1
     - Department A, Contact 2
     - Department B, Contact 3
     - Department C, Contact 4

 => This is mandatory that you can invoice Company XY, for submission to "Department A, Contact 1" or "Department B, Contact 3". We do need two fields on the invoice... You want to see the printed invoice address like:

Company XY
M. Contact 1
ADDRESS Company XY

 E) What about the migration... I mean, I currently having lots of customers to migrate. They currently have:
     - Turnover by company is right because based on partner_id (through analysis)
     - Invoices to various department/contact for the same partner/company based on contact_id can be done
     - Accounting entries belong to partner_id (as well as chosen fiscal position, account, tax and so on)
=> How will you keep this information correct in the migrated instance without having 2 fields on the invoice... I think it is just impossible. How will you handle that ? If I made 100 invoice to that Company XY, I still want to see 100 invoice belonging to them... Not for example 30 to "Department B, Contact 3", 50 to "Department A, Contact 1" and the rest to "Company XY" directly.

 Conclusion:
-------------------

The corrections you bring here are very welcome in any case and make sense, but it is still not enough from my point of view. I understand you want to simplify the DB model by having only one table. I'm not in favor of that one, but ok, it's done. IMO you can let it be, but not without leaving 2 fields on invoices (and other concerned models)... one representing the contact, one the partner. This way, you solve lots of troubles. They suggestion made by Raphaël here tend to solve that point, cause it's not only related to invoices (take my point on the claim for example). I do not know if the implementation of it is good, not enough time, but on the principle, having two fields on every model related to partner is mandatory no matters how.

I mean, if we can have more than one in the SO, where is the trouble to have various on other objects as well ? It is always like that in other software, users are used to that... This will solve A), C),D), and E). The B) one still need to be fixed.

Fixing this very last (not least) thing will make a proper solution IMO. You'll keep only one table for partner and contact, we (as a community and users) will have a way to address our business properly, the migration process would then be able to keep the informations as it was (and this is the minim expected right ?).

I hope this helps, thanks for reading and please consider my remarks.

Keep going,

Joël