sistema de gestión y control presupuestario para...
TRANSCRIPT
FACULTAD DE INGENIERIA
ESCUELA DE INGENIERÍA DE SISTEMAS
SISTEMA DE GESTIÓN Y CONTROL PRESUPUESTARIO PARA ORGANISMOS
DESCENTRALIZADOS DEL ÁMBITO PÚBLICO
Leonardo Gruszka Cohen Tutor: Ing. Carlos Perkinson
Caracas, marzo 2003
UNIVERSIDAD
1970
METROPOLITANA
Derecho de autor
Cedo a la Universidad Metropolitana el derecho de reproducir y difundir el
presente trabajo, con las únicas limitaciones que establece la legislación
vigente en materia de derecho de autor.
En la ciudad de Caracas, a los 6 días del mes de marzo del año 2003.
_________________________
Leonardo Gruszka C.
Aprobación
Considero que el Trabajo Final titulado
“SISTEMA DE GESTIÓN Y CONTROL PRESUPUESTARIO PARA
ORGANISMOS DESCENTRALIZADOS DEL ÁMBITO PÚBLICO”
elaborado por el ciudadano
LEONARDO GRUSZKA COHEN
para optar al título de
INGENIERO DE SISTEMAS
reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas de la
Universidad Metropolitana, y tiene méritos suficientes como para ser
sometido a la presentación y evaluación exhaustiva por parte del jurado
examinador que se designe.
En la ciudad de Caracas, a los 6 días del mes de marzo del año 2003.
_________________________
Ing. Carlos Perkinson
Acta de veredicto
Nosotros, los abajo firmantes constituidos como jurado examinador y
reunidos en Caras, el día 11 del mes de marzo del año 2003, con el
propósito de evaluar el Trabajo Final titulado
“SISTEMA DE GESTIÓN Y CONTROL PRESUPUESTARIO PARA
ORGANISMOS DESCENTRALIZADOS DEL ÁMBITO PÚBLICO”
presentado por el ciudadano
LEONARDO GRUSZKA COHEN
para optar al título de
INGENIERO DE SISTEMAS
emitimos el siguiente veredicto
Reprobado ____ Aprobado ____ Notable ____ Sobresaliente ____
Observaciones: ________________________________________________
(firma) (firma) (firma)
________________ ________________ _______________
Susana Romagni Juan Guaita Carlos Perkinson
Agradecimientos
A… Carlos, José y Marianella, por brindarme todo su apoyo y confianza en todo momento. La Teacher, por su paciencia todos estos años y especialmente estos últimos días, por ayudarme a crecer… Al personal que labora en las oficinas de Planificación y Presupuesto del Fondo Nacional de Desarrollo Urbano (FONDUR), por entregarme una parte de su valioso tiempo y ayudarme con la investigación. Beatriz, por estar pendiente siempre y comenzar a ser como una madre para mí. Mami, por ser ejemplo único de perseverancia y enseñarme cada día que uno puede ocuparse de alcanzar tantas metas y al mismo tiempo, estar pendiente de tanta gente….por estar tan pendiente de mí. Papi, por demostrarme tu amor, entregarme tu cariño y enseñarme a disfrutar de la vida como tú solo sabes hacerlo, aprovechando cada latido de tu corazón, aprovechando el mundo que nos rodea. Mis hermanos, por haber aguantado mi ausencia y la falta de momentos compartidos en estos últimos días que estoy en casa…los recuperaremos de alguna forma. Trumpy, por ser fuente de inspiración de vida, por animarme, quererme, sustentarme, entenderme, apoyarme y demostrarme que eres la mujer de mi vida, que nuestras vidas se han unido para siempre…..TE AMO. Todos aquellos que de una u otra manera me ayudaron y apoyaron.
Índice de Contenido
Índice de contenido
Lista de Tablas y Figuras ......................................................................................... III
Resumen......................................................................................................................V
Introducción. ................................................................................................................1
Capítulo I. Tema de la Investigación .......................................................................5
I.1. Planteamiento del problema..........................................................................5
I.2. Objetivos de la investigación .........................................................................6
Capítulo II. Marco teórico..........................................................................................9
II.1. Presupuesto...................................................................................................10
II.2 Categorías Programáticas...........................................................................16
II.3 Fases del proceso presupuestario.............................................................20
II.3.1. Formulación............................................................................................21
II.3.2. Discusión y aprobación ........................................................................24
II.3.3. Ejecución ................................................................................................25
II.3.4. Control .....................................................................................................29
Capítulo III. Desarrollo del Proyecto.....................................................................35
III.1 Levantamiento de Información...............................................................38
III.1.1 Visitas realizadas durante el levantamiento de información .....42
III.1.2 Consulta de material bibliográfico..................................................45
III.2 Análisis de los Requerimientos ..............................................................47
III.3 Diseño detallado del Sistema.................................................................57
III.3.1 Sub-módulo de Formulación...........................................................59
III.3.2 Sub-módulo de Aprobación ............................................................61
III.3.3 Sub-módulo de Ejecución ...............................................................62
III.3.4 Sub-módulo de situaciones extraordinarias .................................64
III.3.5 Diseño de las tablas de Bases de Datos ......................................66
III.4 Codificación del Sistema.........................................................................71
III.5 Pruebas del Sistema................................................................................78
Índice de Contenido
Capítulo IV: Resultados ...........................................................................................81
IV.1 Procesos fundamentales del sistema.......................................................84
IV.1.1. Formular el presupuesto .....................................................................85
IV.1.2. Aprobar la formulación del presupuesto ..........................................90
IV.1.3. Modificar la formulación de un presupuesto aún no aprobado ....93
IV.1.4. Realizar modificaciones extraordinarias ..........................................95
IV.1.5. Ejecutar Compromisos......................................................................100
IV.1.6. Ejecutar Causaciones .......................................................................103
IV.1.7. Ejecutar Pago.....................................................................................105
IV.1.8. Aprobar la ejecución del presupuesto............................................106
IV.2 Reportes generados ..................................................................................109
Capítulo V. Conclusiones y recomendaciones .................................................114
V.1. Conclusiones ...............................................................................................114
V.2. Recomendaciones .....................................................................................117
Referencias Bibliográficas.....................................................................................122
Apéndice A: Casos de uso específicos..............................................................125
Apéndice B. Diagramas de secuencia. ...............................................................131
Apéndice C. Tablas de bases de datos..............................................................134
Lista de Tablas y Figuras
III
Lista de Tablas y Figuras
TABLAS
1. Diferencias entre el presupuesto tradicional y por programas, 15.
2. Casos de aprobación según su nivel, 94.
FIGURAS
1. Desviaciones, causas y acciones correctivas, 32.
2. Ejemplo de control de metas, 33.
3. Fases del Proceso Presupuestario, 34.
4. Influencias de RPM, 36.
5. Diagrama de casos de uso general, 54.
6. Modelo Conceptual, 56.
7. Diagrama de secuencia para la formulación, 60.
8. Diagrama de secuencia para la aprobación, 63.
9. Diagrama de secuencia para la ejecución, 64.
10. Diagrama de secuencia para las situaciones extraordinarias, 66.
11. Diagrama de clases , 69.
12. Relación del usuario con las bases de datos en OneWorldTM, 74.
13. Interrelación entre las ventanas OneWorldTM, 74.
14. Programas de un presupuesto, 86.
15. Asignaciones de un programa específico, 88.
Lista de Tablas y Figuras
IV
16. Asignaciones de un subprograma específico, 89.
17. Asignación de una partida a un programa, 90.
18. Aprobación de una asignación, 92.
19. Modificación de un programa no aprobado, 95.
20. Selección para modificaciones extraordinarias, 97.
21. Realización de una petición extraordinaria, 98.
22. Aprobación de situación extraordinaria, 99.
23. Compromisos de una asignación, 101.
24. Ejecución de un compromiso, 102.
25. Ejecución de una causación, 104.
26. Ejecución del pago, 106.
27. Búsqueda de compromisos para su aprobación , 107.
28. Aprobación de compromisos,108.
Resumen
V
Resumen
“SISTEMA DE GESTIÓN Y CONTROL PRESUPUESTARIO PARA
ORGANISMOS DESCENTRALIZADOS DEL ÁMBITO PÚBLICO”
Autor: Leonardo Gruszka.
Tutor: Ing. Carlos Perkinson.
Caracas, marzo de 2003.
Fundamentándose en la necesidad de contar con un sistema que cumpla con los requerimientos presupuestarios de un organismo descentralizado del ámbito público en Venezuela, se llevó a cabo una investigación exhaustiva que culminó con el diseño y la implementación de una herramienta formada por módulos interrelacionados, adaptados al software ERP de J.D. Edwards. El proyecto se inició con una fase de investigación en la cual se entendieron las bases del problema planteado y la manera como los entes del estado manejan su presupuesto, se investigó sobre las leyes y procesos del presupuesto, así como las bases de la metodología utilizada. Para poder alcanzar los objetivos , se siguieron los pasos de una metodología específica basada en UML. De cada etapa, se obtuvieron resultados representados por diagramas gráficos. La plataforma utilizada para el desarrollo de la herramienta se basó en los ERP de OneWorldTM, de los cuales se aprovecharon sus bondades en cuanto a seguridad y a la utilización del Point & Click para el desarrollo de aplicaciones. El resultado obtenido en este proyecto es una herramienta amigable y funcional, que gestiona el proceso presupuestario de un organismo público en todas sus fases, de forma segura, para permitir el control de los fondos del presupuesto público y que además, cuenta con ventanas sencillas que facilitan la adaptación de los usuarios al sistema.
Introducción
Introducción.
En la actualidad, el uso de la tecnología para manejar sistemas
presupuestarios, es un requerimiento para cualquier empresa que desee
mantenerse en un nivel competitivo. Esto se debe al hecho que existe la
necesidad de lograr el máximo control posible de la utilización de sus fondos.
Especialmente, en los organismos del estado, el control de las cuentas y la
asignación de fondos, toma una mayor importancia, porque el dinero que se
maneja, le corresponde al estado y en consecuencia, a cada uno de sus
ciudadanos.
En el caso de Venezuela, existe un déficit en el mercado de sistemas de
gestión de presupuestos públicos que permitan la adaptación de las leyes
venezolanas, así como los requisitos del organismo. Todo esto lleva a la
necesidad de implantar tecnología avanzada en los organismos del estado,
para evitar en lo posible la malversación de fondos y permitir el control de las
acciones monetarias que un organismo público lleva a cabo. Por esta razón
se requiere ampliar la funcionalidad de los software ERP, los cuales proveen
eficiencia, rapidez y seguridad al momento de desarrollar una tarea
específica. Esta nueva funcionalidad, permite el control y la adaptación
necesaria para llevar a cabo la gestión presupuestaria de forma efectiva y
transparente.
Introducción
2
En este sentido, el objetivo general de este trabajo es diseñar, desarrollar y
documentar un software integrado a un Sistema JDEdwards, que administre
y controle presupuestos basados en las leyes venezolanas de presupuestos
para organizaciones públicas y que esté en capacidad de manejar cualquier
tipo de presupuesto, así como permitir un control en la utilización de éste con
el propósito de permitir la detección y poder prevenir cualquier error o uso
indebido de los recursos de cada organización.
La solución que se plantea y se describe en este trabajo de grado es la de un
sistema basado en los ERP de J.D. Edwards que permita utilizar las
bondades que ofrecen estos ERP y crear aplicaciones útiles, eficaces y
seguras, para la ejecución de toda la gestión presupuestaria en organismos
públicos. Todas las aplicaciones están interrelacionadas, de modo que el
usuario del organismo accede, según sus requerimientos y su cargo
(responsabilidad), al sistema para manejar el presupuesto de su ente de
modo rápido y sencillo.
La herramienta de desarrollo que se utiliza para codificar las aplicaciones
diseñadas en el proyecto es la de “Point & Click” que ofrecen los Tools de
OneWorldTM de J.D. Edwards. Gracias a esta herramienta se logran codificar
las aplicaciones sin salirse de los lineamientos del software utilizado.
Introducción
3
Para poder cumplir con los objetivos y lograr la solución planteada de forma
efectiva y en el tiempo destinado para ello, se precisa llevar a cabo una
investigación exhaustiva sobre los presupuestos públicos en Venezuela y sus
organismos, a través de entrevistas y visitas a algunos entes del gobierno.
Seguido de este paso, se implementa la metodología RPM (Recommended
Process and Models), basada en UML (Unified Modeling Language), la cual
además de cubrir todos los pasos necesarios, permite la distribución de las
tareas y su ejecución de forma dinámica. Una vez finalizados los pasos de la
metodología para modelar el sistema, éste se crea de forma eficiente,
flexible, segura y amigable.
El análisis realizado sobre el sistema J.D. Edwards, se hace para
comprenderlo, de modo que se pueda conocer a fondo: sus estándares, las
pautas para desarrollar software en dicho sistema, la interacción entre el
usuario y el sistema a través de la interfaz y la relación entre los módulos que
lo componen. Esta es una base fundamental del proyecto porque permite la
adaptación del sistema presupuestario desarrollado y la integración con el
software de J.D. Edwards, de forma homogénea.
Una vez completados los pasos de investigación, se pone en práctica el
desarrollo de las aplicaciones planteadas en el diseño. Estas aplicaciones
permiten a los responsables de los presupuestos en los organismos públicos,
formular los programas y subprogramas, así como asignarle las partidas
Introducción
4
correspondientes según lo consideren. Una vez realizada la formulación, el
sistema exige la aprobación de cada etapa del presupuesto, por parte de las
autoridades. Además, se controlan de forma segura y transparente, las fases
de la ejecución presupuestaria, evitando la malversación de fondos. Por
último, el sistema también maneja los casos de modificaciones
extraordinarias en la gestión de un presupuesto aprobado. Esta herramienta
que es el resultado de la investigación, cuenta con controles de seguridad y
alarmas que impiden la malversación de fondos y hacen que el sistema sea
confiable para llevar a cabo las transacciones relacionadas con el tema
presupuestario de un organismo.
El siguiente informe se compone de un capítulo que expone el tema de la
investigación, en el cual se incluye el planteamiento del problema y los
objetivos de la misma. Seguidamente, se encuentra el marco teórico del
trabajo en el cual, se definen los conceptos y la base teórica del tema
presupuestario El desarrollo del proyecto, los pasos seguidos para lograrlo y
el empleo de la metodología, se describen en el capítulo denominado
desarrollo del proyecto. Adicionalmente, se muestran los resultados
obtenidos a través de la explicación que se hace sobre la herramienta
desarrollada. Finalmente, para completar este trabajo de grado, se procede a
redactar las conclusiones y recomendaciones, las cuales son el reflejo del
trabajo ejecutado y justifican su realización.
Capítulo I. TEMA DE LA INVESTIGACIÓN
Capítulo I. Tema de la Investigación
I.1. Planteamiento del problema
El control y la ejecución presupuestaria en el ámbito de los organismos
públicos, se rigen por leyes estrictas que penalizan a aquellos que no las
cumplen. Sin embargo y pese a la importancia y necesidad de establecer
sistemas automatizados para evitar errores u omisiones y garantizar una
gestión adecuada, los sistemas que se encuentran en muchos organismos
se basan en hojas de cálculo o desarrollos propios de dicho organismo, con
los cuales se puede dar el caso en el cual se genere un descontrol que
facilite la utilización indebida de estos recursos y por ende, un deterioro en el
valor y el funcionamiento de la organización. Las estrictas leyes
presupuestarias no pueden ser cumplidas si no existe un sistema capacitado
para gestionar, advertir sobre diversos problemas en la repartición y
utilización de los fondos.
Se presenta un aspecto de alto interés, debido al hecho que hay escasez de
sistemas que sean alto nivel, fácil entendimiento y confiable seguridad, los
cuales se adapten a las necesidades y funciones que realizan los
organismos del estado para su gestión del tema presupuestario. Esta
carencia permite burlar los sistemas e impide el buen funcionamiento de las
Capítulo I. TEMA DE LA INVESTIGACIÓN
6
organizaciones que no estén tecnológicamente capacitadas. También
disminuye la precisión, en cuánto a los resultados y términos del presupuesto
de los organismos. Esto trae como consecuencia la posible merma
descontrolada de dinero, así como pérdida del tiempo por falta de sistemas
que permitan reducirlo.
I.2. Objetivos de la investigación
Tras haber analizado el problema existente, se plantean los objetivos del
trabajo de grado de forma tal, que éstos sean los pilares del desarrollo de la
investigación. En primer lugar se plantea el objetivo general, el cual sugiere
la necesidad de diseñar, desarrollar y documentar un software integrado a un
sistema de J.D. Edwards, que administre y controle presupuestos basados
en las leyes venezolanas de presupuestos para organizaciones públicas y
que esté en capacidad de manejar el presupuesto de un organismo, así
como permitir un control en la utilización de éste, con el propósito de
proporcionar la detección y estar en capacidad de prevenir cualquier error o
uso indebido de los recursos de una organización.
El ambiente de desarrollo es de programación orientada a objetos, mediante
el uso de lenguajes visuales y SQL Server o empleando las herramientas
que provea el fabricante de la solución administrativa contable, para
Capítulo I. TEMA DE LA INVESTIGACIÓN
7
garantizar una presentación y la homogeneidad del desarrollo con la
aplicación a la cual se integra.
Para darle forma al objetivo general del proyecto, se plantean los objetivos
específicos, los cuales cubren los aspectos referentes a este trabajo desde
diferentes puntos de vista.
El investigador debe adquirir conocimientos sobre la gestión presupuestaria
en Venezuela, así como una idea general acerca de las leyes que rigen dicha
gestión. De la misma manera, aprender a emplear una metodología que
permita modelar cualquier sistema en un futuro, en el caso de este proyecto,
aprender a usar UML (Unified Modeling Language), lenguaje que está
orientado a objetos. Es también un objetivo del proyecto comprender y estar
en la capacidad de manejar y desarrollar las herramientas que poseen los
ERP de J.D. Edwards, de manera que se generen aplicaciones claras,
amigables y que funcionen correctamente.
Diseñar un sistema útil y de fácil entendimiento para manejar presupuestos
en Venezuela, es un objetivo de este proyecto. Esto se debe al hecho que se
emplea la metodología utilizada y con ella, se generan los diagramas de
forma explícita para evitar problemas al momento de desarrollar las
aplicaciones.
Capítulo I. TEMA DE LA INVESTIGACIÓN
8
Por último, se debe desarrollar una herramienta que permita manejar las
ramas que abarca la administración de presupuestos, como lo son:
asignación, compromisos, pagos y ejecución del Presupuesto, al nivel de
programas, s ubprogramas, actividades, partidas y subpartidas.
La herramienta a desarrollar debe garantizar el cumplimiento estricto de las
leyes que estén vigentes para manejo de fondos de un presupuesto a través
de un módulo de control, al mismo tiempo permitir flexibilidad ante cualquier
cambio que se haga a una ley. Para cumplir las leyes y evitar la pérdida
indebida de fondos, la herramienta debe estar en capacidad de manejar
alertas de control para detectar quién o cómo se han contravenido las
normas o leyes que rigen la utilización de fondos o recursos del presupuesto.
Adicionalmente, el módulo de seguridad que se desarrolla, debe controlar el
acceso a las diferentes unidades del software, para que las autoridades de
un organismo puedan detectar a cualquier infractor durante la gestión
presupuestaria.
Otra característica de la herramienta debe ser la posibilidad de generar
reportes del uso de los recursos de forma sencilla y a través de una interfaz
útil y amigable.
Capítulo II. MARCO TEÓRICO
Capítulo II. Marco teórico
El presupuesto en Venezuela, su planificación, tratamiento, elaboración y
control se rigen por ciertos conceptos y leyes que deben ser tomados en
cuenta independientemente del tipo de organismo que desea implementar un
presupuesto en un periodo cualquiera.
La teoría presupuestaria de los organismos públicos, se basa en un plan
anual que realiza el organismo y que debe ser aprobado por la Oficina
Nacional de Presupuesto (ONAPRE). Una vez aprobado el presupuesto,
existen varias leyes que rigen la ejecución de ésta, así como varias etapas
que se deben cumplir para poderlo llevar a cabo. Estas etapas están bien
marcadas y tienen asignadas leyes que las rigen.
Para poder entender y analizar estas etapas, se deben conocer primero los
conceptos básicos del presupuesto y en especial, el presupuesto público en
Venezuela.
A través del marco presupuestario, se puede entender la base teórica sobre
la cual se fundamentan las acciones empleadas y los puntos que se
mencionan durante este trabajo. Todo esto, con respecto a aquello que se
refiere al presupuesto y dejando a un lado, lo referente a la parte tecnológica
Capítulo II. MARCO TEÓRICO
10
con la cual se describe la tecnología utilizada para la realización del
proyecto.
En las siguientes secciones se explica con detalle los aspectos conceptuales
y metodológicos del presupuesto público en Venezuela.
II.1. Presupuesto
El presupuesto tiene muchas definiciones. Se refiere a la posibilidad del
gasto, sus limitaciones, la forma como se asignan los fondos y las cifras
esperadas de ingresos, egresos y una ganancia a futuro. Pero esta definición
no abarca la amplitud que representa el presupuesto de una institución.
“El presupuesto se puede considerar como un sis tema mediante el
cual se elabora, aprueba, coordina la ejecución, controla y evalúa la
producción pública (Bien o Servicio) de una institución, sector o región,
en función de las políticas de desarrollo previstas en los Planes”.
(AVPP, 1995, p. 94).
Para poder llevar a cabo el proceso presupuestario, se deben incluir todos
los elementos de la programación, tales como: objetivos, metas, volúmenes
de trabajo, recursos reales y financieros. Esto se hace para justificar y
garantizar el cumplimiento de los objetivos y metas previstas inicialmente por
Capítulo II. MARCO TEÓRICO
11
parte del organismo. El presupuesto representa un excelente instrumento de
gobierno, administración y planificación para cualquier institución que lo
manipule.
Otra definición muy completa sobre presupuesto es la siguiente:
“Instrumento de planificación y control donde se pronostican o preveen
los ingresos que se van a percibir y los gastos que se van a realizar
por parte de cada una de las Unidades que integran a la Institución o
Empresa, la cual tiene por finalidad cumplir con sus objetivos y
alcanzar unas metas, previamente establecidas, en un período de
tiempo determinado.” (González Oliveiros , 1988, p. 10).
En este sentido, cada organismo, empresa u organización, debe formular sus
presupuestos anualmente y seguir de la mejor manera posible su ejecución.
Especialmente, los organismos públicos, tiene esa necesidad porque los
fondos que manejan le pertenecen al estado y por ende, a los ciudadanos del
país al cual pertenece el organismo.
El presupuesto público no se puede considerar como un documento de
carácter administrativo y contable, sino más bien como un factor fundamental
y decisorio de las actividades de una colectividad políticamente organizada.
Capítulo II. MARCO TEÓRICO
12
Se puede decir que el presupuesto público es un documento especial que
prevé y autoriza los ingresos y gastos durante un período de tiempo
determinado, el cual generalmente es de un (1) año.
El presupuesto público se refiere siempre a un período futuro y siempre es
una previsión, es decir, una estimación para poder lograr los resultados que
están programados.
Es una herramienta que debe expresar con precisión y claridad la
responsabilidad, derechos, obligaciones y atribuciones de sus
administradores. Además, permite al Estado orientar y programar sus
acciones, pero también lo limita a cumplir con lo programado ya que
establece las autorizaciones máximas de los gastos en un período de tiempo.
“El presupuesto es un medio para prever y decidir la producción que
se va a realizar en un período determinado, así como para asignar
formalmente los recursos que esa producción exige en la praxis de
una institución, Sector o Región. Este carácter práctico del
presupuesto implica que debe concebírselo como un sistema
administrativo que se materializa por etapas: formulación, discusión y
sanción, ejecución, control y evaluación.” (ONAPRE, 2002).
Capítulo II. MARCO TEÓRICO
13
Los requisitos con los que debe cumplir el presupuesto público en
Venezuela, se encuentran en (ONAPRE, 2002).
Existen diferencias entre el presupuesto público y el empresarial. Los
presupuestos se formulan y ejecutan de forma distinta y aunque la intención
de ambos es tener el control de los fondos de la organización, en los
organismos públicos, la meta es utilizar los ingresos obtenidos en gastos que
generen beneficios directos a través de obras y planes para la ciudadanía,
mientras que el presupuesto empresarial busca generar ganancias para los
empresarios que dirigen la empresa en cuestión.
Esta diferencia se puede expresar a través de las fórmulas según lo indica
(González Oliveiros, 1988, portada):
SECTOR PÚBLICO: Gastos Ordinarios = Ingresos Ordinarios
Gastos Extraordinarios = Ingresos Extraordinarios
SECTOR EMPRESARIAL: Costo Fijo + Costo Variable = Costo Total.
Ingreso Total – Costo Total = Beneficio
Inicialmente, la gestión presupuestaria en los organismos del estado, se
basaba en el presupuesto tradicional, el cual contemplaba los gastos según
el ente que lo realizaba y de forma cronológica. Actualmente, los organismos
se rigen por los presupuestos basados en programas, los cuales están
Capítulo II. MARCO TEÓRICO
14
organizados por tareas y permiten mayor dinamismo en su formulación y
ejecución.
Las diferencias que existen entre el presupuesto tradicional y el presupuesto
por programas (el cual se ejecuta actualmente en Venezuela) se muestran
en la tabla 1.
Adicionalmente, el presupuesto tiene un proceso a seguir el cual debe ser
claro para toda aquella persona que tenga relación con éste durante su
gestión. Las etapas del proceso presupuestario están debidamente divididas,
ya que deben ser consideradas como aspectos igualmente importantes del
sistema de presupuesto.
“Carece de sentido mantener la idea o el concepto de que presupuestar es
solamente prever” (AVPP, 1995, p. 90). Por lo general, tratan las etapas de
aprobación, ejecución y control, aunque no establecen el equilibrio adecuado
en el tratamiento de el las.
Existe una interrelación imprescindible entre todas las etapas del proceso y
por ende, no puede haber separaciones por razones de metodología. “Esto
lleva a afirmar que el presupuesto es un proceso de previsión, ejecución y
evaluación de resultados, donde es imprescindible que la información
Capítulo II. MARCO TEÓRICO
15
completa y detallada se vaya formando en cada etapa para ser aprovechada
en la siguiente” (AVPP, 1995, p. 91).
Tabla 1 – Diferencias entre el presupuesto tradicional y por programas.
Elemento de comparación Presupuesto tradicional Presupuesto por
programas
Finalidad Las compras Las realizaciones
Uso de los sistemas de
clasificación
Institucional y por el gasto,
no permite analizar la política
fiscal
Utiliza distintas
clasificaciones que facilitan
el análisis de la política fiscal
Forma de presentación Carece de elementos de
información
Facilita información sobre el
gasto
Unidades de asignación Recursos para las unidades
administrativas
Recursos para los
programas
Posibilidad del proceso El proceso es empírico,
arbitrario y mecánico
El proceso tiene una base
técnica
Posibilidad de establecer la
responsabilidad
Responsabilidad legal y
financiera
Además, responsabilidad por
la ejecución de metas
Forma de control Control financiero y legal Además, control en las
realizaciones físicas
Conexión con la planificación No facilita establecer la
planificación
Forma parte del proceso de
planificación
Identificación de metas y
objetivos
No permite identificarlos Los identifica con relación a
los planes
Posibilidad de detectar
duplicación de labores
No se pueden detectar Identifica las duplicaciones.
Posibilidad de determinar la
eficiencia
No permite identificarla Permite identificar el grado
de eficiencia.
Fuente: González Oliveiros, J. 1988.
Capítulo II. MARCO TEÓRICO
16
El presupuesto en Venezuela tiene además, unos pr incipios que están
definidos y permiten cierta homogeneidad y claridad entre los presupuestos
de los distintos entes públicos que existen en Venezuela. Los principios
fundamentales del presupuesto público en Venezuela, estos principios se
deben cumplir en todo presupuesto y se encuentran publicados en ONAPRE
(2002).
II.2 Categorías Programáticas
Un factor de gran importancia que se precisa tomar en cuenta para la
formulación presupuestaria y el cual, a su vez, permite llevar a cabo, de
forma organizada y adecuada la ejecución presupuestaria, es la definición,
explicación y división de las categorías programáticas que componen un
presupuesto. Estas categorías siguen un orden jerárquico, pero al mismo
tiempo, pueden tener interacción entre ellas, debido a que el presupuesto por
programas permite un manejo dinámico de sus acciones.
De acuerdo al tipo de producción (terminal o intermedia), de las acciones
presupuestarias y del tipo y ámbito de la red de dichas acciones existen
diversas categorías programáticas. A continuación se explican las categorías:
Capítulo II. MARCO TEÓRICO
17
a) Programa: Categoría donde la producción es terminal de la red de
acciones presupuestarias de una institución, sector o región.
Tiene las siguientes características:
??Es la categoría programática de mayor nivel en el ámbito
de la producción terminal.
??Expresa la contribución a una política, ya que la
producción terminal refleja un propósito esencial en la
red de acciones presupuestarias que ejecuta una
institución, sector o región.
??Se conforma por el conjunto de categorías programáticas
de menor nivel que confluyen al logro de su producción.
Ejemplo de programa:
??Programa: Educación básica.
??Producto(s) terminal(es): Egresados .
??Políticas: Educativa.
b) Subprograma: Es aquella cuyas relaciones de condicionamiento
son excluidas de un programa. Por sí solo, cada subprograma
resulta en producción terminal.
Capítulo II. MARCO TEÓRICO
18
Tiene las siguientes características:
?? La producción terminal de cada subprograma precisa, a
un mayor nivel de especificidad, la producción del
programa.
?? La producción de todos los subprogramas es sumable en
unidades físicas, sin pérdida del significado de la unidad
de medición de la producción del programa del cual
forma parte.
?? La tecnología de producción es diferente para cada
subprograma de la producción del programa del cual
forma parte.
Los insumos de todos los subprogramas son sumables en términos
financieros y cada tipo de insumo de todos los subprogramas es
sumable en términos de unidades físicas a nivel de programa.
Ejemplo de subprograma:
??Programa: Educación media.
??Subprograma: Diversificada.
??Producto terminal: Egresados .
Capítulo II. MARCO TEÓRICO
19
c) Actividad: Es aquella cuya producción es intermedia, es condición
de uno o varios productos terminales o intermedios. La actividad es
la acción presupuestaria del nivel mínimo y es indivisible al
momento de asignar formalmente los recursos. Los tres (3) tipos
de actividades con los que cuenta un presupuesto, según su
influencia en los programas o subprogramas del presupuesto son:
?? Actividad Específica: Categoría programática cuya
producción es exclusiva de una producción terminal y
forma parte integral del programa, subprograma o
proyecto que la expresa.
?? Actividad Central: Categoría programática cuya producción
condiciona a todos los productos de la red de acciones
presupuestarias de una institución o sector y no es parte
integrante de ningún programa o subprograma.
?? Actividad Común: Tiene todas las características de una
actividad central, salvo que condiciona dos o más
programas, pero no a todos los programas de la institución
o sector.
Capítulo II. MARCO TEÓRICO
20
d) Proyecto: Es la categoría programática que expresa la creación,
ampliación o mejora de un medio de producción durable.
Ejemplo de proyecto:
??Proyecto: Edificaciones escolares.
??Obras. Ciclo básico de Petare, Grupo escolar en Sucre.
II.3 Fases del proceso presupuestario
Una vez definidas las categorías programáticas, es necesario conocer las
fases con las cuales cuenta un presupuesto desde su comienzo (a través de
la formulación), hasta la culminación de la ejecución de cada una de sus
categorías.
El presupuesto se debe considerar como una unidad completa y no se deben
separar las etapas del proceso presupuestario, ya que esto sólo se debe
hacer para poder facilitar el análisis de todo el proceso y así lograr dividir el
trabajo de forma adecuada en proc ura de una mayor especialización. “No es
posible llevar a cabo ninguna de dichas etapas sin considerar las
características con que se desarrollan las que la anteceden; a su vez, la
Capítulo II. MARCO TEÓRICO
21
calidad en la realización de una etapa condiciona la calidad de las
sucesivas”. (AVPP, 1995, p. 203).
Para que la formulación del presupuesto se realice correctamente se
requiere estudiar y evaluar exhaustivamente los resultados de años
anteriores, para así poder sustentar la formulación que esté en cuestión. Una
vez realizada la formulación de forma eficaz y técnicamente calificada, se
deben tomar las medidas que sean necesarias para garantizar que la
ejecución cumpla con lo programado en el presupuesto. Además, es
importante garantizar un control para detectar desvíos e irregularidades entre
lo programado y aquello que se ejecute.
II.3.1. Formulación
La fase de formulación es la parte inicial de la gestión de un presupuesto
específico. Durante esta fase, los responsables de generar el presupuesto
anual de un organismo deben exponer las categorías programáticas que
componen dicho presupuesto, así como la asignación de sus partidas y
subpartidas. De este modo, se puede describir de forma exacta, los recursos
y el importe monetario necesario para la ejecución de cada asignación
creada durante la etapa.
Capítulo II. MARCO TEÓRICO
22
Para cada organismo, existen dos tipos de presupuesto, el de ingresos y el
presupuesto de gastos. Dependiendo si las partidas generan ingresos o
gastos, éstas se incluyen en uno de los dos presupuestos anuales que debe
tener un organismo
- Presupuesto de ingresos.
La formulación de este presupuesto implica analizar el sistema de
ingresos de cada institución, es decir, los medios que utiliza un organismo
público para obtener sus ingresos.
Durante el proceso de formulación del presupuesto de ingresos, se
evalúan los rendimientos a corto plazo de las distintas fuentes de ingreso,
para poder describir su magnitud y compatibilidad con los planes y
programas que serán financiados a través del presupuesto. En otras
palabras y desde una visión más global, es el que explica quién, cómo y
cuánto se apropia el Estado de la renta nacional para cumplir con sus
funciones económicas y sociales.
Los requerimientos para la formulación del Presupuesto de ingresos, se
mencionan en AVPP (1995, p. 184).
Capítulo II. MARCO TEÓRICO
23
- Presupuesto de gastos.
Formular el presupuesto de gastos implica llevar a cabo una programación
del mismo. Esta implicación se puede entender, analizando los puntos que
menciona AVPP (1995, p. 204).
La formulación del presupuesto de gastos requiere de la ejecución de tareas
que se deben llevar a cabo con alta precisión y profundidad, de forma tal,
que el presupuesto pueda reflejar la responsabilidad del sector público en el
cumplimiento de sus políticas para el desarrollo de la nación. Por otro lado,
se tiene la obligación de aplicar criterios rigurosos para determinar y hacer el
cálculo de los insumos que requiere la producción pública.
La formulación presupuestaria debe ser realizada de forma permanente y
con un personal especializado. Esta etapa debe tener una dirección
centralizada, pero a su vez debe adquirir “…formas realistas, que sea llevada
a cabo en términos concretos y precisos por los propios responsables de los
procesos productivos” (AVPP 1995, p. 205).
Por último, se destaca que debe existir un equilibrio entre dos formas de
trabajo para poder conseguir el éxito en la formulación del presupuesto: la
forma centralizada y la descentralizada. La centralizada sirve para definir la
política presupuestaria de la nación y la coordinación general de los trabajos
Capítulo II. MARCO TEÓRICO
24
conducentes. Mientras que cada organismo debe elaborar
descentralizadamente los proyectos de su presupuesto.
II.3.2. Discusión y aprobación
Una vez terminado el proceso de formulac ión, el presidente del ente está en
la obligación de aprobar o desaprobar el presupuesto presentado y la
institución debe enviar al Ejecutivo Nacional un documento en el cual indique
todos los detalles del presupuesto aprobado.
En la primera etapa, se exponen ante la comisión de aprobación de
presupuestos, la justificación del proyecto presupuestario y luego contesta
las preguntas que le realiza la comisión.
En la segunda fase de aprobación, se hace comparecer ante la comisión de
aprobación de presupuestos a los presidentes o representantes de los
institutos autónomos, a cualquier funcionario para solicitar informes,
opiniones o declaraciones en aquellos casos que así lo ameriten. En el caso
de los institutos descentralizados, esta comparecencia se hace cuando los
entes tienen aportes acordados en el Proyecto de Presupuesto.
Capítulo II. MARCO TEÓRICO
25
II.3.3. Ejecución
Si bien el presupuesto se entiende como la visión anticipada, expresada en
un documento aprobado, de aquellos insumos que se requieren para poder
alcanzar una producción. El paso siguiente a la aprobación del mismo, el
cual está esencialmente ligado al documento, es el de efectuar las acciones
necesarias que conllevan a lograr la producción que se tiene prevista. Esto
significa que un presupuesto debe llevarse a cabo en un espacio real y
concreto, así como en un tiempo con las mismas características, de forma tal
que se puedan obtener los objetivos planeados en términos de resultados
tangibles, mesurables y evaluables.
La ejecución del presupuesto se efectúa en dos planos: el físico y el
financiero. AVPP (1995), explica la ejecución del plano físico (p. 230) y la del
plano financiero (p. 231).
La ejecución de un ingreso comienza en el momento que se crea el derecho
de percibir un bien y termina en el momento de la adquisición del mismo. Las
etapas más importantes en la ejecución de un ingreso son:
Capítulo II. MARCO TEÓRICO
26
- Entrega del bien: momento en el cual se genera el derecho de percibir
un ingreso.
- Conformación de la factura: acto administrativo que verifica la realidad
del derecho y el monto que se debe percibir por la entrega del bien.
- Recepción del pago: es el momento en que termina la ejecución del
ingreso y se extingue el derecho a percibir la contraprestación.
La ejecución de un gasto comienza cuando se solicita la realización de dicho
gasto y se termina en el momento que se paga, es decir, cuando se
extinguen las obligaciones con terceros que derivan del gasto. Las etapas
más relevantes de la ejecución de un gasto son:
- Cuando se emite y se aprueba una orden de compra, ya que se
produce la relación contractual con un tercero. Se realiza un
compromiso.
- Cuando se recibe el bien por parte del tercero, ya que nace la
obligación de pagarle. Se realiza una causación.
- Cuando se emite el pago (orden o cheque), ya que termina el proceso
de ejecución de un gasto y se extinguen las obligaciones de pago.
Adicionalmente, se pueden realizar modificaciones presupuestarias a las
categorías programáticas y sus asignaciones, inclusive en un presupuesto
que ya esté aprobado. Esta acción representa una parte de la ejecución que
Capítulo II. MARCO TEÓRICO
27
contiene leyes especiales para su desarrollo y permite hacer correcciones en
caso de encontrar alguna falla en el proceso presupuestario después de que
su formulación haya sido aprobada y el presupuesto, puesto en práctica.
Las modificaciones presupuestarias son “las variaciones legalmente
acordadas durante la ejecución del presupuesto, sobre los créditos
originalmente aprobados”. (AVPP, 1995, p. 282).
Estas modificaciones son originadas por la existencia de sobreestimaciones y
subestimaciones en los créditos aprobados inicialmente. También, se puede
dar el caso de modificación por la presencia de algún imprevisto durante la
ejecución del presupuesto aprobado.
Las modificaciones presupuestarias se clasifican en:
- Rectificaciones:
Es una autorización para aceptar gastos adicionales a los acordados
inicialmente en los diferentes programas, subprogramas, proyectos y
partidas. De esta forma se pueden atender los imprevistos que surjan
durante la ejecución. También, se pueden utilizar las rectificaciones para
aumentar los créditos que hayan sido insuficientes. “Su fuente de
financiamiento anual es el crédito de la partida “Rectificaciones al
Capítulo II. MARCO TEÓRICO
28
presupuesto” que contiene la Ley de Presupuesto anual.” (AVPP 1995, p.
286).
- Traspasos:
Es una reasignación de los créditos que posee el pres upuesto aprobado;
bien sea a un mismo programa o a diferentes programas de un organismo.
Esto surge como consecuencia de alguna sobreestimación o una
subestimación durante la ejecución. La característica principal de los
traspasos, es el no afectar el total del presupuesto aprobado.
- Insubsistencias:
Es una anulación total o parcial de los créditos no comprometidos que estén
acordados a algún programa, subprograma, proyecto o partida. La razón
principal para una insubsistencia es cuando se estima que los ingresos
programados no podrán satisfacer los gastos previstos.
- Créditos adicionales.
Es una autorización adicional de gastos para suplir los programas,
subprogramas, proyectos y partidas. La autorización se acuerda para
“financiar gastos necesarios no previstos o cuyas partidas resulten
insuficientes y siempre que el Tesoro cuente con recursos para atender la
respectiva erogación”. (AVPP, 1995, p. 295).
Capítulo II. MARCO TEÓRICO
29
II.3.4. Control
“El control presupuestario puede definirse como el conjunto de actividades
que se emprenden para medir y examinar los resultados obtenidos en el
período para evaluarlos y para decidir las medidas correctivas que sean
necesarias” (AVPP, 1995, p. 303).
Para poder llevar un control adecuado y correcto del presupuesto que se
está ejecutando en un momento dado se deben considerar los siguientes
elementos:
- Determinar los objetivos que se desean lograr. Esto se refiere a los
objetivos que están aprobados en el presupuesto, bien sean las metas
físicas que se desean alcanzar, como en términos de ingresos de
capital. Igualmente, se deberán controlar las autorizaciones para los
gastos siempre y cuando estén definidos en la programación de la
ejecución del presupuesto.
- Encontrar la forma de realizar las mediciones necesarias para permitir
la cuantificación real de la ejecución en comparación con los
resultados previstos. De la misma forma, llevar a cabo dichas
mediciones.
Capítulo II. MARCO TEÓRICO
30
- Comparar, tanto en términos físicos como financieros, aquello que
está presupuestado con lo ejecutado en un período dado. Esto se
conoce como la Determinación de las Desviaciones.
- Emitir los informes de la ejecución presupuestaria, en éstos, se deben
indicar la explicación de las desviaciones, tanto sus causas como sus
consecuencias. De la misma forma, se deben emitir los informes
referentes a la disponibilidad que se tenga para poder controlar las
autorizaciones máximas para gastar.
- Tomar las medidas correctivas que sean necesarias para poder
cumplir las metas y volúmenes de trabajo, así como la programación
prevista en un período. En caso de no cumplirse aquello que estaba
previsto, informar a las autoridades competentes dicho
incumplimiento.
Por otra parte, para poder comprobar que la gestión presupuestaria se está
llevando a cabo de manera transparente y bajo el marco legal, un proceso de
control debe cumplir con las siguientes etapas :
a) Acción desviada.
b) Envío de información al Ministerio de Hacienda sobre ejecución
presupuestaria.
c) Análisis y evaluación de la información recibida.
d) Detección de desviaciones.
Capítulo II. MARCO TEÓRICO
31
e) Propuesta de medidas correc tivas.
f) Aprobación de medidas correctivas.
g) Efecto compensatorio de medidas correctivas.
“Como puede verse, aun en el caso de estimaciones optimistas del
tiempo necesario para cada una de esas etapas, es muy probable
que, en la mayor parte de las situaciones las acciones correctivas
sean demasiado tardías cuando, en buena parte de las acciones
empresarias, el tiempo es la esencia del proceso”. (CLAD, 1979,
p.183).
En caso de existir una desviación, se deben realizar las correcciones
necesarias para garantizar la eficacia del presupuesto. Estas desviaciones
pueden ser voluntarias o involuntarias y existe la necesidad de prevenir,
descubrir y corregir cualquier tipo de desviación que pueda afectar el proceso
de la gestión presupuestaria en cualquiera de sus etapas.
La figura 1 muestra la razón y las posibles acciones que se pueden llevar a
cabo en caso que se presente alguna desviación.
Capítulo II. MARCO TEÓRICO
32
Desviaciones Causas Posibles Acciones Correctivas ¿Provisión recursos adicionales?
Recursos insuficientes
Externas no controlables ¿Cambio metas programas ?
¿Cambios compensatorios en
otras metas?
Atrasos en ejecución
Errores de programación ¿Las anteriores?
Inadecuada gestión ¿Sanciones a responsables?
Recursos excedentes
Externas no controlables ¿Devolución recursos excedentes?
¿Disminución partidas futuras? ¿Cambio metas programas ?
¿Cambio compensación en otras
metas?
Adelantos en Errores de
programación ¿Las anteriores? ejecución ¿Sanciones a responsables?
Gestión eficiente ¿Las anteriores? ¿Premios o incentivos?
Transferencias entre
programas
Decisiones no autorizadas de
directivos empresas
¿Convalidación? ¿Sanciones?
Figura 1 - Desviaciones, causas y acciones correctivas.
Fuente: CLAD, 1979, p.184.
En la figura 2 se muestra un ejemplo, en el cual se señala la producción meta
y su forma de medirla, según la categoría programática en cuestión.
Capítulo II. MARCO TEÓRICO
33
UNIDADES DE MEDIDA DE PRODUCCIÓN-META Y META
CATEGORIA PROGRAMÁTICA UNIDAD DE MEDIDA DE PRODUCCION META META
* ENSEÑANZA PRIMARIA alumno en enseñanza alumno egresado * ATENCIÓN MATERNO INFANTIL
madre atendida madre atendida
* CONSTRUCCIÓN DE VIVIENDAS
m2 de viviendas en construcción m2 de viviendas terminadas
* ADMINSTRACIÓN DEL IMPUESTO SOBRE LA RENTA
Ps. De impuestos liquidados
Ps. de impuestos recaudados
* CONSTRUCCIÓN DE ESCUELAS
m2 en construcción m2 construidos
No de aulas terminadas * CONSTRUCCIÓN DE HOSPITALES
m2 en construcción No de construcción acabada
Figura 2 - Ejemplo de control de metas.
Fuente: AVPP, 1995, p. 313.
Las fases del presupuesto deben ser integradas para de forma eficiente y en
el período de tiempo requerido para la realización y culminación de la gestión
presupuestaria de un organismo. La figura 3, muestra un esquema general
de las fases de un proceso presupuestario integradas.
PROGRAMA
SUB-PROGRAMA
PROYECTO
Capítulo II. MARCO TEÓRICO
34
Figura 3 - Fases del Proceso Presupuestario.
Fuente: ONAPRE, 2002.
Capítulo III. DESARROLLO DEL PROYECTO
Capítulo III. Desarrollo del Proyecto
El desarrollo de este proyecto se lleva a cabo basándose en la metodología
RPM (Recommended Process and Models) y con el soporte que ofrece el
lenguaje de modelaje UML (Unified Modeling Language).
El RPM no es un método nuevo, ni una nueva forma de trabajo, sino más
bien una descripción de procesos y modelos comunes que recomiendan los
expertos en UML. Éste es aplicado y practicado en el análisis y diseño de
modelos. Por razones de conveniencia y estandarización, el nombre RPM, el
cual significa modelos y procesos recomendados, se utiliza para sugerir
estos procesos y modelos, así como la naturaleza cíclica del desarrollo
interactivo. Está basado en UML y sus influencias principales se muestran en
la figura 4.
Como el lenguaje UML no define procesos estándar, los mismos autores
sobre UML reconocen la importancia de procesos que permitan utilizar los
lenguajes de modelaje. Esto se debe al hecho que la estandarización de
procesos está más allá de las definiciones y la visión que tiene el UML.
Capítulo III. DESARROLLO DEL PROYECTO
36
Figura 4 – Influencias de RPM.
Fuente: Larman, 1998, p. 18.
Desde el comienzo de la investigación, se llevan a cabo distintas actividades
que proporcionan conocimientos sobre el tema y las herramientas que se
requieren para desarrollar la aplicación planteada y luego, la ejecución de
dicha aplicación basada en los sistemas ERP de J.D. Edwards.
Los sistemas ERP (Enterprise Resource Planning) permiten automatizar casi
todos los procesos de una organización. A diferencia de otros conceptos de
algunas organizaciones, en los cuales existen tipos de software para
diversas funciones y departamentos de una empresa, los ERP están en
Fusión
OOSE Martin-Odell
Responsabilidad– Diseño dirigido
UML OMT
Booch
Modelos y Procesos
Recomendados (RPM)
Capítulo III. DESARROLLO DEL PROYECTO
37
capacidad de controlar y gestionar todas las funciones de una compañía o
institución.
“Es una lógica de aplicación de multi-modo que ayudan al fabricante o
al otro negocio a manejar las partes importantes de su empresa,
incluyendo hojas de operación (planning) de producto, las piezas que
compran, los inventarios y mantenerlos, el obrar recíprocamente con
los surtidores, proporcionar servicio al cliente, y seguir órdenes”
(Peña, 2000, p. 29).
Estos sistemas mencionados, comprenden aspectos que cubren diversas
áreas y las integra. Estas áreas son recursos humanos, materiales y activos
fijos, compras y adquisiciones, proveedores, ventas y planificación de
mercadeo, puntos de venta, seguimiento a clientes, sistemas de
almacenamiento, bodegaje y subcontratación de servicios, costeo en sus
diversas formas, transporte de mercadería y muchas otras, dependiendo de
las necesidades de la organización que posee y maneja el software.
En esta parte del trabajo de investigación se detalla cada factor, aspecto
tecnológico, pantallas, diagramas, tarea, entrevista, lectura y cualquier otro
pormenor que se toma en cuenta, se utiliza y se analiza para la realización
de este proyecto, así como para la obtención de los resultados y redacción
de las conclusiones que genera el trabajo y el desarrollo del sistema
planteado.
Capítulo III. DESARROLLO DEL PROYECTO
38
Para explicar las actividades realizadas, éstas se muestran según los pasos
que plantea la metodología, esto no significa que lleva una secuencia
cronológica, ya que la metodología, por ser dinámica, permite la ejecución de
actividades de distintas fases de ella en el mismo período de tiempo.
III.1 Levantamiento de Información
Esta primera fase se refiere a la investigación y captura de la información
pertinente al tema de presupuesto público. Para entender el funcionamiento
de las actividades rutinarias y especiales que conlleva la formulación y
ejecución de los presupuestos en organismos públicos descentralizados.
Igualmente, para poder diagnosticar los problemas e identificar de forma
correcta los objetivos que se desean alcanzar a lo largo del Trabajo Especial
de Grado.
Al realizar este levantamiento de información, se entienden las bases del
presupuesto público, los conceptos más relevantes, los formatos utilizados
para la formulación, las normas para que esta última se lleve a cabo y los
pasos para la ejecución de la gestión presupuestaria. Así mismo, se detectan
los problemas principales que tienen los organismos para poder controlar el
Capítulo III. DESARROLLO DEL PROYECTO
39
ejercicio de su administración presupuestaria y se observaron algunos
sistemas presupuestarios utilizados por dichos organismos.
Estos problemas se detectan como consecuencia de las visitas realizadas a
algunos organismos del estado y de las entrevistas llevadas a cabo durante
estas visitas. Los principales problemas detectados se basan en la falta de
sistemas calificados y eficientes que permitan un control tanto en la
formulación, como en la ejecución de los presupuestos de los organismos.
Se encuentran muchos sistemas manuales o basados en hojas de cálculo y
pocas alarmas de control para poder prevenir, detectar y en el caso de existir
una malversación de fondos que viole los principios del presupuesto y que no
esté ajustado a las pautas de un presupuesto aprobado, corregirlo.
En primer lugar, se detecta la necesidad de una herramienta que permita la
formulación del presupuesto apegada a la ley venezolana de presupuesto
vigente. Para ello se tienen formatos específicos para cada tipo de
formulación (programas, subprogramas, actividades) y un sistema efectivo de
aprobación de la propuesta formulada. Además, de contemplar lo referente a
créditos adicionales que provengan de cualquier fuente.
También, se divisa la necesidad de controlar la ejecución y realizar el
seguimiento de cada una de las partidas aprobadas de forma tal, que se lleve
a cabo una inspección constante, amigable, rápida y eficaz de cada paso de
Capítulo III. DESARROLLO DEL PROYECTO
40
la ejecución; desde el compromiso, la causación y el pago de cada partida
asignada.
Es importante destacar que el presupuesto público se realiza y ejecuta para
un período de un año, comenzando el 1° de enero y finalizando el 31 de
diciembre de cada año.
Para conocer el sistema a utilizar, se investiga sobre el sistema OneWorldTM
de esta compañía a través de material bibliográfico e información existente
en la página en internet que tiene esta empresa (http:www.jdedwards.com).
Uno de los grandes aportes de OneWorldTM es la seguridad que brinda. El
sistema de seguridad que posee OneWorldTM puede establecerse en
diversos niveles, como lo son: Clave de Usuario, Menú, Unidad de Negocio,
Tipo de Entidad, Programa, Código de Acción, Campo, Versión de Reporte.
La seguridad de OneWorldTM permite al administrador de seguridad controlar
la seguridad para usuarios individuales y para un grupo de usuarios. El
administrador de seguridad puede controlar usuarios (seguros y no seguros)
y grupos a través de las siguientes funciones:
- Seguridad de Aplicación. Controla el acceso o la instalación a
aplicaciones específicas.
Capítulo III. DESARROLLO DEL PROYECTO
41
- Seguridad de Acción. Controla la habilidad para llevar a cabo acciones
específicas, tales como añadir, cambiar, borrar, seleccionar o copiar.
- Seguridad de las filas de tablas. Controla el acceso a una lista
específica o a un rango de registros en una tabla.
- Seguridad de columna de tablas. Controla el acceso a una columna
específica dentro de una tabla. Las columnas en OneWorldTM son
representadas como un campo, tanto en las ventanas como en los
reportes.
- Seguridad de opciones de procesamiento. Controla si un usuario
puede ver los valores por prioridad, cesando las opciones que
afectarían la forma en la cual la aplicación trabaja. También controla el
permiso que tienen los usuarios para cambiar de versiones dicha
aplicación.
- Seguridad de salida. Controla el acceso al menú de salida que tienen
las ventanas de una aplicación.
- Seguridad exclusiva de una aplicación. Controla el acceso a
información segura utilizando una aplicación exclusiva.
- Seguridad de llamadas externas. Controla el acceso a las llamadas a
aplicaciones externas.
- Seguridad de ActivEra. Controla el acceso a funciones de ActivEra.
- Seguridad de acceso a la base de datos. Previene el acceso a la base
de datos desde afuera de OneWorldTM.
Capítulo III. DESARROLLO DEL PROYECTO
42
III.1.1 Visitas realizadas durante el levantamiento de información
- Visitas rutinarias al instituto autónomo Fondo Nacional de Desarrollo
Urbano (FONDUR), ubicado en la avenida Venezuela, el Rosal. Edificio
FONDUR, Caracas, Venezuela. Las visitas realizadas se describen a
continuación:
?? Entrevista con el presidente de dicho instituto, donde se
pautan las condiciones de la permanencia en FONDUR y un
breve resumen del manejo presupuestario en las obras de
este instituto. Se revisan algunos presupuestos de obras que
han sido propuestos por la organización y que debían ser
firmados por el presidente para su respectiva aprobación.
?? Entrevista con el Gerente de Planificación y Presupuesto de
la Institución. En esta visita se conocen los términos
generales del tema presupuestario, como lo es la diferencia
que existe en el manejo presupuestario de la empresa
privada y la pública. También la diferencia entre los entes
centralizados y descentralizados que existen en la nación.
?? Sesión de trabajo en las oficinas de Planificación y
Presupuesto del Fondo. Se sostiene una entrevista con el
Administrador y jefe del área de presupuesto de este
organismo. Durante la entrevista se trata sobre el manejo del
presupuesto y se entienden los conceptos y otros términos
Capítulo III. DESARROLLO DEL PROYECTO
43
referentes al presupuesto. Se examinan las hojas de cálculo
en donde se almacenan los datos del presupuesto de cada
año. Se recopila material importante, tal como los
presupuestos de años anteriores y diferentes formatos que se
utilizan en el presupuesto de cualquier organización pública
descentralizada.
?? Sesión de trabajo en las oficinas de Planificación y
Presupuesto del Fondo. Se observa el funcionamiento de un
sistema de ejecución que se deseaba instalar en el
organismo para comenzar a trabajar en él. Para esto, se
sostiene una reunión en la cual participan algunos empleados
de la oficina de Planificación y Presupuesto de FONDUR la
cual, tiene como ponente al desarrollador del sistema que se
presentó. Durante esta reunión se observan los formatos de
las categorías programáticas y las diferentes dificultades que
pueden tener los empleados al momento de ejecutar el
sistema. También se comenta sobre la resistencia al cambio
que existe en los organismos del gobierno para adaptarse a
nuevos sistemas computacionales. Se revisan las leyes
presupuestarias, en especial la Ley Orgánica de la
Administración Financiera del Sector Público, para entender
cuáles son las normas principales en la elaboración y puesta
en práctica de cualquier presupuesto que se desee realizar,
Capítulo III. DESARROLLO DEL PROYECTO
44
así como sus especificaciones en cuanto a programas,
subprogramas, proyectos, obras, actividades, partidas y
subpartidas.
?? Sesión de trabajo en las oficinas de Planificación y
Presupuesto del Fondo y en las oficinas de informática del
organismo. Durante esta visita se sostiene una entrevista con
un empleado encargado de procesar los compromisos y
causaciones que se emiten en el organismo, quien explica
como se lleva a cabo el chequeo y control de los proyectos a
partir de las múltiples valuaciones que se envían a la oficina,
así como el chequeo de memos y de la forma como se
aprueban.
?? Entrevista con el Jefe de Informática de FONDUR. En esta
conferencia se recibe material que explica cómo son las
bases de datos que se desean tener en el organismo. Este
material se lo otorgan a aquellas personas o compañías que
ofrecen crear un software para el manejo de presupuestos en
el instituto.
- Visita realizada a la Asociación Venezolana de Presupuesto Público
(AVPP), ubicada en la avenida Universidad, Torre Villasmil, piso 13, Caracas,
Venezuela.
Capítulo III. DESARROLLO DEL PROYECTO
45
?? Adquisición del libro escrito por dicha asociación (AVPP,
1995) y consulta al encargado de la oficina con respecto al
presupuesto público. En esta Asociación se accede a la
biblioteca y se obtienen manuales sobre algunos sistemas
antiguos que se plantearon en el espacio descentralizado de
los entes públicos.
- Visita realizada a la Oficina Nacional de Presupuesto (ONAPRE), antigua
Oficina Central de Presupuesto (OCEPRE). La ONAPRE está ubicada en la
avenida Universidad, Torre Villasmil, piso 2, Caracas, Venezuela.
?? Visita al Centro de Documentación de la ONAPRE, en el cual
se encuentra material sobre el tema presupuestario. Aquí se
extrae material valioso para poder entender la evolución
histórica que ha tenido la gestión presupuestaria en
Venezuela y observar las variables y características que han
permanecido constantes a lo largo de la historia del
presupuesto público en el país.
III.1.2 Consulta de material bibliográfico
Para la realización de esta etapa, la bibliografía más utilizada es:
Capítulo III. DESARROLLO DEL PROYECTO
46
- ONAPRE (2002): En esta página se encuentra un instructivo de
gran utilidad en cuanto a conceptos, principios y características
que debe tener todo presupuesto para su formulación. Se
encuentran las bases del presupuesto público según la Oficina
Nacional de Presupuesto (ONAPRE).
- AVPP (1995): Este libro contiene todos los aspectos relativos al
presupuesto público en Venezuela. Se utiliza principalmente para
conocer y entender los pasos y requisitos que tiene la ejecución
presupuestaria en este país (Capítulo V, parte C), el control de
dicho presupuesto (Capítulo V, parte D) y algunos conceptos en
general (Capítulo III).
- Ley Orgánica (2000): Con este documento se conocen las leyes
que rige el sistema presupuestario actual. Se conoce sobre las
disposiciones generales (Capítulo I) y especialmente sobre las
normas para administrar los organismos descentralizados
(Capítulos II y IV).
- Presupuesto FONDUR (2000): En este manual, se obtiene una
vista previa de los formatos que existen para la formulación de
presupuestos. Formatos para programas, subprogramas, partidas y
subpartidas.
Capítulo III. DESARROLLO DEL PROYECTO
47
III.2 Análisis de los Requerimientos
Tras realizar un análisis exhaustivo sobre la terminología, forma de trabajo y
leyes que se relacionan con el tema presupuestario, se definen varios puntos
importantes que sirven de base en el desarrollo del sistema. Estos puntos se
refieren principalmente al manejo del presupuesto, el cumplimiento de sus
fases, las personas encargadas de llevar a cabo el proceso presupuestario y
la seguridad necesaria durante la realización de las acciones que componen
la gestión presupuestaria.
La bibliografía utilizada para aplicar la metodología RPM en la fase de
análisis es: Larman (1998). Se decide utilizar este libro, ya que Craig Larman
(autor del libro) fue quien ideó y diseñó esta metodología y tiene información
detallada sobre cómo se deben realizar los diagramas, con ejemplos y
particularidades.
Luego de efectuar el análisis, se desarrollan las siguientes consideraciones:
a) En cualquier entidad pública descentralizada, existen varias etapas
por las cuales debe pasar un presupuesto para ser formulado,
aprobado y ejecutado; por ende, cualquier sistema presupuestario que
se desee aplicar debe contar con herramientas que permitan este
Capítulo III. DESARROLLO DEL PROYECTO
48
traspaso de información hacia las diferentes personas (que
desempeñan diferentes cargos) en la organización.
b) Debido al alto número de personas que manejan la información
presupuestaria de un ente del estado, el módulo de seguridad de la
herramienta es fundamental.
c) El manejo de presupuesto público en Venezuela es siempre de la
forma “por programa” (véase la sección II.1 ). “El presupuesto por
programas es una expresión de la producción pública y, a la vez,
como un instrumento para asignar insumos en función de dicha
producción” (AVPP, 1995, p. 131). “Un programa es la categoría
programática cuya producción es terminal de la red de acciones
presupuestarias de una institución, sector o región” (AVPP, 1995, p.
138).
d) En el manejo ordinario y rutinario del presupuesto, deben abarcarse
todas las características que posee el presupuesto público en
Venezuela y cumplir con los principios de éste, especificados en AVPP
(1995), p. 95.
e) En los casos de situaciones extraordinarias; tales como créditos
adicionales (bien sean por petición del organismo o por alguna
asignación proveniente de una ley extraordinaria), se tiene un módulo
especial que los controla, porque éstos son manejados de forma
diferente al presupuesto corriente. También se deben tomar en cuenta
Capítulo III. DESARROLLO DEL PROYECTO
49
los traspasos, rectificaciones e insubsistencias. (véase la sección
II.3.3.).
f) Durante la ejecución del presupuesto, se debe contar con un
seguimiento efectivo y completo de las distintas partidas
comprometidas, causadas o pagadas.
g) El cumplimiento de todas las leyes presupuestarias es un requisito de
este proyecto, ya que éstas garantizan la integridad del sistema.
Otro requerimiento es la presentación y desarrollo de formatos útiles,
conocidos e íntegros que regulen las distintas acciones para la
administración de los presupuestos. Debe existir uno o más formatos para
cada tipo de acción que se realice en este ámbito.
Las necesidades de distintos tipos de organismos que manejan las diversas
formas y ramas de la ley presupuestaria nacional, es un requerimiento
importante que se debe tomar en cuenta para el desarrollo del sistema, de
forma tal , que se solventen las necesidades que tienen los entes del estado.
Éstas se logran observar durante la etapa de levantamiento de información
(véase la sección III.1). Una necesidad es solventar la falta de sistemas de
informac ión en las organizaciones, debido al factor que los sistemas
existentes en el mercado son muy generales. Además, está la necesidad de
implementar una herramienta amigable y fácil de manejar (similar a los
formatos preestablecidos en papel), porque las personas que trabajan en
Capítulo III. DESARROLLO DEL PROYECTO
50
estos organismos, laboran cuantiosamente y se ven en la necesidad de
apoyarse en un sistema de uso sencillo.
Los distintos tipos de organismos que se pueden adaptar a este trabajo son
aquellos entes públicos y descentralizados como lo son: institutos
autónomos, empresas del estado, fundaciones del es tado y entes regionales.
Según el análisis que se realiza, sólo estas organizaciones están en
capacidad de adaptarse al modelo del proyecto porque no entregan sus
ingresos al gobierno central, sino que lo reutilizan para nuevas inversiones
directamente, es decir, “…utilizan su presupuesto de ingresos para
contemplar el de gastos”. (Ley Orgánica de la Administración Financiera del
Sector Público, 2000, art. 6-7).
Para poder completar el análisis y seguir con las siguientes fases en la
metodología, se crean diagramas que permiten reflejar los resultados y
generar un punto de partida para la realización del diseño del sistema.
Según la metodología RPM, los diagramas se realizan para entender de
forma gráfica la definición del problema, los actores que interactúan con el
sistema y la relación existente entre sus distintos procesos .
“Un caso de uso es un documento narrativo que describe la secuencia de los
eventos de un actor (agente externo) utilizando un sistema para completar el
proceso” (LARMAN, 1998, p. 49). Si bien el caso de uso no representa la
Capítulo III. DESARROLLO DEL PROYECTO
51
funcionalidad ni los requerimientos que tiene un sistema, permite tener una
idea general de la forma en la cual se maneja un sistema y además de intuir
algunos de los requerimientos del sistema que representa.
“El diagrama de casos de uso ilustra un conjunto de casos de uso para un
sistema, los actores y la relación entre los actores y el sistema” (LARMAN,
1998, p. 55).La idea principal de este diagrama, es poder presentar a los
actores externos del sistema y la forma en la cual se interrelacionan con el
sistema, de forma sencilla y gráfica.
Con la realización del diagrama de casos de uso, se definen los actores que
interactúan con el sistema, los cuales alimentan de información al sistema y a
su vez la reciben de forma continua según el rol que cada uno de ellos tiene
en la gestión presupuestaria del organismo.
“Un actor es una entidad externa al sistema que de alguna manera participa
en la historia del caso de uso. Un actor simula generalmente el sistema a
través de eventos de entrada, o recibe algo de él” (LARMAN, 1998, p. 52). Es
importante señalar que los actores se describen según el rol que tienen en el
caso de uso.
La persona responsable del manejo presupuestario en un organismo es
generalmente el gerente de presupuesto de dicho organismo, por ende el
Capítulo III. DESARROLLO DEL PROYECTO
52
actor denominado gerente de presupuesto, es la persona responsable y
quien más interacción suele tener con el sistema. Este actor está presente en
cada fase del proceso presupuestario y en él recae la responsabilidad de
aprobar las diferentes asignaciones, así como la aprobación de la ejecución.
Aunque generalmente no es el responsable de formular el presupuesto, sí
tiene acceso a esta parte del sistema. Si bien el gerente de presupuesto
tiene acceso a todos los módulos del sistema, éste puede estar representado
en más de una persona, por lo cual se puede dar el caso, por ejemplo, de un
responsable de aprobación y otro de ejecución.
Otro actor de alta interacción que también está presente en la mayoría de las
etapas a lo largo de todo el proceso, son las personas que representan el
personal de presupuesto del organismo. De alguna forma u otra, este actor
forma parte de las fases excepto, lo referente a la aprobación de cualquier
acción tomada. Es decir, este actor formula las asignaciones, lleva a cabo las
fases de ejecución presupuestaria y realiza las peticiones extraordinarias,
para luego ser aprobadas por el gerente del presupuesto.
Se puede dar el caso en un organismo, donde el personal de recursos
humanos tiene algún tipo de interacción con el sistema, esto se debe al
hecho que existen partidas y programas referentes al manejo de los
empleados del organismo. A veces, la información del personal es
complicada de manejar y requiere al actor denominado personal de RRHH
Capítulo III. DESARROLLO DEL PROYECTO
53
para su manejo. Este actor, se encarga de formular los programas y las
asignaciones de los fondos que van dirigidos al personal. También, pueden
acceder al sistema en la fase de ejecución para registrar, por ejemplo, el
pago del personal (en la partida que se refiere a los empleados del
organismo).
Otro actor que interactúa con el sistema es el personal de finanzas. Como
éste maneja los fondos de la empresa, está presente en la formulación del
presupuesto, especialmente durante las asignaciones de los fondos, de
manera tal, que se tiene un control de cuánto se puede asignar.
Por último, está el administrador del sistema quien, si bien no tiene contacto
con el tema presupuestario, es responsable de gerenciar y controlar a los
usuarios de forma tal, que no haya problemas para su desempeño. También
debe encargarse del mantenimiento del sistema en todo momento.
Los procesos representados en el diagrama de casos de uso general (véas e
la figura 5) son los módulos descritos en el diseño detallado del sistema
(véase la sección III.3) y con los cuales, los actores interactúan según sus
acciones y de acuerdo a la responsabilidad que cada uno de ellos tiene en el
sistema.
Capítulo III. DESARROLLO DEL PROYECTO
54
Administrador Administrar elSistema
Personal de Finanzas
Personal de RRHH
Aprobar el presupuesto
Realizar modificaciones legales
Formular el presupuesto
Ejecutar el presupuesto
Personal de Presupuesto
Gerente de Presupuesto
Manejar créditosadicionales
Figura 5 – Diagrama de casos de uso general.
Fuente: Elaboración propia.
A través del diagrama de casos de uso general, se logra entender la
interacción del sistema, pero es con los casos de uso detallados , que se
entienden a fondo las especificaciones del vínculo existente entre cada actor
Capítulo III. DESARROLLO DEL PROYECTO
55
y los procesos con los cuales se relaciona. En estos diagramas se observan
los actores que interac túan con los procesos, su responsabilidad y los datos
que el sistema retorna. Los diagramas de casos de uso detallados se
encuentran en el apéndice A.
Una vez entendida la interacción entre las personas que manejan el sistema
desarrollado y el sistema como tal, se realiza el modelo conceptual de forma
tal, que se entiende la interrelación existente entre los distintos procesos del
presupuesto y la forma en la cual éstos se conectan, además, para reflejar
los datos que se necesitan para alimentar los procesos del sistema, sin
conocer aún los procedimientos que ejecuta el sistema con los datos
suministrados.
La forma como se refleja la interrelación entre los procesos es a través del
modelo conceptual (véase la figura 6), el cual es “el artefacto más importante
a crear durante el análisis orientado a objetos” (LARMAN, C. 1998, p. 85). El
modelo conceptual representa los conceptos que existen en un problema
específico y el cual se representa como una estructura estática sin
operaciones definidas. “El término modelo conceptual tiene la ventaja que
enfatiza fuertemente la atención en conceptos de dominio, no entidades de
software” (LARMAN, 1998, p. 87).
Capítulo III. DESARROLLO DEL PROYECTO
56
Figura 6 – Modelo Conceptual.
Fuente: Elaboración propia.
Los casos de uso sugieren la interacción entre los actores y el sistema, para
el cual, el actor genera acciones y eventos (entrada) esperando una
respuesta (salida) por parte de dicho sistema. Los diagramas de secuencia
Capítulo III. DESARROLLO DEL PROYECTO
57
permiten ilustrar estos eventos y las operaciones que inician los actores
hacia el sistema.
“Un diagrama de secuencia es un dibujo que muestra, para un
escenario particular de un caso de uso1, los eventos generados por
actores externos, su orden…el énfasis del diagrama eventos que
cruzan los límites del sistema desde los actores hacia sistemas”
(LARMAN, 1998, p. 137).
III.3 Diseño detallado del Sistema
Para cumplir con el diseño, se toman en consideración los pasos
correspondientes desde que se formula un presupuesto, su respectiva
aprobación, el seguimiento de su ejecución y el control de dicha ejecución
para evitar malversación y errores en los pagos que se realizan. Además, se
toman en cuenta los casos extraordinarios durante la gestión presupuestaria.
En el diseño, se divide el módulo de presupuesto público para J.D. Edwards
en cuatro submódulos como lo son: formulación, aprobación, ejecución y
situaciones extraordinarias.
Capítulo III. DESARROLLO DEL PROYECTO
58
Actualmente, J.D. Edwards no sólo mantiene los negocios en marcha con
sus aplicaciones de ERP, sino que además provee de software de alto nivel
que permiten a las compañías conectarse con sus suplidores y clientes a
través del comercio colaborativo. Debido a que los clientes de J.D. Edwards
utilizan múltiples sistemas y tecnologías, la compañía provee de una
arquitectura abierta que permite flexibilizarse y logra integrarse con las
tecnologías, procesos y socios de negocios que existen en el mercado.
J.D. Edwards se ha consolidado en el mercado gracias a sus ventajas
competitivas que le permiten sobresalir en varios aspectos con respecto a su
competencia. Las ventajas principales que refleja la tecnología de esta
compañía son: plenitud en su funcionamiento, permite cambios en sus
configuraciones, permite avanzar con los cambios en la economía, ofrece
soporte de alto nivel, posee una interfaz gráfica que se maneja de forma
sencilla, posee herramientas de desarrollo “Point & Click”, posee un asistente
para permitir el diseño y creación de los reportes, permite las actualizaciones
de software de forma sencilla, tiene un centro integrado de soluciones para el
cliente, entre otras.
La bibliografía utilizada para aplicar la metodología RPM es: Larman (1998).
Se decide utilizar este libro para el diseño por las mismas razones que se
decide usarlo para el análisis de este sistema (véase la sección III.2).
Capítulo III. DESARROLLO DEL PROYECTO
59
III.3.1 Sub-módulo de Formulación
Para realizar la formulación, se comienza por estructurar el presupuesto y
definir el nivel de cada sección que se desee presupuestar. Para ello, se
define si es un programa, subprograma, actividad, subactividad. Se tiene en
cuenta cuál es la cantidad monetaria que se tiene para gastar en total y se
justifica cada unidad monetaria (Bolívar) que se desea asignar a cada una de
las secciones a utilizar. Es probable que sólo se formule una sección, para
esto se manejará información sobre el gasto total permitido y si esta sección
que se va a formular no es un programa, se especificará a qué programa
pertenece. Para cada sección, se determinan las partidas que contemplan
esa sección y cada una debe justificarse.
Los distintos formatos que existen para la formulación son importantes ya
que allí se tienen las pautas. En general, los datos más relevantes que se
colocan en cada partida que se desee presupuestar son:
?? Código de la partida.
?? Descripción.
?? Unidad en la cual se mide esta partida.
?? Cantidad.
?? Precio Unitario.
?? Total en bolívares.
Capítulo III. DESARROLLO DEL PROYECTO
60
La etapa de formulación debe comenzar con una descripción de los objetivos
del presupuesto, así como los objetivos de cada programa.
El diagrama de secuencia que se representa en la figura 7, describe de
forma gráfica el proceso de formulación que acontece cuando interviene el
gerente de presupuesto. Este actor, al igual que el personal de presupuesto,
debe realizar varias acciones para formular el presupuesto de forma
completa y lógica.
Figura 7 – Diagrama de secuencia para la formulación.
Fuente: Elaboración propia.
:Sistema
Realizardisminucionesaumentos(tipo, monto)
Llevarseguimiento(numprograma)
Gerente de Presupuesto
Formularprograma(numprograma, objetivo)
Capítulo III. DESARROLLO DEL PROYECTO
61
III.3.2 Sub-módulo de Aprobación
Para controlar los diferentes entes y los distintos pasos que debe recorrer un
presupuesto para ser aprobado, lo más importante, es la seguridad que
autoriza y controla dichas aprobaciones y donde deben estar bien asignadas
y definidas las funciones y los límites de cada uno de estos entes.
Es importante que para cada acción en la cual se involucren fondos del
organismo, exista su respectiva aprobación, de lo contrario, no se puede
continuar con la etapa siguiente.
La aprobación se realiza para las siguientes acciones:
- Aprobación de cada programa descrito y detallado por partidas que la
componen.
- Aprobación de los compromisos que se realicen a lo largo de la
ejecución.
- Aprobación y responsabilidad de las causaciones realizadas de
acuerdo a los compromisos.
- Aprobación y responsabilidad por los pagos que se realicen.
Los formatos para aprobar cada una de las acciones descritas en esta
sección facilitan este proceso y mantienen el control uniforme de las
propuestas realizadas.
Capítulo III. DESARROLLO DEL PROYECTO
62
Sin embargo, existe la posibilidad de desaprobar una propuesta. En este
caso, se especifican las causas de la no aprobación y se le informa al ente
formulador de la propuesta con las nuevas indicaciones que se hayan
descrito en esta desaprobación.
En el diagrama de secuencia que se exhibe en la figura 8, se ilustran todos
los procesos de aprobación que puede ejecutar el gerente del presupuesto.
Estas aprobaciones abarcan la aprobación de la formulación, todas las fases
de la ejecución e inclusive, la autorización para realizar modificaciones a un
presupuesto ya aprobado (situaciones extraordinarias).
III.3.3 Sub-módulo de Ejecución
La ejecución de cualquier parte en la gestión presupuestaria es quizá la más
importante, debido al hecho que si la ejecución está bien controlada, el
dinero que se destina a cada partida es el que debe ir y se evita la
malversación de fondos.
La ejecución que se diseña tiene la posibilidad de controlar los compromisos,
causaciones y pagos de las diferentes partidas con sus formatos específicos.
Este control tiene como entrada las valuaciones que envían los
Capítulo III. DESARROLLO DEL PROYECTO
63
departamentos del organismo. Al finalizar cada registro de cualquier parte de
la ejecución, se envían los datos al sub-módulo de aprobación.
Figura 8 - Diagrama de secuencia para la aprobación.
Fuente: Elaboración propia.
Adicionalmente, para ejecutar una fase, es necesaria la existencia de la
aprobación de la fase que le antecede. De la misma forma, para que una
fase de la ejecución sea válida para el sistema, se requiere su respectiva
aprobación.
:Sistema
Aprobarpresupuesto()
Gerente de Presupuesto
Autorizarpago(monto, forma)
Aprobarsituacionextraordianria(tipo)
Autorizarcausacion(monto)
Autorizarcompromiso(monto, compañía)
Capítulo III. DESARROLLO DEL PROYECTO
64
En la figura 9 se contempla el diagrama de secuencia que representan las
acciones que lleva a cabo el gerente de presupuesto durante la ejecución
presupuestaria. Este gerente cumple las mismas funciones que el personal
de presupuesto y puede llevar un seguimiento a través de reportes que
indican el estado de la ejecución de los programas y sus partidas.
Figura 9 – Diagrama de secuencia para la ejecución.
Fuente: Elaboración propia.
III.3.4 Sub-módulo de situaciones extraordinarias
En esta parte del sistema se manipula lo que se refiere a acciones que no
contempla la gestión rutinaria del presupuesto público. Esta sección también
:Sistema
Llevarseguimiento(numprograma)
Gerente de Presupuesto
Compometerasignaciona(monto,numprograma,codpartida)
Causarpartida(monto,numprograma,codpartida,compromiso)
Ingresarpago(monto,numprograma,codpartida, causacion)
Capítulo III. DESARROLLO DEL PROYECTO
65
tiene sus formatos especiales para los créditos adicionales, traspasos,
rectificaciones e insubsistencias. Además, se controlan las adiciones y
disminuciones que se indican en la fase de aprobación presupuestaria.
Lo primero que se requiere definir es el tipo de modificación según el caso en
cuestión. Otra exigencia es asegurarse que la categoría a la cual se le
practica una modificación extraordinaria, no se encuentre en ninguna fase de
su ejecución. Es decir, que no se puede ejecutar un traspaso desde o hacia
una asignación que ya esté comprometida.
El diagrama de secuencia del gerente de presupuesto cuando lleva a cabo el
cumplimiento de las situaciones extraordinarias, se muestra en la figura 10 y
describe como este actor es el principal ar tífice en la gestión de este sub-
módulo.
Cabe señalar que los diagramas de secuencia que reflejan la interacción de
los demás actores con los procesos del sistema y el sistema como tal, se
encuentran en el apéndice B.
Capítulo III. DESARROLLO DEL PROYECTO
66
Figura 10 – Diagrama de secuencia para las situaciones extraordinarias.
Fuente: Elaboración propia.
III.3.5 Diseño de las tablas de Bases de Datos
Siguiendo las especificaciones del diseño y sus resultados, se procede a
diseñar el modelo físico de las bases de datos. Estas bases de datos se
encuentran compuestas por una serie de tablas basadas en los parámetros
que ofrece J.D. Edwards para su diseño.
Los datos que utilizan las aplicaciones que se crean con las herramientas de
OneWorldTM se basan en bases de datos relacionales que vienen con la
aplicación y las cuales, son fáciles de crear. Los requerimientos para crear
una tabla son que los campos de datos que la componen se encuentren en el
:Sistema Gerente de
Presupuesto
Aprobarsituacionextraordianria()
Requerirsituacionextraordnaria()
Capítulo III. DESARROLLO DEL PROYECTO
67
diccionario de datos de OneWorldTM y que alguno de ellos sea el índice o
clave de la tabla. La tabla debe estar definida.
La interfaz que utiliza OneWorldTM para crear sus tablas, es de fácil uso y se
puede ejecutar utilizando únicamente el ratón (mouse). Un índice primario
identifica registros únicos en una tabla. “El índice permite al sistema
manejador de bases de datos (DBMS) ordenar y localizar los registros de
forma veloz” (JDEdwards, 2000, p. 125).
Las tablas tienen un código único dentro de la base de datos general que
posee OneWorldTM, así como una descripción. Se basa en un modelo de
bases de datos relacionales y se conforman de los siguientes campos:
- Nombre
- Descripción
- Tipo de dato
- Longitud.
- Alias
El alias es un código que identifica al campo dentro de la base de datos. De
esta forma, se puede utilizar un mismo campo en varias tablas.
Capítulo III. DESARROLLO DEL PROYECTO
68
Para entender las tablas, se necesita observar las especificaciones de cada
una de ellas y cómo fue introducida en OneWorldTM y así poder ser utilizadas
durante la etapa de codificación del sistema. Se requiere conocer en detalle
el contenido de los campos enumerados anteriormente, para cada una de las
tablas de base de datos utilizada. Dicha especificación se encuentra
representada en el apéndice C. La relación existente entre las tablas y como
se conjugan entre sí, se muestra en el diagrama de clases presentado en la
figura 11.
Según la metodología Recommended Process and Models (RPM), para
completar el diseño se debe graficar un diagrama de manera tal que se
entienda de forma gráfica la interacción que tienen los componentes del
sistema. Este diagrama es el producto final del diseño y con el cual se
diseñan las tablas de bases de datos.
El diagrama de clases ilustra las clases del software diseñado de forma
específica en una aplicación. “En contraste con el modelo conceptual, el
diagrama de clases de diseño muestra definiciones para entidades de
software en vez de conceptos del mundo real.” (LARMAN, 1998, p. 258).
Capítulo III. DESARROLLO DEL PROYECTO
69
Figura 11 – Diagrama de clases.
Fuente: Elaboración propia.
Capítulo III. DESARROLLO DEL PROYECTO
70
Para el diseño de las tablas de bases de datos y de pantallas se utiliza como
referencia bibliográfica, JDEdwards (2000). Se decide utilizar esta guía ya
que describe de forma específica y completa la forma de trabajar con las
herramientas de desarrollo de OneWorldTM.
Además de dichos cursos, se comienza con un entrenamiento técnico
recibido tras la asistencia constante y frecuente a la empresa B.F.G.P.
Ingenieros. Durante este período, que se fusiona posteriormente con el
desarrollo de la aplicación, se tiene la necesidad de asistir a dicha compañía
regularmente en horarios de oficina.
A lo largo del entrenamiento técnico se utiliza material de apoyo referente a
las herramientas de desarrollo que posee J.D. Edwards, así como reuniones
y entrevistas con empleados de la empresa, especialmente, desarrolladores
de aplicaciones. Durante las entrevistas, se aprovecha para entender los
procesos existentes en el desarrollo de aplicaciones y proyectos con las
herramientas de OneWorldTM.
Capítulo III. DESARROLLO DEL PROYECTO
71
III.4 Codificación del Sistema
Al completar la codificación del sistema, se obtiene el producto final a través
de varias aplicaciones, las cuales completan el cumplimiento de los objetivos
planteados al comienzo de este trabajo de grado. Para llevar a cabo esta
fase, se investigan y utilizan los estándares y forma de trabajo que demanda
la tecnología de los sistemas ERP de J.D. Edwards.
Tras haber finalizado el diseño y una vez introducidas todas las tablas
dentro del sistema (véase el apéndice C), se crean las vistas lógicas
necesarias para ser asignadas a las ventanas de las aplicaciones
desarrolladas. Todas las vistas lógicas creadas son asignadas a una o más
ventanas dentro de las aplicaciones y son éstas las que permiten la
interconexión entre las ventanas (usuarios) y las tablas (bases de datos).
Una vista lógica o “Business View” es una selección de datos compuestos
por una o más tablas. Luego de crear las tablas de bases de datos, las vistas
lógicas se utilizan para seleccionar únicamente los datos que serán utilizados
en una aplicación.
OneWorldTM utiliza estas vistas de forma tal que se pueden generar las
sentencias de SQL que requiere el sistema. Estas vistas se pueden
actualizar durante una aplicación o también pueden ser utilizadas para
Capítulo III. DESARROLLO DEL PROYECTO
72
diseñar un reporte que muestra datos . Esto permite que existan menos
movimientos de los datos a través de la red al no transmitir los datos
innecesarios para la aplicación.
Como menciona JDEdwards (2000), una vista lógica:
- Puede contener datos existentes en más de una tabla.
- Puede contener todos o algunos datos de sus tablas.
- Relaciona las aplicaciones de OneWorldTM con las tablas.
- Es requerido para crear una aplicación o para generar algún reporte.
- Define datos de múltiples tablas que utiliza una aplicación (como en
empalmes y uniones de tablas).
(p.149).
La programación se divide en los sub-módulos mencionados en fase de
diseño (véase la sección III.3), por ende, se crean aplicaciones separadas,
aunque interconectadas entre sí, para cada uno de estos sub-módulos y se
comienza con el desarrollo de la parte de formulación presupuestaria,
seguido del módulo de aprobación, ejecución y por último, el módulo de
situaciones extraordinarias.
Para desarrollar las aplicaciones, se cuenta principalmente con dos tipos de
ventanas: las Find&Browse y la Fix/Inspect, ambas dentro de las
herramientas de desarrollo que ofrece OneWorldtm.
Capítulo III. DESARROLLO DEL PROYECTO
73
Una ventana es la interfaz que existe entre los usuarios y las tablas de bases
de datos. Las ventanas deben estar asociadas a una o más (dependiendo
del tipo de ventana) vistas lógicas existentes. Esta interfaz debe:
- Presentar los datos de forma lógica.
- Contener la funcionalidad necesaria para que el usuario pueda
ingresar y manipular la data.
En la figura 12, se visualiza la relación existente entre los usuarios, las
aplicaciones (con sus ventanas), las vistas lógicas y las tablas de bases de
datos.
En la figura 13 se puede observar los distintos tipos de ventanas que ofrece
OneWorldTM y su interrelación.
Capítulo III. DESARROLLO DEL PROYECTO
74
Figura 12 – Relación del usuario con las bases de datos en OneWorldTM.
Fuente: JDEDWARDS, 2000, p. 212.
Figura 13 – Interrelación entre las ventanas OneWorldTM.
Fuente: JDEDWARDS, 2000, p. 213.
Capítulo III. DESARROLLO DEL PROYECTO
75
Los elementos de una ventana son: el tipo, vista(s) lógica(s) asociada(s),
controles, propiedades, estructura de datos y reglas de eventos.
Cuando se crea una ventana, lo primero que se debe hacer es especificar el
tipo. Cada uno de los tipos de ventanas, tiene características que permite
completar diferentes tareas. Los tipos de ventana que provee la herramienta
de diseño de ventanas de OneWorldTM son:
- Find&Browse: se utiliza para buscar, ver y seleccionar múltiples
registros en un grid.
- Fix/Inspect: Permite añadir nuevos registros a una tabla o actualizar
alguno existente.
- Header detail: permite trabajar con data de dos tablas separadas, de
forma tal que se pueda añadir o actualizar un registro de cabecera. Al
mismo tiempo, se puede añadir, actualizar o eliminar registros
detallados.
- Headerless detail: se utiliza para desplegar múltiples registros de una
tabla que no esté normalizada.
- Search and select: se utilizan para localizar un valor y devolverlo a un
campo especificado.
- Message: se utiliza para desplegar mensajes o requerirle al usuario
que realice una acción.
Capítulo III. DESARROLLO DEL PROYECTO
76
- Parent/Child: se utiliza para representar las relaciones padre/hijo
dentro de una aplicación.
En el proyecto, las ventanas Find&Browse se utilizan para hacer las
búsquedas necesarias en la ventana, inclusive con algunas condiciones
dadas por el usuario, como por ejemplo, para buscar todos los programas de
un presupuesto que no haya sido aprobado aún. Una vez obtenida esta
búsqueda, se permiten ciertas acciones de acuerdo a la ventana en la cual
se está trabajando, como es el caso en el cual se asigna una partida al
programa seleccionado en un presupuesto. Estas ventanas se utilizan
únicamente para buscar y seleccionar.
Las ventanas Fix/Inspect se utilizan para hacer modificaciones en las bases
de datos al trabajar directamente con la vista lógica que representa a la(s)
tabla(s) a modificar. Un ejemplo de ello es cuando se añade o modifica un
programa de un presupuesto existente. Estas ventanas se utilizan
adicionalmente para ver al detalle un registro de una tabla. Por ejemplo,
para ver los detalles de una asignación de una partida en un programa de un
presupuesto.
Otras ventanas con las que cuenta OneWorldtm y las cuales se utilizan, pero
con el propósito de darle soporte a las ventanas principales de la aplicación
Capítulo III. DESARROLLO DEL PROYECTO
77
son: las Search&Select, para hacer búsquedas rápidas que retornan un valor
requerido y las del tipo Message (mensaje) para dar mensajes al usuario.
La navegación del sistema a través de las ventanas y aplicaciones es muy
dinámica y permite el acceso a cualquier aplicación y ventana dentro de
cualquier punto de partida, siempre y cuando tenga coherencia. No en vano,
la seguridad del sistema y la forma en la cual está programado, impide que
se modifiquen datos, bien sea con o sin intención de hacerlo, de forma no
deseada; cuidando así, la integridad y calidad de los datos.
Para codificar los eventos y las reglas de los eventos que ocurren en las
aplicaciones del sistema, se utiliza la herramienta “Point & Click”, la cual
permite tener un control de las funciones que se programan y facilitan las
instrucciones de programación necesarias para el desarrollo de este sistema.
Las herramientas de desarrollo que presenta J.D. Edwards son de uso
sencillo, debido a que se basa en el manejo de modelos y eventos para
poder desarrollar aplicaciones y modificarlas de forma eficiente. Gracias a
estas herramientas de desarrollo “Point & Click”, la producción en el área de
desarrollo de la empresa es rápida y arroja resultados de muy alto nivel.
Con tan sólo hacer clic a los objetos que se desean, se pueden migrar
nuevas versiones directamente al sistema. Esto se debe al factor que la
Capítulo III. DESARROLLO DEL PROYECTO
78
tecnología utilizada en estas herramientas está basada en objetos. Lo mismo
se cumple al momento de crear un desarrollo de un proyecto específico.
“Las herramientas de desarrollo son muy fáciles de usar e intuitivas,
con manejo de eventos y modelos, lo cual permite desarrollar
aplicaciones y hacer modificaciones a OneWorldTM en forma rápida y
eficaz, permitiendo que el personal del área de sistema sea altamente
productivo en poco tiempo” (Peña, 2000, p. 51).
III.5 Pruebas del Sistema
Paralelamente con la codificación del sistema, comienza la fase de prueba, la
cual continúa hasta el final del desarrollo de la aplicación. A través de
diversas pruebas realizadas a las aplicaciones que se desarrollan, se va
moldeando el sistema de modo que se adapte a OneWorldTM y además, sea
un sistema amigable, sin perder su funcionalidad.
Se prueban los procedimientos, las funciones de las ventanas y la lógica de
la aplicación como tal. También se realizan pruebas de navegación e
interconexión entre las ventanas, así como la seguridad existente para cada
sub-módulo del diseño.
Capítulo III. DESARROLLO DEL PROYECTO
79
Si bien no se sigue un plan específico de prueba, se tiene en cuenta, a lo
largo del proyecto, cada punto que se debe evaluar y la forma en la cual se
llevan a cabo dichas pruebas.
Las primeras pruebas que se comienzan a consumar son ensayos
individuales de los procedimientos aislados y utilizando data de prueba. De
esta forma se comprueba la integridad de las bases de datos y se asegura la
buena ejecución de los procedimientos básicos de las ventanas. De la misma
manera, se verifica que las ventanas estén conectadas correctamente y con
los parámetros necesarios según el caso. Finalmente, se prueba la
integración entre los sub-módulos (aplicaciones) existentes en el diseño y se
cerciora que el sistema funciona correctamente de forma global y las
aplicaciones no tienen problemas de interconexión entre ellas.
Posteriormente, se solicita a algunas personas que laboran en B.F.G.P.
Ingenieros, para que trabajen con el sistema; éstos ofrecen sus comentarios
y se realizan las modificaciones pertinentes. Esta prueba permite obtener
otros puntos de vista, los cuales moldean las aplicaciones de forma tal que
se hacen más amigables y con una mejor adaptación al usuario.
Por último, se realizan las pruebas de integración al sistem a de J.D. Edwards
y se corrobora que las aplicaciones desarrolladas, se adaptan a los
estándares de este sistema. Se chequea el software desde el punto de vista
Capítulo III. DESARROLLO DEL PROYECTO
80
de un usuario común de J.D. Edwards (esta es la forma en la cual se utiliza el
sistema en caso de ser implementado en algún organismo público) y se
verifica que la seguridad del sistema está íntegra, por lo tanto, que el sistema
es confiable.
Es importante aclarar que las pruebas al sistema seguirán desarrollándose
en el tiempo y se realizarán constantemente, debido a que ningún sistema es
perfecto y siempre se pueden encontrar fallas y errores, los cuales deben ser
corregidos. De esta forma y con un chequeo constante del mismo, se puede
tener un sistema cada vez mejor.
Capítulo IV. RESULTADOS
Capítulo IV: Resultados
La herramienta desarrollada en este trabajo, cuenta con varias aplicaciones
que permiten la ejecución de los pasos necesarios para llevar a cabo la
gestión del presupuesto de un organismo público.
Los resultados derivados de este trabajo, se reflejan en dicha herramienta y
se basan en el diseño detallado del sistema (véase la sección III.3.), producto
de la metodología empleada en este trabajo. Dichos resultados evidencian el
cumplimiento de los objetivos planteados. Está dividida en procesos que
representan las fases existentes para completar el presupuesto de un
organismo.
La plataforma tecnológica en la cual se basa el proyecto, son los ERP de
OneWorldTM, los cuales son ofrecidos por J.D. Edwards. Esta plataforma
permite ver los resultados de forma fácil y amigable, as í como controlar el
acceso a las personas encargadas del manejo de la gestión presupuestaria
según su cargo y su responsabilidad en el organismo. Con formatos
estandarizados de OneWorldTM, la adaptación del usuario al sistema, se hace
más sencilla.
Capítulo IV. RESULTADOS
82
La seguridad que se le aplica al sistema ocupa un papel de gran importancia
para permitir la transparencia y separar las funciones por parte de las
personas encargadas de la gestión presupuestaria. Gracias a los
mecanismos implementados y la manera de emplear la seguridad en J.D.
Edwards en las aplicaciones programadas, se puede confiar en los datos que
refleja el sistema, evitar en lo posible la malversación de fondos y en caso
que ésta exista, conocer el(los) responsable(s) de dicha malversación.
En primer lugar, se ejerce un tipo de seguridad del sistema como tal, en el
cual no se puede ejecutar una fase presupuestaria sin la aprobación de la
fase que le antecede. Por ejemplo: no se puede causar una partida si su
compromiso no ha sido aprobado aún. Esto es igual a indicar que ninguna
fase se considera “válida” sin su previa aprobación. De esta forma se evita
que se puedan generar estafas en la asignación de partidas para luego ser
ejecutadas, debido a que dichas asignaciones deben ser autorizadas (a
través del sistema) por parte de las autoridades del organismo.
Para asegurarse que cada quien ejerza la función que le corresponde en la
gestión presupuestaria de un organismo y poder detectar a los responsables
del manejo de partidas en el sistema, se utiliza la seguridad que ofrece J.D.
Edwards (véase el capítulo III). Para ello, cada aplicación del sistema puede
ser accedida únicamente por aquellos usuarios que tengan la autorización de
hacerlo, inclusive se puede dar el caso que se acceda a una ventana
Capítulo IV. RESULTADOS
83
específica, pero que no se puedan ejecutar todas las funciones de dicha
ventana. Por ejemplo: si una persona entra en el modo de aprobación de
presupuesto, no tendría la autorización de modificar nada en la formulación
del mismo, sólo podría comentar sobre ella.
Con estos dos métodos implementados, se protege la integridad del
presupuesto y se resguardan sus principios . De la misma forma, se cumple
con uno de los objetivos planteados, porque uno de los puntos más
importantes en la formulación y ejecución de los presupuestos públicos, es la
garantía de saber que los fondos que se manejan están asegurados y
minimizar, en lo posible, los riesgos de malversación de los fondos, los
cuales, en el caso de los organismos públicos, son del estado.
A continuación se describen los procesos fundamentales para poder llevar a
cabo la gestión presupuestaria. Los procesos representan la base de la
herramienta y de acuerdo a los requerimientos y funciones existentes para
poder completar la ejecución de éstos, se desarrollan los demás
procedimientos y formas que posee la herramienta.
Capítulo IV. RESULTADOS
84
IV.1 Procesos fundamentales del sistema
Las aplicaciones del sistema están basadas en los procesos que se realizan
para la gestión presupuestaria y cada ventana perteneciente a dichas
aplicaciones permite la ejecución, o parte de ella, de varios procesos. Esto
significa que las aplicaciones realizan varios procedimientos que además,
tienen relación entre sí y las funciones que poseen las ventanas permiten
navegar entre ellas para cumplir con los procesos de acuerdo al tipo de
usuario que maneje el sistema y su autorización para disponer, manejar y
ejecutar dichos procedimientos.
Si bien lo anterior es cierto, a continuación se explican los procesos
principales para ejecutar cabalmente la gestión presupuestaria y los cuales
son piezas fundamentales en la codificación y el desarrollo del sistema
realizado. Todos los demás procesos, eximiendo los mencionados a
continuación, están ligados y se procesan en función de la ejecución de los
siguientes procesos.
Estos procesos comienzan con la formulación del presupuesto, su respectiva
aprobación. Continúa con las fases de la ejecución, en las cuales se deben
realizar compromisos, causaciones y pagos de las asignaciones que tiene el
presupuesto aprobado, cada fase de la ejecución debe pasar por un proceso
Capítulo IV. RESULTADOS
85
de aprobación. Adicionalmente, existe un proceso de modificaciones de un
presupuesto aprobado o situaciones extraordinarias.
IV.1.1. Formular el presupuesto
La forma en la cual el sistema permite la formulación del presupuesto se
basa en la creación y composición de programas y subprogramas
pertenecientes al presupuesto que se está formulando, así como en las
asignaciones de partidas y subpartidas a los diferentes programas y
subprogramas de dicho presupuesto. Para ello, deben existir los
componentes de las asignaciones, por ende, el sistema cuenta con procesos
que permiten la creación de presupuestos, programas, subprogramas,
partidas y subpartidas.
Para poder crear los presupuestos, con sus programas y subprogramas, no
es necesario asignarles partidas, se puede navegar a través de un
presupuesto (que no haya sido aprobado) para añadir programas y
subprogramas. También, se pueden ver los programas de un presupuesto y
los subprogramas de un programa específico.
Capítulo IV. RESULTADOS
86
En la figura 14, se muestra la ventana en donde se obtiene todos los
programas pertenecientes al presupuesto seleccionado por un usuario y de
acuerdo a los parámetros de búsqueda proporcionados por el mismo.
Figura 14 – Programas de un presupuesto.
Fuente: Elaboración propia.
Una vez creados los programas y subprogramas, se pueden asignar las
partidas y subpartidas, según corresponda y según requiera el(los)
responsable(s) de la formulación del presupuesto por parte del organismo.
Capítulo IV. RESULTADOS
87
Se pueden asignar partidas a los programas o a los subprogramas, de la
misma forma y una vez asignada una partida, se pueden asignar subpartidas
(de la partida ya asignada) tanto a programas como a subprogramas. Esto
permite cierta flexibilidad para formular y asignar las partidas necesarias,
pero como no ha sido aprobado el presupuesto, no influye en la seguridad
del sistema para el manejo de los fondos.
En la figura 15, se presentan las asignaciones de partidas a un programa
específico que pertenezca a un presupuesto. Para las demás asignaciones
(partida-subprograma, subpartida-programa y subpartida-subprograma), se
tienen ventanas similares a la presentada en la figura 15 (véase la figura 16
para las asignaciones de partidas a subprogramas).
Una vez seleccionada la asignación o cuando se decide realizar una nueva
asignación de una partida a un programa específico, el usuario puede
modificar las especificaciones de una asignación, especialmente, la cantidad
de dinero asignada para la partida seleccionada en el programa escogido. El
sistema maneja una alarma para impedir que el monto asignado para la
asignación sea mayor a la cantidad total de la partida seleccionada, de esta
manera se evitan asignaciones sobrevaluadas en el mismo momento de
formularlas.
Capítulo IV. RESULTADOS
88
Figura 15 – Asignaciones de un programa específico.
Fuente: Elaboración propia.
La figura 17 expone la forma en la cual se asigna una partida a un programa
perteneciente a un presupuesto. Esta ventana también se utiliza para ver las
especificaciones de una asignación que se haya realizado. Para las demás
asignaciones (partida-subprograma, subpartida-programa y subpartida-
subprograma), se tiene una ventana similar a la mostrada en la figura 17.
Capítulo IV. RESULTADOS
89
Figura 16 – Asignaciones de un subprograma específico.
Fuente: Elaboración propia.
Cabe destacar que todos los procedimientos referentes al proceso de
formulación se pueden ejecutar únicamente cuando el presupuesto, sus
programas (o subprogramas) y asignaciones aún no han sido aprobados. La
razón por la cual esto se controla, es porque una vez aprobado un
presupuesto, no se pueden realizar modificaciones en la distribución de los
fondos del organismo, a menos que se realice una modificación
extraordinaria (véase la sección IV.1.4.).
Capítulo IV. RESULTADOS
90
Figura 17 – Asignación de una partida a un programa.
Fuente: Elaboración propia.
IV.1.2. Aprobar la formulación del presupuesto
Una vez formulado el presupuesto, sus programas y asignadas las partidas
correspondientes, el sistema permite, a las personas responsables, aprobar
o desaprobar la gestión de formulación llevada a cabo anteriormente. El
Capítulo IV. RESULTADOS
91
sistema muestra las opciones para aprobar o desaprobar según la voluntad y
el criterio de quien está encargado de la aprobación.
Cabe destacar que la única forma existente para poder llevar a cabo la
ejecución de un presupuesto, es tras la aprobación por parte del organismo y
posteriormente por el ente (organismo) responsable de dicho organismo.
Este sistema sólo alcanza para la aprobación interna de parte del organismo,
la aprobación externa, se lleva a cabo de la forma como el ente externo
acostumbra a hacerlo y al cual se le entrega un informe, producto de los
reportes del sistema.
En el sistema, la aprobación se realiza en las mismas ventanas utilizadas
para la formulación, pero en un modo (vista) diferente. Durante este proceso,
se pueden aprobar los programas, subprogramas, asignaciones e incluso el
presupuesto completo; pero se impide modificar cualquier dato referente a la
formulación en sí. Esto significa que el responsable de aprobar, no tiene la
opción de modificar la formulación ni de crear ningún tipo de asignación en el
presupuesto. Esto último, se controla con la seguridad de usuario que posee
J.D. Edwards, en la cual se permite el acceso a las aplicaciones para las
cuales el usuario tiene autorización.
La figura 18 muestra la ventana en la cual el usuario responsable de la
aprobación de una asignación, tiene la posibilidad de aprobar o desaprobar
Capítulo IV. RESULTADOS
92
dicha asignación. El usuario accede a la ventana y observa la asignación de
la misma forma que se observa en la fase de formulación (véase la sección
IV.1.1.), pero en el modo de aprobación en el cual aparece un botón para
aprobar esta asignación y además, tiene la posibilidad de comentar dicha
aprobación.
Figura 18 – Aprobación de una asignación.
Fuente: Elaboración propia.
Capítulo IV. RESULTADOS
93
En esta aplicación y para tener un proceso efectivo en el manejo de los
datos, se cuenta con varios niveles de aprobación, de forma tal que si se
aprueba un nivel, todos los casos de niveles inferiores que estén ligados al
nivel en aprobación, también cuenten con la misma suerte, es decir: que si
se aprueba un subprograma, todas las asignaciones de partidas y
subpartidas formuladas para ese subprograma, sean aprobadas
automáticamente. En la tabla 2, se indica los casos posibles de aprobación y
cómo se relacionan según su nivel.
IV.1.3. Modificar la formulación de un presupuesto aún no aprobado
La manera en la cual se modifica cualquier instancia que aún no ha sido
aprobada de un presupuesto, es equivalente a la forma en la cual ésta se
formula. Simplemente, el usuario debe seleccionar el programa,
subprograma, partida u otro que desee modificar y realizar sus
modificaciones.
Cabe señalar que una vez aprobada una instancia, el sistema no permite
modificaciones en su formulación. Además, las partidas que ya hayan sido
asignadas en cualquier presupuesto aprobado, no podrán ser modificadas.
Capítulo IV. RESULTADOS
94
Tabla 2 – Casos de aprobación según su nivel.
Presupuesto APBDO
Programa //////////// APBDO
Subprograma //////////// //////////// APBDO
Programa-
Partida
////////////
////////////
APBDO
Subprograma-
Partida
////////////
////////////
////////// ////////////
APBDO
Programa-
Subpartida
////////////
////////////
////////////
APBDO
Subprograma-
Subpartida
////////////
////////////
//////////
////////////
////////////
////////////
APBDO
Leyenda:
APBDO = Aprobado por el usuario.
//////////// = También aprobado, automáticamente.
Fuente: Elaboración propia.
Por ejemplo: si un programa está aprobado, no se pueden realizar
modificaciones a ningún subprograma ni asignación que tenga que ver con
dicho programa, aún cuando, el presupuesto no esté todavía aprobado.
La ventana en la cual el usuario tiene la opción de modificar un programa
que aún no ha sido aprobado, se exhibe en la figura 19.
Capítulo IV. RESULTADOS
95
Figura 19 – Modificación de un programa no aprobado.
Fuente: Elaboración propia.
IV.1.4. Realizar modificaciones extraordinarias
Cuando el presupuesto es aprobado, comienza a desarrollarse su fase de
ejecución y a partir de este momento, se prohíbe cualquier cambio no
autorizado en su formulación. Los cambios que se realizan deben cumplir un
proceso en el cual se cumplan las normas de modificaciones
Capítulo IV. RESULTADOS
96
presupuestarias, de esta forma, se facilita el control de los fondos y se
garantiza que la ejecución presupuestaria se basa y se lleva a cabo de
acuerdo a su propia formulación.
El sistema permite todos los casos de modificaciones presupuestarias,
siempre y cuando exista una aprobación por parte del organismo, la cual
debe ser registrada para poder ejecutar dicha modificación. Lo primero que
debe hacer el usuario es seleccionar la(s) asignación(es) para la(s) cual(es)
se requiere una modificación.
Luego de tener la asignación seleccionada, el usuario debe especificar qué
tipo de modificación presupuestaria desea requerir. Una vez seleccionado si
es un traspaso, una rectificación, insubs istencia o un crédito adicional, se
debe indicar el monto a modificar (bien sea pedir o quitar de una partida).
A través de la figura 20, se observa la manera como los encargados de la
parte de ejecución, específicamente de modificaciones extraordinarias,
deciden el tipo de modificación y la asignación que desean cambiar. Una vez
seleccionada la asignación, el usuario registra el monto y la forma en la cual
desea que se realice dicha modificación (véase la figura 21).
Capítulo IV. RESULTADOS
97
Figura 20 – Selección para modificaciones extraordinarias.
Fuente: Elaboración propia.
Para poder hacer efectiva la modificación requerida, el organismo debe
autorizar el aumento o disminución (según sea el caso) de los fondos ya
aprobados. Para esto, el sistema dispone de una parte que permite la
autorización de dichos cambios y en los cuales una persona se hace
responsable de aceptar las reformas a la formulación.
Capítulo IV. RESULTADOS
98
Figura 21 – Realización de una petición extraordinaria.
Fuente: Elaboración propia.
La forma de hacer esto, es similar a la aprobación de la formulación del
presupuesto. El usuario responsable de aprobar esta situación extraordinaria
puede navegar a través de los programas y observar todas las peticiones
extraordinarias hechas en el presupuesto en cuestión, luego decidir si
aprueba o no esta(s) petición(es). La manera en la cual se puede aprobar
una petición extraordinaria se muestra en la figura 22.
Capítulo IV. RESULTADOS
99
Figura 22 – Aprobación de situación extraordinaria.
Fuente: Elaboración propia.
Es importante destacar que una vez comprometida una partida, no existe la
posibilidad de modificar su formulación, ya que la ley no lo permite y el monto
destinado para la partida es inmodificable, una vez que ésta se haya
comenzado a ejecutar. Para controlar esto, la herramienta maneja una
alarma que le notifica al usuar io cuando la asignación que ha seleccionado
para modificar, ya está involucrada en un compromiso.
Capítulo IV. RESULTADOS
100
IV.1.5. Ejecutar Compromisos
La condición principal para poder realizar un compromiso, es que el
compromiso se realice en el presupuesto vigente y que éste a su vez, esté
aprobado. Por ende, el sistema solamente permite ejecutar un compromiso si
se cumplen estas condiciones.
El módulo de ejecución permite el acceso al sistema de todas aquellas
personas que trabajan con la ejecución de las asignaciones de partidas y
subpartidas a los diferentes programas y subprogramas pertenecientes al
presupuesto en ejecución. Para poder ejecutar un compromiso, se debe
acceder a las asignaciones de la misma forma como se navega a través de
un presupuesto en su etapa de formulación, pero sin la posibilidad de realizar
modificación alguna.
El usuario puede observar todos los compromisos realizados a una
asignación seleccionada en una ventana (véase la figura 23), la cual muestra
además, el monto total que ha sido comprometido para dicha asignación.
Como el usuario se encuentra en el módulo de ejecución, se le ofrece la
posibilidad de comprometer la partida que está asignada (en caso que ésta
aún no esté comprometida en su totalidad). En la figura 24 se enseña la
ventana en la cual un usuario responsable de la ejecución, compromete la
Capítulo IV. RESULTADOS
101
asignación de una partida en un programa de un presupuesto aprobado. La
ventana para realizar compromisos cumple la misma función para
comprometer cualquier otro tipo de asignación (subpartida-programa, partida-
subprograma y subpartida-subprograma). Esta ventana cuenta con una
alarma de control que impide al usuario comprometer una suma de dinero
mayor a la que está asignada en el presupuesto aprobado, de esta forma, se
evita el compromiso de fondos que no están estipulados en este
presupuesto.
Figura 23 – Compromisos de una asignación.
Fuente: Elaboración propia.
Capítulo IV. RESULTADOS
102
Figura 24 – Ejecución de un compromiso.
Fuente: Elaboración propia.
Cabe señalar, que todo compromiso, luego de ser ejecutado, debe ser
aprobado para que tenga validez y se pueda continuar con la etapa siguiente
en el proceso de ejecución presupuestaria. Para ello el sistema cuenta con
un proceso de aprobación de la ejecución (véase la sección IV.1.8. ).
Capítulo IV. RESULTADOS
103
IV.1.6. Ejecutar Causaciones
Causar las partidas es un procedimiento que necesita un control por parte del
sistema, porque una vez causada la partida (o subpartida), el organismo está
en la obligación legal de pagar la asignación correspondiente.
La condición que se debe cumplir para crear una causación, es la existencia
de un compromiso aprobado dentro del presupuesto vigente. El sistema
permite al usuario seleccionar cualquiera de los compromisos aprobados y
utilizarlo para su respectiva causación.
Para ejecutar una causación, se debe acceder a las asignaciones de la
misma forma como se navega a través de un presupuesto en su etapa de
formulación, pero sin la posibilidad de realizar modificaciones. Una vez
seleccionada la asignación, se debe acceder a su compromiso, esto se debe
a que la causación depende del monto comprometido y no del monto
asignado.
En la figura 25 se exhibe la ventana en la cual el usuario puede causar una
partida ya comprometida y aprobada por el organismo. En esta ventana, el
usuario causa la cantidad correspondiente y asume la responsabilidad de sus
acciones, sin embargo, el sistema controla el monto a causar, de modo que
no sea mayor al monto comprometido para dicha asignación.
Capítulo IV. RESULTADOS
104
Figura 25 – Ejecución de una causación.
Fuente: Elaboración propia.
Cabe señalar, que toda causación, luego de ser registrada, debe ser
aprobada para que tenga validez y así, poder continuar con la etapa
siguiente en el proceso de ejecución presupuestaria (véase la sección
IV.1.8.).
Capítulo IV. RESULTADOS
105
IV.1.7. Ejecutar Pago
El último paso que tiene una asignación de un presupuesto durante su
ejecución, es su pago. Éste se lleva a cabo de la misma forma como se
compromete y se causa una partida, debe cumplir con los mismos requisitos
y la forma existente en el sistema, para acceder al pago, es igual a las
formas anteriores.
Es necesario que la causación de la partida esté aprobada y que se tengan
los datos correctos sobre el pago, como lo son: receptor del pago, forma de
pago, número de cheque, banco, monto pagado y otras. Es importante
destacar que una causación se puede pagar en varias partes; por lo cual, el
sistema controla el monto total a pagar, indica la cantidad faltante y alarma
en caso que se intente exceder el monto requerido para el pago. Con esta
última alarma, se impide la creación de un gasto extra, lo cual evita la
malversación (voluntaria o involuntaria) de fondos.
La ventana que exhibe el registro de un pago en el sistema se ilustra en la
figura 26. En esta ventana, el usuario simplemente registra todos los datos
relacionados con el pago de las asignaciones causadas.
Capítulo IV. RESULTADOS
106
Figura 26 – Ejecución del pago.
Fuente: Elaboración propia.
IV.1.8. Aprobar la ejecución del presupuesto
Una vez comprometidas las partidas, es necesario aprobar dichos
compromisos. Esto se realiza en el módulo de aprobación, desde el cual, el
usuario responsable de la aprobación, accede a la ventana que muestra el
compromiso ya existente y se le ofrece la oportunidad de aprobarlo o
desaprobarlo, según lo considere. De esta forma, las personas que se
Capítulo IV. RESULTADOS
107
encargan de realizar dichos compromisos, pueden revisar sobre el
desempeño que han tenido sus acciones. En la figura 27 se muestra la
ventana que se le presenta al responsable de las aprobaciones de los
compromisos realizados y en la cual se buscan todos los compromisos que
aún no estén aprobados, según los parámetros que ingresa el usuario. Una
vez seleccionado un compromiso, se presenta una ventana (véase la figura
28) en la cual se decide, a través de un botón, si se aprueba o se
desaprueba el compromiso seleccionado anteriormente
Figura 27 – Búsqueda de compromisos para su aprobación.
Fuente: Elaboración propia.
Capítulo IV. RESULTADOS
108
Figura 28 – Aprobación de compromisos.
Fuente: Elaboración propia.
Para asegurar la integridad en la ejecución presupuestaria y debido al hecho
que puede haber responsables distintos según la fase en cuestión, el acceso
al sistema es controlado dependiendo de la etapa que se desee aprobar.
Esto significa, que una persona que no esté autorizada para aprobar los
pagos de las partidas, no tendría la posibilidad de ingresar a esta parte del
módulo, inclusive si tiene la autorización de entrar al módulo para aprobar
por ejemplo, una causación.
Capítulo IV. RESULTADOS
109
Cabe señalar que desde esta fase de la ejecución, no es posible
comprometer, causar ni ejecutar pagos referentes a ningún presupuesto, ni
siquiera, aquellos que ya estén aprobados. Tampoco se está en la capacidad
de modificar la formulación de los presupuestos, únicamente autorizar sobre
la ejecución y sus pasos.
IV.2 Reportes generados
Si bien el sistema permite la navegación a través de la aplicación, de
acuerdo la etapa del presupuesto que se ejecuta y a la autorización y
responsabilidad otorgada al usuario que utiliza el sistema, es necesario que
los resultados más importantes de la gestión realizada por los diferentes
usuarios que acceden al sistema, se muestren claramente en forma de
resultados. Con estos resultados, se puede justificar los procesos ejecutados
y las tareas que se desarrollan en cada fase.
La herramienta presentada en este trabajo, tiene la capacidad de generar
reportes de las operaciones básicas que se realizan y se basan en la
combinación de los procesos ejecutados y los resultados obtenidos durante
la gestión del presupuesto. Estos reportes muestran en forma de informe los
datos que se desean exponer para ser revisados por alguna autoridad en el
Capítulo IV. RESULTADOS
110
momento de presentar el presupuesto, bien sea para su aprobación, o para
la justificación de su ejecución.
Los siguientes reportes, se llevan a cabo con las herramientas que ofrecen
los Tools de OneWorldTM, a través de “aplicaciones batch” y se imprimen en
el programa Acrobat Reader de Adobe (http:www.adobe.com/acrobat).
- Programas detallados .
Este reporte permite al usuario ver todos los programas de un presupuesto
independientemente de la fase en la cual se encuentre. En este reporte se
puede observar el monto total que ha sido asignado a cada programa del
presupuesto, el número de subprogramas y asignaciones por programa que
tiene el presupuesto. En caso que el presupuesto ya esté aprobado, se
refleja el monto total, por programa, que está comprometido, causado y
pagado.
Con este informe, se tiene una idea general del presupuesto en cuestión, su
estado y los programas que lo conforman. Especialmente, se observan los
montos asignados y ejecutados en cada programa, lo cual permite controlar y
justificar la distribución de los fondos del organismo que ejecuta la gestión
del presupuesto.
Capítulo IV. RESULTADOS
111
- Partidas y subpartidas por Programas.
Para tener la información necesaria acerca de los gastos y los fundamentos
del monto asignado a las partidas y subpartidas de cada programa, se
genera un reporte que muestra las partidas del presupuesto con el monto
que ha sido asignado para cada uno de los programas que existen. Estas
partidas, se pueden encontrar desglosadas por las subpartidas que las
conforman. El reporte además, expone el monto total asignado a cada
partida y subpartida (este es la suma de las asignaciones a cada programa).
Cabe destacar, que no siempre el total del monto asignado a una partida es
igual a la suma del monto asignado a sus subpartidas, esto se debe al hecho
que existe la posibilidad de asignar una partida directamente al programa
que se formula.
Con este reporte, se entiende el origen de los fondos y se obtiene el
desglose del total presupuestado. Además, se observan todas las partidas de
un presupuesto en un solo informe, operación que no se puede ejecutar
desde las ventanas del sistema.
Capítulo IV. RESULTADOS
112
- Detalles de la ejecución, por programa.
Una vez aprobado el presupuesto y comenzada su ejecución, se puede
generar un reporte que presenta el estado en el cual se encuentran las
asignaciones del presupuesto. El informe está estructurado por programas,
de los cuales se reflejan cada una de sus asignaciones. Para cada
asignación, muestra los compromisos, causaciones y pagos que se han
venido desarrollando durante su ejecución. La información suministrada en
cada uno de las fases de la ejecución de la asignación es el monto
(comprometido, causado o pagado), la fecha de ejecución, si está o no
aprobada, y el responsable de haber ingresado al sistema los datos de la
fase ejecutada.
- Modificaciones extraordinarias.
Debido a que las modificaciones extraordinarias del presupuesto es un tema
delicado en la gestión del mismo, porque se refiere a cambios en la
asignación de fondos tras su aprobación, la herramienta genera un reporte
que refleja todas las modificaciones presupuestarias realizadas y aprobadas.
En este reporte se observan las asignaciones que han sido modificadas en
cada programa. Para cada una de las asignaciones, se muestra(n) la(s)
modificación(es), describiendo su tipo (rectificación, insubsistencia, traspaso
Capítulo IV. RESULTADOS
113
o crédito adicional), la fecha, el monto modificado, el responsable de ésta, si
está o no aprobado el cambio y el código de otro programa y de otra
asignación que estén involucradas en la modificación (en caso que exista
otra asignación involucrada).
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
Capítulo V. Conclusiones y recomendaciones
V.1. Conclusiones
Una vez concluido el trabajo final de grado, se logra presentar una
herramienta que engloba el tema planteado y solventa en buena parte el
problema existente, problema por el cual se inicia esta tesis. Tras haber
finalizado las fases comprendidas en este trabajo, se consigue reflejar el
resultado de la investigación, a través de una herramienta compuesta por
varios módulos interrelac ionados entre sí, con capacidad de operar de
manera segura y amigable la gestión presupuestaria de un organismo
público descentralizado en Venezuela, garantizando la transparencia y
confiabilidad de los datos y cumpliendo de esta forma, con los objetivos de la
investigación.
Estudiar el tema presupuestario, la definición del presupuesto, los tipos de
presupuestos que existen, sus categorías programáticas , las fases
necesarias para su cumplimiento y las leyes principales que rigen la gestión
presupuestaria en Venezuela, permite conocer a fondo el tema para la
investigación y hacer un análisis claro sobre éste, de modo que se facilita el
diseño de la estructura del sistema creado, los formatos utilizados, los
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
115
módulos que componen dicho sistema y los principios de seguridad que se
deben cumplir.
Investigar sobre el tema del presupuesto en Venezuela, a través de
entrevistas y visitas a diversos organismos del ámbito público, beneficia la
realización del diseño de la herramienta desarrollada, porque se conoce y se
tiene en cuenta la forma de trabajo y las acciones más importantes y
comunes que se llevan a cabo durante la gestión presupuestaria, así como
las fallas principales que se presentan en la ejecución de esta actividad. Este
aporte es de gran importancia, porque es una experiencia vivida que permite
captar factores de alta importancia para el tema investigado.
Conocer los estándares, las bases del funcionamiento y el lenguaje de
desarrollo que tienen los ERP de J.D. Edwards, permite completar la fase de
diseño de la herramienta, ya que se comprenden los esquemas de seguridad
y la forma de almacenamiento para el diseño de las tablas y vistas lógicas
empleadas. De la misma manera, contribuye con el desarrollo y codificación
de la herramienta, porque se entiende la manera en la cual se programan las
aplicaciones, las ventanas disponibles para la codificación y las ventajas y
opciones que brinda J.D. Edwards.
Aplicar la metodología RPM, basada en el lenguaje UML, suministra los
instrumentos necesarios para desarrollar el proceso de investigación, cumplir
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
116
con las fases requeridas para lograr el objetivo planteado de forma efectiva y
en el tiempo estipulado para ello. Adicionalmente, proporciona los diagramas
derivados de cada fase, los cuales ilustran las bases de la herramienta a
través de gráficos claros.
Combinar todas las fases del proyecto, los conocimientos adquiridos y la
plataforma tecnológica con la metodología implementada, genera el
resultado final de este trabajo y el cual se manifiesta por medio de una
herramienta capaz de manejar los presupuestos públicos de forma efectiva y
con el resguardo de un sistema confiable y seguro como lo es OneWorldTM.
De la misma manera, OneWorldTM cuenta ahora, con un nuevo módulo que
le permite aumentar su alcance y expandir las aplicaciones que ofrece.
Esta herramienta cuenta con cuatro aplicaciones o sub-módulos. El primero
es el sub-módulo de formulación, con el cual se elabora el presupuesto y se
realizan las asignaciones de fondos que sean necesarias para la ejecución
futura del presupuesto. Otro sub-módulo es el de aprobación, desde esta
aplicación se generan las autorizaciones obligatorias para validar las
acciones de los usuarios que manejan la gestión presupuestaria, estas
aprobaciones incluyen la formulación y ejecución de las etapas requeridas
durante el proceso presupuestario. Adicionalmente, se cuenta con la
aplicación de ejecución del presupuesto, la cual navega a través de un
presupuesto para ejecutar compromisos, causaciones y pagos de las
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
117
asignaciones anteriormente aprobadas. Por último, se cuenta con un sub-
módulo de situaciones extraordinarias, para realizar cualquier modificación
(rectificación, traspaso, insubsistencia o crédito adicional) solicitada en un
presupuesto aprobado. De todas estas aplicaciones, el sistema produce
reportes de manera tal, que se presenten los datos de forma ordenada para
su revisión.
Con los resultados obtenidos del trabajo desempeñado en esta tesis de
grado, los organismos del ámbito público en Venezuela pueden optar por un
sistema ERP que cuenta con aplicaciones para gestionar y controlar sus
presupuestos en todas sus fases de desarrollo.
V.2. Recomendaciones
Las recomendaciones que se realizan para mejorar la herramienta
desarrollada en este trabajo son:
- Incluir la categoría programática correspondiente a proyectos, permite
una mayor especificación de la herramienta para verificar el origen de
los fondos y conocer más en detalle los programas de un presupuesto.
Dichos proyectos deben incluirse en la formulación del presupuesto
como parte de los programas y subprogramas y deben estar en
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
118
capacidad de tener asignaciones de partidas y subpartidas, de misma
forma como ocurre con los programas y subprogramas .
Adicionalmente, controlar la ejecución de los proyectos que tenga el
presupuesto.
- Añadir los detalles sobre las obras que realiza un organismo, dentro
de los programas y subprogramas de su presupuesto, aumenta el
alcance de la herramienta, porque permite tener el detalle de los
fondos y un mayor control al momento de ejecutarse. Esto se debe a
que la ejecución de obras se hace con montos menores a aquellos
que se asignan para la ejecución de programas y subprogramas, los
cuales son más generales que las obras.
- Especificar en detalle las actividades y subactividades necesarias para
cumplir con los programas y subprogramas de un presupuesto,
explicar la forma en la cual se deben llevar a cabo dichas actividades y
asignar los costos para su ejecución. Dividir estas actividades en
específicas, centrales, comunes, según sea el caso. Todo esto, añade
funcionalidad a la herramienta y contribuye con la transparencia de la
gestión presupuestaria.
- Incluir los documentos de valuaciones que generan los
departamentos de los organismos y/o las compañías contratadas para
la ejecución, permite conocer el origen de la ejecución a través de un
documento generado y el cual debe ser acatado para aumentar el
control durante el proceso de presupuesto.
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
119
- Añadir un módulo para agregar la planificación del presupuesto, previo
a su formulación, de modo que éste, se integre con la formulación y
ejecución del presupuesto para así garantizar, el cumplimiento de los
objetivos de la planificación.
- Integrar otras tablas de bases de datos que posee OneWorldTM de
forma tal que la aplicación esté interconectada con tablas de clientes,
compañías, usuarios y otros campos y requerimientos que tenga la
herramienta. De la misma forma, las aplicaciones existentes, también
pueden utilizar las bases de datos creadas para este proyecto. Esto
genera una integración mayor entre las herramientas que posee J.D.
Edwards, lo cual aumenta su funcionalidad y reduce la complejidad de
los procesos de sus módulos.
- Permitir la generación de presupuestos, programas y asignaciones
para períodos de tiempo variados, como por ejemplo, un presupuesto
que dure dos años. Esto admite casos distintos al presupuesto anual,
los cuales se pueden presentar en situaciones extraordinarias o a
través de leyes especiales, como la ley conocida como “ley paraguas”.
- Crear una herramienta similar a la presentada en este trabajo, con los
mismos formatos y formas de manejo presupuestario, pero que
gestione y controle el presupuesto público de entes centralizados, los
cuales, deben utilizar los fondos que le otorga el gobierno central para
poder operar su presupuesto. Esta funcionalidad, proporciona a J.D.
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
120
Edwards con una combinación de herramientas presupuestarias para
ser utilizadas en cualquier organismo público.
- Añadir nuevos reportes, como reflejo de las actividades realizadas en
el presupuesto tras utilizar la herramienta, beneficia la exposición de
los resultados, lo cual favorece la justificación de las acciones
cumplidas (tanto en la formulación como la ejecución). Entre los
principales reportes que se recomiendan crear se encuentran los
siguientes:
?? Hacer un reporte con las especificaciones de los
subprogramas, que muestre la formulación de los
subprogramas y las asignaciones de partidas. Con este
reporte, se observa de forma más especificada las
categorías del presupuesto y las asignaciones que éstas
tienen.
?? Crear un reporte que resuma toda la formulación de un
presupuesto, desde la presentación de sus programas
hasta la de la más mínima asignación. Este reporte es útil
para ser presentado en el ente aprobador del presupuesto,
una vez el organismo haya aprobado su propio
presupuesto.
Capítulo V. CONCLUSIONES Y RECOMENDACIONES
121
?? Crear reportes con gráficos y utilizando estadísticas para
comparar los procesos y las acciones en cualquier etapa
de la gestión presupuestaria.
- Permitir la creación de reportes según los requerimientos del usuario,
de esta forma, el usuario puede realizar los reportes de acuerdo a sus
necesidades tras ingresar parámetros seleccionados por el mismo
usuario.
Referencias Bibliográficas
122
Referencias Bibliográficas
?? AVPP (1995). Aspectos Conceptuales y Metodológicos del Presupuesto
Público. Caracas: Asociación Venezolana de Presupuesto Público, 3ª
edición.
?? CLAD (1979). Las Empresas Estatales en América Latina. Caracas:
Centro Latinoamericano de Administración para el Desarrollo.
?? González Oliveiros, J. (1988). Presupuesto Público y Empresarial.
Caracas: 1988.
?? JDEDWARDS (2000). Development tools . Denver, Colorado: J.D.
Edwards World Source Company.
?? JDEDWARDS (2000-2001). Página oficial de J.D. Edwards, [en línea].
Denver, Colorado: JDEdwards World Source Company. Disponible en:
http://www.jdedwards.com. [2002, marzo].
?? Larman, C. (1998). Applying UML and Patterns. New Jersey: Prentice
Hall Inc, Upper Saddle River.
Referencias Bibliográficas
123
?? Ley Orgánica (2000, 5 de septiembre). Ley Orgánica de la Administración
Financiera del Sector Público 2000. Caracas: Gaceta Oficial N° 37.029.
?? ONAPRE (2002). Página oficial de la ONAPRE. [en línea]. Caracas:
Oficina Nacional de Presupuesto (ONAPRE). Disponible En:
http://www.ocepre.gov.ve/. [2002, marzo].
?? ORACLE (2002). Página oficial de Oracle. [en línea]. Redwood City,
California: Oracle Corporation. Disponible en: www.oracle.com. [2002,
octubre].
?? Peña, J. (2000). Sistema de Financiamiento con Estudios de Variables
Crediticias para ser integrado al Software ERP de JDEdwards. Trabajo
de Grado, Ingeniería de Sistemas en la Universidad Metropolitana,
Caracas.
?? Presupuesto FONDUR (2000). Presupuesto de ingresos y gastos 2000
reformulado. Caracas: Fondo Nacional de Desarrollo Urbano (FONDUR).
?? SAP (2002). Página oficial de SAP. [en línea]. Waldorf: SAP. Disponible
en: www.sap.com. [2002, octubre].
Referencias Bibliográficas
124
Otra bibliografía recomendada.
?? Ley de Presupuesto (2000, 11 de diciembre). Ley de presupuesto para el
ejercicio fiscal 2001. Caracas: Gaceta Oficial N° 5.505 Extraordinario.
?? Lyden Fremont, J. y Miller Ernest, G. (1983). Presupuesto Público.
Méjico: Editorial Trillas s.a.
?? Universidad Metropolitana (2001). Trabajo Final, Normas para la
presentación del informe. Caracas: Universidad Metropolitana, Vice-
rectorado académico.
Apéndices
125
Apéndice A: Casos de uso específicos.
Apéndices
126
CASOS DE USO
Caso de uso: Formular el presupuesto
Actores: Personal de presupuesto, personal de finanzas, gerente de
presupuesto, personal de RRHH
Propósito: Elaborar el presupuesto anual del organismo a través de la
asignación de partidas y subpartidas a los distintos
programas y subprogramas.
Resumen: Los actores crean y modifican programas, subprogramas,
partidas, subpartidas y asignaciones de un presupuesto
antes que éste, sea ejecutado.
Tipo: Primario
Curso normal de los eventos
Acción del actor Comportamiento del sistema
1. Navegar a través del presupuesto.
2. realizar búsquedas para mostrar el
presupuesto
3. Crear las categorías requeridas.
4. Modificar dichas categorías.
5. Validar los datos ingresados y
mostrar alarmas en caso de algún
inconveniente.
6. Asignar las partidas a las categorías
existentes.
7. Almacenar presupuesto.
Apéndices
127
Caso de uso: Ejecutar el presupuesto
Actores: Personal de presupuesto, gerente de presupuesto, personal
de RRHH.
Propósito: Cumplir con las obligaciones presupuestarias y completar la
ejecución del presupuesto previamente aprobado.
Resumen: Los actores acceden al presupuesto aprobado para realizar
los compromisos, causaciones y pagos correspondientes a
la ejecución de las asignaciones existentes.
Tipo: Primario
Curso normal de los eventos
Acción del actor Comportamiento del sistema
1. Navegar a través del presupuesto
aprobado.
2. Busca las asignaciones existentes.
3. Comprometer asignaciones.
4. Alerta sobre compromisos que
excedan el monto asignado.
5. Muestra compromisos aprobados.
6. Causar compromisos.
5. Alerta sobre causaciones que
excedan el monto comprometido.
8. Muestra causaciones aprobadas.
9. Pagar causación
10. Alerta sobre pagos que excedan el
monto causado.
Apéndices
128
Caso de uso: Aprobar el presupuesto
Actores: Gerente de presupuesto
Propósito: Aprobar las etapas de formulación y ejecución del
presupuesto.
Resumen: El gerente accede en la etapa de la cual es responsable de
hacer la aprobación y revisa aquello que aún no esté
aprobado. Posteriormente, aprueba o desaprueba la etapa y
en algunos casos, comenta sobre su decisión.
Tipo: Primario
Curso normal de los eventos
Acción del actor Comportamiento del sistema
1. Revisar las asignaciones aún no aprobadas.
2. Aprobar o desaprobar las asignaciones
según su criterio.
3. Buscar otras asignaciones
para ser atendidas por el actor.
4. Revisar los compromisos aún no aprobadas.
5. Revisar las causaciones aún no aprobadas.
6. Revisar los pagos aún no aprobadas.
7. Mostrar las etapas que
esperan por su aprobación y al
responsable de su ejecución
8. Aprobar o desaprobar la etapa
seleccionada.
Apéndices
129
Caso de uso:
Realizar modificaciones legales
Actores: Gerente del presupuesto
Propósito: Realizar cambios a la asignación de partidas del
presupuesto, una vez éste haya sido aprobado.
Resumen: El gerente analiza las peticiones extraordinarias del
personal y decide si aprobar o no la asignación. Una vez
aprobada, se espera por la respuesta de las autoridades del
estado y se ejecutan estas modificaciones legales.
Tipo: Primario
Curso normal de los eventos
Acción del actor Comportamiento del sistema
1. Navegar por el sistema para ver las
peticiones.
2. Aprobar o desaprobar las peticiones
3. El sistema almacena la aprobación
de la modificación, pero no las realiza.
4. Ingresa la aprobación por parte de
un ente externo (autoridad)
Apéndices
130
Caso de uso: Manejar créditos adicionales
Actores: Personal de presupuesto, gerente de presupuesto.
Propósito: Requerir una modificación legal en un presupuesto
aprobado, de modo que se cambien las asignaciones de
partidas y subparitidas
Resumen: Los actores acceden a las asignaciones del presupuesto y
realizan peticiones de rectificación, insubsistencia, crédito
adicional o traspaso según sea el caso.
Tipo: Primario
Curso normal de los eventos
Acción del actor Comportamiento del sistema
1. Buscar las asignaciones del
presupuesto que no han sido
comprometidas.
2. Busca y muestra las asignaciones
que aún no han sido comprometidas en
su ejecución
3. Selecciona el tipo de modificación.
4. Realiza la petición para la
modificación y selecciona el monto.
5. Valida la petición
Apéndices
131
Apéndice B. Diagramas de secuencia.
Apéndices
132
DIAGRAMAS DE SECUENCIA
Figura B1 – Secuencia del personal de RRHH.
Fuente: Elaboración propia.
Figura B2 – Secuencia del personal de finanzas.
Personal de RRHH
:Sistema
Enviarlistadesueldos (códigoemp, sueldo)
Ejecutarpago (codigoemp, monto)
Realizarpagoextraordinario (razon, monto)
:Sistema
Mostrartotalrecursos (monto)
Manejarcontabilidad ()
Personal de Finanzas
Apéndices
133
Fuente: Elaboración propia.
Figura B3 – Secuencia del Administrador.
Fuente: Elaboración propia.
:Sistema
Ingresarusuario (nombre, clave)
Manejarseguridad ()
Administrador
: Sistema Personal de Presupuesto
Compometerasignaciona(monto,numprograma,codpartida)
Causarpartida(monto,numprograma,codpartida,compromiso)
Ingresarpago(monto,numprograma,codpartida, causacion)
Formularprograma(numprograma, objetivo)
Modificarpresupuesto()
Realizarsituacionesextraordinarias()
Apéndices
134
Figura B4 – Secuencia del personal de presupuesto.
Fuente: Elaboración propia.
Apéndice C. Tablas de bases de datos.
Apéndices
135
TABLAS DE BASES DE DATOS
PRESUPUESTO (F559901)
En esta tabla se almacena la información esencial referente a un presupuesto.
Tabla C1 – Presupuesto.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Aprobación Indica si el presupuesto ha
sido aprobado Numérico 1 ABDO
Año Año de ejecución del
presupuesto Numérico 4 BLYR Fuente: Elaboración propia.
OBJ_PRESUPUESTO (F559910)
En esta tabla se almacena la información sobre los objetivos de un presupuesto
(Cod_presupuesto).
Tabla C2 – Objetivos del presupuesto.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Num_objetivo Número del
objetivo Numérico 3 NUMF X
Tipo de objetivo Tipo del objetivo String 40 TX40
Años de ejecución
Período de duración del
objetivo String 10 IDYE
Descripcion_obj Descripción del
objetivo String 200 D200
Metas
Descripción de las metas del
objetivo String 100 GAD
Fuente: Elaboración propia.
Apéndices
136
PROGRAMA (F559902)
En esta tabla se almacena toda la información esencial referente a un programa
específico de un presupuesto (Cod_presupuesto).
Tabla C3 – Programa.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X
Sector Sector que abarca el
programa String 30 SCTR
Denominación Nombre del Programa String 30 DNMC
Unidad_ejecutora Unidad que ejecuta
dicho Programa String 50 UDAD
Aprobación Indica si el programa ha
sido o no Aprobado String 10 ABDO
Fuente: Elaboración propia.
SUBPROGRAMA (F559903)
En esta tabla se almacena toda la información esencial referente a un subprograma
específico de un programa (Cod_Programa) en un presupuesto (Cod_presupuesto).
Tabla C4 – Subprograma.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X
Num_subprograma Número del subprograma Numérico 5 NSUB X
Denominación Nombre del Programa String 30 DNMC
Aprobación Indica si el programa ha
sido o no Aprobado String 10 ABDO
Fuente: Elaboración propia.
Apéndices
137
PARTIDA (F559904)
En esta tabla se almacena toda la información esencial referente a una partida. La
tabla de la subpartida (F559905) es similar a ésta.
Tabla C5 – Partida.
Campo Descripción Tipo Longitud Alias Clave
Cod_Partida Código de la Partida String 20 CPAR X Unidad de
Medida Unidad en la cual se
mide la Partida String 15 UMED
Cantidad Cantidad requerido
de la Unidad Numérico 8 QTY
Precio Unitario Precio Unitario Numérico 8 UP
Concepto Denominación de la
Partida String 30 DNMC Fuente: Elaboración propia.
Apéndices
138
PROGRAMA – PARTIDA (F559906)
Esta tabla viene de una relación entre las tablas Programa (F559902) y la tabla
Partida (F559904) y contiene la información referente a la asignación que se le hace
a una partida (Cod_partida) para un programa (Cod_programa) de un presupuesto
(Cod_presupuesto). Las asignaciones que se hacen entre los programas y las
subpartidas, los subprogramas y las partidas, así como la relación entre los
subprogramas y las subpartidas; se almacenan en las tablas F559907, F559908 y
F559909 respectivamente, las cuales son similares a la tabla Programa-Partida.
Tabla C6 – Relación Programa-Partida.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X
Cod_Partida Código de la Partida String 15 CPAR X
Monto Monto asignado para
este programa Numérico 12 AA
Tipo Tipo de la Asignación String 20 DLJT Fuente: Elaboración propia.
Apéndices
139
ORDEN DE APROBACION (F559914)
En esta tabla se almacenan los datos que se refieren a una orden de aprobación
emitida para un presupuesto específico (Cod_presupuesto).
Tabla C7 – Orden de Aprobación.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Cod_orden Código de la Orden String 2 LTRC X
Responsable Responsable por la
aprobación String 30 ALPH
Fecha Fecha en la cual se
aprobó Fecha 6 ADAT
Tipo_aprob Tipo de aprobación String 10 ATTY
Comentarios
Comentarios y observaciones de la
orden String 300 DL
Fuente: Elaboración propia.
COMPROMISO (F559911)
En esta tabla se almacenan los datos que se refieren a un compromiso, para ser
utilizado en cualquier asignación de un presupuesto aprobado.
Tabla C8 – Compromiso.
Campo Descripción Tipo Longitud Alias Clave
Cod_compromiso Código del
Compromiso String 8 AN8 X
Denominación Denominación del
Compromiso String 30 DNMC
Responsable
Persona responsable de
haber realizado el Compromiso String 30 BUCD06DS
Aprobación
Indica si el compromiso ha sido
aprobado Numérico 2 ABDO
Cod_compañia Código de la compañía String 10 IDC
Fuente: Elaboración propia.
Apéndices
140
COMPROMISO – PROGRAMA – PARTIDA (F559915)
Esta tabla se genera por la relación existente entre las tablas Programa (F559902) y
la tabla Partida (F559904) y la tabla Compromiso (F559911). Contiene la
información referente a la las asignaciones de Partidas en Programas, pero una vez
estas partidas hayan sido comprometidas. Los compromisos realizados a las
asignaciones entre los programas y las subpartidas, los subprogramas y las
partidas, así como la relación entre los subprogramas y las subpartidas; se
almacenan en las tablas F559916, F559917 y F559918 respectivamente, las cuales
son similares a la tabla Compromiso-Programa-Partida.
Tabla C9 – Relación Compromiso–Programa–Partida.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto
existente String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X Cod_Partida Código de la Partida String 15 CPAR X
Cod_compromiso Código del Compromiso String 8 CCOMP X Monto Monto comprometido Numérico 15 AA
Fecha efectiva
Fecha en la cual se compromete la
asignación Fecha 6 ABCX
Denominación Denominación del
Compromiso String 30 DNMC
Responsable
Persona responsable de haber realizado el
Compromiso String 30 BUCD06DS
Aprobación Indica si el compromiso
ha sido aprobado Numérico 2 ABDO
Cod_compañia
Código de la compañía con la cual se compromete Numérico 10 IDC
Fuente: Elaboración propia.
Apéndices
141
CAUSACIÓN - PROGRAMA - PARTIDA (F559920)
Esta tabla se genera por la relación existente entre las tablas Programa (F559902),
la tabla Partida (F559904) y la causación de sus compromisos. Contiene la
información referente a la las asignaciones de partidas en programas, pero una vez
estas partidas hayan sido comprometidas y a su vez, causadas. Las causaciones
realizadas a las asignaciones entre los programas y las subpartidas, los
subprogramas y las partidas, así como la relación entre los subprogramas y las
subpartidas; se almacenan en las tablas F559927, F559928 y F559929
respectivamente, las cuales son similares a la tabla Causación-Programa-Partida.
Tabla C10 – Relación Causación–Programa–Partida.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X
Cod_Partida Código de la Partida String 15 CPAR X
Cod_compromiso Código del Compromiso String 8 CCOMP X
Cod_causacion Código de la Causación Numérico 5 CCAUS X
Denominación Denominación de la
causación String 30 DNMC Monto Monto pagado Numérico 15 AA
Fecha efectiva Fecha en la cual se causa la asignación Fecha 6 ABCX
Aprobación Indica si la causación ha
sido aprobada Numérico 2 ABDO
Responsable
Persona responsable de haber realizado la
causación String 30 BUCD06DS Fuente: Elaboración propia.
Apéndices
142
PAGO – PROGRAMA – PARTIDA (F559921)
Esta tabla se genera por la relación existente entre las tablas Programa (F559902),
la tabla Partida (F559904) y los pagos de sus causaciones. Contiene la información
referente a la las asignaciones de partidas en programas, pero una vez estas
partidas hayan sido comprometidas, causadas y a su vez, pagadas. Los pagos
realizados a las asignaciones entre los programas y las subpartidas, los
subprogramas y las partidas, así como la relación entre los subprogramas y las
subpartidas; se almacenan en las tablas F559930, F559931 y F559932
respectivamente, las cuales son similares a la tabla Causación-Programa-Partida.
Tabla C11 – Relación Pago –Programa–Partida.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del
presupuesto String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X
Cod_Partida Código de la
Partida String 15 CPAR X
Cod_compromis o Código del
Compromiso String 8 CCOMP X
Cod_causacion Código de la Causación Numérico 5 CCAUS X
Cod_pago Código del Pago Numérico 15 PYID X
Forma_pago Forma de Pago String 3 PYCD
Numero_cheque
Número del cheque (si se paga en
cheque) String 8 CN
Monto Monto pagado Numérico 15 AA
Fecha pago Fecha de ejecución
del pago Fecha 6 DTPD
Aprobación Indica si el pago ha
sido aprobado Numérico 2 ABDO
Responsable
Persona responsable de
haber realizado el pago String 30 BUCD06DS
Fuente: Elaboración propia.
Apéndices
143
PETICIÓN EXTRAORDINARIA (F559925)
En esta tabla se almacenan los datos de una petición para realizar una modificación
extraordinaria, posterior a la aprobación del presupuesto.
Tabla C12 – Petición extraordinaria.
Campo Descripción Tipo Longitud Alias Clave
Cod_presupuesto Código del Presupuesto String 5 CDGO X
Num_programa Número del programa Numérico 5 NPRO X
Cod_Partida Código de la Partida String 15 CPAR X
Cod_extraord Código de la Situación Numérico 5 CEXTR X
Descripción Descripción de la modificación String 30 DNMC
Tipo Tipo de situación String 15 TIPO
Monto Monto requerido Numérico 15 AA
Responsable Responsable de la petición String 30 BUCD06DS
Aprobación Indica si la modificación
ha sido aprobada Numérico 2 ABDO
Comentarios Se comenta sobre la
aprobación/desaprobación String 200 D200 Fecha
aprobación Fecha de la aprobación Fecha 6 ABCX
Fuente: Elaboración propia.