Programar es prever

He estado un tiempo sin escribir nada en el blog, y los próximos cambios que se van a dar en la legislación española sobre la aplicación del impuesto del IVA en las facturas me ha animado a hacerlo.

Hasta ahora, la forma habitual de enfocar el recargo del IVA en las facturas, al menos en las aplicaciones que yo desarrollaba y en alguna otra de otros programadores que conozco se basaba en guardar los valores de los porcentajes de los impuestos en variables globales de disco.

El próximo cambio de valores me ha hecho pensar que programar es prever, y quién nos dice que dichos valores no vayan a sufrir variaciones a lo largo del tiempo de aquí a unos meses o años.

Por ello me he planteado pasar todo ello a una estrucutura de tablas lo más flexible posible y que no tenga que implicar la actuación del programador a la hora de hacer estos cambios.

Esquema general de tablas

Esquema general de tablas

Basándonos en una aplicación sencilla de facturas de ventas, el esquema que he ideado es el mostrado en la imagen.

Partimos de una tabla principal de IMPUESTOS  en los que podremos dar de alta tanto IVA como IGIC, IRPF, Recargo de equivalencia….

En la tabla TIPOS-IVA se añadirán los distintos tipos de cada impuesto. Por ejemplo, en el caso del IVA irán los registros: General, Reducido, Superreducido y Exento, por ejemplo.

Y en la tabla valores del IVA , tanto los porcentajes de cada uno de estos TIPOS como su fecha de entrada en vigor.

He añadido además una tabla de COMPATIBLES para tener una relación de qué impuestos son compatibles entre sí y por tanto aplicables en una única factura. Por poner un ejemplo de incompatiblidad, el impuesto IGIC aplicable en la comunidad autónoma de Canarias , NO es compatible con el IVA, pues de alguna forma el primero sustituye al segundo.

Todos los valores anteriores, se dán de alta automáticamente al iniciar la aplicación mediante llamadas a diferentes procesos sin origen en el proceso de arranque GENERAL.

Proceso GENERAL

Proceso GENERAL

Desde este proceso GENERAL  se hacen llamadas a diferentes procesos sin origen que van dando de alta los registros necesarios en las diferentes tablas

Los procesos interesantes son

IVAS-ALTAS

IGIC-ALTAS

IRPF-ALTAS

RECARGO-ALTAS

En la imagen no aparece, pero también se incluye un proceso para dar de alta los registros de la tabla COMPATIBLES.

Podremos escoger qué impuestos vamos a usar de forma general en el formulario de CONFIGURACIÓN  en la pestaña “fiscales” y sus valores habituales , así como personalizar para cada cliente qué impuestos le vamos a aplicar de forma general en las facturas que les emitamos y sus valores, todo ello con subindexaciones para que sólo podamos escoger los TIPOS  del IMPUESTO  elegido.

Así mismo, en los artículos  escogeremos también el IMPUESTO  y su TIPO, calculando el porcentaje aplicado según los dos campos anteriores.

En la tabla de MOVIMIENTOS (lineas de la factura ) en el campo PORCENT-IVA-FACT  he usado como valor inicial la función IVA-PORCENT  a la que le paso los parámetros : fecha de la factura, tipo de impuesto, e impuesto. Esta función, dependiendo de esos tres parámetros, me calcula el valor de ese impuesto-tipo que graba a la linea en esa fecha de factura. La función es manifiestamente mejorable pero me pareció una solución válida para conseguir el fin que se necesitaba, la devolución del tanto por ciento en vigor.

En la tabla FACTURAS uso 7 campos BASE IMP , dado que el IGIC tiene hasta siete registros en la tabla TIPOS-IVA, y desde MOVIMIENTOS hay tambien 7 actualizaciones distintas a los respectivos cambios, todas ellas condicionadas a los distintos binomios IMPUESTO  TIPOS-IVA  que estemos usando.

Como en una factura pueden coexistir dos impuestos que la graban ( por ejemplo IVA y Recargo de Equivalencia ) y uno que la resta  ( IRPF ) he creado los respectivos campos para calcular los valores de dichos impuestos con respecto a las bases imponibles correspondientes, así como la retención del IRPF sobre el total de la suma de las bases, todo ello mediante las funciones correspondientes que dependen de la fecha de la factura, del tipo y del impuesto.

Por último indicar que todo aquel que quiera el mapa del programa, puede escribirme un correo a agustismv@gmail.com y se lo proporcionaré con mucho gusto para que lo useis como queráis.

P. D: pensando en la v7, bastaría con conectar la tabla  VALORES-IVA  con PAISES  y así la tendríamos para distintos paises.

Anuncios

Acerca de Agustin
Velneoadicto. Tuve la grandísisma suerte de que me enseñaran los más grandes: Juan Muñoz-Cobos , Jesús Arboleya y Jesús Inclán..

7 Responses to Programar es prever

  1. ketter says:

    Desde el principio he utilizado tablas para los tipos de impuestos. Por eso no he ganado un duro en los cambios de legislación 🙂 el cliente lo hace todo.

    Ahora veo que estaba en el camino correcto 😉

    Por cierto, eso es así pensando en V7 y qbasic ¿no?

  2. Miguel says:

    Hola, cierto de esa manera se pierde por un lado pero se gana por otro, recuerdo hace años, el plan antiguo de contabilidad con las cuentas de regularización 800, 890 etc, mi primera contabilidad la hice pidiendo las cuentas de regularización y cierre al usuario con un formulario, cuando cambio la ley y entraron las cuentas 129, etc, yo no toqué un ápice de mi programa, gané menos dinero, pero mis clientes me vendieron el programa por el boca a boca una barbaridad.

    Buen trabajo, saludos cordiales.

  3. Fausto says:

    He leido el blog. No se si es porque me acabo de levantar o porque estoy un poco espeso, pero que diferencia hay con hacerlo en una tabla a hacerlo en una variable global que el usuario puede modificar.
    Creo que es mejor ponerlo en tablas, por ejemplo para compartirlo entre varias aplicaciones que trabajan sobre una misma vBase, no hay que cambiar el parametro en todas las aplicaciones, sino solo en una de ellas, pero no veo la diferencia de cara al usuario y al programador de ponerlo en una tabla a ponerlo en una variable que el usuario puede modificar.

    • agustin says:

      Hola Fausto. Imagina el improbable pero no descartable caso de que en un solo año, los valores del IVA cambiaran varias veces. En ese caso tendrías que aumentar el número de variables con las que trabajar, con las fechas de entrada en vigor para poder rehacer cálculos antiguos etc etc.
      No sé, creo que con las tablas ahorras molestias al cliente y tú te ahorras trabajo.
      Pero es sólo mi idea, que conste.
      Un saludo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: