El Ministerio de Hacienda es una entidad gubernamental que se puso a la cabeza de las demás carteras estatales innovando tecnológicamente sus procesos de registro y control por medio de aplicativos para poder hacer las diversas declaraciones de IVA, RENTA y PAGO A CUENTA, el famoso DET (Declaración Electrónica Tributaria), un aplicativo que se puede descargar y al que se le pueden adicionar diversos módulos para registrar, emitir y transferir las diversas declaraciones y formularios que Hacienda solicita y el I.C.V. Informe de Compras y Ventas antes llamado  C.O.A. (Módulo de Confrontación de Operaciones Autodeclaradas) que es exigible a ciertas empresas en la que entregan detalle de sus ventas y compras.

Ambos aplicativos permiten la digitación individual de los datos solicitados así como la transferencia o carga al aplicativo de archivos con los datos a registrar por medio de interfaces de conversión, es decir que si tengo una lista muy larga de datos, en lugar de digitarla, puedo cargar un listado generado en mi base de datos o en Excel en formato texto tabulado y automáticamente el sistema «chupa» estos datos del archivo y los carga al aplicativo con lo que me ahorro en digitación larga, repetitiva y tediosa.

Sin embargo dichas aplicaciónes a pesar de sus rimbombantes nombres, no están exentas de problemas e inconsistencias y casi siempre que sale una nueva o una actualización se presentan problemas e inconvenientes que se deben mas al desconocimiento de conceptos contables básicos de parte de los técnicos que elaboran estos módulos que a complejidades del propio sistema.

Por ejemplo el mas reciente módulo del DET. que es el formulario (F983v2) Informe de Inventario Fisico de Bienes del Activo Realizable que es un modulo que pide detallar el inventario realizable (o sea el que se vende) de las empresas, artículo por artículo pidiendo nombre, cantidad o existencia final al 31 de diciembre del año cerrado, el costo del artículo y el valor total  de la existencia del articulo.

Todo esto debe sumar el total del Inventario que hemos declarado en el balance de comprobación al final del ejercicio contable.

Es mas que obvio que el dato que importa es el valor en dolares del inventario.

Los costos de los artículos se generalmente se registran utilizando mas de 2 cifras decimales, algunos contadores usan 4, 6 decimales y algunos llegan a usar hasta mas de 12 decimales para calcular el valor del inventario, aunque personalmente considero que manejar 8 cifras significativas para este cálculo en la mayoría de los casos, es suficiente.

De tal manera que si tengo 12,345 unidades que me cuestan 3.165434123 dolares tendré como valor de inventario: 39,077.28 dolares, y así, artículo por artículo tengo valores individuales por cada ítem que al sumarlos todos me dan el costo total del inventario.

Pero el módulo F983v2 es tan «inteligente» que no solo puede leer una lista de datos para registrarlos sino que ademas CALCULA EL VALOR DEL INVENTARIO multiplicando cantidad por costo y valida el resultado para dejar subir el registro a su base de datos, rechazándolo si el dato enviado no pega con el que el módulo F983v2 calcula y así evitar errores (SENCILLAMENTE GENIAL!!!!).

Solo que al momento de sacar al público el nuevo módulo, el cálculo lo hacía con dos decimales para el costo…y también es de hacer notar que por la entrada en vigencia del nuevo paquete fiscal el plazo para presentarlo estaba por vencer a los pocos días de liberado el programa.

¿?

¿Que significa esto?

Que en el caso anterior, el sistema DET en su aplicativo F983v2 hacía lo siguiente:

Existencia = 12,345 multiplicado por 3.17  es igual a : 39,133.65

El valor declarado en contabilidad en los balances consideraba: 39,077.28 dólares
El valor calculado por DET segun el costo con solo dos decimales: 39,133.65 dólares.

Aproximando el costo a la cifra significativa superior, es decir 3.16543 se convierte en 3.17, o en 3.16 según el criterio de aproximación, para nuestro caso vámonos con 3.17.

Veamolo en cuadritos:

Nos da una diferencia de 56.37 dólares por una linea de producto y aunque no en todos los artículos hay descuadre, puede ser que al final tengamos un diferencial acumulado de unos 50 a 100 dólares entre negativos y positivos, lo cual ya haría caer en contradicción a la empresa con lo declarado en sus balances.

Dos días despues, el Ministerio de Hacienda publicó otra versión del aplicativo que operaba con 10 decimales, porque obviamente tuvieron muchas quejas de los usuarios, sobre todo porque el plazo de entrega vencía en un período no mayor a dos días desde que fué publicado el aplicativo en el sitio web del ministerio, es decir supuestamente el módulo se libero el 24 de febrero y vencía el viernes 26 de febrero y por lo que sé, el plazo fué ampliado hasta el lunes primero de marzo de 2010.

Sin embargo la fecha de publicación del parche no coincide con la que aparece en la página del MH a menos que haya sido liberado en la noche de ese mismo día, 26 de febrero.

El punto aqui es que si la persona o el grupo de analistas que  diseñó el aplicativo, hubiesen tenido un mínimo de conocimiento o de criterio contable, fácilmente hubieran determinado que en realidad el valor que importa es el declarado en los balances y que por lo tanto las cifras que realmente eran necesarias de registrar son la de cantidad o existencia y la de valor de inventario, aún si querían el costo unitario, debieron considerar desde el principio los 10 decimales para la validación, aproximando respuesta a 2 decimales o abriendo un rango de tolerancia en la rutina de validación.

Por otro lado creo que la gente de la unidad de servicios informáticos del Ministerio de Hacienda, no aplica ningún tipo de pruebas con casos reales antes de sacar un software a disposición del público, por sencillo que sea, a pesar de que seguramente estan concientes de que normalente la realidad dista mucho del diseño teórico.

Desconozco la estructura jerárquica u operativa de la unidad de servicios informáticos de la DGII del Ministerio de Hacienda, pero debería tener verdaderos analistas de sistemas que diseñen los programas basado en los principios básicos de ingeniería de software para evitar este tipo de inconvenientes que en el mejor de los casos es subsanado por los técnicos de cada empresa y en el peor, representa atrasos y quejas de los usuarios, los cuales encuentran una excusa válida para no presentar sus declaracioens a tiempo.

Este no es el primer caso que se dá, ya lo mencioné antes, que siempre se tienen problemas con los aplicativos pero es porque la gente técnica que desarrolla los mismos no tiene conocimiento real de la parte operativa de los registros en  las empresas, creo se debe trabajar mucho en el área de ingeniería de software ya que estos pequeños errores cuestan mucho dinero a las empresas y al estado en reprocesos, atrasos e incomodidades.