“elementos de tecnologÍas de informaciÓn involucrados en el modelo de facturaciÓn electrÓnica...
TRANSCRIPT
UNIVERSIDAD ALAS PERUANASFACULTAD DE INGENIERÍAS Y ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
INGENIERÍA DE INFORMACIÓN
“DESARROLLO DE UN SISTEMA DE INFORMACION PAPERLESS WEB PARA MEJORAR EL PROCESO DE FACTURACIÓN
ELECTRÓNICA EN LA EMPRESA COMPUTER PATRISOFT”
INTEGRANTES
CÉSAR HERNÁN PATRICIO PERALTALUIS FRANCISCO RIVERA JARA
NEIL VALDIVIA YAÑEZ
DOCENTE
GLADYS KUNIYOSHI GUEVARA
LIMA – PERÚ
2011
INDICE DE CONTENIDO
1.- CAPITULO 1: INTRODUCCION..........................................................................101.1.- Planteamiento del Problema.........................................................................101.2.- Objetivos Generales.....................................................................................101.3.- Objetivos Específicos....................................................................................101.4.- Alcances.......................................................................................................11
2.- CAPITULO 2: FUNDAMENTOS TEORICOS.......................................................132.1.- Modelo de facturación tradicional versus electrónico...................................13
2.1.1.- Situación actual de la facturación en Chile................................................132.1.2.- Facturación electrónica en Chile...............................................................14
2.2.- Aspectos legales de la facturación electrónica en Chile...............................162.3.- Facturación electrónica y firma digital...........................................................17
2.3.1.- Objetivo de la firma digital.........................................................................172.3.2.- Encriptación con clave pública..................................................................172.3.3.- Certificado digital.......................................................................................202.3.4.- Aplicación de la firma digital en la factura electrónica...............................21
2.4.- El estándar XML y su aplicación en la factura electrónica............................262.4.1.- ¿Qué es XML y cuáles son sus beneficios?..............................................262.4.2.- Aplicación de XML en la factura electrónica..............................................282.4.3.- World Wide Web Consortium (W3C).........................................................282.4.4.- Firma digital de documentos XML (XMLDSIG).........................................292.4.5.- Aplicación de XMLDSIG en factura electrónica.........................................312.4.6.- Tecnología XML Web Services y sus beneficios.......................................312.4.7.- Aplicación de la tecnología XML Web Services en factura electrónica.....32
3.- CAPITULO 3: METODOLOGIA...........................................................................353.1.- Descripción de la metodología......................................................................353.2.- Aplicación de la metodología........................................................................36
4.- CAPITULO 4: RESULTADOS Y DISCUSION......................................................444.1.- Evaluación del proyecto................................................................................44
4.1.1.- Evaluación técnica....................................................................................444.1.2.- Evaluación económica..............................................................................484.1.3.- Conclusiones.............................................................................................62
INDICE DE TABLAS
Tabla 2.1: Funciones en el modelo tradicional y electrónico de facturación...................15Tabla 3.1: Artefactos a obtener en la fase de Inicio........................................................37Tabla 3.2: Artefactos a obtener en la fase de Elaboración.............................................39Tabla 3.3: Artefactos a obtener en la fase de Construcción...........................................40Tabla 3.4: Artefactos a obtener en la fase de Transición................................................41Tabla 4.1: Valores de ponderación para asignar a los criterios......................................45Tabla 4.2: Ponderación asignada a cada criterio............................................................46Tabla 4.3: Tipos de calificación para asignar a las alternativas......................................46Tabla 4.4: Resultado de la evaluación técnica...............................................................47Tabla 4.5: Resumen de costos y beneficios...................................................................49Tabla 4.6: Procesos que causarán mayor impacto financiero........................................50Tabla 4.7: Flujo de caja para estimar el costo del desarrollo..........................................52Tabla 4.8: Variables consideradas para calcular el flujo de caja....................................55Tabla 4.9: Costos operacionales incluidos a partir del quinto año..................................55Tabla 4.10: Flujo de caja para medir la rentabilidad del proyecto...................................56Tabla 4.11: Flujo de ahorro de costos para la empresa..................................................60Tabla 4.12: Variables consideradas en el flujo de ahorro de costos...............................60
INDICE DE FIGURAS
Figura 2.1: Modelo tradicional de facturación.................................................................13Figura 2.2: Modelo electrónico de facturación................................................................14Figura 2.3: Ilustración del proceso de encriptación........................................................17Figura 2.4: Encriptación Asimétrica................................................................................18Figura 2.5: Hashing........................................................................................................19Figura 2.6: Representación de un certificado digital.......................................................20Figura 2.7: Estructura del Código de Autorización de Folios..........................................21Figura 2.8: Estructura del Timbre Electrónico.................................................................22Figura 2.9: Código de barras bidimensional (PDF417)...................................................23Figura 2.10: Estructura resumida de un DTE.................................................................24Figura 2.11: Elementos de un DTE que involucran la firma digital.................................25Figura 2.12: Esquema de una firma digital XML.............................................................29Figura 2.13: Participación de XML Web Services en la factura electrónica....................32Figura 3.1: Rational Unified Process (RUP)...................................................................35Figura 3.2: Aplicación de RUP en el proyecto................................................................36Figura 4.1: Principales beneficios de la factura electrónica............................................48Figura 4.2: Principales ahorros de costos de la Factura Electrónica..............................49Figura 4.3: Estudio sobre costos unitarios de facturación de la CSS.............................59
RESUMEN
A raíz de la introducción del modelo de facturación electrónica en Perú es que surge la
idea de llevar a cabo este proyecto, el cual tiene por objetivos generales investigar y
conocer las tecnologías de información involucradas en la facturación electrónica y
construir un conjunto de librerías de clases que puedan ser reutilizadas para la
generación de documentos tributarios electrónicos. Para llevar a cabo este proyecto se
utilizó la metodología Rational Unified Process (RUP), la cual cuenta con fases y
disciplinas que nos permitieron controlar, administrar y desarrollar el proyecto. Se
realizó una evaluación técnica para determinar la mejor alternativa en cuanto a
plataforma y lenguaje para desarrollar las librerías de clases, así como un estudio
económico para determinar el costo de desarrollar el producto y la rentabilidad
económica tanto para el inversionista como para la empresa COMPUTER PATRISOFT
SAC.
CAPITULO 1
PLANTEAMIENTO METODOLÓGICO
1 CAPITULO 1: PLANTEAMIENTO METODOLÓGICO
1.1 Descripción de la Realidad Problemática
Desde hace unos años el Gobierno de Perú se encuentra dando pasos para introducir
el concepto de Gobierno Electrónico (e-government) en el País, pionero de esta tarea
es la Superintendencia de administración Tributaria (SUNAT), el cual dio su primer paso
con la introducción de las declaraciones de impuestos electrónicas a través de Internet
y actualmente se encuentra implantando el modelo de facturación electrónica. Este
revolucionario modelo permitirá a las empresas poder automatizar otra parte de sus
procesos de negocios y por tanto reducir costos y aumentar su eficiencia. Para que las
empresas chilenas puedan adoptar de forma satisfactoria la facturación electrónica,
éstas tendrán que modificar parte de sus procesos internos, incorporar nuevas
tecnologías y modificar sus programas tradicionales de facturación. La idea es poder
construir un producto que pueda ser utilizado por las empresas chilenas, para adaptar
sus programas de facturación y que estos puedan soportar el nuevo modelo de
facturación electrónica.
1.2 Delimitaciones y Definición del Problema
1.2.1. - Delimitaciones:
A. Delimitación Espacial
El presente trabajo de investigación, a nivel de prototipo,
se realizó en la empresa COMPUTER PATRISOFT
S.A.C., ubicada en Lima - Perú. No obstante, aplicabilidad
y alcance de sus resultados, tienen validez en cualquier
organización que, dentro de su funcionalidad, ejecute el
proceso de facturación electrónica, mediante un sistema
web reduciendo radicalmente el uso de papel.
B. Delimitación Temporal
El desarrollo de la presente tesis, ha tenido un horizonte
temporal comprendido entre octubre de 2011 y noviembre
del 2011.
1. La primera etapa: Desarrollando en el periodo octubre-
noviembre de 2011, comprende la construcción de la
herramienta informática a nivel de prototipo, el análisis e
interpretación de resultados, la contrastación de hipótesis,
las conclusiones, la recomendaciones.
C. Delimitación Social
De acuerdo a la naturaleza de las variables que
intervienen en el tema desarrollado, los siguientes roles
sociales son involucrados
Gerente.
Ventas.
Contabilidad
D. Delimitación Conceptual
A continuación se presentan los principales descriptores
temáticos usados para delimitar el aspecto conceptual
sobre el cual se apoya este trabajo de investigación.
para poder comprender de que trata la gestion paperless
en facturacion electronica, hablar de paperless significa el
ahorro de papel en la emision de comprobantes de pago
a los clientes, con finalidad de ahorar tiempo y dinero en
la emision e impresion.
…………………………
1.2.2. - Definición del Problema……………………………………......
Formulación del Problema………………………………………………......
Objetivos de la Investigación:
1.4.1 - Objetivo General………………………………………………..
1.4.2 - Objetivos Específicos…………………………………………..
Hipótesis de la Investigación………………………………………………...
1.3 Objetivos de la Investigación
1.1.Objetivos Generales
Investigar y conocer las tecnologías de información involucradas en el modelo de
facturación electrónica en Perú según las normativas de la SUNAT.
Construir un conjunto de librerías de clases reutilizables que permitan la
generación de documentos tributarios electrónicos.
1.2.Objetivos Específicos
Estudiar los procesos de negocio del modelo de facturación electrónica en Perú.
Estudiar y conocer los conceptos, objetivos y aplicaciones de la firma electrónica
con certificado digital.
Estudiar y conocer las especificaciones del estándar XML y las especificaciones
de firma electrónica sobre documentos XML (XMLDSIG), según la W3C (World
Wide Web Consortium).
Conocer sobre la tecnología Web Services y su participación en el modelo de
facturación electrónica.
Construir un prototipo de aplicación que muestre la generación de la factura
electrónica utilizando las librerías de clases desarrolladas.
1.4 Hipótesis de la Investigación
1.5 Alcances
Para dar cumplimiento a los objetivos planteados anteriormente se llevarán a cabo un
conjunto de actividades y tareas las cuales estarán delimitadas por los siguientes
alcances:
Definir los conceptos y elementos teóricos del modelo de facturación electrónica.
Definir los conceptos generales de la firma digital y su aplicación en el modelo de
facturación electrónica en Chile.
Definir los conceptos del estándar XML y la especificación XMLDSIG de la W3C
para la firma digital de documentos XML.
Definir los conceptos del código de barras bidimensional (PDF417).
Construir un conjunto de librerías de clases que permitan la generación en
formato XML y el firmado de documentos tributarios electrónicos.
Construir un prototipo de aplicación que permita la generación de la factura
electrónica.
CAPITULO 2
FUNDAMENTOS TEORICOS
2 CAPITULO 2: FUNDAMENTOS TEORICOS
2.1 Modelo de facturación tradicional versus electrónico.
2.1.1 Situación actual de la facturación en Chile.
Actualmente el Servicio de Impuestos Internos (SII) exige a los contribuyentes que sus
documentos tributarios en papel, sean registrados y autorizados antes de utilizarlos,
esta autorización del SII se lleva a cabo a través de un timbre de cuño que el
contribuyente está obligado a aplicar sobre sus documentos en papel antes de hacer
uso de los mismos, para lo cual está obligado a concurrir periódicamente a la Unidad
del SII que le corresponde, llevando los documentos preimpresos y foliados para que
estos sean timbrados.
El procedimiento actual para registrar y timbrar documentos tributarios acarrea costos
considerables tanto para las empresas como para el SII, especialmente para aquellas
que requieren timbrar grandes volúmenes de documentos. Por otra parte el utilizar
formularios foliados y timbrados dificulta el procesamiento masivo, ya que se debe
respetar los folios. Además se exige la utilización de impresión por impacto,
desechando tecnologías de impresión más avanzadas como láser e inyección de tinta.
Respecto al almacenamiento de documentos tributarios, el contribuyente está obligado
a guardar el documento en papel por un período de 6 años, durante el cual estará
sujeto a cualquier inspección por parte del SII, esta obligación demanda para grandes
volúmenes de documentos, elevados costos en administración y bodegaje.
Figura 2.1: Modelo tradicional de facturación.
2.1.2 Facturación electrónica en Chile.
En el modelo de facturación electrónica los contribuyentes deberán estar enrolados en
el Servicio de Impuestos Internos (SII) como emisores de documentos tributarios
electrónicos, lo cual no los obligará a emitir todos sus documentos en forma electrónica
pero si a recibir documentos electrónicos de otros emisores.
Los contribuyentes enrolados podrán solicitar la autorización de sus folios a través del
sitio Web del SII con los que podrán emitir sus documentos tributarios electrónicos, los
cuales deberán almacenar solamente en formato electrónico eximiéndose de la
obligación de conservarlos en papel para posibles inspecciones del SII.
Los documentos tributarios electrónicos emitidos deberán ser enviados al SII a través
de Internet y al receptor ya sea manual o electrónico, utilizando el medio que
corresponda, si el receptor es manual se le deberá enviar la representación en papel
del documento.
Un documento tributario electrónico se considerará válido si este es generado según las
especificaciones del SII, este debe contener una firma digital para garantizar la
integridad del documento y la autenticidad del emisor y el firmante. Adicionalmente la
representación impresa del documento deberá contener un timbre electrónico el que se
imprimirá en un código de barras bidimensional y se obtendrá a través de un
mecanismo de seguridad especificado por el SII, este timbre permitirá verificar en
cualquier momento la validez de un documento tributario electrónico impreso.
Figura 2.2: Modelo electrónico de facturación.
En la tabla 2.1 podemos apreciar un comparativo de cómo se llevan a cabo las
funciones involucradas en el proceso de facturación en cada uno de los modelos.
Función Modelo tradicional de facturación
Modelo electrónico de facturación
Foliación de documentos
Preimpreso en los documentos
Autorizado a través del sitio Web del SII
Timbrado de documentos
En oficinas del Servicio de Impuestos Internos
Por el contribuyente
Timbre De cuño ElectrónicoAlmacenamiento Papel por un período de Electrónico
6 años para el contribuyente
Verificación de validez Sólo de autorización en el sitio Web del SII
Autorización, Recepción y Validez en el sitio Web del SII.
Impresión del documento
Papel autocopiativo, formulario continuo, prefoliado, impresora de impacto.
Papel normal ni autocopiativo ni continuo y con impresora láser o de inyección de tinta.
Tabla 2.1: Funciones en el modelo tradicional y electrónico de facturación.
2.2 Aspectos legales de la facturación electrónica en Chile.
Con el objetivo de otorgar validez legal al modelo de facturación electrónica en Chile se
han dictado normativas y resoluciones que establecen los procedimientos y
especificaciones a seguir por todos los contribuyentes que participen en esta iniciativa.
La normativa principal está compuesta por las siguientes resoluciones:
Resolución Exenta SII N°45 del 01 de Septiembre del 2003
Establece normas y procedimientos de operación respecto de los documentos
Tributarios Electrónicos.
Fuente: Subdirección de Fiscalización
Resolución Exenta N°18 del 22 de Abril del 2003
Establece que los contribuyentes que sean autorizados para emitir documentos
tributarios electrónicos, deberán otorgarlos impresos en soporte papel a los
receptores no electrónicos y a los receptores electrónicos en los casos que
indica.
Fuente: Subdirección de Fiscalización
Resolución Exenta N°11 del 14 de Febrero del 2003
Establece Procedimiento para que Contribuyentes Autorizados para Emitir
Documentos Electrónicos que Indica Pueda También Enviarlos por estos Medios
a “Receptores Manuales”.
Fuente: Subdirección de Fiscalización
2.3 Facturación electrónica y firma digital.
2.3.1 Objetivo de la firma digital.
Las emergentes tecnologías de información impulsan cada vez más a las empresas a
utilizar Internet como un medio para integrar sus negocios con otras empresas en
transacciones B2B, e incluso para intercambiar con sus clientes a través de
transacciones B2C. Estas transacciones involucran intercambio de datos muy sensibles
para las compañías, por lo cual se requieren de avanzadas tecnologías de seguridad
que permitan garantizar la confidencialidad de estas transacciones, de tal modo que los
datos que se intercambian no puedan ser interceptados por terceros no autorizados
para utilizarlos de forma inadecuada.
Pero la confidencialidad no es el único elemento importante cuando estamos
intercambiando mensajes de negocio, también es necesario asegurar la autenticidad
“¿quién envío el mensaje?”, la integridad “¿habrá sido modificado el mensaje en su
trayecto?”, y también crear un soporte para el no repudio “¿podrá el emisor negar haber
enviado un mensaje?”.
Estos son los objetivos de la firma digital, en otras palabras, proveer a los mensajes
electrónicos de un mecanismo análogo a la firma tradicional en el mundo del papel.
2.3.2 Encriptación con clave pública.
Encriptación:
La encriptación es una transformación matemática de los datos, a través de un
algoritmo específico y por medio de la utilización de una clave, de forma tal que los
datos puedan ser transformados a su estado original, solamente utilizando una clave
para tal propósito. La encriptación garantiza la confidencialidad en el intercambio de
mensajes electrónicos.
Figura 2.3: Ilustración del proceso de encriptación.
Encriptación Asimétrica:
La encriptación asimétrica o también conocida como encriptación con clave pública,
permite a los usuarios de una red insegura como Internet intercambiar datos
confidenciales que no pueden ser modificados ni accedidos por entidades no
autorizadas. Este proceso se realiza a través de una transformación matemática de los
datos de acuerdo a un algoritmo y un par de números, conocidos como llaves pública y
privada.
Cada participante en el intercambio tiene su par de llaves, la llave pública se entrega
libremente a todas las personas a las cuales se desea enviar mensajes, mientras que la
llave privada se conserva de forma segura y se protege. A pesar de que el par de llaves
están relacionadas matemáticamente, es computacionalmente imposible derivar la llave
privada a partir de la llave pública.
La relación entre la llave pública y privada está dada por el hecho de que un mensaje
cifrado con una llave solo puede ser descifrado con la otra.
Figura 2.4: Encriptación Asimétrica.
Si un mensaje es cifrado con la llave privada, solo aquellas personas que tengan
acceso a la llave pública correspondiente a esa llave privada podrán descifrar el
mensaje. Por otra parte si un mensaje es cifrado con la llave pública, solo el propietario
de la llave privada podrá descifrar el mensaje.
Hashing:
Consiste en obtener a partir de un mensaje y aplicando una transformación o algoritmo
matemático, un mensaje mucho más pequeño pero cuyo contenido representa de forma
única al mensaje original, esta representación que se obtiene se denomina hash o
digesto. Si un bit del mensaje original es modificado y la transformación es aplicada
nuevamente se obtiene un nuevo hash diferente al anterior.
Algunos algoritmos de hashing conocidos son el MD5, SHA1.
Figura 2.5: Hashing.
2.3.3 Certificado digital.
Como se manifestó en la sección anterior la encriptación con clave pública permite
lograr confidencialidad, autenticidad, integridad y no repudio, pero ahora surge otra
problemática y es una de las más críticas en torno a la criptografía, la administración de
las claves, ¿quién certifica y distribuye las claves?, ¿quién establece el período de
validez de las claves existentes?
Para suplir los problemas planteados por estas interrogantes es que surgen las
entidades certificadoras (CA), el objetivo principal de una entidad certificadora es validar
y certificar que una clave pertenece realmente a un ente determinado.
Por otra parte las entidades certificadoras necesitaban de un formato electrónico que
pudiera contener las claves públicas y privadas, así como información que identificara al
propietario de las claves, es así que surgen los certificados digitales.
Los certificados son documentos electrónicos generados y distribuidos por las
Entidades de Certificación, que contienen la identidad del propietario, su
correspondiente clave pública y el período de validez. Los certificados digitales
contienen la firma electrónica de la entidad certificadora, lo cual garantiza la validez y
autenticidad de los mismos.
Figura 2.6: Representación de un certificado digital.
2.3.4 Aplicación de la firma digital en la factura electrónica.
En el modelo de facturación electrónica la firma digital se aplica en varias instancias las
cuales se listan y explican a continuación.
Enrolamiento e intercambio con el SII:
Toda empresa emisora de documentos tributarios electrónicos tendrá que interactuar
con el SII a través de su sitio Web, para esto el representante legal de la empresa y
todas las personas autorizadas para realizar operaciones con los DTE, deberán adquirir
certificados digitales ya que la autentificación y el enrolamiento en el sitio Web del SII
es a través de certificados digitales.
Código de Autorización de Folios (CAF):
El código de autorización de folios es un documento en formato XML que entrega el
Servicio de Impuestos Internos a los contribuyentes, este contiene el tipo de documento
y el rango de folios que el SII está autorizando al contribuyente para que pueda emitir
documentos tributarios electrónicos, además el CAF contiene la llave privada que
deberá utilizar el contribuyente para firmar el timbre electrónico de los DTE que se
emitirán dentro de ese rango.
Figura 2.7: Estructura del Código de Autorización de Folios.
En la sección <TD> se especifica el tipo de documento tributario “33” (Factura
Electrónica), en la sección <RNG> se indica el rango de folios que se está autorizando
para ese tipo de documento, desde el 50 hasta el 101, en la sección <FRMA> aparece
el valor de la firma digital que realizó el SII sobre todo el documento XML que
representa el CAF, cuando un contribuyente recibe el CAF puede verificar la integridad
y autenticidad del mismo utilizando la clave pública cuyo valor se obtiene de la sección
<RSAPK> y verificando la firma digital contenida en <FRMA>.
Por otra parte en la sección <RSASK> se encuentra la clave privada que utilizará el
contribuyente para firmar el timbre electrónico que deberá estar presente tanto en la
representación electrónica como impresa del documento tributario.
Timbre Electrónico:
El timbre electrónico es un elemento que deberá contener cada documento tributario
electrónico y permitirá verificar en cualquier instante la autenticidad del DTE. El timbre
deberá contener varios atributos del DTE tales como: RUT del emisor y receptor, monto
total, fecha y folio y además el CAF que autoriza la emisión de ese DTE. El timbre
deberá ser firmado digitalmente con la clave privada que entregó el SII en el CAF que
autoriza la emisión de ese DTE.
Figura 2.8: Estructura del Timbre Electrónico.
Como se puede apreciar en la sección <FRMT> debe colocarse el valor de la firma
digital sobre todo el elemento <TED></TED>, o sea sobre todo el timbre, la firma digital
es calculada utilizando la clave privada entregada por el SII en el CAF que autoriza la
emisión del DTE en cuestión.
La Figura 2.8 muestra la representación en formato XML del timbre electrónico, en la
representación impresa del documento tributario, el timbre electrónico deberá
imprimirse en forma de código de barras bidimensional (PDF417), esto permite que en
cualquier momento se pueda verificar la autenticidad de un documento leyendo la
información contenida en el código de barras. En la Figura 2.9 se muestra un ejemplo
de un código de barras bidimensional en formato PDF417.
Figura 2.9: Código de barras bidimensional (PDF417).
Documento Tributario Electrónico:
Por otra parte el documento tributario electrónico también es representado en formato
XML, este documento deberá ser firmado digitalmente utilizando la clave privada
contenida en uno de los certificados adquiridos para tales propósitos por la empresa
emisora. Esta firma digital sobre el DTE permitirá que tanto el SII como cualquier
receptor electrónico puedan verificar la autenticidad e integridad del documento
electrónico.
Figura 2.10: Estructura resumida de un DTE.
El elemento <Signature> contiene el valor de la firma digital calculada sobre el elemento
<Documento>.
En la Figura 2.11 se muestra un resumen de todos los elementos del documento
tributario electrónico en los cuales está involucrada la firma digital.
Figura 2.11: Elementos de un DTE que involucran la firma digital.
2.4 El estándar XML y su aplicación en la factura electrónica.
2.4.1 ¿Qué es XML y cuáles son sus beneficios?
Mientras el estándar HTML (Hypertext Markup Language) no es extensible, el estándar
que dio origen a este, SGML (Standard Generalized Markup Language) es
completamente extensible. Para crear conjuntos de documentos personalizados en
SGML, los autores desarrollaban los DTD los cuales permitían controlar y especificar la
forma de todos los documentos en ese conjunto, esta tarea requería de mucho tiempo y
además resultaba ser compleja, pero sin embargo funcionaba. Entonces surge la
interrogante de cómo capturar la extensibilidad de SGML minimizando su complejidad,
en otras palabras, era resolver un abismo que existía entre SGML y HTML.
La respuesta es XML (Extensible Markup Language), este estándar permite reutilizar la
mayoría de las ventajas y funcionalidades del SGML evitando la complejidad del
lenguaje, habilitando a los desarrolladores Web para producir documentos
personalizados con un alto grado de consistencia. Mientras HTML es simplemente un
tipo de documento SGML, XML es una versión simplificada de SGML.
Actualmente XML es un estándar cuya especificación está establecida por la W3C
(World Wide Web Consortium), este estándar fue diseñado para describir los datos,
utilizando para ello los DTD (Document Type Definition) o esquemas XML.
La diferencia entre XML y HTML es que fueron diseñados con propósitos diferentes,
XML fue diseñado para describir los datos y se enfoca en qué son los datos en si,
mientras que HTML fue diseñado para mostrar los datos y se enfoca en como los datos
se ven. HTML permite mostrar la información mientras que XML permite describir la
información. Los elementos antes mencionados nos dan una clara idea de XML no es
un reemplazo de HTML sino un complemento de este.
Beneficios del lenguaje XML:
Simplicidad.
Estándar de libre uso.
Extensibilidad.
Se describe a si mismo.
Separa el contenido de la presentación.
Soporta documentos en múltiples lenguajes.
Facilita la comparación y agregación de datos.
Puede contener diversos tipos de datos.
Puede contener los datos existentes actualmente.
Rápida adopción por la industria tecnológica.
A continuación se muestra un ejemplo de un documento XML:
<?xml version="1.0" encoding="ISO-8859-1" ?> <CATALOG>
<CD> <TITLE>Empire Burlesque</TITLE>
<ARTIST>Bob Dylan</ARTIST> <COUNTRY>USA</COUNTRY> <COMPANY>Columbia</COMPANY> <PRICE>10.90</PRICE> <YEAR>1985</YEAR>
</CD><CD>
<TITLE>Hide your heart</TITLE> <ARTIST>Bonnie Tyler</ARTIST> <COUNTRY>UK</COUNTRY> <COMPANY>CBS Records</COMPANY> <PRICE>9.90</PRICE> <YEAR>1988</YEAR>
</CD></CATALOG>
2.4.2 Aplicación de XML en la factura electrónica.
El estándar XML fue seleccionado por el Servicio de Impuestos Internos como el
formato en el cual se representarán e intercambiarán electrónicamente los documentos
tributarios electrónicos.
En el sitio Web del Servicio de Impuestos Internos podemos encontrar el esquema XML
que establece la estructura que deben tener los documentos tributarios electrónicos
representados en lenguaje XML.
2.4.3 World Wide Web Consortium (W3C).
La W3C es una organización internacional encargada de desarrollar y promover
tecnologías y estándares que permitan la interoperabilidad. Especificaciones, guías,
software y herramientas son algunos de los elementos desarrollados por esta
organización que han permitido desarrollar todo el potencial del Web. Es un forum de
información, comercio y comunicación.
Algunos estándares promovidos por la W3C son: Hyper Text Markup Language
(HTML), Extensible Markup Language (XML), Cascading Style Sheets (CSS), Scalable
Vector Graphics (SVG), entre muchos otros.
Para la facturación electrónica en Chile, el Servicio de Impuestos Internos utilizó varios
estándares establecidos por la W3C, primeramente XML, como el lenguaje que se
utilizará para representar los documentos tributarios electrónicos y que fue visto
anteriormente, luego XMLDSIG, que son las especificaciones para firmar digitalmente
documentos XML y que abordará en la próxima sección.
2.4.4 Firma digital de documentos XML (XMLDSIG).
Si bien el concepto de firma digital es genérico y aplica sobre cualquier transacción
electrónica, por el auge que ha adquirido el estándar XML, la W3C desarrolló una
especificación que establece como deben ser firmados los documentos XML, esto
permitirá sacar provecho de los beneficios de XML y además la interoperabilidad entre
todas las tecnologías que sigan la especificación, lo que se traduce en que un receptor
de un documento XML pueda verificar la firma digital realizada por el emisor de dicho
documento sin necesidad del establecimiento de algún acuerdo previo.
La especificación conocida bajo la sigla XMLDSIG, establece el esquema de una firma
digital sobre un documento XML.
Una de las características fundamentales del XMLDSIG es la habilidad de poder firmar
solo partes específicas del documento XML y no este completo, esto es relevante si
tenemos en cuenta que un documento XML puede tener una larga historia, en la cual
diferentes partes o elementos han sido incorporados en distintos espacios de tiempos y
por entidades diferentes. Esto también es relevante cuando en algunas ocasiones
solamente se necesita resguardar la integridad de algunas partes del documento XML,
dejando la posibilidad de que las demás puedan ser modificadas.
En la siguiente figura se muestran los elementos de una firma digital XML.
Figura 2.12: Esquema de una firma digital XML.
Pasos para calcular una firma digital XML:
1. Determinar los recursos o elementos que serán firmados.
2. Calcular el digesto o hashing de cada recurso o elemento.
3. Crear todos los elementos referencias con su respectivo valor del digesto dentro
de un elemento <SignedInfo>
4. Calcular el digesto del elemento <SignedInfo>, cifrarlo y colocarlo dentro del
elemento <SignatureValue>
5. Agregar la información de la llave a utilizar para verificar la firma dentro del
elemento <KeyInfo>.
6. Colocar los elementos <SignedInfo>, <SignatureValue> y <KeyInfo> dentro del
elemento <Signature>.
Pasos para verificar una firma digital XML:
1. Verificar la firma del elemento <SignedInfo>, para esto hay que recalcular el
digesto del elemento <SignedInfo>, descifrar el elemento <SignatureValue>
utilizando la llave pública especificada en <KeyInfo> y comparar ambos valores.
2. Si el paso 1 es correcto, para cada una de las referencias recalcular el digesto y
compararlo con el valor del digesto <DigestValue> especificado dentro de cada
elemento referencia <Reference>.
Para más información consultar en el sitio Web de la W3C: http://www.w3.org/Signature/
2.4.5 Aplicación de XMLDSIG en factura electrónica.
Como mencionamos anteriormente el Servicio de Impuestos Internos ha establecido el
uso del XMLDSIG como estándar para el firmado digital de documentos tributarios
electrónicos.
Si observamos la Figura 2.10 presentada en la sección 2.3.4, donde se muestra cuál es
el esquema o estructura de un documento tributario electrónico, podemos ver que
existe un elemento <Signature> el cual contendrá la firma digital sobre el elemento o
recurso <Documento>, según lo explicado en la sección 2.4.4 y según el esquema
expuesto en la Figura 2.12.
2.4.6 Tecnología XML Web Services y sus beneficios.
Un XML Web Service o Servicio Web XML es una entidad programable que provee
funcionalidades específicas y es accesible a un sinnúmero de sistemas o aplicaciones
utilizando estándares de Internet tales como el XML y HTTP.
Los Servicios Web XML dependen completamente de XML y otros estándares de
Internet para crear una infraestructura que soporte la interoperabilidad entre
aplicaciones a tal punto, que resuelve muchos de los problemas que históricamente se
habían presentado en este ámbito.
Un Servicio Web XML puede ser utilizado internamente por una aplicación o expuesto
externamente a través de Internet, para usar desde cualquier aplicación. Producto a
que este es accedido a través de una interfaz estándar, un Servicio Web XML permite
que sistemas heterogéneos trabajen en conjunto como una unidad simple con
funcionalidades extendidas a través del Web.
Esta tecnología provee una solución viable para habilitar la interoperabilidad de los
datos y de los sistemas ya que utiliza mensajería basada en el estándar XML, lo cual
ayuda a eliminar las diferencias existente entre sistemas que utilizan modelos de
componentes, sistemas operativos y lenguajes incongruentes.
Una de las principales características de un Servicio Web XML es el alto grado de
abstracción que existe entre la implementación y la utilización o consumo del servicio.
Utilizando el estándar XML como mecanismo de mensajería a través del cual el servicio
es creado y accedido, permite que tanto el proveedor del servicio como el cliente o
consumidor del mismo, no necesiten conocer nada uno del otro más allá que los
parámetros de entrada, la salida y donde se encuentra publicado el servicio.
La tecnología de Servicios Web XML impone una nueva era del desarrollo de
aplicaciones distribuidas, constituye uno de los próximos pasos revolucionarios de
Internet y se convertirán en la estructura fundamental para unir todos los dispositivos de
computadores.
2.4.7 Aplicación de la tecnología XML Web Services en factura electrónica.
Una de las principales ventajas que nos brinda la facturación electrónica es la rapidez
con la cual se podrán intercambiar los documentos tributarios, el comprador podrá
recibir más rápido la factura, el proveedor podrá enviar sus documentos tributarios
mucho más rápido al Servicio de Impuestos Internos. Pero para que esto sea posible se
necesita una infraestructura que permita la integración de sistemas heterogéneos, y es
aquí donde intervienen los Servicios Web XML.
En la facturación electrónica los Servicios Web XML intervienen en varias instancias,
primeramente el Servicio de Impuestos Internos a puesto a disposición de los
contribuyentes varios Servicios Web que permitirán realizar determinadas operaciones,
tales como: Autentificación automática al SII, Consulta de estado de un envío de
documentos tributarios y Consulta de estado de un documento tributario. Por otra parte
los proveedores podrán exponer sus propios Servicios Web para que los compradores
descarguen sus facturas, o los compradores podrán exponer sus Servicios Web para
que los proveedores envíen sus facturas.
Figura 2.13: Participación de XML Web Services en la factura electrónica.
CAPITULO 3
METODOLOGIA
3 CAPITULO 3: METODOLOGIA
3.1 Descripción de la metodología.
Rational Unified Process (RUP), es una metodología que expresa el proceso de
ingeniería de software organizado en disciplinas y como un flujo de trabajo. Plantea la
existencia de roles los cuales son responsables de artefactos que se obtienen a partir
de la ejecución de actividades y que pueden servir como elementos para llevar a cabo
otras actividades, todo este proceso apoyado por herramientas.
RUP tiene dos dimensiones, por una parte tenemos las fases las cuales determinan el
avance del proyecto en el tiempo y estas son cuatro: Inicio, Elaboración, Construcción y
Transición. En la otra dimensión tenemos las disciplinas: Modelamiento del Negocio,
Requerimientos, Análisis y Diseño, Implementación, Pruebas, Distribución,
Configuración y Administración de Cambios, Administración de Proyecto y Ambiente.
Las disciplinas permiten agrupar lógicamente todas las actividades que deben ser
llevadas a cabo durante la ejecución del proyecto.
En cada una de las fases tenemos iteraciones, estas pueden ser varias en una misma
fase y pueden involucrar algunas o todas las disciplinas, en dependencia de la fase y la
iteración en la que nos encontremos se requerirá más o menos esfuerzo en una u otra
disciplina.
En la siguiente figura se muestra la interacción de los elementos antes mencionados,
las curvas de colores indican una idea aproximada del esfuerzo que requiere una
disciplina en una fase determinada.
Figura 3.14: Rational Unified Process (RUP).
3.2 Aplicación de la metodología.
La aplicación de RUP en nuestro proyecto nos permite controlar, administrar y
desarrollar el mismo.
Para llevar a cabo el control nos apoyamos en las fases ya que estas marcan el avance
del proyecto en el tiempo, tienen objetivos bien definidos y existen criterios que nos
permiten determinar cuando pasar de una fase a otra.
Las disciplinas establecen como llevar a cabo el desarrollo del proyecto, estas son una
agrupación lógica de todas las actividades a desarrollar, se encuentran definidos los
roles que ejecutan cada actividad y cuales son los artefactos que deberán utilizarse y
cuales obtenerse como resultado.
La administración la realizamos siguiendo una de las disciplinas que es la
Administración de Proyecto, en esta disciplina están definidas actividades y artefactos
relacionados con la administración, Planes de Proyectos, Planes de Iteraciones, Lista
de Riesgos, Planes de Prueba, Planes de Distribución, entre otros.
Figura 3.15: Aplicación de RUP en el proyecto.
Los criterios a seguir para pasar de una fase a la otra, así como los principales
artefactos a obtener serán expuestos a continuación:
Fase de Inicio
Esta fase es importante principalmente para los primeros esfuerzos de desarrollo, en la
cual es significativo identificar los riesgos del proyecto, también se debe determinar si el
proyecto se justifica y .si es factible llevarlo a cabo.
Objetivos
Establecer el ámbito y las condiciones de límites del proyecto, que estará
incluido y que no en el producto final.
Determinar el costo total del esfuerzo, los recursos y el tiempo para llevar a cabo
todo el proyecto.
Determinar los riesgos potenciales del proyecto, clasificarlos y como
administrarlos y contenerlos.
Criterios de Evaluación
Los requerimientos han sido capturados, son correctos y existe un entendimiento
de los mismos.
Todos los requerimientos están dentro del ámbito del proyecto, están costeados
y planificados dentro del tiempo total de desarrollo del proyecto.
Las estimaciones de costo/tiempo, prioridades y riesgos son apropiadas.
Todos los riesgos han sido identificados y existen planes de contención para
cada uno de ellos.
Artefactos
Artefacto Disciplina Criterio de AceptaciónVisión Requerimientos Los requerimientos esenciales,
principales características y restricciones están documentados.
Lista de Riesgos Administración del Proyecto
Los riesgos iniciales del proyecto están identificados.
Plan de Iteración Administración del Proyecto
Plan de iteración para la primera iteración de la fase de Elaboración completo y revisado.
Infraestructura de Desarrollo
Ambiente Todas las herramientas que soportan el proyecto están seleccionadas, las que se necesitan para trabajar en la fase de inicio están instaladas.
Glosario Requerimientos Términos importantes están definidos y revisados.
Modelo de Casos de Uso
Requerimientos Actores y Casos de Usos más importantes se encuentran identificados.
Tabla 3.2: Artefactos a obtener en la fase de Inicio.
Fase de Elaboración
El propósito de esta fase es definir los elementos fundamentales de la arquitectura del
sistema para proveer una base estable para los esfuerzos de diseño e implementación
posteriormente en la fase de construcción. Esta arquitectura debe ser desarrollada
considerando los requerimientos más significativos (aquellos que tienen un gran
impacto en la arquitectura del sistema) y un análisis de riesgos.
Objetivos
Asegurar que la arquitectura, los requerimientos, y la planificación son lo
suficientemente estables y que los riesgos están identificados y mitigados para
permitir estimar el costo del esfuerzo y el tiempo para completar el desarrollo.
Identificar todos los riesgos significativos involucrados en la arquitectura.
Demostrar que la arquitectura base definida soportará los requerimientos a un
costo razonable y según los tiempos requeridos.
Criterios de Evaluación
La visión del producto y los requerimientos son estables.
Los planes de iteración para la fase de construcción están lo suficientemente
detallados para permitir realizar el trabajo.
Los planes de iteración para la fase de construcción están soportados por
estimaciones realistas.
Artefactos
Artefacto Disciplina Criterio de AceptaciónLista de Riesgos Administración del
ProyectoActualizados y revisados.
Documento de Arquitectura de Software
Análisis y Diseño Creado y delineado, incluyendo descripción detallada para los casos de usos arquitecturalmente significativos (vista de casos de uso), identificación de los principales mecanismos y elementos de diseño (vista lógica), más la definición de la vista de
procesos y la vista de distribución. Modelo de Diseño (incluyendo artefactos constituyentes)
Análisis y Diseño Definido y delineado, la realización de los casos de uso para los escenarios significativos arquitecturalmente han sido definidas y el comportamiento requerido ha sido asociado con sus elementos de diseño correspondiente. Los componentes han sido identificados y las decisiones de construcción/compra/reutilización están claras para estimar el costo de la fase de construcción y una planificación adecuada.
Modelo de Implementación (incluyendo artefactos constituyentes)
Implementación La estructura inicial ha sido creada y la mayoría de los componentes prototipados.
Plan de Iteración Administración del Proyecto
Plan de iteración para la fase de Construcción completo y revisado.
Modelo de Casos de Uso
Requerimientos Completado aproximadamente en un 80%, todos los casos de uso y actores han sido identificados y las descripciones de la mayoría de los casos de usos desarrolladas.
Tabla 3.3: Artefactos a obtener en la fase de Elaboración.
Fase de Construcción
El propósito de esta fase es clarificar los requerimientos restantes y completar el
desarrollo del sistema basado en la arquitectura definida, esta fase se puede decir que
es en cierto sentido el proceso de manufactura.
Objetivos
Completar el análisis, diseño, desarrollo y pruebas de todas las funcionalidades
requeridas.
Criterios de Evaluación
La versión del producto obtenida es lo suficientemente estable y madura para
ser distribuida a la comunidad de usuarios.
Artefactos
Artefacto Disciplina Criterio de Aceptación“El sistema” - La versión beta del producto, listo para
probar.Material de Soporte para Usuarios Finales
Distribución Manuales de usuario y otros materiales de entrenamiento deberán estar en borrador basado en los casos de uso.
Plan de Iteración Administración del Proyecto
Plan de iteración para la fase de Transición completo y revisado.
Tabla 3.4: Artefactos a obtener en la fase de Construcción.
Fase de Transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios
finales. La fase de Transición puede llevarse a cabo con varias iteraciones e incluye
pruebas del producto para su liberación final.
Objetivos
Ingeniería específica de la distribución, tales como: empaquetado comercial y
producción.
Realizar tareas de afinamiento, tales como: corrección problemas, mejora de
rendimiento y utilización.
Evaluar el producto obtenido contra la visión completa y los criterios de
aceptación del producto.
Criterios de Evaluación
El usuario debe estar satisfecho.
Los gastos en recursos versus lo planeado deben ser aceptables.
Artefactos
Artefacto Disciplina Criterio de AceptaciónEl producto Distribución Debe estar completo de acuerdo a los
requerimientos. El producto final debe ser utilizable por los usuarios finales.
Material de Soporte para Usuarios Finales
Distribución Materiales que asistan al usuario final en el aprendizaje, operación y mantenimiento del producto deben estar completos de acuerdo a los requerimientos.
Tabla 3.5: Artefactos a obtener en la fase de Transición.
CAPITULO 4
RESULTADOS Y DISCUSION
4 CAPITULO 4: RESULTADOS Y DISCUSION
4.1 Evaluación del proyecto.
Para evaluar técnicamente el proyecto se establecieron un conjunto de criterios
ponderados, varias alternativas de solución y calificamos cada una de ellas según los
criterios para obtener la mejor alternativa.
En cuanto a la evaluación económica realizamos de forma general un análisis de costos
y beneficios, un cálculo estimado del costo del desarrollo, un flujo de caja para
determinar la rentabilidad del proyecto para el inversionista y finalmente un flujo de
ahorro de costos para demostrar la rentabilidad desde el punto de vista de la empresa.
4.1.1 Evaluación técnica.
Por las características de este proyecto, específicamente que uno de los objetivos es la
construcción de un conjunto de librerías de clases, la evaluación técnica se orientó en el
sentido de encontrar una plataforma y un lenguaje de desarrollo para llevar a cabo la
construcción de estas librerías. De aquí que se consideraron 4 plataformas con sus
lenguajes como alternativas de solución.
Criterios de evaluación:
Los criterios considerados para evaluar las alternativas fueron los siguientes:
1. No existencia de un producto similar en el mercado basado en la plataforma y el
lenguaje.
Es muy importante el hecho de que el producto sea único en la plataforma y
lenguaje seleccionado, esto nos brinda ventajas competitivas y mayor facilidad
para la comercialización.
2. Masificación de la plataforma en las empresas chilenas.
Como el producto que se entregará tendrá que ser utilizado por los equipos de
desarrollo de las empresas para integrarlos con sus programas de facturación o
incluso construir uno nuevo, es de vital importancia que la plataforma que se
seleccione este masificada en el mercado chileno, esto será un factor
determinante en la aceptación del producto por parte del mercado.
3. Plataforma y lenguaje orientados a objetos y manejo nativo de XML y Web
Services.
Por los estándares definidos por el SII para el modelo de facturación electrónica,
se hace indispensable que la plataforma y el lenguaje seleccionado manejen los
elementos antes mencionados.
4. Experiencia del equipo de desarrollo en la plataforma y el lenguaje.
Si bien no es un factor crítico de éxito, permitirá reducir los costos de desarrollo y
obtener el producto más rápidamente, lo cual si puede ser fundamental para
causar un impacto positivo en el mercado.
5. Manejo de criptografía, certificados digitales, firma digital e implementación del
estándar XMLDSIG de la W3C.
Este caso es igual que el número 3, el SII definió ciertos estándares para el
modelo de facturación electrónica, entre ellos, el firmado digital de los DTE, para
lo cual estableció que se utilizaría el estándar XMLDSIG de la W3C. De aquí que
es indispensable que la plataforma seleccionada implemente este estándar y
aparezca en la lista de soluciones certificadas en la implementación de este
estándar en la W3C.
6. Existencias de librerías para la plataforma y lenguaje que permitan la generación
de códigos de barras bidimensionales en formato PDF417.
Para garantizar la autenticidad de los DTE y la posibilidad de fiscalización por
parte del SII, se incluyó en la versión impresa de los DTE un código de barras
bidimensional (PDF417) que contiene información del DTE y permite a
cualquiera que lea este código, verificar la validez del documento.
7. Posibilidades de soporte para la plataforma y lenguaje a través de foros de
discusión o bibliografía en Internet.
Este no es un factor crítico de éxito, pero dado que el proyecto involucra
tecnologías muy novedosas, sería beneficioso el contar con foros de discusión
por Internet o algún otro tipo de soporte al cual recurrir en caso de algún
problema durante el desarrollo del proyecto.
8. Existencia de herramientas CASE para RUP y la plataforma y lenguaje que
permitan realizar ingeniería a partir del desarrollo.
El no cumplimiento de este criterio no impide la realización del proyecto, pero si
pudiera reportar beneficios, principalmente en cuanto a reducción de los tiempos
de desarrollo y por ende costos, ya que pudiéramos a partir de los diseños
realizados utilizando la metodología RUP, generar bloques de código en forma
automática.
Para ponderar los criterios se utilizaron los siguientes valores:
Ponderación Nivel de Importancia3 Alta2 Media1 Baja
Tabla 4.6: Valores de ponderación para asignar a los criterios.
Teniendo en cuenta el grado de importancia de cada criterio para cumplir con los
objetivos se asignó la siguiente ponderación a cada uno de ellos:
Nº Criterio de Evaluación Ponderación1 No existencia de un producto similar en el mercado basado
en la plataforma y el lenguaje.3
2 Masificación de la plataforma en las empresas chilenas. 33 Plataforma y lenguaje orientados a objetos y manejo nativo
de XML y Web Services.3
4 Experiencia del equipo de desarrollo en la plataforma y el lenguaje.
2
5 Manejo de criptografía, certificados digitales, firma digital e implementación del estándar XMLDSIG de la W3C.
3
6 Existencias de librerías para la plataforma y lenguaje que permitan la generación de códigos de barras bidimensionales
3
en formato PDF417.7 Posibilidades de soporte para la plataforma y lenguaje a
través de foros de discusión o bibliografía en Internet.2
8 Existencia de herramientas CASE para RUP y la plataforma y lenguaje que permitan realizar ingeniería a partir del desarrollo.
1
Tabla 4.7: Ponderación asignada a cada criterio.
Alternativas de plataformas y lenguajes
Teniendo en cuenta los criterios antes expuestos se eligieron cuatro plataformas
candidatas con sus respectivos lenguajes:
Plataforma Microsoft .NET (C#)
Plataforma J2EE (Java)
Plataforma Microsoft COM+ (Visual Basic 6.0)
Plataforma Borland Delphi (Delphi 7.0)
A cada una de estas plataformas se le asignó una calificación por cada uno de los
criterios analizados, las ponderaciones de la calificación son las que se expresan a
continuación en la siguiente tabla:
Ponderación Descripción3 Cumple grado alto2 Cumple grado medio1 Cumple grado bajo0 No cumple
Tabla 4.8: Tipos de calificación para asignar a las alternativas.
Resultado de la evaluación
La siguiente tabla muestra cuáles fueron las calificaciones asignadas a cada plataforma
para cada criterio y finalmente el resultado que corresponde a la suma del producto de
cada calificación por la ponderación del criterio.
AlternativaCriterios de Evaluación Evaluació
n1 2 3 4 5 6 7 8Plataforma Microsoft .NET (C#) 3 3 3 3 3 3 3 3 60Plataforma J2EE (Java) 0 2 3 2 3 3 3 3 46
Plataforma Microsoft COM+ (Visual Basic) 3 3 1 3 0 3 3 0 42Plataforma Borland (Delphi 7.0) 3 1 2 2 0 0 2 0 26
Tabla 4.9: Resultado de la evaluación técnica.
Como se puede apreciar en la tabla, según nuestros criterios, la plataforma
Microsoft .NET con el lenguaje de programación C# es la alternativa más adecuada
para llevar a cabo este proyecto.
4.1.2 Evaluación económica.
Análisis de costos y beneficios de la Factura Electrónica
Una encuesta realizada por el Centro de Estudios de Economía Digital de la Cámara de
Comercio de Santiago entre 500 empresas de diversos tamaños y sectores en las
regiones Metropolitana, Quinta y Octava arrojó los siguientes resultados en cuanto a los
beneficios y los ahorros de la facturación electrónica.
En cuanto a los principales beneficios de la facturación electrónica, el 67% de las
empresas identifica la agilización de los procesos de facturación y pago, mientras el
54% menciona la simplificación de la declaración y pagos de impuestos, el 44% los
ahorros en costos operacionales, el 41% la reducción de errores en el proceso de
facturación y el 36% la disminución de riesgos de fraude por indebida utilización de los
documentos tributarios.
Figura 4.16: Principales beneficios de la factura electrónica.
En cuanto al ahorro de costos, las empresas visualizan el mayor potencial en la
disminución de gastos asociados al almacenaje físico de los documentos en papel
(66%), seguido por el trámite del timbraje de documentos en el SII (60%), los costos
relacionados al envío y recepción de facturas (49%), y los costos de emisión y
procesamiento de facturas (32%).
Figura 4.17: Principales ahorros de costos de la Factura Electrónica.
La siguiente tabla muestra un resumen de los costos y beneficios asociados al modelo
de facturación electrónica.
Beneficios CostosDisminución de los costos netos de operación.
Servicio de almacenamiento de documentos electrónicos o infraestructura para soportarlo.
Simplificación en el manejo de documentos.
Conexión a Internet.
Liberación de espacio físico de almacenamiento.
Adecuación de los actuales sistemas de facturación o adquisición de un software de facturación electrónica.
Mayor confianza en los documentos tributarios.
Adquisición de Certificados Digitales.
Mejor resguardo de la información. Redes computacionales.Menor tiempo de búsqueda de los documentos.Impresión en papel corriente.Verificación de documentos tributarios.Evitar el timbraje de documentos en el SII.
Tabla 4.10: Resumen de costos y beneficios.
Los procesos que causarán un mayor impacto financiero en las empresas se describen
en la siguiente tabla:
Proceso AfectadoEl modelo de facturación electrónica provocará
Reducción de costos en: Aumento de costos en:Impresión de documentos tributarios.
Impresión.Transporte.
Timbraje de documentos tributarios.
Transporte.Recursos humanos.
Procesamiento Recursos humanos.Uso de infraestructura computacional
Construcción o adquisición de software de facturación electrónica.Actualización o adquisición de un software contable.
Despacho físico Recursos humanos.Transporte.Servicio de correo.
Conexión a Internet.Certificados digitales.
Almacenamiento físico (6 años)
Recursos humanos.Espacio físico.Infraestructura para bodegaje.
Infraestructura computacional.Administración de datos.Sistema de almacenamiento masivo propio o contratado.
Reducción de tiempo Aumento de tiempoTransmisión Envío y RecepciónProcesamiento Emitir, recibir, verificar,
almacenar, actualizar, integrar y ordenar los documentos tributarios.La utilización de los recursos físicos y tecnológicos de la empresa
Tabla 4.11: Procesos que causarán mayor impacto financiero.
Estimación del costo del desarrollo
Para estimar el costo del desarrollo se presenta un flujo de caja en meses desde el mes
de septiembre hasta el mes de marzo, que es el período durante el cual se ha estado
trabajando en el proyecto.
En cuanto a recursos humanos, solamente se considera el costo hora hombre de un
solo recurso y cuyo valor hora se estima en 10,000 pesos chilenos. Se consideran
gastos en transporte a partir del mes de diciembre, por concepto de encuentros con los
profesores guías, se estiman dos encuentros semanales. Los gastos varios consideran
impresiones, tintas, papeles y otros. A continuación se muestra el flujo de caja que
permitió determinar el costo estimado en desarrollar el producto.
ESTIMACION DE COSTO DE DESARROLLO DEL PROYECTO PERIODOS EN MESESCONCEPTOS Sep-03 Oct-03 Nov-03 Dic-03 Ene-04 Feb-03 Mar-04Ingresos Egresos Costo en recurso humano (HH) -$ 400,000 -$ 400,000 -$ 480,000 -$ 720,000 -$ 920,000 -$ 910,000 -$ 630,000Conexión Internet -$ 8,000 -$ 8,000 -$ 8,000 -$ 8,000 -$ 8,000 -$ 8,000 -$ 8,000Transporte $ 0 $ 0 $ 0 -$ 2,560 -$ 5,120 -$ 5,120 -$ 5,120
Varios -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000
Flujo neto -$ 418,000 -$ 418,000 -$ 498,000 -$ 740,560 -$ 943,120 -$ 933,120 -$ 653,120
COSTO TOTAL -$ 4,603,920
Tabla 4.12: Flujo de caja para estimar el costo del desarrollo.
Rentabilidad del proyecto para el inversionista
Para este proyecto hemos analizado dos formas de comercialización y ambas pueden
demostrar que el proyecto es rentable:
1. Realizar una venta directa del producto a una casa de software y que ellos se
dediquen a comercializarlo, en este caso el producto tendría un precio entre un
60% y un 70% sobre el costo del desarrollo.
2. Crear una empresa propia que se dedique a comercializar el producto.
La primera alternativa no requiere de mucho análisis, simplemente demuestra que el
proyecto es rentable ya que se estaría obteniendo un entre un 60% y un 70% de
utilidad.
En el caso de la segunda alternativa esta es más compleja de analizar, para lo cual nos
creamos un flujo de caja a 7 años, tomando como año cero el 2003. El flujo se
construyó basado en la instalación de una empresa para comercializar el producto. Este
flujo lo actualizamos mediante el cálculo del VAN considerando una taza de descuento
de un 15%.
Para calcular el flujo de caja se plantearon varios supuestos, principalmente la cantidad
de licencias del producto adquiridas anualmente, las cuales se establecieron
planteando un escenario pesimista a partir de una cifra real del SII que plantea que en
el país existen 296,000 contribuyentes activos, la cifra supuesta es de 1400 licencias al
cabo de los 7 años con un crecimiento sostenido de 50 licencias por año, lo cual
representa un 0.47% en el séptimo año y un crecimiento del 0.017% anual del total de
contribuyentes activos.
Respecto al precio de la licencia del producto, se decidió entregar las librerías de forma
gratuita, las empresas solamente tendrían que cancelar 30,000 pesos chilenos anuales
por conceptos de actualización. Esto se utilizaría como estrategia comercial y
favorecería la masificación del producto.
También se ofrecerá un servicio de soporte vía WEB el cual puede ser un prepago
anual de 10,000 pesos por 20 eventos, o simplemente un pago de 1000 pesos por
evento. Imponiendo un escenario pesimista, se consideró que un 10% de las empresas
que adquieren el producto compraran el paquete de soporte, del 90% de las empresas
restantes, el 10% solicitará 1 evento anual.
Para facilitar la comercialización y el soporte del producto, se incluyó una inversión en
la construcción de un sitio WEB que permita a las empresas informarse acerca de las
funcionalidades, la licencia, los precios, también descargar el producto y las
actualizaciones y solicitar el soporte por esta vía. La idea es que este sitio WEB
centralice todos los elementos relacionados con la comercialización y distribución del
producto.
Respecto a la publicidad, se decidió construir un brochure de una página con toda la
información del producto, el cual sería enviado por correo electrónico a los
departamentos de informática de las empresas, además haciendo referencia al sitio
WEB para obtener más información. Para desarrollar esta labor y otras tareas
administrativas, es que se decidió la contratación de un recurso por 300,000 pesos
mensuales.
Los costos operacionales no fueron incluidos hasta el quinto año, ya que en los
primeros años no se decidió invertir en infraestructura, el sitio WEB estaría publicado
en un proveedor de WEB hosting y el recurso contratado trabajaría desde su casa con
sus propios recursos.
Para calcular los costos en facturación se estimó un costo por factura de 500 pesos,
basándonos en el estudio de factura electrónica de la Cámara de Comercio de Santiago
que estimó un costo promedio de 700 pesos.
Por último el impuesto a la utilidad considerado fue de un 17%, el cual está publicado
en el sitio WEB del SII como el valor que se estima para el año 2004.
En la siguiente tabla se muestra un resumen de las variables consideradas para
calcular el flujo:
VARIABLESValor de la Licencia $ 0Derecho anual para recibir actualización de versiones $ 30,000Valor anual paquete soporte via Web (20 eventos) $ 10,000Valor soporte adicional x evento $ 1,000% Emp. que adquieren paquete de soporte 10%% Emp. sin soporte que solicitan soporte adicional 10%Cant eventos adicionales x empresa (promedio) 1Impuesto a la utilidad 17%Costo Factura 500Salario recurso operaciones $ 300,000
Tabla 4.13: Variables consideradas para calcular el flujo de caja.
Desglose de Costos Operacionales x Mes
Oficina $ 140,000Teléfono $ 25,000Varios $ 50,000
Secretaria $ 200,000
TOTAL MENSUAL $ 415,000
TOTAL ANUAL $ 4,980,000
Tabla 4.14: Costos operacionales incluidos a partir del quinto año.
FLUJO DE CAJA INVERSIONISTA
AÑO 0 = 2003 PERIODOS EN AÑOSCONCEPTOS 0 1 2 3 4 5 6 7Ingresos Cant. de Licencias Adquiridas 50 100 150 200 250 300 350 Cant. de Licencias Adquiridas (Acum.) 50 150 300 500 750 1,050 1,400 Ingresos por Venta de Licencias $ 0 $ 0 $ 0 $ 0 $ 0 $ 0 $ 0Ingresos por servicio de actualización $ 1,500,000 $ 4,500,000 $ 9,000,000 $ 15,000,000 $ 22,500,000 $ 31,500,000 $ 42,000,000Ingresos por servicio de soporte $ 55,000 $ 150,000 $ 300,000 $ 500,000 $ 750,000 $ 1,050,000 $ 1,400,000Egresos Mantención del dominio .cl -$ 20,170 $ 0 -$ 20,170 $ 0 -$ 20,170 $ 0 -$ 20,170Arriendo Web Hosting -$ 139,000 -$ 139,000 -$ 139,000 -$ 139,000 -$ 139,000 -$ 139,000 -$ 139,000Arriendo Conexión Internet -$ 168,000 -$ 168,000 -$ 168,000 -$ 168,000 -$ 168,000 -$ 168,000 -$ 168,000Gastos recursos humanos -$ 3,600,000 -$ 3,600,000 -$ 3,600,000 -$ 3,600,000 -$ 3,600,000 -$ 3,600,000 -$ 3,600,000Gastos en Facturación -$ 25,000 -$ 75,000 -$ 150,000 -$ 250,000 -$ 375,000 -$ 525,000 -$ 700,000Costos Operacionales $ 0 $ 0 $ 0 $ 0 -$ 4,980,000 -$ 4,980,000 -$ 4,980,000UTILIDAD ANTES DE IMPUESTO -$ 2,397,170 $ 668,000 $ 5,222,830 $ 11,343,000 $ 13,967,830 $ 23,138,000 $ 33,792,830UTILIDAD ANTES DE IMPUESTO ACUM. -$ 2,397,170 -$ 1,729,170 $ 3,493,660 $ 14,836,660 $ 28,804,490 $ 51,942,490 $ 85,735,320IMPUESTO $ 0 $ 0 $ 593,922 $ 1,928,310 $ 2,374,531 $ 3,933,460 $ 5,744,781UTILIDAD NETA -$ 2,397,170 $ 668,000 $ 4,628,908 $ 9,414,690 $ 11,593,299 $ 19,204,540 $ 28,048,049Iniciación de Actividades -$ 500,000 Inversión en Desarrollo Producto -$ 4,603,920 Inversión en Construcción Web Site -$ 500,000 Licencia Visual Studio .NET Enterprise -$ 1,000,000
Diseño brochure producto -$ 150,000
FLUJO ANUAL -$ 6,753,920 -$ 2,397,170 $ 668,000 $ 4,628,908 $ 9,414,690 $ 11,593,299 $ 19,204,540 $ 28,048,049
FLUJO ACUMULADO -$ 6,753,920 -$ 9,151,090 -$ 8,483,090 -$ 3,854,182 $ 5,560,508 $ 17,153,807 $ 36,358,347 $ 64,406,396
VAN CON TASA 15.00% $ 24,704,021 15.00%
Tabla 4.15: Flujo de caja para medir la rentabilidad del proyecto.
Análisis de los resultados
Si observamos el Valor Actual Neto (VAN) calculado con una tasa de descuento
considerablemente elevada de un 15%, apreciamos que este es positivo y además es
bastante elevado lo cual nos indica que el proyecto es rentable.
Por otra parte podemos apreciar en el flujo acumulado que en el 4 año se estaría
recuperando la inversión con 5,000,000 de pesos de utilidad neta.
Finalmente estamos hablando de un proyecto que podría dejar una utilidad neta de
64,000,000 de pesos al cabo de los siete años, lo cual representa una cifra atractiva si
consideramos la cantidad de licencias que se estima colocar en el mercado.
Rentabilidad del proyecto para la empresa
Para demostrar la rentabilidad del proyecto orientado a la empresa lo haremos a través
de un flujo de ahorro de costos.
El proyecto dte.NET puede tener una rentabilidad mayor o menor para una empresa,
dependiendo de la cantidad de documentos tributarios que esta emita anualmente y el
costo unitario de emitir un documento tributario.
Para poder construir este flujo nos hemos basado en un estudio de la Cámara de
Comercio el cual plantea que los 10,000 mayores contribuyentes del país emiten en
promedio 28,800 documentos tributarios anualmente con un costo unitario de 442
pesos, reduciéndose a 102 pesos con la facturación electrónica representando un
ahorro de un 83%. Estos valores se estiman para el fin de la transición de la facturación
electrónica, lo cual significa que el modelo se ha implantado satisfactoriamente, está
masificado y operando adecuadamente.
Se consideró que la empresa pagará el derecho de actualización del producto
anualmente y también el paquete de soporte, además que la inversión para integrar el
producto con su sistema de facturación o construir uno nuevo sería de 15,000,000 de
pesos aproximadamente, lo cual representa una cifra considerable.
A continuación se presenta el grafico que expresa el estudio realizado por la Cámara de
Comercio y también el flujo de ahorro de costos para la empresa.
Figura 4.18: Estudio sobre costos unitarios de facturación de la CSS.
FLUJO DE AHORRO DE COSTOS PARA LA EMPRESA
PERIODOS EN AÑOSCONCEPTOS 0 1 2 3 4 5 6 7Antes Número de DT emitidos 28,800 28,800 28,800 28,800 28,800 28,800 28,800Costo facturación tradicional $ 12,729,600 $ 12,729,600 $ 12,729,600 $ 12,729,600 $ 12,729,600 $ 12,729,600 $ 12,729,600Después Costo facturación electrónica $ 2,937,600 $ 2,937,600 $ 2,937,600 $ 2,937,600 $ 2,937,600 $ 2,937,600 $ 2,937,600Costo adquisición de licencia DTE.NET $ 0 Costo derecho actualización DTE.NET -$ 30,000 -$ 30,000 -$ 30,000 -$ 30,000 -$ 30,000 -$ 30,000 -$ 30,000Costo paquete de soporte DTE.NET -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000 -$ 10,000
Inversión en integración o desarrollo -$ 15,000,000
FLUJO ANUAL -$ 15,000,000 $ 9,752,000 $ 9,752,000 $ 9,752,000 $ 9,752,000 $ 9,752,000 $ 9,752,000 $ 9,752,000
FLUJO ACUMULADO -$ 15,000,000 -$ 5,248,000 $ 4,504,000 $ 14,256,000 $ 24,008,000 $ 33,760,000 $ 43,512,000 $ 53,264,000
VARIABLES CONSIDERADASNúmero de DT emitidos anualmente 28,800Número de DT emitidos mensualmente 2,400Costo Facturación Tradicional 442
Costo Facturación Electrónica 102
Tabla 4.17: Variables consideradas en el flujo de ahorro de costos.
Tabla 4.16: Flujo de ahorro de costos para la empresa.
Análisis de los resultados:
Si observamos el flujo neto actual podemos apreciar que la empresa tendría ahorros de
aproximadamente 10,000,000 de pesos anuales, además en el segundo año estaría
recuperando la inversión inicial con utilidades de 4,000,000 de pesos aproximadamente.
En el largo plazo podemos apreciar un ahorro acumulado de 50,000,000 de pesos.
4.1.3 Conclusiones
Para concluir deberíamos resumir dos aspectos:
Técnicamente el estudio realizado demuestra que el proyecto es factible de llevar
a cabo.
Económicamente el estudio presentado demuestra que el proyecto es rentable
tanto para el inversionista como para una empresa que adquiera el producto.