Odoo Server (MOVED TO GITHUB)

is res.partner.address is going to disappear?! oh my!

Asked by risto3

Sorry, I just noticed that this is probably a better place to pose this than in the fora which seem to go unnoticed.

=============,

Monitoring trunk I noticed that res.partner.address seems to be slated to disappear in v7 and is deprecated in 6.2.

As things in 6.1 stands, this is a serious and major regression for accounting.

Currently, partner companies (clients and/or suppliers) are a single res.partner object (with company registry location/number for the legal entity) and the associated addresses contain at least the head office address with its association establishment number.
Other addresses for the legal entity are added for secondary [registered] establishments, depots, worksites and the like.

Accounting wise, it is the legal entity (res.partner) which is associated to the supplier or client accounting document with the pertinent address selected.

I believe it is wrong to delete the object as it is crucial, perhaps keep it for 'company'- oriented cases.

Thanks in advance for clarification

==================
in
I mentioned the following:

"res_partner has VAT number, but what is missing is the unique company identification number (in France, the VAT number is derived from the SIREN), potentially required when is_company = true.
As well, it would be useful to support the legal establishment identification number (SIRET in France) on res_partner_address, which is also unique.
res_partner_bank should potentially use res_partner and a res_partner_address rather than free text for the address fields to make iso20022 easier to implement.

l10n_fr_siret is a good start for France, but forces a new partner for each establishment (not practical)."

and

"I notice, finally, that actually 'vat' and 'company_registry' are incorrectly on the res.company object instead of the res.partner object and that in trunk, l10n_fr wants to put 'siret' and 'ape' as well in res.company instead of res.partner (for 'ape') and res.address (for 'siret').
Please see my forum entry question regarding res.address. "

and

"btw, at least for france, officially, the company registry (SIREN) needs two items, the company number and the 'greffe' or law office of the tribunal serving the chamber of commerce where the company headquarters is located. "

perhaps this is currently applies to addons as l10n_fr is found there, but given company_registry is in server..

Question information

Language:
English Edit question
Status:
Answered
For:
Odoo Server (MOVED TO GITHUB) Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
mzunino (emezeta) said : 		#2

Oh, boy please, tell me that all about this was none but a kind of pure written terrorism!
Thank you.

ps: whether this question remains expired/unanswered, please point out to where could we meet some reliable information about the issue.

        emezeta.

Revision history for this message
risto3 (risto3) said : 		#3

Hello, I'm not sure if emezeta is asking me to respond or whether he is asking as well for more details...

What I can say is it is clear from the trunk sources (openerp/addons/base/res/res_partner.py) that res.partner.address is deprecated (find the comment) and absolutely no information about migration.

If it actually, really, goes away, then there is a huge problem because in accounting records, invoices (both supplier and customer) point today to res.partner (the legal entity i.e. organisation)

Here is an extract from account_invoice:
        'partner_id': fields.many2one('res.partner', 'Partner', change_default=True, readonly=True, required=True, states={'draft':[('readonly',False)]}),
        'address_contact_id': fields.many2one('res.partner.address', 'Contact Address', readonly=True, states={'draft':[('readonly',False)]}),
        'address_invoice_id': fields.many2one('res.partner.address', 'Invoice Address', readonly=True, required=True, states={'draft':[('readonly',False)]}),

Deprecating res.partner.address pulls the rug out from under partner companies with multiple sites or organisation units *UNLESS* the equivalent is added added as an additional relation to res.partner.

This is the reason asking the question, a BLUEPRINT or WHITEPAPER explaining the envisioned structure would help.

Revision history for this message
Ana Juaristi Olalde (ajuaristio) said : 		#4

I also would like to know someone from OpenERP, S.A to explain with detail what is planned for res.parner.address in next version.
Worried about it.
Thank you:
Ana

Revision history for this message
Numérigraphe (numerigraphe) said : 		#5

From what was shown at the latest community days, partner address and partner are merged into a single object, and records are organized in tree structures.
So addresses simply become partners on their own.
This is to ease some business cases, and B2C in particular.

Lionel Sausin.

Revision history for this message
Ferdinand (office-chricar) said : 		#6

@Lionel
yes the idea of the tree structure is good, but assume you have 10 contacts and the office is moving to another location
AFAICS the address in every contact has to be changed

what we need is a possibility to define a field like street somewhere in the upstream tree structure and this gets displayed/used for all child resources

Revision history for this message
Numérigraphe (numerigraphe) said : 		#7

Regarding the fact that company_registry, SIRET and NAF are on the wrong object, I filed Bug #1042332 and Bug #1042324.
VAT is actually on res.partner already (res.company has it as a "related" field).
Lionel.

Revision history for this message
risto3 (risto3) said : 		#8

In absence of any useful precision, it appears that version 7 of this platform fragilises and deprecates the importance of finance/accounting, manufacturing, sales and service and accords focus purely on marketing/CRM.
Perhaps the name should change accordingly given this high-impact, non evolutionary and unstable approach.
We shall need to evaluate whether we can stay on the 6.1 (6.x?) platform... with the gtk client (also apparently in maintenance mode).

Can you help with this problem?

Provide an answer of your own, or ask risto3 for more information if necessary.

To post a message you must log in.