Comment 163 for bug 1160365

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.