ovl: se permite guardar rif con formato inválido

a VER....

El TXT

VEJ123456789

En expresiones regulares en que se diferencia de:

VEJ307520882

lamentablemente el SENIAT no nos da sino un webservices para verificarlo, que lo hace actualmente el botón,

Si una instalaci;on NO tiene conexión a Internet, como creo un partner si lo pongo como restricción "Si no existe en el Seniat no lo crees".

Nosotros en primera instancia lo desarrollamos así. Y en implmentaciones en procesos de bulk de datos (Importaciones desde csv por ej.) era casi imposible parsear lo correcto, es por esto que lo dejamos solo validada la JEyV al principio -despues del VE- y 9 caracteres,

hay algo que no sepa mi amigo aristóbulo?

Si te fijas en el reporte inicial el rif contiene un caracter en blanco entre country_id y el rif VE' 'J123456789,
en ese caso el rif se guarda sin ningún problema.

Sabías que la variable vat que recibe __check_vat_ve ya viene sin el(los) caractere(s) en blanco que pueda(n) existir entre el country_id y el rif? lo que genera el problema anterior

Sabías que si guardas un rif 'VEXXXXXXXXXXX' y no declaras una dirección de factura con pais = VE, entonces ni de suerte vas a validar que el rif no esté duplicado? por lo que puedo tener N cantidad de proveedores con el mismo rif o incluso el mismo proveedor creado N veces.

Les presento al culpable de permitir caracteres vacíos entre el country_code y el vat
http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/view/head:/base_vat/base_vat.py#L52

Ahora siendo este un método base propongo que se sobreescriba en la ovl para NO limpiar el caracter en blanco, de manera que la validación funcione de manera mas coherente.

A ver...

El 29 de marzo de 2012 17:39, [SISB] Aristóbulo Meneses <
<email address hidden>> escribió:

> Si te fijas en el reporte inicial el rif contiene un caracter en blanco
> entre country_id y el rif VE' 'J123456789,
> en ese caso el rif se guarda sin ningún problema.
>
>
Ok entiendo que lo incorrecto es permitir caracteres que no estén [0-9]
correcto?

Si es así solamente o crees que debemos validar algo adicional hbla ahora o
calla para siempre ;-)

> Sabías que la variable vat que recibe __check_vat_ve ya viene sin
> el(los) caractere(s) en blanco que pueda(n) existir entre el country_id
> y el rif? lo que genera el problema anterior
>
>
noup!

> Sabías que si guardas un rif 'VEXXXXXXXXXXX' y no declaras una dirección
> de factura con pais = VE, entonces ni de suerte vas a validar que el rif
> no esté duplicado?

Si y eso está bien, es intencional.

Fijate:

Si tienes proveedores extranjeros (Como los creas?).
En entornos multilocalizacion -como el nuestro mx-ve al mismo tiempo- no
puedo validar todo lo de VE.

> por lo que puedo tener N cantidad de proveedores con
> el mismo rif o incluso el mismo proveedor creado N veces.
>

En ese caso, tenemos que con permisos restringir quien puede crear partners
NO-VE para evitar esto, pero en este ultimo ejemplo la funcionalidad creo
que esta correcta, la primera no, son bugs diferentes, estoy bien?

>
>
> ** Changed in: sisb
> Status: New => Confirmed
>
> ** Changed in: sisb
> Importance: Undecided => Critical
>
> --
> You received this bug notification because you are subscribed to Openerp
> Venezuela.
> https://bugs.launchpad.net/bugs/968628
>
> Title:
> ovl: se permite guardar rif con formato inválido
>
> Status in Localización Venezuela:
> New
> Status in Sistema Integral Simón Bolívar:
> Confirmed
>
> Bug description:
> Durante la creación de partners se permite guardar rif con formato
> inválido.
>
> Ej. VE J123456789
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/openerp-venezuela-localization/+bug/968628/+subscriptions
>

--
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>
twitter @nhomar

Lancé un merge proposal con lo que creo es la solución para este bug.
Sobrescribí el método __check_vat para que no limpie los caracteres vacíos si la dirección de factura es VE, para el resto el comportamiento es el original.

=== modified file 'l10n_ve_fiscal_requirements/partner.py'
--- l10n_ve_fiscal_requirements/partner.py 2012-02-14 18:28:19 +0000
+++ l10n_ve_fiscal_requirements/partner.py 2012-03-29 23:06:05 +0000
@@ -149,6 +149,16 @@
             return False
         return True

+ def _split_vat(self, vat):
+ '''
+ By default base_vat._split_vat cleans vat of whitespaces,
+ if country code is VE this doesn't apply
+ '''
+ vat_country, vat_number = vat[:2].lower(), vat[2:]
+ if not 'VE' in [a.country_id.code for a in self.pool.get('res.partner.address').browse(cr, uid, current_partner['address'])]:
+ vat.strip()
+ return vat_country, vat_number
+
     def update_rif(self, cr, uid, ids, context=None):
         if context is None:
             context = {}

corrijo:

=== modified file 'l10n_ve_fiscal_requirements/partner.py'
--- l10n_ve_fiscal_requirements/partner.py 2012-02-14 18:28:19 +0000
+++ l10n_ve_fiscal_requirements/partner.py 2012-03-29 23:06:05 +0000
@@ -149,6 +149,16 @@
             return False
         return True

+ def _split_vat(self, vat):
+ '''
+ By default base_vat._split_vat cleans vat of whitespaces,
+ if country code is VE this doesn't apply
+ '''
+ vat_country, vat_number = vat[:2].lower(), vat[2:]
+ if not 'VE' in [a.country_id.code for a in self.pool.get('res.partner.address').browse(cr, uid, current_partner['address'])]:
+ vat_number = vat_number.strip()
+ return vat_country, vat_number
+
     def update_rif(self, cr, uid, ids, context=None):
         if context is None:
             context = {}

El problema va mas allá, por favor obvien los diff anteriores y disculpen.

Este bug esta resuelto,

a la fecha con la revno 938 OVL70

Saludos.