Título del Proyecto: Sistema Web de gestión de facturas electrónicas.

Transcripción

1 Resumen Título del Proyecto: Sistema Web de gestión de facturas electrónicas. Autor: Jose Luis Saenz Soria. Director: Manuel Rojas Guerrero. Resumen En la última década se han producido muchos avances en los mecanismos de autenticación y firma. Esto ha permitido alcanzar un nivel de seguridad suficiente para que las facturas en formato electrónico puedan ser validadas y tengan la misma validez legal que una factura impresa. El apoyo del estado además ha hecho que tenga beneficios aplicar este formato, y multitud de empresas quieren aplicar esta tecnología. Con la aplicación desarrollada en este proyecto, se pone a su disposición un portal online diseñado en base a Struts 2, donde gestionar sus facturas, poder firmarlas y validarlas, y llevar un control sobre ellas, a través del archivo de la base de datos. Palabras Clave: Factura Electronica, Struts 2, firma electronica Introducción La facturación electrónica aunque es un concepto que ya lleva varios años en funcionamiento sigue reportando y cada vez mas, muchos beneficios para quien las utiliza. La administración para facilitar su implantación ha distribuido una API estándar con un modelo específico de factura llamado Facturae. Este formato se adapta a las necesidades de cualquier empresa, pero a su vez representa el marco común para un modelo unificado. - I -

2 Proyecto Para realizar una implantación de este sistema en este proyecto se ha optado por una implantación Web a través de un portal. Se utiliza el esquema Modelo- Vista-Controlador, implementado mediante el framework Strut 2 sobre un servidor de aplicaciones Apache Tomcat. Todos los datos se almacenan en otro servidor de bases de datos MySQL. A través de este portal se pueden realizar múltiples opciones de gestión de facturas, pero la más importante es la de firma de facturas para hacer que sean igual de válidas que una factura tradicional. - II -

3 Conclusiones La factura electrónica aún está en pleno auge, y va camino de convertirse, junto con otros trámites que se están informatizando, en un proceso totalmente telemático. Las facilidades que se ofrecen desde todos los sectores para su implantación, como la comodidad y el ahorro que suponen para la empresa son argumentos que se tienen muy en cuenta. Referencias [WWW01] Portal oficial sobre factura electrónica (Facturae). [ROUG07] Ian Roughley (2007). Starting Struts 2 INFOQ. - III -

4 Abstract Sistema Web de gestión de facturas electrónicas Project title: Digital Invoice web management system. Author: Jose Luis Saenz Soria. Director: Manuel Rojas Guerrero. Abstract On the last decade there have been many improvements on the authentication and signing technologies. This has led to achieve levels of security that are able to make digital invoices valid, and have the same recognition as a traditional invoice. The support from the government in Spain and the benefits it implies, has led to many companies wanting to get this technology. With the application developed in this project, you can access an online site designed over Struts 2 where you can manage your invoice database and sign them when required. Keywords: Digital Invoice, Struts 2, Digital signature Introduction Although digital invoice is a concept that has been around for several years it still has a lot to offer to those who still don t have it. Spanish government has established a specific invoice format called Facturae and created a free API to handle it. This format adapts to any kind of company, but it represents the common frame to have a unified model for digital invoices. - IV -

5 Project To implement the desired system, this project opted to use a Web Architechture. This will be implemented using the Model-View-Controller architechture, using Struts 2 framework, over an Apache Tomcat server. All the data is stored on a Database MySQL server. Trough the site you can make many management options, but the most important is the invoice digital signing, that make them as valid as a printed invoice. - V -

6 Conclusions Digital invoice is a technology still growing and bound to become along with many other paperwork a totally telematic process. The benefits you get and the support digital invoices is getting is great, but the saving both in money and in work you get with digital invoices is not to be overlooked. References [WWW01] Oficial Site about the Facturae invoice format [ROUG07] Ian Roughley (2007). Starting Struts 2 INFOQ. - VI -

7 Indice Sistema Web de gestión de facturas electrónicas Capitulo 1: Introducción Motivación Historia Objetivos Estado del arte Recursos Hardware y Software Capitulo 2: Análisis de Requisitos Capítulo 3. Modelado de Datos Análisis Tablas Modelo de la base de datos Capítulo 4. Diseño de la arquitectura Arquitectura Web Patrón MVC Struts Capítulo 5. Diseño de interfaz web Capítulo 6. Desarrollo de la aplicación Estructura de la aplicación Capa de Vista Capa de Controlador Capa de Modelo Capítulo 7. Módulo de firma electrónica API Java para firma de facturas electrónicas Capítulo 8. Planificación Capítulo 9. Estudio económico Recursos Humanos Recursos informáticos Recursos Totales Capítulo 10. Conclusiones Capítulo 11. Anexos Anexo I: Como conseguir un certificado digital Anexo II: Tarjetas Inteligentes Documento Nacional de Identidad electrónico (DNIe) Anexo III: Legislación Capítulo 12. Bibliografía VII -

8 Capitulo 1: Introducción - 1 -

9 1.1. Motivación La gestión de documentos ha sido siempre las funciones más importantes y utilizadas de la informática. Sin embargo, a la hora de realizar gestiones oficiales o para almacenar información que requiera verificación, autenticación o trazabilidad de las personas que tratan el documento, era necesaria la utilización del papel. Esto está cambiando recientemente con la aparición y homologación de los certificados y las firmas digitales, que permiten ofrecer una seguridad equiparable a la que ofrece un documento firmado físicamente. De esta forma se puede conseguir que documentos que hasta ahora requerían una presencia física se puedan hacer sin ningún problema a través de sistemas digitales. El objetivo es conseguir que cualquier documento que pueda ser firmado físicamente, pueda ser firmado digitalmente. El paso necesario para que esto sea posible, es una legislación que se adapte a los sistemas y permita la total oficialidad de los documentos con firma digital Este es el caso de la factura electrónica, que gracias al desarrollo de la tecnología, certificaciones necesarias y a nuevas leyes para darle carácter oficial, hoy por hoy son una alternativa real a la factura tradicional e incluso son de obligada utilización en algunos sectores para favorecer su desarrollo

10 Profundizar en el conocimiento de estos sistemas y a la vez desarrollarlo en un entorno web son los principales retos del proyecto, ampliando y consolidando conocimientos sobre aplicaciones online y frameworks, bases de datos y emisiones de certificados digitales, que son de interés para el autor. Al tratarse de un proyecto en un área que es relativamente reciente en España, existen multitud de posibilidades de desarrollo y demanda de este tipo de aplicaciones. La factura además es un documento insustituible en cualquier transacción comercial, y por lo tanto, cualquier empresa tiene necesidad de manejar este tipo de documentos. Esto le da a la aplicación un alcance enorme de usuarios potenciales. Para una empresa el uso de la factura electrónica le supone muchas ventajas, tanto económicas, por ahorro de costes de producción y almacenamiento, como de velocidad de gestión, la seguridad de los documentos y la agilidad a la hora de buscar y analizar los datos que contienen. Todo esto la convierte en una buena oportunidad de negocio si se consigue una aplicación que ofrezca soluciones a los interesados. Se busca realizar una aplicación claramente sencilla, intuitiva y accesible, al tratarse de entornos web, deben primar estas características sobre las demás. Por lo tanto se orientará sobre todo a pequeñas y medianas empresas que son las que buscan más este tipo de aplicaciones, por no tener suficiente personal cualificado para tareas tan específicas, aunque el objetivo es que pueda ser utilizado por cualquier tipo de empresa

11 1.2. Historia En España los orígenes de la factura electrónica se encuentran en la factura telemática, que se reguló por primera vez en el Real Decreto 80/1996, de 26 de enero donde se establecían las normas que ya se habían previsto en el artículo 88 de la Ley 37/1992, de 28 de diciembre. Pero hasta que la unión europea no clarificó su uso mediante la resolución 2001/115/CE, no se dio el paso definitivo a la implantación de la factura electrónica como medio válido e independiente de facturación. Esta resolución establecía que: Se autorizaba a las empresas a emitir facturas electrónicas sin necesidad de mantener una copia impresa Establecer el 1 de enero de 2004 como fecha límite para que los países de la UE adopten las medidas necesarias para cumplir la resolución Finalmente se terminó de regular con las órdenes ministeriales EHA/962/2007, de 10 de abril y PRE/2971/2007, de 5 de octubre, que son las que se dispone actualmente

12 1.3. Objetivos El presente proyecto desarrollará una plataforma de gestión de facturas electrónicas, que permita la emisión, almacenamiento, envío y recepción de facturas de tipo electrónico, así como contemplar la posibilidad de adaptar facturas en soporte tradicional al formato de soporte electrónico. La plataforma funcionará en un entorno web cliente-servidor, para mayor comodidad y facilitar el manejo intuitivo. La plataforma permitirá la emisión de facturas en modo cliente-servidor, estando alojados los documentos en un único servidor seguro, dado el carácter delicado de los datos de un sistema de facturación. Del mismo modo permitirá la recepción de facturas en el servidor, para gestionar la facturación en ambos sentidos. De esta forma, todos los requerimientos respecto a la gestión de facturación dentro de una organización deberán estar contemplados en los diversos módulos que compondrán la plataforma de factura electrónica. Al ser un documento estándar, la emisión de facturas es válida para cualquier tipo de empresa. Dependiendo del volumen de facturación, el sistema requerirá mayores requisitos de almacenamiento y procesamiento, aunque para la realización del proyecto, este se orientará a pequeñas y medianas empresas, que no requieren requisitos extraordinarios. Es fundamental que el sistema sea intuitivo y que permita a usuarios no expertos manejar la herramienta. De esta forma que podrán operar la herramienta autónomos y gente no especializada sin muchos problemas

13 Se debe plantear una arquitectura cliente servidor que cumpla con los requisitos mínimos para la gestión de facturas electrónicas en cuanto a parámetros de carga, datos, firma, etc. Realizar un desarrollo de la herramienta utilizando patrones de diseño y herramientas consolidadas y evaluadas como mejor alternativa entre las disponibles en el mercado. Utilizar un módulo de administración para la gestión de los accesos a la herramienta y las relaciones entre las empresas que acceden para emitir facturas, los usuarios y contactos asociados a estas empresas. Crear un módulo de gestión de facturas que implemente toda la funcionalidad esperada de la gestión tradicional de facturas. Utilizar un módulo de emisión de factura electrónica, en base a la API pública definida para los distintos estándares del mercado. Utilizar un módulo para la firma de la factura con certificado electrónico, donde dichos certificados puedan ser validados por diversos métodos en función del emisor. Desarrollar un módulo de importación y exportación de facturas electrónicas que permita tanto importar como exportar las facturas en diversos formatos, como XML o PDF

14 Implementar un módulo de envío y recepción de facturas que permita transferir facturas electrónicas a través del correo electrónico para su intercambio

15 1.4. Estado del arte Actualmente para que una factura electrónica sea reconocida como válida tiene que cumplir 3 requisitos: 1. Estar firmada mediante una firma electrónica avanzada basada en certificado reconocido. 2. Tener el consentimiento de ambas partes recogido y ser enviada por medios electrónicos. 3. Campos mínimos de información: Núm. Factura Fecha expedición Razón Social emisor y receptor NIF emisor y receptor Domicilio emisor y receptor Descripción de las operaciones (base imponible) Tipo impositivo Cuota tributaria Fecha prestación del servicio (si distinta a expedición) - 8 -

16 Para emitir una firma electrónica avanzada basada en certificado reconocido es necesaria una arquitectura de clave pública PKI (Public Key Infraestructure). Esta infraestructura es la encargada de cifrar y descifrar los mensajes y firmar digitalmente la información garantizando que no se repudien los envíos. Básicamente lo que hace la arquitectura PKI es hacer un envío de la factura a una autoridad de certificación reconocida, que dan fe de la realización y la validez de la información que contienen incluida una marca de tiempo o timestamp y enviarla al destinatario final de la información. El papel que juega la autoridad de certificación dentro de este sistema es vital, pues es la encargada de garantizar y verificar la identidad del solicitante de autenticación. Los certificados recogen datos del firmante y su clave pública, y los firman mediante la clave privada que emite la autoridad de certificación. La confianza en las autoridades de autenticación es lo que sustenta el sistema, pues toda la garantía de que las firmas son reales emana de ellos. Por eso están controladas por el estado y por diversos organismos, aunque también existen entidades privadas encargadas de emitir certificados. En el caso de España la encargada de autorizar la creación de una autoridad de certificación es la fábrica nacional de moneda y timbre el Ministerio de Industria, Turismo y Comercio, la Agència Catalana de Certificació, la Autoritat de Certificació de la Comunitat Valenciana, etc

17 Ejemplos de autoridades de certificación independientes son: CAcert.org, emisor administrado por la comunidad virtual con base legal en Australia. Thawte, sólo para certificados personales. Emisor propiedad de Verisign. Otro de los puntos fundamentales del sistema es la utilización de claves. Cada emisor/receptor dispone de 2 claves, una de ellas pública, que puede dar a cualquier persona para identificarse, sin ningún perjuicio para su seguridad, la otra privada, que si que debe ser protegida. Utilizándolas, cualquiera puede codificar un documento utilizando la clave pública, que se supone conocida, pero una vez cifrado, solo la clave privada asociada a esa clave pública puede descifrarlo. Esto se conoce como criptografía asimétrica, y con esto se soluciona la vulnerabilidad de tener que enviar el método de desencriptación al receptor del mensaje. Por lo tanto la seguridad de este sistema no recae sobre el algoritmo en si, sino sobre la seguridad que ofrezca la clave privada que se utilice, cuanto mas compleja y larga sea más difícil será de descifrar mediante un ataque por fuerza bruta. En lo que respecta al formato de emisión de las facturas existen diferentes estándares, que se tratan o bien de versiones creadas por organismos internacionales o por los gobiernos para mantener un formato unificado. Aunque en la mayoría de países no es necesario que se siga ese formato, sino que se trata de recomendaciones para facilitar el desarrollo

18 En España se ha desarrollado el formato facturae, desarrollado por el ministerio de industria, turismo y comercio y que recoge las particularidades del sistema español. La ONU también tiene definido un estándar para el formato de facturas electrónicas dentro de EDIFACT llamado INVOIC También se están desarrollando diferentes alternativas basadas en XML como son UBL (Universal Business Language), o CEN, desarrollado por países escandinavos

19 1.5. Recursos Hardware y Software Para facilitar la programación y comprobar la adaptabilidad Hardware el proyecto se desarrolla en una maquina virtual utilizando Windows XP. Para montar la máquina virtual se utilizó VM Ware El entorno de programación utilizado es Eclipse para el desarrollo de la aplicación Java. Se utilizará el framework Apache Struts. Para la realización de la web se utilizará Dreamweaver CS3. La redacción, creación de gráficos y planificación se realiza utilizando el paquete office profesional

20 Capitulo 2: Análisis de Requisitos

21 Ficha de Requisitos Requisito R-1F Título Creación de perfil de Usuario Descripción Se debe crear un perfil de usuario para cada cliente, de manera que se pueda personalizar el servicio en función de las necesidades del tipo de usuario. Requisitos Relacionados Observaciones Se debe tratar cada usuario por separado para garantizar la seguridad y simplificar y amoldarse lo máximo posible al proceso que quiere el usuario

22 Ficha de Requisitos Requisito R-2F Título Introducción de Inventario Descripción El sistema debe tener un módulo de introducción de inventario, con el fin de agilizar la realización de las facturas seleccionando los productos desde un listado. Requisitos Relacionados R-1F Observaciones Cada usuario podrá introducir su propio inventario personalizado

23 Ficha de Requisitos Requisito R-3F Título Adaptar el formato para ajustarse al estándar español facturae Descripción Con el fin de ajustarse lo máximo posible a las especificaciones establecidas por el ministerio de industria, se usará el formato facturae, necesario para la aceptación de este sistema por parte de la administración general del estado. Requisitos Relacionados Observaciones Se utilizará la API realizada para este efecto por el ministerio de industria

24 Ficha de Requisitos Requisito R-4F Título Implementar un sistema de búsqueda de facturas Descripción Para la correcta gestión de los datos, se implementará un sistema de búsquedas que permita localizar eficientemente la información que se busque dentro del archivo de facturas de cada usuario. Requisitos Relacionados Observaciones Se darán múltiples campos y opciones de búsqueda, para hacerla lo mas precisa y eficiente posible

25 Ficha de Requisitos Requisito R-5F Título Creación de perfiles de cliente para cada proveedor Descripción Al realizar una factura se creará un perfil de cliente asociado al proveedor que emite la factura, de manera que el cliente pueda consultar sus facturas recibidas en el portal, y permitiendo al proveedor agilizar la realización de la factura en caso de tener que volver a enviar una factura al mismo cliente. Requisitos Relacionados R-1F Observaciones

26 Ficha de Requisitos Requisito R-6F Título Envío por de las facturas Descripción El sistema podrá enviar por correo electrónico las facturas que emita a sus destinatarios. Utilizando el perfil del cliente asociado a esa factura. Requisitos Relacionados R-5F Observaciones

27 Ficha de Requisitos Requisito R-7F Título Exportación a otros formatos Descripción La factura podrá exportarse a diferentes formatos, ya sea Word, pdf, para facilitar su envío e impresión más clara. Requisitos Relacionados R-6F Observaciones

28 Ficha de Requisitos Requisito R-8F Título Generación de estadísticas y datos de análisis Descripción Integrado con la búsqueda o como módulo independiente el sistema permitirá obtener varios tipos de estadísticas y datos de análisis sobre sus clientes. Requisitos Relacionados R-4F Observaciones

29 Ficha de Requisitos Requisito R-9F Título Generación de Firma Descripción La firma del documento debe realizarse con las máximas garantías y seguridad existentes actualmente. Requisitos Relacionados Observaciones

30 Ficha de Requisitos Requisito R-1NF Título Simplicidad de navegación Descripción El portal intentará ser lo más intuitivo posible, de manera que tenga el mínimo necesario de pantallas de interacción con el usuario, pero sin que suponga una saturación de campos a rellenar ni de información. Requisitos Relacionados Observaciones

31 Capítulo 3. Modelado de Datos

32 3.1 Análisis La aplicación hará uso de una base de datos para todas las tareas de almacenamiento de datos. Para realizar esta gestión se utilizará el motor MySQL, por ser de libre distribución y gratuito. Para la realización de la base de datos se han tenido en cuenta los requisitos mínimos para la realización de una factura electrónica válida. La factura ordinaria tiene unos campos obligatorios que son: Núm. Factura Fecha expedición Razón Social emisor Razón Social receptor NIF emisor NIF receptor Domicilio emisor Domicilio receptor Descripción de las operaciones (base imponible) Tipo impositivo Cuota tributaria Fecha prestación del servicio (si distinta a expedición)

33 Además de estos datos, que por supuesto tienen que aparecer en la factura electrónica las características de esta hacen que se requiera, para cumplir la normativa, que la factura esté firmada mediante una firma electrónica avanzada basado en certificado reconocido y ser transmitido de un ordenador a otro recogiendo el consentimiento de ambas partes. Por lo tanto a todos los datos anteriores habría que añadir un elemento firma para guardar la verificación de la factura. Para realizar este modelo, se van a emplear 5 tablas. Una tabla para almacenar los emisores de las facturas, otra para los receptores de las facturas que creen los emisores, otra para los diferentes tipos impositivos, otra para las facturas ya firmadas y una tabla para almacenar las facturas generadas

34 3.1 Tablas Emisor Esta tabla almacenará los datos de identificación del emisor. Estos datos se rellenarán al crear el perfil de emisor en el portal, para no tener que volver a introducirlos. EMISOR Campo Clave Tipo Null ID_EMISOR SI Entero (Autoincremental) NO NOMBRE NO Carácter (40) NO NIF NO Carácter (20) NO DIRECCION NO Carácter (100) NO CP NO Numérico(5) NO NO Carácter (40) NO ID_EMISOR: Identificador unívoco de cada emisor de la factura. NOMBRE: Nombre o Razón social del emisor de la factura. NIF: NIF o CIF del emisor, según se trate de una persona o una empresa la entidad que emite la factura. DIRECCION: Domicilio propio o fiscal de la persona o empresa que emite la factura. CP: Código postal asociado al domicilio. correo electrónico de contacto con el emisor

35 Receptor Los receptores son creados por el emisor de las facturas, para luego poder seleccionarlos y facilitar la creación de otras facturas con el mismo receptor. Para ello, la tabla receptor tiene asociado el emisor que le corresponde. RECEPTOR Campo Clave Tipo Null ID_RECEPTOR SI Entero (Autoincremental) NO NOMBRE NO Carácter (40) NO NIF NO Carácter (20) NO DIRECCION NO Carácter (100) NO CP NO Numérico(5) NO NO Carácter (40) NO ID_RECEPTOR: Identificador unívoco de cada receptor de la factura. NOMBRE: Nombre o Razón social del receptor de la factura. NIF: NIF o CIF del emisor, según se trate de una persona o una empresa la entidad que emite la factura. DIRECCION: Domicilio propio o fiscal de la persona o empresa que recibe la factura. CP: Código postal asociado al domicilio. correo electrónico de contacto con el receptor

36 Firma: En esta tabla se guardan los datos de las facturas que ya están firmadas, asociando la firma, con la factura emitida. FIRMA Campo Clave Tipo Null ID_FIRMA SI Entero (Autoincremental) NO ID_FACTURA EXTRANJERA Entero NO FIRMA NO LongBLOB NO FECHA NO TimeStamp NO ID_FIRMA: Identificador unívoco de la firma. ID_FACTURA: Factura asociada a esa firma. FIRMA: Contenido de la firma digital, se utiliza un campo longblob, usados para almacenar gran cantidad de datos en binario. FECHA: Timestamp de generación de la firma

37 Impuesto Almacena los tipos impositivos del IVA válidos. Al ser unos valores fijos es más sencillo almacenarlos en una tabla aparte. IMPUESTO Campo Clave Tipo Null ID_TIPO SI Entero (Autoincremental) NO DESC_TIPO NO Carácter (40) NO VALOR_TIPO NO Float NO ID_TIPO: Identificador unívoco del tipo de valor impositivo. DESC_TIPO: Descripción del tipo de valor impositivo (Tipo general, tipo reducido o tipo superreducido). VALOR_TIPO: Almacena el valor de los tipos impositivos aplicables a las facturas, en función del tipo de bienes que se ofrezcan

38 Factura En esta tabla es donde se almacenan los datos generales de la factura sin firmar. Esta factura contiene ya todos los datos necesarios para que sea considerada como válida, a falta únicamente de la firma. FACTURA Campo Clave Tipo Null ID_FACTURA SI Entero (Autoincremental) NO ID_RECEPTOR EXTRANJERA Entero NO ID_TIPO EXTRANJERA Entero NO BASE_IMPONIBLE NO Float NO FECHA NO TimeStamp NO ID_FACTURA: Identificador unívoco de la factura. ID_RECEPTOR: Clave del receptor asociado a la factura, a partir de ese receptor se obtiene el emisor asociado a éste receptor y todos sus datos asociados. ID_TIPO: Tipo impositivo asociado a la factura. BASE_IMPONIBLE: Importe (Antes de impuestos) del producto o servicio que se está facturando. FECHA: Marca de tiempo generada en el momento de la emisión de la factura

39 3.2 Modelo de la base de datos Emisor PK ID_EMISOR NOMBRE NIF DIRECCION CP EmisorCol1 Receptor PK ID_RECEPTOR Factura Firma NOMBRE NIF DIRECCION CP ReceptorCol1 PK ID_FACTURA ID_RECEPTOR ID_TIPO BASE_IMPONIBLE FECHA PK ID_FIRMA ID_FACTURA FIRMA FECHA Impuesto PK ID_TIPO DESC_TIPO VALOR_TIPO

40 Capítulo 4. Diseño de la arquitectura

41 4.1 Arquitectura Web Para la realización del proyecto se implementará una arquitectura Web. Esta arquitectura se compone de 3 capas. La capa de presentación, la capa del servidor de aplicaciones y la capa de persistencia o bases de datos. La capa de presentación es a la que acceden todos los clientes o usuarios de la aplicación. No contiene ninguna lógica de negocio, y su función se limita a mostrar, a través del navegador, los resultados de la lógica de negocio que se sitúa en la capa de aplicación. La capa de aplicación es la que realiza todo el manejo de la lógica, comunicándose con la capa de persistencia para el acceso y almacenamiento de los datos, y con la capa de presentación para mostrar los resultados pedidos. Dado que toda la lógica del proceso se hace en la capa de aplicación, que se encuentra en el servidor de aplicaciones, todo el software que el cliente necesita para acceder a la aplicación es un navegador

42 4.2 Patrón MVC El patrón que se va a seguir con esta arquitectura es el MVC (Modelo Vista Controlador). Modelo: representa la información con la que trabaja la aplicación, la que tiene la lógica de negocio y accede a los datos. Vista: representa el modelo de forma accesible para los usuarios (Interfaz) Controlador: se dedica a responder a eventos, ya sean acciones de usuario, acceder al modelo o a la vista según la acción que corresponda

43 4.3 Struts Para la implementación de la arquitectura Web, con patrón MVC, se ha utilizado el framework Struts. Este framework, desarrollado por la Apache software foundation tiene como objetivo es facilitar la implementación del esquema MVC. Struts distribuye las 3 capas de la siguiente forma: Controlador: Esta función la realiza el Servlet ActionServlet. Cuando recibe una petición del navegador decide que subclase Action va a tratar la petición en función de cómo se haya declarado el fichero de configuración struts-config.xml. Después será la subclase Action, la que analice el estado del modelo y controle el flujo de la aplicación y el tratamiento de los errores. Una instancia de una subclase de Action es la que se encarga de gestionar la petición y responder al cliente o indicar al Servlet controlador a qué otro componente del sistema debe delegar el control Modelo: Representa al estado de la aplicación. Estará formado por dos tipos de clases: Subclases de la clase base org.apache.struts.action.actionform que proporciona Struts. Clases normales sin necesidad de extender ActionForm. Vista: La vista estará formada por páginas JSP que no contendrán lógica de negocio, ni flujo de la aplicación e información del modelo, sólo tags. Utiliza el modelo generado para obtener la información y presentarla

44 Capítulo 5. Diseño de interfaz web

45 La navegabilidad de una web se define como aquellas propiedades y recursos que utiliza un usuario para poder moverse entre las diferentes secciones y módulos. El objetivo es que sea sencilla, intuitiva y que el usuario sea capaz de realizar cualquier acción sin perderse. El diseño de una buena navegabilidad es fundamental para que una aplicación web triunfe y sea aceptada por sus usuarios. El aspecto físico también es importante, pero al tratarse de una aplicación pura de gestión, tradicionalmente no se exige que tenga un gran atractivo visual, pero sí que este sea lo más efectivo posible para realizar las tareas sin errores y de la forma más rápida posible. Para poder hacer esto, antes de diseñar físicamente la web, se va a proceder a estudiar previamente las opciones de navegación dentro de la web y sus opciones de acceso una vez dentro

46 Pantallas Iniciales: Presentación La pantalla de presentación de la web mostrará el logo de la aplicación y las opciones de acceder, para los usuarios ya registrados, o registrarse, para los nuevos usuarios que quieran utilizar la aplicación. Registro La pantalla de registro mostrará los campos necesarios para dar de alta a un nuevo emisor de facturas. En caso de que los datos sean demasiados como para ser mostrados en una p{gina y haya que hacer scroll, se proceder{ a hacer una segunda pantalla de manera que la introducción de datos sea más espaciada y no abrume al usuario. Pantalla de login Simplemente mostrará las opciones de introducir usuario, contraseña, y la opción de recordad via la contraseña en caso de olvido. Portal El portal presentará una estructura un menú dude navegabilidad, un menú lateral, a la izquierda, con todas las opciones de navegabilidad, y una barra superior con opciones generales de acceso

47 Barra superior Esta barra dará las opciones de acceder a las opciones de: Facturas: Accederá al módulo de generación de facturas, donde se mostrará todas las opciones y se accederá a ellas. Gestión de datos: Accederá al módulo de gestión de los datos, para realizar todas las funciones de alta, baja y modificación de tipos de datos. Búsqueda: se accederá a una página con las opciones posibles de búsqueda Logout: para desconectarse y salir del sistema de forma segura

48 Capítulo 6. Desarrollo de la aplicación

49 6.1 Estructura de la aplicación Siguiendo las directrices descritas anteriormente, se implementará utilizando Struts y por lo tanto el patrón MVC, con capa de Vista, Controlador y Modelo. A modo de resumen, la integración de las tecnologías anteriormente explicadas sería de la siguiente forma: El servidor Apache Tomcat se encarga de almacenar las páginas web dinámicas JSP, sus CSS y como servidor de aplicaciones de la lógica de negocio. También se encarga de soportar el sistema Struts e interactuar con el servidor de la base de datos a través de BEANS. El servidor MySQL es el encargado de almacenar la base de datos relacional. Desde los BEANS lanzados desde Tomcat se podrá acceder para realizar cualquier opción de consulta o mantenimiento de la base de datos

50 6.2 Capa de Vista La capa de la vista está formada por el conjunto de las páginas que se pueden ver desde el navegador del cliente. Para el diseño de las vistas se utilizarán páginas JSP que permiten el uso de código java y de etiquetas Struts (taglibs) mezclado con código HTML. Para el control de los datos introducidos en los diferentes formularios de las páginas, Struts proporciona una clase llamada ActionForm que es capaz de comprobar y almacenar los datos de los formularios JSP para posteriormente transferirlos a la clase Action (se verá en la capa de controlador) que los manipulará. De esta manera se tienen localizados los datos y listos para ser usados. Aunque pueden ser usados en la capa modelo, al ser algo tan intrínsecamente relacionado a la capa de vista se realizarán en esta capa

51 6.3 Capa de Controlador Como ya se ha explicado anteriormente, Struts posee un controlador centralizado (El ActionServlet) que hace que no sea necesario mapear las acciones. Las páginas JSP poseen una llamada de tipo Form donde se almacenan los datos de los formularios cuando se produce un evento. Cuando se acciona el evento, una clase de tipo Action entra en funcionamiento y con los datos guardados en la clase Form llama a los métodos correspondientes de la capa modelo. También se utilizan para el tratamiento de errores y el control del flujo. El mapeo de la paginas JSP con sus respectivos Actions y Forms, se controla a través de un fichero de configuración XML llamado Struts-config.xml. Es a este fichero al que accede el ActionServlet como guía de asociación para identificar las relaciones. Como ejemplo de esta capa, en la pantalla de login, al pulsar el botón de acceder, se pueden generar dos tipos de Action, que el nombre de usuario y la contraseña sean válidos o que no lo sean. En función de lo que devuelva, consultará el Struts-config.xml y redirigirá al menú principal en caso de que sea válido, o volverá a mostrar la pantalla de login en caso de que sea incorrecto el acceso

52 6.3 Capa de Modelo Esta capa es la encargada de llevar a cabo las acciones requeridas por el controlador. Es aquí donde están las clases que tienen que realizar operaciones de negocio. En esta capa se realizan las acciones más relevantes de la aplicación: Acceso a base de datos: Se realiza mediante el conector, el driver JDBC que proporciona el creador de la base de datos. Se ha creado una clase encargada de realizar las conexiones y desconexiones con la base de datos. Configurando correctamente el fichero Struts-config.xml con el driver de MySQL se puede acceder de forma sencilla al servidor de la base de datos a través de un DataSource. Integración del módulo de firma electrónica para las facturas

53 Capítulo 7. Módulo de firma electrónica

54 7.1 API Java para firma de facturas electrónicas Para facilitar la implementación del formato Facturae en cualquier aplicación, el Ministerio de Industria, Turismo y Comercio, dentro del plan Avanza, ha creado una API pública para Java que permite implementar con todas sus características facturas firmadas en formato Facturae. La distribución de esta API está empaquetada en un fichero ZIP que contiene: Facturae-API-2.0.jar: API. Directorio lib : Contiene las librerías de apoyo, entre las que se encuentran los componentes de firma también desarrollados por el Ministerio. Directorio META-INF : Incorpora el manifest.mf, disclaimer.txt (castellano e inglés), LEEME.txt (castellano e inglés), licencia.txt (castellano, inglés, catalán, gallego y euskera). Facturae-API-2.0-javadoc.jar: Javadoc en formato JAR (se puede abrir con cualquier programa de compresión de ficheros). Doc_Guia_Usuario_API_v2_0.pdf: Guía de uso de la versión 2.0 del API en formato PDF

55 Para poder entender, un poco por encima, la funcionalidad del API de Facturae se va a detallar a continuación su arquitectura. Este API se divide en dos partes bien diferenciadas: Por un lado están los componentes de marshal, unmarshal y validación. Ayudan a la gestión de datos XML, permitiendo la conversión recíproca de datos XML y objetos Java. Por otro lado se encuentra el componente de firma, encargado de realizar la firma digital de una factura electrónica. El API está compuesto por las siguientes librerías (cada grupo de librerías corresponde, respectivamente, a las partes diferenciadas comentadas anteriormente): Facturae-API.jar Es el núcleo del API y contiene los componentes básicos. Librerías JAXB Contiene la lógica necesaria para realizar la transformación entre datos XML y objetos Java. Permite realizar o activation.jar o jaxb-api.jar o jaxb-impl.jar o jsr173_1.0_api.jar

56 swing-layout jar Contiene extensiones de los layout de swing. Son empleados por la interfaz de usuario de selección de certificado. Componentes de logs Se utiliza la librería commons-logging.jar para flexibilizar el sistema de logs empleado por el desarrollador. Se incluye log4j por defecto. o commons-logging.jar o o log4j jar FacturaEBridge.jar Bridge de firma. Contiene la interfaz fachada de los servicios de firma. Facturae-API-CompPack.jar Contiene el componente de firma empleado por el API. Se conecta al bridge anterior mediante configuración. LibXADESJNI_MZ_W5.jar Librerías nativas de acceso al almacén de certificados de Mozilla en Windows

57 Capítulo 8. Planificación

58 La duración de la realización del proyecto ha sido de 5 semanas. La distribución de tareas en ese espacio de tiempo ha sido la siguiente: Nombre de tarea Duración Comienzo Fin Predecesoras Identificación de Necesidades y lun vie 5 días analisis de 25/07/11 29/07/11 requisitos Estudio de la 5 días Arquitectura Diseño de Interfaz 10 días del Portal Diseño e implementación de 5 días la Base de datos Lógica de Manejo 5 días de base de datos Implementación del módulo de 7 días firma electrónica Realización de la 8 días Memoria lun 01/08/11 lun 08/08/11 lun 08/08/11 lun 15/08/11 lun 22/08/11 lun 22/08/11 vie 05/08/11 vie 19/08/11 vie 12/08/11 vie 19/08/11 mar 30/08/11 mié 31/08/ ;3-51 -

59 Capítulo 9. Estudio económico

60 Para la realización del estudio económico en este proyecto informático se considerarán dos partes diferenciadas: Recursos Humanos: Se valora todos los costes asociados al personal de desarrollo del proyecto Recursos Informáticos: Se valorarán tanto los recursos hardware necesarios para la realización del proyecto como los requisitos de licencias de software que sean necesarios. 9.1 Recursos Humanos El personal asociado al desarrollo del proyecto consta de un ingeniero técnico en inform{tica, a un salario estimado de 30 /Hora y de un director de proyecto, cuyo salario estimado ser{ de 45 /hora. En el caso del Ingeniero técnico el porcentaje de dedicación al proyecto será completo (100%) mientras que el del director del proyecto se estima en el 10% del total. Teniendo en cuenta que el proyecto tiene una duración de 5 semanas a 5 horas diarias trabajadas, el total de horas sería de 125: Trabajador Horas Imputadas Coste/Hora Coste Total Ingeniero Técnico ,00 Director de Proyecto 12, ,50 Total 4.312,

61 9.2 Recursos informáticos El coste total de los recursos informáticos empleados para la realización del proyecto se muestra en la siguiente tabla: Tipo Recurso Precio Hardware y Software Portatil Hacer Aspire 5740 G + Licencia Windos 7 Ultimate Software Microsoft Office 2010 Software Software Total Vmware Workstation Adobe Dreamweaver CS5 750,00 379,00 155,00 531, , Recursos Totales Sumando los dos presupuestos se obtiene el presupuesto final del coste de la aplicación. Recurso Precio Recursos Humanos 4.312,50 Recursos Informaticos 1.815,00 Total 6.127,

62 Capítulo 10. Conclusiones

63 La factura electrónica va camino de no solo ser una alternativa real a la factura tradicional (Que ya lo es) sino que existe la voluntad de que sea el método principal de facturación de cara al futuro. Las ventajas que ofrece para una empresa que maneja grandes volúmenes de facturación son inmensas, e incluso para una PYME le supone un ahorro y una mayor comodidad a la hora de operar con las facturas. Además el apoyo que se le da por parte gubernamental en España, para facilitar la implantación de este formato, es de gran ayuda para los desarrolladores. Al servir ya una API creada por ellos con un formato específico estándar facilita mucho el trabajo. Además tener un formato estándar facilita la aceptación por los usuarios que suelen ser reacios a usar nuevas tecnologías en entornos tan críticos del negocio como es la facturación. Con el desarrollo de esta aplicación se espera poder dar una solución básica para cualquier empresa que pueda necesitar una aplicación online para la gestión de su inventario de facturación. Este proyecto ha permitido al autor profundizar en el conocimiento de tanto de arquitectura web, con el framwork Struts como los conceptos relacionados con la firma digital de documentos y su validez y fiabilidad

64 Capítulo 11. Anexos

65 11.1 Anexo I: Como conseguir un certificado digital Para conseguir una firma digital, lo primero que se debe hacer es elegir la autoridad de certificación que ofrezca garantías personales como al resto de personas o entidades donde se pueda llegar a usar. El estado Español tiene una Autoridad de Certificación, esta reside en la Fábrica de Moneda y Timbre, la cual se llama CERES. Para ilustrar con un ejemplo como conseguir una firma digital, se utilizará a modo de ejemplo, la firma digital que proporciona la Fábrica de Moneda y Timbre. Para obtener el certificado, se entrará en la página Web de la fábrica, su dirección es:

66 Una vez esté desplegada la página principal en el explorador, para conseguir la firma electrónica, se debe acceder a la zona de Ceres (Enlace de Obtenga su certificado )

67 Ceres es la Autoridad de Certificación de la Fábrica de Moneda y Timbre, en ella se puede obtener diversa información relacionada con la firma electrónica. Para solicitar la firma electrónica, se debe acceder a la zona de ciudadanos

68 Después se debe pulsar en la pestaña de obtener el certificado. Una vez en esta página, señala unas recomendaciones previas para que el proceso de obtención de firma electrónica pueda terminarse satisfactoriamente. El proceso de obtención de la firma electrónica, consta de tres pasos fundamentales

69 1.- Solicitud vía internet del certificado En este primer paso, se debe rellenar un pequeño formulario con dos datos; uno de ellos es el DNI del solicitante y el otro es la longitud de la clave, en este apartado se muestran dos opciones. Clave de nivel medio 1024 bits o por el contrario una clave de nivel alto de 2048 bits; aunque si se elige esta opción, la página avisa que algunas aplicaciones donde se puede utilizar firma digital no están preparadas para una clave tan grande. Una vez introducidos estos dos datos, el navegador generará una clave numérica que se debe guardar para el siguiente paso

70 2. Acreditación de la identidad Este paso se debe realizar en una oficina de registro. El funcionario verificará la identidad personal con el DNI físico del cual dispone cualquier persona y a continuación, con el código que se obtuvo en el primer paso, generará otro y código necesario para el último trámite donde se obtendrá el certificado electrónico. 3. Descarga del Certificado de Usuario Este es el último trámite para obtener el certificado. Consiste en rellenar con el DNI y el código entregado por el funcionario en el paso 2 este formulario

71 A continuación de rellenar los datos, y enviar la información, en el ordenador se instalará el certificado electrónico. Durante la instalación, la aplicación hace una recomendación muy a tener en cuenta. Ésta consiste en exportar el certificado que se ha instalado en algún dispositivo externo, bien sea un USB, CD-ROM o un simple disquete, si por cualquier motivo hay que formatear el ordenador, no se perderá el certificado y no se tendrá que realizar de nuevo todos los pasos señalados para la adquisición de uno nuevo

72 11.1 Anexo II: Tarjetas Inteligentes Una tarjeta inteligente, smart card, o tarjeta con circuito integrado (TCI), es cualquier tarjeta del tamaño de un bolsillo con circuitos integrados que permiten la ejecución de cierta lógica programada. Aunque existe un diverso rango de aplicaciones, hay dos categorías principales de TCI. Las tarjetas de memoria, que contienen sólo componentes de memoria no volátil y posiblemente alguna lógica de seguridad, y las tarjetas microprocesadoras, que contienen memoria y microprocesadores. La percepción estándar de una tarjeta inteligente es una tarjeta microprocesadora de las dimensiones de una tarjeta de crédito, también puede ser más pequeñas, como por ejemplo, las tarjetas SIM o GSM, con varias propiedades especiales, por ejemplo, un procesador criptográfico seguro, sistema de archivos seguro, características legibles por humanos, y es capaz de proveer servicios de seguridad como confidencialidad de la información en la memoria. Las tarjetas no contienen baterías, la energía es suministrada por los lectores de tarjetas

73 Existen numerosas clasificaciones de tarjetas inteligentes dependiendo de sus capacidades, de la estructura de su sistema operativo, de su tamaño, e interfaz. Por ello nos centraremos en su clasificación en función de sus capacidades como ejemplo. En función de las capacidades que tiene el chip de una tarjeta inteligente se pueden catalogar los siguientes tipos: Memoria: tarjetas que tienen como fin ser un contenedor de ficheros pero que no albergan aplicaciones ejecutables. Se emplean para la identificación y control de acceso sin altos requisitos de seguridad. Microprocesadoras: tarjetas con una estructura análoga a la de un ordenador, ya que disponen de procesador, memoria volátil y memoria permanente. Éstas si contienen ficheros y aplicaciones. Suelen emplearse para la identificación y pago como monederos electrónicos. Criptográficas: Son tarjetas microprocesadoras avanzadas en las que hay módulos hardware que permiten la ejecución de algoritmos usados en cifrados y firmas digitales. En estas tarjetas se puede almacenar de forma segura uno o varios certificados digitales, y sus claves privadas, y firmar documentos o autenticarse con la tarjeta sin que el certificado abandone la tarjeta, ya que es el procesador de la propia tarjeta el que realiza la firma o la autenticación. Como ejemplo de estas tarjetas, son las emitidas por la Fábrica Nacional de Moneda y Timbre (FNMT) y el Documento Nacional de Identidad electrónico (DNIe)

74 Documento Nacional de Identidad electrónico (DNIe) En España se expide desde marzo del año 2006 un tipo especial de documento de identidad denominado DNI electrónico. El nacimiento del Documento Nacional de Identidad electrónico (DNIe) responde a la necesidad de otorgar identidad personal a la ciudadanía para su uso en la nueva Sociedad de la Información, además de servir de impulsor de la misma. Así, el DNIe es la adaptación del documento de identidad tradicional a la nueva realidad de una sociedad interconectada por las redes de comunicaciones. De este modo, cada ciudadano podrá hacer realizar múltiples gestiones de forma segura a través de medios telemáticos y asegurando la identidad de los participantes en la comunicación. La adjudicataria del proyecto es la Unión Temporal de Empresas, compuesta por Indra, Telefónica y Software AG

75 En el DNI electrónico se han desarrollado tres niveles de seguridad. En un primer nivel, podemos encontrar tanto hologramas, letras táctiles como imágenes láser cambiantes. En un segundo nivel, imágenes codificadas, microtextos, kinegramas; y, por último, medidas criptográficas y biométricas. El microchip, que constituye la principal novedad visible por el usuario, almacena la siguiente información: Los datos de filiación del titular, correspondientes con el contenido personalizado en la tarjeta. La fotografía digitalizada del ciudadano. La imagen digitalizada de la firma manuscrita. La plantilla biométrica de la impresión dactilar de los dedos índice de cada mano. Certificados

76 Dentro de los certificados, podemos encontrar además del certificado de la Autoridad de Certificación expedidora y de un certificado de componente que permite la autenticación mutua de dispositivos tal y como se describe en el estándar CWA-14890, dos certificados X.509 del ciudadano, uno de autenticación y otro de firma, con la misma validez jurídica que la firma manuscrita, y las claves privadas asociadas a cada uno de ellos. Es conveniente precisar que cada pareja de claves se genera dentro del chip durante el proceso de expedición. El hecho de que haya dos certificados persigue que el ciudadano pueda distinguir entre las actividades de autenticación y firma electrónica cuando se produzcan, al margen de la similitud de los procesos criptográficos implicados en ambas

77 El DNI electrónico presenta una serie de ventajas para el ciudadano entre las que hay que destacar las siguientes: Desde el punto de vista de la SEGURIDAD: El DNI electrónico es un documento más seguro que el tradicional, pues incorpora mayores y más sofisticadas medidas de seguridad que harán virtualmente imposible su falsificación. Mediante el DNI electrónico podremos garantizar la identidad de los interlocutores de una comunicación telemática, ya sea para intercambio de información, acceso a datos o acciones o compra por Internet. Igualmente, gestionar mejor el acceso a nuestro espacio de trabajo, nuestro ordenador personal y a la información que contenga. Usando el DNI electrónico podemos intercambiar mensajes con la certeza de que nuestro interlocutor es quien dice ser y que la información intercambiada no ha sido alterada

78 Desde el punto de vista de la COMODIDAD: Con el DNI electrónico se podrán realizar trámites a distancia y en cualquier momento: El DNI electrónico permitirá realizar multitud de trámites sin tener que acudir a las oficinas de la Administración y sin tener que guardar colas. Y hacerlo en cualquier momento (24 horas al día, 7 días a la semana). El DNI electrónico se expedirá de forma inmediata: No será necesario acudir dos veces a la Oficina de Expedición, sino que la solicitud y la obtención del documento se hará en una única comparecencia, en cualquiera de las Oficinas de Expedición existentes en España, que se irán dotando progresivamente del equipamiento necesario para la expedición del nuevo documento. Hacer trámites sin tener que aportar una documentación que ya exista en la Administración: una de las ventajas derivadas del uso del DNI electrónico y de los servicios de Administración Electrónica basados en él será la práctica eliminación del papel en la tramitación. El ciudadano no tendrá que aportar una información que ya exista en otra Unidad de la Administración, evitándose -de nuevo- colas y pérdidas de tiempo. La Unidad que realice la tramitación lo hará por él, siempre que el ciudadano así lo autorice