SISTEMA INTELIGENTE DE INTERPRETACIÓN DE FACTURAS · institucional de la Universidad y hacer...
107
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA SISTEMA INTELIGENTE DE INTERPRETACIÓN DE FACTURAS Autor: Carlos Bernabeu Juan Director: Juan Antonio Pérez-Campanero Anastasio Madrid Junio 2012
Transcript of SISTEMA INTELIGENTE DE INTERPRETACIÓN DE FACTURAS · institucional de la Universidad y hacer...
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
SISTEMA INTELIGENTE DE INTERPRETACIÓN
DE FACTURAS
Autor: Carlos Bernabeu Juan
Director: Juan Antonio Pérez-Campanero Anastasio
Madrid
Junio 2012
alumno
Proyecto Final de Carrera- Sistema Inteligente de Interpretación de
facturas
AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO
ABIERTO ( RESTRINGIDO) DE DOCUMENTACIÓN
1º. Declaración de la autoría y acreditación de la misma.
El autor D. _____________________________________ , como _______________ de
la UNIVERSIDAD PONTIFICIA COMILLAS (COMILLAS), DECLARA
que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión,
en relación con la
obra___________________________________________________________________
___________________________________________________________________1,
que ésta es una obra original, y que ostenta la condición de autor en el sentido que
otorga la Ley de Propiedad Intelectual como titular único o cotitular de la obra.
En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el
consentimiento de los restantes titulares para hacer la presente cesión. En caso de
previa cesión a terceros de derechos de explotación de la obra, el autor declara que
tiene la oportuna autorización de dichos titulares de derechos a los fines de esta
cesión o bien que retiene la facultad de ceder estos derechos en la forma prevista en la
presente cesión y así lo acredita.
2º. Objeto y fines de la cesión.
Con el fin de dar la máxima difusión a la obra citada a través del Repositorio
institucional de la Universidad y hacer posible su utilización de forma libre y gratuita (
con las limitaciones que más adelante se detallan) por todos los usuarios del
repositorio y del portal e-ciencia, el autor CEDE a la Universidad Pontificia Comillas de
forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los
derechos de digitalización, de archivo, de reproducción, de distribución, de
comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y
1 Especificar si es una tesis doctoral, proyecto fin de carrera, proyecto fin de Máster o cualquier otro
trabajo que deba ser objeto de evaluación académica
Carlos José Bernabeu Juan
como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se
cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente.
3º. Condiciones de la cesión.
Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la
cesión de derechos contemplada en esta licencia, el repositorio institucional podrá:
(a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a
internet; realizar adaptaciones para hacer posible la utilización de la obra en formatos
electrónicos, así como incorporar metadatos para realizar el registro de la obra e
incorporar “marcas de agua” o cualquier otro sistema de seguridad o de protección.
(b) Reproducirla en un soporte digital para su incorporación a una base de datos
electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a
los efectos de garantizar su seguridad, conservación y preservar el formato. .
(c) Comunicarla y ponerla a disposición del público a través de un archivo abierto
institucional, accesible de modo libre y gratuito a través de internet.2
(d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 3
4º. Derechos del autor.
El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la
Universidad por medio de su registro en el Repositorio Institucional tiene derecho a:
2 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los
siguientes términos:
(c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de
modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional
3 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado.
a) A que la Universidad identifique claramente su nombre como el autor o propietario
de los derechos del documento.
b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a
través de cualquier medio.
c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá
ponerse en contacto con el vicerrector/a de investigación
d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites
necesarios para la obtención del ISBN.
d) Recibir notificación fehaciente de cualquier reclamación que puedan formular
terceras personas en relación con la obra y, en particular, de reclamaciones relativas a
los derechos de propiedad intelectual sobre ella.
5º. Deberes del autor.
El autor se compromete a:
a) Garantizar que el compromiso que adquiere mediante el presente escrito no
infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o
cualquier otro.
b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la
intimidad y a la imagen de terceros.
c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por
daños, que pudieran ejercitarse contra la Universidad por terceros que vieran
infringidos sus derechos e intereses a causa de la cesión.
d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por
infracción de derechos derivada de las obras objeto de la cesión.
6º. Fines y funcionamiento del Repositorio Institucional.
La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y
respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y
con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la
Universidad asume los siguientes deberes y se reserva las siguientes facultades:
a) Deberes del repositorio Institucional:
- La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no
garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan
un uso posterior de las obras no conforme con la legislación vigente. El uso posterior,
más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría,
que no se obtenga beneficio comercial, y que no se realicen obras derivadas.
- La Universidad no revisará el contenido de las obras, que en todo caso permanecerá
bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones
legales en nombre del autor en el supuesto de infracciones a derechos de propiedad
intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier
reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente
en que los usuarios hagan uso de las obras.
- La Universidad adoptará las medidas necesarias para la preservación de la obra en
un futuro.
b) Derechos que se reserva el Repositorio institucional respecto de las obras en él
registradas:
- retirar la obra, previa notificación al autor, en supuestos suficientemente justificados,
o en caso de reclamaciones de terceros.
Madrid, a ……….. de …………………………... de ……….
ACEPTA
Fdo……………………………………………………………
Autorizada la entrega del proyecto del alumno:
Carlos José Bernabeu Juan
EL DIRECTOR DEL PROYECTO
Juan Antonio Pérez-Campanero Anastasio
Fdo.:……………………………………………Fecha:……………/…………../……………
V°B° del Coordinador de Proyectos:
David Contreras Bárcena
Fdo.:……………………………………………Fecha:……………/…………../……………
AGRADECIMIENTOS
Quiero agradecerle a mi Padre los valores que ha inculcado en mí.
A mi Madre por ayudarme y acompañarme en momentos en los que no estaba seguro,
y por darme los empujones necesarios para volver a despegar a lo largo de toda la
carrera.
Al resto de mi familia y amigos por ayudarme siempre y aconsejarme.
I
SISTEMA INTELIGENTE DE INTERPRETACIÓN DE FACTURAS
Autor: Carlos Bernabeu Juan
Director: Juan Antonio Pérez-Campanero Anastasio
Entidad Colaboradora: ICAI, Universidad Pontificia de Comillas.
Figura 0.1 Aplicación en ejecución
Resumen del proyecto El objeto de este proyecto es el de crear un sistema sencillo para la informatización de
las facturas en las empresas mediante tecnología OCR, no sólo para la agilización del
proceso sino también para el ahorro en costes de personal.
Palabras clave: Digitalización facturas, sistema inteligente, interpretación de facturas,
facturas, interpretación, OCR.
Introducción
Actualmente las empresas ya sean pequeñas, medianas o grandes, tienen muchos
proveedores, de servicios o productos, y todos emiten facturas. Las facturas son el
comprobante oficial de una transacción económica entre dos partes. Es muy
importante para las empresas la gestión de las facturas, y para hacer las cosas más
sencillas, se intentan mantener en soporte informático, indexadas y en bases de datos
con seguridad ante posibles fallos.
La forma de pasar de soporte en papel a soporte informático es por medio de un
operario que lo único que hace es transcribir lo que ve en el papel al sistema
II
informático de gestión de facturas. Este proceso además de añadir costes a la
empresa, no es llevado a cabo por todas las empresas, de hecho, las empresas que lo
hacen suelen tener un tamaño considerable, las medianas y pequeñas suelen dejar las
facturas archivadas en un formato perecedero, como puede ser el papel. Con el
desarrollo del sistema se va a conseguir una mayor aceptación del concepto de
informatización de las empresas, poniendo al alcance de todos la digitalización de las
facturas.
El sistema se ha desarrollado para cubrir las necesidades básicas de la digitalización de
las facturas.
Actualmente las empresas que tienen servicios parecidos desarrollados los ofrecen a
un precio que para las empresas pequeñas y medianas son incapaces de afrontar. Es
por ello que hemos desarrollado la herramienta con software libre, abaratando así los
costes de la aplicación.
Operatividad
El sistema inteligente de interpretación de facturas combina tecnología OCR, (Optical
Character Recognition), con una interfaz sencilla de utilizar y flexible que permite tanto
digitalizar las facturas como corregir datos erróneos y añadir comentarios a las facturas
digitales.
Se compone de cuatro módulos fundamentales, el primero se encarga de la carga y
captura de las secciones importantes de una factura, al conjunto de secciones
importantes en una factura las hemos llamado esqueleto. El segundo es el módulo
OCR, que se encargará de adquirir los datos de las partes de la imagen que hemos
seleccionado anteriormente como importantes. El tercer módulo es el de corrección
de errores, que se encarga de dar la opción al usuario de corregir cualquier tipo de
error que el OCR haya podido introducir. Y el último módulo es el de acceso a las bases
de datos, guardando los datos de cada factura en la base de datos de la empresa.
Todo el programa se desarrollará en Java, utilizando Eclipse como entorno de
desarrollo y para las bases de datos MySQL. Más adelante se detallará el porqué de la
elección de éstas tecnologías.
III
Figura 0.2 Zonas de la aplicación
Desafíos técnicos
Los problemas que surgieron al abordar el proyecto estaban casi todos relacionados
con la elección de un sistema OCR. Al tener relativamente poco tiempo y el equipo
estar formado por una sola persona, la elaboración de un OCR desde cero y nuevo se
descartó inmediatamente. Los OCR existentes son, la mayoría, de pago y al no
disponer de un presupuesto no nos fue posible adquirir ninguna licencia. Los OCR que
utilizamos durante el desarrollo del sistema eran o versiones gratuitas de prueba o
OCR sin ningún soporte ni garantías.
Figura 0.3 Dificultades. Precisión del OCR
Finalmente encontramos una solución que nos aportaba tanto fiabilidad, tasa de
aciertos elevada, soporte y garantía de funcionamiento. Se trataba de un sistema en
fase beta por medio del cual ABBY FineReader, (uno de los motores OCR con mejores
prestaciones del mercado), estaba disponible para hacer Cloud Computing por medio
de una conexión a internet.
IV
Conclusiones
Con este proyecto se demuestra que tecnología punta como puede ser el
procesamiento OCR de facturas, puede estar al alcance de las empresas que no
disponen del poder adquisitivo asociado a las empresas que suelen adquirir este tipo
de sistemas.
La tecnología OCR se puede aplicar a prácticamente todas las tareas de informatización
de archivos en una empresa, en particular a los procesos de informatización de
facturas, eliminando tareas monótonas y que no requieren cualificación dentro de la
empresa.
Con este proyecto se pone a disposición del 80% de las empresas españolas, las
PYMES, una solución sencilla de utilizar, fiable y barata, que servirá tanto para
aumentar el grado de informatización de la empresa, como ayudar a su crecimiento
futuro.
Referencias
[WWW01] ABBY OCR SDK Forum. http://forum.ocrsdk.com/
[WWW02] ABBY Developers. http://www.abbyy-developers.com/en:onlineocrsdk:start
[WWW03] Simple OCR Web Page. http://www.simpleocr.com/
[WWW04] Google Docs OCR. http://googlesystem.blogspot.com.es/2009/09/google-
docs-ocr.html
V
INTELIGENT SYSTEM FOR THE INTERPRETATION OF INVOICES
Author: Carlos Bernabeu Juan
Supervisor: Juan Antonio Pérez-Campanero Anastasio
Affiliation: ICAI, Universidad Pontificia de Comillas.
Figure 0.1 Application Running.
Abstract The project’s objective is to create a simple OCR-based system for the interpretation of
invoices, not only to speed the process up but also to have less people in charge of this
matter on the organization, and therefore save money on a daily basis.
Keywords: OCR, intelligent system, invoice interpretation, invoice.
Introduction
Nowadays organizations have lots of service providers, and they all send different
invoices to the organization. Invoices are the official document needed to perform a
commercial transaction between two entities. The management of this invoices is very
important for the organization, they keep them safe on their databases.
VI
The way to keep record of everything and to have the databases as up-to-date as
possible is to have people continuously transcribing from the paper invoice to the
informatics system. This process not only adds cost to the organization, but also is
commonly avoided in small businesses. In fact the organizations that actually perform
these tasks are big businesses, the small ones leave the invoices in the paper format.
With the developing of this project, we will achieve a higher acceptance of the concept
that is the computerization of the organizations, performing the invoice interpretation
at a very low cost.
Usage
Our system combines OCR technology, (Optical Character Recognition), with a easy-to-
use flexible interface, that will allow OCR processing and data correcting all in one
solution.
The system has four basic modules, the first module is in charge of uploading the
invoice into the system and then defining the important sections of that invoice, those
important sections contain the information that we want to save. The second module
is the OCR module, in charge of processing the invoice and capturing the information
in it. The third module is the one in charge of correcting any mistakes the OCR might
have had, giving the possibility of manual correction. The last module is the database
module, in charge of updating the databases with the new information.
The program will be developed in Java, with Eclipse as the developing environment
and MySQL as the database manager.
VII
Figure 0.2 Sections of the application.
Technical difficulties
The biggest technical difficulty was the one related to the election of the OCR. We
didn’t have enough time to develop the OCR so we had to use one that already
existed. The problem with this technology is that it is very expensive, we didn’t have
any kind of budget so we couldn’t buy a license. During the development of the system
we used free trial versions of the OCR’s but the problem was that they didn’t include
all the features and didn’t offer any support.
Figure 0.3 Difficulties. OCR’s precission
VIII
We finally found one that offered us reliability, support, and had a very high hit rate,
ABBY’s FineReader, (one of the best commercial OCR available nowadays). ABBY had
just launched a beta web page for developers to use the ABBY FineReader OCR using
cloud computing.
Conclusions
With our project we minimize the gap between technology and small businesses, and
we offer these businesses state-of-the-art technology for them to use on their
organizations at a very small price compared with the solutions in the global market.
OCR technology is so versatile it can be used virtually everywhere, from invoice
interpretation to car plate recognition. We offer the small businesses, (which form 80%
of the organizations), a simple, reliable, easy-to-use, and cheap solution to help them
save money and grow as part of the information technology society.
References
[WWW01] ABBY OCR SDK Forum. http://forum.ocrsdk.com/
[WWW02] ABBY Developers. http://www.abbyy-developers.com/en:onlineocrsdk:start
[WWW03] Simple OCR Web Page. http://www.simpleocr.com/
[WWW04] Google Docs OCR. http://googlesystem.blogspot.com.es/2009/09/google-
docs-ocr.html
IX
ÍNDICE
1. Introducción .............................................................................................................................. 1
1.1 Ciclo de una factura ............................................................................................................. 1
2. Alcance del Proyecto ................................................................................................................ 3
2.1 Objetivos ............................................................................................................................. 3
2.2 Funcionamiento básico del sistema .................................................................................... 3
2.3 Tecnologías .......................................................................................................................... 4
2.3.1 Java .......................................................................................................................... 5
2.3.2 Eclipse ...................................................................................................................... 5
2.3.3 MySQL ..................................................................................................................... 6
2.3.4 OCR .......................................................................................................................... 7
2.3.5 Elección del OCR ...................................................................................................... 7
2.4 Metodología ........................................................................................................................ 9
3. Estado del Arte ....................................................................................................................... 11
3.1 Qué es un OCR ................................................................................................................... 11
3.1.1 Preproceso ............................................................................................................. 11
3.1.2 Segmentación ........................................................................................................ 12
3.1.3 Representación digital de la imagen ..................................................................... 12
3.1.4 Reconocimiento ..................................................................................................... 13
3.2 Tecnologías existentes ...................................................................................................... 14
3.3 Tecnologías en desarrollo.................................................................................................. 15
3.4 Empresas en el mercado ................................................................................................... 17
3.5 Situación actual ................................................................................................................. 21
4. Planificación ............................................................................................................................ 23
4.1 EDT .................................................................................................................................... 23
4.2 Descripción de paquetes de trabajo ................................................................................. 24
4.2.1 Definición............................................................................................................... 24
4.2.2 Análisis ................................................................................................................... 24
4.2.3 Programación ........................................................................................................ 25
X
4.2.4 Control ................................................................................................................... 25
4.3 Organización del proyecto ................................................................................................ 26
4.3.1 Organigrama .......................................................................................................... 26
4.3.2 Descripción puestos de trabajo ............................................................................. 27
4.4 Planificación del proyecto ................................................................................................. 30
5. Estimación económica ............................................................................................................ 33
6. Diseño del sistema .................................................................................................................. 37
6.1 Modelo de casos de uso .................................................................................................... 37
6.2 Módulo de carga de facturas ............................................................................................ 38
6.2.1 Creación del esqueleto .......................................................................................... 41
6.3 Módulo OCR ...................................................................................................................... 43
6.3.1 OCR utilizado ......................................................................................................... 44
6.4 Módulo de corrección de errores...................................................................................... 46
6.4.1 Causas de fallos en los OCR ................................................................................... 46
6.5 Módulo de bases de datos ................................................................................................ 48
6.5.1 Proveedores .......................................................................................................... 49
6.5.2 Esqueletos ............................................................................................................. 49
6.5.3 Facturas ................................................................................................................. 51
7. Programación .......................................................................................................................... 53
8. Conclusiones y trabajos futuros ............................................................................................. 61
9. Bibliografía .............................................................................................................................. 63
Anexo A: Manual de usuario ...................................................................................................... 65
1
1. INTRODUCCIÓN
Uno de los objetivos principales de las empresas es la digitalización de la información,
para obtener mayor rapidez, robustez y disponibilidad de los datos que maneja la
empresa. Una gran parte de esta información tiene que ver con facturas y con
información contable, por esta razón se necesitan soluciones informáticas a la hora de
pasar las facturas al ordenador y en definitiva al sistema informático de la empresa.
Según un estudio elaborado por Red.es en colaboración con el Instituto Nacional de
Estadística, prácticamente la totalidad de las empresas españolas tienen ordenador,
conexión a internet y correo electrónico. Ésta afirmación nos indica que una solución
informática a la gestión de facturas sería viable en cuanto a posibilidad de uso para
casi el 100% de las empresas españolas.
1.1 Ciclo de una factura La forma en que se gestionan las facturas ha sido siempre muy pesada, consumía
recursos humanos que podrían aprovecharse en otras tareas y además era una tarea
monótona y aburrida.
Figura 1: Ciclo de una factura
2
En el momento de la recepción de la factura, un operario se encargaba incluirla en el
sistema de gestión existente en la empresa. Generalmente esta inclusión solía ser
tecleando a mano cada campo leído de la factura. Esto sin contar que algunas
empresas ni siquiera tenían software de gestión de facturas y lo que hacían al recibirlas
era archivarlas.
Nuestro proyecto se centra en la tarea del desarrollo de una solución capaz de obtener
los datos relevantes de una factura, de una manera sencilla y fiable, y pasarlos al
sistema informático. Éste tipo de soluciones están disponibles a un precio elevado en
el mercado, sólo accesibles a las empresas de gran tamaño.
Con nuestro proyecto el ciclo quedaría así:
Figura 2: Ciclo de una factura con nuestro sistema
Emisión de la Factura
Recepción de la Factura
Escaneado de la Factura
Procesamiento utilizando OCR
Inclusión automática en el sistema existente
en la empresa
3
2. ALCANCE DEL PROYECTO
2.1 Objetivos Nuestro objetivo es la obtención de datos de las facturas de manera precisa y fiable,
eliminando la tarea manual de introducción de los datos de la factura en el ordenador,
añadiendo algunas funciones como la posibilidad de revisar las facturas en pantalla,
editar datos y previsualización de la factura que está siendo digitalizada.
Un segundo objetivo es, una vez hayamos introducido un tipo de factura en el sistema,
entrenar al programa para que, seleccionando el emisor de la factura, se centre en los
sectores de la factura que contienen información útil, de esta manera no es necesario
utilizar el OCR en la factura entera sino sólo en las zonas de interés.
El público objetivo para el que desarrollamos este sistema son en general empresas
medianas y pequeñas. El problema al que se enfrentan estas empresas es que la
mayoría del software que se desarrolla se hace para beneficio de grandes empresas
con suficiente poder adquisitivo como para permitirse las licencias de sus productos
software. Nosotros nos centraremos en un mercado que es mayoritario en todos los
países, el de las PYMES, ofreciendo una solución fiable a un precio asequible.
2.2 Funcionamiento básico del sistema El funcionamiento básico del sistema es muy predictivo. Se carga la imagen de una
factura, que previamente ha sido escaneada, y se da la opción de crear un ‘Esqueleto’,
que explicaré más adelante, se ejecuta el OCR, que se encargará de obtener los datos
de la imagen. Después de una serie de comparaciones y de verificaciones, se muestran
los datos recogidos de la imagen. Estos datos pueden modificarse en caso de error o
darles el visto bueno y guardarlos en la base de datos.
4
2.3 Tecnologías
Para poder llevar a cabo nuestro proyecto utilizaremos la tecnología OCR.
Un OCR es un programa informático capaz de obtener caracteres de una imagen y
pasarlos a texto editable. En nuestro proyecto utilizaremos OCR ya existentes debido a
que la elaboración de un OCR requiere una dedicación igual o posiblemente superior a
la disponible para la elaboración del proyecto.
Existen muchos motores OCR en el mercado, como pueden ser: SimpleOCR, Tesseract,
JMajick, ASPRISE y ABBY. Los describiré con detalle más adelante.
Se programará en Java, por medio de ECLIPSE con MySQL y utilizando un OCR externo.
5
2.3.1 Java
Java es un lenguaje de programación orientado a objetos que en los últimos años ha
sido el lenguaje más utilizado por los desarrolladores de software, en concreto hay
más de 9 millones de desarrolladores que lo utilizan. Su versatilidad, eficiencia ,
seguridad y portabilidad hacen de Java un lenguaje completo, robusto y a la vez
flexible. Se utiliza en todo tipo de industrias y plataformas, ya sea móvil, ordenador o
red.
Algunos datos que nos ofrece Oracle son que Java:
- se utiliza en 1.1 billones de ordenadores
- en 3 billones de teléfonos móviles
- se producen 31 veces más móviles con java que con android y Apple juntos.
-100% de los BlueRay incorporan java.
Además de todas las ventajas que el lenguaje ofrece a los desarrolladores, java está en
continuo desarrollo y cada vez la comunidad de soporte es mayor, siendo una de las
más activas de los últimos años. No solo se ha reconocido su eficacia en el mundo
laboral sino que también se enseña como primer lenguaje en las universidades y
centros educativos, lo cual indica que es un lenguaje completo y que tiene futuro.
2.3.2 Eclipse
Una vez que elegimos el lenguaje era muy importante elegir bien la plataforma de
desarrollo. Eclipse es una comunidad de individuos y organizaciones que tienen como
objetivo colaborar en un escenario sin ánimo de lucro desarrollando software de libre
distribución.
Se centra en varios lenguajes de programación incluyendo Java. Además de tener
varios ‘plugins’ como puede ser el de WindowBuilder de Google, que hace que la
programación sea sencilla y fluida.
6
2.3.3 MySQL
MySQL se ha convertido en uno de los gestores de bases de datos más populares en
los últimos años. Esto se debe a sus altas prestaciones, fiabilidad y sencillez en el uso.
Además de ser uno de los más flexibles, funcionando en más de 20 plataformas
incluyendo Linux, Windows, Mac OS, Solaris, IBM AIX, entre otras.
Para diseñar las bases de datos, sus diagramas y para el control del servidor de bases
de datos utilizamos MySQL WorkBench, que es una herramienta para unificar el
diseño, la programación y la administración de las bases de datos de MySQL.
7
2.3.4 OCR
En el transcurso del desarrollo del sistema y tras muchas pruebas e intentos, hemos
adoptado el OCR desarrollado por ABBY, ABBY FineReader, que hace uso del concepto
de procesamiento en la nube y analiza las imágenes online, devolviendo los resultados
en archivos de texto.
Aunque existen varias soluciones OCR que no requieren de internet para poder
funcionar, como es el caso de OCR de pago como ASPRISE o de libre distribución como
TESSERACT, nos hemos decantado por la solución de ABBY debido a que las otras
tecnologías debían ser complementadas con procesadores muy complejos para poder
obtener resultados fiables.
2.3.5 Elección del OCR
En un principio comenzamos con el OCR ofrecido por ASPRISE, que además incorpora
un SDK para Java. El funcionamiento del OCR es muy sencillo y predictivo, con llamadas
a clases con nombres muy descriptivos. Este motor funciona de manera más o menos
fiable cuando utilizamos imágenes que presenten texto muy claro, pero si
introducimos perturbaciones como puedan ser líneas horizontales o verticales que son
muy comunes en facturas, el OCR pierde fiabilidad de manera escandalosa. Quedó
descartado tras semanas de pruebas.
Tras el primer intento fallido con el OCR de ASPRISE, comenzamos a utilizar varios OCR
de software libre, como son el JMagick o el Tesseract. El primero lo descartamos por su
compleja adaptación a java. El segundo parecía prometer algo más sabiendo que era el
OCR que utiliza Google para los libros y, tras unos días de búsqueda de una solución a
cómo implementarlo para Java, encontramos una librería llamada Tess4j que es un
“wrapper” por medio de JNA para poder hacer uso del motor OCR Tesseract que está
programado en C++. Tras haber conseguido algo que parecía que iba a funcionar, sólo
quedaba implementarlo en Eclipse y probar su efectividad y eficiencia. Tesseract pese
a ser uno de los OCR de libre distribución que mejor tasa de aciertos tiene, necesita un
soporte y procesamiento muy grande y además perdía fiabilidad cuando la imagen
contenía líneas, igual que pasaba con ASPRISE.
8
Tras varias semanas de búsqueda encontramos una solución beta aportada por ABBY,
una de las empresas más grandes en el sector, que ofrecía procesamiento online para
archivos no demasiado pesados. Tras varias pruebas y tras analizar los resultados
obtenidos, concluimos que era la solución que obtenía los mejores resultados y que,
aunque se convertía en un proceso algo más largo por el hecho de tener que
comunicarse online con el OCR, los resultados merecían el aumento del tiempo de
procesamiento.
En conclusión, la tecnología OCR está en continuo cambio y es debido a eso que las
soluciones existentes pueden tener un índice de aciertos alto en ciertas situaciones,
pero pueden fallar escandalosamente en otras. Por eso nos hemos decantado por la
solución ofrecida por ABBY, que a pesar de ser una beta, se comporta de manera fiable
y precisa en toda la batería de ejemplos probados.
9
2.4 Metodología
La metodología seguida a lo largo de todo el desarrollo del proyecto ha sido una
metodología mixta, pero en la mayoría del tiempo en espiral. Como nuestro proyecto
se basa en el principio de que el OCR acierte, decidimos que lo mejor era centrar todo
el desarrollo entorno al correcto funcionamiento del motor OCR.
El ciclo comenzaba probando un motor OCR en nuestro sistema y, tras ver si
funcionaba o no, entonces se decidía si seguir adelante con el proyecto y desarrollar
los otros módulos o volver a la fase de búsqueda de otro OCR.
Una vez que decidíamos seguir adelante porque el OCR funcionaba, entonces
desarrollábamos un mini prototipo de la versión final, que sería el que determinaría si
definitivamente continuábamos con el proyecto.
El problema existente con esta técnica era que perdíamos muchas horas buscando un
motor OCR que funcionase y no avanzábamos en el grueso del proyecto, que era toda
la parte de creación del esqueleto, con lo cual decidimos cambiar la metodología.
Empezamos a desarrollar el sistema como si el OCR ya funcionase y con una tasa de
aciertos alta, desarrollamos la carga de facturas, la creación del esqueleto y dejamos
los métodos para la parte del OCR creados, con lo cual no había más que añadir el OCR
y adaptarlo a lo que ya había hecho.
Como la parte de corrección de errores dependía íntegramente de los datos devueltos
por el OCR, la dejamos para el final, junto con el acceso a base de datos para guardar
las facturas.
Para saber si el OCR era adecuado o no, desarrollábamos un pequeño prototipo como
el del principio con la única función de ver cómo se comportaba el OCR cuando le
indicábamos que procesase una imagen con texto como las que íbamos a utilizar en el
proyecto final. Una vez veíamos que el OCR se comportaba como era de esperar, se
añadía al proyecto y se volvía a probar, en caso de no ser del todo preciso se volvía a
repetir la búsqueda y adaptación de OCR.
10
Hemos tenido que cambiar de OCR varias veces, debido a que por separado y con
imágenes con texto el OCR se comportaba de forma fiable, pero cuando lo incluía en el
proyecto y le decía que procesase una factura, fallaba.
Este tipo de fallos son comunes en los motores OCR gratuitos debido a que son
motores poco optimizados y que ante variaciones pequeñas en la imagen a procesar,
devuelven resultados completamente diferentes. Por ejemplo, en nuestro caso cuando
le pasábamos una factura con campos y con recuadros, el OCR fallaba porque no
entendía que eran esas líneas, cosa que no ocurre con un OCR comercial y optimizado.
11
3. ESTADO DEL ARTE
Hoy en día hay varias empresas que ofrecen una solución muy parecida a la propuesta
en el proyecto, utilizando un sistema parecido y basándose en OCR también. Esto nos
hace llegar a la conclusión de que el proyecto tiene demanda y se basa en una idea
que está en auge, que es la digitalización de la información.
Generalmente las empresas que ofrecen un servicio de interpretación de facturas lo
hacen o bien con un OCR desarrollado por la propia empresa o con uno ya existente en
el mercado pero optimizado y mejorado por la empresa.
3.1 Qué es un OCR y qué tecnologías utiliza La tecnología OCR engloba a un conjunto de técnicas que complementándose entre sí,
se emplean para distinguir de forma automática los diferentes caracteres existentes.
La precisión de los OCR no llega al 100% y se sabe que cuantos más símbolos existen
en el alfabeto que el OCR maneja, menor es su fiabilidad.
Todo sistema OCR tiene 4 etapas bien diferenciadas: Preproceso, Segmentación,
Representación Digital de la Imagen y Reconocimiento.
3.1.1 Preproceso
En esta fase el objetivo es eliminar de la imagen todo lo que sean perturbaciones o
ruido, es decir, imperfecciones que no pertenezcan al carácter.
12
3.1.2 Segmentación
En la segmentación tratamos de dividir en partes la imagen a procesar, intentando
separar entre caracteres, como es obvio, una imagen que contenga un texto continuo
será más difícil de analizar que otra que contenga texto delimitado por campos, como
puede ser un formulario.
Figura 3: Segmentación en un OCR
En los casos en los que no existen campos que delimiten los caracteres, para realizar la
segmentación es necesario conocer alguna característica más del texto, como puede
ser la longitud aproximada de cada carácter o la separación entre letra y letra.
3.1.3 Representación Digital de la Imagen
Una vez realizada la segmentación, se dispone de una imagen normalizada en la que
se encuentra la información susceptible de ser reconocida. Esta información se
encuentra en una matriz bidimensional de tantas dimensiones como componentes
tenga. La dimensión de estos vectores suele ser elevada y en esos casos ocurre lo que
se ha estudiado y llamado la “maldición de la dimensionalidad”, que provoca que los
resultados, independientemente del método de clasificación utilizado, sean malos. Por
ello se han desarrollado muchas técnicas de selección y extracción de características
mediante las cuales se obtiene una representación del objeto a reconocer más
eficiente.
13
Eficiencia en este caso significa que con una representación más compacta, se
consigue un poder discriminativo igual o superior al que obtendríamos con la
representación original. Esto es importante porque reduce el tamaño de las muestras y
reduce el coste computacional. Algunos métodos de extracción de características y
representación digital son:
-PCA (Principal Component Analysis).
-LDA (Linear Discriminant Analysis).
-ICA (Independent Component Analysis).
-NDA (Non-Linear Discriminant Analysis).
3.1.4 Reconocimiento
El objetivo final del OCR es el de clasificar una imagen entre un conjunto de símbolos
posibles. Esto se lleva a cabo en esta última fase, por medio de definición de clases a
las que pueden pertenecer los objetos analizados.
Actualmente existen gran variedad de métodos de clasificación que han ido surgiendo
durante el desarrollo de los OCR. El más popular por su sencillez y gran versatilidad es
el KNN, o también llamado K-Nearest-Neighbours. El KNN funciona de la siguiente
manera: dado un conjunto de objetos de muestra de los cuales ya conoce su clase, y
dado un conjunto de objetos que aun no conocemos, se busca entre los objetos de
muestra para encontrar los K más parecidos al nuevo objeto, y se le asigna la clase más
numerosa entre los K objetos de muestra seleccionados.
Como es obvio y sabiendo cómo funciona el método KNN es necesario tener una base
de datos de imágenes de las que conocemos la clase, a este conjunto se le llama
conjunto de entrenamiento.
14
3.2 Tecnologías existentes
Actualmente se han desarrollado tecnologías que permiten el procesado de
formularios manuscritos, eliminando la tarea de hacerlo manualmente. Se escanea el
documento y posteriormente se le aplica el OCR. Tras obtener los resultados un
operador debe corregir los posibles fallos cometidos por el OCR.
Figura 4: Procesado de un formulario manuscrito
15
3.3 Tecnologías en desarrollo
Actualmente se están desarrollando tecnologías capaces de agilizar procesos del día a
día de las empresas, como puede ser el reconocimiento de campos en las facturas.
Existen dos tipos de tecnologías en este sector, las inteligentes y las no inteligentes.
Las inteligentes se diferencian en que tienen un proceso de aprendizaje por medio del
cual extraen los campos clave de las facturas de un proveedor para ahorrase tiempo de
procesamiento la siguiente vez que llegue una factura de ese proveedor. Esto lo
consigue utilizando la técnica que en este proyecto hemos bautizado como de creación
de Esqueletos.
Figura 5: Procesado de una factura
16
Otro tipo de desarrollos que se están llevando a cabo son en el campo de la
identificación de matrículas de vehículos.
Figura 6: Procesado de una matrícula
17
3.4 Empresas en el mercado
Las empresas son QUANTYCA SOFTWARE SOLUTIONS, PIXELWARE, SCANCIA entre
otras.
3.4.1 Quantyca Software Solutions
Es una empresa fundada en 2007 que da soluciones informáticas basadas en
tecnología punta a empresas pequeñas que de otra manera no podrían costeárselas.
Su producto estrella es el Contamática 100, que es un sistema de contabilidad basado
en la tecnología OCR, que analiza las facturas y las valida online. La licencia es de pago
por uso y tiene un precio de suscripción de 399€.
Los productos que ofrece son:
-NavegaDoc: Es un gestor de documentos inteligente que utiliza un buscador
para buscar información dentro de un documento.
-Contamática 100: Es el gestor online de facturas con un acierto del 100%.
-Contamática LowCost: Es el gestor online de facturas pero limitado a una
versión más básica.
Figura 7: Quantyca
18
3.4.2 Pixelware
Empresa especializada en la gestión digital de expedientes, albaranes y facturas.
Ofrecen soluciones innovadoras y en evolución constante, utilizando tecnologías
pioneras.
Proporcionan aplicaciones personalizadas que cumplen las expectativas y
requerimientos del cliente.
El producto que ofrecen es la gestión de albaranes y facturas mediante OCR.
Figura 8: PixelWare
19
3.4.3 Scancia
Desarrollado por VirtualSoftware, compañía española nacida en 1992 que desarrolla
sistemas informáticos, es un sistema de gestión integral y digital de facturas, contratos
y otros tipos de documentos. Se encarga de digitalizarlos, procesarlos y luego obtener
los datos en formato digital.
Figura 9: Scancia
20
3.4.4 Neoscan
Software de procesamiento digital de facturas e integración con programas contables,
escanea la factura, procesa el documento con un OCR y guarda los datos procesados,
integrándolos con el sistema contable de la empresa.
Figura 10: NeoScan
21
3.5 Situación actual
Todas las empresas del sector se centran en ofrecer una solución fiable pero muy cara,
y generalmente enfocada a empresas de gran tamaño con suficiente capital como para
comprar las licencias.
Según un informe elaborado por Red.es en colaboración con el Instituto Nacional de
Estadística indica que el 95% de las empresas españolas son las llamadas
Microempresas, es decir, empresas con menos de 10 empleados.
Figura 11: Gráfico de porcentaje de Microempresas en España
En el gráfico se muestra el total de microempresas frente al total de empresas en
España y el número de empleados en las microempresas.
Como podemos observar la gran mayoría de las empresas españolas son pequeñas y
con menos de 5 empleados, lo cual indica que una solución software cara para la
gestión de las facturas no sería aceptada por el mercado objetivo de las
microempresas.
El éxito radica en ofrecer una solución que cumpla con tres parámetros sencillos de
explicar pero difíciles de conseguir en la práctica:
-Sencillez: La aplicación debe ser intuitiva y fácil de usar, la mayoría de las
personas están familiarizadas con programas comerciales como puede ser el Microsoft
Word, Excel o Powerpoint. El objetivo es que la aplicación se parezca en cómo usarla a
dichos programas.
22
-Fiabilidad: Una solución software que además requiere alta interacción del
usuario no sería muy exitosa debido a que la gente está adoptando nuestra solución
para ahorrar tiempo y recursos que podrían utilizarse en otras tareas. Nuestra solución
debe ser fiable y tener una tasa de aciertos cercana al 100%.
-Económica: Como ya hemos visto en los gráficos anteriores, la mayoría de las
empresas son microempresas, no disponen de suficiente capital como para estar
adquiriendo licencias caras. Gracias a que la aplicación está enfocada a utilizar
software de libre distribución y gratuito, no supondrá un coste elevado para las
empresas que decidan adquirirlo.
23
4. PLANIFICACIÓN
En este apartado hemos realizado un Plan de Proyecto, que incluirá:
-Estructura de División del Trabajo: Organización del trabajo a realizar por
medio de un árbol invertido.
-Descripción de los diferentes Paquetes de Trabajo: Entradas, Procesos y
Salidas de información en el sistema.
-Organización del Proyecto: Cómo está estructurada la cadena de mando y qué
roles y perfiles son los necesarios para elaborar el proyecto.
-Planificación: Cómo está planificado el proyecto a lo largo de su desarrollo.
4.1 Estructura de División del Trabajo
Se va a proceder a organizar el trabajo a desarrollar mediante un árbol invertido,
donde se refleja las diferentes actividades que se irán realizando para el PGP final de la
aplicación a desarrollar del proyecto de fin de carrera.
Figura 12: Estructura de División del Trabajo
Aplicación Informática-Digitalize
A0. Definición del Proyecto
A1. Análisis del Problema
A2. Programación Control del Proyecto
24
4.2 Descripción de los Paquetes de Trabajo
En esta sección se describen los diferentes paquetes definidos en la Estructura de
División del Trabajo, definiendo sus entradas, salidas y los procesos que tienen lugar
en cada paquete.
4.2.1 A0. Definición del Proyecto
Paquete de trabajo A0. Definición del proyecto
Entradas: -Pliego de Prescripciones Técnicas, (PPT)
- Requisitos de la aplicación
Procesos: - Lectura del Pliego de Prescripciones Técnicas (PPT)
- Extracción de información relevante
- Análisis de requisitos del cliente
- Definición del alcance de la tecnología a desarrollar
- Elaboración del planteamiento general
Salidas: - Definición del Proyecto
4.2.2 A1. Análisis del problema
Paquete de trabajo A1. Análisis del problema
Entradas: - Definición del Proyecto
Procesos: - Análisis de requisitos
- Definición de objetivos
- Definición de recursos y tecnologías a utilizar
Salidas: - Texto del Análisis del Problema
25
4.2.3 A2. Programación
Paquete de trabajo A2. Programación
Entradas: - Definición del Proyecto
-Análisis del Problema
Procesos: - Desarrollo de la Aplicación basándonos en las entradas
Salidas: - Aplicación en fase de diseño y desarrollo
4.2.4 A3.Control del Proyecto
Paquete de trabajo A.3 Control del Proyecto
Entradas: -Pliego de Prescripciones Técnicas (PPT)
-Estructura de División del Trabajo
-Descripción de los Paquetes de Trabajo
-Presupuestos para el proyecto
-Planificación del proyecto
Procesos: -Establecer medidas de correcta finalización de cada
paquete de actividad
-Estipular reuniones de control y verificación
-Establecer medidas para la correcta entrega de
documentos parciales y finales en la fecha limite marcada
-Entrega de documentación aprobada y corregida
-Métricas de medida de calidad, económicas, técnicas y
del cumplimiento de fechas estipuladas
Salidas: - Plan de control del proyecto
26
4.3 Organización del Proyecto
Como todo proyecto que sea de una complejidad y longitud considerable, debe haber
una estructura de toma de decisiones, por medio de la cual se establezca una
jerarquía.
En este apartado se expone esa estructura y se definen los roles de cada uno de los
implicados.
4.3.1 Organigrama
Diagrama 1: Organigrama del proyecto
Coordinador de Proyecto
Director de Proyecto
Jefe de Proyecto
Consultor
Línea discontinua:
Interviene
27
4.3.2 Descripción de Puestos de Trabajo
Nombre del puesto Director del proyecto
Responsabilidades Planteamiento y Definición del Proyecto
Descripción
Posee la responsabilidad total del planeamiento teórico de las bases del proyecto. Su
firma certifica la calidad del proyecto así como su viabilidad.
Debe ser un Ingeniero
Conocer y controlar los temas tratados en el Proyecto
Miembro de la Universidad o miembro de una empresa que oferte el proyecto
Responsabilidades para con el proyecto
Definición del Proyecto
Firma del Proyecto
Responsable último del Proyecto
28
Nombre del puesto Jefe de proyecto
Responsabilidades Planteamiento y ejecución correcta del
desarrollo del proyecto
Descripción
Posee la responsabilidad total del planeamiento y la ejecución del proyecto. Se
necesita que el jefe de proyecto posea una correcta combinación de las siguientes
habilidades:
Gran capacidad inquisitiva
Detección de problemas sin especificar
Resolución de conflictos interpersonales
Reconocimiento de riesgos que afectan directamente las probabilidades de
éxito del proyecto, y la constante medición, formal e informalmente de dicho
riesgo a lo largo del ciclo de vida del proyecto
Capacidad de reducir los riesgos significativamente
Capacidad de una política de comunicación abierta, asegurándose de que cada
participante tenga una oportunidad de expresar sus opiniones y
preocupaciones
Capacidad de tomar las decisiones necesarias para que el riesgo sea
controlado y la incertidumbre reducida al mínimo.
Responsabilidades para con el proyecto
Control y coordinación del proyecto
Control y coordinación del equipo de trabajo
Control de métricas
Presidir y coordinar de las reuniones del equipo de trabajo
Elaboración de la documentación
Comunicación entre cliente y equipo de trabajo
Cada decisión tomada por el encargado de proyecto debe involucrar un beneficio
29
directo hacia el proyecto.
Nombre del puesto Consultor
Responsabilidades Elaboración de la sección asignada del
proyecto.
Descripción
Profesional capacitado que ofrezca soluciones a problemas o situaciones que aporten
valor. Capacitado y con experiencia en el área de tecnología y con conocimientos en el
rea de desarrollo de software, herramientas ofimáticas, redes y comunicaciones.
Requisitos a cumplir:
Conocimientos de Tecnologías de la información
Conocimientos básicos en consultoría informática
Conocimientos básicos de gestión de proyectos
Cursar último curso de Ingeniería Informática
Sus áreas de responsabilidad serán:
Elaboración de paquetes de trabajo asignados
Asistir a reuniones de control.
30
4.4 Planificación del Proyecto
El proyecto comenzó oficialmente en Septiembre de 2011, fecha en la que
comenzamos a cursar 5º de IINF pero no se da comienzo real hasta el alta del
proyecto, que es en Noviembre, cuando firmamos la apertura del proyecto con
nuestro Jefe de Proyecto.
En esta sección se muestra con detalle la planificación seguida en estos meses de
trabajo.
Figura 13: Planificación del Proyecto
31
Figura 14: Planificación del Proyecto
32
El diagrama de Gant, con cada una de las tareas importantes resaltadas en negro,
(Definición del Proyecto, Análisis del Problema, Programación, Elaboración de la
Memoria y Control del Proyecto).
Figura 15: Diagrama de GANT
33
5. ESTIMACIÓN ECONÓMICA
La estimación económica que describimos en esta sección está sujeta a varias
condiciones importantes que son necesarias para su correcto entendimiento.
La primera es que estamos estimando los cálculos basándonos en que un Consultor
cobra 20€ la hora de trabajo.
La segunda es que un Jefe de Proyecto cobra 30€ la hora de trabajo.
La tercera condición es que suponemos una implicación con total disponibilidad tanto
para el Consultor como para el Jefe de Proyecto, algo que no es real debido a que el
consultor es el alumno que realiza el proyecto y no siempre puede dedicarse
únicamente al proyecto. Y de la misma forma, el Jefe de Proyecto no tiene total
disponibilidad para el proyecto en cuestión debido a que es un profesor de la
universidad y tiene otras tareas que atender aparte del proyecto del que es jefe.
Teniendo estas condiciones en cuenta, y desglosando por horas invertidas para cada
paquete de trabajo definido previamente, la estimación de horas quedaría:
34
Número de Horas por Paquete de Trabajo y Trabajador
Consultor Jefe de
proyecto
Director
de
Proyecto
Total
Definición del
proyecto
2h 2h 4h
Análisis del
problema
Análisis de
requisitos
23h 23h 46h
Análisis de
tecnologías a
emplear
25h 25h
Diagramas 15h 15
Programación Interfaz 60h 10h 70h
Lógica básica 60h 60h
Bases de
datos
10h 10h
Revisión
datos
procesados y
corrección de
errores
20h 20h
Implantación 60h 60h
Control del
proyecto
Reuniones
periódicas
1h 1h 2h
Memoria del
Proyecto
30h 30h
Pruebas y
corrección de
errores
20h 20h
Total 253 horas 106
horas
3 horas 362
horas
Tabla 1: Número de horas por paquete de trabajo
35
Incorporando la tarifa del jefe de proyecto, la del director y la del consultor:
Tarifas de cada Trabajador
Consultor
Jefe de Proyecto
Director de Proyecto
20€/h 30€/h 25€/h
Tabla 2: Tarifas
Presupuesto por Trabajador
Consultor Jefe Proyecto Director Proyecto
Total
253h*20€/h 106h*30€/h 3h*25€/h
Total 5.060 € 3.180 € 75€ 8.315 €
Tabla 3: Presupuesto
36
37
6. DISEÑO DEL SISTEMA
El proyecto se ha desarrollado en java utilizando Eclipse y un ‘plugin’ llamado
WindowBuilder desarrollado por Google para el diseño de la interfaz gráfica.
El proyecto tiene varios módulos que permiten al usuario final realizar las tareas
definidas en el modelo de casos de uso.
6.1 Modelo de casos de uso
Crear Esqueleto de
Proveedor Nuevo.
Procesar una Factura
de un Nuevo
Proveedor.
Procesar una Factura
de un Proveedor
Existente.
Usuario
Figura 15: Modelo de Casos de Uso
38
6.2 Módulo de selección y carga de facturas Es el primer módulo que desarrollamos y se encarga de la carga de una factura válida.
Las facturas pueden cargarse como imágenes normales (jpeg, bmp) o como imágenes
escaneadas (tiff). La factura se selecciona y se precarga en la aplicación, mostrándola
en la zona de visualización de la factura.
Figura 17: Inicio de la Aplicación
39
Figura 18: Zonas de la Aplicación
Figura 19: Selección de la factura
40
Una futura mejora para la aplicación podría ser el procesamiento de un lote de
facturas escaneadas, que es simplemente hacer que el uso continuado de la aplicación
no se vuelva algo pesado. Con esta mejora se consigue aumentar la rapidez con la que
procesamos facturas al igual que se aumenta en comodidad.
Una vez que hemos precargado la factura en el sistema, éste nos pregunta si la factura
es de un proveedor nuevo o uno del que ya hemos procesado alguna factura. En caso
de ser un proveedor nuevo vamos a tener que crear el llamado ‘Esqueleto’, que no es
más que un conjunto de coordenadas en las que con una probabilidad alta se van a
encontrar los datos relevantes para el usuario. En este momento entramos en la
sección de creación de esqueleto.
Figura 20: Precarga de la factura en el sistema
41
6.2.1 Sección de creación de esqueleto
Un esqueleto se va a crear siempre vinculado a un proveedor o emisor de facturas.
Todas las facturas tienen una serie de campos clave, como pueden ser el emisor,
receptor, número de factura, fecha, cantidad base, impuestos y cantidad total. A estos
campos clave se les va a asociar un área en la imagen de la factura para que, en
próximas cargas de facturas de ese proveedor, el OCR se pueda centrar en analizar
sólo las zonas seleccionadas como importantes.
Figura 21: Creación del Esqueleto
42
Cada zona la selecciona el usuario y de esa selección depende en gran medida la tasa
de aciertos del OCR. Cada zona se guarda en base de datos con 2 puntos que contienen
cada uno una coordenada ‘x’ y otra ‘y’. Estas coordenadas se generan al hacer drag-
and-drop sobre la factura. Más adelante se cargan las coordenadas para formar los
rectángulos con el área de la imagen que se debe analizar.
Figura 22: Esqueleto creado
43
Una vez que el Esqueleto se ha creado con éxito, se guarda en la base de datos llamada
Esqueletos. Esta base de datos es la que contiene una referencia por cada proveedor
nuevo que emite una factura que después será analizada por nuestro sistema.
En el caso de que no sea necesaria la creación de un esqueleto, por ejemplo si el
proveedor ya tiene un esqueleto creado, al cargar la factura simplemente se selecciona
el proveedor que ha emitido la factura y automáticamente se cargan los datos de su
Esqueleto.
Figura 23: Selección de Proveedor
6.3 Módulo de OCR Tras cargar el esqueleto de un proveedor, pasamos al módulo más importante de
nuestro sistema, el módulo OCR. El OCR se va a encargar de analizar cada sección de la
factura que haya sido incluida como relevante y parte del esqueleto. Como ya
explicamos anteriormente, el módulo OCR es el que más cambios ha sufrido a lo largo
del ciclo de desarrollo del proyecto. En la versión final el OCR que hemos utilizado es el
que ha puesto ABBY a disposición de los desarrolladores en su web, es decir, lo que se
44
quiera analizar hay que enviarlo a la web de ABBY y recibir los resultados en un archivo
de texto.
6.3.1 OCR utilizado
El OCR de ABBY se llama FIneReader y funciona de la siguiente manera: Antes de
aplicar el OCR se realiza un pre-procesamiento de la imagen cargada, de esta manera
se corrigen distorsiones en la imagen original, como pueden ser orientación, manchas
o simple ruido.
FineReader comienza el análisis de de la imagen desarrollando una estructura del
documento a analizar. Divide la página en bloques de texto, tablas e imágenes. Tras
hacer esto comienza el proceso de detección de líneas, palabras individuales y letras.
Cada pedazo de la imagen es comparado con una serie de patrones que definen con
una probabilidad alta una letra concreta. Todo esto es posible gracias a los algoritmos
desarrollados por ABBY, los ADRT, (ABBY’s Adaptive Document Recognition
Technology). FineReader determina la posición de cada letra en una palabra, cada
palabra en una línea como también las propiedades de cada página. Todas las
divisiones tanto lógicas como físicas, como puedan ser el encabezado, pie de página y
demás, se mantienen exactamente en el mismo lugar. FineReader tiene soporte para
37 de los 42 lenguajes OCR disponibles. Compara las palabras detectadas con las
existentes en sus diccionarios, lo cual asegura mejor tasa de aciertos.
En este módulo además de enviar las zonas de la factura a procesar y recibir los datos
procesados, todos los datos se pasan por un procesador propio de la aplicación que se
va a encargar de eliminar todo tipo de impurezas antes de mostrar lo analizado en la
zona habilitada para la recepción de datos en la aplicación.
El procesador se encarga de validar la integridad de los datos, validando formatos de
fecha, formatos de campos como pueden ser el CIF/NIF.
45
Figura 24: Datos devueltos por el OCR
Como puede observarse la tasa de aciertos es muy alta, de hecho solo ha cometido
fallos al confundir algún 0 por un 3, todo lo demás es exactamente lo que le dijimos
que analizase. En éste caso en que se ha confundido, entraría en juego el siguiente
módulo, que es el de corrección de errores.
46
6.4 Módulo de corrección de errores
El módulo de corrección de errores es un módulo que no debería existir, pero debido a
que la tecnología OCR aún no está garantizando el 100% de aciertos, es necesaria una
sección dedicada a la posibilidad de que el OCR falle.
6.4.1 Causas de los fallos en los OCR
Los ruidos o impurezas son problemas comunes en todas las áreas de procesamiento
digital de imagen, y en particular son bastante comunes en procesos OCR.
Generalmente son variaciones en el color donde no debería haber variación, aunque a
simple vista no parezca haber variación, es muy difícil conseguir que una zona de un
color sea uniforme y no contenga sombras.
Figura 25: Sombras en una imagen
El problema radica en que cuando nosotros miramos la imagen nos damos cuenta que
en la zona rosa, aunque haya variaciones y sombras, no hay información útil. No nos
pararíamos a mirar porqué existe variación porque sabemos que no contiene el texto
que es lo que queremos en realidad. Pero eso sólo ocurriría si el OCR fuese un cerebro
humano, entonces pasaría por alto esas variaciones. Al no ser así y sabiendo cómo
funciona la tecnología OCR que es, en definitiva, un comparador, nos damos cuenta
que el motor OCR sí se pararía a analizar esas variaciones, pudiéndose confundir y
errar en su predicción.
47
Estas variaciones y ruidos no tienen porqué ser producto de un mal escaneado,
también pueden producirse por mala compresión como por ejemplo la compresión
producida por el algoritmo JPEG, que aunque ofrece altos grados de compresión,
pierde calidad y puede llegar a cambiar pixeles en la imagen.
Existen filtros que pueden reducir este tipo de problemas, mediante técnicas como la
fusión de pixeles para diluir el impacto ante cambios bruscos en color. Ésta técnica se
conoce como procesamiento digital de señales con filtros de baja frecuencia, lo que
significa que deja que las señales con frecuencias bajas y que cambian de manera
gradual con el tiempo pasen por el filtro, y bloquea aquellas señales de alta frecuencia
que cambian bruscamente.
Este tipo de filtros también tienen un problema, al fusionar pixeles puede darse la
situación de que la imagen se desenfoque y pierda claridad en los bordes, haciendo
una vez más que el OCR pierda efectividad.
Figura 26: Señales sin filtro (arriba y abajo a la izquierda), frente a señales tras pasar el
filtro (arriba y abajo a la derecha).
Una mejora en un futuro sería la de añadir distintos tipos de filtros a nuestra aplicación
para aumentar su tasa de aciertos y por consiguiente disminuir la de fallos.
48
Figura 27: Sección de corrección de errores
6.5 Módulo de bases de datos
En el módulo de bases de datos lo que se hace es guardar los datos en la base de datos
MySQL. Es necesario que los datos que se vayan a guardar se validen y se verifiquen,
de tal manera que no pueda fallar el programa por un error de sintaxis SQL. Los
campos que se han definido como ‘String’ no es necesario validarlos pero aquellos
definidos como ‘Int’ o ‘Float’ o Date hay que asegurarse que tienen el formato
adecuado.
La base de datos se compone de tres tablas: Proveedores, Esqueletos y Facturas
49
6.5.1 Proveedores
Ésta tabla contiene los datos de todos los proveedores que alguna vez han enviado una
factura y ésta se ha analizado y procesado en el sistema.
Figura 28: Combobox con los Proveedores o Emisores de Facturas
6.5.2 Esqueletos
La tabla de esqueletos contiene información de las zonas importantes de las facturas
de un proveedor. Al seleccionar un proveedor que ya existe en el sistema, éste
automáticamente carga los datos del esqueleto asociado a ese proveedor, mostrando
las zonas seleccionadas como importantes con diferentes colores en la factura.
50
Figura 29: Sistema cargando el esqueleto de un proveedor
51
6.5.3 Facturas
Ésta tabla contiene la información de la factura procesada, pudiéndola adaptar al
formato que el cliente exija. Al ya tener la factura en base de datos no se corre riego
de pérdida de información o de deterioro de la factura física.
Figura 30: Tablas en la base de datos.
52
53
7. PROGRAMACIÓN
El proyecto está programado en Java y se utilizó como entorno de desarrollo Eclipse.
Para la creación de la interfaz gráfica se ha utilizado el WindowBuilder de Google, que
es un pluggin de Eclipse para crear interfaces gráficas.
Nuestro proyecto consta de 10 clases, 6 de creación propia y 4 del OCR de ABBY:
- appGestionFacturas.java
- Esqueleto.java
- OCR.java
- PanelImagen.java
- Procesador.java
- Filtro.java
- Base64.java
- Client.java
- ProcessingSettings.java
- Task.java
Voy a describir las clases que hemos desarrollado en el proyecto
54
appGestionFacturas.java
Es la clase principal y se encarga de inicializar todos los componentes de la interfaz
gráfica y de llamar en cada momento a cada una de las demás clases.
appGestionFacturas
1.Filtro.java
2.PanelImagen.java
3.Esqueleto.java 4.OCR.java
5.Procesador.java
55
Filtro.java
Ésta clase se encarga de dar al usuario la opción de elegir una imagen de una factura a
cargar, pero teniendo en cuenta los formatos que están permitidos. En caso de no
haber elegido un formato correcto notificará al usuario mediante un cuadro de diálogo
emergente para que vuelva a elegir otra imagen.
Fragmento de código 1
public boolean accept(File f) { boolean r; int i= f.getName().lastIndexOf('.'); String s= f.getName().substring(i).toLowerCase();
if(s.equals(".jpg")==true|| s.equals(".gif")==true||s.equals(".tif")==true||s.equals(".bmp")==true)
{ r=true; }else { r=false; } return r; }
56
PanelImagen.java
La clase PanelImagen.java es la encargada de todo el procesamiento gráfico en la imagen de la
factura, desde cargar la imagen hasta superponer la imagen con su esqueleto. Llegado el
momento ésta clase nos permitirá crear un esqueleto visualmente y directamente sobre la
imagen cargada. Para ello hemos tenido que redefinir el método paintComponent del
componente JPanel.
Fragmento de código 2
//Redefinimos el PaintComponent para adaptarlo a las necesidades de cada momento public void paintComponent(Graphics g) { this.g=g; if(sw3!=2)//Pinta la imagen inicial { super.paintComponent(g); g.drawImage(img, 0,0, this); } if(sw3==2)//Pintar el rectangulo definido por las coordenadas x,y,w,h en cada momento { int x=coordenadaX1; int y=coordenadaY1; int w=(coordenadaX2-coordenadaX1); int h=(coordenadaY2-coordenadaY1); super.paintComponent(g); //Queremos que se vea la factura por detrás, la pintamos g.drawImage(img, 0,0, this); g.setColor(Color.red); //Rectangulo g.drawRect(x, y, w, h); } if(sw4==1)//Pintar todos los rectángulos definidos { super.paintComponent(g); g.drawImage(img, 0,0, this); //Como son 7 pintamos los 7 rectángulos for(int i=0;i<7;i++) { g.setColor(color[i]); g.drawRect(x[i], y[i], w2[i], h2[i]); } } }
57
Esqueleto.java
La clase Esqueleto.java es la encargada de inicializar el esqueleto asociado a un
proveedor nuevo, guardando las coordenadas de cada rectángulo asociado a un campo
clave en la base de datos de Esqueletos.
Fragmento de código 3
//SetNombre public void setNombre(String nombre) { this.nombreProveedor= nombre; } //SetNF va a inicializar las coordenadas del Número de Factura public void setNF(int x1,int y1,int x2,int y2) { this.NFx1=x1; this.NFy1=y1; this.NFx2=x2; this.NFy2=y2; } //SetF va a inicializar las coordenadas de la Fecha public void setF(int x1,int y1,int x2,int y2) { this.Fx1=x1; this.Fy1=y1; this.Fx2=x2; this.Fy2=y2; } //SetR va a inicializar las coordenadas del Receptor public void setR(int x1,int y1,int x2,int y2) { this.Rx1=x1; this.Ry1=y1; this.Rx2=x2; this.Ry2=y2; } //SetCIF va a inicializar las coordenadas del CIF/NIF public void setCIF(int x1,int y1,int x2,int y2) { this.CIFx1=x1; this.CIFy1=y1; this.CIFx2=x2; this.CIFy2=y2; }
58
Fragmento de código 4
int retorno = stmt.executeUpdate(); //Ahora hay que añadir los datos del esqueleto stmt = conexion.prepareStatement("INSERT INTO pfc.esqueletos VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)"); stmt.setInt(1,indice); stmt.setString(2,nombreProveedor); stmt.setInt(3,NFx1 ); stmt.setInt(4,NFx2); stmt.setInt(5,NFy1); stmt.setInt(6,NFy2 ); stmt.setInt(7,Fx1 ); stmt.setInt(8,Fx2 ); stmt.setInt(9,Fy1); stmt.setInt(10,Fy2 ); stmt.setInt(11,Rx1); stmt.setInt(12,Rx2); stmt.setInt(13,Ry1); stmt.setInt(14,Ry2); stmt.setInt(15,CIFx1); stmt.setInt(16,CIFx2); stmt.setInt(17,CIFy1); stmt.setInt(18,CIFy2); stmt.setInt(19,Bx1); stmt.setInt(20,Bx2); stmt.setInt(21,By1 ); stmt.setInt(22,By2 ); stmt.setInt(23,IVAx1); stmt.setInt(24,IVAx2); stmt.setInt(25,IVAy1); stmt.setInt(26,IVAy2); stmt.setInt(27,Tx1); stmt.setInt(28,Tx2); stmt.setInt(29,Ty1); stmt.setInt(30,Ty2);
59
OCR.java
OCR.java es la clase que llama a las clases de ABBY, en el paquete ‘com’, para procesar
las imágenes que necesitamos analizar.
Fragmento de código 5
public OCR(String app, String pass, String img, String txt) { Client restClient = new Client();
//El applicationId es el identificador de nuestra aplicación en ABBY.com
restClient.applicationId = app;
//El password es la contraseña de nuestra aplicación en ABBY.com
restClient.password = pass; //Aqui recogemos el path a la imagen a procesar String filePath = img; //Los resultados los devolverá en ese txt String outputFile = txt; //Comunicación con ABBY.com y procesado de las imagenes ProcessingSettings settings = new ProcessingSettings();
60
Procesador.java
La clase Procesador.java va a analizar los datos obtenidos por el OCR de ABBY y se va a
encargar de eliminar caracteres extraños y poner los datos en formatos que sean
aceptados por la base de datos.
Fragmento de código 6
//Fecha, tiene que estar en formato MySQL AAAA-MM-DD auxiliar=datos[1].toString(); int j=0; String a=""; //contamos cuantos números hay for(int i=0;i<auxiliar.length();i++) { if(Character.isDigit(auxiliar.charAt(i))) { j++; int li= auxiliar2.length();
auxiliar2 = new StringBuffer(auxiliar2).insert(li, auxiliar.charAt(i)).toString();
}else { if(auxiliar.charAt(i)=='/'||auxiliar.charAt(i)=='-') { a=a+""+j; j=0; int li= auxiliar2.length();
auxiliar2 = new StringBuffer(auxiliar2).insert(li,"-").toString();
} } }
// 'a' va a contener un número por ejemplo 114, que significa que el día
//tiene una cifra, el mes también y el año cuatro, con lo cual hay que ponerlo siempre con dos cifras(añadiendo 0)
//y en formato AAAA-MM-DD a=a+""+j; //Añadimos 0 si es necesario if(a.equals("114")) { //Añado 0
auxiliar2 = new StringBuffer(auxiliar2).insert(0, '0').toString();
auxiliar2 = new StringBuffer(auxiliar2).insert(3, '0').toString();
//Lo pongo en formato SQL String dia=auxiliar2.substring(0, 2); String mes=auxiliar2.substring(3, 5);
String anio=auxiliar2.substring(6,10);
auxiliar2=""+anio+"-"+mes+"-"+dia; }
61
8. CONCLUSIONES Y TRABAJOS FUTUROS
Vivimos en la Sociedad de las Tecnologías de la Información, hoy en día todo negocio
dispone de un ordenador o algo controlado por un ordenador. La información ya no
viaja en formatos tangibles, se mueve y fluye vía Internet y esto agiliza mucho la
comunicación entre las diferentes partes que intervienen en un comercio.
Aunque se han digitalizado muchos sectores de las empresas, aún quedan algunos que
siguen haciendo uso de medios físicos como el papel para diversas tareas, como puede
ser informar, o enviar una factura.
Las facturas son la base de todo negocio, sin ellas no se podría comprobar que en
algún momento existió una transacción económica entre dos partes, el comprador y el
vendedor. Son tan importantes que las empresas dedican secciones enteras de sus
organizaciones a su gestión, se reciben, se incluyen en el sistema contable de la
empresa y después se contabilizan. El proceso de incluir las facturas en el sistema de
una empresa es, en casi todos los casos manual, y absorbe recursos y tiempo.
Gracias a los avances en las tecnologías en general en los últimos años y en particular
en la tecnología OCR, ha sido posible el desarrollo de un sistema capaz de automatizar
el proceso de digitalización de las facturas.
El mercado de los sistemas de automatización de procesos del día a día de las
empresas es un mercado que está en crecimiento, es relativamente nuevo y hay pocos
competidores. De hecho, en el caso particular del software de proceso y análisis de
facturas, los proveedores se pueden contar con los dedos de las manos.
Es por esas razones por las que nos hemos centrado en desarrollar una herramienta
sencilla de utilizar, fiable, y que se puede mejorar en caso de querer comercializarla. La
herramienta está lejos de alcanzar una tasa de aciertos del 100%, pero se puede
conseguir para versiones futuras.
62
El sistema está enfocado a empresas que no tienen capital suficiente como para
adquirir un software de primera calidad con soporte por parte de la empresa y con
actualizaciones periódicas. Ponemos al alcance de las PYMES un sistema sencillo de
utilizar, predictivo y fiable para informatizar aún más sus organizaciones y poder hacer
uso de las nuevas tecnologías, aunque no puedan permitirse el lujo de comprar las
costosas licencias de los productos existentes ahora mismo en el mercado.
63
9. BIBLIOGRAFÍA
[CONT09] Contreras Bárcena, David. “Apuntes de Ingeniería del Software II de Ingeniería
Superior en Informática”. Universidad Pontificia Comillas de Madrid. Madrid 2009.
[MUÑO10] Muñóz García, Manuel. “Apuntes de Gestión de Proyectos Informáticos de
Ingeniería Superior en Informática”. Universidad Pontificia Comillas de Madrid. Madrid 2010.
[WWW01] Actualidad TIC. OCR. http://www.iti.es/media/about/docs/tic/02/2003-11-ocr.pdf
[WWW02] Google. www.google.es
[WWW03] Wikipedia. www.wikipedia.es
[WWW04] JNA wrapper for Tesseract OCR. www.tess4j.org
[WWW05]Quantyca Contamatica. http://www.quantyca.com/main/contamatica-100-
overview.html
[WWW06]Pixelware Sofware. http://www.pixelware.com/
[WWW07]Neoscan Software. http://www.neoscan.es/
[WWW08]Eclipse Windowbuilder. http://www.eclipse.org/windowbuilder/
[WWW09]Finereader Online OCR. ABBY.
http://finereader.abbyyonline.com/en/Help/WhatIsOCR
[WWW10]Resumenes PFC. IIT. Universidad Pontificia Comillas.
http://www.iit.upcomillas.es/pfc/resumenes/4c80a8886c773.pdf
[WWW11] Estudio de las tecnologías en las empresas españolas. Ministerio de Industria,
Turismo y Comercio.
http://www.osimga.org/export/sites/osimga/gl/documentos/d/20110905_ontsi_pemes_2011.
[WWW12] What is JAVA. http://www.java.com/en/about/
[WWW13] Eclipse Home Page. http://www.eclipse.org/org/
[WWW14] Ejemplos memoria PFC. Universidad Pontificia Comillas.
http://www.labcom.upcomillas.es/pfc/docs/EjemploMemoria.pdf
[WWW15]Java examples. MySQL. http://www.chuidiang.com/java/mysql/EjemploJava.php
[WWW16]Java Examples. http://todojava.awardspace.com/ejemplos-java.html
[WWW17]SimpleOCR’s Web Page. http://www.simpleocr.com/
64
[WWW18] Google Docs OCR. Google.http://googlesystem.blogspot.com.es/2009/09/google-
docs-ocr.html
[WWW19] Tesseract OCR. Google. http://code.google.com/p/tesseract-ocr/
[WWW20] Jmagick OCR.
http://sourceforge.net/apps/mediawiki/jmagick/index.php?title=Main_Page
[WWW21] Installing Jmagick OCR.
http://sourceforge.net/apps/mediawiki/jmagick/index.php?title=Installing_JMagick
[WWW22] Metodología de Desarrollo de Software. Wikipedia.
http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
[WWW23] OCR en matrículas de automóviles. http://webs.uvigo.es/gpi-
rv/ficheros/pub/reports/cap2.pdf
[WWW24] UML Software. Gliffy. http://www.gliffy.com/uses/uml-software/
[WWW25] Java Examples. JDBC. http://www.devdaily.com/java/edu/pj/jdbc/jdbc0002
[WWW26] Java Examples. MySQL. RoseIndia. http://www.roseindia.net/jdbc/jdbc-
mysql/SetDate.shtml
[WWW27] Diagramas de Flujo Online.Techadictos. http://techadictos.com/crear-diagramas-
de-flujo-online/
[WWW28]ABBY OCR SDK Examples.
https://github.com/abbyysdk/ocrsdk.com/blob/master/Java/Abbyy.Ocrsdk.client/src/TestApp.
java
[WWW29]ABBY OCR Forum. http://forum.ocrsdk.com/
[WWW30]ABBY OCR Developers. http://www.abbyy-developers.com/en:onlineocrsdk:start
65
ANEXO A
Manual de Usuario
SISTEMA INTELIGENTE DE INTERPRETACIÓN
DE FACTURAS
Autor: Carlos Bernabeu Juan
Director: Juan Antonio Pérez-Campanero Anastasio
Madrid
Junio 2012
66
67
Introducción
El Sistema Inteligente de Interpretación de Facturas es una herramienta software
diseñada para agilizar el proceso de digitalización de la información contenida en las
facturas. Éste proceso se basa en la tecnología OCR que, combinada con técnicas de
procesamiento de los datos obtenidos, permiten que el sistema sea fiable y eficiente.
En este manual se explicarán cada una de las opciones del sistema así como todas sus
posibles formas de utilización.
68
69
Elementos en la pantalla principal
Una vez que ejecutamos la aplicación se muestra la siguiente pantalla principal
Figura 31: Pantalla de Inicio
La aplicación muestra dos zonas claramente diferenciadas, una será la zona de carga y
previsualización de la factura a procesar, y la otra será la zona de trabajo, donde se
muestran los datos obtenidos por el OCR, se da la posibilidad de modificar datos por si
hay erratas, y se da la opción de guardar la factura en formato digital.
70
Si analizamos con más detalle cada una de las zonas observamos que en la zona de la
previsualización de la factura también hay más elementos.
Figura 32: Zona de previsualización de la factura
En la zona donde se encuentra el 1 observamos un mensaje de bienvenida, en esa zona
se previsualizarán las facturas más adelante y ahí se seleccionarán las zonas
importantes de la factura (Esqueleto).
En la zona marcada con el 2 observamos una zona de texto, en ella se muestran los
mensajes de progreso de la aplicación, así como las acciones llevadas a cabo por el
usuario.
En la parte superior de la imagen se encuentra el 3. En la zona 3 está el panel de
creación de esqueletos, por medio del cual podremos seleccionar las zonas
importantes de la imagen.
71
Seguimos analizando elementos y observamos que la zona de procesamiento de los
datos también tiene varios elementos.
Figura 33: Zona de proceso
La zona marcada con el número 1 es la zona más importante del sistema, contiene la
funcionalidad del sistema resumida en cuatro botones, de ésta manera se simplifica la
forma de uso del sistema.
La zona marcada con el 2 contiene los datos básicos que se van a procesar de la
factura, serán editables cuando estemos corrigiendo posibles errores de
procesamiento.
La zona 3 es la de comentarios de la factura, en esta zona se podrá añadir todo tipo de
notas para futuros procesamientos o para aclarar cuestiones relacionadas con la
factura.
72
73
Carga de una factura
La carga de facturas en el sistema es el primer paso para el procesamiento de la
factura.
Pinchamos en el botón “Seleccionar Factura”
Y aparece un cuadro de diálogo por medio del cual cargamos la factura.
Figura 34: Cuadro de diálogo para la selección de la factura
74
Una vez seleccionada la factura pinchamos en abrir y la factura, si tiene un formato
válido, se cargará en el sistema y aparecerá en la zona de previsualización.
Figura 35: Factura en la zona de previsualización
75
Sección de Creación de un Esqueleto
Automáticamente después de cargar la factura, el sistema muestra otro cuadro de
diálogo preguntando si la factura pertenece a un proveedor que aún no tiene un
esqueleto asignado o si pertenece a uno con el que ya se ha trabajado antes.
Figura 36: Cuadro de diálogo para entrar en la creación de un esqueleto
En caso de seleccionar la opción “Sí”, entraremos en la sección de creación de
esqueletos.
76
Figura 37: Sección de creación de un esqueleto
Cuando entramos en la creación de esqueletos, automáticamente se activan los
botones que están en el panel de creación de un esqueleto.
Un esqueleto va a constar de 7 partes o zonas importantes, Número de Factura, Fecha,
Receptor, CIF/NIF, Base, Impuesto y Total.
77
Para poder seleccionar cada una de estas áreas, se selecciona el área a definir en el
combobox de áreas.
Figura 38: Campos clave de la factura
Acto seguido se sitúa el cursor en la zona que se desea seleccionar y se pincha y
arrastra.
Figura 39: Selección de una zona importante en la factura
La zona seleccionada aparecerá en rojo, en caso de estar seguro de que esa es la zona
que se quería seleccionar, se pincha en guardar para guardar esa porción del
esqueleto.
Es muy importante que se seleccione con precisión el área importante, debido a que
en futuros procesamientos, la tasa de aciertos dependerá de lo preciso que sea el
esqueleto de esa factura.
78
Tras repetir éste paso con los 7 elementos importantes de la factura, se debe
introducir un nombre para ese proveedor.
Una vez introducido el nombre, se pincha en “Finalizar” para guardar el esqueleto en
base de datos. Una vez finalizada la creación del esqueleto, se activa la opción de pasar
el OCR.
Figura 40: Botón de pasar OCR activado
79
OCR
A la zona de procesamiento por medio de OCR se puede llegar de dos formas, o bien
cargando una factura y creando su esqueleto o bien cargando una factura y
seleccionando un esqueleto ya existente de un proveedor ya existente.
Figura 41: Cuadro de diálogo para la creación de un esqueleto
Cuando cargamos la factura, si seleccionamos la opción “No”, podremos acceder a la
sección de procesamiento OCR eligiendo el emisor de la factura, (proveedor), de la
base de datos de proveedores.
Figura 42: Selección del emisor de la factura
80
Una vez seleccionado el proveedor, el sistema automáticamente carga el esqueleto
asociado a ese proveedor y muestra las zonas importantes en la imagen de la factura a
procesar.
Figura 43: Esqueleto del emisor seleccionado
En este momento el sistema ya está capacitado para pasar el OCR, con lo cual
pinchamos en el botón “Pasar OCR”.
81
Tras esperar unos segundos a que el OCR procese la factura, se nos muestran los
resultados en la zona de recuperación de datos y se habilita el botón de corrección de
datos.
Figura 44: Datos devueltos por el OCR
82
83
Corrección de Datos
En caso de que en OCR no acierte, hay una opción que se habilita tras pasar el OCR, la
de corregir los datos.
Tras pasar el OCR pinchamos en el botón “Corregir Datos”
Tras seleccionar corregir datos, la aplicación permite que se editen los datos
recuperados por el OCR y habilita el botón de “Guardar”.
Figura 45: Datos en disposición de ser modificados
En caso de ser necesaria la corrección de datos basta con situarse en la caja de texto
del dato erróneo y modificarlo. También se pueden añadir comentarios.
84
Figura 46: Datos corregidos y listos para ser guardados
85
Guardar en memoria la factura
Una vez que hemos corregido los datos y hemos añadido los comentarios, podemos
guardar la factura en formato digital en memoria. Para ello pincharemos en el botón
“Guardar”, que guardará los datos de esa factura en base de datos.
Como durante todo el proceso, las acciones llevadas a cabo por el usuario quedarán
reflejadas en la zona de mensajes de la aplicación.
Figura 47: Área de mensajes de la aplicación mostrando información del guardado en base de
datos
