Memoria PDF
Memoria PDF
Memoria PDF
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
SANTIAGO DE CHILE
ENERO DEL 2003
FIRMA
RESUMEN DE LA MEMORIA
PARA OPTAR AL TITULO DE
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.2. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2. Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Antecedentes
2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
11
12
14
16
16
17
17
3. Struts Framework
18
3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
19
19
20
3.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
II
3.2.1. JavaBeans y el Ambito
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
24
25
25
3.3. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3.1. Internacionalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
27
3.4. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
29
30
30
31
32
4. Requerimientos
33
4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
33
33
34
34
35
37
38
4.4.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
38
40
41
42
43
44
46
47
48
IV
5. Diseno
49
50
5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
51
52
53
53
55
55
56
59
63
6. Implementacion
67
6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.3. Archivos Utiles
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
73
74
74
76
78
78
7. Conclusiones
81
8. Anexos
83
84
8.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
8.2. Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
86
8.3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
86
VI
88
92
94
97
VII
Captulo 1
Introduccion
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
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
1.3.2. Especficos
Los objetivos que se deben lograr con el nuevo sistema de facturacion son los siguientes:
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.
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:
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
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.
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:
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.
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:
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.
16
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
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
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
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)
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.
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.
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:
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.
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):
<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.
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.
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.
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.
<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
<servlet-name>action</servlet-name>
<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
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.
33
34
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.
37
4.4.1. Actores
Los siguientes son los actores identificados para el sistema:
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
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
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
41
Paso
4a
Actor
Escenario Secundario
Sistema
En caso de que el numero tipeado no
cumpla con las reglas de asociacion,
se solicita nuevamente el ingreso del
numero.
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
Escenario Secundario
Sistema
En caso de algun error se vuelve al
estado inicial con el listado de facturas sin enviar.
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
Escenario Secundario
Sistema
En caso de algun error se vuelve al
estado inicial del sistema.
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
Escenario Secundario
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
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
Escenario Secundario
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.
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
Escenario Secundario
Sistema
En caso de algun error se vuelve
al estado inicial mostrando los informes disponibles.
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
Escenario Secundario
Sistema
En caso de algun error se vuelve a la
anterior configuracion.
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
Escenario Secundario
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
51
52
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.
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.
Pagos
RUTs
Dominios
Sistema de
Facturacin
-Operario
-Jefe Administrativo
-Administrador
Facturacin
Electrnica
Manual
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.
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
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
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.
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
Sistema
Validacin
de datos
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
Sistema
Ejecucin de
impresin en
impresora
interna
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
Sistema
Asociacin Interna
de los nmeros
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
Sistema
Generacin de
mails, listado
para Informat y
modificacin
registro dominio
Operario
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
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
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
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
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.
69
path=""
type=""
name=""
scope=""
input="">
<forward name=""
</action>
path=""/>
</action-mappings>
</struts-config>
Este archivo define 3 configuraciones por separado, la de los form-beans, en la cual se dice que
un nombre dado como parametro de la opcion name, tendra la validacion del archivo dado en el
campo type.
70
Para el caso de los global-forwards, se define un nombre, por medio del parametro name,
asociado a un archivo JSP (tpicamente), definido en el parametro path. De esta forma, se obtiene
un nombre que puede ser referenciado desde cualquier JSP y hara la correspondiente referencia al
archivo definido en el global-forwards.
Finalmente, se definen los action-mappings, que posee los parametros que define el nombre
de la accion con el parametro path, el servlet que ejecutara las acciones correspondientes con
el parametro type, el nombre del FormBean que validara los datos con el parametro name (el
que se definio dentro de los tags form-beans), el alcance que tendran esos datos con el parametro
scope, desde donde sera referenciada la accion con el parametro input y quien desplegara los
datos para cada ActionForward definidos en el servlet con el tag forward.
Para el caso de los servlets, la estructura tpica de un archivo que implementa un servlet de este
sistema es la siguiente:
//configuraci
on del usuario que esta conectado
UserContext uctx =
(UserContext)session.getAttribute("UserContext");
//si no se obtiene se reenv
a a la pantalla de ingreso
71
if (uctx == null)
return (mapping.findForward("logon"));
try {
//se comienza con la interaccion con la base de datos para
//realizar lo que el servlet debe hacer
uctx.resetConnection();
Tal como en el codigo se comenta, este archivo en su forma mas generica debe comenzar obteniendo las configuraciones de la sesion. En primer lugar, obtiene el tipo de internacionalizacion
que se esta usando por medio de la clase Locale. Luego, recupera la sesion que trae asociada el
requerimiento, para de ella obtener el contexto en el que esta inmerso el usuario, si no se obtiene
se reenva el requerimiento a la pantalla de ingreso del sistema (la sesion podra haber expirado).
72
Luego obtiene la herramienta que se utiliza para obtener los mensajes del idioma adecuado, que en
el sistema implementado, tambien se usa para obtener las sentencias que se usaran para interactuar
con la base de datos.
Una vez que se tiene el ResourceBundle, se puede comenzar con la interaccion con la base de
datos y ejecutar todas las acciones que debe cumplir este servlet, para el correcto funcionamiento
del sistema. Si todo funciona correctamente se retornara la respuesta adecuada para que tome el
control la siguiente accion definida en el struts-config.xml. Si ocurre algun problema, la excepcion
capturada generara un mensaje de error adecuado, ya sea dentro de la sesion, dentro del contexto
del usuario o en el log del servlet.
En la seccion 8.5.2 del anexo de esta memoria, se muestra y explica de manera mas extensa los
archivos que definen los mapeos y los que implementan los servlets, entregando ejemplos con los
valores que se usaron en el sistema implementado.
los procesos Imprimir Facturas y Asociar Numero, los operadores estan acostumbrados a operar
con grupos de maximo 100 facturas, por lo que las mediciones se realizan en torno a ese numero.
Estas mediciones se muestran en las siguientes subsecciones, destacandose al final una medicion
realizada para la generacion de Facturas Electronicas.
Medicion Numero
1: Obtener Facturas
servidor, enviando cada uno de esos archivos a la impresora determinada en la configuracion del
sistema.
Las mediciones realizadas, se obtuvieron variando el numero de facturas a imprimir, que son
las que determinan el numero de archivos generados e impresos.
Medicion Numero
2: Imprimir Facturas
75
Como se explico anteriormente, el proceso encargado de imprimir las facturas genera archivos
temporales en el servidor, lo normal es que se enven grupos de 100 facturas a la impresora. Esta
cantidad esta predeterminada por la cantidad de trabajos que puede encolar la impresora. Los tiempos mencionados, no incluyen lo que demora la impresora en imprimir una factura, lo cual depende
en gran parte del estado de la impresora.
76
Medicion Numero
3: Asociar Numero
77
Medicion Numero
4: Envo de Facturas
Medicion Numero
5: Generacion de Facturas Electronicas
El rendimiento del sistema es bastante bueno, considerando que con los tiempos observados se
pueden generar 2 facturas por cada 3 segundos, para un da normal de operacion en NIC Chile,
en donde se generar 200 facturas diariamente (en promedio), bastara con 5 minutos para que el
sistema genere los documentos XML que representan las facturas de un da.
80
Captulo 7
Conclusiones
El diseno e implementacion de un sistema que deba reemplazar a uno existente, puede resultar mucho mas complejo que disenar e implementar algo totalmente nuevo. La dificultad radica
en que el nuevo sistema, generalmente debe cumplir todas las tareas que realiza el antiguo, agregando nuevas funcionalidades, por lo cual se debe tener un completo conocimiento de todas las
implicancias que tiene el antiguo sistema dentro de otros procesos (computacionales o manuales)
en la organizacion. Esta dificultad se abordo manteniendo una constante comunicacion con los operadores del a rea administrativa, para ir validando los procesos y acciones que se deban cumplir,
dejando al autor y operadores satisfechos con el sistema.
El desarrollo de un sistema que realice facturacion electronica, es una tarea pionera en Chile. Al
momento de realizar esta memoria, de las empresas participantes en el Programa Piloto del SII, NIC
Chile es la que cuenta con la mas avanzada implementacion del sistema. La mayor dificultad en
desarrollar la facturacion electronica radica en el hecho de usar herramientas y tecnologas nuevas y
poco conocidas en Chile, como es el uso de certificados y firmas digitales, junto con los mecanismos
de encriptacion, generacion de documentos con el formato PDF417 y el uso de XML. Ademas, se
debe analizar la integracion con los sistemas actuales de facturacion que posee la empresa. Para
las empresas que no cuentan con capacidad de desarrollo de un sistema de generacion de facturas
electronicas, existe la posibilidad de contratar el servicio en alguna empresa desarrolladora de este
software en el mercado1 .
1
A este fecha existen 2 empresas conocidas que desarrollan software para facturacion electronica.
81
A medida que avanza el programa Piloto del SII para la generacion de facturas electronicas, se
hacen cada vez mas notorias las ventajas de contar con este sistema en vez de el sistema manual
de facturacion. Como ventajas se pueden nombrar los ahorros en papel y materiales de oficina
asociados, el costo de enviar correspondencia con la factura, los traslados del papel de la factura, el
almacenaje en bodega de las facturas emitidas, el ahorro de impresion en formularios con 5 copias
en un tipo de impresora especfica (matriz de punto) etc. Pero un costo muy importante es el del
tiempo de generar una factura. Como se mostro en la seccion 6.4.5 de esta memoria, para generar
200 facturas solo se necesitan 5 minutos de operacion del sistema, las que posteriormente se pueden
imprimir en impresoras disponibles en el mercado, ya sea de tipo inyeccion de tinta o laser, proceso
que en el sistema manual demorara un medio dia de trabajo (4 horas) aproximadamente.
El desarrollo del sistema en el lenguaje Java, usando el marco de trabajo Struts, permitio trabajar
de una manera ordenada y modularizada. Ademas, se obtiene un sistema multiplataforma y de facil
mantencion, en donde se desarrolla de manera separada la logica de las acciones, la implementacion
del procesamiento de los requerimientos y la presentacion de los resultados a los requerimientos
del usuario. La abundante documentacion que posee el lenguaje Java y la variada disponibilidad
de paquetes para implementar las diversas necesidades del sistema de facturacion, lo hicieron una
buena herramienta de desarrollo. Para el caso de NIC Chile (y del autor de esta memoria), es la
primera vez que se desarrolla un sistema completo en este lenguaje, por lo que no se contaba con
el apoyo ni experiencia del grupo de desarrolladores de NIC Chile en este tema. Por esta razon, el
desarrollo pudo resultar mas lento que si hubiese sido en algun lenguaje conocido y dominado por
el autor de la memoria o el grupo de desarrollo (como Perl). Por otra parte, se debe considerar que
al desarrollar y poner en marcha un sistema hecho con Java y Struts, tiene un costo fijo bastante
alto en lo que a recursos de memoria y capacidad de procesamiento se refiere, mas alto que lo
requerido por un desarrollo en lenguajes como Perl o PHP, pero el costo marginal, cuando el sistema
esta operando es menor que los presentados por estos otros lenguajes. Esto se debe a que nuevos
requerimientos generaran un nuevo thread dentro de la maquina virtual de Java, en cambio en los
lenguajes interpretados se generan nuevas instancias del interprete.
Los cambios mas importantes que se tienen con el nuevo sistema de facturacion, son la mantencion en una base de datos de todas las facturas que se emiten desde NIC Chile, la definicion
de clientes y sucursales de clientes para las facturas, el eliminar los listados de detalle de factura
(que se deban imprimir por separado), aprovechando de mejor manera el espacio para el detalle
que trae consigo la factura en papel y la automatizacion de los reportes al sistema Informat. Todas
estas funcionalidades del sistema de facturacion desarrollado, dejan satisfechos a los operadores y
por supuesto, al autor de esta memoria.
82
83
Captulo 8
Anexos
8.1. Definiciones
direcci
on IP: Identificador u nico de un computador conectado a Internet, usado para
que los computadores puedan comunicarse entre s. Por ejemplo, para el nombre uchile.cl el
numero IP asociado es: 146.83.12.3.
DNS: Domain Name System. Servicio fundamental para el funcionamiento de Internet, que
se encarga de traducir de un nombre alfanumerico a una direccion IP.
Informat: Sistema Computacional para el manejo de la contabilidad de la Facultad de
Ciencias Fsicas y Matematicas de la Universidad de Chile. Para el caso de NIC Chile, se
confecciono en el ano 1999, el reporte automatico de las facturas emitidas, por medio de
traspasos de archivos por Internet, usando el protocolo FTP.
Perl: Lenguaje de programacion interpretado, similar en sintaxis al lenguaje C, incluye utilidades del sistema Unix. Ademas es una buena herramienta de desarrollo para CGIs (Commmon Gateway Interface), por el buen manejo de cadenas de caracteres que tiene, entre otras
virtudes. La version 1.0 de Perl fue lanzada en 1987.
Java: Lenguaje de Programacion disenado para usarlo en ambientes distribuidos de Internet,
reforzado con el modelo de Programacion Orientada al Objeto. Puede ser usado para crear
aplicaciones que pueden funcionar en un solo computador o en varios computadores de forma
distribuida. Este lenguaje fue introducido por Sun Microsystems en el ano 1995.
84
FTP: (File Transfer Protocol) Protocolo estandar usado en Internet para las transferencias de
archivos entre computadores.
FrameWork: Define un entorno de trabajo, explicando como se deben dividir los componentes del trabajo para un mejor funcionamiento. Entrega un ordenamiento y estructuracion
del trabajo. En el caso de esta memoria se uso el Struts Framework.
Servlets: Pequenos programas que se ejecutan en el servidor, en un contexto de aplicacion
cliente-servidor. Algunos manejan interacciones con Bases de Datos y permiten ingreso de
datos por parte de los usuarios. Para esta memoria se utilizaron Servlets escrito en el lenguaje
Java.
CGI: Es la va estandar por medio de la cual un servidor Web entrega los requerimientos de
un usuario a una aplicacion y recibe la respuesta de la aplicacion para entregarsela al usuario.
HTML: (Hypertext Markup Language) Son los smbolos o codigos insertados en un archivo
que indican como se deben desplegar los datos e imagenes en un navegador en Internet. La
mayora de los elementos estan en pares, indicando donde comienza la instruccion y donde
termina.
XML: (Extensible Markup Languaje) Es una manera flexible de crear formatos comunes para
los datos sobre Internet. Se basa en las recomendaciones formales desde el World Wide Web
Consortium (W3C), siendo similar al lenguaje de las paginas web de hoy, el HTML.
SmallTalk: Lenguaje de programacion disenado para soportar el concepto de Programacion Orientada al Objeto, nacio en la decada de los 70.
interface Java: Metodo declarado dentro de una clase Java, pero que puede ser implementado dentro de otras clases. Gran utilidad para que distintas aplicaciones usen el mismo
metodo adecuado al entorno en donde se desempenan.
PDF417: Simbologa en dos dimensiones que permiten almacenar sobre 1.1 kilobytes de informacion que puede ser leda por una maquina, en un espacio no mas grande que el habitual
de un codigo de barras normal. Ademas, puede contener diferentes tipos de datos.
8.2. Abreviaturas
TLD: Top Level Domain.
SII: Servicio de Impuestos Internos.
DTE: Documento Tritario Electronico.
85
8.3.1. Introduccion
Bienvenido al nuevo Sistema de Facturacion de NIC Chile. Este manual a sido disenado para
ayudar al usuario a entender y utilizar esta herramienta. En e l se describe detalladamente el software
que Ud. esta proximo a usar.
Este manual esta dividido en 4 partes, en la primera se da una breve introduccion al Sistema de
Facturacion con sus objetivos y alcances, en las dos siguientes secciones se explican las funcionalidades del sistema y en la u ltima parte se muestra la solucion de problemas que podran afectar al
usuario durante la utilizacion del sistema.
86
istracion abarca aparte de las tareas tecnicas1 , las tareas administrativas de recibir solicitudes de
creacion por nuevos dominios, evitando que mas de una persona natural o jurdica tenga el mismo
nombre.
En Chile, 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.
Para generar las facturas por las operaciones comerciales que se realizan en NIC Chile, se
presenta este software, el cual permitira:
Para el correcto uso de las funcionalidades mencionadas se definen 3 roles para los usuarios del
sistema. En primer lugar esta el rol del Operador, el cual realiza las tareas tpicas del proceso de
facturacion: imprimir, asociar numero y enviar las facturas al cliente. Tambien tiene la funcionalidad de reportar las facturas generadas para el sistema contable Informat. En segundo lugar se tiene
1
87
el rol del Jefe Administrativo, el cual, ademas de las funcionalidades del operador podra revisar las estadsticas del sistema de facturacion. Finalmente se tiene el operador Administrador el
cual podra administrar los usuarios del sistema y los permisos que tendran asociados. Ademas,
podra determinar la configuracion del sistema.
Se espera que luego de la lectura del presente manual, el lector pueda usar la herramienta sin
problemas.
2. Dominios: Documentos que se generan de manera automatica procesando los pagos por
dominios. Estos documentos son de clientes distintos a la Universidad de Chile, por lo
que se pueden imprimir directamente.
3. Otros: Corresponden a los documentos que se ingresaron de forma manual al sistema,
por medio de la la funcionalidad Crear Factura.
Las interfaces, por medio de las cuales se presentan los listados de documentos pendientes,
clasificados por tipo corresponden a las figuras 8.4, 8.5 y 8.6.
Asociar Numero: Permite asociar un numero a los distintos documentos que se han impreso.
El operador, debe mirar el numero de folio que viene preimpreso en el papel de la factura,
e ingresarlo en el cuadro de texto del sector derecho de la interfaz. Luego, si selecciona
el pequeno boton, se iran proponiendo los numeros correlativos (generalmente el papel de
factura viene numerado correlativamente). La asociacion de numeros tambien es de manera
diferenciada para los distintos tipos de clasificacion de documentos (ventas internas, dominios y otros).
Luego de ingresados los numeros de las facturas que se imprimieron, se presiona el boton
89
Asociar Numeros y el sistema de manera automatica asociara los numeros ingresados a las
facturas. Con esta operacion las facturas dejan de estar pendientes por imprimir y asociar
numero, apareciendo en el listado de facturas listas por enviar. La asociacion de numeros se
realiza por medio de la interfaz de la figura 8.7.
Enviar Facturas: Con esta opcion, se generara un listado que contiene los campos necesarios
para que la empresa de correos pueda despachar las facturas a los domicilios de los clientes.
Si el operador decide enviarlas, debe presionar el boton Enviar Todo el Listado, con lo cual
de manera automatica se genera un mail para la empresa de correos y actualiza los registros
de las facturas al estado enviadas, las que no vuelven a aparecer en los listados de pendientes
ni por enviar. Todo este proceso se gatilla desde la interfaz mostrada en la figura 8.8.
Listados Informat: Permite generar de manera automatica los listados para enviarlos al sistema Informat. Estos listados cumplen todos los requerimientos impuestos por Informat
(numero de lneas, campos necesarios y el formateo exigido) y el operador los podra visualizar antes de enviarlos, presionando en la opcion Ver asociada al numero del Informe. En
primera instancia se enviaran listados de 40 facturas, una vez que se realiza el reconocimiento
desde Informat se realizaran los ingresos de facturas en grupos de 30.
90
Para realizar el primer envo a Informat, primero se deben generar los traspasos, los que se
realizan desde la interfaz de la figura 8.9, para luego enviar los informes como se muestra en
la figura 8.10.
Ver Informes: Opcion que desplegara en pantalla informes de estadsticas de ventas de dominios, clasificados por la ubicacion geografica de los clientes, tipo de cliente, fechas, etc.
91
El uso de estas funciones permitira al usuario realizar todo el proceso de facturacion para los
temes ingresados en forma automatica (los dominios) y los temes ingresados en forma manual
(creacion de facturas).
92
1. Administracion de Usuarios: Con esta alternativa el administrador podra realizar tareas como:
crear, modificar y eliminar usuarios. Ademas, debera indicar que tipo de permisos tendra el
usuario que se tiene seleccionado.
2. Configurar Sistema: Por medio de esta accion, el administrador podra revisar la configuracion
actual del sistema. Esta configuracion abarca las opciones de acceso para las conexiones a
las bases de datos, de las constantes del sistema, valores de configuraciones propias de los
listados, como la cantidad de lineas que se deben mostrar en una sola pagina, etc.
Una serie de configuraciones del sistema no se podran realizar por medio de una interfaz web,
para ellas el administrador debera revisar y editar los archivos necesarios para ello. Dentro de estas
configuraciones esta el de las sentencias que interactuaran con las Bases de Datos.
93
95
R: Las facturas creadas quedan en el listado clasificado como Otros, asegurese de seleccionar esta opcion para que el sistema despliegue el listado. Cuando cree la factura, asegurese
de presionar el boton Grabar Factura.
P: El listado de envo de la nomina a la empresa de correos tiene mas temes que los facturados el da de hoy
R: Este listado muestra todas las facturas que estan en estado pendiente de envo al correo,
las que puede poseer temes facturados varios dias atras, pero que no han sido enviados. Si
esta seguro de que el tem ya fue enviado, contactese con el Administrador del sistema.
96
Figura 8.9: Listado de Facturas listas para Informat, ordenadas por fecha.
Recopilar los pagos desde la base de datos de pagos, en la cual se insertan los pagos realizados
por medio de WebPay y Servipag.
Una vez que se tienen los nombres de dominios pagados junto con su numero de proceso,
se procede a obtener los datos necesarios para emitir la factura, desde la base de datos de
97
registro de dominios.
Con los datos a facturar se busca al cliente dentro de la base de datos de facturacion. De no
estar, se inserta y se obtiene su identificador. Para la insercion, se debe buscar dentro de la
misma base de datos la comuna y ciudad correspondiente. De no estar, se deben insertar. Si
el cliente ya estaba insertado, se obtiene su identificador.
Con el identificador del cliente se busca alguna factura pendiente como para insertar el registro como detalle. Si existe, se obtiene el identificador de la factura. De lo contrario, se
inserta como un nuevo documento para el cliente y se obtiene el identificador.
Con el identificador del documento se insertan los datos del dominio como detalles del documento (asociado con el identificador del documento, obtenido en el paso anterior).
Finalmente, se debe actualizar la informacion del documento, sumando el IVA y el precio
correspondiente al nuevo detalle.
98
En la figura 8.14 se muestra en detalle el proceso de crear y grabar una nueva factura.
Para crear una factura, en primer lugar el operador debe haber ingresado al sistema, validandose
con los datos que figuran en la base de datos. Una vez validado el usuario, visualizara la pagina
principal del sistema de facturacion, desde la cual, seleccionara crear factura. Luego, se desplegara una interfaz de creacion de una factura, en donde se solicitan los campos obligatorios que debe
poseer este documento. Una vez ingresados los datos se procede a grabar la factura en la base de
datos. Finalmente, se debe redirigir el navegador del usuario a la pantalla principal del sistema de
facturacion.
El proceso de Imprimir facturas en detalle queda explicado en la figura 8.15. El usuario luego
de validarse, y seleccionar del menu principal del sistema de facturacion Imprimir Facturas, se
desplegara un listado con las facturas del tipo que selecciono imprimir 2. Luego podra seleccionar un
2
99
subconjunto de ellas dando la orden de imprimirlas. Con esto, para cada factura se crea un archivo
de impresion en un directorio temporal del servidor, el que se manda a imprimir con el comando y
la impresora indicada en la configuracion del sistema.
Cuando el operador desea Asociar Numero a las facturas pendientes por emitir, luego de
ingresar y validarse, seleccionara la opcion de Asociar Numero con el tipo de documento correspondiente (en el caso de comprobantes internos, es el numero de comprobante), luego el sistema desplegara un listado con los documentos a los cuales les puede asociar numero. El operador
seleccionara los documentos ingresando los numeros que desea asociarles (el numero que viene
preimpreso en el papel factura). Finalmente, ejecutara la accion de asociar por medio de la cual se
le comunica a la base de datos de la asociacion, modificando el registro del documento. Toda esta
interaccion queda reflejada en la figura 8.16.
El envo de las facturas es el momento en que una factura deja de aparecer como pendiente y
termina su ciclo. Para acceder a este proceso, el usuario luego de validarse e ingresar al sistema,
100
Pagos
Dominios
Registros
de Pagos
Recopilar
Pagos
Datos de
Facturacin
Doiminio
pagado
Obtener
Datos
Factura
Fin
Datos de
la factura
Busqueda
de cliente
Datos de
Cliente
Inserta
Cliente
No est
Cliente
Facturacin
Datos
cliente
cliente
Documento
pendiente
Datos
documento
actualizados
cliente
Busqueda
de Documento
Pendiente
No est
documento
documento
Actualizacin
Dato documento
Facturacin
Datos
documento
Inserta
Documento
documento
Inserta
Detalle
documento
selecciona la opcion Envo de Facturas, desde el menu principal del sistema. Luego, se desplegara un listado (con el formato adecuado y los datos necesarios) con las facturas, listado que debe
imprimir con dos copias, una para la empresa de correos y otra para NIC Chile, como control interno. Una vez impresas las dos copias del listado, el operador ejecutara la accion de envo de facturas,
la cual generara un mail a la empresa de correos con el listado de facturas. Todo este proceso, se
muestra en la figura 8.17.
Dentro de los errores que podra cometer el operador del sistema, esta el ingreso de un numero
equvoco para asociar a los datos de la factura. Este error se puede reparar por medio de la opcion
101
Ingreso al
Sistema
Sistema
Manual
Validacin
Usuario
Facturacin
Principal
Facturacin
Crear
Factura
Crear
Factura
Resultado
Grabacin
Datos
Factura
Datos
Factura
Grabar
Factura
Ingreso al
Sistema
Validacin
Usuario
Sistema
Manual
Facturacin
Principal
Facturacin
Imprimir
Factura
Resultado
Impresin
Archivos
Impresion
Sistema
Facturas
por Imprimir
Facturas
seleccionadas
Impresin
Facturas
del menu: Editar Facturas, con la cual al operador se le mostrara un listado con las facturas que
estan en la base de datos del sistema, desde el cual seleccionara una, luego se desplegaran en
102
Ingreso al
Sistema
Validacin
Usuario
Sistema
Manual
Facturacin
Principal
Facturacin
Asociar
Nmero
Resultado
asociacin
Listado de
Facturas
Facturas
seleccionadas
con nmero
Nmero y
Factura
asociada
Asociacin
Nmeros
Ingreso al
Sistema
Sistema
Manual
Validacin
Usuario
Facturacin
Principal
Facturacin
Envo
facturas
Resultado
de envio
Nmeros de
Facturas
enviada
Listado de
Facturas
Envo de
Facturas
Enviar
Sistema
Impresin de
listado
pantalla los datos de la factura seleccionada, para poder ser editados, en particular el numero que
asocio previamente. Los procesos de esta funcionalidad se muestran en la figura 8.18.
103
Ingreso al
Sistema
Sistema
Manual
Validacin
administrador
Principal
Facturacin
Facturacin
Editar
Factura
Datos
Factura
Datos Factura
Listado
Facturas
Factura
Datos
Actualizados
Actualizar
datos
Ingreso al
Sistema
Sistema
Manual
Validacin
administrador
Principal
Facturacin
Facturacin
Administar
Usuarios
Seleccin
usuario
Datos
usuario
Datos Usuario
Usuario
Datos
Actualizados
Eliminar
Actualizar
datos
Eliminar
Usuario
Eliminacin
Usuario
Ingreso al
Sistema
Sistema
Manual
Validacin
administrador
Facturacin
Principal
Facturacin
Resultado
actualizacin
Configurar
Sistema
Datos
Configuracin
Configuracin
Actualizada
Sistema
ser enviadas, el operador podra seleccionar Enviar Informes, con lo cual de forma interna se arman los informes con el formato exigido y se envan por Internet al servidor de Informat. Luego,
cuando desde Informat se reconozca el ingreso de las facturas, se podra efectuar el envo nueva105
mente, esta vez con un nuevo formato. Una vez que se envan las facturas a Informat, se procede
a realizar una actualizacion en la base de datos para los registros de estas facturas, modificando
una variable que marca el estado de estas facturas, as ya no volveran a aparecer en los listados de
facturas pendientes de enviar. Todos estos procesos se ven reflejados en la figura 8.21.
Ingreso al
Sistema
Validacin
Usuario
Sistema
Manual
Facturacin
Principal
Facturacin
Listados
Informat
Resultado
envio
Listados por
Enviar
Factura
enviada
a Informat
Envo a
Informat
Envo
Informe
Sistema
Comunicacin
servidor
Informat
106
Ingreso al
Sistema
Validacin
Usuario
Sistema
Manual
Facturacin
Principal
Facturacin
Reportes
Datos
Reporte
Listados de
Reportes
Reporte
Seleccionado
Despliegue
Reporte
logon.title=Ingreso al Sistema
index.title=Sistema de Facturaci
on
index.logoff=Salir del Sistema
index.home=Ir al Inicio
prompt.username=Usuario
prompt.password=Password
#MANEJO DE ERRORES
error.password.mismatch=<li>Usuario y/o Password incorrectos
107
Para poder hacer uso de estos mensajes, primero se deben incluir dentro del archivo de configuracion del WEB, llamado web.xml, de la forma:
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<!-- Action Servlet Configuration -->
<servlet>
<servlet-name>action</servlet-name>
<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:
<%@
<%@
<%@
<%@
<%@
<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.
<struts-config>
name="logonForm"
type="cl.nic.dte.web.LogonForm"/>
name="CrearFacturaForm"
109
<form-bean
<form-bean
<form-bean
type="cl.nic.manual.CrearFacturaForm"/>
name="DatosImprimirForm"
type="cl.nic.manual.DatosImprimirForm"/>
name="PorAsociarNumeroForm"
type="cl.nic.manual.PorAsociarNumeroForm"/>
name="EnviarFacturaManualForm"
</form-beans>
<global-forwards>
<forward
name="logoff"
<forward
name="logon"
<forward
name="manual"
</global-forwards>
path="/logoff.do"/>
path="/logon.jsp"/>
path="/manual/manual.jsp"/>
path="/logon"
type="cl.nic.dte.web.LogonAction"
name="logonForm"
scope="request"
input="/logon.jsp">
<forward name="electronico"
path="/keystores.jsp"/>
<forward name="nokeystores"
path="/bienvenida.jsp"/>
<forward name="manual"
path="/manual/manual.jsp"/>
</action>
<action
path="/asociarnumeromanual"
type="cl.nic.manual.AsociarNumeroManualAction"
name="PorAsociarNumeroForm"
scope="request"
input="/porasociarnumero.do">
<forward name="success" path="/manual/asociarnumeromanual.jsp"/>
</action>
<action
path="/crearfactura"
type="cl.nic.manual.PorCrearFacturaAction"
name="CrearFacturaForm"
scope="request"
input="/crearfactura.jsp">
<forward name="success"
path="/manual/crearfactura.jsp"
110
</action>
<action
path="/grabarfactura"
type="cl.nic.manual.GrabarFacturaAction"
name="CrearFacturaForm"
scope="request"
input="/crearfactura.do">
<forward name="success"
path="/manual/grabarfactura.jsp
</action>
<action
path="/porenviarfacturas"
type="cl.nic.manual.PorEnviarFacturasAction"
name="PorEnviarFacturasForm"
scope="request"
input="/manual/manual.jsp">
<forward name="success"
path="/manual/porenviarfacturas
</action>
<action
path="/enviarlistadomanual"
type="cl.nic.manual.EnviarListadoManualAction"
name="EnviarFacturaManualForm"
scope="request"
input="/porenviarfacturas.do">
<forward name="success"
path="/manual/enviolistado.jsp"
</action>
</action-mappings>
</struts-config>
En la primera parte del archivo se definen los nombres de los archivos que realizaran la definicion y validacion de los beans que se usaran dentro de la accion. Luego en la definicion de los
action-mappings solo se referencia el nombre definido.
En la segunda parte del archivo se definen 3 nombres globales que al ser referenciados desde
cualquier otro JSP referenciaran al archivo definido por el parametro path.
111
En el primer mapeo definido, se define el path logon, el cual puede ser referenciado desde
otro componente directamente, al ejecutar la accion logon, se validan los campos con el archivo
LogonForm, el cual posee las correspondientes reglas de validacion, si cumple con la validacion
se ejecutara el servlet LogonAction, si este retorna electronico, dara paso al archivo JSP: keystores.jsp, si retorna nokeystores dara paso al JSP: bienvenida.jsp y si retorna manual dara paso
al JSP de inicio del sistema manual: manual.jsp
A continuacion se muestra un extracto del archivo LogonForm:
package cl.nic.dte.web;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionMapping;
112
En este archivo se definen los 3 campos usados en el formulario de ingreso al sistema: username,
password y tipo. Ademas deben estar los metodos set y get para cada campo, junto con el metodo
validate, el cual retorna los mensajes de errores en el mismo JSP que ve el usuario o pasa el control
al servlet.
Un extracto del servlet que valida el ingreso de usuario (LogonAction) es:
package cl.nic.dte.web;
public final class LogonAction extends org.apache.struts.action.Action {
113
UserContext.derivatePassword(username + password))){
errors.add(
ActionErrors.GLOBAL_ERROR,
new ActionError("error.password.mismatch"));
saveErrors(request, errors);
uctx.error("LogonAction: password incorrecto");
return (new ActionForward(mapping.getInput()));
}
} catch (NoSuchAlgorithmException e) {
errors.add( ActionErrors.GLOBAL_ERROR,
new ActionError("error.password.mismatch"));
saveErrors(request, errors);
uctx.error("LogonAction: password incorrecto");
return (new ActionForward(mapping.getInput()));
}
try {
// Cargo los keystores del usuario (sin incializarlos)
uctx.loadKeystores();
} catch (Exception e) {
uctx.error("LogonAction: Problemas al cargar el KeyStore " + e);
throw (new ServletException("Error al cargar KeyStores: " + e));
}
HttpSession session = request.getSession();
// Asigno el bean a la sesion y ajusto el time out de la sesion
session.setAttribute("UserContext", uctx);
session.setMaxInactiveInterval(
Integer.parseInt(config.getString("SESSION_TIME")));
uctx.log("LogonAction: Ingreso al sistema");
// Remove the obsolete form bean
if (mapping.getAttribute() != null) {
if ("request".equals(mapping.getScope()))
request.removeAttribute(mapping.getAttribute());
else
session.removeAttribute(mapping.getAttribute());
}
if ("E".equals(tipo))
if (uctx.getKeystores().isEmpty())
return (mapping.findForward("nokeystores"));
115
else
return (mapping.findForward("electronico"));
else
return (mapping.findForward("manual"));
} catch (ClassNotFoundException e) {
errors.add( ActionErrors.GLOBAL_ERROR,
new ActionError("error.db.connection"));
servlet.log("LogonAction: error al Conectarse a la DB: " + e);
saveErrors(request, errors);
return (new ActionForward(mapping.getInput()));
} catch (SQLException e) {
errors.add( ActionErrors.GLOBAL_ERROR,
new ActionError("error.db.connection"));
servlet.log("LogonAction: error al Conectarse a la DB: " + e);
saveErrors(request, errors);
return (new ActionForward(mapping.getInput()));
}
}
}
Lo primero que se realiza en el servlet es recibir los parametros que ingreso el usuario en el
formulario, luego se carga la configuracion declarando un nuevo ResourceBundle, desde el cual
se leeran algunos parametros de configuracion. A continuacion, se intenta conectar con la base de
datos para validar al usuario que ingresa, luego se obtienen los permisos del usuario, guardandolos como valores de la sesion, finalmente se genera el mensaje para el mapeo correspondiente:
nokeystores, electronico o manual.
El archivo de ResourceBundle mencionado tiene mensajes de la forma:
# duracion de la sesion
SESSION_TIME=1800
# Propiedades de la DB del SII con cacherut
DB_DRIVER_SII=com.mysql.jdbc.Driver
DB_URL_SII=jdbc:mysql://localhost/BaseDatosSII
DB_USER_SII=usuario
116
DB_PASSWORD_SII=usuario
# Propiedades de la DB ToDo
DB_DRIVER_ToDo=com.mysql.jdbc.Driver
DB_URL_ToDo=jdbc:mysql://localhost/BaseDatosToDo
DB_USER_ToDo=usuario
DB_PASSWORD_ToDo=usuario
# Variables de las facturas
EMPRESA_CORREOS=Chileservice
PATH_FORMATO_FACTURA=/src/cl/nic/manual/formato_factura.txt
TAMANO_LETRA_FACTURA=12
COMANDO_IMPRIMIR_FACTURA=/usr/bin/lpr -Pfacturas
DIRECTORIO_FACTURAS=/tmp/
CENTRO_COSTO=1966
ITEM=6.1.01.03.01 (2152)
CANCELAR_A=Universidad de Chile
117
Estos mensajes son tratados de la misma forma como se tratan los mensajes de internacionalizacion, como se pudo apreciar es muy u til para definir las sentencias SQL que interactuan con la
base de datos.
Otro mapeo definido en el archivo struts-config.xml es el de Asociar Numero a las facturas. Esta
accion usa el archivo PorAsociarNumeroForm para validar los campos del formulario mostrado por
porasociarnumero.do, si la validacion es correcta el control pasa a AsociarNumeroManualAction
para ejecutar las acciones correspondientes, si este u ltimo retorna success, el usuario vera en en
navegador el JSP asociarnumeromanual.jsp.
Un extracto del archivo que muestra en pantalla el listado de los temes por asociar numero es:
<%@
<%@
<%@
<%@
<%@
<html:html>
<head>
<title><bean:message key="porenviar.title"/></title>
<html:base/>
</head>
<table width=100%>
<dl>
<logic:iterate id="DatoDocumento" type="cl.nic.dte.web.DatoDocumento"
name="datosfacturas" scope="request">
<tr><td>
<dt style="background-color: cyan"><b>
<bean:write name="DatoDocumento" property="nombre"/></b>
(<bean:write name="DatoDocumento" property= "rut.formated"/>,
<bean:write name="DatoDocumento" property="fecha"/>)
</td>
<td bgcolor="cyan">
<html:multibox property="datoFacturas" onclick="sgteNumero()">
<bean:write name="DatoDocumento" property="id"/></html:multibox>
<html:text name="numerodefactura" property="numerodefactura"
size="8" maxlength="8" value="" /> </td> </tr>
118
<tr><td colspan="2">
<logic:iterate id="detalle" type="cl.nic.dte.web.Detalle"
name="DatoDocumento" property="detalles">
<dd><bean:write name="detalle" property="cantidad"/> <bean:write name="detalle" property="nombre"/>:
<bean:write name="detalle" property="descripcion"/>
</dd>
</logic:iterate>
</td>
</tr>
</logic:iterate>
</dl>
</table>
En este archivo se muestra el como utilizar los tags de la estructura logica, para realizar iteraciones sobre colecciones de objetos. En este caso se presentan 2 ciclos anidados.
Un extracto de este segundo ejemplo del archivo PorAsociarNumeroForm es:
package cl.nic.manual;
import
import
import
import
javax.servlet.http.HttpServletRequest;
org.apache.struts.action.ActionError;
org.apache.struts.action.ActionErrors;
org.apache.struts.action.ActionMapping;
119
120
ps_ins_folio.setString(4, "Enviada");
ResultSet rs_ins_folio = ps_ins_folio.executeQuery();
// hacer el update de DATO_DOCUMENTO en el campo estado
PreparedStatement ps_update_dato =
uctx.getConnection().prepareStatement(
config.getString(
"DB_UPDATE_DATO_DOCUMENTO_ENVIO_MANUAL"));
ps_update_dato.setString(1, idDocumento.toString());
ResultSet rs_update_dato = ps_update_dato.executeQuery()
return (mapping.findForward("success"));
}
catch (Exception e) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("error.db.connection"));
try {
uctx.error("EnviarFacturamanualAction: error con la DB: "+
}
catch (SQLException e2) {
servlet.log("EnviarFacturamanualAction: error con la DB(2)
+e2);
}
}
saveErrors(request, errors);
return (new ActionForward(mapping.getInput()));
}
}
Este servlet, luego de validar al usuario que lo solicita rescatando los valores de la sesion,
recupera los datos que se enviaron por medio del formulario correspondiente, para poder ejecutar
122
las acciones necesarias por cada elemento, en este caso el asociar un numero al registro de la factura
en la base de datos.
</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>
<!-- Action Servlet Mapping -->
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<!-- The Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<!-- Application Tag Library Descriptor -->
<taglib>
<taglib-uri>/WEB-INF/app.tld</taglib-uri>
<taglib-location>/WEB-INF/app.tld</taglib-location>
</taglib>
<!-- Struts Tag Library Descriptors -->
<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>
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
Bibliografa
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
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: