Comment 147 for bug 1160365

On 14/04/13 16:26, Ana Juaristi Olalde wrote:
> @Fabien:
> Let me say again that I'm not agree with your comments here:
> - the address to send the quote to must be the one of the contact, not the company
> NO. The address to send the quote IS an address belonging to company. Not more, not less.

Yes, it's the same. The address of the contact is the same than the one
of the company (at least the postal address, the email address not).
It's just that one company may have several offices, so you have to use
the right one (the one where the contact is working).

> - the delivery address to use depends on the contact, not on the company (If Sandro buys sth, we have to deliver in Bruxelles, not in Grand-Rosiere, even if both GR and Bruxelles are defined as valid delivery address, and sandro is just a contact)
> No, SANDRO could buy something to be send to Grand Rosiere. The pales where you are sending goods is totally independent on Contact/people making the sale order and ordering WHERE (address) he want's to send goods.

Yes, OpenERP just does proposition in the sale order. The user can
change and put whatever address he wants. The proposition algorythm will
use the address which is set as a default for the delivery. If there are
no default, it will use the office of Sandro by default (but you can
change and deliver to another office if you want).

> Real example: Yesterday was my birthday. Someone outside my company and of course my home address sent me pink flowers. He ordered for me to a different address where they live or work. Nothing more. I'm not the flower shop's customer, my address is not part of the structure the orderer has got. I received the flowers but I did not pay any invoice. Real case where you need having registered an address to sent goods but this address doesn't belong to ordering partner. So... on this case you need 2 keys on picking (partner who is ordering, who is going to pay and address(contact) where you are sending goods)

Happy birthday, even if I am one day late.

> - the pricelist depends on the contact, not the company
> I don't know any real case where you define different pricelist depending on contact. You say international sites for a company could have different prices on each country but... I don't know any company in the world that if they are placed in different countries they don't have different VAT on each of them so THEY ARE different PARTNERS no contacts.
> Let's say ZARA Spain, Zara USA, or ZARA japan... I'm sure they are owning different vat numbers on each country and YES, they are part of a group so they need parent_id to be related between them in order to obtain group statistics.

Usually it's not, the pricelist is the same for the whole company by
default in OpenERP. But, we can imagine the other scenario in B2B,
working for big companies. It's not a matter of country but department.
Some companie, like Caterpillar in Belgium, are so big that you can
apply different strategies according to the department you sell to.

I am not telling it's the default use case. The default use case is to
have the same pricelist for the whole company. I am just telling that
it's possible and the data model allows this.

> - even the fiscal position may depend on the contact, not on the company
> Not in Spain. I don't know in other countries but... I don't know any case where fiscal position is depending on contact. Contact could be a contact or an address and fiscal settings and rules are ALWAYS related to partner. Otherwise it's ilegal.

I am not telling it's the default use case. The default use case is to
have the same fiscal position for the whole company. I am just telling
that it's possible and the data model allows this. (e.g. taxes that are
different by states, in the same country. So, if a company as several
offices, you have to select the right one)

> About trying to configure real cases... Yesterday, I tried to test Olivier's base_contact branch. I expended a couple of hours trying to set a real basic structure. It's supposed I'm advanced user and I have not been able to do it. Just read my comment #134. I stopped just because I couldn't so... how is it suposed to work a basic final user?

Please note that base_contact is not finished yet. We did not code
reviewed it yet.

> @maxime, thank you for your example. It's just very basic and similar to those that I tried to write here and I agree with you but I'm afraid that they are not going to recognize there is a conceptual basic problem on model so any example we can write will be not seriously considered.

No, it is seriously considered. If I did not consider you, I would just
stop reading and answering this thread. I don't care who is right and I
am not trying to defend our solution. I just want to be sure we chose
the best solution and that the reasons are clear for everyone.

Fabien