UNIVERSIDAD DE CHILEFACULTAD DE CIENCIAS FISICAS Y MATEM ATICAS

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACI ON

DISE NO E IMPLEMENTACI ON DE UN NUEVO SISTEMA DE FACTURACI ON PARA NICCHILE

JOS E ANDR ES URZ UA REINOSO

COMISI ON EXAMINADORA CALIFICACIONES:NOTA (n

) (Letras) FIRMA

PROFESOR GUIADR. JOS E MIGUEL PIQUER :

PROFESOR CO-GUIA :DR. PATRICIO POBLETE

PROFESOR INTEGRANTE :SR. GABRIEL IRIBARREN

NOTA FINAL EXAMEN DE TITULO :

MEMORIA PARA OPTAR AL TITULO DEINGENIERO CIVIL EN COMPUTACI ON

SANTIAGO DE CHILEENERO DEL 2003

RESUMEN DE LA MEMORIAPARA OPTAR AL TITULO DEINGENIERO CIVIL EN COMPUTACI ONPOR: JOS E URZ UA REINOSOFECHA: 20/01/2003PROF. GUIA: Sr. JOS E MIGUEL PIQUER

DISE NO E IMPLEMENTACI ON DE UN NUEVO SISTEMA DE FACTURACI ON PARA NICCHILE

Para emitir facturas por las operaciones comerciales como inscripcion y renovacion de domin-ios, NIC Chile posee un software desarrollado internamente, el cual presenta limitaciones que sehacen notorias al aumentar este numero de operaciones. Por otra parte, el creciente uso de la tec-nologa y la necesidad de optimizar y facilitar las operaciones comerciales entre las empresas, hallevado al Servicio de Impuestos Internos (SII) a propiciar un modelo de facturacion electronica,en donde NIC Chile forma parte del Programa Piloto del SII.

Esta memoria, describe el diseno e implementacion de un nuevo sistema de facturacion paraNIC Chile, el cual debe realizar tanto facturacion de forma manual como electronica. Este trabajoincluye un manual de usuario y detalladas descripciones de las herramientas utilizadas para eldesarrollo.

El desarrollo del sistema se realizo utilizando el lenguaje Java, con un marco de trabajo denom-inado Struts, lo que permitio obtener un sistema modularizado y de buen desempeno, que cumplelos requerimientos y diseno especicados en este documento.

La operacion con facturas electronicas entrega grandes ventajas a una empresa como NIC Chile,en donde todo el proceso del producto que se vende es digital (desde la inscripcion hasta las elim-inaciones de dominios) y solo se incorporan papeles en el momento de entregar un comprobantepor un pago recibido. Dentro de las ventajas se tiene el ahorro estimado de $486 pesos (estimaciondada por el SII), por conceptos de papel, copias, envo de correspondencia, etc. Ademas, se debeconsiderar el ahorro en el tiempo, que para el caso de NIC Chile de un proceso de varias horas sepasa a alrededor de 5 minutos en generar las facturas de un da promedio.

El sistema desarrollado, cumple con un diseno estandar y aplicable a nuevos documentos tribu-tarios electronicos (DTEs), pensando en la incorporacion de toda la Universidad de Chile al modelode operacion con DTEs.

Agradecimientos

En primer lugar quisiera agradecer a mis padres y hermanos por entregarme sus valores, edu-cacion e incondicional apoyo en mis actividades. A mi pareja Paola, por su carino, preocupacion ydedicacion en todo momento.

Tambien quiero entregar mis agradecimientos a NIC Chile, institucion que me entrega la posi-bilidad de desarrollarme laboralmente. Especialmente a don Edgardo Krell y al grupo de Desarrol-lo.

Indice general

1. Introduccion 1

1.1. Antecedentes Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Justicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.2. Especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Antecedentes 7

2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Modelo Actual de Facturacion en NIC Chile . . . . . . . . . . . . . . . . . . . . . 8

I

2.3. Documentos Tributarios Electronicos . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. Enrolamiento en el Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2. Autorizacion de un rango de folios . . . . . . . . . . . . . . . . . . . . . . 11

2.3.3. Generacion de DTEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.4. Recepcion de DTEs por los contribuyentes . . . . . . . . . . . . . . . . . 14

2.3.5. Recepcion de un DTE por el SII . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.6. Consolidacion de un DTE . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.7. Fiscalizacion en Terreno . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.8. Anulacion de un DTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Struts Framework 18

3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1. Historia de Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2. Patron de Diseno MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.3. Introduccion al Marco de Trabajo de Struts . . . . . . . . . . . . . . . . . 20

3.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

II

3.2.1. JavaBeans y el Ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2. Beans ActionForm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.3. Beans de Estado del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.4. Beans de la Logica del Negocio . . . . . . . . . . . . . . . . . . . . . . . 25

3.3. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1. Internacionalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2. Interacciones de Forms y FormBean . . . . . . . . . . . . . . . . . . . . . 27

3.4. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.1. Clases Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.2. La Implementacion de ActionMapping . . . . . . . . . . . . . . . . . . . 30

3.4.3. Descriptor de Despliegue de la Aplicacion Web . . . . . . . . . . . . . . . 30

3.4.4. Congurar el Mapeo del Servlet Action . . . . . . . . . . . . . . . . . . . 31

3.4.5. Congurar la Librera de Etiquetas de Struts . . . . . . . . . . . . . . . . . 32

4. Requerimientos 33

4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

III

4.2. Requerimientos de Interfaces Externas . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1. Interfaces de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2. Interfaces de Comunicacion . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3. Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1. Requerimientos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . 37

4.4. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.2. Diagramas de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.3. Caso de Uso: Imprimir Facturas . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.4. Caso de Uso: Asociar Numero . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.5. Caso de Uso: Enviar Facturas . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.6. Caso de Uso: Crear Factura . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.7. Caso de Uso: Emitir DTE . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.8. Caso de Uso: Editar Facturas . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.9. Caso de Uso: Ver Informes . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.10. Caso de Uso: Congurar Sistema . . . . . . . . . . . . . . . . . . . . . . 48

IV

4.4.11. Caso de Uso: Administracion de Usuarios . . . . . . . . . . . . . . . . . . 49

5. Dise no 50

5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2. Plataformas de Hardware y Software . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3. Bases de Datos Denidas Externamente . . . . . . . . . . . . . . . . . . . . . . . 52

5.4. Descripcion de Interfaces Externas . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.5. Decisiones Previas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6. Diseno del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.6.1. Diagrama de Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.6.2. Diagrama de Flujo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.6.3. Diagramas de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.6.4. Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6. Implementacion 67

6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

V

6.3. Archivos Utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.4. Funcionamiento del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.4.1. Medicion de Obtener Facturas . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4.2. Medicion de Imprimir Facturas . . . . . . . . . . . . . . . . . . . . . . . 74

6.4.3. Medicion de Asociar Numero . . . . . . . . . . . . . . . . . . . . . . . . 76

6.4.4. Medicion de Envo de Facturas . . . . . . . . . . . . . . . . . . . . . . . . 78

6.4.5. Medicion de Generacion de Facturas Electronicas . . . . . . . . . . . . . . 78

7. Conclusiones 81

7.1. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8. Anexos 84

8.1. Deniciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.2. Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.3. Manual de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.3.2. Acerca del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

VI

8.3.3. Funciones Basicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.3.4. Funciones de Administracion . . . . . . . . . . . . . . . . . . . . . . . . 92

8.3.5. Solucion de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.4. Diagramas de Flujo de Nivel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

8.5. Codigo Fuente de Algunas Funciones . . . . . . . . . . . . . . . . . . . . . . . . 107

8.5.1. Archivos de Internacionalizacion de Struts . . . . . . . . . . . . . . . . . 107

8.5.2. Archivo de Conguracion de los Mapeos de Action . . . . . . . . . . . . . 109

8.5.3. Descriptor de Despliegue de la Aplicacion Web . . . . . . . . . . . . . . . 123

8.5.4. Denicion detalla del Modelo de Datos . . . . . . . . . . . . . . . . . . . 125

VII

Captulo 1

Introduccion

1.1. Antecedentes Generales

El buen funcionamiento y masicacion que ha logrado Internet, se debe en gran parte a la exis-tencia de los nombres de dominios. Por medio de estos, se puede acceder a distintos computadores,en cualquier lugar del mundo con solo acordarse de su nombre. Por ejemplo, para acceder a lasnoticias de la cadena CNN en Internet, solo basta con acordarse del nombre de dominio que ellosmanejan: www.cnn.com, en vez de tener que recordar la direccion IP del computador quemantiene los contenidos noticiosos, que podra ser: 64.236.24.20.

Los nombres de dominios estan clasicados por sujos. As existen los sujos para pases,conocidos como ccTLD (Country Codes Top Level Domain), como por ejemplo: .CL para Chile,.AR para Argentina, .UK para Reino Unido, .FR para Francia, y sujos genericos, conocidos comogTLD (Generic Top Level Domain) como por ejemplo: .COM relativos a dominios comerciales,.NET para identicar nombres relativos a redes, .MIL para organizaciones militares, .EDU paraorganizaciones educacionales; a los que ultimamente se han agregado los .INFO, .BIZ y .AERO.

Para que las personas puedan acceder y crear sus nombres de dominios bajo algun TLD, esnecesario que exista alguna organizacion encargada de la Administracion de ese sujo. La entidad

1

coordinadora de los Administradores de registro a nivel internacional es ICANN, la cual delegala funcion de administrar los ccTLD en entidades generalmente conocidas como NIC (NetworkInformation Center), habitualmente una entidad por pas.

NIC Chile es actualmente un proyecto del Departamento de Ciencias de la Computacion de laUniversidad de Chile, que se encarga de la administracion del TLD correspondiente a la Republicade Chile, llamado .CL (punto CL), tarea delegada por IANA (posteriormente ICANN absorbio lasfunciones de IANA) desde el ano 1987. La administracion, consiste en publicar en Internet de man-era correcta, la asociacion de un nombre de dominio bajo .CL con la(s) direccion(es) IP correspon-diente(s), por medio de un funcionamiento continuo del servicio de DNS. Ademas, NIC Chile deberecibir solicitudes de creacion por nuevos dominios, evitando que mas de una persona natural ojurdica tenga el mismo nombre.

Para las tareas que debe cumplir NIC Chile en la administracion del TLD .CL, se cuenta condiversos sistemas desarrollados internamente. Dadas las necesidades de nuevas funcionalidades, secomenzo un perodo de completa renovacion de este software, dentro de los cuales esta el sistemade facturacion.

En Chile, tanto las solicitudes de inscripcion como la renovacion de los dominios inscritos sonprocesos que involucran una operacion comercial, la cual debe ser respaldada con su correspon-diente documento tributario, en este caso una Factura. Este documento da cuenta de la posesion yel pago por un contrato entre dos partes.1 En el caso de NIC Chile, es el servicio de DNS para eldominio solicitado, por un perodo de 2 anos.

Para generar las facturas por las operaciones comerciales que se realizan en NIC Chile, existe unsoftware desarrollado de forma interna que cumple con la tarea de agrupar, imprimir y asociar lasfacturas a los dominios y titulares correspondientes, segun la legislacion vigente.2 Con el aumentode las inscripciones y renovaciones de dominios, aumenta el volumen de dominios a facturar, antelo cual se hacen mas notorias las limitaciones del software existente, las que son analizadas en lasiguiente seccion de este captulo.

El creciente uso de la tecnologa en las operaciones comerciales y la necesidad de optimizar yfacilitar las operaciones entre las empresas ha llevado al SII a propiciar un modelo de operacion conDocumentos Tributarios Electronicos(DTE), que utilice Internet como canal de comunicacion[2].

1Definicion del Sub Director de Informatica del SII, Fernando Barraza.2Permite facturar solo operaciones comerciales relativas a dominios

2

NIC Chile esta participando dentro de un programa piloto del SII, en conjunto con varias otrasempresas, para generar Facturas Electronicas.

Las limitaciones del sistema actual de facturacion de NIC Chile, la participacion en el Piloto deemision de DTEs del SII y el comienzo del desarrollo de una nueva version del software interno deNIC Chile, dan paso a la presente memoria, en la cual se muestra el Diseno e Implementacion deun nuevo Sistema de Facturacion para NIC Chile.

1.2. Justificacion

El actual sistema de facturacion, construido en su mayora con interfaz web, posee ciertas lim-itaciones, que en conjunto con el aumento de la cantidad de facturas que se deben emitir3, hangenerado la necesidad de disenar e implementar un nuevo Sistema de Facturacion.

El actual sistema esta dividido en tres partes. Por un lado, esta el sistema mismo de impresiony envos de facturas, por otro lado estan los reportes que se le deben enviar a la Universidad deChile por medio del sistema llamado Informat, y tambien se tiene por separado un sistema deestadsticas de facturacion de dominios. Esta separacion de funcionalidades genera inconsistenciastales como estadsticas no actualizadas, reportes con errores para Informat, dicultades para recon-struir facturas, etc. Estas inconsistencias no se produciran si existiese un sistema en que estuviesetodo integrado.

Agregar alguna nueva funcionalidad al actual sistema es una tarea bastante complicada, por noexistir una conguracion centralizada ni modulos con funcionalidades claras. Ademas, si se agregaque no existe unicidad en el lenguaje ni en la plataforma de desarrollo, aumentan las dicultadesde mantencion y escalabilidad del sistema. El software actual esta mayoritariamente escrito enel lenguaje Perl pero tambien posee un modulo escrito en el lenguaje Java. Por otra parte, lamayora de las aplicaciones estan hechas en plataforma web, pero la aplicacion dedicada a imprimirlas facturas (la que esta escrita en Java) es un software independiente que se debe instalar en cadacomputador en donde se quiera usar, debiendose congurar cada uno de ellos de forma individual.

3En la actualidad se facturan alrededor de 4000 dominios mensuales.

3

Cuando el operador del actual Sistema de Facturacion comete algun error o no sigue estricta-mente una secuencia de pasos durante el proceso, se generan inconsistencias en los datos, generan-do anulaciones de facturas y la repeticion del proceso desde el inicio. La reparacion de las inconsis-tencias generadas no es una funcionalidad al alcance de los operadores del Sistema de Facturacion,ante lo que deben recurrir a personas externas a su area para solucionar la inconsistencia y poderseguir procesando, por lo que se genera una inconveniente dependencia de estas personas.

La forma de operar del actual sistema no maneja de una manera correcta los clientes. Por ejem-plo, para el caso de que se deben emitir varias facturas para un mismo RUT pero con distintadireccion, el sistema actual genera una sola factura que tiene como direccion de envo la del primertem de la factura, generando los correspondientes reclamos de los clientes a los cuales nunca lesllega la factura y de otros que reciben en sus facturas temes que ellos no cancelaron, situacioncomun para el caso de empresas clientes con muchas sucursales.

En el ano 1997 el Servicio de Impuestos Internos, comenzo a analizar el tema de Documen-tos Tributarios Electronicos (DTE). Este tema atrajo a NIC Chile, por lo cual forma parte de lasempresas que participan en el programa Piloto de emision de DTEs, en particular la emision deFacturas Electronicas. Dada esta situacion y considerando las limitaciones antes mencionadas, re-sulta sumamente conveniente comenzar con el desarrollo de un nuevo Sistema de Facturacion quepermita realizar tanto facturacion manual como facturacion electronica.

Por otra parte, debido a la creciente demanda de los servicios de NIC Chile, como la necesidadde incorporar nuevas funcionalidades se comenzo un proyecto de renovacion de todo el softwareque usa el sistema, de modo que el desarrollo de un nuevo sistema de Facturacion se enmarca dentrode la planicacion general de sistema de NIC Chile.

1.3. Objetivos

1.3.1. Generales

Crear un nuevo sistema de facturacion para NIC Chile, mejorando la arquitectura, fun-cionamiento y alcances del actual sistema, as como integrar las funcionalidades actuales con la

4

implementacion de nuevos requerimientos.

1.3.2. Especficos

Los objetivos que se deben lograr con el nuevo sistema de facturacion son los siguientes:

Un sistema Integrado, en el cual se abarquen todos las funcionalidades requeridas en elcaptulo 4.

Unicidad de plataforma y lenguaje de programacion.Un sistema Modular, en donde se especique que modulos se encargan de que tareas con lacorrespondiente documentacion.

Flexibilidad de manipulacion para los operadores, entregarles las herramientas necesariaspara corregir errores y deshacer operaciones.

Permitir facturacion tanto de forma electronica como manual.

Un sistema escalable, en el cual se puedan agregar nuevas funcionalidades.

Facilidad de uso.

1.4. Alcances

Este trabajo contempla el diseno completo e implementacion del Sistema de Facturacion, evi-tando caer en las limitaciones identicadas en el sistema actual y agregando las funcionalidadesespecicadas en los objetivos y en el captulo 4.

La implementacion abarca todo el sistema disenado, integrando las funcionalidades ya hechaspara generar DTE y las modicaciones necesarias de acuerdo a los ultimos requerimientos del SII.Cabe mencionar que NIC Chile ya tiene un sistema que solo genera factura electronica, sistema

5

que el autor de esta memoria integro al trabajo desarrollado. Este trabajo, incluyo actualizaciones alas implementaciones ya hechas para generar facturas electronicas, de acuerdo a las modicacionesenviadas por el SII. Ademas, se complemento el trabajo con la generacion de los archivos conformato PDF para que los receptores no-electronicos pudiesen imprimir las facturas.

Tambien se abarca en este trabajo el estudio de una nueva herramienta de desarrollo de sistemasen plataforma web, llamada Struts, que es descrita en el captulo 3.

Cabe hacer notar que en esta memoria no se abarcan los temas de polticas de reportes comoenvos de facturas entre NIC Chile y la Facultad de Ciencias Fsicas y Matematicas, para el sistemaInformat.

6

Captulo 2

Antecedentes

2.1. Introduccion

Este captulo se referira a los antecedentes recopilados de la operacion del actual Sistema deFacturacion de NIC Chile. Ademas, se mostrara un resumen de la operacion con DocumentosTributarios Electronicos, denidas desde el SII; esta operacion se incluye con el objetivo de que ellector conozca el medio ambiente bajo el cual se desempenara el sistema, que debe integrarse conla emision de Documentos Tributarios Electronicos.

Si el lector desea tener mayores antecedentes sobre la emision de los DTEs, el como se llego almodelo y el uso de la criptografa, puede encontrar una informacion mas detallada en la segundareferencia bibliograca de esta memoria.

7

2.2. Modelo Actual de Facturacion en NIC Chile

El proceso actual de facturacion para los dominios comienza desde que NIC Chile recibe re-portes de pagos desde Servipag y Web Pay, que son los mecanismos de recaudacion utilizados.Estos reportes son procesados en forma automatica generando registros en la Base Datos de Pa-gos denominada ToDo. El actual sistema esta restringido solo a generar facturas por pagos dedominios, funcionando de la siguiente forma:

1. El operador ingresa al sistema de facturacion.

2. El sistema recopila y despliega una lista de todos los dominios pagados, para los cuales no seha impreso una factura.

3. El operador pide al sistema que agrupe el pago de todos aquellos dominios que registren elmismo RUT y el mismo tipo de pago1.

4. El sistema despliega un listado de dominios, que cumplen con el requerimiento anterior.

5. El operador imprime las facturas del listado anterior, proceso conocido como Facturar porRut.

6. El operador asocia las facturas impresas con los respectivos numeros de serie que vienenpreimpresos en el papel de las facturas.

7. Para cada una de las facturas impresas anteriormente, el operador imprime una nomina conel detalle de los dominios y numeros de proceso includos en la factura.

8. El operador imprime facturas no agrupadas, que son aquellas facturas que contienen solo undominio cancelado por RUT.

9. El operador asocia las facturas impresas con los respectivos numeros de serie que vienenpreimpresos en el papel (ahora para las facturas no agrupadas).

10. El operador separa las distintas copias que componen una factura, dejando dos copias para elcliente, las que corchetea y prepara para el envo por correo.

11. El operador imprime dos copias de un listado que contiene un resumen de todas las facturasimpresas.

1Webpay o Servipag.

8

12. El operador entrega las facturas impresas al correo, anexando una copia del listado impresoen el paso anterior.

13. El operador enva un email a la empresa de correo con el detalle de todas las facturas proce-sadas durante el da.

Cabe mencionar que el papel de una factura en blanco (sin imprimir) posee 5 copias, y poseeun numero de serie impreso. De las 5 copias preimpresas, 2 son enviadas al cliente por correo, 2son usadas para el sistema de contabilidad (copias de color azul y cafe) y una es almacenada comorespaldo por el area de facturacion (copia de color verde).

El sistema de facturacion genera listados de facturas que son enviados al sistema Informat. Elenvo de los listados de facturas deben seguir la siguiente secuencia, establecida desde el area decontabilidad de la Facultad de Ciencias Fsicas y Matematicas:

Envo de grupos de 40 facturas a Informat: Se envan de forma digital listados de 40 facturas(que ya fueron impresas), por medio de un sistema FTP desarrollado por Informat. Al mismotiempo, se debe enviar de forma manual el listado de las copias de color cafe en grupos de 40facturas. Este envo manual es realizado por medio de una persona que se dirige fsicamente,desde NIC Chile a la Facultad de Ciencias Fsicas y Matematicas.

Reconocimiento de Informat: Desde Informat se revisan los grupos de facturas enviados tantoen forma digital como en forma manual y dan la autorizacion para el ingreso de las copiasazules de las facturas.

Envo de grupos de 30 facturas: De las facturas que autorizo Informat, se envan en gruposde 30 las copias azules, separadas por medio de pago. El envo se hace en forma digital y enforma manual. Estos grupos estan identicados por un numero de folio, que es para el controlinterno entre NIC Chile y la Facultad de Ciencias Fsicas y Matematicas.

Validacion de Ingreso: Una vez que Informat recepciona el ingreso, tanto fsico como manual,genera una validacion para el numero de folio y un aviso de recepcion del dinero.

Un diagrama del proceso actual de facturacion, que no incluye la interaccion con Informat, esel de la gura 2.1.

9

TODO

Servipag WebPay

proc_servipag webpay_paga

Facturarpor RUT

Nminapor RUT

Imprimir(Java)

Emitir

EnviarNmina

EnviarMail

Operario

1

234

5 6

Figura 2.1: Diagrama Sistema Actual de Facturacion.

2.3. Documentos Tributarios Electronicos

El estudio de las deniciones y modelo de operacion de los DTE comenzo en el ano 1997, porparte del SII, poniendose en marcha el plan Piloto a mediados del ano 2002, en el cual participanalrededor de 7 empresas de distintos rubros.

El modelo de operacion de los DTE, incorpora metodos que permiten vericar la veracidad eintegridad de los documentos emitidos, de la misma forma incorpora metodos para la scalizaciondel SII sobre las operaciones comerciales que estos respaldan. Ademas, incluye un medio de autor-izacion de folios, que cumple la misma funcion scalizadora del timbre de cuno, en la operacioncon documentos tributarios en papel.

Los DTE son transmitidos por medios de comunicacion electronicos entre los agentes partici-

10

pantes: emisor, receptor y SII. Una vez emitidos los DTE pueden ser impresos en papel corrienteen impresoras de libre acceso en el mercado. Esta version impresa incluye un codigo de barras de2 dimensiones, por medio del cual se verica la validez del DTE.

El modelo de operacion con DTEs abarca 7 etapas, las que son explicadas en las siguientessubsecciones.

2.3.1. Enrolamiento en el Sistema

Es la etapa en donde el contribuyente se inscribe en el SII como emisor de DTEs. Al enrolarseen el sistema, NIC Chile debe identicar los funcionarios de NIC Chile que estaran autorizadospara emitir DTEs, los cuales deben poseer certicados digitales validos a la fecha, emitidos poralguna autoridad certicadora autorizada por el SII.

Estas personas son las unicas autorizadas para solicitar folios para el contribuyente, y puedenser distintas a quienes generan las facturas.

2.3.2. Autorizacion de un rango de folios

Los contribuyentes solicitan al SII un rango de folios para emitir DTEs con folio en ese rango.En la actualidad, esto se realiza mediante el timbre de cuno que el contribuyente esta obligadoa aplicar sobre sus documentos en papel, antes de utilizarlos. Para aplicar este timbre, el con-tribuyente debe acudir a la Unidad del SII que corresponde a su domicilio, llevando los documentosque desea timbrar con los numeros de folios preimpresos.

En el modelo de operacion con DTEs del SII, el contribuyente solicitara va Web las autoriza-ciones de folios para un tipo de Documento2, evitando el concurrir a las dependencias del SII. Enreemplazo del timbre de cuno, el contribuyente recibira va electronica un codigo de autorizacionpara emitir los DTEs.

2Facturas para el piloto

11

La solicitud de un rango de folios comienza cuando la(s) persona(s) autorizada(s) se auten-tican en el sitio web del SII, usando su certicado digital. El SII vericara la validez de losdatos y del certicado en sus registros. Luego el SII entregara al solicitante el rango de folios quesegun sus polticas internas autorizo, armando un conjunto de datos segun lo especicado en eldocumento Especicacion de Codigos de Autorizacion y de Timbres de Documentos TributariosElectronicos[2], el cual contiene la siguiente informacion:

Version del codigo que generara el SII.

RUT del contribuyente.

Tipo de DTE.

Rango de Folio.

Fecha de Autorizacion.

Llave publica del contribuyente.

Con este codigo de autorizacion, el contribuyente podra timbrar DTEs para el folio autorizado,utilizando ese codigo de autorizacion y el certicado digital con el cual se solicitaron los codigos.Cuando el contribuyente necesite mas folios, debera repetir el proceso.

2.3.3. Generacion de DTEs

Un DTE es un documento XML con el formato denido en el documento Formato de Docu-mentos Tributarios Electronicos[2], el cual debe contener los valores equivalentes a los contenidosen un documento tributario tradicional en papel.

Ademas de la informacion habitual de un documento tributario (RUT de emisor, fecha deemision, direccion del emisor, RUT del receptor, razon social del receptor, direccion del recep-tor, modo de pago, lneas de detalle y otros), el emisor debe generar un Timbre electronico unicopara cada DTE. El timbre esta compuesto por 3 elementos:

12

1. Datos Representativos: Corresponden a la Version del timbre que generara el emisor, RUTdel emisor, el tipo del DTE, el numero de Folio, fecha de emision del DTE y el monto totaldel DTE.

2. Firma Digital sobre los datos representativos: Usando el certicado que el contribuyenteindico que utilizara para generar DTEs (cuando solicito la autorizacion del rango de folio alcual pertenece el DTE a emitir segun su tipo y numero de folio asignado), el emisor procedea rmar digitalmente los datos representativos del DTE.

3. Codigo de Autorizacion: Corresponde al que entrego el SII con el rango de folios autorizados.

El contribuyente debe incluir este Timbre representado segun lo dene el documento Especi-cacion de Codigos de Autorizacion y de Timbres de Documentos Tributarios Electronicos[2] en eldocumento XML, que constituye el DTE segun lo dene el documento Formato de DocumentosTributarios Electronicos[2].

Finalmente, el contribuyente debe rmar digitalmente el documento completo XML que con-stituye el DTE segun lo dene el documento Firma Digital de Documentos XML relativos a laoperacion con Documentos Tributarios Electronicos[2], utilizando el certicado digital que sehaya denido para ese n.

Junto con enviar el DTE generado al receptor, el contribuyente debera enviar una copia al SII.

Cualquier DTE generado debe poder ser impreso utilizando papel corriente e impresoras delibre acceso en el mercado. Esta version impresa, esta orientada principalmente a los receptores noelectronicos y a los documentos que deben acompanar mercadera como las Guas de Despacho.

Antes de imprimir un DTE, este debe ser generado como se menciono anteriormente, luego sedeben:

Imprimir en un papel sus valores en el orden y formato denidos en el documento Normativade Impresion en Papel de Documentos Tributarios Electronicos[2].El timbre del documento se imprime como un codigo de barras bidimensional con simbologaPDF417.

13

Un ejemplo de un DTE impreso es el que se muestra en la gura 2.2.

2.3.4. Recepcion de DTEs por los contribuyentes

Se debe distinguir entre el receptor electronico, es decir, el que a su vez tambien es un emisor deDTEs; y el receptor manual, el cual opera con la forma tradicional con los documentos tributariosen papel. Este ultimo, recibira una version impresa del DTE o lo imprimira el mismo.

El receptor electronico debera vericar la validez y vigencia del certicado digital que se uti-lizo para rmar el archivo XML de cada DTE que reciba. Ademas, de vericar que ese certicadoesta habilitado para rmar DTEs en nombre del emisor. La validez de la rma digital del DTE, per-mite al contribuyente receptor estar seguro de que el DTE fue emitido efectivamente por el duenodel certicado digital y ademas le permite probar la irrefutabilidad (no repudiacion) del DTE, esdecir, el emisor no podra renegar la autora del DTE.

Luego, el receptor electronico debera vericar la correctitud de los datos del Timbre del DTE.Para esto debe comprobar inicialmente que los datos representativos del DTE sean los mismos quecontiene el Timbre, que el RUT del emisor y tipo de DTE sean los mismos que los contenidos en elcodigo de autorizacion contenido en el timbre, y que el numero de folio este dentro del rango queautoriza el mismo codigo.

Por ultimo, el receptor debe vericar que los datos del DTE, indiquen que esta destinado a suRUT y Razon Social.

Si alguna de estas validaciones fallasen, el receptor podra rechazar el DTE sin hacer registrocontable de el. En caso que las validaciones sean correctas, pero se encuentre alguna discrepanciacuando se veriquen las condiciones comerciales, se operara de la misma forma tradicional de losdocumentos tributarios sustentados en papel, corrigiendo la situacion va la correspondiente notade credito o de debito.

El receptor no electronico solo recibe el DTE en su version impresa y solo puede vericarsi un numero de folio ha sido autorizado o no por el SII. Para esto, el SII habilitara un sistemade vericacion va Internet y telefonica de documentos, en la que el receptor debera indicar el

14

Figura 2.2: Ejemplo de un DTE impreso.

15

RUT del emisor, el tipo de documento y el numero de folio, a lo que el SII respondera si el folioesta autorizado, no autorizado o desautorizado.

2.3.5. Recepcion de un DTE por el SII

Para la emision de DTEs, los emisores deben enviar una copia de cada DTE emitido al SII.Al ser recibido en el SII, se seguira el mismo procedimiento de vericacion de la rma digital deldocumento XML y del timbre. Es decir, el SII actua como un receptor electronico adicional. Losdocumentos que no veriquen el timbre o la rma digital, seran rechazados por el SII y, por lotanto, no tendran derecho a credito scal.

2.3.6. Consolidacion de un DTE

Si la copia que enva el emisor al SII es aceptada, el receptor podra cobrar el credito del DTE.Para estar seguro que un DTE recibido esta presente en el SII, y que el DTE presente en el SII es lacopia el del DTE que el receptor posee, el receptor debe consolidar el documento.

En el proceso de consolidacion el receptor consulta al SII por el RUT del emisor, el tipo y elnumero de folio de un DTE. SII respondera si ha recibido y aceptado una emision de ese folio paraese RUT emisor, en caso de ser verdadero, entregara el valor de la rma digital.

El receptor electronico comparara la rma digital entregada por el SII contra la rma digitaldel DTE, en caso de ser equivalentes, el receptor puede estar seguro de que el DTE que posee es lacopia el del DTE entregado al SII y por lo tanto podra recuperar el credito.

Para un receptor manual, el SII habilitara un servicio de consulta va Internet y telefonica dondeel receptor debera indicar el RUT del emisor, el tipo y numero de folio del DTE, a lo que el SIIcontestara si estos valores corresponden a la copia del DTE presente en sus bases de datos.

16

2.3.7. Fiscalizacion en Terreno

Para la scalizacion en terreno los inspectores del SII estaran en posesion de un computador debolsillo y un lector de codigos de barras.

Cuando se traslade mercadera, debe ir acompanada de la version impresa del DTE que lavalida. El inspector hara uso del lector de codigos de barras para obtener el valor del timbre y delcomputador de bolsillo para vericar el timbre.

Por otro lado, el SII podra requerir el envo va Internet del archivo de auditora del con-tribuyente, para scalizacion remota.

2.3.8. Anulacion de un DTE

Si se genera una factura que tiene errores que ameritan que no deba ser enviada al receptor, sedebe generar una nota de credito para corregir la situacion, la cual debera estar claramente indicadacomo Anulacion e indicar el monto neto e impuestos identicos a los de la factura original.

La nueva factura emitida debe tener como referencia a la factura anterior y la nota de creditoemitida para la anulacion. Este procedimiento es obligatorio en el caso de que el RUT del receptorsea erroneo, no pudiendo en este caso utilizarse el metodo de correccion establecido en el ocionumero 105 de 1990 (referido a la correccion de campos como RUT, nombre y giro). Si el errorse produce en una nota de credito, se debera emitir una nota de debito tambien con la marca deanulacion, haciendo referencia a ambos documentos: la factura original y la nota de credito.

Si el error se produce en una nota de debito, se debera emitir una nota de credito tambien conla marca de anulacion, haciendo referencia a ambos documentos: la factura original y la nota dedebito.

En caso que el documento ya haya sido enviado al receptor y se detecte un error en el, tambiense debera enviar al receptor el documento corrector que corresponda.

17

Captulo 3

Struts Framework

3.1. Introduccion

Cada vez es mas necesario dentro del diseno y desarrollo de aplicaciones Web el denir como semanejara el ujo de la informacion dentro de la aplicacion, para lo cual existen diversos Frameworken diversos lenguajes. Esta memoria esta basada en el Framework Struts, del proyecto Jakartade Apache, la cual funciona en un medio ambiente con lenguaje Java. En este captulo, se muestradesde la historia hasta ejemplos de archivos de conguracion e implementacion de un sistemadesarrollado con Struts informacion obtenida principalmente del sitio web de Apache [8] y de unmanual realizado por Juan Antonio Palos [12].

Para entender a cabalidad los temas expuestos en este captulo es necesario que el lector ten-ga conocimientos previos de Java Servlets, JavaServer Pages y JavaBeans. En caso contrario serecomienda revisar la bibliografa indicada en esta memoria, correspondiente a estos temas.

18

3.1.1. Historia de Struts

Cuando se inventaron los Servlets de Java para el desarrollo de aplicaciones Web, se obtuvouna herramienta mas rapida y potente que el CGI estandar. Los servlets eran portables, y extensi-bles. El problema de los Servlets es que para enviar una lnea de codigo HTML al navegador eranecesario ejecutar una instruccion, situacion que se complicaba cuando el resultado de la ejecu-cion del Servlet son muchas lneas de HTML. La solucion a este problema fue la aparicion de lasJavaServer Pages (JSP en adelante), que permitan escribir Servlets dentro de ellas, as se podamezclar codigo HTML con Java, manteniendo todas las ventajas de los Servlets.

As las aplicaciones web desarrolladas en Java se convirtieron rapidamente en aplicacionescentralizadas en JSP (conocido como el Modelo 1), lo que no era malo en si mismo, pero noresolva el problema del control de ujo y otros, dentro de las aplicaciones web, dejando en clarola necesidad de otro modelo.

Cuando los desarrolladores web se dieron cuenta de que los JSP y los Servlets se podan usarjuntos, con los JSP encargados solo de escribir el codigo HTML en el navegador y los Servletsdel control de ujo de los datos, nacio el Modelo 2 para el desarrollo de las aplicaciones web enJava. Este modelo sigue el clasico patron de diseno Model-View-Controller (MVC en adelante),de SmallTalk, este patron es explicado en la siguiente subseccion.

El proyecto Struts se lanzo en Mayo del 2000, por Craig R. McClanahan para proporcionar unmarco de trabajo MVC estandar a la comunidad que desarrolla aplicaciones web en Java. En Juliodel 2001, se libero Struts 1.0[8].

3.1.2. Patron de Diseno MVC

En el patron de diseno MVC, el ujo de la aplicacion esta dirigido por un Controlador central. ElControlador delega solicitudes (en el caso de aplicaciones web corresponden a solicitudes HTTP) aun manejador apropiado. Los manejadores estan unidos a un Modelo, y cada manejador actua comoun adaptador entre la solicitud y el Modelo. El Modelo representa o encapsula, un estado o logicade negocio de la aplicacion. Luego, el control normalmente es devuelto a traves del Controladorhacia la Vista apropiada.

19

El reenvo puede determinarse consultando los conjuntos de mapeos, normalmente cargadosdesde una base de datos o un archivo de conguracion. Esto proporciona un acoplamiento cercanoentre la Vista y el Modelo, que puede hacer las aplicaciones signicativamente mas faciles de creary de mantener.

En la gura 3.1 se puede visualizar un esquema de este Patron de Diseno.

Modelo

- Agrupa los estadosde las aplicaciones

- Responde a losrequerimientos

- Muestra la funcionalidad de laaplicacin

- Notifica a la Vista de los cambios

Controlador- Uno por cada funcionalidad - Selecciona la visualpara la respuesta - Mapea las acciones delUsuario a actualizacionesdel Modelo - Define el comportamientode la aplicacin

Vista

- Envia las acciones delusuario al Controlado

- Solicitudes actualizadasdesde el Modelo

- Interpreta el Modelo

- Permite al Controladorseleccionar las vistas

Consultade estado

Notificacionesde cambios

Seleccin de Vista

Acciones de usuarios

Cambios deEstado

Invocaciones de Mtodos

Eventos

Figura 3.1: Diagrama Patron de Diseno Model-View-Controller.

3.1.3. Introduccion al Marco de Trabajo de Struts

Usando el patron de diseno MVC, las aplicaciones Struts tienen tres componentes principales:un servlet controlador, que esta proporcionado por el propio Struts, paginas JSP (la vista), y lalogica de negocio de la aplicacion (o el modelo).

El servlet controlador Struts une y enruta solicitudes HTTP a otros objetos del marco de tra-bajo, incluyendo JSP y subclases del tipo org.apache.struts.action.Action[3] proporcionadas por el

20

desarrollador Struts. Una vez inicializado, el controlador analiza un archivo de conguracion derecursos, el que dene (entre otras cosas) el mapeo de acciones para una aplicacion. El controladorusa estos mapeos para convertir las solicitudes HTTP en acciones de aplicacion.

El mapeo de acciones normalmente denira: la ruta al archivo solicitado, el tipo de objeto(subclase del Action) que actuara sobre la solicitud y otras propiedades segun se necesite.

El objeto Action puede manejar la solicitud y responder al cliente (normalmente un navegadorWeb), o indicar a que control debera ser reenviado. Por ejemplo, si el ingreso de un nombre deusuario y contrasena en un formulario tiene exito, una accion asociada podra ser el reenviar lapeticion hacia el Menu principal de la aplicacion.

Los objetos Action tienen acceso al servlet controlador de la aplicacion, y por eso tienen accesoa los metodos del servlet. Cuando se reenva un control, un objeto Action puede reenviar indirecta-mente uno o mas objetos compartidos, incluyendo JavaBeans, situandolos en una de las coleccionesestandar compartidas por los servlets Java.

Un objeto Action puede crear un bean de tarjeta de compra, o un tem de la tarjeta, situando elbean en la coleccion de la sesion, y luego reenviando el control a otro mapeo. Este mapeo podrausar una pagina JSP para mostrar los contenidos de la tarjeta del usuario. Como cada cliente tienesu propia sesion, cada uno tambien tendra su propia tarjeta de compra. En una aplicacion Struts, lamayora de la logica del negocio se puede representar usando JavaBeans. Una Action puede llamara las propiedades de un JavaBean sin conocer realmente como funciona. Esto encapsula la logicadel negocio, para que la Action pueda enfocarse en el manejo de errores y donde reenviar el control.

Los JavaBeans tambien se pueden usar para manejar formularios de entrada. Un problemaclave en el diseno de aplicaciones Web es retener y validar lo que el usuario ha introducido en-tre solicitudes. Con Struts, se puede denir un conjunto de clases bean formulario (subclases deorg.apache.struts.action.ActionForm), y almacenar facilmente los datos de un formulario de entra-da en estos beans formularios. El bean se graba en una de las colecciones estandar o de contextocompartidas, por eso puede ser usado por otros objetos, especialmente un objeto Action.

Un bean de formulario Struts se declara en la conguracion de recursos denida en un archivofuente Java, y enlazado a un ActionMapping usando un nombre de propiedad comun. Cuando unasolicitud llama a un Action que usa un bean de formulario, el servlet controlador recupera o crea elbean formulario, y lo pasa el objeto Action. Este objeto entonces puede chequear los contenidos del

21

bean de formulario antes de que su formulario de entrada se muestre, y tambien la cola de mensajesa manejar por el formulario. Cuando esta listo, el objeto Action puede devolver el control con unreenvo a su formulario de entrada, usando un JSP. El controlador puede responder a la solicitudHTTP y dirigir al cliente al JSP correspondiente.

El marco de trabajo Struts incluye etiquetas personalizadas que pueden rellenar automatica-mente los campos de un formulario o un bean de formulario. Lo unico que la mayora de laspaginas JSP necesitan saber sobre el resto del marco de trabajo son los nombres de los camposapropiados y donde enviar el formulario. Los componentes como los mensajes encoladospor elAction pueden salir usando una simple etiqueta personalizada. Tambien se pueden denir otrasetiquetas especicas de la aplicacion para ocultar detalles de implementacion de las paginas JSPs.

Las etiquetas personalizadas en el marco de trabajo Struts estan disenadas para usar las car-actersticas de internacionalizacion incluidas en la plataforma Java. Todas las etiquetas de camposy los mensajes pueden recuperarse desde un recurso de mensajes y Java puede proporcionar au-tomaticamente el recurso correcto para el idioma y pas de un cliente. Para proporcionar mensajespara otro idioma, simplemente se agrega otro archivo con las etiquetas escritas en dicho idioma.

Junto al internacionalismo, otros benecios de esta aproximacion son las etiquetas consistentesentre formularios y la posibilidad de revisar todas las etiquetas y mensajes desde una localizacioncentral (en el archivo en donde estan denidas).

Un diagrama de como funcionara el patron MVC con Struts, en un aplicacion web, se muestraen la gura 3.2.

3.2. Modelo

El procesamiento de cada solicitud enviada a la aplicacion web esta denida en el Modelo.En general, el desarrollador de componentes del Modelo, se enfocara en la creacion de clasesJavaBeans que soporten todos los requerimientos de funcionalidad. La precision natural de losbeans requeridos por una aplicacion particular variara mucho dependiendo de esos requerimientos,pero generalmente pueden clasicarse en varias categoras descritas en la siguiente subseccion. Sinembargo, primero es util una breve revision del concepto de ambito en relacion con los beans y JSP.

22

Controlador(Servlets)

Vista(JSPs, TagLibs)

Model(JavaBeans)

1. Solicitud 2. Acciones

3. Resultados

4. Redireccionamiento

5. Consulta6. Resultado

NavegadorCliente

Figura 3.2: Patron MVC en una aplicacion web.

3.2.1. JavaBeans y el Ambito

En una aplicacion web, los JavaBeans pueden almacenarse en varias colecciones de atribu-tos diferentes. Cada coleccion tiene diferentes reglas para el tiempo de vida de esa coleccion, yla visibilidad de los Beans almacenados en ella. Las reglas que denen el tiempo de vida y lavisibilidad se llama el ambito de esos beans. La especicacion JSP dene las elecciones de ambitousando los siguientes terminos:

page: Beans que son visibles dentro de una sola pagina JSP para el tiempo de vida de lasolicitud actual.

request: Beans que son visibles dentro de una sola pagina JSP, as como en cualquier paginao servlet que este incluido o reenviado por esta.

session: Beans que son visibles para todas las paginas JSP y los servlets que participan enuna sesion de usuario particular, a traves de una o mas solicitudes.

23

application: Beans que son visibles para todas las paginas JSP y los servlets que formanparte de una aplicacion Web.

Es importante recordar que las paginas JSP y los servlets, al igual que las aplicaciones Web,comparten los mismos conjuntos de colecciones de beans.

3.2.2. Beans ActionForm

Un bean ActionForm corresponde a una clase Java que extiende la clase ActionForm[3], queStruts generalmente asume que se ha denido para cada formulario de entrada en la aplicacionweb. Si se declaran estos beans en el archivo de conguracion del mapeo de acciones, el servletcontrolador realiza automaticamente las siguientes acciones:

Chequea en la sesion de usuario si hay un ejemplar de un bean de la clase apropiada, bajo laclave apropiada.

Si no esta disponible dicho bean en el ambito de la sesion, se crea uno nuevo automaticamentey se anade a la sesion de usuario.

Por cada parametro de la solicitud, cuyo nombre corresponda con el nombre de una propiedaddel bean, se llamara al correspondiente metodo set().El bean ActionForm actualizado sera pasado al metodo perform() de la clase Action cuandoes llamado, haciendo que esos valores esten disponibles inmediatamente.

Para la codicacion de los beans ActionForm, se deben considerar los siguientes principios:

1. La propia clase ActionForm no requiere que se implemente ningun metodo especco. Se usapara identicar el rol que esos beans particulares juegan en la arquitectura general. Normal-mente, un bean ActionForm solo tendra metodos setxxx() y getxxx(), sin logica de negocio.

24

2. El objeto ActionForm tambien ofrece un mecanismo de validacion estandar. Si se sobree-scribe un metodo stub, y se proporciona mensajes de error en el recurso de aplicacionestandar, Struts validara automaticamente la entrada del formulario.

3. Denir una propiedad (asociada con metodos getXxx() y setXxx()) para cada campo queeste presente en el formulario. El nombre del campo y el nombre de la propiedad debencorresponder de acuerdo a las convenciones usuales de los JavaBeans. Por ejemplo, un campode entrada llamado username hara que se llame al metodo setUsername().

4. Se debe pensar en los beans ActionForm como un firewall entre el requerimiento HTTPy el objeto Action. Usando el metodo validate se puede asegurar de que estan presentes todaslas propiedades requeridas, y que contienen valores razonables. Un ActionForm que falla enla validacion no sera presentado para el manejo del Action.

5. Se podra usar un bean en el Formulario y usar referencias a sus propiedades. Por ejemp-lo, se podra tener un bean customer en el Action Form, y luego referirse a la propiedadcustomer.name en la vista JSP. Esto correspondera con los metodos customer.getName() ycustomer.setName(string Name) del bean customer.

3.2.3. Beans de Estado del Sistema

Corresponden al conjunto de objetos de negocio que representan el estado actual del sistema,por ejemplo: el carrito de compra que el usuario va modicando a lo largo de su interaccion con laaplicacion. Estos objetos de negocio seran tpicamente JavaBeans de los que se guardara la refer-encia en la sesion del usuario, los que seran modicados desde los Action y que seran consultadosdesde los JSPs.

3.2.4. Beans de la Logica del Negocio

Para una reutilizacion maxima del codigo, los beans de la logica del negocio deberan serdisenados e implementados para que no sepan que estan siendo ejecutados en un entorno de apli-cacion Web. Si por algun motivo es necesario importar una clase javax.servlet.* en el bean, seesta ligando esta logica de negocio al entorno de una aplicacion Web, lo que no es correcto y sedebera considerar reordenar las cosas, para que las clases Action traduzcan toda la informacionrequerida desde la solicitud HTTP que esta siendo procesada en llamadas a metodos setXxx() de

25

propiedades de los beans de logica de negocio, despues de que se pueda hacer una llamada a unmetodo execute(). Dicha clase de logica de negocio podra reutilizarse en entornos distintos al dela aplicacion Web, para el que fue construida en un principio.

3.3. Vista

La Vista comprende principalmente los JSP y los servlets involucrados en la generacion de lainterfaz de usuario o con otros sistemas. Struts provee soporte para construir aplicaciones multi-idioma, interaccion con formularios y otras utilidades mediante la utilizacion de Tags especiales(TagLibraries).

3.3.1. Internacionalizacion

La explosion del desarrollo de aplicaciones basadas en tecnologas Web, as como el desplieguede dichas aplicaciones sobre Internet y otras redes accesibles, han hecho que los lmites nacionalessean invisibles en muchos casos. Esto se ha traducido en la necesidad de que las aplicacionessoporten la internacionalizacion y localizacion.

Struts se construye sobre la plataforma Java, proporcionada para construir aplicaciones interna-cionalizadas y localizadas. Los conceptos claves para familiarizarse con ellos son:

Locale: La clase fundamental Java que soporta internacionalizacion es java.util.Locale. Todaclase de tipo Locale representa una eleccion particular de pas e idioma (ademas de variantesopcionales del idioma) y tambien un conjunto de utilidades de formateo para cosas como losnumeros y las fechas.

ResourceBundle: La clase java.util.ResourceBundle proporciona la herramienta fundamen-tal para el soporte de mensajes en varios idiomas.PropertyResourceBundle: Una de las implementaciones estandar de ResourceBundle quenos permite denir recursos usando la misma sintaxis nombre=valor usada para inicializar

26

los archivos de propiedades. Esto es muy conveniente para preparar paquetes de recursos conmensajes que son usados en una aplicacion Web, porque estos mensajes normalmente estanorientados a texto.

MessageFormat: La clase java.text.MessageFormat permite reemplazar partes de un men-saje (en este caso, recuperado de un paquete) con argumentos especicados en tiempo deejecucion. Esto es util en casos donde se esta creando una sentencia, pero las palabras po-dran aparecer en diferente orden en diferentes idiomas. Con la marca:

0 en el mensaje,se indica que debe ser reemplazado por el primer argumento, con

1 se dice que se debereemplazar por el segundo argumento, y as sucesivamente.

MessageResources: La clase Struts org.apache.struts.util.MessageResources permite tratarun conjunto de paquetes de recursos como una base de datos, y ademas permite solicitar unacadena de mensajes particular para una Localidad particular (normalmente asociado con elusuario actual) en lugar de la localidad por defecto, en la que el propio servidor se esta eje-cutando.

El soporte de la internacionalizacion en un marco de trabajo como Struts esta limitado a lapresentacion de texto e imagenes internacionalizadas al usuario. El soporte para localidades es-peccas con metodos de entrada (usado con idiomas como el Japones, el Chino y el Koreano) sedeja a disposicion del cliente, que normalmente es un navegador Web.

Un ejemplo de archivos de internacionalizacion y de uso se puede ver en la seccion 8.5.1 deesta memoria.

3.3.2. Interacciones de Forms y FormBean

Es comun en los desarrollos web el construir formularios usando las capacidades estandar delHTML, como la etiqueta . Los usuarios esperan que las aplicaciones interactivas tenganciertos comportamientos y uno de estos esta relacionado con el manejo de errores (si el usuariocomete un error, la aplicacion debera permitirle corregir solo lo que necesita ser modicado) sintener que reintroducir cualquier parte del resto que esta bien de la informacion de la pagina oformulario actual.

Struts proporciona una facilidad comprensiva para construir formularios, basada en la facilidad

27

de las Libreras de Etiquetas Personalizadas de JSP 1.1. Por ejemplo, un elemento de entrada paraun campo username podra parecerse a esto (en JSP):

Este caso, usando Struts sera:

Sin la necesidad de referirse explcitamente al formulario JavaBean del que se recupera el valorinicial. Esto lo maneja automaticamente el marco de trabajo.

Algunos ejemplos con codigo fuente para la construccion de formularios se pueden ver en laseccion 8.5.

3.4. Controlador

Luego de entender las componentes de la Vista y el Modelo de la aplicacion, correspondeanalizar las del Controlador. Struts incluye un servlet que implementa la funcion de mapear desdeuna solicitud a una clase, por lo que las principales responsabilidades del controlador son:

Escribir una clase Action por cada solicitud logica que podra ser recibida.

Congurar un ActionMapping (en XML) por cada solicitud logica que podra ser enviada. Elarchivo de conguracion XML normalmente se llama struts-cong.xml.

28

Actualizar el archivo del descriptor de despliegue de la aplicacion Web (en XML) para quela aplicacion incluya los componentes Struts necesarios.

Anadir los componentes Struts apropiados a la aplicacion.

Cada uno de estos temas son explicados en las subsecciones siguientes.

3.4.1. Clases Action

El objetivo de una clase Action es procesar una solicitud y devolver un objeto que identicadonde se debera reenviar el control, para proporcionar una respuesta adecuada.

Una clase Action tpica implementara una logica que comenzara validando el estado actual dela sesion del usuario, vericando que el usuario no intente entrar en el medio de una aplicacion,sin cumplir los pasos previos de la secuencia correcta. Si la validacion no se ha completado, laclase valida las propiedades del bean formulario segun sea necesario. Si se encuentra un problema,la clase almacena las claves de los mensajes de error apropiados como un atributo de la peticion yreenva el control de vuelta al formulario de entrada para que se puedan corregir los errores.

Luego realiza el procedimiento solicitado, mediante el codigo incorporado dentro de la claseAction o realizando llamadas a un metodo apropiado de un bean de la logica del negocio. A con-tinuacion, debe actualizar los objetos del lado del servidor que seran usados para crear la siguientepagina de la interfaz con el usuario.

Finalmente, devuelve un objeto apropiado que identica algun elemento de la vista (una paginaJSP, por ejemplo), basada en los beans actualizados recientemente.

Las clases Action presentan algunos problemas de diseno, como que el servlet controlador creauna sola instancia de la clase Action y la usa para todas las solicitudes, por lo que, si se quiereoperar correctamente en un ambiente multi-thread, se debe codicar una nueva clase Action.

Otro problema, es que el asignar recursos y mantenerlos a traves de las solicitudes del mismo

29

usuario (en la misma sesion) puede causar problemas de escalabilidad. Se debera pensar en liberaresos recursos (como las conexiones a una base de datos), antes de reenviar el control al componentede la Vista apropiado.

3.4.2. La Implementacion de ActionMapping

Para poder operar correctamente, el servlet Controlador necesita conocer varias propiedadessobre como se debera mapear todo un requerimiento solicitado a una clase Action apropiada, eseconocimiento se encapsula en una interface Java, llamada ActionMapping, en donde laspropiedades mas importantes son:

type: Nombre totalmente cualicado de la clase Java que implementa la clase Action usadapor este mapeo.

name: El nombre del bean de formulario, denido en el chero de conguracion que us-ara este action.

path: El path del requerimiento solicitado, que corresponden con la seleccion de este mapeo.

forward: El path del requerimiento solicitado a la que se pasa el control cuando se ha invo-cado su mapeo.

En la seccion 8.5.2 de esta memoria se puede revisar un completo archivo con la conguracionde los mapeos del Action y sus correspondientes comentarios.

3.4.3. Descriptor de Despliegue de la Aplicacion Web

El paso nal en la conguracion de la aplicacion, es congurar el descriptor de despliegue paraincluir todos los componentes que son necesarios.

30

Un completo archivo de ejemplo del descriptor de despliegue de la aplicacion, con los corre-spondientes comentarios se puede visualizar en la seccion 8.5.3.

3.4.4. Configurar el Mapeo del Servlet Action

Existen dos aproximaciones comunes para denir las URLs que seran procesadas por el servletcontrolador: correspondencia de prejo y correspondencia de extension.

La correspondencia de prejo indica que todas las URLs que empiecen con un valor particularsean pasadas a este servlet. Por otro lado, en el mapeo por extension, se reenvan las URLs so-licitadas al servlet action basandose en que la URL termina en un punto seguido por un conjuntodenido de caracteres. Por ejemplo, para la correspondencia de prejo se podra tener:

action/execute/*

Lo que signica que una URL que coincida con el path /logon descrito anteriormente podraparecerse a:

http://www.mycompany.com/myapplication/execute/logon

Donde /myapplication es el path de contexto bajo el que se ha desplegado la aplicacion.

Para el mapeo por extension se tendra:

31

action*.do

Y una URL que corresponda con el path /logon descrito anteriormente se parecera a:

http://www.mycompany.com/myapplication/logon.do

3.4.5. Configurar la Librera de Etiquetas de Struts

Finalmente se debe denir la librera de etiquetas de Struts, en la actualidad vienen 4 libreras.Las que son:

1. struts-bean: Contiene etiquetas utiles para acceder a los beans y sus propiedades, as comopara denir nuevos beans (basados en esos accesores) que son accesibles para el resto de lapagina mediante variables de scripting y atributos de ambito de pagina. Tambien se propor-cionan mecanismos convenientes para crear nuevos beans basados en el valor de una cookie,de las cabeceras y de los parametros [9].

2. struts-html: Contiene etiquetas para crear formularios de entrada struts, as como otras eti-quetas generalmente utiles en la creacion de interfaces de usuario basados en HTML [11].

3. struts-logic: Contiene etiquetas que son utiles para manejar la generacion condicional desalida de texto, hacer ciclos sobre colecciones de objetos para generacion repetitiva de salidade texto y control del ujo de la aplicacion [10].

4. struts-template: Contiene etiquetas que denen un mecanismo de plantillas.

En la seccion 8.5.3 se incluye un archivo que contiene una denicion ejemplo de libreras deetiquetas.

32

Captulo 4

Requerimientos

4.1. Introduccion

Con los antecedentes revisados en el captulo 2, es necesaria la denicion de los requerimientosde Interfaces y los requerimientos Funcionales, como la identicacion de los Casos de Uso juntocon los actores del sistema, temas de los que trata este captulo.

4.2. Requerimientos de Interfaces Externas

Las interfaces externas se pueden dividir en Interfaces de Software e Interfaces de Comuni-cacion, en las primeras se abarcan las conexiones a Bases de Datos y en las segundas se mencionancomo se comunica la aplicacion con su entorno.

33

4.2.1. Interfaces de Software

El sistema se debera comunicar con la base de datos que almacena el reporte de los pagos desdeWebpay y Servipag y con el actual sistema de registro de dominios que posee NIC Chile, desde elcual debe obtener los datos necesarios para poder generar las facturas.

Para la generacion de facturas electronicas, el sistema se debe comunicar con el software queobtiene la informacion desde el SII, como por ejemplo los numeros de folios. Ademas de comuni-carse con los modulos que generan el timbre y la rma electronica.

Para la generacion de facturas tanto electronicas como manuales, el sistema se debe comunicarcon una base de datos que maneja todos los RUT de los contribuyentes del SII, junto con las razonessociales, a n de vericar que la razon social para la cual se emite una factura exista en la base dedatos del SII y este correcta la asociacion con el RUT al cual se esta facturando.

4.2.2. Interfaces de Comunicacion

El sistema sera usado va web, dentro de la red local de NIC Chile, al cual se podra accederdesde la pagina principal de Administracion, la que usan los distintos operadores de la organi-zacion, en sus distintas labores. Los protocolos de comunicacion son los mismos que los del sitiode Administracion.

Para la comunicacion con el SII, se usaran las paginas que ellos dispongan para los con-tribuyentes electronicos.

34

4.3. Requerimientos Funcionales

Los requerimientos funcionales que debe cumplir el Sistema, junto con su explicacion, son lossiguientes:

1. El sistema debe identicar todos los dominios con factura pendiente.Desde que un cliente de NIC Chile cancela una solicitud de dominio, ya sea por inscripcion,renovacion o transferencia, este queda con la factura pendiente. Todos los dominios que estenen el estado pendiente de factura deben ser identicados para ser procesados.

2. El sistema debe ser capaz de agrupar las facturas de un mismo cliente en una sola.Es normal que un cliente de NIC Chile cancele solicitudes por mas de un dominio, paralo cual es necesario imprimir una sola factura por la cantidad de dominios que el clientecancelo1.

3. El sistema debe ser capaz de manejar excepciones al proceso normal de facturacion.En la actualidad existen clientes como la Universidad de Chile a la cual no se le deben emitirfacturas, si no que solo comprobantes internos de venta. Ademas, se tienen otros clientes quenecesitan recibir las facturas de forma separada (caso de sucursales) y no todas agrupadaspor un mismo RUT.

4. Debe permitir imprimir un subconjunto de las facturas pendientes en el sistema.NIC Chile, en estos momentos, emite aproximadamente 4000 facturas mensuales, por lo quees probable que el operador no alcance a cumplir con el proceso de facturacion para todoslos dominios pendientes, de esa forma, se le debe permitir facturar un subconjunto de laspendientes.

5. Debe permitir asociar un numero de serie con la factura impresa. De paso, se debe modicarel registro del dominio, asociando el numero de factura correspondiente.Cada factura impresa lleva un numero de serie que viene preimpreso en el papel utilizado.Este numero de serie es el identicador de la factura, por lo que debe estar asociado al registrodel dominio, para posteriormente obtener a quien se emitio dicha factura.

6. Debe permitir volver a iniciar el proceso completo de facturacion, para aquellas facturas quepor algun motivo no fueron impresas correctamente.

1En NIC Chile las facturas se emiten luego que el cliente paga el(los) dominio(s).

35

Cuando el papel en donde se imprimen las facturas viene con algun problema, o la impresorafalla durante la impresion (falla electrica, tecnica, etc) se debe poder iniciar el proceso defacturacion completo para las solicitudes afectadas.

7. Cuando la glosa de una factura sobrepasa el espacio disponible para impresion en el papel(por ejemplo, cuando se facturan muchos dominios para un mismo cliente), se deben generartantas facturas como sea necesario.Este numero de facturas estara determinado de acuerdo a la relacion numero de lneas deglosa dividido por el numero de lneas disponibles para imprimir en el papel.

8. Debe permitir imprimir un listado con todas las facturas impresas, para ser enviado a laempresa de correos.La empresa que despacha las facturas a los domicilios de los clientes necesita un listado detodas las facturas impresas, el cual utilizan al momento de repartir la correspondencia.

9. Debe permitir enviar un email a la empresa de correo con la lista de las facturas enviadasfsicamente a ellos.La empresa que despacha las facturas necesita recibir un email con el listado de las facturasque se les envio, con el n de comprobar que las facturas que ellos reciben desde NIC Chileson las mismas que se muestran en el listado. Dicho email es el unico listado en formatodigital que ellos reciben.

10. Debe generar reportes utiles, como:

Volumen de dominios por cliente.Estadsticas de medios de pago.Estadsticas de ventas de dominios por localidades.Estadsticas de ventas diarias, por creacion de dominios y renovacion.

En NIC Chile los informes que se manejan del area de facturacion estan diseminados endistintos sistemas. Es necesario que se centralice la generacion de los informes, a modo depoder tener un mejor control.

11. Debe generar el libro de venta diario.En la actualidad no existe la generacion de un Libro de Venta Diario en NIC Chile, el cualsolo existe en la Facultad de Ciencias Fsicas y Matematicas. El Jefe Administrativo lo so-licita, con el objetivo de tener la informacion mas accesible y poder conocer los informes encualquier momento sin tener que esperar los reportes desde la Facultad de Ciencias Fsicas yMatematicas.

12. Debe tener modos de validacion de datos.NIC Chile tiene registro de dominios desde el ano 1997, los cuales al ser renovados2, se les

2Cada 2 anos

36

debe generar una factura. Estos dominios, podran tener datos erroneos (por ejemplo, razonessociales que no existan) que al momento de facturar se deben comprobar su validez.

13. Debe permitir crear facturas, para las cuales el operador del sistema ingresara en forma man-ual los datos necesarios.NIC Chile emite facturas de forma automatica solo por ventas de dominios, eventualmente sepodran emitir facturas para otras actividades como cursos de capacitacion o alguna asesora.

14. Debe tener integracion con el sistema Informat.En la actualidad la impresion de facturas y el reporte de las facturas a la Facultad se desar-rolla por 2 medios distintos y por personas distintas. El nuevo Sistema de Facturacion debeincorporar la generacion de los informes para Informat, con todas las reglas que este sistemaimpone.

15. Debe permitir realizar el proceso de facturacion de forma manual como electronica.En la actualidad en NIC Chile solo se realiza la facturacion manual de dominios. El nuevosistema debe ser capaz de poder generar facturas de forma electronica y manual indiferente-mente. Para la generacion de facturas electronicas se deben adaptar las mismas funciones, amodo de no cambiar en su totalidad el modo de operacion, cumpliendo con los requerimien-tos y estandares entregados por el SII.

4.3.1. Requerimientos No Funcionales

1. El sistema debe ser construido sobre plataforma web.La mayora del Software que se usa en NIC Chile esta construido sobre plataforma web,incluyendo gran parte del actual sistema de facturacion. Ademas, para la facturacion elec-tronica el canal de comunicacion denido es Internet, por lo que un sistema construido enplataforma web es el mas adecuado.

2. Se debe utilizar el lenguaje Java para la implementacion del sistema.Dentro del proyecto de renovacion del software interno de NIC Chile, esta el evaluar eldesarrollo de un sistema interno en el lenguaje Java, por esta razon se solicito al autor de estamemoria usar el lenguaje Java para el desarrollo del sistema.

37

4.4. Casos de Uso

Para dejar mas en claro las funcionalidades que debe abarcar el sistema junto con los actoresque las realizaran, se utilizaron casos de uso. En las siguientes subsecciones se muestran los actoresy los correspondientes diagramas de casos de uso.

4.4.1. Actores

Los siguientes son los actores identicados para el sistema:

Operador: Persona que usara el sistema mas frecuentemente. Es el encargado de cumplircon todo el proceso de facturacion, tanto de forma manual como electronico, dependien-do de como se este operando. Corresponden a los actuales operadores de facturacion y decontabilidad.

Jefe Administrativo: Usuario que utiliza el sistema para revisar los informes de estadsticasdel Sistema, como: distribucion de dominios por localidades, por medio de pago, etc. Tam-bien debe tener la opcion de poder facturar.

Administrador: Persona que controla la conguracion del sistema. Indica las excepcionesen el proceso de facturacion y algunos datos tecnicos como especicacion de la impresora.Ademas maneja la administracion de usuarios, como creacion, modicacion, eliminacion ydenicion de permisos.

4.4.2. Diagramas de Casos de Uso

En la gura 4.1 se presenta un diagrama de casos de uso, los cuales son explicados uno a uno enlas subsecciones siguientes. En el diagrama se aprecia un caso de uso llamado Emitir DTE el cualse explica para que el lector tenga un mejor conocimiento de que trata la emision de una FacturaElectronica[2], tema que no se abarca ni implementa en la presente memoria.

38

ImprimirFactura

AsociarNmero

EnviarFacturas

CrearFactura

VerInformes

ConfigurarSistema

Operarioo

JefeAdministrativo

Jefe Administrativo

AdministradorAdministracinde Usuarios

EmitirDTE

ListadosInformat

EditarFacturas

Operarioo Jefe

Administrativo

Figura 4.1: Diagrama de casos de uso del Sistema.

Estos casos de uso se obtuvieron integrando las funcionalidades actuales del sistema de fac-turacion con los nuevos requerimientos, explicados en la seccion 4.3 de este captulo.

39

4.4.3. Caso de Uso: Imprimir Facturas

Nombre: Imprimir FacturasObjetivo: Que el operador del sistema pueda enviar a la impresora las fac-

turas que previamente selecciono para imprimir.Actores: OperadorTrigger: Solicitud de imprimir por parte del Operador.Precondiciones: El usuario selecciono un grupo de facturas pendientes para im-

primir.PostcondicionesCaso Normal:

El sistema enva las facturas a la impresora y genera un mensajeal operador si se imprimieron bien.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro imprimir yvuelve al estado inicial, con las mismas facturas en estado pen-diente.

Escenario PrimarioPaso Actor Sistema1 Selecciona un grupo de facturas

pendientes para imprimirlas y lasenva a la impresora

2 Si se reciben los datos para imprim-ir, se envan a la impresora determi-nada en la conguracion

3 Retira las facturas desde la impreso-ra para asociarles numero si es quesalieron correctamente impresas

Escenario SecundarioPaso Actor Sistema3a Si las facturas no se imprimieron bi-

en o un rango de ellas no salio cor-rectamente, se procede a repetir laimpresion del rango que salio mal

40

4.4.4. Caso de Uso: Asociar Numero

Nombre: Asociar NumeroObjetivo: Que el operador del sistema pueda asociar un numero a la fac-

tura impresa, este numero puede ser el numero de comprobanteinterno o el que viene preimpreso en el papel de la factura.

Actores: OperadorTrigger: Solicitud de asociar numero para las facturas impresas por parte

del Operador.Precondiciones: El operador tipea el numero correspondiente en el casillero que

lo solicita para las facturas impresas sin numero asociadoPostcondicionesCaso Normal:

El sistema asocia un numero a las facturas impresas en la basede datos y solicita al operador la conrmacion de la operacion.

PostcondicionesCaso anormal:

En caso de no poder asociar un numero (podra estar ya asocia-do) se le comunica al operador para vericar el numero.

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion asociar

numero.

2 Despliega el listado de facturas im-presas que no tienen un numero aso-ciado.

3 Tipea el numero correspondiente, yasea de factura o de comprobante in-terno.

4 Asocia en el registro de la factura elnumero ingresado.

41

Escenario SecundarioPaso Actor Sistema4a En caso de que el numero tipeado no

cumpla con las reglas de asociacion,se solicita nuevamente el ingreso delnumero.

4.4.5. Caso de Uso: Enviar Facturas

Nombre: Enviar FacturasObjetivo: Que el operador del sistema a partir de las facturas impresas y

con numero asociado pueda imprimir un listado de las facturasa enviar y de paso generar un email para la empresa de correos.Ademas el sistema debe modicar el registro del dominio indi-cando que ya esta facturado.

Actores: OperadorTrigger: Solicitud de enviar por parte del OperadorPrecondiciones: Existen facturas impresas y con numero asociado para enviar.PostcondicionesCaso Normal:

El sistema muestra el listado de las facturas generadas para serimpreso y genera un email, el cual es enviado a los mails dela empresa de correos, con copia a otros email determinados enla conguracion del Sistema. Ademas, cambia el estado a losdominios como facturados y a las facturas como enviadas.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro enviar las fac-turas, volviendo al estado inicial.

42

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion de Enviar fac-

turas2 Muestra un detalle de la informacion

que se enviara.3 Imprime el listado y luego selec-

ciona el boton Enviar.4 Marca como enviadas las facturas y

genera el email para los destinatar-ios correspondientes. Genera un re-porte.

5 Revisa el reporte del sistema, de es-tar bien puede volver a iniciar el pro-ceso de facturacion, de lo contrariorevisa el error.

Escenario SecundarioPaso Actor Sistema5a En caso de algun error se vuelve al

estado inicial con el listado de fac-turas sin enviar.

4.4.6. Caso de Uso: Crear Factura

Nombre: Crear FacturaObjetivo: Que el operador del sistema pueda crear una factura a partir de

algunos datos que debe tipear en la interfaz de crear facturas.Actores: Operador.Trigger: Solicitud de crear factura por parte del Operador.Precondiciones: Ninguna.PostcondicionesCaso Normal:

El sistema crea una nueva factura para poder asociarle numero eimprimirla.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro crear una fac-tura, volviendo al estado inicial.

43

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion Crear Factura2 Despliega una interfaz en la cual in-

gresa la informacion.3 Ingresa los datos necesarios para

generar una factura. PresionaGuardar.

4 Guarda la factura generada.5 Revisa el reporte del sistema, de es-

tar bien puede seguir creando fac-turas o volver al inicio del sistema,de lo contrario revisa el error.

Escenario SecundarioPaso Actor Sistema5a En caso de algun error se vuelve al

estado inicial del sistema.

4.4.7. Caso de Uso: Emitir DTE

Nombre: Emitir DTEObjetivo: Que el Operador del Sistema pueda emitir DTE (Facturas Elec-

tronicas)Actores: Operador.Trigger: Solicitud emitir Facturas Electronicas para los datos pendientes.Precondiciones: Existen datos pendientes por facturar.PostcondicionesCaso Normal:

El sistema luego de solicitar las claves de ingreso y del certi-cado digital emite los DTE, generando los documentos XML yPDF correspondiente.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro emitir los doc-umentos solicitados.

44

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion Electronico

al momento de conectarse al Sis-tema.

2 Solicita la clave para usar el certi-cado digital, inscrito en el SII pararmar los DTE.

3 Una vez ingresada la clave, solicitaver los Documentos Por Facturar.

4 Despliega el listado de documentospor facturar en grupos de 100.

5 Selecciona el listado de documentosa emitir.

6 Solicita la clave necesaria paragenerar el timbre y rmar el XML.

7 Ingresa la clave asociada al certica-do que se usara para timbrar y rmarlos DTE.

8 Valida las claves y comienza agenerar los XML rmados y losPDF. Ambos documentos los guar-da en la base de datos.

Escenario SecundarioPaso Actor Sistema3a En caso de que la clave sea invalida

el sistema la vuelve a solicitar.7a En caso de que la clave sea invalida

el sistema la vuelve a solicitar (man-teniendo en memoria el listado delos documentos seleccionados paraemitir).

8a En caso de fallar la rma o genera-cion del XML o PDF el sistema lan-zara un reporte al nal, una vez quenalizo la emision de la totalidad delos documentos solicitados.

45

4.4.8. Caso de Uso: Editar Facturas

Nombre: Editar FacturasObjetivo: Que el Operador del Sistema pueda editar las facturas que exis-

ten en el sistemaActores: Operador.Trigger: Solicitud editar facturas.Precondiciones: Existen facturas en la base de datos del sistema.PostcondicionesCaso Normal:

El sistema despliega el listado de facturas, luego de recibir loscambios en la factura ingresa los nuevos datos en la base dedatos.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro modicar losdatos de la factura solicitada

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion Editar Fac-

turas del menu de navegacion delsistema.

2 Despliega el listado de las facturasingresadas en el sistema.

3 Selecciona la factura a editar.4 Despliega los datos de la factura que

se selecciono para editar.5 Actualiza los datos de las facturas.6 Graba los datos actualizados.

46

Escenario SecundarioPaso Actor Sistema2a En caso de que no existan facturas

en la base de datos del sistema,despliega un mensaje indicando lasituacion.

6a En caso de que no se pueda actua-lizar los datos de la factura solicita-da, se despliega un mensaje indican-do lo ocurrido.

4.4.9. Caso de Uso: Ver Informes

Nombre: Ver InformesObjetivo: Que el Jefe Administrativo pueda visualizar distintos informes

del Sistema.Actores: Jefe Administrativo.Trigger: Solicitud de ver informes por parte del Jefe Administrativo.Precondiciones: Existen informes que visualizar.PostcondicionesCaso Normal:

El sistema despliega los informes solicitados.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro desplegar elinforme solicitado, volviendo al inicio.

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion de Visualizar

Informes.2 Muestra el detalle del informe selec-

cionado.3 Revisa el informe desplegado,

puede solicitar ver otro o salir delsistema.

47

Escenario SecundarioPaso Actor Sistema3a En caso de algun error se vuelve

al estado inicial mostrando los in-formes disponibles.

4.4.10. Caso de Uso: Configurar Sistema

Nombre: Congurar SistemaObjetivo: Que el Administrador pueda modicar o ingresar opciones de

conguracion del Sistema.Actores: Administrador.Trigger: Solicitud de congurar el sistema por parte del Administrador.Precondiciones:PostcondicionesCaso Normal:

El sistema reeja los cambios hechos.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro cambiar la con-guracion.

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion de Congurar

Sistema2 Muestra el detalle de las congura-

ciones actuales.3 Determina la conguracion a cam-

biar y la modica.4 Actualiza la conguracion

48

Escenario SecundarioPaso Actor Sistema4a En caso de algun error se vuelve a la

anterior conguracion.

4.4.11. Caso de Uso: Administracion de Usuarios

Nombre: Administracion de UsuariosObjetivo: Que el Administrador pueda modicar o ingresar nuevos usuar-

ios del Sistema.Actores: Administrador.Trigger: Solicitud de Administrar Usuarios por parte del Administrador.Precondiciones:PostcondicionesCaso Normal:

El sistema reeja los cambios hechos.

PostcondicionesCaso anormal:

El sistema genera un mensaje de que no se logro ingresar o mod-icar el o los usuarios.

Escenario PrimarioPaso Actor Sistema1 Selecciona la opcion de Adminis-

tracion de Usuarios2 Muestra el listado de los usuarios.3 Determina el usuario a modicar o

ingresar uno nuevo.4 Actualiza la conguracion

Escenario SecundarioPaso Actor Sistema4a En caso de algun error se vuelve a la

anterior conguracion.

49

Captulo 5

Diseno

5.1. Introduccion

Luego de recopilar los antecedentes y requerimientos del nuevo sistema de Facturacion y unavez conocido el Framework con el cual se debe desarrollar el sistema, es necesario denir yexplicar el diseno.

Se comienza deniendo las plataformas de hardware y software bajo las cuales se de-sempenara el sistema, junto con las Bases de datos con las que interactua. Luego, se sigue conlos diagramas necesarios para explicar el funcionamiento del sistema, junto con las funciones y elmodelo de datos.

En este diseno no se muestran los procesos necesarios para operar con documentos tributarioselectronicos, pero s la interaccion que existe con ellos.

50

5.2. Plataformas de Hardware y Software

El sistema sera usado dentro de la Intranet de NIC Chile, la cual es utilizada por todos losfuncionarios de las areas de Atencion a Clientes, Soporte Tecnico, Legal y Facturacion.

La implementacion del sistema disenado en esta memoria fue realizada en el servidor de desar-rollo que posee NIC Chile, en el cual, el hardware y software disponible es:

Procesador AMD Athlon(TM) XP, de 1600 MHz2 Discos duros de 60 GB cada uno, marca Maxtor modelo 6L060J3

1 GB de memoria RAM

Sistema Operativo Linux Red Hat 7.3

Servidor web Apache 1.3.23

Motor de Base de Datos MySql 3.23.10

Tomcat, version 4.0

Lenguaje Java, version 1.4.0Struts FrameWork, version 1.0.2

Ant, version 1.5

En el mismo servidor se encuentra instalado todo el software con el cual se relacionara elsistema de facturacion, como es el que inserta los pagos en el repositorio de pagos, el que actualizalas razones sociales con los RUT y el software que realiza los envos de los ingresos al sistemacontable Informat. Todos estos software mencionados estan instalados en este servidor, con motivode mantener un servidor de desarrollo lo mas similar al servidor de produccion de NIC Chile.

51

5.3. Bases de Datos Definidas Externamente

El sistema se relacionara con 3 bases de datos denidas externamente:

1. Repositorio de pagos: Corresponde a la base de datos denominada ToDo, en la cual semantienen los pagos relacionados con dominios, que son insertados directamente de los pro-cesos que atienden por medio de Servipag y Web Pay. Los registros de esta base de datosposeen el nombre del dominio, el numero de proceso del dominio, la f