Memoria PDF

UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION
DE UN NUEVO SISTEMA DE FACTURACION

PARA NIC
E IMPLEMENTACION
DISENO
CHILE
URZUA
REINOSO
JOSE ANDRES
EXAMINADORA
COMISION
CALIFICACIONES:
NOTA (n )
PROFESOR GUIA
DR. JOSE MIGUEL PIQUER
(Letras)
PROFESOR CO-GUIA
DR. PATRICIO POBLETE
PROFESOR INTEGRANTE
SR. GABRIEL IRIBARREN
NOTA FINAL EXAMEN DE TITULO
MEMORIA PARA OPTAR AL TITULO DE
INGENIERO CIVIL EN COMPUTACION
SANTIAGO DE CHILE
ENERO DEL 2003
FIRMA
RESUMEN DE LA MEMORIA
PARA OPTAR AL TITULO DE
INGENIERO CIVIL EN COMPUTACION

REINOSO
POR: JOSE URZUA
FECHA: 20/01/2003
PROF. GUIA: Sr. JOSE MIGUEL PIQUER
DE UN NUEVO SISTEMA DE FACTURACION

PARA NIC
E IMPLEMENTACION
DISENO
CHILE
Para emitir facturas por las operaciones comerciales como inscripcion y renovacion de dominios, NIC Chile posee un software desarrollado internamente, el cual presenta limitaciones que se
hacen notorias al aumentar este numero de operaciones. Por otra parte, el creciente uso de la tecnologa y la necesidad de optimizar y facilitar las operaciones comerciales entre las empresas, ha
llevado 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 para
NIC Chile, el cual debe realizar tanto facturacion de forma manual como electronica. Este trabajo
incluye un manual de usuario y detalladas descripciones de las herramientas utilizadas para el
desarrollo.
El desarrollo del sistema se realizo utilizando el lenguaje Java, con un marco de trabajo denominado Struts, lo que permitio obtener un sistema modularizado y de buen desempeno, que cumple
los requerimientos y diseno especificados 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 eliminaciones de dominios) y solo se incorporan papeles en el momento de entregar un comprobante
por un pago recibido. Dentro de las ventajas se tiene el ahorro estimado de $486 pesos (estimacion
dada por el SII), por conceptos de papel, copias, envo de correspondencia, etc. Ademas, se debe
considerar el ahorro en el tiempo, que para el caso de NIC Chile de un proceso de varias horas se
pasa 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 tributarios electronicos (DTEs), pensando en la incorporacion de toda la Universidad de Chile al modelo
de operacion con DTEs.
Agradecimientos
En primer lugar quisiera agradecer a mis padres y hermanos por entregarme sus valores, educacion e incondicional apoyo en mis actividades. A mi pareja Paola, por su carino, preocupacion y
dedicacion en todo momento.
Tambien quiero entregar mis agradecimientos a NIC Chile, institucion que me entrega la posibilidad de desarrollarme laboralmente. Especialmente a don Edgardo Krell y al grupo de Desarrollo.

Indice
general
1. Introduccion
1.1. Antecedentes Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2. Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Antecedentes
2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Modelo Actual de Facturacion en NIC Chile . . . . . . . . . . . . . . . . . . . . .
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. Configurar el Mapeo del Servlet Action . . . . . . . . . . . . . . . . . . .
31
3.4.5. Configurar la Librera de Etiquetas de Struts . . . . . . . . . . . . . . . . .
32
4. Requerimientos
33
4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
33
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: Configurar Sistema . . . . . . . . . . . . . . . . . . . . . .
48
IV
4.4.11. Caso de Uso: Administracion de Usuarios . . . . . . . . . . . . . . . . . .
5. Diseno
49
50
5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.2. Plataformas de Hardware y Software . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.3. Bases de Datos Definidas 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

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8. Anexos
83
84
8.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 Configuracion de los Mapeos de Action . . . . . . . . . . . . . 109
8.5.3. Descriptor de Despliegue de la Aplicacion Web . . . . . . . . . . . . . . . 123
8.5.4. Definicion detalla del Modelo de Datos . . . . . . . . . . . . . . . . . . . 125
VII
Captulo 1
Introduccion
1.1. Antecedentes Generales

El buen funcionamiento y masificacion que ha logrado Internet, se debe en gran parte a la existencia 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 las
noticias de la cadena CNN en Internet, solo basta con acordarse del nombre de dominio que ellos
manejan: www.cnn.com, en vez de tener que recordar la direcci
on IP del computador que
mantiene los contenidos noticiosos, que podra ser: 64.236.24.20.
Los nombres de dominios estan clasificados por sufijos. As existen los sufijos 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 sufijos genericos, conocidos como
gTLD (Generic Top Level Domain) como por ejemplo: .COM relativos a dominios comerciales,
.NET para identificar nombres relativos a redes, .MIL para organizaciones militares, .EDU para
organizaciones educacionales; a los que u ltimamente se han agregado los .INFO, .BIZ y .AERO.
Para que las personas puedan acceder y crear sus nombres de dominios bajo algun TLD, es
necesario que exista alguna organizacion encargada de la Administracion de ese sufijo. La entidad
1
coordinadora de los Administradores de registro a nivel internacional es ICANN, la cual delega

la funcion de administrar los ccTLD en entidades generalmente conocidas como NIC (Network
Information Center), habitualmente una entidad por pas.
NIC Chile es actualmente un proyecto del Departamento de Ciencias de la Computacion de la
Universidad de Chile, que se encarga de la administracion del TLD correspondiente a la Republica
de Chile, llamado .CL (punto CL), tarea delegada por IANA (posteriormente ICANN absorbio las
funciones de IANA) desde el ano 1987. La administracion, consiste en publicar en Internet de manera correcta, la asociacion de un nombre de dominio bajo .CL con la(s) direccion(es) IP correspondiente(s), por medio de un funcionamiento continuo del servicio de DNS. Ademas, NIC Chile debe
recibir solicitudes de creacion por nuevos dominios, evitando que mas de una persona natural o
jurdica tenga el mismo nombre.
Para las tareas que debe cumplir NIC Chile en la administracion del TLD .CL, se cuenta con
diversos sistemas desarrollados internamente. Dadas las necesidades de nuevas funcionalidades, se
comenzo un perodo de completa renovacion de este software, dentro de los cuales esta el sistema
de facturacion.
En Chile, tanto las solicitudes de inscripcion como la renovacion de los dominios inscritos son
procesos que involucran una operacion comercial, la cual debe ser respaldada con su correspondiente documento tributario, en este caso una Factura. Este documento da cuenta de la posesion y
el pago por un contrato entre dos partes.1 En el caso de NIC Chile, es el servicio de DNS para el
dominio solicitado, por un perodo de 2 anos.
Para generar las facturas por las operaciones comerciales que se realizan en NIC Chile, existe un
software desarrollado de forma interna que cumple con la tarea de agrupar, imprimir y asociar las
facturas a los dominios y titulares correspondientes, segun la legislacion vigente. 2 Con el aumento
de las inscripciones y renovaciones de dominios, aumenta el volumen de dominios a facturar, ante
lo cual se hacen mas notorias las limitaciones del software existente, las que son analizadas en la
siguiente seccion de este captulo.
El creciente uso de la tecnologa en las operaciones comerciales y la necesidad de optimizar y
facilitar las operaciones entre las empresas ha llevado al SII a propiciar un modelo de operacion con
Documentos Tributarios Electronicos(DTE), que utilice Internet como canal de comunicacion[2].
1
2
Definicion del Sub Director de Informatica del SII, Fernando Barraza.

Permite facturar solo operaciones comerciales relativas a dominios
NIC Chile esta participando dentro de un programa piloto del SII, en conjunto con varias otras
empresas, para generar Facturas Electronicas.
Las limitaciones del sistema actual de facturacion de NIC Chile, la participacion en el Piloto de
emision de DTEs del SII y el comienzo del desarrollo de una nueva version del software interno de
NIC Chile, dan paso a la presente memoria, en la cual se muestra el Diseno e Implementacion de
un nuevo Sistema de Facturacion para NIC Chile.
1.2. Justificacion
El actual sistema de facturacion, construido en su mayora con interfaz web, posee ciertas limitaciones, que en conjunto con el aumento de la cantidad de facturas que se deben emitir 3 , han
generado 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 impresion
y envos de facturas, por otro lado estan los reportes que se le deben enviar a la Universidad de
Chile por medio del sistema llamado Informat, y tambien se tiene por separado un sistema de
estadsticas de facturacion de dominios. Esta separacion de funcionalidades genera inconsistencias
tales como estadsticas no actualizadas, reportes con errores para Informat, dificultades para reconstruir facturas, etc. Estas inconsistencias no se produciran si existiese un sistema en que estuviese
todo integrado.
Agregar alguna nueva funcionalidad al actual sistema es una tarea bastante complicada, por no
existir una configuracion centralizada ni modulos con funcionalidades claras. Ademas, si se agrega
que no existe unicidad en el lenguaje ni en la plataforma de desarrollo, aumentan las dificultades
de mantencion y escalabilidad del sistema. El software actual esta mayoritariamente escrito en
el lenguaje Perl pero tambien posee un modulo escrito en el lenguaje Java. Por otra parte, la
mayora de las aplicaciones estan hechas en plataforma web, pero la aplicacion dedicada a imprimir
las facturas (la que esta escrita en Java) es un software independiente que se debe instalar en cada
computador en donde se quiera usar, debiendose configurar cada uno de ellos de forma individual.
3
En la actualidad se facturan alrededor de 4000 dominios mensuales.
Cuando el operador del actual Sistema de Facturacion comete algun error o no sigue estrictamente una secuencia de pasos durante el proceso, se generan inconsistencias en los datos, generando anulaciones de facturas y la repeticion del proceso desde el inicio. La reparacion de las inconsistencias generadas no es una funcionalidad al alcance de los operadores del Sistema de Facturacion,
ante lo que deben recurrir a personas externas a su a rea para solucionar la inconsistencia y poder
seguir 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 ejemplo, para el caso de que se deben emitir varias facturas para un mismo RUT pero con distinta
direccion, el sistema actual genera una sola factura que tiene como direccion de envo la del primer
tem de la factura, generando los correspondientes reclamos de los clientes a los cuales nunca les
llega la factura y de otros que reciben en sus facturas temes que ellos no cancelaron, situacion
comun para el caso de empresas clientes con muchas sucursales.
En el ano 1997 el Servicio de Impuestos Internos, comenzo a analizar el tema de Documentos Tributarios Electronicos (DTE). Este tema atrajo a NIC Chile, por lo cual forma parte de las
empresas que participan en el programa Piloto de emision de DTEs, en particular la emision de
Facturas Electronicas. Dada esta situacion y considerando las limitaciones antes mencionadas, resulta sumamente conveniente comenzar con el desarrollo de un nuevo Sistema de Facturacion que
permita realizar tanto facturacion manual como facturacion electronica.
Por otra parte, debido a la creciente demanda de los servicios de NIC Chile, como la necesidad
de incorporar nuevas funcionalidades se comenzo un proyecto de renovacion de todo el software
que usa el sistema, de modo que el desarrollo de un nuevo sistema de Facturacion se enmarca dentro
de la planificacion 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, funcionamiento 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 el

captulo 4.
Unicidad de plataforma y lenguaje de programacion.
Un sistema Modular, en donde se especifique que modulos se encargan de que tareas con la
correspondiente documentacion.
Flexibilidad de manipulacion para los operadores, entregarles las herramientas necesarias
para 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, evitando caer en las limitaciones identificadas en el sistema actual y agregando las funcionalidades
especificadas en los objetivos y en el captulo 4.
La implementacion abarca todo el sistema disenado, integrando las funcionalidades ya hechas
para generar DTE y las modificaciones necesarias de acuerdo a los u ltimos 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 a
las implementaciones ya hechas para generar facturas electronicas, de acuerdo a las modificaciones
enviadas por el SII. Ademas, se complemento el trabajo con la generacion de los archivos con
formato 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 sistemas
en 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 como
envos de facturas entre NIC Chile y la Facultad de Ciencias Fsicas y Matematicas, para el sistema
Informat.
Captulo 2
Antecedentes
2.1. Introduccion
Este captulo se referira a los antecedentes recopilados de la operacion del actual Sistema de
Facturacion de NIC Chile. Ademas, se mostrara un resumen de la operacion con Documentos
Tributarios Electronicos, definidas desde el SII; esta operacion se incluye con el objetivo de que el
lector conozca el medio ambiente bajo el cual se desempenara el sistema, que debe integrarse con
la emision de Documentos Tributarios Electronicos.
Si el lector desea tener mayores antecedentes sobre la emision de los DTEs, el como se llego al
modelo y el uso de la criptografa, puede encontrar una informacion mas detallada en la segunda
referencia bibliografica de esta memoria.
2.2. Modelo Actual de Facturacion en NIC Chile

El proceso actual de facturacion para los dominios comienza desde que NIC Chile recibe reportes 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 Pagos denominada ToDo. El actual sistema esta restringido solo a generar facturas por pagos de
dominios, 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 se
ha impreso una factura.
3. El operador pide al sistema que agrupe el pago de todos aquellos dominios que registren el
mismo 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 por
Rut.
6. El operador asocia las facturas impresas con los respectivos numeros de serie que vienen
preimpresos en el papel de las facturas.
7. Para cada una de las facturas impresas anteriormente, el operador imprime una nomina con
el 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 un
dominio cancelado por RUT.
9. El operador asocia las facturas impresas con los respectivos numeros de serie que vienen
preimpresos en el papel (ahora para las facturas no agrupadas).
10. El operador separa las distintas copias que componen una factura, dejando dos copias para el
cliente, 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 facturas
impresas.
1
Webpay o Servipag.
12. El operador entrega las facturas impresas al correo, anexando una copia del listado impreso
en el paso anterior.
13. El operador enva un email a la empresa de correo con el detalle de todas las facturas procesadas durante el da.
Cabe mencionar que el papel de una factura en blanco (sin imprimir) posee 5 copias, y posee
un numero de serie impreso. De las 5 copias preimpresas, 2 son enviadas al cliente por correo, 2
son usadas para el sistema de contabilidad (copias de color azul y cafe) y una es almacenada como
respaldo por el a rea de facturacion (copia de color verde).
El sistema de facturacion genera listados de facturas que son enviados al sistema Informat. El
envo de los listados de facturas deben seguir la siguiente secuencia, establecida desde el a rea de
contabilidad 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 mismo
tiempo, se debe enviar de forma manual el listado de las copias de color cafe en grupos de 40
facturas. 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 tanto
en forma digital como en forma manual y dan la autorizacion para el ingreso de las copias
azules de las facturas.
Envo de grupos de 30 facturas: De las facturas que autorizo Informat, se envan en grupos
de 30 las copias azules, separadas por medio de pago. El envo se hace en forma digital y en
forma manual. Estos grupos estan identificados por un numero de folio, que es para el control
interno 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, es
el de la figura 2.1.
WebPay
Servipag
proc_servipag
webpay_paga
TODO
Imprimir
(Java)
Facturar
por RUT
Nmina
por RUT
Emitir
Operario
Enviar
Nmina
6
Enviar
Mail
Figura 2.1: Diagrama Sistema Actual de Facturacion.
2.3. Documentos Tributarios Electro nicos

El estudio de las definiciones y modelo de operacion de los DTE comenzo en el ano 1997, por
parte del SII, poniendose en marcha el plan Piloto a mediados del ano 2002, en el cual participan
alrededor de 7 empresas de distintos rubros.
El modelo de operacion de los DTE, incorpora metodos que permiten verificar la veracidad e
integridad de los documentos emitidos, de la misma forma incorpora metodos para la fiscalizacion
del SII sobre las operaciones comerciales que estos respaldan. Ademas, incluye un medio de autorizacion de folios, que cumple la misma funcion fiscalizadora del timbre de cuno, en la operacion
con 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 corriente
en impresoras de libre acceso en el mercado. Esta version impresa incluye un codigo de barras de
2 dimensiones, por medio del cual se verifica la validez del DTE.
El modelo de operacion con DTEs abarca 7 etapas, las que son explicadas en las siguientes
subsecciones.
2.3.1. Enrolamiento en el Sistema

Es la etapa en donde el contribuyente se inscribe en el SII como emisor de DTEs. Al enrolarse
en el sistema, NIC Chile debe identificar los funcionarios de NIC Chile que estaran autorizados
para emitir DTEs, los cuales deben poseer certificados digitales validos a la fecha, emitidos por
alguna autoridad certificadora autorizada por el SII.
Estas personas son las u nicas autorizadas para solicitar folios para el contribuyente, y pueden
ser 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 obligado
a aplicar sobre sus documentos en papel, antes de utilizarlos. Para aplicar este timbre, el contribuyente debe acudir a la Unidad del SII que corresponde a su domicilio, llevando los documentos
que desea timbrar con los numeros de folios preimpresos.
En el modelo de operacion con DTEs del SII, el contribuyente solicitara va Web las autorizaciones de folios para un tipo de Documento2 , evitando el concurrir a las dependencias del SII. En
reemplazo del timbre de cuno, el contribuyente recibira va electronica un codigo de autorizacion
para emitir los DTEs.
2
Facturas para el piloto
11
La solicitud de un rango de folios comienza cuando la(s) persona(s) autorizada(s) se autentifican en el sitio web del SII, usando su certificado digital. El SII verificara la validez de los
datos y del certificado en sus registros. Luego el SII entregara al solicitante el rango de folios que
segun sus polticas internas autorizo, armando un conjunto de datos segun lo especificado en el
documento Especificacion de Codigos de Autorizacion y de Timbres de Documentos Tributarios
Electronicos[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 certificado 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 definido en el documento Formato de Documentos Tributarios Electronicos[2], el cual debe contener los valores equivalentes a los contenidos
en un documento tributario tradicional en papel.
Ademas de la informacion habitual de un documento tributario (RUT de emisor, fecha de
emision, direccion del emisor, RUT del receptor, razon social del receptor, direccion del receptor, modo de pago, lneas de detalle y otros), el emisor debe generar un Timbre electronico u nico
para cada DTE. El timbre esta compuesto por 3 elementos:
12
1. Datos Representativos: Corresponden a la Version del timbre que generara el emisor, RUT
del emisor, el tipo del DTE, el numero de Folio, fecha de emision del DTE y el monto total
del DTE.
2. Firma Digital sobre los datos representativos: Usando el certificado que el contribuyente
indico que utilizara para generar DTEs (cuando solicito la autorizacion del rango de folio al
cual pertenece el DTE a emitir segun su tipo y numero de folio asignado), el emisor procede
a firmar 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 define el documento Especificacion de Codigos de Autorizacion y de Timbres de Documentos Tributarios Electronicos[2] en el
documento XML, que constituye el DTE segun lo define el documento Formato de Documentos
Tributarios Electronicos[2].
Finalmente, el contribuyente debe firmar digitalmente el documento completo XML que constituye el DTE segun lo define el documento Firma Digital de Documentos XML relativos a la
operacion con Documentos Tributarios Electronicos[2], utilizando el certificado digital que se
haya definido para ese fin.
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 de
libre acceso en el mercado. Esta version impresa, esta orientada principalmente a los receptores no
electronicos y a los documentos que deben acompanar mercadera como las Guas de Despacho.
Antes de imprimir un DTE, e ste debe ser generado como se menciono anteriormente, luego se
deben:
Imprimir en un papel sus valores en el orden y formato definidos en el documento Normativa

de Impresion en Papel de Documentos Tributarios Electronicos[2].
El timbre del documento se imprime como un codigo de barras bidimensional con simbologa
PDF417.
13
Un ejemplo de un DTE impreso es el que se muestra en la figura 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 de
DTEs; y el receptor manual, el cual opera con la forma tradicional con los documentos tributarios
en papel. Este u ltimo, recibira una version impresa del DTE o lo imprimira el mismo.
El receptor electronico debera verificar la validez y vigencia del certificado digital que se utilizo para firmar el archivo XML de cada DTE que reciba. Ademas, de verificar que ese certificado
esta habilitado para firmar DTEs en nombre del emisor. La validez de la firma digital del DTE, permite al contribuyente receptor estar seguro de que el DTE fue emitido efectivamente por el dueno
del certificado digital y ademas le permite probar la irrefutabilidad (no repudiacion) del DTE, es
decir, el emisor no podra renegar la autora del DTE.
Luego, el receptor electronico debera verificar la correctitud de los datos del Timbre del DTE.
Para esto debe comprobar inicialmente que los datos representativos del DTE sean los mismos que
contiene el Timbre, que el RUT del emisor y tipo de DTE sean los mismos que los contenidos en el
codigo de autorizacion contenido en el timbre, y que el numero de folio este dentro del rango que
autoriza el mismo codigo.
Por u ltimo, el receptor debe verificar que los datos del DTE, indiquen que esta destinado a su
RUT y Razon Social.
Si alguna de estas validaciones fallasen, el receptor podra rechazar el DTE sin hacer registro
contable de e l. En caso que las validaciones sean correctas, pero se encuentre alguna discrepancia
cuando se verifiquen las condiciones comerciales, se operara de la misma forma tradicional de los
documentos tributarios sustentados en papel, corrigiendo la situacion va la correspondiente nota
de credito o de debito.
El receptor no electronico solo recibe el DTE en su version impresa y solo puede verificar
si un numero de folio ha sido autorizado o no por el SII. Para esto, el SII habilitara un sistema
de verificacion 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 folio
esta 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 verificacion de la firma digital del
documento XML y del timbre. Es decir, el SII actua como un receptor electronico adicional. Los
documentos que no verifiquen el timbre o la firma digital, seran rechazados por el SII y, por lo
tanto, no tendran derecho a credito fiscal.
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 la
copia fiel 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 el
numero de folio de un DTE. SII respondera si ha recibido y aceptado una emision de ese folio para
ese RUT emisor, en caso de ser verdadero, entregara el valor de la firma digital.
El receptor electronico comparara la firma digital entregada por el SII contra la firma digital
del DTE, en caso de ser equivalentes, el receptor puede estar seguro de que el DTE que posee es la
copia fiel 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 donde
el receptor debera indicar el RUT del emisor, el tipo y numero de folio del DTE, a lo que el SII
contestara si estos valores corresponden a la copia del DTE presente en sus bases de datos.
16
2.3.7. Fiscalizacion en Terreno

Para la fiscalizacion en terreno los inspectores del SII estaran en posesion de un computador de
bolsillo y un lector de codigos de barras.
Cuando se traslade mercadera, debe ir acompanada de la version impresa del DTE que la
valida. El inspector hara uso del lector de codigos de barras para obtener el valor del timbre y del
computador de bolsillo para verificar el timbre.
Por otro lado, el SII podra requerir el envo va Internet del archivo de auditora del contribuyente, para fiscalizacion 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, se
debe generar una nota de credito para corregir la situacion, la cual debera estar claramente indicada
como 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 credito
emitida para la anulacion. Este procedimiento es obligatorio en el caso de que el RUT del receptor
sea erroneo, no pudiendo en este caso utilizarse el metodo de correccion establecido en el oficio
numero 105 de 1990 (referido a la correccion de campos como RUT, nombre y giro). Si el error
se produce en una nota de credito, se debera emitir una nota de debito tambien con la marca de
anulacion, 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 con
la marca de anulacion, haciendo referencia a ambos documentos: la factura original y la nota de
debito.
En caso que el documento ya haya sido enviado al receptor y se detecte un error en e l, tambien
se 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 definir como se
manejara el flujo de la informacion dentro de la aplicacion, para lo cual existen diversos Framework
en diversos lenguajes. Esta memoria esta basada en el Framework Struts, del proyecto Jakarta
de Apache, la cual funciona en un medio ambiente con lenguaje Java. En este captulo, se muestra
desde la historia hasta ejemplos de archivos de configuracion e implementacion de un sistema
desarrollado con Struts informacion obtenida principalmente del sitio web de Apache [8] y de un
manual realizado por Juan Antonio Palos [12].
Para entender a cabalidad los temas expuestos en este captulo es necesario que el lector tenga conocimientos previos de Java Servlets, JavaServer Pages y JavaBeans. En caso contrario se
recomienda 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 obtuvo
una herramienta mas rapida y potente que el CGI estandar. Los servlets eran portables, y extensibles. El problema de los Servlets es que para enviar una lnea de codigo HTML al navegador era
necesario ejecutar una instruccion, situacion que se complicaba cuando el resultado de la ejecucion del Servlet son muchas lneas de HTML. La solucion a este problema fue la aparicion de las
JavaServer Pages (JSP en adelante), que permitan escribir Servlets dentro de ellas, as se poda
mezclar codigo HTML con Java, manteniendo todas las ventajas de los Servlets.
As las aplicaciones web desarrolladas en Java se convirtieron rapidamente en aplicaciones
centralizadas en JSP (conocido como el Modelo 1), lo que no era malo en si mismo, pero no
resolva el problema del control de flujo y otros, dentro de las aplicaciones web, dejando en claro
la necesidad de otro modelo.
Cuando los desarrolladores web se dieron cuenta de que los JSP y los Servlets se podan usar
juntos, con los JSP encargados solo de escribir el codigo HTML en el navegador y los Servlets
del control de flujo de los datos, nacio el Modelo 2 para el desarrollo de las aplicaciones web en
Java. 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 un
marco de trabajo MVC estandar a la comunidad que desarrolla aplicaciones web en Java. En Julio
del 2001, se libero Struts 1.0[8].
MVC
3.1.2. Patron de Diseno
En el patron de diseno MVC, el flujo de la aplicacion esta dirigido por un Controlador central. El
Controlador delega solicitudes (en el caso de aplicaciones web corresponden a solicitudes HTTP) a
un manejador apropiado. Los manejadores estan unidos a un Modelo, y cada manejador actua como
un adaptador entre la solicitud y el Modelo. El Modelo representa o encapsula, un estado o logica
de negocio de la aplicacion. Luego, el control normalmente es devuelto a traves del Controlador
hacia la Vista apropiada.
19
El reenvo puede determinarse consultando los conjuntos de mapeos, normalmente cargados

desde una base de datos o un archivo de configuracion. Esto proporciona un acoplamiento cercano
entre la Vista y el Modelo, que puede hacer las aplicaciones significativamente mas faciles de crear
y de mantener.
En la figura 3.1 se puede visualizar un esquema de este Patron de Diseno.
Modelo
- Muestra la
funcionalidad de la
aplicacin
- Responde a los
requerimientos
- Agrupa los estados
de las aplicaciones
- Notifica a la Vista de
los cambios
Consulta
de estado
Cambios de
Estado
Notificaciones
de cambios
Seleccin de Vista
Vista
- Permite al Controlador
seleccionar las vistas
- Envia las acciones del
usuario al Controlado
Acciones de usuarios
- Solicitudes actualizadas
desde el Modelo
- Interpreta el Modelo
Controlador
- Uno por cada
funcionalidad
- Selecciona la visual
para la respuesta
- Mapea las acciones del
Usuario a actualizaciones
del Modelo
- Define el comportamiento
de la aplicacin
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 la
logica de negocio de la aplicacion (o el modelo).
El servlet controlador Struts une y enruta solicitudes HTTP a otros objetos del marco de trabajo, 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 configuracion de

recursos, el que define (entre otras cosas) el mapeo de acciones para una aplicacion. El controlador
usa estos mapeos para convertir las solicitudes HTTP en acciones de aplicacion.
El mapeo de acciones normalmente definira: 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 navegador
Web), o indicar a que control debera ser reenviado. Por ejemplo, si el ingreso de un nombre de
usuario y contrasena en un formulario tiene e xito, una accion asociada podra ser el reenviar la
peticion hacia el Menu principal de la aplicacion.
Los objetos Action tienen acceso al servlet controlador de la aplicacion, y por eso tienen acceso
a los metodos del servlet. Cuando se reenva un control, un objeto Action puede reenviar indirectamente uno o mas objetos compartidos, incluyendo JavaBeans, situandolos en una de las colecciones
estandar compartidas por los servlets Java.
Un objeto Action puede crear un bean de tarjeta de compra, o un tem de la tarjeta, situando el
bean en la coleccion de la sesion, y luego reenviando el control a otro mapeo. Este mapeo podra
usar una pagina JSP para mostrar los contenidos de la tarjeta del usuario. Como cada cliente tiene
su propia sesion, cada uno tambien tendra su propia tarjeta de compra. En una aplicacion Struts, la
mayora de la logica del negocio se puede representar usando JavaBeans. Una Action puede llamar
a las propiedades de un JavaBean sin conocer realmente como funciona. Esto encapsula la logica
del 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 problema
clave en el diseno de aplicaciones Web es retener y validar lo que el usuario ha introducido entre solicitudes. Con Struts, se puede definir un conjunto de clases bean formulario (subclases de
org.apache.struts.action.ActionForm), y almacenar facilmente los datos de un formulario de entrada en estos beans formularios. El bean se graba en una de las colecciones estandar o de contexto
compartidas, por eso puede ser usado por otros objetos, especialmente un objeto Action.
Un bean de formulario Struts se declara en la configuracion de recursos definida en un archivo
fuente Java, y enlazado a un ActionMapping usando un nombre de propiedad comun. Cuando una
solicitud llama a un Action que usa un bean de formulario, el servlet controlador recupera o crea el
bean 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 mensajes
a manejar por el formulario. Cuando esta listo, el objeto Action puede devolver el control con un
reenvo a su formulario de entrada, usando un JSP. El controlador puede responder a la solicitud
HTTP y dirigir al cliente al JSP correspondiente.
El marco de trabajo Struts incluye etiquetas personalizadas que pueden rellenar automaticamente los campos de un formulario o un bean de formulario. Lo u nico que la mayora de las
paginas JSP necesitan saber sobre el resto del marco de trabajo son los nombres de los campos
apropiados y donde enviar el formulario. Los componentes como los mensajes encoladospor el
Action pueden salir usando una simple etiqueta personalizada. Tambien se pueden definir otras
etiquetas especificas 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 caractersticas de internacionalizacion incluidas en la plataforma Java. Todas las etiquetas de campos
y los mensajes pueden recuperarse desde un recurso de mensajes y Java puede proporcionar automaticamente el recurso correcto para el idioma y pas de un cliente. Para proporcionar mensajes
para otro idioma, simplemente se agrega otro archivo con las etiquetas escritas en dicho idioma.
Junto al internacionalismo, otros beneficios de esta aproximacion son las etiquetas consistentes
entre formularios y la posibilidad de revisar todas las etiquetas y mensajes desde una localizacion
central (en el archivo en donde estan definidas).
Un diagrama de como funcionara el patron MVC con Struts, en un aplicacion web, se muestra
en la figura 3.2.
3.2. Modelo
El procesamiento de cada solicitud enviada a la aplicacion web esta definida en el Modelo.
En general, el desarrollador de componentes del Modelo, se enfocara en la creacion de clases
JavaBeans que soporten todos los requerimientos de funcionalidad. La precision natural de los
beans requeridos por una aplicacion particular variara mucho dependiendo de esos requerimientos,
pero generalmente pueden clasificarse en varias categoras descritas en la siguiente subseccion. Sin
embargo, primero es u til una breve revision del concepto de a mbito en relacion con los beans y JSP.
22
1. Solicitud
2. Acciones
Controlador
(Servlets)
3. Resultados
Model
(JavaBeans)
4. Redireccionamiento
Navegador
Cliente
5. Consulta
6. Resultado
Vista
(JSPs, TagLibs)
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 atributos diferentes. Cada coleccion tiene diferentes reglas para el tiempo de vida de esa coleccion, y
la visibilidad de los Beans almacenados en ella. Las reglas que definen el tiempo de vida y la
visibilidad se llama el a mbito de esos beans. La especificacion JSP define las elecciones de a mbito
usando los siguientes terminos:
page: Beans que son visibles dentro de una sola pagina JSP para el tiempo de vida de la
solicitud actual.
request: Beans que son visibles dentro de una sola pagina JSP, as como en cualquier pagina
o servlet que este incluido o reenviado por esta.
session: Beans que son visibles para todas las paginas JSP y los servlets que participan en
una 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 forman
parte 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], que
Struts generalmente asume que se ha definido para cada formulario de entrada en la aplicacion
web. Si se declaran estos beans en el archivo de configuracion del mapeo de acciones, el servlet
controlador realiza automaticamente las siguientes acciones:
Chequea en la sesion de usuario si hay un ejemplar de un bean de la clase apropiada, bajo la

clave apropiada.
Si no esta disponible dicho bean en el a mbito de la sesion, se crea uno nuevo automaticamente
y se anade a la sesion de usuario.
Por cada parametro de la solicitud, cuyo nombre corresponda con el nombre de una propiedad
del bean, se llamara al correspondiente metodo set().
El bean ActionForm actualizado sera pasado al metodo perform() de la clase Action cuando
es llamado, haciendo que esos valores esten disponibles inmediatamente.
Para la codificacion de los beans ActionForm, se deben considerar los siguientes principios:
1. La propia clase ActionForm no requiere que se implemente ningun metodo especfico. Se usa
para identificar el rol que esos beans particulares juegan en la arquitectura general. Normalmente, 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 sobreescribe un metodo stub, y se proporciona mensajes de error en el recurso de aplicacion
estandar, Struts validara automaticamente la entrada del formulario.
3. Definir una propiedad (asociada con metodos getXxx() y setXxx()) para cada campo que
este presente en el formulario. El nombre del campo y el nombre de la propiedad deben
corresponder de acuerdo a las convenciones usuales de los JavaBeans. Por ejemplo, un campo
de entrada llamado username hara que se llame al metodo setUsername().
4. Se debe pensar en los beans ActionForm como un firewall entre el requerimiento HTTP
y el objeto Action. Usando el metodo validate se puede asegurar de que estan presentes todas
las propiedades requeridas, y que contienen valores razonables. Un ActionForm que falla en
la 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 ejemplo, se podra tener un bean customer en el Action Form, y luego referirse a la propiedad
customer.name en la vista JSP. Esto correspondera con los metodos customer.getName() y
customer.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 modificando a lo largo de su interaccion con la
aplicacion. Estos objetos de negocio seran tpicamente JavaBeans de los que se guardara la referencia en la sesion del usuario, los que seran modificados desde los Action y que seran consultados
desde 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 ser
disenados e implementados para que no sepan que estan siendo ejecutados en un entorno de aplicacion Web. Si por algun motivo es necesario importar una clase javax.servlet.* en el bean, se
esta ligando esta logica de negocio al entorno de una aplicacion Web, lo que no es correcto y se
debera considerar reordenar las cosas, para que las clases Action traduzcan toda la informacion
requerida 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 un
metodo execute(). Dicha clase de logica de negocio podra reutilizarse en entornos distintos al de
la 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 la
interfaz de usuario o con otros sistemas. Struts provee soporte para construir aplicaciones multiidioma, 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 despliegue
de dichas aplicaciones sobre Internet y otras redes accesibles, han hecho que los lmites nacionales
sean invisibles en muchos casos. Esto se ha traducido en la necesidad de que las aplicaciones
soporten la internacionalizacion y localizacion.
Struts se construye sobre la plataforma Java, proporcionada para construir aplicaciones internacionalizadas y localizadas. Los conceptos claves para familiarizarse con ellos son:
Locale: La clase fundamental Java que soporta internacionalizacion es java.util.Locale. Toda

clase de tipo Locale representa una eleccion particular de pas e idioma (ademas de variantes
opcionales del idioma) y tambien un conjunto de utilidades de formateo para cosas como los
numeros y las fechas.
ResourceBundle: La clase java.util.ResourceBundle proporciona la herramienta fundamental para el soporte de mensajes en varios idiomas.
PropertyResourceBundle: Una de las implementaciones estandar de ResourceBundle que
nos permite definir recursos usando la misma sintaxis nombre=valor usada para inicializar
26
los archivos de propiedades. Esto es muy conveniente para preparar paquetes de recursos con
mensajes que son usados en una aplicacion Web, porque estos mensajes normalmente estan
orientados a texto.
MessageFormat: La clase java.text.MessageFormat permite reemplazar partes de un mensaje (en este caso, recuperado de un paquete) con argumentos especificados en tiempo de
ejecucion. Esto es u til en casos donde se esta creando una sentencia, pero las palabras podran 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 debe
reemplazar por el segundo argumento, y as sucesivamente.
MessageResources: La clase Struts org.apache.struts.util.MessageResources permite tratar

un conjunto de paquetes de recursos como una base de datos, y ademas permite solicitar una
cadena de mensajes particular para una Localidad particular (normalmente asociado con el
usuario actual) en lugar de la localidad por defecto, en la que el propio servidor se esta ejecutando.
El soporte de la internacionalizacion en un marco de trabajo como Struts esta limitado a la

presentacion de texto e imagenes internacionalizadas al usuario. El soporte para localidades especficas con metodos de entrada (usado con idiomas como el Japones, el Chino y el Koreano) se
deja 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 de
esta memoria.
3.3.2. Interacciones de Forms y FormBean

Es comun en los desarrollos web el construir formularios usando las capacidades estandar del
HTML, como la etiqueta <input>. Los usuarios esperan que las aplicaciones interactivas tengan
ciertos comportamientos y uno de estos esta relacionado con el manejo de errores (si el usuario
comete un error, la aplicacion debera permitirle corregir solo lo que necesita ser modificado) sin
tener que reintroducir cualquier parte del resto que esta bien de la informacion de la pagina o
formulario 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 para
un campo username podra parecerse a esto (en JSP):
<input type="text" name="username"

value="<%= loginBean.getUsername() %>"/>
Este caso, usando Struts sera:
<html:text property="username"/>
Sin la necesidad de referirse explcitamente al formulario JavaBean del que se recupera el valor
inicial. Esto lo maneja automaticamente el marco de trabajo.
Algunos ejemplos con codigo fuente para la construccion de formularios se pueden ver en la
seccion 8.5.
3.4. Controlador
Luego de entender las componentes de la Vista y el Modelo de la aplicacion, corresponde
analizar las del Controlador. Struts incluye un servlet que implementa la funcion de mapear desde
una 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.
Configurar un ActionMapping (en XML) por cada solicitud logica que podra ser enviada. El
archivo de configuracion XML normalmente se llama struts-config.xml.
28
Actualizar el archivo del descriptor de despliegue de la aplicacion Web (en XML) para que
la 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 identifica
donde se debera reenviar el control, para proporcionar una respuesta adecuada.
Una clase Action tpica implementara una logica que comenzara validando el estado actual de
la sesion del usuario, verificando 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, la
clase 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 y
reenva 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 clase
Action o realizando llamadas a un metodo apropiado de un bean de la logica del negocio. A continuacion, debe actualizar los objetos del lado del servidor que seran usados para crear la siguiente
pagina de la interfaz con el usuario.
Finalmente, devuelve un objeto apropiado que identifica algun elemento de la vista (una pagina
JSP, por ejemplo), basada en los beans actualizados recientemente.
Las clases Action presentan algunos problemas de diseno, como que el servlet controlador crea
una sola instancia de la clase Action y la usa para todas las solicitudes, por lo que, si se quiere
operar correctamente en un ambiente multi-thread, se debe codificar 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 liberar
esos recursos (como las conexiones a una base de datos), antes de reenviar el control al componente
de la Vista apropiado.
3.4.2. La Implementacion de ActionMapping

Para poder operar correctamente, el servlet Controlador necesita conocer varias propiedades
sobre como se debera mapear todo un requerimiento solicitado a una clase Action apropiada, ese
conocimiento se encapsula en una interface Java, llamada ActionMapping, en donde las
propiedades mas importantes son:
type: Nombre totalmente cualificado de la clase Java que implementa la clase Action usada
por este mapeo.
name: El nombre del bean de formulario, definido en el fichero de configuracion que usara 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 invocado su mapeo.
En la seccion 8.5.2 de esta memoria se puede revisar un completo archivo con la configuracion
de los mapeos del Action y sus correspondientes comentarios.
3.4.3. Descriptor de Despliegue de la Aplicacion Web

El paso final en la configuracion de la aplicacion, es configurar el descriptor de despliegue para
incluir todos los componentes que son necesarios.
30
Un completo archivo de ejemplo del descriptor de despliegue de la aplicacion, con los correspondientes comentarios se puede visualizar en la seccion 8.5.3.
3.4.4. Configurar el Mapeo del Servlet Action

Existen dos aproximaciones comunes para definir las URLs que seran procesadas por el servlet
controlador: correspondencia de prefijo y correspondencia de extension.
La correspondencia de prefijo indica que todas las URLs que empiecen con un valor particular
sean pasadas a este servlet. Por otro lado, en el mapeo por extension, se reenvan las URLs solicitadas al servlet action basandose en que la URL termina en un punto seguido por un conjunto
definido de caracteres. Por ejemplo, para la correspondencia de prefijo se podra tener:
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>/execute/*</url-pattern>
</servlet-mapping>
Lo que significa que una URL que coincida con el path /logon descrito anteriormente podra
parecerse 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:
<servlet-mapping>
31
<url-pattern>*.do</url-pattern>
</servlet-mapping>
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 definir la librera de etiquetas de Struts, en la actualidad vienen 4 libreras.
Las que son:
1. struts-bean: Contiene etiquetas u tiles para acceder a los beans y sus propiedades, as como
para definir nuevos beans (basados en esos accesores) que son accesibles para el resto de la
pagina mediante variables de scripting y atributos de a mbito de pagina. Tambien se proporcionan 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 etiquetas generalmente u tiles en la creacion de interfaces de usuario basados en HTML [11].
3. struts-logic: Contiene etiquetas que son u tiles para manejar la generacion condicional de
salida de texto, hacer ciclos sobre colecciones de objetos para generacion repetitiva de salida
de texto y control del flujo de la aplicacion [10].
4. struts-template: Contiene etiquetas que definen un mecanismo de plantillas.
En la seccion 8.5.3 se incluye un archivo que contiene una definicion ejemplo de libreras de
etiquetas.
32
Captulo 4
Requerimientos
4.1. Introduccion
Con los antecedentes revisados en el captulo 2, es necesaria la definicion de los requerimientos
de Interfaces y los requerimientos Funcionales, como la identificacion de los Casos de Uso junto
con 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 Comunicacion, en las primeras se abarcan las conexiones a Bases de Datos y en las segundas se mencionan
como 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 desde
Webpay y Servipag y con el actual sistema de registro de dominios que posee NIC Chile, desde el
cual debe obtener los datos necesarios para poder generar las facturas.
Para la generacion de facturas electronicas, el sistema se debe comunicar con el software que
obtiene la informacion desde el SII, como por ejemplo los numeros de folios. Ademas de comunicarse con los modulos que generan el timbre y la firma electronica.
Para la generacion de facturas tanto electronicas como manuales, el sistema se debe comunicar
con una base de datos que maneja todos los RUT de los contribuyentes del SII, junto con las razones
sociales, a fin de verificar que la razon social para la cual se emite una factura exista en la base de
datos 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 acceder
desde la pagina principal de Administracion, la que usan los distintos operadores de la organizacion, en sus distintas labores. Los protocolos de comunicacion son los mismos que los del sitio
de Administracion.
Para la comunicacion con el SII, se usaran las paginas que ellos dispongan para los contribuyentes electronicos.
34
4.3. Requerimientos Funcionales

Los requerimientos funcionales que debe cumplir el Sistema, junto con su explicacion, son los
siguientes:
1. El sistema debe identificar 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, e ste queda con la factura pendiente. Todos los dominios que esten
en el estado pendiente de factura deben ser identificados 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, para
lo cual es necesario imprimir una sola factura por la cantidad de dominios que el cliente
cancelo1 .
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 emitir
facturas, si no que solo comprobantes internos de venta. Ademas, se tienen otros clientes que
necesitan recibir las facturas de forma separada (caso de sucursales) y no todas agrupadas
por 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 que
es probable que el operador no alcance a cumplir con el proceso de facturacion para todos
los dominios pendientes, de esa forma, se le debe permitir facturar un subconjunto de las
pendientes.
5. Debe permitir asociar un numero de serie con la factura impresa. De paso, se debe modificar
el 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 identificador de la factura, por lo que debe estar asociado al registro
del dominio, para posteriormente obtener a quien se emitio dicha factura.
6. Debe permitir volver a iniciar el proceso completo de facturacion, para aquellas facturas que
por algun motivo no fueron impresas correctamente.
1
En 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 impresora
falla durante la impresion (falla electrica, tecnica, etc) se debe poder iniciar el proceso de
facturacion 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 generar
tantas facturas como sea necesario.
Este numero de facturas estara determinado de acuerdo a la relacion numero de lneas de
glosa 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 la
empresa de correos.
La empresa que despacha las facturas a los domicilios de los clientes necesita un listado de
todas 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 enviadas
fsicamente a ellos.
La empresa que despacha las facturas necesita recibir un email con el listado de las facturas
que se les envio, con el fin de comprobar que las facturas que ellos reciben desde NIC Chile
son las mismas que se muestran en el listado. Dicho email es el u nico listado en formato
digital que ellos reciben.
10. Debe generar reportes u tiles, 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 a rea de facturacion estan diseminados en
distintos sistemas. Es necesario que se centralice la generacion de los informes, a modo de
poder 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 cual
solo existe en la Facultad de Ciencias Fsicas y Matematicas. El Jefe Administrativo lo solicita, con el objetivo de tener la informacion mas accesible y poder conocer los informes en
cualquier momento sin tener que esperar los reportes desde la Facultad de Ciencias Fsicas y
Matematicas.
12. Debe tener modos de validacion de datos.
NIC Chile tiene registro de dominios desde el ano 1997, los cuales al ser renovados 2, se les
2
Cada 2 anos
36
debe generar una factura. Estos dominios, podran tener datos erroneos (por ejemplo, razones
sociales 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 manual los datos necesarios.
NIC Chile emite facturas de forma automatica solo por ventas de dominios, eventualmente se
podran 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 desarrolla por 2 medios distintos y por personas distintas. El nuevo Sistema de Facturacion debe
incorporar la generacion de los informes para Informat, con todas las reglas que este sistema
impone.
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 nuevo
sistema debe ser capaz de poder generar facturas de forma electronica y manual indiferentemente. Para la generacion de facturas electronicas se deben adaptar las mismas funciones, a
modo de no cambiar en su totalidad el modo de operacion, cumpliendo con los requerimientos 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 electronica el canal de comunicacion definido es Internet, por lo que un sistema construido en
plataforma 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 el
desarrollo de un sistema interno en el lenguaje Java, por esta razon se solicito al autor de esta
memoria 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 actores
que las realizaran, se utilizaron casos de uso. En las siguientes subsecciones se muestran los actores
y los correspondientes diagramas de casos de uso.
4.4.1. Actores
Los siguientes son los actores identificados para el sistema:
Operador: Persona que usara el sistema mas frecuentemente. Es el encargado de cumplir

con todo el proceso de facturacion, tanto de forma manual como electronico, dependiendo de como se este operando. Corresponden a los actuales operadores de facturacion y de
contabilidad.
Jefe Administrativo: Usuario que utiliza el sistema para revisar los informes de estadsticas
del Sistema, como: distribucion de dominios por localidades, por medio de pago, etc. Tambien debe tener la opcion de poder facturar.
Administrador: Persona que controla la configuracion del sistema. Indica las excepciones
en el proceso de facturacion y algunos datos tecnicos como especificacion de la impresora.
Ademas maneja la administracion de usuarios, como creacion, modificacion, eliminacion y
definicion de permisos.
4.4.2. Diagramas de Casos de Uso

En la figura 4.1 se presenta un diagrama de casos de uso, los cuales son explicados uno a uno en
las subsecciones siguientes. En el diagrama se aprecia un caso de uso llamado Emitir DTE el cual
se explica para que el lector tenga un mejor conocimiento de que trata la emision de una Factura
Electronica[2], tema que no se abarca ni implementa en la presente memoria.
38
Imprimir
Factura
Ver
Informes
Jefe
Administrativo
Asociar
Nmero
Configurar
Sistema
Operario
o
Jefe
Administrativo
Enviar
Facturas
Administracin
de Usuarios
Crear
Factura
Emitir
DTE
Administrador
Listados
Informat
Operario
o Jefe
Administrativo
Editar
Facturas
Figura 4.1: Diagrama de casos de uso del Sistema.
Estos casos de uso se obtuvieron integrando las funcionalidades actuales del sistema de facturacion con los nuevos requerimientos, explicados en la seccion 4.3 de este captulo.
39
4.4.3. Caso de Uso: Imprimir Facturas

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Paso
1
2
3
Paso
3a
Imprimir Facturas
Que el operador del sistema pueda enviar a la impresora las facturas que previamente selecciono para imprimir.
Operador
Solicitud de imprimir por parte del Operador.
El usuario selecciono un grupo de facturas pendientes para imprimir.
El sistema enva las facturas a la impresora y genera un mensaje
al operador si se imprimieron bien.
El sistema genera un mensaje de que no se logro imprimir y
vuelve al estado inicial, con las mismas facturas en estado pendiente.
Escenario Primario
Actor
Sistema
Selecciona un grupo de facturas
pendientes para imprimirlas y las
enva a la impresora
Si se reciben los datos para imprimir, se envan a la impresora determinada en la configuracion
Retira las facturas desde la impresora para asociarles numero si es que
salieron correctamente impresas
Escenario Secundario
Actor
Sistema
Si las facturas no se imprimieron bien o un rango de ellas no salio correctamente, se procede a repetir la
impresion del rango que salio mal
40

4.4.4. Caso de Uso: Asociar Numero
Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Paso
1
Asociar Numero
Que el operador del sistema pueda asociar un numero a la factura impresa, este numero puede ser el numero de comprobante
interno o el que viene preimpreso en el papel de la factura.
Operador
Solicitud de asociar numero para las facturas impresas por parte
del Operador.
El operador tipea el numero correspondiente en el casillero que
lo solicita para las facturas impresas sin numero asociado
El sistema asocia un numero a las facturas impresas en la base
de datos y solicita al operador la confirmacion de la operacion.
En caso de no poder asociar un numero (podra estar ya asociado) se le comunica al operador para verificar el numero.
Actor
Selecciona
numero.
la
Escenario Primario
Sistema
opcion asociar
2
3
Despliega el listado de facturas impresas que no tienen un numero asociado.

Tipea el numero correspondiente, ya
sea de factura o de comprobante interno.
Asocia en el registro de la factura el

numero ingresado.
41
Paso
4a
Actor
Sistema
En caso de que el numero tipeado no
cumpla con las reglas de asociacion,
se solicita nuevamente el ingreso del
numero.
4.4.5. Caso de Uso: Enviar Facturas

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Enviar Facturas
Que el operador del sistema a partir de las facturas impresas y
con numero asociado pueda imprimir un listado de las facturas
a enviar y de paso generar un email para la empresa de correos.
Ademas el sistema debe modificar el registro del dominio indicando que ya esta facturado.
Operador
Solicitud de enviar por parte del Operador
Existen facturas impresas y con numero asociado para enviar.
El sistema muestra el listado de las facturas generadas para ser
impreso y genera un email, el cual es enviado a los mails de
la empresa de correos, con copia a otros email determinados en
la configuracion del Sistema. Ademas, cambia el estado a los
dominios como facturados y a las facturas como enviadas.
El sistema genera un mensaje de que no se logro enviar las facturas, volviendo al estado inicial.
42
Paso
1
2
3
4
Paso
5a
Escenario Primario
Actor
Sistema
Selecciona la opcion de Enviar facturas
Muestra un detalle de la informacion
que se enviara.
Imprime el listado y luego selecciona el boton Enviar.
Marca como enviadas las facturas y
genera el email para los destinatarios correspondientes. Genera un reporte.
Revisa el reporte del sistema, de estar bien puede volver a iniciar el proceso de facturacion, de lo contrario
revisa el error.
Actor
Sistema
En caso de algun error se vuelve al
estado inicial con el listado de facturas sin enviar.
4.4.6. Caso de Uso: Crear Factura

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Crear Factura
Que el operador del sistema pueda crear una factura a partir de
algunos datos que debe tipear en la interfaz de crear facturas.
Operador.
Solicitud de crear factura por parte del Operador.
Ninguna.
El sistema crea una nueva factura para poder asociarle numero e
imprimirla.
El sistema genera un mensaje de que no se logro crear una factura, volviendo al estado inicial.
43
Paso
1
2
3
4
5
Paso
5a
Escenario Primario
Actor
Sistema
Selecciona la opcion Crear Factura
Despliega una interfaz en la cual ingresa la informacion.
Ingresa los datos necesarios para
generar una factura. Presiona
Guardar.
Guarda la factura generada.
Revisa el reporte del sistema, de estar bien puede seguir creando facturas o volver al inicio del sistema,
de lo contrario revisa el error.
Actor
Sistema
En caso de algun error se vuelve al
estado inicial del sistema.
4.4.7. Caso de Uso: Emitir DTE

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Emitir DTE
Que el Operador del Sistema pueda emitir DTE (Facturas Electronicas)
Operador.
Solicitud emitir Facturas Electronicas para los datos pendientes.
Existen datos pendientes por facturar.
El sistema luego de solicitar las claves de ingreso y del certificado digital emite los DTE, generando los documentos XML y
PDF correspondiente.
El sistema genera un mensaje de que no se logro emitir los documentos solicitados.
44
Paso
1
2
3
4
5
6
7
8
Paso
3a
7a
8a
Escenario Primario
Actor
Sistema
Selecciona la opcion Electronico
al momento de conectarse al Sistema.
Solicita la clave para usar el certificado digital, inscrito en el SII para
firmar los DTE.
Una vez ingresada la clave, solicita
ver los Documentos Por Facturar.
Despliega el listado de documentos
por facturar en grupos de 100.
Selecciona el listado de documentos
a emitir.
Solicita la clave necesaria para
generar el timbre y firmar el XML.
Ingresa la clave asociada al certificado que se usara para timbrar y firmar
los DTE.
Valida las claves y comienza a
generar los XML firmados y los
PDF. Ambos documentos los guarda en la base de datos.
Actor
Sistema
En caso de que la clave sea invalida
el sistema la vuelve a solicitar.
En caso de que la clave sea invalida
el sistema la vuelve a solicitar (manteniendo en memoria el listado de
los documentos seleccionados para
emitir).
En caso de fallar la firma o generacion del XML o PDF el sistema lanzara un reporte al final, una vez que
finalizo la emision de la totalidad de
los documentos solicitados.
45
4.4.8. Caso de Uso: Editar Facturas

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Paso
1
2
3
4
5
6
Editar Facturas
Que el Operador del Sistema pueda editar las facturas que existen en el sistema
Operador.
Solicitud editar facturas.
Existen facturas en la base de datos del sistema.
El sistema despliega el listado de facturas, luego de recibir los
cambios en la factura ingresa los nuevos datos en la base de
datos.
El sistema genera un mensaje de que no se logro modificar los
datos de la factura solicitada
Escenario Primario
Actor
Sistema
Selecciona la opcion Editar Facturas del menu de navegacion del
sistema.
Despliega el listado de las facturas
ingresadas en el sistema.
Selecciona la factura a editar.
Despliega los datos de la factura que
se selecciono para editar.
Actualiza los datos de las facturas.
Graba los datos actualizados.
46
Paso
2a
Actor
6a
Sistema
En caso de que no existan facturas
en la base de datos del sistema,
despliega un mensaje indicando la
situacion.
En caso de que no se pueda actualizar los datos de la factura solicitada, se despliega un mensaje indicando lo ocurrido.
4.4.9. Caso de Uso: Ver Informes

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Paso
1
2
3
Ver Informes
Que el Jefe Administrativo pueda visualizar distintos informes
del Sistema.
Jefe Administrativo.
Solicitud de ver informes por parte del Jefe Administrativo.
Existen informes que visualizar.
El sistema despliega los informes solicitados.
El sistema genera un mensaje de que no se logro desplegar el
informe solicitado, volviendo al inicio.
Escenario Primario
Actor
Sistema
Selecciona la opcion de Visualizar
Informes.
Muestra el detalle del informe seleccionado.
Revisa el informe desplegado,
puede solicitar ver otro o salir del
sistema.
47
Paso
3a
Actor
Sistema
En caso de algun error se vuelve
al estado inicial mostrando los informes disponibles.
4.4.10. Caso de Uso: Configurar Sistema

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Paso
1
2
3
4
Configurar Sistema
Que el Administrador pueda modificar o ingresar opciones de
configuracion del Sistema.
Administrador.
Solicitud de configurar el sistema por parte del Administrador.
El sistema refleja los cambios hechos.
El sistema genera un mensaje de que no se logro cambiar la configuracion.
Escenario Primario
Actor
Sistema
Selecciona la opcion de Configurar
Sistema
Muestra el detalle de las configuraciones actuales.
Determina la configuracion a cambiar y la modifica.
Actualiza la configuracion
48
Paso
4a
Actor
Sistema
En caso de algun error se vuelve a la
anterior configuracion.
4.4.11. Caso de Uso: Administracion de Usuarios

Nombre:
Objetivo:
Actores:
Trigger:
Precondiciones:
Postcondiciones
Caso Normal:
Postcondiciones
Caso anormal:
Paso
1
2
3
4
Paso
4a
Administracion de Usuarios
Que el Administrador pueda modificar o ingresar nuevos usuarios del Sistema.
Administrador.
Solicitud de Administrar Usuarios por parte del Administrador.
El sistema refleja los cambios hechos.
El sistema genera un mensaje de que no se logro ingresar o modificar el o los usuarios.
Escenario Primario
Actor
Sistema
Selecciona la opcion de Administracion de Usuarios
Muestra el listado de los usuarios.
Determina el usuario a modificar o
ingresar uno nuevo.
Actualiza la configuracion
Actor
Sistema
En caso de algun error se vuelve a la
anterior configuracion.
49
Captulo 5
Diseno
5.1. Introduccion
Luego de recopilar los antecedentes y requerimientos del nuevo sistema de Facturacion y una
vez conocido el Framework con el cual se debe desarrollar el sistema, es necesario definir y
explicar el diseno.
Se comienza definiendo las plataformas de hardware y software bajo las cuales se desempenara el sistema, junto con las Bases de datos con las que interactua. Luego, se sigue con
los diagramas necesarios para explicar el funcionamiento del sistema, junto con las funciones y el
modelo de datos.
En este diseno no se muestran los procesos necesarios para operar con documentos tributarios
electronicos, 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 los
funcionarios de las a reas de Atencion a Clientes, Soporte Tecnico, Legal y Facturacion.
La implementacion del sistema disenado en esta memoria fue realizada en el servidor de desarrollo que posee NIC Chile, en el cual, el hardware y software disponible es:
Procesador AMD Athlon(TM) XP, de 1600 MHz

2 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.0
Struts FrameWork, version 1.0.2
Ant, version 1.5
En el mismo servidor se encuentra instalado todo el software con el cual se relacionara el

sistema de facturacion, como es el que inserta los pagos en el repositorio de pagos, el que actualiza
las razones sociales con los RUT y el software que realiza los envos de los ingresos al sistema
contable Informat. Todos estos software mencionados estan instalados en este servidor, con motivo
de 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 definidas externamente:
1. Repositorio de pagos: Corresponde a la base de datos denominada ToDo, en la cual se

mantienen los pagos relacionados con dominios, que son insertados directamente de los procesos que atienden por medio de Servipag y Web Pay. Los registros de esta base de datos
poseen el nombre del dominio, el numero de proceso del dominio, la fecha en que se cancelo y el proceso que lo inserto (Servipag o Web Pay).
2. Repositorio de RUTs: Corresponde a una base de datos local alimentada inicialmente desde el sitio web del SII, al consultar por las razones sociales de todos los RUTs que estaban
registrados en NIC Chile como titulares de algun dominio. Esta base de datos se sigue alimentando a medida que los clientes de NIC Chile inscriben nuevos dominios con nuevos
RUTs, los que de no estar en la base de datos local se consulta va web al SII. De encontrar
respuesta, se agrega el nuevo RUT asociado a la razon social obtenida desde el SII. En caso
contrario, se deja pendiente la solicitud para facturacion (si es que ya fue cancelada) y se pide
al solicitante que confirme la razon social asociada al RUT, por medio de un envo de fax a
las oficinas de NIC Chile.
Los registros de esta base de datos solo poseen el RUT, el dgito verificador y la razon social.
Cada vez que se debe emitir alguna factura para un RUT en particular, se consulta esta base
de datos para obtener la razon social correcta que se usara para la cual se emitira la factura.
El nombre asociado al RUT, que ingreso al cliente, es utilizado para el campo denominado:
En representacion de:.
3. Registro de Dominios: Es la base de datos que mantiene todos los registros de dominios y
los datos de sus titulares. Desde esta base de datos se obtienen todos los datos de facturacion
del cliente, para posteriormente, insertarlos o comprobar su existencia en la base de datos de
facturacion. Los dominios que se mantienen pueden estar en 4 estados:
a) En-Tramite: Dominios recien inscritos, los que despues de un mes y si esta pagado y
nadie se opone a la inscripcion sera asignado al titular que lo solicita. El perodo de un
mes esta establecido en la reglamentacion de NIC Chile1 . En este estado tambien estan
los dominios que figuran en el perodo de Renovacion, los que cumplidos 2 anos de
estar asignados, deben volver a cancelar para seguir como asignados.
b) Asignados: Corresponden a los dominios que ya cumplieron con el estado EnTramite, estando asignados a un titular u nico. Durante este periodo solo se pueden
hacer modificaciones al formulario de inscripcion del registro.
1
Puede ser vista en: http://www.nic.cl/reglamentacion.html
52
c) En-Tramite.old: Corresponden a los dominios inscritos y que estaban en el estado

En-Tramite y fueron eliminados, ya sea por que se cumplio el plazo de un mes y no
se pago la solicitud, o porque el solicitante decidio eliminarlo.
d) Dominios.old: Corresponde a los dominios que estando asignados fueron eliminados,
esto puede suceder en casos que se solicita formalmente a NIC Chile eliminar una
inscripcion de dominio o realizar una Transferencia de dominio o una Revocacion.
Esta base de datos esta en constante uso, pues se ve afectada por las inscripciones, modificaciones, eliminaciones y todas las demas operaciones que pueden afectar a un registro de
dominio.
Una vez que se concreta la emision de una factura para uno o mas dominios, se debe intervenir
en el Registro de Dominios para asociar el identificador de la factura al dominio y de paso indicar
que el dominio fue facturado.
5.4. Descripcion de Interfaces Externas

El sistema se relacionara de manera externa con el software que permite pagar las solicitudes
de dominios, el cual genera nuevos registros en el repositorio de pagos, que a su vez, deben ser
facturados.
Por otro lado, se relacionara de forma indirecta con el software que enva los reportes al sistema
contable de la Facultad de Ciencias Fsicas y Matematicas, el cual, valida los ingresos de los pagos
recibidos y facturados en NIC Chile.
5.5. Decisiones Previas

Para estructurar el diseno del Sistema de Facturacion es necesario tomar algunas decisiones
previas, basadas en los antecedentes, requerimientos y experiencia recopilada desde los operadores
del a rea administrativa de NIC Chile. Estas decisiones son:
53
Para una correcta integracion de los sistemas de documentos tributarios electronicos y manuales se utilizara el mismo repositorio de datos del sistema. Inicialmente, se esta operando
solo con Facturas Electronicas y Facturas manuales, pero desde el SII se estan impulsando
las emisiones de nuevos DTEs, como es el caso de las boletas de compra y venta.
Con el fin de no modificar excesivamente la forma de operacion de los operadores del sistema
actual de facturacion, se desarrollaron interfaces graficas de usuario similares a las actuales
para los procesos mas importantes, aunque la operacion que hay detras de las interfaces es
totalmente diferente.
Se eliminan las nominas asociadas a las facturas (captulo 2, seccion 2.2, punto 7). Las facturas ahora seran generadas de manera automatica por un proceso que funcionara en alguna
hora predeterminada, el cual sera el encargado de agrupar facturas por RUTs, considerando
las restricciones del espacio que existe para imprimir el detalle. De exceder este espacio se
creara una nueva factura. Esto se decidio despues de realizar un estudio que arrojo que el
numero de facturas con mas de 15 dominios en un mes, no sobrepasaba las 4.
Se integra todo el sistema de facturacion en una sola plataforma y lenguaje. As, el proceso
de imprimir las facturas que antes estaba separado en otro programa que se deba instalar y
configurar en cada computador, esta integrado dentro de este nuevo sistema con una configuracion centralizada y utilizable desde cualquier computador a traves del cual se conecta el
operador. Por otro lado, la generacion de informes para el sistema Informat dependiente de
un funcionario de NIC Chile, ahora podra ser realizada por cualquier usuario del sistema de
facturacion con el rol correspondiente.
Inicialmente se definen 3 roles para la operacion del sistema correspondientes a los actores de
los casos de uso, explicados en el captulo 4, en la subseccion 4.4.1. El sistema esta disenado
para poder agregar mas usuarios y roles distintos, se maneja un esquema de permisos centralizado.
El mayor numero de errores durante el proceso de facturacion se producen cuando el operador
debe asociar numero a las facturas, por el hecho de tipear desde el teclado el numero, dgito
por dgito, con una alta probabilidad de equivocarse. Cuando el operador se daba cuenta del
error, deba acudir a funcionarios mas especializados de NIC Chile para realizar la correccion.
En el nuevo sistema se decidio entregar al operador la opcion de visualizar el listado de
facturas con sus numeros asociados, para poder cambiar el numero a alguna de ella cuando
sea necesario. As, el operador puede administrar las facturas completamente desde su lugar
de trabajo.
Se decidio mantener un registro de las acciones ejecutadas en el sistema. De esta forma, se
podra encontrar facilmente los pasos para la reconstruccion de estados del sistema y a las
personas responsables de las acciones.
54
Se decidio clasificar los clientes a los cuales se les debe imprimir una factura, usando el RUT
de facturacion y la direccion a la cual se le debe emitir la factura. Con esto, el manejo de
sucursales de clientes que solicitan facturas bajo el mismo RUT, pero con distinta direccion
de emision queda solucionado. Tal como se menciono anteriormente, este era uno de los
problemas comunes del anterior sistema de facturacion de NIC Chile.
Para una completa integracion con los demas software de NIC Chile, el sistema interactuara con distintos programas que haran de intermediarios con los registros actuales de los dominios. Para ello se decide crear registros de datos que se generaran de manera automatica en
el sistema, los que seran utilizados por otro programa que de manera automatica generara las
acciones necesarias para mantener la integridad.
Los operadores del sistema actual de facturacion, fueron incorporados al proceso de diseno
y validacion de las interfaces. Con esto, se logro un conocimiento del sistema antes de la
implantacion, con lo que el cambio del antiguo al nuevo sistema sera de menor impacto.
del Sistema
5.6. Diseno
Para el diseno del sistema se deben considerar todas las funcionalidades y relaciones externas
que se tendra con los sistemas y fuentes de datos ya existentes. Ademas, se deben cumplir los
requerimientos analizados en el captulo 4.
5.6.1. Diagrama de Arquitectura

En la figura 5.1 se muestra la arquitectura del sistema. En la zona mas oscura, se muestra el
sistema de facturacion con sus dos subsistemas de facturacion manual y electronica, el sistema
completo interactua con las bases de datos externas de Pagos (repositorio de pagos), de Dominios
(Registro de dominios) y de RUTs (en donde se almacenan las razones sociales asociadas a un RUT,
previa consulta al SII). Ademas se muestra una base de datos propia del sistema de facturacion, en la
cual se mantendran los registros de las facturas y sus estados con las acciones que se han ejecutado
sobre el sistema y las operaciones sobre las facturas por parte de los usuarios.
Los usuarios acceden al Sistema por medio de un computador conectado a la Intranet de NIC
55
Pagos
RUTs
Dominios
Sistema de
Facturacin
-Operario
-Jefe Administrativo
-Administrador
Facturacin
Electrnica
Manual
Figura 5.1: Diagrama de Arquitectura del Sistema de Facturacion.
Chile, en el cual ejecutaran un navegador que se podra enlazar con la pagina de ingreso al sistema.
En el momento del ingreso, se solicita seleccionar entre el sistema manual o electronico, los que
usan la misma base de datos. En el mismo ingreso se verifica los permisos que tiene el usuario, para
asociar los roles de operador, administrador o jefe administrativo.
5.6.2. Diagrama de Flujo de Datos

La figura 5.2 muestra el Diagrama de Flujo de Datos del sistema. En esta figura, se muestran
todos los procesos necesarios para cumplir con los requerimientos de la facturacion en NIC Chile.
Cada uno de los procesos dibujados se describen a continuacion, en el orden tpico de ejecucion:
1. Obtener Facturas: Este proceso se encarga de obtener todos los registros desde el repositorio
de Pagos para los cuales se debe emitir una factura (o comprobante interno) y luego identifica
al cliente correspondiente. Si no esta en la base de datos de facturacion, se inserta como nuevo
cliente con todos los datos necesarios (RUT, direccion, giro, telefono, comuna, ciudad, Razon
Social, etc). Una vez insertado el cliente, agrupa los temes pendientes de facturar con la
misma forma de pago. Finalmente, almacena la nueva factura en la base de datos, junto con
el detalle.
56
RUTs
Pagos
Crear
Factura
Dominios
Obtener
Facturas
Imprimir
Facturas
Facturacin
Consultar
Reportes
Resultado
Impresin
Asociar
Nmero
Listados
Informat
Configurar
Sistema
Administrar
Usuarios
Envios de
Facturas
Resultado
Asociacin
Editar
Facturas
Figura 5.2: Diagrama de Flujo de Datos.
Es importante destacar que este proceso no necesita intervencion humana, por lo que puede
funcionar de forma perodica o dependiente de otro evento. Ademas, las facturas que inserta
en la base de datos son de forma indiferente para los sistemas electronico y manual.
2. Crear Factura: Por medio de este proceso y sus interfaces, el usuario puede crear facturas
por temes que no sean dominios2 para lo cual debe tipear los campos requeridos, como los
datos del cliente y el detalle de la factura. Luego de validar los datos ingresados, esta nueva
factura es insertada en la base de datos de Facturacion.
3. Imprimir Factura: Permite imprimir las facturas pendientes de emision que estan en la base
de datos. Como primer paso, el operador debe seleccionar el tipo de documentos que se
emitiran:
Itemes Dominios: Corresponden a las facturas generadas de forma automatica por el
proceso Obtener Facturas, que indican el pago por algun dominio.
Item Otros: Corresponden a las facturas que el operador creo de forma manual, por
algun tem que no es dominio.
2
Estas son generadas en forma automatica.
57
Comprobantes Internos: Corresponden a las transacciones efectuadas con datos de facturacion pertenecientes a la Universidad de Chile, las que no se deben facturar si no que
se deben emitir un Comprobante Interno. Dentro de este tipo estan los comprobantes
por temes de dominios y los por otro temes.
Una vez seleccionado el tipo de documento, se presentara en pantalla un listado de las facturas pendientes por emitir para ese tipo de documento. Del listado, el operario puede seleccionar las que desee y solicitar la impresion de estas, en la impresora predeterminada por la
configuracion del sistema.
4. Resultado Impresion: Presentara el resultado de la solicitud de impresion para los documentos seleccionados en el proceso Imprimir Factura.
5. Asociar Numero:
Permite asociar el numero que viene preimpreso en el papel de la factura,
en el cual se imprimieron los datos correspondientes. El operador debe tipear el numero
correspondiente, luego la interfaz le ira proponiendo el numero siguiente (suponiendo que
la numeracion es correlativa). Una vez que el operador asocio los numeros con las facturas,
e stas cambian de estado en la base de datos de facturacion por lo que ya no seran visibles
para el proceso Imprimir Facturas.
6. Resultado Asociacion: Muestra en pantalla un mensaje que indica el resultado de la asociacion de los numeros con las facturas pendientes. Si ocurrio algun error permite volver a
repararlo.
7. Envos de Facturas: Una vez que se tienen facturas con numeros asociados, estas se pueden
enviar a la empresa de correos para su entrega. De la misma forma, pueden ser procesadas
por el sistema Informat para la generacion de sus informes. Este proceso se encarga de estas
tareas. Ademas de la generacion del listado, que el operador ve en pantalla para posteriormente imprimirlo y enviarlo fsicamente a la empresa de correos, esta la generacion del mail
correspondiente, avisando a la empresa de correos del envo, el que ademas va con copia a
una direccion de email interna de NIC Chile, a modo de control.
Este proceso modifica el registro de la factura en la base de datos, a modo de que aparezcan
como facturas enviadas y no se muestren en los procesos anteriores.
8. Editar Facturas: Muestra un listado de las facturas a las cuales se les ha asociado un numero,
con el fin de que el usuario pueda editar el contenido de la factura. Luego de la modificacion,
la factura volvera a ser guardada en la base de datos.
9. Administrar Usuarios: Permite crear, modificar y eliminar usuarios del sistema de facturacion. Dentro de estas operaciones esta la definicion de los permisos para los usuarios,
los que se dividen en 3 roles: Operador, Jefe Administrativo y Administrador. Este proceso
realiza modificaciones en el registro de los usuarios en la base de datos de facturacion.
58
10. Configurar Sistema: Presenta la configuracion actual del sistema, mostrando los valores de
los datos utilizados para:
Conexiones a las distintas Bases de Datos: Nombre de usuario y claves, ademas del
nombre de los drivers utilizados y la URL de cada base de datos.
Imprimir las facturas: El comando de impresion utilizado en el servidor, el nombre de la
impresora, el directorio temporal en donde se almacenaran los archivos para imprimir.
Constantes del Sistema: Numero de lneas que se desplegaran para los listados.
Datos Factura Manual: Valores de los campos centro de costo, item, cancelar a,
nombre de la empresa de correos, etc.
Una vez que el usuario modifica los campos necesarios y solicita Grabar, el sistema comienza a reflejar dichos cambios.
11. Listados Informat: Proceso que genera de forma automatica los listados para el sistema
Informat. Este proceso podra operar sin intervencion humana en su generacion, pero en el
envo debe existir la intervencion humana para cumplir la secuencia de pasos descritas al
final de la seccion Modelo Actual de Facturacion en NIC Chile, en el captulo 2 de esta
memoria.
12. Consultar Reportes: Este proceso permite visualizar los reportes de estadsticas del sistema
de facturacion, entregando graficos y tablas con: volumen de dominios por cliente, estadsticas de medios de pago, estadsticas de ventas de dominios por localidades y estadsticas de
ventas diarias, por creacion de dominios y renovacion.
La ejecucion de este proceso sera casi de forma exclusiva del usuario Jefe Administrativo.
Cada uno de los procesos descritos, agrupa variados subprocesos, los que se pueden visualizar
en un diagrama de flujo de datos de nivel 2 para cada uno de ellos, incluidos en la seccion 8.4 de
esta memoria.
5.6.3. Diagramas de Secuencia

Cada proceso dentro del diagrama de flujo de datos (figura 5.2), cumple una serie de pasos
o subprocesos, en los que existe intervencion de un usuario, las que se explican por medio de los
diagramas de secuencia del siguiente listado:
59
Crear Factura: En la figura 5.3, se muestran las operaciones que debe realizar el usuario
para ingresar una factura por algun tem no procesado de manera automatica (como los dominios). El usuario luego de tipear los datos solicitados en la interfaz del Crear Factura,
solicita grabar la factura, la cual previa validacion de los datos y obtencion de la razon social
del RUT desde la base de datos de RUTs, genera un mensaje que confirma el ingreso de la
factura o que la rechaza, explicando las razones.
Operario
Solicitud de Crear factura
Sistema
Interfaz de crear factura

Ingreso de los datos
Resultado creacin
Validacin
de datos
Figura 5.3: Diagrama de Secuencia, proceso: Crear factura.
Imprimir Factura: La figura 5.4, muestra la secuencia de pasos para cumplir con el proceso
de imprimir las facturas pendientes. Cabe mencionar que las facturas se imprimen en una
impresora del tipo Matriz de Punto, a la cual, se envan grupos de 100 facturas. El resultado
de la impresion indica si ocurrio algun error interno en el sistema como alguna falla en la
comunicacion con la impresora o falta de espacio para almacenar los documentos temporales
de impresion. Errores como que el papel esta en malas condiciones o fallo la impresora al
escribir, solo son verificados por el operador.
La impresion de las facturas se efectua para los casos de las facturas por ventas de dominios y
para facturas creadas manualmente para algun otro tem. Las ventas realizadas por dominios
a un cliente que registre como RUT de facturacion el de la Universidad de Chile, no debe ser
facturadas.
Asociar Numero:
Para asociar numeros a las facturas pendientes, el usuario necesariamente
debe tener impresas las facturas para identificar el numero que viene preimpreso en el papel.
Para ello primero visualiza un listado de facturas pendientes para asociarles el numero, ingresa el numero en el casillero correspondiente a los datos que imprimio en el papel, luego
60
Operario
Solicitud Imprimir Facturas

por tipo documento
Sistema
Listado Facturas pendientes

para tipo documento
temes seleccionados
Ejecucin de
impresin en
impresora
interna
Mensaje resultado impresin
Figura 5.4: Diagrama de Secuencia, proceso: Imprimir factura.
enumera las siguientes facturas y finalmente ejecuta la accion de asociar los numeros ingresados para las facturas que selecciono. Esta secuencia se puede apreciar en la figura 5.5.
Operario
Solicitud de Asociar Nmero

tipo documento
Sistema
Listado Facturas pendientes

tipo documento
Nmeros asociados a facturas
Mensaje resultado asociacin
Asociacin Interna
de los nmeros
Figura 5.5: Diagrama de Secuencia, proceso: Asociar Numero.

Al momento de asociar un numero a una factura, e sta deja de aparecer en los listados de
facturas pendientes por imprimir, agregandose al listado de las facturas pendientes por enviar.
Si la asociacion es para el tipo de documento interno, este numero no corresponde al de la
factura sino al de un comprobante interno.
Envo de Facturas: Para generar el envo de las facturas, en primer lugar el sistema despliega
el listado de las facturas que poseen numero asociado, luego el usuario debe imprimir ese
listado en dos copias, una para la empresa de correos y la otra queda en NIC Chile para
61
control interno. Luego que el usuario imprimio los listados, solicita enviar las facturas, lo que
genera un mail a la empresa de correos y los listados correspondientes al sistema Informat.
Operario
Solicitud de Enviar Facturas
Sistema
Listado Facturas para enviar

Impresin
2 copias
listado
Solicitud de enviar listado

Mensaje resultado envio
Generacin de
mails, listado
para Informat y
modificacin
registro dominio
Figura 5.6: Diagrama de Secuencia, proceso: Envo de Facturas.

Una vez que se enviaron las facturas se debe asociar el numero de la factura a el (los) registro(s) de dominio(s) correspondiente(s).
Editar Facturas: Con la edicion de facturas, el operador podra reparar el error habitual de
ingreso del numero que viene preimpreso en el papel a los datos que imprimio. La secuencia
de esta funcionalidad queda representada en el diagrama de la figura 5.7.
Operario
Solicitud de Editar Facturas
Sistema
Listado Facturas
Seleccin
de factura
Factura seleccionada
Datos de factura seleccionada
Bsqueda de
datos de
factura
Datos modificados
Resultado Modificacin
Actualizacin
datos de
factura
Figura 5.7: Diagrama de Secuencia, proceso: Edicion de Facturas.

Cabe destacar que una factura estara en condiciones de ser editada desde el momento que
fue ingresada al sistema, no siendo necesario el tener asociado un numero. De esta forma, si
62
existe algun error en los datos de la factura como alguno de los datos del cliente, se pueden
modificar antes de que sea enviada.
Configurar Sistema: Para realizar cualquier modificacion a la configuracion del sistema, el
usuario debe ingresar como Administrador. Luego de la validacion, se debe seleccionar la
opcion Configurar Sistema del menu principal. Esto, en primer lugar mostrara el estado
actual de la configuracion, la cual el administrador podra modificar y actualizar. Luego que
el sistema recibe los cambios se debera proceder a reiniciar3 la aplicacion para que estos
cambios se vean reflejados. La secuencia de pasos para configurar el sistema se muestran en
la figura 5.8.
Administrador
Solicitud de Configurar
Sistema
Datos de configuracin
Modificacin
de datos
Datos Actualizados
Resultado de actualizacin
Actualizacin
de los datos
Figura 5.8: Diagrama de Secuencia, proceso: Configurar Sistema.
5.6.4. Modelo de Datos

Para la mantencion de los datos del sistema de facturacion, se comenzo utilizando un modelo de
datos ya existente en NIC Chile, en el cual el autor de esta memoria participo en su confeccion en
conjunto con el equipo de desarrollo de NIC. Este modelo de datos cumple con todos los requerimientos que indica el SII para la emision de los DTEs, con el fin de tener un sistema los mas estandar
posible, pensando en la extension de la emision de DTEs para toda la Universidad de Chile.
A medida que se avanza en el diseno del sistema descrito en esta memoria, fue necesario realizar
3
Volver a compilar e instalar en el servidor
63
algunas modificaciones al modelo de datos definido en NIC Chile. En la figura 5.9 se muestra
un extracto del modelo actual, con las entidades y relaciones mas relevantes para el sistema que
se esta disenando. Cabe mencionar que en el sistema original cuenta con 32 entidades y en este
extracto se muestran solo 15.
La entidad principal del modelo es DATO DOCUMENTO, en la cual se mantienen los datos
de la factura y se agregaron las u ltimas 6 columnas durante la integracion con el sistema manual.
Estas u ltimas 6 columnas, mantienen los valores de los campos que vienen preimpresos en el papel
factura (para el caso de facturacion manual): gua despacho, gua despacho de, tem, centro
de costo, atencion de, son y cancelar a. El campo son lleva como valor el total de la factura
expresado en palabras, los campos tem, centro de costo y cancelar a son valores sacados desde
la configuracion del sistema, que se mantienen constantes para las facturas. Las demas columnas
son las que se extraen desde las exigencias del SII para los datos que se deben almacenar de un
DTE, los que para el caso de NIC Chile no se usan en su totalidad.
En la figura 5.9 se puede apreciar la entidad FOLIO MANUAL, en la cual se almacenaran los
numeros asociados a las facturas emitidas de forma manual. Para el caso de las facturas electronicas
los numeros de folio se tienen de antemano, por lo que existe una entidad por separado para la
mantencion de los folios de este tipo de factura (FOLIO DTE). La entidad FOLIO MANUAL
posee como columnas el numero de la factura, el identificador del dato de la factura y un tipo, que
indica el estado del numero de folio (asociado, enviado, anulado).
Los clientes se mantienen en la entidad CLIENTE, en la cual se identifican por medio del
RUT, el nombre que ellos ingresan para la emision de factura al momento de inscribir el dominio,
as como el giro. El campo razonsocial se extrae desde la base de datos de RUTs en el momento
en que se ingresa la factura; es importante mantenerlo en esta entidad, de modo de poder reconstruir
las facturas en el futuro con los datos exactos que fueron emitidas, ya que una razon social podra
cambiar en el tiempo o ser eliminada.
Es comun que se utilice un mismo RUT de cliente para la emision de factura, pero con direccion distinta, lo que genera dos clientes distintos. Para la correcta mantencion de estos casos
se mantiene la entidad SUCURSAL CLIENTE. En la cual, se identifica al cliente por el RUT y
en ella se especifica la direccion a la que se debe emitir la factura. Lo mismo que pasa para los
clientes, cuando usan el mismo RUT con distintas direcciones, sucede para los emisores de facturas, los que se mantienen en la entidad EMISOR, identificados por el RUT, pero en la entidad
SUCURSAL EMISOR, se especifica la direccion y el nombre de la sucursal correspondiente. Las
sucursales de los emisores tienen un codigo asociado, definido por el SII, el cual debe ir impreso
en la factura electronica. Estos codigos se mantienen en la entidad CODIGO SUCURSAL.
64
Los usuarios del sistema se mantienen en la entidad USUARIO, en donde se especifica solo
el nombre de usuario, la clave y el nombre completo. Los usuarios tienen un tipo de permiso
asociado. Estos permisos son mantenidos en la entidad PERMISOS TIPO, en donde se indica el
tipo del permiso, para que usuario, en que sucursal y para que tipo de documento.
El manejo de las ciudades y comunas que los clientes de NIC Chile ingresan como parte de la
direccion de facturacion, se hace a traves de las entidades CIUDAD y COMUNA, respectivamente.
En donde, cada ciudad puede tener una o mas comunas asociadas y cada comuna tiene una ciudad
asociada.
En la seccion 8.5.4 del captulo 8 de esta memoria, se muestra una descripcion mas detallada
de las entidades del extracto del modelo de datos del sistema.
65
Figura 5.9: Extracto Modelo Datos Sistema Facturacion.
66
Captulo 6
Implementacion
6.1. Introduccion
El uso del marco de trabajo Struts y el diseno mostrado en el captulo 5, se ven reflejados en
la metodologa y archivos desarrollados durante la implementacion del sistema. Ademas, en este
captulo se agregan mediciones en tiempo del funcionamiento del sistema en los casos mas crticos
y comunes.
6.2. Metodologa
El framework utilizado para desarrollar el sistema, propone una estructura de archivos dejando
en claro cuales se encargan de que proceso, como: validacion de datos, vista, acciones, conexiones
a bases de datos, etc. Pero no propone un orden de desarrollo de los archivos.
El autor de esta memoria, durante la implementacion fue probando distintos o rdenes de desarrollo para los archivos, encontrando que el mejor orden, cuando se tiene claro que es lo que
67
realizara la nueva accion a incorporar, es el siguiente:
1. Definir el mapeo correspondiente a la nueva accion en el archivo struts-config.xml, indicando

el nombre de la accion, el servlet que ejecutara las acciones correspondientes, el nombre del
FormBean que validara los datos, el alcance que tendran esos datos, de donde sera referenciada y quien desplegara los datos para los ActionForward definidos en el servlet.
2. Escribir el archivo que realizara la definicion y validacion de los beans que se usaran en el
Servlet y el JSP (archivo que extiende de la clase ActionForm). Es importante definir las
reglas de validacion de este archivo, para asegurar que al servlet lleguen los datos que se
esperan.
3. Escribir el archivo que actuara como el servlet, ejecutando las acciones del requerimiento.
Este archivo para el sistema que se desarrollo mantena una estructura base, la cual se muestra
y explica en la siguiente subseccion.
4. Escribir el archivo JSP que generara la vista para el usuario. Se debe tener especial cuidado
con los beans que se utilizaran en este archivo ya que deben estar definidos en el FormBean
e ingresados como atributos al requerimiento que recibe la pagina JSP.
Utilizando este orden de desarrollo, se logra realizar una completa definicion de la nueva accion
a incorporar en el sistema (equivalente a un diseno de la accion), definiendo los nombres de los
archivos que luego se escribiran, con las entradas y salidas correspondientes. Luego, al escribir
la validacion de los datos, antes de las acciones en que estos participaran, se logra especificar las
condiciones que los datos deben cumplir para un correcto funcionamiento (esto equivale al proceso
de pruebas que deben cumplir los datos). Finalmente, al momento de desarrollar el servlet que
ejecutara las acciones y el archivo JSP ya se tendra toda la accion disenada y los datos validados.
Una vez generados los archivos, se deben compilar y copiar las clases al directorio que mantiene
la aplicacion. Luego, se debe reiniciar el servicio tomcat4 en el servidor, si es que se modifico algun
archivo de configuracion de la aplicacion, en este caso el struts-config.xml.
Una vez instalada la nueva accion, se pueden realizar modificaciones directamente a los
archivos que definen los beans, las acciones o la vista afinando el desempeno con lo que se quiere.
Si el mapeo definido en el archivo struts-config.xml, no se modifica basta con compilar y copiar las
clases modificadas al directorio de la aplicacion.
68
La mayor dificultad con la que el autor de la memoria se encontro durante el desarrollo, fue
el diferenciar claramente los objetos que se deban validar dentro del FormBean y los que no eran
necesarios. Por ejemplo, para las acciones que se pueden llamar a si mismas, como el desplegar
un listado extenso de temes por partes, dando la opcion de ver los siguientes temes del listado, se
necesita que las variables que marcan el numero del primer tem que se esta mostrando no vuelvan
a ser definidas en el FormBean, pues en cada llamada a si misma volvera a tomar el valor inicial
y no un valor incremental como se desea. Para estos casos es necesario definir la variable en el
servlet que ejecuta la accion, el cual recupera la variable del requerimiento, la modifica y la vuelve
a ingresar como atributo del requerimiento.
El uso de archivos que definen los mensajes y propiedades de la aplicacion, generan un proceso
tedioso (al principio, es cosa de costumbre) de tener que ingresar cada nuevo mensaje en ellos,
pero al momento de realizar cambios son de gran utilidad, ahorrando todo el tiempo de la busqueda
de saber en donde se utilizo el valor que se desea cambiar. Ademas, permite mantener un lugar
centralizado con los valores de las constantes del sistema, como la configuracion y sentencias que
interactuan con las Bases de Datos.
6.3. Archivos Utiles

En general, los archivos mas u tiles e importantes del sistema son los que manejan e implementan las acciones y los mapeos. En primer lugar, un mapeo mal definido provocara que las acciones
y los datos no se comuniquen, aunque esten bien validados y bien implementadas las acciones.
El archivo struts-config.xml, define toda la comunicacion del sistema, especificando las entradas,
salidas, acciones y validaciones que se deben realizar en cada proceso definido en e l.
Los archivos que implementan los servlets, ejecutan el nucleo de la accion. Son los que se
comunican con las bases de datos, seleccionando, insertando y actualizando datos. Ademas, son los
que retornan la respuesta necesaria para saber que accion sigue con el control del requerimiento.
En general, son acciones distintas para casos de error o de e xito.
La estructura tpica de un archivo de configuracion del sistema, (tpicamente llamado: strutsconfig.xml) es de la forma:
69
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC

"-//Apache Software Foundation//DTD Struts Configuration 1.0//EN
"http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
<struts-config>

<servlet>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>cl.nic.manual.ApplicationResources</param-value>
</init-param>
</servlet>
108
En donde se indica la ubicacion del archivo de mensajes. Para usar estos mensajes dentro de las
paginas JSP, se debe incluir:
<%@
<%@
<%@
<%@
<%@
page language="java" %>

taglib uri="/WEB-INF/app.tld" prefix="app" %>
taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<html:html>
<head>
<title><bean:message key="porfacturarmanual.title"/></title>
<html:base/>
</head>
En donde se incluyen todas las librerias de Tags, y se usa la opcion key del tag bean:message
para incluir el mensaje correspondiente, en este caso se escribira el mensaje: Sistema Manual:
Dominios por Facturar.
8.5.2. Archivo de Configuracion de los Mapeos de Action

El archivo que define los mapeos de todas las acciones del sistema lleva por nombre strutsconfig.xml, un extracto de este archivo es:
<struts-config>

<servlet>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>cl.nic.dte.web.ApplicationResources</param-value>
</init-param>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>nocache</param-name>
<param-value>true</param-value>
123
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>validate</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

<taglib>
<taglib-uri>/WEB-INF/app.tld</taglib-uri>
<taglib-location>/WEB-INF/app.tld</taglib-location>
</taglib>

<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-html.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>
124
<taglib-location>/WEB-INF/struts-logic.tld</taglib-location>
</taglib>
</web-app>
8.5.4. Definicion detalla del Modelo de Datos

El extracto del modelo de datos mostrado en la figura 5.9 posee 15 entidades, las cuales se
definen a continuacion:
1. CLIENTE: Entidad que mantiene los datos de los clientes a los cuales se les emiten facturas.
Esta entidad posee los siguientes campos:
rut: Corresponde al RUT del cliente.
nombre: Corresponde al nombre del cliente, tpicamente nombre y apellido.
giro: Muestra el giro del cliente, si no tiene es giro particular.
razonsocial: Es la razon social que muestra la base de datos de razones sociales obtenida
desde el SII, al momento de ingresar la factura.
2. SUCURSAL CLIENTE: Entidad encargada de mantener las sucursales de los clientes. Esta
entidad posee los siguientes campos:
id: Identificador interno de la sucursal.
nombre: Nombre de la sucursal (podra ser distinto al del cliente).
direccion: Direccion, nombre de la calle y numero.
codigo: Codigo asignado dentro de la empresa a la cual pertenece la sucursal.
cliente: El RUT del cliente al cual pertenece la sucursal.
comuna: Identificador de la comuna en donde esta la sucursal.
3. CIUDAD: Mantiene un registro de los nombres de las ciudades y un identificador interno:
id: Identificador interno de la ciudad.
nombre: Nombre de la ciudad.
125
4. COMUNA: Mantiene un registro de los nombres de las comunas, un identificador interno y

la ciudad a la cual pertenecen:
id: Identificador interno de la comuna.
nombre: Nombre de la comuna.
ciudad: Identificador de la ciudad.
5. MODALIDAD PAGO: Mantiene un registro de las distintas modalidades de pago, reconocidas por el SII:
id: Identificador interno de la modalidad.
forma: Solo dos tipos.
modalidad: Distintas modalidades: contado, cheque, tarjeta, etc.
6. TIPO DTE: Define los tipos de Documentos Tributarios Electronicos que se usaran en el
sistema:
id: Identificador del tipo de DTE.
dteValue: Valores de los documento tributarios electronicos.
tipo: Nombra los distintos tipos de documento, sin importar si es eletronico o manual.
tipoDocumento: Indica el tipo de documento dentro de la clasificacion electronica y
manual.
nombre: Nombre del tipo de documento.
7. TIPO DOCUMENTO: Define los tipos de documento:
id: Identificador del tipo de documento.
nombre: Nombre del tipo de documento.
8. USUARIO: Mantiene los usuarios del sistema, posee los siguientes campos:
login: Nombre de usuario con el cual se conecta al sistema.
password: Clave por medio de la cual el usuario se autentifica en el sistema.
nombre: Nombre del usuario.
9. PERMISOS TIPO: Mantiene los permisos de los usuarios del sistema, posee los siguientes
campos:
permisos: Numero que identifica los permisos del usuario.
sucursal: Identificador de la sucursal a la cual tiene permisos el usuario.
usuario: Login del usuario.
126
tipoDTE: Tipo de documento al cual tiene permiso de uso el usuario.

10. FOLIO DTE: Mantiene el registros de los numeros de folio autorizados por el SII, posee los
siguientes campos:
emisor: Identificador del emisor de este folio.
tipoDTE: El tipo de DTE para el cual se autorizo el folio.
folio: Numero o valor del folio.
estado: Indica el estado del folio: emitido, enviado, anulado, etc.
fecha: Fecha en que se autorizo el folio.
codigo: Codigo con el cual se autorizo.
timbre: Valor del timbre que lleva asociado el folio.
xml: Documento XML que contiene el DTE con este folio.
pdf : Documento PDF que contiene el DTE con este folio.
dato: Identificador de los datos que se generaron con este folio.
11. DATO DOCUMENTO: Mantiene el registro de los datos del documento que esta en la base
de datos. Posee los siguientes campos:
id: Identificador del dato.
tipoDocumento: Indica el tipo de documento al cual pertenecen estos datos.
estado: Indica el estado en que estan estos datos, los que pueden ser distintos para el
sistema manual como electronico.
fecha: La fecha en que se inserto el dato en el sistema.
entregaBienes: Indica si es por entrega de bienes.
indicadorVenta: Muestra el indicador de venta del dato.
pago: Indica la forma de pago del dato.
fechaVencimiento: Indica la fecha de vencimiento del dato en el documento.
emisor: Identificador del emisor de este dato.
montoNeto: Indica el monto Neto del documento al cual pertenece el dato.
montoExento: Indica el monto Exento del documento al cual pertenece el dato.
iva: Indica el IVA del documento al cual pertenece el dato.
ivaAnticipado: Indica el IVA anticipado del documento al cual pertenece el dato.
ivaNoretenido: Indica el IVA no retenido del documento al cual pertenece el dato.
creditoConstructora: Indica el credito de la constructora para el documento que usa este
dato, si es que existe.
127
garantiaEnvases: Indica la garanta por envases, si es que existe, para el documento.

montoTotal: Indica el monto total por el cual se emite el documento.
fechaPago: Muestra la fecha de pago del documento.
cliente: Identificador del cliente al cual se emite el documento.
guiadespacho: Valor del campo guia despacho de las facturas manuales.
guiadespachode: Valor del campo guia despacho de, de las facturas manuales.
item: Valor del campo item de las facturas manuales.
centrodecosto: Valor del campo centro de costo de las facturas manuales.
atencionDe: Valor del campo atencion de de las facturas manuales.
son: Valor del campo son de las facturas manuales, que indica el monto total en palabras.
cancelarA:
12. FOLIO MANUAL: Mantiene los numeros de folio asignados por medio del sistema manual.
Posee los siguientes campos:
numero: Indica el valor del folio o el numero de folio.
dato: Identificador del dato que tiene asociado este folio.
tipo: Identificador del tipo de dato al cual esta asociado este folio.
13. EMISOR: Mantiene los emisores que funcionaran en el sistema. Posee los siguientes campos:
rut: RUT del emisor.
nombre: Indica el nombre del emisor.
codigo: Indica el valor de un codigo de manejo interno.
14. SUCURSAL EMISOR: Mantiene las sucursales que puede tener un emisor. Posee los siguientes campos:
id: Identificador de la sucursal.
emisor: RUT del emisor al cual pertenece esta sucursal.
nombre: Nombre de la sucursal.
codigo: Codigo de manejo interno de la sucursal.
direccion: Nombre de la calle y numero de la direccion de la sucursal.
comuna: Identificador de la comuna a la cual pertenece la sucursal.
15. CODIGO SUCURSAL: Mantiene el registro de los codigos de sucursales y la sucursal asociada:
codigo: Indica el codigo u nico asociado a una sucursal.
sucursal: Identificador de la sucursal a la cual pertenece el codigo.
128
Bibliografa
[1] Sebastian Castro Avila.

Evaluacion de un Motor de Bases de Datos para NIC Chile. Memoria para optar al ttulo de Ingeniero Civil en Computacion, Universidad de Chile, 2002.
[2] Benjamn Tomas Barros Arancibia. Documentos Tributarios Electr o nicos. Memoria para
optar al ttulo de Ingeniero Civil en Computacion, Universidad de Chile, 2002.
[3] Varios autores. JavaTM 2 Platform, Standard Edition, v1.3.1 API Specification, 2000.
Disponible a traves de http://java.sun.com/j2se/1.3/docs/api/.
[4] Varios autores.
JavaTM Servlet Technology, 2000.
http://java.sun.com/products/servlet/.
Disponible a traves de
[5] Varios autores. JavaServer PagesTM, Dynamically Generated Web Content, 1999.
Disponible a traves de http://java.sun.com/products/jsp/.
[6] Varios autores.
JavaBeansTM, 1999.
http://java.sun.com/products/javabeans/.
[7] Varios autores.
The JavaTM Tutorial, 2002.
http://java.sun.com/docs/books/tutorial/.
Disponible
Disponible a
traves
traves
de
de
[8] Apache Software Foundation. The Apache Struts Web Application Framework, 2002.
Disponible a traves de http://jakarta.apache.org/struts/.
[9] Apache
Software
Foundation.
The
Struts
Userss
Guide
Bean
Taglib
Guide,
2002.
Disponible
a
traves
de
http://jakarta.apache.org/struts/userGuide/dev bean.html.
[10] Apache
Software
Foundation.
The
Struts
Userss
Guide
Logic
Taglib
Guide,
2002.
Disponible
a
traves
de
http://jakarta.apache.org/struts/userGuide/dev logic.html.
129
[11] Apache
Software
Foundation.
The
Struts
Userss
Guide
HTML
Taglib
Guide,
2002.
Disponible
a
traves
de
http://jakarta.apache.org/struts/userGuide/dev html.html.
[12] Juan Antonio Palos Programacion en Castellano. El API Struts, 2002. Disponible a traves
de http://www.programacion.com/tutorial.struts.html.
130

Memoria PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Memoria PDF

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD DE CHILE

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION

DE UN NUEVO SISTEMA DE FACTURACION

NOTA FINAL EXAMEN DE TITULO

MEMORIA PARA OPTAR AL TITULO DE

INGENIERO CIVIL EN COMPUTACION

INGENIERO CIVIL EN COMPUTACION

DE UN NUEVO SISTEMA DE FACTURACION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4.4. Configurar el Mapeo del Servlet Action . . . . . . . . . . . . . . . . . . .

3.4.5. Configurar la Librera de Etiquetas de Struts . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.10. Caso de Uso: Configurar Sistema . . . . . . . . . . . . . . . . . . . . . .

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

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

5.3. Bases de Datos Definidas Externamente . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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