openerp-community team mailing list archive

[Carlos Liébana <carlosliebana@xxxxxxxxx>]

Hello,

2012/8/22 Raphael Valyi <rvalyi@xxxxxxxxx>

> Hello Carlos and others,
>
> I'm answering inline below:
>
> On Tue, Aug 21, 2012 at 8:13 AM, Carlos Liébana <carlosliebana@xxxxxxxxx>
>  wrote:
>
>>
>>
>> [...]
>>
>>
>> I don't see it either. It seems that now contacts are linked to the
>> company itself (which may be correct in a lot of cases) but as you mention
>> it should be possible also to do it against several addresses. But what
>> worries me the most is how to deal with several addresses, and why this
>> feature has "dissapeared" in v7 by default. If there's not
>> "res.partner.address" anymore, it won't be usable in a lot of cases, above
>> all manufacturing and logistic industries.
>>
>> Can somebody from OpenERP SA explain this, please?
>>
>
> You guy frightened me a lot with this statement: "oh shit! they wouldn't
> dare removing the multi-address feature, would they?"
> Fortunately, the multi-address is still supported! The trick is to go in
> Settings/Sale and then enable the checkbox "allow a different address for
> delivery and invoicing". Then you'll get your beloved address fields back...
>

Ok! Thanks for your help, I didn't see that. What frightened me is that
"unique" address coming by default is not populated on delivery orders, so
no address is available there. Something strange, even with one address for
partner.


>
> Actually, speaking specifically about this feature I support the new
> approach: at least in the many small companies where they don't care about
> such different address you can hide the field. Generally speaking they
> finally put an end to that non modular "advanced" trash god group you would
> need to enable anyway in previous versions. Now, that's more modular,
> that's better.
>
> As for the base_contact features, well, I won't comment on them because I
> don't know that module very well, so cannot compare with the new features.
> I would tend to trust Ana instead, unless proven otherwise.
>
> As for the migration scripts from openupgrade I support the initiative too
> as not all our customers are willing to go with the Enterprise contract
> (specially when they are just a bit upper the pricing thresholds), so
> having migration alternatives is a must. Thanks to the authors, we will
> certainly help when facing non Enterprise migrations (not the job we
> prefer, but it might still be worth not loosing our customers neither
> support them on oldish versions).
>
> Best regards,
>
>
> --
> Raphaël Valyi
> Founder and consultant
> http://twitter.com/rvalyi <http://twitter.com/#%21/rvalyi>
> +55 21 2516 2954
> www.akretion.com
>
>