← Back to team overview

openerp-community team mailing list archive

Re: company address design in ver. 7.0.

 

Hello,

Both approaches have their advantages and disadvantages. We have adjusted
our addons in preparation for 7.0 and in the beginning there was some
doubt about it, but now we like it. The possibility to make sales to
consumers is a plus. In our examples however, we miss the possibility to
connect one contact to several Companies. On the other hand, it is often
confusing for customers how to work with these advanced address relation
systems.

So from the customer's point of view we are not that negative towards
these changes...

-----Original Message-----
From:
openerp-community-bounces+geert.surkijn=catsanddogs.com@xxxxxxxxxxxxxxxxxx
t
[mailto:openerp-community-bounces+geert.surkijn=catsanddogs.com@xxxxxxxxxx
chpad.net] On Behalf Of Etienne Hirt
Sent: dinsdag 4 december 2012 11:57
To: openerp-community@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openerp-community] company address design in ver. 7.0.

Hello,

This reminds my of my craints when i got to know that base_contact was
removed from 6.2 branch. Anybody else concerned with the base_contact
approach for 7.0?

On 24.08.12 I sent to the list the following Email text:

> The location in 6.1 was a good approach as the address remained the
> object so assign to all other modules. This was not the case in 6.0
> where many modules had to be adapted to cope with jobs instead of
> address (and the address was used as location).
>
> We finalised the 6.1 approach with the missing features from 6.0 (see
> https://code.launchpad.net/~openerp-community/openobject-addons
> /trunk-> bug-923440-base_contact_finalise6.1)
> and will soon migrate to 6.1 such that we can use all modules with the
> address.
>
> I hope that a good solution in Version 7 will be prepared.

Best Regards

Etienne




On 04.12.2012 11:43, Joėl Grand-Guillaume wrote:
> Hello,
>
>
> This is a big deal of troubles... No answer yet, but we/they need to
> find a way. Same mess with invoice reconciliation... Make a SO, choose
> a partner A (company checked) as SO's partner, partner B as an invoice
> address, then you cannot reconcile both. Payment will have to be made
> by partner B, which is obviously not the case, the company will pay,
> not the contact !
>
> We had a talk with OpenERP on that.. No answer yet :(
>
> Regards,
>
>
> Le 3 déc. 2012 ą 14:44, Normunds Vilcans <normunds.vilcans@xxxxxxxxxxx
> <mailto:normunds.vilcans@xxxxxxxxxxx>> a écrit :
>
>> Hello!
>>
>> They changed the whole design again.
>> It seems, that previous design was not good enough for B2C, and
>> somebody argued that too complex (may agree on that).
>>
>> But just simple use case revealed substantial problems in new approach.
>>
>> If we want to define a new location for a Partner e.g. warehouse, we
>> should create a separate  Contact for each Partner's location now.
>> This leads to multiple similar partner entries in database, what
>> leads to a mess in partners database, for example if you have over
>> 1000 partners and accounting mess.
>>
>> Example is demo db: Agrolait (is company checked) Define for them
>> Warehouse (contact, is company not checked, address type set
>> Delivery).
>> then define Warehouse 2 , then more locations.
>>
>> At the end you will have in your partners database a lot of Agrolait
>> (Partners/Contacts)
>> Agrolait
>> Warehouse (Agrolait) (cause linked to Agrolait ) Office (Agrolait)
>> Shop (Agrolait) Main Office (Agrolait) Main Office (Other BIG
>> company) Warehouse (Axelor) Axelor itself etc.
>>
>> The funniest thing is at the end:
>> Your Sales manager can directly issue an invoice for your partner's
>> Shop (Agrolait) or your partners warehouse Warehouse (Agrolait).
>> Of course, this will be reflected in accounting too, lets say in
>> "Aged Trial Balance". Not expected?
>> Or you can issue a separate VAT declaration for your customer's "Body
>> Shop" in Brussels... one for customer an another for it's shop.
>>
>>
>> I would like to hear some comments from community  regarding this.
>>
>> Additional question to OpenERP S.A. : do you make any functional
>> research at all, before making such a big changes?
>>
>>
>> --
>>
>> Normunds Vilcans
>> Alistek, SIA
>> Tel: +371 67964296
>> Fax: +371 67964296
>> Mob: +371 29721272
>>
>> <alistek_logo.jpg><="" tr="" border="0" align="left">
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> <mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>
> --
>
>
> *Joėl Grand-Guillaume** *
>
> *Division Manager*
> *Business Solutions*
> *
> *
> *Camptocamp SA*
> PSE A, CH-1015 Lausanne
>
> http://openerp.camptocamp.com/
>
>
> Phone: +41 21 619 10 28
> Office: +41 21 619 10 10
> Fax: +41 21 619 10 00
> Email: joel.grandguillaume@xxxxxxxxxxxxxx
> <mailto:joel.grandguillaume@xxxxxxxxxxxxxx>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


Follow ups

References