Fabien. About this |||||||||||||||||||||||||||| - commercial_id is not required on all objects as it's exactly the same than partner_id.commercial_id, so we will just put it where it's required as a technical artifact to allow specific reporting, not everywhere. |||||||||||||||||||||||||||| It can not be a function, this is a real problem, In V6.1 what you are calling inconcistency, we are calling loss functionality, and for sure it is not a base_contact task (this is for other purpose i think) I think here we have a misunderstood, with this or i forgot something. I can have (in real cases in 7 countries I used this feature) Case 1: "Subsidiaries" ================ 1 Partner -- > Several Invoice Addresses: This is called "Subsidiaries" and it is not a "Functional Field", we "With business approach" had __ automated some assignations __ but basically it is NOT at all a function field and less "Read Only". Ah and BTW: We use this a a "Fiscal Requirement " in México, in VE 1 partner >> 1 Invoice address (This is why we didn't see it before) In this case the Address is "Just" A contact. Extra Information: We developed in the past some constraints for Venezuela because we can not have 2 invoices Addresses for one partner, with V7 we __just__ remove the constraint to other object. Results: ====== Pro: Oliver solution works Model Works, because you lock what was not locked. Cons: But it is Incomplete in terms of what we had in V6.1, more freedom and inconsistencies, but easily customizable by constraints We did several Times and we dont have problem to migrate our approach but with the same base data model --at least in terms of number of fields--). Sol: ???? Accounting PoV: ============ In this case all accounting information was taken from the partner itself, in this point, what we got with new version is the same, (Oliver Approach). From Reports: =========== All was consolidated to the same partner, I don't know if it is in this way yet, i couldn't find the way with Oliver approach. In this Point is important, and very important, that you consider, in the past the report was: SELECT * FROM object WHERE conditions GROUP BY partner_id; What ever you decide different to this, is a regression in terms of performance, we __must__ to solve this IMHO. FYI we have a big deal (H**) Fabrice can support me on that with something like 15k Invoices PER DAY, imagine the problem with an approach in reports with python code ;-) I think it can be solved easily, I am sure you will offer a good approach (or a workaround considering our PoV) Case 2 : "Consortium" ====== 1 Partner > Several Partners Childs_Of with Total Different "Fiscal Information" this is called "Consortium" In V6.1 we had the field parent_id (not used in any place in the core) that allow us build this feature with taking as pivot you old model. Then, we simple fill a Partner with is own Fiscal information, and in any time, i can move freely as part of any "Consortium". It was used by us to consolidate too! every partner had his own Fiscal and legal Information separatelly, but i could in any time (with just one method of 10 lines) even allow the parent Partner pay the bill of the child parents even in a recursive way (child > father > grand father > grand grand father). [Yeah the Fiscal planification in México is a Mess but OpenERP solved it until v6.1 without even know it ;-)] This is a real case in México, and even tools of 300USD had it. Results: ====== pros: Oliver approach insert the concept of dont delete the parent id one time it is created. cons: - it is technically so complex now, because it is not part of the simple recursive data model, now we need to deal with a lot of more variants and in python code - more dangerous even - Why? because in python side we can have several mistakes that erase, delete, modify the base information, that you can makle in a report but not in data itself. - We lost the infinite multi-level data structure (because by functionality it if blocked in views) - We lost the ability to just take off the domain in case of "Sales or Purchase to consortium", it means, in this case you will sale to C2C and Invoice to Agrolait, but you were attended by Akretion, and send goods to Vauxoo, total different Fiscal entities where we just taking off the domain comply with this feature, now I am a little missed what will i do. sol: ??? Comments: ======== I know you think this case is inconsisttent (you said before) but in consortiums it is totally correct, and --before-- the solution was __just take domains__ now? From Reports and accounting: ====================== The old approach didnt make anything with this if you give me one efficient report i will be happy, i can migrate my solutions to your proposal. ============================================================================================================== Footer Note: I am talking about accounting, because for us it is the lower level of granularity in an ERP, but we didn't test Purchase (it create Supplier Invoices) Sales (Customer Invoices) Picking (Cost Accounting related with locations), Human Resources (Third Party payments), ...... , We in vauxoo our First and most important approach is accounting with this specific 2 cases. I continue testing. About Raph Solution: I am agreed on the extra field, i read the code, and I think is better improve or even modify the core to finish the new functionality, at the end of the day i think it is job of OpenERP and Fabien is open to solve case by case, AM I RIGHT FABIEN?. @Fabien: We need to think correctly in the extra module, to avoid have to change the name and technical problems in the future IMHO the module done (and it in NOT base contact) must be strong enough to be merged as a 'Feature' In V7.0 Thanks A LOT for your time and the time of EVERYBODY.