Provincias españolas en numero, NO como marca iso 3166-2

642 views
Skip to first unread message

Francisco Gil

unread,
Jul 3, 2013, 2:58:12 AM7/3/13
to opener...@googlegroups.com
Hola,

Tengo Openerp 6.0.4, resulta que hasta hoy no me habia dado cuenta que los códigos de las provincias en España estan en número, que son correspondientes a los dos números iniciales correspondientes a los Códigos Postales. Esto no deberia ser asi, y deberian ser dos letras como marca la  iso 3166-2 (código ISO que determina el standard para el tratamiento de subdivisiones de estados y provincias).

Mi pregunta es la siguiente, dado que ya tengo clientes y direcciones creados, casi 2000, en el caso que yo cambiara estos números por letras, ¿Cómo me podria afectar?....

Gracias,


Pedro Manuel Baeza Romero

unread,
Jul 3, 2013, 4:05:02 AM7/3/13
to opener...@googlegroups.com
Buenas, Francisco,

Efectivamente, los topónimos utilizan como código los dos primeros dígitos del código postal, que cambian según provincia, pero mirando un poco ya he visto que existe una normalización de dichos códigos, que se puede consultar aquí:

http://es.wikipedia.org/wiki/ISO_3166-2:ES

El utilizarlo hasta ahora de esta forma ha sido por comodidad, ya que muchas veces en procesos de importación y similares, se podía buscar la provincia cogiendo los dos primeros dígitos del código postal. Tal vez sería más recomendable normalizarlo, aunque suponga perder esa ventaja. Por eso, pido la opinión del resto de la comunidad para ver qué hacemos al respecto.

En cuanto a tu pregunta, en principio no deberías tener ningún problema en cambiar esos códigos, ya que el enlace entre la dirección y la provincia se realiza por el ID del registro, no por el código.

Un saludo.





--
Has recibido este mensaje porque estás suscrito al grupo "openerp-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a openerp-spai...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a opener...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/openerp-spain.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

Jordi Esteve

unread,
Jul 3, 2013, 5:30:56 AM7/3/13
to opener...@googlegroups.com
On 03/07/13 10:05, Pedro Manuel Baeza Romero wrote:
> Buenas, Francisco,
>
> Efectivamente, los top�nimos utilizan como c�digo los dos primeros
> d�gitos del c�digo postal, que cambian seg�n provincia, pero mirando
> un poco ya he visto que existe una normalizaci�n de dichos c�digos,
> que se puede consultar aqu�:
>
> http://es.wikipedia.org/wiki/ISO_3166-2:ES
>
> El utilizarlo hasta ahora de esta forma ha sido por comodidad, ya que
> muchas veces en procesos de importaci�n y similares, se pod�a buscar
> la provincia cogiendo los dos primeros d�gitos del c�digo postal. Tal
> vez ser�a m�s recomendable normalizarlo, aunque suponga perder esa
> ventaja. Por eso, pido la opini�n del resto de la comunidad para ver
> qu� hacemos al respecto.
>
> En cuanto a tu pregunta, en principio no deber�as tener ning�n
> problema en cambiar esos c�digos, ya que el enlace entre la direcci�n
> y la provincia se realiza por el ID del registro, no por el c�digo.

Exacto. Como dice Pedro, puedes cambiar los c�digos de provincia de 2
d�gitos a 2 letras, ya que el enlace entre la direcci�n y la provincia
se realiza por el ID del registro, no por el c�digo. Y la actualizaci�n
autom�tica de la ciudad y provincia a partir del c�digo postal no tiene
en cuenta el c�digo de 2 d�gitos de la provincia, pues usa los valores
por defecto de OpenERP que dependen del zip introducido.

Yo creo que si estar�a mejor definir los c�digos de provincia con 2
letras iso 3166-2 en lugar de los 2 d�gitos del c�digo postal en el
m�dulo l10n_es_toponyms. Pero puestos a mejorar, lo ideal ser�a extraer
todos los datos de pa�ses y subdivisiones que ya nos ofrece la librer�a
pycountry:

https://pypi.python.org/pypi/pycountry

Tryton precisamente tienen todos los datos extraidos de la librer�a
pycountry dentro del m�dulo country, de forma que al instalarlo ya
dispones de todos los pa�ses y de todas las subdivisiones del mundo.
Pensad que hay muchos tipos de subdivisiones: en Espa�a provincias,
comunidades aut�nomas y ciudades aut�nomas, en Andorra tienen
parroquias, en Estados Unidos tienen estados, ... Todo esto ya nos lo
ofrece pycountry, y con un script similar al que se utiliza en Tryton
para disponer de estos datos en un fichero xml, tb se podr�a hacer en
OpenERP.

PD: Espero que mencionar Tryton no haga repel�s, lo he hecho para
explicar una funcionalidad que tiene que podr�a ser interesante para
OpenERP. Para poder mejorar es normal compararse con otras aplicaciones
y ERPs. Muchas veces en esta lista de localizaci�n espa�ola hemos hecho
comentarios sobre otras aplicaciones de gesti�n y contabilidad, como
contaplus, sage, navision, ...

--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
M�bil 679 170 693

Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Pened�s
Tel 93 890 2108

Pedro Manuel Baeza Romero

unread,
Jul 3, 2013, 5:45:08 AM7/3/13
to opener...@googlegroups.com
Jordi, muchísimas gracias por la explicación. No conocía esa librería, y desde luego se le puede dar mucho uso. En un futuro cercano, plantearé a la comunidad el adoptar esa librería como base, o incluso plantearlo en el core, pero la verdad es que ahora mismo, sin saber cómo funciona, no puedo saber su aplicación.

Un saludo.

P.D.: Desde luego que no hay problema en mencionar a Trytón en estos post constructivos. ¡Ojalá y surgieran más de estas aportaciones en ambas direcciones!


El 3 de julio de 2013 11:30, Jordi Esteve <jes...@zikzakmedia.com> escribió:
On 03/07/13 10:05, Pedro Manuel Baeza Romero wrote:
Buenas, Francisco,

Efectivamente, los topónimos utilizan como código los dos primeros dígitos del código postal, que cambian según provincia, pero mirando un poco ya he visto que existe una normalización de dichos códigos, que se puede consultar aquí:

El utilizarlo hasta ahora de esta forma ha sido por comodidad, ya que muchas veces en procesos de importación y similares, se podía buscar la provincia cogiendo los dos primeros dígitos del código postal. Tal vez sería más recomendable normalizarlo, aunque suponga perder esa ventaja. Por eso, pido la opinión del resto de la comunidad para ver qué hacemos al respecto.

En cuanto a tu pregunta, en principio no deberías tener ningún problema en cambiar esos códigos, ya que el enlace entre la dirección y la provincia se realiza por el ID del registro, no por el código.

Exacto. Como dice Pedro, puedes cambiar los códigos de provincia de 2 dígitos a 2 letras, ya que el enlace entre la dirección y la provincia se realiza por el ID del registro, no por el código. Y la actualización automática de la ciudad y provincia a partir del código postal no tiene en cuenta el código de 2 dígitos de la provincia, pues usa los valores por defecto de OpenERP que dependen del zip introducido.

Yo creo que si estaría mejor definir los códigos de provincia con 2 letras iso 3166-2 en lugar de los 2 dígitos del código postal en el módulo l10n_es_toponyms. Pero puestos a mejorar, lo ideal sería extraer todos los datos de países y subdivisiones que ya nos ofrece la librería pycountry:

https://pypi.python.org/pypi/pycountry

Tryton precisamente tienen todos los datos extraidos de la librería pycountry dentro del módulo country, de forma que al instalarlo ya dispones de todos los países y de todas las subdivisiones del mundo. Pensad que hay muchos tipos de subdivisiones: en España provincias, comunidades autónomas y ciudades autónomas, en Andorra tienen parroquias, en Estados Unidos tienen estados, ... Todo esto ya nos lo ofrece pycountry, y con un script similar al que se utiliza en Tryton para disponer de estos datos en un fichero xml, tb se podría hacer en OpenERP.

PD: Espero que mencionar Tryton no haga repelús, lo he hecho para explicar una funcionalidad que tiene que podría ser interesante para OpenERP. Para poder mejorar es normal compararse con otras aplicaciones y ERPs. Muchas veces en esta lista de localización española hemos hecho comentarios sobre otras aplicaciones de gestión y contabilidad, como contaplus, sage, navision, ...


--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
Mòbil 679 170 693


Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Penedès
Tel 93 890 2108


--
Has recibido este mensaje porque estás suscrito al grupo "openerp-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a openerp-spain+unsubscribe@googlegroups.com.

Jordi Esteve

unread,
Jul 3, 2013, 7:45:32 AM7/3/13
to opener...@googlegroups.com
On 03/07/13 11:45, Pedro Manuel Baeza Romero wrote:
> Jordi, much�simas gracias por la explicaci�n. No conoc�a esa librer�a,
> y desde luego se le puede dar mucho uso. En un futuro cercano,
> plantear� a la comunidad el adoptar esa librer�a como base, o incluso
> plantearlo en el core, pero la verdad es que ahora mismo, sin saber
> c�mo funciona, no puedo saber su aplicaci�n.

Ver�s en el enlace que te he pasado ejemplos de su uso, es muy sencillo.

>
> Un saludo.
>
> P.D.: Desde luego que no hay problema en mencionar a Tryt�n en estos
> post constructivos. �Ojal� y surgieran m�s de estas aportaciones en
> ambas direcciones!

Eso espero, Pedro. S�lo decirte que en las listas de Tryton se suele
mencionar a menudo a OpenERP, que por algo son primos-hermanos ;-)

--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
M�bil 679 170 693

Zikzakmedia SL
Dr. Fleming, 28, baixos

Antonio Roncero

unread,
Jul 3, 2013, 8:44:58 AM7/3/13
to opener...@googlegroups.com
Creo que la mejor opción podría ser mantener los dos porque en muchos documentos oficiales (se me ocurre la declarativa del modelo 182 y la presentación de la lopd) exigen los códigos numéricos de provincia.

Pedro Manuel Baeza Romero

unread,
Jul 3, 2013, 9:05:23 AM7/3/13
to opener...@googlegroups.com
Antonio, muchas gracias por la información, ya que precisamente son este tipo de cosas las que condicionan los datos. Ya he estado echando un vistazo a la librería y, efectivamente, su uso es muy sencillo.

Un primer enfoque para utilizar esta librería es tener un asistente desde el que se escoge qué subdivisión de qué país importar, pero la actual estructura del modelo res.country.state no permitiría contemplar esa doble nomenclatura.

Otro enfoque sería olvidar totalmente los modelos de OpenERP y hacer la consulta al rellenar los campos de dirección directamente sobre la librería. Supongo que es el enfoque por el que ha optado Tryton, aunque veo algunos puntos oscuros como la forma en la que se guardaría esos datos (¿como cadenas? ¿se añaden dinámicamente a alguna tabla?...). Luego echaré un vistazo al código para verlo.

De nuevo, gracias por vuestras aportaciones.

Un saludo.


--
Has recibido este mensaje porque estás suscrito al grupo "openerp-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a openerp-spai...@googlegroups.com.

Jordi Esteve

unread,
Jul 3, 2013, 12:45:19 PM7/3/13
to opener...@googlegroups.com
On 03/07/13 15:05, Pedro Manuel Baeza Romero wrote:
> Antonio, muchas gracias por la informaci�n, ya que precisamente son
> este tipo de cosas las que condicionan los datos. Ya he estado echando
> un vistazo a la librer�a y, efectivamente, su uso es muy sencillo.
>
> Un primer enfoque para utilizar esta librer�a es tener un asistente
> desde el que se escoge qu� subdivisi�n de qu� pa�s importar, pero la
> actual estructura del modelo res.country.state no permitir�a
> contemplar esa doble nomenclatura.
>
> Otro enfoque ser�a olvidar totalmente los modelos de OpenERP y hacer
> la consulta al rellenar los campos de direcci�n directamente sobre la
> librer�a. Supongo que es el enfoque por el que ha optado Tryton,
> aunque veo algunos puntos oscuros como la forma en la que se guardar�a
> esos datos (�como cadenas? �se a�aden din�micamente a alguna
> tabla?...). Luego echar� un vistazo al c�digo para verlo.

Pedro, te aclaro como lo tiene enfocado Tryton:

En Tryton hace tiempo cambiaron ligeramente el concepto de
res.country.state de OpenERP (traducido por Provincia, pero como he
comentado no es adecuado, pues puede ser una provincia, comunidad
aut�noma, parroquia, estado, ...). En Tryton se llama Subdivisi�n, y las
subdivisiones tienen subdivisiones padre, muy parecido a las estructuras
jer�rquicas de las categor�as que tiene OpenERP/Tryton, por ejemplo las
categor�as de partners o de productos. Esto permite tener subdivisiones
padres de otras, por ej. Barcelona tiene como padre Catalunya. Esto
permite una mayor informaci�n territorial, por ejemplo cuando a un
partner le asignas s�lo Barcelona, sabes que est� en Barcelona y a la
vez en Catalunya que es padre de la anterior. Si a�ad��semos las
comarcas, podr�amos tener 3 niveles: comarcas, provincias y comunidades
aut�nomas.

En resumen, para poder sacar provecho de los datos de la liber�a
pycountry primero se deber�a adaptar la clase res.country.state de
OpenERP para que sea una estructura jer�rquica.

Tryton no usa la librer�a pycountry cada vez que debe rellenarse una
provincia (en el argot de Tryton subdivisi�n), si no que con la librer�a
pycountry un programador ha extra�do todos los pa�ses y subdivisiones
para confeccionar un xml de datos que se cargan al instalar el m�dulo
country y as� est�n disponibles al instante (evidentemente, este es un
de los m�dulos que tarda m�s en instalarse).

Pedro Manuel Baeza Romero

unread,
Jul 4, 2013, 2:16:03 AM7/4/13
to opener...@googlegroups.com
Jordi, muy interesante la explicación. Desde luego, en OpenERP no sería directamente usable sin alguna adaptación. Cuando termine las cuestiones relativas a la adaptación de la localización a la v7, abordaré este tema a ver si se puede hacer algo.

Muchas gracias por toda la información, y encantado de charlar contigo.

Un saludo.


El 3 de julio de 2013 18:45, Jordi Esteve <jes...@zikzakmedia.com> escribió:
On 03/07/13 15:05, Pedro Manuel Baeza Romero wrote:
Antonio, muchas gracias por la información, ya que precisamente son este tipo de cosas las que condicionan los datos. Ya he estado echando un vistazo a la librería y, efectivamente, su uso es muy sencillo.

Un primer enfoque para utilizar esta librería es tener un asistente desde el que se escoge qué subdivisión de qué país importar, pero la actual estructura del modelo res.country.state no permitiría contemplar esa doble nomenclatura.

Otro enfoque sería olvidar totalmente los modelos de OpenERP y hacer la consulta al rellenar los campos de dirección directamente sobre la librería. Supongo que es el enfoque por el que ha optado Tryton, aunque veo algunos puntos oscuros como la forma en la que se guardaría esos datos (¿como cadenas? ¿se añaden dinámicamente a alguna tabla?...). Luego echaré un vistazo al código para verlo.

Pedro, te aclaro como lo tiene enfocado Tryton:

En Tryton hace tiempo cambiaron ligeramente el concepto de res.country.state de OpenERP (traducido por Provincia, pero como he comentado no es adecuado, pues puede ser una provincia, comunidad autónoma, parroquia, estado, ...). En Tryton se llama Subdivisión, y las subdivisiones tienen subdivisiones padre, muy parecido a las estructuras jerárquicas de las categorías que tiene OpenERP/Tryton, por ejemplo las categorías de partners o de productos. Esto permite tener subdivisiones padres de otras, por ej. Barcelona tiene como padre Catalunya. Esto permite una mayor información territorial, por ejemplo cuando a un partner le asignas sólo Barcelona, sabes que está en Barcelona y a la vez en Catalunya que es padre de la anterior. Si añadíésemos las comarcas, podríamos tener 3 niveles: comarcas, provincias y comunidades autónomas.

En resumen, para poder sacar provecho de los datos de la libería pycountry primero se debería adaptar la clase res.country.state de OpenERP para que sea una estructura jerárquica.

Tryton no usa la librería pycountry cada vez que debe rellenarse una provincia (en el argot de Tryton subdivisión), si no que con la librería pycountry un programador ha extraído todos los países y subdivisiones para confeccionar un xml de datos que se cargan al instalar el módulo country y así estén disponibles al instante (evidentemente, este es un de los módulos que tarda más en instalarse).


--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
Mòbil 679 170 693


Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Penedès
Tel 93 890 2108

--
Has recibido este mensaje porque estás suscrito al grupo "openerp-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a openerp-spain+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages