Comment 3 for bug 1160365

On 03/26/2013 04:03 PM, Raphaël Valyi - http://www.akretion.com wrote:
> So are you YES or NO actually going to add new contact_id fields on
> business documents? (like we were referring as the B) solution in the
> original bug) ?

No, the proposed solution doesn't include that. The idea of unifying the
partner structure in 7.0 is that a contact is a first-class partner. It can
sometimes delegate some of its properties to a parent entity (or copy them),
but for most purposes it can be used directly.

> You says "A) Let the "commercial party" for a partner be the person or
> company that is used as reference for all invoicing/accounting matters" Is
> that supposed to be the existing partner_id field or a new field (stored or
> not) ?

It's not a stored field, it's a definition. It could be a new stored field in
the future, as I mentioned in the "Further refinements" section, but that's not
planned for 7.0.

> How that Olivier?
> Look at the following piece of code in the account/account_invoice.py file
> (there are dozens of such cases if not hundreds considering also the sale,
> purchase, stock and main community modules):
>
> pay_pro_id =
> property_obj.search(cr,uid,[('name','=','property_account_payable'),('res_id','=','res.partner,'
> +str(partner_id)+''),('company_id','=',company_id)])

This (rather ugly) code will work just fine with the proposed solution AFAICS.
If the account_payable property was explicitly set on the parent company, it
will be copied to its contacts (that's part B), so this code will find it. If
not, it will fall back to the default for the property in both cases.

> You can make a contact inherit whatever you want form its parent company: if
> partner_id is suddenly allowed to be just the id of the contact record, that
> property search will fail to find the property attached to the company
> record one. But this is just a quick example: any search/domain involving
> partner_id will not work out of the box at all and lead to regressions very
> hard to spot.

We think it will work in most cases, and we will be searching for possible
issues before finalizing the solution. If some can be identified we'll have to
examine the options.

> Also, I would like to insist that reading accounting/financial/fiscal data
> isn't limited to the account module. For instance, in many situations
> (specially sales bewteen sovereign states such as international commerce or
> inside federal countries), you may need to read fiscal data right from the
> sale order to find out the right taxes to display. So for instance if
> partner_id can be a contact in a sale order or a purchase order, well all
> the fiscal-rule framework (a pillar for our localization but also used in
> international e-commerce) is broken
> https://launchpad.net/openerp-fiscal-rules

By default all invoicing/accounting-related data will be copied/synced by the
res.partner model itself; the account module will simply extend the list of
fields to sync. If extra partner fields are added by other modules they can
presumably extend the list of fields to sync, just like account would do it.

Could you explain with a specific example what would not work based on the
proposed solution?