[8.0] Cambiado hardcodeo nombres de posición fiscal

[JuanjoA]

Ahora se puede seleccionar a nivel de posición fiscal el tipo de identificación que se espera para los clientes asociados. Esto nos da opción a cambiar los nombres de las posiciones fiscales según necesidad, y da libertad a quien no quiera hacerlo y usar el estándar.

Si es cierto que una vez aplicado, será necesario configurar las posiciones fiscales según necesidad, ya que por defecto se pondrá nacional.
El mínimo a configurar será (para estos casos):

1. Régimen nacional (ya estará ok, National)
2. Régimen Intracomunitario (Seleccionar Intracom)
3. Régimen Extracomunitario / Canarias, Ceuta y Melilla (Seleccionar Export)

[ozono]

A mi me parece correcto. Lo único que veo es que las comprobaciones del tipo se hacían contra enteros y ahora son cadenas.

[omar7r]

Yo veo necesario un script de migración ya que este cambio obligaría a todo el mundo a recorrerse las posiciones fiscales a mano para escribirles este nuevo campo, por lo que en el momento que se aplique este commit fallarían los envíos sino se hace esto a mano.

[JuanjoA]

El tema del script lo veo bien, si aplico post_init_hook, ¿sería necesario reinstalar el módulo o también se aplicaría en un update?

[rlizana]

@JuanjoA post_init_hook solo se lanza al instalar un modulo, no en las actualizaciones.

[omar7r]

Sería un migrations al cambiar la versión no un post_init_hook, hay ejemplos en l10n_es

[pedrobaeza]

Pero esto no es lo que he comentado en el issue... ahora más tarde os propongo una alternativa.

[JuanjoA]

Oki, thx @omar7r y @rlizana , si alguién puede que lo pruebe please, sigo mañana, que estoy Ko.
Nota: el tema del selection, string e int, lo he cambiado. (thx @ozono )

[pedrobaeza]

Como he dicho en el issue, "la parte hardcodeada" no se debe quitar. Simplemente, hacer un elif más para si se tiene algún dato en la posición fiscal.

[pedrobaeza]

Esto no tiene ninguna ventaja ponerlo aquí arriba con la nueva función de selection_add. Mejor que esté en la propia definición del campo por legibilidad

[pedrobaeza]

No tengo claro que los números se vayan a almacenar así en la BD y no como VARCHAR, así que lo mejor sería hacer un int() en el método que lo obtiene.

[JuanjoA]

He cambiado lo mencionado por @pedrobaeza, no me acaba de cuadrar del todo, pero ahorra el script de migración, y aporta la flexibilidad requerida.

Edito: le he quitado el valor por defecto, por lo que hay que configurarlo manualmente si se requiere.

[pedrobaeza]

Sigue sin ser lo que quería, aunque bueno, llevas parte de razón en que debe tener prioridad lo puesto en la posición fiscal, pero no puedes quitar el 1 como valor por defecto en else. Pon este código:

partner_ident = self.fiscal_position.sii_partner_identification_type
if partner_ident:
    res = int(partner_ident)
elif self.fiscal_position.name == u'Régimen Intracomunitario':
    res = 2
elif (self.fiscal_position.name ==
        u'Régimen Extracomunitario / Canarias, Ceuta y Melilla'):
    res = 3
else:
    res = 1
return res

[pedrobaeza]

Y recuerda siempre tener la complejidad ciclomática en mente (los if y bifurcaciones que haces).

[JuanjoA]

Está al comienzo, res=1

[pedrobaeza]

Cierto, se me pasó, pero mejor el código que yo propongo por legibilidad y complejidad menor.

[pedrobaeza]

Otro consejo es nunca utilizar la \ para múltiples líneas. Mejor paréntesis (ya he editado mi propuesta de código), porque con eso a veces pueden salir errores con líneas complejas.

[JuanjoA]

Listo @pedrobaeza .