2012/8/20 Ana Juaristi <[email protected]> > IMHO this new aproach is not making things easier but its erasing very > valuable functionality. The first structure customer/address/job/contacts > was able to support any kind of structure, even if it was simple or very > complex.
The problem is that in 99% of the cases, the companies use 1 customer/ N address/ 1 or N contacts. For them, base_contact was a pain in the ass because the specific details of the contact (job contact as you mention) regarding the company it's linked to, but there were other modules that handle with that properly. > In version 6.1 is still possible defining this complex structures but > loosed usability since we have got a new object "location" including again > address fields and duplicating information. That is.. now we have got > customer/address including many2one to location and many2one to contacts. > Adress now is "similar" to job before. Not exactly the same. > The structure by default is 1 customer / N address / 1 contact (for each address). It can be ok for a lot of companies because they handle 1 contact per address or because they can leave empty adresses and link one contact to them. From my point of view, this is a good approach. > > In 7.0 I don't even see this option of creating several addresses with > contact functions on those addresses. > 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? > > On the other side, IMHO (again) invoicing to a contact is not legally > allowed at less in Spain. Normally we have got several contacts in a > company but the legal fiscal entity, with fiscal information (like VAT or > others) that we invoice to is only one. The company. > For that, there's a new checkbox in res.partner call "Is a company?". So you can have companies, contacts (not checked "Is a company?") and individual companies. The concept can be ok, but IMHO some changes should be made: 1) Customers and contacts had to maintain to different menu entries, with filters in "is a company" by default. 2) Sale, purchase, invoice... had to filter also companies and contacts. Right now I can interact with a contact in those cases which, as Ana says, it's totally wrong. > Conceptually a contact is different from a customer so for me it's totally > right that they are 2 different structures with 2 different menu entries. > Ok, I should have read before your next line. ;) > > I'm afraid I don't like at all the changes that we are having with the > simplification of the system on basic things that were working perfectly > before. Simplifying usability is not loosing functionality so If it was > possible I would ask mantaining base_contact as it has been always, giving > people possibility of installing it or not depending on their needs. Instead of giving priority to base_contact (none of our customers uses it) I would focus on the address issue mentioned above. I can't do something so simple like invoicing and sending some products to differrent addresses right now. Maybe I'm missing something, I can't see any address in the delivery order. > If someone uses OpenERP b2c, could be ok but for b2b, would be strongly > needed having a complex structure compatible with older versions. > > Thank you very much: > > Ana > > > > > 2012/8/20 Fabrice Henrion <[email protected]> > >> Hello,**** >> >> There is some information here: http://www.openerp.com/node/1169**** >> >> Best,**** >> >> __ >> Fabrice Henrion >> Director of Business Development Americas**** >> >> OpenERP Inc. >> 399 Bradford Street – Suite 101 >> Redwood City, CA 94063 >> Tel: +1 (650) 307-6736**** >> >> http://www.openerp.com**** >> >> ** ** >> >> *From:* [email protected][mailto: >> [email protected]] *On >> Behalf Of *Mark Oellermann >> *Sent:* Monday, August 20, 2012 12:45 PM >> *To:* Carlos Liébana >> *Cc:* [email protected] >> *Subject:* Re: [Openerp-community] uninstalling base_contact**** >> >> ** ** >> >> Hi,**** >> >> We implemented base_contact because it is a better model for the world we >> deal with (large companies with multiple offices, and with consultants and >> project managers that change or perform multiple roles often). The book and >> documentation around 6.0 all made base_contact sound like it was a central >> (supported) element of OpenERP but we've been disappointed to find that the >> implementation was a bit half-baked (installing it turned all "contact" >> references in other modules to "address" type references).**** >> >> ** ** >> >> We muddled through a 6.1 upgrade and adapted everything to suit the "new" >> base_contact model which was better in design but still pretty broken in >> implementation. Now I see that there's a new model coming in 7 again. Aside >> from me trawling through code, does anyone have (or can point me to) any >> documentation or a brief description of what's proposed for 7?**** >> >> Cheers,**** >> >> Mark**** >> >> ** ** >> >> On 21 August 2012 03:29, Carlos Liébana <[email protected]> wrote:* >> *** >> >> Has somebody backported current 7.0 contact approach to 6.1?**** >> >> 2012/8/20 Stefan Rijnhart <[email protected]>**** >> >> On 20-08-12 09:02, Eric Caudal wrote:**** >> >> Isnot there a module that does the opposite? Migrate the contacts from >> 6.0 to 6.1 new model?**** >> >> ** ** >> >> ** ** >> >> Such a script is included in the OpenUpgrade project, contributed by >> Credativ: >> >> http://bazaar.launchpad.net/~openupgrade-committers/openupgrade-addons/6.1/files/head:/base_contact/migrations/6.1.1.0/ >> >> See also here for a standalone SQL script: >> http://www.openerp.com/forum/post101890.html#p101890 >> >> But migrating from 6.1 base_contact to 7.0 base module is a different >> thing, actually. >> >> Best regards, >> Stefan. >> >> >> **** >> >> -- **** >> >> Therp - Maatwerk in open ontwikkeling**** >> >> ** ** >> >> Stefan Rijnhart - Ontwerp en implementatie**** >> >> ** ** >> >> mail: [email protected]**** >> >> tel: +31 (0) 614478606**** >> >> http://therp.nl**** >> >> https://twitter.com/therp_stefan**** >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp**** >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp**** >> >> ** ** >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> > > > -- > Ana Juaristi Olalde <http://www.anajuaristi.com/>: Personal phone: 677 93 > 42 59. User/usuario skype: Avanzosc > CEO Avanzosc, S.L <http://www.avanzosc.com/> : Office phone / Tfono > oficina: (+34) 943 02 69 02 > www.openerpsite.com > > > > > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
