openerp-community team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

Hello,

It's quite easy to add a relationship between contacts to simulate the
features of base_contact on v7. Or to allow several level of parents
instead of only one. (as the structure is already a real tree structure)

We already promised such a module to some OpenERP Enterprise customers
using base_contact, so we will develop it in a few months, when they
will need to migrate.

> On the other hand, it is often confusing for customers how to work
> with these advanced address relation systems.

Yes, one could argue that it is an important feature to have several
addresses for one partner but when we started to analyse how customers
REALLY use the v6.1 contact mechanism, we noticed that often, if it
existed several addresses for a partner, the users still created several
partners. (instead of several address for the same partner)

And, when doing lambda tests, the users did not understood the
differences between partner, address and contact.

With v7.0, all our lambda user tests says the same; it's crystal clear.

And I don't even talked about the mess of all the modules
(base_contact_crm, base_contact_sale, ...)

> 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 !

It's already done/fixed in trunk. It has been fixed by QDP 2 weeks ago,
following the advice of Luc. The journal items are at the name of the
company, not the person.


On 12/04/2012 04:10 PM, Geert Surkijn wrote:
> 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
> 
> _______________________________________________
> 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


-- 
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com