Contabilidad Tesis
Contabilidad Tesis
I
Resumen
En los últimos años con el avance de las nuevas tecnologías los procesos de la Contabilidad general se
han visto influenciados por el constante desarrollo. A pesar de que existe una gran variedad de
soluciones contables en aplicaciones de software, tanto nacionales como extranjeras, que facilitan
dichos procesos no se ha logrado obtener un estándar funcional para todos estos sistemas, que
responda a las especificidades de la contabilidad que se realiza en las entidades cubanas.
Este trabajo tiene como objetivo central llevar a cabo la modelación de los procesos de negocio
inherentes al subsistema Contabilidad general, identificar los requisitos funcionales, y crear una
propuesta de diseño de forma tal que constituya el punto de partida para futuros Sistemas de gestión
contable en Cuba. Para lograr este propósito se empleó el modelo de desarrollo de software definido por
los especialistas del proyecto en general y las herramientas igualmente establecidas para el desarrollo
de acuerdo a los diferentes roles.
Para elaborar esta propuesta, fue necesario dividir todo el contenido de trabajo en diversos subsistemas,
y éstos a su vez en componentes, los cuales guardan una estrecha relación entre sí,
independientemente de que se trabajen por separado. Aunque, para captar los detalles esenciales del
negocio con los clientes, se mantuvo íntegra la información, separándola por temas sólo al comenzar el
diseño de la solución y la posterior implementación.
Palabras Claves: Contabilidad general, Procesos de negocio, Requisitos funcionales, Diseño, Sistemas
de gestión contable, modelo de desarrollo.
II
Tabla de Contenido
INTRODUCCIÓN ...................................................................................................................................... 1
1. Introducción............................................................................................................................................... 5
1.1.3 Sistemas contables financieros presentes en entidades cubanas. Tratamiento del subsistema
Contabilidad general. ....................................................................................................................................... 6
2. Introducción............................................................................................................................................. 16
III
2.7.2 Requisitos funcionales.................................................................................................................... 37
3. Introducción............................................................................................................................................. 81
IV
INTRODUCCIÓN
Actualmente el mundo de los negocios avanza a pasos agigantados, y este movimiento arrollador va de
la mano con los cambios que surgen en la tecnología, las nuevas demandas de información, los cambios
sociales, culturales y económicos existentes en este nuevo entorno. Todo esto pone de manifiesto el
nuevo horizonte en el curso de la contabilidad y el profesional contable, pues esta ciencia es quizás una
de las más importantes dentro del campo de los negocios, para no llevar el término al absolutismo; dada
su naturaleza de informar acerca del incremento de la riqueza, la productividad y el posicionamiento de
las empresas en los ambientes competitivos.
La importancia de los sistemas de información contable radica en la utilidad que tienen estos tanto para
la toma de decisiones en las empresas como para aquellos usuarios externos.
Las nuevas demandas de información abren campo a la introducción de nuevos conceptos que pueden
llegar a potencializar la empresa dentro del mercado si se le da el adecuado manejo, reconocimiento y
medición.
Sin embargo a pesar de la gran diversidad de sistemas, no existe una solución única e integral para
tratar los procesos contables específicos de la contabilidad cubana. Muchos de los sistemas que hoy
están en el mercado carecen de una estructura de soporte adaptable y en otros casos sufren los efectos
de decisiones no previstas en su creación, por lo que se necesita un producto totalmente configurable y
flexible. Además gran cantidad de empresas en el territorio, utilizan productos importados trayendo
consigo gastos considerables de divisas por conceptos de mantenimiento y licencia, en adición a la falta
de manejo de la dualidad monetaria, con relación a las particularidades de la contabilidad nacional.
Es por ello que se crea el proyecto ERP-Cuba coordinado por el Ministerio de Finanzas y Precios,
compuesto por especialistas de diversos organismos, quienes de conjunto con estudiantes y profesores
de la Universidad de las Ciencias Informáticas tienen la misión de diseñar y construir una solución
integral que cumpla con los requerimientos funcionales y técnicos que estén a la altura de las mejores
soluciones de este tipo a nivel mundial.
1
Implementar un sistema con tales características es un proceso largo, costoso, complejo y requiere de
gran cantidad de personal. Siendo más factible dividir su desarrollo en subsistemas que representen las
distintas áreas de la empresa, de forma que se optimice todo el proceso.
Dadas las necesidades previamente descritas se hace necesario plantear como problema a resolver:
¿Cómo contribuir al desarrollo de una solución contable que estandarice el manejo de la Contabilidad
cubana de manera tal que se emplee la dualidad monetaria y; que sea flexible y adaptable?
Para dar solución al problema existente, se propone como objeto de estudio los procesos de negocio
que tienen lugar en la Contabilidad financiera. Siendo el campo de acción el modelado de los procesos
contables del subsistema Contabilidad general.
Teniendo en cuenta el problema anterior se traza como objetivo general realizar el Análisis y Diseño
del subsistema Contabilidad general. Para dar solución al objetivo general planteado se proponen los
siguientes objetivos específicos:
Dentro de las tareas que se proponen para dar solución a los objetivos trazados se encuentran:
Crear los artefactos correspondientes al negocio mediante la modelación por procesos, esto
permitirá posteriormente una buena captura de los requisitos funcionales.
Validar con los clientes las especificaciones de los requerimientos detectados, para de esta forma
dejar constancia de que éstos se ajustan a sus necesidades.
Elaborar los artefactos definidos por el modelo de desarrollo para el flujo de trabajo de Diseño.
Se plantea como idea a defender: un buen Análisis y Diseño de los procesos contables que tienen lugar
en el subsistema Contabilidad general permitirá, una posterior implementación que se ajuste a las
necesidades de las entidades cubanas.
Métodos Teóricos
Lógico - histórico: se emplea para estudiar el desarrollo lógico e histórico de los principales
criterios sobre el tema. El empleo de este método permitió describir y explicar las características
del objeto y representar un nivel de la investigación, cuyo contenido es sometido a elaboración
racional.
Modelación: pues se crean abstracciones que explican la realidad, por ejemplo, todos los
modelos y diagramas presentados.
Capítulo 1: Fundamentación teórica. En este capítulo se hace un estudio del estado del arte de las
herramientas para el Modelado de negocio y Gestión de requisitos. Además se explica el modelo de
desarrollo, herramientas, notación y lenguaje de modelado a utilizar para el desarrollo del Análisis y
Diseño de la futura solución.
3
Capítulo 2: Descripción de la solución propuesta. En este capítulo se reflejará el trabajo de investigación
sobre los procesos de negocio inherentes a la Contabilidad general, de una empresa cubana, mediante
el Modelado de Negocio. Además se incluyen las descripciones de los requisitos o condiciones relativas
a las necesidades de los clientes coleccionadas a través de los diferentes métodos de captura de
información para estos propósitos, constituyendo la Gestión de requisitos de dicha solución. Con
basamento en los requisitos, se realizaron los prototipos de interfaces para la solución a desarrollar.
4
CAPÍTULO 1 Fundamentación teórica.
1. Introducción
En el presente capítulo se agregan conceptos sobre la Contabilidad general, para una mayor
comprensión del alcance de esta ciencia y al mismo tiempo como subsistema de un Sistema contable.
De estos últimos se realiza un estudio donde se brinda una visión general de sus características más
significativas y los subsistemas que se han automatizado en ellos de mayor importancia para la
Contabilidad, profundizando en los de mayor número de implantaciones en Cuba. A continuación se
realiza una descripción del modelo de desarrollo, tecnologías y herramientas a utilizar para la
consecución de la solución propuesta, así como una breve descripción del papel que desempeñan los
roles vinculados a esta investigación.
1.1.1 Contabilidad.
La contabilidad es una ciencia de naturaleza económica que tiene por objeto producir información para
hacer posible el conocimiento pasado, presente y futuro de la realidad económica en términos
cuantitativos en todos sus niveles organizativos, mediante la utilización de un método específico
apoyado en bases suficientemente contrastadas, con el fin de facilitar la adopción de las decisiones
financieras externas y las de planificación y control internas. (Cañibano, 1974)1
Como ciencia que es, constituye un sistema informativo que emite datos estructurados y relevantes de
los distintos entes que componen la realidad económica, como son las familias, las empresas, el sector
público y la nación. Estos datos, tras ser analizados e interpretados, son empleados por los sujetos
económicos para controlar los recursos con los que cuentan y tomar las medidas oportunas para
hacerlos más fructíferos y, en todo caso, para evitar una situación deficitaria que pondría en peligro su
supervivencia. En principio, estos datos indican cuáles son los recursos económicos y financieros de los
que dispone la unidad económica objeto de análisis. Para que esta información sea útil a aquellos que la
emplean, ha de ser objetiva, creíble, oportuna, clara, asequible y completa (Oliver, y otros, 1990).
1
Concepto de contabilidad más actualizado que existe, expresado por un especialista reconocido.
5
1.1.2 Sistemas contables
Un Sistema contable sigue un modelo básico y bien diseñado, ofreciendo así, control, compatibilidad,
flexibilidad y una relación de costo/beneficio. En la contabilidad de cualquier empresa
independientemente del sistema contable que utilice, se deben ejecutar tres pasos básicos relacionados
con las actividades financieras; los datos se deben registrar, clasificar y resumir, sin embargo el
proceso contable involucra además la comunicación a quienes estén interesados y la interpretación de la
información contable para ayudar en la toma de decisiones comerciales.
Existen muchas empresas dedicadas a la creación y comercialización de Sistemas contables por todo el
mundo, esta investigación expondrá algunos rasgos significativos de los más usados en varias
empresas nacionales, pudiéndose mencionar por tanto:
ASSETS NS
Es un Sistema de gestión integral, estándar y parametrisado que permite el control de los procesos de
Compras, Ventas, Producción, Taller, Inventario, Finanzas, Contabilidad, Presupuesto, Activos fijos,
Útiles y herramientas; y Recursos humanos. Como Sistema integral todos sus módulos trabajan en
estrecha relación, generando, automáticamente, al subsistema de Contabilidad los Comprobantes de
operaciones por cada una de las transacciones efectuadas, esto permite que se pueda trabajar bajo el
principio de Contabilidad al día, si se elige generar automáticamente los asientos diarios de cada una de
las transacciones efectuadas a través del sistema en los diferentes módulos.
Se podrá además, confeccionar otros asientos diarios de operaciones no controladas por ASSETS y
emitir en cualquier momento los Estados financieros de la entidad en múltiples monedas atendiendo a la
6
tasa de cambio. Los Estados financieros se pueden emitir para toda la compañía, por centros de costo o
agrupaciones (D'Marco, 2006).
Es una solución completa de oficina. Cubre todas las funcionalidades en las áreas de Contabilidad,
Distribución, Logística, Servicios, Recursos humanos, Nóminas, Proyectos, Fabricación, entre otras. Es
un software modular diseñado para cualquier tipo de empresa que ha sido traducido a múltiples idiomas.
Además, soporta regímenes legales y comerciales en más de 20 legislaciones diferentes.
El innovador diseño de Exact Globe aporta una nueva dimensión a la Contabilidad. Las cuentas
financieras ya no son un elemento aparte de la gestión de operaciones. Todos los documentos que han
sido incluidos en los procesos principales generan automáticamente asientos en el libro mayor. Por lo
tanto, el balance y la cuenta de pérdidas y ganancias están siempre actualizados (Exact, 2006).
SAP
Está basado en una plataforma abierta que proporciona un completo control sobre su operativa y
estrategia empresarial. Mejora, al mismo tiempo, la productividad ya que proporciona la flexibilidad
necesaria para adaptar la estrategia corporativa a las necesidades empresariales cambiantes,
basándose en informaciones claras y en tiempo real. Entre las funcionalidades que SAP ERP le ofrece,
cabe destacar: Análisis empresarial, Contabilidad financiera e interna, Gestión del capital humano,
Gestión de operaciones, Gestión de servicios corporativos, Autoservicios.
Contabilidad financiera e interna, ofrece control e integración de toda la información financiera y contable
esencial para la toma de decisiones estratégicas y operativas. Esta herramienta mejora la gestión de
controles internos, auditoria, simplifica el análisis financiero y le permite llevar a cabo procesos de
negocio adaptables a cambios en el mundo de las finanzas. Todo esto le permitirá transformar sus
controles financieros de una simple función administrativa, en una parte de su empresa centrada en la
estrategia, el valor y la rentabilidad del capital. Rentabilidad y crecimiento sostenibles metas alcanzables
con esta solución financiera. Permite mantener el control y la responsabilidad de las finanzas y
contabilidad al mismo tiempo que capacita a su empresa para conseguir altos niveles de crecimiento
sostenible. Esta solución financiera le facilita, acelerar el proceso de cierre mediante la automatización
de procesos, flujo de trabajo y colaboración interna y externa; mejorar la eficacia de sus esfuerzos de
conformidad mediante auditorías completas, informes más exhaustivos y gestión de controles internos,
mejorar el análisis de negocio y el soporte para la toma de decisiones, implantando herramientas de
7
gestión que analizan toda la empresa y sus recursos y maximiza el flujo de caja mediante la mejora de la
facturación, las cuentas de deudores, los cobros y la gestión de tesorería. (SAP, 2009)
VERSAT-Sarasola
El módulo de Contabilidad general y de gastos permite llevar el control y el registro contable individual
de todos los hechos económicos que se originan en las estructuras internas de las entidades y obtener
los Estados financieros y los análisis económicos y financieros en estos niveles. El análisis de la
información puede realizarse a partir de los Clasificadores de cuentas, Centros de costos o desde los
Comprobantes contables, hasta los “Documentos primarios” que dieron origen a cada una de las
operaciones. Se estructura en un grupo de subsistemas, donde se procesan y contabilizan documentos
primarios y se anotan los movimientos de los recursos materiales, financieros y laborales que se utilizan
en una entidad a partir de una configuración previa de los comprobantes que se originan.
RODAS XXI
Además, cuenta con el módulo Administrador, que brinda mayor integralidad al sistema y garantiza
facilidades adicionales durante su instalación y explotación.
8
El módulo de Contabilidad del sistema RODAS XXI, al ser éste un sistema integral, incluye la
importación de comprobantes generados por las operaciones en el resto de los módulos permitiendo su
revisión antes de ser traspasados al Mayor general, es posible incluso realizar ajustes a los
comprobantes importados antes de traspasarlos. Además de la importación, en este módulo pueden
realizarse comprobantes de operaciones directamente, contabilizando operaciones que por sus
particularidades no se realizan en ninguno de los otros módulos del sistema o sencillamente realizando
comprobantes de ajuste de operaciones. Este módulo le brinda, mediante una opción, la posibilidad de
revertir comprobantes de forma automática facilitando la realización de ajustes (RodasXXI, 2002).
SISCONT5
Este sistema se aviene a las definiciones y conceptos del Ministerio de la Industria básica aunque por
las acciones contables financieras que permite puede ser utilizado en otras entidades nacionales.
Está formado por los módulos, Efectivo en caja y banco, Inventarios, Cobros y pagos, Facturación,
Activos fijos tangibles, Nóminas y Contabilidad.
Puede ser explotado en régimen mono-usuario y multiusuario. Se define para mono-entidad y multi-
entidad, para esta última existe el control de su acceso para las entidades en un mismo equipo de
cómputo como servidor (Siscont5, 2008).
CONDOR
El Sistema de gestión contable CONDOR, que ofrece soluciones informáticas óptimas adaptadas a las
normas y principios de la Contabilidad general aceptados en Cuba de conformidad con las normas y
procedimientos establecidos por los Ministerios de Finanzas y precios y; de Informática y
Comunicaciones. Cuenta actualmente con más de 1000 clientes en el Ministerio del Transporte y en el
Instituto Nacional de Recursos hidráulicos (SICS, 2008). Está compuesto por módulos como el de
Contabilidad general, Activos fijos, Nómina/Pre-nómina, Inventario, Condexce2 y Disponibilidad
financiera permitiendo el intercambio entre ellos automáticamente y por opciones.
El módulo de Contabilidad general controla todas las transacciones propias de la contabilidad. Permite el
enlace con los demás módulos mediante Comprobantes de operaciones, permite hacer consolidado de
múltiples compañías dentro de una misma entidad (SICS, 2008).
2
Convertidor de la información contable del módulo Condor - Contabilidad general a un libro Excel, permitiendo la
elaboración y el análisis de la información en las diferentes etapas de forma automática y sencilla, garantizando la seguridad y
confiabilidad en los datos.
9
1.2 Modelo de desarrollo y herramientas empleadas
Todo desarrollo de software es riesgoso y difícil de controlar, es por eso que se debe tener un especial
cuidado a la hora de seleccionar una metodología adecuada de desarrollo de software porque puede
que al final los clientes no queden satisfechos y los desarrolladores aún más insatisfechos. Para la
solución contable en desarrollo, un conjunto bien notable de especialistas decidió establecer un Modelo
de Desarrollo de Software orientado a Componentes como modelo idóneo a emplear.
El ERP3 es un sistema integral de gestión empresarial que está diseñado para modelar y automatizar la
mayoría de los procesos en la empresa (Contabilidad general, Caja, Banco, Costos y procesos, Cobros
y pagos, Inventario, Auditoría, Planificación, entre otros). Su misión es facilitar la planificación de todos
los recursos de la empresa. El software ERP planea y automatiza muchos procesos con la meta de
integrar información a lo largo de la empresa y elimina los complejos enlaces entre los sistemas de las
diferentes áreas del negocio. Es un proyecto que por su complejidad en los procesos de negocio,
tamaño, integración entre los subsistemas que lo conforman y además por el cúmulo de información que
almacenan y analizan, requiere de una largo período de elaboración, construcción y coordinación entre
los equipos de desarrollo (Producción, 2009).
3
Enterprise Resource Planning (Planificación de recursos de la empresa).
10
Fig. 1: Organización por roles de la línea.
Rol de Analista:
El Analista debe poseer grandes habilidades de comunicación además de conocimiento del proceso de
desarrollo definido para el ERP. Debe ser capaz de identificar, delimitar y describir los procesos de
negocio. Representándolos a través de la notación BPMN. Debe tener habilidades para identificar y
describir los requisitos de software.
Responsabilidades:
Participar en las sesiones de trabajo para identificar, describir y validar los procesos de negocio y
los requisitos de software.
Taller de diseño.
Modelo conceptual.
Especificación de requisitos.
Casos de prueba.
Se especializa en la capa Lógica de negocios. Debe ser capaz de identificar, organizar y dividir en
componentes su Línea de desarrollo.
Responsabilidades:
Taller de Análisis.
Reunión de implementación.
Implementación.
El modelo de desarrollo antes expuesto fue creado dadas las necesidades y particularidades del
proyecto ERP-Cuba, el cual está en función principalmente de la arquitectura definida. En la presente
investigación se emplearon los roles de Analista y Diseñador de lógica de negocio, con todos los
artefactos y actividades que el modelo determina se deben generar y dar seguimiento respectivamente.
BPMN (Business Process Modelling Notation (Notación para el Modelado de Procesos de Negocio)) es
una iniciativa de la BPMI (Business Process Management Initiative, un consorcio de negocios) que
apunta a definir una notación gráfica común para modelar los procesos de negocio.
13
1.2.4. Visual Paradigm para UML
El Visual Paradigm es una Suite de herramientas CASE que utiliza “UML” como lenguaje de modelado.
Es independiente de plataforma, dotada de una buena cantidad de productos o subsistemas para
facilitar el trabajo durante la confección de un software, lo cual garantiza la calidad del producto final. Es
una herramienta que en la universidad ha incrementado los niveles de aceptación, ya que actualmente
se han comprado las licencias para su uso. Este ofrece:
Diseño centrado en casos de uso y enfocado al negocio que generan un software de mayor
calidad.
Uso de un lenguaje estándar común a todo el equipo de desarrollo que facilita la comunicación.
Otra de las características que posee es que resulta una herramienta amigable para el usuario ya que
contiene facilidades para redactar especificaciones de Casos de Uso del Sistema utilizando plantillas
que se encuentran definidas o que pueden ser creadas por los usuarios, permite la sincronización entre
Diagramas de Entidad Relación y Diagramas de Clases, la generación de Código / Ingeniería Inversa.
Además permite la integración entre distintos ambientes de Desarrollo Integrados (IDE) como Visual
Studio y Eclipse entre otros (International, 2006).
Para realizar el diseño se consultaron las siguientes herramientas que fueron definidas por los
especialistas para llevar a cabo la implementación:
ExtJs framework: es un framework para Java Script muy utilizado en el desarrollo de aplicaciones Web
con AJAX. Tiene una librería inmensa que permite configurar las interfaces Web de manera semejante a
aplicaciones de escritorio. Contiene la mayoría de los controles de los formularios Web incluyendo Grids
para mostrar datos y elementos semejantes a la programación de escritorio como los formularios,
14
paneles, barras de herramientas, menús y muchos otros. Dentro de su librería de componentes incluye
elementos para el manejo de datos, lectura de XML, lectura de datos JSON e implementaciones
basadas en AJAX. Presenta el uso de Java Script con una programación orientada a objetos (Diseño
Avanzado de Aplicaciones Web., 2009).
Doctrine framework: es un potente y completo sistema ORM (Object Relational Mapper) para PHP 5.2+
con un DBAL (Database Abstraction Layer) incorporado. Entre muchas otras cosas tiene la posibilidad
de exportar una base de datos existente a sus clases correspondientes y también a la inversa, es decir
convertir clases (favorablemente creadas siguiendo las pautas del ORM) a tablas de una base de datos.
(Diseño Avanzado de Aplicaciones Web., 2009).
Zend_Ext framework: es uno de los más utilizados para PHP y utiliza el patrón MVC como base de su
funcionamiento. Es fácilmente integrable a las aplicaciones debido a su composición ya que contiene
diferentes clases de gran utilidad, como por ejemplo en la búsqueda dinámica de ficheros a incluir o
utilizar. Cuenta con un importante mecanismo de manejo de controladores y vistas por lo que se
propone tenerlo en cuenta para el diseño de estos dos componentes de la arquitectura. (Diseño
Avanzado de Aplicaciones Web, 2009).
15
CAPÍTULO II: Descripción de la solución propuesta.
2. Introducción
En este capítulo se presenta una propuesta de lo que será el sistema a partir del análisis realizado
posteriormente al negocio, detallando la descripción de los procesos que lo componen y determinando
cuáles de estos procesos se automatizarán para conformar el producto final.
Aparecen también enumerados los requisitos funcionales del sistema a desarrollar, logrando establecer
de este modo los rasgos imprescindibles que debe tener el mismo una vez que haya sido terminado,
para que las necesidades y solicitudes de los clientes queden en su mayoría satisfechas.
Una técnica para la especificación de los requisitos más importantes del sistema, que da soporte al
negocio, es el modelo del negocio, con lo cual se refuerza la idea de que sea el propio negocio lo que
determine los requisitos.
Un proceso puede ser definido como un conjunto de actividades enlazadas entre sí que, partiendo de
una o más entradas las transforma, generando un resultado (Aiteco, 2006).
16
2.3 Procesos que tienen lugar en el subsistema Contabilidad general
En la presente investigación se definieron cinco procesos principales para el subsistema Contabilidad
general, éstos son:
Realizar apertura.
Realizar cierre.
A continuación se explica brevemente en que consiste cada proceso así como los diagramas donde se
muestra la secuencia de pasos para llevarlos a cabo. Una descripción exhausta se puede encontrar en
los documentos de descripción de procesos que se adjunta a la investigación, como parte de los anexos.
El Nomenclador de cuentas nacional es un documento oficial que está reflejado en la Resolución No. 9
del 2007 emitido por el Ministerio de Finanzas y Precios. El proceso Configurar nomenclador de cuentas
para la entidad consiste en seleccionar de ese nomenclador las cuentas y subcuentas específicas que
emplea cada entidad para organizar su información contable. El nomenclador configurado se aprueba,
se imprime y pasa a formar parte del Manual de procedimiento de contabilidad de la entidad.
17
Diagrama del proceso:
La apertura no es más que el paso inicial para realizar la contabilidad en cualquier entidad, sus
características varían de acuerdo al nivel de procesamiento de la información contable, ya sea de forma
manual, automatizada o para una entidad nueva. Debe hacerse al inicio del año o Ejercicio económico, o
en el momento en que surja la nueva entidad. Para establecer comparaciones entre los resultados del
concluido ejercicio, se emitirán los Estados financieros que muestran el estado en el que inicia el nuevo
año la entidad.
18
Diagrama del proceso:
Sección1 - Subproceso Apertura de ejercicio contable: ésta se lleva a cabo después de un cierre de
Ejercicio contable donde se actualizan todas las cuentas reales transfiriendo sus saldos de fin de
período, como los iniciales del año, poniéndolas en vigencia.
19
Diagrama del subproceso Apertura de ejercicio contable:
Sección2 - Subproceso Apertura por cambio de sistema: este proceso de apertura resulta más
sencillo, ya que la incorporación o captura del Nomenclador de cuentas, del Codificador de centros de
costo y de los Elementos y subelementos del gasto, se realizan por importación del Sistema en uso
hasta ese momento.
20
Diagrama del subproceso Apertura por cambio de sistema:
21
Sección3 - Subproceso Apertura inicial: en ella se definen paso por paso todos los recursos
necesarios como nomencladores, Cuentas reales, Cuentas nominales y de existir las de Orden. Se
asienta el primer Comprobante de operaciones en el libro Mayor, lo que permite la emisión del Balance
de comprobación de saldos registrando el inicio de la entidad.
22
Proceso de negocio: Emitir comprobante de operaciones
Los procedimientos de cierre en este subsistema están condicionados a que no existan operaciones
pendientes de posteo (asentados) y que hayan efectuado el cierre correspondiente los restantes
subsistema en uso. Procesados todos los hechos económicos mediante las diferentes opciones y
subsistemas, y asentados en los registros contables, así como terminados los procedimientos que se
deben seguir desde el punto de vista contable, se procede a cerrar un período económico, el cual se
divide en tres categorías: Cuando no es mes 12, Cuando es mes 12 y Cuando es mes 13 o Cierre de
Ejercicio contable.
24
Sección1 - Subproceso Cuando no es mes 12: estos cierres son de tipo mensuales, que se hacen
dentro del Año o Ejercicio contable. Los períodos pueden ser de uno a seis meses según estime la
entidad y su objetivo es saber el estado de la entidad en ese tiempo.
25
Sección2 - Subproceso Cuando es mes 12: éste es el último cierre de período que se hace y es en el
mes de Diciembre.
26
Sección3 - Subproceso Cuando es mes 13: el objetivo central es emitir los Estados financieros para
comprobar la situación contable en la que cierra la entidad.
En este proceso figura la elaboración de los Estados financieros, que constituyen una representación
estructurada de la situación y rendimiento financieros de la entidad. Los Estados financieros también
muestran los resultados de la gestión realizada por los administradores con los recursos que se les han
confiado. Para cumplir este objetivo los Estados financieros suministran información acerca de los
siguientes elementos de la entidad:
Activos.
Pasivos.
Flujos de efectivo.
Entre los Estados financieros fundamentales de la entidad figuran: Balance de comprobación de saldos,
Estado de situación, Estado de resultado, Reporte de utilidad acumulada.
Balance de comprobación de saldos: una vez asegurado que se han contabilizado todas las
operaciones que procedan y los libros cuadrados, se elabora un Balance de comprobación de saldos
pre-cierre, con los saldos de las cuentas, subcuentas, análisis y sub-controles, a fin de comprobar el
cuadre de los saldos deudores con los acreedores y facilitar la emisión de los Estados financieros que
procedan. Para emitir este reporte la entidad no precisa de un período específico, puede ser en
cualquier momento que lo estime necesario.
Estado de situación (o Balance general): se elabora a partir del Balance de comprobación de saldos y
en él se incluirán, como mínimo, rúbricas específicas con los importes correspondientes a las siguientes
partidas:
Inventarios.
28
Activos fijos tangibles.
Provisiones.
Intereses minoritarios.
Estado de resultado: este reporte también se emite a partir del Balance de comprobación de saldos y
en él se incluirán, como mínimo, rúbricas específicas con los importes que correspondan a las siguientes
partidas:
Ingresos ordinarios.
Gastos financieros.
Pérdidas o utilidades antes de impuestos, que se hayan reconocido por la venta o disposición por
otra vía de Activos, así como por la cancelación de Pasivos correspondientes a explotaciones en
interrupción definitiva.
Se presentará un desglose de los gastos utilizando para ello una clasificación basada en la naturaleza
de los mismos o en la función que cumplan dentro de la entidad.
29
En el Estado de resultado, se presentarán rúbricas adicionales que contengan otras partidas, así como
agrupaciones y subtotales de las mismas, cuando tal presentación sea relevante para la comprensión
del rendimiento financiero de la entidad o sea exigido por alguna norma en particular.
30
2.4 Patrones de Control de flujo empleados
Para realizar los diagramas de procesos de negocio, se emplearon diversos patrones de control de flujo
que aportaron más flexibilidad y organización, permitiendo crear una notación estandarizada que
representara los aspectos más significativos de comportamiento de los procesos en una entidad. Estos
patrones son:
Secuencia: estandariza la habilidad de representar secuencias de actividades.
División paralela: representa una división de una sola línea de control en múltiples líneas o
ramas de control que puedan ser ejecutadas concurrentemente.
Opción exclusiva: es un punto de decisión en el flujo de un proceso donde una sola rama de
varias, es seleccionada.
Unión simple: representa un punto en el flujo de trabajo del proceso donde dos o más ramas
alternativas se unen sin incluir sincronización.
Todos estos patrones están divididos en categorías para lograr un mayor alcance y representación de la
información, de los utilizados se presentan las divisiones:
Opción exclusiva - Compuerta exclusiva (XOR Gateway): El cual parte de una actividad que
debe orientarse por una sola rama, escogiendo entre varias opciones, es por ello que al tomar la
deseada, se excluyen las demás.
Unión simple - Implícito (Implicit): Constituye la unión de varias actividades en una final, donde
desde varias entradas converge la información hasta obtener una única salida.
31
Fig. 12: Mapa de procesos para el subsistema Contabilidad general.
32
Modelo conceptual del proceso Configurar nomenclador de cuentas para la entidad:
Fig. 13: Modelo conceptual del proceso Configurar nomenclador de cuentas para la entidad.
34
Modelo conceptual del proceso Realizar cierre:
35
2.7 Requerimientos
Los requerimientos representan las necesidades de los usuarios y los objetivos del sistema. Deben ser
concisos, completos y especificar claramente todo lo que se necesita llevar a cabo, ya sean entradas,
salidas, válidas o no; todas las posibles respuestas y situaciones. No deben ser ambiguos, sólo deben
tener una interpretación. Deben ser verificables, es decir; se debe poder chequear que cada requisito es
cumplido por el software. Además, los requisitos deben ser lo más adaptables y modificables posible
(Torres, 2008). Los requerimientos deben ser capaces de satisfacer todos y cada uno de los objetivos
del sistema.
La IEEE4 define un requerimiento como: (1) “Una condición o necesidad de un usuario para resolver un
problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema
o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento
formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2)”. (IEEE,
1993)
A continuación se presentan un grupo de técnicas que de forma clásica han sido utilizadas para esta
actividad en el proceso de desarrollo de todo tipo de software.
La Entrevista es una técnica para recopilar información a partir de un intercambio directo entre
personas o grupos (López, 2004). Esta fue la primera técnica empleada para la captura de los requisitos
con los que debía cumplir el subsistema Contabilidad general. La misma estuvo dirigida a especialistas
en contabilidad que han manejado diversos Sistemas contables que forman parte del equipo de trabajo.
4
Institute of Electrical and Electronics Engineers (IEEE). (Instituto de Ingenieros Eléctricos y Electrónicos), una asociación
técnico-profesional mundial dedicada a la estandarización, entre otras cosas.
36
que podemos tener acceso en forma directa o indirecta para su consulta (González). Esta técnica se
utilizó para estudiar y analizar las descripciones del negocio hechas por los especialistas, tanto como los
Manuales de usuario, de Sistemas contables como el Versat-Sarasola y otros documentos relativos a la
Contabilidad general, lo que permitió además tener conocimiento de otros requisitos necesarios que no
fueran capturados durante la entrevista.
Brainstorming (Tormenta de ideas) es también una técnica de reuniones en grupo cuyo objetivo es
que los participantes muestren sus ideas de forma libre. Consiste en la mera acumulación de ideas y/o
información sin evaluar las mismas. (Escalona, y otros, 2002). Para el empleo de esta técnica se
reunieron los integrantes del equipo de trabajo, por varios días, donde surgieron ideas novedosas, lo que
permitió optimizar al máximo el trabajo a desarrollar.
Concept Mapping (Modelo conceptual) son grafos en los que los vértices representan conceptos y las
aristas representan posibles relaciones entre dichos conceptos. (Escalona, y otros, 2002). Permitieron
un mejor entendimiento del negocio a través del modelado de los conceptos fundamentales que se
asocian en los procesos de negocio tratados.
R5 Definir cuentas de ingresos y gastos para las diferencias por redondeo en monedas y variaciones de
tipo de cambio por monedas.
R9 Cierre
Debe estar
creada la
Estructura
económica.
Descripción En esta primera apertura se define la Cuenta sin ningún tipo de apertura
específica. Se crea la cabeza de la cuenta, de acuerdo con sus atributos
Código, Descripción, Naturaleza, Contenido económico, Fecha inicio, Fecha
fin.
40
En los campos de Fecha se seleccionarán datos de fecha. Siendo
obligatorio definir Fecha inicio. En caso de definir una Fecha fin, esta
debe ser mayor que la de Inicio.
Post-requisito No procede.
Descripción Para ello se realizará una apertura del árbol de cuentas sin usar otro
nomenclador, a cualquier nivel de la máscara.
41
- En el campo Descripción se podrán introducir los datos definidos
según la máscara de nomencladores de Configuración.
Post-requisito No procede.
No procede No procede
Deben estar
42
configurados los
nomencladores
por los que se
puede realizar la
apertura.
Descripción En este tipo de apertura se le realizará a la cuenta una apertura usando otro
nomenclador, a un nivel definido por la máscara.
Post-requisito No procede.
43
Conceptos tratados Conceptos Atributos
No procede.
El usuario se haya
autenticado en el sistema y
tenga permisos para
ejecutar la acción.
El Nomenclador de cuentas
debe contener información
y deben haberse realizado
los enlaces
correspondientes con otros
clasificadores como los de
clientes, los de persona, los
de centros de costo, los de
elementos del gasto u otros
creados en la solución.
44
error”.
- Chequear en cada pase que tenga anexo que la sumatoria del anexo
al pase sea igual al importe que tiene el pase en débito o crédito, por
tipo de monedas.
45
- Suma de control de todos los niveles de centros y elementos.
Post-requisito No procede
Criticidad Importante.
46
Precondiciones Precondiciones
Pre-requisito
No procede.
El usuario se haya autenticado en el
sistema y tenga permisos para
ejecutar la acción.
- El importe del Registro anexo al pase debe ser igual al importe del
pase registrado en el comprobante.
Postcondiciones Se ha registrado un pase en el Registro anexo al pase.
Post-requisito No procede
Criticidad Importante.
47
Conceptos tratados Conceptos Atributos
Validaciones
Si el comprobante está en estado “Asentado”
- Chequear en cada pase que tenga anexo que la sumatoria del anexo al
pase sea igual al importe que tiene el pase en débito o crédito, por tipo
de monedas (Base/Original).
Post-requisito No procede
Criticidad Importante.
49
Debe existir el comprobante y estar No procede.
en estado “Sin error”.
Validaciones
El Comprobante de operaciones debe estar en estado “Sin error”.
Post-requisito No procede
Criticidad Importante.
Validaciones
El Comprobante de operaciones debe estar en estado “Terminado”.
50
Postcondiciones Se ha cambiado el estado del comprobante.
Post-requisito No procede
Criticidad Importante.
R9 Cierre
Pre-requisito No procede.
Descripción
Los procedimientos de cierre están condicionados a que no existan
documentos pendientes de contabilizar y que haya efectuado el cierre
correspondiente en los restantes módulos en uso.
Validaciones
- Verificar que todos los subsistemas estén cerrados. El sistema
debe verificar que todos los subsistemas se encuentren en estado
“Cerrado”. De existir algún subsistema que no haya cerrado se
muestra un mensaje de error notificando que el período no se
puede cerrar.
51
tengan el saldo como acreedoras y las cuentas que son acreedoras
no tengan el saldo como deudoras. En caso de que existan, se
muestra un mensaje de error notificando que el período no se
puede cerrar.
Postcondiciones
- El subsistema cambia de fecha activa para el nuevo período.
Post-requisito No procede
Criticidad Importante.
52
Precondiciones El contador debe haberse identificado y autenticado ante el sistema.
Pre-requisito No procede.
Descripción
Los procedimientos de cierre están condicionados a que no existan
operaciones pendientes de asientos y que hayan efectuado el cierre
correspondiente los restantes módulos de contabilidad en uso. Procesados
todos los hechos económicos mediante las diferentes opciones y
subsistemas, y asentados en los registros contables, así como terminados
los procedimientos que se deben seguir desde el punto de vista contable,
se procede a cerrar un período ejercicio económico.
Validaciones
El sistema valida los datos de la siguiente manera:
53
contrarios a su naturaleza. En caso de que existan, se muestra un
mensaje de error notificando que el período no se puede cerrar. De
igual forma se procederá con los grupos presupuestarios.
Postcondiciones
- Al cerrar el período, el subsistema cambia la fecha de
procesamiento para el próximo período.
Post-requisito No procede
Criticidad Importante.
Descripción
El sistema cerrará el Ejercicio económico.
54
Validaciones
El sistema valida los datos según:
Postcondiciones
- Al cerrar el ejercicio económico, el subsistema cambia la fecha de
procesamiento para el próximo año y período, activando un nuevo
ejercicio contable.
Post-requisito No procede
Criticidad Importante.
La característica más importante de los Estados financieros y lo que los hace diferentes; es la
información que deben contener. Los detalles de cada uno de ellos están comprendidos también dentro
del paquete de Especificaciones de requisitos anexados a la investigación. Se decidió por los autores no
reflejar estas especificaciones en el presente documento, dada su extensión y nivel de complejidad por
lo que sólo se muestra una figura de la información que deben contener:
55
R13.1 Especificación de requisitos: Generar reporte de balance de comprobación de saldos:
Fig. 18: Formato del Estado financiero, Generar reporte de balance de comprobación de saldos.
56
R13.2 Especificación de requisitos: Generar reporte de estado de situación:
Fig. 19: Formato del Estado financiero, Generar reporte de estado de situación.
57
R13.3 Especificación de requisitos: Generar reporte de estado de resultado:
Fig. 20: Formato del Estado financiero, Generar reporte de estado de resultado.
58
R13.4 Especificación de requisitos: Generar reporte de utilidad acumulada:
Fig. 21: Formato del Estado financiero, Generar reporte de utilidad acumulada.
Los requisitos una vez definidos necesitan ser validados. La validación de requisitos tiene como misión
demostrar que la definición de éstos precisa realmente el sistema que el usuario necesita o el cliente
desea (Lowe & Hall, 1999). Es necesario asegurar que el análisis realizado y los resultados obtenidos de
la etapa de definición de los requisitos sean correctos. Pocas son las propuestas existentes que ofrecen
técnicas para la realización de la validación y muchas de ellas consisten en revisar los modelos
obtenidos en la definición de requisitos con el usuario; para detectar errores o inconsistencias.
Aún así, existen algunas técnicas que pueden aplicarse para ello, como la Revisión técnica formal, las
Listas de chequeo, las Auditorías, y los Prototipos.
59
De estas técnicas sólo se empleó la Revisión técnica formal donde los analistas del subsistema una
vez terminadas las especificaciones de requisitos realizaron la reunión de revisión, a la cual convocaron
a la especialista funcional a cargo del subsistema Contabilidad general Ernestina Lourdes Iglesias
Planas, al Dr. José Carlos Del Toro Ríos Director nacional del proyecto ERP-Cuba; al Ing. Rolando
Ramírez Concepción representante del UCID, a la MsF. Ana Inés Maury Agaisse representante del
MAC, al Ing. Osmar Leyet Fernández el entonces Jefe de línea y la analista principal Ing. Yanet Vega
Minet los cuales firmaron y aprobaron las especificaciones descritas sin posteriores modificaciones.
Esta es una de las partes más importantes de cualquier programa que determina la facilidad con que
puede ser ejecutado lo que el usuario desea hacer. Un programa muy poderoso con una interfaz
pobremente elaborada tiene poco valor para un usuario no experto.
Para el subsistema Contabilidad general se definieron los siguientes prototipos de interfaz de usuario
según los requisitos descritos (Para ver las especificaciones de las interfaces dirigirse al Manual de
usuario de Contabilidad general, el cual se encuentra anexado a la investigación).
60
Prototipo de interfaz del requisito: R1 Gestionar entidad económica.
Esta interfaz mostrará en forma de árbol todas las Entidades económicas creadas. Permitiendo las
opciones de adicionar una nueva o eliminar alguna existente para lo cual será necesario
seleccionarla previamente.
61
Prototipo de interfaz del requisito: R1.1 Adicionar entidad económica.
Mediante esta interfaz se podrá crear una nueva Entidad económica, llenando cada campo según
sus especificidades. Donde los datos de los campos Criterio económico, Formato y, Estructura y
composición; se asignarán desde otros subsistemas. Después de introducidos los datos, para
realizar la inserción de la nueva entidad, podrá presionarse el botón Aplicar si se desea continuar
adicionado entidades, sino bastaría con presionar el botón Adicionar para crearla y cerrar la interfaz.
62
Prototipo de interfaz del requisito: R2 Gestionar grupo o subgrupo contable.
Esta interfaz mostrará en forma de árbol el nombre y el código de cada Grupo y Subgrupo contable
que se haya creado hasta el momento. Brindando además las opciones de crear, modificar, buscar o
eliminar Grupos o Subgrupos contables. Para llevar a cabo esta última operación se deberá
seleccionar previamente el grupo o subgrupo que se desea eliminar.
63
A través de esta interfaz se podrá crear un nuevo Grupo o subgrupo contable según sea el caso.
Para ello se deberán llenar todos sus campos.
Esta interfaz editará los datos del Grupo o subgrupo contable en su campo correspondiente
permitiendo modificar cualquiera de ellos. En el caso de los Grupos contables sólo se podrán
modificar los que no contengan subgrupos asociados.
64
Fig. 27: Prototipo de interfaz Gestionar contenido económico.
Esta interfaz mostrará listados todos los Contenidos económicos. A su vez permitirá la opción de
adicionar, modificar, buscar o eliminar cualquiera de ellos. En el caso de la opción eliminar, se podrá
llevar a cabo siempre y cuando el Contenido económico previamente seleccionado no esté asociado
a ninguna cuenta en el Nomenclador de cuentas.
Mediante esta interfaz se podrá adicionar un nuevo Contenido económico. Para ello se deberán
llenar todos los campos necesarios, en este caso el campo Fecha fin podrá quedar vacío ya que no
necesariamente se sabe cuando dejará de estar en vigencia un Contenido económico.
65
Prototipo de interfaz del requisito: R3.2 Modificar contenido económico.
Esta interfaz editará los datos del Contenido económico seleccionado y permitirá modificar
cualquiera de ellos.
66
Prototipo de interfaz del requisito: R4 Configurar estados financieros.
Esta interfaz brindará la opción de configurar y definir los Estados financieros que serán emitidos por
la entidad, así como la información que deben mostrar. En caso de ocurrir algún error en el momento
de su creación los Grupos y Conceptos se podrán eliminar seleccionándolos previamente.
67
Prototipo de interfaz del requisito: R5 Definir cuentas de ingresos y gastos para las diferencias
por redondeo en monedas y variaciones de tipo de cambio por monedas.
Mediante esta interfaz se mostrarán las cuentas de Ingreso y Gasto por diferencia de tasa de
cambio, así como la cuenta Resultado. En caso de surgir algún error o cambio, cualquiera de ellas se
podrá eliminar, seleccionándola previamente.
Prototipo de interfaz Asignar cuenta del requisito: R5 Definir cuentas de ingresos y gastos
para las diferencias por redondeo en monedas y variaciones de tipo de cambio por monedas.
68
Esta interfaz permitirá seleccionar las cuentas de Ingreso y Gasto por diferencia de tasa de cambio
así como la de Resultado. Para ello en cada campo se cargarán las cuentas correspondientes.
Prototipo de interfaz del requisito: R6 Gestionar cuenta contable del nomenclador de cuentas.
Esta interfaz permitirá adicionar, modificar, eliminar y crear una apertura de una cuenta contable.
Además se podrán realizar búsquedas en función del código o la descripción de las cuentas
deseadas, así como su vigencia. Para ello se mostrarán las cuentas en forma de árbol de manera tal
que sólo se pueda adicionar una cuenta padre a partir de la raíz del árbol.
La interfaz anterior permitirá crearle aperturas a las cuentas padres, para ello en los campos Código
y Descripción se cargarán los datos de la cuenta padre y en el campo Apertura en: se mostrará el
nivel de la cuenta en el cual se va a hacer dicha apertura.
Prototipo de interfaz Asignar tipo de cuenta del requisito: R6.2 Crear apertura de árbol de
cuenta.
70
Prototipo de interfaz Crear cuenta apertura del requisito: R6.2 Crear apertura de árbol de
cuenta.
Una vez seleccionado el nivel, se introducen los datos de la apertura, manteniendo ésta el mismo
Contenido económico que la cuenta padre por lo que no se redefine.
Prototipo de interfaz del requisito: R6.3 Crear apertura por otro nomenclador.
71
Existen ciertos casos en los que se hace necesario realizar aperturas por nomencladores que están
definidos en otros subsistemas, por ejemplo el Nomenclador de persona en Capital humano. La
interfaz anterior permitirá mostrar los nomencladores disponibles para hacer aperturas y luego de
seleccionar el nomenclador se podrán escoger los criterios específicos del mismo.
Prototipo de interfaz Modificar cuenta apertura del requisito: R6.4 Modificar cuenta contable o
apertura.
72
En caso de ocurrir errores o cambios en los datos de las cuentas o sus aperturas éstos se podrán
modificar en cualquiera de sus campos mediante las interfaces anteriores respectivamente.
Prototipo de interfaz del requisito: R6.7 Configurar cuentas contables de ingresos, gastos y
resultado.
Una vez creadas las Cuentas contables, éstas se deben clasificar según su naturaleza en Ingreso,
Gasto o Resultado, esta acción se podrá realizar a través de la interfaz anterior.
Prototipo de interfaz del requisito: R7 Configurar nomenclador para apertura por otro
nomenclador.
73
En esta interfaz se mostrarán los nomencladores por los que se pueden hacer aperturas.
Permitiendo adicionar, modificar o eliminar dichos nomencladores.
Prototipo de interfaz del requisito: R7.1 Adicionar nomenclador para apertura por otro
nomenclador.
A través de esta interfaz se podrán adicionar y configurar los nomencladores creados por otros
subsistemas, necesarios para el uso en Contablidad general por los cuales se pueden hacer
aperturas.
Prototipo de interfaz del requisito: R7.2 Modificar nomenclador para apertura por otro
nomenclador.
75
Prototipo de interfaz del requisito: R8.1 Nuevo comprobante de operaciones.
Esta interfaz permite crear nuevos Comprobantes de operaciones, introduciendo todos los datos
requeridos.
Prototipo de interfaz Registro anexo al pase del requisito: R8.1 Nuevo comprobante de
operaciones.
76
En esta interfaz se introducirán todos los datos relacionados con los pases que contengan saldos de
cuentas de Gastos. En el campo Importe el saldo debe coincidir con el saldo en el campo Débito de
la cuenta que lo originó.
En esta interfaz el usuario podrá abrir cualquier Comprobante de operaciones que desee, y si el
estado del mismo no es “Asentado”, de ser necesario podrá modificar cualquiera de sus elementos.
79
Fig. 52: Prototipo de interfaz Comprobante de operaciones.
Interfaz que permitirá visualizar el Comprobante de operaciones al que pertenece la cuenta o subcuenta
seleccionada en el Mayor y Submayor respectivamente. En caso de que la cuenta o subcuenta sea de
gasto se permitirá también ver el Registro anexo al pase de la misma.
80
CAPÍTULO III: Construcción y validación de la solución propuesta.
3. Introducción
El diseño debe definir una solución que satisfaga de modo efectivo y eficiente los requisitos
especificados en el análisis, y al hacer ésto el modelo incorporará nuevos artefactos (clases, atributos y
operaciones para las mismas, entre otros) y tendrá en cuenta la plataforma tecnológica concreta sobre
la que debe construirse el sistema informático. De hecho, el diseño debe proporcionar una solución
creativa para el problema especificado en el análisis.
Para llevar a cabo el diseño de la solución propuesta, se consideraron las herramientas a emplearse en
la implementación y se realizó un estudio sobre las mismas, por lo que las clases del diseño web se
modelaron basadas en el patrón Modelo-Vista-Controlador (MVC), utilizando mecanismos de diseño de
clases generadas estándares para todas las vistas creadas con ExtJs framework. Además como otro
mecanismo se incluyó un paquete llamado Doctrine del cual heredaran las clases generadas en base de
datos o mapeadas, incluidas en el domain. Para crear las clases controladoras y modelos, se utilizó
Zend_Ext framework. Lo que permite estructurar la aplicación por capas: capa de Presentación (vista),
capa de Negocio (controlador) y la de Acceso a Datos (modelo), esta arquitectura posibilita un trabajo
más seguro, rápido y eficiente (Diseño Avanzado de Aplicaciones Web., 2009).
El subsistema Contabilidad general está formado por un conjunto de componentes que encapsulan
funcionalidades que representan el núcleo del Sistema integral de gestión de entidades. Los mismos se
interrelacionan entre sí y con otros componentes de otros subsistemas para dar respuesta a las
necesidades de lograr agrupar todas las características y especificidades en un único sistema que
norme las actividades contables y financieras, y que permita tener un óptimo control de los recursos.
Componentes definidos:
Configuración: en este componente se gestionan una serie de nomencladores que son la base
para el componente Nomenclador de cuentas, entiéndase Grupos y subgrupos contables,
Contenidos económicos de las cuentas y; Estructuras económicas que representan a los
propietarios de esas cuentas.
Nomenclador de cuenta: este componente es el encargado de gestionar el árbol de cuentas en
el mayor sentido de la palabra, entiéndase las cuentas y sus aperturas, sean del tipo que sean,
controladas por otros subsistemas.
81
Comprobantes de Operaciones: este componente es el encargado de contabilizar los
Comprobantes de operaciones de todos los subsistemas que componen la solución contable en
desarrollo.
Cierre: es el encargado de cerrar los Períodos y Ejercicios contables, y a la vez darle apertura a
los próximos.
Recuperaciones: este componente es el encargado de gestionar todos los reportes del
subsistema, dando la información necesaria y oportuna para la toma de decisiones.
Un patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el
núcleo de la solución al problema, de forma que puede ser reutilizado continuamente.
82
Modelo-Vista-Controlador:
Es un patrón de diseño que plantea la separación de diferentes clases en dependencia de la función que
realizan de manera tal que sea posible manejar dinámicamente la forma en que se procesan solicitudes
y gestionar cómo se mostrarán los resultados al usuario final. En otras palabras separa la presentación
del dominio de la aplicación.
Se emplearon otros patrones en la solución, los cuales están implícitos en el framework como el
Decorator en la clase Zend_View, que se encarga de asignarle responsabilidades a objetos de manera
dinámica y configurarlos con nuevos atributos. El Zend framework tiene implementado el patrón Front
Controller que implica que todas las solicitudes son dirigidas a un único script PHP 5 que se encarga de
instanciar al controlador frontal y redirigir las llamadas. Tiene una instancia única del controlador frontal
disponible mediante el patrón Singleton para lograr una vía de entrada única a las solicitudes.
En el presente epígrafe se muestran los diagramas de clases del diseño de cada componente, con sus
respectivos modelos de dominio donde se incorporan las entidades con las que se relacionan. Las
descripciones de los diagramas de clases están reflejadas en documentos anexos a la presente
investigación ya que fueron artefactos que se generaron durante el flujo de trabajo y donde se exponen
5
PHP (PHP Hypertext Pre-processor) es un lenguaje de programación interpretado, diseñado originalmente para la creación
de páginas web dinámicas.
83
una serie de rasgos esenciales de cada una de las clases y métodos que las componen, a continuación
se listan las imágenes relativas a dichas propuestas de diseño:
84
Configuración.
85
Fig. 55: Diagrama de clases de Nomenclador de grupo o subgrupo contable.
86
Fig. 56: Diagrama de clases de Nomenclador de contenido económico.
87
Fig. 57: Diagrama de clases de Configurar cuentas para redondeo.
88
Fig. 58: Diagrama de clases de Configurar estados financieros.
90
Fig. 61: Diagrama del paquete Domain del componente.
91
Comprobante de operaciones.
92
Fig. 63: Diagrama del paquete Domain del componente.
93
Cierre.
94
Recuperaciones.
95
Fig. 67: Diagrama de clases de Submayor.
96
Fig. 68: Diagrama del paquete Domain del componente.
Las métricas de diseño a nivel de componentes se concentran en las características internas de los
componentes del software e incluyen medidas de la cohesión, acoplamiento y complejidad del
subsistema. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un
diseño a nivel de los componentes (Pressman, 1998).
Entre los tipos de Métricas que se utilizan para evaluar el diseño están:
Tamaño operacional de clase (TOC): está dado por el número de métodos asignados a una
clase.
Relaciones entre clases (RC): está dado por el número de relaciones de uso de una clase con
otras.
Profundidad de herencia (PH): está dado por la profundidad en al herencia de las clases
heredadas de un nodo padre.
Número de descendientes (ND): está dado por la cantidad de clases que heredan de un padre.
97
Número de operaciones redefinidas para una clase hija (NOR): está dado por la cantidad de
operaciones redefinidas en cada clase hija.
Para evaluar el diseño se empleó la métrica Tamaño operacional de clase (TOC), la cual mide la calidad
de acuerdo a los atributos Responsabilidad, Complejidad de implementación y Reutilización de las
clases. Sólo se empleó ésta debido a que en la propuesta de diseño realizada no existen ni casos de
herencia, ni utilización de relaciones de uso, lo que descarta la posibilidad de aplicar las otras métricas.
En la TOC los atributos de calidad Responsabilidad, Complejidad de implementación son inversamente
proporcionales a la Reutilización, lo que puede ser traducido como, mientras mayor sea la
Responsabilidad y Complejidad de implementación de una clase, menor será su nivel de Reutilización.
En este epígrafe sólo se mostrarán las gráficas y las valoraciones que merecen los resultaros después
de aplicar la métrica, para la cual se tuvieron en cuenta el número de métodos de las clases
Controladoras y Modelos reflejadas en el diseño de acuerdo a la propuesta planteada por arquitectura.
Todo el cálculo está contenido en el documento Métricas para el diseño el cual está dentro de los
archivos anexos a esta investigación.
98
Tamaño operacional de las clases
99
Fig. 72: Gráfico del nivel de Reutilización de las clases.
Analizando los resultados obtenidos en la evaluación de la métrica TOC se puede concluir que el diseño
de los componentes Configuración, Nomenclador de cuentas, Comprobante de operaciones, Cierre y
Recuperaciones tienen una calidad aceptable teniendo en cuenta que el 90 % de las clases incluidas en
estos componentes posee menos cantidad de operaciones que la mitad del valor máximo registrado en
las mediciones. Además el 96% de las clases poseen evaluaciones positivas en los atributos de calidad
(Responsabilidad, Complejidad de implementación y Reutilización).
En este capítulo, se ha expuesto todo lo referente al diseño, los patrones empleados, en este caso el
más importante el Modelo-Vista-Controlador, que fue el que sirvió de basamento para la realización del
diseño como tal. Se incluyen los diagramas de diseño de las clases web de todos los componentes, el
diagrama de componentes y los paquetes de dominio relativos a los componentes. Además como
recurso indispensable se aplicaron métricas al diseño, para determinar cuan factible es éste, arrojando
buenos resultados.
100
Conclusiones
El modelo de desarrollo definido por el proyecto permitió realizar el trabajo de una forma
organizada, priorizando actividades y la generación de artefactos que influyeran
satisfactoriamente en la solución.
El análisis realizado permitió cumplir con todas las necesidades que fueron definidas en las
entrevistas con los clientes.
101
Recomendaciones
Es de vital importancia que se inicie la fase dos, del Análisis y Diseño, donde se modele el
negocio relacionado con los otros procesos que no fueron incluidos en la primera parte:
Agregación y Consolidación, los cuales tienen gran peso en el funcionamiento correcto y
completo del software y de la Contabilidad general como tal.
Faltaría recomendar a los demás proyectos que empleen el modelo de desarrollo consultado y
aplicado en esta investigación.
102
Bibliografía
A., Myers B. 1996. Fismat. [Online] 1996. [Cited: Febrero 22, 2009.]
http://www.fismat.umich.mx/~crivera/tesis/node6.html.
Cortes, Jesús. 1932. Biblioteca del hombre de negocios moderno. [Online] 1932. [Cited: 3 3, 2009.]
Diseño Avanzado de Aplicaciones Web. Arias, Yuniel Eliades Proenza. 2009. 8, s.l. : Opentelematics,
2009.
D'Marco. 2006. Assets NS. [Online] 2006. [Cited: 04 08, 2009.] http://assets.co.cu/index.asp.
Escalona, María José and Koch, Nora. 2002. Ingeniería de Requisitos en Aplicaciones para la Web-Un
estudio comparativo. Sevilla : s.n., 2002.
Exact, Globe. 2006. Exact Software. [Online] 2006. [Cited: 3 3, 2009.] www.exactsoftware.es.
Figueroa, Roberth G., Solis, Camilo J. and Cabrera, Armando A. 2008. Adonisnet's.weblog. [Online]
2008. http://adonisnet.wordpress.com/2008/06/18/metodologias-tradicionales-vs-metodologias-agiles/.
García, Joaquin. 2005. Patrones de diseño, diseño de software orientado a objetos. 2005.
González, Jose Luis Hernández. Instituto Tecnologico de Apisaco. [Online] [Cited: 04 09, 2009.]
http://www.itapizaco.edu.mx/~joseluis/apuntes/estadistica/definiciones%20y%20muestreos.pdf.
Hernandez, Minerva. 2006. Semanario Económico y Financiero de Cuba. [Online] 2006. [Cited: 04 09,
2009.] http://www.opciones.cubaweb.cu/leer.asp?idnuevo=2390.
103
Himmelblau, David. 1938. Fundamentos de la contabilidad. México : s.n., 1938.
IEEE. 1993. Standards Collection: Software Engineering. 1993. IEEE Standard 610.
Lago, Ramiro. 2007. Patrones de diseño de software. [Online] 2007. [Cited: 04 10, 2009.]
http://www.proactiva-calidad.com/java/patrones/index.html.
Larman, Craig. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso
unificado. s.l. : Prentice Hall.
López, Jorge Quesada. 2004. La Informática y la Empresa. [Online] 10 2004. [Cited: 04 09, 2009.]
http://www.fec.uh.cu/info3/RECOPILACION.htm.
Martínez, Alejandro and Martínez, Raúl. Guía a Rational Unified Process. Castilla la Mancha : s.n.
Oliver, Mercedes Cervera and Aparicio, Javier Romano. 1990. Contabilidad.tk. [Online] 1990. [Cited:
04 08, 2009.] http://www.contabilidad.tk/prologo-1.htm.
Pressman, Roger. 1998. Ingeniería de Software. Un enfoque práctico. s.l. : Mc Graw Gill, 1998.
Producción, Equipo de. 2009. Modelo de Desarrollo Orientado a Componentes ERP-Cuba. Ciudad
Habana : s.n., 2009.
RodasXXI. 2002. Rodas XXI Sistema Integral Económico Administrativo. [Online] 2002. [Cited: 04 08,
2009.] http://www.rodasxxi.cu/.
Rumbaugh, James, Jacobson, Ivar and Booch, Grady. 2000. El Lenguaje Unificado de Modelado.
Manual de Referencia. 2000.
SAP, ERP. 2009. SAP España. [Online] 2009. [Cited: 05 28, 2009.]
http://www.sap.com/spain/solutions/business-suite/erp.epx.
104
SICS. 2008. SICS Servicios Informáticos, Consultoria y Sistemas . [Online] 2008. [Cited: 04 09, 2009.]
http://www.sics.cu/productos.aspx.
Siscont5. 2008. Siscont Sistema Contable Financiero. [Online] 2008. [Cited: 04 08, 2009.]
http://www.siscont.com/DESCRIPTIVO%20SISCONT.pdf.
Torres, José Luis. 2008. Promoting Community Wordwide. Especicifacion de requisitos en Ingenieria de
Software. [Online] 2008. [Cited: 04 28, 2009.] http://www.uag.mx/ieee/contsep01/requerimientos.htm..
105
Glosario de Términos
A
Activos: son los bienes y derechos que posee la empresa, de los cuales es posible hacer una
valoración en términos monetarios, los cuales van a conformar el Balance general.
Activos circulantes: constituyen aquel grupo de cuentas que representan bienes o derechos,
susceptibles de convertirse en dinero o de consumirse el próximo ciclo normal de operaciones de la
empresa.
Activos fijos: son los bienes o derechos adquiridos por la empresa y los cuales son de carácter más o
menos permanente, los cuales se adquieren con la intención de utilizarlos en la operaciones normales
de negocio y no de venta.
AJAX: acrónimo de Asynchronous JavaScript And XML es una técnica de desarrollo web para crear
aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los
usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta
forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa
aumentar la interactividad, velocidad y usabilidad en las aplicaciones.
Capital: son las aportaciones que realizan los propietarios de una entidad y aquellos beneficios que se
han obtenido en un período determinado y que no se distribuyen en forma de dividendo, es decir,
representan las obligaciones que tiene la empresa con los propietarios de la misma.
Cuentas nominales: Tienen como característica principal que son cuentas temporales, éstas duran
abiertas lo que dura el Ejercicio contable de la empresa, y al finalizar éste, son cerradas y su resultado
es traspasado a la cuenta Capital quien es en definitiva la cuenta que va ser afectada por los beneficios
o pérdida del negocio. Las cuentas nominales se crean en cada ejercicio de la empresa para registrar
106
los ingresos, los costos, gastos, pérdidas y en consecuencia poder determinar los resultados obtenidos
por la empresa en ese ejercicio, por ello se le conoce como cuenta de resultados.
Cuenta orden: permiten controlar en las unidades el presupuesto anual aprobado, el financiamiento
situado o recibido para Gastos corrientes y de Capital, así como el comportamiento de otros hechos
económicos específicos.
Empresa estatal: La empresa estatal es una entidad económica con personalidad jurídica propia, que
constituye el eslabón primario de la economía y, como tal, la base del complejo sistema de relaciones de
la economía nacional.
Empresa presupuestada (o Unidad presupuestada): Son las entidades mediante las cuales el Estado
administra directamente parte de los bienes que integran la propiedad estatal socialista y presta sus
servicios sociales, como la educación y la salud pública y organiza su administración interna. No tiene
personalidad jurídica civil aunque sí son sujetos de derecho económico, laboral y financiero. En ellas,
sus gastos se financian totalmente por el Presupuesto del estado, al cual aportan sus ingresos de
tenerlo.
Gasto: Los gastos son disminuciones brutas de Activos causadas por la entrega de artículos o por la
prestación de un servicio. Los gastos constituyen sacrificios o expiración de Activos, cuando éstos
acaban, sus totales y el patrimonio disminuyen.
107
IDE: un IDE en inglés, Integrated Development Environment es un entorno de programación que ha
sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un
compilador, un depurador y un constructor de interfaz gráfica.
JSON: acrónimo de "JavaScript Object Notation", es un formato ligero para el intercambio de datos.
JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML.
Libro mayor: el Libro mayor constituye un documento obligatorio que debe llevar toda organización, y
en él se agrupan todas las cuentas de Activo, Pasivo, Capital, Ingresos y Gastos. En este libro se hace
un resumen de todas las afectaciones que han tenido cada una de las cuentas, como resultado de las
operaciones de la empresa durante el período contable, estas operaciones han sido previamente
registradas en el Libro Diario y a partir de éste es que se elabora el Libro mayor.
Libro submayor: su objetivo es analizar las subcuentas y análisis de las cuentas que lo requieran
excepto aquellas que son analizadas en Submayores específicos en el resto de los Módulos del sistema,
con la finalidad de obtener todos y cada uno de sus saldos, con vista al cuadre mensual con las cuentas
control del Mayor.
108
O
ORM: El mapeo objeto-relacional u Object Relational Mapping es una técnica de programación para
convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y
el utilizado en una base de datos relacional.
Pasivos: son las fuentes de financiamiento, para llevar a cabo las operaciones es decir son las
obligaciones que tiene la empresa con terceros. Es la clasificación de los recursos de la empresa con
respecto a su procedencia, que pueden ser aportaciones de capital por parte de los propietarios,
recursos ganados por la empresa en su actividad mercantil, o utilización de recursos de terceros que
pueden ser a corto o largo plazo.
Sociedad mercantil: Persona jurídica que se dedica a realizar actos de comercio, con domicilio en el
extranjero. De existir algún domicilio en el territorio nacional, se convertiría en una Sucursal.
Tasa de cambio: la tasa de cambio de un país, es el valor de cada moneda nacional comparada con
una moneda internacional, se puede definir también como el poder de compra de una moneda respecto
al poder de compra de otra medida en términos monetarios.
XML: por sus siglas en inglés de Extensible Markup Language, es un metalenguaje extensible de
etiquetas que permite definir la gramática de lenguajes específicos.
109