universidad de guayaquil facultad de …repositorio.ug.edu.ec/bitstream/redug/28351/1/b-cisc-ptg....
TRANSCRIPT
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
ANÁLISIS Y DESARROLLO DE UN SISTEMA DE GESTOR Y RECEPTOR DE
COMPROBANTES ELECTRÓNICOS UTILIZANDO LAS NORMAS DE SEGURIDAD DE
ENCRIPTACIÓN DE LOS DATOS CON CIFRADO ASIMÉTRICO, PARA LA EMPRESA
“FIXED S.A”
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR(ES):
CARLOS JOSE CEDEÑO ARELLANO
CARLOS EDUARDO SOLORZANO ZAVALA
TUTOR:
ING. JOSÉ ALONSO ANGUIZACA, M. SC.
GUAYAQUIL – ECUADOR
2018
II
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS
TÍTULO: “ANÁLISIS Y DESARROLLO DE UN SISTEMA DE GESTOR Y RECEPTOR DE
COMPROBANTES ELECTRÓNICOS UTILIZANDO LAS NORMAS DE SEGURIDAD DE
ENCRIPTACIÓN DE LOS DATOS CON CIFRADO ASIMÉTRICO, PARA LA EMPRESA FIXED S.A”
AUTOR(ES): Carlos José Cedeño Arellano
Carlos Eduardo Solorzano Zavala REVISORES: Ing. Cristian Tomalá Mazzini
INSTITUCIÓN: Universidad de Guayaquil FACULTAD: Ciencias Matemáticas y Físicas
CARRERA: Ingeniería en Sistemas Computacionales.
FECHA DE PUBLICACIÓN: 2018 Ni DE PÁGS.: 137
ÁREA TEMÁTICA: Tecnología y sistemas
PALABRAS CLAVES: Metodología ágil, Visual Studio, Sistema Gestor y Receptor, Desarrollo, Ayuda
al medo ambiente.
RESUMEN: Hoy en día un gran número de empresas emiten facturas electrónicamente, la entidad
regulatoria de impuestos gubernamentales decretó que todas las empresas que son contribuyentes
especiales emitieran comprobantes electrónicos desde el 01/01/2015, con el objetivo de cuidar el medio
ambiente y poder reducir la evasión de impuesto. El sistema de gestor y receptor de comprobantes
electrónicos contará con dos principales funcionalidades que lo destaca y lo hace diferente del software
del mercado. En la actualidad los comprobantes electrónicos son emitidos mediante una cuenta de
correo a un cliente o proveedor que termina en un documento físico archivado para su historial, aquí ya
se perdió el enfoque que tenía el proyecto de facturación electrónica, cuidar del medio ambiente. El
sistema de gestor y receptor de comprobantes electrónicos evitará la necesidad de descargar el
comprobante electrónico e imprimirlo para que este no termine en un documento físico archivado. El
sistema leerá una cuenta de correo que se configure en el software, una vez que lea e identifique los
correo con comprobantes adjuntos con extensión XML, los convertirá en binario para almacenarlos en la
base de datos, así la empresa tendrá su información a la mano de manera digital ahorrando costos de
suministros de oficina.
N° DE REGISTRO (en base de datos): N° DE CLASIFICACIÓN:
DIRECCIÓN URL (tesis en la web):
ADJUNTO PDF: SI NO
CONTACTO CON AUTOR: Carlos José Cedeño Arellano Carlos Eduardo Solórzano Zavala
Teléfono: 0969718419 0993353726
E-mail: [email protected] [email protected]
CONTACTO DE LA INSTITUCIÓN Nombre: Carrera de Ingeniería en Sistemas Computacionales
Teléfono:
III
APROBACIÓN DEL TUTOR
En mi calidad de Tutor(a) del trabajo de titulación, “ANÁLISIS Y DESARROLLO DE UN
SISTEMA DE GESTOR Y RECEPTOR DE COMPROBANTES ELECTRÓNICOS
UTILIZANDO LAS NORMAS DE SEGURIDAD DE ENCRIPTACIÓN DE LOS DATOS
CON CIFRADO ASIMÉTRICO, PARA LA EMPRESA FIXED S.A”, elaborado por el Sr.
Carlos José Cedeño Arellano y el Sr. Carlos Eduardo Solorzano Zavala titulados de la
Carrera de Ingeniería en Sistemas Computacionales, Facultad de Ciencias Matemáticas y
Físicas de la Universidad de Guayaquil, previo a la obtención del Título de Ingeniero en
Sistemas, me permito declarar que luego de haber orientado, estudiado y revisado, la
Apruebo en todas sus partes.
Atentamente
José Alonzo Anguizaca, M. Sc.
TUTOR
IV
DEDICATORIA
Este presente trabajo se lo dedico a mis
padres, y en memoria a mi madre que
siempre fue una mujer luchadora, que
desde el suelo se sabía levantar sin tener el
apoyo de nadie. Ese ejemplo de lucho lo
llevo en mi porque ella me lo enseño
Carlos José Cedeño Arellano.
V
AGRADECIMIENTO
Agradezco primeramente a Dios por verme
encaminado hacia el camino del bien y
darme la sabiduría necesaria que me fue
posible llegar hasta aquí. También
agradezco a mis padres por su ejemplo de
lucha y ver incluido ética y morales en mi
vida. Un agradecimiento a mi esposa por
estar siempre brindarme su apoyo.
Carlos José Cedeño Arellano.
VI
DEDICATORIA
Este presente trabajo se lo dedico a mis
padres, por siempre estar conmigo
apoyándome y guiándome con la sabiduría
necesaria para no flaquear ante los
fracasos a lo largo de mi vida, por sus
concejos e influencia positiva para que siga
siempre adelante. A cada una de las
personas que me apoyaron a lo largo de la
carrera, por brindarme la confianza y creer
en mí, por esa unión de esfuerzos y
perseverancia para alcanzar la meta
anhelada.
Carlos Eduardo Solorzano Zavala.
VII
AGRADECIMIENTO
Agradezco a mis padres por darme el
ejemplo de lucha ante cualquier adversidad
y ser perseverante para alcanzar las metas
propuestas, su fortaleza y dedicación fue
transmitida con éxito eh aquí el fruto de
cada una de sus enseñanzas. A cada
integrante de mi familia por compartir esta
vida maravillosa llena de enseñanzas, a la
Universidad de Guayaquil (UG), cada uno
de los docentes de la CISC que aportaron
con su enseñanza para obtener el
conocimiento necesario que permitieron ser
cada día mejor en el ámbito profesional y
personal.
Carlos Eduardo Solorzano Zavala.
VIII
TRUBUNAL PROYECTO DE TITULACIÓN
_______________________________
Ing. Eduardo Santos Baquerizo M Sc
DECANO DE LA FACULTAD
CIENCIAS MATEMÁTICAS Y FÍSICAS
________________________________
Ing. Abel Alarcón Salvatierra, M gs.
DIRECTOR DE LA CARRERA DE
INGENIERÍA EN SISTEMAS
COMPUTACIONALES
__________________________________
Ing. Cristian Tomalá Mazzini.
PROFESOR REVISOR DEL AREA
TRIBUNAL
_________________________________________________
Ing. Fernando Castro Aguilar
PROFESOR REVISOR DEL AREA
TRIBUNAL
___________________________________
Ing. José Alonso Anguizaca.
PROFESOR REVISOR TUTOR DEL
PROYECTO
DE TITULACIÓN
_____________________________________
Ab. Juan Chávez Atocha, Esp.
SECRETARIO
IX
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este proyecto de titulación,
me corresponde exclusivamente; y el patrimonio intelectual de
la misma a la UNIVERSIDAD DE GUAYAQUIL”
CARLOS JOSE CEDEÑO ARELLANO
CARLOS EDUARDO SOLORZANO ZAVALA
X
ABREVIATURAS
RRA Reglamento de Régimen Académico.
UG Universidad de Guayaquil.
CISC Carrera de Ingeniería en Sistemas Computacionales.
FTP Archivos de Transferencia.
IDE Entornos de desarrollo integrado.
SRI Servicio de Rentas Internas.
LINQ Language Integrated Query.
MVC Modelo Vista Controlador
SQL Structured Query Language
SMTP Simple Mail Protocol
MD5 Message digests 5.
PMBOX Project Management Body of Knowledge
XML Extensible Markup Language
XI
ÍNDICE GENERAL
PROYECTO DE TITULACIÓN .................................................................................... I
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA .............................. II
APROBACIÓN DEL TUTOR ...................................................................................... III
DEDICATORIA ............................................................................................................. IV
AGRADECIMIENTO ..................................................................................................... V
DEDICATORIA ............................................................................................................. VI
AGRADECIMIENTO .................................................................................................. VII
DECLARACIÓN EXPRESA ........................................................................................ IX
ÍNDICE GENERAL ....................................................................................................... XI
ÍNDICE DE GRAFICOS ........................................................................................... XIV
ÍNDICE DE TABLAS .................................................................................................. XV
RESUMEN ................................................................................................................. XVI
ABSTRACT .............................................................................................................. XVII
Capítulo 1 ........................................................................................................................ 1
Introducción ..................................................................................................................... 1
1.1. Antecedentes ................................................................................................. 2
1.2. El problema ......................................................................................................... 5
1.2. Objetivos......................................................................................................... 6
1.3.1. Objetivo General. ............................................................................................ 6
1.3.2. Objetivos específicos. .................................................................................... 6
1.5. Contexto y marco teórico .................................................................................. 8
1.5.1. El propósito del estudio. ................................................................................. 8
1.5.2. El significado del estudio. .............................................................................. 8
1.6.1. Presunciones del autor del estudio .............................................................. 8
1.6.2. Plan de calidad ................................................................................................ 9
XII
1.6.3. Restricciones y alcance ............................................................................... 12
1.6.4. Metodología ................................................................................................... 13
Capítulo 2 ...................................................................................................................... 17
2.1. Antecedente del estudio .................................................................................. 17
2.2. Fundamentación teórica .................................................................................. 17
2.2.1. ¿Qué es un proyecto? .................................................................................. 17
2.2.2. Ciclo de vida de un proyecto ....................................................................... 17
2.2.3 Metodología .................................................................................................... 20
2.2.4. Clasificación de las metodologías según el grado de formalismo. ....... 21
2.2.5. ¿Qué es el manifiesto ágil? ......................................................................... 22
2.2.6. ¿Cómo se debe aplicar una metodología ágil?........................................ 23
2.2.7. Los datos y su encriptación ......................................................................... 23
2.2.8. ¿Qué es Microsoft SQL Server? ................................................................ 24
2.2.9. ¿Qué es Visual Studio? ............................................................................... 25
2.2.10. ¿Qué es .NET Framework? ...................................................................... 28
2.2.11 Devexpress ................................................................................................... 29
2.2.12 Encriptación asimétrica ............................................................................... 30
2.2.13 Algoritmo Md5 .............................................................................................. 31
2.2.14 Linq “Language Integrated Query”. –........................................................ 32
2.2.15 Hilos. .............................................................................................................. 33
2.3. Fundamentación legal ..................................................................................... 36
2.3.1 Derecho de autoría. .................................................................................... 36
2.3.2 Medio ambiente. .......................................................................................... 36
2.3.3 Emisión de comprobantes electrónicos. ..................................................... 36
2.3.4 Código Orgánico Integral Penal (http://www.justicia.gob.ec, 2014) ....... 44
2.3.5 Hipótesis .......................................................................................................... 47
Capítulo 3 ...................................................................................................................... 48
XIII
Propuesta tecnológica ................................................................................................. 48
3.1. Análisis de factibilidad: .................................................................................... 48
3.1.1. Factibilidad operacional ............................................................................... 49
3.1.2. Factibilidad técnica ....................................................................................... 60
3.1.3 Factibilidad legal ............................................................................................. 72
3.1.4 Factibilidad económica .................................................................................. 73
3.1.5 Etapas de la metodología del proyecto ...................................................... 74
3.1.6 Entregables del proyecto .............................................................................. 75
Capítulo 4 ...................................................................................................................... 80
4.1 Criterios de aceptación del producto o Servicio ........................................ 80
Técnica de recolección de datos ........................................................................... 80
4.2 Conclusiones ................................................................................................... 96
4.3 Recomendaciones .......................................................................................... 97
4.4 Anexos ................................................................................................................ 98
4.4.1 Formato XML Factura .................................................................................... 98
4.2.2 Formato XML comprobante de retención ................................................. 102
4.2.3 Formato XML guía de remisión .................................................................. 105
4.2.4 Formato XML nota crédito .......................................................................... 106
4.2.5 Formato XML nota debito ........................................................................... 111
4.5 Encuesta relacionada al Sistema gestor y receptor de comprobantes
electrónicos .................................................................................................................. 113
Bibliografía .................................................................................................................. 116
XIV
ÍNDICE DE GRAFICOS
figura 1. pruebas de usuarios .................................................................................... 11 figura 2. casos de prueba .......................................................................................... 11 figura 3. metodologias ............................................................................................... 14 figura 4. ciclo de vida del software ............................................................................. 18 figura 5. metodologias agil ......................................................................................... 22 figura 6. plataforma de onewindows ......................................................................... 28 figura 7. encriptacion asimetrica ................................................................................ 31 figura 8. algoritmo md5. ............................................................................................. 31 figura 9. proceso de hilos .......................................................................................... 34 figura 10. diseñador de reporte .................................................................................. 35 figura 11. recepcion de comprobantes ....................................................................... 50 figura 12. comprobantes validos ................................................................................ 50 figura 13. comprobantes sin respuestas del sri .......................................................... 51 figura 14. comprobantes autorizados y no autorizados .............................................. 51 figura 15. administrador de correo ............................................................................ 52 figura 16. configuración de cuenta de correo ............................................................. 52 figura 18. registro de emisor ...................................................................................... 53 figura 19. parametrizacion de ws y servidor proxy ..................................................... 54 figura 20. descarga de correos……………………………………………..………….……55 figura 21. sitio web inicio de sesion ........................................................................... 56 figura 22. cambio contraseña sitio web ...................................................................... 57 figura 23. página de inicio del portal web ………………………………………………..57 figura 24. descarga de comprobantes del portal web ................................................ 57 figura 25. ride ............................................................................................................ 59 figura 26. comunicacioes entre capas ....................................................................... 63 figura 27. diagrama entidad relacion.......................................................................... 65 figura 28. esquema offline ......................................................................................... 67 figura 29. codigo relevante ........................................................................................ 69 figura 30. metodologia del proyecto……………………………......................................74 figura 31. modulo de seguridad de acceso …………………….....................................76 figura32. Modulo de firma electronica ……………………..............................................77 figura 33. modulo de configuracion ………………….....................................................78 figura 34. Modulo de administrador de correo ……………………..................................79 figura 35. caso de uso acceso al sistema .................................................................. 81 figura 36. caso de uso creación de usuarios .............................................................. 82 figura 37. caso uso de los procesos de facturación electrónica. ................................ 83 figura 38. caso de uso para configuracion de cuenta de correo. ................................ 84 figura 39. caso de uso para para registrar y modificar emisor ................................... 85 figura 40. caso de uso configuración de parámetros web service .............................. 86 figura 41. caso de uso modificar diseño de reporte “ride” .......................................... 87 figura 42. caso uso redactar correo ........................................................................... 88
XV
ÍNDICE DE TABLAS
tabla 1. requisitos ....................................................................................................... 17 tabla 2. licencias ......................................................................................................... 75
XVI
Universidad de Guayaquil
Facultad de Ciencias Matemáticas y Físicas
RESUMEN
TEMA: “ANÁLISIS Y DESARROLLO DE UN SISTEMA DE GESTOR Y
RECEPTOR DE COMPROBANTES ELECTRÓNICOS UTILIZANDO LAS
NORMAS DE SEGURIDAD DE ENCRIPTACIÓN DE LOS DATOS CON
CIFRADO ASIMÉTRICO, PARA LA EMPRESA FIXED S.A”
Hoy en día un gran número de empresas emiten facturas electrónicamente, la
entidad regulatoria de impuestos gubernamentales decretó que todas las
empresas que son contribuyentes especiales emitieran comprobantes
electrónicos desde el 01/01/2015, con el objetivo de cuidar el medio ambiente y
poder reducir la evasión de impuesto. El sistema de gestor y receptor de
comprobantes electrónicos contará con dos principales funcionalidades que lo
destaca y lo hace diferente del software del mercado. En la actualidad los
comprobantes electrónicos son emitidos mediante una cuenta de correo a un
cliente o proveedor que termina en un documento físico archivado para su historial,
aquí ya se perdió el enfoque que tenía el proyecto de facturación electrónica,
cuidar del medio ambiente. El sistema de gestor y receptor de comprobantes
electrónicos evitará la necesidad de descargar el comprobante electrónico e
imprimirlo para que este no termine en un documento físico archivado. El sistema
leerá una cuenta de correo que se configure en el software, una vez que lea e
identifique los correo con comprobantes adjuntos con extensión XML, los
convertirá en binario para almacenarlos en la base de datos, así la empresa tendrá
su información a la mano de manera digital ahorrando costos de suministros de
oficina.
Palabras clave: Metodología ágil, Visual Studio, Sistema Gestor y Receptor,
Desarrollo, Ayuda al medo ambiente.
XVII
ABSTRACT
THEME: "ANALYSIS AND DEVELOPMENT OF A MANAGEMENT SYSTEM AND
ELECTRONIC RECEIPT RECEIVER USING THE SECURITY RULES OF
ENCRYPTION OF THE DATA WITH ASYMMETRIC ENCRYPTION, FOR THE
COMPANY FIXED S.A"
Today a large number of companies issue invoices electronically, the government
tax regulatory entity decree that all companies that are special taxpayers issue
electronic receipts from 01/01/2015, with the aim of taking care of the environment
and can reduce tax evasion. The system of electronic voucher manager and
receiver will have two main functionalities that make it stand out and makes it
different from the market software. At present, electronic receipts are issued
through an email account to a customer or supplier that ends up in a physical
document filed for their history, here the focus of the electronic invoicing project
was already lost, taking care of the environment. The electronic voucher manager
and receiver system will avoid the need to download the electronic voucher and
print it so that it does not end up in an archived physical document. The system
will read an email account that is configured in the software, once it reads and
identifies the emails with attached vouchers with XML extension, it will convert
them into binary to store them in the database, so the company will have its
information at hand digitally saving office supplies costs.
Key words: agile Methodology, Visual Studio, manager and receiver System,
Development, help the environment.
1
Capítulo 1
Introducción
La presente propuesta es para el desarrollo de un sistema gestor y receptor de
comprobantes electrónicos para cumplir con las leyes tributarias impuestas por el
gobierno central. Todas las entidades o personas obligadas a llevar contabilidad
deben emitir comprobantes electrónicos, el software no solo ayudará a la empresa
FIXED S.A a cumplir con las leyes, también ayudará en ahorro de suministros de
oficinas y tener la información a la mano.
Este sistema es importante para los procesos de facturación de la empresa FIXED
S.A, aportará a la empresa en los lineamientos del negocio poniendo en práctica
las reglas impuestas por entidades controladoras del estado, el tener un sistema
de gestor y receptor de comprobantes electrónicos también ayudará en el prestigio
de la compañía, siendo FIXED S.A. una empresa de servicios de tecnologías
informáticas y relativamente nueva en el mercado, se exige contar con la
información de manera inmediata.
Este proyecto se enfocará en demostrar que la tecnología es un pilar importante
para el crecimiento de cualquier empresa, atomizando costos y procesos que les
pueda ayudar a emprender en nuevas áreas y poder competir en el mercado.
Muchas entidades hoy en día ven al área de informática como un gasto, inclusos
migrando toda su infraestructura a servidores a la nube para poder desligarse del
gasto de servidores de mantenimiento o de renovación, así como el costo de los
administradores del centro de cómputo.
Si existe un centro de datos en una compañía LTDA y este no tiene una misión y
visión enfocada a la misión y visión de la compañía realmente no será rentable
para esta. La empresa FIXED S.A, no cuenta con un centro de datos, pero cada
software o aplicativo que desarrolle o adquiera deberá apoyar a la misión y visión
2
de la compañía. El sistema gestor de comprobantes electrónicos ayudará a la
compañía en sus estrategias de fidelidad de cliente, enviándoles las facturas a sus
clientes de manera inmediata y con respuesta a la mano en caso de ser extraviado
algún documento por parte del cliente.
1.1. Antecedentes
La empresa FIXED S.A. es una empresa constituida el 15 de agosto del 2017;
que ofrece servicios de infraestructuras informáticas. Buscando el emprendimiento
en nuevos mercados de la informática, existen muchas empresas de servicios
informáticos, la gran mayoría de esta se enfoca en una sola sublíneas de la
informática. FIXED S.A., quiere atacar al nicho de mercado de empresas que
carecen de una asesoría informática.
Desde su constitución la empresa está en busca de clientes e incrustarse en el
mercado para llegar a ser una empresa líder en infraestructuras informáticas, la
empresa cuenta con cuatros accionista en la actualidad y cada uno de ellos
cumplen rol importante en la empresa
La empresa tiene proyectado para finales del 2020 tener una cartera de entre 50
y 100 clientes, la empresa está en proceso de capacitación de dos de los ERP
más robusto de Latinoamérica como son SAP y Dinamice AX, para ofrecer a sus
clientes un servicio completo de asesoría informática e infraestructura.
Los cuatros accionista son profesionales en la rama de sistemas informáticos y
cada uno con un gran potencial de conocimiento de mercado del área de la
informática, cada uno de ellos ha trabajado en empresas grandes y en
crecimientos, las experiencias de su trayectoria laboral los hace personas ricas en
conocimientos que los llevará al crecimiento.
El aplicativo nació en base a las necesidades que tienen muchas empresas en
la entrega y recepción de comprobantes electrónicos y que han podido palpar lo
dificultoso que resulta contar con esta información a tiempo.
3
¿Qué es Certificado de Firma Electrónica?
Es un documento digital mediante el cual la entidad certificadora, asegura la
vinculación entre la entidad del usuario, su clave pública y privada.
¿Qué contiene un certificado digital?
Entidad de la empresa certificadora.
Los datos del titular de la firma digital.
Fecha de emisión y fecha de vencimiento del certificado.
La serie o número único que identifica el certificado.
Clave pública del titular del certificado.
¿Qué garantiza la firma electrónica?
Autenticidad: información del documento y la firma le correspondiente
únicamente al titular de la firma.
Integridad: El contenido del mensaje o documento no ha sido modificada
después de la firma.
No repudio: El titular de la firma electrónica no podrá negar dicho documento
o mensajes firmados.
Confidencialidad: la información contenida ha sido cifrada y solo el emisor
puede autorizar que el receptor la des encripte.
Módulos del sistema
El sistema gestor y receptor de comprobantes electrónicos, contará con los
siguientes módulos:
1. Seguridad de Acceso. - El módulo de seguridad de acceso es muy
importante, ya que en este se crearán las opciones del sistema, así como
también los roles por empresa y por usuarios, y el mantenimiento de usuarios.
2. Firma electrónica. – En dicho módulo se encontrarán las opciones de los
procesos para la firma de los comprobantes, que estarán fundamentados en
cuatros pasos importantes para la firma de los documentos, estos pasos son
consecutivos es decir el paso siguiente depende del anterior.
4
Paso 1 documentos en repositorios. – en esta opción se mostrarán todos los
archivos que han sido depositados en el repositorio del sistema y que aún no han
sido validados.
Paso 2 documentos válidos y pendientes de enviar y firmar. – Esta opción del
sistema nos permitirá visualizar todos los documentos que fueron depositados en
el repositorio de recepción de comprobantes del sistema y que cumplieron con la
estructura exigida por el SRI.
Paso 3 documentos enviados y sin respuesta del SRI. – En esta opción se
mostrarán los archivos que cumplieron el paso uno y que no han tenido respuesta
del SRI.
Paso 4 documentos autorizados/ no autorizados. – En esta opción se
mostrarán los archivos que cumplieron los pasos uno, dos, tres. En esta opción
los comprobantes electrónicos tienen dos estados posibles autorizados o no
autorizados.
3. Administrador de correos electrónicos
Este módulo nos permitirá administrar los correos electrónicos enviados y
recibidos de las cuentas respectivas configuradas en el sistema. Se podrá redactar
un correo, así como enviar comprobantes electrónicos por email de forma masiva
a los clientes cuando se emite una factura.
4. Configuraciones
En este módulo se configurará los parámetros del sistema, los parámetros del
sistema pueden ser de dos tipos:
Parámetros generales, son parámetros generales del sistema, un ejemplo de un
parámetro global del sistema es donde se configuran las direcciones de los webs
services del SRI, este tipo de parámetros no son por empresas, porque los web
services que se consumirán desde el sistema son globales.
5
Parámetros por empresa, son parámetros exclusivos por empresa, ya que el
sistema es multiempresa cada empresa se maneja de manera independiente,
pueden existir grupos empresariales y el sistema debe soportar la configuración
individual. Uno de los parámetros por empresa que podemos hacer mención es la
cuenta de correo que se emitirán y receptarán comprobantes electrónicos.
Página web, el sistema contara con una página web para la consulta y descarga
de los comprobantes electrónicos. Los contribuyentes podrán acceder y bajar los
documentos en los formatos XML y .pdf, siendo estos:
XML, es el documento autorizado y firmado por la entidad regulatoria SRI. Este
documento no podrá modificar ni el contribuyente ni el emisor debido que dicho
documento ya fue autorizado.
PDF, el documento con extensión .pdf representa a una factura física y es un
documento autorizado, ya que este contiene una firma electrónica que lo hace
valido en la parte legal o tributaria.
Como se mencionó en el párrafo anterior los contribuyentes podrán hacer uso de
la página web, bajo esta primicia la página web contara con un cubo de
información gerencial para medir el nivel de facturación, donde jugarán tres
variables importantes como:
Tiempo
Valor
Contribuyente
1.2. El problema
Con la necesidad de que las pequeñas y medianas empresas, deben emitir
comprobantes electrónicos a partir del 01/01/2018, mediante reforma a la
Resolución NAC-DGERCGC15-f00000745-B publicada el pasado octubre del
2015, el SRI amplió el plazo por dos años para que los contribuyentes se acojan
a este procedimiento de pre autorización de la emisión de comprobantes.
6
Muchas de estas empresas cuentan con sistemas heredados, es decir difícil de
escalar, por ende, desarrollar un módulo de facturación electrónica en estos
sistemas podría ser muy costoso.
Adicionalmente el cliente facilita a sus proveedores una cuenta de correo. Para la
recepción de comprobantes electrónicos, muchas de estas cuentas reciben
grandes cantidades de correos no deseados o spam, por lo que genera dificultad
para localizar los correos de los proveedores, no existe un sistema de receptor de
comprobantes electrónicos, para que estos sean almacenados en una base local
del cliente y pueda ser consultada la información con tan solo dar un clic y no tener
que estar buscando el o los comprobantes en la cuenta de correo o en el montón
de factura archivadas.
1.2. Objetivos
1.3.1. Objetivo General.
Analizar y desarrollar un sistema gestor y receptor de comprobantes
electrónicos utilizando las normas de seguridad de encriptación de los datos
con cifrado asimétrico, para la empresa FIXED S.A.
1.3.2. Objetivos específicos.
Contribuir con el medio ambiente almacenando los comprobantes
electrónicos de manera digital.
Ahorrar tiempo en la busca de documentos.
Reducir espacio físico por almacenamiento de comprobantes.
Ahorrar costos de desarrollo sobre el módulo de facturación electrónica.
Tener información disponible de los comprobantes electrónicos.
Enviar un correo electrónico cuando un comprobante no ha sido autorizado, a
una cuenta previamente configurada.
7
1.4. Justificación
Los sistemas heredados o sistemas contables de muchas empresas solo se
limitarían a generar los XML, el sistema de gestor y receptor de comprobantes
electrónicos se encargará de hacer todo el proceso de la firma y envió de los
comprobantes, también se encargará de leer la cuenta de correo para capturar los
XML enviados por los proveedores, para almacenar dichos documentos de forma
binaria en la base de datos, esto dará lugar a:
Tener la información a la mano con tan solo dar clic.
Fomentar a la digitalización de documento.
Contribuir con el cuidado del medio ambiente.
Se encriptará la información almacenada en la base de datos, los campos que se
consideren necesarios en el análisis. Usando cifrado asimétrico con el algoritmo
MD5 (message digest 5). Para obtener una mayor seguridad en el sistema y
resguardar la información se encriptarán los datos que puedan revelar o poner en
riesgo la información del sistema.
El sistema de gestor y receptor de comprobantes electrónicos necesitara de un
archivo. p12 o de un token, para el proceso de la firma digital sin uno de los dos
elementos antes mencionado el sistema no podrá funcionar, en otras palabras,
son requisitos indispensables para el funcionamiento del proyecto.
Los archivos .p12, son archivos de tecnología de firma digital que nos permite
firmar documentos electrónicos.
El token, es un dispositivo electrónico USB, los cuales tiene la característica de
almacenar contraseñas y certificados digitales, además permiten llevar la
identidad digital de la persona. Este dispositivo tiene una validez de vida útil de
diez años.
8
1.5. Contexto y marco teórico
1.5.1. El propósito del estudio.
Demostrar que la tecnología es una herramienta versátil e útil en las empresas de
crecimiento y en las que se encuentra madura en el mercado, con el sistema
gestor y receptor de comprobantes electrónico se busca evidenciar que si las
empresas usan la tecnología pueden dar un gran aporte al cuidado del medio
ambiente, y adicionalmente tienen grandes beneficios como el ahorrar costo,
ahorrar suministros de oficinas.
Se busca que la herramienta sea amigable al usuario, y fácil de entender para que
el usuario no necesite de una capacitación profunda para utilizar la herramienta
de manera adecuada.
1.5.2. El significado del estudio.
Este gestor y receptor de comprobantes electrónicos se diferencia de otros
productos del mercado, en muchas características, no necesita de programación
adicional para integrarse con otros sistemas, recibe un archivo estándar realiza
los procesos necesarios para enviar a autorizar dicho documento, reducir la
impresión de documentos.
El tener un sistema independiente que realice procesos nuevos, que tal vez
implementarlos en sistemas heredados son complejos y podría llevar mucho
tiempo, incluso entorpecer procesos ya funcionales de los sistemas. Con este tipo
de software sea una mejor opción de no tener el inconveniente de desarrollar
submódulos en sistemas antiguos.
1.6. Metodología de desarrollo
1.6.1. Presunciones del autor del estudio
Se presume lo siguiente:
El personal de FIXED S.A, probará el software en la fase de pruebas de
usuarios.
9
El sistema gestor y receptor de comprobantes electrónicos será un software
amigable
El docente tutor dará los mejores lineamientos para que el software tenga una
ingeniería de software adecuada para que el software tenga un alcance y
limitaciones.
Las buenas prácticas de programación y las herramientas harán del software
un sistema rápido.
1.6.2. Plan de calidad
Pruebas de desarrollo. – se realizarán pruebas durante el desarrollo del
software, en cada uno de los procesos los desarrolladores asumirán los errores
comunes de los usuarios inexpertos que se podrían dar al usar la herramienta, y
validar que el sistema pueda detectar la entrada de datos. Las pruebas de
desarrollo son las primeras que se realizan en el desarrollo del sistema, mencionar
estas pruebas tal vez suene innecesario muchas veces los desarrolladores no
realizan las pruebas mínimas, cuando se pasa el sistema a las pruebas de calidad
en el primer intento suelen hacer caer al software.
Pruebas de calidad. Este tipo de pruebas las realiza un departamento aislado del
departamento de desarrollo, en las empresas de desarrollo bien estructuras estos
dos departamentos son muy aisladas, no debería estar el departamento de
desarrollo junto al departamento de calidad, se suelen crear grupos de amigos que
busquen conveniencias y dejar pasar bugs del sistema.
El área de calidad se debe caracterizar por ser un área totalmente estricta, deben
realizar todas las pruebas posibles, utilizando las llamadas cajas negras y cajas
blancas.
El departamento de calidad debe tener equipos que figuren un ambiente de
producción, para que la prueba sea muy cercana o similar al ambiente de
producción.
Cuando el departamento de calidad apruebe el software o el aplicativo este debe
firmar un documento donde declara que el sistema ha sido probado, evidenciando
10
las entradas y salidas de datos. Y que este está apto para ser pasados a las
pruebas finales las conocidas pruebas de usuarios a las que haremos mención
más adelante.
Pruebas de usuarios. Las pruebas de usuarios son las pruebas finales del
software donde los usuarios o los dueños de procesos, ejecutarán en el sistema
sus tareas rutinarias de trabajos o procesos, el sistema debe permitir el ingreso
de datos necesarios para arrojar informes coherentes.
En estas fases de los proyectos de software suelen haber concordancia donde el
usuario o los dueños de procesos no siempre describen o dan toda la información
necesaria para desarrollar los procesos, esto se da cuando existen usuarios
resistente al cambio, la metodología ágil que se usará en este estudios minimizara
la probabilidad que se den este tipo de inconvenientes, ya que cada pantalla del
sistema se debe hacer una acta donde el usuario firma que ha entregado toda la
información necesaria.
En esta metodología se le muestra al usuario la pantalla de ingresos de datos o
de proceso para que este la apruebe y proceder con el desarrollo, es de muy
importancia pedir los reportes por pantalla o por procesos para saber que debe
arrojar el sistema.
11
Figura 1. PRUEBAS DE USUARIOS
Fuente: Datos de la investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
Figura 2. CASOS DE PRUEBA
Fuente: Datos de la investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
12
Pruebas de estrés. - las pruebas de estrés se basan en realizar peticiones a la
base de datos o realizando grandes tipos de transacciones simulando el trabajo
de muchos usuarios en el sistema. La ventaja de realizar las pruebas de estrés es
probar al sistema en su punto máximo para agotar la posibilidad de que el sistema
no se caiga en su máxima funcionalidad. Para realizar este tipo de pruebas se
necesita de tener una muestra o una media de las transacciones o usuarios
trabajando en el sistema. Es necesario recalcar, que cuando se aplican estas
pruebas se debe revisar el alcance del sistema. Si en el alcance dice que el
sistema soporta como máximo 100 usuarios conectados, las pruebas no pueden
pasar este límite.
1.6.3. Restricciones y alcance
El sistema gestor y receptor de comprobantes electrónicos es un sistema que
como todo sistema tiene un alcance y limitaciones, las cuales se detallarán a
continuación.
Restricciones.
Necesita un sistema operativo Windows.
Las versiones de Windows debe ser Windows 7 o superior.
Los equipos donde correrá el sistema debe ser Core i3 o superior con un
mínimo de dos GB de RAM.
Si el SRI cambia la estructura de uno de los documentos el sistema dejará de
funcionar, es decir es un sistema dependiente.
Necesita de un certificado o token con fecha de vencimiento no menor a la
fecha actual.
Alcance.
El sistema trabajará con las versiones de los documentos emitidas hasta la
actualidad por el SRI que son 1.0.0 y 1.1.1.
El sistema solo firmara los siguientes documentos:
Factura
Nota crédito
13
Nota débito
Guía remisión
Retenciones
1.6.4. Metodología
Esta metodología de programación fue implementada a mediado de la década de
los 90. Debido a las falencias de la metodología orientada a documentación, la
metodología orientada a documentación se basa en levantar la información y
posteriormente a documentar estos procesos, para luego continuar con el
desarrollo.
Esta metodología puede llevar al fracaso a un proyecto de software si este desde
el inicio del proyecto se realiza mal el levantamiento de información y
posteriormente se documentará mal y obviamente todo el desarrollo estará mal.
La metodología ágil se caracteriza por ser una herramienta que disminuye el
fracaso de un proyecto de software en las variables más importantes, en este tipo
de proyectos que son Tiempo y Costo. La metodología ágil se basa en realizar la
documentación al final de los procesos, es decir se procede con los mismos pasos
de la metodología orientada a documentación.
A diferencia que en cada proceso se realizan entregables pequeños desde los
diseños de pantallas. Donde el usuario o los dueños de procesos confirman que
los procesos diseñados o ya programados automatizan los procesos manuales o
los mejoran. Así cuando se tenga que entregar todo el proyecto, los submódulos
o procesos estarán probados por los usuarios y la posibilidad que el proyecto sea
rechazado por los patrocinadores del proyecto sea muy pequeña.
A continuación, se detalla cada uno de los procesos de amabas metodología
descrita en la figura.
14
Figura 3. METODOLOGIAS
Fuente: Datos de la investigación
Elaborado: Carlos Cedeño y Carlos Solorzano
Planteamiento. - En esta fase del proyecto las metodologías no inciden
ningún cambio entre ellas, ya que en esta etapa del proyecto se está
planteando una necesidad y relativamente no se involucra ningún tipo de
ingeniería de software o algo relacionado con gestión de proyecto de
software. En el planteamiento se expone una problemática o una
necesidad que necesita ser atendida, es necesario recalcar que la etapa
en mención no necesariamente es utiliza en proyecto de software, en
proyecto de cualquier índole siempre existirá este punto inicial.
Análisis tradicional (“Metodología pesada”). - En esta fase del proyecto
si nos basamos en la metodología tradicional o denominada pesada, una
vez planteada la necesidad o la problemática se procede a realizar el
análisis del problema dando como resultado un informe de viabilidad del
proyecto. En la metodología ágil también se realiza el análisis de viabilidad
del proyecto si el informe de viabilidad del proyecto du resultado es indica
que el proyecto es viable, se procederá a priorizar los requisitos que estos
pueden ser numerados de la siguiente forma:
Tabla 1. REQUISITOS
15
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
En la tabla se muestra como pueden ser priorizados los requisitos expuesto en la
etapa del análisis, la priorización de estos requisitos dependerá de muchos
factores y del proyecto que se lleve a cabo.
Como podemos apreciar en la figura las 7, la metodología tradicional es lineal,
esto quiere decir que una etapa depende de la otra. Detallaremos a continuación
las etapas de diseño, desarrollo y pruebas.
Es fácil apreciar que hay un gran cambio entre la metodología pesada y la
metodología ágil en estas tres etapas. En la metodología pesada la etapa de
diseño se basa en la etapa de análisis y juntamente con la documentación de los
procesos para diseñar el sistema, los subsistemas o un proceso.
Una vez culminada la etapa de diseño se procede con la etapa del desarrollo del
sistema, por lo general esta es la etapa más larga en la línea del tiempo del
desarrollo del proyecto, si nos detenemos a analizar y nos hacemos estas
preguntas de muchas que nos pueden surgir en esta etapa.
¿Se está utilizando la metodología adecuada?
¿Se hizo una buena ingeniería de requerimientos?
¿Los procesos están bien diseñados?
N.º Puntuación Priorización
1 1 Alta
2 2 Media
3 3 Baja
16
Si estas tres de tantas preguntas que podrían surgir, resulta que una de ellas es
falsa la probabilidad que el proyecto se desfase en la línea del tiempo y su costo
se dispare, y la probabilidad de que el proyecto fracase es muy alto.
En la figura 7 en la metodología ágil se puede observar que se hace una iteración
entre las tres etapas diseña, desarrolla, prueba, esto conlleva a que el proyecto
tenga un margen de error de fracaso muy pequeño. Basándose a iteraciones
directamente con los usuarios o dueños de procesos y probando el desarrollo se
podría saber si los procesos están correctos. A diferencia de la metodología
pesada que al final del proyecto en la fase de pruebas podría saber si los procesos
están correctos.
17
Capítulo 2
2.1. Antecedente del estudio
Se realizó el respectivo análisis del proyecto y las conclusiones en la que se
determinó, que no existe un sistema gestor y receptor de comprobantes
electrónicos que coincidan con el tema expuesto. Sin lugar a duda existen muchos
sistemas de firma electrónica en el mercado no tiene una seguridad incluida y
muchos menos apoyan a cuidar el medio ambiente y enfocarse a la visión de toda
empresa que es la fidelidad al cliente.
2.2. Fundamentación teórica
2.2.1. ¿Qué es un proyecto?
Es un esfuerzo temporal que realiza una persona o un grupo de personas, por lo
general un proyecto tiende a solucionar una problemática o de innovación. Se dice
que un proyecto es un esfuerzo temporal porque un proyecto siempre tiene un
inicio y un fin ya siendo el fin satisfactorio o por abordar el proyecto.
2.2.2. Ciclo de vida de un proyecto
Los ciclos de vida de un proyecto son las fases o etapas de este definidas en
tiempos y actividades involucradas. Las fases de un proyecto son casi siempre
secuenciales, y por ende siempre la primera fase es el pilar fundamental del
proyecto en base a la primera fase se basarán las etapas siguientes, los proyectos
de software son como cuando se quieren construir un rascacielos, que si no tienes
bien las bases principal a medida de que crezca el rascacielos este podría
desplomarse echando a perder toda la infraestructura, de igual manera un
proyecto de software de realizarse un buen levantamiento de información que por
lo general es siempre la primera etapa en los proyectos de software. Si esta etapa
está mal constituida todas las demás etapas estarán mal.
A continuación, se mencionarán las etapas más comunes utilizadas en proyectos
de software que son: levantamiento de información, análisis, diseño, desarrollo,
pruebas, implementación, seguimiento.
18
Figura 4. CICLO DE VIDA DEL SOFTWARE
Fuente: Datos de la investigación
Elaborado: Carlos Cedeño y Carlos Solorzano
Necesidades. - en esta fase denominada necesidades, o requerimiento es la
etapa inicial de todo proyecto, es una etapa de las cuales se le suele prestar
menos atención, pero realmente para los ingenieros de software esta etapa es una
de las más importante ya que de aquí se derivan las demás etapas, si no hubiese
necesidades no se pudiera realizar un análisis de viabilidad, desde la etapa de
análisis en adelante estas son dependiente de una etapa sucesora.
Si en esta etapa los requerimientos son ambiguo, o inalcanzable es probable que
en la etapa de Análisis de como resultado que el proyecto no es viable.
Cada etapa juega un papel importante en el proyecto, donde cada una de esta se
enfoca o se encasilla en la línea del tiempo del cronograma del proyecto, sus
19
actividades y tareas no pueden ejecutarse por lo general en las etapas sucesora
o antecesora.
Análisis. – Es la etapa donde se define la fiabilidad del proyecto, cada uno de los
requerimientos son estudiados y priorizados, también se escurrían su
funcionabilidad. En esta fase del proyecto se define si el proyecto debe continuar,
aquí se analizan varias variables administrativas y de interés para los
patrocinadores del software e interesados, en la guía de gestión de proyectos
“PMBOX”, hace énfasis que el sistema o los sistemas deben estar alineados a la
visión y misión de la entidad. Los patrocinadores del proyecto se harán las
preguntas como:
¿Qué beneficios darán a la compañía?
¿El costo del proyecto está en los presupuestos de la compañía?
Diseño. – es la etapa donde se diseñará, la estructura del proyecto, diseño de
base de datos, arquitectura, flujograma de procesos, diseño de front end, etc.
Cuando forme el equipo de trabajo para el desarrollo del software dependerá de
los recursos de quien auspicie el proyecto se recomienda que para cada etapa
exista un especialista enfocado en el tema del área, en este caso la etapa en
mención se necesitaría un arquitecto de software, que estudiaría la arquitectura y
diseño del mismo, y dependerá mucho del Análisis que se haya definido en la
etapa anterior.
Codificación. – También denominada etapa de desarrollo en esta fase
intervienen los analista de sistemas o jefe de desarrollo y programadores, estos
ya reciben el proyecto macro desglosados en tareas y actividades, los
participantes de esta etapa por lo general no saben la cobertura del proyecto
muchas veces llegan a entender un subprograma o módulo, es el ingeniero de
software que mira y mide el proyecto de manera macro como un rompecabezas
que se distribuye en subsistemas, módulos, procesos, actividades y tareas.
Pruebas. – En el desarrollo de un software existen cuatros tipos de pruebas, cada
una de estas buscan encontrar bugs del sistema o falencia, ya sea por malas
prácticas de programación, validaciones, o procesos mal definidos. En la sesión
20
1.6.2. se hará mención más a detalle de las pruebas de software. Aquí
mencionamos las pruebas de desarrollo de software:
Pruebas de desarrollo.
Pruebas de calidad.
Pruebas de usuarios.
Pruebas de estrés.
Validaciones. – esta fase puede variar depende del gerente de proyecto, en esta
etapa se pueden llamar como validaciones al funcionamiento integral del sistema,
la integración entre módulos y procesos, se suele usar un método para realizar
estas validaciones que se le denomina paralelo, en la cual los usuarios trabajan
en los dos sistemas simultáneamente en caso de ser éste remplazando un
software. Se compararán los resultados arrojados por las dos aplicaciones, si la
implementación es totalmente nueva se trabajará en el sistema y los usuarios
finales validarán la información arrojada por el software.
Mantenimiento y evolución. – Cuando las etapas de validaciones han sido
satisfactorias, se procede a firmar el acta de entrega por parte proveedores si el
proyecto fue tercerizado, de aquí en adelante se suele llegar a un acuerdo entre
el patrocinador del proyecto y la empresa desarrolladora, haciendo un contrato de
soporte para suplir las necesidades de los usuarios o pulir los bugs del sistema en
caso de ser encontrados.
2.2.3 Metodología
Definiremos la metodología como aquella disciplina que indicará qué métodos y
técnicas hay que usar en cada fase del ciclo de vida de desarrollo del proyecto”
(Gallego, 2014).
La metodología nos permite llevar un proyecto de software de manera ordenada,
aplicando las mejores prácticas y lineamientos, la metodología nos ayuda a cuidar
y a disminuir las posibilidades de que un proyecto se desfase en el tiempo y si
21
esto ocurre el proyecto se presupuestará y el riesgo que el proyecto sea abordado
por falta de recursos es muy alta.
2.2.4. Clasificación de las metodologías según el grado de formalismo.
Metodología pesada
“Son las metodologías clásicas, los métodos de trabajo son muy formales.
Conlleva realizar una gran carga de trabajo de gestión y generar una gran cantidad
de documentación.” (Gallego, 2014)
Los estudios basados en esta metodología se basaban en documentar todo el
proyecto al inicio, basándose en la documentación de los procesos que fueron
estudiados en la ingeniería de requerimiento. En esta metodología se asume que
la etapa de ingeniería de requerimiento todos los procesos serán levantados
correctamente y que todas las posibilidades que tengan un proceso serán
tomadas en cuenta.
En la vida real esto no funciona así, generalmente cuando se está en la etapa de
ingeniería de requerimiento los usuarios resistentes al cambio o por celos de
perder su empleo estos no describen los procesos correctamente lo que conlleva
al fracaso del proyecto. Sin lugar a duda esta metodología es obsoleta y no es la
mejor opción para que un proyecto sea satisfactorio.
Metodología ágil
“Son las últimas en aparecer y se basan en dar respuestas a los problemas con
los que se encuentran las metodologías tradicionales. Usan el concepto de
adaptación a los requisitos que no se conocen en lugar de predicción.” (Gallego,
2014).
Como se mencionó en el ítem anterior las metodologías pesadas son muy
cerradas a cambios y por ende el índice de probabilidad de que los procesos estén
mal planteados son muy grandes. Basándose en esas falencias de la metodología
pesada surgió la metodología ágil, que no es más que una iteración directamente
22
con el usuario o con el dueño del proceso desde el inicio de hasta la finalización
del proyecto.
La metodología ágil se base en un espiral cerrada, así de esta forma se comienza
desde el levantamiento de información y posteriormente con el diseño del software
o pantalla y se mostrará a los usuarios o dueños de procesos para su aceptación,
si el usuario está de acuerdo se procederá con la programación, después de esto
nuevamente se reunirá con el usuario para mostrar el proceso y ejecutar ejercicios
reales donde el sistema tomará los datos de entradas y los procesará obteniendo
como resultados la salida de datos que será evaluada por los usuarios.
Figura 5. METODOLOGIAS AGIL
Fuente: Datos de la Investigación
Elaborado: Carlos Cedeño y Carlos Solorzano
2.2.5. ¿Qué es el manifiesto ágil?
“En marzo de 2001, se reunieron 17 profesionales de software. […] Los integrantes
de esta reunión resumieron en cuatro postulados lo que ha quedado denominado
23
como Manifiesto Ágil, que son los valores sobre los que se asientan las
metodologías ágiles.” (Menzinsky, López, & Palacio, 2016)
Es conocido como la norma establecida en marzo del 2001 por un grupo de
profesionales de ingeniería de software.
2.2.6. ¿Cómo se debe aplicar una metodología ágil?
“Se debe analizar el proyecto en concreto y ver cuál de todas las metodologías
existentes sería la más adecuada a su proyecto. Y si ninguna le satisface
plenamente, debería de ser capaz de adaptarlas.” (Fernández, 2014)
Las empresas de desarrollo de software de Ecuador por lo generalmente están
acostumbrados a utilizar la misma metodología para todos los proyectos y no
existe un estudio de por medio para calificar la metodología que más se apegue a
la problemática. El tomar en cuenta la metodología a usar en nuestro proyecto es
un buen principio y más que un principio debe ser una regla para que los proyectos
de software no se desfasen por la línea del tiempo.
2.2.7. Los datos y su encriptación
Los datos es un problema antiguo, que se vienen acarreando desde el inicio de la
era de las computadoras, en la primera generación de las computadoras cuando
se usaban tarjetas perforadas por la década de los 60, aun no existía el término
de bases de datos. Al inicio de la era del software informático estos solos
realizaban operaciones en memorias, no existía la facilidad de guardar el histórico,
después de estos aparecen los archivos planos que permiten guardar información
actuando en aquel tiempo como una opción de almacenamientos de datos
procesados por software informáticos.
Los archivos planos fue una solución temporal para los pasos agigantados que
daba la informática, los archivos .bat o .txt, etc. No fueron de gran ayuda a la
problemática de los datos.
La primera vez que se ha escuchado el término base de datos fue en 1963, desde
aquel tiempo el término base de datos es muy común y ha tomado tanta
importancia que hoy en día es una rama de la informática. Con la aparición de las
24
bases de datos que no permiten almacenar grandes cantidades de datos, no
quiere decir que los datos no sigan siendo un problema en el mundo de la
informática.
En el siglo XII aún se carece del problema de los datos, este estudio no está
enfocado a los datos, pero es necesario hacer referencia a estos, ya que hoy en
día los datos es lo más importantes para las empresas, si vulneran su seguridad
informática para secuestrarle los datos y pedir recompensa por su información o
para venderla a la competencia. Esto es tan grave que podría mandar a la ruina a
cualquier entidad.
Los datos están expuestas muchas veces a la red de redes que estos podrían ser
capturados alterados, y así violando la confidencialidad de los datos. De aquí el
problema de la seguridad de los datos que están expuesto a hacker de sombrero
negro siendo personas con muchos conocimientos informáticos que le dan un mal
uso a la información como, venderla, alterarla, o secuestrarla para pedir grandes
sumas de dinero.
Muchas empresas aplican hoy en día una seguridad doble se le podría llamar,
aplicando la seguridad en la red como son las MZ, pero si esta fuera vialidad se
opta por tener encriptada la base de datos. Ya que si un hacker ingresa a la red o
tiene acceso a los datos éste tendría que realizar otro trabajo forzoso para robar
la información que es la desencriptación de los datos.
2.2.8. ¿Qué es Microsoft SQL Server?
“Microsoft® SQL Server™ es un sistema de administración y análisis de bases de
datos relacionales de Microsoft para soluciones de comercio electrónico, línea de
negocio y almacenamiento de datos.” (Microsoft, 2017)
SQL Server es una de las tantas herramientas que nos permite almacenar y
manipular grandes cantidades de datos, SQL es una herramienta de Microsoft y
este producto se adquiere bajo licencia y por usuarios. Sin embargo, Microsoft
tiene una versión gratuita que es SQL Express la cual se utilizará para almacenar
los datos procesados por el gestor y receptor de comprobantes electrónicos.
25
2.2.9. ¿Qué es Visual Studio?
En su página oficial, Microsoft (2017) lo define así:
Visual Studio es un conjunto completo de herramientas de desarrollo para la
generación de aplicaciones web ASP.NET, Servicios Web XML, aplicaciones de
escritorio y aplicaciones móviles. Visual Basic, Visual C# y Visual C++ utilizan
todos los mismos entornos de desarrollo integrado (IDE), que habilita el uso
compartido de herramientas y facilita la creación de soluciones en varios
lenguajes. Asimismo, dichos lenguajes utilizan las funciones de .NET Framework,
las cuales ofrecen acceso a tecnologías clave para simplificar el desarrollo de
aplicaciones web ASP y Servicios Web XML.
Visual estudio tiene una gama de lenguaje de programación como son C#, C++,
etc., cada uno de estos lenguajes nos permite crear más de un tipo de aplicación
desde un sistema de escritorio hasta una aplicación Android, nuestro estudio
estará desarrollado en C# desktop.
Su historia. – El paquete de lenguaje de desarrollo de visual studio incorpora más
de una plataforma para el desarrollo de diversas aplicaciones. Sus versiones
destacadas que influyeron en mundo de la programación y que a medida del paso
del tiempo estas fueron siéndose más robusta y tomando mercado en el mundo
de la informática.
Visual Studio 6.0 esta versión fue lanzada en el año 1998, se dice que esta
versión fue el indicio de la base para el desarrollo de Microsoft durante los
siguientes 4 años. En la cual la industria de software Microsoft puso sus
miradas a la plataforma .net Framework, hoy en día este IDE de programación
de Microsoft es una herramienta versátil y muy acogedora.
Visual Studio .net 2002.- Ya para esta época Microsoft había rompido el
paradigma de y produjo un cambio sustancial y poniendo sus miradas en la
plataforma .net de Microsoft .net, los programas o aplicaciones desarrolladas
en esta versión ya no se compilaban en lenguaje de maquina si no en un
lenguaje intermedio. (CIL – Common Intermediate Language).
26
Con la aparición de esta versión se da el indicio del lenguaje c# hoy en día un
potente lenguaje de desarrollo, en el cual se desarrolló mi trabajo de tesis de
grado. El desarrollo de c# se basó en los pilares de c++ y java.
Visual Studio .net 2003.- Sin lugar a duda la corporación Microsoft su trabajo
e evolución ha sido muy continuo, al cabo del año lanza esta nueva versión
con más de una edición, es decir más de un lenguaje de programación lo que
se podría denominar un paquete de lenguaje de desarrollo los cuales fueron:
Academic, Professional, Enterprise Developer y Enterprise Architect.
Visual Studio .net 2005.- En el año 2005 aparece una nueva versión
mejorada y más robusta la cual se publicó por la internet a mediado del mes
de octubre del 2005 esta versión únicamente estaba en inglés. Esta versión se
mantuvo en ingles durante los dos primeros años, hasta que ha mediado del
año 2006 aparece la versión en español.
La versión lanzada en el año 2005 trae consigo muchas mejoras que le dieron
mayor credibilidad y crecimiento al producto, uno de los cambios más radicales
es la compilación para procesadores de 64 y 86 bits.
Microsoft en el año 2005 también lanza una versión exprés para principiantes
y pequeñas empresas que se encontraba totalmente gratuita en la página de
Microsoft incluyendo una edición independiente por cada lenguaje de
desarrollo.
Visual Studio .net 2008.- Se lanza al mercado una nueva versión
incorporando también otra versión de .net framework (.NET 3.5), consigo
también viene de la mano una nueva versión de S.O llama Windows Vista y
sus subsistemas Windows Communication Foundation (WCF) y Windows
Presentation Foundation (WPF). El WCF es una herramienta dedicada a los
servicios, mientras que WPF se orienta a los lenguajes tradicionales de las
versiones anteriores, pero con mejoras.
Visual Studio .net 2010.- Es una de las versiones más recientes y en su
conjunto se incluye el .net Framework 4.0, la versión de Visual Studio se lanzó
27
a mediado del año 2010. Esta actualización o nueva versión de Visual Studio
trae varias ediciones, según la necesidad las cuales la mencionamos a
continuación:
o Visual Studio 2010 Ultimate.
o Visual Studio 2010 Premium.
o Visual Studio 2010 Professional.
o Visual Studio Team Foundation Server 2010.
o Visual Studio Test Professional 2010.
o Visual Studio Team Explorer Everywhere 2010.
Visual Studio .net 2012.- La nueva versión de Visual Studio fue lanzada en
el año 2012, la cual incluye diversas herramientas para el desarrollo de
aplicaciones de varios índoles. También cuenta con una versión gratuita y
versiones trial.
Permitiendo el desarrollo nativo para las plataformas que este soporta.
El procesador de código soporta IntelliSense fue mejorado siendo en esta
versión más rápido que el anterior ayudando de manera directa al
programador.
Visual Studio .net 2013.- Se podría decir que el equipo de Microsoft trabajo
casi que de manera paralela entre las versiones 2012 y 2013, es necesario
destacar que la nueva versión 2013 aún mantiene embebida se podría decir
las herramientas de desarrollo de la versión 2012. Aquí hago mención los
principales cambios o los más destacados de la versión 2013 vs versión 2012:
o Selector de tema e IDE conectada
o Mejoras a los temas de color
Visual Studio .net 2015.- esta versión es una de las más estables e utilizadas
actualmente en la cual se han incorporado una serie de mejoras de entorno y
de ayuda para el programador, una de las mejoras que en lo personal me
parece muy interesante es que podemos ver los objetos o variables en que
parte del proyecto o programa están siendo utilizada.
28
Una de las funcionalidades es que no permite medir los recursos consumidos
por un proceso en la máquina, así como también medir el rendimiento de la
misma. Sin duda esta versión trae cosas muy interesantes que le ayudan a ser
la vida más fácil al programador. Otros de los cambios notorios en esta versión
que me llama la atención es la auto creación de código como crear plantillas y
hasta realizar procesos de manera automáticos a partir de una entidad.
Figura 6. Plataforma de OneWindows
Fuente www.microsoft.com
Elaborado por: Carlos Cedeño y Carlos Solorzano
Visual Studio .net 2017.- Ya Windows lanzo la versión 2017, la cual tiene
iteración con sistemas operativos MAC, de esta manera Microsoft quiere romper
las cadenas que sus herramientas de desarrollo corran en sistemas Windows.
2.2.10. ¿Qué es .NET Framework?
En el libro La biblia de C# encontramos la siguiente definición:
.NET Framework se compone de cuatro partes […]: el entorno común de
ejecución, un conjunto de bibliotecas de clases, un grupo de lenguajes de
programación y el entorno ASP.NET. .NET Framework fue diseñado con tres
29
objetivos en mente. Primero, debía simplificar el desarrollo de aplicaciones y
servicios Web que no solo funcionen en plataformas tradicionales, sino también
en dispositivos móviles. Por último. El entorno fue diseñado para proporcionar un
solo grupo de bibliotecas que pudieran trabajar con varios lenguajes. (Fergurson,
Patterson, Beres, Boutquin, & Gupta, 2003)
Net Framework es la plataforma de desarrollo de código administrado de Microsoft
está formada por una serie de herramientas y librerías con la que puede crear todo
tipo de aplicaciones, desde escritorio hasta Android.
Está compuesto por un conjunto de tecnologías que forman parte importante de
la plataforma .net el net Framework constituye una infraestructura de
programación para contribuir distribuir y ejecutar aplicaciones y servicios para la
plataforma .net, el net Framework soporta completamente las características de
.net
El IDE de programación .net Framework ha venido evolucionando conforme ha
venido desarrollándose las versiones de visual studio, este framework es el pilar
fundamental de las plataformas de desarrollo de visual estudios. Ha evolucionado
de manera muy acelerada conforme a los requerimientos de las tecnologías.
La Biblioteca de Clases Base se clasifica, en tres grupos clave:
ASP.NET y Servicios Web XML
Windows Forms
ADO.NET
2.2.11 Devexpress
“Devexpress es una de las más completas suites de componentes de UI para el
desarrollo en todas las plataformas de .NET como Windows Forms, ASP.NET,
MVC, Silverlight y Windows 8 XAML.” (Samaniego García, 2017)
Devexpress, es un Framework para ciertos lenguajes de programación de visual
estudio como C#, Asp, Visual Basic etc., es una herramienta versátil, con muchos
componentes dinámicos, como gráficos, reportes, tanto como para herramientas
web como para desktop. Este framework ayuda a los programadores haciendo la
programación más fácil.
30
Su historia. – Devexpress sale al mercado en el año de 1998 y su origen fue
Glendale, California, en su inicio comenzó a diseñar controles para Interfax de
usuarios para las siguientes herramientas de programación: Borland Delphi / C ++
Builder y ActiveX Controls para Microsoft Visual Studio.
Ventajas.
Cuenta con controles para la mayoría de las herramientas de Microsoft.
Contiene más de 70 controles, la cual nos permite diseñar y desarrollar
potentes herramientas.
En la creación de sus controles es semi – automática, donde la herramienta
se encarga de escribir la mayoría de la codificación, como eventos
funciones etc. Que son fácil de usar y de poca complejidad.
El método para llenar sus controles es sumamente sencillo, así como
recoger la información de sus controles es de fácil acceso.
Sus componentes para el desarrollo web son responsive al 100%
Sus componentes cuentan con temas propios.
Desventajas.
Sus controles están enfocados únicamente para plataforma Windows
Requiere licencia
2.2.12 Encriptación asimétrica
La encriptación asimétrica se basa en dos claves públicas y privada que se pueden
difundir sin ninguna dificultad a toda información que necesite ser transmitida
encriptada, si se necesita recibir información encriptada debemos darle nuestra
clave pública al receptor que nos enviara la información, así podemos desencriptar
los datos encriptados.
Quizás parezca algo incoherente que al dar nuestra clave publica el emisor pueda
identificar nuestra clave privada, este tipo de criptografía usa algoritmos bastante
robustos.
31
Figura 7. ENCRIPTACION ASIMETRICA
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
2.2.13 Algoritmo Md5
Es un algoritmo de reducción criptográfica de 128 bits, fue inventado por Ronalf
Riverst en la década de los 90, en el año 2004 se le divulgaron algunas
debilidades. Este algoritmo comienza rellenando el mensaje a una longitud en
módulo 448 mod 512. Es la longitud del mensaje.
Figura 8. ALGORITMO MD5.
Fuente: Datos del a investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
32
Este algoritmo toma el mensaje original y se expande hasta alcanzar una longitud
de la cadena de 448 módulos 512 bits la longitud de la cadena, esta es dividida
sobre 512 y arrojara como resultado. Y posteriormente se añade a la cadena 64
bits a la cadena original, ahora tenemos como resultado un múltiplo de 512 bits,
los cuales salen de la suma del 448 + 64 bits.
Ventajas
Su codificación es de dominio público, y no se requiere ninguno pago para
tener adquirir una licencia.
Este algoritmo esta implementado casi en todos los lenguajes de desarrollo
Es veloz al momento de codificar y decodificar la cadena
Ventajas
Debido a su popularidad existen muchos foros para su vulnerabilidad
Ya se han descubiertos vulnerabilidades
2.2.14 Linq “Language Integrated Query”. –
Es una manera directa de acceder a los datos de una base de datos, este lenguaje
es nativo de .Net, donde se pueden ejecutar sentencias SQL, expresiones lamba,
etc. La diferencia de ADO y Linq, es que ADO actúa como un intermediario entre
el aplicativo y la base de datos, con Linq se omite este paso y se puede acceder
de manera directa a los datos consecuentemente tendremos respuestas más
rápidas en consultas y transacciones de datos.
Linq trabaja de la mano con el IDE de programación de Microsoft, como es de
nuestros conocimientos el .net framework es un protocolo de desarrollo para
herramientas de visual studio.
LINQ en C#
Aplicar Linq en la plataforma de desarrollo de C# es bastante sencillo, si
conocemos o hemos trabajados con sentencias ADO o con base de datos SQL
aprender de esta nueva técnica nos será muy fácil, ya que contiene funciones con
el mismo nombre y que realizan la misma acción.
33
Aquí doy un ejemplo de realizar una consulta de en LINQ, se debe empezar
declarando una variable de tipo var, y esta obtendrá los campos o datos
dependiendo de que me devuelva la consulta.
Operadores lamba
Las operaciones lambas no son más que un filtro o condiciones a una lista de
objetos que se encuentra en memoria del ordenador previamente ya cargada.
Las operaciones lambas se ejecutan por lado del cliente.
2.2.15 Hilos.
Un hilo es un proceso o tarea que se ejecuta de manera asíncrona, nos permite
ejecutar más de una tarea en un sistema, por lo general los hilos son útiles en
procesos que tardan en terminar su ejecución. Si no se utiliza hilos en procesos
largos el usuario tendría que esperar a que el proceso termine, para mandar a
ejecutar otra tarea en el sistema.
Un hilo puede tener más de un estado, a continuación, haremos mención de estos
y daremos una breve explicación de los estados de los hilos.
Creado. – Cuando un proceso está asociado a un hilo, y este es ejecutado se crea
un hilo. Después de ser creado el hilo este pasa al estado de ejecución este
34
permanece en este estado mientras el proceso asociado no ha culminado con su
tarea.
En ejecución. - llámese un hilo en ejecución cuando un proceso o procedimiento
ha sido invocado por medio del hilo y su tarea aún no ha finalizado. En una
máquina o programa pueden existir más de un hilo ejecutándose a la vez, sin
embargo, debemos tener cuidados cuando utilizamos hilos, no cabe duda de que
tienen grandes ventajas, pero, así como tienen ventajas consumen demasiados
recursos.
Parado. - llámese un hilo Parado cuando este fue ejecutado, y fue detenido por
un proceso o por una acción del usuario o está en la cola por ser atendido dicho
proceso por la CPU del ordenador.
Muerto. - un hilo puede ser muerto de dos maneras por causa natural o que maten
el proceso. Cuando un hilo pasa del estado en ejecución a muerto por manera
natural llámese así cuando el proceso culminó y se ejecutó la línea de stop para
el hilo.
Cuando un hilo muere de forma forzosa se podría decir que es cuando un hilo está
en ejecución y se mata el proceso de forma manual.
Figura 9. PROCESO DE HILOS
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
35
2.2.16 Diseñador de reporte. - Esta opción nos permite que el usuario final pueda
realizar ajuste en los reportes, es decir el sistema contará con la opción de poder
ejecutar el diseñador del reporte en tiempo de ejecución, para esto el diseño del
reporte se guardará en la base de datos en un campo de tipo Binario, el sistema
solo contará con los diseñadores de reportes de los siguientes comprobantes:
Factura.
Nota crédito.
Nota débito.
Guía remisión
Retención.
Si se requiere agregar o quitar una opción de uno de estos reportes que en los
términos de facturación electrónica se les denomina Ride solo bastará con hacer
un clik en el registro correspondiente para que el sistema ejecute el diseñador, y
previamente se proceda a realizar los cambios necesario y guardar los cambio.
Figura 10. diseñador de reporte
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
36
2.3. Fundamentación legal
2.3.1 Derecho de autoría.
La Universidad de Guayaquil tendrá el derecho de autoría sobre el trabajo
realizado para obtener el título de ingeniero en sistemas, el o los autores no
tendrán derecho del producto desarrollado o prototipo. De manera voluntaria
deben ceder sus derechos a la Universidad de Guayaquil, siendo esta la que tenga
la plena autoridad de modificar o distribuir dicho producto.
2.3.2 Medio ambiente.
El servicio de rentas internas en su proyecto de facturación electrónica busca
contribuir con el cuidado del medio ambiente. Mediante la reducción de usar
comprobantes tributarios impresos. Si hacemos conciencia las empresas o
personas naturales que reciben un comprobante electrónico. ¿Este se almacenará
de manera digital o física? Contestando a la pregunta la gran realidad es que
dichos comprobantes electrónicos son impresos y archivados en un folder.
2.3.3 Emisión de comprobantes electrónicos.
Las empresas y las personas naturales están obligadas a llevar contabilidad y
sujetas a emitir comprobantes electrónicos.
Base legal de comprobantes electrónicos SRI.
Resolución NAC-DGERCGC16-00000287. (SRI, http://www.sri.gob.ec, 2016)
El director General del Servicio de Rentas Internas (SRI).
Resuelve expedir definiciones para la emisión de comprobantes emitidos
por medios digitales o electrónicos de pago.
Artículo 1. Objeto. - Expedir definiciones para la emisión de “comprobantes de
pagos emitidos por medios digitales o electrónicos” generados en transacciones
realizadas a través de cuentas de dinero electrónico, tarjetas de crédito, débito y
prepago, emitidos por participantes del sistema de dinero electrónico, así como
por instituciones financieras y establecimientos emisores, según corresponda.
37
Dichos comprobantes servirán única y exclusivamente para sustentar el derecho
a la devolución o compensación del impulso al valor agregado (IVA) por uso de
medios electrónicos de pago en transacciones de bienes o servicios gravados con
IVA por consumo final, según lo previsto en la ley orgánica para el equilibrio de las
finanzas públicas.
Los “comprobantes de pagos emitidos por medios digitales o electrónicos”
deberán emitirse conjuntamente y de forma obligatoria con las respectivas
facturas, notas de venta u otros comprobantes de venta autorizados de
conformidad con el reglamento de comprobantes de Venta, Retención y
Documentos Complementarios.
Las transacciones que se realicen entre macroagentes y corresponsales
únicamente se sustentaran en “comprobantes de pagos emitidos por medios
digitales o electrónicos”.
Resolución NAC- DGERCGC14-00790. (SRI, http://www.sri.gob.ec, 2014)
Expedir las normas para la emisión y autorización de comprobantes de venta,
retención y documentos complementarios mediante comprobantes electrónicos.
Artículo 1.- Ámbito de aplicación. - Se autoriza, a los, sujetos pasivos la emisión
de comprobantes de venta, retención y documentos complementarios mediante la
modalidad de comprobantes electrónicos, conforme a las disposiciones señaladas
en la presente Resolución.
Artículo 2.- De la emisión. - Los sujetos pasivos de tributos podrán emitir como
comprobantes electrónicos, entre otros, los siguientes Comprobantes de venta,
retención y documentos complementarios:
Facturas
Comprobantes de Retención
Guías de Remisión
Notas de Crédito y
Notas de Débito.
Artículo 3.- Procedimiento. - Para la emisión de comprobantes electrónicos los
sujetos pasivos deberán cumplir lo siguiente:
38
1. Presentar su solicitud al Servicio 'de Rentas Internas en el formato
dispuesto para el efecto en la página web institucional www.sri.gob.ec. La
solicitud deberá ser presentada por vía electrónica a través de la aplicación
"Comprobantes Electrónicos", disponible en el sistema de "Servicios en
Línea ", que se encuentra en la referida página web institucional.
2. Para el efecto, previamente el contribuyente deberá, por única vez,
ingresar una solicitud de emisión bajo el aplicativo "Comprobantes
Electrónicos", en la opción, de "Pruebas". Aprobada la solicitud, se deberá
efectuar todos los ajustes necesarios en los sistemas computarizados e
informáticos para la emisión de comprobantes electrónicos de tal manera
que se garantice la calidad de la informaci6n enviada a la Administración
Tributaria conforme a la "Ficha Técnica" que se publique. Al tratarse de un
periodo de prueba, los comprobantes electrónicos emitidos bajo esta
opción, sin perjuicio de la autorización otorgada por el Servicio de Rentas
Internas, no tienen validez tributaria, y por tanto no sustentan costos y
gastos; ni crédito tributario.
3. Una vez que el contribuyente haya realizado todas las verificaciones dentro
del ambiente de "Pruebas", así como los ajustes necesarios señalados en
el numeral anteriores, ingresara su solicitud de emisión de comprobantes
electrónicos, en la opción "ambiente de producción". Los comprobantes.
emitidos bajo esta opción, tienen validez tributaria; sustentan costos,
gastos y credito4ributario, de conformidad con la ley. Es responsabilidad
del emisor garantizar al adquirente 'que el comprobante de venta, retención
y documentos complementarios emitido mediante la modalidad de
mensajes de datos cumple con todos los requisitos necesarios para su
validez. La aprobación otorgada por el Servicio de Rentas Internas
respecto de la solicitud de emisi6n de comprobantes electrónicos tendrá
vigencia indefinida.
4. Los comprobantes electrónicos deberán estar firmados electrónicamente
únicamente por él emisor, es su responsabilidad mantener vigente el
certificado de firma electrónica utilizado y además deberá observar lo
dispuesto en el artículo 17 de la Ley de Comercio Electrónico, Firmas
Electrónicas y Mensajes de Datos. Este certificado podrá extinguirse,
39
suspenderse o revocarse de acuerdo a lo establecido en la ley antes
mencionada y su Reglamento.
5. Los comprobantes electrónicos emitidos en el ambiente de "Pruebas", así
como en el ambiente de "Producción", deberán cumplir con los requisitos
de pre impresión y llenado, establecidas en el Reglamento de
Comprobantes de Venta, Retención y Documentos Complementarios y las
resoluciones que, se dicten para el efecto.
6. Los sujetos pasivos deberán estar a lo dispuesto en la "Ficha Técnica" así
como sujetarse a los requisitos adicionales de unicidad y especificaciones
detalladas en los archivos, "XML" y "XSD", que el Servicio de Rentas
Internas Publique en la página web institucional www.sri.gob.ec.
Artículo 4.- Del deber de informar las alternativas de emisión. - El emisor
deberá poner en conocimiento del usurario o consumidor la posibilidad de recibir
el comprobante de manera electrónica o impresa. Este constituye una
representación impresa del documento electrónico (RIDE).
Articulo 5.- Del consentimiento. - Los emisores de comprobantes electrónicos
deben contar con el Consentimiento del consumidor o usuario antes de la emisión
y envió del comprobante electrónico. Así misino, los emisores instruirán
satisfactoriamente al consumidor o unitario sobre la forma de acceder a la
información de dicho comprobante, los medios (portal web, correo electrónico,
entre otros.), los equipos y programas que requiere para ello.
Artículo 6.- De la impresión. - Siempre que se hubiese trasmitido a la
Administración Tributaria el comprobante electrónico, los emisores deberán
imprimir y entregar el RIDE en los siguientes casos:
a) Cuando no exista el 'consentimiento 'del usuario o consumidor para recibir, el
comprobante electrónico
b) Cuando la impresión sea requerida de manera expresa por el receptor, en el
momento de la emisión o después
c) Cuando en la compra no se identifique al consumidor o usuario (consumidor
final). La impresión de la representación del comprobante electrónico (RIDE)
tendrá igual validez que los comprobantes establecidos en el Reglamento de
40
Comprobantes de Venta, Retención y Documentos Complementarios y su
contenido podrá ser verificado con la información que reposa en la base de datos
de la Administración Tributaria.
Artículo 7.- Casos especiales. - Cuando por motivos de fuerza mayor no sea
posible generar un comprobante electrónico mediante comprobante electrónico,
el emisor podrá. Emitir un comprobante de venta, retención y documentos
complementarios bajo las otras formas de emisión conforme a los requisitos
establecidos en el Reglamento de Comprobantes de Venta, Retención y
Documentos Complementarios.
Articulo 8.- De la clave de acceso. - El emisor deberá proporcionar al consumidor
o usuario la "clave de acceso" de su, comprobante electrónico lo que servir para
comprobar en la página web del Servicio de Rentas Internas el estado del
comprobante electrónico.
Articulo 9.- De la trasmisión. - Los. sujetos pasivos, que emitan comprobantes
electrónicos deberán remitirlos a la Administración Tributaria en el momento
mismo de realizarse la transacción utilizando para ello los enlaces "web services"
dispuestos en la "Ficha Técnica". A través de este mecanismo se realizará él
envió, recepción, validación, autorización o rechazo de los comprobantes
electrónicos. Solamente en caso de que los sujetos pasivos, por la naturaleza de
su actividad económica, emitan comprobantes electrónicos masivamente, podrán
enviarlos al Servicio de Rentas Internas de forma conjunta o agrupada en las
condiciones señaladas en la "Ficha Técnica", dentro de un máximo de veinte y
cuatro horas de haberse realizado la transacción o generación del comprobante
electrónico.
Articulo 10.- De la unicidad.- Los comprobantes electrónicos llevaran, como
requisito obligatorio, una "cave de acceso" de carácter numérico que será
generada por el emisor. Esta cave, que se constituye en el número de autorización
del comprobante, será Única para cada documento.
41
Artículo 11.- Del estado. - Los comprobantes enviados a la Administración
tributaria para validación podrán pasar a los siguientes estados: "Autorizado" o
"No Autorizado", pidiendo ser consultados en el portal web institucional. Cuando
los sujetos pasivos emisores de comprobantes electrónicos conozcan que un
comprobante emitido se encuentre en estado "No Autorizado", estarán en la
obligación de hacer la entrega posterior a los receptores de los mencionados
comprobantes, una vez confirmado su estado "Autorizado" en máximo veinte y
cuatro horas.
Artículo 12- De la obligación de la entrega. - Los emisores tienen la obligación
de enviar o poner a disposición de los usuarios o consumidores el comprobante
electrónico en las condiciones, Oportunidad y medios establecidos en la presente
resolución. La omisión del envió, indisponibilidad o inaccesibilidad al comprobante
electrónico se constituye en no entrega. Cuando el consumidor o usuario no
proporcione al emisor la informaci6n necesaria para el acceso al comprobante
electrónico, tendrá que imprimir y entregar el RIDE.
Articulo 13.- De la consulta. - Los usuarios o consumidores deberán consultar,
en los medios que ponga a su disposición el Servicio de Rentas Internas, la validez
de los mencionados comprobantes electrónicos.
Articulo 14.- De la verificación. -El Servicio de Rentas Internas pondrá a
disposición de todos los sujetos pasivos, en su página web institucional "Servicios
en Línea", la herramienta de "Consulta Pública y Privada de Validez de
Comprobantes Electrónicos" en la cual se podrá verificar el estado del
comprobante electrónico. No se podrá aplicar crédito tributario o sustentar. -
costos y gastos con comprobantes electrónicos falsos o no autorizados.
La Administración Tributaria ofrece a los sujetos pasivos la opción de consulta en
detalle de los comprobantes electrónicos emitidos y/o recibidos en un determinado
periodo. Esta herramienta puede ser utilizada ingresando con la cave personal a
la opción "consulta privada".
Articulo 15.- De la conservación. - Los sujetos pasivos que fueren autorizados
a emitir comprobantes electrónicos, así como aquellos. que reciban documentos
autorizados emitidos bajo esta modalidad, deberán conservar dicha información
42
por una plaza igual al establecidos para los comprobantes emitidos en la
modalidad de preimpresi6n, sin perjuicio del registro que mantendrá el Servicio de
Rentas Internas de las transacciones realizadas por los sujetos pasivos.
Artículo 16.- Control Posterior. - La Administración Tributaria se reserva la
facultad de realizar los respectivos controles y verificaciones posteriores con
relación a la veracidad de la información enviada a su base de datos.
Artículo 17:- Normas Supletorias.- En lo no previsto en la presente Resolución,
incluidas sanciones por contravenciones, faltas reglamentarias e infracciones, se
estará a lo dispuesto en el Código Tributario, la Ley de Régimen Tributario Interno,
su Reglamento de Aplicación, el Reglamento de Comprobantes de Venta,
.Retención y Documentos Complementarios y demás normativa vigente.
DISPOSICIONES GENERALES
Primera.- Sin perjuicio de los requisitos de llenado establecidos en el Reglamento
de Comprobantes, de Venta, Retención y Documentos Complementarios, en la
emisión de comprobantes electrónicos, se deberá incluir la siguiente información:
a) Respecto a las notas de crédito y notas de débito, se deberá señalar la fecha
de emisión del comprobante de venta.
b) Respecto a los comprobantes de retenci6n, se deberá señalar en la fecha de
emisión, mes y año como periodo fiscal.
c) Respecto al número secuencial, este será de nueve dígitos y no podrá omitirse
los ceros a la izquierda. Los sujetos pasivos emisores de comprobantes
electrónicos deberán asignar puntos de emisi6n exclusivos para esta modalidad.
Segunda. - El Servicio de Rentas Internas mantendrá a disposición de los sujetos
pasivos una herramienta gratuita con la cual podrán, generar sus comprobantes
electrónicos, sin perjuicio que los contribuyentes puedan utilizar sus propios
sistemas computarizados e informáticos.
Tercera. - Para efectos de esta Resolución se entenderán los términos siguientes
conforme se detalla: Ambiente de producción. Empieza al finalizar la fase de
pruebas: Todas las acciones que se realicen en este ambiente as1 como los
comprobantes electrónicos autorizados, tienen validez tributaria.
43
Ambiente de prueba. - Es una fase de pruebas, en. el ciclo de desarrollo de la
facturación electrónica que permite recrear todos los escenarios para
configuraciones de software y hardware iguales a las del ambiente de producción.
Los comprobantes electrónicos, emitidos en este ambiente no tienen validez
tributaria.
Clave de Acceso. - Código numérico que constituye un requisito obligatorio del
comprobante electrónico y que lo individualiza.
Comprobante electrónico. - Es aquel mensaje de datos que está firmado
electrónicamente, referido a una transacción económica, que contiene toda
información creada, generada, procesada, enviada, recibida, comunicada o
archivada por medios electrónicos y que puede ser intercambiada por cualquier
medio.
Ficha Técnica. - Documento que contiene los lineamientos y especificaciones
técnicas para la implementación de las distintas modalidades.
RIDE. - Representación Impresa del Documento Electrónico.
Unicidad. - Característica de los comprobantes de venta emitidos mediante la
modalidad electrónica que garantiza que no se volverá a repetir otro comprobante
con el mismo número de autorización.
Web Services. - Un servicio web es una pieza de software que utiliza un conjunto
de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.
Distintas aplicaciones de software desarrolladas en lenguajes de programaciones
diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios
web para intercambiar datos en redes de ordenadores como Internet.
XML. - Siglas en ingles de Extensible Markup Language (lenguaje de marcas
extensible); es un estándar para el' intercambio de información estructurada entre
diferentes plataformas.
44
XSD. - Es un lenguaje de esquema utilizado para describir la estructura y las
restricciones de los contenidos de los documentos XML de una forma muy precisa.
Resolución NAC- DGERCGC15-f00000745-B. (SRI, http://www.sri.gob.ec, 2015)
Refórmese la resolución No. NAC-DGERCGC14-00790, que expide las normas
para la emisión y autorización de comprobantes de venta, retención y documentos
complementarios mediante comprobantes electrónicos.
Artículo 1.- Refórmese la Disposición Transitoria De la Resolución No. NAC-
DGERCGC14-00790, Publicada en el Registro Oficial No. 346 del 2 de octubre del
2014, en el siguiente sentido:
“La Resolución No. NAC-DGERCGC12-00105, Publicada en el Registro Oficial
No. 666 de 21 de marzo del 2012, en la que resuelve: Expedir las normas para el
nuevo esquema de emisión de comprobantes de Venta, Retención y Documentos
Complementarios mediante mensajes de datos (comprobantes electrónicos)”,
será aplicable hasta el 31 de diciembre del 2017.
2.3.4 Código Orgánico Integral Penal (http://www.justicia.gob.ec, 2014)
Este Código tiene como finalidad normar el poder punitivo del Estado, tipificar las
infracciones penales, establecer el procedimiento para el juzgamiento de las
personas con estricta observancia.
A continuación, se detalla los artículos más importantes concernientes a los delitos
informáticos, contenidos en el capítulo tercero, sección tercera, delitos contra la
seguridad de los activos de los sistemas de información y comunicación:
Artículo 229.- Revelación ilegal de base de datos. -
La persona que, en provecho propio o de un tercero, revele información registrada,
contenida en ficheros, archivos, bases de datos o medios semejantes, a través o
dirigidas a un sistema electrónico, informático, telemático o de
telecomunicaciones; materializando voluntaria e intencionalmente la violación del
secreto, la intimidad y la privacidad de las personas, será sancionada con pena
privativa de libertad de uno a tres años. Si esta conducta se comete por una o un
servidor público, empleadas o empleados bancarios internos o de instituciones de
45
la economía popular y solidaria que realicen intermediación financiera o
contratistas, será sancionada con pena privativa de libertad de tres a cinco años.
Artículo 230.- Interceptación ilegal de datos. -
Será sancionada con pena privativa de libertad de tres a cinco años:
1. La persona que, sin orden judicial previa, en provecho propio o de un tercero,
intercepte, escuche, desvíe, grabe u observe, en cualquier forma un dato
informático en su origen, destino o en el interior de un sistema informático, una
señal o una transmisión de datos o señales con la finalidad de obtener
información registrada o disponible.
2. La persona que diseñe desarrolle, venda, ejecute, programe o envíe mensajes,
certificados de seguridad o páginas electrónicas, enlaces o ventanas
emergentes o modifique el sistema de resolución de nombres de dominio de
un servicio financiero o pago electrónico u otro sitio personal o de confianza,
de tal manera que induzca a una persona a ingresar a una dirección o sitio de
internet diferente a la que quiere acceder.
3. La persona que a través de cualquier medio copie, clone o comercialice
información contenida en las bandas magnéticas, chips u otro dispositivo
electrónico que esté soportada en las tarjetas de crédito, débito, pago o
similares.
4. La persona que produzca fabrique, distribuya, posea o facilite materiales,
dispositivos electrónicos o sistemas informáticos destinados a la comisión del
delito descrito en el inciso anterior.
Artículo 231.- Transferencia electrónica de activo patrimonial. -
La persona que, con ánimo de lucro, altere, manipule o modifique el
funcionamiento de programa o sistema informático o telemático o mensaje de
datos, para procurarse la transferencia o apropiación no consentida de un activo
patrimonial de otra persona en perjuicio de esta o de un tercero, será sancionada
con pena privativa de libertad de tres a cinco años. Con igual pena, será
sancionada la persona que facilite o proporcione datos de su cuenta bancaria con
la intención de obtener, recibir o captar de forma ilegítima un activo patrimonial a
46
través de una transferencia electrónica producto de este delito para sí mismo o
para otra persona.
Artículo 232.- Ataque a la integridad de sistemas informáticos. -
La persona que destruya, dañe, borre, deteriore, altere, suspenda, trabe, cause
mal funcionamiento, comportamiento no deseado o suprima datos informáticos,
mensajes de correo electrónico, de sistemas de tratamiento de información,
telemático o de telecomunicaciones a todo o partes de sus componentes lógicos
que lo rigen, será sancionada con pena privativa de libertad de tres a cinco años.
Con igual pena será sancionada la persona que:
1. Diseñe, desarrolle, programe, adquiera, envíe, introduzca, ejecute, venda
o distribuya de cualquier manera, dispositivos o programas informáticos
maliciosos o programas destinados a causar los efectos señalados en el
primer inciso de este artículo.
2. Destruya o altere sin la autorización de su titular, la infraestructura
tecnológica necesaria para la transmisión, recepción o procesamiento de
información en general. Si la infracción se comete sobre bienes
informáticos destinados a la prestación de un servicio público o vinculado
con la seguridad ciudadana, la pena será de cinco a siete años de privación
de libertad.
Artículo 233.- Delitos contra la información pública reservada legalmente. -
La persona que destruya o inutilice información clasificada de conformidad con la
Ley, será sancionada con pena privativa de libertad de cinco a siete años. La o el
servidor público que, utilizando cualquier medio electrónico o informático, obtenga
este tipo de información, será sancionado con pena privativa de libertad de tres a
cinco años. Cuando se trate de información reservada, cuya revelación pueda
comprometer gravemente la seguridad del Estado, la o el servidor público
encargado de la custodia o utilización legítima de la información que sin la
autorización correspondiente revele dicha información, será sancionado con pena
privativa de libertad de siete a diez años y la inhabilitación para ejercer un cargo o
función pública por seis meses, siempre que no se configure otra infracción de
mayor gravedad.
47
Artículo 234.- Acceso no consentido a un sistema informático, telemático o
de telecomunicaciones. -
La persona que sin autorización acceda en todo o en parte a un sistema
informático o sistema telemático o de telecomunicaciones o se mantenga dentro
del mismo en contra de la voluntad de quien tenga el legítimo derecho, para
explotar ilegítimamente el acceso logrado, modificar un portal web, desviar o
Redirecciona de tráfico de datos o voz u ofrecer servicios que estos sistemas
proveen a terceros, sin pagarlos a los proveedores de servicios legítimos, será
sancionada con la pena privativa de la libertad de tres a cinco años.
2.3.5 Hipótesis
h1: ¿desarrollar un sistema de gestión y recepción de comprobantes electrónicos
utilizando las normas de seguridad de encriptación de los datos con cifrado
asimétrico, permitirá contribuir con el medio ambiente, ahorrar costos y tiempos a
la empresa FIXED S.A.?
48
Capítulo 3
Propuesta tecnológica
La presente propuesta para obtener el título de ingeniero en sistema busca
evidenciar o resaltar la diferencia de este producto y de otros ya existentes en el
mercado, como ya es de conocimiento existen en el mercado grandes sistemas
administrativos contable denominados ERP, que cuenta con módulos de
facturación electrónica o pequeños sistemas de facturación electrónica. Aquí se
nombran varios de los puntos que denotan la diferencia del sistema gestor y
receptor de comprobantes electrónicos de otros sistemas.
Es un sistema independiente de un sistema administrativo contable
Tiene la capacidad de capturar o leer los archivos XML recibidos de una
determinada cuenta de correo si estos cumplen con la estructura de algún
documento electrónico.
Apoya la estrategia de cualquier empresa que lo implemente “fidelidad del
cliente”
Ahorrar costo en suministro de oficinas
La configuración del sistema es totalmente sencilla
3.1. Análisis de factibilidad:
El presente estudio y trabajo de titulación se enfoca en apoyar la economía de la
compañía FIXED S.A, así como también este ayudará a regular a la empresa
cumpliendo leyes impuesto por el estado, si estudiamos la problemática planteado
en la sesión 1.2, vemos que no existe un software que sea capaz de ayudar a la
compañía a agilizar las respuestas de búsqueda de comprobantes electrónicos,
recibidos por los proveedores.
Si hacemos conciencia y enfocamos que todo software que se desarrolle se
oriente a la digitalización de documentos, a pesar de que nuestro estudio no se
base en digitalización de documentos, uno de los objetivos específicos de este
trabajo de titulación es disminuir los suministros de impresión. En Ecuador se
implementó la Facturación electrónica de manera parcial desde el 01/01/2015, con
la finalidad de disminuir la impresión de documentos para que de esta manera se
49
tenga que cortar menos árboles, sin embargo, vemos que el hoy en día todo
documento tanto emitido como recibido termina impreso.
3.1.1. Factibilidad operacional
El o los usuarios recibirán una capacitación sobre el software, así como también
de los procesos del sistema, adicionalmente se les dará una inducción de cómo
solucionar problemas frecuentes que pueden darse en el proceso de la firma de
un documento.
El sistema ayudará de manera directa la funcionalidad de la empresa, ésta
podrá emitir comprobantes electrónicos, impidiendo multas por parte del
estado por incumplimiento de las leyes.
El sistema cuenta con filtro de búsqueda personalizados por el usuario,
para una mejor respuesta de búsqueda.
El sistema detalla los pasos que conllevan firmar un documento en el
sistema y saber en qué estado se encuentra un comprobante.
El sistema gestor de comprobantes electrónico cuenta con subprocesos
automáticos en las siguientes opciones:
Recepción de comprobantes. – Esta opción cuenta con un hilo que se ejecuta
según el tiempo parametrizado, para dicha opción, el sistema censará la carpeta
repositorio de comprobantes cuya ubicación de la carpeta será en
C:\Comprobantes\Repositorio de Comprobantes, si este directorio no existe en
el sistema, crea el directorio, el hilo se prenderá con el objeto time, el objeto time
dependiendo del tiempo parametrizado que estará guardado en la base de datos.
En la siguiente figura se muestra se muestra la ventana de configuración de los
directorios para los comprobantes, así como también la dirección donde están los
archivos físicos. p12
En la ruta de repositorios de comprobantes es donde se deben depositar los
archivos XML que se desean firmar y enviar al SRI, cuando un archivo se
encuentra en esta ruta quiere decir que este archivo aún no ha sido validado y
estará esperando ser validado, para posteriormente el sistema tome acción sobre
él. Si está valido lo mueve al directorio de comprobantes válidos y además lo
50
guardará en la base de datos como un string, caso contrario lo moverá al directorio
de comprobantes con errores.
Figura 11. recepción de comprobantes
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Comprobantes válidos. – en esta ventana se muestran todos los comprobantes
que cumplieron con la estructura de un XML diseñando por el SRI, y están en la
espera de ser firmados y enviados al SRI. En esta opción se podrá visualizar el
ride antes de firmar y enviar el documento siempre y cuando el programa en esta
opción esté operando de manera manual.
Figura 12. comprobantes validos
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
51
Comprobantes sin respuesta del SRI. - En esta ventaja se visualizarán los
comprobantes que fueron firmados y enviados, pero no se ha obtenido una
respuesta por la entidad regulatoria. Esto suele pasar cuando los servidores del
SRI al recibido el comprobante, pero no da respuesta de autorizado o no
autorizado.
Figura 13. comprobantes sin respuestas del SRI
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Comprobantes autorizados y no autorizados. - se visualizarán los
comprobantes que ya tienen una respuesta por la entidad regulatoria, aquí el
usuario podrá filtrar por fecha, tipo de respuesta, por tipo de comprobante, por
emisor.
Figura 14. comprobantes autorizados y no autorizados
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
52
Administrador de correos. - El sistema cuenta con la opción de administrador
de correo simulando un correo como Hotmail, Yahoo! etc. En esta consola del
sistema podres ver el árbol jerárquico donde la cabeza es la cuenta configurada
en la empresa en la opción configuración de cuenta. Esta cuenta tendrá cuatro
opciones
Mensajes enviados
Mensajes eliminados
Mensaje en buzón de salida
Buzón de entrada
Tal como se muestra en la figura.
Figura 15. ADMINISTRADOR DE CORREO
Configuración de cuenta de correo. – En esta opción se crear y configuraran las
cuentas de correo por emisor. Donde juegan papel importante los parámetros
como puerto, tipo de seguridad, tipo de cuenta, servidor proxy entre otras
opciones.
Figura 16. CONFIGURACIÓN DE CUENTA DE CORREO
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
53
Figura 17. bandeja de correo
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Registro de un nuevo emisor. – El sistema Gestor y receptor de comprobantes
electrónicos es multiempresa lo cual nos permite registrar un nuevo emisor o
empresa. Y tendrá datos básicos como:
Ambiente.
Tipo emisión.
Datos del certificado digital. Entré otros.
Figura 18. registro de emisor
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
54
Parametrización de web services y servidor proxy. – El sistema cuenta con la
facilidad de parametrizar las url de los webs services del SRI tanto de producción
como de pruebas. Se realizó el diseño y programación de esta pantalla con la
finalidad, que si llegaran a cambiar la dirección de los servicios del SRI no se
tendría que modificar el código fuente. Adicionalmente se encuentra la
configuración de los datos del servidor proxy en caso de ser necesario para la
salida de correos.
Figura 19. parametrización de WS y servidor proxy
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Descarga de correos electrónicos. – Esta opción nos permite descargar los
correos electrónicos de la cuenta configurada en el sistema, con la finalidad de
tener los comprobantes electrónicos recibidos en la base local del sistema. Como
se mencionó en los objetivos específicos del sistema uno de estos objetivos es
disminuir la impresión de comprobantes y abaratar costo de suministro de oficina.
55
Para descargar los correos el sistema debe tener acceso a la internet, y los datos
proporcionado en la configuración de cuenta deben ser los correctos y dependerá
de la configuración del servidor de correo y los puertos habilitados para este tipo
tramas.
Previo a este proceso se podrán de descarga de correos los comprobantes
electrónicos se verán reflejados en la opción en la ventana comprobantes
recibidos. El usuario podría descargar e imprimir si lo desea o visualizar el
documento como pdf.
Figura 20. descarga de correos
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
56
Sitio web del sistema. – El sistema cuenta con una aplicación web para el uso
de los contribuyentes y emisor, la finalidad de esta aplicación web es para brindar
otro servicio al cliente, además de poderle reenviar los comprobantes electrónicos
en caso de ser necesario, también que tenga la facilidad de tener acceso a su
información desde la internet, pudiendo descargar, imprimir o visualizar los
comprobantes electrónicos.
Para los contribuyentes que se loguee por primera vez en el sistema el usuario y
el password será su número de cedula o ruc. El sistema verificara si la cedula o
ruc ingresada está en la base de datos del sistema gestor y receptor de
comprobantes electrónicos. De no encontrarse la cedula en la base de datos
indicara que la persona que intenta acceder o ingresar a la aplicación no es ni
cliente ni proveedor del emisor.
Si la cedula existe en la base de datos indistintamente si es un proveedor o cliente
el sistema lo dirigirá a una nueva ventana donde le exigirá el cambio de
contraseña.
Una vez culminado el paso del cambio de la contraseña el sistema lo dirigirá a la
ventana del login, para exigir que vuelva ingresar con su nueva contraseña.
Figura 21. sitio web inicio de sesión
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
57
Figura 22. cambio contraseña sitio web
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
El sitio web para el sistema gestor y receptor de comprobantes electrónicos es
para brindar una facilidad más a sus contribuyentes, para que estos puedan
acceder desde la internet con la finalidad de brindar un mejor servicio.
Es necesario recalcar que el proyecto tiene como objetivo cuidar y velar la
información de la empresa, así como también la integridad de sus contribuyentes.
Los contribuyentes pueden acceder al sitio web únicamente si la empresa FIXED
le ha emitido un comprobante electrónico, de ser así estos pueden acceder
ingresando su cedula como usuario y password en la primera vez que ingresen al
sistema les obligara que cambie su contraseña.
Una vez que el contribuyente allá ingresado al sitio este podrá buscar sus
comprobantes electrónicos, por tipo documento, por rango de fecha, pudiendo
imprimir y descargar el ride.
58
Figura 23. página de inicio del portal web
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
Figura 24. descarga de comprobantes del portal web
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
59
Figura 25 RIDE
60
3.1.2. Factibilidad técnica
Multiprocesos. – El sistema gestor y receptor de comprobantes
electrónicos es multiprocesos dándole la facilidad al usuario a ejecutar más
de una acción en el sistema. Utilizando hilos permite la ejecución de
multiproceso con la finalidad de brindar un ambiente agradable y que el
usuario no tenga que esperar la finalización de los procesos para la
continuación de sus acciones sobre el sistema.
Diseñador de reportes en tiempo de ejecución. – Cuenta con la opción
de poder levantar el diseñador del reporte en tiempo de ejecución, de esta
manera facilitándole al usuario poder realizar cambios en los reportes del
sistema, como agregar campos, quitar campos, o rediseñar todo el reporte.
El usuario no necesita tener ningún sistema adicional para realiza esta
acción, ya que el sistema al momento de realizar su compilado obtiene
todas las librerías necesarias desde el código fuente, para hacerla parte
del ejecutable.
Filtro de búsqueda avanzada. – El sistema le permite al usuario realizar
un filtro personalizado, sobre una consulta ya cargada en el sistema, esto
indica que, si la consulta arrojó un total de mil registros, el usuario podría
realizar un filtro personalizados sobre los mil registros.
Menú dinámico. – El sistema cuenta con un menú dinámico permitiendo
al usuario escribir el nombre de la opción personalizada, y este realizará
una búsqueda en las opciones del sistema mediante la cadena de texto
editada.
Configuración de cuentas de correo. – El sistema cuenta con la opción
de configurar una cuenta de correo existente según los parámetros del
domino de correo, dándole la opción de varios protocolos de correo como
son SMTP, ECHANGE, etc. Así como también asociar de los puertos
respectivos según el protocolo de correo.
61
Conexión cifrada según lo requiera el servidor de correo. - Si el
servidor de correo requiere que los paquetes tengan seguridad SSL, o
TSL, el sistema aplicará este tipo de seguridad para que el servidor de
correo tome la trama del mensaje como segura y los enrute hacia la nube.
Test de conexión de la cuenta de correo. - El sistema cuenta con la
opción de realizar un teste de login a la cuenta configurada, para saber si
esta está configurada correctamente esto ayudará a identificar si estamos
usando los puertos adecuados, o el tipo de seguridad requerida por el
servidor de correo, o las credenciales registradas.
Configuración de tiempos automáticos para procesar comprobantes.
El sistema cuenta con la opción de poder configurar los procesos para
ejecutar la firma de los documentos de manera automática o manual.
Funcionamiento manual. - Si la configuración esta de manera manual del
es necesario realizar los procesos para la firma de los documentos, es
decir el usuario que lo administre tendría que realizar una serie de pasos
para procesar los documentos a continuación se detallan los pasos si este
operando de manera manual el sistema gestor y receptor de comprobantes
electrónicos.
Ejecutar el proceso de validar esquema del archivo XML.
Ejecutar el proceso para subir los archivos a la base de datos
Ejecutar el proceso para la firma y envió de los comprobantes
electrónicos.
Funcionamiento automático. - Cuando se escoge la opción de
funcionamiento automático el sistema le permite decir al usuario si el
proceso se ejecuta una vez al día y en una hora especifica. Como también
puede establecer días de la semana que se ejecuta estableciendo una
hora de inicio y hora fin de la ejecución automática.
62
Estructura del proyecto. – El sistema gestor y receptor de comprobantes
electrónico este contenido en una solución de Visual Studio y a su vez
separado en cuatros capas, cada una de las capas es un proyecto que
este contenido en la solución a continuación hablaremos de las capas y
del proyecto de reportes.
Business.- en esta capa se aplicó toda la lógica del negocio la mayor parte
de la codificación del sistema se encuentra en esta capa, este proyecto de
la solución llama al proyecto Info, Data.
Info, en esta capa están todas las entidades del sistema tanto clases del
SRI, como propias del sistema. Este proyecto no tiene como referencia a
ninguna de las capas del proyecto. Es totalmente independiente
únicamente es invocado por las capas Data, Business, Winform.
Data. - aquí está el acceso a los datos la única manera de llegar a los datos
es pasando por la lógica del negocio es decir por la capa Business, aquí
también encontraremos las entidades creadas por Entity Framework, que
no son más que entidades que representan a vistas y tablas de la base de
datos.
Winform. - LA capa de presentación de usuario están los formularios y
controles de usuarios de manera que en esta capa no se encuentra mayor
cantidad de código siendo esta la capa de solicitud de peticiones y de
presentación.
Reportes. - Esta capa del proyecto es independiente no llama a ninguna
de las capas anteriormente mencionada, es llamada por la capa de
presentación únicamente. De la misma manera que el proyecto macro está
dividido en cuatros proyectos también lo está el proyecto de reporte, con
la única diferencia que en el proyecto macro las capas son proyecto y en
esta capa está divido en carpetas.
63
Comunicación entre las capas del proyecto. – La solución como se
mencionó anteriormente contiene cuatro capas y adicionalmente la capa
de reportes que trabaja de manera independiente. En la gráfica se muestra
la comunicación de los subsistemas.
Figura 26. comunicación entre capaz
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Controles de usuarios. - Visual Studio brinda una herramienta o control
donde se puede diseñar un control según las necesidades del
programador, el control creado o diseñado por el usuario aparecerá en la
barra de herramienta como un objeto más de la caja de herramienta.
Utilizar este tipo de técnica de programación es de gran ayuda, si un objeto
se va utilizar en más de una pantalla de las mismas características o
similares es mejor realizar la programación dentro de un control de usuario,
realizando esto se tendrán grandes ventajas como:
Se codifica o se programa una sola vez
Es reutilizable en cualquier pantalla que lo requiera
64
De ser necesario un cambio se realiza en el control y los cambios se
reflejarían en todas las pantallas que utilizan el control de usuario.
Reutilización de código
Ahorro de tiempos
Diagrama de entidad relación. – La base de datos cuenta con entidad relación
en los casos que se ameritan realizar la relación entre las tablas, así como también
cuenta con sus índices de búsquedas. La base de datos está diseñada de tal
manera que es fácil de interpretar que información se guarda en cada una de las
tablas, tal vez no es una buena práctica en la rama de la seguridad informática
que las tablas tengan nombres significativos.
Por seguridad, pero como siendo este un sistema de poco riesgo que lo intente
vulnerar se toma como ventajas que las tablas tengan nombre significativo para
una solución rápida de ser necesaria si la persona que está dando el soporte no
es la que diseño la base de datos.
La entidad relación en las bases de datos juega un papel muy importante para la
consistencia de datos. De manera que si un campo hace referencia a un campo y
estos no concuerdan saltara un error por inconsistencia de datos. Llámese la tabla
A y la Tabla B
En la tabla A existe dos registros cuyo campo Id contiene 1,2. Y la tabla B tiene
cinco registros y se está insertando un nuevo registro y en el campo Id de la tabla
B se intenta guardar 4. En este caso de manera inmediata saltará el software de
entidad relación del motor de la base de datos de SQL server impidiendo guardar
el registro.
De esta misma manera sucede si se intenta eliminar un registro que está siendo
referenciado por otro registro de otra tabla o de la misma tabla si esta es una tabla
recursiva.
65
66
Figura 27. diagrama entidad relación
67
Figura 28. esquema offline
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Proceso de firma y envió de los comprobantes. - En el esquema OFF-LINE el
SRI, especifica que el proceso de enviar los comprobantes tanto al emisor y al
receptor se deben realizar en tres pasos, de manera que el sistema al consumir
los WS y enviar el documento XML, y de manera simultánea enviara un correo al
cliente con los documentos adjuntos Ride, XML.
A continuación, se detalla en el grafico los procesos que se realizar para la firma
y enviar de los documentos.
1. En el paso uno se especifica la manera de enviar los comprobantes los WS
pueden recibir un lote de XML o un XML, el sistema gestor y receptor de
comprobantes electrónicos envía únicamente de manera individual es decir
solo paso como parámetro un XML a los WS.
68
2. En el paso tres el sistema debe realizar la firma del documento, esto implica
al documento que previamente fue validado y que cumple con la estructura
especificada por el SRI, se le debe añadir un tag de firma al XML.
3. En el paso tres el sistema enviará el documento a los servidores del SRI
mediante los WS publicados y de manera paralela se enviará el comprobante
al emisor.
Los WS publicados por el SRI tanto de pruebas como de producción. – El
Servicio de Rentas Internas publico sus WS de pruebas y de producción con la
finalidad de que los contribuyentes puedan realizar las pruebas necesarias antes
de salir a producción
Pruebas.
https://celcer.sri.gob.ec/comprobantes-electronicos-
ws/RecepcionComprobantesOffline?wsdl
https://celcer.sri.gob.ec/comprobantes-electronicos-
ws/AutorizacionComprobantesOffline?wsdl
Producción.
https://cel.sri.gob.ec/comprobantes-electronicos-
ws/RecepcionComprobantesOffline?wsdl
https://cel.sri.gob.ec/comprobantes-electronicos-
ws/AutorizacionComprobantesOffline?wsdl
Código relevante del sistema (“Leer respuesta del SRI”). – La siguiente
porción de código permite leer un bloque de código de XML, para saber si el SRI
devolvió algún tipo de respuesta. Como es una porción de código XML hay que
leer por nodo esto podría recorrerse con un bucle y buscar el nodo requerido y
obtener la data.
Código relevante del sistema (“Enviar comprobante por correo”).
69
Figura 29. código relevante
70
71
72
3.1.3 Factibilidad legal
FIXED S.A se compromete a hacer uso del software de manera personal y no
realizar copias para distribuirlo con o sin fines de lucros. Así como también queda
en su responsabilidad la compra de las Licencia que se detalla en la tabla. Los
autores y desarrolladores del sistema no se comprometen del mal uso del sistema
sus derechos de autoría son cedidos a la Universidad de Guayaquil. Si la empresa
tuviera la necesidad de modificar o comprar los derechos de autor incluyendo los
códigos fuentes. La única manera y fuente es llegar a un mutuo acuerdo con la
Universidad de Guayaquil.
73
Tabla 2. licencias
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
3.1.4 Factibilidad económica
El presente estudio tiene un costo de $ 999 dólares con 99 centavos de dólares
americanos para la empresa FXED S.A. en este proyecto se incluyen las
siguientes herramientas que se detallaran a continuación:
Tabla 3. precios de licencias
Herramienta de
desarrollo
Lenguaje Cantidad de licencia Valor Monetario
Visual Studio C# 0 $0.00
SQL Server 2014 Base de
datos
0 $0.00
Devexpress Framework 1 $999.99
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solórzano
FIXED S.A hará uso de las herramientas Express de Visual Studio y SQL Server
2014, para disminuir el costo del proyecto, la empresa se compromete a comprar
Herramienta
de desarrollo
Lenguaje Cantidad
de
licencia
Comprar
licencia a
partir de:
Costo
Visual Studio C# 0 Ilimitada $0.00
SQL Server
2014
Base de
datos
0 A partir de los 2
GB de
información
$0.00
Devexpress Framework 1 Desde la
implementation
$999.99
74
la licencia con el objetivo de ser una inversión para su área de desarrollo, y los
accionistas tienen en mente implementar en el año 2018.
3.1.5 Etapas de la metodología del proyecto
En este estudio se utilizará la metodología ágil, donde se enfatizan las bondades
de las mismas, en relación con otras metodologías. Sin lugar a duda quizás otras
metodologías tienen su particularidad, pero en el estudio la metodología ya antes
mencionada es la que más se ajusta a la problemática.
Como se muestras en la figura esta metodología se basa en la problemática como
otras metodologías luego la priorización de requisitos esto depende del proyecto
no siempre los requisitos son priorizados. De aquí en adelante es una iteración
entre los auspiciantes del software, usuarios y desarrolladores. Cada entregable
o proceso podrá tener varias iteraciones hasta que su funcionalidad este sin
errores ni fallos.
Figura 30. metodología del proyecto
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
75
Planteamiento. - El planteamiento del presente proyecto surgió con la necesidad
de que la empresa FIXED S.A, no tiene facturación electrónica y
De manera que esta es una empresa nueva buscando innovar en las áreas de la
tecnología de la información. Quiere tener su información a la mano y no quiere
depender de un empleado para que organice los comprobantes de documentos
electrónicos emitidos y recibidos.
Planteamiento. - Al ser este un proyecto pequeño no hubo la necesidad de
priorizar las tareas o procesos para el desarrollo. Si se tratara de un proyecto
macro si es de gran importancia priorizar los requisitos mucho si el proyecto está
dividido en etapas y cada una de ellas es un entregable funcional.
Iteraciones. - En la etapa de iteraciones generalmente se involucran mínimo tres
fases, análisis diseño y desarrollo. Basándonos en nuestro trabajo de titulación
como señálala la metodología ágil que se debe fusionar más de una fase. Se ha
aplicado el método de la misma manera que lo ordena la metodología. Esto
conlleva que hubo que reunirse con los usuarios de FIXED S.A, para realizar la
ingeniería de requerimiento luego se procedió con el análisis y posteriormente
diseñar las pantallas y por último mostrar al usuario final que de la ingeniería de
requerimiento se analizó y se diseñó el proceso o flujo. Y los usuarios de FIXED
S.A estaban o no de acuerdo con los procesos diseñados.
Puesta en marcha. - Cuando un proceso ha pasado por varias iteraciones si así
lo amerita el caso, y ya se han realizados las pruebas necesarias dando como
resultados informes correctos o procesos correctos. Es aquí cuando se decide a
poner en marcha o implementar el módulo o el sistema. En el trabajo de titulación
se realizaron las pruebas necearías por cada opción del sistema y la iteración
entre ellas.
3.1.6 Entregables del proyecto
Los entregables del proyecto o denominados hitos, estos pueden ser
documentación, desarrollo entre otros, cada fase puede tener más de un
76
entregable. Si se basa en la metodología ágil prácticamente el proyecto macro es
dividido en sub proyectos, donde cada uno de éstos es un entregable.
El sistema gestor y receptor de comprobantes electrónicos lo divide en los
siguientes subproyectos:
Seguridad de Acceso
Facturación Electrónica
Configuraciones
Administrador de correo
Cada uno de estos módulos o sub proyectos tendrán más de un entregable, si
hace referencia al módulo de Administrador de correo electrónico, uno de los
entregable que podría hacer mención es que la opción de enviar correo de forma
masiva funcione. Cuando aún no se haya probado la opción para enviar correo de
manera individual que este sería otro entregable. Cuando todas las opciones del
módulo han sido probadas entonces se hará la entrega del módulo o sub proyecto.
Entregable del módulo Seguridad de Acceso, en este entregable o hito
que se hará a la empresa FIXED S.A, se probarán la funcionalidad del
módulo en general que corresponde a las siguientes opciones:
Figura 31. módulo de seguridad de acceso
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
77
Cada una de estas funciones o acciones del sistema deben funcionar en
sus totalidades. Como se ilustra en la figura cada una de estas opciones
no permite crear usuarios y asignar roles a los mismo.
Figura 32. módulo de firma electrónica
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Entregable del módulo firma electrónica, Este subsistema debe cumplir
a cabalidad, lo que es la firma y envió de comprobantes electrónicos, así
como también su funcionalidad automática de los cuatros pasos por lo que
debe pasar el XML antes de tener una respuesta por la entidad regulatoria.
Adicionalmente debe recibir los comprobantes electrónicos por los
proveedores y clientes. En este módulo se entregará los reportes de los
comprobantes electrónicos denominados ride.
Entregable del módulo configuración, El sistema debe permitir cambiar
las configuraciones y crear nueva configuración, como se mencionó en la
sesión 4. Que los parámetros pueden ser por empresa o de manera global.
78
Figura 33. módulo de configuración
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Entregable del módulo administrador de correo, este entregable debe
funcionar las opciones del módulo como son:
o Creación de cuenta de correo
o Asignación de cuenta de correo por empresa
o Redactar un correo
o Renviar comprobantes en lotes.
o Administrador de correo, donde se encuentra los comprobantes
o de correo enviados, recibidos y los que no se han enviado por algún
error.
79
Figura 34. módulo de administración de correo
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
80
Capítulo 4
4.1 Criterios de aceptación del producto o Servicio
Tomando en cuenta todo el factor que influyó favorablemente el desarrollo del
presente proyecto de titulación podemos hacer mención los siguientes
criterios:
El levantamiento de información se lo realizó con usuarios finales tomando
en cuenta cada análisis como una retroalimentación permanente donde
siempre se llegó a un consenso con los usuarios implicados para aprobar
cada decisión tomada en cuanto al desarrollo del sistema.
Se apegó a las sugerencias de la empresa en cuanto alinear el proyecto a
los objetivos de negocio, se logró satisfacer a las partes interesadas
aprobando el correcto funcionamiento del sistema en las pruebas, se
cumplió con las expectativas, solucionando la problemática, se alineó a los
recursos de la empresa desarrollando la aplicación en las plataformas que
trabaja la empresa.
El tema económico, el proyecto no generó ninguna inversión de parte de
FIXED S.A permitiendo dar paso a las entrevistas para realizar el
levantamiento de información y aprobación del desarrollo del proyecto.
Técnica de recolección de datos
Análisis de la encuesta
Esta técnica de recolección de datos se la realiza para asentar un precedente en
los usuarios ya que el análisis de estos resultados se logrará medir el nivel de
aceptación y la viabilidad del sistema, asimismo se le comunica que de forma
indirecta sobre la propuesta tecnológica que se va a realizar para captar su interés
y su capacidad de sugerir especificaciones.
Los datos recopilados de las siguientes estadísticas fueron obtenidos en base a
las encuestas realizadas al personal de la empresa FIXED S.A, siendo estos los
siguientes miembros de la compañía en mención:
Gabriela Pacheco “Gerente General”
Mario Montero “presidente”
Jorge Aroca “Gerente de proyecto”
81
3.1.6 Casos de usos
Caso de uso por módulos del sistema gestor y receptor de comprobantes
electrónicos.
Figura 35. caso de uso acceso al sistema.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Tabla 4. caso de uso por módulos del sistema gestor y receptor de comprobantes electrónicos.
Caso de uso
Caso de uso por módulos del sistema gestor y receptor de comprobantes electrónicos.
Actores Administrador, usuarios
Tipo Primario
Descripción El sistema consta de cuatros modulo y cada uno de ellos con sus opciones. En la figura se muestra que los usuarios solo tienen acceso a dos módulos y por ende no tendrán acceso a las opciones del módulo.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Seguridad y
Accesso
Configuracion
es
Facturación
electronica
Email Usuario Administra
82
Caso de uso Creación de usuarios.
Figura 36. caso de uso creación de usuarios.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Tabla 5. caso de uso creación de usuarios.
Caso de uso Caso de uso creación de usuarios.
Actores Administrador, usuarios
Tipo Primario
Descripción Los usuarios son creados únicamente por los administradores,
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Nuevo
Modificar
Anular
Consultar
Administrador
83
Figura 37. caso uso de los procesos de facturación electrónica.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Tabla 6. caso de proceso de facturación electrónica
Caso de uso Caso de los procesos de facturación electrónica.
Actores Administrador, usuarios
Tipo Primario
Descripción Tantos como los usuarios y administradores, tienen acceso a los procesos de la facturación electrónica. Debido que el usuario necesita saber el estado de los documentos.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Comprobantes en
repositorios
Comprobantes
validos
Comprobantes sin
respuestas
comprobantes
Aut./no auto.
Usuario Administrador
84
Figura 38. caso de uso para configuración de cuenta de correo.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Tabla 7. caso de uso para configuración de cuenta de correo.
Caso de uso configuración de cuenta de correo
Actores Administrador, usuarios
Tipo Primario
Descripción Únicamente los usuarios administradores tendrán acceso a la configuración de las cuentas, para envió y recepción de comprobantes electrónicos.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Creacion de
cuenta
Modificar cuenta
de correo
Anular cuenta de
correo
Consultar cuenta
de correo
Administrador
85
Figura 39. caso de uso para para registrar y modificar emisor
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Tabla 8. caso de uso para modificar y creación de emisor.
Caso de uso caso de uso para para registrar y modificar emisor
Actores Administrador
Tipo Primario
Descripción En la pantalla de emisor se encuentra datos relevantes para el sistema, estos datos de ser cambiados pueden influir de manera muy grabe para la compañía.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Creacion de
emisor
Modificar del
emisor
Anular emisor
Consultar emisor
Administrador
86
Figura 40. caso de uso configuración de parámetros web service
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Tabla 9. caso de uso modificar y consultar parámetros web services SRI.
Caso de uso Parámetros web service SRI
Actores Administrador
Tipo Primario
Descripción En esta pantalla se configuran las url del web services del SRI, tanto de pruebas como de producción. Esta pantalla se vuelve delicada para no poder dar acceso a cualquier usuario, debido a que si es modificada una de las url el sistema no podría enviar los comprobantes electrónicos.
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Modificar
Consultar
Administrador
87
Figura 41. caso de uso modificar diseño de reporte “ride”
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solorzano
Tabla 10. CASO DE USO MODIFICAR DISEÑO DE REPORTE “RIDE”.
Caso de uso Modificar diseño de reportes “Ride”
Actores Administrador
Tipo Primario
Descripción El diseñador de reporte de los cinco comprobantes electrónicos que maneja el sistema es de uso solo del administrador del sistema. Ya que un usuario inexperto podría dañar el diseño del reporte, y si esto pasa le llegara mal el ride a los clientes o proveedores dependiendo del diseño modificado.
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
Modificar reporte
Eliminar campos
Agregar campos
Modificar campos
Administrador
88
Figura 42. caso uso redactar correo.
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solorzano
Tabla 11. caso de uso redactar correo.
Caso de uso Redactar correo
Actores Administrador, usuarios
Tipo Primario
Descripción La ventana de redactar correo es de uso administrativo y de usuario en general si así lo desea el administrador del sistema. Esta opción nos permite redactar un correo y adjuntar los comprobantes electrónicos que el usuario desee adjuntar.
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
Redactar correo
Usuario Administrador
89
1. ¿Considera que el Software es amigable?
Opciones Porcentajes
BUENO 35%
MUY BUENO 34%
EXCELENTE 30%
MALO 1%
MUY MALO 0,0%
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
35%
34%
30%
1%0%
Software Amigable
Bueno
Muy Bueno
Excelente
Malo
Muy Malo
90
2. ¿El software Funciono correctamente?
Opciones Porcentajes
BUENO 15%
MUY BUENO 45%
EXCELENTE 40%
MALO 0,0%
MUY MALO 0,0%
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
15%
45%
40%
0%0%
El Software Funciono Correctamente
Bueno
Muy Bueno
Excelente
Malo
Muy Malo
91
3. ¿Tuvo problemas al generar la firma y el comprobante electrónico?
Opciones Porcentajes
BUENO 30%
MUY BUENO 30%
EXCELENTE 30%
MALO 10%
MUY MALO 0,0%
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
11%
38%38%
13% 0%
Tuvo problemas al generar la firma y el comprobante electronico
Bueno
Muy Bueno
Excelente
Malo
Muy Malo
92
4. ¿Tuvo inconvenientes con el módulo de configuraciones?
Opciones Porcentajes
BUENO 30%
MUY BUENO 30%
EXCELENTE 30%
MALO 10%
MUY MALO 0,0%
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
30%
30%
30%
10%0%
Tuvo inconvenientes con el módulo de configuraciones
1er trim.
Muy Bueno
Excelente
Malo
Muy Malo
93
5. ¿No tuvo inconvenientes al manipular el módulo de administrador de
correo?
Opciones Porcentajes
BUENO 30%
MUY BUENO 30%
EXCELENTE 40%
MALO 0%
MUY MALO 0%
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
30%
30%
40%
0%0%
No tuvo inconvenientes al manipular el módulo de administrador de correo
Bueno
Muy Bueno
Excelente
Malo
Muy Malo
94
6. ¿Tuvo problemas al reenviar los comprobantes electrónicos en lotes?
Opciones Porcentajes
BUENO 33%
MUY BUENO 33%
EXCELENTE 33%
MALO 1%
MUY MALO 0,0%
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
33%
33%
33%
1%0%
Tuvo problemas al reenviar los comprobantes electrónicos en lotes
BUENO
MUY BUENO
EXCELENTE
MALO
MUY MALO
95
7. ¿Considera que el sistema es complicado de manejar?
Opciones Porcentajes
BUENO 46%
MUY BUENO 46%
EXCELENTE 8%
MALO 0%
MUY MALO 0%
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
Fuente: Datos de la Investigación
Elaborado por: Carlos Cedeño y Carlos Solorzano
11%
38%38%
13%0%
Considera que el sistema es complicado de manejar
BUENO
MUY BUENO
EXCELENTE
MALO
MUY MALO
96
4.2 Conclusiones
Se analizó y desarrolló un SISTEMA DE GESTIÓN Y RECEPCIÓN DE
COMPROBANTES ELECTRÓNICOS UTILIZANDO LAS NORMAS DE
SEGURIDAD DE ENCRIPTACIÓN DE LOS DATOS CON CIFRADO
ASIMÉTRICO.
El sistema de la presente propuesta de titulación almacena los comprobantes
electrónicos emitidos y recibidos de manera digital en la base de datos SQL
SERVER, como tipo de dato Binario.
El sistema guarda los comprobantes electrónicos de forma binaria, de esta
manera presidiendo de la impresión de los mismo, y en consecuencia no
almacenarlos de manera física.
El sistema receptor y gestor de comprobantes electrónicos, censa y lee los
comprobantes electrónicos de un repositorio, el cual puede ser una carpeta en
red o local que se parametrizar en el sistema, para proceder a firmarlos y
enviarlos tanto al SRI como al receptor. Con esto la empresa FIXED S.A a
través de su sistema solo debe generar los xml que es menos costoso que
desarrollar el módulo de facturación electrónica.
El sistema reenvía los comprobantes electrónicos al emisor, especificando el
archivo adjunto ya sea el RIDE o el XML.
El sistema gestor y receptor de comprobantes electrónico notifica a una cuenta
de correo parametrizada en el mismo, al momento de generarse
la eventualidad cuando el comprobante electrónico es devuelto y del mismo
modo cuando no es autorizado por el SRI.
97
4.3 Recomendaciones
Desarrollar un módulo estadístico para medir la concurrencia tanto de los
comprobantes devueltos como no autorizados por el SRI.
Buscar un optimo almacenamiento de los comprobantes electrónicos que no
influya con el crecimiento de la base de datos, ya que el sistema almacena el
RIDE y XML de manera binario, y esto puede acelerar el crecimiento de la
base de datos.
No imprimir y archivar el RIDE, dado que uno de los objetivos es reducir
el espacio físico por almacenamiento de comprobantes.
Se recomienda hacer tareas programadas en la base de datos que genere
respaldo de información encriptados.
Desarrollar el enviar de mensajes de texto a un número de teléfono celular
parametrizado en el sistema, con información similar a la enviada mediante la
notificación por correo electrónico.
98
4.4 Anexos
4.4.1 Formato XML Factura
ETIQUETAS O TAGS
CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<?xml versión="1.0" encoding="UTF-8" ?> Obligatorio - - <factura id="comprobante" versión="1.0.0"> Obligatorio - - <intributaría> Obligatorio - -
<ambiente>1 </ambiente>
Obligatorio, conforme tabla 4
Numéric
o
1
<tipoEmision>1 </ tipoEmision>
Obligatorio, conforme tabla 2
Numéric
o
1
<razonSocial>Distribuidora de Suministros Nacional S.A.</razonSocial>
Obligatorio Alfanumérico
Max 300
<nombreComercial>Empresa Importadora y Exportadora de Piezas</ nombreComercial >
Obligatorio cuando corresponda
Alfanum
érico
Max 300
<ruc>1792146739001</ruc> Obligatorio Numérico
13
<claveAcceso>2110201101179214673900110020010000000011234567813</claveAcceso>
Obligatorio, conforme tabla 1
Numéric
o
49
<codDoc>01</codDoc>
Obligatorio, conforme tabla 3
Numéric
o
2
<estab>002</estab> Obligatorio Numérico
3
<ptoEmi>001</ptoEmi> Obligatorio Numérico
3
<secuencial>000000001</secuencial> Obligatorio Numérico
9
<dirMatriz>Enrique Guerrero Portilla OE1-34 AV. Galo Plaza Lasso</dirMatriz>
Obligatorio Alfanumérico
Max 300
</infoTributaria> Obligatorio - - <infoFactura> Obligatorio - -
<fechaEmision>21/10/2012</fechaEmision> Obligatorio Fecha dd/mm/aaaa
<dirEstablecimiento>Sebastián Moreno S/N Francisco García</ dirEstablecimiento >
Obligatorio cuando corresponda
Alfanumérico
300
<contribuyenteEspecial>5368</contribuyenteEspecial>
Obligatorio cuando corresponda
Alfanum
érico
Max 13
<obligadoContabilidad>SI</ obligadoContabilidad >
Obligatorio cuando corresponda
Texto
SI / NO
<tipoIdentificacionComprador>04</ tipoIdentificacionComprador >
Obligatorio, conforme tabla 6
Numéric
o
2
<guiaRemision>001-001-000000001</guiaRemision>
Obligatorio cuando corresponda
Numéric
o
15
<razonSocialComprador>PRUEBAS SERVICIO DE RENTAS INTERNAS</razonSocialComprador>
Obligatorio
Alfanum
érico
Max 300
99
<identificacionComprador>1713328506001</ identificacionComprador >
Obligatorio Alfanumérico
Max 20
<direccionComprador>salinas y santiago</direccionComprador>
Obligatorio, cuando corresponda
Alfanumérico
Max 300
<totalSinImpuestos>295000.00</totalSinImpuestos> Obligatorio Numérico
Max 14
<totalDescuento>5005.00</totalDescuento> Obligatorio Numérico
Max 14
<totalConImpuestos> Obligatorio - - <totalImpuesto> Obligatorio - -
<codigo>3</codigo >
Obligatorio, conforme tabla 16
Numéric
o
1
<codigoPorcentaje>3072</ codigoPorcentaje>
Obligatorio, conforme tabla 18
Numéric
o
Min 1 M
ax 4
<baseImponible>295000.00</ baseImponible > Obligatorio Numérico
Max 14
<valor>14750.00</valor > Obligatorio Numérico
Max 14
</totalImpuesto > Obligatorio - -
<totalImpuesto> Obligatorio - -
<codigo>2</codigo >
Obligatorio, conforme tabla 16
Numéric
o
1
<codigoPorcentaje>2</ codigoPorcentaje>
Obligatorio, conforme tabla 17
Numéric
o
Min 1 M
ax 4
<descuentoAdicional>5.00</descuentoAdicional>
Opcional, aplica para código impuesto 2.
Numérico
Max 14
<baseImponible>309750.00</ baseImponible > Obligatorio Numérico
Max 14
<valor>37169.40</valor > Obligatorio Numérico
Max 14
</totalImpuesto > Obligatorio - - <totalImpuesto> Obligatorio - - <codigo>5</codigo >
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>5001</ codigoPorcentaje>
Obligatorio, conforme tabla 18
Numérico
Min 1 M ax
4 <baseImponible>12000.00</ baseImponible > Obligatorio Numérico Max 14 <valor>240.00</valor > Obligatorio Numérico Max 14 </totalImpuesto > Obligatorio - - </totalConImpuestos > Obligatorio - - <propina>0.00</propina> Obligatorio Numérico Max 14 <importeTotal>347159.40</ importeTotal> Obligatorio Numérico Max 14 <moneda>DOLAR</moneda>
Obligatorio cuando corresponda
Alfanuméri
co
Max 15
<pagos> Obligatorio - - <pago> Obligatorio - <formaPago>01</formaPago>
Obligatorio, conforme tabla 24
Numérico
2
<total>347159.40</total> Obligatorio Numérico Max 14 <plazo>30<plazo>
Obligatorio, cuando
Numérico
Max 14
100
corresponda
<unidadTiempo>dias</unidadTiempo>
Obligatorio, cuando corresponda
Texto
Max 10
</pago> Obligatorio - - </pagos> Obligatorio - - <valorRetIva>10620.00</valorRetIva> Opcional Numérico Max 14 <valorRetRenta>2950.00</valorRetRenta> Opcional Numérico Max 14 </infoFactura> Obligatorio - - - <detalles> Obligatorio - - - <detalle> Obligatorio - - <codigoPrincipal>125BJC-01</codigoPrincipal > Opcional Alfanuméri
co Max 25
<codigoAuxiliar>1234D56789-A</codigoAuxiliar>
Obligatorio cuando corresponda
Alfanuméri
co
Max 25
<descripcion>CAMIONETA 4X4 DIESEL 3.7</descripcion> Obligatorio Alfanumérico
Max 300
<cantidad>10.00</cantidad> Obligatorio Numérico Max 14 <precioUnitario>300000.00</precioUnitario> Obligatorio Numérico Max 14 <descuento>5000.00</descuento> Obligatorio Numérico Max 14 <precioTotalSinImpuesto>295000.00</ precioTotalSinImpuesto>
Obligatorio Numérico Max 14
<detallesAdicionales>
Obligatorio cuando corresponda
-
-
<detAdicional nombre="Marca Chevrolet" valor="Chevrolet"/>
Obligatorio cuando corresponda
Alfanuméri
co
Max 300
<detAdicional nombre="Modelo " valor="2012"/>
Obligatorio cuando corresponda
Alfanuméri
co
Max 300
<detAdicional nombre="Chasis" valor="8LDETA03V20003289"/>
Obligatorio cuando corresponda
Alfanuméri
co
Max 300
</detallesAdicionales>
Obligatorio cuando corresponda
-
-
- <impuestos> Obligatorio - - - <impuesto> Obligatorio - - <codigo>3</codigo>
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>3072</codigoPorcentaje>
Obligatorio, conforme tabla 18
Numérico
Min 1 M ax
4 <tarifa>5</ tarifa> Obligatorio Numérico Min 1 M ax
4 <baseImponible>295000.00</baseImponible> Obligatorio Numérico Max 14 <valor>14750.00</valor> Obligatorio Numérico Max 14 -</impuesto> Obligatorio - - -<impuesto> Obligatorio - - <codigo>2</codigo>
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>2</codigoPorcentaje>
Obligatorio, conforme tabla 17
Numérico
Min 1 M ax
4 <tarifa>12</ tarifa> Obligatorio Numérico Min 1 M ax
4 <baseImponible>309750.00</baseImponible> Obligatorio Numérico Max 14
101
<valor>37170.00</valor> Obligatorio Numérico Max 14 </impuesto> Obligatorio - - -<impuesto> Obligatorio - - <codigo>5</codigo>
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>5001</codigoPorcentaje>
Obligatorio, conforme tabla 18
Numérico
Min 1 M ax
4 <tarifa>0.02</ tarifa> Obligatorio Numérico Min 1 M ax
4 <baseImponible>12000.00</baseImponible> Obligatorio Numérico Max 14 <valor>240.00</valor> Obligatorio Numérico Max 14 </impuesto> Obligatorio - - </impuestos> Obligatorio - - - <detalle> Obligatorio - - - <detalles>
Obligatorio
-
-
- <infoAdicional>
Obligatorio cuando corresponda
-
-
<campoAdicional nombre="Codigo Impuesto ISD">4580</campoAdicional>
Obligatorio cuando corresponda
Alfanuméri
co
Max 300
<campoAdicional nombre="Impuesto ISD">15.42x</campoAdicional>
Obligatorio cuando corresponda
Alfanuméri
co
Max 300
</infoAdicional>
Obligatorio cuando corresponda
-
-
</factura> obligatorio - -
Fuentes: Datos investigativos
Elaborado por: Carlos Cedeño, Carlos Solórzano
102
4.2.2 Formato XML comprobante de retención
ETIQUETAS
O TAGS
CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<?xml version="1.0" encoding="UTF-8" ?>
Obligatorio
-
-
-<comprobanteRetencion id="comprobante" version="1.0.0">
Obligatorio
-
-
<infoTributaria> Obligatorio - -
<ambiente>1</ambiente> Obligatorio, conforme tabla 4
Numérico
1
<tipoEmision>1</ tipoEmision> Obligatorio, conforme tabla 2
Numérico
1
<razonSocial>Distribuidora de Suministros Nacional S.A.</razonSocial>
Obligatorio Alfanumérico
Max 300
<nombreComercial>Empresa Importadora y Exportadora de Piezas y Partes de Equipos de Oficina</ nombreComercial >
Obligatorio cuando corresponda
Alfanumérico
Max 300
<ruc>1792146739001</ruc> Obligatorio Numérico
13
<claveAcceso>2410201107179214673900110020010000000011234567815</claveAcceso> Obligatorio,
conforme tabla 1
Numérico
49
<codDoc>07</codDoc> Obligatorio, conforme tabla 3
Numérico
2
<estab>002</estab> Obligatorio Numérico
3
<ptoEmi>001</ptoEmi> Obligatorio Numérico
3
<secuencial>000000001</secuencial>
Obligatorio
Numéric
o
9
<dirMatriz>Enrique Guerrero Portilla OE1-34 AV. GALO PLAZA LASSO</dirMatriz>
Obligatorio
Alfanumérico
Max 300
</infoTributaria> Obligatorio - -
<infoCompRetencion> Obligatorio - -
<fechaEmision>15/01/2012</fechaEmision>
Obligatorio
Fecha
dd/mm/aa
aa
<dirEstablecimiento>Rodrigo Moreno S/N Francisco García</ dirEstablecimiento >
Obligatorio cuando corresponda
Alfanumérico
Max 300
<contribuyenteEspecial>5368</contribuyenteEspecial> Obligatorio cuando corresponda
Alfanumérico
Max 13
<obligadoContabilidad>SI</ obligadoContabilidad > Obligatorio cuando
Texto SI / NO
103
corresponda
<tipoIdentificacionSujetoRetenido>04</tipoIdentificacionSujetoRetenido> Obligatorio,
conforme tabla 6
Numérico
2
<razonSocialSujetoRetenido>Juan Pablo Chávez Núñez</razonSocialSujetoRetenido>
Obligatorio
Alfanumérico
Max 300
<identificacionSujetoRetenido>1713328506001</identificacionSujetoRetenido>
Obligatorio Alfanumérico
Max 20
<periodoFiscal>03/2012</periodoFiscal> Obligatorio Fecha mm/aaaa
</infoCompRetencion> Obligatorio - - - <impuestos> Obligatorio - -
- <impuesto> Obligatorio - -
<código>2</código> Obligatorio, conforme tabla 20
Numérico
1
<codigoRetencion>1</codigoRetencion> Obligatorio, conforme tabla 21
Alfanumérico
Min 1 Max 5
<baseImponible>101.94</baseImponible> Obligatorio Numérico
Max 14
<porcentajeRetener>30</porcentajeRetener> Obligatorio, conforme tabla 21
Numérico
Min 1 Max 3
<valorRetenido>30.58</valorRetenido> Obligatorio Numérico
Max 14
<codDocSustento>01</codDocSustento> Obligatorio Numérico
2
<numDocSustento>002001000000001</numDocSustento>
Opcional Numérico
15
ETIQUETAS
O TAGS
CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<fechaEmisionDocSustento>20/01/2012</fechaEmisionDocSustento>
Obligatorio cuando corresponda
Fecha
dd/mm/aaaa
</impuesto> Obligatorio - - - <impuesto> Obligatorio - -
< código >1</ código> Obligatorio, conforme tabla 20
Numérico
1
<codigoRetencion>323B1</codigoRetencion> Obligatorio, conforme tabla 21
Alfanumérico
Min 1 Max 5
104
<baseImponible>10904.50</baseImponible> Obligatorio Numérico
Max 14
<porcentajeRetener>2</porcentajeRetener> Obligatorio, conforme tabla 21
Numérico
Min 1 Max 3
<valorRetenido>218.09</valorRetenido> Obligatorio Numérico
Max 14
<codDocSustento>01</codDocSustento> Opcional Numérico
2
<numDocSustento>002001000000001</numDocSustento> Opcional Numérico
15
<fechaEmisionDocSustento>20/01/2012</fechaEmisionDocSustento>
Obligatorio cuando corresponda
Fecha
dd/mm/aaaa
</impuesto> Obligatorio - - - <impuesto> Obligatorio - -
< código>6</ código> Obligatorio, conforme tabla 20
Numérico
1
<codigoRetencion>4580</codigoRetencion> Obligatorio, conforme tabla 21
Alfanumérico
Min 1 Max 5
<baseImponible>2000</baseImponible> Obligatorio Numérico
Max 14
<porcentajeRetener>5</porcentajeRetener> Obligatorio, conforme tabla 21
Numérico
Min 1 Max 3
<valorRetenido>100</valorRetenido> Obligatorio Numérico
Max 14
<codDocSustento>12</codDocSustento> Obligatorio Numérico
2
<numDocSustento>002001000000001</numDocSustento> Opcional Numérico
15
<fechaEmisionDocSustento>20/01/2012</fechaEmisionDocSustento>
Obligatorio cuando corresponda
Fecha
dd/mm/aaaa
</impuesto> Obligatorio - - </impuestos> Obligatorio - -
- <infoAdicional>
Obligatorio cuando corresponda
-
-
<campoAdicional nombre="ConvenioDobleTributacion">MA123456</campoAdicional>
Obligatorio cuando corresponda
Alfanumérico
Max 300
<campoAdicional nombre="documentoIFIS">BP2010-01-0014</campoAdicional>
Obligatorio cuando corresponda
Alfanumérico
Max 300
<campoAdicional nombre="valorpagadoIRsociedaddividendos">20000</campoAdicional>
Obligatorio cuando corresponda
Alfanumérico
Max 300
Obligatorio cuando correspond
105
4.2.3 Formato XML guía de remisión
</infoAdicional> a
- -
</comprobanteRetencion> Obligatorio - -
ETIQUETAS O TAGS CARÁCTER TIPO DE CAMPO
LONGITUD / FORMATO
<?xml version="1.0" encoding="UTF-8" ?> Obligatorio - -
-<guiaRemision id="comprobante" version="1.0.0"> Obligatorio - -
- <infoTributaria> Obligatorio - -
<ambiente>1</ambiente>
Obligatorio, conforme tabla 4
Numérico
1
<tipoEmision>1</ tipoEmision>
Obligatorio, conforme tabla 2
Numérico
1
<razonSocial>Distribuidora de Suministros Nacional S.A.</razonSocial>
Obligatorio Alfanumérico
Max 300
<nombreComercial>Empresa Importadora y Exportadora de Piezas y Partes de Equipos de Oficina</ nombreComercial >
Obligatorio cuando corresponda
Alfanumé
rico
Max 300
<ruc>1792146739001</ruc> Obligatorio Numérico 13
<claveAcceso>2110201106179214673900100110020010000000011234567815</claveAcceso>
Obligatorio, conforme tabla 1
Numérico
49
<codDoc>06</codDoc>
Obligatorio conforme tabla 3
Numérico
2
<estab>002</estab> Obligatorio Numérico 3
<ptoEmi>001</ptoEmi> Obligatorio Numérico 3
<secuencial>000000001</secuencial> Obligatorio Numérico 9
<dirMatriz>Enrique Guerrero Portilla OE1-34 AV. Galo Plaza Lasso</dirMatriz>
Obligatorio Alfanumérico
Max 300
</infoTributaria> Obligatorio - - <infoGuiaRemision> Obligatorio - -
<dirEstablecimiento>Sebastián Moreno S/N Francisco García</ dirEstablecimiento >
Obligatorio cuando corresponda
Alfanumé
rico
Max 300
<dirPartida>Av. Eloy Alfaro 34 y Av. Libertad Obligatorio Alfanumérico
Max 300
106
4.2.4 Formato XML nota crédito
ETIQUETAS O TAGS
CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<?xml version="1.0" encoding="UTF-8" ?> Obligatorio - -
- <notaCredito id="comprobante" version="1.0.0">
Obligatorio - -
Esq.</dirPartida> <razonSocialTransportista>Transportes S.A.</razonSocialTransportista>
Obligatorio Alfanumérico
Max 300
<tipoIdentificacionTransportista>04</tipoIdentificacionTransportista>
Obligatorio, conforme tabla 6
Numérico
2
<rucTransportista>1796875790001</rucTransportista>
Obligatorio Alfanumérico
Max 13
<rise>Contribuyente Regimen Simplificado RISE</rise>
Obligatorio cuando corresponda
Alfanumé
rico
Max 40
<obligadoContabilidad>SI</ obligadoContabilidad >
Obligatorio cuando corresponda
Texto
SI / NO
<contribuyenteEspecial>5368</contribuyenteEspecial>
Obligatorio cuando corresponda
Alfanumé
rico
Max 13
<fechaIniTransporte>21/10/2011</fechaIniTransporte>
Obligatorio Fecha dd/mm/aaaa
<fechaFinTransporte>22/10/2011</fechaFinTransporte>
Obligatorio Fecha dd/mm/aaaa
<placa>MCL0827</placa> Obligatorio Alfanumérico
Max 20
</infoGuiaRemision> Obligatorio - -
- <destinatarios> Obligatorio - - - <destinatario> Obligatorio - -
<identificacionDestinatario>1716849140001</identificacionDestinatario>
Obligatorio Alfanumérico
Max 20
<razonSocialDestinatario>Alvarez Mina John Henry</razonSocialDestinatario>
Obligatorio Alfanumérico
Max 300
<dirDestinatario>Av. Simón Bolívar S/N Intercambiador</dirDestinatario>
Obligatorio Alfanumérico
Max 300
<motivoTraslado>Venta de Maquinaria de Impresión</motivoTraslado>
Obligatorio Alfanumérico
Max 300
<docAduaneroUnico>0041324846887</docAduaneroUnico>
Obligatorio cuando corresponda
Alfanumé
rico
Max 20
<codEstabDestino>001</codEstabDestino>
Obligatorio cuando corresponda
Numérico
3
107
- <infoTributaria> Obligatorio - -
<ambiente>1</ambiente> Obligatorio, conforme tabla 4
Numérico 1
<tipoEmision>1</ tipoEmision> Obligatorio, conforme tabla 2
Numérico 1
<razonSocial>Distribuidora de Suministros Nacional S.A.</razonSocial>
Obligatorio Alfanumérico Max 300
<nombreComercial>Empresa Importadora y Exportadora de Piezas </ nombreComercial >
Obligatorio cuando corresponda
Alfanumérico Max 300
<ruc>1792146739001001</ruc> Obligatorio Numérico 13
<claveAcceso>2110201104179214673900110020010000000011234567812</claveAcceso>
Obligatorio, conforme tabla 1
Numérico 49
<codDoc>04</codDoc> Obligatorio conforme tabla 3
Numérico 2
<estab>002</estab> Obligatorio Numérico 3
<ptoEmi>001</ptoEmi> Obligatorio Numérico 3
<secuencial>000000001</secuencial> Obligatorio Numérico 9
<dirMatriz>ENRIQUE GUERRERO PORTILLA OE1-34 AV. GALO PLAZA LASSO</dirMatriz>
Obligatorio Alfanumérico Max 300
</infoTributaria> Obligatorio - -
<infoNotaCredito> Obligatorio - -
<fechaEmision>21/10/2012</fechaEmision>
Obligatorio Fecha dd/mm/aaaa
<dirEstablecimiento>Sebastián Moreno S/N Francisco García</ dirEstablecimiento>
Obligatorio cuando corresponda
Alfanumérico Max 300
<tipoIdentificacionComprador>04</ tipoIdentificacionComprador >
Obligatorio, conforme tabla 6
Numérico 2
<razonSocialComprador>PRUEBAS SERVICIO DERENTAS INTERNAS</razonSocialComprador>
Obligatorio Alfanumérico Max 300
<identificacionComprador>1713328506001</identificacionComprador>
Obligatorio Alfanumérico Max 20
108
<contribuyenteEspecial>5368</contribuyenteEspecial>
Obligatorio cuando corresponda
Alfanumérico Max 13
<obligadoContabilidad>SI</ obligadoContabilidad>
Obligatorio cuando corresponda
Texto SI / NO
<rise>Contribuyente Régimen Simplificado RISE</rise>
Obligatorio cuando corresponda
Alfanumérico Max 40
<codDocModificado>01</codDocModificado>
Obligatorio, conforme tabla 3
Numérico 2
<numDocModificado>002-001-000000001</numDocModificado>
Obligatorio Numérico 15
<fechaEmisionDocSustento>21/10/2011</fechaEmisionDocSustento>
Obligatorio Fecha dd/mm/aaaa
<totalSinImpuestos>295000.00</totalSinImpuestos>
Obligatorio Numérico Max 14
<valorModificacion>346920.00</valorModificacion>
Obligatorio Numérico Max 14
<moneda>DOLAR</moneda> Obligatorio cuando corresponda
Alfanumérico Max 15
<totalConImpuestos> Obligatorio - -
<totalImpuesto> Obligatorio - -
<codigo>3</codigo >
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>3072</ codigoPorcentaje>
Obligatorio, conforme tabla 18
Numérico
Min 1 Max
4
ETIQUETAS O TAGS CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<baseImponible>295000.00</ baseImponible > Obligatorio Numérico Max 14
<valor>14750.00</valor > Obligatorio Numérico Max 14
</totalImpuesto > Obligatorio - -
<totalImpuesto> Obligatorio - -
109
<codigo>2</codigo >
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>2</ codigoPorcentaje>
Obligatorio, conforme tabla 17
Numérico
Min 1 Max
4
<baseImponible>339250.25</ baseImponible > Obligatorio Numérico Max 14
<valor>37170.00</valor > Obligatorio Numérico Max 14
</totalImpuesto > Obligatorio - -
</totalConImpuestos > Obligatorio - -
<motivo>DEVOLUCIÓN</motivo> Obligatorio Alfanumérico Max 300
</infoNotaCredito> Obligatorio - -
- <detalles> Obligatorio - -
- <detalle> Obligatorio - -
<codigoInterno>125BJC-01</codigoInterno > Opcional Alfanumérico Max 25
<codigoAdicional>1234D56789-A</codigoAdicional>
Obligatorio cuando corresponda
Alfanumérico Max 25
<descripcion>CAMIONETA 4X4 DIESEL 3.7</descripcion>
Obligatorio Alfanumérico Max 300
<cantidad>10.00</cantidad> Obligatorio Numérico Max 14 <precioUnitario>30000.00</precioUnitario>
Obligatorio Numérico Max 14
<descuento>5000.00</descuento> Obligatorio cuando corresponda
Numérico Max 14
<precioTotalSinImpuesto>295000.00</ precioTotalSinImpuesto>
Obligatorio Numérico Max 14
<detallesAdicionales> Obligatorio cuando corresponda
<detAdicional nombre="Marca" valor="Chevrolet"/>
Obligatorio cuando corresponda
Alfanumérico Max 300
<detAdicional nombre="Modelo" valor="2012"/> Obligatorio cuando corresponda
Alfanumérico Max 300
<detAdicional nombre="Chasis" valor="8LDETA03V20003289"/>
Obligatorio cuando corresponda
Alfanumérico Max 300
</detallesAdicionales> Obligatorio cuando corresponda
- <impuestos> Obligatorio - -
110
- <impuesto> Obligatorio - -
<codigo>3</codigo>
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>3072</codigoPorcentaje>
Obligatorio, conforme tabla 18
Numérico
Min 1 Max
4
<tarifa>5</ tarifa> Obligatorio cuando corresponda
Numérico Min 1 Max 3
<baseImponible>295000.00</baseImponible> Obligatorio Numérico Max 14
<valor>14750.00</valor> Obligatorio Numérico Max 14
-</impuesto> Obligatorio - -
-<impuesto> Obligatorio - -
ETIQUETAS O TAGS CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<codigo>2</codigo>
Obligatorio, conforme tabla 16
Numérico
1
<codigoPorcentaje>2</codigoPorcentaje>
Obligatorio, conforme tabla 17
Numérico
Min 1 Max
4
<tarifa>12</ tarifa> Obligatorio cuando corresponda
Numérico Min 1 Max 4
<baseImponible>309750.00</baseImponible> Obligatorio Numérico Max 14
<valor>37170.00</valor> Obligatorio Numérico Max 14
-</impuesto> Obligatorio - -
</impuestos> Obligatorio - -
- <detalle> Obligatorio - -
- <detalles> Obligatorio - -
- <infoAdicional>
Obligatorio cuando corresponda
-
-
<campoAdicional nombre="E-MAIL">[email protected]</campoAdicional>
Obligatorio cuando correspond
Alfanuméric
o
Max 300
111
4.2.5 Formato XML nota debito
ETIQUETAS O TAGS CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
Obligatorio
-
-
<notaDebito version="1.0.0" id="comprobante"> Obligatorio - -
<infoTributaria> Obligatorio - -
<ambiente>1</ambiente>
Obligatorio, conforme tabla 4
Numérico
1
<tipoEmision>1</tipoEmision> Obligatorio
, conforme tabla 2
Numérico
1
<razonSocial>PRUEBA</razonSocial>
Obligatorio
Alfanumérico
Max 300
<nombreComercial>PRUEBA 2</nombreComercial> Obligatorio
cuando corresponda
Alfanumérico
Max 300
<ruc>1760013210001</ruc> Obligatorio Numérico 13
<claveAcceso>2103201605176001321000110010010000000011234567814</claveAcceso>
Obligatorio, conforme tabla 1
Numérico
49
<codDoc>05</codDoc>
Obligatorio conforme tabla 3
Numérico
2
<estab>001</estab> Obligatorio Numérico 3 <ptoEmi>001</ptoEmi> Obligatorio Numérico 3 <secuencial>000000001</secuencial> Obligatorio Numérico 9 <dirMatriz>SALINAS</dirMatriz> Obligatorio Alfanumérico Max 300
</infoTributaria> Obligatorio - - <infoNotaDebito> Obligatorio - -
<fechaEmision>21/03/2016</fechaEmision> Obligatorio Fecha dd/mm/aaaa
<dirEstablecimiento>PÁEZ</dirEstablecimiento>
Obligatorio cuando corresponda
Alfanumérico
Max 300
<tipoIdentificacionComprador>04</tipoIdentificacionComprador>
Obligatorio conforme tabla 6
Alfanumérico
Max 20
<razonSocialComprador>PRUEBA SRI</razonSocialComprador>
Obligatorio
Alfanumérico
Max 300
a
</infoAdicional>
Obligatorio cuando corresponda
-
-
</notaCredito> Obligatorio - -
112
<identificacionComprador>1713328506001</identificacionComprador>
Obligatorio Alfanumérico Max 20
<contribuyenteEspecial>12345</contribuyenteEspecial>
Obligatorio cuando corresponda
Alfanumérico
Max 13
<obligadoContabilidad>SI</obligadoContabilidad>
Obligatorio cuando corresponda
Texto
SI / NO
<codDocModificado>01</codDocModificado> Obligatorio
, conforme tabla 3
Numérico
2
<numDocModificado>001-001-112312315</numDocModificado>
Obligatorio
Numérico
15
<fechaEmisionDocSustento>21/03/2016</fechaEmisionDocSustento>
Obligatorio
Fecha
dd/mm/aaaa
<totalSinImpuestos>50.0</totalSinImpuestos> Obligatorio Numérico Max 14
<impuestos> Obligatorio - -
<impuesto>
Obligatorio
-
-
<codigo>2</codigo> Obligatorio,
conforme tabla 16
Numérico
1
<codigoPorcentaje>2</codigoPorcentaje>
Obligatorio, conforme tabla 17
Numérico
Min 1 M ax 4
<tarifa>12.00</tarifa> Obligatorio Numérico Min 1 M ax 4
<baseImponible>50.0</baseImponible> Obligatorio Numérico Max 14
<valor>6.00</valor> Obligatorio Numérico Max 14
</impuesto> Obligatorio - -
</impuestos> Obligatorio - -
ETIQUETAS O TAGS
CARÁCTER
TIPO DE CAMPO
LONGITUD / FORMATO
<valorTotal>56.00</valorTotal> Obligatorio Numérico
Max 14
<pagos> Obligatorio - -
<pago> Obligatorio - -
<formaPago>17</formaPago>
Obligatorio, conforme tabla 24
Numéric
o
2
<total>56,00</total> Obligatorio Numérico
Max 14
<plazo>15<plazo>
Obligatorio, cuando
Numéric
o
Max 14
113
corresponda
<unidadTiempo>dias</unidadTiempo>
Obligatorio, cuando corresponda
Texto
Max 10
</pago>
Obligatorio
-
-
</pagos>
Obligatorio
-
-
</infoNotaDebito> Obligatorio - -
<motivos> Obligatorio - -
<motivo>
Obligatorio
-
-
<razon>Interés por mora</razon> Obligatorio Alfanumérico
Max 300
<valor>50.00</valor>
Obligatorio
Alfanum
érico
Max 300
</motivo>
Obligatorio
-
-
</motivos>
Obligatorio
-
-
<infoAdicional> Obligatorio - -
<campoAdicional nombre="Dirección">AMAZONAS S/N ROCA</campoAdicional>
Obligatorio cuando corresponda
Alfanum
érico
Max 300
<campoAdicional nombre="Email">[email protected]</campoAdicional>
Obligatorio cuando corresponda
Alfanumérico
Max 300
<campoAdicional nombre="Teléfono">0222222222222 ext. 3322</campoAdicional>
Obligatorio cuando corresponda
Alfanum
érico
Max 300
</infoAdicional>
Obligatorio
-
-
</notaDebito>
Obligatorio
-
-
4.5 Encuesta relacionada al Sistema gestor y receptor de comprobantes electrónicos
ENCUESTA RELACIONADA AL ANÁLISIS Y DESARROLLO DE UN SISTEMA DE GESTOR Y RECEPTOR DE COMPROBANTES ELECTRÓNICOS UTILIZANDO LAS NORMAS DE SEGURIDAD DE
114
ENCRIPTACIÓN DE LOS DATOS CON CIFRADO ASIMÉTRICO, PARA EL PERSONAL DE LA EMPRESA FIXED S.A
Edad: años Sexo: M F VALORACION EXCELENTE 5 MUY BUENO 4 BUENO 3 MALO 2 MUY MALO 1
Solicito me brinde 15 minutos de su tiempo para responder la siguiente
encuesta la cual me ayudará a determinar mejoras del mismo.
Instrucciones: Marque la respuesta que usted considere apropiada • Seleccione una
opción respuesta por cada pregunta con una (x)
PREGUNTAS
1. ¿Considera que el Software es amigable? BUENO MALO MUY BUENO MUY MALO EXCELENTE
2. ¿El software Funciono correctamente? BUENO MALO MUY BUENO MUY MALO EXCELENTE
3. ¿Tuvo problemas al generar la firma y el comprobante electrónico? BUENO MALO MUY BUENO MUY MALO EXCELENTE
4. ¿Tuvo inconvenientes con el módulo de configuraciones? BUENO MALO MUY BUENO MUY MALO EXCELENTE
5. ¿No tuvo inconvenientes al manipular el módulo de administrador de correo? BUENO MALO MUY BUENO MUY MALO EXCELENTE
115
6. ¿Tuvo problemas al reenviar los comprobantes electrónicos en lotes? BUENO MALO MUY BUENO MUY MALO EXCELENTE
7. ¿Considera que el sistema es complicado de manejar? BUENO MALO MUY BUENO MUY MALO EXCELENTE
116
Bibliografía
Arias, Á. (2014). Bases de datos con MySQL: 2ª Edición. Vigo: IT Campus
Academy.
ESCUELA, DEING. (s.f.). Base de datos.
Fergurson, J., Patterson, B., Beres, J., Boutquin, P., & Gupta, M. (2003). La biblia
de C#. Madrid: EDICIONES ANAYA MULTIMEDIA.
Fernández, G. (2014). Introducción a las metodologías ágiles. España, Barcelona:
Universidad Oberta de Catalunya.
Gabillaud, J. (2015). SQL Server 2014 SQL, Transact SQL: diseño y creación de
una base de datos. Barcelona: ENI.
Gallego, M. T. (2014). Metodología Scrum. Gestión de Proyectos Informáticos, 1-
55.
Herranz, R. (2016). Despegar con Scrum. Madrid: Utópica Informática.
http://www.justicia.gob.ec. (01 de 05 de 2014). http://www.justicia.gob.ec.
Obtenido de http://www.justicia.gob.ec : http://www.justicia.gob.ec/wp-
content/uploads/2014/05/c%C3%B3digo_org%C3%A1nico_integral_pena
l_-_coip_ed._sdn-mjdhc.pdf
Menzinsky, A., López, G., & Palacio, J. (2016). Guía de Scrum Manager.
Zaragoza: lubaris Info 4 Media SL.
Microsoft. (28 de mayo de 2017). Microsoft Developer Network. Obtenido de
Microsoft Developer Network: https://msdn.microsoft.com/es-
es/library/bb545450.aspx
Pérez Mora, Ó. (2005). Bases de datos. Catalunya: Universitat Oberta de
Catalunya.
Samaniego García, K. (15 de junio de 2017). Devexpress el mejor aliado:
Dawconsblog. Obtenido de Dawconsblog:
http://dawconsblog.blogspot.com/2014/04/devexpress-el-mejor-aliado-en-
el.html
Snyder, C. S. (2014). A Guide to the Project Management Body of Knowledge:
PMBOK (®) Guide. Project Management Institute.
SRI. (30 de 09 de 2014). http://www.sri.gob.ec. Obtenido de http://www.sri.gob.ec:
http://www.sri.gob.ec
SRI. (30 de 09 de 2014).
http://www.sri.gob.ec/DocumentosAlfrescoPortlet/descargar/cea483e1-
117
ab3a-4b95-b11f-40723d16cf7f/NAC-DGERCGC14-00790.pdf. Obtenido
de http://www.sri.gob.ec/DocumentosAlfrescoPortlet/descargar/cea483e1-
ab3a-4b95-b11f-40723d16cf7f/NAC-DGERCGC14-00790.pdf:
http://www.sri.gob.ec
SRI. (01 de 10 de 2015). http://www.sri.gob.ec. Obtenido de http://www.sri.gob.ec:
http://www.sri.gob.ec
SRI. (11 de 07 de 2016 ).
http://www.sri.gob.ec/DocumentosAlfrescoPortlet/descargar/072d8f12-
1ac1-42cf-a301-81b74ead0da0/NAC-DGERCGC16-00000287.pdf.
Obtenido de
http://www.sri.gob.ec/DocumentosAlfrescoPortlet/descargar/072d8f12-
1ac1-42cf-a301-81b74ead0da0/NAC-DGERCGC16-00000287.pdf:
http://www.sri.gob.ec/web/guest/base-legal-comprobantes-electronicos
SRI. (11 de 07 de 2016). http://www.sri.gob.ec. Obtenido de http://www.sri.gob.ec:
http://www.sri.gob.ec/web/guest/base-legal-comprobantes-electronicos
Módulo de seguridad y acceso
1. Inicio de sesión datos del usuario
a. Escriba su usuario
b. Escriba su contraseña
c. De click en el botón aceptar pata ingresar
d. De click en el botón cancelar si desea desistir del ingreso al sistema
2. Datos de la empresa y sucursal en la que se desea logear
a. Seleccione una empresa
b. Seleccione una sucursal “Opcional”
c. De click en el botón aceptar para acceder
d. De click en el botón cancelar si desea desistir del ingreso al sistema
a
b
d c
a
b
c d
3. Entorno de trabajo y menú de opciones
a. Área de trabajo
b. Menú de opciones
c. Formularios de click en la fecha con dirección hacia abajo para ver los formularios o ventanas abiertas
d. Tema de click en la fecha con dirección hacia abajo para ver los las opciones de temas
a b
c d
4. Consulta y modificación de menú del sistema
En la parte superior se reflejan los botones de opciones de nuevo, modificar, consultar,
anular, salir.
Para modificar o consultar un registro de clik sobre el registro requerido luego presione
el botón de la acción.
5. Registro de un nuevo menú del sistema
De click en el botón nuevo de la ventana de consulta mostrada en el índice numero 4
a. Escriba el nombre del menú que se reflejara en el árbol de opciones del menú
b. Escriba o incremente o decremente el nivel
c. Escriba el nombre del formulario
d. Escriba el nombre del asemble
e. Seleccione la opción donde pertenecerá el menú
6. Menú por empresa
a. Seleccione o busque la opción menú por empresa en el árbol de opciones
b. Seleccione la empresa
a
b
c
d
e
c. Seleccione las opciones que desea asignar a la empresa seleccionada
d. De click en el botón guardar o guardar y salir
7. Menú por empresa y por usuarios
a. Seleccione o busque la opción menú por empresa en el árbol de opciones
b. Seleccione la empresa
c. Seleccione las opciones que desea asignar a la empresa seleccionada
d. De click en el botón guardar o guardar y salir
8. Consulta y modificación de usuarios
En la parte superior se reflejan los botones de opciones de nuevo, modificar, consultar,
anular, salir.
Para modificar o consultar un registro de clik sobre el registro requerido luego presione el
botón de la acción.
9. Creacion de un nuevo usuario
a. De click en el botón nuevo ubicado en la parte superior de la consulta
b. Escriba el nombre de usuario
c. Escriba contraseña para el usuario
d. Escriba nombre del usuario
e. Seleccione las empresas que el sistema tendrá acceso
Módulo de configuración general y por empresa
Configuración por empresa
1. Configuración de reporte mediante diseñador de reporte
a. De clik en la opción diseñador de reporte
b. Seleccione un registro
c. De click en el botón diseñador de reporte
2. Mantenimiento de empresa
De click en empresas en el menú de opciones
a. De click en un registro si desea consultar o modificar
b. De clik en el botón nuevo si desea registrar una nueva empresa
c. Datos generales
d. Ambiente de emisión de los comprobantes al SRI
e. Datos del certificado digital
f. Parámetros de reportaría
g. Alerta y notificaciones
h. Parámetros de integración con otros sistemas
3. Parametrización de directorio de comprobantes
a. De click en directorio de comprobante
b. Escriba la ruta principal de los comprobantes
c. Describa la ruta de repositorios de comprobantes
d. Describa la ruta para los comprobantes validos
e. Describa la ruta para los certificados digital de la firma electrónica
f. Describa la ruta para los comprobantes con errores
4. Parametrización de WS del SRI
a. De click en Parámetros Web service SRI
b. Escriba la url para recepción de comprobantes de ambiente de prueba
c. Escriba la url para recepción de comprobantes de ambiente de producción
d. Escriba la url para autorización de comprobantes de ambiente de prueba
e. Escriba la url para autorización de comprobantes de ambiente de producción
f. Describa os datos del proxy de ser necesario
a
b
c
d e
f
f
e
d
c
b
a
Módulo de facturación electrónica
5. Clientes y proveedores
a. Únicamente es una cónsulta de contribuyente debido que el sistema los crea
automáticamente con los datos proporcionados en el XML.
6. Actualización de comprobantes en base sistema Administrativo
a. Seleccione un rango de fecha
b. Comprobantes pendientes de exportar aparecen los comprobantes que no han
sido exportado al sistema contable
c. Comprobantes exportados, se visualizan los comprobantes exportados ya al
sistema externo.
d. Consulta de comprobante en base externa
e. Calendario aquí se parametriza en el intervalo de tiempo que se exportaran los
comprobantes a la base externa en caso de que exista una previa programación.
a
b c d f
7. Comprobantes recibidos
En esta opción se podría visualizar los comprobantes recibidos por ya sea de clientes o de proveedores.
a. De click en la opción comprobantes recibidos en el árbol de menú de opciones
b. Escoja un rango de fecha
c. Si desea realizar una búsqueda avanzada puede escribir nombre del cliente o proveedores o número de comprobante
d. Seleccione un numero de página por hoja
e. Seleccione el tipo de comprobantes que desea visualizar ya sea por .pdf o XML
f. De click en el botón buscar
g. Puede descargar los comprobantes como pdf o XML dando click en los botones de descarga
b d g
f
d
e
c
8. Comprobantes en repositorios
a. Permite refrescar la grid
b. Ejecuta el proceso de validar los XML
c. Copia los archivos en la carpeta comprobantes validos o comprobantes no validos según sea el caso y
adicionalmente graba el registro en la base de datos
d. imprime los registro visible de la grid
9. Comprobantes validos
a. Permite refrescar la grid
b. Ejecuta el proceso de envió de comprobantes
c. Visualización de proceso de los hilos por firma de documentos
d. Detalle de error en caso de que exista un error
a b c d
d c
a b
1. Comprobantes sin respuesta del SRI
a. Permite refrescar la grid
b. Ejecuta el proceso de petición de autorización al SRI
a b
Módulo de Email
1. Creacion de cuenta de correo
a. Nombre de la cuenta
b. Dirección de correo desde donde se enviran los correos
c. Cuenta a la que se emitirá una copia por email enviado.
d. Cuenta a la que se emitirá un email por comprobante no autorizado
e. Seleccione el tipo de cuenta
f. Escoja el tipo de autentificación
g. Servidor entrante
h. Servidor saliente
i. Datos del login de la cuenta
j. Parámetros del servidor de salida
k. Parámetros del servidor entrante
a b
c d
e
J f
i
h
g
k
2. Administrador de correo
a. De clik para descargar los correos recibido de la cuenta configurada
b. Cancelar descarga
c. Cuenta de correo
d. De clik para ver los correos del buzón de entrada
e. De clik para ver los correos del buzón de salida
f. De clik para ver los correos eliminados
g. De clik para ver los correos emitidos
h. De clik para ver los correos enviados con errores
e
e
d
c b a
f
g