Facturación con LibreOffice y Firebird

Pensando en qué iba a hacer a continuación, me he dado cuenta de que la tabla de detalles no está normalizada. Como se que la normalización es importante, voy a corregirlo. De paso preparo todo para poder facturar diferentes tipos de impuesto. Para poder modificar esto, necesito hacer varios (muchos) cambios, lo que me hace reflexionar sobre la importancia de tener claro el diseño de la base de datos y de las tablas antes de lanzarse a crear un "programa" con la base de datos. En realidad muchos de los errores de diseño que he cometido (¡quizá no todos!), lo he hecho a propósito, para ir viendo paso a paso problemas que podemos tener y la manera de solucionarlos, porque, vuelvo a recordar, el objetivo de estos vídeos no es crear un programa de facturación que podamos copiar y utilizar;  el objetivo era ver si las capacidades de Base y Firebird nos podrían servir para algo serio y de paso detectar errores. También, para mi, otros objetivos eran aprender, ¡y ya os digo que esto

En el día de hoy, hacemos distinción entre facturas emitidas, en las que ya no se pueden modificar ningún dato, y facturas pendientes, que podemos seguir modificando hasta su emisión. Para hacerlo, creamos dos formularios y utilizamos la propiedad de filtrado que tienen los formularios. Me he equivocado en el formato de la fecha y, en el formulario de facturas emitidas, no he comprobado que, aunque se puedan modificar, no se puedan eliminar para no perder el número de factura. El que quiera ya sabe como modificarlo, en todo caso, si me acuerdo arreglaré las dos cosas el próximo día.

El informe que creamos el último día imprimía todas las facturas. Pero generalmente no es eso lo que queremos, sino que sería mejor poder elegir que facturas imprimimos. En este día vamos a generar dos informes más, uno para imprimir una sola factura y otro para imprimir un rango de números de factura. Para hacer esto, reaprovechamos la consulta que ya habíamos creado y también reaprovechamos el informe del último día (¡menuda diferencia en tiempo!)

En este día, mediante un informe, creamos el formato par imprimir las facturas. El vídeo es un poco largo y puede que pesado, porque en el diseño del formulario se pierde mucho tiempo, pero creo que vemos algunas cosa interesantes. En el informe vemos las diferentes zonas existentes cuando agrupamos los datos por un campo y estudiamos que poner en cada una de ellas. También vemos como añadir un logotipo y otras decoraciones para la factura y, al final, lo más interesante, funciones para totalizar los campos por grupos, que nos sirve para crear el total de la factura. Ya me podéis perdonar, pero he tenido que interrumpir el vídeo por una llamada...

 En el día 10, ¡por fin!, añadimos la tabla de detalles de factura para que las facturas puedan tener más de un concepto. Como consecuencia de crear la tabla de detalles, necesitamos un tipo de formulario que sea capaz de mostrar los datos de las facturas y los datos de concepto (guardados en la tabla detalles). Al final arreglamos un poco los formularios.

Eliminamos los datos de pruebas y reiniciamos  las tablas, es decir nos las apañamos para que los campos autonuméricos vuelvan a empezar en uno. A continuación importamos desde Calc otros datos de pruebas, un poco más reales. Creamos una consulta con las dos tablas, Facturas y Clientes para ver todos los datos de cada factura. A continuación vemos algunos problemas de integridad referencial, es decir, que nuestra base de datos se queda inestable porque hemos eliminado en una tabla un registro que era necesario en otras tabla. Seguidamente vemos como, utilizando la herramienta Relaciones, se puede evitar el problema de integridad referencial mediante las restricciones incluidas en la relaciones.

Mi intención original era que quien quisiera fuera avanzando en la creación de la facturación al tiempo que yo, pero posiblemente haciendo alguna cosa diferente de como yo lo hago y metiendo diferentes datos, de tal modo que al hacer cosas diferentes posiblemente tendríamos diferentes problemas. Pero he visto un par de comentarios que ha habido en el canal de  Telegram, y parece que hay quien prefiere descargarse los archivos que se van publicando en el repositorio de El Mau, pero por lo visto, en el repositorio, aunque está los archivos, no contienen datos.  Por eso, he decidido publicar mi propio repositorio en GitHub , con mis archivos y mis datos tal y como quedan después de cada publicación. De paso, he publicado también los vídeos, para que quien quiera pueda descargarlos o verlos sin necesidad de Youtube. Si descargas los archivos .odb y .FDB y los colocas en una carpeta de tu sistema, puede (casi seguro) que la estructura de las carpetas no coincida con subida al repositoiro, p

En este día ve mos como controlar la navegación por los campos de entrada con el tabulador, para que el usuario no tenga que usar el ratón. A continuación importamos una tabla de Calc, con sus datos, para convertirla en tabla de Base. Con el  procedimiento anterior no se puede crear un campo autonumérico. Para solucionar este problema, primero creamos la estructura de la tabla y a continuación importamos los datos. Este día tiene dos vídeos porque he preferido añadir una parte que se me olvidó grabar.

 Comenzamos el día maquillando un poco los formularios y arreglando alguno de los posibles problemas en la introducción de datos. El día de hoy conseguimos que, en el formulario Factura, para seleccionar un cliente, se despliegue una lista para que lo seleccionemos, sin necesidad de abrir la base de datos, y al final guarde el número de cliente, que es lo que necesitábamos. Intentamos limitar el rango de datos que se introducen en los formularios. Para los campos CHAR (y VARCHAR) podemos limitar la cantidad de caracteres introducido, con los números, podemos poner un máximo y un mínimo, pero no funciona como a mí me gustaría.

 El día de hoy comenzamos solucionando el problema de los NIF duplicados, para ello empleo un índice único. De paso comento un poco el uso de índices (en esto, seguro que alguien puede comentar algo más o algo diferente). A continuación creamos el formulario de la tabla facturas. Este nos hace ver algún problema nuevo, por ejemplo, no parece muy práctico ir a la tabla de clientes a buscar el número de cliente para escribirlo en esta tabla, así que tenemos que buscar una solución.

 Probando, para informar del bug  que había detectado el día anterior, me he dado cuenta de que en realidad no es un bug. Resulta que he recordado que a los números de coma flotante no se les puede limitar el número de decimales, ellos deciden cuantos decimales ponen. Tampoco se les puede limitar el tamaño, sino que el tamaño, en realidad, es el número de bites que emplean para representar cada número y esto va implícito en el tipo de datos (FLOAT o DOUBLE). Aunque, si creas un campo con números en coma flotante, en la tabla se muestra con un decimal, podemos modificar este comportamiento (los decimales que se muestran, no el número real de ellos). En el vídeo de hoy lo muestro. También veremos en el vídeo, con algunos ejemplos, que los dichosos números de coma flotante no son exactos. Por otro lado, en el vídeo anterior dije que ya sabía que es imposible modificar el tipo de datos en las tablas, y que esto era un bug conocido por mí. Como ocurre muchas veces, y en un solo día hemos vi

 En este día pasamos a la acción. Una vez que he separado los datos de las dos posibles tablas en la hoja de cálculo, paso a la acción y creo la base de datos de Firebird y las dos tablas que habíamos identificado. En el proceso de creación de tablas me entretengo  en explicar los tipos de datos que utilizo y por qué. Supongo que en esto de los tipos de datos habrá opiniones diferentes a la mía, de hecho, en casi ningún tutorial utilizan algunos datos como yo. También relacionado con los tutoriales, explico un error que he detectado en uno de ellos y que creo que es bastante frecuente. Pienso que mis explicaciones pueden ser útiles, porque en general, en los tutoriales se entretienen muy poco en explicar los datos (y yo quizá me he entretenido demasiado). Hay un dato que he explicado, la inexactitud de los números en coma flotante, que muchas veces, cuando lo he mencionado, me han rebatido. Para el que esté interesado, en esta página  La Guía del Punto Flotante - Tipos exactos  explica

Lo primero que tenemos que saber, es que datos debemos guardar en la base de datos. Para ello, como yo estoy en España, busco la información en la página de la Agencia Tributaria española. Allí dice que la información que debe tener una factura es: Número y, en su caso, serie. La numeración de las facturas dentro de cada serie será correlativa. La fecha de su expedición. Nombre y apellidos, razón o denominación social completa, tanto del obligado a expedir factura (este creo que soy yo) como del destinatario de las operaciones. Número de Identificación Fiscal Domicilio, tanto del obligado a expedir factura como del destinatario de las operaciones Descripción de las operaciones, consignándose todos los datos necesarios para la determinación de la base imponible del Impuesto y su importe, incluyendo el precio unitario sin Impuesto de dichas operaciones, así como cualquier descuento o rebaja que no esté incluido en dicho precio unitario El tipo impositivo o tipos impositivos, en su caso,

 Todo comenzó con una idea en el grupo LibreOffice-ES de Telegram. En ese grupo propuse que comenzáramos a usar LibreOffice Base para poder opinar sobre la aplicación, aunque fuera con un proyecto pequeño. Así mismo, propuse que usáramos preferiblemente bases de datos Firebird porque, en algún momento, esta base de datos se propuso como base de datos por defecto en LibreOffice, e incluso, en algunas versiones, llegó a establecerse como tal. Debido a los errores que se producían se volvió a poner como base de datos experimental, dejando de ser la base de datos por defecto. A pesar de los errores que dicen que tiene, en mis pruebas y no me ha saltado ningún error grave; pero en todo caso, si usamos esta base de datos y apreciamos errores, podemos colaborar al desarrollo reportando los errores que observemos y además, reportando estos errores hacemos ver a los desarrolladores que hay interés en Base, para que presten un poco más de atención a esta aplicación. En línea con mi propuesta, o