Contabilidad en la nube

CONTABILIDAD EN LA NUBE Carlos Martínez Sacristán Enrique Ugedo Egido FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID TRABAJO FIN DE GRADO GRADO EN INGENIERÍA DE COMPUTADORES Y GRADO EN INGENIERÍA DEL SOFTWARE Curso académico 2016/2017 Madrid, 9 de febrero de 2017 Director: Luis Fernando Llana Díaz DEPARTAMENTO DE SISTEMAS INFORMÁTICOS Y COMPUTACIÓN I Índice Índice de figuras ................................................................................................ IV Resumen ............................................................................................................... V Abstract ............................................................................................................... VI Capítulo 1 Introducción ................................................................................... 1 Chapter 1 Introduction .................................................................................... 3 Capítulo 2 Estado del arte ............................................................................... 5 Sección 2.1 Python ...................................................................................... 5 2.1.a) Estructuras de datos ...................................................................... 6 Sección 2.2 Django ..................................................................................... 6 2.2.a) Formularios web ............................................................................. 7 2.2.b) Modelos y bases de datos ........................................................... 7 Sección 2.3 MySQL ...................................................................................... 8 2.3.a) phpMyAdmin .................................................................................. 8 Sección 2.4 GNUCash ................................................................................. 9 2.4.a) Base de datos .............................................................................. 10 Sección 2.5 Otras tecnologías de desarrollo de aplicaciones web . 12 2.5.a) PHP ................................................................................................. 12 2.5.b) Ruby on Rails ................................................................................. 13 2.5.c) Bottle .............................................................................................. 13 2.5.d) Flask ................................................................................................ 13 2.5.e) Pyramid ......................................................................................... 13 Sección 2.6 Otras aplicaciones de contabilidad ................................. 14 2.6.a) Quicken ......................................................................................... 14 2.6.b) Mint.com ....................................................................................... 14 2.6.c) MyValue ........................................................................................ 15 Capítulo 3 Aplicación web............................................................................ 16 Sección 3.1 Objetivos ................................................................................ 16 II Sección 3.2 Tecnologías utilizadas .......................................................... 17 3.2.a) Servidor Web ................................................................................ 17 3.2.b) Django ........................................................................................... 17 3.2.c) MySQL y phpMyAdmin ............................................................... 18 Sección 3.3 Metodología de trabajo ..................................................... 19 3.3.a) Máquinas virtuales ....................................................................... 19 3.3.b) Conexión al servidor .................................................................... 19 3.3.c) Control de versiones.................................................................... 20 3.3.d) Reuniones periódicas .................................................................. 21 Capítulo 4 Implementación .......................................................................... 22 Sección 4.1 Estructura del proyecto ....................................................... 22 4.1.a) Configuración del proyecto ...................................................... 24 4.1.b) Estructura de la aplicación ........................................................ 24 Sección 4.2 Base de datos ....................................................................... 30 Sección 4.3 Funcionamiento de las vistas ............................................. 33 4.3.a) Lista de cuentas ........................................................................... 33 4.3.b) Guardar asiento ........................................................................... 34 4.3.c) Ver cuenta .................................................................................... 34 4.3.d) Borrar entrada .............................................................................. 35 Sección 4.4 Tratamiento de los datos .................................................... 36 4.4.a) GUID ............................................................................................... 36 4.4.b) Consultas a la base de datos .................................................... 37 4.4.c) Tipos de cuentas GNUCash ....................................................... 37 4.4.d) Listar cuentas ................................................................................ 38 4.4.e) Totalizar cuenta ........................................................................... 39 4.4.f) Ver cuentas .................................................................................. 40 Sección 4.5 Dificultades encontradas durante la implementación . 42 4.5.a) Aprendizaje de las tecnologías ................................................. 42 4.5.b) GUID ............................................................................................... 42 4.5.c) Renombramiento de las tablas ................................................. 43 III 4.5.d) Cálculo del balance de una cuenta ....................................... 43 4.5.e) Integración del formulario en la vista de cuenta .................. 45 Capítulo 5 Resultados visibles ........................................................................ 46 Capítulo 6 Conclusiones y trabajo futuro .................................................... 51 Chapter 6 Conclusions and future work ..................................................... 53 Contribución de los participantes................................................................... 55 Carlos Martínez Sacristán .............................................................................. 55 Enrique Ugedo Egido ..................................................................................... 57 Referencias ......................................................................................................... 59 Glosario ................................................................................................................ 61 IV Índice de figuras Figura 1. Diagrama Entidad-Relación de GNUCash .................................... 11 Figura 2. Árbol de directorios ........................................................................... 23 Figura 3. Modelo de la tabla Accounts ......................................................... 25 Figura 4. Direcciones URL y vistas asociadas ................................................. 26 Figura 5. Código de la vista "listaCuentas" .................................................... 26 Figura 6. Código de la plantilla "lista_cuentas.html" .................................... 27 Figura 7. Hoja de estilos de "lista_cuentas.html" ........................................... 28 Figura 8. Algunos formularios del fichero "forms.py" ..................................... 29 Figura 9. Tablas utilizadas de la base de datos ............................................ 32 Figura 10. Vista principal de la aplicación de escritorio GnuCash ........... 46 Figura 11. Vista principal de la aplicación desarrollada ............................. 47 Figura 12. Vista detalle de cuenta en la aplicación .................................... 48 Figura 13. Vista detalle de cuenta en GnuCash .......................................... 48 Figura 14. Desplegable con lista de cuentas ................................................ 49 Figura 15. Confirmación de borrado .............................................................. 49 Figura 16. Formulario de inserción de asiento ............................................... 50 V Resumen Partiendo de la aplicación de contabilidad GNUCash, que proporciona un entorno en el que llevar las cuentas de gastos e ingresos, realizamos una aplicación web que utiliza la misma base de datos, pero siendo en este caso multiplataforma. Las modificaciones llevadas a cabo en esta aplicación serán interpretadas por GNUCash la siguiente vez que utilicemos la aplicación de escritorio para abrir la base de datos. Sus usuarios ya no necesitarán memorizar o anotar en otro lugar los movimientos monetarios del día a día para anotarlos en GNUCash al llegar a casa, sino que podrán introducirlos directamente en su móvil. Palabras clave: Contabilidad, finanzas personales, economía, ahorros, cuentas, bancos, crédito. VI Abstract The starting point of our project is the application GNUCash, that is an accounting application. We have started a Web application that uses the same database as GNUCash. So, we can use the application everywhere on any device. The modifications carried out on the database are compatible with those of GNUCash. So, both programs can be used indistinctly. The users' application will not need to memorize or to annotate in some other place their daily movements. Instead, they can annotate it directly in the GNUCash database one their mobile. Key words: Accounting, personal finance, economics, savings, accounts, banks, credit. VII 7 se podrían considerar genéricas, evitando reescribir la lógica de tareas comunes y un sistema de plantillas basado en etiquetas y que soporta herencia. Las URL se definen mediante expresiones regulares y su visita inicia la ejecución de la vista correspondiente, en la que puede haber cualquier tipo de función desarrollada en Python para atender a las necesidades concretas de cada momento, operación o consulta. Incluye protección CSRF para asegurarse de que los datos introducidos en formularios son válidos y acordes a los tipos definidos en los modelos relacionados con la base de datos. 2.2.a) Formularios web Una de las principales funciones de Django es la creación de formularios. Incorpora la librería Forms que permite crear formularios definidos desde cero o creando un ModelForm y se guardará el resultado del formulario en un modelo. Al utilizar ModelForm, se indican qué campos de un modelo se quieren incluir en el formulario e incluso es posible personalizar algunas opciones más del mismo. Se pueden utilizar campos de distintos modelos y definir un campo con un valor determinado por una función, cosa que será muy útil en la implementación de este proyecto. Posteriormente Django crea automáticamente el código HTML a partir de ese ModelForm. Al recibirse el formulario relleno, desde la vista puede gestionarse al gusto. Estos datos se introducen en el modelo correspondiente y por tanto, como se ha explicado anteriormente, en la base de datos. Es necesario incluir el token CSRF para evitar inconsistencia en los tipos de datos del formulario y del modelo. 2.2.b) Modelos y bases de datos Django permite una sincronización perfecta con la base de datos MySQL mediante la creación de modelos (Models) en lenguaje Python. Al desarrollar una aplicación en Django, se modificarán los datos recogidos en los modelos, y éstos se replicarán automáticamente en la base de datos MySQL. Existen comandos que crean los modelos a partir de una base de datos ya existente, recuperando también la información del tipo de variable correspondiente a cada una de las filas que conforman la tabla de la BBDD. 8 Sección 2.3 MySQL MySQL es un sistema gestor de bases de datos relacionales en SQL. Permite la gestión de una base de datos relacional usando un lenguaje de consulta estructurado. Es una de las mejores soluciones técnicas para gestión de bases de datos y quizás la más utilizada en la actualidad. Recientes estudios demuestran que MySQL tiene una velocidad superior a la de sus rivales, incluido Oracle, a la hora de ejecutar consultas SQL. Tiene soporte para bases de datos de grandes dimensiones. Permite hasta 64 índices por tabla. Es compatible con la práctica totalidad de los Sistemas Operativos existentes. Si a esto se le añade un lenguaje de programación también compatible, como Python, Java o PHP, permite desarrollar aplicaciones Web versátiles y fáciles de migrar a otros SO. Se ofrece bajo licencia GNU GPL para los usos compatibles. Para incorporarlo a productos privativos es necesario comprar una licencia específica que permita esos usos a la empresa. Está desarrollado en ANSI C. 2.3.a) phpMyAdmin Es una herramienta desarrollada en PHP que funciona como editor de bases de datos MySQL y permite también su administración a través de una interfaz web. Con ella se puede ejecutar cualquier sentencia SQL además de hacer operaciones básicas como crear, eliminar y editar bases de datos, tablas y entradas de forma sencilla e intuitiva. Otra opción interesante es la exportación e importación de datos en varios formatos. Se ofrece bajo la licencia GPL. 9 Sección 2.4 GNUCash GNUCash es un programa de contabilidad y gestión de finanzas enfocado sobre todo a particulares y pequeñas empresas. Es un programa de software libre que forma parte del proyecto GNU (tiene una licencia GPL) y es multiplataforma (GNU/Linux, Windows, macOS). Está basado en la doble entrada como sistema de contabilidad, es decir, cada movimiento de una cuenta tiene otra como contrapartida. Por ejemplo, un gasto de 30 euros en un restaurante se anota en la cuenta “Restaurantes”, perteneciente a la cuenta “Gastos”. Este dinero debe salir de algún sitio, y en este caso (suponiendo que se pague en efectivo), se anotará que salió de la cuenta “Metálico”, perteneciente a “Activo”. Es un programa en el que las transacciones se realizan de una forma totalmente transparente y se puede observar cómo se realizan los cálculos y ajustes, al contrario que otros programas de contabilidad más destinados a usuarios finales en los que no podemos ver su funcionamiento interno. Esto, unido a su diseño sencillo y visual, permite aprender rápidamente lo básico sobre contabilidad y cómo funciona el sistema de doble entrada. GNUCash permite la gestión de distintos tipos de cuentas que se detallarán más adelante. Cuentas de gastos, tarjetas de crédito, préstamos, y prácticamente todo lo que se requiera, ya que es muy configurable tanto para llevar el control de una cuenta real como simplemente para controlar tus gastos. Al crear un nuevo libro de contabilidad existen distintas opciones predefinidas, entre ellas la de “Cuenta común”, que por defecto incluye un árbol de cuentas en el que se engloban la mayoría de gastos o beneficios cotidianos, como sueldo, impuestos, suministros domésticos, comestibles, ocio, gastos médicos, etcétera. A parte se pueden crear otras subcuentas de gastos e ingresos para llevar un control eficiente de éstos, así como programar transacciones en el tiempo y automatizar muchas de estas entradas y salidas de capital (muy útil por ejemplo para gastos o ingresos fijos de cada mes, como el sueldo, la hipoteca, pagos de seguros, cuotas, etcétera). 10 Tiene otras funcionalidades muy interesantes como pueden ser la generación de gráficos o informes de cualquier operación. Hay multitud de opciones a la hora de generar estos gráficos y pueden exportarse a HTML. También está implementada la opción de hacer operaciones con una entidad bancaria de forma online (siempre que el sistema del banco soporte el estándar OFX o el HBCI). La importación de información financiera de otros programas (dependiendo del formato), el manejo de transacciones multi-divisas o la gestión de carteras de acciones/fondos de inversión son otras de las opciones disponibles. El libro de cuentas puede ser guardado en un único archivo XML o en una base de datos, gracias a que GNUCash ha añadido esta posibilidad. También se pueden exportar a un fichero CSV el árbol de cuentas o las transacciones. 2.4.a) Base de datos La versión 2.4.0. (publicada el 21 de diciembre de 2010) introdujo el motor gráfico WebKit y la posibilidad de operar usando bases de datos SQLite.3, MySQL o PostgreSQL además del usual formato de datos en XML. Para ello, la comunidad desarrolló un conjunto de tablas que recogían la información necesaria para que el programa funcione y todos los datos que anteriormente se guardaban en XML, así como las relaciones entre los datos de las distintas tablas y los GUID que actúan como claves primaria o secundaria en cada caso. Esto dio como resultado el diagrama entidad-relación que se muestra en la Figura 1. 11 Figura 1. Diagrama Entidad-Relación de GNUCash 12 Sección 2.5 Otras tecnologías de desarrollo de aplicaciones web 2.5.a) PHP Es un lenguaje de programación del lado del servidor orientado sobre todo al desarrollo web de contenido dinámico con acceso a información almacenada en una base de datos. Se puede integrar directamente en el HTML, evitando tener que llamar a un archivo externo que procese los datos. Un servidor web interpreta el código y genera la página web resultante. Normalmente se suele integrar con Apache como servidor web y MySQL como servidor de base de datos en entornos Linux en un paquete llamado LAMP, pero permite la conexión con diferentes tipos de servidores de bases de datos tanto SQL (PostgreSQL, Oracle, etc) como NoSQL (MongoDB, etc). PHP tiene las ventajas de ser el más usado y por tanto el que tiene mayor comunidad y documentación detrás. También cuenta con varios CMS (sistemas de administración de contenido), es decir, herramientas que permiten editar, crear, clasificar o publicar cualquier tipo de información en una página web, actuando sobre una base de datos. Los más famosos son WordPress, Joomla y Drupal. Por otra parte cuenta con gran cantidad de librerías y frameworks que facilitan diferentes tareas. Los más importantes son frameworks que utilizan el modelo MVC (Modelo-VistaControlador) como Symfony, Laravel o Codeigniter. Es un lenguaje más similar a C o a JavaScript que a lenguajes de marcas como HTML o XML. La principal diferencia con JavaScript es que éste se ejecuta en el navegador, mientras que PHP lo hace en el servidor. Por lo tanto puede acceder a cualquier recurso disponible en el servidor, como la base de datos. Además no requiere que el navegador del cliente sea compatible con PHP ya que la ejecución se hace en el servidor, que obviamente sí debe ser compatible, y el resultado se envía al navegador cliente, generalmente como una página en formato HTML o WML. Otra diferencia reseñable es que PHP es un lenguaje no tipado, es decir, sus variables no necesitan ser declaradas ni inicializadas. 13 2.5.b) Ruby on Rails Es un framework para desarrollar aplicaciones web de código abierto, escrito en el lenguaje de programación Ruby. Sigue el patrón MVC (Modelo-Vista-Controlador) y está diseñado para hacer más fácil la programación de aplicaciones web. Permite que escribiendo menos código se realice más que en otros lenguajes o frameworks, siempre que lo hagas según “el modo Rails”, es decir, que existe una forma que es mejor que las demás para hacer las cosas, y te permite ser más productivo en menos tiempo. Está basado en el principio DRY (Don’t repeat yourself), que significa que repetir código es una mala práctica y no se debe hacer. También se basa en otro principio “Convención sobre programación”, que significa que en lugar de requerir que especifiques toda la configuración, Rails hace suposiciones sobre lo que quieres hacer y cómo vas a hacerlo. 2.5.c) Bottle Bottle es un microframework muy simple desarrollado en Python que proporciona un mínimo de herramientas al desarrollador (enrutamiento, plantillas y una pequeña abstracción sobre WSGI). Está diseñado para ser rápido sencillo y ligero, ideal para desarrolladores que buscan flexibilidad, crear una API web, o programar algo realmente simple, con facilidad y rapidez. Soporta URL con parámetros, plantillas, base de datos clave-valor y complementos para muchos WSGI de terceros y plugins para bases de datos popuares. Puede ejecutarse como servidor web independiente. 2.5.d) Flask Flask es un framework minimalista escrito en Python que permite crear aplicaciones web rápidamente y con un número mínimo de líneas de código. Está basado en la especificación WSGI, el motor de templates Jinja2 inspirado en Django y tiene una licencia BSD. 2.5.e) Pyramid Pyramid es un framework web de código abierto escrito en Python y basado en WSGI. Es minimalista, inspirado en Zope, Pylons y Django. Forma parte del Pylons project. Está integrado tanto con bases de datos 14 SQL a través de SQLAlchemy, como con bases de datos de objetos Zope y otros NoSQL como CouchDB. Permite definir rutas usando expresiones regulares que se asignan a objetos. Permite también recorridos jerárquicos de objetos, siendo cada parte de la URL un objeto que contiene otros objetos, quedando parecida a la ruta de una carpeta en un sistema de archivos. Sección 2.6 Otras aplicaciones de contabilidad 2.6.a) Quicken Quicken es una herramienta de gestión de finanzas personales desarrollada por la empresa Quicken Ink (recientemente vendida por Intuit Inc a HIG Capital). Se ejecuta desde sistemas Windows y Macintosh. Las versiones iniciales, se lanzó por primera vez en 1983, se ejecutaban en DOS. Existen diferentes versiones de Quicken con más o menos características u orientadas a otras gestiones financieras como alquileres de viviendas. Es líder en el mercado de América del Norte pero las funciones básicas se utilizan ampliamente en otros países, habiendo sido adaptadas las versiones para una gran variedad de mercados. Quicken Online era una versión gratuita, alojada en los servidores de Intuit. La empresa almacenaba los datos del usuario y proporciona parches y actualizaciones automáticas del software de forma periódica. Posteriormente se lanzó como una suscripción de pago mensual. Durante el año de gratuidad consiguió más de 1,5 millones de clientes. Su desarrollo se detuvo en 2010 tras la compra de Mint.com 2.6.b) Mint.com Mint.com es quizás la alternativa más similar a lo desarrollado en este proyecto. Gratuito, basado en web, es un gestor de finanzas personales desarrollado por Aaron Patzer. Su área de servicio es Estados Unidos y Canadá, donde tiene acuerdos para la agregación de cuentas. Inicialmente con Yodlee pero actualmente utiliza Intuit para conectar las cuentas bancarias. Permite por tanto rastrear los movimientos, transacciones, saldos y préstamos a través de una única interfaz de usuario así como crear presupuestos y establecer metas. 15 Según últimos datos, Mint.com afirmó tener más de 20 millones de usuarios en 2016, el doble que tres años antes. Su punto débil más importante es la seguridad. Para su funcionamiento es necesario proporcionar los nombres de usuario y contraseñas de acceso a las oficinas electrónicas de los bancos del usuario. Estos datos son almacenados en las bases de datos de Mint.com en un formato desencriptable. Lo cual plantea preocupación ante posibles ataques que podrían poner esa información sensible al acceso de terceras personas malintencionadas. Algunos bancos proporcionan códigos de acceso alternativos con acceso de sólo lectura a la información financiera para el uso de esta aplicación. Reduce el riesgo de que un ser malintencionado, al obtenerlos, pudiera operar en las cuentas del usuario de Mint.com, pero sigue planteando un problema de privacidad en tanto que los datos económicos quedarían al descubierto. 2.6.c) MyValue MyValue es una aplicación que se asemeja mucho a GNUCash. Fundada en España en 2009, financiada por el CDTI del Ministerio de Ciencia e Innovación. Se conecta a los bancos del usuario para obtener la información actualizada de los movimientos en sus cuentas (esto lo permite GNUCash en algunos bancos, aunque normalmente se hará este paso de información a mano). MyValue permite además tener una cuenta de efectivo en la que ir anotando los gastos realizados con dinero en metálico y que por tanto no quedan reflejadas en las cuentas bancarias. Esta es la característica que nos motiva a introducirla en el estado del arte y que la diferencia de otra conocida aplicación, fintonic, que únicamente recopila los datos de los bancos, sin permitir al usuario introducir movimientos de forma manual. En la aplicación, que es multiplataforma (versión web para escritorio y aplicaciones móviles para Android y iPhone), se pueden categorizar movimientos según las preferencias del usuario, controlar recibos y facturas, hacer presupuestos que se ajusten a cada necesidad, fijar objetivos de ahorro y monitorizar inversiones. 16 Capítulo 3 Aplicación web Sección 3.1 Objetivos El objetivo de la aplicación web de GNUCash, es el de ofrecer un servicio web accesible a través de cualquier plataforma, mediante el que se puedan llevar de una forma sencilla las finanzas personales. Pudiendo consultar y modificar nuestras cuentas tan sólo necesitando un dispositivo con acceso a Internet. Utilizando la nube para el almacenamiento de estos datos. Se aprovechará que se ha introducido en GNUCash la posibilidad de almacenar la información en una base de datos externa, en lugar del XML local. En este caso se utiliza MySQL como servidor de bases de datos. De esta forma, se almacenarán los datos en la nube y serán accesibles desde internet. Se pretende permitir además que pueda haber varios usuarios conectados a la misma base de datos, o el mismo usuario en distintos dispositivos. Las vistas y los cambios que se realicen en cualquiera de estas sesiones, se reflejarán en la base de datos y se actualizarán de forma inmediata. Esto favorece que la aplicación web pueda usarse de forma simultánea en distintos dispositivos y que los datos contenidos siempre sean consistentes. Se mejorará así la alternativa de sincronizar el XML ya que si en ese caso hubiera varios usuarios modificando de forma simultánea, se crearía un conflicto con los ficheros XML y sólo perdurarían los datos del último fichero guardado, perdiéndose las modificaciones de los demás. El desarrollo de esta aplicación responde a la escasez de opciones en el mercado, libres y gratuitas, que permitan al usuario llevar sus cuentas tanto desde un ordenador como desde un Smartphone o una Tablet sin necesidad de descargarse una aplicación en cada dispositivo. 23 Esta aplicación web se compone de los siguientes ficheros y directorios, representados como un árbol de directorios, que se detalla a continuación y que da una visión global completa del proyecto y de la separación entre las distintas capas de la arquitectura de las que se ha hablado anteriormente. Figura 2. Árbol de directorios En Django, cada proyecto contiene una configuración, pero puede contener varias aplicaciones independientes cada una con sus modelos, vistas y platillas. Dentro del proyecto “tfg”, se encuentra otra carpeta “tfg”, que contiene la configuración del proyecto, y una carpeta “gnucash”, que es la aplicación, dentro de la cual se encuentran los modelos, vistas y plantillas. 24 4.1.a) Configuración del proyecto settings.py: El primer paso al crear el proyecto en Django fue configurarlo para poder usarlo con una base de datos MySQL. Para ello es preciso modificar el archivo settings.py, especificando el tipo de servidor de base de datos, el nombre de la base de datos (“gnucash”), usuario, contraseña, host y puerto. También es necesario configurar otro tipo de cosas, como registrar el nombre de la aplicación que se va a ejecutar o dónde se encuentra la carpeta con las plantillas de la aplicación. Para la base de datos, se configura el diccionario DATABASES con los datos requeridos. En este caso cabe destacar que el campo ENGINE debe definirse como django.db.backends.mysql para MySQL. debug.log: También se creó un sistema de logger en el proyecto (se configura en settings.py), que permitiese depurar y encontrar errores durante el desarrollo. Según el nivel especificado, se escriben los errores en caso de existir. Se pueden comprobar el valor de variables u objetos desde cualquier parte del código simplemente invocando al log, que lo escribirá todo en este archivo que se encuentra en la raíz del proyecto. 4.1.b) Estructura de la aplicación A continuación se explica qué son y el uso que se le da en este proyecto a los ficheros importantes que encontramos dentro de la aplicación. models.py: Es el fichero en el que se encuentran los modelos. Cada modelo es una clase en Python que representa cada tabla de la base de datos. Los modelos contienen los campos de cada tabla con su formato específico. En el fichero models.py de esta aplicación existen veinticuatro clases, que son las veinticuatro tablas correspondientes en la base de datos de GNUCash. Como se puede observar en la Figura 3, que se corresponde con el modelo de la tabla Accounts, el modelo es una clase de Python, en la que se define cada campo de la tabla con un tipo que hereda de models de forma que Django lo pueda interpretar. 25 Figura 3. Modelo de la tabla Accounts Así pues, por ejemplo el nombre de la cuenta (name) es un campo de texto de longitud máxima 2048 caracteres, lo que se corresponde con la secuencia: name = models.CharField(max_length=2048) De la misma forma, se definen el resto de campos de acuerdo al estándar de los modelos de Django. En este mismo ejemplo puede verse que los enteros se definen como IntegerField, o que la clave primaria del modelo se indica con la propiedad primary_key=true. Los modelos pueden contener la clase interna Meta, que sirve para dar metadatos al modelo, es decir, especificar todo lo que no es un campo, ya sean opciones de ordenamiento o el nombre de la tabla de la base de datos. En el ejemplo, se especifica el nombre de la tabla de base de datos con la opción db_table=’accounts’, y de acuerdo a la documentación de Django se indica la opción managed=False para especificar a Django que no administre la creación, modificación o eliminación de la tabla. Se dejará esta tarea en manos de la aplicación oficial de GNUCash. views.py: Aquí se encuentran todas las vistas del proyecto y funciones auxiliares utilizadas para hacer cálculos. Hay que recordar que las vistas son el núcleo programático de la aplicación. Las vistas están asociadas a una URLs. Esto se hace en un archivo que se encuentra dentro de la configuración del proyecto llamado urls.py. En este archivo se asocian los nombres de las vistas a una URLs concreta dentro del proyecto. En las 26 vistas se tratan los datos que posteriormente renderizamos en las plantillas como HTML que se mostrará en las URLs especificadas. En la Figura 4 se muestra como se asocia en el archivo urls.py las direcciones URL relativas a la dirección de ejecución del entorno, con la vista que se desea ejecutar al visitar la URL correspondiente. Las direcciones están escritas como expresión regular. Figura 4. Direcciones URL y vistas asociadas Tomando como ejemplo la vista listaCuentas, en la Figura 5 se muestra cómo funciona y cómo se implementa una vista en Django. Figura 5. Código de la vista "listaCuentas" Como se puede apreciar, una misma vista puede estar referenciada por distintas URLs, y éstas no tienen por qué coincidir con el nombre de la plantilla en la que retorna el resultado de ejecución de la vista. Una vista es una función Python, que recibe el entorno por request, y devuelve un conjunto de datos a una plantilla (lista_cuentas.html en este caso) por el método render_to_response. Los datos se convierten en 27 un objeto httpResponse con el contenido de la página solicitada. En la vista listaCuentas, se obtiene la lista de cuentas mediante consultas a la base de datos y se van introduciendo en una lista en Python que se envían como argumento a la plantilla para que los muestre en la página. templates: Esta carpeta contiene todas las plantillas HTML asociadas a URLs concretas. La plantilla index.html podría ser la pantalla inicial de la aplicación, muestra una lista de las operaciones implementadas desde la que se llamará a otras templates como asiento_nuevo.html, que es la pantalla en la que se muestra un formulario para crear un nuevo asiento e insertarlo en base de datos. También lista_cuentas.html, que muestra un listado con todas las cuentas del libro de cuentas, con su balance total. En cuenta.html se podrá ver al detalle cada cuenta con sus movimientos, cuentas destino, descripción, cantidades y fecha. Los templates en Django pueden extender a otros templates, característica que se utiliza por ejemplo con template.html, que es utilizado como cabecera para otras plantillas. Siguiendo con el ejemplo explicado en el apartado de views.py, se muestra la parte importante de la plantilla lista_cuentas.html. Figura 6. Código de la plantilla "lista_cuentas.html" 28 Se trata de un archivo HTML, en el que se introducen las sentencias Django entre llaves, con la sintaxis “{% sentencia %}” y las variables que llegan desde la vista entre dos llaves, con la sintaxis “{{ variable }}”. En el ejemplo mostrado, y en general en todas las plantillas de la aplicación, se extiende de la plantilla template.html personalizando el título (Lista de cuentas), y el contenido propio en HTML, mostrando la lista de cuentas con un bucle for de account_list, que es la lista recibida desde la vista. De esta lista se accede a los datos concretos utilizando “.” (punto) para determinar la posición correspondiente. Se pueden utilizar filtros de plantillas para alterar el valor de las variables como por ejemplo al mostrar el nombre de las cuentas: {{ account.0|safe|escape }} Para escapar de forma correcta el código HTML que se ha introducido en la vista. O para mostrar dos decimales en el balance, que es el formato utilizado por GNUCash y el más habitual para importes monetarios: {{account.1|floatformat:2|intcomma}} En las plantillas es también donde se introducen los estilos de la visualización de la página HTML con código CSS, buscando que se parezcan lo máximo posible al programa de escritorio. Figura 7. Hoja de estilos de "lista_cuentas.html" 29 forms.py: Contiene la definición de los formularios utilizados para solicitar información al usuario. Django ofrece una manera sencilla y útil para la creación de formularios dentro de la aplicación. Consiste en crear un archivo forms.py en el que se declaran los formularios importando los modelos de los que dependen dichos formularios. En views.py se crea la función que se encarga de realizar (en este caso) la inserción en base de datos. Desde la vista se le pasará el formulario al template para que lo muestre como HTML. En el de esta aplicación forms.py se crea el formulario que permite guardar un asiento en base de datos. Además de dos funciones que permiten que la elección de cuenta sea un desplegable con opciones en lugar de un campo de texto. Figura 8. Algunos formularios del fichero "forms.py" Como puede observarse, los formularios también son clases de Python. En ellas está contenida una clase Meta que es donde se indica el modelo en el que se basa el formulario, se seleccionan los campos que se esperan obtener mediante el formulario y se modifica si se desea algunos valores como las etiquetas que se mostrarán al usuario en cada campo. 30 Sección 4.2 Base de datos Este proyecto trata de complementar una aplicación existente con una base de datos ya existente, por este motivo, es necesario obtener esa base de datos directamente de la aplicación GNUCash. Para ello, se crea un libro de contabilidad nuevo y vacío desde la aplicación de escritorio y se guarda en el servidor MySQL. Una vez obtenida la base de datos MySQL, vacía pero con la estructura que necesita el programa, debe ser integrada en la aplicación, esto se hace mediante la creación de los modelos correspondientes a cada una de las tablas. Django ofrece una facilidad para crear de forma automática los modelos a partir de una base de datos existente. Lo primero que hay que hacer es, por supuesto, conectar la aplicación que estamos desarrollando con la base de datos, como hemos indicado anteriormente, en settings.py. Una vez creado el entorno, se lanza la ejecución del siguiente comando desde la carpeta en la que se encuentra el entorno python manage.py inspectdb > myapp/models.py Tras su ejecución, se crean en models.py las veinticuatro clases correspondientes a las tablas de la base de datos. Sobre estos modelos generados automáticamente, es necesario hacer una serie de modificaciones en ellos para que funcionen de manera correcta. • Django agrega automáticamente un campo id de clave primaria si el modelo no lo tiene. Habrá que quitar esas líneas y establecer como clave primaria el campo de GUID correspondiente. • El comando inspectdb no puede detectar si un campo es autoincrementado, así que habrá que cambiar a AutoField los que corresponda. • Hay que comprobar que los tipos de cada columna (VARCHAR, DATE…) se han convertido correctamente a tipos de cada campo del modelo (CharField, DataField…) 31 El siguiente paso será crear las tablas del núcleo de Django, esto se consigue con el comando python manage.py migrate --fake Así se sincroniza el estado de la base de datos con el conjunto de modelos. Al hacerlo, Django modifica el nombre de las tablas en MySQL añadiendo el prefijo con el nombre de la aplicación, de forma que la tabla Split, por ejemplo, pasa a llamarse gnucash_Splits. Eso no es lo que se quiere para esta aplicación ya que al cambiar el nombre de las tablas, éstas no serían reconocidas por la aplicación de escritorio GNUCash y la intención es que sí lo sea. Es por ello por lo que se añade la opción --fake. Por otra parte, a pesar de tener veinticuatro tablas en la base de datos, este proyecto está enfocado en las funcionalidades más básicas de GNUCash, buscando ofrecer la posibilidad de agregar un asiento nuevo a la cuenta correspondiente en la base de datos. En general, hay muchas tablas que son para funciones específicas que incluso desde la aplicación de escritorio, un usuario particular no llegaría a utilizar. Las funcionalidades implementadas requieren únicamente el uso de tres tablas, que son las que se muestran a continuación. 32 Figura 9. Tablas utilizadas de la base de datos • Accounts: es la tabla que contiene las cuentas de nuestro libro de cuentas, en la que se almacena su nombre, su GUID, su tipo, la cuenta padre o su descripción. • Transactions: contiene todas las transacciones, que son los movimientos que se producen cuando se mueve dinero entre dos cuentas. Se almacena entre otros, su GUID, su descripción y la fecha en la que se produjo. Al crearse una transacción se crean dos Splits asociados a cada cuenta en la que se produce el movimiento. • Splits: en esta tabla se almacenan todos los Splits, asociados a una transacción y a una cuenta. Se almacena su GUID, el GUID de la cuenta, el GUID de la transacción, y su valor, entre otros datos. 39 Se utiliza una lista auxiliar Account_toHTML, que reorriendo la lista de cuentas, por cada una va añadiendo a Account_toHTML el nombre de la cuenta (el último nombre de la lista) concatenado a un número de espacios multiplicado por cada padre que tenga, para que al mostrarlo en la plantilla como HTML salga tabulado como un árbol de directorios, junto con una etiqueta href con el GUID de la cuenta, y el total, calculado mediante una función auxiliar totalizarCuenta. account_toHTML.append((' ' * (len(account_list[i][0])-1) + '<a href="/cuenta.html?guid=' + account_list[i][1] + '">' + account_list[i][0][-1] + '</a><br/>',totalizarCuenta(account_list[i][1]))) Esta lista se envía a la plantilla lista_cuentas.html para que muestre el directorio de cuentas con enlaces a cada cuenta. 4.4.e) Totalizar cuenta Para calcular el total de cada cuenta, es decir la suma de los movimientos de esa cuenta y la de sus hijos, se llama desde listaCuentas a una función totalizarCuenta a la que se le pasa el GUID de la cuenta. En dicha función se obtienen los Split asociados a esa cuenta y se suma su valor a una variable amount. En el caso de que las cuentas sean de tipo “income”, “liability” o “equity”, no se suma sino que se resta el valor del Split. Luego se obtienen los hijos de esa cuenta y se recorren llamando recursivamente a totalizarCuenta pasándole el GUID de cada hijo, y añadiendo a amount los totales de cada cuenta. 40 4.4.f) Ver cuentas Para mostrar los movimientos de cada cuenta concreta en la plantilla cuenta.html, desde la vista verCuentayAsiento hay que realizar un filtrado de los datos para tratarlos y mostrarlos de la forma en la que lo hace GNUCash. Lo primero que se hace en esta vista, es extraer los Split de la cuenta deseada, cuyo GUID llega por GET (o POST si se ha insertado un asiento). Se hace de la siguiente forma: splits = Splits.objects.filter(account_guid=request.GET['guid']) Recorriendo la lista de Splits, por cada uno se realizan una serie de operaciones. Se convierte su valor a decimales, ya que por ejemplo 10,50€ en base de datos se guardará como 1050: split.value_num = split.value_num/float(split.value_denom) Mediante consultas, se obtiene la transacción asociada al Split y a partir de ésta el Split complementario, desde el que se recuperará la cuenta a la que va el dinero de ese movimiento consultando a Accounts con el GUID de dicho Split. Por cada Split se genera una tupla con las fechas (para ordenar), el Split, la transacción, el balance y el valor, que se añade a una lista de asientos: t=(transaction_split.post_date, transaction_split.enter_date,split,transaction_split, split2_account,balance,-split.value_num) asientos.append(t) Se ordenan los asientos por fecha, con la función sort() ya que la fecha es el primer valor de la tupla. Después se va sumando el valor de cada Split al balance de la cuenta, salvo en el caso de que las cuentas sean de tipo “income”, “liability” o “equity”, que no suman sino que restan el valor del Split. Por último se actualiza la tupla que se pasará a la vista, quitando las fechas y guardando el balance asociado a cada asiento. Los elementos se van insertando en la tupla con el método append(asiento), pero podría utilizarse otro método para insertar al principio e invertir el orden en que se muestran los movimientos. 41 Esta vista integra también el formulario para añadir asientos, por lo que se comprueba si se ha recibido una llamada por el método POST. En caso afirmativo, se realizan las operaciones necesarias para tratar el formulario recibido e insertarlo en la base de datos. Se crea una variable de tipo Transactions y dos de tipos Splits, en ellas se genera un GUID para cada una y se van introduciendo los datos correspondientes según los recibidos por POST. En uno de los Split, el campos account_guid corresponde al GUID recibido por GET, de la cuenta que se está mostrando. Una vez asignados todos los valores se guardan en la base de datos con la función save() y se actualiza la vista de la cuenta. Los formularios vienen de los definidos en forms.py, que ya se han explicado anteriormente, y se pasan a la vista a través del método render. 42 Sección 4.5 Dificultades encontradas durante la implementación El desarrollo de un proyecto basado en una aplicación existente siempre supone un reto en el cual pueden surgir complicaciones inesperadas. La aplicación existente puede tener sus peculiaridades y éstas hacer que adaptar otra versión sea algo laborioso o que produzca dolores de cabeza y atascos en la implementación del proyecto. 4.5.a) Aprendizaje de las tecnologías Cabe destacar que ninguno de los componentes del grupo tenía conocimientos de las tecnologías que se usan para el desarrollo de la aplicación, tanto Python como Django, lo que supuso un problema desde el principio, obligando a dedicar más tiempo al estudio y aprendizaje de las tecnologías que al desarrollo en sí de la aplicación. Aprender cómo usar el framework Django requirió del seguimiento de muchos tutoriales online y de sobretodo la implementación como aprendizaje de pequeños proyectos Django enfocados a la integración de formularios con una base de datos. 4.5.b) GUID Ya se ha explicado anteriormente como obtener el GUID utilizado como clave primaria en las entradas de tabla de la base de datos de GNUCash, por lo que no volveremos a detallarlo. Pero cabe destacar la dificultad que supuso este hecho. Los modelos de Django crean por defecto un id que se utiliza como clave primaria y es autoincremental. Esto modificaría también la base de datos y no sería compatible con GNUCash. El formato en que se guardaba el dato no era estándar, por lo que fue necesario aplicar un tratamiento al UUID obtenido. Las primeras pruebas, con inserciones a mano en la base de datos, con estos UUID obtenidos, daban un error al abrir la base de datos con GNUCash, que avisaba de que la base de datos podía haber sido modificada por una aplicación externa, como indicando que algo podría estar yendo mal y el funcionamiento de la aplicación verse afectado negativamente por este hecho. 43 Existe en el repositorio SVN de GNUCash unos ficheros referentes al GUID, incluso alguno en Python, pero no ha sido posible hacer uso de ellos al no poderse integrar fácilmente en nuestra aplicación. 4.5.c) Renombramiento de las tablas La base de datos de GNUCash es bastante extensa, como se pudo ver en el diagrama entidad-relación capítulos antes. Aunque para esta aplicación no se utilicen todas las tablas, se consideró oportuno hacer la migración de todas ellas para favorecer el desarrollo de nuevas funciones en el futuro. Hacer eso de forma manual habría sido demasiado laborioso y propenso a errores humanos. Como se ha explicado anteriormente, Django proporciona una facilidad en este aspecto. El problema vino cuando al usar ese comando, creaba los modelos, sí, (aunque era pertinente realizar algunas comprobaciones) pero también hacía modificaciones en la base de datos. Renombraba todas las tablas, concatenando a su nombre original (el utilizado por GNUCash) con el prefijo del nombre de la aplicación Django. Quedando por ejemplo la tabla Accounts de la forma tfgapp_Accounts. Esto evidentemente no iba a ser entendido por GNUCash en el escritorio. Fue necesario buscar otras alternativas para evitar que esa concatenación se realizase. En concreto, se especificó el nombre en el campos db_table de la clase Meta de cada uno de los modelos autogenerados. 4.5.d) Cálculo del balance de una cuenta Es curioso que en ningún lado se guarda el balance de la cuenta tras un movimiento ni el balance total actual de la cuenta. Puede tener sentido para permitir meter asientos nuevos entre otros ya existentes (habría entonces que modificar los balances de todos los asientos con fecha posterior). Además así se permite mostrar el balance resultante tras cada asiento por órdenes distintos, por ejemplo, por fecha valor o por fecha de introducción. Más fácil sería almacenar un total como balance actual de una cuenta, en una variable más de Accounts. Pero GNUCash no lo tiene así configurado. 44 Por un lado, al mostrar la lista completa de las cuentas, se debe mostrar el saldo de cada una de ellas. Es necesario por lo tanto recuperar todos los asientos (Splits) de esa cuentas y hacer la suma de todos sus importes. Por otro lado, al acceder a una cuenta para ver sus movimientos, tras cada uno de ellos se debe mostrar también el balance resultante tras ese movimiento. El hecho de que las plantillas en Django no permitan la modificación de variables, ni apenas operaciones desde el propio template, supuso un problema debido a que desde la vista se le pasa a la plantilla una lista de asientos, en la que se incluye cada Split asociado, con el valor del movimiento. Este valor es el que se almacena en base de datos, es decir, puede ser positivo o negativo, pero en la plantilla siempre se muestra como positivo, variando su posición entre la columna del “debe” y del “haber”. A su vez, se debía hacer un cálculo del balance resultante tras introducir el asiento. Tanto este cálculo como la modificación de mostrar el valor siempre en positivo hubiese sido muy simple hacerlo directamente en la plantilla a medida que va mostrando cada movimiento, simplemente cambiándole el signo al valor y sumándolo o restándolo a una variable balance. Al encontrar el problema de no poder hacer cálculos en la plantilla, se modificó el comportamiento de la vista para enviar a la plantilla los datos ya tratados. En la vista se creó una variable balance que se incrementa dependiendo del tipo de cuenta y del valor del movimiento. Se pasa a la plantilla este valor también con el signo cambiado. Asociando estos datos en una misma tupla del movimiento correspondiente. Al pasarle una lista con estas tuplas a la plantilla se pueden mostrar los datos de la forma que lo hace GNUCash. 45 4.5.e) Integración del formulario en la vista de cuenta Django facilita tanto la creación de formularios que genera automáticamente el código HTML para crearlo y mostrar los campos necesarios. Permite elegir distintos formatos, como párrafo, como tabla… pero ninguno se adaptaba bien a la tabla en la que debía mostrarse, además de que no se debían mostrar también las etiquetas, puesto que estas están en la primera fila de la tabla. Para ello se recorren desde la plantilla todos los campos de cada formulario y se inserta únicamente el field de cada campo, entre las etiquetas de columnas (<td>). Por otro lado, el ancho de estos campos era automático y descuadraba ligeramente la vista final de la página HTML, por lo que se añadió al CSS la condición de que éstos campos ocupasen un porcentaje de ancho de la columna en vez de un ancho fijo. Para mostrar una cuenta concreta, se la identificaba pasando el GUID por GET. Al querer integrar el formulario en la misma plantilla, resultó que éste pasaba datos por POST y no se podía interpretar también el GET. Esto se solucionó poniendo un campo de tipo hidden (oculto) en el formulario, de forma que en caso de recibirse un nuevo asiento, identifique la cuenta que debe mostrar por el GUID recibido desde POST en vez de desde GET. 46 Capítulo 5 Resultados visibles La aplicación presenta en su vista inicial una lista de las cuentas disponibles y el balance de cada una de ellas. Esta vista es similar a la mostrada por la pantalla principal de la aplicación de escritorio GNUCash, mostrando también las cuentas en cascada en función de la categorización existente. Figura 10. Vista principal de la aplicación de escritorio GnuCash 47 Figura 11. Vista principal de la aplicación desarrollada 48 Al pinchar en cualquiera de las cuentas se accede al detalle de la misma. En esta página se muestran los movimientos en detalle, ordenados del más antiguo al más reciente. Los detalles incluyen una fecha operación y fecha valor, descripción, cuenta destino, importe de entrada o de salida y balance posterior. La última línea de la lista de movimientos detalle de una cuenta está compuesta por campos vacíos de un formulario en el que rellenar los datos correspondientes para crear un nuevo movimiento. Al enviar el formulario, si los datos son válidos, se inserta automáticamente el asiento y se actualiza la vista de la cuenta en consecuencia. Figura 12. Vista detalle de cuenta en la aplicación Figura 13. Vista detalle de cuenta en GnuCash 55 Contribución de los participantes Carlos Martínez Sacristán Respecto a la aportación de cada alumno al proyecto, cabe destacar que no ha habido un reparto de tareas estricto, por lo que ambos generalmente hemos trabajado en las mismas materias conjuntamente, aunque hay tareas y desarrollos en los que un componente ha trabajado de una forma más destacada que el otro. De forma individual, lo primero a hacer fue instalar el programa GNUCash y comenzar a usarlo en el día a día para aprender su funcionamiento básico y centrarnos en qué queríamos desarrollar en nuestra aplicación web. Tras tener creado un entorno en una máquina virtual en el que poder desarrollar, me centré en buscar documentación de Django y seguir tutoriales para poder conectar un proyecto Django con una base de datos en MySQL, creando varios proyectos de prueba, en los que poco a poco se fueron integrando nuevas funcionalidades, creando formularios que modificaban la base de datos, y aprendiendo la forma en la que se relacionan las vistas con las plantillas en Django. También se hicieron pruebas de sincronización de los modelos con las tablas de la base de datos para ver de qué forma podíamos integrar la base de datos de GNUCash en nuestro proyecto. Durante el desarrollo, hubo mucha tarea de investigación sobre el funcionamiento de GNUCash y la forma en que podíamos desarrollarlo en Django y Python. Primero, con las relaciones entre las tablas de la base de datos, en las que creamos asientos en el programa original y posteriormente vimos el comportamiento de la base de datos desde phpmyadmin, para así poder investigar cómo desarrollarlo en Django, y obtener finalmente el mismo funcionamiento en nuestro proyecto que en la aplicación original. También requirió de investigación la forma de tratar los datos en Python, el funcionamiento de las colecciones, la búsqueda de métodos apropiados para cada momento, ya que a medida que se desarrolla la aplicación surgen requisitos en cuanto a la forma de obtener y mostrar los datos que requieren de modificaciones con Python, y al ser un lenguaje con el que no habíamos trabajado, tuvimos que buscar constantemente documentación. 56 Hubo que crear y configurar el proyecto que posteriormente usaríamos como proyecto definitivo, realizando la configuración para poderlo usar con MySQL y preparándolo para poder integrar la base de datos de GNUCash. Aunque la mayor parte del proyecto está implementado de forma conjunta, hay funcionalidades desarrolladas por mi parte, como la parte de la lógica e implementación de mostrar los detalles de cada cuenta. Para ello hubo que investigar tanto la forma en la que mostraba los datos GNUCash como la forma de tratar los datos para mostrarlos de la misma manera en nuestro proyecto. Otra tarea fue buscar documentación para crear un log de errores que nos permitiese debuguear y encontrar fallos durante el desarrollo, y que posteriormente hubo que implementar. Para que la aplicación tuviese un aspecto similar al de GNUCash, se fueron aplicando estilos con CSS a las plantillas de la lista de cuentas y de ver cada cuenta, de forma que ambas plantillas quedaran con un formato de tabla bastante intuitivo a la hora de usar la aplicación, y lo más parecido posible al programa ya desarrollado. La aplicación ha requerido de pruebas constantes durante su desarrollo que nos han permitido ver fallos en la forma de mostrar los datos o errores que podían afectar al correcto funcionamiento de la base de datos. Hemos realizado modificaciones a raíz de estas pruebas solucionando problemas que no eran graves pero que si provocaban errores tanto en la forma de visualizar los datos como en cálculos con éstos que podían guardarse, por lo tanto mal, en la base de datos. Fruto de esto hemos arreglado cosas como el nombre de las columnas dependiendo de la cuenta que se esté mostrando (haciéndolo de acuerdo a GNUCash), el formato de los decimales tanto en la lista como en los detalles de la cuenta, el tener en cuenta el tipo de cuenta para calcular el balance, debido a que unas suman al balance final y otras restan, o la ordenación de la lista para que muestre las cuentas sólo con su nombre sin el nombre de sus padres delante, entre otras. 57 Enrique Ugedo Egido La elaboración de este proyecto ha sido bastante horizontal y ambos componentes hemos trabajado en la mayor parte del mismo de forma paralela y ayudándonos mutuamente, sin haber existido una separación estricta de funciones. Dicho esto, es evidente que ambos hemos desarrollado diferentes partes necesarias para el proyecto de forma individualizada. Lo primero de todo fue crear el entorno de pruebas en el que íbamos a familiarizarnos con el funcionamiento de la aplicación GNUCash, con lenguaje de programación Python y empezar a usar Django para desarrollar aplicaciones web de prueba. Para ello se creó la máquina virtual en VirtualBox con Ubuntu e instalaron los paquetes necesarios para la integración de todos los servicios, así como la aplicación de escritorio de GNUCash y los complementos que permiten su uso con bases de datos MySQL. Después fue necesario realizar un trabajo de investigación sobre GNUCash por lo que me encargué de buscar toda la información relativa a la organización de la base de datos, así como su diagrama entidadrelación y las peculiaridades de sus campos clave (GUID) y la forma de obtenerlos mediante comandos de Python y de integrar que éste se incluyera de forma automática al rellenar un formulario. También se estudió el comportamiento de los distintos tipos de cuenta para poder totalizar su balance en la función correspondiente. Para continuar con esta investigación se consultaron los archivos de código fuente, alojados en un svn, en busca de funciones que nos pudieran ser útiles para nuestra aplicación, así como la documentación correspondiente. También me suscribí a las listas de correo de desarrolladores para consultar algunas dudas y para estar al tanto de las novedades o bugs que se encontraban, por si alguno de estos pudiera afectar al normal desarrollo de nuestro proyecto. Del mismo modo, se utilizaron en alguna ocasión la sala de chat de desarrolladores en IRC para preguntar alguna duda concreta. Como el desarrollo de la aplicación se ha llevado a cabo directamente en el servidor, se creó una carpeta de Dropbox, con una cuenta específica, que permitía la sincronización de todos los ficheros. El motivo principal era poder utilizar entornos de programación más cómodos que la línea de comandos. 58 Para poder colaborar también en la parte de programación propiamente dicha seguí los tutoriales que me recomendó Carlos para aprender a hacer formularios en Django y alguno más que encontré, aparte de hacer pruebas propias de mi curiosidad para comprobar el comportamiento del programa con cosas poco habituales. Desarrollé algunas funciones de especial interés para el proyecto como la que obtiene el balance total de la cuenta, la lista de cuentas jerarquizada por categorías (o cuentas padre), una gran parte del método que recupera los datos de un formulario para grabarlos en distintas tablas de la base de datos y la función que permite borrar entradas desde la vista de cuenta eliminando tanto el Transaction como ambos Splits. Tal como se desarrolló el formulario individualizado de añadir un asiento nuevo. También realicé la integración del formulario de asiento nuevo en la vista detalle de una cuenta. Cambiando algunos aspectos como que se muestre de forma ordenada por fecha, lo que obligó a hacer un nuevo mecanismo de cálculo del balance tras cada asiento, que también adapté. Por último, me he encargado de realizar pruebas de funcionamiento durante todo el proceso y especialmente al final. Detectando algunos fallos como la posibilidad de que al crear un asiento nuevo se pueda producir un fallo de algún tipo al escribir el Split en la base de datos, pero posterior a la escritura del Transaction, lo que crearía una inconsistencia en los datos al existir una transacción sin asientos asociados, o con solo un asiento. Este mismo fallo se da también para el caso de eliminar. Consecuencia de estas pruebas se han realizado algunas modificaciones para ajustar el funcionamiento de la aplicación al esperado, por ejemplo: Aplicar la diferenciación antes descrita de tipos de cuentas a la hora de calcular su balance (las cuentas de ingresos, deudas y equidad suman los asientos negativos, por así decirlo) y dar formato a la presentación de los balances, para mostrar 2 decimales y alineados a la derecha. 59 Referencias [1] Django Project, “Django documentation,” 2005-2017. [Online]. Available: https://docs.djangoproject.com/en/1.10/. [2] Django Project, «Documentación de Django,» 2005-2017. [En línea]. Available: https://docs.djangoproject.com/es/1.10/. [3] Python, «Python 3.6.0 documentation,» 2001-2017. [En línea]. Available: https://docs.python.org/3/. [4] S. Infante Montero, «Maestros del Web,» 7 mayo 2012. [En línea]. Available: http://www.maestrosdelweb.com/curso-django-elmodelo-de-datos/. [5] The GnuCash Project, “Documentation,” 2001-2016. [Online]. Available: http://gnucash.org/docs.phtml. [6] T. G. Project, “SQL - GnuCash,” [Online]. Available: https://wiki.gnucash.org/wiki/SQL. [7] D. A. N. Harrington, “Hands-on Python Tutorial,” 18 enero 2014. [Online]. Available: http://anh.cs.luc.edu/python/handson/3.1/handsonHtml/ifstatements.html. [8] CODEHERO, «Django desde Cero,» 2013-2015. [En línea]. Available: http://codehero.co/series/django-desde-cero.html. [9] DjangoGirls, «Introducción · Django Girls Tutorial,» [En línea]. Available: https://tutorial.djangogirls.org/es/. [10] Maestros del Web, «Categoría "django",» 2012. [En línea]. Available: http://www.maestrosdelweb.com/guias/guias-django/. [11] R. M. Nikos Drakos, «Guía de aprendizaje de Python 5. Estructuras de datos,» 11 septiembre 2005. [En línea]. Available: http://pyspanishdoc.sourceforge.net/tut/node7.html. [12] J. K.-M. Adrian Holovaty, El libro de Django 1.0, 2007. [13] R. Gruet, “Python 2.7 Quick Reference,” 16 abril 2013. [Online]. Available: http://rgruet.free.fr/PQR27/PQR2.7.html. [14] R. Brown, “Django vs Flask vs Pyramid: Choosing a Python Web Framework,” 2016. [Online]. Available: https://www.airpair.com/python/posts/django-flask-pyramid. [15] R. Necaise, “Python for Java Programmers | Main / Table of Contents,” 2006-2008. [Online]. Available: http://python4java.necaiseweb.org/Main/TableOfContents. 60 [16] «Django-es - Grupos de Google,» [En línea]. Available: https://groups.google.com/forum/#!forum/django-es. [17] A. Sarasa Cabezuelo, Gestión de la información web usando Python, Editorial UOC, 2016. [18] Colaboradores de Wikipedia, «Django (framework),» Wikipedia, La enciclopedia libre, 2017. [En línea]. Available: https://es.wikipedia.org/wiki/Django_(framework). [19] Colaboradores de Wikipedia, «GnuCash,» Wikipedia, La enciclopedia libre, 2016. [En línea]. Available: https://es.wikipedia.org/wiki/GnuCash. [20] Colaboradores de Wikipedia, «Ruby on Rails,» Wikipedia, La enciclopedia libre, 2016. [En línea]. Available: https://es.wikipedia.org/wiki/Ruby_on_Rails. [21] Colaboradores de Wikipedia, «PHP,» Wikipedia, La enciclopedia libre, 2017. [En línea]. Available: https://es.wikipedia.org/wiki/PHP. [22] Colaboradores de Wikipedia, «Python,» Wikipedia, La enciclopedia libre, 2017. [En línea]. Available: https://es.wikipedia.org/wiki/Python. [23] Colaboradores de Wikipedia, «MySQL,» Wikipedia, La enciclopedia libre, 2017. [En línea]. Available: https://es.wikipedia.org/wiki/MySQL. [24] W. Rosita, M. Margarita, C. Maximiliano, M. Marcos y P. Nicolás, «Algoritmos de Programación con Python,» [En línea]. Available: http://librosweb.es/libro/algoritmos_python/. 61 Glosario ANSI C Es un estándar publicado por el Instituto Nacional Estadounidense de Estándares (ANSI), para el lenguaje de programación C., 8 API Application Programming Interface, es un conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción., 13 APT Advanced Packaging Tool (Herramienta Avanzada de Empaquetado), abreviado APT, es un sistema de gestión de paquetes creado por el proyecto Debian., 17, 19 BBDD Bases de datos, 7 C Es un lenguaje de programación, como evolución del anterior lenguaje B, a su vez basado en BCPL., 12 CouchDB Apache CouchDB, comúnmente llamada CouchDB, es un gestor de bases de datos de código abierto, cuyo foco está puesto en la facilidad de su uso y en ser "una base de datos que asume la web de manera completa"., 14 CRUD Create, Read, Update and Delete o "Crear, Leer, Actualizar y Borrar" en español. Se usa para referirse a las funciones básicas en bases de datos o la capa de persistencia en un software., 17 CSS Hojas de estilo en cascada (o CSS, siglas en inglés de Cascading Stylesheets) es un lenguaje de diseño gráfico para definir y crear la presentación de un documento estructurado escrito en un lenguaje de marcado., 28, 40, 47 DOS Disk Operating System, "Sistema Operativo de Disco" y "Sistema Operativo en Disco", es una familia de sistemas operativos para computadoras personales (PC)., 14 framework Es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software., 6, 13, 17, 19, 37, 42, 44 62 GET Método de HTTP para recuperar datos de un servidor. El método GET solicita un recurso del servidor indicado en el campo URI., 31, 32, 36, 40 github GitHub es una forja (plataforma de desarrollo colaborativo) para alojar proyectos utilizando el sistema de control de versiones Git., 20 GNU Es un sistema operativo de tipo Unix desarrollado por y para el Proyecto GNU. Está formado en su totalidad por software libre, mayoritariamente bajo términos de copyleft., 2, 4, 9 HBCI Homebanking Computer Interface. Archivo de almacenamiento de datos de cuentas., 10 HTML HyperText Markup Language (lenguaje de marcas de hipertexto), hace referencia al lenguaje de marcado para la elaboración de páginas web., 6, 7, 10, 12, 22, 26, 27, 28, 31, 32, 36, 37, 40, 42, 44 HTTPS Hypertext Transfer Protocol Secure (Protocolo seguro de transferencia de hipertexto), es un protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos de Hipertexto, es decir, es la versión segura de HTTP., 43, 44 IRC Internet Relay Chat. Es un protocolo de comunicación en tiempo real basado en texto, que permite debates entre dos o más personas., 48 Java Lenguaje de programación de propósito general, concurrente, orientado a objetos que fue diseñado específicamente para tener tan pocas dependencias de implementación como fuera posible., 8, 17 JavaScript Lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos,3 basado en prototipos, imperativo, débilmente tipado y dinámico. Utilizado en el lado del cliente., 12 Jinja2 Motor de templates para Python., 13 LAMP LAMP es el acrónimo usado para describir un sistema de infraestructura de internet que usa las siguientes herramientas Linux, Apache, MySQL/MariaDB, Perl/PHP/Python., 12 LAMPP Paquete Linux para la instalación LAMP. Similar a XAMPP, 17, 19 licencia BSD Berkeley Software Distribution. Es una licencia de software libre permisiva, 6, 13 63 Licencia GNU "GPL" General Public License. Es la licencia de derecho de autor más ampliamente usada en el mundo del software libre y código abierto, y garantiza a los usuarios finales la libertad de usar, estudiar, compartir y modificar el software, 8, 9 OFX Open Financial Exchange File. Archivo de almacenamiento de datos de cuentas, 10 ORM Object-relationl Mapping, 17 POST Método de HTTP para recuperar datos de un servidor. El método POST se utiliza para pasar explícitamente datos al servidor en el propio mensaje de solicitud., 40 Proteccion "CSRF" Cross-site request forgery o falsificación de petición en sitios cruzados) es un tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía., 7 Pylons Es un framework web ligero y hace mucho énfasis en la flexibilidad y el rápido desarrollo. escrito en Python., 13 request Solicitud que se realiza a un servidor mediante protocolo HTTP. El servidor procesa la solicitud del cliente y devuelve una respuesta., 22, 26, 36 shell Término usado en informática para referirse a un intérprete de comandos, el cual consiste en la interfaz de usuario tradicional de los sistemas operativos basados en Unix y similares como GNU/Linux., 5 SO Sistema Operativo, 8 SQL Structured Query Language. En español lenguaje de consulta estructurada. Es un lenguaje específico del dominio que da acceso a un sistema de gestión de bases de datos relacionales que permite especificar diversos tipos de operaciones en ellos., 8, 12, 14, 18 SQLAlchemy Es un ORM para python. Incluye soporte para SQLite, MySQL, PostgreSQL, Oracle, MS SQL, entre otros., 14 SSH Secure SHell, en español intérprete de órdenes seguro. Es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red., 19 64 SVN Apache Subversion. Es una herramienta de control de versiones open source basada en un repositorio cuyo funcionamiento se asemeja enormemente al de un sistema de ficheros., 48 URL Uniform Resource Locator. Es un identificador de recursos uniforme (Uniform Resource Identifier, URI) cuyos recursos referidos pueden cambiar, esto es, la dirección puede apuntar a recursos variables en el tiempo., IV, 7, 13, 14, 26, 31, 32, 43, 45 WML (Wireless Markup Language) es el lenguaje para crear páginas que puedan ser desplegadas en los móviles a través de interfases visuales de los micro-navegadores (WAP Browsers) hechos para tal fin. WML está definido como una aplicación XML 1.0., 12 WSGI Web Server Gateway Interface. WSGI es una interface simple y universal entre los servidores web y las aplicaciones web o frameworks., 13 XML eXtensible Markup Language o "Lenguaje de Marcas Extensible" es un meta-lenguaje que permite definir lenguajes de marcas, utilizado para almacenar datos de forma legible., 1, 3, 10, 12, 16 Zope Zope es un proyecto comunitario activista de un entorno de desarrollo para la creación de sitios web dinámicos y/o aplicaciones web usando un servidor de aplicaciones web orientado al objeto, escrito en el lenguaje de programación Python., 13, 14