@Fabien & @odony

Well, I start to be desperate here honestly... Let's move this forward. WE NEED A CONCRETE SOLUTION, not arguments. As you said Fabien, lets talk about FACTD and BUGS. I remind you that I took the time to test your suggested solution and provide a FEED-BACK about : what's good, what's still a bug, what's still unsolved... See #34: https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/34

=> I receive back from you print screens instead of solution/way to solve the remaining trouble faced/discovered. This is not the way we will solve this problem. I try once again to be exhaustive on all points raised that need a solution, please prove us you get an answer for each of them with what's suggested:


 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... 
=> this is a bug I think and can be fixed allowing to invoice Joel in Invoice (mean allow to invoice "invoicing" partner"), you agree ?

 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 ? 
=> This is a bug and can be fixed, you agree ?

 C) In the case invoice are related to "Joel (Camptocamp)", the sales turnover for Camptocamp is not correct (from Reporting -> Invoice analysis menu, not from grouping invoices,...). 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 as part of Camptocamp history, nor it'll group them properly using the Group by... Child of stuff isn't good because of performance issue (try grouping even the account.move.line when you have 30K => it doesn't work in v7.0 and there's no child of here) + very difficult to implement when using third party reporting system + Raphaël is right : https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/85
=> This is not a "technical" bug but a huge/not acceptable usability issue. Only solution is to store in DB the partner_id + contact_id in the way old schema implemented it. Don't care if you name them commercial_whatever_id. We need it in DB for external system + group by +  perfs reasons that's all.

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:
  - Group Company XY
     - Company A
         - Department A, Contact 1
         - Department A, Contact 2
     - Company B
         - Department B, Contact 3
 => This is mandatory that you can invoice Company A, for submission to "Department A, Contact 1" or "Department A, Contact 2". We do need two fields on the invoice... Because even if properties are correctly set (the only bug you saw and correct here), we can still make invoice addressed to Contact 1 or 2 depending on the project (cause they are they people to validate the invoice internally), but still, the invoice belong to Company A, will be paid by Company A and the turnover belong to Company A not invoicing Contact 1 or 2 !!! Using group by must show this as it was in previous version.

 E) Now migration (done by your service). We get strong trouble because before migration, those WERE good, and aren't any more:
     - Turnover by company is right because based on partner_id (through analysis or whatever group by)
     - Invoices to various department/contact for the same partner/company based on contact_id can be done
     - External link to other systems that are based on the 6.1 data model... 
=> How will you keep this information correct / backward compatible in the migrated instance without having 2 fields on the invoice (or other objects) I think it is just impossible. How will you handle that ? 

 F) Another trouble for migration (still done by you):

Before migration:
Invoice open to Company A, Contact M. Martin => Invoice printed and sent to M. Martin in Switzerland while Company A is in Sweden. 

After Migration (and you've done it):
Invoice open to Company A, no more contact => Print out the invoice, and send it to... Company A in Sweden !!??!?

=> Again, if you do not store 2 fields, you cannot guarantee backward compatibility here right ? Or what solution do you have ?

 G) All modules in standard addons or community or whatever will have to be rebuild them to use what you suggest with your "commercial_entity_id" so why not using the Raphaël's way that keep backward compatibility, while still keeping you DB schema and views simpler as you liked to have ? 
=> Any concrete reasons or facts on that ? I mean in both cases there is work to be done, just the solution you suggest need more... Or I may be missing something?

H) You said : 
"""Don't make we wrong. The change in the semantic in v7 is the following:
  - In v6.1, "Joël, Camptocamp" was an address of Camptocamp.
  - In v7, "Joël, Camptocamp" is a person representing the "Camptocamp"
    company.
    ....
It means that someone representing the company "Joël" can do a purchase
for the company and it's not the same situation than having a purchase
in the name of Camptocamp. (e.g. in Belgium you can break a contract if
you can proove that Joël did not had the right to sign for Camptocamp)

In terms of data model, it does not change anything as:
  - on the invoice, you have the link to both (directly or indirectly,
    depending if we add a related field)
  - on Joël, you have the link to what he purchased
  - on Camptocamp, you have two fields:
      - invoice_ids: what C2C bought directly
      - invoice_commercial_ids: what C2C and Joël bought (or child_of
        if you don't want the related field)

Note also that "partner_id, address_id" is not exactly the same than
"partner_commercial_id, partner_id". The semantic really changed, it's
not just a switch in field names.
"""
About what you're speaking here ? V8.0 ? No such a fields (invoice_commercial_ids) are present today on the partner, nor the foreign key on the invoice... this is all we ask for.. Keeping the info backward compatible by having both partner_id and commercial_entity_id on the invoice and ALL OTHER OBJECTS if needed (picking, claim, opportunity,...). And if this is the direction, why not naming them as before so we don't have to change everything everywhere..

=> What is the concrete solution implemented for v 7.0 !? As Guewen said, we are facing trouble right here, right now and need a solution for v7.0. We know we'll find a way to deal with that better in the future, our concern is 7.0.

Now:

 * Do not say in any case you'll have to rework your module, cause fixing little views issues is almost nothing, fixing the whole Party DB schema is another story and you know it => this is part of the reason why you don't want to go back on this point !

 * I pay OPW for smooth migration AND backward compatibility guarantee... If you break stuff here, what I'm suppose to say to my customer. I don't care about OpenERP's reasons to do that here. I want (as all my customers) retrieve back the same informations after migrating, no matter the DB schema or whatever... I just care about having the same results in my OpenERP instance (see case E, F & G)).

 * Why the hell is it so difficult to make an exception in the release policy when you break something so badly (mainly F, G & H). We do need 2 fields, and stored one, name them as you like if keeping the old name doesn't suits you. And we do need them not only on invoices, we don't want child_of crap if it can be avoided just by adding a single field on business docs that BTW was always there !


Please, we do understand your move here. We know it's for good reasons (or at least I understood them even if not agree 100%). We also sure that in the future, it'll be a good move, with the advantages you pointed out.

BUT we're living with 7.0, our customers are moving to it. We, partners and customers, ASK AND BEG YOU to keep the backward compatibility. I gave you all the points here, answer them and make them work.


Thank you for reading,

Regards,


Joël