a89730_Soto_H_Sistema_de_Administracion_contable_Confenats_2013_Tesis_1

Vista previa del material en texto

UNIVERSIDAD NACIONAL 
ANDRES BELLO 
liii IliHili 11111111111 11111111 
35613000239010 
UNIVERSIDAD ANDRES BELLO 
FACULTAD DE INGENIERíA 
ESCUELA DE INFORMÁTICA 
INGENIERÍA EN COMPUTACIÓN E INFORMÁTICA 
UNIVERSIDAD 
ANDRES BELLO 
Sistema de Administración Contable Confenats. 
Hipólito Alejandro Soto Aguilera. 
Alejandro Segundo Valdebenito Cruz. 
PRØYECTOPE TITULO PARA OPTAR AL TITULO 
DE INGNIERO EN GESTIÓN INFORMÁTICA 
ANDRES SELLO 
SANTIAGO - CHILE 
JULIO 2013 
ÍNDICE TEMÁTICO 
CONTENIDOS N° Pág. 
RESUMEN 7 
1 INTRODUCCIÓN. 9 
1.1 ANTECEDENTES DE LA EMPRESA 9 
1.2 HISTORIA. 9 
1.3 OBJETIvOS DE CONFENATS 9 
1.4 ORGANIGRAMA 10 
1.5 SITUACIÓN ACTUAL 11 
1.6 ACTORES RELEVANTES DE LA SITUACIÓN ACTUAL 12 
1.7 IDENTIFICACIÓN DEL PROYECTO 12 
1.8 PLANTEAMIENTO DEL PROBLEMA. 13 
1.9 ALCANCE DEL PROYECTO 13 
1.10 SUPUESTOS DEL ALCANCE 14 
1.11 LIMITACIONES DEL ALCANCE. 15 
2 FUNDAMENTACIÓN. 17 
2.1 OBJETIVOGENERAL 17 
2.2 OBJETIVO ESPECÍFICOS 17 
2.3 IDENTIFICACIÓN DE ACTORES Y ROLES DE CLIENTE 17 
2.4 DESCRIPCIÓN DE PLATAFORMA ACTUAL. 17 
2.5 SOLUCIÓN PROPUESTA 18 
2.6 ARQUITECTURA A UTILIZAR EN LA APLICACIÓN 22 
2.7 HERRAMIENTAS PARA EL DESARROLLO DE LA SOLUCIÓN 23 
2.8 FACTORES CRÍTICOS DE ÉXITO. 23 
2.9 GESTIÓN TI DE LA ORGANIZACIÓN 24 
2.9.1 Estrategia de negocio 24 
2.9.2 Arquitectura de TI 24 
2.9.3 Infraestructura de TI 24 
2.10 ESTIMACIÓN DE COSTOS DEL PROYECTO. 24 
2.11 TABLA DE HOMOLOGACIÓN. 25 
3 METODOLOGÍAS. 27 
3.1 MODELO PARA EL DESARROLLO DEL PRODUCTO 27 
3.2 ADMINISTRACIÓN DEL PROYECTO. 28 
3.2.1 Metodología de Administración de Proyecto. 28 
3.2.2 Equipo de Proyecta 28 
3.3 PLAN DE PROYECTO 29 
3.3.1 Plan de Documentoción 29 
3.3.2 Plan de Resolución de Problemas 29 
3.3.3 Plan de Pruebas 29 
3.3.4 Plan de Comunicación. 30 
3.3.5 PIan de Aceptación del proyecto. 30 
3.3.6 Roles y Responsabilidades 31 
3.3.7 Estructura del Desglose del Trabajo (WBS). 32 
3.3.8 Crono gramo del proyecto 32 
3.4 CONTROL DE PROYECTO 33 
3.4.1 Gestión de Cambios. 33 
3.4.2 Gestión de Riesgos 33 
3.4.3 Matriz de Riesgos. 34 
2 
3.4.4 Matriz de Riesgas Reducidas 34 
3.5 EJECuCIÓN DEL PROYECTO. 35 
3.5.1 Construcción de Campanentes y Módulos 35 
3.5.2 Diagramo de Despliegue 35 
3.5.3 Estrategia de Poblamienta de Datas 36 
3.5.4 Estrategia de Poblamiento de Capacitación 36 
3.5.5 Estrategia de Pruebas 36 
3.5.6 Informe de Pruebas. 36 
3.6 ENTREGABLES DEL PROYECTO 36 
3.6.1 Documentación de análisis y diseño 36 
3.6.2 Prototipo 36 
3.7 HERRAMIENTAS UTILIZADAS 37 
4 INTRODUCCIóN AL CAPÍTULO 39 
4.1 
4.2 ROLES Y RESPONSABILIDADES 
4.3 RESULTADO DEL PLAN DE COMUNICACIÓN. 
4.4 RESULTADO DE PLAN DE TRABAJO 
4.5 RESULTADO DE PLAN DE GESTIÓN DE RIESGOS 
4.6 RESULTADO DE GESTIÓN DE LA CONFIGURACIÓN. 
4.7 RESULTADO DE PLAN DE INFRAESTRUCTURA 
4.8 RESULTADO PLAN CIERRE DEL PROYECTO. 
4.9 REQUERIMIENTOS FUNCIONALES 
4.9.1 Módulo Seguridad. 
4.9.1.1 Mantenedores 
4.9.1.2 Operaciones 
4.9.2 Módulo Diseñador 
4.9.2.1 Mantenedores Generales 
4.9.2.2 Configuraciones 
4.9.2.3 Operaciones 
4.9.2.4 Consultas. 
4,9.3 Módulo Contabilidad 
4.9.3.1 Operaciones. 
4.9.3.2 Consultas. 
4.9.3.3 Listados. 
4.9.4 Módulo Conciliación. 
4.9.4.1 Operaciones. 
4.10 RESULTADOS DEL DISEÑO. 
4.10.1 Casos de Uso 
4.10.1.1 Accederal Sistema 
4.10.1.2 Definición y administración de perfiles de seguridad. 
4.10.1.3 Diseño Contable 
4.10.1.4 Operaciones Contables 
4.10.1.5 Conciliación Bancaria 
4.10.1.6 Administración de Períodos y ejercicios 
4.10.2 Diagramo de clases 
4.10.3 Modelo de Dotas 
4.10.4 Diagrama de Componentes. 
4.10.5 Diagramo de Despliegue 
4.10.6 Procesos 
4.10.7 Prototipo 
4.10.8 Logros. 
4.10.9 Métricos de Logros Alcanzados. 
CONCLUSIONES 
BIBLIOGRAFÍA. 
3 
39 
39 
39 
39 
40 
42 
43 
43 
43 
43 
43 
46 
48 
48 
51 
57 
58 
62 
62 
64 
65 
66 
66 
68 
68 
68 
70 
71 
72 
73 
75 
76 
77 
78 
79 
80 
82 
85 
87 
90 
92 
EQUIPO DE TRABAJO 
ÍNDICE DE TABLAS 
TABLA 1 ESTIMACIÓN COSTO. 24 
TABLA 2 TABLA DE HOMOLOGACIÓN 25 
TABLA 3 ROLES DE EQUIPO DE PROYECTO 31 
TABLA 4 ROLES DE CLIENTE 31 
TABLA 5 TABLA DE RIESGOS 34 
TABLA 6 TABLA DE RIESGOS MITIGADOS 34 
TABLA 7 TABLA DE ESTIMACIÓN ORIGINAL 39 
TABLA 8 TABLA DE HORAS REALES 40 
TABLA 7 FORMULARIO MANTENCIÓN DE USUARIOS. 44 
TABLA 8 FORMULARIO MANTENCIÓN DE EMPRESAS 45 
TABLA 9 FORMULARIO MANTENCIÓN DE MÓDULOS 45 
TABLA 10 FORMULARIO MANTENCIÓN DE TRANSACCIONES DE SEGURIDAD. 45 
TABLA 11 FORMULARIO MANTENCIÓN DE PERFIL DE SEGURIDAD 46 
TABLA 12 FORMULARIO AUTENTICACIÓN DE USUARIO 46 
TABLA 13 FORMULARIO CAMBIO DE PASSWORD 47 
TABLA 14 FORMULARIO ASIGNACIÓN DE PERFILES DE USUARIO 47 
TABLA 15 FORMULARIO MANTENCIÓN DE ÁREA DE NEGOCIO. 48 
TABLA 16 FORMULARIO MANTENCIÓN DE SUCURSALES. 48 
TABLA 18 FORMULARIO MANTENCIÓN DE CENTROS DE COSTOS. 49 
TABLA 19 FORMULARIO MANTENCIÓN DE SUBSISTEMAS 49 
TABLA 20 FORMULARIO ADMINISTRACIÓN PERSONAS. 50 
TABLA 21 FORMULARIO ADMINISTRACIÓN DE DATOS BÁSICOS. 50 
TABLA 22 FORMULARIO MANTENCIÓN DE DATOS DICCIONARIOS 51 
TABLA 23 FORMULARIO MANTENCIÓN DE CONFIGURACIONES. 52 
TABLA 24 FORMULARIO MANTENCIÓN DE TIPO PLAN DE CUENTA 52 
TABLA 25 FORMULARIO MANTENCIÓN DE PLAN DE CUENTA. 53 
TABLA 26 FORMULARIO MANTENCIÓN DE ESTRUCTURA CONTABLE 53 
TABLA 27 FORMULARIO DEFINICIÓN DE LÓGICAS CONTABLES 54 
TABLA 28 FORMULARIO DEFINICIÓN DE LÓGICAS CONTABLES 55 
TABLA 29 FORMULARIO DEFINICIÓN DE FORMULARIOS CONTABLES-ENCABEZADO 57 
TABLA 30 FORMULARIO ADMINISTRACIÓN DE SEGURIDAD DE FORMULARIOS CONTABLES 57 
TABLA 31 FORMULARIO ADMINISTRACIÓN DE EJERCICIOS CONTABLES 58 
TABLA 32 FORMULARIO ADMINISTRACIÓN PERÍODOS CONTABLES 58 
TABLA 33 FORMULARIO CONSULTA ÁREA DE NEGOCIO. 59 
TABLA 34 FORMULARIO CONSULTA DATOS DICCIONARIOS 59 
TABLA 35 FORMULARIO CONSULTA SUCURSALES 60 
TABLA 36 FORMULARIO CONSULTA MONEDAS. 61 
TABLA 37 FORMULARIO CONSULTA CENTRO DE COSTOS. 61 
TABLA 38 FORMULARIO SELECCIÓN DE FORMULARIO CONTABLE PA INGRESO. 62 
]ABLA 39 FORMULARIO SELECCIÓN DE FORMULARIO CONTABLE PARA INGRESO 53 
TABLA4O INGRESODEVOUCHER 54 
TABLA41 CONSULTADEVOUCHER 64 
TABLA 42 CONSULTA DE FORMULARIOS 65 
TABLA 43 EMISIÓN DE BALANCE. 66 
TABLAM REGISTRODECARTOLA. 66 
TABLA 45 MOVIMIENTOS No CONCILIADOS 67 
TABLA 46 CONCILIACIÓN AUTOMÁTICA. 67 
TABLA 47 CONCILIACIÓN MANUAL. 67 
TABLA4S CASoDEUSol. 69 
TABLA49 CASODEUSO2. 70 
4 
TABLA 50 CASO OE Uso 3. 72 
TABLAS1 CASODEUSO4. 73 
TABLAS2 CASODEUSOS. 74 
TABLAS3 CASODEUSO6. 75 
TABLA 54 TABLA DE OBJETIvOS 75 
TABLA 55 TABLA DE PROBLEMAS 75 
TABLA 56 METRICAS OBJETIVO VIS PROBLEMAS 75 
TABLA 57 TABLA DE REQUERIMIENTOS 75 
TABLA 58 TABLA METRICA REQUERJMIENTOS VIS OBJETIVOS 75 
TABLA 59 TABLA METRICA PROBLEMA vis REQUERIMLENTOS 75 
5 
ÍNDICE DE FIGURAS 
FIGURA 1 ORGANIGRAMA DE CONFENATS. 10 
FIGURA 2 PROCESO ACTUAL FINANCIERO - CONTABLE 11 
FIGURA 3 PROCESO ACTUAL DE CONCILIACIÓN BANCARIA 12 
FIGURA 4 ACTORES RELEVANTES DE LA SITUACIÓN ACTUAL 12 
FIGURAS DIAGRAMACAUSA-EFECTO 13 
FIGURA 6 ESTRUCTURA DE MAYOR PARA IMPUTACIÓN DE CUENTAS CONTABLES. 18 
FIGURA 7 APLICACIÓN DE DATOS DICCIONARIOS 18 
FIGURAS ESTRUCTURAS CONTABLES PARA LA IMPUTACIÓN DE DATOS DE GESTIÓN (AUXILIAR). 19 
FIGURA 9 EJEMPLO DE LÓGICAS CONTABLES. 19 
FIGURA 10 ELEMENTOS DE CONFIGURACIÓN DEL SISTEMA CONTABLE 20 
FIGURA 11 FUNCIONAMIENTO DE FORMULARIOS CONTABLES. 21 
FIGURA 12 ESTRUCTURAS DE BANCOS / CARTOLA DE MOVIMIENTOS 22 
FIGURA 13 ARQUITECTURA 3 CAPAS 23 
FIGURA 14 MODELO CASCADA CON RETROALIMENTACIÓN 27 
FIGURA 15 ETAPAS PMBOK. 28 
FIGURA 16 EQUIPO DE PROYECTO. 28 
FIGURA 17 EQUIPO DE PROYECTO - CLIENTE 29 
FIGURA 18 ETAPAS MODELO CASCADA 32 
FIGURA 19 CRONOGRAMA DEL PROYECTO. 32 
FIGURA 20 MÓDULOS SISTEMA CONFENATS 35 
FIGURA 21 DIAGRAMA DE DESPLIEGUE 35 
FIGURA 22 GRÁFICO DE HORAS REALES VERSUS PRESUPUESTADAS. 40 
FIGURA 23 CASO USO ACCEDER AL SISTEMA 68 
FIGURA 24 CASO Uso DEFINICIÓN Y ADMINISTRACIÓN DE PERFILES DE SEGURIDAD70 
FIGURA 25 CASO Uso DISEÑO CONTABLE. 71 
FIGURA 26 CASO USO INGRESO DE OPERACIONES CONTABLES. 72 
FIGURA 27 CASO Uso CONCILIACIÓN BANCARIA 73 
FIGURA 28 CASO Uso ADMINISTRACIÓN EJERCICIOS Y PERIODCS 75 
FIGURA 29 DIAGRAMA DE CLASES 76 
FIGURA 30 TABLAS PRINCIPALES DEVOUCHIER 77 
FIGURA 31 TABLAS PRINCIPALES DE FORMULARIOS CONTABLES 78 
FIGURA 32 DIAGRAMA DE COMPONENTES 78 
FIGURA 33 DIAGRAMA DE DESPLIEGUE 79 
FIGURA 34 PROCESO ACCEDER AL SISTEMA 83 
FIGURA 35 PROCESO ADMINISTRACIÓN DE PERFILES DE SEGURIDAD. 80 
FIGURA 36 PROCESO DISEÑO CONTABLE. 80 
FIGURA 37 PROCESO DE INGRESO DE OPERACIONES CONTABLES. 81 
FIGURA 38 PROCESO DE CONCILIACIÓN BANCARIA. 81 
FIGURA 39 PROCESO DE ADMINISTRACIÓN DE EJERCICIOS Y PERI000S CONTABLES 82 
FIGURA4O INICIOSESIÓN 82 
FIGURA 41 PERFILES DE SEGURIDAD. 83 
FIGURA 42 DISEÑO DE FORMULARIOS CONTABLE - ENCABEZADO 83 
FIGURA 43 DISEÑO DE FORMULARIOS CONTABLE - DETALLE 84 
FIGURA 44 INGRESO DE FORMULARIOS CONTABLE. 84 
FIGURA 45 INGRESO DE FORMULARIOS VOUCHERS 8S 
FIGURA 46 INGRESO DE FORMULARIOS VOUCHER - ESTRUCTURA 85 
FIGURA 47 LOGROS 86 
6 
Resumen 
El sistema de administración contable de Confenats desarrollado, tiene como objetivo principal el 
registro de asientos contables en forma estructurada y segura, aplicando las validaciones de 
negocio al momento de la imputación, lo cual facilita los procesos de análisis y gestión contable. 
La necesidad de crear un proyecto de software nace de la carencia de procesos administrativos 
contables, y el consumo excesivo de horas hombre en la ejecución de estas actividades, ya que al 
momento no se cuenta con una información estandarizada y estructurada. 
En relación a este proyecto se ocupó tecnología y será desarrollado en la plataforma Visual Basic 
6.0 como lenguaje de programación y motor de bases de datos SQL SERVER 2008. El cliente 
posee licencia de desarrollo de estos software, por lo cual, se solicitó su uso para la creación del 
proyecto de software denominado Sistema de Administración Contable Confenats, que conlleva a 
la administración contable. 
Como resultado se obtuvo un instrumento informático basado en un conjunto de necesidades 
planteadas inicialmente por la empresa en referencia. A raíz de este proyecto de software 
Confenats podrá controlar y optimizar las actividades administrativas contables. 
Al concluir el proyecto, Confenats tendrá la información necesaria con respecto a su situación 
financiera, poseer información segura y estructurada para los procesos de auditoría y actividades 
de administración contable. 
7 
CAPÍTULO ¡ 
INTRODUCCIÓN 
1 INTRODUCCIÓN. 
1.1 Antecedentes de la empresa. 
• Razón Socia! : Confenats 
• Rut : 70.024.360-5 
• Dirección : Erasmo Esca!a #2358, Santiago. 
• Teléfono : 56 02 2 6994478. 
• Presidente : Roberto Alarcón Gómez. 
• Emai! confenatschi!e@hotmail.com. 
• Socios : 17.000 aprox. 
1.2 Historia. 
Confenats, es !a continuadora legal de la Fenats Naciona!, organización que representa y ha 
representado a !o !argo de su historia a !os trabajadores de !a Sa!ud; de los estamentos 
profesiona!es y no profesionales a través de un sistema de afl!iación vo!untaria mediante e! cua! 
se adquiere !a condición de socio de !a organización base Fenats existente en cada uno de !os 
hospita!es púb!icos a !o !argo de! país. 
Confenats presenta afiliados a !o largo de todo e! territorio naciona! (!7.000 afi!iados aprox.), 
pero las tareas administrativas contables, son realizadas centralmente en Santiago. 
Confenats, por ser una organización sin fines de !ucro, no debe posee una contabi!idad tributab!e. 
1.3 Objetivos de Con fenats. 
a. Promover e! mejoramiento económico de sus afiliados y de !as condiciones de vida y de 
trabajo de los mismos. 
b. Procurar el perfeccionamiento técnico, !aboral y gremial, como también !a recreación y 
esparcimiento de sus emp!eados, incluyendo las actividades económicas que acuerde !a 
organización. 
e. Recabar información sobre !a acción de! servicio púb!ico y de !os p!anes, programas y 
resoluciones re!ativos a sus funcionarios. 
d. Hacer presente, ante !as autoridades competentes cua!quier incumplimiento de !as normas de! 
Estatuto Administrativo. 
e. Proponer a !as autoridades, criterios sobre po!íticas de recursos humanos, carrera funcionaria, 
capacitación y dar a conocer su opinión sobre gestión administrativa. 
f. Representar a !os funcionarios en los organismos y entidades en que !a ley les concediere 
participación. Podrán, a so!icitud del interesado, asumir !a representación de !os confederados 
9 
para deducir ante la Contraloría General de la República, el recurso de reclamación establecido 
en el respectivo Estatuto Administrativo. 
g. Realizar acciones de bienestar, de orientación y de formaciones gremiales, de capacitación o de 
otra índole, dirigidas al perfeccionamiento funcionario, a la recreación y al mejoramiento social 
de sus afiliados. 
h. Prestar asistencia y asesoría técnica a sus asociados y también procurarles recreación y 
esparcimiento. 
i. Constituir, concurrir a la constitución o asociarse a mutualidades, fondos y otros servicios y 
participar en ellos. Estos servicios podrán consistir en asesorías técnicas, jurídicas, educacionales, 
culturales, de promoción, socio-económicas y otras. 
j. Establecer centrales de compra o economatos. Para el cumplimiento de estas finalidades, en 
especial de las señaladas en las letras a, b, g y h, podrán celebrar convenios con instituciones 
privadas o públicas. 
k. Desarrollar todas las actividades propias de una confederación, que se acuerden según las 
disposiciones de su Estatuto. 
1.4 Organigrama. 
Confenats, está compuesta por todos sus afiliados a lo largo del territorio nacional, los cuales 
eligen a su directiva, cuyo organigrama es el siguiente: 
Carlos Ortiz Diaz 
nr l't)tiSC 
Hernán González Ruiz 
L•cto: Dçno 
 
Jcrge Araya Guerra 
Jaime Araya Godoy 
Victor Silva Alarcón 
Hunilce Sepúlveda 
Hugo González Arias 
Roberto Alarcón Gómez 
Raquel Carvacho Zapata 
Sandra Garcia Aguirre 
uF V!ynr:c, 
José Luis Escobar 
ro' 
Gina Rossi Cerda 
Figura 1 Organigrama de Confenats. 
lo 
1.5 Situación ActuaL 
El área administrativa-contable de Confenats actualmente opera a través de actividades definidas 
e independientes. Estas actividades son realizadas en forma manual, y a criterio del usuario que 
realiza la acción. 
La independencia de actividades no permite brindar la información requerida a la actividad que la 
sucede, lo cual produce un mayor esfuerzo de HH en su ejecución. Como tampoco brindan 
seguridad de acceso a la información y a posible manipulación posterior, perdiendo la 
trazabilidad de ambas, operación e información. 
P
ro
cs
so
 F
ln
n
c
k
to
 -
 C
o
n
ta
b
le
 
A
d
m
in
is
tr
a
ti
vo
 C
o
n
ta
b
le
 
ErUega 
1 
y 
o 
o 
u 
4 
 Rf<tpoonM Gerernr 
-- 
Figura 2 Proceso actual Financiero - Contable. 
II 
C
o
n
ci
li
a
c
ió
n
 
.3 
NC 
ci:Ln Q ). Si 
Se 
.novLLre10 de 
oa co? 
LSCrLLO 
J 
pL no (cccl Cont bit 
- 
conci 
xceIe 
Liacion 
Figura 3 Proceso actual de conciliación bancaria. 
Ambos procesos, financiero - contable y conciliación bancaria son realizados en forma manual, 
administrados y controlados a través de archivos Excel. 
1.6 Actores relevantes de la situación actuaL 
Los actores relevantes son el contador y el administrativo contable de la situación actual. 
Contador Administrativo Contable 
Figura 4 Actores relevantes de la situación actual. 
1.7 Identificación del proyecto. 
Confenats no posee un lineamiento de negocio definido, ya que al ser una organización sin fines 
de lucro, sus esfuerzos se encuentran en optimizar sus procesos administrativos contables. 
En base a lo anterior, Confenats posee la necesidad de: 
• Redefinición de procesos administrativos contables. 
• Estandarización de información. 
• Seguridad y trazabilidad de información. 
• Sistematizar procesos financieros-contables. 
12 
1.8 Planteamientodel problema. 
Confenats identifica los siguientes 4 puntos principales de problemas que se desean mitigar con 
la implementación de procesos y un sistema contable. A continuación se especifican: 
• Análisis contable no es realizado en forma diaria. 
• Excesivo esfuerzo de HH en análisis contables y preparación de informes. 
• Carencia de información de gestión para procesos administrativo-contable. 
• Carencia en seguridad de información. 
Formularios Físicos LP1ani11as excel 
 
Información no se 
en cuenera e sos clii ra da 
Carencia validaciones 
en el ingreso de caen tos cotables 
Existencia de jntomsacjón 
ilegible 
Ing re so osan oil de 
tnfonnnación 
Redigitación de infarnnación 
Información incompleta 
de eventos connables 
a nivel de mayor 1 
Maripsilación de 
informes de gestión 
Carencia de procesos 
/
Administrativos - Contables 
Distintas toenles 
de información rdoenisnerelac ióo entre acosiadades 
Carencia de snfornnación 
pare ejecsc ido del proceso Pérdida de infom,ación 
/
de gestión 
Uso eccesivo de HH 0/ 
/ 
Conciliación bancari!J Actividades Independientes 
Figura 5 Diagrama causa - efecto. 
1.9 Alcance del proyecto. 
El sistema contable a diseñar debe operar en forma digital los formularios contables fisicos con 
que Confenats opera actualmente. 
El sistema debe proporcionar herramientas de diseño, las cuales deben considerar 
configuraciones de las siguientes dimensiones: 
• Plan de cuentas. 
• Cuentas de mayor. 
• Datos diccionarios. 
• Estructuras contables. 
• Lógicas contables. 
• Formularios contables. 
13 
• Mantención de datos maestros, en base a los datos diccionarios definidos y configurado 
en el sistema. 
Las herramientas de diseño permiten flexibilización y escalabilidad, ya que a través de estas, el 
usuario puede generar nuevas dimensiones de gestión, simplificar el ingreso de asientos y aplicar 
nuevas reglas de negocio, sin la necesidad de realizar mejoras en el sistema, evitando de esta 
manera horas de desarrollo, permitiendo al sistema adaptarse a la realidad de Confenats. 
El sistema debe considerar la administración de periodos y ejercicios contables, además debe 
permitir la generación del proceso de conciliación bancaria. Se debe considerar la lectura del 
archivo enviado por el banco, y conciliar con respecto a los movimientos contables de la cuenta 
de banco. 
El detalle contable de los movimientos de banco, depende de la configuración de la estructura 
asignada a la cuenta de mayor de banco. El proceso de conciliación puede ser generado en forma 
manual o en forma automática. 
El sistema debe generar contemplar los siguientes informes: 
• Saldos de Mayor. 
• Saldos de auxiliar (estructura contable). 
• Balance. 
Al término de la fase de diseño se debe entregar prototipos de módulos: 
• Seguridad. 
• Diseñador. 
• Contabilidad. 
• Conciliación. 
1.10 Supuestos del alcance. 
• Confenats pone a disposición de esta solución, servidores de desarrollo y productivo, con 
sus respectivos planes de respaldo. 
• Proceso de conciliación bancaria solo contempla las entidades bancarias Corpbanca y 
Estado. 
• Entrega de plan de cuenta debe ser entregado por Confenats. 
• Se considera como proceso de implantación el diseño de 14 formularios contables, los 
cuales abarcan los asientos utilizados actualmente: 
o Ingresos. 
o Gastos Generales. 
o Remuneraciones. 
o Actividades gremiales. 
o Traslado, estadía y movilización. 
o Gastos e insumos diversos. 
14 
o Mantención y reparación. 
o Inversiones. 
o Beneficios. 
o Proyectos. 
o Traspasos. 
o Cotizaciones CUT. 
o Otros (Devolución). 
o FEP. 
• Cartolas de banco para el proceso de conciliación deben ser entregados por Confenats, y 
poseer el nivel necesario para este proceso. 
Confenats debe realizar las gestiones con su profesional de TI, para las tareas de implementación 
y respaldos de información. 
1.11 Limitaciones de/alcance. 
• El ingreso de información de carga inicial es responsabilidad de Confenats. 
o Sistema debe permitir el ingreso de esta información. 
• No se considera módulo presupuesto. 
• Aplicaciones de desarrollo y mantención se encuentra definido Visual Basic 6.0 y 
Microsoft SQL Server 2008. 
15 
CAPÍTULO II 
FUNDAMENTACIÓN 
16 
2 FUNDAMENTACIÓN. 
2.1 Objetivo GeneraL 
Construir un prototipo funcional de un sistema contable, el cual permita el registro de asientos 
contables en forma estructurada y segura, aplicando validaciones del negocio definidas al 
momento de la imputación, lo que facilita los procesos de análisis y gestión contable. 
2.2 Objetivo Específicos. 
• Conocer los procesos administrativos contables y los asientos que los componen, en caso 
de ser necesario, se realizarán mejoras. 
• Organizar registros contables en estructuras flexibles. Estas estructuras permiten obtener 
el detalle de las operaciones administrativas, otorgando la información necesaria para los 
procesos contables. 
• Administrar y entregar la trazabilidad de los formularios contables y asientos generados. 
Esto nos permite verificar el correcto y oportuno registro de las operaciones 
administrativas contables. 
• Generar asientos contables en forma automática a partir del ingreso de información a 
través formularios digitales. Esto permite separar las funciones administrativas y 
contables, evitando la re digitación de información. 
• Sistematizar proceso de conciliación bancaria, ya que actualmente se posee distintos 
orígenes de información, la cual no se encuentra estandarizada, para la ejecución de este 
proceso, lo que implica un esfuerzo excesivo. 
• Generar informes de gestión para obtener la conclusión de los procesos administrativos 
contables. 
2.3 Identificación de Actores y Roles de cliente. 
Los roles que actualmente posee nuestro cliente son los siguientes: 
• Contador, encargado de analizar e interpretar los asientos contables que respaldan las 
operaciones administrativas de Confenats. Esto conforme a las normas y procedimientos. 
• Administrativo Contable, encargado de la interpretación y digitación de los asientos 
contables y análisis de cuentas contables. 
2.4 Descripción de plataforma actuaL 
Confenats posee las siguientes herramientas para soportar el negocio actualmente: 
• Computadores con sistema operativo Windows 7 de 32 bits. 
• Impresora láser Xerox Phaser 3600 PS. 
• Office 2003 y 2007. 
17 
Titulo 1 Valo, 
INGRESOS 
Observación 
 
al No existe Item de oasto O. asociado al grupo 1 
2.5 Solución propuesta. 
El sistema contable a diseñar debe brindar una alta integridad de información y una estructura de 
plan de cuenta en base al negocio de la empresa. Se debe considerar una estructura básica de 
dimensiones de gestión como: 
• Sucursal. 
• Moneda de imputación. 
• Centro de costo. 
Estas dimensiones deben ser de carácter fijo para todas las cuentas de mayor que componen el 
plan de cuenta de la empresa. 
Figura 6 Estructura de mayor para imputación de cuentas contables. 
Con la definición de información a nivel de mayor, el sistema debe permitir el diseño de datos 
adicionales de gestión. 
Los datos diccionarios le deben permitir al sistema implementar las reglas del negocio que el 
usuario requiera. Las validaciones que esta dimensión puede aplicar son: 
• Búsqueda simple. Esto implica la validación de existencia. 
• Búsqueda relacionada. Implica la validación entre datos diccionarios. 
• Ayuda. Permitir al usuario, la opción de la búsqueda rápida de información. 
• Mantención de información para todo dato que posea una tabla de validación de 
existencia. 
1 Gruoo Gasto 
2 11am de aaslo 
Figura 7 Aplicacióu de datos diccionarios 
18 
1 
Estos datos diccionarios representan las dimensiones de gestión contable que el usuario necesita 
para la administración de la información, los cuales a través de sus procesos de validación, le 
permiten al sistema realizar las validaciones al momento del ingreso de cada transacción. 
Estos datos adicionales deben ser "agrupados" en estructurascontables, las cuales deben permitir 
el registro y consulta del detalle de las operaciones. Estas estructuras deben ser asociadas a las 
cuentas de mayor, lo que permite la implementación de una contabilidad de gestión, ya que al 
mismo tiempo de ir imputando la información, se va creando transacción a transacción una base 
de gestión, la cual le permite a la organización, contar con información oportuna y fidedigna. 
Figura 8 Estructuras contables para la imputación de datos de gestión (auxiliar). 
Con la definición de plan de cuentas y estructuras contables, el sistema debe permitir la 
definición de lógicas contables, las cuales representen el asiento a ingresar. 
REGISTROS CONTABLES 
1. Causación de los recursos 
CUENTAS POR COBRAR 
INGRESOS 
Cuota Administración XXX 
Fondo de Imprevistos X 
2. Recaudo de los recursos. 
XXXX 
CAJA / BANCOS 
CUENTAS POR COBRAR 
3. Constitucion del fondo y pmvís ion. 
XXXX 
XXXX 
FONDO LIQUIDO - Fondo de Imprevistos X 
CAJA / BANCOS X 
GPSTO FONDO DE IMPRE'I1STOS X 
PROVISIÓN FONDO DE IMPRE'ASTOS X 
4. Utilización del fondos 
PROVISIÓN IMPREVISTOS X 
FONDO LIQUIDO - Fondo de Imprevistos X 
Figura 9 Ejemplo de lógicas contables. 
19 
Establecidas las lógicas contables, el sistema posee las condiciones necesarias para la 
configuración de formularios digitales contables. 
Figura 10 Elementos de configuración del sistema contable. 
La implementación de formularios digitales, permite la simplificación de registros de asientos 
contables, configurando la solicitud de información en forma clara y estructurada, validando en 
línea la información, para que esta sea confiable. 
Los formularios digitales permiten que un usuario que no posea habilidades contables, pueda 
realizar imputaciones en una forma controlada, sin afectar sus actividades actuales y solicitando 
información que es de su conocimiento. 
20 
CONTABILI DAD: 
Toda información que ionga 
relacion con cantidades, queda 
automáticamente regleirada en 
el área de contabilidad 
9MAÇ'h7 ELT,tN/CC' ¿g GLiTOÇQP5C'l OA-lLE 
8905 F97-4 
/ 54C 
• 80I/5 / 
• 3V/Z'000 FORMULARIO ELECTRONICO 
M4IW / DE INGRESO DE DATOS: 
Diseñado por un epeciatinta 
contable para ser utihzado 
rO/4C CZ / por cualquier flrel de usuario. 
DATOS DE GESTION. 
Diseñados a la medida 
de su negocio, con toda 
le nformacion que necesite 
para la toma de decisiones 
Figura 11 Funcionamiento de formularios contables. 
FO RML1LARIO ELECTRONICO 
CONTALLL 
siNcRoNiA GARANTIZADA: 
Entre la contabdidad 
y os datos de gestión. 
La definición de estructuras contables permite el registro ordenado de los movimientos de banco 
en la contabilidad, de esta manera, el proceso de conciliación bancaria se puede realizar de una 
manera ordenada con datos confiables, provenientes desde una única fuente de información. 
Se debe implementar el proceso de lectura de cartolas enviadas por el banco. 
Para la correcta ejecución del proceso de conciliación bancaria automática se deben definir 
criterios de conciliación entre movimientos de cartolas bancarias y movimientos contables de 
bancos, esto en base a la estructura de archivo que e! banco puede brindar y el diseño de 
estructura de banco definido. 
Se debe permitir al usuario el proceso de conciliación manual, para aquellas transacciones no 
conciliadas por criterios de pareo automático. 
21 
BANCO 
 
 
Figura 12 Estructuras de bancos / Cartola de movimientos. 
2.6 Arquitectura a Utilizar en la Aplicación. 
La arquitectura a utilizar el desarrollo del software está basada en el modelo de 3 capas. 
Lo principal de este modelo es que permite la separación de la lógica de negocio con la de diseño, 
también en caso de algún cambio solo se acata al nivel requerido sin tener que revisar las demás 
capas. 
Las tres capaz son: 
• Capa Presentación. Esta capa es la que ve el usuario, le comunica la información y 
captura los datos que el usuario ingresa en un mínimo proceso. Esta capa es también 
conocida como la interfaz gráfica y se comunica solamente con la capa de negocio 
• Capa de Negocio. En esta capa están los programas que se ejecutan, aquí se establecen 
las reglas del negocio que se deben cumplir, también es llamada capa de lógica. 
• Capa de Datos. Es donde residen los datos y es la encargada de accesar a los mismos, 
está formada por gestores de bases de datos, recibe de la capa de negocio las solicitudes 
de acceso, almacenamiento y recuperación de la información. 
22 
Sentr-PT 
Servidor Archivos PC-PT 
1 
295 24 2811 
S.tfhl Confenats SwrtchO 
PC-PT 
Usuario 2 
Server-PT 
Servidor de Bases de Datos 
Figura 13 Arquitectura 3 capas. 
2.7 Herramientas para el Desarrollo de la Solución. 
Microsoft Visual Basic 6.0, es una herramienta de programación poderosa para el desarrollo de 
aplicaciones clientes-servidor, esto a pesar de ser un lenguaje de programación antiguo, es de 
conocimiento de muchos desarrolladores, y el costo de mantención por concepto de HH es 
considerablemente bajo, lo que nos proporciona un entorno adecuado para realizar pequeños 
prototipos rápidos. 
Microsoft SQL Server 2008, es un Sistema de Gestión de Bases de Datos Relacionales (SGBDR). 
El Transact-SQL soporta la definición, modificación y eliminación de bases de datos, tablas, 
índices, etc., es decir, el lenguaje de definición de datos (LDD), así como la consulta, 
actualización y borrado de duplas de tablas, es decir, el lenguaje de manipulación de datos 
(LMD). En seguridad, SQL permite administrar permisos a TODO. Permisos a nivel de servidor, 
seguridad en tablas, permitir o no lectura, escritura, ejecución; seguridad en los procedimientos 
almacenados. 
2.8 Factores Críticos de éxito. 
• El patrocinio de la alta dirección hacia los objetivos del proyecto. 
• Un equipo y recursos dedicados al proyecto. 
• Fuerte compromiso de los representantes del cliente en las etapas claves del proyecto. 
• La comunicación con el cliente cumple un rol crítico en el éxito del proyecto, por lo que 
se debe hacer un gran esfuerzo por parte del BSM para lograr capturar de la forma más 
clara posible las opiniones y solicitudes del cliente. 
• La administración de gestión del cambio es fundamental, ya que este proyecto consiste 
en la definición de nuevos procesos administrativos — contables, normalización y 
estructuración de información y la implementación de una solución de software. De lo 
23 
anterior, a los usuarios finales se debe incentivar a la nueva forma de trabajar, explicando 
los beneficios que con lleva la implementación de los cambios definidos, y ser muy 
asertivos en el proceso de capacitación. 
2.9 Gestión TI de la Organización. 
2.9.1 Estrategia de negocio. 
Confenats no posee un lineamiento de negocio definido, ya que al ser una organización sin fines 
de lucro, sus esfuerzos se centran en optimizar sus procesos administrativos contables. 
2.9.2 Arquitectura de TI. 
Confenats no posee un departamento de TI, ni un modelo de Arquitectura lógica, pero está 
consciente en la inversión de tecnología para optimizar los procesos contables que hoy soporta su 
área administrativa. Esta iniciativa es impulsada por un consultor externo, y aprobado por el 
directorio de Confenats. 
Se debe considerar que la inversión en tecnología es en base a la realidad de las operaciones que 
actualmente manejan, las cuales se encuentran en 500 transacciones contables mensuales. 
Como aplicaciones de desarrollo y mantención se encuentra definido Visual Basic 6.0 y 
Microsoft SQL Server 2008. 
2.9.3 Infraestructura de TI. 
Confenats posee implementada en su casa matriz ubicada en Santiago un intranet la cual está 
compuesta por 7 usuarios, cada uno con una unidad computacional asignada. Todos los usuarios 
pertenecen al área administrativa — contable. 
En el año 2012, se realizó la inversión de 2 servidores, los cuales deben brindar los servicios de 
bases de datos y de aplicaciones. 
Confenats no posee un Datacenter para el proceso de mantenimiento de servidores.La 
administración es realizada por un profesional externo a la compañía. 
2.10 Estimación de Costos del Proyecto. 
Para la estimación de costos se apoyo los roles que se ocupa en cada etapa modelo de ciclo de 
vida del proyecto de software, se procedió a la planificación con relación al tiempo en el que se 
desarrollaría, según Carta Gana estimada, la cual muestra según las fases un periodo tentativo de 
lo que será el desarrollo completo del proyecto. 
Rol Horas Precio UF/HH Total 
BSM 307.55 0.7 215.29 
QA 48 0.5 24 
Desarrollador 160 0.4 64 
Total 303.29 
Tabla 1 Estimación Costo. 
24 
Z 11 Tabla de homologación. 
Confenats realizo la búsqueda de un sistema contable que se adecuará a sus necesidades, plan de 
cuentas, que se adapte a su realidad de negocio y que permita una independencia de desarrollo y 
soporte en el caso de existir cambios en el negocio. 
Se consideró la opción de Softland versus la solución a implementar, de lo cual se destacan las 
siguientes funciones: 
Funcionalidad Softland Sistema 
Administración de plan de cuentas SI SI 
Flexibilidad en dimensiones de gestión NO SI 
Generación de asientos contables SI SI 
Diseño contable configurable NO SI 
Plataforma WEB SI NO 
Administración de perfiles de seguridad SI SI 
Carga de cartolas bancarias ( Estado / Corpbanca ) NO Sl 
Soporte. Independencia del proveedor NO SI 
Tabla 2 Tabla de homologación. 
CAPÍTULO III 
MATERIALES Y METODOS 
26 
3 Metodologías. 
3.1 Modelo para el Desarrollo del Producto. 
Debido a que se posee completo conocimiento de los requerimientos, los que a la vez no son de 
un carácter complejo y variable, se optó por un modelo de cascada con retroalimentación. 
Este modelo permite localizar e identificar los errores en las primeras etapas del proyecto a un 
bajo costo. También contribuye a minimizar los gastos de la planificación ya que permite 
efectuarla sin problemas. 
Las ventajas de aplicar esta metodología son: 
• Se encuentra todo correctamente organizado y no se mezclan las fases. 
• Perfecto para proyectos rígidos donde se especifican bien los requerimientos y se tiene un 
alto conocimiento de las herramientas utilizadas. 
• La planificación es sencilla. 
• La calidad del producto resultante es alta. 
• Sus fases son conocidas por los desarrolladores. 
Este modelo nos permite cerrar de manera formal cada etapa del proyecto, obteniendo la 
aprobación de los usuarios validadores, comprometiendo al cliente y al equipo de proyecto en el 
desarrollo e implementación de un producto de software que entregue valor a Confenats. 
El modelo cascada nos permite una planificación simple y organizada de nuestro proyecto. 
Figura 14 Modelo Cascada con retroalimentación. 
27 
3.2 Administración del proyecto. 
3.2.1 Metodología de Administración de Proyecto. 
Para la realización del proyecto se utilizan las prácticas y procesos recomendados por el PMBOK 
(Project Management Body of Knowledge) proporcionado por PMI (Project Managment 
Institute). 
Control 
Figura 15 Etapas PMBOK. 
3.2.2 Equipo de Proyecto. 
Buasines Solution 
Man ger 
De sarro la dor 
QA 
2 
Equipo de Proyecto 
Figura 16 Equipo de proyecto. 
28 
Sponsor 
Usuario Líder 
Soporte TI 
+ 
Equipo Funcional - Cliente 
Figura 17 Equipo de proyecto - Cliente. 
3.3 PIan de proyecto. 
3.3.1 PIan de Documentación. 
Se deben establecer los requisitos de esté, esto significa que se da a conocer lo que se va a 
documentar. Luego comienza el establecimiento de los documentos junto a la definición de las 
nomenclaturas que se deben generar dependiendo de la etapa en que se encuentre el proceso 
dentro del Modelo de Desarrollo de Software, para luego dar paso al establecimiento de 
extensiones de los documentos. 
Finalmente, planificar fechas de estimación para la documentación. 
3.3.2 Plan de Resolución de Problemas. 
La primera etapa de este plan, es identificar el problema para luego poder analizar las razones que 
la generaron, que pueden ser causadas por ambigüedad en la especificación de los 
requerimientos. El siguiente paso es lograr un acuerdo con el cliente para poder seguir avanzando 
con el proyecto y no quedar atascado en alguna etapa, lo que permitirá plantear posibles 
soluciones al problema generado. 
Cuando el acuerdo esté listo, se debe registrar la modificación como aceptada para luego 
desarrollar la solución planteada y hacer efectivo dicho proceso. 
Finalmente, el proceso concluye cuando se aprueba el cambio por ambas partes, lo que permite 
seguir avanzando con el proyecto. 
3.3.3 PIan de Pruebas. 
Este plan nos servirá para determinar el buen funcionamiento del proyecto de software que se 
está construyendo como solución. 
• Pruebas Unitarias. Se desarrollarán a nivel de módulos para verificar si cumple con los 
objetivos solicitados y corregir los errores detectados. 
29 
En estas pruebas unitarias se ejecutarán las pruebas de validación (requerimientos de! 
análisis) y de verificación (de acuerdo a la especificación de diseño). 
• Pruebas de Integración. Permitirá integrar los distintos componentes de la aplicación 
hasta contar con el producto que se entregará. Esta prueba se hace después de las pruebas 
unitarias. 
• Aceptación. Objetivo es comprobar si el producto está listo para ser implementado en 
operación. Se considerará como fase final y aceptación del funcionamiento correcto del 
producto. Se registra la entrega en un Documento con forma Ok. 
3.3.4 Plan de Comunicación. 
La metodología aplicada con el cliente será la siguiente: 
Actores. 
• Henry Luengo (Consultor Externo de Confenats). 
• Paola Romero (Contador Externo Confenats). 
• Hipólito Soto (BSM). 
Con respecto a los canales de comunicación dentro del proyecto, se establecieron reuniones una 
vez cada 2 semanas para presentar estados de avances y las posibles consultas que se generen. 
Estas reuniones deben ser de carácter presencial en dependencias del cliente. 
Ante cualquier situación puntual, también se coordinaron reuniones por teléfono para establecer 
juntas en una fecha no planificada. Se establece como canal alternativo los correos electrónicos. 
Se generará minutas de reunión donde se expresarán los acuerdos tratados y será firmado por los 
asistentes a la reunión. 
3.3.5 PIan de Aceptación del proyecto. 
Se contempla el término cuando se aplique la medición del hito en un estado de avance para cada 
fase del ciclo de vida del proyecto, cumpliendo lo con lo establecido. 
Se dará por terminada una actividad cuando existan entregables que cumplan con lo requerido y 
con las respectivas aprobaciones de ambas partes. 
Finalmente, actualizar los documentos y procesos realizados si fuese necesario, con el fin de 
responder de mejor manera ante un nuevo proyecto, reduciendo la cantidad de errores al registrar 
la experiencia vivida en el proyecto, el cual se dará por finalizado generando un informe de 
cierre. 
30 
 
Responsabilidades 
 
1. Bussines 
Solution 
Manager 
• Facilitar la labor del equipo de proyecto. 
Planificar, coordinar y supervisar las actividades de diseño, desarrollo e 
implementación. 
• Facilitar la información de evolución del proyecto al cliente. 
Garantizar la disponibilidad de os recursos comprometidos. 
2. Desarrollador • Diseñar soluciones de software de acuerdo a requerimientos entregados. 
• Modelar los requerimientos en diseño lógicos y físicos que den soporte a 
la programación del proyecto. 
Asegurar un ambiente de trabajo de base de datos seguro y confiable. 
3. QA • Ejecutar tareas de plan de testing. 
Generar escenarios de prueba. 
Generar documentación de verificación de pruebas. 
Rol Responsabilidades 
Comunicar la visión y alcance del proyecto. 
• Conseguir los recursos económicos. 
• Brindar cobertura política al proyecto. 
Aprobar cambios en la carta del proyecto. 
• Mantener la visibilidad del proyecto en la organización. 
• Proporcionar la información necesaria al equipo de proyecto. 1 
• Validar documentación formal acerca de requerimientosfuncionales del 
proyecto. 
• Aceptar el alcance del proyecto. 
• Aprobar los entregables del proyecto. 
Implementar y mantener servidores y servicios de red en la organización. 
• Asegurar la calidad y performance en el funcionamiento de 
infraestructura de redes y servicios de la organización. 
1. Sponsor 
2. Usuario líder 
3. Soporte TI 
3.3.6 Roles y Responsabilidades. 
Tabla 3 Roles de equipo de proyecto. 
Tabla 4 Roles de Cliente. 
31 
Definición de 
criterios de 
aceptación 
Irnplementación / 
Carta de 
-. aceptación 
Implementación Pruebas 
De Validación 
De Verificación 
Integración 
Diseño 
Plan dePruebasi 
Plan de 
capacitación 
Entregables 
Plan de instalación Análisis! 
F Especificaciones 
de requerimientos 
Capacitación 
Diseño! 
Descripción 
detallada de 
solución 
Pruebas / Plan de 
pruebas e informe 
de resultados 
Desarrollo 
Codificación de 
Software 
Creación de base 
de datos 53 
Termino de 
proyecto 
Diseño de 
estructura de 
datos 
1 
Diseño de 
arquitectura 
Identificación del 
Problema 
Definición de 
requerimientos 
T 
klentificación de 
riesgos 
5 
Cronograma del 
proyecto 
Planificación del 
análisis 
3.3.7 Estructura del Desglose del Trabajo (WBS). 
Sistema Contable 
Confenato 
Controll Evaluación 
Figura 18 Etapas modelo cascada. 
3.3.8 Cronograma del proyecto. 
 
O 00,10,1 de 
1 ____ - 50.1.50 ContaSe Condense. 
2 - Gc.t,on del pnsytcto 
8 04k - Oil 
4 ea,I±taçoeCe ilOylCo 
7 ReelIGe 12*1!1 
9 -Aoójee 
ce e de no ono. Os 
7 e,0c1cac.on CI leo1odlt.elCo. 
9 - 010.90 
10 SSOICIiCiO(61 al Costo 
II - noao 
12 - uódj.lo SeI40.d 
17 / coelolecnie deAotnlcosoe 
11.eteeedoydeLj.00,cs 
It ti.eneneaord.51411.o 
II Lloetenedord.n,ndob. 
17 tlolleeedjc de OTO 
Id ,v T.locleendoc CI isento 
lO . 0.91.211 oepeelke. 
28 - uóaabrloeiadoe 
21 - uanlenoondeetaso.Bá.00. 
27 .v Md11.medde.e000de,,eooco 
28 . ldontnnedor Cd 05002 CoCee.,.. 
24 ldalteeedOrdd.40o11090 
25 Tsddeel(elde. 
2 V 13011.1 IdO, de 
27 .7 ljadeeedoe dlcoefljeola CO,.. 
20 .7 ed,nl.,adoç atIpo ClIn CI 0011100 
 
Ooeoyle C.ee.zj elIde O0.br13 115,5113 rasr13 21 
.0lLiM P.IJ!JiJl 
01-aa dio.? lOe 07.03-13 III 01.06-13 
60.00 di.. jet 0b03-13 ccc 01.06-13 
8.5 dai konhl .00-030111-08-13 
50880.0, pe07-30-13 l0..l3 
ilaan*14-84.13.ti'3€-13 
19-5 diOs 01. 10-01-13 03-04-03 
3061 011143-13 pl 1143-13 3 
02 da. 1.118-22-03 'e.o 87-34-187 SM 
'Odia. son 08-04-13 ele 05-04-13 
lo da. ojo 0&84-18C12€.34.I3 
3d dli. lee, 1034.13 1w 0405.13 
doe. 11501 d0-04-d 3 el. 18-04-13 
- 08 Ida non 16-04-13 11.116.04.03 
011a. eoell-0413 eoe 17.04.13 13 OFSASI110LLA000 
OS alo, enoéll.04-13 enlo 17-04-lO 34 DOS9000LLA001 
0.5 dos 701 10-34-lO 9106.34-13 II DOi8000LlAfOn 
o 1.00 701 18-34-lO nt 18.04-10 le 4, 06 1*6605 L00030 
osd.00j019.84.03 19-84-lI 17 06!A0n0LLAD 
373.05 (119-30.13 d 9-04.18 II ¿ 
Odias 040122.04.13 00 02-08-13 
3 dios 
0.22da. 
Oso 3044_II ee'oe 74.04-18 
2(122-89-17 0172-34-18 II DL SA ROO LL8006 
Idi .02244-13 114123-34-13 22 ,n6sA68oLLAqol 
825 Ola. ew28.01-13 elal 23.00.0323 C065Ab009-80 025 Sos 10173-04-17 eac 33-04.1374 t tLSA050LL4O 
225 da. es,23.31-13 0eae33.34-13 25 tofs*800L1106 
075 Sos Icé 34.34_la ess 24.04-II 20 t
,
D51AR00L0.t 
877 Sl, oet21-04-13 nI 74.01.1727 p3 DEDAOROLL.AI 
Figura 19 Cronograma del proyecto. 
32 
3.4 Control de Proyecto. 
El Bussiness Solution Manager (BSM) será el responsable de monitoreo y control del proyecto. 
Para esto, deberá mantener diversos documentos y herramientas actualizadas con los datos de 
avances del proyecto: 
• Carta Gantt actualizada con el grado de avance de cada una de las actividades del 
proyecto. 
• Librería de solicitudes de cambio, junto con un historial de los cambios aceptados. 
• Especificación de requerimientos actualizada con los cambios aceptados. 
3.4.1 Gestión de Cambios. 
Los cambios se efectuarán a medida que avanza el proyecto y hasta la etapa de análisis, se debe 
seguir el siguiente procedimiento: 
• Solicitud de cambio. Se deberá crear un documento formal con la especificación de 
cambios requeridos. 
• Análisis del cambio. El BSM deberá analizar la solicitud de cambio a fin de determinar si 
es necesario el cambio o no. 
• Documentación del cambio. Una vez aceptado el cambio, este deberá ser documentado 
actualizando todos los documentos relacionados. 
Toda solicitud de cambio solicitada en forma posterior a la etapa de análisis, no será parte de este 
proyecto. Esto en acuerdo con Confenats, en el caso de ser necesario el cambio, se verá en una 
extensión del proyecto, con fin de no afectar el cronograma establecido. 
3.4.2 Gestión de Riesgos. 
Como todo proyecto, este presenta algunos riesgos que deben ser tomados en consideración y 
abordados durante el desarrollo del mismo. A continuación se indican los principales riesgos 
detectados y los controles para minimizar los impactos. 
• Definición de procesos para tarea de administración contable. (Rl) 
El cliente debe poseer definidos los procesos administrativos contables antes de la etapa de 
análisis, y deben ser entregados al equipo de proyecto. Para esto, dentro de las actividades de 
análisis del proyecto se asignarán 72 horas (3 días) para el apoyo y cierre de los mismos, y el 
responsable asignado será el BSM. 
• Tiempo de asignación de recursos del cliente para el proyecto. (R2) 
Si bien el cliente se compromete con la asignación de recursos para el proyecto, es posible que en 
ocasiones estos no puedan ejecutar las tareas que el proyecto requiere. Es por esto que se debe 
crear un catálogo de recursos que posean una planificación y con porcentaje de asignación 
definidos, que les permita ejecutar las actividades del proyecto sin afectar sus actividades diarias. 
• Resistencia al cambio. (R3) 
Con la definición de nuevos procesos y con la implementación del nuevo sistema, la información 
requerida será estructurada y con reglas de negocio definidas, por lo cual, en un comienzo, 
implica una mayor exigencia al usuario al momento de trabajar con el sistema. Para esto, se busca 
33 
la motivación del cliente, a través de capacitaciones que muestren los beneficios que conileva la 
implementación del sistema a construir. 
• Normalización y limpieza de información. (R4) 
Para el proceso de implementación de! sistema, es necesario la reestructuración y limpieza de 
información inicial a registrar. Se contempla que en la etapa de diseño, se identificarán cada 
dimensión de gestión y su información inicial. 
3.4.3 Matriz de Riesgos. 
La matriz que se muestra a continuación refleja los impactos y probabilidades de los riesgos 
anteriormente mencionados, sin considerar las medidas de control planificadas. 
1 5-MuyAlto ____________________ 
R4 Rl M 4-Alto R3 
P 3-Medio R2 
A 2-Bajo 
C 1 - Insignificante 
T 1 - Improbable 2 -Baja 3 — Media 4 - Alta 5 - Muy Alta 
O PROBABILIDADES 
Tabla 5 Tabla de riesgos. 
3.4.4 Matriz de Riesgos Reducidos. 
A continuación, se encuentra la matriz de riesgos considerando las medidas consideradas 
planificadas para controlarlos. Se puede ver que e! impacto se ve reducido gracias a los controles. 
1 5-MuyAlto 
M 4-Alto 
P 3-Medio Rl R4 
A 2-Bajo R2,R3 
C 1 - Insignificante 
T 1 - Improbable 2 -Baja 3 — Media 4 - Alta 5 - Muy Alta 
O PROBABILIDADES 
Tabla 6 Tabla de riesgos mitigados. 
34 
Servrdorde plicaciones 
Servidorde Base de Datos 
USuano 1 Usuario N 
Figura 21 Diagrama de despliegue. 
3.5 Ejecución del proyecto. 
3.5.1 Construcción de Componentes y Módulos. 
Para la construcción de diseño y programación de la solución, se utilizará el lenguaje de 
programación visual Basic 6.0 y Microsoft SQL Server 2008. Esto dado que el cliente posee 
licencias de desarrollo para las aplicaciones indicadas. 
Seguridad 
 
 
Administración de usuariosyperfilesde seguridad 
 
Diseñador 
 
 
• Definir lógicas conblesyregIasde negocio. 
• Diseo de formularios contables. (Simplificaciónde un asientocontablel. 
• Administraciónde ejerciciosy perlados. 
• Mante nción de datos maestras. 
 
Contabilidad 
 
• \Iidación de información atravós de datos diccionarios. 
• Ingreso de formularios contables. 
• Ingreso de vouchers. 
• Trazabilidad de información ycaritrolde aprobación detransacciones. 
• Emisión de listadoscontablesy balance. 
 
 
Conciliación 
 
 
Administración y ejecución de proceso de conciliación bancaria. 
 
 
 
Figura 20 Módulos Sistema Confenats. 
3.5.2 Diagrama de Despliegue. 
Permite modelar el hardware que requiere la aplicación a implementar y como se relacionan con 
los componentes de software del sistema final. 
35 
3.5.3 Estrategia de Poblamiento de Datos. 
La información deberá ser ingresada mediante un DTS a la base de datos, por medio de archivos 
Excel con formato definido de acuerdo a la estructura de la tabla a poblar. 
La información financiera contable debe ser registrada en forma manual por el cliente. Esta 
información debe ser ingresada de la siguiente manera. 
• Información del ejercicio anterior. Se debe digitar un solo Boucher contable, con el 
saldo de las cuentas de activos y pasivos. 
• Información del ejercicio actual. Se digitarán todos los formularios asociados a cada 
transacción del ejercicio actual. 
3.5.4 Estrategia de Poblamiento de Capacitación. 
El objetivo de esta estrategia es enseñarle al usuario final la forma de proceder y explotar las 
aplicaciones que conforman la solución de software creada. 
• Entrega de manuales. 
• Definir calendario de capacitación. 
• Establecer criterio de aceptación. 
3.5.5 Estrategia de Pruebas. 
Permite determinar el buen funcionamiento de la aplicación creada y lograr los objetivos que 
fueron definidos como específicos. Los datos que se ocupen como prueba deben ser lo más 
fidedignos posibles, se deben verificar los posibles punto de errores que pueda tener la 
aplicación. 
3.5.6 Informe de Pruebas. 
Toda prueba que se efectúe, deberá tener un documento denominado "Informe de Prueba" en cual 
llevar la firma del responsable de la ejecución y del BSM. El responsable es el encargado de 
ejecutar la prueba y verificar que se realice en forma correcta. 
3.6 ffntregables del Proyecto. 
3.6.1 Documentación de análisis y diseño. 
Esta documentación incluye la Definición de requerimientos, Modelo Conceptual de negocios, 
Procesos de negocios, Casos de uso, modelo de datos y la propuesta de plataforma sobre la cual 
debe implementarse el software. 
3.6.2 Prototipo. 
Debido a que el proyecto comprende únicamente las fases de análisis y diseño de la solución 
requerida por el cliente, el software no se entrega en funcionamiento, sino que se entrega a demás 
de la documentación de diseño un prototipo de la capa de presentación, o interfaz de usuario, que 
deberá ser utilizado como base para la implementación del software. 
36 
3.7 Herramientas Utilizadas. 
Para la realización del proyecto se utilizaron diversas herramientas de software para llevar a cabo 
las herramientas de su desarrollo: 
• Documentación: Microsoft Word 2010. 
• Proceso de negocio: Bizagi Studio 9. 
• Administración de proyecto: Microsoft Project 2010. 
• Prototipo: Visual Studio 6.0 y Microsoft SQL Server 2008. 
• WBS: WBS Chart Pro. 
• Casos de Uso: StarUml 5.0.2.1570 
• Diagramas de secuencia: StarUml 5.0.2.1570 
NOTA: Prototipo, ya que el proyecto considera la entrega de fuentes, y cuya limitante, es la 
herramienta Visual Studio 6.0. Se indicó al cliente la migración a Visual Studio .Net. 
37 
CAPÍTULO IV 
RESULTADOS Y DISCUSIÓN 
38 
4 Introducción al capítulo. 
En este capítulo se observan los resultados del proyecto en las distintas etapas que han sido parte 
de su modelo de desarrollo, mostrando cómo se llevó a cabo cada ciclo del proyecto. Indicando 
cuando y donde hubo incidentes que obligaron a ocupar las herramientas definidas para elaborar 
la gestión de proyecto, mostrando los resultados obtenidos mediantes gráficos y diagramas. 
4.1 Equipo de trabajo. 
El equipo de trabajo definido en el capítulo anterior, no presentó alteración. 
4.2 Roles y Responsabilidades. 
Roles y Responsabilidades del equipo de proyecto, no presentó alteraciones. 
4.3 Resultado del Plan de comunicación. 
Se realizaron las reuniones de avance del proyecto todos los días martes, cada 2 semanas, con una 
duración máxima de 1.5 Horas. 
• La planificación de las reuniones se definió a partir de las 19:00 Horas. Asistentes BSM y 
equipo de proyecto por parte del cliente. 
• Se evaluó que fase de cada ciclo se ha cumplido, dependiendo de las tareas asignadas a 
los roles involucrados en el desarrollo del proyecto, de esta manera se busca poder 
efectuar las correcciones oportunas y recuperar los tiempos de atraso. 
• Se realizaron BrainStorming para plantear una solución a los atrasos generados. 
• Se deja escrito en un acta todos los acuerdos y compromisos adquiridos. Acta incluye 
temas tratados y compromisos adquiridos, la cual se envía a todos los participantes 
planificados y se respalda en carpeta del proyecto. 
4.4 Resultado de Plan de Trabajo. 
Al comienzo de! proyecto se realizó una estimación del esfuerzo, obteniendo una definición de 
actividades distribuidas para cada etapa del proyecto. 
La planificación inicial se tuvo que ajustar, esto por concepto de aumento de carga académica por 
parte del equipo de proyecto, y el no cumplimento de entrega de requerimientos por parte de los 
usuarios expertos definidos. 
A continuación se despliegan las tablas de acuerdo a presupuesto y real. 
Etapa Fecha Inicio Fecha Termino Nro. Días Horas 
Gestión del proyecto 07-03-2013 14-06-2013 68.88 35.55 
Análisis 11-03-2013 03-04-2013 16.5 120 
Diseño 08-04-2013 26-04-2013 15 120 
Desarrollo 16-04-2013 14-05-2013 20 196 
Test 15-05-2013 22-05-2013 4.7 28 
Implementación 05-06-2013 06-06-2013 2 16 
Totales 127.08 515.55 
Tabla 7 Tabla de Estimación original. 
39 
/ 
Horas PPTO 
Horas Reales 
100 
50 
Tabla 8 Tabla de Horas Reales. 
Grafico que muestra las horas reales de ejecución, versus las horas presupuestadas: 
300 
250 
200 
150 
o 
& K 
1 
1' \.
ÇÇe 
Etapa Fecha Inicio Fecha Termino Nro. Días Horas 
Gestión del proyecto 07-03-2013 14-06-2013 68.88 35.55 
Análisis 11-03-2013 03-04-2013 16.5 120 
Diseño 08-04-2013 26-04-2013 15 120 
Desarrollo 16-04-2013 14-05-2013 24.5 244 
Test 15-05-2013 22-05-2013 6.45 64.4 
Implementación 05-06-2013 06-06-2013 2 16 
Totales 133.33 599.95 
Figura 22 Gráfico de horas reales versus presupuestadas. 
4.5 Resultado de Plan de Gestión de Riesgos. 
Inicialmente se contemplaron los siguientes riesgos: 
• Definición de procesos para tarea de administración contable. (Rl) 
• Tiempo de asignación de recursos del cliente para el proyecto. (R2) 
• Resistencia al cambio. (R3) 
• Normalización y limpieza de información. (R4) 
40 
Los riesgos identificados derivaron en la siguiente tabla: 
1 5-MuyAlto 
M 4—Alto R3 R4 Rl 
P 3—Medio R2 
A 2—Bajo 
C 1 — Insignificante 
T 1 - Improbable 2—Baja 3 — Media 4 - Alta 5 - Muy Alta 
O PROBABILIDADES 
De acuerdo a las actividades definidas de mitigación permitió estimar una reducción del riesgo, el 
cual se representa en la siguiente tabla: 
1 5-MuyAlto __________________ 
M 4-Alto 
P 3-Medio Rl R4 
A 2-Bajo R2,R3 
C 1 - Insignificante 
T 1 — Improbable 2 -Baja 3 — Media 4 - Alta 5 - Muy Alta 
O PROBABILIDADES 
Durante la ejecución del proyecto no aparecieron nuevos riesgos. 
Con respecto al riesgo R2 -Tiempo de asignación de recursos del cliente para el proyecto, a 
pesar de las actividades de mitigación, y de acuerdo a la ejecución del proyecto, este riesgo no 
pudo ser mitigado. Por ende la matriz final de riesgo es representada de acuerdo a la siguiente 
tabla: 
1 5-MuyAlto ___________________ 
M 4-Alto 
P 3 - Medio Rl R2,R4 
A 2-Bajo R3 
C 1 - Insignificante 
T 1 — Improbable 2 -Baja 3 — Media 4 - Alta 5 - Muy Alta 
O PROBABILIDADES 
41 
4.6 Resultado de Gestión de la configuración. 
El objetivo de esteplan, fue definir y mantener la integridad del código y documentos que se 
generaron a lo largo del ciclo de vida del proyecto. 
Los ítems de configuración definidos fueron: 
Ítems Sub- ítems Descripción 
Planes 
1-Plan de 
proyecto. 
2-Plan de riesgos. 
3-Plan de gestión 
de la 
configuración. 
4-Plan de gestión 
del cambio. 
5-Plan de 
comunicación. 
6-Plan de pruebas. 
7-Plan de cierre 
Formato del documento u*.docu, debe nombrarse como 
"Plan de cltem respectivo> 
Informes 
1- Informe de 
pruebas. 
2-Manual de 
usuarios 
3-Actas de 
reuniones Archivos con formato Microsoft Word 
Documentos de 
la metodología 
1- Documento de 
Casos de Uso. 
2-Documento de 
arquitectura. 
3-Código del 
Software. 
Para los ítems 1 y 2, se debe considerar archivo con 
formato Microsoft Word. 
Para fuentes de prototipo, se debe considerar Visual Studio 
6.0 
Para Objetos de bases de datos, Microsoft SQL Server 2008. 
Diagramas 
1-Casos de Usos. 
2-Carta Gantt. 
3-W.B.S 
Documentos según software que permita su creación y 
mantención 
42 
4.7 Resultado de Plan de Infraestructura. 
El hardware definido para poder realizar el proyecto se basó en los siguientes equipos y sus 
características: 
Modelo Equipo ACER Aspire 4739 
Procesador Intel Dual Core 13 2.5 Hz 
RAM 6GBDDR3 
Capacidad de Disco Duro 320 Gb 
Sistema Operativo Windows 7 Ultimate 
Modelo Equipo Equipo multiprocesadorACPl 
Procesador DualCore Intel Pentium E5400, 2700 MHz 
RAM 2GBDDR3 
Capacidad de Disco Duro 320 Gb 
Sistema Operativo Microsoft Windows XP Professional SP3 o Superior 
4.8 Resultado PIan Cierre del Proyecto. 
Para la verificación del cierre de cada etapa del ciclo de vida del proyecto, se presenta la 
siguiente tabla que muestra la etapa y su evidencia de cierre. 
Etapa del Proyecto Evidencia 
¿ Cierre 
Realizado? 
Análisis Especificación de requerimientos SI 
Diseño Arquitectura de Software SI 
Desarrollo Software y base de datos SI 
Test Acta de aceptación del proyecto SI 
Implementación Informe de cierre del proyecto SI 
4.9 Requerimientos Funcionales. 
De acuerdo al relevamiento y análisis de requerimientos se obtienen los siguientes requerimientos 
funcionales por módulo a construir: 
4.9.1 Módulo Seguridad. 
4.9.1.1 Mantenedores. 
Código RQO 1 
Módulo Seguridad. 
Nombre Definición de usuarios. 
Descripción El software deberá solicitar nombre de usuario, contraseña, cargo del 
usuario, un mail de referencia, y rango de vigencia. 
43 
Este software permitirá realizar modificaciones en el perfil del usuario, 
y realizar eliminación de usuarios para aquellos administradores que 
cuenten con los permisos necesarios. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• La eliminación del usuario es posible, pero es aplicable solo para 
aquellos usuarios que no posean acción en todos los sistemas. 
(Seguridad, Básico, Contabilidad y Conciliación). 
• En el caso que el usuario exista, sistema debe desplegar la 
información asociada al usuario. 
Entrada • Usuario. Llave principal. 
• Nombre de usuario. 
• Password. No deben ser desplegados los caracteres al momento de 
su digitación. 
• Cargo. 
• Mail. 
• Rango de vigencia. 
Salida Actualización del perfil de usuario, ingreso o eliminación de un 
usuario. 
CasodeUso CUI 
Tabla 7 Formulario Mantención de usuarios. 
Código RQO2 
Módulo Seguridad. 
Nombre Definición de Empresa. 
Descripción Este proceso de mantención solo permite la definición de la empresa, y 
sus características. La creación de base de datos es de responsabilidad 
del DBA. (Se debe entregar documento con la creación de empresa). 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• La eliminación de empresas solo aplica a la configuración del 
sistema. No considera la eliminación de bases de datos y su 
respaldo. 
• En el caso que la empresa exista, sistema debe desplegar la 
información asociada a la empresa. 
Entrada • Empresa. 
• Rut Empresa. 
• Rut representante legal. 
• Razón social. 
• Razón social representante legal. 
• Dirección. 
• Teléfonos. 
• Mail. 
• Servidor de base de datos. 
• Bases de datos. 
• Login de bases de datos. 
• Password de base de datos. 
• Moneda base de la empresa. 
44 
• Rango de vigencia. 
Salida Actualización, ingreso o eliminación de una empresa. 
Caso de Uso CUI 
Tabla 9 Formulario Mantención de empresas. 
Código RQO3 
Módulo Seguridad. 
Nombre Definición de módulos. 
Descripción Este proceso de mantención solo permite asociar un código a cada 
módulo del sistema a construir. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar módulos que no posean transacciones de 
seguridad asociadas. 
En el caso que el módulo exista, sistema debe desplegar la 
información asociada al código de módulo imputado. 
Entrada • Código de módulo. 
• Descripción módulo. 
• Rango de vigencia. 
Salida Actualización, ingreso o eliminación de un módulo. 
Caso de Uso CU2 
Tabla 9 Formulario Mantención de módulos. 
Código RQO4 
Módulo Seguridad. 
Nombre Definición de transacciones de seguridad. 
Descripción El software permitirá administrar las transacciones realizadas en cada 
módulo. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar transacciones de seguridad que no posean 
perfiles de seguridad asignados. 
• En el caso que transacción de seguridad exista, sistema debe 
desplegar la información asociada al código de transacción de 
seguridad imputado. 
Entrada • Código de módulo. 
• Código de transacción. 
• Descripción de transacción. 
• Rango de vigencia. 
Salida Actualización, ingreso o eliminación de una transacción. 
Caso de Uso CU2 
Tabla 10 Formulario Mantención de transacciones de seguridad. 
45 
Código RQO5 
Módulo Seguridad. 
Nombre Definición de Perfil de seguridad. 
Descripción El software permitirá administrar los perfiles ingresados en el módulo. 
Reglas de negocio 
____ 
• Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar perfiles de seguridad que no posean un 
usuario asignado. 
• Se debe seleccionar código de módulo para que sistema despliegue 
las transacciones de seguridad correspondiente. Las transacciones 
de seguridad son definidas por módulo al momento de implementar 
la solución. 
Entrada 
______ 
• Código de perfil. 
• Descripción de perfil. 
• Rango de vigencia. 
• Código de módulo. 
• Código de transacciones de seguridad. 
Salida Actualización, ingreso o eliminación de un perfil. 
Casos de Uso CU2 
Tabla 11 Formulario Mantención de perfil de seguridad. 
4.9.1.2 Operaciones. 
Código ! RQO6 
Módulo Seguridad. 
Nombre Autenticación. 
Descripción Al ingresar a cada módulo a construir, sistema debe solicitar la 
autenticación para el ingreso del sistema. 
Reglas de negocio • Solo se debe permitir ingreso de usuarios válidos. 
• Se debe solicitar siempre el ingreso de password asignada al 
usuario. 
• Permitir realizar cambio de clave del usuario. 
o Para esta acción, se debe registrar una autenticación válida del 
sistema. 
Entrada 
___________ 
• Usuario. 
• Password. 
• Empresa. (Atributo no debe ser solicitado en el ingreso al módulo 
de seguridad). 
Los atributos de Usuario y Password son de carácter obligatorio. 
Salida Visualización de los módulos contenidos en el programa. 
Caso de Uso CUI 
Tabla 12 Formulario Autenticación de usuario. 
46 
Código RQO7 
Módulo Seguridad 
Nombre Cambio de password. 
Descripción El software deberá solicitar nombre de usuario y contraseña antiguos 
para permitir el cambio de contraseña. 
Entrada Nombre de usuario y contraseña 
Salida Nueva contraseña. 
Caso de Uso CU1 
Tabla 13 Formulario cambio de Password. 
Código RQO8 
Módulo Seguridad. 
Nombre Asignación de perfil de seguridad a usuarios. 
Descripción El software permitirá administrar los perfiles ingresados en el módulo. 
Reglas de negocio 
• 
• Todos los atributos son de carácter obligatorio. 
• Al momento de seleccionar losatributos de empresa y usuario, 
sistema debe desplegar perfiles disponibles y perfiles asociados. 
• Usuario se debe seleccionar el perfil que desee asignar o quitar. 
Entrada • Código de empresa. 
• Codigo de usuario. 
• Perfiles disponibles. 
• Perfiles asignados. 
Salida Perfil asignado al usuario. 
Caso de Uso CU2 
Tabla 14 Formulario asignación de perfiles de usuario. 
47 
4.9.2 Módulo Diseñador. 
4.9.2.1 Mantenedores Generales. 
Código RQO9 
Módulo Diseñador. 
Nombre Definición de área de negocio. 
Descripción El software permitirá agrupar los datos diccionarios de acuerdo al 
negocio que se desea implementar. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar área de negocio que no posean un dato 
diccionario asignado. 
• Si código de área de negocio existe, sistema debe desplegar 
información registrada. 
Entrada • Código de área de negocio. 
• Descripción. 
• Rango de vigencia. 
Salida Area de negocio creada con sus respectivos datos diccionarios. 
Caso de Uso CU3 
Tabla 15 Formulario Mantención de área de negocio. 
Código RQIO 
Módulo Diseñador. 
Nombre Definición de sucursales. 
Descripción Se definirán las sucursales correspondientes al área de negocio. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar sucursal que no posean imputación contable 
o lógica asociada. 
• Si código de sucursal existe, sistema debe desplegar información 
registrada. 
Entrada • Código de sucursal. 
• Descripción de sucursal. 
• Rango de vigencia. 
Salida Mostrará la información de la sucursal registrada. 
Casos de Uso CU3 
Tabla 16 Formulario Mantención de sucursales. 
Código RQ1 1 
Módulo Diseñador. 
Nombre Definición de monedas. 
Descripción Se definirán la moneda con la imputación contable y lógica asociada 
correspondiente. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar moneda que no posean imputación contable 
o lógica asociada. 
48 
• Si código de moneda existe, sistema debe desplegar información 
registrada. - 
Entrada • Código de moneda. 
• Descripción de moneda. 
• Rango de vigencia. 
• Número de decimales. 
Salida Mostrará la información de moneda registrada. 
Caso de Uso CU3 
Tabla 17 Formulario Mantención de monedas. 
Código RQ12 
Módulo Diseñador. 
Nombre Definición de centro de costos. 
Descripción Se definirán el centro de costos para su respectiva administración. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Solo se puede eliminar centro de costo que no posean imputación 
contable o lógica asociada. 
• Si código de centro de costo existe, sistema debe desplegar 
información registrada. 
Entrada • Código de centro de costo. 
• Descripción de centro de costo. 
• Rango de vigencia. 
Salida Mostrará la información del centro de costos asociado al código 
ingresado. 
Caso de Uso CU3 
Tabla 18 Formulario Mantención de centros de costos. 
Código RQ13 
Módulo Diseñador. 
Nombre Definición de subsistemas. - - 
Descripción Esta dimensión le permite al usuario la segmentación de los cierres de 
periodos. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• No se puede eliminar código de subsistema que esté asignado a un 
formulario contable. 
• Si el código de subsistema existe, sistema debe desplegar la 
información registrada. 
Entrada • Código de subsistema. 
• Descripción. 
• Rango vigencia. 
Salida Mostrará la información del subsistema correspondiente. 
Caso de Uso CU3 
Tabla 19 Formulario Mantención de su bsistemas. 
49 
Código RQ14 
Módulo Diseñador. 
Nombre Mantención de personas. 
Descripción Realizara administración de personas. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• La asignación de código debe ser propuesta por el sistema. 
• No se puede realizar la eliminación de personas. 
• Se debe poder clasificar el tipo de relación comercial que posee la 
persona con Confenats. 
Entrada • Código de persona. 
• Razón social. 
• Giro comercial. 
• Rut. 
• Rango de vigencia. 
• Clasificación de persona. 
o Bancos. 
o Cliente. 
o Honorario. 
o Instituciones. 
o Proveedor. 
o Trabajador. 
Salida Clasificara el tipo de relación comercial de la persona. 
Caso de Uso CU3 
Tabla 20 Formulario Administración personas. 
Código RQI5 
Módulo Diseñador. 
Nombre Mantención de tablas generales (Datos diccionarios codificados). 
Descripción Esta opción debe permitir la mantención de los datos diccionarios en 
las tablas generales. 
Reglas de negocio • Debe desplegar los datos diccionarios que posean codificación, y 
que no sean parte de la estructura fija de implementación. 
• Al seleccionar dato diccionario, sistema debe desplegar la 
estructura e información registrada. 
• Debe indicar en color amarillo los atributos que son llave para el 
proceso de mantención. 
• Cada atributo de tabla a mantener debe existir como dato 
diccionario, ya que de esta manera se puede configurar grilla de 
mantención. 
Entrada • Dato Diccionario. 
• Detalle de estructura de tabla. 
Salida Desplegara las tablas de acuerdo a estructura fisica para proceso de 
mantención. 
Caso de Uso CU3 
Tabla 21 Formulario Administración de datos básicos. 
50 
4.9.2.2 Configuraciones. 
Código RQI6 
Módulo Diseñador. 
Nombre Definición de datos diccionarios. 
Descripción Un dato diccionario es una dimensión que debe permitir estructurar la 
información de las transacciones a imputar. 
Se realizaran los ingresos de tablas, procedimientos de búsqueda, 
búsqueda relacionada y procedimientos de ayuda. 
Reglas de negocio • Solo se puede eliminar un dato diccionario que no posea una 
estructura contable asignada. 
• Si el dato diccionario existe, sistema debe desplegar la información 
registrada. 
• Sistema debe permitir crear los objetos de bases de datos. (tablas, 
procedimientos almacenados para proceso de búsqueda, búsqueda 
relacionada y ayuda). 
• Se debe considerar la siguiente nomenclatura (prefijo) para la 
codificación de los datos diccionarios: 
o Dc: Dato codificado, es decir, posee una tabla que respalda su 
validación. 
o Df: Dato fecha. 
o Dn: Dato secuencia. 
o Dq: Dato monto o cantidad. 
o Dg: Dato glosa. 
o Dm: Dato marca o flag. 
Entrada • Código de dato diccionario. 
• Tipo de dato de base de datos SQL. 
• Largo. 
• Título de dato diccionario. 
• Tabla de base de datos SQL. 
• Área de negocio. 
• Lista de datos diccionarios. 
• Datos de datos relacionados. 
• Procedimiento de búsqueda. 
• Procedimiento de búsqueda relacionada. (cuando dato diccionario 
depende de otro dato diccionario). 
• Procedimiento de ayuda. 
Salida Muestra los datos diccionarios creados con sus respectivos campos. 
Caso de Uso CU3 
Tabla 22 Formulario Mantención de datos diccionarios. 
UN!V!RiTJAD BELU) 
Código 
______ 
: RQ17 
Módulo _. Configuración. 
Nombre . .. Definición de configuraciones. 
Descripción Por ejemplo, nombre de ODBC para reportes. Considerar que esta 
funcionalidad no está disponible para usuarios finales. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
El código de configuración debe estar asociado a un módulo. 
• No se encuentra habilitado el concepto de eliminación. 
- . Si código de configuración existe, sistema debe desplegar 
información registrada. 
Entrada • Código de módulo. 
• Código de configuración. 
• Valor de configuración. 
Salida Mostrará la información del módulo de configuración 
Caso de Uso - £ . CU3 
Tabla 23 Formulario Mantención de configuraciones. 
Código RQ18 
Módulo Diseñador. 
Nombre Tipo de plan de cuentas. 
Descripción Realizara la administración de la cuenta, definiendo cada uno de sus 
parámetros, para la mantención de la misma. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• No se puede eliminar plan de cuenta que esté asignado al plan de 
cuenta imputable de la empresa. 
• Si código de plan de cuenta existe, sistema debe desplegar 
información registrada.• El plan de cuenta de imputacion de instalacion debe ser entregado 
por Confenats para concepto de configuración. 
Entrada - 
- .- 
- . . 
Código de plan de cuenta. 
• Descripción de plan de cuenta. 
• Rango de vigencia. 
• Marca de plan de instalación. 
o Sí. 
o No. (plan de cuenta alternativo, esto si la empresa lo requiere). 
• Niveles de plan de cuenta. 
o Definición de largo. 
Salida Mostrará la información del código de plan correspondiente. 
Caso de Uso CU3 
Tabla 24 Formulario Mantención de tipo plan de cuenta. 
52 
Código RQ19 
Módulo Diseñador. 
Nombre Definición Plan de cuentas. 
Descripción Realizara la administración de la cuenta, definiendo cada uno de sus 
parámetros. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• No se puede eliminar cuenta de mayor que esté asignado al plan de 
cuenta imputable de la empresa. 
• Si la cuenta de mayor existe, sistema debe desplegar la información 
registrada. 
• Sistema debe desplegar plan de cuenta completo, de acuerdo a los 
niveles definidos en el tipo de plan de cuenta. 
Entrada • Código de plan de cuenta. 
• Código de cuenta de mayor. 
• Descripción de cuenta de mayor. 
• Tipo de cuenta. 
o Activo. 
o Pasivo. 
o Ingreso. 
o Egreso. 
Salida Mostrará la información del plan de cuenta completo correspondiente. 
Caso de Uso CU3 
Tabla 25 Formulario Mantención de plan de cuenta. 
Código RQ2O 
Módulo Diseñador. 
Nombre Definición de estructuras contables. 
Requisitos Tener los permisos correspondientes como Administrador. 
Descripción Este concepto permite al sistema poder registrar el detalle de la 
información asociada a la cuenta de mayor. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• No se puede eliminar código de estructuras. 
• Si el código de estructura contable existe, sistema debe desplegar la 
información registrada. 
• Sistema para estructuras nuevas, debe desplegar todos los atributos 
de carácter Fijo. 
Entrada • Código de estructura contable. 
• Descripción de estructura contable. 
• Rango de vigencia. 
• Atributos de estructura (dato diccionario). 
Salida Mostrará la información de las estructuras nuevas, desplegando los 
atributos de carácter fijo. 
Caso de Uso CU3 
Tabla 26 Formulario Mantención de estructura contable. 
53 
Código RQ2I 
Módulo Diseñador. 
Nombre Definición Plan cuenta empresa. 
Descripción Este concepto permite al sistema poder registrar el detalle de la 
información asociada a la cuenta empresa. 
Reglas de negocio ____ 
- 
• Todos los atributos son de carácter obligatorio. 
No se puede eliminar cuenta de mayor de plan de cuenta de la 
empresa. Solo se puede dejar no vigente. 
• Descripción de cuenta debe ser obtenida de plan de cuenta de 
implementación. 
• Plan de cuenta de empresa debe estar asociados a las dimensiones: 
o Sucursal. 
o Moneda. 
o Centro de costo. 
Entrada 
_______ 
1 
1 
• Código de cuenta mayor. 
• Descripción de cuenta. (obtenido de plan cuenta de 
implementación). 
• Marca de presupuestable. 
• Código de estmctara. 
o Código de sucursal. 
o Código de moneda. 
o Código de centro de costo. 
o Rango de vigencia. 
Salida 
____ 
Se obtendrá en plan cuenta empresa asociado a las dimensiones e 
implementación correspondiente. 
Caso de Uso CU3 
Tabla 27 Formulario Definición de lógicas contables. 
Códp RQ22 
Módulo Diseñador. 
Nombre Definición de lógicas contables. 
Descripción Este concepto permite representar un evento contable en base a 
cuentas de mayor. 
Reglas de negocio 
• ..- 
• Todos los atributos son de carácter obligatorio. 
• No se puede eliminar código de lógicas contables. 
• Se debe validar que lógica contable cumpla el principio de 
contrapaida. (Debe existir una línea al debe y haber como 
mínimo). 
Entrada _______ 
_____________________ 
____ 
• Código de lógica contable. 
• Descripción de lógica contable. 
• Rango de vigencia. 
• Código de subsistema. 
• Detalle de lógica contable. 
o Línea de mayor. 
54 
o Código de cuenta mayor. 
o Tipo Sucursal. 
• Estático. 
• Digitado. 
o Sucursal. 
o Tipo Moneda. 
• Estático. 
• Digitado. 
o Moneda. 
o Tipo de Centro de costo. 
• Estático. 
• Digitado. 
o Marca Debe/Haber. 
Salida Se obtendrá la lógica contable validad para cumplir la contrapartida. 
Caso de Uso CU3 
Tabla 28 Formulario Definición de lógicas contables. 
Código RQ23 
Módulo Diseñador 
Nombre Definición de formularios contables. 
Descripción Este concepto permite simplificar el ingreso de Boucher contables, 
solicitando los datos necesarios, en base a la configuración, 
optimizando tiempo, validación en línea y estructuración de 
información. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• No se puede eliminar formulario contable. Solo se puede dejar no 
vigente. 
• Todo atributo de encabezado debe poseer al menos un valor, 
cuando el Tipo de ingreso posea el valor estático, fórmula o 
ambiental. 
• Todo atributo de encabezado debe ser visible, cuando el Tipo de 
ingreso posea el valor digitado. 
• Todo atributo de detalle debe poseer valor. En el caso que lógica 
contable el atributo de mayor sea estático, sistema debe desplegar 
valor de definición, en caso contrario, debe ser asignado un dato 
diccionario desde el encabezado. 
• Sistema debe desplegar atributos de mayor y de estructuras 
contables asociados a las cuentas de mayor para su configuración. 
• En el caso de asignar plantilla de formulario fisico, cada atributo 
solicitado por plantilla debe poseer un atributo desde el 
encabezado del formulario. 
• En el caso de existir código de formulario imputado, sistema debe 
desplegar la información registrada. 
• La información a desplegar para la configuración del encabezado 
de formulario, depende del valor que posea el atributo Tipo de 
ingreso. 
55 
 
o Digitado, no se despliega ninguna ventana de selección. 
o Estático, el usuario define el valor a asignar. Sistema no debe 
validar atributo. 
o Ambiental, se debe desplegar formulario de selección de 
atributos, el cual solo debe presentar los valores predefinidos. 
o Fórmula, se debe desplegar formulario de generación de 
fórmulas. Este formulario debe desplegar los datos diccionarios 
de su misma naturaleza, es decir, por ejemplo, si el atributo de 
es un dato codificado, se debe desplegar todos los atributos 
"dc" que el formulario posea configurado. Para el caso de los 
datos de monto, se puede definir fórmulas matemáticas. 
 
 
Entrada 4 • Código de formulario. 
• Descripción de formulario. 
• Estado de registro de formulario. 
• Estado de Boucher. 
• Código de lógica contable. 
• Rango de vigencia. 
• Atributos de encabezado. 
o Dato diccionario formulario. 
o Tipo de ingreso. 
• Estático. 
• Ambiental. 
• Código empresa. 
• Moneda base de empresa. 
• Periodo. 
• Sucursal. 
• Código de usuario de conexión. 
• Fecha de servidor. 
• Decimales moneda base. 
• Fórmula. 
• Digitado. 
o Valor. 
o Visible (marca). 
• Detalle. 
o Cuenta de mayor. 
o Debe/Haber (marca). 
o Atributo de estructura de mayor y contable 
asociada a cuenta de mayor. 
o Atributo de formulario. 
• Formulario Físico. 
o Plantilla. 
• Sin Plantilla. 
• Ingresos. 
• Egresos. 
o Atributos de plantilla. 
• Atributo de plantilla. 
56 
 
 
 
 
• Atributo de formulario. 
Salida Se obtendrá el formulario contables con un encabezado, detalle, 
plantilla, asignación de datos diccionario y formulas. 
Caso de Uso CU3 
Tabla 29 Formulario Definición de formularios contables — encabezado. 
4.9.2.3 Operaciones. 
Código RQ24 
Módulo Diseñador. 
Nombre Administración de seguridad a formularios contables. 
Descripción Permitirá tener un control de la seguridad en los formularios contables 
y generar diferentes acciones de administración en el formulario 
contable. 
Reglas de negocio • Todos los atributos son de carácter obligatorio. 
• Se deben desplegar todos los formularios contables disponibles. 
• Se deben desplegar todos los formularios asociados.