Bueno, es cuestión de perspectivas.
En el Perú de acuerdo a la entidad tributaria SUNAT existen estos tipos
de identificadores que deben ser manejados en todo software de gestión
comercial, es así que en la localización peruana de Tryton y GNU Health
lo manejamos en una tabla:
*_TABLA 2: TIPO DE DOCUMENTO DE IDENTIDAD_* *_
_*
*N°* *DESCRIPCIÓN*
0 OTROS TIPOS DE DOCUMENTOS
1 DOCUMENTO NACIONAL DE IDENTIDAD (DNI)
4 CARNET DE EXTRANJERIA
6 REGISTRO ÚNICO DE CONTRIBUYENTES
7 PASAPORTE
Y creemos que a futuro se pueden agregar o eliminar algún tipo, al
margen que el "OTROS TIPOS DE DOCUMENTOS" podría sugerir que no, pero no
queda otra entonces que el HARDCODE.
Saludos
Fernando
El 07/12/17 a las 07:25, Sergi Almacellas Abellana escribió:
> El 07/12/17 a les 11:59, Fernando Sánchez ha escrit:
>> Hola Sergi
>>
>> Hasta la versión 4.2 la definición del campo type en la clase
>> PartyIdentifier era así
>> <http://hg.tryton.org/modules/party/file/4.2/party.py#l253>:
>>
>> *type = fields.Selection('get_types', 'Type')*
>>
>>
>> Usaba el método 'get_types' para poblar la lista y el usuario
>> seleccione, yo sobrescribí este método y obtenía los valores de una
>> tabla sin ningún problema. >
>> Desde la 4.4 se cambió a
>> <http://hg.tryton.org/modules/party/file/4.4/party.py#l301>:
>>
>>
>> *type**= fields.Selection([**(None, ''), ('eu_vat', 'VAT'), *
>>
>> *], 'Type')*
>>
>>
>> A mi modesto entender la definición de la 4.2 fue mejor pues te
>> permitía evitar el HARDCODE de los tipos de identificación.
>
> De hecho, los tipos de identificación deben ser estáticos. No entiendo
> porqué necesitas almazenar-los en una tabla.
>
>
>> Sería interesante saber cual fue la razón por la que se hizo el
>> cambio, pues hasta donde se ve, en la 4.2 tienes mayor flexibilidad.
>
> Aquí tienes la issue donde se discutió:
>
> https://bugs.tryton.org/issue6374
>
>
>
