3560902038406UTFSM
3560902038406UTFSM
3560902038406UTFSM
2016
DISEÑO, IMPLEMENTACIÓN Y
EVALUACIÓN COMPARATIVA DE
COMPONENTE DE FACTURACIÓN ELECTRÓNIC
http://hdl.handle.net/11673/19926
Downloaded de Peumo Repositorio Digital USM, UNIVERSIDAD TECNICA FEDERICO SANTA MARIA
UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA
DEPARTAMENTO DE INFORMÁTICA
SANTIAGO - CHILE
NOVIEMBRE- 2016
Agradecimientos
Mis agradecimientos van a mi madre y tía, que fueron incondicionalmente presentes y me
brindaron siempre su apoyo, como a la empresa Arteformas por contribuir en la formulación
de este trabajo. También a la UTFSM y a sus profesores, que brindaron gran parte de mi
formación académica.
i
Resumen
En este trabajo se propondrá un componente de facturación electrónica que pretende asistir el
desarrollo de sistemas ERP a medida, poniendo énfasis en aquellos que por su rubro o
procesos internos, la compra de un ERP comercial no se apega a su funcionamiento. El
desarrollo del componente se encuentra basado en el ecosistema de gemas de Ruby:
RubyGems, y es integrado posteriormente a un sistema web basado en el framework del
mismo lenguaje Ruby on Rails.
Abstract
This component will propose a component of electronic invoicing that pretends to assist the
development of tailored EPR systems, putting emphasis in those that because of their area of
operation or internal processes, the bought of a commercial ERP system doesn’t fit to their
functions. The development of the component is being based around the gem ecosystem of
Ruby: RubyGems, and thereafter is integrated to a web system based on the same language
framework: Ruby on Rails.
Additionally, a rubric will be proposed and used in the evaluation of components of electronic
invoicing. From the results encountered at the evaluation, the benefits and cons of each
solution will be profiled, identifying scenarios which favor the choice of one component
above the rest.
ii
Glosario
− Application Program Interface (API): especificación que consiste en una serie de
reglas que permite a distintos productos de software comunicarse entre sí.
− Black-Box: hace referencia a la naturaleza de los componentes, que son vistos como
una serie de entradas y salidas que estos pueden proveer, sin conocimiento de su
funcionamiento interno (como una caja negra).
− Certificado Digital: Documento electrónico generado por un prestador de servicios
acreditado en la materia, que permite la autenticación de un contribuyente. Puede ser utilizado
en el sitio web del SII o para la emisión y firmas de un DTE.
− Código de Autorización de Folios (CAF): documento entregado por el SII que
autoriza al contribuyente la emisión de un rango de DTE de un tipo. La generación de los
DTE requiere información del CAF para tener validez.
− Código de Autorización de Libros (CAL): Símil del CAF para los libros de compra y
venta electrónicos.
− Contribuyente: Son las personas naturales o jurídicas, o los administradores o
tenedores de bienes ajenos afectados por impuestos.
− Contribuyente electrónico: Contribuyente autorizado por el SII para la emisión (y
recepción) de documentos tributarios electrónicos.
− Commercial Off The Shelf (COTS): componentes distribuidos comercialmente por un
proveedor para su reuso en productos de propiedad de un cliente.
− Computer Line Interface (CLI): modo de interacción en que el usuario envía comando
al programa en forma de sucesivas líneas de texto (comandos). Provee una forma de
comunicación únicamente basada en input y output textual.
− Documento Tributario: documento emitido que respalda la entrega de bienes, o
préstamo de servicios, y que está gravado con tributos.
− Documento Tributario Electrónico (DTE): documento generado y firmado
electrónicamente por un emisor electrónico, que produce efectos tributarios y cuyo formato
está establecido por el Servicio de Impuestos Internos.
− Enterprise Resources Planning (ERP): sistemas de información que tienen por
finalidad el manejo de los recursos económicos de una compañía, en relación a procesos de
planificación, producción, inventario, envío, finanzas, entre otros.
− Framework: estructura reusable que permite la construcción de un producto de
software, mediante la extensión de un producto genérico diseñado para este propósito.
− In-House: conducir una actividad, operación o mantener un activo al interior de la
empresa, sin apoyarse en una entidad externa para esto.
− Model View Controller (MVC): patrón de arquitectura de software que separa un
producto de software en tres partes: modelo, vista y controlador.
− On-Demand: servicio disponible al momento que se requiere, y que es cobrado en
relación a su frecuencia y/o intensidad de uso.
iii
− ORM: técnica que permite la manipulación de información relacional de una base de
datos utilizando un paradigma orientado a objetos.
− PDF417: formato de código de barras bidimensional. Es utilizado en las muestras
impresas de los DTE para codificar algunos datos del documento, permitiendo validarlo fuera
de línea.
− RUN: Rol Único Nacional (RUN). Identificador similar al RUT que se le otorga a
personas naturales. Sirve como identificador ante el Servicio de Impuestos Internos y ante
todo otro organismo del Estado.
− RUT: Rol Único Tributario (RUT). Es un identificador único que se asigna a
entidades jurídicas una vez dado cuenta del inicio de actividades. Es utilizado universalmente
por los organismos del Estado para identificar las entidades.
− Simple Object Access Protocol (SOAP): protocolo para el intercambio de
información estructurada en servicios web. Utiliza el formato XML para la codificación de los
mensajes.
− SII: Sigla de Servicio de Impuestos Internos. organismo público que realiza la
aplicación y fiscalización del pago de impuestos internos en Chile.
− Stakeholder: Actor clave que tiene esta involucrado en el desarrollo de un producto de
software, necesitando una solución óptima atingente a sus intereses.
− Universal Description, Discovery and Integration (UDDI): protocolo que permite el
descubrimiento de servicios web WSDL mediante el envío de mensajes SOAP.
− Web Services Description Language (WSDL): Formato XML utilizado para la
descripción de servicios web. Provee una definición abstracta de los tipos y las operaciones
provistas por este, permitiendo ser ligado a un protocolo concreto de red. Puede ser utilizado
en conjunción a SOAP o API’s HTTP para poner a disposición un servicio en particular.
− XML (eXtensive Markup Language): Metalenguaje extensible de etiquetas que
permite la definición de lenguajes específicos a un dominio para organizar y etiquetar
información. Es utilizado ampliamente por el SII para especificar el formato de los DTE,
CAF, CAL y otros documentos electrónicos.
iv
Índice
Agradecimientos ......................................................................................................................... i
Resumen .................................................................................................................................... ii
Abstract ...................................................................................................................................... ii
Glosario..................................................................................................................................... iii
Índice ......................................................................................................................................... v
Introducción ............................................................................................................................ viii
Capítulo 1: Contexto .................................................................................................................. 1
1.1 Definición inicial del problema ................................................................................. 1
1.2 Facturación electrónica en Chile ...................................................................................... 3
1.2.1 Normativa legal previa a obligatoriedad ................................................................... 3
1.2.2 Normativa legal vigente ............................................................................................ 5
1.2.3 Descripción del sistema ............................................................................................ 7
1.2.4 Certificado digital ..................................................................................................... 8
1.2.5 Modelo de operación para contribuyentes .............................................................. 10
1.2.6 Proceso de postulación, certificación y autorización, Ambiente de pruebas .......... 12
1.3 Objetivo General ............................................................................................................ 16
1.4 Objetivos secundarios .................................................................................................... 16
Capítulo 2: Estado del arte ....................................................................................................... 17
2.1 Soluciones de Facturación Electrónica en Sistemas ERP .............................................. 17
2.2 Componentes de Facturación Electrónica ...................................................................... 19
2.3 Otras soluciones existentes ............................................................................................ 22
Capítulo 3: Propuesta específica .............................................................................................. 24
3.1 Arquitectura basada en componentes............................................................................. 24
3.1.1 Problemas asociados a Component-Based Architecture ......................................... 26
3.1.2 Reuso vs Component-Based-Architecture .............................................................. 27
3.2 Propuesta de componente y sistema ERP ...................................................................... 28
Capítulo 4: Desarrollo de Componente.................................................................................... 33
4.1 Exigencias impuestas por el SII ..................................................................................... 33
4.1.1 Generación de Documentos Tributarios Electrónicos (DTE) ................................. 33
v
4.1.2 Envío automático de DTE’s al SII .......................................................................... 39
4.1.3 Consulta de envío de los DTE ................................................................................ 40
4.1.4 Intercambio de DTE entre contribuyentes .............................................................. 40
4.1.5 Generación de copias impresas de los DTE ............................................................ 41
4.1.6 Generación y envío de información de compras y ventas....................................... 44
4.1.7 Herramientas de generación de pruebas para certificación ..................................... 45
4.2 Especificaciones de Sistema ERP .................................................................................. 46
4.2.1 Descripción General del Sistema ERP .................................................................... 46
4.2.2 Modelo de datos ...................................................................................................... 47
4.3 Implementación de componente y sistema ERP ............................................................ 47
4.3.1 Estructura de aplicación Rails ................................................................................. 47
4.3.2 Estructura de aplicación a desarrollar ..................................................................... 50
4.3.3 Gemas a utilizar ...................................................................................................... 50
4.3.4 Uso de engines en la aplicación .............................................................................. 51
4.3.5 Implementación del componente ............................................................................ 55
Capitulo 5: Evaluación y análisis comparativo de componentes ............................................. 57
5.1 Selección de Componentes ............................................................................................ 57
5.1.1 LibFacturista - FacturaElectronicaChile.com ......................................................... 57
5.1.2 LibreDTE-lib - LibreDTE ....................................................................................... 58
5.1.3 Facturación_Electronica ......................................................................................... 58
5.2 Modelos de calidad ........................................................................................................ 58
5.2.1 Primeros modelos de calidad .................................................................................. 58
5.2.2 Modelos de calidad para COTS .............................................................................. 61
5.3 Criterios de Evaluación .................................................................................................. 65
5.3.1 Atributos de calidad ................................................................................................ 65
5.3.2 Cobertura funcional ................................................................................................ 73
5.4 Evaluación de componentes........................................................................................... 74
5.4.1 Resultados de “Atributos de calidad” ..................................................................... 74
5.4.2 Resultados de “Cobertura funcional”...................................................................... 85
Capítulo 6: Validación ............................................................................................................. 87
6.1 Plan de transición y despliegue ...................................................................................... 88
6.1.1 Transición del sistema ERP .................................................................................... 88
vi
6.1.2 Despliegue de sistema ERP .................................................................................... 88
6.2 Identificación de escenarios ........................................................................................... 91
6.2.1 Discusión de resultados .......................................................................................... 91
6.2.2 Caracterización de componentes............................................................................. 93
Capitulo 7: Conclusiones ......................................................................................................... 95
Referencias .............................................................................................................................. 98
Anexo ..................................................................................................................................... 100
A - Casos de uso de sistema ERP ...................................................................................... 100
Iniciar Sesión ................................................................................................................. 100
Administrar Cuenta ........................................................................................................ 100
Administrar Vendedores ................................................................................................ 100
Administrar Clientes ...................................................................................................... 101
Administrar Láminas ..................................................................................................... 102
Administrar Artículos .................................................................................................... 102
Emitir o actualizar una guía de venta ............................................................................. 103
Emitir una factura a partir de una guía de venta ............................................................ 104
Emitir una factura electrónica a partir de una factura .................................................... 105
Obtener historial de un cliente ....................................................................................... 105
Ingresar cheque abonado por el cliente .......................................................................... 105
Administrar estados de guía de venta ............................................................................ 106
Administrar recargos y descuentos ................................................................................ 106
Administrar bancos y plazas .......................................................................................... 107
Imprimir o enviar por correo guía de venta ................................................................... 108
Imprimir lista de láminas ............................................................................................... 108
Imprimir factura electrónica .......................................................................................... 108
B - Esquemas de modelos de datos .................................................................................... 110
vii
Introducción
Debido a la creciente necesidad generalizada por parte de los contribuyentes a implementar
una solución de facturación electrónica en la empresa, se han abierto una serie de
problemáticas que estas deben enfrentar. Las empresas deberán adquirir nuevos productos de
software que operen en concordancia con el modelo operacional del SII.
Dependiendo del rubro, los sistemas ERP con facturación electrónica propuestas en el
mercado podrían no ajustarse demasiado a las necesidades del cliente, y en este caso, una
solución ajustada a medida deberá ser utilizada.
Este trabajo tiene como finalidad presentar una alternativa de facturación electrónica a los
contribuyentes y desarrolladores de soluciones, así como otorgar una guía de las obligaciones
a cumplir por parte de un software de facturación electrónica, y los procesos que el
contribuyente deberá integrar en su empresa. Como información adicional, este informe
entregará un criterio de evaluación de un tipo específico de soluciones de facturación
electrónica, con el fin de asistir a usuarios desarrolladores que necesiten integrar estas
funcionalidades a un sistema ERP completo, o un símil.
El presente informe comienza con una definición del contexto de la problemática específica a
tratar junto la normativa legal vigente en la materia en el capítulo 1, seguido de los objetivos a
cumplir en este trabajo. El capítulo 2 cubre las propuestas existentes en el mercado, de índole
general y las específicas a tratar. El capítulo 3 da el diseño de la propuesta específica a
desarrollar, la cual es elaborada en el capitulo 4, capitulo que otorga las bases técnicas de la
solución. El capitulo 5 contiene la rúbrica de evaluación propuesta, junto con la evaluación de
los candidatos. Luego en el capítulo 6 se discuten los resultados encontrados, y se establecen
algunas conclusiones a partir de estos. Finalmente, se da paso a las conclusiones generales de
este trabajo, junto a una síntesis de los puntos relevantes encontrados en la realización de este.
viii
Capítulo 1: Contexto
A modo de facilitar la comprensión de este trabajo, esta sección se propone entregar una
definición inicial del problema, la cual es detallada posteriormente con la explicación de las
bases legales que rigen la materia y los procesos que el SII demanda a los contribuyentes. Esta
base teórica permitirá entender el dominio del problema y posteriormente, los detalles
técnicos de la solución propuesta.
Las tecnologías de información (TI) ejercen roles bastante importantes en la sociedad actual.
Aplicaciones y servicios permiten agilizar algunos aspectos de nuestras vidas y resolver
problemas que antes no eran posibles o viables. Hoy en día podemos observar diversas
aplicaciones de las TI en salud, entretenimiento, comunicación, análisis científico,
administración de recursos, entre otros.
La organización moderna también hace uso de estas tecnologías. Pudiendo controlar de forma
automatizada como se llevan a cabo sus procesos de manufacturación, inventario, ventas,
finanzas, etc. El uso apropiado de estas otorga una base competitiva, con la cual una
organización puede destacar respecto a la competencia y mantenerse en el tiempo.
Para la integración con los modelos de operación basados en DTE, SII provee diversas
alternativas para los contribuyentes, estas son:
− Utilización del portal web MiPyme, que permite a empresas generar DTE’s
− Utilización de sistema de facturación del mercado
− Utilización de sistema de facturación de elaboración propia.
1
En relación a las últimas dos soluciones, el SII define un proceso de postulación y
certificación en donde los contribuyentes deben cumplir una serie de requisitos para obtener la
autorización por parte del SII para emitir los DTE.
Excluyendo las lógicas de cada organización en solución en particular, todas tienen que
cumplir con el estándar impuesto por el SII para la emisión de DTE de manera uniforme.
Sería deseable de este modo, la existencia de un software que se dedicara exclusivamente a
dicho propósito, y que pueda ser integrado con facilidad a un sistema de ventas, encargándose
éste exclusivamente de aquellas responsabilidades.
2
1.2 Facturación electrónica en Chile
La facturación electrónica en Chile se gestó de manera concreta el año 2003, cuando el SII
inició el proceso de masificación del sistema de facturación electrónica para todos los
contribuyentes que solicitaron voluntariamente su uso mediante una postulación. Esta
postulación define requisitos a cumplir, de tal manera que un contribuyente puede obtener una
resolución por parte del SII, que le permita ser habilitado como emisor y receptor de
documentos tributarios electrónicos. En adición a este proceso de postulación, el SII también
define un sistema de facturación electrónica gratuito, el cual queda de libre uso para los
contribuyentes que lo deseen.
Esta sección define sus contenidos en los subcapítulos 1 y 2 como un resumen de la normativa
legal previa y las modificaciones de la vigente actualmente. Luego se pretende otorgar una
descripción de la operación básica del sistema propuesto por el SII, el cual los contribuyentes
deben adoptar. El subcapítulo 4 explicará lo que dentro del modelo de funcionamiento se
entiende por certificado digital. El subcapítulo 5 se dedicará a explicar el modelo para los
contribuyentes de emisión y recepción de documentos tributarios electrónicos propuestos por
el SII. Finalmente, el subcapítulo 6 explicará las fases del proceso de postulación para
certificarse como contribuyente de documentos tributarios electrónicos.
Anterior a la ley actual de facturación electrónica (ley N° 20.727), la ley sobre impuesto a las
ventas y servicios definió las obligaciones de los contribuyentes afectos a IVA, los cuales
debían emitir ciertos documentos tributarios de manera física, consisten en formularios
previamente timbrados.
Este timbrado proveniente del SII autoriza a los contribuyentes a emitir el documento
tributario que respalda cierta operación comercial, otorgando validez a los documentos. En
caso de su ausencia, o de omitir la emisión de los documentos (realizar operaciones
comerciales que requieran documento tributario sin emitir este), el contribuyente se arriesga a
grandes multas o su cancelación del permiso para operar [3].
Los documentos tributarios que deben ser emitidos físicamente, son nombrados
principalmente del artículo 53 de la misma ley, y son los siguientes:
3
− Guía de despacho en caso de traslado de bienes importados asociados a una factura, la
cual es postergada
− Notas de Crédito y/o Débito por operaciones afectas
− Liquidación y Liquidación factura
Con la facultad legal que se le otorga al SII, y habiendo iniciado pruebas piloto el año 2002
con 8 empresas (Agrosuper, Embotelladora Andina, Entel PCS, Ideal, Montecarlo, NIC Chile
de la Universidad de Chile, Sodimac y Telefónica Móvil), el SII abre públicamente el 2 de
septiembre del 2003 el proceso de masificación de la facturación electrónica, poniendo a
disposición del proceso de postulación de manera pública todos los contribuyentes que deseen
adoptar el modelo de facturación electrónica1.
En este estado, el SII puede facultar a los contribuyentes a facturar electrónicamente sus
documentos tributarios, sin embargo, estos quedan en libertad de seguir emitiendo físicamente
trabajando con dos series de timbrado: uno para documentos físicos y otro para los
electrónicos, a modo que la numeración de los documentos nunca se intercepta. Esto no los
excluye de la recepción de documentos tributarios electrónicos, la cual pasa a ser una
obligatoriedad por parte de los contribuyentes.
En vista a este problema, el SII abre el año 2005 el portal MiPyme, el cual es un portal web
diseñado pensando en las pequeñas y medianas empresas que desean facturar
electrónicamente sin la necesidad de certificarse comprando un software de mercado o
desarrollando una solución personalizada. La legislación hace posible su uso el 1 de
septiembre del 2005, en la resolución exenta SII N°86, en el cual, dado que “el sistema de
facturación electrónica ha demostrado ser eficiente, seguro, facilitador del cumplimiento
tributario y redundar en la obtención de importantes beneficios económicos por parte de los
contribuyentes usuarios de este sistema”, otorga la autorización a contribuyentes que se
inscriban en el portal MiPyme para ser emisores de documentos tributarios electrónicos, a
aquellos que cumplan con una serie de requisitos.
1
Servicio de Impuestos Internos. SII inicia masificación de la factura electrónica [en línea]
<http://www.sii.cl/pagina/actualizada/noticias/2003/020903noti01jo.htm> [consulta: 26 octubre 2016].
4
La resolución ha sido modificada posteriormente en el año 2006 (Resolución exenta N°93 y
N°124) las cuales modifican la barrera de requerimientos en las cuales la utilización del portal
MiPyme se enmarca. Estas barreras son posteriormente removidas en el año 2014 en la
Resolución exenta N°99 en vista de la obligatoriedad propuesta por la Ley 20.727, derogando
las resoluciones anteriores y dejando solo aquellas condiciones que verifiquen el inicio de
actividades por parte del contribuyente y que este quede clasificado como contribuyente de
primera categoría.
La ley define un plazo antes de que la medida opere efectivamente de dos años, estableciendo
un periodo de transición que incluye la aplicación gradual de la obligación legal. Durante
dicho periodo se espera que en el mediano plazo la totalidad de los contribuyentes estén
operando con documentos tributarios electrónicos, lo cual irá aparejado de los importantes
beneficios anteriormente mencionados para los contribuyentes y el mismo SII. La disposición
transitoria propuesta por la ley obliga a empresas según su tamaño y ubicación, a adoptar la
facturación electrónica en distintos plazos. Los tiempos propios de cada tipo de empresa
quedan detallados en la figura 1.1.
5
Figura 1.1: Calendario de obligatoriedad según tamaño y ubicación de empresas definido por
el SII2.
− Contribuyente opera en una zona sin cobertura de datos móviles o fijos de operadores
de telecomunicaciones que tienen infraestructura.
− Contribuyente opera en una zona sin cobertura de suministro eléctrico.
− Contribuyente opera en zona declarada como catástrofe conforme a la ley Nº 16.282.
− Otras causales que el SII estime.
En dichos casos, el SII debe enviar una resolución identificando el grupo de contribuyentes
afectados por dicha situación, previo estudio de los organismos técnicos autorizados en la
materia. La resolución debe indicar además los plazos en la medida opere en vigencia.
También los contribuyentes pueden solicitar al SII una petición de excepción a la emisión de
DTE. En este caso se otorga al SII 30 días para estudiar la resolución y dar una respuesta,
entendiéndose transcurrido ese plazo sin respuesta, como solución aceptada. Durante el plazo
de espera, el SII deberá otorgar al contribuyente los documentos timbrados físicamente
necesarios para operar.
2
Servicio de Impuestos Internos. Aspectos Generales de la nueva Ley de Factura Electrónica (Ley
20.727 de 2014) [en línea] <http://www.sii.cl/factura_electronica/ley/ley_fe_20727.htm> [consulta: 26
octubre 2016].
6
1.2.3 Descripción del sistema
El sistema propuesto por el SII, permite a los contribuyentes que se encuentren autorizados
para emitir DTE mediante la certificación que lo avala, y poder realizar transacciones
comerciales que requieran el apoyo tributario con la utilización de estos documentos.
Similar a su contraparte física, DTE deben ser firmados y asignados a un contribuyente por
parte del SII. El contribuyente podrá solicitar una serie de folios a través del sitio web del SII,
de manera que con la utilización de estos folios (código de autorización de folios), podrá
generar DTE válidos que cuenta con la autorización del SII. La generación por parte del
emisor requiere ser firmada por medio de su certificado digital.
Al momento de realizar una transacción comercial que requiera la emisión de un DTE, este
deberá ser generado en conformidad con su estructura y transmitido al SII antes de la
recepción de bienes por parte del destinatario o su transporte. El emisor adicionalmente,
deberá hacer envío de este DTE al receptor vía correo electrónico, en caso de que esté
igualmente sea un contribuyente electrónicamente autorizado, si este no fuese el caso, el
emisor deberá hacer envío de una copia en papel.
De manera similar, el contribuyente deberá ser capaz también de recibir DTE de otros
contribuyentes a su casilla electrónica, los cuales deberán ser revisados y respondidos,
enviando mensajes de “acuse de recibo” al emisor del envío.
Cada DTE define su información mediante el metalenguaje XML, información que debe estar
correctamente estructurada de acuerdo a las especificaciones propuestas por el SII. Estas se
encargan de definir la obligatoriedad de que campos deben estar anexados en el, dependiendo
del tipo de DTE que se está emitiendo.
Todos los documentos deben contener un campo con un timbre electrónico para seguimiento
de su estado y que los fiscalizadores verifiquen la validez del documento fuera de línea, la
cual también puede ser verificada por los contribuyentes a través de una opción en el sitio web
del SII. El timbre electrónico consiste en una firma con los datos relevantes del DTE junto
con el código de autorización de folios (CAF) el cual debe ser solicitado previamente por el
contribuyente en el sitio web del SII. En el caso de documentos físicos, el timbre electrónico
es expresado mediante un código de barras bidimensional.
Adicional al timbre, todos los documentos deben ser firmados electrónicamente. Las firmas
son generadas por la llave privada de un certificado digital que una de las empresas
autorizadas concede al contribuyente. El detalle de este certificado será explicado en detalle
en la sección correspondiente a “Certificado digital”.
7
1.2.3.2 Almacenamiento de los DTE
Se requiere que los contribuyentes electrónicos almacenen los DTE de forma segura para
revisiones que el SII pueda exigir a los contribuyentes. El documento físico deja de tener
importancia para las revisiones y no es necesario su almacenamiento. En el caso del
contribuyente manual, la obligación de almacenar físicamente todos los documentos
tributarios que este recibe queda sin cambios.
8
algoritmo es asimétrico o simétrico, se define si el receptor debería utilizar la misma llave
para decodificar el mensaje.
Figura 1.2: Esquema de encriptación de mensaje con clave pública en criptografía con llaves
asimétricas3.
De esta forma los DTE son enviados utilizando encriptación asimétrica. A modo de garantizar
su integridad, es necesario generar un “fingerprint” del documento, el cual es un hash del
documento completo cifrado con la llave privada del emisor. Las llaves públicas de los
contribuyentes son almacenadas en los certificados digitales, las cuales quedan anexas y
suscritas a estos, a modo que se pueda probar la autenticidad de los DTE que estos emiten de
forma innegable y sin repudio. Los repositorios en los cuales se almacenan, y se generan los
certificados junto con las llaves privadas corresponden a los prestadores acreditados.
3
GENBETA DEV. Tipos de criptografía: simétrica, asimétrica e hibrida [en línea]
<http://www.genbetadev.com/seguridad-informatica/tipos-de-criptografia-simetrica-asimetrica-e-
hibrida> [consulta: 26 octubre 2016].
9
organismo el cual certifica la calidad de los prestadores es la Subsecretaría de Economía. Las
empresas que actualmente se encuentran acreditadas para prestar sus servicios según el sitio
web de SII son:
− Acepta.com
− E-CertChile
− E-Sign
− Certinet
El Modelo de operación propuesto es que las empresas contribuyentes deben adoptar para
emitir DTE y lograr pasar las pruebas del proceso de postulación. Los pasos propuestos
quedan descritos en el “Instructivo Técnico” y son los siguientes:
10
los rangos de folio que ha solicitado, de modo que cada DTE utilice solo un identificador y
que cada identificador sea anexado al CAF que lo generó, por lo que el sistema del
contribuyente debe ser capaz de realizar dichos procesos.
− Generar DTE en formato XML en conformidad con lo exigido por el SII: Cada DTE
deberá cumplir según su tipo con una estructura obligatoria de campos que lo representan,
bajo un esquema XML.
De forma adicional a los propuestos, se recomienda que el contribuyente se haga cargo de las
siguientes responsabilidades:
11
(IECV) del periodo, en un formato similar al de los DTE. Se debe considerar un proceso
automatizado que permita con la información disponible, generar los IECV.
El contribuyente puede postular en el sitio web del SII para ser aprobado como contribuyente
electrónico con la capacidad de enviar DTE. Los requisitos que un contribuyente debe cumplir
para poder postular son: haber dado inicio de actividades y que este quede clasificado como
contribuyente de primera categoría, en el caso de documentos afectos a IVA (como en el caso
de la factura electrónica), se requiere adicionalmente estar catalogado como contribuyente de
IVA y validar que mantiene actividades en terreno, o estar en proceso de validación de estas.
En este ambiente de pruebas, el contribuyente puede certificarse para ser admitido por el SII
para operar como contribuyente electrónico, para esto, el proceso de certificación considera 4
fases de pruebas que verifican la capacidad para llevar a cabo las tareas descritas en el modelo
de operación para contribuyentes5, estas fases son:
4
Servicio de Impuestos Internos. PROCEDIMIENTO DE POSTULACIÓN, CERTIFICACIÓN Y
AUTORIZACIÓN [en línea]
<http://www.sii.cl/factura_electronica/factura_mercado/proc_postulacion.htm> [consulta: 26 octubre
2016].
5
Servicio de Impuestos Internos. MANUAL PARA EMPRESAS USUARIAS [en línea]
<http://www.sii.cl/factura_electronica/factura_mercado/manual_certificacion.pdf> [consulta: 26
octubre 2016].
12
El contribuyente que desee completar el proceso de certificación debe completar cada una de
las pruebas sin objeciones por parte del SII. En adición a estas, para finalizar el proceso es
necesario emitir una declaración en la cual el contribuyente declara que cumple con los
requisitos mediante un soporte computacional adecuado. Cabe destacar que el proceso de
postulación permite al contribuyente operar bajo un ambiente de pruebas, por lo que la
implementación de los procesos que son exigidos al contribuyente en cada una de las fases,
puede ser llevado de manera incremental e incluso posterior al inicio de la postulación.
Una vez aceptada la postulación, el SII otorga al contribuyente la posibilidad de generar un set
de pruebas desde el ambiente de postulación, el cual consiste en una serie de datos ficticios
que el contribuyente debe emitir en DTE’s al SII. El set de pruebas considera un set de
documentos tributarios a enviar que por lo menos incluye factura electrónica, nota de crédito
electrónica y nota de débito electrónica. Como requerimiento adicional, se deben enviar libros
de compra y venta, los cuales deben ser construidos con la información dada en los DTE (en
el caso del libro de venta), y con información provista por el SII (en el caso del libro de
compra),
Los datos del set de pruebas deben ser enviados al SII exactamente como se le fueron
presentados y siguiendo las consideraciones de confección que el SII dispone, en un plazo
máximo de 2 meses posterior a la generación del set de pruebas.
Los documentos pueden ser comprobados dentro de ese plazo en el ambiente de postulación
las veces que se estime conveniente, hasta que estos se encuentren correctamente formulados
sin reparos, cuando eso se cumpla, el contribuyente podrá declarar su avance de la postulación
desde la web del ambiente de certificación.
El SII revisará los DTE generados a partir del set de pruebas, verificando la validez de estos
respecto al último set de pruebas generado.
6
Servicio de Impuestos Internos. MANUAL PARA EMPRESAS USUARIAS [en línea]
<http://www.sii.cl/factura_electronica/factura_mercado/manual_certificacion.pdf> [consulta: 26
octubre 2016].
13
En caso de rechazo, el contribuyente podrá reintentar el proceso, siempre que el envío esté
dentro del plazo de 2 meses posterior a la generación del set de pruebas, en caso contrario, el
contribuyente deberá generar un nuevo set de pruebas y confeccionar los DTE a partir de este.
Si el SII acepta el avance de postulación, el contribuyente podrá iniciar la fase 2 del proceso.
En esta fase se exige al contribuyente a emitir DTE al SII de facturas electrónicas con datos
representativos y reales de su rubro. El contribuyente deberá generar DTE respectivos a datos
de su facturación de los dos últimos meses, con un máximo de 100 documentos. En caso de
empresas con mayor flujo de información, los documentos pueden corresponder solo a un
mes, y en el caso de empresas con bajo volumen, los documentos pueden ser de más de dos
meses, pero cumpliendo un mínimo de 10 documentos. El SII verificará que el volumen de
DTE enviados sea similar al volumen histórico de documentos emitidos por el contribuyente.
Cuando el contribuyente esté conforme con su envío y este haya sido aceptado sin reparos,
podrá declarar su avance de la postulación, el cual será revisado por el SII al igual que la fase
anterior. Una vez que este sea aprobado, el contribuyente podrá iniciar la siguiente fase del
proceso.
Esta fase verifica que el contribuyente posea la capacidad de hacer recepción de DTE
recibidos por otros contribuyentes y que responda correctamente con acuse de recibo o
rechazo de acuerdo a las definiciones dadas por el SII.
El SII desde una casilla de correo especialmente habilitada para el proceso, enviará DTE al
contribuyente a la casilla de correo que esté asignó al momento de la postulación. Los DTE
deberán ser validados respecto al esquema XML específico de cada tipo de documento. Este
verificará la respuesta que el contribuyente realiza para cada uno de los DTE enviados en esta
fase, analizando su consistencia y correctitud en cada caso. Una vez que estas pruebas ocurran
y sea su correctitud verificada, el contribuyente podrá hacer inicio de la siguiente fase del
proceso.
Esta fase requiere al contribuyente la capacidad de generar documentos para ser impresos en
el formato acordado en el SII, el cual considera la impresión de un código de barras
bidimensional con la información del timbre electrónico (en el estándar PDF417).
14
Se necesita que el contribuyente envíe, a una casilla de correo especialmente designada para
el envío de estos, las imágenes generadas a partir de cada uno de los documentos generados
desde el set de pruebas, además de 10, los cuales deberán ser representativos de los tipos de
documentos que el contribuyente será autorizado a emitir.
Las imágenes deben ser enviadas a la casilla en un único documento PDF, el cual será
revisado por el SII. Una vez que este sea verificado, el SII declara la completitud del
contribuyente en todas las fases de pruebas del proceso de certificación, y que este se
encuentra listo para dar la declaración de cumplimiento de requisitos y finalizar el proceso.
El SII habilita la opción de otorgar una declaración en el cual el contribuyente, a través del
representante legal el cual está llevando a cabo el proceso de postulación. Dicha declaración
señala obliga a cumplir las declaraciones juradas que el SII emita respecto a la facturación
electrónica, que conoce las obligaciones que emanan de la autorización como contribuyente
electrónico y que además cuenta, con procesos establecidos y controlados, formas de tratar
procedimientos que el SII considera críticos. Estos son los siguientes7:
Una vez que el contribuyente emita la declaración de cumplimiento de requisitos, y con todas
las fases de certificación aprobadas, el SII finalizara el proceso de postulación, emitiendo una
resolución que autoriza al contribuyente a emitir DTE y este pasará al ambiente de
producción, en el cual podrá comenzar a generar DTE legalmente válidos a partir del periodo
tributario indicado en la resolución.
7
Servicio de Impuestos Internos. MANUAL PARA EMPRESAS USUARIAS [en línea]
<http://www.sii.cl/factura_electronica/factura_mercado/manual_certificacion.pdf> [consulta: 26
octubre 2016].
15
1.3 Objetivo General
− Diseñar un plan de transición y despliegue, que permita poner el sistema web ERP en
producción.
16
Capítulo 2: Estado del arte
Debido a la problemática, esta sección se enmarca en el estudio de distintas soluciones de
facturación electrónica existentes en el mercado, siendo la vasta mayoría sistemas que
integran funcionalidades esperadas en un ERP (“Enterprise Resources Planning”, o
planificación de recursos empresariales).
La minoría restante, otorga componentes de facturación electrónica, los cuales permiten ser
integrados a sistemas ya existentes. Se dará un vistazo a estos dos tipos de soluciones, siendo
nuestro foco de estudio las soluciones basadas en componentes.
Nubox: Empresa orientada a ofrecer aplicaciones web que son distribuidos desde su
infraestructura y accesibles desde cualquier equipo con conexión a internet. Ofrecen distintas
sub-aplicaciones para el manejo de distintas necesidades de una empresa: contabilidad, pago
de remuneraciones, administración comercial, control de existencias e inventario, control de
activos fijos, gestión y facturación electrónica. Cada una de estas sub-aplicaciones puede ser
contratada en base a un plan mensual que dependerá de las necesidades de usuarios en el
sistema, cantidad de documentos de venta y en el caso de facturación electrónica, por la
cantidad de DTE emitidos8.
SoftLand: Ofrece dos líneas de soluciones para distintos tamaños de empresa. SoftLand ERP
y SoftLand PYME. La primera provee en un solo servicio todos los módulos ERP disponibles,
la solución PYME divide sus soluciones en tres aplicaciones, para contabilidad, remuneración
de sueldos, y gestión comercial/POS (Point of sale). Siendo esta última la responsable de
8
Nubox. Factura electrónica Nubox | Software de facturación [en línea]
<http://www.nubox.com/software-de-factura-electronica.html> [consulta: 26 octubre 2016].
17
facturar electrónicamente. Ambas gamas de soluciones son provistas en aplicación de
escritorio que debe ser apoyada con infraestructura de servidores provista por empresa
cliente9.
SoftRam: Empresa provee dos soluciones de escritorio para apoyar empresas según su
tamaño: PymeXSys, orientada a la pequeña y mediana empresa, y SoftRam-ERP, para
grandes empresas. Las diferencias de las dos soluciones que proveen consisten en la cantidad
de módulos funcionales (suites) que poseen, siendo el módulo de facturación electrónica
integrado en ambas soluciones10. Softram además dispone de soluciones móviles para
necesidades de un POS (Point of Sale, o punto de venta), y de una solución de portal web para
manejo del área comercial, calidad de servicio y pago de liquidaciones de sueldo. Estas dos
últimas soluciones no consideran funcionalidades de facturación electrónica.
Defontana: Proveen un software ERP disponible para una plataforma web, el sistema
promete adaptarse a distintos rubros para cumplir sus necesidades específicas (producción,
minería, salud e inmobiliaria). En todas sus versiones, cuenta con integración a servicio de
facturación electrónica. Los planes están definidos de forma mensual y difieren en la cantidad
de módulos disponibles, numero de usuarios habilitados, y número de trabajadores que se
pueden gestionar dentro del software12.
Lanix: Empresa posee solución LanixERP bajo plataforma web, la cual consiste de módulos
que apoyan a tareas comunes de las organizaciones: Modulo de ventas, compras, inventario,
gestión de producción, contabilidad, tesorería y pago de remuneraciones. Cada módulo
interactúa con los otros para realizar sus funciones13.
9
Softland. Softland – Lo hacemos fácil [en línea] <http://www.softland.cl/> [consulta: 26 octubre
2016].
10
SOFTRAM. Productos y Servicios [en línea] <http://www.softram.cl/productos-
servicios.html?value=n0fot6k7h7x80nfkdpwbfn53894q%27%20id%20%27&detail=rgpb813580z%27
%20iddet%20%27> [consulta: 26 octubre 2016].
11
Factura Movíl SpA. Factura Electrónica [en línea] <http://facturamovil.cl> [consulta: 26 octubre
2016].
12
Defontana Chile. Software ERP: Valores y Funcionalidades [en línea]
<http://www.defontana.com/cl/precios/> [consulta: 26 octubre 2016].
13
LanixERP. Soluciones para las empresas de hoy [en línea] <http://www.lanixerp.cl/soluciones/>
[consulta: 26 octubre 2016].
18
Informat: Proveen un servicio INET ERP que cumple funcionalidades básicas de un software
ERP (gestión financiero, gestión de recursos humanos, logística y área comercial) en
plataforma de escritorio para sistemas Windows. Añade un módulo adicional llamado
IFACTURE INET que se comunica única y exclusivamente con INET ERP (no se puede
utilizar de forma independiente) y se encarga de hacer la facturación electrónica.
Adicionalmente poseen otra solución de plataforma web, que solo permite realizar la gestión
de ventas y facturación electrónica (IFACTURE WEB)14.
Este tipo de soluciones está enfocado a empresas de desarrollo que deseen integrar su sistema
ERP con el componente ofrecido, a modo de mantener la lógica de sus procesos intacta e
integrar la facturación electrónica.
14
Informat. Informat.cl - IFACTURE INET [en línea] <http://www.informat.cl/ifacture-inet/>
[consulta: 26 octubre 2016].
15
Transtecnia. Catálogo de Soluciones [en línea] <http://www.transtecnia.cl/catalogo_soluciones.htm>
[consulta: 26 octubre 2016].
19
la información del servicio, el cual es posteriormente solicitado con mensajes XML utilizando
el protocolo SOAP.
Otra empresa que además de ofrecer un sistema ERP (Softnet ERP) provee servicios de
facturación electrónicas vía componentes es Softnet. La empresa entrega dos planes para
trabajo con un componente de generación de DTE, una solución de pago mensual, en la que la
empresa proveedora mantiene el componente accesible como web service para la empresa
cliente, y un plan “In-House”, en el cual el cliente dispone del componente para instalarlo en
su arquitectura y modificarlo a gusto.
16
FacturaEnLinea.cl. Cotiza [en línea] <http://www.facturaenlinea.cl/cotiza.php> [consulta: 26 octubre
2016].
20
utilizando XML para enviar/recibir solicitudes, la misma empresa además provee conectores
para integración con componente en distintos lenguajes: VB.NET, VB6, Java, PHP y
Javascript17.
Azurian, posee cuatro planes para la emisión de DTE’s y a diferencia de las anteriores,
también integra procesos de recepción de DTE’s. Los planes entregas por Azurian son: “DTE
plus In House”, en el cual el componente es instalada en infraestructura del cliente, “DTE plus
Mixto”, en el que parte de la infraestructura es instalada en infraestructura cliente,
permitiendo facturación fuera de línea y sincronización con aplicación su nube (mantenida en
infraestructura de Azurian), “DTE plus Cloud” otorga todos los servicios de emisión y
recepción de DTE como componente en la nube (tipo web service) y “DTE plus Cloud
Facturador”, que integra la posibilidad de facturar en la nube, trabajando en solitario sin ser
18
un componente .
17
Softnet. Softnet | Facturaciónn Electrónica, Erp Softnet [en línea]
<http://www.softnet.cl/aplicaciones_ti-soluciones-emision_DTE.php> [consulta: 26 octubre 2016].
18
Azurian. Modalidades de Implementación de Factura Electrónica en Chile [en línea]
<http://www.azurian.com/fichas/factura-electronica-chile> [consulta: 26 octubre 2016].
19
Posland. Factura Electrónica desde su propio software [en línea] <http://posland.cl/odoo/servidor-
factura-electronica-conector/> [consulta: 26 octubre 2016].
20
NDTE Chile. ¿Qué ofrece NDTE Chile? [en línea] <http://www.ndtechile.cl/que-ofrece-nte-chile/>
[consulta: 26 octubre 2016].
21
funcionalidades del componente comprende la emisión y firmado de los DTE’s, así como la
generación del documento PDF para impresión a contribuyentes no electrónicos21.
La librería puede ser usada en conjunto a la plataforma LibreDTE, la cual es accesible desde
su sitio web (https://libredte.sasco.cl), además de contar con una API en la cual puede ser
usada a modo de componente web service para realizar los procesos de facturación
electrónica. LibreDTE está construida utilizando el framework SowerPHP23, el cual es un
framework minimalista basado en principios MVC.
21
FacturaElectronicaChile.com. Facturación Electrónica (SII) [en línea]
<http://facturaelectronicachile.com> [consulta: 26 octubre 2016].
22
LibreDTE. Biblioteca PHP para facturación electrónica en Chile [en línea]
<https://github.com/LibreDTE/libredte-lib> [consulta: 26 octubre 2016].
23
LibreDTE. Arquitectura de LibreDTE [en línea]
<https://wiki.libredte.cl/doku.php/dev/arquitectura> [consulta: 26 octubre 2016].
24
Servicio de Impuestos Internos. Conozca de factura eléctronica y de los sistemas
disponibles [en línea] <http://www.sii.cl/factura_electronica/como_fact_elect.htm> [consulta:
26 octubre 2016].
22
tiempo requerido), no poder emitir todos los documentos tributarios electrónicos posibles
(facturas de exportación, notas de crédito y débito de exportación, liquidación de factura,
boletas afectas, etc.) y que cada DTE tiene que ser emitido uno por uno, eliminando la
posibilidad de grandes empresas de facturar por lotes mediante la administración de folios.
25
niclabs. Bibliotecas de factura electrónica (DTE), desarrollada y mantenida por Jose Urzua y NIC
Chile Research Labs [en línea] <https://github.com/niclabs/DTE> [consulta: 26 octubre 2016].
26
pbruna. A gem to work with Chile SII Factura Electrónica [en línea]
<https://github.com/pbruna/talonario> [consulta: 26 octubre 2016].
23
Capítulo 3: Propuesta específica
Existiendo una ausencia de soluciones de facturación electrónica, a modo de componentes que
puedan ser utilizadas desde infraestructura propietaria, a disposición gratuita y sin problemas
de licenciamiento para uso comercial, se presenta una propuesta de componente que pretende
responder las necesidades de facturación electrónica requeridas por el SII para operar en el
modelo de contribuyente electrónico.
Esta sección pretende explicar la arquitectura basada en componentes, y las tecnologías base a
utilizar para implementar la propuesta.
Estos defectos, pueden aparecer en partes del código que están asignados a otra persona del
equipo, requiriendo una colaboración estrecha los miembros del equipo involucrados para
resolver las consecuencias de los cambios, aun cuando estos eran pertinentes sólo a una zona
acotada del código.
Esto provoca que la delegación de tareas sea pobre, lo cual en equipos grandes puede impactar
bastante en la productividad del equipo, aún más si estos están distribuidos geográficamente.
24
a un comportamiento prescrito, común a todos los componentes en una arquitectura”27. La
arquitectura que comprende la utilización de componentes de software para componer así las
funcionalidades de un software, se entiende como arquitectura basada en componentes.
El uso de componentes permite entender nuestro sistema como un grafo de módulos que
realizan funcionalidades, unidos mediante conexiones unidireccionales que denotan las
dependencias entre estos. De esa forma permite expresar con mayor claridad el
funcionamiento de un sistema, tanto a terceros como a miembros del equipo.
La red de dependencias además favorece a dar una noción precisa de como un componente
afecta al resto del sistema, ya que solo los dependientes de este serán afectados, reduciendo
los posibles defectos descontrolados en otras partes del sistema.
Desde otra arista, un componente que posee una interfaz claramente definida y que realiza una
función concreta puede ser fácilmente extraído del proyecto y reutilizado en otros que
también requieren su funcionalidad. La capacidad de reuso de los componentes permite a
empresas mantener un ecosistema de componentes frecuentemente solicitados en proyectos y
de esa forma, reducir el costo que requiere la realización de nuevos proyectos.
27
W3C. Web Services Glossary [en línea] <https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/>
[consulta: 26 octubre 2016].
25
3.1.1 Problemas asociados a Component-Based Architecture
Esta misma caja negra provoca que medir las características internas que definen la calidad de
un componente sea imposible de realizar, propagando una incertidumbre en la calidad total
del sistema [8]. Esto resulta especialmente problemático en sistemas en los cuales se requiere
un QoS determinado.
26
− Integración dificultosa y falta de predictibilidad: Aun habiendo seleccionado un
componente que cumpla los requerimientos funcionales necesarios, la integración puede
resultar dificultosa por diferencias entre la arquitectura actual y la propuesta por el
componente [9], supuestos erróneos sobre la utilización del componente por falta de
información en la documentación, composición errónea de componentes, entre otros.
Las principales causas de los problemas ligados al diseño de software con componentes
provienen de una falta de técnicas apropiadas que permitan resolver efectivamente la
selección de componentes y de la poca información que se posee de estos para realizar el
proceso. Es difícil determinar la factibilidad de la integración entre varios componentes, o si
estos componentes logran cubrir aquellos aspectos que son críticos para los stakeholders.
Para resolver este problema, la literatura provee técnicas que prestan especial atención en
técnicas de selección de componentes, los cuales proveen métodos cuantitativos para evaluar
los componentes en base a propiedades medibles de estos, y de esa manera seleccionar los
componentes a utilizar. Los criterios que los modelos utilizan son variables, y por lo general
van relacionados con métricas funcionalidades propias de algunos estándares de calidad de
software, como la ISO/IEC 25010, o la ISO/IEC 9126-1.
Una revisión de los modelos de calidad se llevará a cabo en el estado del arte. A partir de los
requisitos funcionales y el estudio de estos modelos, se definirá una rúbrica para componentes
de facturación electrónica, que será utilizada para llevar a cabo la evaluación comparativa de
componentes candidatos.
27
− Arquitectura definida: Los componentes son diseñados pensando su integración en
una arquitectura predefinida, a modo que puedan operar con otros componentes o
frameworks.
Considerando que los sistemas operativos más utilizados cuentan con ejecutables para
Chrome, o Firefox (siendo navegadores bastante populares, cubriendo más de un 70% de los
usuarios)28, y que los dispositivos móviles con iOS o Android cuentan con estos navegadores,
la construcción de un sistema web accesible desde estos navegadores permite que los usuarios
puedan hacer uso de este desde una amplia gama de dispositivos.
28
W3Counter. Browser & Platform Market Share [en línea]
<https://www.w3counter.com/globalstats.php> [consulta: 26 octubre 2016].
28
Diversos lenguajes ofrecen herramientas para la generación dinámica de sitios web que es
necesaria para el sistema. Las tecnologías más rudimentarias permiten el desarrollo de cada
parte del sistema de manera entrelazada y son ejecutados en el lado del servidor, como es el
caso de PHP, un lenguaje interpretado que permite la generación de páginas HTML con
contenido dinámico, al momento que este es requerido por los clientes29.
Si bien utilizando tecnologías como PHP, ASP o CGI junto a un motor de bases de datos
relacional, se pueden satisfacer las necesidades del sistema, existen problemas debido a que
no hay convención en cómo estructurar las partes, lo cual provoca código de bastante
complejidad, dificultad para la colaboración y un grado escaso de reuso (lo cual se desea
evitar). Se han presentado patrones de diseño que buscan resolver estos problemas de manera
estandarizada, definiendo una estructura organizada para la construcción de sistemas web.
En particular a nuestro foco de interés, surgen los denominados Framework Web, los cuales
están pensados para soportar la implementación y diseño de sistemas web. Estos son
montados sobre las bases de un lenguaje definiendo una estructura molde a utilizar, e integran
utilidades comunes y necesarias para el desarrollo web30.
Muchos frameworks web implementan el patrón de diseño MVC. El patrón MVC, propone
segmentar la aplicación en tres componentes: modelo, vista y controlador, encargadas de
distintas responsabilidades.
29
The PHP Group. What can PHP do? [en línea] <http://php.net/manual/en/intro-whatcando.php>
[consulta: 26 octubre 2016].
30
StackOverflow. What is a Web Framework? How does it compare with LAMP [en línea]
<http://stackoverflow.com/questions/4507506/what-is-a-web-framework-how-does-it-compare-with-
lamp> [consulta: 26 octubre 2016].
29
Figura 3.1: Esquema de interacción de componentes en patrón MVC.
El modelo, contiene las entidades del dominio, así como la lógica de negocio relacionada a
estas. El controlador es el intermediario entre la vista y el modelo, responde a las llamadas de
las vista, solicita información del modelo, la cual es procesada y enviada de vuelta a la vista.
La vista es finalmente encargada de presentar la información en una interfaz gráfica al
usuario, y de capturar eventos para ser enviados al controlador.
Dadas estas diferencias, el MVC aplicado a frameworks web no es puro, ya que está apoyado
estructuralmente con otros componentes para suplir otras funciones que no son
responsabilidad habitual de MVC clásico.
30
En la actualidad existen numerosos frameworks web para cada lenguaje: Laravel, Codeigniter,
CakePHP o Symphony para PHP, Django o Flask en el caso de Python, Sinatra o Ruby on
Rails para Ruby. Algunos frameworks integran una gran serie de funcionalidades, mientras
que otros intentan mantener el peso de su inclusión a un mínimo (micro frameworks), o
difieren en los patrones de diseño utilizados (no todos se basan en un diseño MVC).
Para la implementación de este sistema, se hará uso del framework web para Ruby: Ruby on
Rails (o comúnmente llamado solamente Rails), el cual es un framework web basado el patrón
MVC para organizar la estructura de la aplicación31.
Rails se integra como librería (gema) mediante el gestor de paquetes para Ruby, RubyGems.
Rails es un framework para la creación de aplicaciones web, el cual asiste el proceso de
implementación de “features” comunes, como generación de HTML dinámico, procesamiento
de “forms” y acceso a base de datos.
Rails es un framework que propone una solución única para estos problemas, basada en la
experiencia de sus autores (“opinionated framework”, o framework “opinado”), de esta forma,
establece convenciones a seguir y una forma de realizar tareas comunes, facilitando la toma
de decisiones por desarrolladores y mejorando la mantenibilidad del código, ya que al seguir
las convenciones el código se vuelve homogéneo y más fácil de comprender.
Rails se apoya fuertemente en las virtudes de Ruby: una sintaxis limpia y un alto nivel de
abstracción, que permite la construcción de DSL (el cual es usado para la generación de vistas
y configuración de Rails), y el gestor de paquetes RubyGems.
El beneficio de utilizar gemas (el nombre dado para los paquetes), es que las funcionalidades
de Rails pueden ser extendidas, por gemas especialmente pensadas para ser integradas junto a
Rails. Las gemas son subidas por la comunidad y dejadas a libre disposición para el uso libre
de los desarrolladores, permitiendo disminuir los tiempos de desarrollo de aplicaciones web,
ya que funcionalidades comunes están generalmente cubiertas por gemas populares.
Las gemas más populares son constantemente mantenidas por la comunidad, por lo que la
calidad de estas es alta, y son mantenidas al día para funcionar con nuevas versiones de Ruby.
31
RailsApps Project. What is Ruby on Rails? [en línea] <http://railsapps.github.io/what-is-ruby-
rails.html> [consulta: 26 octubre 2016].
31
En efecto, el concepto de gemas de Ruby se utilizará de las bases en la implementación del
componente, ya que este será implementado como una gema, la cual se requerirá por el
sistema ERP.
Por otra parte, el componente de facturación electrónica dependerá de otras gemas, las cuales
asistirán procesos genéricos a cubrir: Generación de código de barras PDF417, manejo de
XML y generación de firmas digitales son algunos puntos que serán cubiertos con estas.
32
Capítulo 4: Desarrollo de Componente
En base a la propuesta, este capitulo considera la especificación de las exigencias impuestas
por el SII que fueron implementadas en el componente, además de mencionar requisitos
externos al componente que pertenecen al sistema ERP en el cual se integrará. Esta sección
también explicará cómo fue formada la integración del componente al sistema. La segunda
parte de la propuesta será definida en detalle en el capitulo siguiente.
La normativa del SII, obliga a los contribuyentes a seguir con ciertas exigencias comunes para
todos a la hora de emitir documentos tributarios electrónicos. A la hora de diseñar un
componente de facturación electrónica se debe asegurar que, por lo mínimo, cada una de las
exigencias impuestas esté cubierta.
En particular, estas exigencias pueden ser revisadas en detalle a partir de los documentos
técnicos provistos por el SII. Para facilitar la comprensión, se pueden agrupar las exigencias
en los siguientes grupos de roles, los cuales serán cubiertos por la implementación específica
del componente.
Cada uno de los DTE generados deberá contener información del timbrado electrónico, el cual
lo entrega el SII y permite la emisión de ese tipo de DTE. Adicionalmente, el formato de estos
XML contendrá una o varias firmas, las cuales deben ser realizadas siguiendo el estándar
XMLDSIG 1.1, recomendado por la W3C. Esta firma debe ser efectuada por la llave privada
del certificado provisto por las empresas prestadoras acreditadas en la materia.
Cada DTE que se desee emitir, debe estar contenido dentro de un envío de DTE. Este
contenedor se encarga de contener datos de información del emisor, así como la firma
electrónica completa del documento. Cabe destacar que un envío de DTE usualmente contiene
un DTE, pero el formato permite la inclusión de hasta 2000 DTE.
33
En particular, respecto al esquema XML exigido (“SiiDte EnvioDTE_v10.xsd”), la
información contenida por cada DTE se define en un nodo <Documento>, el cual deberá ser
contenido por un nodo <DTE>. Este nodo <DTE> contendrá a su vez la firma del nodo
<Documento>, la cual es definida por XMLDSIG 1.1, y es contenida en un nodo <Signature>.
Luego, cada nodo <DTE> debe ser contenido en un nodo <SetDTE>, el cual puede contener
uno o más <DTE>, <SetDTE> a su vez contiene información del emisor del envío, la cual es
contenida en un nodo <Caratula>. Finalmente, <SetDTE> es contenido nuevamente por
<EnvioDTE>, el cual es el nodo padre de todo DTE válido. Este nodo contiene la última
firma, la cual se efectúa sobre los contenidos de <SetDTE>, y es contenida en un nuevo nodo
<Signature>.
34
cuáles campos son permitidos, señalando aquellos que son obligatorios, opcionales, o de
carácter condicional32.
− Encabezado: Contiene datos del documento, como su tipo, folio utilizado, fecha de
emisión, montos, e información de transporte, además de incluir datos del emisor y el receptor
del DTE.
32
Servicio de Impuestos Internos. Formato documentos tributarios electrónicos [en línea]
<http://www.sii.cl/factura_electronica/factura_mercado/formato_dte.pdf> [consulta: 26 octubre 2016].
35
− Timbre electrónico del documento: Corresponde a una firma electrónica sobre
algunos datos del DTE, la cual es creada a partir del CAF (código de autorización de folios)
entregado. Su conformación y utilidad será explicada en “Sobre el uso de Timbraje
Electrónico”.
Cada documento EnvioDTE debe ser firmado, por lo menos dos veces. Por cada DTE, debe
realizarse una firma electrónica sobre su respectivo nodo <Documento> y una sobre el
<SetDTE>, el cual incluye el detalle de todos los DTE pertenecientes al envío y los datos del
encabezado. Cada una de las firmas electrónicas es realizada utilizando la llave pública del
certificado digital del contribuyente, el cual es una persona natural autorizada por la empresa
para emitir los documentos.
El proceso de firmado debe considerar los estándares publicados en XMLDSIG 1.1 y otros
detalles adicionales, los cuales han sido documentados de manera extraoficial en 33. En
detalle, el proceso de firmado supone los siguientes pasos:
− Canonizar el nodo bajo el cual se realizará la firma electrónica. Para efectos del SII,
esto supone:
Mantener todo salto de línea, espacio y tabulación entre los tags
XML sin cambios.
Las 5 entidades predefinidas en XML (& < > ‘ y “) que ocurran como
contenido dentro de un nodo, deberán ser escapadas utilizando su referencia como
entidades (& < > " y ').
33
DI Management Services. XML-DSIG and the Chile SII [en línea]
<http://www.cryptosys.net/pki/xmldsig-ChileSII.html> [consulta: 26 octubre 2016].
36
El ordenamiento de los namespaces y atributos de los nodos deberá
ser realizado de manera lexicográfica por su nombre local, con una preferencia a los
namespaces de los nodos por sobre sus atributos (si no posee nombre local tiene
prioridad por sobre los otros). Los atributos deberán ser ordenados luego de estos
utilizando ordenamiento lexicográfico con dos claves, la URI del namespace del
atributo como clave primaria y el nombre del atributo como clave secundaria.
Aquellos atributos que no posean un namespace asignado poseen prioridad.
− Con la llave privada del contribuyente, se deberá firmar el digest SHA1 del nodo
<SignedInfo> canonizado.
Para realizar el proceso de firmado, se utilizó Signer34 como base para asistir con las
especificaciones del estándar XMLDSIG 1.1, la cual trabaja utilizando la gema OpenSSL
como base para la creación de los digest y para realizar el firmado, y la gema Nokogiri35 para
el manejo de documentos XML.
Para cubrir aquellos otros requisitos no incluidos en el estándar, se requirió hacer una copia
local de la gema para adaptarla al funcionamiento del SII.
34
ebeigarts. WS Security XML Certificate signing for Ruby [en línea]
<https://github.com/ebeigarts/signer> [consulta: 26 octubre 2016].
35
Sparkle Motion. Nokogiri is an HTML, XML, SAX, and Reader parser with XPath and CSS selector
support [en línea] <https://github.com/sparklemotion/nokogiri> [consulta: 26 octubre 2016].
37
4.1.1.4 Sobre el uso de Timbraje Electrónico
El timbraje electrónico para cada tipo de DTE debe ser solicitado en el portal web del SII, y
permite al contribuyente emitir un número válido de DTE en un rango de folios. Es
responsabilidad del componente controlar que el rango de folios se respete (no permita la
creación fuera de este), y que la asignación de folios sea única a cada DTE (SII rechazara los
DTE si el folio para ese tipo de documento ya se encuentra recepcionado).
El rango de folios entregado por el SII consiste en un documento XML que cuenta con un
CAF (código de autorización de folios) y un par de claves privado/pública que forman parte
del proceso de timbrado. El procedimiento para timbrar un documento consiste en lo
siguiente:
− Cálculo del digest: Bajo el nodo DD con los caracteres codificados, se calcula el
digest SHA1.
− Obtención del valor de la firma: Utilizando la llave privada perteneciente al XML del
rango de folios autorizado, se firma el digest del nodo <DD> encontrado previamente. Este
valor deberá ser codificado en Base64 e insertado como valor del nodo <FRMT>, el cual es
un hijo del nodo <TED>.
Este proceso debe ser realizado para cada documento tributario dentro de un <EnvioDTE>.
38
4.1.2 Envío automático de DTE’s al SII
Para hacer uso de la API de envío de DTE, es necesario obtener un token de autentificación
por parte del SII. Para esto, se deben utilizar dos servicios SOAP: “CrSeed” y
“GetTokenFromSeed”.
El primero, expone un método para obtener una semilla, la cual es una cadena de texto
generada aleatoriamente por el SII para facilitar la autenticación. Esta semilla debe ser
compuesta en un documento XML, el cual debe ser firmado con la llave privada del
contribuyente. Este documento XML luego se envía en el segundo servicio
“GetTokenFromSeed”, el cual valida la firma y entrega un token de autenticación, el cual
sirve para hacer uso de otras API del SII en nombre del contribuyente. El token es válido por
un corto periodo de tiempo, por lo que se recomienda que cada operación genere su propio
token.
Para acceder a las API SOAP desde el componente, se utilizó Savon36, cliente que permitió la
obtención de los WSDL del SII y el envío de solicitudes.
Una vez que se obtiene el token de autenticación, se puede realizar el envío de DTE al SII
mediante la API HTTP definida para tal propósito (/cgi_dte/UPL/DTEUpload), mediante un
POST se envía la información del DTE junto con el token obtenido. En caso de éxito, el SII
responde con un XML, el cual contiene el TrackID del envío, el cual es un número de
seguimiento para hacer la posterior consulta del estado de este. En caso contrario, este XML
también retornará el status de envío, mostrando el código y razón del fallo.
Para acceder a esta API HTTP, se utilizo Unirest37, el cual es un cliente de solicitudes HTTP
que permite el envío de archivos (mediante solicitudes “mutlipart”).
36
SavonRB. Heavy metal SOAP client [en línea] <https://github.com/savonrb/savon> [consulta: 26
octubre 2016].
39
4.1.3 Consulta de envío de los DTE
Una vez que el envío haya sido realizado al SII, y este haya procesado y probado su validez,
el SII podrá determinar el estado de aceptación del documento. Es fundamental verificar que
cada envío de DTE resulte aceptado, o sino se estarían utilizando documentos inválidos en los
pasos posteriores.
La consulta al SII se puede realizar a través del sitio web, con el TrackID del envío a
consultar, así como también por medio de las API designadas para tal propósito. Para efectos
del componente, nos interesa la versión automatizada mediante las API.
La consulta de los envió se realiza mediante una API SOAP (“QueryEstUp”), la cual usa
como parámetros el TrackID del envío a consultar, el RUT del contribuyente y un token de
autenticación (el cual se obtiene de la misma manera de que se utiliza para envío de DTE). La
respuesta contiene un XML el cual contiene el estado de aceptación de cada tipo de DTE que
formaba parte del envío.
Se requiere que una vez que el DTE sea aprobado por el SII, se haga envío del DTE al
contribuyente receptor mediante correo, el cual debe contener una copia del XML enviado al
SII. En el caso de ser receptor de los DTE, se requiere generar mensajes de respuesta (acuses
de recibo) en el formato apropiado para ellos por el SII. Los mensajes de respuesta son
archivos XML que deben ser enviados al emisor del DTE al cual se responde, y contienen
información de aceptación al DTE según validaciones que el componente deberá realizar.
Dependiendo del estado de conformidad del contribuyente receptor del DTE, este también
puede optar por rechazarlo mediante una justificación expresada en una glosa.
Según el nivel de detalle de la respuesta, el SII define dos tipos de mensaje de respuesta: El
primero permite responder a la totalidad del envío, y es considerado el acuse de recibo de este,
el segundo tipo permite la revisión individual de cada DTE compuesto en un envío,
permitiendo aceptar, aceptar con reparos, o rechazar por separado cada uno de estos. Ambos
tipos siguen un esquema XML común, y comparten campos obligatorios (carátula con datos
del contribuyente emisor de la respuesta, y firma electrónica del XML). El esquema XML que
define las respuestas es “SiiDte RespuestaEnvioDTE_v10.xsd”.
37
Mashape. Unirest in Ruby: Simplified, lightweight HTTP client library [en línea]
<https://github.com/Mashape/unirest-ruby> [consulta: 26 octubre 2016].
40
Adicionalmente, para efecto de Ley N°19983, el SII define un tercer tipo de respuesta, la cual
da cuenta del acuse de recibo de mercaderías o servicios prestados. Esta respuesta solo deja en
claro la recepción conforme de bienes por parte del emisor, por lo que debe ser realizado
posteriormente efectuado la aceptación correcta de los DTE, y solo si los bienes son recibidos
de manera conforme. El esquema XML que define este tipo de respuesta está definido en
“SiiDte EnvioRecibos_v10.xsd”.
Para la validación de las firmas electrónicas, se utilizó la gema xmldsig38, la cual funciona con
ayuda de Nokogiri y OpenSSL para la validación de firmas XMLDSIG 1.1.
Para aquellos contribuyentes que continúen operando de forma manual, se requiere que el
DTE sea enviado a estos bajo cierto formato, en un documento impreso. El documento debe
ser un archivo PDF, el cual debe reflejar la información de su contraparte electrónica.
Detalles relevantes sobre la impresión, son que debe provenir de un documento PDF, y deben
contar con la generación de un código de barras bidimensional PDF417, el cual contiene
información codificada del DTE, a modo de permitir verificar su autenticidad.
El SII define un reglamento a seguir respecto al formato que deben contener las muestras
impresas40. A continuación se expone un resumen del formato exigido, para aquellas muestras
impresas en formato hoja papel:
38
benoist. Implementation of the xmldsig specification [en línea] <https://github.com/benoist/xmldsig>
[consulta: 26 octubre 2016].
39
PrawnPDF. Fast, Nimble PDF Writer for Ruby [en línea] <https://github.com/prawnpdf/prawn>
[consulta: 26 octubre 2016].
41
Dimensiones para hojas de papel:
Zona superior izquierda: Debe contener los siguientes datos del emisor del documento:
La información del emisor debe ser idéntica a la dispuesta por el SII, la cual es consultable en
su sitio web41.
− Tamaño mínimo: de 1,5 x 5,5 centímetros. en el lado derecho color negro o rojo,
enmarcado por una línea de entre 0,5 a un milímetro de grosor.
− Tamaño máximo del recuadro: 4 x 8 centímetros.
− Letras: tamaño igual o superior a 10 en alta y negritas.
− Fecha de emisión
− Datos del receptor
40
Servicio de Impuestos Internos. Manual de muestras impresas [en línea]
<http://www.sii.cl/factura_electronica/factura_mercado/manual_muestras_impresas.pdf> [consulta: 26
octubre 2016].
41
Servicio de Impuestos Internos. Datos para impresión de documentos tributarios [en línea]
<https://maullin.sii.cl/cvc_cgi/dte/pe_construccion_dte> [consulta: 26 octubre 2016].
42
Razón social del receptor
RUT del receptor
Giro del receptor
Dirección del receptor
− Datos de referencia (si corresponde)
Tipo de documento (si corresponde)
N° Folio
Fecha de emisión de documento referencia
Motivo
Otros
− Zona de detalle (Ítems y descuentos y recargos)
− Zona de totales
− Recuadro acuse de recibo (Ley 19.983)
− Timbre electrónico (a una distancia mayor o igual a 2 cm de borde izquierdo del
documento
− Leyenda de destino (solo para copia cedible) en zona inferior derecha del documento.
La generación del código PDF417 fue realizada con ayuda de la gema PDF41742.
42
American Society for Engineering Education. A Ruby wrapper for the PDF417 barcode library [en
línea] <https://github.com/asee/pdf417> [consulta: 26 octubre 2016].
43
4.1.6 Generación y envío de información de compras y ventas
Los contribuyentes electrónicos están obligados a llevar la emisión de sus libros de compra y
venta en formato electrónico, los cuales deben contener la información de compras y ventas
de un periodo mensual. El plazo que los contribuyentes poseen para enviar esta información,
es hasta el final del próximo mes (al cual hace referencia el periodo).
Cada libro de compra y venta consiste en un archivo XML, definiendo una estructura similar a
la de los realizados para los DTE: Presencia de un código de autorización para la emisión de
libros (CAL) y una firma electrónica sobre la información del libro contable, utilizando el
estándar anteriormente mencionado XMLDSIG 1.1.
Los XML de libros de compra y ventas están definidos por el esquema “XMLSiiDte
LibroCV_v10.xsd”. La información de cada libro de venta queda definida en un nodo padre
llamado <LibroCompraVenta>, este nodo tiene como hijo <EnvioLibro> y <Signature>, el
cual es una firma electrónica realizada sobre los contenidos del primer hijo.
<EnvioLibro> contiene <Caratula>, la cual posee información del envío, y las zonas de
resúmenes y detalles respectivamente, las cuales se definen mediante la inclusión del nodo
<ResumenPeriodo> con sus hijos <TotalesPeriodo>, y nodos tipo <Detalle>. Finalmente, se
inserta el código de autorización de libros (CAL) dentro del <EnvioLibro> en el nodo
<LceCal>.
44
Para la realización de la firma electrónica bajo el nodo <Signature> se asistió el proceso
utilizando la gema Signer43, de manera similar como se realizaron las firmas XMLDSIG para
los EnvioDTE.
Los libros de compra y venta deben registrar todo el detalle de los documentos tributarios
emitidos en el periodo, detalles que deben ser resumidos en una sección que totaliza los
movimientos agrupándolos por tipo de documento tributario.
La información presente en los libros de compra y venta puede ser completada parcialmente
de aquella que está almacenada en el sistema. Lo que no puede ser completado corresponde a
documentos tributarios de origen manual, los cuales deben ser digitados de forma manual. El
sistema encargado debe facilitar que estos libros parciales sean generados, e integrar métodos
para permitir completar la información faltante.
Cada contribuyente que desee operar con software de mercado o elaboración propia, debe
pasar por las pruebas de certificación que el SII envía. Si bien la certificación da cuenta de
que las otras responsabilidades estén cubiertas de forma efectiva, el proceso de certificación
requiere que la preparación de estas cumpla con ciertas condiciones especiales. Por esta
misma razón, aunque la existencia de herramientas para la certificación no es necesaria,
otorga un valor agregado al componente ya que permite disminuir el esfuerzo a la hora de
integrar a un sistema y certificar un contribuyente.
43
ebeigarts. WS Security XML Certificate signing for Ruby [en línea]
<https://github.com/ebeigarts/signer> [consulta: 26 octubre 2016].
45
a partir de la información requerida, y generación automatizada de muestras impresas a partir
de los set de prueba y simulación. La fase de intercambio entre contribuyentes no requiere un
tratamiento especial en relación a su uso fuera de certificación, ni tampoco supone un
esfuerzo considerable, por lo que la inclusión de herramientas para este queda descartada.
El sistema a construir consiste en una herramienta de gestión pensada para las necesidades de
una empresa de rubro maderero y de construcción de muebles, el cual fue exigido por un
cliente para su realización. El sistema debe ser capaz de apoyar el proceso de ventas de la
empresa, llevando un seguimiento de las órdenes pedidas por los clientes, además de integrar
funciones que permitan manejar el stock de productos (inventario).
Las órdenes deben ser emitidas a partir de un vendedor autorizado en el sistema, las cuales se
hacen a un cliente existente en la base de datos. Los productos que puede comprar el cliente
son los insumos propios del dominio del rubro: herramientas de construcción, tablas/planchas
de madera y cubiertas postformadas, estas últimas, difieren en que son elaboradas aplicando
una lámina de color en su cubierta. De esta forma, el sistema debe llevar un apropiado control
de los artículos y láminas a utilizar en los pedidos.
Debido a que el precio de cada cubierta difiere por sus dimensiones, color de lámina utilizada
y complejidad de la forma utilizada, el precio debe poder ser ajustado de forma manual. El
sistema debe proveer precios referenciales de las láminas, los cuales deberán poder ser
consultados a la hora de realizar las órdenes de pedido. El vendedor puede agregar recargos y
descuentos a que afectan a sólo un ítem de la orden, o globales, que se aplican al final de la
orden y afectan a todo lo pedido.
A partir de las órdenes de venta, se tendrá la opción de generar las facturas y guías de
despacho correspondiente, por lo que la interacción con el componente se generará entre estos
modelos. El vendedor tendrá la opción de facturar la totalidad de la orden de venta, o solo
parte de esta, y el sistema se deberá encargar de llevar un control de lo facturado y lo que falta
por facturar. Este comportamiento deberá ser idéntico para el caso de las guías de despacho,
trabajando con una numeración independiente a la de las facturas.
46
Una descripción completa de los casos de uso requeridos a construir se encuentra presente en
el anexo A, “Casos de uso de sistema ERP”.
A partir de la definición dada del sistema ERP, y siendo complementado por los casos de uso
del sistema, se construye un modelo conceptual de datos, el cual se utilizara para la
implementación del sistema.
Debido a la complejidad del sistema el modelo fue separado en tres partes: Modelo de sistema
ERP, modelo de facturación, y modelo de administración de correos.
El primero interactúa con el modelo de facturación en los modelos “Ítem pedido” y “Nota
pedido”, por lo que aparecen replicados en ambos esquemas.
Para entender cómo funciona una aplicación Rails, y como se desarrollará la solución, es
necesario entender la estructura de una aplicación tradicional Rails. La jerarquía de directorios
que define una aplicación Rails tradicional es la siguiente:
47
|-- app
| |-- assets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
| `-- application.html.erb
|-- bin
|-- config
| |-- environments
| | |-- development.rb
| | |-- production.rb
| | `-- test.rb
| |-- initializers
| |-- locales
| |-- routes.rb
| `-- secrets.yml
|-- db
|-- Gemfile
|-- Gemfile.lock
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- test
|-- tmp
`-- vendor
El directorio “bin”, contiene vínculos a ejecutables de las gemas del proyecto, son
automáticamente generados y permiten ejecutar tareas de las gemas, desde la raíz del
directorio de Rails, sin conocer la ubicación exacta de su instalación (siendo estos conocidos
como “binstubs”).
44
SitePoint. A Quick Study of the Rails Directory Structure [en línea] <https://www.sitepoint.com/a-
quick-study-of-the-rails-directory-structure> [consulta: 26 octubre 2016].
48
ambiente en que la aplicación es lanzada (por defecto, está la distinción entre ambiente de
desarrollo, ambiente de producción y ambiente de pruebas), el subdirectorio “initializers”
define archivos de configuración que son ejecutados al momento de lanzar la aplicación, y son
generalmente usados para la configuración de gemas asociadas al proyecto. El subdirectorio
“locales”, en donde se puede definir distintas localizaciones de la app para cada lenguaje, el
archivo “routes.rb”, el cual cumple la función de enrutador, redirigiendo las llamadas de los
clientes a las respectivas acciones de los controladores, y el archivo “secrets.yml”, el cual
contiene información sensible de la app como credenciales de autenticación, los cuales
quedan a disposición de la aplicación. Para mantener las credenciales del ambiente de
producción, este último archivo es generalmente excluido del sistema de versionamiento, y su
configuración se mantiene protegida sólo en el ambiente de producción.
El directorio “db”, contiene los archivos relacionados con la base de datos, aquí se almacenan
las bases de datos SQLite (generalmente utilizadas para entornos de desarrollo), las
migraciones (archivos que son utilizados de manera secuencial para definir y mantener al día
el esquema de base de datos de la aplicación), y los seeds (archivos utilizados para alimentar
la base de datos, generalmente con información de prueba, en ambientes de desarrollo).
El archivo “Gemfile”, en el cual la aplicación Rails define las dependencias de gemas a usar,
este archivo es generado por defecto en la instalación de Rails, ya que contiene algunas
dependencias básicas que Rails requiere, y otras sugeridas. Al momento de instalar las gemas,
se revisa este archivo y se resuelven las dependencias de cada gema, así como las versiones a
instalar de estas. El archivo “Gemfile.lock” asiste el proceso de instalación, congelando las
versiones de cada gema que fueron resueltas al momento de la instalación. Esto permite al
momento de colaborar, que se mantengan las mismas versiones de cada gema a utilizar45.
El directorio “lib”, contiene librerías de soporte que la aplicación pueda utilizar, y que no
clasifiquen dentro de una gema o un helper. El subdirectorio “assets” está pensado para
mantener recursos externos a la aplicación, y que sean usados por “lib”. El otro subdirectorio,
“tasks”, permite definir tareas ejecutables por la utilidad rake, la cual corre a través de línea de
comandos (CLI). Normalmente se recomienda mantener un tamaño moderado de código en
“lib”, y si este crece mucho, desligarlo del proyecto y generar una gema con tal funcionalidad.
En el caso de la implementación a realizar, las funcionalidades que forman parte de la
facturación electrónica, son posicionadas en este directorio, para luego constituir una gema.
Los detalles de este proceso son explicados con detención más adelante.
El directorio “log” mantiene los archivos con los registros de actividad reportados por el
sistema. El directorio “public” contiene archivos que son accesibles públicamente por los
45
StackOverflow. Gemfile.lock Use in Rails? [en línea]
<http://stackoverflow.com/questions/9208240/gemfile-lock-use-in-rails> [consulta: 26 octubre 2016].
49
clientes, y algunas vistas relacionadas con mensajes de error típicos (HTTP 404, 422 y 500).
En esta carpeta residen los recursos de assets en ambiente de producción, una vez que estos
son compilados.
Luego está el directorio “tests”, en la que residen los archivos de pruebas utilizados para hacer
testing funcional de la aplicación, el directorio “tmp” donde residen archivos generados
temporalmente por Rails, y el directorio “vendor”, en donde se contienen los recursos
externos a la aplicación.
Para la implementación del sistema a desarrollar, gran parte de la estructura tradicional de una
aplicación Rails se mantendrá sin cambios. Los modelos contienen las entidades del modelo
con sus respectivas validaciones y reglas, los controladores establecen el vínculo entre la
lógica transaccional de los modelos y el despliegue de información de las vistas, definiendo
por lo bajo acciones suficientes para realizar un CRUD de un modelo (creación, lectura,
actualización y eliminación de entidades). En los casos de uso más complejos, los
controladores son provistos de acciones adicionales para responder a los clientes, y llaman a
más de un tipo de entidad del modelo para presentar o manejar la información.
La interfaz de usuario es generada por las vistas, las cuales son asistidas por javascript para
definir el comportamiento del frontend. Se utilizan componentes de Bower46 para integrar
paquetes “front-end” en la aplicación, consistentes primordialmente en librerías javascript,
junto con hojas de estilo CSS e imágenes.
Para cubrir algunas de las funciones necesarias a cumplir por el sistema, se utilizaron gemas
disponibles en el repositorio RubyGems, las más relevantes son mencionadas a continuación.
46
Bower. Bower: A package manager for the web [en línea] <https://bower.io> [consulta: 26 octubre
2016].
50
− ajax-datatables-rails para asistir la creación de datatables (componente javascript para
generación de tablas dinámicas con opciones de filtrado y búsqueda), kaminari para la
paginación en estas.
− rut_chileno, para la validación de RUT en el backend
− pg, que es requerido por el ORM de Rails (ActiveRecord) para manejar el motor de
base de datos Postgresql, el cual fue utilizado en ambientes de desarrollo y producción.
− sass-rails, para el uso de hojas de estilo SCSS en la aplicación.
− prawn, para la generación de PDF lo cual se usa generar historial de clientes
− axlsx, para la generación de hojas de cálculo XLS, y roo para la lectura de estas, lo
cual se usa para exportar/importar artículos entre el sistema y archivos XLS.
− bower-rails para asistir el proceso de instalación e integración de componentes de
“front-end” desde el repositorio de Bower.
− paperclip para adjuntar archivos a modelos, usado para guardar los DTE, recibos de
DTE y el certificado a utilizar. Los archivos se almacenan en el servicio de almacenamiento
en la nube Amazon S3, con ayuda de la gema aws-sdk, la cual contiene las credenciales y
autoriza el uso del almacenamiento.
Con ayuda de las gemas y del framework Rails, se pretenden implementar los casos de uso
que el sistema requiere. Para aquellos que tengan un vínculo con las funcionalidades de
facturación electrónica, deberán ser resueltos con ayuda del componente.
Las llamadas al componente deberán ser realizadas a través de la interfaz definida para
realizar estas acciones. Es necesario que exista un código “puente”, encargado de establecer el
vínculo entre entidades propias del dominio de la aplicación (y del framework rails) y las
llamadas al componente, dando el formato que el componente requiere para que estas
51
funcionen de forma apropiada. De forma similar, las respuestas necesitan ser interpretadas y
procesadas por la aplicación, si esto fuera necesario.
Dado que el componente de facturación electrónica se desarrolla como gema, no puede estar
ligado con entidades internas de la aplicación, y por lo tanto no debe conocer de las
facilidades de framework Rails, ni de los modelos propios de la aplicación. Esto implica que
todas las funciones de persistencia de información, deben ser realizadas fuera del componente.
De manera similar con las vistas relacionadas, ya que estas deben ser generadas por la
aplicación con ayuda del modelo MVC propuesto por Rails,
Este desentendimiento del componente, puede ser desventajoso para esta implementación en
particular, pero de esa forma el componente se vuelve mucho más portable. Podrá ser
integrado a otras aplicaciones Ruby, u otros lenguajes, utilizando solicitudes HTTP por
ejemplo. Ya que el componente no se encarga de la lógica de almacenamiento, ni de la
presentación, podrá ser utilizado en un número mucho más amplio de contextos.
La interacción con el componente quedará resuelta por una parte de la aplicación. Para reducir
la complejidad agregada que esto puede provocar, es necesario que la interacción entre la
interfaz del componente y la aplicación sea lo mínima posible, y que esta parte de la
aplicación (el delegado de comunicarse con el componente), esté separado del resto de la
aplicación. Esta parte también debe ser la encargada de mantener los modelos relacionados de
facturación electrónica, junto con las vistas que sean requeridas por los casos de uso
relacionados con esta.
Otro beneficio de realizar esta separación, es que para efectos de desarrollo, el código
relacionado del componente se puede implementar en este módulo de la aplicación. Dado que
el componente y la aplicación fueron desarrollados en paralelo, resulta una manera más
natural de trabajar en la creación de un componente reusable. Una vez que el componente se
encuentre funcional y haya sido probado apropiadamente, el código se puede extraer de la
aplicación, siendo empaquetado en una gema y publicándola.
Para realizar esta división del módulo de la aplicación relacionado con funciones de
facturación electrónica, se utilizaron engines de Rails, como es propuesto en [13]. Los engines
de Rails pueden ser considerados pequeñas aplicaciones, las cuales se pueden montar en una
aplicación padre, otorgándole sus funcionalidades. A nivel de clases, una aplicación Rails
hereda del engine Rails (Rails::Application y Rails::Engine respectivamente), por lo que sus
comportamientos son similares47.
47
RailsGuides. Getting Started with Engines [en línea] <http://guides.rubyonrails.org/engines.html>
[consulta: 26 octubre 2016].
52
Es necesario explicar la diferencia de utilizar un plugin, ya que estos son generados de manera
similar por la CLI de Rails, utilizando “rails plugin new”. Un plugin consiste en una librería
embebida dentro de la aplicación (utilizando una carpeta lib), de comportamiento similar al de
una gema corriente, permitiendo su posterior reuso a través del Gemfile entre aplicaciones, o
su distribución por RubyGems. Un engine a diferencia, además de contener el directorio lib,
trae consigo la estructura típica de una aplicación Rails.
Un engine igualmente puede ser distribuido como una gema, aunque esto es menos frecuente,
dado la dificultad de que una parte de la aplicación, conteniendo vistas y modelos, sea
ampliamente reusable por otros usuarios.
Existen dos tipos de engines los cuales varían ligeramente en su estructura, utilizando distintas
opciones en la línea de comandos. El engine tipo --full (completo) genera una estructura de
directorios similar al de una aplicación Rails normal: app está presente, permitiendo la
construcción de vistas, modelos y controladores en el modelo. El directorio bin también es
incluido, lo que permite la ejecución de comandos Rails dentro del contexto del engine, lo que
permite que un engine pueda generar modelos, vistas, o scaffolds, de manera idéntica al de
una aplicación Rails corriente. Incluso se pueden generar migraciones, las cuales serán
propiedad del engine, residiendo en su propio directorio db/migrations.
Los contenidos del engine son directamente añadidos a la aplicación padre, lo cual puede
provocar colisiones por ejemplo, a la hora de definir modelos. Si la aplicación padre comparte
el nombre de clase de un modelo en particular, se provocará un comportamiento inesperado, y
existirá una incerteza en la aplicación al momento de integrar, dependiendo del orden en que
se carguen las dependencias. Este problema se acentúa sobre todo cuando el número de
engines en la aplicación crece, ya que las colisiones son mucho más probables.
53
Figura 4.4: Diagrama de dependencias entre partes de la aplicación ERP con el componente
de facturación electrónica.
# ERP/Gemfile
source 'https://rubygems.org'
# ...
# ...
# Modules
path "modules" do
gem "facturacion_electronica"
end
# ERP/components/facturacion_electronica/Gemfile
source "https://rubygems.org"
path "gem" do
gem "facturacion_electronica_gem"
end
gemspec
54
# ERP/modules/facturacion_electronica/facturacion_electronica.gemspec
Gem::Specification.new do |s|
# ...
s.add_dependency "facturacion_electronica_gem"
# ...
end
55
Para la comunicación con el componente, se definen funciones de acceso público a las clases
del componente. Los parámetros de cada llamada toman tipos primitivos, o estructuras de
información corrientes en Ruby (OpenStruct). El engine toma información de los modelos, y
adapta para que las llamadas se efectúen correctamente.
56
Capitulo 5: Evaluación y análisis comparativo de
componentes
Este capitulo expone el estudio comparativo de las alternativas presentes en el mercado,
respecto del componente construido en la primera parte de la propuesta. Con la información
recaudada en la sección de estado del arte, se formará una selección de componentes para
conformar el estudio.
La rúbrica será sustentada con la ayuda de modelos de calidad para componentes, permitiendo
perfilar el desempeño de distintas dimensiones de calidad de cada uno de los componentes
participantes en el análisis.
Los resultados obtenidos en esta fase, servirán para más adelante para caracterizar los
escenarios de uso favorables de cada uno de los componentes.
Los componentes seleccionados para formar parte del análisis son los siguientes:
57
Para realizar las pruebas y evaluación del componente, se obtuvo una demo del componente.
La cual fue utilizada usando su integración bajo Python 3.4 y la librería ctypes para realizar el
vínculo dinámico con LibFacturista.
Para realizar las pruebas y evaluación de esta solución, se utilizó PHP 5.5.17 para ejecutar
LibreDTE-lib y composer, como manejador de dependencias (y de esa forma importar
LibreDTE-lib).
5.1.3 Facturación_Electronica
Para evaluar el componente, se utilizó la versión de Ruby del ambiente de desarrollo (2.1.5).
Las pruebas fueron realizadas con una versión standalone del componente, sin ser integrado al
sistema ERP desarrollado.
Esta sección pretende discutir los modelos de calidad presentados en la literatura, dando un
vistazo en los modelos históricos de uso general, y los modelos de calidad especialmente
diseñados para componentes de software. Este estudio posteriormente permitirá definir el
modelo de calidad en el cual se basará la evaluación de componentes.
La calidad de software puede ser definida como “el grado en que un sistema, componente de
sistema o procesos cumplen requerimientos específicos”, o como “el grado en que un sistema,
58
componente de sistema o proceso cumple las expectativas de un cliente o usuario” [14]. Un
modelo de calidad de software es definido como “la serie de características y las relaciones
entre estas que proveen la base para especificar y evaluar requerimientos de calidad” [16].
Los primeros modelos de calidad de software, propuestos para uso general, fueron el de
McCall (1977) [15], Boehm(1978) [17] y FURPS(1992) [18]. El modelo de McCall define la
calidad del producto de software en tres aspectos: Operación del producto, Revisión del
producto y Transición del producto, estos tres aspectos se dividen en 11 factores de calidad
externos.
FURPS fue originalmente presentado por Robert Grandy, su nombre se descompone en las
características propuestas para definir la calidad: Funcionalidad, Usabilidad, Confiabilidad
(Reliability), Desempeño (Performance) y Soportabilidad (Supportability), a su vez cada una
de las características se separa en sub-características. FURPS ha sido actualizado en FURPS+,
el cual añade características al modelo: Requerimientos de diseño, Requerimientos de
implementación, Requerimientos de interfaz y Requerimientos físicos48.
Existen estándares ISO que tratan la calidad de los productos de software: La norma ISO
9126-1 [19] la cual está basada en los trabajos de Boehm y McCall. Esta norma establece dos
dimensiones de la calidad del software: Calidad en el uso, los cuales son aspectos de la
calidad perceptibles por el usuario final, y Calidad del producto, las cuales son características
intrínsecas al producto, y están contenidas en su estructura interna y externa. En el proceso de
desarrollo de software, las características internas son influenciadas por la calidad del proceso
de desarrollo, siendo a su vez las características internas influenciadoras de la calidad externa
del producto. De la misma forma, las características de calidad en uso son influenciadas por
las características externas del producto de software.
48
IBM developerWorks. Capturing Architectural Requirements [en línea]
<http://www.ibm.com/developerworks/rational/library/4706.html#N100A7> [consulta: 26 octubre
2016].
59
Figura 4.7: Calidad en el ciclo de vida de un producto de software [19].
Figura 4.8: Árbol de características y subcaracterísticas para calidad en uso según norma
ISO/IEC 9126-1 [19].
60
La norma ISO/IEC 9126-1 es posteriormente actualizada en la ISO/IEC 25010, agregando
más características al modelo de calidad del producto (Seguridad y Compatibilidad)
reagrupando las subcaracterísticas, además de expandir el modelo de calidad en el uso
(redefiniendo características, agregando subcaracterísticas y añadiendo una nueva
característica “Cobertura contextual”) [20].
Figura 4.10: Árbol de características y subcaracterísticas para calidad en uso según norma
ISO/IEC 25010 [20].
Los componentes COTS (“Commercial off the shelf”) son componentes distribuidos
comercialmente por un proveedor para su reuso en productos de propiedad de un cliente. Una
definición más comprensiva de un componente COTS es aquel que cumple alguna de las
61
siguientes condiciones: (i) es vendido, prestado o licenciado al público general, (ii) ofrecido
por un proveedor tratando de obtener beneficio comercial por el, (iii) es soportado y
modificado por el proveedor, (iv) disponible en múltiples copias idénticas o (v) utilizado sin
modificación alguna de su estructura interna [5].
Finalmente, el modelo propuesto consiste en una adaptación del estándar ISO 9126 para
facilitar su uso en componentes basado en el análisis anteriormente mencionado. El modelo
define 5 características y 16 subcaracterísticas, de las cuales proponen métricas para realizar
la evaluación.
Tabla 4.12: Características y subcaracterísticas del modelo propuesto por Bertoa et al. para la
evaluación de componentes.
Characteristics Sub-characteristics (Product) Sub-characteristics (Runtime)
Functionality Accuracy Suitability
Interoperability
Compliance
Security Compatibility
Reliability Recoverability Maturity
Usability Learnability
Understandability
Operability
Complexity
Efficiency Time Behaviour
Resource Behaviour
62
Maintainability Changeability
Testability
En el trabajo de Álvaro et al. se propone un modelo de calidad para componentes, con el fin
de ser utilizado para facilitar los procesos de selección de COTS, con énfasis en realizar una
proposición aplicable para uso real en la industria, y para facilitar la certificación de los
componentes existentes en el mercado (siendo parte de un proceso más grande, dedicado a la
certificación de componentes de software).
El modelo propuesto nuevamente es una modificación del modelo ISO 9126, ajustado a
aquellas características accesibles en los componentes, y que son relevantes [21]. Siendo uno
de los cambios más notorios la inclusión de la característica negocio (business) en el modelo,
la cual refiere a las características de marketing del componente de software,
complementando a las otras características de calidad.
En base a los requerimientos solicitados por el sistema, y las necesidades de cada stakeholder
presente en la construcción del sistema, propone la adaptación de estos tres modelos de
calidad para responder a la calidad interna y externa del producto, señalando a ISO 9126 y
Dromey como los encargados de estas dos dimensiones respectivamente (ISO/IEC TR 15504-
63
2 es utilizado para complementar la “process-efficiency” y “product-efficiency”, similarmente
a como son vistas en el Quality Cube Model).
Utilizando esta técnica, logran definir un modelo de calidad con características similares a las
de ISO 9126, más la adición de la característica Gestionabilidad (“Manageability”), la cual
responde a la necesidad de poder estimar tiempos y definir plazos en el proyecto que se desea
integrar el componente.
Singh et al. proponen un framework para la construcción de un modelo de calidad para COTS
con énfasis en la reusabilidad. Define un proceso para la construcción de un modelo de
calidad basado en las métricas que se descomponen de las metas de calidad requeridas por los
stakeholders y propone un proceso para la selección de componentes, utilizando el modelo de
calidad anteriormente generado, otorgando pesos a las métricas propias del modelo basado en
la especificación de requerimientos provista a cumplir por el componente. Adicionalmente
propone un modelo de calidad generado utilizando el framework, inspirado en los atributos
más frecuentemente propuestos en la literatura (Funcionalidad, usabilidad, confiabilidad,
eficiencia, mantenibilidad y portabilidad) [25].
64
5.3 Criterios de Evaluación
Es importante considerar que el enfoque de esta rúbrica es medir la calidad del componente
con el fin de ser integrado en un software, no para ser percibido por un usuario final
(contribuyente que utiliza software ERP con facturación electrónica). Por esto, la noción de
usabilidad para el producto de software cambia, alterando el significado de esta característica.
Para la selección de atributos de calidad, se utilizó como base las características más
frecuentemente nombradas en los modelos de calidad para componentes existentes en la
literatura [25]. Los atributos son los siguientes:
Para definir las subcaracterísticas, se utilizó el trabajo de Álvaro et al. [21] el cual define un
modelo de calidad con las características mencionadas (basadas en ISO 9126), adecuándose al
contexto de componentes de software: redefine subcaracterísticas, elimina algunas que son
65
irrelevantes o no aplican, y agrega cuatro nuevas subcaracterísticas (Autosuficiencia,
Configurabilidad, Escalabilidad y Reusabilidad).
Dada la naturaleza y los datos que se poseen para realizar la evaluación de los componentes
de facturación electrónica, algunas subcaracterísticas fueron adicionalmente omitidas del
modelo. La subcaracteristica pertinente a la cobertura funcional del software, fue extraída para
ser revisada en detalle, descomponiéndose en una nueva jerarquía.
Para efectos de este trabajo, la característica de negocio (Business) propuesta en dicho trabajo
es dejada fuera de análisis. Aunque es un aspecto de interés a considerar, los distintos tipos de
comercialización de los componentes candidatos no lo permiten.
Las subcaracterísticas son nuevamente desprendidas en atributos de calidad, los que entregan
una forma puntual de medir la calidad de ese aspecto específico a asesorar. Los tipos de
métricas a utilizar para realizar las mediciones de los atributos, son los siguientes:
66
A continuación se definen las subcaracterísticas y los atributos a utilizar para medir cada una
de estas. La rúbrica completa de atributos de calidad queda descrita en la tabla 4.16.
Adecuación (Suitability): Esta característica expresa que tan bien el componente se adecua a
los requerimientos especificados.
67
− Auditabilidad: Este atributo indica si el componente cuenta con un sistema de
auditoría, con la capacidad de registrar el acceso de los usuarios al componente y su
información (Presencia).
68
− Facilidad de aprendizaje: Este atributo intenta estimar la cantidad de esfuerzo y
tiempo necesario para dominar las tareas específicas (usar, configurar, administrar y dominar
el componente) (Calificación).
− Esfuerzo para configurar: Este atributo mide la capacidad del componente para ser
configurado (Calificación).
− Tiempo de respuesta: Este atributo mide el tiempo desde que se envía una petición
hasta que se el componente envía una respuesta (Valor numérico).
69
Eficiencia material (Resource efficiency): Esta característica indica la cantidad de recursos
utilizados para realizar tareas específicas, bajo condiciones.
− Set de pruebas provisto: Este atributo indica si existen set de tests provistos para
verificar la funcionalidad del componente y/o medir alguna de sus propiedades (Presencia).
70
5.3.1.6 - Portabilidad - Subcaracterísticas
− Esfuerzo para adaptar: Este atributo indica la cantidad de cambios requeridos para
transferir un componente a otro ambiente (Calificación).
Reusabilidad (Reusability): Esta característica evalúa la habilidad del componente para ser
reutilizado.
71
Tabla 4.16: Definición de atributos de calidad a evaluar en rubrica.
Característica Subcaracteristica Atributo Tipo Métrica Valores
Pre-condicionado y Post-
Funcionalidad Adecuación condicionado Presencia No/Si
Precisión Correctitud Porcentual 0-100 (%)
Compatibilidad de
Interoperabilidad información Presencia No/Si
Encriptación de la
Seguridad información Presencia No/Si
Controlabilidad Calificación 1-5
Auditabilidad Presencia No/Si
Conformidad Estandarización Presencia No/Si
Certificación Presencia No/Si
Autosuficiencia Grado de independencia Calificación 1-5
Usabilidad Comprensibilidad Documentación disponible Presencia No/Si
Calidad de documentación Calificación 1-5
72
5.3.2 Cobertura funcional
Para evaluar la cobertura funcional. Se hará uso de una escala de 3 valores posibles: sin
cobertura (0), cobertura parcial (1) y cobertura total (2).
La rúbrica generada será combinada con la entregada por los atributos de calidad, formando la
rúbrica final.
73
Envío de respuesta de DTE
Generación Muestra Impresa
Generación de Copias Impresas Factura Electrónica
Generación Muestra Impresa
Guía de Despacho
Generación Muestra Impresa
Nota de Crédito
Generación Muestra Impresa
Nota de Débito
Generación información Compras y Ventas Generación de Libro de Compra
Generación de Libro de Venta
Con la rúbrica formada, se evaluó los componentes candidatos en sus respectivos entornos de
prueba. Dependiendo del tipo de métrica, el resultado originado fue una medición exacta, o
una calificación cualitativa, la cual será fundamentada. Esta sección se encargará de mostrar
los resultados obtenidos para cada métrica de la rúbrica, en los 3 candidatos seleccionados.
74
− Generación de un EnvioDTE y Envío al SII: Se evalúa que el componente sea capaz
de generar DTE’s empaquetados en un EnvioDTE mediante los parámetros de entrada, y que
estos puedan ser enviado al SII sin errores, ni rechazos.
Se construyen 8 casos para los dos sets de prueba, variando la estructura del XML entregado,
y los DTE’s requeridos a generar. Cada una de las pruebas se ejecuta 2 veces. Los resultados
para cada componente pueden ser observados en la tabla 4.18:
En el caso de LibFacturista, solo fueron posibles realizar las pruebas que eran soportadas por
las funcionalidades del componente. Debido a que este no puede generar el XML de los DTE,
ni tampoco soporta el firmado de XML con más de un DTE en este.
75
acceder a sus funciones. Este archivo se encuentra pre-compilado, por lo que para modificar y
acceder a funciones de carácter privado se necesitan aplicar procedimientos de ingeniería
inversa.
76
− LibFacturista: Este componente que cuenta con funcionalidades limitadas, solo es
capaz de firmar y enviar los DTE al SII. La generación del XML debe ser implementada fuera
del componente, generando un alto grado de dependencia en otros componentes. La
calificación puesta a este componente es de 2.
77
desconoce los posibles atributos que el componente permite. En el caso de “LibreDTE-lib”, la
documentación generada es exhaustiva y estandarizada. Cómo se origina del código fuente, es
un reflejo más idóneo del funcionamiento de este, y se mantiene al día con la modificación de
éste de manera semi-automatizada.
Para “LibFacturista”, se provee un archivo de configuración que sigue una estructura clave-
valor similar a los ficheros .ini, la cual permite definir aspectos regionales del componente y
del agente encargado de realizar la integración. El resto de las configuraciones es entregado
mediante un string que separa las tuplas clave-valor utilizando punto y coma. Ya que la
documentación para estos parámetros no es exhaustiva, y su magnitud es limitada, se evalúa al
componente en este aspecto con una calificación de 2 (Esfuerzo alto).
78
En el caso de “LibreDTE-lib”, toda la configuración es provista exclusivamente al
componente por medio de los parámetros permitidos para cada una de sus interfaces. Los
parámetros otorgan una gran flexibilidad a la hora de configurar el componente (con una alta
magnitud de parámetros por configurar), pero al no estar centralizados, suponen un esfuerzo
para el integrador, teniendo que poseer nociones más exactas de cómo el componente opera, y
en cuál de sus llamadas debe ser configurado. Por aquellas razones, el componente obtiene
una calificación de 3 (Esfuerzo medio).
Para “LibreDTE-lib”, los errores son almacenados en un “log” (registro) de mensajes, común
en el componente. Este “log” puede ser revisado al momento posterior de realizar una
operación para revisar si este ocurrió sin errores.
79
En “FacturaciónElectronica”, aunque algunas interfaces retornan un valor de verdad que
indica el éxito de la llamada, no existe un comportamiento estandarizado para manejar los
posibles errores, y no están todos debidamente catalogados.
Se realizaron 5 muestras las cuales fueron promediadas para cada prueba. Los resultados están
expuestos en la tabla 4.19:
80
Tabla 4.19: Resultados encontrados para atributo de calidad “Tiempo de respuesta”.
LibFacturista LibreDTE-lib Facturación_Electronica
Tiempo de respuesta: Firma de un
XML 373 [ms] 13 [ms] 26 [ms]
Tiempo de respuesta: Envío de DTE al
SII 3571 [ms] 719 [ms] 1642 [ms]
Tiempo de respuesta: 1 EnvioDTE Set
Básico -- 1794 [ms] 15510 [ms]
Tiempo de respuesta: 100 EnvioDTE
de 10 facturas, sin envío -- 21334 [ms] 141181 [ms]
49
Arnaud Le Blanc. PHP memory profiler extension [en línea] <https://github.com/arnaud-lb/php-
memory-profiler> [consulta: 26 octubre 2016].
50
Python. memory_profiler 0.41: A module for monitoring memory usage of a python program [en
línea] <https://pypi.python.org/pypi/memory_profiler> [consulta: 26 octubre 2016].
51
Sam Saffron. memory_profiler for ruby [en línea]
<https://github.com/SamSaffron/memory_profiler> [consulta: 26 octubre 2016].
81
Tabla 4.21: Resultados encontrados para atributo de calidad “Utilización de disco”.
LibFacturista LibreDTE-lib Facturación_Electronica
7,61 [MB] 2,37 [MB] 2,12 [MB]
82
5.4.1.6 Característica “Portabilidad”
Para analizar este aspecto, se realiza el supuesto de querer adaptar el formato de los DTE para
contener otro formato debido a un cambio regional, teniendo que hacer variaciones en la
estructura de los DTE, campos de carátula y nodos de detalle; y en la ruta HTTP a la cual se
debe enviar los DTE.
Ya que los componentes candidatos responden a un fin muy específico en un formato exacto,
y las modificaciones que pueden ser requeridas para trasladarlos a otro ambiente pueden ser
mucho mayores a las propuestas, esta aproximación es minimalista al problema de estimar
este atributo. Aun así, nos entrega un dato de las magnitudes relativas de los esfuerzos
necesarios para adaptar estos componentes.
83
esquema definido por el SII, son completamente maleables (exceptuando las firmas
electrónicas y el timbrado de los documentos, procesos que son realizados por el
componente). Dado esto, el componente fue calificado con una alta abstracción de dominio
(5).
− LibreDTE-lib: Este componente se encarga de generar los DTE a partir de la
información entregada como parámetro (mediante la utilización de un objeto
sasco\LibreDTE\Sii\Dte). Los parámetros posibles son aquellos que el SII permite, incluyendo
tipos opcionales y de carácter condicional para contribuyentes especiales (impuestos
adicionales según actividad, retenciones, valores en otra moneda y otros). Como el
componente se puede adaptar a estos casos, fue calificado con una alta abstracción de dominio
(5).
− FacturaciónElectronica: La generación de los DTE es realizada dentro del
componente al momento de realizar el envío, mediante un objeto SiiFactura. Este toma una
serie de parámetros disponibles en los cuales se inserta la información que el XML final
contendrá. La generación de estos campos solo considera aquellos de carácter obligatorio para
4 tipos de DTE (facturas, guías de despacho, notas de crédito y notas de débito electrónicas).
Dado que el componente sólo puede generar DTE bajo esas condiciones, se calificó con una
baja abstracción de dominio (2).
De esta forma, “LibFacturista” es el más independiente de los candidatos (5), ya que su modo
de uso mediante ligado dinámico, puede ser integrado a una alta variedad de lenguajes y
sistemas operativos. Para “LibreDTE-lib”, y “FacturaciónElectronica”, estos componentes son
locales a un lenguaje de programación, por lo que generan un nivel medio de dependencia (3).
84
5.4.2 Resultados de “Cobertura funcional”
Revisión de DTE 0 2 2
85
Generación Muestra Impresa
Nota de Débito 2 2 2
Generación
información Compras
y Ventas Generación de Libro de Compra 0 2 2
− LibreDTE-lib obtiene un puntaje de 38 sobre 41. Los aspectos que este no cubre están
relacionados con el intercambio entre contribuyentes, ya que este delega la recepción y envío
de correos a una implementación externa al componente.
86
Capítulo 6: Validación
La propuesta de componente fue descrita ampliamente junto a sus detalles de implementación
en la sección de “Desarrollo”, la cual fue acompañada a la creación de un sistema ERP que
era beneficiado por sus funcionalidades. El sistema ERP construido a medida, fue necesario
puesto que los requerimientos provenían de un rubro con necesidades particulares, las cuales
no eran fácilmente cubiertas por las ofertas existentes en el mercado.
87
6.1 Plan de transición y despliegue
La construcción del sistema ERP se realizó de forma iterativa, poniendo énfasis en cubrir las
necesidades de facturación electrónica en las últimas iteraciones, y delegando la construcción
de funciones del sistema ERP a iteraciones tempranas. Se designaron 3 iteraciones, las cuales
dividen los casos de uso asociados al sistema ERP considerando la anterior premisa.
Cada iteración a desarrollar supone un entregable a otorgar al cliente, el cual podrá evaluar
mediante el uso y validar su correctitud. La validación temprana de los casos de uso más
simples, permite disminuir los riesgos asociados a dedicar esfuerzos de manera equivoca, los
cuales son más costosos de corregir en fases tardías del desarrollo. El hecho que el cliente
pueda evaluar cada entregable, permite ajustar la aplicación rápidamente para las siguientes
iteraciones.
Para realizar la transición de la información, fue necesario construir pequeñas utilidades que
permitieron el traspaso de información entre el sistema viejo y el actual. Estas aplicaciones
utilizan algunas de las gemas anteriormente mencionadas en la “Implementación del Sistema
ERP”, como roo o axlsx.
Una vez que las tres iteraciones fueron construidas, entregadas y evaluadas por el cliente, se
inició una fase correctiva, en la cual el sistema fue adaptando sus funciones para concordar
con las expectativas del cliente. Luego de esta fase correctiva y realizando las capacitaciones
guiadas a todo usuario que hará uso del sistema en las dependencias del cliente, el sistema fue
puesto en marcha.
El despliegue del sistema ERP fue desarrollado de forma paralela al plan de transición, dado
que cada iteración una vez finalizada, fue desplegada en infraestructura de producción. El
plan de despliegue necesita permitir la incorporación rápida de nuevas versiones del sistema a
producción, teniendo en cuenta la prevención de bajas en el funcionamiento del sistema.
88
la aplicación sea accesible desde otras localizaciones geográficas. Por lo que se optó por
utilizar infraestructura en la nube.
Por ello, se pensó en una solución PaaS (Platform as a Service), que proveen hardware y
herramientas de software, necesarias para levantar aplicaciones en la web a sus usuarios como
un servicio52. El usuario no maneja ni controla directamente la infraestructura Cloud (la cual
incluye redes, servidores, sistemas operativos o almacenamiento), pero tiene control acerca de
las aplicaciones desplegadas y posiblemente opciones de configuración para el ambiente en el
cual corre la aplicación53.
Ejemplos de soluciones PaaS existentes son: EngineYard, Google App Engine, Heroku,
Microsoft Azure, Amazon AWS, Nitrous.io, OpenShift, entre otros54.
Para el despliegue del sistema ERP, se eligió Amazon AWS, los cuales ofrecen una gran
cantidad de soluciones IaaS (Amazon EC2, Amazon RDS, Amazon S3), las cuales son
accesibles desde su servicio PaaS, conocido como Amazon Elastic Beanstalk.
Una vez que se sube una versión de la aplicación, la plataforma se encarga de los pasos
posteriores de despliegue55. Cada aplicación vive en un ambiente, el cual es el encargado de
preocuparse del despliegue, balanceo de carga, escalamiento y monitoreo de la aplicación.
52
TechTarget. Platform as a Service (PaaS) [en línea]
<http://searchcloudcomputing.techtarget.com/definition/Platform-as-a-Service-PaaS> [consulta: 26
octubre 2016].
53
IBM Cloud. What is platform as a service (PaaS)? [en línea]
<http://www.thoughtsoncloud.com/2014/02/what-is-platform-as-a-service-paas> [consulta: 26 octubre
2016].
54
PaaSfinder. Find your PaaS [en línea] <https://www.paasify.it/filter> [consulta: 26 octubre 2016].
55
Amazon Web Services. AWS Elastic Beanstalk [en línea]
<https://aws.amazon.com/elasticbeanstalk> [consulta: 26 octubre 2016].
89
posibilidad de pagar precios fijos por una reserva de tiempo, u “on-demand” (solo por la
cantidad de horas utilizadas). Este último modelo se puede combinar con la utilidad de
escalamiento automatizado provista por Amazon, cubriendo las necesidades de los usuarios
que acceden a la aplicación, y pagando solo los recursos necesarios por ello.
Para el levantamiento del sistema ERP, se utilizaron tres servicios de Amazon, en conjunto
con Elastic Beanstalk para el despliegue:
− Amazon EC2 para el despliegue del servidor que ejecuta el sistema ERP. Se utilizó
una instancia t2.micro, la cual fue configurada con el sistema operativo Amazon Linux
2016.03 v2.1.0 de 64 bits, y con la versión 2.3 de Ruby.
− Amazon RDS para contener la base de datos relacional utilizada por las instancias. Se
utilizó una instancia db.t2.micro, con PostgreSQL 9.5.1 como motor de base de datos.
El despliegue de cada nueva versión fue asistido con la utilidad CLI de Elastic Beanstalk, eb.
La utilidad permite integrarse al sistema de versionamiento git, apuntando el despliegue de
una branch a una aplicación en Elastic Beanstalk. Para la aplicación, se apuntó que el
despliegue de las versiones se realizará desde la branch master. Se utilizó git-flow como
estrategia para el desarrollo de cada iteración/casos de uso, y para la fase correctiva del
sistema. La utilidad eb se asegura de realizar el deployment de la aplicación, en el estado del
último commit de la branch apuntada.
Una vez que la aplicación es subida a Elastic Beanstalk, esta es distribuida a la(s) instancias,
las cuales realizan el proceso de actualización correspondiente, reportando su estado a Elastic
Beanstalk. Los reportes permiten tener control de la información de despliegue, si este ha
finalizado correctamente, o si se presentaron errores.
56
Amazon Web Services. Amazon S3 Storage Classes [en línea] <https://aws.amazon.com/s3/storage-
classes> [consulta: 26 octubre 2016].
90
6.2 Identificación de escenarios
Para identificar los escenarios, es necesario discutir los resultados encontrados en cada
atributo de la rúbrica.
Aspectos que requieran la generación avanzada de XML (en el caso de contribuyentes que
poseen una situación tributaria que se escapa del modelo más usual. LibreDTE-lib posee el
soporte adecuado para estos casos. En los aspectos que Facturación_Electronica sobresale es
en la recepción y envío de DTE por parte de otros contribuyentes, ya que puede ser
configurado para el cumplimiento de dichos propósitos.
Todos los componentes están estandarizados por las obligaciones impuestas por el SII para
operar; ninguno de los candidatos cuenta con una certificación adicional a la otorgada por el
SII, al cumplir las pruebas del ambiente de certificación.
91
Respecto a la característica Usabilidad: los candidatos LibFacturista y LibreDTE-lib poseen
una documentación disponible, siendo la de LibreDTE-lib de mejor calidad (alta).
Facturación_Electronica no fue documentado apropiadamente, siendo este uno de los aspectos
futuros a mejorar.
En la característica de eficiencia, LibreDTE-lib demostró ser altamente más eficiente que los
otros candidatos, ganando todas las pruebas exceptuando el de la utilización en disco (la cual
para la mayoría de los efectos prácticos, no posee un valor relevante), la cual fue menor en
Facturación_Electronica por un 11,8% (0,25 [MB]). El segundo más eficiente es
Facturación_Electronica, el cual tiene tiempos de respuesta cercanos al de LibreDTE-lib en
algunos casos. LibFacturista fue el más ineficiente en los tres aspectos (utilización de
memoria, disco y tiempos de respuesta).
92
poca abstracción de dominio). Los otros componentes poseen un nivel medio de esfuerzo, por
lo que son más adecuados para una implementación diferente a la propuesta por el SII.
En base a lo discutido, se construye una tabla resumen de los componentes en los aspectos
macro evaluados en la rúbrica:
El componente LibFacturista posee baja cobertura funcional, una usabilidad (para integrar)
regular y confiabilidad regular. Gracias a su independencia arquitectural está pensado para ser
utilizado en soluciones en las que se necesita una gran cobertura de plataformas, o que se
requiere trabajar con una plataforma en específico. Requiere ser apoyado con otros COTS o
una implementación propia para cubrir el modelo de operación del SII.
LibreDTE-lib destaca en la mayoría de los atributos, es una solución robusta para ambientes
de desarrollo PHP. Siendo el único de los tres que provee opciones de generación avanzada de
DTE, es el candidato a utilizar en casos que se escapen del contribuyente tradicional, o en
93
aquellos que la eficiencia es requerida (como es el caso en contribuyentes que emitan o
reciban una gran cantidad de documentos tributarios). Requiere un esfuerzo de configuración
medio y debe ser complementado con una estrategia de intercambio entre otros
contribuyentes, ya que carece de esta.
Facturación_Electronica destaca por su alta cobertura funcional, librando de casi todas las
tareas pertinentes al integrador. Aunque su eficiencia, facilidad de uso, confiabilidad son
menores a las de LibreDTE-lib. Se identifica que es útil en casos que requieren la menor
intervención posible en el modo de operación del SII, y donde la magnitud de información
con la que trabaja el componente, no sea muy grande (por temas de eficiencia). Es un
componente que destaca por su facilidad de integración (gracias a su configurabilidad y
facilidad de aprendizaje). Su uso queda recomendado para la construcción de sistemas ERP a
medida, que asistan a empresas de pequeña o mediana escala.
94
Capitulo 7: Conclusiones
En este trabajo se observó el desarrollo de una solución de facturación electrónica, en
conformancia con el modelo de operación definido por el SII. Dado que todos los
contribuyentes electrónicos requerían una solución de este carácter, independiente de su rubro
o modelo de operación, se construyó una solución capaz de abstraerse de la implementación
particular, permitiendo ser reutilizada. Se encontró que la arquitectura basada en componentes
y el uso de COTS respondía a este propósito en particular, por lo que se procedió a la
construcción de un componente de facturación electrónica.
Para verificar que el componente era capaz de resolver la problemática, este fue integrado a
un sistema ERP a medida, el cual fue construido en paralelo a la realización del proyecto. El
ecosistema de gemas de Ruby demostró ser particularmente beneficioso a la hora de
encapsular el componente, y definir sus dependencias a utilizar.
Por otra parte, la utilización de engines propuesta en [13] ayudo a separar las funcionalidades
del sistema ERP en módulos (componentes). Se cree que en proyectos grandes de Rails, este
beneficio es significante, disminuyendo la complejidad de las dependencias y facilitando el
trabajo entre equipos.
Otro aspecto que se cubrió en este trabajo fue el otorgar una herramienta para asesorar la
evaluación de componentes de facturación electrónica. Se descubrió que la evaluación
de la calidad de componentes de software no calzaba idealmente con los modelos de
calidad para software existentes, puesto que la visión de otros stakeholders, y los
posibles atributos a medir, necesitaban cambiar la perspectiva de la evaluación. Se
desarrolló una rúbrica ajustada únicamente a este propósito, bajo la cual se evaluaron
tres componentes (incluyendo el desarrollado).
A modo de detalle, el objetivo general de este trabajo fue cubierto en la sección 4.1 del
desarrollo. Sección que otorga gran detalle técnico de: las obligaciones impuestas por el SII
que fueron necesarias de implementar; especificaciones del componente y del sistema ERP a
desarrollar; y detalles de la integración.
Puesto que muchos de los detalles técnicos de bajo nivel son difíciles de hallar en la
documentación u son omitidos, esta sección resulta particularmente valiosa. La información
rescatada para lograr este propósito se originó de varios sitios. Se destaca la importancia de
95
los documentos del SII; la mesa de ayuda del SII; el sitio de CyptoSys que profundiza en las
firmas electrónicas XMLDSIG57; y el sitio de Factura Electrónica Desarrolladores58, donde se
congrega una gran cantidad de inquietudes técnicas.
El estudio cauteloso de esta sección, complementado con una lectura del instructivo técnico
del SII, pueden ser de gran utilidad a la hora de implementar una solución de facturación
electrónica.
En relación a cada uno de los objetivos específicos de este trabajo, se resumen los resultados
obtenidos:
57
DI Management Services. XML-DSIG and the Chile SII [en línea]
<http://www.cryptosys.net/pki/xmldsig-ChileSII.html> [consulta: 26 octubre 2016].
58
Marcelo Rojas. Factura Electrónica Desarrolladores .Net [en línea]
<http://lenguajedemaquinas.blogspot.cl> [consulta: 26 octubre 2016].
96
plataforma demostró ser útil para abstraerse de los detalles finos del despliegue, además de
proveer un sistema de monitoreo y opciones de escalabilidad, permitiendo ajustar
dinámicamente la cantidad de infraestructura para responder a las demandas de usuarios
finales.
− Realizar una revisión de la rúbrica en base al modelo de calidad ISO 25010, puesto
que la rúbrica originada está basada en modelos de calidad ajustados para componentes, que
estaban fuertemente ligados a ISO 9126. De las propuestas encontradas, Q’Facto 12 fue la
única en hacer un nexo con ISO 25010.
97
Referencias
[1] CENTRO de estudios de la economía digital. Perspectivas de la factura electrónica en Chile.
Santiago, Cámara de comercio de Santiago, 2003. 2 p.
[2] Pour G. (1998), Component-based software development approach: new opportunities and
challenges
[3] LEAL B., Tatiana. y NAVEA B., Paola. Facturación electrónica. Revista de Estudios Tributarios
(10): 51-67, Julio, 2014.
[4] Ley N° 825. Diario Oficial de la República de Chile, Santiago, 30 de noviembre de 1976.
[5] A PROCESS for COTS Software Product Evaluation por S. COMELLA-DORDA [et al]. Estados
Unidos, Software Engineering Institute, Carnegie Mellon University, 2004.
[6] SONI, Nikita, JHA, S. K. Component Based Software Development : A new Paradigm. En:
International Journal Of Scientific Research And Education (2°, 2014, India). Amity Institute of
Information and Technology, 2014 pp. 969-974.
[8] TAHVILDARI, Ladan. Component-Based Software Systems: Quality Attributes and CBSE:
Concerning Predictability [diapositivas]. Canadá. University of Waterloo, 2011. 47 diapositivas, col..
[10] AOYAMA, Mikio. New Age of Software Development: How Component-Based Software
Engineering Changes the Way of Software Development?. Japon, Department of Information and
Electronics Engineering, Niigata Institute of Technology, 1998.
[11] PRADEEP, Tomar, NASIB, Singh G. New Algorithm for Component Selection to Develop
Component-Based Software with X Model. En: Lecture Notes on Software Engineering (3°, 2013,
Estados Unidos). IACSIT, 2013 pp. 298-302.
[12] KRASNER, Glen E., POPE, Stephen T. A Cookbook for Using the Model-view Controller User
Interface Paradigm in Smalltalk-80. J. Object Oriented Program. (1): 26-49, Agosto-Septiembre, 1988.
[13] COMPONENT-BASED Rails Applications por HAGEMANN Stephan [et al]. Leanpub, 2016.
[14] IEEE. IEEE Standard Glossary of Software Engineering Terminology en: IEEE Std 610.12 (1990).
1990 pp 1-84.
98
[15] McCall, RICHARDS, Jim A., WALTERS, Gene F., RICHARDS, Paul K. Factors in Software
Quality. Estados Unidos, General Electric Company, 1977. 1 v.
[17] BOEHM, Barry W., BROWN, John R., LIPOW, M. Quantitative evaluation of software quality.
En: Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society
Press (2°, 1976, Estados Unidos), IEEE Computer Society, 1976 pp. 592-605.
[18] GRADY, Robert B. Practical software metrics for project management and process improvement,
Prentice Hall, 1992.
[19] ISO. IEC 9126-1: Software Engineering-Product Quality-Part 1: Quality Model. Geneva,
International Organization for Standardization, 2001. 27 p.
[20] ISO. IEC25010 (2011) Systems and software engineering–Systems and software Quality
Requirements and Evaluation (SQuaRE) – System and software quality models. International
Organization for Standardization. Geneva, International Organization for Standardization, 2011. 34 p.
[21] TOWARDS a Software Component Quality Model por Álvaro Alexandre [et al]. Brasil, Federal
University of Pernambuco and C.E.S.A.R – Recife Center for Advanced Studies and Systems, 2005.
[22] BERTOA, Manuel F., VALLECILLO, Antonio. Quality attributes for COTS components. España,
Universidad de Málaga, Departamento de Lenguajes y Ciencias de la Computación, 2002.
[23] RAWASHDEH, Adnan, MATALKAH, Bassem. A new software quality model for evaluating
COTS components. Journal of Computer Science (2°, 2006, Estados Unidos). Science Publications,
2006 pp 373-381.
[25] THAPAR, Simrandeep Singh, SINGH, Paramjeet, RANI, Shaveta. Reusability-based quality
framework for software components en ACM SIGSOFT Software Engineering Notes (39, 2):1-5.
Marzo. 2014.
99
Anexo
Iniciar Sesión
Nombre: Iniciar sesión
Actores: Vendedor
Precondiciones: Vendedor debe existir en el sistema
Escenario principal:
1. Vendedor pone su nombre de usuario y contraseña
2. Sistema valida el vendedor y lo dirige a menú principal
Extensiones
2a Validación de usuario o contraseña inválida
1. Sistema responde con error de validación
2. Vendedor ingresa sus datos correctamente
3. Sistema valida el vendedor y lo dirige a menú principal
Administrar Cuenta
Nombre: Administrar cuenta
Actores: Vendedor
Precondiciones: Vendedor existente y autentificado en el sistema
Escenario principal:
1. Vendedor elige la opción de Administrar cuenta
2. Vendedor modifica su nombre y/o cambia su contraseña
3. Sistema modifica cuenta de vendedor exitosamente
Administrar Vendedores
Nombre: Administrar vendedores
Actores: Administrador
Precondiciones: Administrador existente y autentificado en el sistema
Escenario principal:
Este escenario describe la creación de un nuevo vendedor en el sistema.
1. Administrador elige la opción de crear nuevo vendedor en el sistema
2. Administrador elige nombre, contraseña y rol a nuevo vendedor.
3. Sistema crea exitosamente nuevo vendedor en el sistema
Extensiones
1a Administrador desea modificar vendedor existente en el sistema
1. Administrador busca vendedor por nombre
2. Sistema despliega resultados en una lista
100
3. Administrador elige el indicado
4. Administrador modifica nombre, contraseña o rol de vendedor existente
5. Sistema modifica exitosamente vendedor del sistema
1b Administrador desea eliminar vendedor existente en el sistema
1. Administrador busca vendedor por nombre
2. Sistema despliega resultados en una lista
3. Administrador elige el indicado
4. Administrador elige “Eliminar vendedor” y confirma
5. Sistema elimina exitosamente vendedor del sistema
a. Vendedor no podrá ser eliminado si tiene guías de venta
asociadas
Administrar Clientes
Nombre: Administrar Clientes
Actores: Vendedor
Precondiciones: Vendedor existente y autentificado en el sistema
Escenario principal:
Este escenario se da cuando el vendedor quiere crear un nuevo cliente en el sistema
1. Vendedor elige la opción de crear nuevo cliente
2. Vendedor ingresa datos personales del clientes: Nombre, RUT, giro, teléfono
fijo, y móviles (si tuviera), dirección, ciudad, comuna y fija una condición de pago
para el cliente (de las ya existentes).
3. Sistema ingresa exitosamente cliente al sistema
Extensiones:
1a El vendedor quiere modificar un cliente ya existente
1. Vendedor elige la opción de modificar cliente
2. Vendedor busca al cliente ya existente por alguna de las siguientes
propiedades: Nombre, RUT, email
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige el cliente indicado
5. Vendedor modifica alguno de los datos personales del cliente: Nombre, RUT,
giro, teléfono fijo, y móviles (si tuviera), dirección, ciudad, comuna y fija una
condición de pago para el cliente (de las ya existentes).
6. Sistema modifica exitosamente al cliente del sistema
1b El vendedor quiere eliminar un cliente ya existente
1. Vendedor elige la opción de modificar cliente
2. Vendedor busca al cliente ya existente por alguna de las siguientes
propiedades: Nombre, RUT, email
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige el cliente indicado
5. Vendedor selecciona “Eliminar cliente” y confirma
101
6. Sistema eliminar exitosamente al cliente junto con sus guías de venta y otras
entidades débiles del modelo asociadas.
Administrar Láminas
Nombre: Administrar Láminas
Actores: Vendedor
Precondiciones: Vendedor existente y autentificado en el sistema
Escenario principal:
Este escenario se da cuando el vendedor quiere crear una nueva lámina en el sistema
1. Vendedor elige la opción de crear nueva lámina
2. Vendedor ingresa datos de la lámina: Nombre, código, marca, acabado, tipo
de lámina, precios de referencia en el mercado (precio general neto y precio
comprado neto) y el stock actual de la lámina en bodega (si fuera aplicable).
3. Sistema ingresa exitosamente la lámina al sistema
Extensiones:
1a El vendedor quiere modificar una lámina ya existente
1. Vendedor elige la opción de modificar lámina
2. Vendedor busca a la lámina ya existente por alguna de las siguientes
propiedades: Nombre, Código, Marca
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige la lámina indicada
5. Vendedor modifica alguno de los datos de la lámina: Nombre, código, marca,
acabado, tipo de lámina, precios de referencia en el mercado (precio general neto y
precio comprado neto) y el stock actual de la lámina en bodega (si fuera aplicable).
6. Sistema modifica exitosamente la lámina del sistema.
1b El vendedor quiere eliminar una lámina ya existente
1. Vendedor elige la opción de modificar lámina
2. Vendedor busca a la lámina ya existente por alguna de las siguientes
propiedades: Nombre, Código, Marca
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige la lámina indicada
5. Vendedor selecciona “Eliminar lámina” y confirma
6. Sistema elimina exitosamente a la lámina junto con sus entidades débiles
asociadas.
Administrar Artículos
Nombre: Administrar Artículos
Actores: Vendedor
Precondiciones: Vendedor existente y autentificado en el sistema
Escenario principal:
Este escenario se da cuando el vendedor quiere crear un nuevo artículo en el sistema
102
1. Vendedor elige la opción de crear nuevo artículo
2. Vendedor ingresa datos de la lámina: Nombre, código, precio neto, tipo y
unidad de medida principal (largo en caso de muebles, unidad caso de clavos, etc.).
3. Sistema ingresa exitosamente el artículo al sistema
Extensiones:
1a El vendedor quiere modificar un artículo ya existente
1. Vendedor elige la opción de modificar artículo
2. Vendedor busca el artículo ya existente por alguna de las siguientes
propiedades: Nombre, Código
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige el artículo indicado
5. Vendedor modifica alguno de los datos de la lámina: Nombre, código o
precio neto.
6. Sistema modifica exitosamente el artículo del sistema.
1b El vendedor quiere eliminar un artículo ya existente.
1. Vendedor elige la opción de modificar artículo
2. Vendedor busca el artículo ya existente por alguna de las siguientes
propiedades: Nombre, Código
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige el artículo indicado
5. Vendedor selecciona “Eliminar artículo” y confirma
6. Sistema elimina exitosamente el artículo junto con sus entidades débiles
asociadas.
103
i. Vendedor busca la lámina por su código,
nombre o marca
ii. Sistema despliega lista de resultados que
coincidan con la búsqueda
iii. Vendedor selecciona el artículo indicado
f. Vendedor determina cantidad a llevar del artículo
5. Vendedor agrega recargos y/o descuentos al pedido
6. Vendedor ingresa abono por parte del cliente.
7. Sistema ingresa correctamente guía de venta al sistema.
Extensiones:
2a El RUT ingresado no existe en el sistema
1. Vendedor ingresa datos personales del clientes: Nombre, RUT, giro, teléfono
fijo, y móviles (si tuviera), dirección, ciudad, comuna y fija una condición de pago
para el cliente (de las ya existentes).
2. Sistema ingresa exitosamente cliente al sistema
1a Vendedor quiere modificar una guía de venta ya existente en el sistema
1. Vendedor elige la opción de modificar una guía de venta
2. Vendedor busca la guía de venta por el RUT del cliente, o por el identificador
de la guía de venta
3. Vendedor puede modificar/eliminar/agregar cualquier artículo de la guía de
venta
a. Siempre que este artículo no se encuentre asociado a ninguna
factura
4. Vendedor puede modificar el abono, recargos y/o descuentos asociados al
pedido
5. Sistema modifica correctamente la guía de venta en el sistema
104
Emitir una factura electrónica a partir de una factura
Nombre: Emitir una factura electrónica a partir de una factura
Actores: Vendedor, Facturación SII.cl
Precondiciones: Vendedor existente y autentificado en el sistema, guía de venta existente en el
sistema, Factura existente en el sistema
Escenario principal:
1. Vendedor elige la opción de emitir factura electrónica
2. Vendedor busca una factura por su número de documento, RUT a facturar o
guía de venta asociada
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige la factura indicada
5. Sistema genera XML de factura electrónica acuerdo a los estándares del SII.cl
6. Sistema envía bajo conexión segura a Facturación SII.cl el XML de la factura
7. Facturación SII.cl verifica la factura y manda información de éxito a Sistema
8. Sistema confirma la transacción y marca la factura como firmada
electrónicamente.
105
Actores: Vendedor
Precondiciones: Vendedor existente y autentificado en el sistema
Escenario principal:
1. Vendedor elige la opción ingresar compromiso
2. Vendedor busca una guía de venta por su identificador o RUT de cliente
asociado
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige la guía de venta indicada
5. Vendedor ingresa datos del nuevo compromiso: Fecha del cheque, rut
girador, glosa (si aplica), número documento (numero cheque), cuenta corriente,
valor, banco y plaza, estado actual, y si esta cancelado o no (si está cancelado se
incluye fecha).
6. Sistema ingresa exitosamente el compromiso al sistema.
106
Este escenario se da cuando el vendedor quiere crear un nuevo recargo o descuento en
el sistema
1. Vendedor elige la opción ingresar recargo/descuento
2. Vendedor ingresa descripción, tipo (VF,VV,PF,PV) y cantidad (si aplica) del
recargo/descuento.
3. Sistema ingresa exitosamente el recargo/descuento al sistema.
Extensiones:
1a El vendedor quiere modificar un recargo/descuento ya existente en el sistema
1. Vendedor elige la opción modificar recargo/descuento
2. Vendedor elige el recargo/descuento que desea modificar de una lista
3. Vendedor cambia la descripción, tipo o cantidad del recargo/descuento.
4. Sistema modifica exitosamente el recargo/descuento del sistema.
1b El vendedor quiere eliminar un recargo/descuento ya existente en el sistema
1. Vendedor elige la opción modificar recargo/descuento
2. Vendedor elige el recargo/descuento que desea modificar de una lista
3. Vendedor elige “Eliminar recargo/descuento” y confirma
4. Sistema elimina exitosamente el recargo/descuento.
a. Guías que ya se encuentren con el recargo/descuento
asociado, permanecerán con una copia estática de dicho recargo/descuento,
por lo que su eliminación no produce efecto cascada
107
2. Vendedor busca el banco/plaza a modificar de una lista
3. Vendedor selecciona el indicado
4. Vendedor elige “Eliminar banco/plaza” y confirma
5. Sistema elimina exitosamente banco y plaza del sistema
a. En el caso de existir un compromiso existente con esa plaza,
no permitirá la eliminación
b. La eliminación de un banco eliminará todas sus plazas
asociadas, siempre que una de sus plazas no se encuentre asociada a un
compromiso existente, en dicho caso, no permitirá la eliminación.
108
1. Vendedor elige la opción de emitir factura electrónica
2. Vendedor busca una factura por su número de documento, RUT a facturar o
guía de venta asociada
3. Sistema despliega lista de resultados que coincidan con la búsqueda
4. Vendedor elige la factura indicada
5. Sistema genera código de barra bidimensional PDF417 con información del
timbre electrónica e información necesaria para validarlo (acorde a sii.cl)
6. Sistema genera detalle de la factura acorde a formato de sii.cl, listo para su
impresión.
109
B - Esquemas de modelos de datos
110
Figura B.2: Esquema de modelo de datos para sistema ERP, módulo de facturación
electrónica.
111
Figura B.3: Esquema de modelo de datos para sistema ERP, administración de correos.
112