pulse aquí

º
CEDRUX. Solución para sistemas de control
logístico.
1 Ing.
Virgen Damaris Quevedo Campins, 1Msc. Meylin Martínez Chong, 2Ing. Tte Lester Antonio González Gutierrez,
2 Ing. Alien Fernández Fuentes.
Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Boyeros, Ciudad de La Habana,
Cuba.
e-mail: [email protected], [email protected], [email protected], [email protected].
RESUMEN. La Planeación de Recursos Empresariales
(Enterprise Resource Planning, ERP) es un sistema
compuesto por un conjunto de módulos funcionales
estándar y que son susceptibles de ser adaptados a las
necesidades de cada empresa. Estos sistemas integran la
información de todas las áreas de la empresa como
Logística,
Planificación,
Recursos
Humanos,
Contabilidad…, etc. Con el uso de los ERP se gana en
comunicación, organización, adaptabilidad, integración,
control sobre los procesos organizacionales, desarrollo, en
fin, es una mejora sustancial para el funcionamiento de
cualquier entidad y/o empresa. En nuestro país no se
contaba con un sistema ERP completo que integrara todos
los módulos necesarios (hasta el momento se utilizaba el
Versat Sarasola que tenía entre otras deficiencias el ser
una aplicación de escritorio). Para dar respuesta a esta
necesidad, la UCI junto a otras organizaciones del país, se
dio a la tarea de desarrollar un sistema completo, ha
venido trabajando en el desarrollo del Sistema Integral de
Gestión Empresarial Cedrux, más conocido por ERP
cubano. Como parte de esta solución aparecen varios
sistemas integrados:
Configuración, Contabilidad,
Planificación, Recursos Humanos y Logística. Esta última
encargada del control de los medios materiales
(Inventario), de los activos fijos tangibles y la facturación.
Estos procesos conforman subsistemas que aunque
presentan
negocios
diferentes,
también
poseen
características comunes indispensables para su correcto
funcionamiento. Con el objetivo de lograr que estos
subsistemas pudiesen funcionar aislados pero manteniendo
todas las funcionalidades se crearon componentes comunes
para ellos, los cuales además tienen la responsabilidad de
lograr la integración con otros subsistemas externos y
constituyen el eje principal del sistema Logístico de
Cedrux. Esto posibilita que los clientes puedan escoger si
desean trabajar con todos los subsistemas de Logística o
sólo con algunos sin tener que obtener el paquete completo
y un avance significativo en la calidad, rapidez y
seguridad en la previsión, seguimiento y control de los
procesos antes mencionados.
Palabras Claves. Planeación de Recursos Empresariales,
módulos, sistema, solución, logística.
CEDRUX. LOGISTIC CONTROL SYSTEM
SOLUTION.
ABSTRACT. The Planeación of Managerial Resources is a
compound system for a standard group of functional modules
and that they are susceptible of being adapted to the necessities
of each company. These systems integrate the information of all
the areas of the company like Logistics, Planning, Human
resources, Accounting…, etc. With the use of the ERP is won in
communication, organization, adaptability, integration, control
on the organizational processes, I develop, in short, it is a
substantial improvement for the operation of any entity and/or
company. In our country we didn't have a system complete ERP
that integrated all the necessary modules (until the moment the
Versat Sarasola was used that had among other deficiencies the
being a desk application). To resolve this need, the
Informatics Sciences University with other organizations
in the country, has been working in the development of
Integrated Business Management System Cedrux, better
known as Cuban’s ERP.
As part of this solution are more integrated system:
Configuration, Accounting, Planning, Human Resources
and Logistics. The latter was responsible for the control of
material resources (inventory) of tangible fixed assets and
turnover. These processes comprise subsystems that have
different business but also have common features essential
for proper operation. With the goal of these subsystems
could operate in isolation while maintaining all the
features common components were created for them,
which also have the responsibility to achieve integration
with other external subsystems and constitute the
backbone of the system Cedrux’s Logistics.
This allows customers to choose whether they want to
work with all the logistics subsystems or only some without
INTRODUCCIÓN
En estos tiempos el ambiente competitivo del mundo
empresarial se ha incrementado indudablemente, debido a
que las entidades requieren promover procesos y entidades de
negocio que brinden ventajas ante la competencia o que
simplemente proporcionen ahorro y eficiencia económica.
Hoy más que nunca se hace necesaria la utilización de
herramientas que proporcionen un mejor control y
centralización de la información con el fin de tomar las
mejores decisiones para los procesos y estrategias del negocio.
En el mundo cada día toma mayor fuerza el empleo de
sistemas para la planificación de recursos empresariales
(ERP) por las múltiples ventajas que brinda, siendo
reconocido el papel que desempeñan en el fortalecimiento de
las relaciones intra empresariales y la eficiencia interna de las
organizaciones que los utilizan. Cuba, incluso estando
bloqueada económicamente por la potencia más grande del
mundo, ha derivado en grandes esfuerzos para la
informatización de la sociedad.
La dirección de nuestro país, como parte del fortalecimiento
de la gestión de las entidades y la informatización de la
sociedad cubana, ha venido planteado la necesidad de
informatizar los procesos de gestión de las entidades
presupuestadas y empresariales a escala nacional utilizando
plataformas más confiables, eficientes y basadas sobre
plataformas libres.
Esta decisión ha estado influenciada por la necesidad de una
comunicación acertada entre los diferentes departamentos de
las entidades que permita dar respuestas coordinadas; la
insuficiente gestión de los procesos, así como de los cambios
y mejoras que estos pueden presentar; la escasez de un
adecuado intercambio de información y contenidos por todos
los agentes implicados en un canal logístico, desde las
materias primas hasta los productos terminados; y la urgencia
de mejorar en el país la eficiencia y los niveles de
productividad con una reducción de los costes y manteniendo
un acertado seguimiento, previsión y control de los procesos
en todas las áreas de la empresa. Este escenario marcó el
surgimiento del Sistema Integral de Gestión Empresarial
Cedrux, concebido en su proyección inicial como un paquete
de soluciones integrales de gestión, basado en los principios
de independencia tecnológica y en la inclusión de las
funcionalidades generales presentes en los procesos de la
economía cubana .
Cedrux, conocido también como ERP cubano, cuenta con la
atención directa de varios Organismos de la Administración
Central del Estado (OACE), y en su desarrollo participa un
CCIA’2010 2
having to obtain the complete package, and a significant
advance in the quality, speed and security in forecasting,
monitoring and control of the above processes.
Enterprise Resource Planning, modules,
system, solution, logistic.
Key words:
equipo multidisciplinario compuesto por especialistas de
diferentes entidades del país y la Universidad de las Ciencias
Informáticas, quienes a partir del análisis realizado sobre las
necesidades básicas para las empresas cubanas,
los
requerimientos
gubernamentales
pertinentes
y las
funcionalidades presentes en sistemas similares a nivel
mundial, determinaron desarrollar en una primera etapa un
completo rango de funcionalidades de varias áreas de las
existentes en las empresas, entre las que destacan:
Contabilidad General, Costos y Procesos, Capital Humano,
Planificación Financiera y Logística, construida dentro de una
sola plataforma de negocios.
Dentro de esta última se pueden definir procesos de vital
importancia en el correcto funcionamiento de una entidad, se
hace referencia a los procesos de registro y control de los
medios materiales, al control de los activos fijos (medios en
explotación) y al proceso de facturación, las cuáles
constituyen el objeto de análisis de este trabajo.
No obstante de existir en Cuba productos que lograban
integrar diferentes funciones del área económica, entre las
que se encuentran las mencionadas con anterioridad, éstos no
satisfacían las demandas de los organismos cubanos.
Generalmente estos productos están enfocados a un sector
específico o se han desarrollado para funcionar según las
características de otra economía, como la europea. Además de
las limitaciones que constituye el elevado precio de un
producto extranjero, está la dependencia que se crea a un
suministrador externo, en quienes se seguiría invirtiendo
hasta lograr adaptar el Sistema a las necesidades de la
economía cubana, aún cuando estos sean productos de
reconocido prestigio internacionalmente.
Por otra parte, los productos cubanos de este tipo, no han
logrado integrar todas las áreas de la gestión económica, lo
que ha influido en la calidad con que se llevan a cabo los
procesos en las entidades cubanas, además de limitar el
intercambio eficiente de información entre las diferentes
áreas. Se debe añadir el inconveniente que representa la
ausencia de un adecuado sistema de soporte, así como las
restricciones causadas por la vejez de las tecnologías
utilizadas.
Debe destacarse además, la dificultad que constituye para la
calidad y rapidez con que se realizan estos procesos, el hecho
de que en la mayoría de las entidades se realicen de forma
manual, y se necesite de mucho tiempo y coordinación para el
traspaso de los documentos oficiales de un área a otra de la
empresa y entre empresas. Esto también provoca errores
sistemáticos en los datos ofrecidos, ya sea por un mal control
en las entidades o a la propia naturaleza humana. El hecho de
CCIA’2010
la realización manual de estos procesos ha incidido altamente
en manifestaciones de corrupción en los niveles de dirección
intermedia del sector empresarial, todo esto condicionado por
la falta de mecanismos eficientes de control interno en las
empresas.
Si bien el sistema Cedrux significa un paso de avance
importante, debe tenerse en cuenta para que las soluciones a
los procesos de control de inventario, activos fijos tangibles y
facturación, presentes este sistema funcionen de forma tal que
satisfagan todas las necesidades detectadas, se hace necesario
una solución técnica que sobrepasa la propia realización de
estos procesos. Estos procesos conforman subsistemas que
aunque presentan negocios diferentes, también poseen
características comunes indispensables para su correcto
funcionamiento. Estos subsistemas deben funcionar aislados
pero manteniendo todas las funcionalidades, además de lograr
la integración con otros subsistemas externos.
Esto posibilitaría que los clientes puedan escoger si desean
trabajar con todos los subsistemas de Logística o sólo con
algunos sin tener que obtener el paquete completo y un
avance significativo en la calidad, rapidez y seguridad en la
previsión, seguimiento y control de los procesos antes
mencionados.
Surge así el siguiente problema a resolver: ¿Cómo obtener un
sistema de control logístico (inventario, facturación, activos
fijos tangibles) como soluciones independientes manteniendo
una integración entre ellos y a su vez con los demás procesos
de gestión empresarial?
Para resolver el problema se trazó como objetivo principal:
Desarrollar componentes comunes que permitan la
integración entre los subsistemas del sistema Logística de
Cedrux y con otros subsistemas externos y permitan un
avance significativo en la calidad, rapidez y seguridad en la
previsión, seguimiento y control de los procesos de
inventario, facturación y activos fijos tangibles.
DESARROLLO
Un usuario hace una solicitud mediante un evento del
navegador en un formulario JS, este envía una notificación a
la clase controladora, mediante JSON o Atributos. Esta setea
entidades y se comunica con la clase gestora Bussines
responsable de la petición, la cual ha debido instanciar. La
gestora o Bussines es la encargada de la lógica propia del
negocio, cálculos y procesamiento de negocio, y también
puede comunicarse con la Doctrine Domain. Esta última se
conecta mediante PDO (Doctrine Record) a la DBO (Capa
interna de doctrine basada en PDO nativo), y esta DBO es la
que se conecta directamente a la base de datos.
El paquete de Servicios incluye todas las funcionalidades
contenidas en los paquetes de Controladoras, Modelo, y
Validaciones. Para solicitar un servicio que está en otro
3
dominio, se accede a través del paquete de Servicios, quien
analizará la solicitud e irá al IoC (Componentes gestor de
servicios), el cual re direccionará la petición al paquete
Servicios que contiene la clase que debe proporcionar la
funcionalidad (esta debe acceder a la Clase que implementa la
funcionalidad, la cual ha instanciado previamente) y la
devolverá a Servicios que a su vez se la entregara al dominio
solicitante. Además este paquete de Servicios también tiene lo
denominado “Lógica adicional” que consiste en que cuando
se conciba una solicitud que no esté implementada como tal,
pero que necesita de los parámetros que tienen los paquetes
mencionados, se implementa esa solicitud en este paquete
(Servicios) y devuelve el resultado al servicio solicitante.
Estrategias de Integración
La aplicación está especificada por tres capas: capa de
Presentación (View), Negocio (Controller) y Acceso a Datos
(Models). La integración vertical consiste en el flujo de los
datos desde la vista hacia la capa de datos y viceversa,
pasando por los diferentes elementos que componen la
arquitectura. Esta consta de cuatros nodos de integración, el
que se encuentra entre la vista y el controlador, el que está
entre el controlador y el modelo, el que vincula el modelo con
el Framework Doctrine y el que se encuentra entre el Doctrine
y la Base de Datos. Todo el código dentro un mismo
componente utiliza llamadas a métodos o eventos de forma
directa.
Cada componente tiene su registro de los datos de los
módulos en un fichero XML que será mapeado por el
Framework para el funcionamiento del mismo, dicho fichero
tiene por nombre IoC y registra las funcionalidades que
ofrecen los métodos de las clases control de los componentes
del sistema. El IoC especifica respuestas deseadas a sucesos o
solicitudes de datos concretas, dejando que otro módulo o
componente lleve a cabo las acciones de control que se
requieran en el orden necesario y para el conjunto de sucesos
que tengan que ocurrir. La base de datos es accedida de forma
directa mediante controladoras y los componentes rehusados
son integrados mediantes interfaces sencillas, garantizando
así una total integración de las capas en el sistema. (Ver
Figura 1).
CCIA’2010
4
Las clases que se encuentran dentro de Domain el nombre
que reciben es el de la tabla en la Base de Datos.
Ejemplo: Factura
 Generated (Dominio bases)
Las clases que se encuentran dentro de Generated el nombre
comienza con la palabra: “Base” y seguido el nombre de la
tabla en la Base de Datos.
Ejemplo: BaseFactura
3. Clases del Framework
Ilustración 1. Integración entre las capas del sistema
Estándares de código
Los estándares de codificación son pautas de programación
que no están enfocadas a la lógica del programa, sino a su
estructura y apariencia física para facilitar la lectura,
comprensión y mantenimiento del código. La Línea de
Arquitectura emitió las Normas y Estándares de Codificación,
este documento constituye una guía para el desarrollo en las
líneas de producción, desde el punto de vista arquitectónico,
con el propósito de lograr una estandarización del código.
Los estándares de codificación en el marco del ERP van a
permitir una mejor integración entre las líneas de producción
y se establecerán las pautas que conlleven a lograr un código
más legible y reutilizable, de tal forma que se pueda aumenta
su mantenibilidad a lo largo del tiempo.
Nomenclatura de las clases
Los nombres de las clases comienzan con la primera letra en
mayúscula y el resto en minúscula, en caso de que sea un
nombre compuesto se empleará notación PascalCasing (Los
identificadores y nombres de variables, métodos y funciones
están compuestos por múltiples palabras juntas, iniciando
cada palabra con letra mayúscula).
Ejemplo: Gestfacturacion
Nomenclatura según el tipo de clases
1. Clases controladoras
Las clases controladoras después del nombre llevan la
palabra:”Controller”.
Ejemplo: GestfacturacionController
2. Clases de los modelos
 Business (Negocio)
Las clases que se encuentran dentro de Business después del
nombre llevan la palabra: “Model”.
Ejemplo: GestfacturacionModel
 Domain (Dominio)
Como parte del marco de desarrollo de Zend existe el
Zend_Loader (Cargador) que, amen del cumplimiento de
ciertas normas para la nomenclatura de las clases garantiza
que, a partir de una ruta de inclusión, éste sea el responsable
de la inclusión de los recursos requeridos en el proceso.
Ejemplo: Los nombres de las clases contienen la dirección
donde se encuentran, de la siguiente forma, si tenemos una
clase llamada Factura en la siguiente estructura
ERP/Logística/Facturación/Factura.php
entonces
un
identificador
de
la
misma
debe
ser
ERP_Logística_Facturación_Factura lo que garantiza que a
través de una casuística particular el cargador localice estos
recursos.
Nomenclatura de las funciones
El nombre a emplear para las funciones se escribe con la
primera palabra en minúscula, en caso de que sea un nombre
compuesto se empleará notación CamelCasing (Es parecido al
PascalCasing con la excepción que la letra inicial del
identificador debe estar en minúscula), y con sólo leerlo se
reconoce el propósito de la misma.
Ejemplo: adicionarFactura
En caso de ser una acción de la clase controladora se le pone
el nombre y seguida la palabra:”Action”
Ejemplo: adicionarFacturaAction
Nomenclatura de las variables
El nombre a emplear para las variables se escribe con la
primera palabra en minúscula, en caso de que sea un nombre
compuesto se empleará notación CamelCasing,
y
comenzando con un prefijo según el tipo de datos.
Ejemplo: arrFactura
Prefijos para los tipos de datos
Los prefijos a utilizar en la creación de variables serán los
siguientes:
Tabla 1. Prefijos de las Variables
Tipos de Datos
Prefijos
CCIA’2010
Arreglos
arr
Cadena
str
Objetos
obj
float
flt
Enteros
int
Boolean
Boo
Nomenclatura de las constantes
El nombre a emplear para las constantes se escribe con todas
las letras en mayúscula.
Ejemplo: FACTURA.
Nomenclatura de los atributos
El nombre a emplear para los atributos se escribe con la
primera palabra en minúscula, en caso de que sea un nombre
compuesto se empleará notación CamelCasing. Además en
caso de ser un objeto se comienza con:”_” y después se
escribe el nombre.
Ejemplo: arrFactura=facturada
objFactura=_ facturada
Tratamiento de Errores
Para garantizar el correcto funcionamiento del sistema se
debe tener en cuenta un tratamiento de errores, el sistema
captura todas aquellas excepciones que son lanzadas y se le
facilita un tratamiento para que el sistema no colapse.
De esta manera se da solución a las problemáticas de los
lanzamientos de excepciones que se dan en el sistema según
las peticiones del usuario, capturando los tipos de errores
lanzados y mostrando de manera visible al usuario mensajes
de confirmación, esto le dará una idea de qué es lo que está
incorrecto y como solucionarlo.
Mediante la interfaz Web se impedirá que el usuario asuma
un papel activo en la introducción de la información, para
esto se contará con cuadros de opción, menú de selección, lo
cual facilitará la entrada de datos. La información que
requiera ser adicionada por el usuario se validará mediante
funciones o expresiones regulares que garanticen que sea
válida y que el cuadro de texto no esté vacío si es obligatorio
llenarlo. Si hay un error en la información le saldrá al usuario
un mensaje en pantalla indicándole el error, al oprimir
Aceptar el mensaje desaparece y el usuario podrá seguir
introduciendo los datos en el formulario. También se
validarán las opciones correspondientes a la extracción o
modificación de datos del servidor de base datos. Si se desea
eliminar algún elemento de la BD se preguntará al usuario si
está seguro de realizar dicha acción, al igual que cuando
desee modificar alguna información, antes de actualizarla se
le preguntará si desea realizarla o no.
5
En el sistema existen funciones que necesitan validaciones
previas para que se ejecuten sin ningún problema, para estas
validaciones se usan varios ficheros XML entre ellos el
validator, el cual contiene las llamadas a las precondiciones y
poscondiciones que deben cumplirse, igualmente esta el
fichero exception el cual contiene los mensajes que serán
mostrador según la excepción lanzada, otro de los ficheros
XML es el ManageException el cual captura excepciones
previas que definimos ya sean para excepciones del Doctrine
o del Framework. Así se logra que se realicen las operaciones
que se desean y que se rectifique al cometer un error.
IoC
IoC es un concepto junto a unas técnicas de programación
en las que el flujo de ejecución de un programa se invierte
respecto a los métodos de programación tradicionales, en
los que la interacción se expresa de forma imperativa
haciendo llamadas a procedimientos (procedure calls) o
funciones. Tradicionalmente el programador especifica la
secuencia de decisiones y procedimientos que pueden darse
durante el ciclo de vida de un programa mediante llamadas
a funciones. En su lugar, en la inversión de control se
especifican respuestas deseadas a sucesos o solicitudes de
datos concretas, dejando que algún tipo de entidad o
arquitectura externa lleve a cabo las acciones de control que
se requieran en el orden necesario y para el conjunto de
sucesos que tengan que ocurrir.
El flujo habitual se da cuando es el código del usuario quien
invoca a un procedimiento de una librería. La inversión de
control sucede cuando es la librería la que invoca el código
del usuario. Típicamente sucede cuando la librería es la que
implementa las estructuras de alto nivel y es el código del
usuario el que implementa las tareas de bajo nivel.
El IoC permite la integración entre componentes y
subsistemas. La inversión de control se hace necesaria para
gestionar las dependencias entre subsistemas y el framework.
Arquitectura.
La Arquitectura del Software es el diseño de más alto nivel de
la estructura de un sistema, programa o aplicación y tiene la
responsabilidad de:
 Definir los módulos principales.
 Definir las responsabilidades que tendrá cada uno de
estos módulos.
CCIA’2010
 Definir la interacción que existirá entre dichos
módulos.
 Control y flujo de datos.
 Secuenciación de la información.
 Protocolos de interacción y comunicación.
 Ubicación en el hardware.
El objetivo principal de la Arquitectura del Software es
aportar elementos que ayuden a la toma de decisiones y, al
mismo tiempo, proporcionar conceptos y un lenguaje común
que permitan la comunicación entre los equipos que
participen en un proyecto. En el desarrollo del sistema se
utilizaron las siguientes:
Cliente-Servidor
La arquitectura cliente/servidor es un modelo para el
desarrollo de sistemas de información en el que las
transacciones se dividen en procesos independientes que
cooperan entre sí para intercambiar información, servicios o
recursos. Se denomina cliente al proceso que inicia el diálogo
o solicita los recursos y servidor al proceso que responde a las
solicitudes.
En este modelo las aplicaciones se dividen de forma que el
servidor contiene la parte que debe ser compartida por varios
usuarios, y en el cliente permanece sólo lo particular de cada
usuario.
Entre las principales características de esta arquitectura se
pueden destacar las siguientes:
 El servidor presenta a todos sus clientes una interfaz
única y bien definida.
 El cliente no necesita conocer la lógica del servidor,
sólo su interfaz externa.
 El cliente no depende de la ubicación física del
servidor, ni del tipo de equipo físico en el que se
encuentra, ni de su sistema operativo.
 Los cambios en el servidor implican pocos o ningún
cambio en el cliente. (López, y otros, 2007)
Modelo-Vista-Controlador
Modelo Vista Controlador (MVC) es un patrón de
arquitectura de software que separa los datos de una
aplicación, la interfaz de usuario, y la lógica de control en
tres componentes distintos. El patrón MVC se ve
frecuentemente en aplicaciones web, donde la vista es la
página HTML y el código que provee de datos dinámicos a la
página. (Edgarin, 2006)
 Modelo: Esta es la representación específica del
dominio de la información sobre la cual funciona la
aplicación. El modelo es otra forma de llamar a la
capa de dominio. La lógica de dominio añade
significado a los datos; por ejemplo, calculando si
hoy es el cumpleaños del usuario o los totales,
impuestos o portes en un carrito de la compra.
 Vista: Este presenta el modelo en un formato
adecuado para interactuar, usualmente un elemento
de interfaz de usuario.
6
 Controlador: Este responde a eventos, usualmente
acciones del usuario e invoca cambios en el modelo y
probablemente en la vista.
Según (Welicki, 2009) algunos de sus principales beneficios
son:
 Menor acoplamiento.
 Mayor cohesión.
 Las vistas proveen mayor flexibilidad y agilidad.
 Mayor facilidad para el desarrollo de clientes ricos en
múltiples dispositivos y canales.
 Más claridad de diseño.
 Facilita el mantenimiento.
 Mayor escalabilidad.
Arquitectura
En el desarrollo del sistema se utilizaron las siguientes
arquitecturas: Cliente-Servidor dado que las transacciones se
dividen en procesos independientes que cooperan entre sí
para intercambiar información, servicios o recursos; y
Modelo-Vista-Controlador para separar los datos de una
aplicación, la interfaz de usuario, y la lógica de control en
tres componentes distintos. Los lenguajes utilizados se
relacionan a continuación: PHP, XML, HTML, XHTML y
JavaScript. Fue utilizado UML como lenguaje para visualizar,
especificar, construir y documentar los artefactos del sistema.
Para el desarrollo fueron utilizadas otras tecnologías como:
JSON como formato ligero de intercambio de datos; Css
(Cascading Style Sheets,) ,formato usado en las páginas web
para dar estilo a documentos HTML y XML, separando el
contenido de la presentación; AJAX para crear aplicaciones
interactivas mediante la combinación de tres tecnologías ya
existentes: HTML, CSS, Document Object Model (DOM),
JavaScript, XML y XSLT; PostgreSQL para extraer y
almacenar información de la base de datos; PGAdmin III
como aplicación gráfica para gestionar el gestor de bases de
datos PostgreSQL; Wamp 5 como servidor web; Mozilla
Firefox como navegador web; Notepad++ como editor de
código fuente; Zend Studio como IDE para el desarrollo de
aplicaciones Web; Subversion como sistema de control de
versiones y TortoiseSVN como cliente; Visual Paradigm
como herramienta de modelado que utiliza “UML”: como
lenguaje de modelaje; Zend Framework para desarrollo de
aplicaciones Web y servicios Web con PHP; ExtJS utilizado
en el desarrollo de aplicaciones Web con AJAX; Doctrine
como sistema ORM (object relational mapper) para PHP 5.2+
que tiene un DBAL (database abstraction layer) incorporado;
UCID Framework que abarca la integración del Framework
ExtJs con el sistema incluyendo el integrador de interfaz, el
generador de interfaz dinámica y la
impresión de
documentos, integra la iconografía, los diferentes temas de
escritorio de la aplicación, el multilenguaje; IoC para la
integración entre componentes y subsistemas, la inversión de
control se hace necesaria para gestionar las dependencias
entre subsistemas y el framework.
Características básicas del proyecto
CCIA’2010
Se consideran funcionalidades generales:
Desde el punto de vista funcional:
1.
2.
3.
4.
5.
6.
Multimoneda
Doble moneda
Multientidades
Control de fechas
Transaccional
Tratamiento Estadístico de la información procesada
Desde el punto de vista técnico:
7.
8.
9.
10.
Independencia Tecnológica
Multiusuario y trabajo en red
Plataforma Web
Interoperabilidad con otros sistemas
Módulo Inventario
1. Nomenclador propio (productos, almacenes,
depósitos, pañoles)
2. Métodos de valoración de los inventarios
3. Control de Inventario (Entrada, salida, existencia,
mínimos, máximos, reaprovisionamiento, reserva)
4. Control de herramientas y útiles. En almacén y en
Uso. Método de desgaste.
5. Tratamiento de las Reservas movilizativas y estatales
6. Tratamiento de los recargos y descuentos.
7. Tomas físicas parciales y totales. Tratamiento de las
diferencias
8. Tratamiento de los aranceles y tasas aduanales no
incluidos en la factura del producto.
9. Gestión de fechas
10. Submayores específicos
11. Emisión de comprobantes al módulo de Contabilidad
y registro del devengado presupuestario
12. Informes específicos de inventarios
Módulo Facturación
1. Nomenclador propio
2. Gestión de la facturación (Formato libre y formato
obligatorio, posibilidad de configuración de la
impresión).
3. Contratación Económica y los plazos y formas de
pagos.
4. Gestión de fechas
5. Submayores específicos
6. Emisión de comprobantes al módulo de Contabilidad
7. Informes específicos
Módulo Activos Fijos Tangibles e Intangibles
1. Nomenclador Grupos y Subgrupos
2. Gestión de Activos Fijos Tangibles (movimientos,
reparaciones capitales y control, almacenados y en
explotación)
3. Tratamiento de los aranceles y tasas aduanales no
incluidas en la factura del producto.
4. Gestión de módulos homogéneos y heterogéneos
5. Métodos de depreciación
6. Registro de depreciación
7.
8.
9.
10.
11.
12.
13.
14.
7
Avalúos y revalorizaciones de activos
Tomas físicas parciales y totales. Tratamiento de las
diferencias
Gestión de Activos Fijos Intangibles
Métodos de amortización
Gestión de fechas
Submayores específicos
Emisión de comprobantes al módulo de Contabilidad
y registro del devengado presupuestario.
Informes específicos
Entorno de usuario
En las entidades que utilicen la solución, se vincularán a la
solución los especialistas relacionados con los procesos
Contables Financieros y de Recursos Humanos. Con la
utilización de la solución, los especialistas comprobaran una
mejora sustancial en la eficiencia y control de las actividades
que actualmente desempeñan, a través de la informatización
de la mayoría de sus actividades, disponiendo de este modo de
más tiempo para el análisis y la planificación de las
actividades estratégicas de la entidad.
A los usuarios se les proveerá una completa y moderna
plataforma de aplicaciones Web, la cual será fácilmente
accesible desde cualquier puesto de trabajo, evitando de este
modo la limitantes de las aplicaciones de escritorio y además
se disminuirán los ciclos de reposición de equipamiento
informático por este concepto. La rotura de una estación no
afectará el trabajo, pues con el uso de la tecnología Web
podrán continuar desarrollando su labor sin que esto implique
pérdida parcial o total de su trabajo. Además, esta plataforma
estará preparada para el trabajo orientado a servicios, creando
las condiciones necesarias para la inclusión de nuevos
módulos y la conexión a otras aplicaciones existentes en la
entidad, brindando de esta forma una altísima adaptabilidad a
las nuevas condiciones y cambios que ocurran en las
entidades.
A través de la vinculación directa de los especialistas
representantes de órganos y organismos del Estado al equipo
de desarrollo se logrará la actualización constante de las
funcionalidades bases de la solución a partir de las
regulaciones del gobierno. Esto brindará un importante valor
añadido a las entidades que la implanten.
CCIA’2010
8
Datos en DQL y no en SQL, puesto que este último presenta
una alta probabilidad de sufrir inyecciones de código.
IoC
Paquete Útiles:
Gestión de Cuentas: Es el componente encargado de mostrar
las cuentas controladas por el subsistema.
Gestión de Áreas
Gestión de Ubicación
Gestión de Depósitos
Gestión de Clientes: Es el componente encargado de mostrar
los clientes-proveedores de la entidad empresarial o
presupuestada con la cual se esté trabajando.
Gestión de Cierre: Permite la gestión del cierre contable,
diario, por período o por ejercicio, en cualquier caso
consolida las cifras y los históricos, preparando al sistema
para una nueva etapa.
Registro Numérico
Paquete Estructura:
Documento General: Es el componente encargado de toda la
gestión de los documentos.
Paquete Común:
Se encuentran componentes que son utilizados por los
subsistemas de Logística con la particularidad de que no
presentan interfaz gráfica.
Común:
Gestionar Bloqueo: Es el componente encargado de bloquear
los documentos que estén siendo utilizados y desbloquearlos
cuando se terminen de utilizar.
Comprobante de Operaciones: Permite la contabilización de
los documentos, es decir, la confección de los comprobantes
de operaciones de los movimientos y su traslado al subsistema
de contabilidad, permitiendo realizar un comprobante para
los documentos que se deseen, dependiendo del tipo de venta
establecida por la entidad. En el caso de los movimientos de
las facturas se pasan los lotes posteados al subsistema de
cobros y pagos para la actualización de los saldos de los
clientes.
AutoLoadPath: Este componente garantiza una optimización
de la integración entre los componentes de todos los
componentes del sistema Logística y de estos con los
externos, permitiendo además una mayor seguridad al
realizarse la comunicación entre ellos. En él se define con
quien se va a relacionar cada componente de manera que en
el momento de la ejecución de la petición de servicio a otro
componente a través del IoC, se permite el acceso solo si está
definido y se incluye dinámicamente este permiso en el
fichero de configuración de acceso Config.php y solamente
mientras se ejecuta la petición. Esto evita que el fichero
Config.php esté cargado estáticamente con el acceso a todos
los componentes y que cada vez que se haga una petición se
permita el acceso a todos los componentes, sin dejar de
cumplir con el requerimiento de poder realizar los innerjoin
entre diferentes componentes en las consultas de Base de
Subsistemas de Logística
Inventario
Facturación
Activos Fijos Tangibles
Servicios
Sistemas externos
El sistema Cedrux, está dividido en varios sistemas en su
primera fase, con 4 de ellos presenta integración los
subsistemas de Logística en su primera versión:
Configuración: Se obtienen los formatos establecidos para los
nomencladores de producto, servicio y activos fijos tangibles y
la estructura de los almacenes, la fecha (contable o de
sistema), la moneda contable y alternativa para el trabajo con
la dualidad monetaria, así como todas las establecidas para la
entidad, los clientes y proveedores y las reglas contables
(documentos y operaciones) con la cual trabajará el
subsistema.
Seguridad: Se obtienen los datos del usuario logueado.
Estructura y Composición: Se obtiene la entidad
(presupuestada o empresarial) y los depósitos u almacenes
(estructuras no formales) asociados a la misma.
Contabilidad: Cuentas controladas por el subsistema.
Generación y registro del comprobante de operaciones.
Establecer las obligaciones de pago y derechos de cobro.
Conclusiones
Se caracterizó el proceso de facturación en una entidad lo que
permitió obtener una idea acertada sobre los aspectos
esenciales que debían tenerse en consideración. Se
caracterizaron además, los sistemas nacionales e
internacionales en explotación en Cuba que cuentan con
subsistemas de facturación, concluyéndose que no existía en
CCIA’2010
el país un sistema integrado de facturación que permitiese
gestionar las facturas y ofertas en las entidades, y que
cumpliera con la normativa del país de desarrollo de
soluciones bajo el principio de independencia tecnológica. Se
realizó un estudio de las tecnologías, lenguajes y
herramientas propuestas para el desarrollo de la aplicación
con lo que se adquirieron conocimientos necesarios para
cumplir el objetivo del trabajo. Se implementó un sistema
integrado que permite gestionar las facturas y ofertas en
cualquier entidad del país. Fueron aplicadas pruebas de
unidad a los componentes obtenidos, con las cuales se
comprobó el comportamiento interno del programa lo que
permitió detectar errores y erradicarlos, además se verificó
que los flujos de control y de datos estaban cubiertos. Fue
evaluada la implementación a través de métricas, las que
arrojaron un resultado positivo, pues de los 8 atributos de
calidad evaluados 6 tuvieron un 100% de cumplimiento, uno
un 75% y otro un 63%.
Recomendaciones
Para próximas iteraciones se hacen las siguientes
recomendaciones:
 Continuar desarrollando los nuevos requisitos que se
detecten.
 Implementar el proceso de facturación para los
Activos Fijos.
9