Odoo Server (MOVED TO GITHUB)

Bug #1160365
Comment #127

Comment 127 for bug 1160365

Revision history for this message

Ana Juaristi Olalde (ajuaristio) wrote on 2013-04-12:

#127

OK... Testing as asked by Fabien in Runbot.

Sale order:
Customer ACME Company Walt disney studios 444444444 Orlando, FL 33333 United States
Invoice Address John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States
Delivery Address Agrolait 69 rue de Namur 1300 Wavre Belgium

It seems quite extrange to be allowed sending goods to Agrolait when it's another partner, but... extremly it could be. (Bug easily can fixed including right domain on sale order)

Going further:
Picking is correctly set to Agrolait. Sales order printing is correctly printed but is showing also John Doe's home address.

Next step:
Create invoice from picking:
Customer John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States
FOR ME THIS IS TOTALLY WRONG. INVOICE CONTACT is John DOE, but... INVOICE ADDRESS SHOULD BE the one from ACME
What am I doing wrong here?
....
Now: Journal entry
Invoice Name Partner
SAJ/2013/0003 / ACME Company

It is made against ACME Company, so... it's right.
---
Conclusions:
1. I can not register contact with their own addresses or contact fields, If I want, I have got to duplicate them but... what for? If I can not use them on documents?
2. With the simple, real example, I can confirm that WE DO NEED at less Partner-Address table, even if in your new aproach there is only a single partners table to register also contacts/employess. I mean...
If you define Address, with only address fields as they are street, country, Zip... an so on... you could save more than one problem easily with your datamodel aproach. It's same aproach that we have with banks. Noone can think about creating a new partner to have a new bank for a partner. Same for addresses.
3. If you allow having related:
Partner --> N address
Partner --> N partner
Address --> N partner
You have got Well built base_contact on this case but... having reused your partner single table. That would be an improvement over last versions since you don't need having duplicate fields on several tables.
On Documents you only need having links agains address, instead of partner as it was before. But... you will be reusing partner table for setting, contacts, or employees or any other conceptual object meaning also person.
It's very very easy.
Please tell me if I'm wrong and why I'm wrong.

@Olivier: Is there any place where I could test also base_contact 7.0 aproach? I would like to see if it's solving something more. Thank you!
Ana

OK... Testing as asked by Fabien  in Runbot.

Sale order: 
Customer 	ACME Company Walt disney studios 444444444 Orlando, FL 33333 United States
Invoice Address 	John Doe for Acme Company (ACME Company) John Doe Home Address  3838383838 Myhome, FL 2222 United States
Delivery Address 	Agrolait 69 rue de Namur 1300 Wavre Belgium

It seems quite extrange to be allowed sending goods to Agrolait when it's another partner, but... extremly it could be. (Bug easily can fixed including right domain on sale order)

Going further:
Picking is correctly set to Agrolait. Sales order printing is correctly printed but is showing also John Doe's home address.

Next step:
Create invoice from picking:
Customer 	John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States 
FOR ME THIS IS TOTALLY WRONG. INVOICE CONTACT is John DOE, but... INVOICE ADDRESS SHOULD BE the one from ACME
What am I doing wrong here?
....
Now: Journal entry
Invoice  Name  Partner
SAJ/2013/0003	/	ACME Company

It is made against ACME Company, so... it's right.
---
Conclusions: 
1. I can not register contact with their own addresses or contact fields, If I want, I have got to duplicate them but... what for? If I can not use them on documents?
2. With the simple, real example, I can confirm that WE DO NEED at less Partner-Address table, even if in your new aproach there is only a single partners table to register also contacts/employess. I mean... 
If you define Address, with only address fields as they are street, country, Zip... an so on... you could save more than one problem easily with your datamodel aproach. It's same aproach that we have with banks. Noone can think about creating a new partner to have a new bank for a partner. Same for addresses.
3. If you allow having related:
Partner --> N address
Partner --> N partner
Address --> N partner 
You have got Well built base_contact on this case but... having reused your partner single table. That would be an improvement over last versions since you don't need having duplicate fields on several tables.
On Documents you only need having links agains address, instead of partner as it was before. But... you will be reusing partner table for setting, contacts, or employees or any other conceptual object meaning also person. 
It's very very easy. 
Please tell me if I'm wrong and why I'm wrong.

@Olivier: Is there any place where I could test also base_contact 7.0 aproach? I would like to see if it's solving something more. Thank you!
Ana