UNIVERSIDAD ANDRES BELLO FACULTAD DE INGENIERIA Y CONSTRUCCION CIVIL ESCUELA DE INGENIERIA DE EJECUCION TECNOLOGICA INGENIERIA DE EJECUCION EN COMPUTACION E INFORMATICA

Elementos de Tecnologas de Informacin Involucrados en el Modelo de Facturacin Electrnica y su Aplicacin Prctica.

MAIKEL CRUZ LAM PROYECTO DE TITULO PARA OPTAR AL TITULO DE INGENIERO EN EJECUCION EN COMPUTACION E INFORMATICA.

SANTIAGO CHILE MARZO, 2004

Aqu va la dedicatoria.

AGRADECIMIENTO Quisiera agradecer a todas aquellas instituciones y personas que hicieron posible la culminacin de mi carrera universitaria y la materializacin de este proyecto de ttulo, a la Universidad Andrs Bello y todos los profesores, que durante estos ltimos cuatro aos supieron compartir su experiencia y conocimiento, a los profesores guas, que en todo momento estuvieron apoyando y supervisando el desarrollo del trabajo, a mi empresa South Consulting y su grupo de profesionales, colegas y amigos que en todo momento me han brindado su colaboracin, a toda mi familia, que siempre la llevo presente y es el motor que impulsa mis ideas y acciones, a todos mis amigos, a mi esposa, a quien tanto amo y sin la cual no hubiera sido posible llegar hasta ac, a todos, gracias.

INDICE DE CONTENIDO 1.- CAPITULO 1: INTRODUCCION...................................................................................9 1.1.- Planteamiento del Problema..................................................................................9 1.2.- Objetivos Generales...............................................................................................9 1.3.- Objetivos Especficos.............................................................................................9 1.4.- Alcances...............................................................................................................10 2.- CAPITULO 2: FUNDAMENTOS TEORICOS.............................................................12 2.1.- Modelo de facturacin tradicional versus electrnico..........................................12 2.1.1.- Situacin actual de la facturacin en Chile....................................................12 2.1.2.- Facturacin electrnica en Chile...................................................................13 2.2.- Aspectos legales de la facturacin electrnica en Chile......................................15 2.3.- Facturacin electrnica y firma digital..................................................................16 2.3.1.- Objetivo de la firma digital..............................................................................16 2.3.2.- Encriptacin con clave pblica......................................................................16 2.3.3.- Certificado digital...........................................................................................19 2.3.4.- Aplicacin de la firma digital en la factura electrnica...................................20 2.4.- El estndar XML y su aplicacin en la factura electrnica...................................25 2.4.1.- Qu es XML y cules son sus beneficios?..................................................25 2.4.2.- Aplicacin de XML en la factura electrnica..................................................27 2.4.3.- World Wide Web Consortium (W3C).............................................................27 2.4.4.- Firma digital de documentos XML (XMLDSIG).............................................28 2.4.5.- Aplicacin de XMLDSIG en factura electrnica.............................................30 2.4.6.- Tecnologa XML Web Services y sus beneficios...........................................30 2.4.7.- Aplicacin de la tecnologa XML Web Services en factura electrnica........31 3.- CAPITULO 3: METODOLOGIA..................................................................................34 3.1.- Descripcin de la metodologa.............................................................................34 3.2.- Aplicacin de la metodologa................................................................................35 4.- CAPITULO 4: RESULTADOS Y DISCUSION............................................................43 4.1.- Evaluacin del proyecto.......................................................................................43 4.1.1.- Evaluacin tcnica.........................................................................................43 4.1.2.- Evaluacin econmica...................................................................................47 4.1.3.- Conclusiones..................................................................................................61

INDICE DE TABLAS Tabla 2.1: Funciones en el modelo tradicional y electrnico de facturacin...................15 Tabla 3.2: Artefactos a obtener en la fase de Inicio.........................................................37 Tabla 3.3: Artefactos a obtener en la fase de Elaboracin..............................................39 Tabla 3.4: Artefactos a obtener en la fase de Construccin............................................40 Tabla 3.5: Artefactos a obtener en la fase de Transicin................................................41 Tabla 4.6: Valores de ponderacin para asignar a los criterios.......................................45 Tabla 4.7: Ponderacin asignada a cada criterio.............................................................46 Tabla 4.8: Tipos de calificacin para asignar a las alternativas......................................46 Tabla 4.9: Resultado de la evaluacin tcnica.................................................................47 Tabla 4.10: Resumen de costos y beneficios..................................................................49 Tabla 4.11: Procesos que causarn mayor impacto financiero.......................................50 Tabla 4.12: Flujo de caja para estimar el costo del desarrollo.........................................52 Tabla 4.13: Variables consideradas para calcular el flujo de caja...................................55 Tabla 4.14: Costos operacionales incluidos a partir del quinto ao................................55 Tabla 4.15: Flujo de caja para medir la rentabilidad del proyecto...................................56 Tabla 4.16: Flujo de ahorro de costos para la empresa..................................................60 Tabla 4.17: Variables consideradas en el flujo de ahorro de costos...............................60

INDICE DE FIGURAS Figura 2.1: Modelo tradicional de facturacin..................................................................13 Figura 2.2: Modelo electrnico de facturacin.................................................................14 Figura 2.3: Ilustracin del proceso de encriptacin.........................................................17 Figura 2.4: Encriptacin Asimtrica..................................................................................18 Figura 2.5: Hashing..........................................................................................................19 Figura 2.6: Representacin de un certificado digital........................................................20 Figura 2.7: Estructura del Cdigo de Autorizacin de Folios...........................................21 Figura 2.8: Estructura del Timbre Electrnico..................................................................22 Figura 2.9: Cdigo de barras bidimensional (PDF417)....................................................23 Figura 2.10: Estructura resumida de un DTE...................................................................24 Figura 2.11: Elementos de un DTE que involucran la firma digital..................................25 Figura 2.12: Esquema de una firma digital XML..............................................................29 Figura 2.13: Participacin de XML Web Services en la factura electrnica....................32 Figura 3.14: Rational Unified Process (RUP)...................................................................35 Figura 3.15: Aplicacin de RUP en el proyecto...............................................................36 Figura 4.16: Principales beneficios de la factura electrnica...........................................48 Figura 4.17: Principales ahorros de costos de la Factura Electrnica.............................49 Figura 4.18: Estudio sobre costos unitarios de facturacin de la CSS............................59

RESUMEN A raz de la introduccin del modelo de facturacin electrnica en Chile es que surge la idea de llevar a cabo este proyecto, el cual tiene por objetivos generales investigar y conocer las tecnologas de informacin involucradas en la facturacin electrnica y construir un conjunto de libreras de clases que puedan ser reutilizadas para la generacin de documentos tributarios electrnicos. Para llevar a cabo este proyecto se utiliz la metodologa Rational Unified Process (RUP), la cual cuenta con fases y disciplinas que nos permitieron controlar, administrar y desarrollar el proyecto. Se realiz una evaluacin tcnica para determinar la mejor alternativa en cuanto a plataforma y lenguaje para desarrollar las libreras de clases, as como un estudio econmico para determinar el costo de desarrollar el producto y la rentabilidad econmica tanto para el inversionista como para la empresa.

CAPITULO 1 INTRODUCCION

1.- CAPITULO 1: INTRODUCCION 1.1.- Planteamiento del Problema Desde hace unos aos el Gobierno de Chile se encuentra dando pasos para introducir el concepto de Gobierno Electrnico (e-government) en el Pas, pionero de esta tarea es el Servicio de Impuestos (SII), el cual dio su primer paso con la introduccin de las declaraciones de impuestos electrnicas a travs de Internet y actualmente se encuentra implantando el modelo de facturacin electrnica. 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 facturacin electrnica, stas tendrn que modificar parte de sus procesos internos, incorporar nuevas tecnologas y modificar sus programas tradicionales de facturacin. La idea es poder construir un producto que pueda ser utilizado por las empresas chilenas, para adaptar sus programas de facturacin y que estos puedan soportar el nuevo modelo de facturacin electrnica. 1.2.- Objetivos Generales Investigar y conocer las tecnologas de informacin involucradas en el modelo de facturacin electrnica en Chile segn las normativas del Servicio de Impuestos Internos (SII). Construir un conjunto de libreras de clases reutilizables que permitan la generacin de documentos tributarios electrnicos. 1.3.- Objetivos Especficos Estudiar los procesos de negocio del modelo de facturacin electrnica en Chile. Estudiar y conocer los conceptos, objetivos y aplicaciones de la firma electrnica con certificado digital. Estudiar y conocer las especificaciones del estndar XML y las especificaciones de firma electrnica sobre documentos XML (XMLDSIG), segn la W3C (World Wide Web Consortium). Conocer sobre la tecnologa Web Services y su participacin en el modelo de facturacin electrnica.

 Construir un prototipo de aplicacin que muestre la generacin de la factura electrnica utilizando las libreras de clases desarrolladas. 1.4.- Alcances Para dar cumplimiento a los objetivos planteados anteriormente se llevarn a cabo un conjunto de actividades y tareas las cuales estarn delimitadas por los siguientes alcances: Definir los conceptos y elementos tericos del modelo de facturacin electrnica. Definir los conceptos generales de la firma digital y su aplicacin en el modelo de facturacin electrnica en Chile. Definir los conceptos del estndar XML y la especificacin XMLDSIG de la W3C para la firma digital de documentos XML. Definir los conceptos del cdigo de barras bidimensional (PDF417). Construir un conjunto de libreras de clases que permitan la generacin en formato XML y el firmado de documentos tributarios electrnicos. Construir un prototipo de aplicacin que permita la generacin de la factura electrnica.

CAPITULO 2 FUNDAMENTOS TEORICOS

2.- CAPITULO 2: FUNDAMENTOS TEORICOS 2.1.- Modelo de facturacin tradicional versus electrnico. 2.1.1.- Situacin actual de la facturacin 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 autorizacin del SII se lleva a cabo a travs de un timbre de cuo 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 peridicamente 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 volmenes de documentos. Por otra parte el utilizar formularios foliados y timbrados dificulta el procesamiento masivo, ya que se debe respetar los folios. Adems se exige la utilizacin de impresin por impacto, desechando tecnologas de impresin ms avanzadas como lser e inyeccin de tinta. Respecto al almacenamiento de documentos tributarios, el contribuyente est obligado a guardar el documento en papel por un perodo de 6 aos, durante el cual estar sujeto a cualquier inspeccin por parte del SII, esta obligacin demanda para grandes volmenes de documentos, elevados costos en administracin y bodegaje.

Figura 2.1: Modelo tradicional de facturacin.

2.1.2.- Facturacin electrnica en Chile. En el modelo de facturacin electrnica los contribuyentes debern estar enrolados en el Servicio de Impuestos Internos (SII) como emisores de documentos tributarios electrnicos, lo cual no los obligar a emitir todos sus documentos en forma electrnica pero si a recibir documentos electrnicos de otros emisores. Los contribuyentes enrolados podrn solicitar la autorizacin de sus folios a travs del sitio Web del SII con los que podrn emitir sus documentos tributarios electrnicos, los cuales debern almacenar solamente en formato electrnico eximindose de la obligacin de conservarlos en papel para posibles inspecciones del SII. Los documentos tributarios electrnicos emitidos debern ser enviados al SII a travs de Internet y al receptor ya sea manual o electrnico, utilizando el medio que corresponda, si el receptor es manual se le deber enviar la representacin en papel del documento.

Un documento tributario electrnico se considerar vlido si este es generado segn 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 representacin impresa del documento deber contener un timbre electrnico el que se imprimir en un cdigo de barras bidimensional y se obtendr a travs de un mecanismo de seguridad especificado por el SII, este timbre permitir verificar en cualquier momento la validez de un documento tributario electrnico impreso.

Figura 2.2: Modelo electrnico de facturacin.

En la tabla 2.1 podemos apreciar un comparativo de cmo se llevan a cabo las funciones involucradas en el proceso de facturacin en cada uno de los modelos.

Funcin Foliacin de documentos Timbrado de documentos Timbre Almacenamiento

Modelo tradicional de facturacin Preimpreso en los documentos En oficinas del Servicio de Impuestos Internos De cuo Papel por un perodo de

Modelo electrnico de facturacin Autorizado a travs del sitio Web del SII Por el contribuyente Electrnico Electrnico

Verificacin de validez Impresin del documento

6 aos para el contribuyente Slo de autorizacin en el sitio Web del SII Papel autocopiativo, formulario continuo, prefoliado, impresora de impacto.

Autorizacin, Recepcin y Validez en el sitio Web del SII. Papel normal ni autocopiativo ni continuo y con impresora lser o de inyeccin de tinta.

Tabla 2.1: Funciones en el modelo tradicional y electrnico de facturacin.

2.2.- Aspectos legales de la facturacin electrnica en Chile. Con el objetivo de otorgar validez legal al modelo de facturacin electrnica 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: Resolucin Exenta SII N45 del 01 de Septiembre del 2003 Establece normas y procedimientos de operacin respecto de los documentos Tributarios Electrnicos. Fuente: Subdireccin de Fiscalizacin Resolucin Exenta N18 del 22 de Abril del 2003 Establece que los contribuyentes que sean autorizados para emitir documentos tributarios electrnicos, debern otorgarlos impresos en soporte papel a los receptores no electrnicos y a los receptores electrnicos en los casos que indica. Fuente: Subdireccin de Fiscalizacin Resolucin Exenta N11 del 14 de Febrero del 2003 Establece Procedimiento para que Contribuyentes Autorizados para Emitir Documentos Electrnicos que Indica Pueda Tambin Enviarlos por estos Medios a Receptores Manuales. Fuente: Subdireccin de Fiscalizacin

2.3.- Facturacin electrnica y firma digital. 2.3.1.- Objetivo de la firma digital. Las emergentes tecnologas de informacin impulsan cada vez ms 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 travs de transacciones B2C. Estas transacciones involucran intercambio de datos muy sensibles para las compaas, por lo cual se requieren de avanzadas tecnologas 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, tambin es necesario asegurar la autenticidad quin envo el mensaje?, la integridad habr sido modificado el mensaje en su trayecto?, y tambin 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 electrnicos de un mecanismo anlogo a la firma tradicional en el mundo del papel. 2.3.2.- Encriptacin con clave pblica. Encriptacin: La encriptacin es una transformacin matemtica de los datos, a travs de un algoritmo especfico y por medio de la utilizacin de una clave, de forma tal que los datos puedan ser transformados a su estado original, solamente utilizando una clave para tal propsito. La encriptacin garantiza la confidencialidad en el intercambio de mensajes electrnicos.

Figura 2.3: Ilustracin del proceso de encriptacin.

Encriptacin Asimtrica: La encriptacin asimtrica o tambin conocida como encriptacin con clave pblica, 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 travs de una transformacin matemtica de los datos de acuerdo a un algoritmo y un par de nmeros, conocidos como llaves pblica y privada. Cada participante en el intercambio tiene su par de llaves, la llave pblica 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 estn relacionadas matemticamente, es computacionalmente imposible derivar la llave privada a partir de la llave pblica. La relacin entre la llave pblica 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: Encriptacin Asimtrica.

Si un mensaje es cifrado con la llave privada, solo aquellas personas que tengan acceso a la llave pblica correspondiente a esa llave privada podrn descifrar el mensaje. Por otra parte si un mensaje es cifrado con la llave pblica, solo el propietario de la llave privada podr descifrar el mensaje. Hashing: Consiste en obtener a partir de un mensaje y aplicando una transformacin o algoritmo matemtico, un mensaje mucho ms pequeo pero cuyo contenido representa de forma nica al mensaje original, esta representacin que se obtiene se denomina hash o digesto. Si un bit del mensaje original es modificado y la transformacin 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 seccin anterior la encriptacin con clave pblica permite lograr confidencialidad, autenticidad, integridad y no repudio, pero ahora surge otra problemtica y es una de las ms crticas en torno a la criptografa, la administracin de las claves, quin certifica y distribuye las claves?, quin establece el perodo 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 electrnico que pudiera contener las claves pblicas y privadas, as como informacin que identificara al propietario de las claves, es as que surgen los certificados digitales. Los certificados son documentos electrnicos generados y distribuidos por las Entidades de Certificacin, que contienen la identidad del propietario, su correspondiente clave pblica y el perodo de validez. Los certificados digitales

contienen la firma electrnica de la entidad certificadora, lo cual garantiza la validez y autenticidad de los mismos.

Figura 2.6: Representacin de un certificado digital.

2.3.4.- Aplicacin de la firma digital en la factura electrnica. En el modelo de facturacin electrnica la firma digital se aplica en varias instancias las cuales se listan y explican a continuacin. Enrolamiento e intercambio con el SII: Toda empresa emisora de documentos tributarios electrnicos tendr que interactuar con el SII a travs de su sitio Web, para esto el representante legal de la empresa y todas las personas autorizadas para realizar operaciones con los DTE, debern adquirir certificados digitales ya que la autentificacin y el enrolamiento en el sitio Web del SII es a travs de certificados digitales. Cdigo de Autorizacin de Folios (CAF): El cdigo de autorizacin 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 electrnicos, adems el CAF contiene la llave privada que deber utilizar el contribuyente para firmar el timbre electrnico de los DTE que se emitirn dentro de ese rango.

Figura 2.7: Estructura del Cdigo de Autorizacin de Folios.

En la seccin <TD> se especifica el tipo de documento tributario 33 (Factura Electrnica), en la seccin <RNG> se indica el rango de folios que se est autorizando para ese tipo de documento, desde el 50 hasta el 101, en la seccin <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 pblica cuyo valor se obtiene de la seccin <RSAPK> y verificando la firma digital contenida en <FRMA>. Por otra parte en la seccin <RSASK> se encuentra la clave privada que utilizar el contribuyente para firmar el timbre electrnico que deber estar presente tanto en la representacin electrnica como impresa del documento tributario. Timbre Electrnico: El timbre electrnico es un elemento que deber contener cada documento tributario electrnico 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 adems el CAF que autoriza la emisin de ese DTE. El timbre deber ser firmado digitalmente con la clave privada que entreg el SII en el CAF que autoriza la emisin de ese DTE.

Figura 2.8: Estructura del Timbre Electrnico.

Como se puede apreciar en la seccin <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 emisin del DTE en cuestin. La Figura 2.8 muestra la representacin en formato XML del timbre electrnico, en la representacin impresa del documento tributario, el timbre electrnico deber imprimirse en forma de cdigo de barras bidimensional (PDF417), esto permite que en cualquier momento se pueda verificar la autenticidad de un documento leyendo la informacin contenida en el cdigo de barras. En la Figura 2.9 se muestra un ejemplo de un cdigo de barras bidimensional en formato PDF417.

Figura 2.9: Cdigo de barras bidimensional (PDF417).

Documento Tributario Electrnico: Por otra parte el documento tributario electrnico tambin es representado en formato XML, este documento deber ser firmado digitalmente utilizando la clave privada contenida en uno de los certificados adquiridos para tales propsitos por la empresa emisora. Esta firma digital sobre el DTE permitir que tanto el SII como cualquier receptor electrnico puedan verificar la autenticidad e integridad del documento electrnico.

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 electrnico en los cuales est involucrada la firma digital.

Figura 2.11: Elementos de un DTE que involucran la firma digital.

2.4.- El estndar XML y su aplicacin en la factura electrnica. 2.4.1.- Qu es XML y cules son sus beneficios? Mientras el estndar HTML (Hypertext Markup Language) no es extensible, el estndar 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 permitan controlar y especificar la forma de todos los documentos en ese conjunto, esta tarea requera de mucho tiempo y adems resultaba ser compleja, pero sin embargo funcionaba. Entonces surge la interrogante de cmo capturar la extensibilidad de SGML minimizando su complejidad, en otras palabras, era resolver un abismo que exista entre SGML y HTML.

La respuesta es XML (Extensible Markup Language), este estndar permite reutilizar la mayora 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 versin simplificada de SGML. Actualmente XML es un estndar cuya especificacin est establecida por la W3C (World Wide Web Consortium), este estndar fue diseado para describir los datos, utilizando para ello los DTD (Document Type Definition) o esquemas XML. La diferencia entre XML y HTML es que fueron diseados con propsitos diferentes, XML fue diseado para describir los datos y se enfoca en qu son los datos en si, mientras que HTML fue diseado para mostrar los datos y se enfoca en como los datos se ven. HTML permite mostrar la informacin mientras que XML permite describir la informacin. 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. Estndar de libre uso. Extensibilidad. Se describe a si mismo. Separa el contenido de la presentacin. Soporta documentos en mltiples lenguajes. Facilita la comparacin y agregacin de datos. Puede contener diversos tipos de datos. Puede contener los datos existentes actualmente. Rpida adopcin por la industria tecnolgica. A continuacin 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.- Aplicacin de XML en la factura electrnica. El estndar XML fue seleccionado por el Servicio de Impuestos Internos como el formato en el cual se representarn e intercambiarn electrnicamente los documentos tributarios electrnicos. En el sitio Web del Servicio de Impuestos Internos podemos encontrar el esquema XML que establece la estructura que deben tener los documentos tributarios electrnicos representados en lenguaje XML. 2.4.3.- World Wide Web Consortium (W3C). La W3C es una organizacin internacional encargada de desarrollar y promover tecnologas y estndares que permitan la interoperabilidad. Especificaciones, guas, software y herramientas son algunos de los elementos desarrollados por esta organizacin que han permitido desarrollar todo el potencial del Web. Es un forum de informacin, comercio y comunicacin. Algunos estndares 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 facturacin electrnica en Chile, el Servicio de Impuestos Internos utiliz varios estndares establecidos por la W3C, primeramente XML, como el lenguaje que se utilizar para representar los documentos tributarios electrnicos y que fue visto anteriormente, luego XMLDSIG, que son las especificaciones para firmar digitalmente documentos XML y que abordar en la prxima seccin. 2.4.4.- Firma digital de documentos XML (XMLDSIG). Si bien el concepto de firma digital es genrico y aplica sobre cualquier transaccin electrnica, por el auge que ha adquirido el estndar XML, la W3C desarroll una especificacin que establece como deben ser firmados los documentos XML, esto permitir sacar provecho de los beneficios de XML y adems la interoperabilidad entre todas las tecnologas que sigan la especificacin, 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 algn acuerdo previo. La especificacin conocida bajo la sigla XMLDSIG, establece el esquema de una firma digital sobre un documento XML. Una de las caractersticas fundamentales del XMLDSIG es la habilidad de poder firmar solo partes especficas 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 tambin es relevante cuando en algunas ocasiones solamente se necesita resguardar la integridad de algunas partes del documento XML, dejando la posibilidad de que las dems 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 sern 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 informacin 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 pblica 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 ms informacin consultar en el sitio Web de la W3C:

http://www.w3.org/Signature/ 2.4.5.- Aplicacin de XMLDSIG en factura electrnica. Como mencionamos anteriormente el Servicio de Impuestos Internos ha establecido el uso del XMLDSIG como estndar para el firmado digital de documentos tributarios electrnicos. Si observamos la Figura 2.10 presentada en la seccin 2.3.4, donde se muestra cul es el esquema o estructura de un documento tributario electrnico, podemos ver que existe un elemento <Signature> el cual contendr la firma digital sobre el elemento o recurso <Documento>, segn lo explicado en la seccin 2.4.4 y segn el esquema expuesto en la Figura 2.12. 2.4.6.- Tecnologa XML Web Services y sus beneficios. Un XML Web Service o Servicio Web XML es una entidad programable que provee funcionalidades especficas y es accesible a un sinnmero de sistemas o aplicaciones utilizando estndares de Internet tales como el XML y HTTP. Los Servicios Web XML dependen completamente de XML y otros estndares de Internet para crear una infraestructura que soporte la interoperabilidad entre aplicaciones a tal punto, que resuelve muchos de los problemas que histricamente se haban presentado en este mbito. Un Servicio Web XML puede ser utilizado internamente por una aplicacin o expuesto externamente a travs de Internet, para usar desde cualquier aplicacin. Producto a que este es accedido a travs de una interfaz estndar, un Servicio Web XML permite que sistemas heterogneos trabajen en conjunto como una unidad simple con funcionalidades extendidas a travs del Web.

Esta tecnologa provee una solucin viable para habilitar la interoperabilidad de los datos y de los sistemas ya que utiliza mensajera basada en el estndar 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 caractersticas de un Servicio Web XML es el alto grado de abstraccin que existe entre la implementacin y la utilizacin o consumo del servicio. Utilizando el estndar XML como mecanismo de mensajera a travs 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 ms all que los parmetros de entrada, la salida y donde se encuentra publicado el servicio. La tecnologa de Servicios Web XML impone una nueva era del desarrollo de aplicaciones distribuidas, constituye uno de los prximos pasos revolucionarios de Internet y se convertirn en la estructura fundamental para unir todos los dispositivos de computadores. 2.4.7.- Aplicacin de la tecnologa XML Web Services en factura electrnica. Una de las principales ventajas que nos brinda la facturacin electrnica es la rapidez con la cual se podrn intercambiar los documentos tributarios, el comprador podr recibir ms rpido la factura, el proveedor podr enviar sus documentos tributarios mucho ms rpido al Servicio de Impuestos Internos. Pero para que esto sea posible se necesita una infraestructura que permita la integracin de sistemas heterogneos, y es aqu donde intervienen los Servicios Web XML. En la facturacin electrnica los Servicios Web XML intervienen en varias instancias, primeramente el Servicio de Impuestos Internos a puesto a disposicin de los contribuyentes varios Servicios Web que permitirn realizar determinadas operaciones, tales como: Autentificacin automtica al SII, Consulta de estado de un envo de documentos tributarios y Consulta de estado de un documento tributario. Por otra parte los proveedores podrn exponer sus propios Servicios Web para que los compradores

descarguen sus facturas, o los compradores podrn exponer sus Servicios Web para que los proveedores enven sus facturas.

Figura 2.13: Participacin de XML Web Services en la factura electrnica.

CAPITULO 3 METODOLOGIA

3.- CAPITULO 3: METODOLOGIA 3.1.- Descripcin de la metodologa. Rational Unified Process (RUP), es una metodologa que expresa el proceso de ingeniera 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 ejecucin 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, Elaboracin, Construccin y Transicin. En la otra dimensin tenemos las disciplinas: Modelamiento del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Distribucin, Configuracin y Administracin de Cambios, Administracin de Proyecto y Ambiente. Las disciplinas permiten agrupar lgicamente todas las actividades que deben ser llevadas a cabo durante la ejecucin 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 iteracin en la que nos encontremos se requerir ms o menos esfuerzo en una u otra disciplina. En la siguiente figura se muestra la interaccin 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.- Aplicacin de la metodologa. La aplicacin 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 agrupacin lgica de todas las actividades a desarrollar, se encuentran definidos los roles que ejecutan cada actividad y cuales son los artefactos que debern utilizarse y cuales obtenerse como resultado. La administracin la realizamos siguiendo una de las disciplinas que es la Administracin de Proyecto, en esta disciplina estn definidas actividades y artefactos

relacionados con la administracin, Planes de Proyectos, Planes de Iteraciones, Lista de Riesgos, Planes de Prueba, Planes de Distribucin, entre otros.

Figura 3.15: Aplicacin de RUP en el proyecto.

Los criterios a seguir para pasar de una fase a la otra, as como los principales artefactos a obtener sern expuestos a continuacin: Fase de Inicio Esta fase es importante principalmente para los primeros esfuerzos de desarrollo, en la cual es significativo identificar los riesgos del proyecto, tambin se debe determinar si el proyecto se justifica y .si es factible llevarlo a cabo. Objetivos

 Establecer el mbito y las condiciones de lmites 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 Evaluacin Los requerimientos han sido capturados, son correctos y existe un entendimiento de los mismos. Todos los requerimientos estn dentro del mbito del proyecto, estn 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 contencin para cada uno de ellos. Artefactos Artefacto Visin Criterio de Aceptacin Los requerimientos esenciales, principales caractersticas y restricciones estn documentados. Lista de Riesgos Administracin del Los riesgos iniciales del proyecto estn Proyecto identificados. Plan de Iteracin Administracin del Plan de iteracin para la primera Proyecto iteracin de la fase de Elaboracin completo y revisado. Infraestructura Ambiente Todas las herramientas que soportan de Desarrollo el proyecto estn seleccionadas, las que se necesitan para trabajar en la fase de inicio estn instaladas. Glosario Requerimientos Trminos importantes estn definidos y revisados. Modelo de Casos Requerimientos Actores y Casos de Usos ms de Uso importantes se encuentran identificados. Tabla 3.2: Artefactos a obtener en la fase de Inicio. Disciplina Requerimientos

Fase de Elaboracin El propsito de esta fase es definir los elementos fundamentales de la arquitectura del sistema para proveer una base estable para los esfuerzos de diseo e implementacin posteriormente en la fase de construccin. Esta arquitectura debe ser desarrollada considerando los requerimientos ms significativos (aquellos que tienen un gran impacto en la arquitectura del sistema) y un anlisis de riesgos. Objetivos Asegurar que la arquitectura, los requerimientos, y la planificacin son lo suficientemente estables y que los riesgos estn 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 segn los tiempos requeridos. Criterios de Evaluacin La visin del producto y los requerimientos son estables. Los planes de iteracin para la fase de construccin estn lo suficientemente detallados para permitir realizar el trabajo. Los planes de iteracin para la fase de construccin estn soportados por estimaciones realistas. Artefactos Artefacto Lista de Riesgos Documento de Arquitectura de Software Disciplina Administracin del Proyecto Anlisis y Diseo Criterio de Aceptacin Actualizados y revisados. Creado y delineado, incluyendo descripcin detallada para los casos de usos arquitecturalmente significativos (vista de casos de uso), identificacin de los principales mecanismos y elementos de diseo (vista lgica), ms

Modelo de Diseo (incluyendo artefactos constituyentes)

Anlisis y Diseo

Modelo de Implementacin (incluyendo artefactos constituyentes) Plan de Iteracin

Implementacin

la definicin de la vista de procesos y la vista de distribucin. Definido y delineado, la realizacin de los casos de uso para los escenarios significativos arquitecturalmente han sido definidas y el comportamiento requerido ha sido asociado con sus elementos de diseo correspondiente. Los componentes han sido identificados y las decisiones de construccin/compra/reutilizacin estn claras para estimar el costo de la fase de construccin y una planificacin adecuada. La estructura inicial ha sido creada y la mayora de los componentes prototipados. Plan de iteracin para la fase de Construccin completo y revisado. Completado aproximadamente en un 80%, todos los casos de uso y actores han sido identificados y las descripciones de la mayora de los casos de usos desarrolladas.

Administracin del Proyecto Modelo de Casos Requerimientos de Uso

Tabla 3.3: Artefactos a obtener en la fase de Elaboracin.

Fase de Construccin El propsito 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 anlisis, diseo, desarrollo y pruebas de todas las funcionalidades requeridas. Criterios de Evaluacin

 La versin del producto obtenida es lo suficientemente estable y madura para ser distribuida a la comunidad de usuarios. Artefactos Artefacto El sistema Material de Soporte para Usuarios Finales Plan de Iteracin Disciplina Distribucin Administracin del Proyecto Criterio de Aceptacin La versin beta del producto, listo para probar. Manuales de usuario y otros materiales de entrenamiento debern estar en borrador basado en los casos de uso. Plan de iteracin para la fase de Transicin completo y revisado.

Tabla 3.4: Artefactos a obtener en la fase de Construccin.

Fase de Transicin El propsito de esta fase es asegurar que el software est disponible para los usuarios finales. La fase de Transicin puede llevarse a cabo con varias iteraciones e incluye pruebas del producto para su liberacin final. Objetivos Ingeniera especfica de la distribucin, tales como: empaquetado comercial y produccin. Realizar tareas de afinamiento, tales como: correccin problemas, mejora de rendimiento y utilizacin. Evaluar el producto obtenido contra la visin completa y los criterios de aceptacin del producto. Criterios de Evaluacin El usuario debe estar satisfecho. Los gastos en recursos versus lo planeado deben ser aceptables.

Artefactos Artefacto El producto Material de Soporte para Usuarios Finales Disciplina Distribucin Distribucin Criterio de Aceptacin Debe estar completo de acuerdo a los requerimientos. El producto final debe ser utilizable por los usuarios finales. Materiales que asistan al usuario final en el aprendizaje, operacin y mantenimiento del producto deben estar completos de acuerdo a los requerimientos.

Tabla 3.5: Artefactos a obtener en la fase de Transicin.

CAPITULO 4 RESULTADOS Y DISCUSION

4.- CAPITULO 4: RESULTADOS Y DISCUSION 4.1.- Evaluacin del proyecto. Para evaluar tcnicamente el proyecto se establecieron un conjunto de criterios ponderados, varias alternativas de solucin y calificamos cada una de ellas segn los criterios para obtener la mejor alternativa. En cuanto a la evaluacin econmica realizamos de forma general un anlisis de costos y beneficios, un clculo 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.- Evaluacin tcnica. Por las caractersticas de este proyecto, especficamente que uno de los objetivos es la construccin de un conjunto de libreras de clases, la evaluacin tcnica se orient en el sentido de encontrar una plataforma y un lenguaje de desarrollo para llevar a cabo la construccin de estas libreras. De aqu que se consideraron 4 plataformas con sus lenguajes como alternativas de solucin. Criterios de evaluacin: 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 comercializacin. 2. Masificacin 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 facturacin 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 aceptacin del producto por parte del mercado. 3. Plataforma y lenguaje orientados a objetos y manejo nativo de XML y Web Services. Por los estndares definidos por el SII para el modelo de facturacin electrnica, 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 crtico de xito, permitir reducir los costos de desarrollo y obtener el producto ms rpidamente, lo cual si puede ser fundamental para causar un impacto positivo en el mercado. 5. Manejo de criptografa, certificados digitales, firma digital e implementacin del estndar XMLDSIG de la W3C. Este caso es igual que el nmero 3, el SII defini ciertos estndares para el modelo de facturacin electrnica, entre ellos, el firmado digital de los DTE, para lo cual estableci que se utilizara el estndar XMLDSIG de la W3C. De aqu que es indispensable que la plataforma seleccionada implemente este estndar y aparezca en la lista de soluciones certificadas en la implementacin de este estndar en la W3C. 6. Existencias de libreras para la plataforma y lenguaje que permitan la generacin de cdigos de barras bidimensionales en formato PDF417. Para garantizar la autenticidad de los DTE y la posibilidad de fiscalizacin por parte del SII, se incluy en la versin impresa de los DTE un cdigo de barras bidimensional (PDF417) que contiene informacin del DTE y permite a cualquiera que lea este cdigo, verificar la validez del documento. 7. Posibilidades de soporte para la plataforma y lenguaje a travs de foros de discusin o bibliografa en Internet.

Este no es un factor crtico de xito, pero dado que el proyecto involucra tecnologas muy novedosas, sera beneficioso el contar con foros de discusin por Internet o algn otro tipo de soporte al cual recurrir en caso de algn problema durante el desarrollo del proyecto. 8. Existencia de herramientas CASE para RUP y la plataforma y lenguaje que permitan realizar ingeniera a partir del desarrollo. El no cumplimiento de este criterio no impide la realizacin del proyecto, pero si pudiera reportar beneficios, principalmente en cuanto a reduccin de los tiempos de desarrollo y por ende costos, ya que pudiramos a partir de los diseos realizados utilizando la metodologa RUP, generar bloques de cdigo en forma automtica. Para ponderar los criterios se utilizaron los siguientes valores: Ponderacin 3 2 1 Nivel de Importancia Alta Media Baja

Tabla 4.6: Valores de ponderacin para asignar a los criterios.

Teniendo en cuenta el grado de importancia de cada criterio para cumplir con los objetivos se asign la siguiente ponderacin a cada uno de ellos: N 1 2 3 4 5 6 Criterio de Evaluacin No existencia de un producto similar en el mercado basado en la plataforma y el lenguaje. Masificacin de la plataforma en las empresas chilenas. Plataforma y lenguaje orientados a objetos y manejo nativo de XML y Web Services. Experiencia del equipo de desarrollo en la plataforma y el lenguaje. Manejo de criptografa, certificados digitales, firma digital e implementacin del estndar XMLDSIG de la W3C. Existencias de libreras para la plataforma y lenguaje que Ponderacin 3 3 3 2 3 3

7 8

permitan la generacin de cdigos de barras bidimensionales en formato PDF417. Posibilidades de soporte para la plataforma y lenguaje a travs de foros de discusin o bibliografa en Internet. Existencia de herramientas CASE para RUP y la plataforma y lenguaje que permitan realizar ingeniera a partir del desarrollo.

2 1

Tabla 4.7: Ponderacin 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 calificacin por cada uno de los criterios analizados, las ponderaciones de la calificacin son las que se expresan a continuacin en la siguiente tabla: Ponderacin 3 2 1 0 Descripcin Cumple grado alto Cumple grado medio Cumple grado bajo No cumple

Tabla 4.8: Tipos de calificacin para asignar a las alternativas.

Resultado de la evaluacin La siguiente tabla muestra cules fueron las calificaciones asignadas a cada plataforma para cada criterio y finalmente el resultado que corresponde a la suma del producto de cada calificacin por la ponderacin del criterio.
Criterios de Evaluacin 1 2 3 4 5 6 7 8 Evaluaci n

Alternativa

Plataforma Plataforma Plataforma Plataforma

Microsoft .NET (C#) J2EE (Java) Microsoft COM+ (Visual Basic) Borland (Delphi 7.0)

3 0 3 3

3 2 3 1

3 3 1 2

3 2 3 2

3 3 0 0

3 3 3 0

3 3 3 2

3 3 0 0

60 46 42 26

Tabla 4.9: Resultado de la evaluacin tcnica. Como se puede apreciar en la tabla, segn nuestros criterios, la plataforma Microsoft .NET con el lenguaje de programacin C# es la alternativa ms adecuada para llevar a cabo este proyecto. 4.1.2.- Evaluacin econmica. Anlisis de costos y beneficios de la Factura Electrnica Una encuesta realizada por el Centro de Estudios de Economa Digital de la Cmara de Comercio de Santiago entre 500 empresas de diversos tamaos y sectores en las regiones Metropolitana, Quinta y Octava arroj los siguientes resultados en cuanto a los beneficios y los ahorros de la facturacin electrnica. En cuanto a los principales beneficios de la facturacin electrnica, el 67% de las empresas identifica la agilizacin de los procesos de facturacin y pago, mientras el 54% menciona la simplificacin de la declaracin y pagos de impuestos, el 44% los ahorros en costos operacionales, el 41% la reduccin de errores en el proceso de facturacin y el 36% la disminucin de riesgos de fraude por indebida utilizacin de los documentos tributarios.

Figura 4.16: Principales beneficios de la factura electrnica.

En cuanto al ahorro de costos, las empresas visualizan el mayor potencial en la disminucin de gastos asociados al almacenaje fsico de los documentos en papel (66%), seguido por el trmite del timbraje de documentos en el SII (60%), los costos relacionados al envo y recepcin de facturas (49%), y los costos de emisin y procesamiento de facturas (32%).

Figura 4.17: Principales ahorros de costos de la Factura Electrnica.

La siguiente tabla muestra un resumen de los costos y beneficios asociados al modelo de facturacin electrnica. Beneficios Disminucin de los costos netos de operacin. Simplificacin en el manejo de documentos. Liberacin de espacio fsico de almacenamiento. Mayor confianza en los documentos tributarios. Mejor resguardo de la informacin. Menor tiempo de bsqueda de los documentos. Impresin en papel corriente. Verificacin de documentos tributarios. Evitar el timbraje de documentos en el SII. Costos Servicio de almacenamiento de documentos electrnicos o infraestructura para soportarlo. Conexin a Internet. Adecuacin de los actuales sistemas de facturacin o adquisicin de un software de facturacin electrnica. Adquisicin de Certificados Digitales. Redes computacionales.

Tabla 4.10: Resumen de costos y beneficios.

Los procesos que causarn un mayor impacto financiero en las empresas se describen en la siguiente tabla: El modelo de facturacin electrnica provocar Reduccin de costos en: Aumento de costos en: Impresin. Transporte. Transporte. Recursos humanos. Recursos humanos. Uso de infraestructura computacional Construccin o adquisicin de software de facturacin electrnica. Actualizacin o adquisicin de un software contable.

Proceso Afectado Impresin de documentos tributarios. Timbraje de documentos tributarios. Procesamiento

Despacho fsico

Recursos humanos. Transporte. Servicio de correo. Recursos humanos. Espacio fsico. Infraestructura para bodegaje. Reduccin de tiempo Envo y Recepcin Emitir, recibir, verificar, almacenar, actualizar, integrar y ordenar los documentos tributarios. La utilizacin de los recursos fsicos y tecnolgicos de la empresa Conexin a Internet. Certificados digitales. Infraestructura computacional. Administracin de datos. Sistema de almacenamiento masivo propio o contratado. Aumento de tiempo

Almacenamiento fsico (6 aos)

Transmisin Procesamiento

Tabla 4.11: Procesos que causarn mayor impacto financiero. Estimacin 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 perodo 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 guas, se estiman dos encuentros semanales. Los gastos varios consideran impresiones, tintas, papeles y otros. A continuacin 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 MESES Nov-03 Dic-03 Ene-04

CONCEPTOS Ingresos

Sep-03

Oct-03

Feb-03

Mar-04

Egresos Costo en recurso humano (HH) Conexin Internet Transporte Varios Flujo neto COSTO TOTAL

-$ 400,000 -$ 8,000 $0 -$ 10,000 -$ 418,000 -$ 4,603,920

-$ 400,000 -$ 8,000 $0 -$ 10,000 -$ 418,000

-$ 480,000 -$ 8,000 $0 -$ 10,000 -$ 498,000

-$ 720,000 -$ 8,000 -$ 2,560 -$ 10,000 -$ 740,560

-$ 920,000 -$ 8,000 -$ 5,120 -$ 10,000 -$ 943,120

-$ 910,000 -$ 8,000 -$ 5,120 -$ 10,000 -$ 933,120

-$ 630,000 -$ 8,000 -$ 5,120 -$ 10,000 -$ 653,120

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 comercializacin 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 tendra 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 anlisis, simplemente demuestra que el proyecto es rentable ya que se estara obteniendo un entre un 60% y un 70% de utilidad. En el caso de la segunda alternativa esta es ms compleja de analizar, para lo cual nos creamos un flujo de caja a 7 aos, tomando como ao cero el 2003. El flujo se construy basado en la instalacin de una empresa para comercializar el producto. Este flujo lo actualizamos mediante el clculo 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 pas existen 296,000 contribuyentes activos, la cifra supuesta es de 1400 licencias al cabo de los 7 aos con un crecimiento sostenido de 50 licencias por ao, lo cual representa un 0.47% en el sptimo ao y un crecimiento del 0.017% anual del total de contribuyentes activos. Respecto al precio de la licencia del producto, se decidi entregar las libreras de forma gratuita, las empresas solamente tendran que cancelar 30,000 pesos chilenos anuales por conceptos de actualizacin. Esto se utilizara como estrategia comercial y favorecera la masificacin del producto.

Tambin se ofrecer un servicio de soporte va 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 comercializacin y el soporte del producto, se incluy una inversin en la construccin de un sitio WEB que permita a las empresas informarse acerca de las funcionalidades, la licencia, los precios, tambin descargar el producto y las actualizaciones y solicitar el soporte por esta va. La idea es que este sitio WEB centralice todos los elementos relacionados con la comercializacin y distribucin del producto. Respecto a la publicidad, se decidi construir un brochure de una pgina con toda la informacin del producto, el cual sera enviado por correo electrnico a los departamentos de informtica de las empresas, adems haciendo referencia al sitio WEB para obtener ms informacin. Para desarrollar esta labor y otras tareas administrativas, es que se decidi la contratacin de un recurso por 300,000 pesos mensuales. Los costos operacionales no fueron incluidos hasta el quinto ao, ya que en los primeros aos no se decidi invertir en infraestructura, el sitio WEB estara publicado en un proveedor de WEB hosting y el recurso contratado trabajara desde su casa con sus propios recursos. Para calcular los costos en facturacin se estim un costo por factura de 500 pesos, basndonos en el estudio de factura electrnica de la Cmara 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 ao 2004.

En la siguiente tabla se muestra un resumen de las variables consideradas para calcular el flujo:

VARIABLES Valor de la Licencia Derecho anual para recibir actualizacin de versiones Valor anual paquete soporte via Web (20 eventos) Valor soporte adicional x evento % Emp. que adquieren paquete de soporte % Emp. sin soporte que solicitan soporte adicional Cant eventos adicionales x empresa (promedio) Impuesto a la utilidad Costo Factura Salario recurso operaciones

$0 $ 30,000 $ 10,000 $ 1,000 10% 10% 1 17% 500 $ 300,000

Tabla 4.13: Variables consideradas para calcular el flujo de caja.

Desglose de Costos Operacionales x Mes Oficina $ 140,000 Telfono $ 25,000 Varios $ 50,000 Secretaria $ 200,000 TOTAL MENSUAL $ 415,000 TOTAL ANUAL $ 4,980,000

Tabla 4.14: Costos operacionales incluidos a partir del quinto ao.

FLUJO DE CAJA INVERSIONISTA AO 0 = 2003 CONCEPTOS Ingresos Cant. de Licencias Adquiridas Cant. de Licencias Adquiridas (Acum.) Ingresos por Venta de Licencias Ingresos por servicio de actualizacin Ingresos por servicio de soporte Egresos Mantencin del dominio .cl Arriendo Web Hosting Arriendo Conexin Internet Gastos recursos humanos Gastos en Facturacin Costos Operacionales UTILIDAD ANTES DE IMPUESTO UTILIDAD ANTES DE IMPUESTO ACUM. IMPUESTO UTILIDAD NETA Iniciacin de Actividades Inversin en Desarrollo Producto Inversin en Construccin Web Site Licencia Visual Studio .NET Enterprise Diseo brochure producto FLUJO ANUAL FLUJO ACUMULADO VAN CON TASA 15.00% PERIODOS EN AOS 3 4 150 300 $0 $ 9,000,000 $ 300,000 -$ 20,170 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 150,000 $0 $ 5,222,830 $ 3,493,660 $ 593,922 $ 4,628,908 200 500 $0 $ 15,000,000 $ 500,000 $0 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 250,000 $0 $ 11,343,000 $ 14,836,660 $ 1,928,310 $ 9,414,690

1 50 50 $0 $ 1,500,000 $ 55,000 -$ 20,170 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 25,000 $0 -$ 2,397,170 -$ 2,397,170 $0 -$ 2,397,170

2 100 150 $0 $ 4,500,000 $ 150,000 $0 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 75,000 $0 $ 668,000 -$ 1,729,170 $0 $ 668,000

5 250 750 $0 $ 22,500,000 $ 750,000 -$ 20,170 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 375,000 -$ 4,980,000 $ 13,967,830 $ 28,804,490 $ 2,374,531 $ 11,593,299

6 300 1,050 $0 $ 31,500,000 $ 1,050,000 $0 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 525,000 -$ 4,980,000 $ 23,138,000 $ 51,942,490 $ 3,933,460 $ 19,204,540

7 350 1,400 $0 $ 42,000,000 $ 1,400,000 -$ 20,170 -$ 139,000 -$ 168,000 -$ 3,600,000 -$ 700,000 -$ 4,980,000 $ 33,792,830 $ 85,735,320 $ 5,744,781 $ 28,048,049

-$ 500,000 -$ 4,603,920 -$ 500,000 -$ 1,000,000 -$ 150,000 -$ 6,753,920 -$ 6,753,920 $ 24,704,021

-$ 2,397,170 -$ 9,151,090 15.00%

$ 668,000 -$ 8,483,090

$ 4,628,908 -$ 3,854,182

$ 9,414,690 $ 5,560,508

$ 11,593,299 $ 17,153,807

$ 19,204,540 $ 36,358,347

$ 28,048,049 $ 64,406,396

Tabla 4.15: Flujo de caja para medir la rentabilidad del proyecto.

Anlisis 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 adems 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 ao se estara recuperando la inversin con 5,000,000 de pesos de utilidad neta. Finalmente estamos hablando de un proyecto que podra dejar una utilidad neta de 64,000,000 de pesos al cabo de los siete aos, 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 travs 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 Cmara de Comercio el cual plantea que los 10,000 mayores contribuyentes del pas emiten en promedio 28,800 documentos tributarios anualmente con un costo unitario de 442 pesos, reducindose a 102 pesos con la facturacin electrnica representando un ahorro de un 83%. Estos valores se estiman para el fin de la transicin de la facturacin electrnica, lo cual significa que el modelo se ha implantado satisfactoriamente, est masificado y operando adecuadamente. Se consider que la empresa pagar el derecho de actualizacin del producto anualmente y tambin el paquete de soporte, adems que la inversin para integrar el producto con su sistema de facturacin o construir uno nuevo sera de 15,000,000 de pesos aproximadamente, lo cual representa una cifra considerable.

A continuacin se presenta el grafico que expresa el estudio realizado por la Cmara de Comercio y tambin el flujo de ahorro de costos para la empresa.

Figura 4.18: Estudio sobre costos unitarios de facturacin de la CSS.

FLUJO DE AHORRO DE COSTOS PARA LA EMPRESA PERIODOS EN AOS 3 4 28,800 $ 12,729,600 $ 2,937,600 -$ 30,000 -$ 10,000 $ 9,752,000 $ 14,256,000 28,800 $ 12,729,600 $ 2,937,600 -$ 30,000 -$ 10,000 $ 9,752,000 $ 24,008,000

CONCEPTOS Antes Nmero de DT emitidos Costo facturacin tradicional Despus Costo facturacin electrnica Costo adquisicin de licencia DTE.NET Costo derecho actualizacin DTE.NET Costo paquete de soporte DTE.NET Inversin en integracin o desarrollo FLUJO ANUAL FLUJO ACUMULADO

1 28,800 $ 12,729,600 $ 2,937,600 $0 -$ 30,000 -$ 10,000

2 28,800 $ 12,729,600 $ 2,937,600 -$ 30,000 -$ 10,000 $ 9,752,000 $ 4,504,000

5 28,800 $ 12,729,600 $ 2,937,600 -$ 30,000 -$ 10,000 $ 9,752,000 $ 33,760,000

6 28,800 $ 12,729,600 $ 2,937,600 -$ 30,000 -$ 10,000 $ 9,752,000 $ 43,512,000

7 28,800 $ 12,729,600 $ 2,937,600 -$ 30,000 -$ 10,000 $ 9,752,000 $ 53,264,000

-$ 15,000,000 -$ 15,000,000 -$ 15,000,000

$ 9,752,000 -$ 5,248,000

Tabla 4.16: Flujo de ahorro de costos para la empresa.

VARIABLES CONSIDERADAS Nmero de DT emitidos anualmente Nmero de DT emitidos mensualmente Costo Facturacin Tradicional Costo Facturacin Electrnica

28,800 2,400 442 102

Tabla 4.17: Variables consideradas en el flujo de ahorro de costos.

Anlisis de los resultados: Si observamos el flujo neto actual podemos apreciar que la empresa tendra ahorros de aproximadamente 10,000,000 de pesos anuales, adems en el segundo ao estara recuperando la inversin 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 deberamos resumir dos aspectos: Tcnicamente el estudio realizado demuestra que el proyecto es factible de llevar a cabo. Econmicamente el estudio presentado demuestra que el proyecto es rentable tanto para el inversionista como para una empresa que adquiera el producto.