Modelo Conceptual del SIIF2
Desarrollo de los lineamientos generales del modelo conceptual de alto nivel de la
administración de las finanzas públicas
Fecha: 1 de Abril de 2014
Índice de Contenidos
1. INTRODUCCIÓN............................................................................................................................ 16
2. RESUMEN EJECUTIVO ................................................................................................................ 17
3. MODELO CONCEPTUAL DE ALTO NIVEL DEL SISTEMA INTEGRADO DE
INFORMACIÓN FINANCIERA ....................................................................................................... 30
3.1 Introducción ....................................................................................................................... 30 3.1.1 Objetivos del sistema .............................................................................................. 32 3.1.2 Alcance del sistema ................................................................................................. 33 3.1.3 Esponsorización y éxito del proyecto ...................................................................... 34
3.1.3.1 Apoyo de las Máximas Autoridades. .......................................................... 34 3.1.3.2 Fortalecimiento de las capacidades internas del sector público
para el desarrollo del SIAF ......................................................................... 35 3.1.3.3 Comité de Usuarios .................................................................................... 35
3.2 Requisitos generales del SIIF2 ......................................................................................... 35 3.2.1 Cobertura institucional ............................................................................................. 36 3.2.2 Trazabilidad ............................................................................................................. 36 3.2.3 Roles y perfiles ........................................................................................................ 36 3.2.4 Seguridad ................................................................................................................ 36 3.2.5 Performance y escalabilidad ................................................................................... 37 3.2.6 Consistencia e integridad de la información ............................................................ 37 3.2.7 Clasificadores .......................................................................................................... 38
3.2.7.1 Clasificadores principales ........................................................................... 38 3.2.7.2 Clasificadores secundarios......................................................................... 39 3.2.7.3 Propiedades institucionales ........................................................................ 39
3.2.8 Nivel de captura de las transacciones ..................................................................... 40 3.2.8.1 Captura a nivel institucional: Unidad Organizativa ..................................... 40
3.2.9 Estado de las transacciones.................................................................................... 41 3.2.10 Visibilidad sobre ejercicios futuros ...................................................................... 42 3.2.11 Base devengado .................................................................................................. 42 3.2.12 Gestión de múltiples monedas ............................................................................ 42 3.2.13 Pantallas de usuario ............................................................................................ 43 3.2.14 Documentación del sistema................................................................................. 43
3.3 Mapa de módulos principales ............................................................................................ 43 3.3.1 Estructura de Alto Nivel: SIIF2 Transaccional y SIIF2 Agregación ......................... 45
3.3.1.1 SIIF2 Transaccional .................................................................................... 45 3.3.1.2 SIIF2 Agregación ........................................................................................ 45
3.4 Funciones de soporte a la gestión financiera .................................................................... 45 3.4.1 Orientación a documentos de negocio .................................................................... 46 3.4.2 Seguimiento administrativo ..................................................................................... 46 3.4.3 Alarmas financieras ................................................................................................. 46
3.5 Funciones de soporte a la operación ................................................................................ 46 3.5.1 Compromisos de Ejercicios futuros ......................................................................... 47 3.5.2 Automatización de tareas ........................................................................................ 47
3.6 Funciones de soporte para el control y auditoría .............................................................. 47
3.7 Configuración .................................................................................................................... 47
3.8 Reportabilidad ................................................................................................................... 48 3.8.1 Introducción a la reportabilidad ............................................................................... 48
3.8.1.1 Requisitos generales a la reportabilidad .................................................... 49 3.8.1.2 Estructura de la capa de datos ................................................................... 50
3.8.2 Búsquedas ............................................................................................................... 51
3.8.3 Reportes operativos ................................................................................................ 52 3.8.4 Reportes analíticos .................................................................................................. 53 3.8.5 Área de análisis ....................................................................................................... 53 3.8.6 Reportes estratégicos .............................................................................................. 54 3.8.7 Listado de los principales reportes .......................................................................... 54
3.9 Interoperabilidad ................................................................................................................ 56 3.9.1 Interoperabilidad institucional .................................................................................. 56 3.9.2 Interoperabilidad transversal ................................................................................... 57
4. INTEGRACIÓN PRESUPUESTARIA Y CONTABLE: PRINCIPALES CONCEPTOS Y
DEFINICIONES .............................................................................................................................. 59
4.1 Centralización normativa y descentralización operativa ................................................... 60
4.2 Integración del sistema...................................................................................................... 61
4.3 Núcleo integrador del sistema ........................................................................................... 62
4.4 Requisitos mínimos para la integración ............................................................................ 64 4.4.1 Universalidad del registro de transacciones con efectos económico-
financieros ............................................................................................................... 64 4.4.2 Registro único .......................................................................................................... 64 4.4.3 Estructura organizativa financiera de las instituciones del Sector Público ............. 65
4.4.3.1 Estructura desde las Finanzas Públicas .................................................... 65 4.4.3.2 Estructura desde el Presupuesto ............................................................... 68 4.4.3.3 Estructura desde la Administración Financiera .......................................... 68 4.4.3.4 Estructura desde la Contabilidad ............................................................... 70
4.4.4 Clasificador Presupuestario y Plan de Cuentas Contables
complementarios e integrados ................................................................................ 73 4.4.4.1 Clasificadores Presupuestarios .................................................................. 74 4.4.4.2 Planes de Cuentas Contable ...................................................................... 78 4.4.4.3 Catálogos de Bienes .................................................................................. 80 4.4.4.4 Interrelación de la Clasificación Presupuestaria, Planes de
Cuentas Contable y otros Sistemas ........................................................... 82 4.4.5 Matriz de conversión presupuesto contabilidad ...................................................... 83 4.4.6 Momentos de Registro ............................................................................................ 83
4.4.6.1 Para los Gastos .......................................................................................... 83 4.4.6.2 Para los Recursos ...................................................................................... 84 4.4.6.3 Base del devengado ................................................................................... 84 4.4.6.4 Mandado a Pagar ....................................................................................... 87 4.4.6.5 Pagado ....................................................................................................... 87
5. INTEGRACIÓN DE LOS MÓDULOS PRINCIPALES .................................................................... 89
5.1 Visión global ...................................................................................................................... 89
5.2 Módulo presupuestario ...................................................................................................... 89 5.2.1 Objetivos .................................................................................................................. 89 5.2.2 Requisitos ................................................................................................................ 90
5.2.2.1 Formulación ................................................................................................ 91 5.2.2.2 Ejecución .................................................................................................... 91 5.2.2.3 Evaluación .................................................................................................. 96
5.2.3 Integración ............................................................................................................... 97 5.2.3.1 Presupuesto y contabilidad ........................................................................ 97 5.2.3.2 Presupuesto y tesorería ............................................................................. 97 5.2.3.3 Presupuesto y gestión de la deuda ............................................................ 97
5.3 Módulo contable ................................................................................................................ 98 5.3.1 Objetivos .................................................................................................................. 99
5.3.2 Requisitos .............................................................................................................. 100 5.3.2.1 Marco Normativo Contable ....................................................................... 100 5.3.2.2 Principales Ingresos al Módulo de Contabilidad ...................................... 107
5.3.3 Esquema general de Integración del Módulo Contable con los Módulos
principales y secundarios del SIIF2 ....................................................................... 129 5.3.3.1 Integración con los módulos principales .................................................. 129 5.3.3.2 Integración con los módulos secundarios ................................................ 134
5.4 Módulo tesorería .............................................................................................................. 138 5.4.1 Objetivos ................................................................................................................ 138 5.4.2 Requisitos .............................................................................................................. 139
5.4.2.1 Gestión de los recursos ............................................................................ 139 5.4.2.2 Gestión de los egresos ............................................................................. 140 5.4.2.3 Roles del módulo de tesorería ................................................................. 143
5.5 Módulo deuda .................................................................................................................. 143 5.5.1 Objetivos ................................................................................................................ 143 5.5.2 Requisitos .............................................................................................................. 144
5.5.2.1 Información sobre recursos provenientes de operaciones de
deuda ........................................................................................................ 144 5.5.2.2 Información sobre gastos asociados a operaciones de deuda ................ 145 5.5.2.3 Información sobre gestión de la deuda pública ........................................ 145
6. INTEGRACIÓN SISTEMAS DE APOYO TRANSVERSALES ..................................................... 146
6.1 Visión Global y Plataforma de Gobierno Electrónico (PGE) ........................................... 147
6.2 Sistema de Compras y Contrataciones Estatales (SICE) ............................................... 147 6.2.1 Características funcionales ................................................................................... 147 6.2.2 Características técnicas ........................................................................................ 148
6.3 Sistema Lucia (DNA) ....................................................................................................... 148 6.3.1 Características funcionales ................................................................................... 148 6.3.2 Características técnicas ........................................................................................ 149
6.4 Sistemas de la Dirección General Impositiva (DGI) ........................................................ 149 6.4.1 Características funcionales ................................................................................... 149 6.4.2 Características técnicas ........................................................................................ 149
6.5 Registro Único de Proveedores del Estado (RUPE) ....................................................... 150 6.5.1 Características funcionales ................................................................................... 150 6.5.2 Características técnicas ........................................................................................ 150
6.6 Sistema de Distribución del Gasto (SDG) ....................................................................... 150 6.6.1 Características funcionales ................................................................................... 150 6.6.2 Características técnicas ........................................................................................ 151
6.7 Sistema de Presentación del Articulado (SPA) ............................................................... 151 6.7.1 Características funcionales ................................................................................... 151 6.7.2 Características técnicas ........................................................................................ 151
6.8 Sistema Nacional de Inversiones Públicas (SNIP) ......................................................... 152 6.8.1 Características funcionales ................................................................................... 152 6.8.2 Características técnicas ........................................................................................ 152
6.9 Sistema de RR.HH (SGH-SLH) ....................................................................................... 153 6.9.1 Características funcionales ................................................................................... 153 6.9.2 Características técnicas ........................................................................................ 153
6.10 Sistema de Planificación Estratégica y Evaluación (SPE) .................................... 154 6.10.1 Características funcionales ............................................................................... 154 6.10.2 Características técnicas..................................................................................... 154
6.11 Sistemas del BROU ............................................................................................... 154 6.11.1 Características funcionales ............................................................................... 154 6.11.2 Características técnicas..................................................................................... 154
6.12 Sistemas del BCU ................................................................................................. 155 6.12.1 Características funcionales ............................................................................... 155 6.12.2 Características técnicas..................................................................................... 155
6.13 Sistemas del BPS .................................................................................................. 156 6.13.1 Características funcionales ............................................................................... 156 6.13.2 Características técnicas..................................................................................... 156
6.14 Sistemas GRP ....................................................................................................... 156 6.14.1 Características funcionales ............................................................................... 156 6.14.2 Características técnicas..................................................................................... 156
7. MODELADO BPM DEL CICLO PRESUPUESTARIO .................................................................. 158
7.1 Situación actual del SIIF .................................................................................................. 158
7.2 Descripción del macroproceso presupuestario ............................................................... 162 7.2.1 Formulación ........................................................................................................... 163 7.2.2 Ejecución presupuestal y financiera ...................................................................... 164 7.2.3 Control y evaluación .............................................................................................. 165
8. ARQUITECTURA TECNOLÓGICA DEL SISTEMA ..................................................................... 167
8.1 Capa de Presentación ..................................................................................................... 168 8.1.1 Portal Web 2.0 ....................................................................................................... 169 8.1.2 Servidor Web ......................................................................................................... 170
8.2 Capa de Negocios ........................................................................................................... 171 8.2.1 Servidor de Aplicaciones ....................................................................................... 171 8.2.2 Reglas de Negocio ................................................................................................ 173 8.2.3 Monitor de Actividades de Negocio ....................................................................... 174 8.2.4 Motor de Inteligencia de Negocios ........................................................................ 175 8.2.5 Motor de Gestión de Datos Maestros .................................................................... 177
8.3 Capa de Datos ................................................................................................................. 179 8.3.1 Motor de Bases de Datos Relacionales ................................................................ 179 8.3.2 Repositorio de Contenidos .................................................................................... 180 8.3.3 Motor de Extracción Transformación y Carga ....................................................... 181
8.4 Capa de Integración ........................................................................................................ 183 8.4.1 Bus de Servicios .................................................................................................... 183 8.4.2 Motor de Gestión de Políticas de Servicios Web .................................................. 185
8.5 Capa de Seguridad .......................................................................................................... 186 8.5.1 Mecanismo de Identificación ................................................................................. 186 8.5.2 Mecanismo de Single Sign–on .............................................................................. 187 8.5.3 Mecanismo de Autorización .................................................................................. 188 8.5.4 Directorios de Credenciales .................................................................................. 189 8.5.5 Mecanismo de Aprovisionamiento de Usuarios .................................................... 190 8.5.6 Mecanismo de Autogestión de Credenciales ........................................................ 192
8.6 Elementos Arquitectónicos de Monitoreo ........................................................................ 193 8.6.1 Monitor de Infraestructura ..................................................................................... 193 8.6.2 Monitor de Uso del Sistema .................................................................................. 194
8.7 Consideraciones sobre la Arquitectura ........................................................................... 195 8.7.1 Ejemplo de topología de despliegue para la plataforma ....................................... 195 8.7.2 Tabla de recomendaciones ante contingencias que impidan la
adquisición de un componente de la plataforma. .................................................. 198
9. EVALUACIÓN NORMATIVA ........................................................................................................ 201
9.1 Evaluación de las normas relevantes .............................................................................. 201
9.2 Principales Contenidos en la Normativa a Dictar ............................................................ 202
Índice de Ilustraciones
Ilustración 3-1 Diagrama de estados de las transacciones ........................................................ 41
Ilustración 3-2 Estructura de los módulos principales del SIIF2 ................................................. 44
Ilustración 3-3 Estructura de la capa de datos para la reportabilidad ......................................... 50
Ilustración 4-1 La contabilidad como núcleo integrador del sistema .......................................... 63
Ilustración 5-1 Estructura de los módulos principales del SIIF2 ................................................. 89
Ilustración 5-2 Marco Normativo Contable ................................................................................ 101
Ilustración 5-3 Principales Ingresos al Módulo Contable .......................................................... 108
Ilustración 6-1 Esquema General de Interoperación para el SIIF2 ........................................... 146
Ilustración 7-1 Estructura del sector público ............................................................................. 158
Ilustración 7-2 El ciclo presupuestario ...................................................................................... 162
Ilustración 7-3 Formulación ....................................................................................................... 163
Ilustración 7-4 Ejecución presupuestal ..................................................................................... 164
Ilustración 7-5 Evaluación y control........................................................................................... 165
Ilustración 8-1 Capas de la plataforma de middleware de la arquitectura base ....................... 168
Ilustración 8-2 Portal Web 2.0 ................................................................................................... 169
Ilustración 8-3 Servidor Web ..................................................................................................... 170
Ilustración 8-4 Servidor de Aplicaciones ................................................................................... 171
Ilustración 8-5 Reglas de Negocio ............................................................................................ 173
Ilustración 8-6 Monitor de Actividades de Negocio ................................................................... 174
Ilustración 8-7 Motor de Inteligencia de Negocios .................................................................... 175
Ilustración 8-8 Motor de Gestión de Datos Maestros ................................................................ 177
Ilustración 8-9 Motor de Bases de Datos .................................................................................. 179
Ilustración 8-10 Motor de Gestión de Contenidos ..................................................................... 180
Ilustración 8-11 Motor de Extracción, Transformación y Carga ................................................ 181
Ilustración 8-12 Bus de Servicios .............................................................................................. 183
Ilustración 8-13 Motor de Gestión de Políticas de Servicios Web ............................................ 185
Ilustración 8-14 Mecanismo de Identificación ........................................................................... 186
Ilustración 8-15 Mecanismo de Single Sign-on ......................................................................... 187
Ilustración 8-16 Mecanismo de Autorización ............................................................................ 188
Ilustración 8-17 Directorios de Credenciales ............................................................................ 189
Ilustración 8-18 Mecanismo de Aprovisionamiento de Usuarios .............................................. 190
Ilustración 8-19 Mecanismo de Autogestión de Credenciales .................................................. 192
Ilustración 8-20 Monitor de Infraestructura ............................................................................... 193
Ilustración 8-21 Monitor de Uso del Sistema ............................................................................ 194
Ilustración 8- 22 Modelo de ejemplo de topología de despliegue de la Plataforma de Middleware
del SIIF2 .................................................................................................................................... 196
Índice de Requisitos
REQ 3-1 Alcance del sistema .................................................................................................... 34
REQ 3-2 Cobertura institucional................................................................................................. 36
REQ 3-3 Trazabilidad ................................................................................................................. 36
REQ 3-4 Roles y perfiles ............................................................................................................ 36
REQ 3-5 Usuarios con distintos cometidos ................................................................................ 36
REQ 3-6 Seguridad .................................................................................................................... 37
REQ 3-7 Performance ................................................................................................................ 37
REQ 3-8 Escalabilidad ............................................................................................................... 37
REQ 3-9 Consistencia e integridad de la información ............................................................... 37
REQ 3-10 Estructura de los clasificadores ................................................................................ 38
REQ 3-11 Flexibilidad de los clasificadores ............................................................................... 38
REQ 3-12 Variabilidad de los clasificadores .............................................................................. 38
REQ 3-13 Trazabilidad temporal de los clasificadores .............................................................. 38
REQ 3-14 Propiedad de los clasificadores principales .............................................................. 38
REQ 3-15 Repercusión en otros sistemas transversales .......................................................... 39
REQ 3-16 Propiedad de los clasificadores secundarios ............................................................ 39
REQ 3-17 Límites a los clasificadores secundarios ................................................................... 39
REQ 3-18 Efecto de los clasificadores secundarios en SIIF2 agregación ................................ 39
REQ 3-19 Propiedad de las propiedades institucionales ........................................................... 39
REQ 3-20 Límites a las propiedades institucionales.................................................................. 40
REQ 3-21 Estructura de las propiedades institucionales ........................................................... 40
REQ 3-22 Efecto de las propiedades institucionales en SIIF2 agregación ............................... 40
REQ 3-23 Nivel de captura de las transacciones ...................................................................... 40
REQ 3-24 Captura a nivel de Unidad Ejecutora y/o Unidad Organizativa ................................. 40
REQ 3-25 Estado de las transacciones ..................................................................................... 41
REQ 3-26 Visibilidad sobre ejercicios futuros ............................................................................ 42
REQ 3-27 Base devengado ....................................................................................................... 42
REQ 3-28 Gestión de múltiples monedas .................................................................................. 42
REQ 3-29 Pantallas de usuario .................................................................................................. 43
REQ 3-30 Documentación del sistema ...................................................................................... 43
REQ 3-31 Captura de Transacciones orientada a Documentos de Negocio ............................ 46
REQ 3-32 Captura y Gestión de Documentación de Respaldo ................................................. 46
REQ 3-33 Gestión Documental .................................................................................................. 46
REQ 3-34 Definición y Parametrización de Alarmas Financieras .............................................. 46
REQ 3-35 Registro y traspaso de compromisos que afectan ejercicios futuros ........................ 47
REQ 3-36 Automatización de Tareas y Cálculos repetitivos ..................................................... 47
REQ 3-37 Bandeja de Entrada de Tareas ................................................................................. 47
REQ 3-38 Funcionalidades automatizadas de control y auditoria ............................................. 47
REQ 3-39 Sistema configurable ................................................................................................. 48
REQ 3-40 Exportación a planilla y documento .......................................................................... 49
REQ 3-41 Perfil de usuario y acceso a los reportes .................................................................. 49
REQ 3-42 Características tecnológicas de la reportabilidad ..................................................... 49
REQ 3-43 Oportunidad de la información para la reportabilidad ............................................... 49
REQ 3-44 Estructura de la capa de datos ................................................................................. 51
REQ 3-45 Búsquedas y Entidades............................................................................................. 51
REQ 3-46 Esquema de los reportes de búsqueda .................................................................... 52
REQ 3-47 Filtros simples y avanzados para las búsquedas ..................................................... 52
REQ 3-48 Área de resultados .................................................................................................... 52
REQ 3-49 Paginación del área de resultados ............................................................................ 52
REQ 3-50 Ordenación del área de resultados ........................................................................... 52
REQ 3-51 Acceso al detalle de la transacción ........................................................................... 52
REQ 3-52 Requisitos de los reportes operativos comunes a los reportes de búsqueda .......... 53
REQ 3-53 Cobertura institucional de los reportes operativos .................................................... 53
REQ 3-54 Adaptación a la plataforma de BI .............................................................................. 53
REQ 3-55 Requisitos de los reportes analíticos comunes a otros reportes .............................. 53
REQ 3-56 Cobertura institucional de los reportes analíticos ..................................................... 53
REQ 3-57 Metadata disponible para análisis ............................................................................. 54
REQ 3-58 Requisitos de los reportes estratégicos comunes a otros reportes .......................... 54
REQ 3-59 Elementos gráficos .................................................................................................... 54
REQ 3-60 Listado de reportes .................................................................................................... 54
REQ 3-61 Economía de reportes ............................................................................................... 56
REQ 3-62 Plataforma de interoperabilidad ................................................................................ 56
REQ 3-63 Integridad y coherencia de la estructura de datos .................................................... 56
REQ 3-64 Normas de interoperación a cargo del SIIF2 ............................................................ 57
REQ 3-65 Conjunto único de servicios web de interoperación .................................................. 57
REQ 3-66 Catálogos básicos e interoperación .......................................................................... 57
REQ 3-67 Interoperabilidad institucional modular ...................................................................... 57
REQ 3-68 Mecanismos de interoperabilidad vía up load ........................................................... 57
REQ 3-69 Sistemas institucionales no aptos para la interoperación ......................................... 57
REQ 3-70 Interoperación transversal ......................................................................................... 58
REQ 4-1 Administrador del Sistema .......................................................................................... 64
REQ 4-2 Universalidad del registro ............................................................................................ 64
REQ 4-3 Registro único de efectos múltiples ............................................................................ 65
REQ 4-4 Estructura de las unidades de registro ........................................................................ 65
REQ 4-5 Procedimientos de registro.......................................................................................... 65
REQ 4-6 Estructura desde las Finanzas Públicas ..................................................................... 66
REQ 4-7 Estructura desde el Presupuesto ................................................................................ 68
REQ 4-8 Estructura desde la administración financiera ............................................................ 68
REQ 4-9 Unidades Rectoras, Unidades Ejecutoras y Unidades Organizativas ........................ 68
REQ 4-10 Entes Contables ........................................................................................................ 71
REQ 4-11 Unidades Ejecutoras – Registración Contable ......................................................... 72
REQ 4-12 Unidad de Consolidación .......................................................................................... 72
REQ 4-13 Desarrollo de Clasificadores Presupuestarios y Plan de Cuentas Contables .......... 73
REQ 4-14 Sustento normativo de los Clasificadores Presupuestarios ...................................... 75
REQ 4-15 Estructura de los Clasificadores Presupuestarios .................................................... 75
REQ 4-16 Estructura Institucional .............................................................................................. 76
REQ 4-17 Estructura por Objeto del Gasto ................................................................................ 77
REQ 4-18 Estructura de Recursos ............................................................................................. 78
REQ 4-19 Sustento normativo del Plan de Cuentas Contable .................................................. 79
REQ 4-20 Estructura del Plan de Cuentas Contable ................................................................. 79
REQ 4-21 Estructura del Catálogo de Bienes ............................................................................ 81
REQ 4-22 Integración del Clasificador Presupuestario, del Catálogo de Bienes y Plan de
Cuentas Contable ........................................................................................................................ 82
REQ 4-23 Desarrollo de la matriz de conversión presupuesto / contabilidad ........................... 83
REQ 5-1 Generación del presupuesto Ley ................................................................................ 91
REQ 5-2 Transmisión de las leyes en materia Presupuestal al módulo de ejecución .............. 91
REQ 5-3 Gestión completa del ciclo quinquenal ........................................................................ 91
REQ 5-4 Crédito inicial y modificaciones ................................................................................... 91
REQ 5-5 Solicitud de modificaciones ......................................................................................... 91
REQ 5-6 Distribución de créditos por Unidad Ejecutora y Unidad Operativa ............................ 91
REQ 5-7 Funcionalidad de Topes y Abatimientos ..................................................................... 91
REQ 5-8 Etapas de ejecución presupuestaria de los gastos ..................................................... 92
REQ 5-9 Lógica de cadena presupuestaria ............................................................................... 92
REQ 5-10 Prudencia presupuestaria ......................................................................................... 92
REQ 5-11 Información requerida por cada entidad ................................................................... 92
REQ 5-12 Captura de información orientada a documentos de negocio .................................. 92
REQ 5-13 Arrastre de información a lo largo de la cadena ....................................................... 92
REQ 5-14 Obligaciones y pagos sin compromiso...................................................................... 92
REQ 5-15 Compromisos que impactan en ejercicios futuros .................................................... 93
REQ 5-16 Programa de ejecución ............................................................................................. 93
REQ 5-17 Estados y modificaciones de las transacciones ........................................................ 93
REQ 5-18 Cartera financiera ...................................................................................................... 93
REQ 5-19 Gestión multimoneda ................................................................................................ 93
REQ 5-20 Ejecución de gastos asociados a la Gestión Humana .............................................. 93
REQ 5-21 Ejecución de gastos asociados a Bienes de Uso y Consumo .................................. 93
REQ 5-22 Ejecución de gastos asociados a Inversión .............................................................. 94
REQ 5-23 Ejecución de Proyectos Internacionales ................................................................... 94
REQ 5-24 Arrendamientos Oficiales .......................................................................................... 94
REQ 5-25 Gestión de Fondos Rotatorios .................................................................................. 94
REQ 5-26 Generación y Envío de Resguardos de Retenciones a DGI..................................... 94
REQ 5-27 Cierre de ejercicio ..................................................................................................... 95
REQ 5-28 Transacciones asociadas a recursos ........................................................................ 95
REQ 5-29 Unidades de registro asociadas a recursos .............................................................. 95
REQ 5-30 Etapas de ejecución presupuestaria de los recursos ............................................... 96
REQ 5-31 Rol generador de transacciones ............................................................................... 96
REQ 5-32 Rol aprobador de transacciones ............................................................................... 96
REQ 5-33 Rol interventor de transacciones ............................................................................... 96
REQ 5-34 Reversión de transacciones ...................................................................................... 96
REQ 5-35 Orientación a programas y objetivos estratégicos .................................................... 96
REQ 5-36 Elementos comunes entre la ejecución y la evaluación ........................................... 96
REQ 5-37 Ejecución como fuente de información financiera para la evaluación ...................... 97
REQ 5-38 Generación automática de asientos contables a partir del registro del devengado . 97
REQ 5-39 Aprobación del asiento contable ............................................................................... 97
REQ 5-40 Actualización del plan de caja a partir de las obligaciones intervenidas .................. 97
REQ 5-41 Generación de transacciones de pago presupuestario a partir del pago de tesorería
..................................................................................................................................................... 97
REQ 5-42 Generación de fuentes de financiamiento a partir de la emisión de deuda .............. 97
REQ 5-43 Generación de transacciones presupuestarias de gasto a partir del servicio de la
deuda ........................................................................................................................................... 98
REQ 5-44 Estados Financieros (EEFF) a producir .................................................................. 102
REQ 5-45 Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo
el Sector Gobierno General ....................................................................................................... 103
REQ 5-46 Manual de Normas Particulares de Contabilidad y Procedimientos Contables...... 104
REQ 5-47 Manual de activos ................................................................................................... 104
REQ 5-48 Manual de Consolidación de la Información Financiera ......................................... 105
REQ 5-49 Manual funcional de la Matriz de Conversión Presupuesto /Contabilidad.............. 106
REQ 5-50 Ingreso del Módulo de Presupuesto ....................................................................... 108
REQ 5-51 Ingreso del Módulo de Tesorería ............................................................................ 109
REQ 5-52 Ingreso del Módulo de Deuda Pública .................................................................... 113
REQ 5-53 Ingreso del Módulo de Tesorería ............................................................................ 113
REQ 5-54 Ingreso del Módulo de Recursos Humanos ............................................................ 116
REQ 5-55 Ingreso del Sistema Nacional de Inversión Pública (SNIP) .................................... 117
REQ 5-56 Ingreso del SICE ..................................................................................................... 119
REQ 5-57 Sub módulo de Almacenes ..................................................................................... 120
REQ 5-58 Sub módulo de Bienes ............................................................................................ 122
REQ 5-59 Contingencias .......................................................................................................... 127
REQ 5-60 Rendición de cuentas .............................................................................................. 127
REQ 5-61 Emisión de Cuentas Nacionales ............................................................................. 128
REQ 5-62 Percepción de recursos .......................................................................................... 139
REQ 5-63 Registración de los recursos ................................................................................... 139
REQ 5-64 Recursos por Desembolsos de Prestamos ............................................................. 139
REQ 5-65 Fuentes de financiamiento por Emisión de Deuda ................................................. 140
REQ 5-66 Conciliación de recursos ......................................................................................... 140
REQ 5-67 Gestión de la disponibilidad financiera de los Incisos ............................................. 140
REQ 5-68 Gestión Garantías ................................................................................................... 140
REQ 5-69 Programación financiera de los pagos .................................................................... 140
REQ 5-70 Plan de Caja ............................................................................................................ 140
REQ 5-71 Medios de Pagos ..................................................................................................... 141
REQ 5-72 Registro de pagos presupuestarios ........................................................................ 141
REQ 5-73 Registro de pagos no presupuestarios ................................................................... 141
REQ 5-74 Pagado y Percibido por Objeto y Programa Presupuestario .................................. 141
REQ 5-75 Devolución al crédito o Pago (Reversión de Pagos) .............................................. 141
REQ 5-76 Anulación y reimpresión de cheques ...................................................................... 142
REQ 5-77 Pagos de Servicios de la Deuda ............................................................................. 142
REQ 5-78 Pago de Retenciones .............................................................................................. 142
REQ 5-79 Gestión de Fondos Rotatorios ................................................................................ 142
REQ 5-80 Valores en Custodia ................................................................................................ 142
REQ 5-81 Pago de Suministros en formato clearing ............................................................... 142
REQ 5-82 Rol generador de transacciones ............................................................................. 143
REQ 5-83 Rol aprobador de transacciones ............................................................................. 143
REQ 5-84 Reversión de transacciones .................................................................................... 143
REQ 5-85 Ingresos de recursos por operaciones de crédito público ...................................... 144
REQ 5-86 Contratación y desembolsos de Préstamos ........................................................... 144
REQ 5-87 Egresos por operaciones de crédito público ........................................................... 145
REQ 5-88 Información de la gestión de la deuda pública ........................................................ 145
REQ 6-1 Interoperación SIIF2 - SICE ...................................................................................... 148
REQ 6-2 Interoperación SIIF2 - Lucía ...................................................................................... 149
REQ 6-3 Interoperación SIIF2 – Sistemas de Recaudación de DGI ....................................... 149
REQ 6-4 Interoperación SIIF2 – Sistemas de Retenciones DGI ............................................. 149
REQ 6-5 Interoperación SIIF2 – Sistemas de Resguardos DGI .............................................. 150
REQ 6-6 Interoperación SIIF2 – Sistema de Certificado de Crédito de DGI ........................... 150
REQ 6-7 Interoperación SIIF2 – Sistema de Certificado Único de Empresa de DGI .............. 150
REQ 6-8 Interoperación SIIF2 – RUPE .................................................................................... 150
REQ 6-9 Interoperación SIIF2 – SDG ...................................................................................... 151
REQ 6-10 Interoperación SIIF2 - SPA ..................................................................................... 151
REQ 6-11 Interoperación SIIF2 - SNIP .................................................................................... 153
REQ 6-12 Interoperación SIIF2 – SGH-SLH ............................................................................ 154
REQ 6-13 Interoperación SIIF2 – SPE .................................................................................... 154
REQ 6-14 Interoperación SIIF2 – e-BROU .............................................................................. 155
REQ 6-15 Interoperación SIIF2 – BROU ................................................................................. 155
REQ 6-16 Interoperación SIIF2 – Sistema de Pago del BCU .................................................. 155
REQ 6-17 Interoperación SIIF2 – BCU .................................................................................... 155
REQ 6-18 Interoperación SIIF2 – Sistemas de Deuda Pública del BCU ................................. 155
REQ 6-19 Interoperación SIIF2 – BPS .................................................................................... 156
REQ 6-20 Interoperación SIIF2 – GRP de Cobertura Institucional .......................................... 157
REQ 8-1 Portal Web 2.0 ........................................................................................................... 169
REQ 8-2 Servidor Web ............................................................................................................. 171
REQ 8-3 Servidor de Aplicaciones ........................................................................................... 172
REQ 8-4 Reglas de Negocio .................................................................................................... 173
REQ 8-5 Monitor de Actividades de Negocio ........................................................................... 175
REQ 8-6 Motor de Inteligencia de Negocios ............................................................................ 176
REQ 8-7 Motor de Gestión de Datos Maestros ....................................................................... 178
REQ 8-8 Motor de Bases de Datos Relacionales .................................................................... 179
REQ 8-9 Repositorio de Contenidos ........................................................................................ 181
REQ 8-10 Motor de Extracción, Transformación y Carga ....................................................... 182
REQ 8-11 Bus de Servicios ...................................................................................................... 184
REQ 8-12 Motor de Gestión de Políticas de Servicios Web .................................................... 185
REQ 8-13 Mecanismo de Identificación ................................................................................... 187
REQ 8-14 Mecanismo de Single Sign-on ................................................................................ 188
REQ 8-15 Mecanismo de Autorización .................................................................................... 189
REQ 8-16 Directorios de Credenciales .................................................................................... 190
REQ 8-17 Mecanismo de Aprovisionamiento de Usuarios ...................................................... 191
REQ 8-18 Mecanismo de Autogestión de Credenciales .......................................................... 192
REQ 8-19 Monitor de Infraestructura ....................................................................................... 194
REQ 8-20 Monitor de Uso del Sistema .................................................................................... 195
Modelo Conceptual del SIIF2 01/04/2014 16/203
1. Introducción
Este documento está compuesto por la presente Introducción, seguida por el Resumen
Ejecutivo que conforma la Sección 2. El resto del contenido está conformado por la Sección 3
Modelo Conceptual de Alto Nivel, la Sección 4 que se refiere a la Integración Presupuestaria
y Contable, mientras que la Sección 5 contiene la Integración de los Principales Módulos.
Posteriormente la Sección 6 se refiere a la Integración con los Sistemas de Apoyo
Transversales, la Sección 7 al Modelado en BPM y la Sección 8 a la Arquitectura
Tecnológica del Sistema, Finalmente la Sección 9 esta compuesta por la Evaluación
normativa.
Para la elaboración de este documento base fueron entrevistados funcionarios de la
Contaduría General de la Nación – CGN -, Tesorería General de la Nación – TGN -,
Ministerio de Economía y Finanzas – MEF- , Oficina de Planeamiento y Presupuesto – OPP -
y la Agencia para el Desarrollo del Gobierno de Gestión Electrónica y la Sociedad de la
Información y del Conocimiento – AGESIC -, así como funcionarios de varias Unidades
Ejecutoras de la Administración Central.
Modelo Conceptual del SIIF2 01/04/2014 17/203
2. Resumen Ejecutivo
El desarrollo de este proyecto tiene su origen en los resultados del proyecto de Diagnóstico
del SIIF actual encargado por la CGN a finales del año 2008. El SIIF actual se encuentra en
operaciones desde el año 1999, y desde su entrada a producción a la fecha se incorporaron
distintos módulos al “núcleo” inicial. El SIIF actual es un sistema desarrollado en base a
funciones, y no a procesos y, si bien cuenta con las principales funciones de un SIAF, éstas
tienen un bajo nivel de integración entre ellas, en especial en relación a la integración
presupuestaria contable. Por último cabe mencionar que a nivel de plataforma tecnológica es
un sistema cliente-servidor, en base a tecnología de la década pasada.
I. Principales Problemas del SIIF Actual
Producto de dicho diagnóstico se detectaron una serie de problemas estructurales y de
sistema entre los cuales es posible mencionar los siguientes:
Problemas estructurales del SIIF actual.
Ausencia de un Modelo Conceptual que defina en forma precisa el alcance, las
principales funcionalidades en forma integrada y cobertura del SIIF.
Presencia de una arquitectura tecnológica base no consolidada, que no presenta
elementos comunes para sus distintos módulos.
Excesiva fragmentación de los módulos del SIIF=> visión de funciones y no de
procesos.
Ausencia de procesos y mecanismos necesarios para la integración financiero -
contable en forma automática.
Disociación entre la programación y ejecución financiera (SEG) con la información de
metas e indicadores (SEV) y avance físico de obras/proyectos.
Ausencia de una política integral de control interno.
Problemas a nivel de sistemas del SIIF actual.
Diferencias en las cifras presupuestarias del SIP (valores históricos) y SEG (valores
nominales).
Doble digitación de la misma información en distintos módulos del sistema.
Información poco oportuna.
El módulo contable (SIC) no se desarrolló por completo, por lo tanto no es posible
generar los informes financieros y contables en forma automática desde el sistema.
Registros de ingresos y de pago de la deuda con bajo nivel de integración al SIIF.
Debilidades en su capacidad de generación de Reportes (imposibilidad de obtener
reportes a una fecha distinta a la actual).
Generación manual de informes a partir de extracciones de la Base de Datos.
Bajo nivel de integración con sistemas de apoyo, como por ejemplo el Sistema de
Compras (SICE) y el Sistema de Inversión Pública (SISI).
En resumen, el SIIF actual está conformado por una serie de módulos y sistemas, los cuales
no presentan una integración a nivel conceptual a la vez que no existe una interoperabilidad
plena entre ellos bajo un enfoque de procesos de negocio. Esta situación afecta la
generación de información financiero contable oportuna, relevante y confiable, impactando
sobre la gestión diaria del sector público, tanto a nivel de los Ministerios y Unidades
Operativas como a nivel de las autoridades de la CGN y del MEF para la toma de decisiones
Modelo Conceptual del SIIF2 01/04/2014 18/203
y rendición de cuentas (desde el 2008 hubo una mejora que fue la incorporación del SAI-
CGN (BI)).
II. El SIIF2
Un instrumento central para la gestión financiera contable del sector público es la utilización
de tecnologías de la información y comunicación (TICs), bajo la forma de Sistemas
Integrados de Administración Financiera (SIAF). El concepto SIAF hace referencia al uso de
TICs en la gestión financiera con el fin de apoyar las decisiones presupuestarias, las
responsabilidades de la gestión de los recursos públicos y la mejora del desempeño de las
entidades públicas, así como la preparación de los Estados Financieros, que incluyen los
estados contables, los estados de ejecución presupuestaria, los informes de flujos de fondos,
el estado de la deuda pública y el estado de activos fijos. Un proyecto de fortalecimiento de
este tipo de sistema, como es el caso del Sistema Integrado de Información Financiera del
Ministerio de Economía y Finanzas de la República Oriental del Uruguay requiere la
definición de una estrategia de desarrollo consistente y sólida. Para ello es necesario el
desarrollo de un Modelo Conceptual, que establezca con precisión el alcance funcional del
sistema, la definición de la arquitectura de base a utilizar y la programación de las fases de
desarrollo necesarias para desarrollar una nueva versión del SIIF.
En líneas generales un Modelo Conceptual (MC) debe definir los objetivos, el alcance y la
cobertura del SIAF, junto con una visión general del marco de la gestión financiera pública,
los principales requisitos de los usuarios y los procesos clave de la gestión financiero
contable que el sistema de información debe apoyar, junto a la definición de la arquitectura
tecnológica de base para su desarrollo.
Objetivos del sistema
Disciplina fiscal, generando información financiera oportuna para monitorear y
controlar la evolución del gasto público en línea con las capacidades actuales y
proyectadas de financiamiento del Sector Público.
Eficiencia en la asignación y captación de los recursos, generando mayor y mejor
información para la toma de decisiones sobre la priorización de políticas y programas
públicos en distintos niveles de la Administración Pública.
Eficiencia operacional, proporcionando herramientas prácticas que faciliten la gestión
de los recursos financieros y brinden información oportuna y relevante para la toma
de decisiones a nivel operativo en los Incisos.
Eficiencia en la rendición de cuentas, generando información contable oportuna y
confiable que le permita dar mayor transparencia a la rendición de las cuentas
públicas.
Alcance
En términos generales el alcance del SIIF2 se compone de un conjunto de módulos
principales, los cuales contienen principalmente las funcionalidades financiero contable que
operan de forma integrada. Estos módulos son: presupuesto, contabilidad, tesorería y crédito
público. A su vez, el SIIF2 cuenta con el apoyo de un conjunto de módulos complementarios,
los cuales se interrelacionan con los módulos principales. Estos módulos son gestión de
Modelo Conceptual del SIIF2 01/04/2014 19/203
recursos humanos, compras y contrataciones, recursos, inversión pública y administración de
bienes, entre otros.
Una adecuada interoperación entre los módulos principales y los módulos complementarios
permite una gestión pública más eficiente, al evitar, por ejemplo, la doble registración de la
información en distintos sistemas asegurando su consistencia. A su vez, fortalece el
ambiente de control sobre las finanzas públicas, generando un registro presupuestario y
contable, sobre la base del devengado, que permita relacionar en forma directa las
operaciones que generan (deudas) o pueden generar (contingencias) obligaciones para el
Estado y la disponibilidad presupuestaria necesaria para afrontar las mismas, evitando la
generación de deuda flotante no registrada, que distorsiona la situación fiscal. A su vez
permite registrar de forma oportuna las variaciones del patrimonio del sector público.
Esponsorización y éxito del proyecto
En forma concurrente a la definición del Modelo Conceptual, existen una serie de
condicionantes que promueven el éxito del proceso de desarrollo e implantación del SIIF2.
Es necesario tener presente que estas condiciones no garantizan por sí solas su reforma
exitosa, pero su ausencia condiciona fuertemente las posibilidades de éxito. Entre los
factores más relevantes es posible mencionar el apoyo de las máximas autoridades y la
participación de los usuarios finales del sistema a lo largo del proceso, junto al fortalecimiento
de capacidades institucionales del sector público. El desarrollo de estas actividades por parte
del MEF es de suma relevancia en el caso del desarrollo del SIIF2.
III. Principales Aspectos del Modelo Conceptual del SIIF2
El SIIF2 tendrá como cobertura la Administración Central (Incisos 02 al 15, 20 al 24 y 30), los
Organismos del Articulo 220 de la Constitución (Poder Judicial, Tribunal de Cuentas, Corte
Electoral, Tribunal de lo Contencioso Administrativo, ANEP, UDELAR, INAU, ASSE, UTEC) y
Poder Legislativo. Además, se debe tener en cuenta que a nivel del Módulo de Contabilidad
debe realizarse la consolidación del Sector Público, por lo cual es necesario contemplar al
resto de las entidades que por si mismas son entes contables.
Los requisitos de alto nivel que el SIIF2 deberá cumplir son: trazabilidad, seguridad, uso de
clasificadores principales y secundarios, visibilidad sobre ejercicios futuros, gestión de
múltiples monedas, conjunto de pantallas de usuario uniforme y la generación de una
documentación exhaustiva que asegura su mantención.
El SIIF2 contará con dos grandes bloques a alto nivel: el SIIF2 Transaccional y SIIF2
Agregación.
El SIIF2 Transaccional es el sistema de operación diaria para el registro de todas las
transacciones detalladas que se generan asociadas a la administración y el manejo de las
finanzas de las instituciones dentro de ámbito de cobertura. Su función principal es constituir
un registro único, oportuno y veraz de todas las transacciones presupuestarias, contables, de
tesorería y de servicio a la deuda realizadas como resultado de la operativa habitual de la
administración de las finanzas públicas. A su vez debe permitir a los funcionarios encargados
de la intervención y auditoría observar el correcto funcionamiento y el cumplimiento de la
legalidad en cada una de las operaciones realizadas.
Modelo Conceptual del SIIF2 01/04/2014 20/203
Por su parte, el SIIF2 Agregación se encarga de aglutinar y almacenar toda la información
de detalle obtenida a través del SIIF2 Transaccional y prepararla para que pueda ser
explotada en forma de reportes orientados a usuarios tácticos y estratégicos. El SIIF2
Agregación proporcionará información de cada uno de los incisos así como información
consolidada de todas las instituciones del ámbito de cobertura, la cual será de gran utilidad
para la toma de decisiones tanto por parte de los incisos como de los Organismos Rectores.
Desde el SIIF2 Agregación se contará con todos los elementos necesarios para poder
realizar los Estados Financieros del Gobierno Central Consolidado, como así también los
Estados Financieros Individuales de cada uno de los entes contables definidos en el ámbito
de cobertura del SIIF2.
De forma más precisa, el SIIF2 Transaccional se organiza en cuatro módulos principales,
Presupuesto, Contabilidad, Deuda y Tesorería.
Presupuesto: que contempla la formulación, la ejecución, las asignaciones y la
evaluación presupuestaria.
Contabilidad: que ejerce de núcleo integrador del sistema puesto que el resto de
subsistemas impactan en ella de forma constante.
Tesorería: que gestiona la Cuenta Única, el plan de caja, la ejecución de los pagos y
cobros y el registro de los ingresos.
Deuda: el módulo de deuda que registra tanto las emisiones como la gestión del
servicio de la deuda.
Además el SIIF2 deberá proporcionar funciones de soporte a la gestión financiera. La
definición de optimizaciones en aspectos relacionados a la usabilidad del SIIF2 que mejoren
la interacción del usuario con el sistema bajo un entorno de uso amigable, es un aspecto
central en el momento de promover mejoras en las funciones de soporte a la gestión
financiera. En los casos donde el sistema se encuentra orientado al registro de transacciones
financieras-contables y no al apoyo de los procesos financieros, es posible observar la mala
práctica de acumular información a lo largo del mes, y sólo concentrar su registro en el
sistema, generalmente en las áreas de contabilidad, en las fechas cercanas al cierre
presupuestario / contable mensual. Por ello se propone la inclusión de las siguientes
funcionalidades que mejoren en forma sustantiva la usabilidad del SIIF2: orientación a
documentos de negocio, seguimiento administrativo y alarmas financieras.
Como parte del desafío de modificar el enfoque del SIIF actual, desde un sistema orientado a
las funciones a un sistema orientado a los procesos, el SIIF2 deberá incorporar
funcionalidades de apoyo a la operación financiero contable es un factor que promueve
este cambio de orientación promoviendo la captura de información en forma oportuna. Para
ello el sistema debe registrar información de los montos comprometidos para ejercicios
posteriores al vigente y debe también automatizar la mayor cantidad posible de tareas
realizadas por los usuarios en forma repetitiva basados en cálculos realizados sobre
algoritmos simples.
El SIIF actual presenta debilidades en las funciones de apoyo específicas para las tareas de
auditoría, tanto para las realizadas por el Tribunal de Cuentas como por los órganos internos
de auditoría. El SIIF2 debe permitir automatizar la realización de las funciones de control y
auditoría tanto de los órganos de control externos como internos.
La cobertura institucional tiene necesidades de gestión particulares motivadas por la
diversidad de servicios que el aparato estatal presta a la ciudadanía. Ello implica que el
SIIF2, tanto en el registro de la información, como en la explotación de la misma debe ser
Modelo Conceptual del SIIF2 01/04/2014 21/203
capaz de acomodar estas diferencias a través de funcionalidades avanzadas de
Configuración. Sólo así el sistema aportará valor a los Incisos y Unidades Ejecutoras, al
respetar, en la medida de lo posible, sus particularidades. Un sistema que no contemple este
aspecto aporta un gran valor a los Órganos Rectores pero un valor cuestionable a las
distintas entidades públicas, desincentivando su utilización.
La reportabilidad es uno de los elementos principales de todo sistema de información y
constituye uno de los productos que mayor valor añadido ofrece tanto al usuario operativo
como al usuario estratégico. En la definición de reportabilidad del SIIF2 distinguimos cinco
tipos de reportes distintos:
Reporte de búsqueda: reportes asociados al sistema transaccional que permite
obtener listados de las principales entidades del sistema según un conjunto de filtros
predefinidos. El usuario objetivo es todo aquel que use el sistema transaccional para
registrar la información o auditar la información registrada.
Reporte operativo: reportes asociados a la operación de una unidad ejecutora.
Permite ver información con mayor nivel de transformación que las búsquedas. El
usuario objetivo es tanto un responsable de unidad ejecutora como un perfil
operativo al interior de la unidad ejecutora.
Reporte analítico: reportes que permiten ver información a nivel de inciso o de
todas las instituciones del ámbito de cobertura del SIIF2. Permiten ver información
con mayor nivel de transformación que los reportes operativos. El usuario objetivo es
un perfil táctico o estratégico con responsabilidad de análisis sobre un inciso o
incluso sobre el conjunto de incisos.
Reporte estratégico: reportes que permiten ver información a nivel de inciso de toda
la administración central. Presentan información en base a indicadores y gráficos que
permiten monitorear los principales objetivos de gestión y gobierno. El usuario
objetivo es un perfil estratégico con responsabilidad de análisis sobre la
administración central normalmente perteneciente a los OO.RR.
Área de análisis: el área de análisis es un lienzo en blanco donde el usuario tiene
acceso a las medidas y dimensiones de análisis a partir de las cuales se genera la
reportabilidad analítica y estratégica. Sobre los datos almacenados el usuario puede
crear sin restricción sus análisis ad-hoc combinando a su libre voluntad las métricas
y dimensiones disponibles. El usuario objetivo es un perfil con un nivel de usuario
avanzado de herramientas de Inteligencia de Negocio (BI) que da soporte analítico a
niveles directivos del MEF o de los Incisos.
Considerando la mayor utilización de sistemas de información en el ámbito público es cada
vez es más crítico que dichos sistemas tengan la capacidad de intercambiar información
entre ellos. En un SIAF este aspecto es de vital importancia puesto que en muchos casos
depende de la capacidad de interoperar que dicho sistema sea “integrado” o no. La
interoperabilidad es una capacidad indispensable para el SIIF2. Esta funcionalidad se
desarrollará potenciando y/o aprovechando la plataforma de interoperación del estado
uruguayo desarrollada por la AGESIC en todos los casos que sea posible.
IV. Principales Aspectos de la Integración Presupuestaria y Contable
El Módulo de Presupuesto y el Módulo Contable son partes esenciales -no las únicas-, del
Sistema Integrado de Administración Financiera, como es el caso del SIIF2. Ambos tienen
elementos propios y comunes, pero uno se complementa con el otro, por lo cual deben
Modelo Conceptual del SIIF2 01/04/2014 22/203
funcionar en forma integrada, respetando sus individualidades y sus objetivos. A modo de
ejemplo: El presupuesto tiene por objetivo estimar los recursos y gastos del Estado, y
posteriormente gestionar su ejecución, en tanto que la contabilidad tiene por objetivo captar
la ejecución desde el punto de vista financiero y económico y elaborar la rendición de
cuentas. Ambos módulos se integran en un esquema de base devengando de la gestión del
gasto público. Por lo tanto la sinergia entre ambos módulos de forma integrada en el SIIF2
permite la obtención de información fiscal para la toma de decisiones, mejorando a su vez la
rendición de cuentas.
Desde el punto de vista de las transacciones presupuestarias / contables, la integración de
las mismas puede visualizarse a partir de la clasificación económica del presupuesto, que lo
ordena en tres grandes grupos y los relaciona de la siguiente forma:
Clasificación Económica del Presupuesto Plan de Cuentas Contable
1. Cuenta Corriente (ingresos corrientes
menos los gastos corrientes)
1. Directamente relacionadas con las
Cuentas de Resultado (ingresos / gastos)
2. Cuenta de Capital (ingresos de capital menos los gastos de capital)
2.1 Ingresos de Capital 2.1 Disminución de Activo no corriente
2.2 Gastos de Capital 2.2 Incremento en el Activo no corriente
3. Financiamiento (fuente menos aplicaciones)
3.1 Fuentes 3.1 Incrementos de Activos Corrientes contra
incrementos de Pasivos no Corrientes o
Patrimonio.
3.2 Aplicaciones Financieras 3.2 Disminuciones de Activos Corrientes
contra disminuciones de Pasivos Corrientes
y Pasivos no Corrientes.
El SIIF2 requiere sustentarse en el principio conceptual y organizativo de centralización
normativa y descentralización operativa. Esto implica que se concentren las funciones de
diseño de políticas, dictado de normas y metodologías, así como las funciones de
evaluación, y se desconcentren las funciones operativas o de gestión.
La centralización normativa significa:
Definir las políticas generales que enmarcan el funcionamiento de cada uno de los
módulos;
Elaborar y supervisar el cumplimiento de las normas, metodologías y procedimientos
generales y comunes que regulan la operatoria del sistema, sin perjuicio de las
adaptaciones que deban realizarse en forma descentralizada en función a las
particularidades de determinadas agencias públicas;
Administrar el sistema y producir la información relevante que le corresponda a éste;
Evaluar el cumplimiento de las políticas.
Modelo Conceptual del SIIF2 01/04/2014 23/203
La descentralización operativa significa:
Fortalecer la capacidad administrativa de las dependencias y entidades públicas para
que puedan ejecutar eficientemente sus objetivos, metas y programas en el marco
de las políticas definidas centralizadamente.
Bajo el Modelo Conceptual del SIIF2, el Módulo de Contabilidad debe cumplir la función de
núcleo integrador del mismo, dado que cuando las transacciones se devengan, cualquiera
sea su módulo de origen, impactan en la contabilidad (registro contable), aún aquellas que no
tengan efecto presupuestario, las cuales son de carácter económico. El SIIF2, desarrollado
con esta concepción, permitirá que los distintos Estados Financieros que se elaboren sean
coherentes entre sí, al ser originados en la misma fuente informativa, permitiendo además el
acoplamiento modular y automático de la información necesaria para las estadísticas fiscales
como por ejemplo las utilizadas en el Sistema de Cuentas Nacionales de las Naciones
Unidas o para las Estadísticas de las Finanzas Públicas del Fondo Monetario Internacional,
los cuales deben derivarse de la misma fuente informativa. Este cambio es un avance
sustancial con respecto a la actual versión del SIIF, la cual no cuenta con la posibilidad de
generar este tipo de información.
Los requisitos mínimos que debe cumplir el SIIF2 para que el módulo contable sea el
núcleo integrador se relacionan en forma directa con la forma de registro de las
transacciones con efectos económico- financieros, la cual debe cumplir con las siguientes
premisas:
Registro único de cada transacción;
Definir claramente la estructura organizativa financiera del Sector Público;
Clasificadores Presupuestarios y Planes de Cuentas Contable complementarios e
integrados;
Matriz de conversión presupuesto / contabilidad desarrollada;
Definición precisa de los momentos de registro.
V. Módulos principales del SIIF2
Como fuera señalado anteriormente, el SIIF2 está compuesto por cuatro módulos principales:
Presupuesto, Contabilidad, Tesorería y Gestión de la Deuda. Esta composición difiere en un
punto central con la estructura actual del SIIF, el cual no cuenta con el Módulo de
Contabilidad desarrollado en forma completa. Esto genera en la actualidad la imposibilidad
de generar todos los Estados Financieros en forma automática desde el propio SIIF. En
forma esquemática, en los siguientes puntos se detallan las funcionalidades centrales de los
módulos principales del SIIF2.
Módulo Presupuestario
El módulo de presupuesto del SIIF2 contempla las funcionalidades necesarias para el
registro y la gestión asociada a todo el ciclo presupuestario, tanto para gastos como para
ingresos, considerando las etapas del ciclo presupuestario de la siguiente forma:
La formulación presupuestaria: original del presupuesto quinquenal de la República
Oriental del Uruguay y las formulaciones anuales actualizadas mediante el ajuste de
los valores e indicadores y las sucesivas rendiciones de cuentas, los que generarán
los créditos disponibles para los ejercicios sucesivos del quinquenio.
Modelo Conceptual del SIIF2 01/04/2014 24/203
La ejecución presupuestaria: que toma como insumo el presupuesto producido por el
proceso de formulación presupuestaria (quinquenal y anual) y controla y gestiona su
ejecución durante cada ejercicio fiscal.
La evaluación presupuestaria: que toma como insumo la información de la fase de
formulación presupuestaria y la información de la ejecución presupuestaria para
proceder a la evaluación, principalmente de carácter financiero, retroalimentando el
ciclo presupuestario.
Por tanto la implementación del módulo presupuestario, necesariamente requerirá como
primera etapa del ciclo la formulación, no puede iniciarse en la ejecución, si no se genera el
problema del SIIF actual – diferencias en las cifras presupuestarias del SIP (valores
históricos) y el SEG valores nominales.
El detalle de los requisitos de negocio necesarios para el correcto funcionamiento de este
módulo se encuentra en la sección 5.2.2.
Ilustración 1 Estructura de los módulos principales del SIIF2
Módulo Contable
En el Sector Público, la contabilidad – denominada gubernamental – requiere de la definición
de criterios técnicos específicos concordantes con los fines propios de las instituciones
públicas, al tiempo que demanda una práctica armónica e integrada con distintos procesos
de administración y producción de información. En ese sentido, debe asegurarse una
coherencia relacional y permanente integración de la contabilidad con los aspectos de índole
presupuestaria, de caja, de la recaudación, de administración de la deuda pública, de
compras, de bienes y, en general, con todo proceso de las instituciones públicas que
Modelo Conceptual del SIIF2 01/04/2014 25/203
implique, directa o indirectamente, variaciones o explicación de variaciones en la situación
económico-financiera del ente.
El rol de la contabilidad gubernamental en este nuevo milenio ha cambiado, ha crecido y,
conceptualmente, se ha jerarquizado producto del nuevo enfoque dado a la Administración
Financiera donde, entre otros aspectos, la Contabilidad Gubernamental es el sistema
integrador de toda la información sobre transacciones y flujos no transaccionales que hacen
a la gestión administrativo-financiera del Estado.
Por lo expuesto el Módulo Contable, se concibe como: el conjunto de principios, normas,
organismos, y procedimientos técnicos utilizados para registrar, valuar, procesar, exponer e
informar sobre las transacciones producidas por los ejecutores del gasto e ingreso público y
los hechos económicos que afecten o puedan llegar a afectar el patrimonio público.
El Módulo Contable tiene como objetivo principal: producir, en tiempo y forma los Estados
Financieros (EEFF) necesarios para mostrar los resultados de la gestión presupuestaria y
económica, así como la situación patrimonial de las organizaciones públicas, a efectos de
que la misma permita la toma de decisiones y fundamentalmente producir la Rendición de
Cuentas del Gobierno Uruguayo dentro de un marco de absoluta transparencia.
A modo de complemento, el objetivo principal del Módulo Contable, cuenta con objetivos
específicos tales como:
Ser el núcleo integrador del SIIF2,
Registrar sistemáticamente todas las transacciones que se produzcan y afecten o
puedan afectar el Patrimonio de entidades del Estado Uruguayo,
Procesar y producir información financiera para la toma de decisiones por los
responsables de la gestión financiera pública y para los terceros interesados en la
misma,
Presentar la información contable necesaria para facilitar las tareas de control, sean
éstas internas o externas,
Estar orientado a la obtención de costos de las actividades del Sector Público,
Permitir que la información que se procese y produzca sobre el Sector Público
Uruguayo se integre al Sistema de Cuentas Nacionales,
Llevar la contabilidad centralizada dentro del siguiente ámbito de cobertura:
Administración Central (Incisos 02 al 15, 20 al 24 y 30), los Organismos del Articulo
220 de la Constitución (Poder Judicial, Tribunal de Cuentas, Corte Electoral, Tribunal
de lo Contencioso Administrativo, ANEP, UDELAR INAU, ASSE, UTEC) y Poder
Legislativo,
Permitir obtener la información Consolidada del Sector Público Uruguayo, bajo
diferentes esquemas que consideren, por ejemplo, tanto al Subsector Gobierno
Central como a los Entes Autónomos.
El detalle de los requisitos necesarios para el correcto funcionamiento de este módulo se
encuentra en la sección 5.3.2.
La integración presupuestaria y contable descrita en la sección 4 del documento de
manera conceptual se detalla en requisitos concretos en los apartados 5.2.3 y 5.3.3. Uno de
los aspectos fundamentales es que todo registro de un devengo presupuestario sea
acompañado de forma automática en el sistema por el asiento contable asociado a dicho
movimiento.
Modelo Conceptual del SIIF2 01/04/2014 26/203
Módulo de Tesorería
El módulo de tesorería debe contemplar las funcionalidades necesarias para el registro y la
gestión asociada a la recaudación y pago de todos los recursos que forman parte de la
gestión del presupuesto. De cara a su adecuado funcionamiento deberá desarrollarse
siguiendo los siguientes principios:
Eficiencia: La gestión de tesorería debe velar por la administración de los fondos
públicos, cualquiera que sea la fuente de financiamiento y uso de los mismos, y de
los títulos y valores en custodia, programando oportunamente los compromisos,
obligaciones y pagos para ejecutar el presupuesto de gastos, viabilizando su óptima
aplicación y realizando un seguimiento permanente, minimizando costos de
funcionamiento.
Prudencia: Toda la gestión de tesorería se debe realizar bajo un estricto criterio de
prudencia, minimizando los riegos en el proceso de administración y obtención de
rendimientos de los recursos públicos.
Oportunidad: La ejecución de los procedimientos relacionados a la tesorería deben
realizarse utilizando los mecanismos más idóneos que aseguran la pronta
disponibilidad de los recursos en un marco de eficiencia, otorgando una mayor
previsibilidad a las fechas de pago de las obligaciones del Estado, que mejoren la
transparencia de la gestión financiera.
Unidad de Caja: Los ingresos públicos se acreditarán en una Cuenta Única del
Tesoro, independientemente del concepto u origen de los mismos, y contra dicha
cuenta se debitaran todos los pagos que correspondan realizar según las
obligaciones legalmente asumidas por las Entidades Públicas.
El detalle de los requisitos necesarios para el correcto funcionamiento de este módulo se
encuentra en la sección 5.4.2.
Módulo de Deuda
El Módulo de Deuda debe contemplar las funcionalidades necesarias para el registro y la
ejecución de las operaciones de crédito público que realiza el Estado en el marco de las
autorizaciones legales correspondientes, así como la ejecución de las operaciones
destinadas al pago de los servicios de la deuda.
Bajo la estructura institucional actual de la República Oriental del Uruguay la gestión de la
Deuda Pública se realiza en forma coordinada por el Banco Central y el Ministerio de
Economía y Finanzas. Por lo tanto, los requisitos del SIIF2 deben considerar esta forma de
funcionamiento.
El Módulo de Deuda debe considerar los siguientes principios para su adecuado
funcionamiento:
Eficiencia y prudencia: El endeudamiento público tiene como objetivo fundamental
cubrir los requerimientos de financiamiento del sector público al más bajo costo
posible, optimizando los recursos y sujeto al menor grado de riesgo posible.
Transparencia: El proceso de endeudamiento público debe llevarse a cabo con
oportunidad, transparencia, procurando el acceso oportuno a información veraz,
comprensible y confiable.
Modelo Conceptual del SIIF2 01/04/2014 27/203
Oportunidad: La ejecución de los procedimientos relacionados a la gestión de la
deuda deben realizarse utilizando los mecanismos más idóneos que aseguran la
pronta disponibilidad de los recursos en un marco de eficiencia, otorgando una
mayor previsibilidad a las fechas de pago de las obligaciones del Estado, que
mejoren la transparencia de la gestión financiera.
El detalle de los requisitos necesarios para el correcto funcionamiento de este módulo se
encuentra en la sección 5.5.2.
VI. Integración de los sistemas de apoyo transversales
La capacidad de interoperar del SIIF2 con el resto de los sistemas del sector público es una
característica fundamental del nuevo sistema. Por esta razón, en la Sección 6 del documento
se especifican en forma detallada los sistemas con los que interoperará el SIIF2. Para cada
sistema se presenta una breve descripción de sus principales objetivos, las interacciones
detectadas como relevantes y los impactos o riesgos que los volúmenes de información,
requeridos por la interoperación, podrían poner sobre la infraestructura y el diseño del
sistema. Los sistemas requeridos para interoperar son:
Sistema de Compras y Contrataciones Estatales (SICE)
Sistema Lucia (DNA)
Sistemas de la Dirección General Impositiva (DGI)
Registro Único de Proveedores del Estado (RUPE)
Sistema de Distribución del Gasto (SDG)
Sistema de Presentación del Articulado (SPA)
Sistema Nacional de Inversiones Públicas (SNIP)
Sistema de RR.HH (SGH-SLH)
Sistema de Planificación Estratégica y Evaluación (SPE)
Sistemas del BROU
Sistemas del BCU
Sistemas del BPS
Sistemas GRP
VII. Modelado BPM del ciclo presupuestario
El modelado de alto nivel del ciclo presupuestario pretende mostrar en forma gráfica el
funcionamiento actual y donde corresponda, las modificaciones sugeridas al ciclo de gestión
del gasto público. De esta forma, la Sección 7 del documento contiene la situación actual
(“As Is”) de los principales procesos del ciclo presupuestario modelados según metodología
BPM. En forma adicional al objetivo antes señalado, esta Sección tiene como objetivo
secundario representar gráficamente el ciclo presupuestario, con el fin de ser incorporado
como Anexo en los Términos de Referencia y permitir a los potenciales proveedores tener
una idea de alto nivel del flujo de funcionamiento actual de dichos procesos.
Modelo Conceptual del SIIF2 01/04/2014 28/203
VIII. Arquitectura tecnológica de base del sistema
La definición de la arquitectura tecnológica de base es un aspecto central en la definición del
SIIF2. Por este motivo, en la Sección 8 se describen en detalle los elementos tecnológicos
que conforman la plataforma base propuesta para el SIIF2.
El objetivo de este apartado es presentar el diseño arquitectónico base para soportar el
desarrollo y posterior operación del SIIF2. Se denomina “Arquitectura Tecnológica Base”
debido a que establece las estructuras fundamentales sobre las cuales se podrá definir y
refinar la arquitectura completa del sistema. Los contenidos definidos en este diseño
permitirán anticiparse a problemáticas técnicas que recurrentemente aparecen en desarrollos
de gran escala.
La base tecnológica definida se centra en las piezas de middleware sobre las que se
ejecutará el SIIF2, e identifica todas las que se necesitarán para manifestar los atributos de
calidad del sistema detectados como requerimientos en la fase de análisis de este proyecto.
Las distintas piezas de la plataforma se describen en base a seis capas:
Presentación, cuyos elementos soportan la ejecución de los componentes de la
interfaz de usuario de los distintos módulos del sistema.
Negocio, cuyos elementos soportan la ejecución de los componentes que
encapsulan la lógica y las reglas de negocio más invariables del sector público, en el
dominio presupuestario, financiero y contable.
Datos, cuyos elementos permiten el almacenamiento y manipulación de la
información persistente del sistema.
Gestión de procesos, cuyos elementos soportan la ejecución de los componentes
que capturan la lógica y las reglas de negocio más dinámicas del sector público, y
que permiten implementar, monitorizar y optimizar los procesos institucionales de
manera altamente flexible y configurable.
Integración, cuyos elementos soportan la ejecución de los componentes que
permiten la interoperación entre elementos internos y sistemas externos.
Seguridad, cuyos componentes permiten otorgar los niveles requeridos de
identificación, aseguramiento, no repudio e integridad al sistema.
IX. Evaluación normativa
En esta sección del documento se realiza un análisis de la normativa existente y relevante a
los efectos del SIIF2.
A partir de esta identificación normativa se realizó un análisis de los requerimientos
establecidos por el Modelo Conceptual diseñado a los efectos de determinar los casos que
requieran ser normados para entrar en funcionamiento.
De este análisis se concluye que bastaría de una disposición reglamentaria bajo la forma de
un Decreto reglamentario del Poder Ejecutivo y se presenta un esbozo del contenido a incluir
en el mismo.
Modelo Conceptual del SIIF2 01/04/2014 29/203
XI. Comentarios Finales
El desarrollo de un Modelo Conceptual que defina en forma precisa el alcance, la forma de
funcionamiento integrado de las principales funcionalidades financiero contable y el ámbito
de cobertura del SIIF2 es un pre requisito indispensable para la etapa de desarrollo del
sistema de información.
Como resultado de las actividades realizadas por el equipo consultor es posible plantear que
actualmente la CGN cuenta con una base sólida de definiciones conceptuales que permitirán
desarrollar de manera adecuada los Términos de Referencia para contratar el desarrollo del
SIIF2. En especial se debe mencionar los siguientes aspectos contemplados en el Modelo
Conceptual elaborado:
Desarrollo de los conceptos fundamentales para la integración presupuestaria
contable, núcleo central para lograr una gestión presupuestaria en base devengado,
iniciando este proceso por una gestión presupuestaria en base caja modificada,
donde ciertos gastos e ingresos se registran bajo el concepto de devengado y otros
permanecen bajo el concepto de percibido, en especial los ingresos, de acuerdo a
los principios recomendados por las IPSAS.
Propuesta de una visión integrada del SIIF2, bajo un enfoque de procesos en lugar
del actual enfoque de funciones, el cual tiene como consecuencia la doble digitación
de información en el mismo sistema o la inconsistencia de información entre los
distintos sistemas que componen el actual SIIF.
Definición de un módulo de reportabilidad con más y mejores funcionalidades que las
actualmente ofrecidas por el SIIF, con el fin de apoyar tanto la gestión a nivel de los
Incisos como la gestión fiscal del MEF.
Fortalecimiento de los procesos de control, automatizando en forma especifica
dentro del sistema el momento del intervenido por parte del Tribunal de Cuentas, así
como del proceso de Rendición de Cuentas mediante la generación de los Estados
Financieros en forma automática desde el propio sistema.
Incremento de las capacidades de interoperabilidad del SIIF2 con el resto de los
sistemas del sector público, como por ejemplo el sistema de compras y
contrataciones, como también con sistemas de gestión institucionales, como el
proyecto GRP impulsado por la AGESIC. Este incremento de capacidad de
interoperación será consecuencia tanto del enfoque funcional como de la
arquitectura tecnológica de base propuesta.
Modelo Conceptual del SIIF2 01/04/2014 30/203
3. Modelo Conceptual de alto nivel del Sistema Integrado de
Información Financiera
3.1 Introducción
Un instrumento central para la gestión financiera contable del sector público es la utilización
de tecnologías de la información y comunicación (TICs), bajo la forma de Sistemas
Integrados de Administración Financiera (SIAF). En forma estilizada, el SIAF es una
herramienta que permite la gestión sistemática e integrada de los recursos públicos, y la
información generada por el sistema actúa como instrumento que facilita la toma de
decisiones, promoviendo una gestión del gasto público más eficaz, eficiente y transparente.
En este contexto el concepto SIAF hace referencia al uso de TICs en la gestión financiera
con el fin de apoyar las decisiones presupuestarias, las responsabilidades de la gestión de
los recursos públicos y la mejora del desempeño de las entidades públicas, así como la
preparación de los Estados Financieros, que incluyen los estados contables, los estados de
ejecución presupuestaria, los informes de flujos de fondos, el estado de la deuda pública y el
estado de activos fijos.
Un proyecto de fortalecimiento de este tipo de sistema, como es el caso del Sistema
Integrado de Información Financiera (SIIF) del Ministerio de Economía y Finanzas de la
República Oriental del Uruguay requiere la definición de una estrategia de desarrollo
consistente y sólida. Para ello es necesario el desarrollo de un Modelo Conceptual, que
establezca con precisión el alcance funcional del sistema, la definición de la arquitectura de
base a utilizar y la programación de las fases de desarrollo necesarias para implementar el
SIIF2.
En líneas generales un Modelo Conceptual (MC) debe definir los objetivos, el alcance y la
cobertura del SIAF, junto con una visión general del marco de la gestión financiera pública,
los principales requisitos de los usuarios y los procesos clave de la gestión financiero
contable que el sistema de información debe apoyar, junto a la definición de la arquitectura
tecnológica de base para su desarrollo. Es muy importante considerar que el MC difiere de
las especificaciones detalladas del sistema de información. Las definiciones del MC proveen
el marco general para la elaboración de los requisitos funcionales más detallados, los cuales
deben ser elaborados en la fase de desarrollo del sistema. Pero si es de suma importancia
que este instrumento establezca con precisión las principales reglas de negocio del ciclo
presupuestario y su integración con la contabilidad.
En el caso particular del SIIF2, el MC debe sustentarse en la aplicación del principio de
centralización normativa y descentralización operativa, dimensión clave para definir el
alcance del sistema de información, como así también definir las reglas de negocio relativas
al proceso de ejecución presupuestaria y contable, considerando con especial atención las
relativas al proceso de integración automático del ciclo financiero – contable
(presupuesto/contabilidad/tesorería/deuda pública) que rige la gestión financiera pública, con
un enfoque de base devengado para los gastos y recursos o base caja modificado para los
recursos. Así, en el MC se deben detallar con precisión las principales definiciones
funcionales, que interrelacionan la cadena financiero contable en las distintas etapas
Modelo Conceptual del SIIF2 01/04/2014 31/203
presupuestarias1 (aprobado, modificado y comprometido), contables (devengado y obligado)
y tesorería (pagado), como así también las reglas correspondientes a los procesos de cierre
y apertura anual presupuestario y contable de cada ejercicio fiscal y considerar la revisión de
los principales conceptos que dan soporte a la implementación de un Sistema de Cuenta
Única del Tesoro, instrumento clave para realizar una gestión moderna de caja.
A su vez, el MC debe indicar con precisión cuáles serán las salidas del sistema, en especial
las salidas contables definiendo los Estados Financieros que contendrán los estados básicos
más los estados complementarios necesarios para una rendición de cuentas transparente
sustentadas por una parte, en el cumplimiento de la normativa nacional referente a las
responsabilidades dentro del sector público, y, por otra parte, en los lineamientos
internacionales contable dados por la IFAC (Normas Internacionales de Contabilidad para el
Sector Público) y para apoyar la gestión de la política fiscal en el Manual de Estadísticas de
Finanzas Públicas del FMI y el Manual de Cuentas Nacionales de las Naciones Unidas. Todo
ello permitirá la generación de información relevante, oportuna y confiable para la toma de
decisiones y para la rendición de cuentas.
Realizar este conjunto de definiciones funcionales implica una revisión de la aplicación de los
criterios normativos tanto a nivel de procesos como a nivel de los sistemas de información
actualmente en uso, así como una revisión del marco normativo de la gestión financiera
pública En ciertas ocasiones, los criterios normativos de las etapas básicas de la gestión
financiera pública presentan ciertas debilidades que deben ser fortalecidas. En otros casos,
el marco normativo presenta ciertas interpretaciones a nivel de procesos y/o implementación
en los sistemas de información que deben ser revisadas para optimizar la gestión del gasto
público.
A nivel de implementación de los sistemas de información, el SIIF, al igual que otros SIAF en
la región es un sistema orientado a las funciones, que contiene, por ejemplo, un módulo de
presupuesto y un módulo de pagos, con baja integración entre ellos, en lugar de ser un
sistema de información orientado a los procesos, el cual refleja de mejor forma el flujo
habitual de la gestión financiera en forma integrada. Un sistema orientado a procesos busca,
por ejemplo, generar en forma automática, a partir de la captura de información en base a
documentos de negocio (por ejemplo contratos o facturas), la cadena presupuestaria
contable que maximice la utilización de la información heredada en el mismo sistema,
evitando su doble digitación, ya sea en el mismo SIAF o en otros sistemas relacionados,
como por ejemplo el sistema de inversión pública.
Si bien el MC debe contener las definiciones funcionales más relevantes para la integración
de los módulos principales que componen el SIAF (presupuesto, contabilidad, tesorería y
deuda pública), también es necesario que el MC explicite con un mayor nivel de detalle las
principales características funcionales del sistema y su arquitectura tecnológica de base para
el desarrollo del SIIF2.
En relación a las principales características funcionales, partiendo de la integración
automática entre el Clasificador Presupuestario y el Plan de Cuentas Contables y
continuando con las funcionalidades básicas destinadas a registrar la ejecución
presupuestaria con la obtención del registro contable en forma automática, un SIAF también
1 En esta sección se indican en forma genérica las distintas etapas presupuestarias y contables, que
incluyen tanto gastos como recursos, las cuales son detalladas en la Sección IV y Sección V.
Modelo Conceptual del SIIF2 01/04/2014 32/203
debe incorporar el registro contable de las transacciones que no tienen impacto
presupuestario, administrar los activos, gestionar los recursos y administrar los pagos, entre
otras funciones. A su vez, en forma creciente los SIAF deben contar con nuevas
funcionalidades que permitan optimizar la gestión financiera pública. A modo de ejemplo, es
posible mencionar funciones de apoyo a la gestión administrativa o de apoyo a las tareas de
auditoría, junto a la posibilidad de contar con potentes herramientas de generación de
reportes en formato flexibles.
Por su parte, la adopción de una arquitectura tecnológica de base para el SIIF2 tiene como
objetivo, desde un punto de vista conceptual, establecer los lineamientos comunes que se
deben utilizar para todos los componentes y módulos que conforman el sistema de
administración financiera. De esta forma, será posible desarrollar soluciones a medida o
parametrizar paquetes comerciales de software bajo capas de arquitectura comunes, que
permitan unificar aspectos referidos a conectividad, usabilidad, seguridad o mecanismos de
generación de reportes. Es preciso señalar que el desarrollo de un sistema de administración
financiera se produce en distintas etapas, generalmente asociadas a las distintas fases del
ciclo presupuestario. Por lo tanto, es necesario evitar que se produzcan problemas de
integración entre distintos módulos del SIIF2 por incompatibilidad de su arquitectura
tecnológica de base.
Para definir una arquitectura de base, resulta necesario identificar los atributos de calidad
básicos del sistema y las capas de software comunes a todas las aplicaciones. A modo de
ejemplo es posible mencionar como atributos de calidad que el sistema genere información
oportuna, que cumpla con parámetros de performance predefinidos, que cuente con
capacidad de incorporar modificaciones a los procesos o nuevos campos de información en
forma rápida, que presente gran capacidad para interoperar con otros sistemas de
información.
Considerando la relevancia de las definiciones funcionales y de arquitectura tecnológica de
base necesarias para el desarrollo del SIIF2, en los apartados siguientes se desarrollan en
detalle los distintos componentes funcionales y tecnológicos mencionados.
3.1.1 Objetivos del sistema
El SIIF2 debe transformarse en una potente herramienta para la gestión del Presupuesto
Nacional y de la Rendición de Cuentas en la República Oriental del Uruguay, promoviendo el
logro de los principales objetivos de la gestión moderna del gasto público.
Disciplina fiscal, contando con información oportuna para monitorear y controlar la
evolución del gasto público en línea con las capacidades actuales y proyectadas de
financiamiento del Sector Público.
Eficiencia en la asignación y captación de los recursos, generando mayor y mejor
información para la toma de decisiones sobre la priorización de políticas y programas
públicos en distintos niveles de la Administración Pública.
Eficiencia operacional, proporcionando herramientas prácticas que faciliten la gestión
de los recursos financieros y brinden información oportuna y relevante para la toma
de decisiones a nivel operativo en los Incisos.
Eficiencia en la rendición de cuentas, generando información contable oportuna y
confiable que le permita dar mayor transparencia a las cuentas públicas.
Modelo Conceptual del SIIF2 01/04/2014 33/203
Para ello, considerando los avances realizados a la fecha por el MEF en la gestión
presupuestaria, las nuevas definiciones funcionales a adoptar y las potencialidades que
brinda la tecnología actualmente, el SIIF2 tendrá como objetivos,
Apoyar una mejor gestión de la política fiscal, en base a la captura y generación de
información que permite dar cuenta de la posición financiera en un momento
determinado en forma oportuna a partir de la conformación de una base de datos
precisa y continuamente actualizada, con cobertura total del Presupuesto Nacional.
Registrar las transacciones con impacto financiero contable de forma más oportuna,
confiable y segura, a partir de la automatización del manejo de la información en
sistemas de información que aseguran el cumplimiento de las normas financiero -
contables y brinden mayores niveles de seguridad y trazabilidad a los datos.
Exponer información económica, financiera y patrimonial tal que permita realizar la
evaluación de la gestión administrativa financiera pública, así como la rendición de
cuentas sustentada en estándares internacionales.
Capturar y proveer información financiera, no financiera y de desempeño que
contribuye al mejoramiento de la eficacia y eficiencia de la gestión pública Así, la
información financiera es básica para la gestión del presupuesto público y la
rendición de cuentas, pero la información referente, por ejemplo, al tamaño de la
dotación de personal y los rangos de remuneración es información no financiera
también muy relevante. A su vez, la información sobre desempeño es un requisito
central en la implementación de un Presupuesto por Resultados, donde las
decisiones requieren información relativa a los objetivos y metas de los programas,
los tipos de bienes y servicios producidos así como también los indicadores mediante
los cuales se miden la eficacia y eficiencia de los programas y políticas públicas. De
este modo, contar con información financiera, no financiera y de desempeño
comprehensiva opera como insumo básico que contribuye al fortalecimiento de la
planificación, seguimiento y evaluación del gasto público en particular y de la gestión
pública en general.
3.1.2 Alcance del sistema
Todos estos atributos conceptuales de un SIAF se plasman en un sistema de información
concreto, el cual está compuesto por un conjunto de subsistemas o módulos, los cuales se
rigen por principios generales y reglas de negocio que reflejan las normas presupuestarias y
contable que establezca el Órgano Rector y ordenan su funcionamiento, asegurando la
calidad y confiabilidad de la información producida.
En términos generales el alcance del SIIF2 se compone de un conjunto de módulos
principales que operan interrelacionados. Estos módulos son: presupuesto, contabilidad,
tesorería y deuda pública. A su vez, el SIAF cuenta con el apoyo de un conjunto de módulos
complementarios, los cuales se interrelacionan con los módulos principales. Estos módulos
son gestión de recursos humanos, compras y contrataciones, recursos, inversión pública y
administración de bienes, entre otros.
Una adecuada interoperación entre los módulos principales y los módulos complementarios
permite una gestión pública más eficiente, al evitar, por ejemplo, la doble registración de la
información en distintos sistemas asegurando su consistencia. A su vez, fortalece el
ambiente de control sobre las finanzas públicas, generando un registro presupuestario y
contable, sobre la base del devengado, que permita relacionar en forma directa las
operaciones que generan (deudas) o pueden generar (contingencias) obligaciones para el
Modelo Conceptual del SIIF2 01/04/2014 34/203
Estado y la disponibilidad presupuestaria necesaria para afrontar las mismas, evitando la
generación de deuda flotante no registrada, que distorsiona la situación fiscal.
Para que el SIIF2 opere de esta forma se debe diseñar, desarrollar e implementar sobre la
base de las definiciones funcionales del MC y cuatro características principales:
El SIIF2 debe ser una herramienta de gestión que posea la capacidad y flexibilidad
necesaria para cubrir tanto los requerimientos y demandas de los Organismos
Rectores de las finanzas públicas, Ministerio de Economía y Finanzas y la Oficina de
Planeamiento y Presupuesto, así como los Órganos de Control (Tribunal de Cuentas,
Auditoría Interna de la Nación), y los Ministerios.
El SIIF2 debe proveer un amplio rango de información tanto en formatos pre-
establecidos y como en formatos flexibles que permitan promover una mejor toma de
decisiones por parte de los directivos públicos. Esta información se debe elaborar
sobre la base de clasificadores comunes e integrados al interior del sistema de
información que aseguren su consistencia.
El acceso al SIIF2 para registrar transacciones, así como consultar la información
necesaria según cada tipo de usuario, debe realizarse bajo un esquema de definición
de funciones operativas o gerenciales. Para ellos el sistema debe definir y
administrar perfiles de usuarios con distintos privilegios funcionales y de acceso a
información de menor o mayor nivel de agregación y consolidación.
El SIIF2 deberá proveer por lo menos las funcionalidades de que dispone
actualmente el SIIF 1, bien sea de forma directa o bien porque proporciona un
mecanismo alternativo que mejora la situación actual.
REQ 3-1 Alcance del sistema
El SIIF2 deberá proporcionar un alcance según lo descrito en el presente apartado. El SIIF2
deberá proveer al menos las funcionalidades de que dispone actualmente el SIIF 1.
3.1.3 Esponsorización y éxito del proyecto
En forma concurrente a la definición del Modelo Conceptual, existen una serie de
condicionantes que promueven el éxito del proceso de desarrollo e implantación del SIIF2.
Es necesario tener presente que estas condiciones no garantizan por sí solas su reforma
exitosa, pero su ausencia condiciona fuertemente las posibilidades de éxito. Entre los
factores más relevantes es posible mencionar el apoyo de las máximas autoridades y la
participación de los usuarios finales del sistema a lo largo del proceso, junto al fortalecimiento
de capacidades institucionales del sector público.
3.1.3.1 Apoyo de las Máximas Autoridades.
Para el desarrollo de un proyecto de fortalecimiento de la gestión financiera pública es un
prerrequisito contar con el apoyo de las autoridades del Ministerio de Economía y Finanzas.
Estos actores son los usuarios finales de la información generada por el SIIF2 a nivel global.
Contar con información oportuna, relevante y confiable es una potente herramienta para el
manejo de la política fiscal, tanto en épocas de restricciones como de expansiones
económicas. A su vez, en el aparato estatal el rol del Ministerio de Economía y Finanzas es
de suma relevancia sobre el resto de los Ministerios. Por esta razón una iniciativa lanzada y
apoyada por las autoridades económicas tiene mayores probabilidades de éxito,
considerando a su vez que estos proyectos tienen una duración promedio de 4/6 años.
Modelo Conceptual del SIIF2 01/04/2014 35/203
3.1.3.2 Fortalecimiento de las capacidades internas del sector público para el
desarrollo del SIAF
Se debe contar desde un inicio con personal altamente capacitado para el desarrollo del
proyecto al interior del MEF. Para ello es necesario fomentar las capacidades internas del
ministerio, tanto funcionales como de ingenieros de software y hardware, evitando la
contratación excesiva de consultores externos, de modo de facilitar la apropiación interna de
los conocimientos y experiencias. En particular se destaca la necesidad de contar, desde el
punto de vista funcional, con profesionales contables que estén comprometidos con el
cambio, que respeten los conceptos contables, que estén dispuestos a una capacitación
permanente a efecto de jerarquizar la profesión en el Sector Público. Desde el punto de vista
técnico, es preciso contar con un equipo sólido en TI, ya que los servicios públicos suelen
tener personal insuficiente, o sin las capacidades requeridas en esta área.
A su vez, dada la complejidad, magnitud y plazos de este tipo de proyectos, es muy
importante que se defina un Equipo Ejecutor del Proyecto con dedicación exclusiva a las
tareas de conceptualización, desarrollo y prueba del SIIF2. Este Equipo Ejecutor del Proyecto
puede estar compuesto por funcionarios provenientes de las distintas áreas del MEF en
combinación con personal contratado específicamente para el proyecto, junto con la
participación de consultores externos altamente especializados. En el caso que el proyecto
de desarrollo del SIIF2 se realice como parte de una operación de los Organismos
Internacionales de Crédito, la implementación de este Equipo Ejecutor del Proyecto se
debería realizar en forma natural como parte del proceso de definición de la unidad ejecutora
del préstamo.
3.1.3.3 Comité de Usuarios
Es muy importante que desde el inicio de la etapa de desarrollo del SIIF2 se ponga en
funcionamiento un Comité de Usuarios integrado por futuros usuarios del sistema
provenientes de distintas instituciones públicas. Este comité deberá reunirse en forma
periódica con el Equipo Ejecutor del Proyecto, funcionando como instancia de consulta y
validación de las distintas fases del desarrollo. Esta actividad permite, por un lado contar con
el punto de vista del usuario del sistema y por otra parte, comunicar las ventajas de la nueva
versión del sistema a los participantes de las instituciones, iniciando de esta forma el
necesario proceso de gestión del cambio y capacitación que esta iniciativa demanda.
Estas condiciones ponen de relieve que el proyecto de fortalecimiento del SIIF2 requiere ser
desarrollado sobre la base de requisitos de orden técnico pero sin desconocer la importancia
de las condiciones contextuales y políticas. Las reformas no pueden ser desplegadas
exclusivamente sobre las innovaciones del sistema de información y desarrollos
conceptuales y metodológicos, sino que debe tener tanto el respaldo del máximo nivel
político como el compromiso de los cuadros burocráticos del Estado, para lo cual es
necesario definir una adecuada estrategia de gestión del cambio. Tener presente esta
combinación de factores contribuirá en gran medida a llevar adelante exitosamente el
proceso de modernización del SIIF.
3.2 Requisitos generales del SIIF2
En este apartado se describen requisitos generales y de alto nivel que el SIIF2 deberá
cumplir en su globalidad con el fin de cumplir con los objetivos antes descritos.
Modelo Conceptual del SIIF2 01/04/2014 36/203
3.2.1 Cobertura institucional
El SIIF2 tendrá como cobertura la Administración Central (Incisos 02 al 15, 20 al 24 y 30), los
Organismos del Articulo 220 de la Constitución (Poder Judicial, Tribunal de Cuentas, Corte
Electoral, Tribunal de lo Contencioso Administrativo, ANEP, UDELAR, INAU, ASSE, UTEC) y
Poder Legislativo. Además, se debe tener en cuenta que a nivel del Módulo de Contabilidad
debe realizarse la consolidación del Sector Público, por lo cual es necesario contemplar al
resto de las entidades que por si mismas son entes contables.
REQ 3-2 Cobertura institucional
La cobertura institucional del SIIF2 es la Administración Central (Incisos 02 al 15, 20 al 24 y
30), los Organismos del Articulo 220 de la Constitución (Poder Judicial, Tribunal de Cuentas,
Corte Electoral, Tribunal de lo Contencioso Administrativo, ANEP, UDELAR, INAU, ASSE,
UTEC) y Poder Legislativo. Asimismo, el SIIF2, a través del Módulo de Contabilidad debe
realizar la consolidación del Sector Público, para lo cual debe contemplar los mecanismos
necesarios para recibir, procesar y consolidar la información contable del resto de las
entidades que por si mismas son entes contables.
3.2.2 Trazabilidad
Uno de los aspectos principales que aporta un SIAF moderno es la trazabilidad de la
operativa. Esto es que para cualquier transacción del sistema sea posible saber en cualquier
momento quién, cuándo y dónde modificó su estado.
REQ 3-3 Trazabilidad
El sistema permitirá para toda transacción registrada, y para todos sus estados (generada,
aprobada, intervenida), conocer quién, cuándo y dónde modificó el estado de la misma.
3.2.3 Roles y perfiles
El sistema deberá ofrecer mecanismos de autenticación y entrada que permitan habilitar
funciones en función del rol que tenga el usuario (i.e. registrador, auditor, gestor) y validar
privilegios en función de su perfil (i.e. generar o aprobar transacciones, visibilidad sobre
distintos niveles de información).
REQ 3-4 Roles y perfiles
El sistema ofrecerá un mecanismo avanzado de gestión de roles y perfiles. La definición de
roles y perfiles se hará de forma centralizada, la asignación de los usuarios a sus roles y
perfiles se realizará de forma descentralizada.
REQ 3-5 Usuarios con distintos cometidos
El sistema permitirá que un usuario pueda tener más de un rol y perfil determinados y que
pueda cambiar entre ellos de forma eficiente (sin necesidad de salir y volver a entrar al
sistema).
3.2.4 Seguridad
Los mecanismos de seguridad son críticos en un SIAF tanto por la importancia intrínseca de
la información que contienen, como por las consecuencias legales que entrañan, sin olvidar
el impacto práctico evidente que el uso del sistema puede tener (i.e. gatillar pagos
automáticos).
Modelo Conceptual del SIIF2 01/04/2014 37/203
REQ 3-6 Seguridad
El sistema deberá proporcionar los mecanismos de seguridad necesarios para evitar todo
tipo de intrusión tanto interna como externa. El acceso al sistema quedará determinado por el
perfil del usuario. Asimismo se determinará también el conjunto de datos al que tiene acceso
(visibilidad sobre la Unidad Organizativa, la Unidad Ejecutora, el Inciso o toda la
Administración). El sistema contemplará el uso de tokens que permitan identificar
individualmente a aquellos usuarios con permisos para realizar transacciones particularmente
críticas.
3.2.5 Performance y escalabilidad
Los tiempos de respuesta del sistema son críticos para la correcta implantación del mismo en
los distintos Incisos de la cobertura institucional. Estos deben ser cuidadosamente vigilados
en los distintos puntos de interacción con el usuario (sin perjuicio de otros, tener en cuenta:
tiempo de acceso al sistema, tiempo de respuesta de pantalla, tiempo de respuesta de
inserción de transacción en la Bases de Datos, tiempo de respuesta de cálculo de reportes,
tiempo de respuesta de exportación de reportes a distintos formatos). También se debe tener
en cuenta los tiempos de respuesta de todos los componentes de la infraestructura, así como
los de interoperabilidad.
Debe tenerse en cuenta también que la performance deseada está fuertemente influida por la
escala (número de incisos incorporados al sistema) y el volumen (número de años de
transacciones acumuladas). La performance definida debe cumplirse en el escenario de
máximos de implantación del sistema.
Las definiciones concretas de tiempos de respuesta esperados exceden al alcance de este
documento pero deberán ser tenidas en cuenta durante la definición técnica y funcional en el
proyecto de desarrollo del SIIF2.
REQ 3-7 Performance
El sistema deberá cumplir con los requisitos de performance definidos, prestando especial
atención a los puntos de interacción con el usuario, los tiempos de respuesta de los
componentes de la infraestructura y los tiempos de respuesta de la interoperabilidad.
REQ 3-8 Escalabilidad
El sistema deberá ser escalable, la escalabilidad estará influenciada por el número de
instituciones incorporadas al sistema (en referencia al número de usuarios) y por el número
de años de transacciones acumuladas (en referencia al volumen de datos).
3.2.6 Consistencia e integridad de la información
El repositorio central del SIIF2 debe mantener consistencia e integridad de datos
permanente. El sistema debe operar en forma consistente y repetible según los requisitos
funcionales de negocio.
REQ 3-9 Consistencia e integridad de la información
El repositorio central de datos del sistema transaccional debe mantener consistencia e
integridad de datos permanente. Esta consistencia debe asegurarse a pesar de fallas
técnicas o caídas de otros componentes del sistema. Todas las transacciones del sistema
deben persistir en la base de datos, de un estado consistente a un nuevo estado consistente
en forma atómica.
Modelo Conceptual del SIIF2 01/04/2014 38/203
El sistema debe operar en forma consistente y repetible según los requisitos funcionales de
negocio y ser inmune a ocurrencias de carreras críticas en operaciones concurrentes.
Toda información presentada al usuario debe ser consistente y ser el reflejo de información
persistida en el repositorio central de datos del sistema.
3.2.7 Clasificadores
Los clasificadores son un elemento vital de todo SIAF y permiten que cada transacción
quede perfectamente catalogada respecto a las distintas perspectivas del negocio. Los
clasificadores juegan un papel principal en registración de transacciones en el SIIF2 y se
convierten en las dimensiones que se utilizarán tanto en los reportes como en el área de
análisis.
El SIIF2 contemplará dos tipos de clasificadores, los principales y los secundarios. Todos
ellos deberán responder a la misma estructura:
REQ 3-10 Estructura de los clasificadores
Todos los clasificadores deberán tener estructura balanceada, considerando que todos sus
elementos forman parte de una rama y que cada rama tiene el mismo número de niveles. A
modo de ejemplo, un elemento no puede tener dos niveles “padre” o un elemento de nivel “3”
debe tener obligatoriamente un padre de nivel “2”. Esto genera una estructura predecible
para el manejo de los clasificadores.
REQ 3-11 Flexibilidad de los clasificadores
Los clasificadores deberán ofrecer flexibilidad en cuanto al número de elementos por nivel de
manera que se puedan satisfacer correctamente las necesidades de gestión de la cobertura
del sistema.
REQ 3-12 Variabilidad de los clasificadores
Los clasificadores deberán permitir acomodar modificaciones, altas y bajas a sus elementos
en función de las necesidades de gestión de la cobertura del sistema.
REQ 3-13 Trazabilidad temporal de los clasificadores
Los cambios realizados a los clasificadores deberán ser trazables en el tiempo de forma que
en la explotación de la información se pueda tener una visión temporal consistente con la
realidad de las necesidades de gestión de la cobertura del sistema.
3.2.7.1 Clasificadores principales
Son clasificadores principales aquellos definidos por el marco legal, normativo y organizativo
del estado y de uso general por todos los incisos de la cobertura. Todos los clasificadores
que contempla el actual SIIF son clasificadores principales. A modo de ejemplo y sin perjuicio
de otros son clasificadores principales para el sistema el clasificador institucional, el de
programa presupuestario, el de objeto del gasto, el de recursos y el plan de cuentas
contable.
REQ 3-14 Propiedad de los clasificadores principales
Los clasificadores principales son propiedad del Órgano Rector y de estos depende su
definición inicial y cualquier modificación posterior a los mismos.
Modelo Conceptual del SIIF2 01/04/2014 39/203
REQ 3-15 Repercusión en otros sistemas transversales
Los clasificadores principales del SIIF2 que también se utilicen en otros sistemas
transversales se mantendrán de forma centralizada en el SIIF2 y el resto de sistemas se
alimentarán de dicho repositorio. Para ello el SIIF2 deberá proveer servicios automatizados
que el resto de sistemas transversales deberán consumir.
3.2.7.2 Clasificadores secundarios
Los clasificadores secundarios son una facilidad a la gestión y operación de los incisos.
Permiten que el registro de información en el SIIF2 se adapte de forma más fiel a las
particularidades de cada inciso aportando mayor riqueza a la información registrada.
REQ 3-16 Propiedad de los clasificadores secundarios
Los clasificadores secundarios son propiedad del Órgano Rector o de los Incisos. Para el
caso de los incisos, de ellos depende su definición inicial y cualquier modificación posterior a
los mismos. Los clasificadores secundarios serán almacenados y conservados de forma
centralizada en el SIIF2.
REQ 3-17 Límites a los clasificadores secundarios
Cada inciso podrá disponer de un máximo de tres catálogos secundarios para todas las
funcionalidades del sistema, con excepción de los que determine la CGN.
REQ 3-18 Efecto de los clasificadores secundarios en SIIF2 agregación
La información relativa a los clasificadores secundarios deberá ser trasladada a los
repositorios de información del SIIF2 agregación para que los incisos puedan explotarla de
forma efectiva.
3.2.7.3 Propiedades institucionales
Si bien las propiedades institucionales no son clasificadores, constituyen también una
facilidad a la gestión y operación de los incisos. Permiten que el registro de información en el
SIIF2 se adapte de forma más fiel a las particularidades de cada inciso aportando mayor
riqueza a la información registrada.
Un ejemplo claro de la necesidad de propiedades institucionales sucede actualmente en el
Ministerio de Salud Pública. Dada su operativa habitual utilizan el campo de resumen de la
obligación para registrar información que les ahorra en ocasiones recurrir a consultar el
expediente en papel. Esta información que ahora guardan de manera desestructurada y que
no responde a una necesidad común a toda la cobertura del sistema sino que es particular se
resuelve mediante la orquestación de propiedades institucionales.
Así una propiedad institucional es un campo de información estructurada que se incluye al
registro de la transacción según la definición particular de cada inciso.
REQ 3-19 Propiedad de las propiedades institucionales
Las propiedades institucionales son propiedad de los incisos y de ellos depende su definición
inicial y cualquier modificación posterior a los mismos. Las propiedades institucionales serán
almacenadas y conservadas de forma centralizada en el SIIF2.
Modelo Conceptual del SIIF2 01/04/2014 40/203
REQ 3-20 Límites a las propiedades institucionales
Cada inciso podrá disponer de un máximo de tres propiedades institucionales para todas las
funcionalidades del sistema, con excepción de los que determine la CGN.
REQ 3-21 Estructura de las propiedades institucionales
El tipo de dato asociado a una propiedad institucional podrá ser numérico, fecha, lista o texto
libre.
REQ 3-22 Efecto de las propiedades institucionales en SIIF2 agregación
La información relativa a las propiedades institucionales no será trasladada a los repositorios
de información del SIIF2 agregación sólo podrá ser explotada desde el SIIF2 transaccional o
desde la Reportabilidad Operativa.
3.2.8 Nivel de captura de las transacciones
La captura de transacciones, en todos los subsistemas del SIIF2, conlleva la asociación de la
misma a distintos clasificadores. Por ejemplo una transacción de compromiso presupuestario
de gasto tendrá, entre otros, información relativa al clasificador del objeto del gasto y al
clasificador del programa presupuestario. Cada uno de estos clasificadores posee distintos
niveles de detalle en una estructura de árbol. La captura de la transacción se realizará, para
todos los clasificadores implicados en dicha transacción al mayor nivel de detalle del mismo
(último nivel). Esto permite después en el SIIF2 agregación ver la información tanto a ese
nivel de detalle como agregada a niveles de detalle superiores cosa que no sería posible de
otro modo.
REQ 3-23 Nivel de captura de las transacciones
Todas las transacciones de todos los subsistemas del SIIF2 se capturaran al mayor nivel de
detalle de los distintos clasificadores asociados a la misma.
3.2.8.1 Captura a nivel institucional: Unidad Organizativa
Este requisito tiene un efecto particular para el clasificador institucional. Actualmente el SIIF 1
captura la información a nivel de Unidad Ejecutora y no contempla la Unidad Organizativa.
Muchos incisos requieren para su gestión interna la posibilidad de distribuir el gasto a nivel
de Unidad Organizativa e incluso existe un sistema (el SDG) que se encarga de hacer esta
distribución de forma aproximada y a posteriori.
El SIIF2 capturará en origen la información a nivel de Unidad Organizativa. Esto en algunos
casos (una minoría) puede implicar la necesidad de explotar algunas transacciones
generando un trabajo de registro adicional. En todo caso este efecto siempre puede ser
mitigado asignando ciertos gastos de impacto compartido a una Unidad Organizativa central
y la decisión puede tomarse al interior de cada inciso.
REQ 3-24 Captura a nivel de Unidad Ejecutora y/o Unidad Organizativa
El SIIF2 capturará las transacciones según el catálogo institucional a nivel de Unidad
Ejecutora y/o Unidad Organizativa como mínimo.
Modelo Conceptual del SIIF2 01/04/2014 41/203
3.2.9 Estado de las transacciones
Las transacciones del sistema contemplaran los estados siguientes:
Borrador: Estado inicial donde una transacción se empezó a digitar y se guardó en
el sistema a medio finalizar. Las transacciones en este estado podrán ser
descartadas quedando completamente eliminadas del sistema.
Verificado o Generado: Estado en que una transacción está completamente
finalizada y se reserva el crédito presupuestario asociado a su monto. Las
transacciones verificadaspuedenrechazarse y de esta forma liberar el crédito
asociado a la misma que se había reservado.
Confirmada o Aprobada: Estado definitivo de una transacción. Se accede a este
estado a partir de la aprobación con el rol correspondiente. Una transacción
aprobada ya no puede eliminarse del sistema. Para realizarse modificaciones sobre
una transacción aprobada deberá generarse una transacción de ajuste que deberá
pasar por el ciclo de aprobación correspondiente.
Intervenida: Las transacciones que requieren de una intervención adicional (sólo las
obligaciones) por el rol correspondiente contemplarán un estado adicional para
reflejar esta situación.
Rechazada: Estado de una transacción generada a la que se deniega su aprobación
y se libera el crédito presupuestario asociado a dicha transacción.
Ilustración 3-1 Diagrama de estados de las transacciones
REQ 3-25 Estado de las transacciones
Todas las transacciones de todos los módulos del SIIF2 contemplaran el esquema de
estados definido arriba. Deberá preverse un rol adicional entre aprobador e interventor, dado
que el Cr. Central debe aprobar los registros verificados por el Gerente Financiero, pero no
bajo el rol de interventor.
Modelo Conceptual del SIIF2 01/04/2014 42/203
3.2.10 Visibilidad sobre ejercicios futuros
Una característica importante del SIIF2 de la República Oriental del Uruguay, dada la
particularidad de su presupuesto quinquenal, es que el sistema permita al usuario tener
visibilidad sobre ejercicios futuros tanto en la formulación como en la ejecución
presupuestaria. Esta característica debe extenderse no sólo a los créditos presupuestales
sino también a los compromisos que se extienden más allá de un ejercicio fiscal.
La legislación uruguaya derogó la posibilidad de mantener residuos pasivos, y con excepción
de la reprogramación de inversiones, los créditos tienen un criterio de anual, que el sistema
debe tener en cuenta, por lo que no se puede hacer referencia a Residuos Pasivos
(reprogramación de gastos no ejecutados).
REQ 3-26 Visibilidad sobre ejercicios futuros
El sistema permitirá gestionar créditos presupuestales y compromisos plurianuales tanto en
el módulo de formulación como en el de ejecución presupuestaria.
3.2.11 Base devengado
En el desarrollo del SIIF2 se deben considerar con especial atención la definición de las
reglas de negocio relativas al proceso de ejecución presupuestaria y contable, focalizando el
análisis en las reglas de negocio relativas al proceso de integración automático del ciclo
financiero – contable (presupuesto/contabilidad/tesorería/deuda pública) que rige la gestión
financiera pública, con un enfoque de base devengado para los gastos y recursos o base
caja modificado para los recursos. Por lo tanto, en base las definiciones del MC se deben
desarrollar con precisión las principales definiciones funcionales, que interrelacionan la
cadena financiera en las distintas etapas presupuestarias (aprobadas, modificadas y
comprometidas), contables (devengado, obligado,) y tesorería (pagado), como así también
las reglas correspondientes a los procesos de cierre y apertura anual presupuestario y
contable de cada ejercicio fiscal.
REQ 3-27 Base devengado
El proceso de integración automático del ciclo financiero – contable
(presupuesto/contabilidad/tesorería/deuda pública) contenido en el SIIF2 debe realizarse bajo
un enfoque de base devengado para los gastos y recursos o en base caja modificado para
los recursos.
3.2.12 Gestión de múltiples monedas
Si bien el presupuesto de la República Oriental del Uruguay está expresado enteramente en
pesos (UYU) durante la ejecución habitual del mismo se producen movimientos en distintas
monedas. El sistema deberá permitir gestionar está situación de forma efectiva, distinguiendo
entre el costo asociado al bien o servicio adquirido de la eventual diferencia financiera
atribuible a variaciones de tipo de cambio. Todo ello no impide que la contabilidad será
manejada enteramente en pesos (UYU).
REQ 3-28 Gestión de múltiples monedas
El sistema permitirá la gestión de múltiples monedas de forma eficiente según lo descrito en
el presente apartado.
Modelo Conceptual del SIIF2 01/04/2014 43/203
3.2.13 Pantallas de usuario
Uno de los aspectos principales de la definición funcional del sistema deberá ser la definición
de las pantallas de usuario con el fin de homogeneizar la usabilidad del sistema. Esta tarea
deberá ser llevada a cabo en paralelo a la definición de los caso de uso del sistema.
REQ 3-29 Pantallas de usuario
El sistema presentará un conjunto de pantallas de usuario totalmente uniforme de acuerdo a
los criterios de usabilidad establecidos. El sistema deberá contemplar los principios
expuestos en la guía de accesibilidad de la AGESIC.
3.2.14 Documentación del sistema
Si bien es algo que todo sistema debería tener la realidad indica que siempre es necesario
incluir este apartado. Dada la extensión temporal de los proyectos de desarrollo de SIAF este
aspecto es particularmente importante. El SIIF2 deberá documentarse de forma exhaustiva
tanto funcional como técnicamente. Además deberán desarrollarse manuales de usuario y de
operación del sistema, como mínimo.
REQ 3-30 Documentación del sistema
El sistema deberá ofrecer una documentación completa, exhaustiva y orientada a los
distintos tipos de usuarios. La documentación deberá proporcionarse en línea y contemplar
que un usuario pueda informarse a través de dicha documentación.
3.3 Mapa de módulos principales
El núcleo principal del SIIF2 está conformado, como muestra la Ilustración 3-2, por cuatro
módulos principales2:
Presupuesto: que contempla la formulación y las etapas parlamentarias, la ejecución,
las asignaciones, las modificaciones durante el ejercicio y la evaluación
presupuestaria incluyendo las Rendiciones de Cuenta.
Contabilidad: que ejerce de núcleo integrador del sistema puesto que el resto de
subsistemas impactan en ella de forma constante.
Tesorería: que gestiona el plan de caja, la ejecución de los pagos y cobros y el
registro de los ingresos.
Deuda: el módulo de deuda que registra tanto las emisiones como la gestión del
servicio de la deuda.
2 El detalle exhaustivo de cada uno de los módulos se encuentra en la sección 5.
Modelo Conceptual del SIIF2 01/04/2014 44/203
Ilustración 3-2 Estructura de los módulos principales del SIIF2
Es importante aclarar que ser un módulo principal no significa necesariamente que se deba
construir un aplicativo específico que responda a los requisitos funcionales sino que la
información asociada al mismo debe estar contenida de forma explícita y detallada en la base
de datos del SIIF2.
En el caso uruguayo se dan dos situaciones completamente diferenciadas para el módulo de
contabilidad y para el módulo de deuda que sirven para ilustrar este concepto. En estos
momentos no hay ningún aplicativo que pueda dar respuesta a las necesidades contables. El
nuevo SIIF2 deberá por tanto realizar lo siguiente:
Contemplar el diseño de un modelo de datos que permita almacenar esta
información.
Desarrollar una aplicación que permita al usuario registrar todos los movimientos
contables económicos y financieros.
Sin embargo, el caso del módulo de deuda es completamente opuesto. El Banco Central del
Uruguay ya dispone de un sistema completo y autónomo para la gestión operativa del
servicio de deuda. En este caso el SIIF2 deberá:
Contemplar el diseño de un modelo de datos que permita almacenar esta
información.
Realizar el desarrollo de un mecanismo de interoperación para capturar en ese
modelo las de transacciones introducidas en el sistema de gestión de la deuda del
Banco Central con el detalle que se defina.
Modelo Conceptual del SIIF2 01/04/2014 45/203
Realizar el desarrollo de los procedimientos necesarios para registrar en el módulo
de contabilidad el impacto contable de cada uno de estas transacciones de servicio
de deuda.
En líneas generales, ser módulo principal sólo significa que se requiere información detallada
en el modelo de datos del SIIF2. Si esta se consigue mediante el desarrollo de un módulo en
forma completa o mediante la interoperación con un módulo existente dependerá de cada
caso y quedará detallado en lasección5. Integración de los Módulos Principales y sección 6.
Integración de Sistemas de Apoyo Transversales.
3.3.1 Estructura de Alto Nivel: SIIF2 Transaccional y SIIF2 Agregación
El SIIF2 contempla dos grandes elementos para satisfacer las necesidades de información
de los usuarios del sistema el SIIF2 Transaccional y el SIIF2 Agregación. En el apartado
3.8.1.2 Estructura de la capa de datos, se muestra un esquema de cada uno de ellos
haciendo hincapié en la estructura de la capa de datos que los soporta.
A continuación se ofrece la definición de los objetivos a los que sirven cada uno de estos
elementos constituyentes del sistema.
3.3.1.1 SIIF2 Transaccional
El SIIF2 transaccional es el sistema de operación diaria para el registro de todas las
transacciones detalladas que se generan asociadas a la administración y el manejo de las
finanzas de la administración central.
Su función principal es constituir un registro único, oportuno y veraz de todas las
transacciones presupuestarias, contables, de tesorería y de servicio de deuda realizadas
como resultado de la operativa habitual de la administración de las finanzas públicas.
A su vez permite a los agentes encargados de la intervención y auditoría observar el correcto
funcionamiento y el cumplimiento de la legalidad en cada una de las operaciones realizadas.
3.3.1.2 SIIF2 Agregación
El SIIF2 agregación se encarga de aglutinar toda la información de detalle obtenida a través
del SIIF2 transaccional y prepararla para que pueda ser explotada en forma de reportes
orientados a usuarios tácticos y estratégicos.
SIIF2 agregación proporcionará información no sólo de cada uno de los incisos si no también
información consolidada de toda la administración central que será de gran utilidad para la
toma de decisiones tanto por parte de los incisos como de los Organismos Rectores.
Desde SIIF2 agregación se contará con todos los elementos necesarios para poder realizar
los Estados Financieros del Gobierno Central Consolidado, como así también los Estados
financieros Individuales de cada uno de los entes contables definidos en el ámbito de
cobertura del SIIF2.
3.4 Funciones de soporte a la gestión financiera
La definición de mejoras en aspectos relacionados a la usabilidad del SIIF2 que mejoren la
interacción del usuario con el sistema bajo un entorno de uso amigable, es un aspecto
central en el momento de promover mejoras en las funciones de soporte a la gestión
financiera. En los casos donde el sistema se encuentra orientado al registro de transacciones
Modelo Conceptual del SIIF2 01/04/2014 46/203
financieras-contables y no al apoyo de los procesos financieros, es posible observar la mala
práctica de acumular información a lo largo del mes, y sólo concentrar su registro en el
sistema, generalmente en las áreas de contabilidad, en las fechas cercanas al cierre
presupuestario / contable mensual. Por ello se propone la inclusión de una serie de
funcionalidades que mejoren en forma sustantiva la usabilidad del SIIF2.
3.4.1 Orientación a documentos de negocio
REQ 3-31 Captura de Transacciones orientada a Documentos de Negocio
El registro de la información financiero contable en el sistema debe realizarse en base a la
captura de “documentos de negocios”, como por ejemplo Órdenes de Compra, Contratos o
Facturas. Estos documentos desencadenarán los registros presupuestarios y contables, así
como las modificaciones de las previsiones de tesorería. A su vez, el sistema debe contener
un formato de captura general que permita capturar los datos necesarios para realizar los
registros financiero contable en forma independiente del tipo de documento de negocio.
3.4.2 Seguimiento administrativo
REQ 3-32 Captura y Gestión de Documentación de Respaldo
El sistema debe contener funcionalidades que permitan adjuntar documentación de respaldo
digitalizada a las transacciones financieras, las cuales deberán almacenarse en un
repositorio que permita su consulta posterior. A su vez, esta funcionalidad deberá contar con
los mecanismos necesarios para interoperar con las iniciativas de Expediente Electrónico
presentes en el ámbito de la administración pública, entre otras.
REQ 3-33 Gestión Documental
El sistema debe contener funcionalidades de gestión documental, destinadas a realizar un
seguimiento de las fechas en las que ocurren los principales eventos del proceso
administrativo (como por ejemplo la fecha de recepción definitiva de los bienes y/o servicios,
fecha de recepción de las facturas) generando reportes y consultas sobre las fechas
capturadas.
3.4.3 Alarmas financieras
REQ 3-34 Definición y Parametrización de Alarmas Financieras
El sistema debe permitir definir un conjunto de alarmas financieras que permiten
desencadenar alertas para el usuario ante eventos administrativos o de gestión, según
criterios parametrizables por institución.
3.5 Funciones de soporte a la operación
Como parte del desafío de modificar el enfoque del SIIF2 actual, desde un sistema orientado
a las funciones a un sistema orientado a los procesos, la incorporación de funcionalidades de
apoyo a la operación financiero contable es un factor que promueve este cambio de
orientación promoviendo la captura de información en forma oportuna.
Modelo Conceptual del SIIF2 01/04/2014 47/203
3.5.1 Compromisos de Ejercicios futuros
REQ 3-35 Registro y traspaso de compromisos que afectan ejercicios futuros
El sistema debe registrar información de los montos comprometidos para ejercicios
posteriores al vigente, considerando el Presupuesto Quinquenal, realizando controles de
saldos presupuestarios para los ejercicios futuros, facilitando la obtención de información de
compromisos futuros. En el proceso de cierre y apertura anual debe prever el traspaso
automático del comprometido que afecta al ejercicio que cierra y a los ejercicios a futuros,
facilitando la obtención de la disponibilidad efectiva para ejercicios posteriores.
3.5.2 Automatización de tareas
REQ 3-36 Automatización de Tareas y Cálculos repetitivos
En base al análisis de los principales procesos de negocio el sistema debe automatizar la
mayor cantidad posible de tareas realizadas por los usuarios en forma repetitiva basados en
cálculos realizados sobre algoritmos simples.
REQ 3-37 Bandeja de Entrada de Tareas
El sistema debe contener una Bandeja de Entrada de Tareas, en la cual se debe reflejar las
tareas pendientes de cada usuario, así como los avisos de las alarmas financieras que
corresponden a cada tipo de rol.
3.6 Funciones de soporte para el control y auditoría
El SIIF actual presenta debilidades en las funciones de apoyo específicas para las tareas de
auditoría, tanto para las realizadas por el Tribunal de Cuentas como por los órganos internos
de auditoría. Habitualmente cuando un órgano de control inicia una auditoría debe solicitar
los antecedentes en formato impreso, así como la generación de claves de usuarios que le
permitan acceder al sistema de administración financiera para realizar sus tareas de control.
El SIIF2 debe permitir automatizar la realización de las tareas de control tanto de los órganos
de control externos como internos.
REQ 3-38 Funcionalidades automatizadas de control y auditoria
El sistema debe brindar funcionalidades automatizadas de control y auditoria que permitan
consultar on-line información sobre las transacciones financieras, así como sobre la
documentación de soporte contenida en el sistema de información, de manera específica
para los órganos de control. A modo de ejemplo es posible mencionar la generación de roles
de auditoria con acceso de solo lectura a toda la información, la definición de criterios de
búsqueda ad hoc para actividades de auditoria y la capacidad de consultar información de
soporte almacenada en el sistema.
3.7 Configuración
La cobertura institucional tiene necesidades de gestión distintas motivadas por la diversidad
de servicios que prestan a la ciudadanía. Ello implica que el SIIF2, tanto en el registro de la
información, como en la explotación de la misma debe ser capaz de acomodar estas
diferencias. Sólo así el sistema aportará valor a los incisos y unidades ejecutoras. Un sistema
que no contemple este aspecto aporta un gran valor a los Órganos Rectores pero un valor
cuestionable a las distintas entidades públicas.
Modelo Conceptual del SIIF2 01/04/2014 48/203
La configuración debe permitir adaptar el sistema razonablemente a las particularidades de
los Incisos a través de los siguientes mecanismos:
Definición y actualización de Catálogos secundarios .
Definición y actualización de Propiedades institucionales.
Adaptaciones de funcionalidad del sistema aplicables sólo al inciso.
Adaptaciones de presentación del sistema aplicables sólo al inciso.
La configuración no está sólo al servicio de los incisos sino también de los Órganos Rectores
y debe contemplar también la posibilidad de flexibilizar y adaptar el sistema de forma global,
esto es acomodando variaciones que impactarán a toda la cobertura institucional. Esto se
llevara a cabo a través de los siguientes mecanismos:
Definición y actualización de Catálogos básicos (Clasificador Presupuestario, Plan de
Cuentas Contables, Clasificador Institucional) .
Adaptaciones de funcionalidad del sistema aplicables a toda la cobertura.
Adaptaciones de presentación del sistema aplicables a toda la cobertura.
REQ 3-39 Sistema configurable
El SIIF2 deberá contemplar un módulo de configuración capaz como mínimo de dar
respuesta a las necesidades expuestas en el presente apartado.
3.8 Reportabilidad
La reportabilidad es uno de los elementos principales de todo sistema de información y
constituye uno de los productos que mayor valor añadido ofrece tanto al usuario operativo
como al usuario estratégico.
Al usuario operativo le permite obtener respuestas rápidas y detalladas que le permiten
ejecutar de forma más eficientes sus tareas diarias. Al usuario estratégico le proporciona
reportes e indicadores con información agregada que le ofrecen una visión ajustada de la
situación global y le permiten tomar decisiones más eficaces en el cumplimiento de los
objetivos de gobierno.
3.8.1 Introducción a la reportabilidad
Distinguimos cuatro tipos de reportes en el marco de un SIAF que procedemos a definir:
Reporte de búsqueda: reportes asociados al sistema transaccional que permite
obtener listados de las principales entidades del sistema según un conjunto de filtros
predefinidos. El usuario objetivo es todo aquel que use el sistema transaccional para
registrar la información o auditar la información registrada.
Reporte operativo: reportes asociados a la operación de una unidad ejecutora.
Permite ver información con mayor nivel de transformación que las búsquedas. El
usuario objetivo es tanto un responsable de unidad ejecutora como un perfil
operativo al interior de la unidad ejecutora.
Reporte analítico: reportes que permiten ver información a nivel de inciso o de toda
la administración central. Permiten ver información con mayor nivel de
transformación que los reportes operativos. Puede haber reportes con igual diseño a
la vez en la reportabilidad operativa y la analítica. El usuario objetivo es un perfil
táctico o estratégico con responsabilidad de análisis sobre un inciso o incluso sobre
la administración central.
Modelo Conceptual del SIIF2 01/04/2014 49/203
Reporte estratégico: reportes que permiten ver información a nivel de inciso de toda
la administración central. Presentan información en base a indicadores y gráficos que
permiten monitorear los principales objetivos de gestión y gobierno. El usuario
objetivo es un perfil estratégico con responsabilidad de análisis sobre la
administración central normalmente perteneciente a los OO.RR o a divisiones de
apoyo a los mismos.
Área de análisis: el área de análisis es un lienzo en blanco donde el usuario tiene
acceso a las medidas y dimensiones de análisis a partir de las cuales se genera la
reportabilidad analítica y estratégica. Desde ahí el puede crear sin restricción sus
análisis ad-hoc combinando a su libre voluntad las métricas y dimensiones
disponibles. El usuario objetivo es un perfil con un nivel de usuario avanzado de
herramientas de BI que da soporte analítico a perfiles estratégicos con
responsabilidad de análisis sobre la administración central normalmente
perteneciente a los OO.RR. o a divisiones de apoyo a los mismos.
3.8.1.1 Requisitos generales a la reportabilidad
Antes de pasar a las particularidades de cada uno de estos tipos de reportabilidad hay una
serie de requisitos que deben ser cumplidos por todas ellas y que procedemos a describir:
REQ 3-40 Exportación a planilla y documento
Todos los reportes generados por el sistema deberán ser exportables a planilla y documento.
La exportación a documento deberá ser lo más fiel posible a lo que el usuario ve en pantalla
y deberá generarse en formato abierto. La exportación a planilla deberá ser lo más orientada
posible a trabajar los datos (cada dato en una celda, ausencia de celdas combinadas,
respeto a los formatos numéricos y de fecha) y deberá generarse en formato abierto.
REQ 3-41 Perfil de usuario y acceso a los reportes
El acceso a cada reporte individual quedará determinado por el perfil del usuario. Asimismo
se determinará también el conjunto de datos al que tiene acceso (visibilidad sobre la Unidad
Organizativa, la Unidad Ejecutora, el Inciso o toda la Administración).
REQ 3-42 Características tecnológicas de la reportabilidad
Los reportes de búsqueda se desarrollarán sobre la misma arquitectura tecnológica que el
sistema transaccional. Se recomienda, en caso de que se decida utilizar una plataforma de
BI (comercial o no) que los reportes estratégicos, los analíticos y el área de análisis se
desarrollen sobre la plataforma de BI. Los reportes operativos pueden ser desarrollados
sobre la arquitectura del transaccional o sobre la plataforma de BI. La definición funcional
detallada permitirá decidir cuál de las dos opciones es más conveniente.
REQ 3-43 Oportunidad de la información para la reportabilidad
Los reportes de búsqueda deberán proporcionar información en tiempo real. No puede haber
desfase alguno entre la introducción de la transacción y la visualización de la misma a través
de las búsquedas. Los reportes operativos deberán proporcionar información en tiempo real.
Si condicionantes tecnológicos no lo permiten deberá haber el mínimo desfase (minutos). Los
reportes analíticos, estratégicos y el área de análisis ofrecerán información del día anterior
(d-1).
Modelo Conceptual del SIIF2 01/04/2014 50/203
3.8.1.2 Estructura de la capa de datos
La capa de datos del SIIF2 responderá como minino a la estructura mostrada en la
Ilustración 3-3, la cual se presenta a modo ilustrativo.
Ilustración 3-3 Estructura de la capa de datos para la reportabilidad
Capa de datos (repositorios):
(I) BD SIIF2: Repositorio único de toda la información transaccional de los módulos
principales del SIIF2.
(II) DW relacional: DW relacional para la reportabilidad operativa.
(III) Esquema agregado: Esquema adaptado a la reportabilidad operativa.
(IV) Esquema replicado: Copia idéntica del repositorio transaccional. Esto permite aislar el
efecto en performance de las búsquedas y la reportabilidad operativa de la transaccionalidad
del sistema.
(V) DW multidimensional: DW multidimensional del SIIF2.
(VI) Cubos multidimensionales: Cubos analíticos para la explotación de información.
Modelo Conceptual del SIIF2 01/04/2014 51/203
Capa de datos (procesos de carga):
(1) Replica RT: Réplica en tiempo real desde la BD del SIIF2 al esquema replicado del DW
relacional.
(2) Agregación relacional: Proceso de transformación y carga de la reportabilidad operativa.
Idealmente debería producirse en RT. En caso de impedimentos tecnológicos habría que
definir cuál es el máximo retraso permitido.
(3) Agregación multidimensional: Proceso de transformación y carga del DW
multidimensional, la oportunidad de la información debe ser a d-1.
(4) Procesado de cubos: El procesado de cubos analíticos debe ser realizado a
continuación de la carga del DW multidimensional y ofrecer información a d-1.
SIIF2 Agregación:
(A) Reportes analíticos: definido en el apartado 3.8.1.
(B) Área de análisis: definido en el apartado 3.8.1.
(C) Reportes estratégicos: definido en el apartado 3.8.1.
SIIF2 Transaccional:
(D) Registro de transacciones: corresponde al conjunto de módulos de presupuesto,
contabilidad, tesorería y deuda definidos en el apartado.5.
(E) Búsquedas: definido en el apartado 3.8.1.
(F) Reportabilidad operativa: definido en el apartado 3.8.1.
REQ 3-44 Estructura de la capa de datos
La estructura de datos del SIIF2 dará respuesta a las necesidades de oportunidad y
organización de la información para la reportabilidad según el esquema mostrado en la
presente sección del documento. El diseño funcional y técnico detallado de la aplicación
puede introducir ligeras variaciones a este esquema.
3.8.2 Búsquedas
Los reportes de búsqueda son reportes asociados al sistema transaccional que permiten
obtener listados de las principales entidades del sistema según un conjunto de filtros
predefinidos.
El usuario objetivo es todo aquel que use el sistema transaccional para registrar la
información o auditar la información registrada.
REQ 3-45 Búsquedas y Entidades
Existirá un reporte de búsqueda por cada entidad principal del sistema (i.e. búsqueda de
afectaciones, búsqueda de compromisos, búsqueda de obligaciones, búsqueda de asientos
contables, etc.).
Modelo Conceptual del SIIF2 01/04/2014 52/203
REQ 3-46 Esquema de los reportes de búsqueda
Los reportes de búsqueda tendrán dos áreas diferenciadas, el área de filtros y el área de
resultados donde aparecerá la tabla con el conjunto de registros que satisfagan los filtros de
búsqueda.
REQ 3-47 Filtros simples y avanzados para las búsquedas
El área de filtros presentará por defecto la búsqueda simple que ofrecerá un conjunto de
filtros reducido y de uso común adaptados a la entidad que se está buscando (por ejemplo
fecha de transacción, número de transacción, objeto del gasto…). Se ofrecerá la posibilidad
de pasar a búsqueda avanzada que desplegará bajo el área de filtros básicos un conjunto de
filtros adicionales de uso más específico también adaptados a la entidad (por ejemplo
proyecto de inversión, unidad operativa,…)
REQ 3-48 Área de resultados
El área de resultados mostrará una tabla con tantos registros como transacciones de la
entidad buscada cumplan con los filtros de búsqueda. Cada reporte de búsqueda presentará
en columnas los campos principales de la entidad buscada (por ejemplo código, título,
monto,…). El número de columnas será lo suficientemente grande como para obtener
información relevante de la transacción y lo suficientemente pequeño como para caber en la
pantalla con la resolución definida para la aplicación sin necesitar scroll horizontal.
REQ 3-49 Paginación del área de resultados
Para poder ofrecer los resultados con tiempos de respuesta inmediatos los reportes de
búsqueda se retornarán con paginación. La paginación ofrecida será lo más similar posible a
la que ofrece www.google.com. Los resultados deberán cachearse de forma eficiente para
que la presentación del reporte y la paginación de las primeras páginas sea lo más rápida
posible.
REQ 3-50 Ordenación del área de resultados
Todas las columnas del reporte que presenten datos de tipo numérico o de tipo fecha
presentarán la opción de ordenar ascendente y descendentemente. La ordenación afectará a
toda la consulta y no sólo a los resultados de la página actual.
REQ 3-51 Acceso al detalle de la transacción
Cada registro correspondiente a la transacción estará vinculado a la pantalla de detalle de la
transacción del propio sistema transaccional
3.8.3 Reportes operativos
Los reportes operativos son reportes asociados a la operación de una unidad ejecutora.
Permiten ver información con un mayor nivel de transformación que las búsquedas.
El usuario objetivo es tanto un responsable de unidad ejecutora como un perfil operativo al
interior de la unidad ejecutora.
La definición detallada de los reportes operativos a construir y sus características funcionales
deberá realizarse durante el proyecto de desarrollo del sistema, sin embargo ciertos
requisitos de alto nivel pueden definirse en este momento:
Modelo Conceptual del SIIF2 01/04/2014 53/203
REQ 3-52 Requisitos de los reportes operativos comunes a los reportes de búsqueda
Los reportes operativos deberán satisfacer los siguientes requisitos ya descritos para los
reportes de búsqueda: REQ 3-46 Esquema de los reportes de búsqueda,
REQ 3-47 Filtros simples y avanzados para las búsquedas y REQ 3-51 Acceso al detalle de
la transacción.
REQ 3-53 Cobertura institucional de los reportes operativos
Los reportes operativos mostrarán información a lo sumo de una unidad ejecutora. Si se
desea ver información agregada de todo un inciso o de toda la administración central se
obtendrán desde la reportabilidad analítica o estratégica.
3.8.4 Reportes analíticos
Los reportes analíticos son reportes que permiten ver información a nivel de inciso o incluso
de toda la administración central. Permiten ver información con mayor nivel de
transformación que los reportes operativos. Puede haber reportes con igual diseño a la vez
en la reportabilidad operativa y la analítica ya que la reportabilidad analítica permite, a
diferencia de la operativa, ver información agregada a nivel de inciso o de toda la
Administración Central.
El usuario objetivo es un perfil táctico o estratégico con responsabilidad de análisis sobre un
inciso o incluso sobre la administración central.
La definición detallada de los reportes analíticos a construir y sus características funcionales
deberán realizarse durante el proyecto de desarrollo del sistema, sin embargo ciertos
requisitos de alto nivel pueden definirse en este momento:
REQ 3-54 Adaptación a la plataforma de BI
En el caso de que la reportabilidad analítica se desarrolle sobre una plataforma de BI los
reportes se adaptaran a las características funcionales de la plataforma de manera que no
sea necesario incrustar código no estándar en los reportes para satisfacer demandas
funcionales.
REQ 3-55 Requisitos de los reportes analíticos comunes a otros reportes
Los reportes analíticos deberán satisfacer los siguientes requisitos ya descritos para los
reportes de búsqueda y/o operativos: REQ 3-46 Esquema de los reportes de búsqueda y
REQ 3-47 Filtros simples y avanzados para las búsquedas. Desde los reportes analíticos no
se tendrá acceso a detalle de transacciones.
REQ 3-56 Cobertura institucional de los reportes analíticos
Los reportes analíticos mostrarán información agregada de una unidad ejecutora, de todo un
inciso o de toda la Administración Central.
3.8.5 Área de análisis
El área de análisis es un lienzo en blanco donde el usuario tiene acceso a las medidas y
dimensiones de análisis a partir de las cuales se genera la reportabilidad analítica y
estratégica. Desde ahí el usuario puede crear sin restricción sus análisis ad-hoc combinando
a su libre voluntad las métricas y dimensiones disponibles.
Modelo Conceptual del SIIF2 01/04/2014 54/203
El usuario objetivo es un perfil con un nivel de usuario avanzado de herramientas de BI que
da soporte analítico a perfiles estratégicos con responsabilidad de análisis sobre la
administración central normalmente perteneciente a los OO.RR o a divisiones de apoyo a los
mismos.
REQ 3-57 Metadata disponible para análisis
En el área de análisis el usuario dispondrá de las mismas medidas y dimensiones del modelo
multidimensional de datos utilizado para la realización de los reportes analíticos y
estratégicos
3.8.6 Reportes estratégicos
Reporte estratégico: reportes que permiten ver información a nivel de inciso de toda la
administración central. Presentan información en base a indicadores y gráficos que permiten
monitorear los principales objetivos de gestión y gobierno.
El usuario objetivo es un perfil estratégico con responsabilidad de análisis sobre la
Administración Central normalmente perteneciente a los OO.RR. o a divisiones de apoyo a
los mismos.
La definición detallada de los reportes estratégicos a construir y sus características
funcionales deberán realizarse durante el proyecto de desarrollo del sistema, sin embargo
ciertos requisitos de alto nivel pueden definirse en este momento:
REQ 3-58 Requisitos de los reportes estratégicos comunes a otros reportes
Los reportes estratégicos deberán satisfacer los siguientes requisitos ya descritos: REQ 3-54
Adaptación a la plataforma de BI y REQ 3-56 Cobertura institucional de los reportes
analíticos. Desde los reportes estratégicos no se tendrá acceso a detalle de transacciones.
REQ 3-59 Elementos gráficos
Los reportes estratégicos deben cumplir una función de dashboard visual para el usuario
estratégico. Por tanto su estructura será la más particular a todos los reportes incluyendo
elementos gráficos e indicadores.
3.8.7 Listado de los principales reportes
REQ 3-60 Listado de reportes
Se contempla como mínimo la elaboración de los siguientes reportes en forma automática
por parte del SIIF2.
Búsquedas:
o Un reporte de búsqueda por entidad principal del sistema: El reporte
proporcionará el listado de transacciones correspondiente a los filtros de
búsqueda para cada entidad3.
o Visualización de la transacción: Proporciona en formato imprimible la
información básica de cabecera y detalle de una transacción.
3 Se entiende por entidad las distintas entidades de negocio del modelo de Entidad – Relación del
sistema. Por ejemplo: las afectaciones, los compromisos, las obligaciones, los beneficiarios.
Modelo Conceptual del SIIF2 01/04/2014 55/203
Reportabilidad operativa:
o Libro de diario contable: Proporciona el listado de transacciones de
contabilidad que cumplen los filtros del reporte, ordenadas por fecha y folio y
con el detalle de los montos al debe y haber por cuenta contable.
o Libro de mayor contable: Proporciona para los filtros seleccionados del
reporte el saldo final de las cuentas contables seleccionadas así como la
posibilidad de ver los asientos contables que contribuyen al saldo de cada
cuenta.
o Detalle presupuestario: Proporciona el listado de transacciones de afectación
o compromiso u obligación (según se elija) que cumplen los filtros del
reporte, ordenadas por fecha y folio con la posibilidad de acceder al detalle
de los conceptos presupuestarios de cada transacción.
o Detalle de saldos presupuestarios: Proporciona para los filtros seleccionados
del reporte el saldo final de cada concepto presupuestario así como la
posibilidad de ver el conjunto de transacciones presupuestarias que
contribuyen a dicho saldo. Este reporte existe para cada una de los tres tipos
de transacciones presupuestarias.
o Cartera financiera presupuestaria: Proporciona, para los filtros
seleccionados, por principal o beneficiario el saldo de afectación (o
compromiso, devengado y obligado según se elija) y el detalle de
transacciones que contribuyen a dicho saldo.
o Cartera financiera contable: Proporciona, para los filtros seleccionados, por
principal o beneficiario el saldo contable y el detalle de asientos contables
que contribuyen a dicho saldo.
o Cartera financiera bancaria: Proporciona, para los filtros seleccionados, por
cuenta bancaria el saldo contable y el detalle de movimientos bancarios que
contribuyen a dicho saldo.
o Reporte de conciliación bancaria: Proporciona para los filtros seleccionados,
por cuenta bancaria, la diferencia entre el saldo contable y bancario y el
detalle de movimientos no conciliados que contribuyen a generar dicha
diferencia.
Reportabilidad analítica:
o Estado de ejecución presupuestaria: Proporciona para los filtros
seleccionados la visión completa del clasificador de gasto y muestra en
columnas los créditos, el afectado, el comprometido, el obligado y el pagado.
El reporte permitirá realizar drill-down a través del clasificador de gasto. El
reporte debe ofrecer también una visión equivalente para el estado de
ejecución de los recursos.
o Balance de sumas y saldos contables: Proporciona para los filtros
seleccionados la visión completa del plan de cuentas contable y muestra en
columnas el saldo inicial, los débitos, los créditos y el saldo final de cada
cuenta o grupo de cuentas. El reporte permitirá realizar drill-down a través
del plan de cuentas contable.
o Estado de Situación Financiera: Proporciona para los filtros seleccionados
los saldos de carteras netas, disponibilidades y anticipos y depósitos.
o Estado de la Deuda Pública: Proporciona para los filtros seleccionados los
saldos de deuda agrupados por tipo y vencimiento.
Modelo Conceptual del SIIF2 01/04/2014 56/203
Reportabilidad estratégica:
o 5 dashboards a definir con la contraparte.
De manera adicional al listado proporcionado la información contenida en el DataWarehouse
deberá ser exhaustiva a efecto de permitir tener los elementos básicos para poder construir
cualquier tipo de Información Fiscal requerida y Estados Financieros, como los detallados en
el Módulo de Contabilidad, o los reportes necesarios para la elaboración de las Cuentas
Nacionales.
REQ 3-61 Economía de reportes
Debe tenerse siempre presente que el número de reportes que ofrece el sistema ha de
mantenerse en unos límites razonables. Para ello es necesario que un perfil con visión global
de las potencialidades del sistema ponga criterio a las múltiples demandas de los usuarios y
que dé el visto bueno a la elaboración de un nuevo reporte sólo sí: aporta un valor diferencial
y no puede ser conseguida esa información a través de reportes ya existentes. El exceso en
el número de reportes del sistema es casi tan nocivo como la ausencia de reportabilidad.
3.9 Interoperabilidad
Considerando la mayor utilización de sistemas de información en el ámbito público es cada
vez más crítico que dichos sistemas tengan la capacidad de intercambiar información entre
ellos. En un SIAF este aspecto es de vital importancia puesto que en muchos casos depende
de la capacidad de interoperar que dicho sistema sea “integrado” o no.
La interoperabilidad entre el SIIF2 y el resto de los sistemas se desarrollará, en la medida de
lo posible, potenciando y/o aprovechando la plataforma de interoperación del estado
uruguayo desarrollada por la AGESIC.
REQ 3-62 Plataforma de interoperabilidad
La interoperabilidad entre el SIIF2 y el resto de los sistemas se desarrollará, en la medida de
lo posible, aprovechando y/o potenciando la plataforma de interoperación desarrollada por la
AGESIC.
El SIIF2 contemplará dos tipos diferenciados de interoperabilidad que procedemos a
describir: la interoperabilidad institucional y la interoperabilidad transversal.
3.9.1 Interoperabilidad institucional
La interoperabilidad institucional es la que se produce entre los módulos principales del SIIF2
y soluciones verticales de GRP que las distintas entidades públicas del ámbito de cobertura
puedan tener en funcionamiento.
Cuando una institución ya disponga de un GRP, o en el caso de que decida en un futuro
implantar este tipo de sistema, el SIIF2 permitirá la interoperación entre este tipo de sistemas
evitando al usuario la doble digitación de información.
Las posibilidades de interoperación institucional se desarrollarán bajo el siguiente conjunto
de requisitos:
REQ 3-63 Integridad y coherencia de la estructura de datos
La estructura y el contenido de la base de datos transaccional del SIIF2 debe ser íntegra
(contener los datos de toda la cobertura), coherente, consistente y completa. Las
Modelo Conceptual del SIIF2 01/04/2014 57/203
instituciones que decidan interoperar deberán hacerlo bajo la garantía de que los
mecanismos de interoperación permiten tener a los Órganos Rectores una calidad de
información equivalente a la situación en que la institución solo opere con el SIIF2.
REQ 3-64 Normas de interoperación a cargo del SIIF2
Las reglas de interoperación y la definición de los servicios web asociados dependerán en
última instancia del organismo a cargo de la regulación del SIIF2, en base a las regulaciones
del Estado Uruguayo desarrolladas por AGESIC.
REQ 3-65 Conjunto único de servicios web de interoperación
Se desarrollará un conjunto completo de servicios web de interoperación para garantizar el
cumplimiento de los requisitos previos. Dicho conjunto será único, es decir, no se realizarán
conjuntos adicionales para cada nuevo sistema institucional sino que los sistemas
institucionales deberán tener la capacidad de adaptarse al conjunto de servicios web
definidos.
REQ 3-66 Catálogos básicos e interoperación
Todos los sistemas institucionales que interoperen con el SIIF2 consumirán los catálogos
básicos a través de los servicios web habilitados y deberán tener la capacidad de continuar
funcionando normalmente en todos los eventos de altas, bajas y modificaciones de
elementos de dichos catálogos. Según el avance hasta el momento del cierre del Documento
de Modelo Conceptual los catálogos básicos son el Clasificador Presupuestario y el Plan de
Cuentas Contables.
REQ 3-67 Interoperabilidad institucional modular
El conjunto único de servicios de interoperabilidad se diseñará de forma modular de tal
manera que una institución tenga la capacidad de interoperar por ejemplo con el módulo de
presupuesto y utilizar el SIIF2 para gestionar la contabilidad y la tesorería.
REQ 3-68 Mecanismos de interoperabilidad vía up load
El sistema deberá tener funcionalidades que permitan la carga de archivos generados por
sistemas institucionales al SIIF2 vía mecanismos de upload. Para ello el SIIF2 deberá
desarrollar los procesos de validaciones correspondientes para asegurar que la información
que ingrese por este medio al SIIF2 cumpla con las reglas de negocio que correspondan.
REQ 3-69 Sistemas institucionales no aptos para la interoperación
Si un sistema institucional no es apto para interoperar, ya sea por incompatibilidad de su
modelo conceptual, por incompatibilidad de la estructura de datos financiero contable o bien
por incapacidad tecnológica, la institución deberá digitar sus transacciones en el SIIF2
manualmente o interoperar mediante un mecanismo de carga de información vía up load de
archivos.
3.9.2 Interoperabilidad transversal
La interoperabilidad transversal es la que se produce entre los módulos principales del SIIF2
y sistemas transversales a la cobertura del sistema, como por ejemplo el SICE y el SNIP. El
conjunto de sistemas con los que el SIIF2 interoperará transversalmente así como el alcance
funcional de alto nivel de dicha interoperación se detallará en el apartado 6 del documento.
Modelo Conceptual del SIIF2 01/04/2014 58/203
REQ 3-70 Interoperación transversal
El SIIF2 deberá desarrollar las capacidades funcionales y tecnológicas de interoperación
para intercambiar información con sistemas de cobertura transversal en el ámbito público,
como por ejemplo el SICE. La interoperación transversal deberá desarrollarse en ambos
sentidos y será indispensable el uso de los catálogos básicos “propietarios” de cada uno de
los sistemas de cobertura transversal. De acuerdo al avance hasta el momento del cierre del
Modelo Conceptual es posible mencionar como ejemplo de los catálogos básicos para el
SIIF2, el clasificador Presupuestario y el Plan de Cuentas, para el SICE el catálogo de
Bienes y Servicios y para el RUPE el catálogo de Proveedores.
Modelo Conceptual del SIIF2 01/04/2014 59/203
4. Integración presupuestaria y contable: principales
conceptos y definiciones
El Módulo de Presupuesto y el Módulo Contable son partes esenciales -no las únicas-, del
Sistema Integrado de Información Financiera. Ambos tienen elementos propios y comunes,
pero uno se complementa con el otro, por lo cual deben accionar en forma integrada,
respetando sus individualidades y sus objetivos. A modo de ejemplo: El presupuesto
(etimológicamente4 “pre” antes y “supuesto” estimación en virtud de su naturaleza previsional
o ex ante) tiene por objetivo estimar los recursos y gastos del Estado, en tanto que la
contabilidad tiene por objetivo captar la realidad (ejecución desde el punto de vista financiero
y económico) y elaborar la Rendición de Cuentas. Por su parte, el SIIF2, utilizando las TIC's
brinda soporte a la gestión del gasto público, generando información financiera confiable,
relevante y oportuna. Por lo tanto la sinergia entre ambos módulos de forma integrada en el
SIIF2 permite la obtención de información fiscal para la toma de decisiones, mejorando a su
vez la rendición de cuentas.
Desde el punto de vista de las transacciones presupuestarias / contables, la integración de
las mismas puede visualizarse a partir de la clasificación económica del presupuesto, que lo
ordena en tres grandes grupos y los relaciona de la siguiente forma:
Clasificación Económica del Presupuesto Plan de Cuentas Contable
1. Cuenta Corriente (ingresos corrientes
menos los gastos corrientes)
1. Directamente relacionadas con las
Cuentas de Resultado (ingresos / gastos)
2. Cuenta de Capital (ingresos de capital menos los gastos de capital)
2.1 Ingresos de Capital 2.1 Disminución de Activo no corriente
2.2 Gastos de Capital 2.2 Incremento en el Activo no corriente
3. Financiamiento (fuente menos aplicaciones)
3.1 Fuentes 3.1 Incrementos de Activos Corrientes contra
incrementos de Pasivos no Corrientes o
Patrimonio.
3.2 Aplicaciones Financieras 3.2 Disminuciones de Activos Corrientes
contra disminuciones de Pasivos Corrientes
y Pasivos no Corrientes.
La integración del presupuesto y la contabilidad es una exigencia para concretar el objetivo
de un moderno Estado que requiere a los administradores públicos proveer el suministro de
información accesible, oportuna y transparente de su gestión, para lo cual los clásicos
4 Estado Eficiente – Administración Financiera Gubernamental – Un enfoque sistémico – José María
Las Heras – Editorial Buyatti – Argentina.
Modelo Conceptual del SIIF2 01/04/2014 60/203
esquemas de información de la actividad estatal demostraron ser inadecuados en cuanto a la
cantidad, calidad, confiabilidad y oportunidad de la información suministrada.
En tal sentido, la visión sistémica, que permite ver a la organización como un todo, tanto con
relación a la influencia de contexto como en la interdependencia de sus distintos
componentes, resulta ser una herramienta significativa para el cumplimiento de los modernos
requisitos gubernamentales.
Como primer criterio, la visión sistémica es fundamental para la comprensión de la
problemática de las organizaciones estatales, pero es necesario contar con un segundo
enfoque que permita abarcar niveles desagregados de administración, para lo cual se recurre
a los lineamientos proporcionados por la “Teoría General de Sistemas”, que aporta al Modelo
Conceptual el enfoque necesario para conceptualización y el desarrollo en un nuevo SIIF. En
este marco se entiende como sistema a: “un conjunto de eventos o sucesos que no pueden
ser divididos en forma independientemente, dado que, en caso contrario, se arriesgan tres
importantes atributos, a saber: (i) cada parte (módulo) del sistema tiene propiedades que se
pierden cuando se separan del sistema (ii) cada sistema tiene propiedades esenciales que
no poseen ninguna de sus partes integrantes y (iii) ambos pierden el objetivo común”.
El enfoque de sistemas también suministra dos aportes sustanciales para organizar el flujo
de datos y la producción de información dentro del SIIF2, los cuales son:
Criterio de centralización normativa y descentralización operativa;
Integración de sistemas.
4.1 Centralización normativa y descentralización operativa
El SIIF2 requiere sustentarse en el principio conceptual y organizativo de centralización
normativa y descentralización operativa. Esto implica que se concentren las funciones de
diseño de políticas, dictado de normas y metodologías, así como las funciones de
evaluación, y se desconcentren las funciones operativas o de gestión.
Para garantizar el éxito en la aplicación de este principio, es importante que exista una clara
delimitación de competencias, funciones y responsabilidades entre los Órganos Rectores y
los ejecutores, evitando así la concurrencia, dispersión y superposición de múltiples
organismos en la administración de los recursos públicos.
La centralización normativa significa:
Definir las políticas generales que enmarcan el funcionamiento de cada uno de los
módulos;
Elaborar y supervisar el cumplimiento de las normas, metodologías y procedimientos
generales y comunes que regulan la operatoria del sistema, sin perjuicio de las
adaptaciones que deban realizarse en forma descentralizada en función de las
particularidades de determinadas agencias públicas;
Administrar el sistema y producir la información relevante que le corresponda a éste;
Evaluar el cumplimiento de las políticas.
La descentralización operativa significa:
Fortalecer la capacidad administrativa de las dependencias y entidades públicas para
que puedan ejecutar eficientemente sus objetivos, metas y programas en el marco
de las políticas definidas centralizadamente.
Modelo Conceptual del SIIF2 01/04/2014 61/203
El equilibrio entre la centralización normativa y la descentralización operativa debe funcionar
como garantía de un eficiente funcionamiento de cada módulo y del SIIF2 en su conjunto.
4.2 Integración del sistema
En función a lo expuesto anteriormente, los sistemas de información están integrados cuando
es posible fusionar los distintos módulos de cada área objeto de estudio y formar un solo
sistema, a partir de la identificación de sus elementos básicos, sin que cada uno de ellos
pierda su identidad.
Cuando las partes de un sistema están debidamente integradas, el total opera en forma más
eficaz y eficiente de lo que lo hacía la suma de las partes. Igualmente, vale señalar que la
calidad de una de las partes de un sistema condiciona la calidad del resto de las partes que
lo integran, dados los lineamientos de la misma “teoría de sistemas”. No siempre es sencillo
diseñar un sistema integrado, ya que en muchos casos se deben fusionar módulos afectados
por diversos enfoques, principios, criterios, normas y técnicas específicas. Para ello, se
requiere una adecuada armonización conceptual, normativa, funcional y operativa previa.
En el caso de la administración financiera pública, el diseño de un SIIF2 es factible en la
medida que las normas que regulan los diferentes sistemas que lo componen sean
coherentes entre sí y que se den adecuadas respuestas técnicas para relacionar los
diferentes tipos de información (presupuestaria, financiera, patrimonial, económica) que la
conforman.
La integración del sistema no se limita a implementar una mera técnica de agregación de
módulos o a un rediseño de procesos; menos aún a una técnica de procesamiento de la
información, restringida al ámbito de competencia específica de las unidades de informática.
El concepto presupone y necesita estar enmarcado dentro de una visión y una estrategia de
organización permeable al cambio, por lo que se exige el liderazgo y compromiso de todos
los niveles intervinientes, tanto de los directivos como de los profesionales y administrativos y
una lucha permanente contra la resistencia a cambiar para mantener el “trabajo individual”
versus una “gestión integrada”.
La integración implica un concepto moderno de organización sustentada en la visión
sistémica e integrada y, por ende, ello lleva necesariamente a un nuevo modelo conceptual y
organizacional y a una nueva forma de gestión de la administración financiera. Dentro de los
cambios que resultan recomendables implementar en el modelo organizacional, a efectos de
la integración de la información financiera, se pueden mencionar sintéticamente los
siguientes:
Modelo Conceptual del SIIF2 01/04/2014 62/203
4.3 Núcleo integrador del sistema
La contabilidad, bajo la concepción expuesta, es un módulo inherente al proceso económico
de las organizaciones, que opera en función de la teoría contable, sustentada, a su vez, en
Normas Contables que le dan confiabilidad a la información producida por la misma. Por
consiguiente, para su estudio, diseño y operación corresponde aplicar la metodología
aportada por el enfoque de sistemas que se ha expuesto precedentemente.
La contabilidad tiene por propósito producir Estados Financieros (EEFF) que muestren los
resultados de la gestión presupuestaria, financiera y económica, así como exponer la
situación patrimonial de las organizaciones. Para ello, la contabilidad opera a partir de los
datos de entrada que surgen del registro de los hechos que tengan o puedan llegar a tener
incidencia económico-financiera en la respectiva organización y cuyo procesamiento debe
realizarse de acuerdo con la metodología aportada por la teoría contable. Bajo un SIIF, el
módulo de contabilidad cumple la función de núcleo integrador del mismo, dado que cuando
las transacciones se devengan, cualquiera sea su módulo de origen, impactan en la
contabilidad (registro contable), aún aquellas que no tengan efecto presupuestario, las cuales
son de carácter económico, como por ejemplo las amortizaciones.
La confiabilidad de un SIIF con las características señaladas sólo puede ser alcanzada si su
núcleo está dado por la integración presupuestaria contable. Esta orientación marca el
principio fundamental de la nueva Contabilidad que debe ser concebida como un auténtico
sistema de información en sí misma, y dejar de lado esa visión simplista que durante años la
asoció a la teneduría de libros, que si bien es necesaria, puede ser realizada
automáticamente como todo otro procedimiento programable.
De
Información producida individualmente como poder de un área o un funcionario
Trabajo aislado e individual
Fuertes esfuerzos individuales y aislados para producción de información parcializada
Controles formales de ejecución o desempeño
Reconocimiento y promoción según indicadores de cantidad de insumos manejados
individualmente
A
Trabajo en red como poder de la organización
Trabajo en comités de coordinación
Menores esfuerzos individuales pero coordinados y unidos para producir información integral e
integrada de mayor calidad
Funcionarios con autonomía y responsabilidad en función de resultados
Reconocimiento y promoción a nivel de equipo según la contribución al logro de las metas de
mejoras colectivas
Modelo Conceptual del SIIF2 01/04/2014 63/203
El SIIF2, desarrollado con esta concepción, permitirá que los distintos EEFF que se elaboren
sean coherentes entre sí, al ser originados en la misma fuente informativa, permitiendo
además el acoplamiento modular y automático de la información necesaria para las
estadísticas fiscales como por ejemplo las utilizadas en el Sistema de Cuentas Nacionales de
las Naciones Unidas o para las Estadísticas de las Finanzas Públicas del Fondo Monetario
Internacional, los cuales deben derivarse de la misma fuente informativa.
Por ser el módulo de contabilidad el núcleo integrador de la información financiera y, por
ende, tener impacto en cada uno de los módulos que integrarán el SIIF2, la Contaduría
General de la Nación deberá ser el administrador del Sistema, procurando fundamentalmente
mantenerlo integrado. Ningún otro módulo podrá efectuar modificaciones al SIIF2 si no
cuenta con la intervención y aprobación de su administrador, el cual debe analizar qué
impacto tienen estas modificaciones sobre el módulo contable.
Contabilidad
Compra y venta de bienes
Pagos
Salarios
DeudaObras
Ingresos
Servicios
•Núcleo Integrador del Sistema
•Alta, bajas, modificaciones de bienes
•Pagos a proveedores,
• Pagos al exterior, etc.
•Sueldos al personal,
• SAC, premios, etc.
•Cancelación de deuda, avales,
•intereses
•Préstamos
•Certificados de Obras, altas, concesiones, etc.
•Recaudación de impuestos,
• Lotería / Casino ,
•Renta de la Propiedad,
•Venta de Bines / Servicios, etc.
•Contrataciones de personal,
•Alquileres,
•Servicio de limpieza,
•Luz, gas, TE, etc.
Ilustración 4-1 La contabilidad como núcleo integrador del sistema
El módulo de contabilidad, bajo el concepto de núcleo integrador, debe cumplir con una serie
de atributos, entre los que se destacan los siguientes:
Integridad: requiere cubrir la totalidad de las operaciones financieras y no
financieras de repercusión patrimonial, sean del ámbito presupuestario o no
presupuestario;
Unicidad: consiste, fundamentalmente, en el registro único de los datos, los que
deben ser ingresados al sistema una sola vez en el lugar donde ocurren las
respectivas transacciones;
Confiabilidad: debe ofrecer certeza de los datos, los hechos y las cifras,
sustentados en marcos normativos y procedimientos fiables;
Oportunidad: posibilita la obtención de información presupuestaria, contable y
financiera actualizada en forma permanente;
Verificación: posibilita el control de la calidad de la información mediante la inclusión
de pistas de auditorías incluidas en todos los procesos (ver 3.2.2);
Transparencia: requiere ofrecer información sobre la gestión financiera en forma
clara, uniforme y pública;
Modelo Conceptual del SIIF2 01/04/2014 64/203
Seguridad: brindar protección física y lógica de la información contra el acceso no
autorizado.
REQ 4-1 Administrador del Sistema
La Contaduría General de la Nación como responsable de la Contabilidad Gubernamental,
núcleo integrador del SIIF2, será el administrador del sistema a través de la gestión del
Módulo Contable.
4.4 Requisitos mínimos para la integración
Los requisitos y características básicas y mínimas que debe cumplir el SIIF2 para que el
Módulo Contable sea el núcleo integrador del mismo y de este modo obtener una base de
datos tal que permita contar con información presupuestaria, financiera, patrimonial y
económica, son los siguientes:
Universalidad del registro de las transacciones con efectos económico- financieros;
Registro único de cada transacción;
Definir claramente la estructura organizativa financiera del Sector Público;
Clasificadores Presupuestarios y Planes de Cuentas Contable complementarios e
integrados;
Matriz de conversión presupuesto / contabilidad;
Definición precisa de los momentos de registro.
4.4.1 Universalidad del registro de transacciones con efectos
económico-financieros
REQ 4-2 Universalidad del registro
Las transacciones que realizan las entidades gubernamentales deben ser registradas en su
totalidad, sean estas operaciones presupuestarias o no presupuestarias y tengan o no efecto
monetario (movimientos de caja). Todas las transacciones institucionales que tengan efecto
económico-financiero deben reflejarse dentro del SIIF2 en los momentos estipulados para el
registro de cada tipo de transacción.
4.4.2 Registro único
Todo movimiento económico-financiero presenta variadas facetas por las cuales puede
analizarse, ya que dichos movimientos tienen efectos presupuestarios, contables y de flujo
de fondos entre otros. Sin embargo, esta posibilidad de múltiple puntos de vista de análisis
no implica la realización de tres o más registros. Por el contrario, implica la realización de un
solo registro a efectos de garantizar la congruencia de cifras entre los distintos componentes
de la administración financiera gubernamental y a la vez reducir el excesivo trabajo de
registro.
A efectos de que el SIIF2 sea eficiente y genere confiabilidad de la información suministrada,
todas las transacciones con incidencia económico-financiera que realicen las entidades
gubernamentales deben ingresarse una sola vez al sistema, eliminando la duplicidad de
registros y por ende de datos, para una misma transacción.
Modelo Conceptual del SIIF2 01/04/2014 65/203
REQ 4-3 Registro único de efectos múltiples
El sistema deberá contemplar un solo registro de efectos múltiples. Es decir, la información
debe ingresarse al sistema en el lugar donde se inicia la transacción y posteriormente, dentro
del mismo sistema, se debe pasar de un evento a otro de acuerdo a las características de la
transacción.
REQ 4-4 Estructura de las unidades de registro
Las unidades de registro deberán definirse de acuerdo a la estructura organizativa de
establecida en las instituciones públicas y deberán cumplir con el principio que el registro
debe realizarse en el lugar donde se produzcan los hechos económico-financieros, a fin de
obtener información oportuna, confiable y segura. El presente requerimiento se debe
considerar en forma conjunta con el requisito de Estructura desde el punto de vista de la
Administración Financiera (cf. REQ 4-8 Estructura desde la administración financiera).
REQ 4-5 Procedimientos de registro
El sistema deberá dar soporte a los distintos procedimientos de registro, los cuales deberán
estar definidos en Manuales de Procedimientos que incluyan todas las transacciones
(universalidad) realizadas por las entidades gubernamentales y sustentadas en las Normas
que se expondrán en el Módulo Contable.
4.4.3 Estructura organizativa financiera de las instituciones del Sector
Público
El SIIF2 necesita contar con una estructura organizativa financiera, de forma tal que le
permita maximizar la utilización de la información a efectos de cubrir todas las necesidades
de los usuarios. Para ello será necesario contar con modelos estructurales que permitan
tener distintas perspectivas según sea la necesidad y atendiendo a los objetivos que
persigue el presente documento. Por esta razón las principales dimensiones a tener en
cuenta son los siguientes:
1 - Finanzas Públicas
2 - Presupuesto
3 - Administración Financiera
4 - Contabilidad.
4.4.3.1 Estructura desde las Finanzas Públicas
El Sector Público, visto desde las Finanzas Públicas, debe sustentarse en los parámetros
establecidos en el Manual de Cuentas Nacionales de las Naciones Unidas y en el Manual de
Estadísticas de las Finanzas Públicas 20015 del FMI. Estos manuales han ordenado en forma
homogénea y de acuerdo con la teoría económica los flujos y stocks financieros públicos, de
modo que sus clasificaciones pueden ser aplicadas universalmente y permiten la
comparación internacional de las cuentas públicas.
5 2001, como último Manual aprobado y en vigencia, si al momento del desarrollo del sistema existiera
una actualización del mismo deberá estar sustentado en el último aprobado por el FMI.
Modelo Conceptual del SIIF2 01/04/2014 66/203
REQ 4-6 Estructura desde las Finanzas Públicas
El Sistema ordenará el Sector Público teniendo en cuenta lo establecido en el Manual de
Estadísticas de las Finanzas Públicas 2001 del FMI, por lo cual su agrupación deberá
contemplar como mínimo los siguientes sectores:
ESTRUCTURA DEL SECTOR PÚBLICO URUGUAYO DESDE LAS FINANZAS PÚBLICAS
SECTOR PÚBLICO
URUGUAYO
Comprende el Sector
Gobierno General y
las entidades
controladas por el
gobierno, conocidas
como corporaciones
/empresas públicas,
cuya principal
función es realizar
actividades
comerciales.
Sector de Empresas/
Entidades
Comprende las
entidades jurídicas,
creadas con el fin de
producir bienes o
servicios para el
mercado. Pueden ser
fuente de utilidades o
de otra ganancia
financiera para sus
propietarios. La
corporación es
propiedad colectiva
de accionistas que
tienen atribuciones
para nombrar a los
directores
responsables de su
gestión general.
Sector de Empresas
no Financieras
Comprende las
entidades creadas
con el objeto de
producir bienes y
servicios no
financieros para el
mercado.
Empresas Públicas
no Financieras6
Sector de Entidades
Financieras
Comprende las
entidades cuya
actividad es prestar
servicios financieros
para el mercado.
Entidades
Financieras
(incluyendo el Banco
Central del
Uruguay)7
Sector Gobierno
General
Comprende las
entidades cuya
actividad primaria es
desempeñar las
funciones de
gobierno.
Sector Gobierno
Central
Compuesto por las
autoridades políticas
de un país se
extiende a todo el
territorio del mismo,
prestar servicios
colectivos en
beneficio de la
comunidad en
conjunto.
Subsector Central
Constituido por un
grupo central de
ministerios,
secretarías o
departamentos que
forman una sola
unidad institucional y
otras unidades que
realizan sus
actividades bajo la
autoridad del
gobierno central.
Subsector
Descentralizado
6 Empresas Públicas: Constitución de la República Oriental del Uruguay - Artículo 185 (Entes
Autónomos, excepto los excluidos por el artículo 186 del texto constitucional) y Artículo 221. 7 Entidades Financieras: Constitución de la República Oriental del Uruguay - Artículo: 196.
Modelo Conceptual del SIIF2 01/04/2014 67/203
Constituido por
instituciones que
tienen personería
jurídica propia y
autonomía suficiente
como para constituir
otras unidades
institucionales del
gobierno.
Fondos de Seguridad
Social8
Comprende todas las
unidades
institucionales que
realizan la gestión de
un sistema de
seguridad social.
Sector Gobierno
Departamental9
Comprende la
autoridad legislativa,
judicial y ejecutiva de
una unidad del
gobierno
departamental y se
limita a las zonas
geográficas en las
que puede dividirse
el país con fines
políticos o
administrativos. Son
consideradas
unidades
institucionales por
poseer sus propios
activos, recaudar
fondos e incurrir en
pasivos mediante la
obtención de
empréstitos por
cuenta propia.
8 Fondos de Seguridad Social: Constitución de la República Oriental del Uruguay Artículo: 195.
9 Gobiernos Departamentales: Constitución de la República Oriental del Uruguay Artículo: 262.
Modelo Conceptual del SIIF2 01/04/2014 68/203
4.4.3.2 Estructura desde el Presupuesto
La estructura desde el punto de vista del presupuesto se sustentará en la Constitución de la
República Oriental del Uruguay, así como otras normas que regulan el sistema
presupuestario.
REQ 4-7 Estructura desde el Presupuesto
El sistema deberá dar soporte a la estructura del presupuesto según los artículos 108, 214,
220 y 221 de la Constitución de la República Oriental del Uruguay.
4.4.3.3 Estructura desde la Administración Financiera
Sobre la base de la centralización normativa y descentralización operativa será necesario
estructurar al Sector Público Uruguayo a efectos del adecuado funcionamiento de la
Administración Financiera.
REQ 4-8 Estructura desde la administración financiera
La estructura bajo el concepto de la Administración Financiera, deberá contemplar las
siguientes agrupaciones:
Gobierno Central sin BPS, normalmente integrado por los tres poderes del Estado
(Legislativo, Judicial y Ejecutivo), con sus distintas jurisdicciones responsables de la
prestación de servicios para satisfacer las demandas comunitarias esenciales y
acciones de regulación y de control, conforme a los siguientes sustentos:
Financiamiento; se deriva de la función de recaudación que es asignada al Estado y
“el crédito público” (deuda pública y endeudamiento),
Personería jurídica: surge del origen fundacional del Estado expresado a través de la
Constitución, y
Patrimonio: comprende la sumatoria del conjunto de las instituciones de los tres
poderes que lo integran.
Organismos descentralizados, creados por normas especiales, asignándoles una
determinada función (tradicionalmente inherentes a la administración central) y que
por razones de mayor eficiencia y eficacia requieren una administración autónoma,
siendo necesarios asignarles:
Personería jurídica,
Patrimonio propio
Financiamiento: puede ser por recursos propios o por transferencias del Tesoro.
Organismos autónomos, creados por leyes específicas por las cuales tienen
autonomía en las decisiones, aunque no en todos los casos autarquía, mientras que
el origen de los recursos puede provenir principalmente del tesoro.
Gobiernos Departamentales También se pueden incluir dentro de este grupo a los
Gobiernos Municipales
Empresas y Sociedades Estatales, organizadas de acuerdo a las normas de carácter
comercial, por lo cual actúan en el mercado y se suelen financiar total o parcialmente
por el precio de las tarifas.
REQ 4-9 Unidades Rectoras, Unidades Ejecutoras y Unidades Organizativas
El SIIF2 deberá contemplar las siguientes unidades para su funcionamiento:
Unidades Rectoras: Formadas por las entidades centralizadas responsables de
formular las normativas del funcionamiento del SIIF2, a saber:
Modelo Conceptual del SIIF2 01/04/2014 69/203
Unidad Rectora Presupuesto: es la unidad responsable de definir el conjunto de
principios, normas, procedimientos y dictar las pautas que se aplicarán a
instituciones, procesos y procedimientos del módulo de presupuesto del SIIF2. A su
vez, ingresará al SIIF2 el presupuesto de ingresos y egresos, quinquenal y anual,
aprobado por la Legislatura como así también las modificaciones autorizadas a
dichos presupuestos.
Unidad Rectora Tesorería: es la unidad responsable de definir el conjunto de
principios, normas, procedimientos y dictar las pautas que se aplicarán a
instituciones, procesos y procedimientos del módulo de tesorería del SIIF2. A su vez,
administrará en el SIIF2 los recursos del Tesoro así como los pagos realizados por el
Tesoro y todos los ajustes relacionados con cualquiera de dichos movimientos.
Unidad Rectora Contabilidad: Administrará el SIIF2 en forma general, velando por
su integridad como sistema integrado de administración financiera pública. A su vez,
es la unidad responsable de definir el conjunto de principios, normas, procedimientos
y dictar las pautas que se aplicarán a instituciones, procesos y procedimientos del
módulo de contabilidad del SIIF2, e ingresará al sistema los asientos de apertura y
cierre del ejercicio en forma automática y tendrá como responsabilidad emitir los
EEFF.
Unidad Rectora Deuda Pública: es la unidad responsable de definir el conjunto de
principios, normas, procedimientos y dictar las pautas que se aplicarán a
instituciones, procesos y procedimientos del módulo de deuda pública del SIIF2. A su
vez, ingresará al SIIF2 las transacciones de amortización de deuda, intereses,
préstamos, colocación de títulos públicos e inversiones financieras, en forma directa
o mediante mecanismos de interoperabilidad.
Unidad Rectora Compras y Contrataciones: es la unidad responsable de definir el
conjunto de principios, normas, procedimientos y dictar las pautas que se aplicarán a
instituciones, procesos y procedimientos del Sistema de Compras y Contrataciones
Estatales (SICE), asegurando que los mecanismos de integración entre el proceso
de compras y adquisiciones, el registro único de proveedores del estado, y el
proceso financiero contable, gestionado en el SIIF2. Permita registrar en forma
oportuna los compromisos de recursos y las variaciones al patrimonio generadas por
el proceso de compras y adquisiciones.
Unidad/es Rectora/s de Recursos: Será/n el/las área/s responsable/s de definir el
conjunto de principios, leyes, normas, instituciones, procesos y procedimientos que
intervienen o se utilizan en la determinación de los ingresos, su percepción en forma
voluntaria, la identificación de incumplimientos y el cumplimiento forzado del conjunto
de fuentes de ingresos por contribuciones con incidencia económica y/o financiera
para el Tesoro Nacional. Informará los ingresos devengados y percibidos en sus
respectivas áreas (DGI, Aduanas, Casino, Lotería), así como los créditos que los
mismos generen.
Unidad Rectora Inversión Pública: Será el área responsable del conjunto de
principios, leyes, normas, instituciones, procesos y procedimientos que regulan,
intervienen o se aplican para la identificación, preparación, evaluación de pre-
factibilidad y de factibilidad, ejecución (por contrato o por administración) y
evaluación de los proyectos y programas de inversión. Informará sobre los
presupuestos de obras/proyectos y el avance de las mismas imputando los costos
correspondientes.
Unidad Rectora Recursos Humanos: Será el área responsable de la emisión de
leyes, normas, instituciones, procesos y procedimientos que intervienen o se aplican
Modelo Conceptual del SIIF2 01/04/2014 70/203
en la administración de los recursos humanos. Comprenden básicamente el plantel
básico de cargos y la descripción de los puestos de trabajo, las regulaciones
laborales vigentes relativas a las condiciones de trabajo, la política salarial y las
remuneraciones. Informarán la liquidación ordinaria y extraordinaria de salarios y
otras compensaciones por prestación de servicios.
Unidades Ejecutoras: formadas por las entidades responsables de la
administración presupuestal de las entidades, que se organizarán mediante
Direcciones Generales de Administración Financiera, serán las responsables de
realizar los registros en el SIIF2, cumpliendo con el requisito de estar lo mas
cercanas posibles al lugar donde se realiza la transacción. Las Unidades Ejecutoras
se podrán organizar en Unidades Organizativas para registrar la información según
las características de funcionamiento de las entidades públicas cubiertas por el
SIIF2.
Unidad Organizativa: Se considera Unidad Organizativa, dentro de cada Unidad
Ejecutora, la parte de las Unidad Ejecutora que es caracterizada por ser
componentes estructurales definidos por la homogeneidad de cometidos y
atribuciones, ya sean de línea jerárquica o de asesoramiento directo, y por tener un
volumen de trabajo que justifique una productividad y eficacia suficientes (Divisiones,
Departamentos, Secciones, Asesoría, Dirección)10
.
4.4.3.4 Estructura desde la Contabilidad
Para la implementación del Módulo Contable resulta fundamental, desde el punto de vista
estructural y funcional, definir cuáles serán las entidades responsables de la emisión de: (i)
Estados Financieros11
(EEFF), y (ii) Estados Financieros Consolidados (EFC), para lo cual
dichas entidades requieren ser agrupadas por Entes Contables (EC) y como tal deberán
responder a la siguiente definición:
Entes Contables: Los EEFF se refieren siempre a una unidad económica identificable, para lo
cual deberá:
constituirse una persona de carácter ideal con capacidad para adquirir derechos y
contraer obligaciones; y
contar con patrimonio propio como conjunto de medidas necesarias para el
cumplimiento de sus metas y objetivos conforme a los ordenamientos jurídicos que la
originaron.
Definido el EC “madre” (Ente Contable del sector Gobierno Central sin considerar los fondos
de la Seguridad Social) que estará a cargo de la CGN, la misma tendrá como
responsabilidad no sólo el proceso contable del Subsector Gobierno Central (sin considerar
los fondos de la Seguridad Social) y la emisión de los EEFF del mismo, sino también
formulará los EFC de todo el Sector Público Uruguayo, el cual tendrá diferentes capas de
consolidación o integración según corresponda.
10
Art. 5 Decreto 186/1996, 16 de Mayo de 1996. 11
Estados Financieros: Nombre dado por las Normas Internacionales de Contabilidad para el Sector
Público (NICSP) a un conjunto completo de Estados según lo define la NICSP N° 1 “Presentación de
Estados Financieros”, concepto este mucho más amplio que el conocido como Estado Contables.
Modelo Conceptual del SIIF2 01/04/2014 71/203
Si bien la CGN será la responsable de la preparación y emisión de los EEFF del Subsector
Gobierno Central (sin considerar los fondos de la Seguridad Social), los responsables de los
registros contables serán las Unidades Ejecutoras, a través de la matriz de relación
presupuesto / contabilidad (que se verá en el punto 4.4.5 Matriz de conversión presupuesto
contabilidad), la cual generará los asientos contables en forma automática. Asimismo y dado
que la mayoría de transacciones en las entidades de Gobierno son presupuestarias, donde el
registro del devengado presupuestario genera el asiento contable, pero es necesario
considerar que existen transacciones que son puramente contables, que no tienen sus
reflejos presupuestarios (deterioros, amortizaciones, contingencias, inventarios, etc.) por lo
cual resulta necesario que las Unidades Ejecutoras registren ambos tipo de transacciones.
REQ 4-10 Entes Contables
En el SIIF2 se deberán estructurar las entidades de acuerdo al concepto de unidad
económica identificable pero respetando la categoría de EC en el cual, en una primera
clasificación se designa las Entidades Comprendidas, a nivel de cada EC, verificando que
esta clasificación cumpla con la definición de dichos Entes y, en especial, la estipulada en el
apartado b) de la definición referida a unidad económica identificable. En el caso de las
entidades ANEP, UDELAR, INAU, ASSE y UTEC, serán considerados dentro del Ente
Contable del Sector Gobierno Central sin los fondos de la Seguridad Social. Bajo los
conceptos expuestos, el SIIF2 deberá identificar los siguientes EC:
Ente Contable del Sector Gobierno Central: (sin considerar los fondos de la
Seguridad Social)
o Responsable firmante: Contaduría General de la Nación…
o Concepto: Ente Contable “madre” al cual se consolidará o integrará la
información contable del resto del Sector Público.
o Entidades comprendidas: Servicios Descentralizados del dominio industrial y
comercial, conforme a las siguientes denominaciones a nivel individual:
Administración Nacional de Telecomunicaciones (ANTEL), Administración
Nacional de Puertos (ANP), Administración Nacional de Correos (ANC) y
Administración de las Obras Sanitarias del Estado (OSE), y Entes
Autónomos del dominio industrial, comercial y financiero, además del Banco
Central de Uruguay (BCU), Banco de la República Oriental del Uruguay
(BROU), Instituto Nacional de Colonización (INC), Banco de Previsión Social
(BPS), Administración Nacional de Combustibles y Portland (ANCAP),
Administración Nacional de Usinas y Trasmisiones Eléctricas (UTE), Agencia
Nacional de Vivienda (ANV), Banco de Seguros del Estado (BSE) y Banco
Hipotecario del Uruguay (BHU), Administración de Ferrocarriles del Estado
(AFE) y Primeras Líneas de Navegación Aerea (Pluna)12
.
Entes Contables de los siguientes Subsectores: Empresas Públicas Financieras y
No Financieras, Descentralizado y Fondos de la Seguridad Social
12
En el caso de ANEP, UDELAR, INAU, y ASSE se está revisando con el Tribunal de Cuentas su forma
de incorporación dentro del Ente Contable del Sector Gobierno Central.
Modelo Conceptual del SIIF2 01/04/2014 72/203
o Responsable firmante: Los contadores responsables del área contable,
conjuntamente con el Director de Administración Financiera o, para el caso
de Empresas Públicas, el Presidente de las mismas.
o Concepto: Entes Contables separados e individuales para cada entidad
gubernamental según sean sus características.
o Entidades comprendidas: Servicios Descentralizados del dominio industrial y
comercial, conforme a las siguientes denominaciones a nivel individual:
ANTEL, Administración Nacional de Puertos, Administración Nacional de
Correos y OSE, y Entes Autónomos del dominio industrial, comercial y
financiero, además del Banco Central de Uruguay, Banco de la República
Oriental del Uruguay, Instituto Nacional de Colonización, Banco de Previsión
Social, ANCAP, UTE y ANV, BSE y BHUAFE y Pluna.
Entes Contables del Sector Gobierno Departamental
o Responsable firmante: Los contadores responsables de los Gobiernos
Departamentales y Municipios
o Concepto: Entes Contables separados e individuales para cada entidad
gubernamental según sean sus características.
o Entidades comprendidas: Gobiernos departamentales individualmente
considerados y cada uno de los municipios.
REQ 4-11 Unidades Ejecutoras – Registración Contable
El SIIF2 deberá contemplar, dentro de la estructura contable de las entidades del Subsector
Gobierno Central, la creación de los roles y perfiles necesarios en las Unidades Ejecutoras
y/o Unidades Organizativas responsables de ingresar las transacciones contables no
presupuestarias.
Dichos roles y perfiles contables también deben estar en todos los EC del Sector Público
Uruguayo comprendidos en los alcances del sistema, cumpliéndose de este modo el principio
de centralización normativa y descentralización operativa. En el ámbito de las entidades
descentralizadas o autónomas con personería jurídica y patrimonio propio las Unidades
Ejecutoras y/o Unidades Organizativas, a través de sus roles y perfiles contables, serán las
responsables de la emisión de los EEFF de la correspondiente entidad gubernamental.
REQ 4-12 Unidad de Consolidación
A efectos del proceso de consolidación de la información contable será necesario que el
SIIF2 identifique e incluya cuáles son las Unidades de Consolidación. Por lo expuesto, la
responsabilidad de la consolidación del Sector Público Uruguayo queda en manos de la
CGN, por cuya razón la misma será la “Unidad de Consolidación Principal”.
Puede darse la situación que existan entidades del gobierno, que en sí mismas revistan la
condición de Entes Contables independientes y que, a su vez, tengan otras entidades
dependientes del mismo o que controlen13
a dichas entidades, como ser el caso de las
Empresas Públicas con subsidiarias o los Gobiernos Departamentales que tengan los
Municipios, en cuyo caso deberán estructurarse “Centros de Consolidación” de carácter
secundarios y que responderán a la Unidad de Consolidación Principal.
13
Control bajo el concepto de la NICSP N° 6 “Estados Financieros Consolidados y Separados”.
Modelo Conceptual del SIIF2 01/04/2014 73/203
4.4.4 Clasificador Presupuestario y Plan de Cuentas Contables
complementarios e integrados
La utilización de un clasificador presupuestario y un plan de cuentas únicos para todo el
Sector Gobierno Central sin Fondos de Seguridad Social, suponen una mejora sustantiva en
la producción de información a los fines de la gestión, toda vez que permita alcanzar una
visión integral y permanente referida a los resultados de las operaciones y a la situación
económico-financiera del mismo.
La integración de los clasificadores presupuestarios y el plan de cuentas contable permitirá
expresar en un lenguaje común, único y uniforme la totalidad de las transacciones
económico-financieras del Sector Gobierno Central, como así también identificar en forma
precisa los componentes significativos de los EEFF, operándose así con un cierto grado de
automatización en el proceso de integración y generando la posibilidad de una evaluación
más certera de la ejecución presupuestaria y una rendición de cuentas más confiable.
Contar con un lenguaje común y único es necesario para que la información del Sector
Público Uruguayo pueda consolidarse y de esa forma obtener una única información
económico-financiera del país. Esto se logra no sólo a través del cumplimiento de normas
emanadas de las unidades rectoras del SIIF2, sino también asumiendo previamente la
necesidad de concretar la homogeneización de los clasificadores presupuestarios, el plan de
cuentas contable y los catálogos de bienes.
La integración de los módulos de presupuesto, de contabilidad y de compras (Clasificador,
Plan y Catálogos) son requisitos esenciales y mínimos a cumplir en el diseño del SIIF2. Para
conseguir la adecuada integración en el funcionamiento del mismo, es importante que, en
primer término, exista una adecuada relación de los elementos del módulo de presupuesto
con los elementos del módulo de contabilidad, como así también la correspondiente relación
del clasificador por objeto del gasto con el catálogo de bienes utilizado por el módulo de
compras, ya que recién después de ello se podrán relacionar las codificaciones.
REQ 4-13 Desarrollo de Clasificadores Presupuestarios y Plan de Cuentas Contables
El SIIF2 deberá dar cumplimiento, a efectos de garantizar la confiabilidad en los catálogos
utilizados, a los siguientes requisitos:
Sustentación en las nuevas corrientes internacionales de la administración
financiera, por lo cual deben estar armonizados conforme a las siguientes relaciones:
o Clasificador Presupuestario: Manual de Estadísticas de las Finanzas
Públicas (2001) del Fondo Monetario Internacional; y
o Plan de Cuentas Contable: Normas Internacionales de Contabilidad para el
Sector Público emitidas por el Consejo de Normas Internacionales de
Contabilidad para el Sector Público (IPSASB) de la Federación Internacional
de Contadores (IFAC);
o Deben ser desarrollados en forma conjunta;
o Mantenidos en forma constante, y con una frecuencia de actualización en
función de la necesidad que de ellas se tenga, por lo cual deberán contar con
la suficiente flexibilidad que permita incorporar las nuevas transacciones
Modelo Conceptual del SIIF2 01/04/2014 74/203
originadas por futuras operaciones, ya que solamente de esta forma se
garantizará la vital comparabilidad14
de los ejercicios económicos;
o Deben ser gestionados y mantenidos por la CGN en su rol de administrador
del SIIF2.
Los clasificadores presupuestarios y el plan de cuentas contable utilizados en el presupuesto,
contabilidad y cuentas nacionales deben permitir su acoplamiento modular, asegurando el
procesamiento automático de la información y evitando conversiones o nuevas
reasignaciones de los datos ya procesados. Este requisito obliga a que entre los
clasificadores presupuestarios y el plan de cuentas se especifiquen cuáles serán utilizados a
nivel de cada transacción y cuáles surgirán por agregación de datos ya registrados a nivel de
cada una de las mismas.
4.4.4.1 Clasificadores Presupuestarios
Los Clasificadores Presupuestarios constituyen la estructura funcional donde se sustentarán
en el SIIF2. Dichos clasificadores permitirán organizar y presentar todas las operaciones
desarrolladas en el ámbito del Sector Público Uruguayo, conformando un sistema de
información realmente ajustado a las necesidades integrales del Gobierno, llevando
estadísticas sobre los sectores públicos nacionales y posibilitando un análisis objetivo de las
acciones ejecutadas por dicho Sector.
Por lo expuesto, el conjunto de clasificaciones presupuestarias representará una herramienta
fundamental para el registro de la información relativa al proceso de recursos y gastos de la
actividad pública, debiendo responder cada clasificador a un propósito u objetivo
determinado; sin perjuicio de que, en su diseño, deben considerarse las necesarias
interrelaciones que existen entre todos ellos a los fines de enriquecer el análisis y evaluación
de la ejecución presupuestaria.
A fin de precisar las interrelaciones de los clasificadores entre sí, es necesario distinguir los
clasificadores primarios, a través de los cuales se registra cada transacción, sea ésta de
recurso o de gasto, de los clasificadores derivados, que surgen de la combinación de dos o
más clasificadores. Es decir en el caso de los clasificadores derivados se estructuran
automáticamente por combinación de los clasificadores primarios y, por lo tanto, no se
capturan al momento de registrar cada transacción u otro flujo en particular.
Los objetivos que deben cumplir los clasificadores presupuestarios son los siguientes:
Contar con clasificaciones presupuestarias que permitan tener un lenguaje único
para toda la administración financiera del país.
Posibilitar su integración con otros clasificadores, planes y catálogos.
Permitir la obtención de información consolidada del Sector Público Uruguayo.
Contribuir al fortalecimiento de los procesos de toma de decisiones y de rendiciones
de cuentas.
Garantizar una administración financiera transparente.
Dotar a las entidades del Gobierno General de una herramienta de Administración
Financiera que les brinde información útil, confiable y oportuna, a los fines de lograr
una adecuada gestión.
14
Comparabilidad: Objetivo de los EEFF según las NICSP.
Modelo Conceptual del SIIF2 01/04/2014 75/203
REQ 4-14 Sustento normativo de los Clasificadores Presupuestarios
Los clasificadores presupuestarios a desarrollar se sustentarán en las siguientes normativas:
La Constitución de la República.
El TOCAF.
Leyes no contempladas en el TOCAF.
A su vez, también deben considerar en forma referencial:
Manual de Estadísticas de las Finanzas Públicas 2001 del FMI, y
Normas Internacionales de Contabilidad para el Sector Público de la IFAC.
REQ 4-15 Estructura de los Clasificadores Presupuestarios
Los clasificadores presupuestarios con los cuales deberá operar el SIIF2 serán por lo menos
los siguientes:
Clasificadores Presupuestarios
Válido para todas las
transacciones
(presupuestarias y
contables)
Institucional Primarios Deberá contemplar lo
establecido en los puntos
4.4.3 Estructura organizativa
financiera de las instituciones
del Sector Público.
Por tipo de moneda
Finalidad y Función Secundarios
(siempre que se
cuenten con las
categorías
programáticas,
pues de lo
contrario serán
Primarios)
Deberá cumplir con los
requerimientos de la NICSP
18 “Información Financiera
por Segmentos”
Fuente de
Financiamiento
Primarios
Geográfico15
Recursos Por Rubro Deberá estar armonizado
con el clasificador de la DGI /
DNA y sustentado sobre el
Manual de Estadísticas de
las Finanzas Públicas 200116
del FMI
15
Clasificador Geográfico: deberá contemplar las necesidades de clasificación geográficas que puedan
llegar a tener las instituciones.
16 2001, como último Manual aprobado y en vigencia, si al momento del desarrollo del sistema existiera
una actualización del mismo deberá estar sustentado en el último aprobado por el FMI.
Modelo Conceptual del SIIF2 01/04/2014 76/203
Clasificadores Presupuestarios
Por Carácter Económico Secundarios
Gastos Por Objeto Primarios
Por Carácter Económico Derivados
Por Categoría
Programática
Primarios
El clasificador debe ser “abierto” (no taxativo y definitivo), razón por la cual se incluirá la
especificación “Otros”, con el código 99 como identificación distintiva. Dicho código sólo
podrá ser utilizado por la CGN a efectos de hacer flexible el mismo (debiendo establecer,
asimismo, la correspondiente relación con los clasificadores derivados). Dicha flexibilidad
tiene por objeto permitir su adecuación a las diversas situaciones que se presenten.
El desarrollo de los clasificadores siempre deberá estar relacionado con los clasificadores
actuales a efectos de garantizar una correcta transición a los clasificadores proyectados
REQ 4-16 Estructura Institucional
El Clasificador Institucional deberá formularse para ser aplicado tanto por el Módulo de
Presupuesto como por el Módulo Contable y el mismo deberá contener un mínimo de 12
dígitos y reflejando como mínimo, el siguiente ordenamiento17
:
1: Sector: 1 dígito
Sector Público Uruguayo
2: Subsector: 1 dígito
Sector Público No Financiero
Sector Público Financiero.
3: Agrupación: 1 dígito
Sector Gobierno General (SGG)
Sector Gobierno Empresarial.
4: Áreas: 1 dígito
Sector Gobierno Central
Sector Gobiernos Departamentales
5: Subáreas: 2 dígitos
1.1.1.1.01 Subsector Gobierno Central
1.1.1.1.02 Subsector Gobierno Descentralizado
1.1.1.1.03 Fondos de la Seguridad Social
17
Los ejemplos dados desde el punto 6 a 8 son a efectos ejemplificativos.
Modelo Conceptual del SIIF2 01/04/2014 77/203
1.1.1.1.04 Municipios
6: Jurisdicciones: 1 dígito
1.1.1.1.01.1 Poder Ejecutivo
1.1.1.1.01.2 Poder Legislativo
1.1.1.1.01.3 Poder Judicial
1.1.1.1.01.4 Organismos de Control
7: Instituciones: 3 dígitos
1.1.1.1.01.1.´001 Presidencia de la República
1.1.1.1.01.1.´002 Ministerio de Defensa Nacional
1.1.1.1.01.1.´003 Ministerio de Economía y Finanzas
8: Unidad Ejecutora: 3 dígitos
1.1.1.1.01.1.´001.001 Servicios de Apoyo a la Presidencia de la República
9: Unidad Organizativa: 2 dígitos
1.1.1.1.01.1.´001.001.01Unidad Organizativa Despacho Presidente
1.1.1.1.01.1.´001.001.02 Unidad Organizativa Ceremonial y Protocolo
El presente clasificador debe ser “abierto” (no taxativo y definitivo), razón por la cual se
incluirá la especificación “Otros”, con el código 99 como identificación distintiva. Dicho código
sólo podrá ser utilizado por la CGN a efectos de hacer flexible el mismo (debiendo
establecer, asimismo, la correspondiente relación con los clasificadores derivados). Dicha
flexibilidad tiene por objeto permitir su adecuación a las diversas situaciones que se
presenten.
REQ 4-17 Estructura por Objeto del Gasto
El Clasificador por Objeto del Gasto deberá ser diseñado e implementado con un nivel de
desagregación tal que permita que sus cuentas faciliten el registro único de todas las
transacciones públicas con incidencia económico-financiera.
La estructura del Clasificador por Objeto del Gasto deberá contener una apertura mínima de
cinco (5) niveles, con nueve (9) dígitos, debiendo asegurarse su agrupamiento y
ordenamiento sobre criterios lógicos predefinidos, pudiendo resultar necesario incorporar
niveles adicionales en partidas que por su naturaleza así lo demanden a efectos de
garantizar la integración de la información financiera, conforme al siguiente enfoque:
Modelo Conceptual del SIIF2 01/04/2014 78/203
Nivel Dígitos Agrupación Ejemplo
1er nivel Uno Grupos Gastos
2do nivel Dos Subgrupos Servicios Personales
3er nivel Dos Objeto Retribuciones personal permanente
4to nivel Dos Partida Principal Básico al cargo
5to nivel Dos Partida Parcial Adicionales
REQ 4-18 Estructura de Recursos
La clasificación de recursos por rubros que el SIIF2 deberá contener ordena, agrupa y
presenta a los recursos públicos en función de los diferentes tipos que surgen de la
naturaleza y el carácter de las transacciones que les dan origen.
Por ello, la clasificación deberá distinguir los recursos que provienen de fuentes tradicionales,
tales como impuestos, tasas, contribuciones, derechos y transferencias, de los que proceden
del patrimonio público, como son la venta de activos, títulos y acciones, ingresos diversos y
las rentas de la propiedad y de los que a su vez provienen del financiamiento, como el
recupero de préstamos y crédito público. La disminución de activos y el incremento de los
pasivos se incorporan a esta clasificación a efectos de unificar los criterios de registro
presupuestario y contable.
Deberá desarrollarse una fluida operatividad en el registro, motivo por el cual los recursos se
agruparán, como mínimo, en seis (6) niveles, con una apertura de once (11) dígitos,
adecuándose a las necesidades operativas de la CGN y armonizados con los clasificadores
utilizados por las unidades ejecutoras de recursos (DNA, DGI, Dirección General de Casinos,
Dirección Nacional de Loterías y Quinielas) y en cumplimento de lo requerido en el Manual
de Estadísticas de Finanzas Públicas (2001) del FMI, tal que:
Nivel Dígitos Agrupación Ejemplo
1er nivel Un digito Capítulo Ingresos
2do nivel Dos dígitos Clase Impuestos
3er nivel Dos dígitos Secciones Impuestos a las Ganancias
4to nivel Dos dígitos Grupos Impuesto sobre los ingresos
5to nivel Dos dígitos Partida Principal Persona Física
6to Nivel Dos dígitos Partida Parcial Impuesto al Trabajo
4.4.4.2 Planes de Cuentas Contable
A efectos de viabilizar el registro y procesamiento sistemático de los flujos económico-
financieros en la contabilidad, se requiere de clasificadores – Planes de Cuentas – que
permitan catalogar y agrupar los cambios experimentados por las principales variables que
determinan y resultan del desempeño de un ente, atendiendo a una precisa tipificación de la
naturaleza de dichos flujos, de manera tal que las agregaciones y desagregaciones de
información que surjan de la aplicación de tales Planes, exterioricen conjuntos homogéneos
Modelo Conceptual del SIIF2 01/04/2014 79/203
transaccionales y diferenciales de otros conjuntos homogéneos del mismo nivel de apertura
del Plan.
REQ 4-19 Sustento normativo del Plan de Cuentas Contable
El diseño y apertura del Plan de Cuentas Contable del SIIF2 deberá asegurar la producción
de EEFF, por lo cual dicha apertura debe cumplir con los requerimientos de las NICSP y en
particular conforme las estipulaciones de presentación y contenido establecidas en la NICSP
Nº 1.”Presentación de Estados Financieros”
Complementariamente, el diseño y apertura del Plan de Cuentas Contable deberá resultar
compatible con la presentación de información consolidada18
, según lo establece la NICSP
Nº 6 “Estados Financieros Consolidados y Separados”, al tiempo que viabilizará y facilita el
proceso de consolidación, toda vez que:
permite la identificación en forma precisa de componentes significativos de los EEFF
según el nivel de la institución pública de que se trate;
permite la identificación en forma precisa de las partidas de créditos y deudas
intergubernamentales;
permite la apertura a octavo nivel de mayores niveles de desagregación, siendo a
tales efectos indispensable, a los fines de consolidación, la catalogación de las
partidas de créditos y deudas y de resultados por transacciones
intergubernamentales, según los clasificadores que identifiquen en forma precisa
cada institución.
REQ 4-20 Estructura del Plan de Cuentas Contable
La estructura del Plan de Cuentas Contable del SIIF2 deberá desarrollarse sobre la base de
una apertura mínima a siete (7) niveles, alcanzando un total de (15) dígitos, deberá cumplir
con las siguientes agrupaciones de: (i) clase, (ii) grupo, (iii) cuenta; (iv) subcuenta y (v)
Subcuenta anexa. A efectos de cubrir acabadamente necesidades de información adicional a
las previstas en las aperturas a nivel de subcuentas, y que pueden variar de una institución
pública a otra, se considera la existencia en el séptimo nivel de un Auxiliar, como se expone
en el siguiente Cuadro:
Nivel Agrupación Digito Aperturas
1 Clase un dígito ACTIVO, PASIVO, PATRIMONIO, INGRESOS y
GASTOS
2 Grupo un dígito ACTIVO, PASIVO: Corriente y No corriente;
PATRIMONIO: Patrimonio público e Intereses
minoritarios
INGRESOS: Impuestos, Contribuciones sociales,
Multas, sanciones, remates y confiscaciones de origen
no tributario, Ingresos y resultados positivos por ventas,
Ingresos de la propiedad, Transferencias, Otros
18
Cumplimiento del Decreto Nª 103/91 a efectos de lograr la consolidación del Sector Público.
Modelo Conceptual del SIIF2 01/04/2014 80/203
ingresos
GASTOS: Gastos de funcionamiento, Gastos
financieros; Gastos y resultados negativos por ventas;
Transferencias y Otros gastos
3 Rubro dos dígitos Inventarios (Bienes de Consumo)19
4 Cuenta20
dos dígitos Materiales y suministros para consumo y prestación de
servicios
5 Subcuenta dos dígitos Materiales y productos de uso en la construcción y
mantenimiento
6 Subcuenta
anexa
dos dígitos Materiales y productos metálicos.
7 Auxiliares Cinco
dígitos
Productos de Acero Inoxidable
El Plan de Cuentas también deberá contemplar que toda apertura que signifique o explique
una clasificación residual del nivel al cual pertenece y en la que, por lo general, se utiliza la
denominación de “otros”, sea codificada con el último número posible para cada nivel (9 si el
nivel tiene un dígito, o 99 si el nivel tiene dos dígitos).
4.4.4.3 Catálogos de Bienes
Es fundamental que el SIIF2 cuente con un sistema de codificación que permita representar
todo el universo tanto de bienes de consumo como los activos fijos, con la flexibilidad
suficiente para que las definiciones sean claras y precisas. Además, dicha codificación
deberá poseer una serie de datos asociados, de manera tal que pueda ser utilizada por todas
aquellas áreas involucradas en la administración de los bienes (presupuesto, compras y
contabilidad).
Así, el SIIF2 contemplará la correspondiente codificación de los bienes de tal modo que
permita su integración en forma automática con el presupuesto y la contabilidad a efectos de
obtener información homogénea partiendo desde su compra, su ingreso al inventario (alta de
los bienes) y, por ende, su registro presupuestario y contable, incluyendo las variaciones
acaecidas en los inventarios de los mismos.
Para cumplir con dicho requerimiento del SIIF2, el catálogo de bienes debe responder y
contener la apertura solicitada tanto por el Objeto del Gasto Presupuestario, como de la
apertura del Plan de Cuentas Contable en lo relacionado a los activos (bienes de uso, bienes
de infraestructura, bienes intangibles, activos biológicos, bienes de consumo, etc.). La
integración a realizar debe ser automática por lo cual se recomienda que dicha relación se
establezca para el alcance de todos los bienes a efectos minimizar las modificaciones
posteriores, por tal motivo se podrá tomar el catálogo actualmente vigente en la medida que
cumpla con lo dicho y en especial que su alcance sea total o se podrá tomar el de las
19 Sólo se toma una cuenta a modo de ejemplo. 20 Nivel a efectos de consolidación de la información.
Modelo Conceptual del SIIF2 01/04/2014 81/203
Naciones Unidas, cualquiera sea el elegido deberán mostrarse las conveniencias del uso de
uno u otro a efectos de establecer criterios uniformes y homogéneos para la identificación de
los bienes.
Las características que debería tener dicha codificación son las siguientes:
Flexibilidad: para que permita representar todo el universo de todos los bienes, en
forma fácil y unívoca,
Parametrización: para evitar duplicaciones de los objetos, que lo tornarían
inmanejable dado el volumen que podría llegar a contener.
El catálogo deberá tener uniformidad en el lenguaje, a los fines de que:
Permita realizar comparaciones,
Posibilite la integración con otros sistemas,
Permita realizar análisis para optimizar procesos,
Permita la elaboración de estadísticas,
Facilite el control de gestión, y
Posibilite mejorar el servicio de la compra.
REQ 4-21 Estructura del Catálogo de Bienes
El catálogo de bienes a utilizar en el SIIF2 deberá contemplar dos partes, a saber:
Primera agrupación: que identificará la clase genérica del objeto, por lo cual tomará
la agrupación del Clasificador por Objeto del Gasto, de forma tal que le posibilite la
integración del catálogo con todos los módulos de administración financiera, dado
que este sistema de identificación no sólo debe ser válido a los efectos de obtener un
inventario, sino que también debe poder utilizarse en la administración de bienes,
para las compras, para estadísticas y para la toma de decisiones, gestión y control, y
Segunda agrupación: que agrupará las características del objeto llegando a la
especificación del ítem y debiendo incluir:
o Código de Segmento,
o Código de Familia,
o Código de Clase,
o Código de Material, y
o Datos Asociados.
o Es recomendable que el catálogo tenga como mínimo la estructura de ocho
(8) dígitos, dividido para las dos partes identificadas, a saber:
De 4 dígitos, que identificará la clase de objeto,
De otros 4 dígitos, que aglutinará las características particulares de
todos los elementos pertenecientes al objeto o clase genérica y
o También será necesario que cuente con “datos asociados” donde cada
objeto integrante del catálogo contará con una serie de datos adicionales
asociados a los efectos de su integración. De esta manera se definirá:
Serie de datos a los efectos del inventario,
Serie de datos que posibiliten la administración de bienes,
Serie de datos que posibiliten la gestión de compras,
El conjunto de series de datos, que proveerán información para la
gestión, toma de decisiones y control.
Modelo Conceptual del SIIF2 01/04/2014 82/203
4.4.4.4 Interrelación de la Clasificación Presupuestaria, Planes de Cuentas Contable y
otros Sistemas
Para la preparación de las clasificaciones se debe considerar el carácter independiente de
cada uno de los módulos, a los efectos de determinar una adecuada compatibilidad de las
metodologías, normas y procedimientos que son necesarias para el desarrollo de un sistema
de información de gestión pública.
El Sistema de Cuentas Nacionales y las Estadísticas Públicas (FMI) son usuarios de los
clasificadores presupuestarios y planes contables para la elaboración de las cuentas del
Sector Público Uruguayo posibilitando así el análisis de las finanzas públicas, que resumen el
flujo económico transaccional y no transaccional del Gobierno General y permiten orientar la
medición mediante indicadores específicos del impacto monetario de las medidas
económicas.
REQ 4-22 Integración del Clasificador Presupuestario, del Catálogo de Bienes y Plan
de Cuentas Contable
La clasificación a realizar en el SIIF2 debe facilitar el enlace modular, condición que permite
establecer un grado de interdependencia entre los módulos del sistema, sirviendo tanto a los
registros presupuestarios como contables y éstas, a su vez, proporcionarán elementos
necesarios para integrarlas con las Cuentas Nacionales y las Estadísticas de las Finanzas
Públicas.
Se deben integrar los clasificadores al mínimo nivel que sean imputables. En principio, y sólo
a efectos de ejemplo y dependiendo de los niveles que conformarán las estructura definitiva
del Clasificador Presupuestario, del Plan de Cuentas Contable y del Catálogo de Bienes, la
integración deberá realizarse en los siguientes niveles:
Nivel
Cont.
Nivel
Pres.
Contabilidad Presupuesto Contrataciones
Estructura 1
(Por Objeto
del Gasto)
Estructura 2
(Por
característica
de los Bienes )
1 Clase
2 1 Grupo Grupo
3 2 Rubro Subgrupo
4 3 Cuenta Objeto
5 4 Subcuenta Partida Principal Segmento
6 5 Subcuenta
anexa
Partida Parcial Familia
7 Auxiliares Clase
Material
Datos asociados
Modelo Conceptual del SIIF2 01/04/2014 83/203
4.4.5 Matriz de conversión presupuesto contabilidad
Una de las características sustanciales del SIIF2 debe ser la producción de información
presupuestaria, económica, financiera, contable y de gestión en forma simultánea, mediante
la utilización de clasificaciones combinadas y de la matriz de conversión, que relacionan los
clasificadores presupuestarios de recursos y de gastos con las cuentas del Plan de Cuentas
Contable, por etapas o momentos del registro, identificando la obra o proyecto en la
estructura programática, la fuente de financiamiento, el medio de percepción y el medio de
pago.
La matriz debe permitir la conversión generando los asientos contables sobre partida doble
en la contabilidad en forma simultánea al registro de la ejecución presupuestaria, en los
momentos del devengado y percibido de recursos, y devengado, mandado a pagar y pagos
de gastos y sus modificaciones, además de permitir el registro de las transacciones sin
efectos presupuestarios. La administración de la matriz debe ser de la CGN.
REQ 4-23 Desarrollo de la matriz de conversión presupuesto / contabilidad
El SIIF2 deberá contener el desarrollo del modelo funcional de la matriz de conversión
presupuesto / contabilidad que permitirá obtener, en forma automática y en una base central
contable, todos los asientos que surjan de las transacciones financieras y económicas. Dicha
base permitirá producir, por agregación de la información previamente almacenada, los EEFF
que incluirá la información tanto Contable como Presupuestaria, de Deuda Pública, de
Tesorería, Cuentas Nacionales y Estadísticas de Finanzas Públicas.
4.4.6 Momentos de Registro
Los momentos de registros constituyen otro de los requisitos claves para la integración del
SIIF2, ya que seleccionar dichos momentos es fundamental para garantizar la interrelación
de los módulos que lo componen a los efectos de obtener información presupuestaria,
financiera y patrimonial.
El orden de los momentos de registro se origina partir de los momentos presupuestarios,
para integrarse en el momento del devengado, dando nacimiento en dicho momento, a la
contabilidad. Los mencionados momentos son los siguientes:
4.4.6.1 Para los Gastos
4.4.6.1.1 Aprobado
El Presupuesto aprobado es la autorización para gastar o monto autorizado21
de crédito
derivado de leyes de asignación presupuestaria, otorgada por el Poder Legislativo.
4.4.6.1.2 Modificado
Es el presupuesto aprobado por el Poder Legislativo que ha sido modificado a posteriori22
con la correspondiente autorización. Las modificaciones pueden ser realizadas por la
Legislatura o a quien ella delegue.
21
Artículo 95 del TOCAF.
22 Artículo 95 del TOCAF.
Modelo Conceptual del SIIF2 01/04/2014 84/203
4.4.6.1.3 Afectación Preventiva
Dicho registro es un acto de administración interna, útil para dejar constancia, certificar o
verificar la disponibilidad de créditos presupuestarios y efectuar la reserva de los mismos al
inicio de un trámite de gastos, antes de concretarse el compromiso.
4.4.6.1.4 Comprometido23
Constituyen compromisos los actos administrativos dictados por la autoridad competente,
que disponen destinar definitivamente la asignación presupuestal o parte de ella, a la
finalidad enunciada en la misma. Los compromisos deberán ser referidos, por su concepto e
importe, a la asignación presupuestal que debe afectarse para su cumplimiento.24
4.4.6.2 Para los Recursos
4.4.6.2.1 Estimados25
Son los cálculos iniciales de los recursos que se estima recaudar en el ejercicio.
4.4.6.2.2 Modificados26
Son las modificaciones realizadas a las estimaciones originales de recursos presupuestarios.
4.4.6.2.3 Devengado (Tratado en el punto 4.4.6.3 Base del devengado).
El devengado de los recursos es el momento en que se produce una modificación cualitativa
y/o cuantitativa en la composición del patrimonio de la Administración Pública, originada en el
ejercicio de su poder de imperio o en transacciones con incidencia económica y financiera,
independientemente del momento en que se produzca el ingreso de fondos, dando así origen
a un crédito.
4.4.6.2.4 Percibido (en el Tesoro)27
El percibido de los recursos es el momento en que los recursos son ingresados en los
organismos u oficinas correspondientes, quedando los recursos a disposición del tesoro,
mediante el pago directo del deudor o, indirectamente, por transferencia de agentes
recaudadores.
4.4.6.2.5 Conciliado en el Banco
Es el momento en que lo conciliado alimenta la disponibilidad financiera de los fondos de
libre disponibilidad de los Ministerios.
4.4.6.3 Base del devengado
Los EEFF deben presentarse sobre base devengada tanto en gastos como en recursos
pudiendo para estos últimos, y hasta tanto se perfeccione el registro de los recursos
23
Artículo 95 del TOCAF.
24 Artículo 14 del TOCAF.
25 Artículo 95 del TOCAF.
26 Artículo 95 del TOCAF.
27 Artículo 12 del TOCAF.
Modelo Conceptual del SIIF2 01/04/2014 85/203
devengados, registrarlos por lo percibido. Por lo tanto, en una primera etapa la metodología
de registro utilizado en el SIIF2 será sobre base caja modificado (gastos por lo devengado y
recursos por lo percibido).
Más allá de lo expuesto, se debería ir a una aplicación gradual del devengado en los
recursos, para de esta forma cumplir a cabalidad con los requerimientos del Sistema de
Cuentas Nacionales, el de Estadísticas de la Finanzas Públicas (FMI) y de las Normas
Internacionales de Contabilidad para el Sector Público de la IFAC.
El momento clave de integración de las transacciones presupuestarias y contables es el
“devengado”. En dicho momento es donde se produce la integración entre los módulos
presupuestarios y contables, dado que en este momento se genera la afectación cuantitativa
o cualitativa del Patrimonio del Estado.
El devengado es un postulado contable que refleja la realidad económica, más allá de la
realidad legal, tal como se expresa FMI (2001)28
“3.41 Si se utiliza la base devengado, los
flujos se registran cuando se crea, transforma, intercambia, transfiere o extingue valor
económico. En otras palabras, los efectos de los eventos económicos se registran en el
período en el que ocurren, independientemente de que se haya efectuado o esté pendiente
el cobro o el pago de efectivo. No obstante, no siempre queda claro el momento en que
ocurren los eventos económicos. En general, el momento que se les atribuye es el momento
en el cual cambia la propiedad de los bienes, se suministran los servicios, se crea la
obligación de pagar impuestos, surge un derecho al pago de una prestación social, o se
establece otro derecho incondicional.”. El FMI fundamenta la utilización del devengado en las
siguientes razones:
la base devengado ofrece la mejor estimación del impacto macroeconómico de la
política fiscal del gobierno (3.47);
la base devengada brinda la información más completa porque registra todos los
flujos de recursos, incluidas las transacciones internas, las transacciones en especie
y los otros flujos económicos. (3.48);
todos los atrasos estarán incluidos en las estadísticas compiladas sobre la base
devengado (3.49);
la información sobre los flujos de efectivo no se pierde al utilizar la base devengado,
por lo cual permitirá realizar una eficaz gestión de liquidez. (3.50);
Con la base devengada, las adquisiciones de activos no financieros se registran por
separado y se hace coincidir el gasto de utilizar esos activos en actividades
operativas con el período en que se los usó, y no con el período en que se los
adquirió (3.51); y
Uniformidad en el tratamiento dado con relación a los otros grandes Sistemas
Estadísticos Macroeconómicos (Cuentas Nacionales, Balanza de Pagos, y
Estadísticas Monetarias y Financieras) utilizan la base del devengado. (3.52).
Por su parte el Manual del Sistema de Cuentas Nacionales de las Naciones Unidas29
establece: “El principio general de la contabilidad nacional es que las transacciones entre
unidades institucionales han de registrarse cuando nacen los derechos y las obligaciones,
cuando se modifican, o cuando se cancelan, es decir, ateniéndose al principio de base
28 Manual de Estadísticas de Finanzas Públicas 2001- a. Posibles bases de registro. 29
Sistema de Cuentas Nacionales 1993 2. Momento de registro.
Modelo Conceptual del SIIF2 01/04/2014 86/203
devengado; las transacciones internas de una unidad institucional se registran análogamente
cuando el valor económico se crea, transforma o extingue. En general, todas las
transacciones, prescindiendo de su naturaleza intrínseca, pueden considerarse (2.64)”.
Las Normas Internacionales de Contabilidad del Sector Público emitidas por el Consejo de
Normas Internaciones de Contabilidad del Sector Público (IPSAS) de la Federación
Internacional de Contadores (IFAC), sustenta sus principales Normas sobre la base
devengada definiéndola como: “Base de acumulación (o devengo): es una base contable por
la cual las transacciones y otros hechos son reconocidos cuando ocurren (y no cuando se
efectúa su cobro o su pago en efectivo o su equivalente). Por ello, las transacciones y otros
hechos se registran en los libros contables y se reconocen en los estados financieros de los
ejercicios con los que guardan relación. Los elementos reconocidos según la base contable
de acumulación (o devengo) son: activos, pasivos, activos netos/patrimonio, ingresos y
gastos.” El IPSASB a través de Estudio 14, Diciembre 201130
, expone los beneficios de la
contabilidad de acumulación (o devengo), entre los que se mencionan:
Es útil tanto para la responsabilidad como para la toma de decisiones. Los informes
financieros preparados conforme a base de acumulación (o devengo) les permiten a
los usuarios:
Evaluar la responsabilidad para todos los recursos que controla la entidad y la
implementación de esos recursos.
Evaluar la situación y el rendimiento financieros, y los flujos de efectivo de la entidad.
Tomar decisiones sobre si proporcionar recursos o mantener relaciones comerciales
con la entidad.
A un nivel más detallado, la presentación de informes de base contable de
acumulación (o devengo) permitirán, entre otros, informar sobre:
exponer la situación financiera general y los activos y pasivos actualmente
disponibles;
demostrar su responsabilidad ante el público por la administración de sus activos y
pasivos reconocidos en los estados financieros;
planificar el pago o la cancelación de los pasivos existentes;
ofrecer un marco uniforme para la identificación de pasivos existentes y pasivos
potenciales o contingentes;
facilitar una mejor administración de los activos, lo que incluye un mejor
mantenimiento, políticas de reemplazo más apropiadas, identificación y eliminación
de los activos excedentes, y una mejor administración de los riesgos como
fluctuaciones en el valor de los pasivos;
poner de manifiesto el impacto de las decisiones financieras sobre el patrimonio y los
activos netos, pudiendo llevar a que las entidades del sector público, al tomar
decisiones financieras, adopten una visión más a largo plazo de lo que generalmente
es posible al basarse en informes de efectivo o de efectivo modificado.
30
Transición de la base contable de acumulación (o devengo):v Directrices para entidades
del Sector Público.
Modelo Conceptual del SIIF2 01/04/2014 87/203
Desde el punto de vista legal, en el caso de Uruguay31
, coincide con la visión económica del
devengado de gastos, dado que el mismo nace cuando “surge la obligación de pago” y dicha
obligación se genera con el cumplimiento del hecho económico que le dio origen. (Por ej.: el
devengamiento de la compra de un bien se da con la recepción del mismo y el
reconocimiento de una cuenta por pagar).
El devengado de los gastos es el momento en que se produce una modificación cualitativa
y/o cuantitativa en la composición del patrimonio de la Administración Pública, producida por
transacciones con incidencia económica y financiera, independientemente del momento en el
que se produzca la salida de fondos, generando una obligación a pagar.
4.4.6.4 Mandado a Pagar
A efectos administrativos y dado el sistema de control que tiene Uruguay con la intervención
del Tribunal de Cuentas, será necesario generar el momento de “mandado a pagar” donde,
una vez emitida la Orden de Pago (OP) se generan dos estados diferentes y secuenciales :
Obligado Intervenido: Cuando la OP cuenta con la intervención del Tribunal de
Cuentas y pasa a la Tesorería para su pago, y
Obligado Priorizado: Cuando la OP ya intervenida por el Tribunal de Cuentas es
priorizada para que la Tesorería General de la Nación efectué el pago.
La incorporación del momento “mandado a pagar” permitirá tener un registro del devengado
con mayor precisión, más allá de que la transacción tenga algún atraso en la intervención o
en el pago. De esta forma que separando el momento del devengado del mandado a pagar
se garantizará que los EEFF expongan al cierre del ejercicio las transacciones realizadas
reflejando la obligación por pagar como corresponde, más allá de que algunas de ellas
puedan tener algún impedimento de pago.
4.4.6.5 Pagado
Se considerará pagada una obligación cuando la Tesorería emita los medios de pago
correspondientes (por ejemplo cheque o transferencia bancaria). En el caso de Pago por
Nota, se imputará previo al mandado a pagar y el pagado definitivo cuando se realice la
transferencia bancaria.
En resumen, los momentos que se deben implementar e identificar dentro del SIIF2 son los
detallados a continuación:
31
TOCAF: Art. 20º. “Los créditos presupuestales se considerarán ejecutados cuando se devenguen los
gastos para los cuales han sido destinados. Se entiende que los gastos se devengan cuando surge la
obligación de pago por el cumplimiento de un servicio o de una prestación”.
Modelo Conceptual del SIIF2 01/04/2014 88/203
Concepto Momentos
Presupuestario Contable
Gastos Aprobado
Modificado
Afectación Preventiva
Compromiso
Devengado Devengado
Mandado a Pagar Mandado a pagar
Pagado Pagado
Recursos Estimado
Modificado
Devengado Devengado
Percibido Percibido
De tal forma, los procesos administrativo-financieros que originan “recursos y fuentes”
(fuentes) y “gastos y aplicaciones” (usos) tienen un momento o etapa clave de sus
respectivas transacciones, el devengado, el cual permite integrar los registros del
presupuesto y la contabilidad y de esa forma el SIIF2 producirá información presupuestaria,
financiera y económica en forma automática.
Modelo Conceptual del SIIF2 01/04/2014 89/203
5. Integración de los módulos principales
5.1 Visión global
En esta Sección se presenta en mayor detalle la integración de los principales módulos qué
componen el núcleo del SIIF2: presupuesto, contabilidad, tesorería, deuda y recursos. En
especial se detalla la integración presupuestaria contable como se solicitaba en los Términos
de Referencia de este proyecto.
Ilustración 5-1 Estructura de los módulos principales del SIIF2
5.2 Módulo presupuestario
En el presente apartado se describen los objetivos, requerimientos y aspectos de integración
a tener en cuenta para el módulo presupuestario.
5.2.1 Objetivos
El módulo de presupuesto debe contemplar las funcionalidades necesarias para el registro y
la gestión asociada a todo el ciclo presupuestario, tanto para gastos como para ingresos,
considerando las etapas del ciclo presupuestario de la siguiente forma:
La formulación presupuestaria: original del presupuesto quinquenal de la República
Oriental del Uruguay y las formulaciones anuales actualizadas mediante el ajuste de
los valores e indicadores y las sucesivas rendiciones de cuentas, los que generarán
los créditos disponibles para los ejercicios sucesivos dentro del quinquenio.
Modelo Conceptual del SIIF2 01/04/2014 90/203
La ejecución presupuestaria: que toma como insumo el presupuesto producido por el
proceso de formulación presupuestaria (quinquenal y anuales) y controla y asiste a la
ejecución del mismo durante cada ejercicio fiscal.
La evaluación presupuestaria: que toma como insumo la información de la fase de
formulación presupuestaria y la información de la ejecución presupuestaria para
proceder a la evaluación, retroalimentando el ciclo presupuestario.
A su vez, el Módulo Presupuestario debe considerar los siguientes principios para su
adecuado funcionamiento:
a) Programación: el presupuesto debe tener el contenido y la forma de la programación.
b) Universalidad: dentro de este postulado se incluye la necesidad de que todo aquello
que constituya materia del presupuesto debe ser incorporado en él.
c) Exclusividad: que no se incluyan en la ley quinquenal y las rendiciones de cuentas
anuales del presupuesto asuntos que no sean inherentes a esta materia. Ambos
principios tratan de precisar los límites y preservar la claridad del presupuesto.
d) Unidad: es la obligación impuesta a todas las instituciones del sector público
uruguayo para que sus presupuestos sean elaborados, aprobados, ejecutados y
evaluados con plena sujeción a la política presupuestaria establecidas por autoridad
competente.
e) Factibilidad: debe programarse lo que es factible ejecutar.
f) Claridad: los documentos presupuestarios se expresan de manera ordenada y clara,
todas las etapas del proceso pueden ser llevadas a cabo con mayor ajuste a los
tiempos y a los resultados a alcanzar.
g) Especificación: en materia de ingresos, deben señalarse con precisión las fuentes
que los originan y, en materia de gastos, las características de los bienes y servicios
que deben adquirirse.
h) Periodicidad: el presupuesto respetará las leyes nacionales, contemplando tanto la
presupuestación quinquenal como las proyecciones anuales.
i) Continuidad: si bien el presupuesto es quinquenal las formulaciones anuales deben
considerarse con la continuidad del presupuesto. Esta norma postula que todos y
cada uno de los elementos del presupuesto anual, deben apoyarse en la rendición
de cuentas.
j) Flexibilidad: el presupuesto no debe contener rigideces que le impidan constituirse
en un eficaz instrumento de administración, de gobierno y de programación
económica y social. Para lograr esta condición en la ejecución del presupuesto, es
necesario remover los factores que obstaculizan una fluida realización de esta etapa
presupuestaria, dotando a los niveles administrativos participantes del poder
suficiente para modificar los medios en provecho de los fines prioritarios del Estado.
k) Equilibrio: el total de gastos públicos debe ser igual al total de los ingresos públicos.
5.2.2 Requisitos
Actualmente en Uruguay existen subsistemas en producción que dan respuesta a las fases
de formulación y evaluación presupuestaria, por ello en el presente documento el esfuerzo se
focaliza en detallar los requisitos funcionales de la fase de ejecución presupuestaria. Aun así
se incluyen también requisitos de muy alto nivel para la formulación y la evaluación que todo
SIAF debe cumplir.
Modelo Conceptual del SIIF2 01/04/2014 91/203
5.2.2.1 Formulación
REQ 5-1 Generación del presupuesto Ley
El sub-módulo de formulación deberá permitir gestionar todo el ciclo de gestión desde la
etapa de borrador hasta el último estado de ley aprobada incluyendo el articulado de la Ley.
REQ 5-2 Transmisión de las leyes en materia Presupuestal al módulo de ejecución
El sub-módulo de formulación deberá contar con los mecanismos necesarios para transmitir
al módulo de ejecución los valores de la Ley de Presupuesto aprobada, con su respectiva
desagregación, así como las modificaciones realizadas en el proceso de Rendición de
Cuentas y las modificaciones surgidas en el articulado, para habilitar al sub-módulo de
ejecución a iniciar la operativa del ejercicio fiscal .
REQ 5-3 Gestión completa del ciclo quinquenal
El sub-módulo de formulación deberá contemplar las funcionalidades necesarias para
formular un presupuesto quinquenal y deberá, en todas las instancias, permitir al usuario una
visión global sobre la totalidad del quinquenio, así como de los presupuestos anuales que se
han ido modificando a lo largo del quinquenio.
5.2.2.2 Ejecución
En el presente apartado se detallan los requisitos funcionales asociados a la ejecución
presupuestaria y haciendo mención especial a los roles implicados en el proceso de la
operativa habitual uruguaya en cuanto a controles y autorizaciones se refiere.
5.2.2.2.1 Ejecución de los gastos
REQ 5-4 Crédito inicial y modificaciones
El módulo de ejecución del SIIF2 tomará como punto de partida de la ejecución los créditos
de la Ley de Presupuesto aprobada. El sistema deberá permitir gestionar el ciclo de
modificaciones presupuestales – incrementos, disminuciones y reasignaciones - y contar en
todo momento con el crédito vigente (inicial + modificaciones) y el crédito disponible (vigente
– afectaciones).
REQ 5-5 Solicitud de modificaciones
El sistema deberá contar con funcionalidades que permitan gestionar el proceso de solicitud
y aprobación de modificaciones presupuestales – incrementos, disminuciones y
reasignaciones – tanto en los Incisos como en los Órganos Rectores de acuerdo al marco
legal vigente.
REQ 5-6 Distribución de créditos por Unidad Ejecutora y Unidad Operativa
El sistema deberá ofrecer la posibilidad de distribuir los créditos presupuestales de cada
programa y objeto del gasto por Unidad Ejecutora y/o por Unidad Operativa según las
necesidades de cada Inciso que conforma la Ley de Presupuesto.
REQ 5-7 Funcionalidad de Topes y Abatimientos
El sistema debe permitir en casos excepcionales y a perfiles seleccionados fijar topes de
ejecución de manera selectiva a los objetos de ejecución del gasto que el usuario indique.
Este tope puede ser fijado para cada objeto de forma porcentual o absoluta.
Modelo Conceptual del SIIF2 01/04/2014 92/203
REQ 5-8 Etapas de ejecución presupuestaria de los gastos
El sistema deberá contemplar la existencia de cinco etapas de ejecución presupuestaria en el
caso de los gastos: i) afectación preventiva, ii) compromiso, iii) devengado (obligado
verificado), iv) mandado a pagar (que incluye obligado intervenido y obligado priorizado) y v)
pagado. El punto de partida de la cadena presupuestaria serán los créditos vigentes de la ley
de presupuesto con sus posteriores actualizaciones.
REQ 5-9 Lógica de cadena presupuestaria
De una entidad (o etapa) cualquiera de la cadena presupuestaria se podrá encadenar
entidades (etapas) de la siguiente fase de ejecución respetando siempre que la suma de
montos de entidades de una etapa posterior sea menor o igual al monto de la entidad
precedente.
REQ 5-10 Prudencia presupuestaria
Las transacciones de la cadena presupuestaria en estado generado reservarán crédito de la
transacción previa. En caso de ser anuladas se liberará el crédito asociado. Este principio
permite evitar conflictos en caso de aprobación masiva de transacciones generadas.
REQ 5-11 Información requerida por cada entidad
La información requerida por cada entidad (afectación preventiva, compromiso, devengado,
etc.) deberá ser definida en detalle durante la fase de levantamiento funcional del proyecto
de implementación del sistema. Deberán contemplarse por lo menos el objeto del gasto, el
año, la fecha, la unidad organizativa, el área programática, el programa, el proyecto, fuente
de financiamiento, moneda y el monto entre otros.
REQ 5-12 Captura de información orientada a documentos de negocio
La captura de información deberá realizarse orientada a los documentos de negocio que
soportan el proceso (por ejemplo licitaciones, órdenes de compra, facturas, notas de crédito)
De esta manera el usuario que registra información del sistema deberá operar bajo la
premisa que está “introduciendo una factura en el sistema” en vez de que está “dando de alta
una obligación”. El sistema contemplará igualmente la posibilidad de entrar información de
forma neutra (sin asociarlo a un documento de negocio).
REQ 5-13 Arrastre de información a lo largo de la cadena
La información capturada deberá heredarse a lo largo de la cadena de forma que toda la
información común entre, por ejemplo, una afectación preventiva y un compromiso, no deba
volver a introducirse. La información se capturará siempre en el primer momento en que esté
disponible (i.e. adjudicación de una compra en el momento del compromiso, ingreso de bien
en el momento del devengado, el envío a la tesorería para el pago en el momento de la
obligación y por último la cancelación de la factura en el momento del pago).
REQ 5-14 Obligaciones y pagos sin compromiso
El sistema ofrecerá facilidades a los usuarios, en los casos que la normativa lo permita, para
realizar obligaciones y pagos directamente desde la afectación preventiva sin necesidad de
realizar todos los pasos de la cadena presupuestaria. El sistema generará el compromiso y el
devengo correspondiente para que la consistencia de datos de la cadena presupuestaria se
mantenga de forma transparente para el usuario final.
Modelo Conceptual del SIIF2 01/04/2014 93/203
REQ 5-15 Compromisos que impactan en ejercicios futuros
El sistema deberá contemplar no sólo el almacenamiento y la gestión de los créditos para
años subsiguientes del quinquenio sino también de los compromisos que se extienden por
más de un ejercicio fiscal solo a título informativo.
REQ 5-16 Programa de ejecución
El sistema deberá proponer e informar un programa de ejecución con la previsión de
ingresos y gastos a ejecutar, desagregado a nivel del clasificador institucional y el de objeto
del gasto como mínimo. El programa de ejecución deberá actualizarse mensualmente en
base a los datos de la ejecución efectivamente realizada, permitiendo para el caso de los
gastos, la reprogramación de los gastos no ejecutados. El programa de ejecución servirá
para ejercer control informativo a través de la reportabilidad del ritmo de ejecución
presupuestaria. El programa de ejecución no limitará la capacidad de obligación efectiva de
los incisos.
REQ 5-17 Estados y modificaciones de las transacciones
Las transacciones registradas contemplarán un esquema de estados según definido en el
apartado 3.2.9 Estado de las transacciones REQ 3-25 Estado de las transacciones. Las
transacciones aprobadas sólo serán modificables a través de transacciones de ajustes que
pasen por el mismo circuito de validación que la transacción original. No se permitirá la
existencia simultánea de ajustes en estado generado. Para poder reajustar una transacción
será obligatorio que todos los ajustes previos estén aprobados.
REQ 5-18 Cartera financiera
La información asociada al proveedor (y la posible existencia de un beneficiario) se manejará
en una sub-entidad independiente asociada al compromiso, al devengo y al pago. Esto
permitirá ofrecer reportabilidad de mayor riqueza relativa a los proveedores de la cobertura.
REQ 5-19 Gestión multimoneda
La ejecución de gasto en moneda extranjera se controlará en base a tipos de cambio
provisionales en las etapas de afectación y compromiso. En el momento de la obligación se
registrará el asiento contable asociado en base al tipo de cambio del momento. Cualquier
diferencia generada por tipo de cambio, tanto a favor o en contra, producida por variaciones
en el tipo de cambio entre los momentos de obligación y pago tendrá su correspondiente
impacto financiero, generándose el movimiento contable correspondiente.
REQ 5-20 Ejecución de gastos asociados a la Gestión Humana
La ejecución de gastos asociados a los sueldos de los funcionarios deberá contemplar los
escenarios de interoperación necesarios para poder generar, a partir de la información del
SGH-SLH, los compromisos asociados al pago de los sueldos de todo el ejercicio fiscal y el
devengamiento mensual del gasto.
REQ 5-21 Ejecución de gastos asociados a Bienes de Uso y Consumo
La ejecución de gastos asociados a los Bienes de Uso y Consumo deberá contemplar los
escenarios de interoperación necesarios para integrarse con el SICE, a través del catálogo
de cuentas relacionado con el objeto del gasto y el plan de cuenta contable y de los
procedimientos a efectos de generar los compromisos, devengamiento y pagos asociados a
los procesos de licitación manejados por el SICE.
Modelo Conceptual del SIIF2 01/04/2014 94/203
REQ 5-22 Ejecución de gastos asociados a Inversión
La ejecución de gastos asociados a los proyectos de Inversión deberá contemplar los
escenarios de interoperación necesarios para generar las transacciones asociadas de forma
consistente los criterios y la información que maneja el SNIP.
REQ 5-23 Ejecución de Proyectos Internacionales
El sistema deberá contar con las funcionalidades necesarias para gestionar los proyectos
financiados por organismos multilaterales. Para ello deberá contar con un repositorio que
contenga la información del préstamo o proyecto permitiendo su rendición y generación en
forma automática de los reportes solicitados por dichos organismos. Los pagos asociados a
la ejecución de dichos recursos quedarán automáticamente asociados a las cuentas
corrientes creadas a tal efecto. Esta funcionalidad debe contar con los desarrollos necesarios
para interoperar con el Sistema de Proyectos Internacionales cuando el mismo se encuentre
operativo.
REQ 5-24 Arrendamientos Oficiales
El sistema debe contar con las funcionalidades necesarias para registrar, gestionar y validar
los pagos de los alquileres mensuales que surgen de los contratos de arrendamientos
oficiales. Para ello deberá contar con un repositorio de datos que contenga la información
correspondiente a los contratos de arrendamientos oficiales, generando información que
permita controlar en forma restrictiva las obligaciones que los Incisos a nivel de Unidad
Ejecutora registren en el sistema correspondiente al pago de alquileres. Esta funcionalidad
debe funcionar en forma interdependiente con el módulo presupuestario y el módulo contable
para registrar los movimientos contables y presupuestarios correspondientes en forma
automática. Al inicio del ejercicio la funcionalidad en base a la información del repositorio
generara todas las afectaciones y compromisos del ejercicio y generara periódicamente las
obligaciones correspondientes.
REQ 5-25 Gestión de Fondos Rotatorios
De acuerdo a la normativa vigente, el sistema debe contar con las funcionalidades
necesarias para una adecuada gestión de los Fondos Rotatorios autorizados para los Incisos
a nivel de Unidad Ejecutora.
La funcionalidad de gestión de fondos rotatorios debe permitir la ejecución de operaciones
normales o de regularización de fondos. El módulo debe realizar en forma automática al
inicio del ejercicio el cálculo de la disponibilidad de fondos rotatorios para cada Inciso en
base a la duodécima parte del crédito presupuestal menos la diferencia que se arrastra del
ejercicio anterior y debe liberar una operación de tesorería desde la CUN a las cuentas de los
Incisos. Esta funcionalidad debe registrar la autorización de los fondos rotatorios como
anticipo de fondos y su liquidación, al momento de devengar dicha liquidación, en el módulo
contable.
REQ 5-26 Generación y Envío de Resguardos de Retenciones a DGI
El sistema deberá generar en forma automática los resguardos asociados a las retenciones
de impuestos (por ejemplo: IVA, IRPF no dependientes, IRPF arrendamientos, etc.). La
información de estos resguardos generados deberá ser enviada a la DGI en un formato
establecido por dicho Organismo.
Modelo Conceptual del SIIF2 01/04/2014 95/203
REQ 5-27 Cierre de ejercicio
El sistema deberá contemplar todos los aspectos asociados al cierre anual del ejercicio.
Deberá considerarse la idoneidad de habilitar también cierres periódicos.
5.2.2.2.2 Ejecución de los recursos
Para los fines del presente MC se entenderá por ingresos a todos aquellos que percibirá el
subsector Gobierno Central sin fondos de seguridad social cualquiera sea su fuente de
origen (DGI, DNA, Dirección Nacional de Loterías y Quinielas, Dirección General de Casinos,
otros ingresos percibidos en la Tesorería), pero que sean distintos a los originados en
operaciones de deuda pública.
La estimación se realizará sobre los parámetros fijados por el marco macroeconómico y fiscal
en que se elaborará el presupuesto explicitando, además, las hipótesis económico-
financieras sobre las variables propias del organismo que se tienen en consideración para la
estimación.
REQ 5-28 Transacciones asociadas a recursos
El SIIF2 debe contar con los mecanismos necesarios para que en el componente recursos
del Módulo de Presupuesto las áreas que realizarán transacciones que son registradas en el
Sistema sean las siguientes:
DGI,
DNA,
Dirección Nacional de Loterías,
Dirección General de Casinos,
TGN,
Cajas Paraestatales,
Incisos,
BROU,
BCU,
Otros
REQ 5-29 Unidades de registro asociadas a recursos
El SIIF2 debe contar con los mecanismos necesarios para que en el componente recursos
del Módulo de Presupuesto las unidades de registros se encuentren lo más próximas
posibles al evento que genera la transacción, resultando aconsejable que el registro lo realice
directamente la Unidad Rectora Recursos, a través de sus entidades públicas dependientes,
en especial, a través de la DGI y DNA. En el caso de los ingresos provenientes de Dirección
Nacional de Loterías y Quinielas y Dirección General de Casinos correspondería
incorporarlos directamente al módulo presupuestal, quedando el registro a cargo de las
Unidades Ejecutoras de Dirección Nacional de Loterías y Quinielas y Dirección General de
Casinos, como asimismo el tratamiento de los recursos propios de los distintos Incisos que
conforman el Gobierno Central.
En el caso que este proceso requiera un proceso gradual de implementación, el módulo de
presupuesto del SIIF2 deberá poder capturar los datos necesarios para la registración
presupuestaria de los ingresos mediante mecanismos de interoperación adecuados desde
los sistemas de origen de las entidades recaudadoras o bien permitir el registro en forma
directa sobre el módulo de presupuesto del SIIF2.
Modelo Conceptual del SIIF2 01/04/2014 96/203
REQ 5-30 Etapas de ejecución presupuestaria de los recursos
El sistema deberá contemplar la existencia de dos etapas de ejecución presupuestaria en el
caso de los ingresos: i) devengado y ii) percibido. El punto de partida de la cadena
presupuestaria será la estimación de los recursos de la ley de presupuesto, con sus
posteriores modificaciones.
5.2.2.2.3 Roles de la ejecución presupuestaria
Una adecuada definición de roles es clave para el correcto funcionamiento del SIIF2 en
régimen. Para ello los roles deben ser claramente definidos en la etapa de diseño del
sistemas en base a los roles generales señalados a continuación.
REQ 5-31 Rol generador de transacciones
El sistema contemplará la definición de un rol de usuario habilitado para generar
transacciones.
REQ 5-32 Rol aprobador de transacciones
El sistema contemplará la definición de un rol de usuario habilitado para aprobar
transacciones.
REQ 5-33 Rol interventor de transacciones
El sistema contemplará la definición de un rol de usuario habilitado para intervenir
transacciones presupuestarias.
REQ 5-34 Reversión de transacciones
En todos los casos los roles deberán tener privilegios asociados a la reversión de
transacciones, las cuales deben estar asociadas a su rol original. Es decir el rol generador
podrá solo generar reversiones, mientras que será el rol aprobador quien cuenta con los
privilegios necesarios para aprobar la reversión.
5.2.2.3 Evaluación
La adecuada integración de la evaluación al ciclo presupuestario es clave para una adecuada
gestión del presupuesto público. No contar con una fase de evaluación que retroalimente al
ciclo presupuestario genera habitualmente la presencia de presupuestos inerciales, donde la
formulación y ejecución presupuestaria no consideran la información de los ejercicios
anteriores.
REQ 5-35 Orientación a programas y objetivos estratégicos
El sub-módulo de evaluación deberá apoyar a la gestión orientada a objetivos estratégicos e
indicadores asociados a los distintos programas presupuestarios (que en algunos casos
pueden ser transversales a varios incisos). La información sobre gestión estratégica a
considerar por el módulo de evaluación es la definida en el Sistema de Planificación
Estratégica y Evaluación (SPE).
REQ 5-36 Elementos comunes entre la ejecución y la evaluación
El clasificador de programas presupuestarios deberá ser de uso y mantención común a
ambos sub-módulos de manera que la evaluación en base a estos criterios a partir de la
información de ejecución pueda realizarse de forma transparente.
Modelo Conceptual del SIIF2 01/04/2014 97/203
REQ 5-37 Ejecución como fuente de información financiera para la evaluación
El sub-módulo de ejecución presupuestaria será la principal fuente de información financiera
para la realización de la evaluación presupuestaria. Ello no descarta planteamientos a futuro
donde también se tenga en cuenta información contable en una orientación a evaluación en
base a costos y no sólo a gastos.
5.2.3 Integración
En el presente apartado se describe la integración entre el módulo de presupuesto y el resto
de módulos principales del sistema. La descripción de la integración se focaliza en el sub-
módulo de ejecución presupuestaria.
5.2.3.1 Presupuesto y contabilidad
La integración entre presupuesto y contabilidad se describe de forma exhaustiva en el
apartado correspondiente al módulo contable del presente documento. Todos los
antecedentes allí descritos deberán ser tenidos en cuenta de forma holística en la
implementación de la integración de ambos módulos. En este apartado solo se indican
requisitos funcionales generales de esta integración.
REQ 5-38 Generación automática de asientos contables a partir del registro del
devengado
La generación de una transacción en el momento del devengado gatilla de forma automática,
y en base a la matriz de equivalencia del clasificador por objeto del gasto y del plan de
cuentas contable, el asiento contable correspondiente en estado generado.
REQ 5-39 Aprobación del asiento contable
El asiento contable estado generado deberá ser aprobado por un rol aprobador contable que
verificará la propuesta automática del sistema teniendo la oportunidad, si procede, de
corregir el asiento contable propuesto por uno más adecuado.
5.2.3.2 Presupuesto y tesorería
REQ 5-40 Actualización del plan de caja a partir de las obligaciones intervenidas
El sistema actualizará el plan de caja propuesto en el módulo de tesorería de manera acorde
a los montos y fechas de las obligaciones intervenidas.
REQ 5-41 Generación de transacciones de pago presupuestario a partir del pago de
tesorería
La ejecución de pagos de tesorería generará en el módulo presupuestario la transacción de
pago presupuestario equivalente asociada a la transacción correspondiente con el fin de
contar con la información de ejecución presupuestaria al nivel de pagado con la
desagregación del clasificador presupuestario.
5.2.3.3 Presupuesto y gestión de la deuda
REQ 5-42 Generación de fuentes de financiamiento a partir de la emisión de deuda
Las transacciones de emisión de deuda originada para la captación de recursos generarán el
conjunto de transacciones de los correspondientes ingresos presupuestarios. Se realizará
Modelo Conceptual del SIIF2 01/04/2014 98/203
una ejecución simultánea de devengo y percibido asociado al monto y características de la
emisión realizada.
REQ 5-43 Generación de transacciones presupuestarias de gasto a partir del servicio
de la deuda
Al inicio de ejercicio y en base al inventario de instrumentos de deuda registrados por el
Banco Central del Uruguay (BCU) o por la Unidad de Gestión de Deuda del MEF se
registrarán las afectaciones y compromisos asociadas al servicio de la misma. El sistema
permitirá registrar sus devengamientos, las obligaciones y pagos asociados a la misma a
medida que dichos eventos económicos se produzcan, ya sea mediante interoperabilidad o
captura directa de datos.
5.3 Módulo contable
En el Sector Público, la contabilidad – denominada gubernamental – requiere de la definición
de criterios técnicos específicos concordantes con los fines propios de las instituciones
públicas, al tiempo que demanda una práctica armónica e integrada con distintos procesos
de administración y producción de información. En ese sentido, debe asegurarse una
coherencia relacional y permanente integración de la contabilidad con los aspectos de índole
presupuestaria, de caja, de la recaudación, de administración de la deuda pública, de
compras, de bienes y, en general, con todo proceso de las instituciones públicas que
implique, directa o indirectamente, variaciones o explicación de variaciones en la situación
económico-financiera del ente.
El rol de la contabilidad gubernamental en este nuevo milenio ha cambiado, ha crecido y,
conceptualmente, se ha jerarquizado producto del nuevo enfoque dado a la Administración
Financiera donde, entre otros aspectos, la Contabilidad Gubernamental es el sistema
integrador de toda la información sobre transacciones y flujos no transaccionales que hacen a
la gestión administrativo-financiera del Estado.
Por lo expuesto el Módulo Contable, se concibe como: el conjunto de principios, normas,
organismos, y procedimientos técnicos utilizados para registrar, valuar, procesar, exponer e
informar sobre las transacciones producidas por los ejecutores del gasto e ingreso público y
los hechos económicos que afecten o puedan llegar a afectar el patrimonio público.
Concordantemente, el TOCAF (artículo 93) establece que “el sistema de contabilidad
gubernamental comprende el conjunto de principios, órganos, normas y procedimientos
técnicos utilizados para recopilar, valuar, procesar y exponer los hechos económicos y
financieros que puedan tener efectos en la Hacienda Pública”.
De esta forma, el Módulo Contable, así concebido, habrá de producir información oportuna,
objetiva y confiable para la toma de decisiones y para terceros, por cuyo motivo cobra vital
relevancia en la Administración Pública, tanto a los fines de la gestión como de la rendición
anual de cuentas. Es en ese sentido, que el procesamiento contable, desarrollado sobre la
base de un marco funcional sustentado en normas contables confiables está en condiciones
de garantizar la transparencia en la producción de información pública y, por ende, en la
gestión de gobierno.
Modelo Conceptual del SIIF2 01/04/2014 99/203
El Módulo Contable a diseñarse, responderá a las siguientes características generales:
La base de registro de los gastos e ingresos será sobre base devengada o
acumulativa. En una primera etapa, en el caso de los recursos serán registrados
sobre base caja, para ir paulatinamente adoptando la base devengada para el
registro de los mismos,
Permitirá el registro y la fiscalización de los activos, pasivos, ingresos, gastos, como
así también los costos.
Las transacciones se registrarán una sola vez y, a partir de dicho registro único, se
deberán obtener todas las salidas de información que se requieran (contables,
presupuestarias, tesorería) ya sea a nivel central o periférico,
Será común, único, uniforme y aplicable a todo el Sector Público Uruguayo No
Empresarial.
Integrará los registros presupuestarios con los contables,
Alimentará las Cuentas Nacionales y la información solicitada por Organismos
Internacionales, como por ejemplo la información requerida por el Manual de
Estadísticas de Finanzas Públicas del FMI,
Expondrá, en tiempo real, la ejecución presupuestaria, los movimientos y situación
de los fondos y las variaciones, composición y situación del patrimonio de las
instituciones públicas,
Estará basado en Normas Internacionales de Contabilidad para el Sector Público
emitidas por la Federación Internacional de Contadores IFAC.
5.3.1 Objetivos
El Módulo Contable tiene como objetivo principal “Producir, en tiempo y forma los Estados
Financieros (EEFF) necesarios para mostrar los resultados de la gestión presupuestaria y
económica, así como la situación patrimonial de las organizaciones públicas, a efectos de
que la misma permita la toma de decisiones y fundamentalmente producir la Rendición de
Cuentas del Gobierno Uruguayo dentro de un marco de absoluta transparencia”.
A modo de complemento, el objetivo principal del Módulo Contable, cuenta con objetivos
específicos tales como:
Ser el núcleo integrador del SIIF2,
Registrar sistemáticamente todas las transacciones que se produzcan y afecten o
puedan afectar el Patrimonio de entidades del Estado Uruguayo,
Procesar y producir información financiera para la toma de decisiones por los
responsables de la gestión financiera pública y para los terceros interesados en la
misma,
Presentar la información contable necesaria para facilitar las tareas de control, sean
éstas internas o externas,
Estar orientado a la obtención de costos de las actividades del Sector Público;
Permitir que la información que se procese y produzca sobre el Sector Público
Uruguayo se integre al Sistema de Cuentas Nacionales,
Llevar la contabilidad centralizada dentro del siguiente ámbito de cobertura:
Administración Central (Incisos 02 al 15, 20 al 24 y 30), los Organismos del Articulo
220 de la Constitución (Poder Judicial, Tribunal de Cuentas, Corte Electoral, Tribunal
de lo Contencioso Administrativo, ANEP, UDELAR INAU, ASSE, UTEC) y Poder
Legislativo,
Modelo Conceptual del SIIF2 01/04/2014 100/203
Permitir obtener la información Consolidada del Sector Público Uruguayo, bajo el
siguiente esquema:
o La base para consolidar los EEFF serán los EEFF del Subsector Gobierno
Central,
o Consolidará los EEFF32
emitidos por los Servicios Descentralizados del
dominio industrial y comercial individualmente; (ANTEL, Administración
Nacional de Puertos, Administración Nacional de Correos, OSE y ANV),
como así también los EEFF del Sector Gobiernos Departamentales,
o Consolidará los EEFF33
de los Entes Autónomos del dominio industrial,
comercial y financiero; (Banco Central de Uruguay, Banco de la República
Oriental del Uruguay, Instituto Nacional de Colonización, Banco de Previsión
Social, ANCAP, UTE, AFE, Pluna, BSE y BHU).
El cumplimiento de los objetivos expuestos quedará a cargo de la Contaduría General de la
Nación como órgano responsable de la contabilidad gubernamental para el Sector Público
Uruguayo y como administrador del SIIF2.
5.3.2 Requisitos
A efectos de desarrollar el Módulo Contable será necesario tener en cuenta una serie de
requisitos que son fundamentales para lograr el éxito del mismo. Dentro de los requisitos a
contemplar se deberán considerar como mínimo los siguientes:
Marco NormativoContable,
Principales Ingresos al Módulo Contable
Principales Salidas del Módulo Contable
Es necesario aclarar que parte de estos requisitos pueden ser cubiertos por el desarrollo de
un sistema de información, como sería el caso del SIIF2, mientras que en otros casos
corresponde a desarrollos de tipo normativo. Con el fin de brindar una visión comprehensiva
de los puntos que deben considerarse para el Módulo Contable, en este documento se
desarrollan a alto nivel los tres tipos de requisitos, profundizando y señalando en forma
explícita aquellos que corresponden al desarrollo del sistema de información.
5.3.2.1 Marco Normativo Contable
El Módulo Contable debe estar sustentado en un marco normativo contable que otorgue
confiabilidad al mismo, por lo cual necesita una serie de manuales funcionales, que se
complementan con los requeridos en la Sección 4. Integración del Sistema, (diseño de los
clasificadores presupuestarios integrados con el plan de cuentas contable y el desarrollo de
la matriz de conversión presupuesto/contabilidad), del presente Informe, que deberán estar
diseñados previamente al desarrollo tecnológico, a saber:
32
NICSP N° 6: “Estados Consolidados y Separados”. 33
NICSP N° 22: “Revelación de Información Financiera sobre el Sector Gobierno General”.
Modelo Conceptual del SIIF2 01/04/2014 101/203
Ilustración 5-2 Marco Normativo Contable
La Contabilidad Gubernamental moderna a nivel internacional no sólo requiere un Módulo
Contable para su funcionamiento sino también un cuerpo normativo que lo sustente. Las
modernas corrientes contables dejan de lado aquellos tradicionales “Principios de
Contabilidad Generalmente Aceptados” para incluirlos en un marco aún mayor, el cual es
posible denominar como Marco Conceptual Contable (MCC) constituyendo este marco la
guía general para una buena implementación de la Contabilidad Gubernamental.
El MCC actúa, entonces, como guía y regulador normativo que posibilita superar la
dispersión existente en materia de exposición y contenidos de la información financiera, tanto
del Gobierno Central como de los Gobiernos Departamentales, dada la variedad de
circunstancias sociales, económico-financieras y jurídicas del país.
En tal sentido, se requiere que el Módulo Contable cuente con un Marco Conceptual
Contable que se desarrolle sobre la base de la normativa nacional relacionada con la
contabilidad, de los contenidos conceptuales de las Normas Internacionales de Contabilidad
del Sector Público (NICSP) emitidas por el Consejo de Normas Internacionales de
Contabilidad del Sector Público (IPSASB por su sigla en inglés), de la Federación
Internacional de Contadores (IFAC por su sigla en inglés) como así también considerar los
conceptos definidos por el Consejo de Normas Internacionales de Contabilidad (IASB por su
sigla en inglés).
El MCC debe definir cuáles serán los EEFF a producir desde el Módulo Contable (salidas del
sistema), que como mínimo deberá contemplar los estados señalados en el Requisito
indicado a continuación.
Modelo Conceptual del SIIF2 01/04/2014 102/203
REQ 5-44 Estados Financieros (EEFF) a producir
Estados Financieros mínimos a producir por el SIIF2:
Estados Principales:
o Estado de Situación Financiera (ESF),
o Estado de Rendimiento Financiero (ERF),
o Estado de Cambios en el Patrimonio (ECP),
o Estado de Flujos de Efectivo (EFE),
o Estado de Ejecución Presupuestaria de Gastos (EEPG),
o Estado de Ejecución Presupuestaria de Recursos (EEPR),
o Notas a los Estados Financieros (Notas)
Estados Complementarios:
o Compatibilidad Presupuesto / Contabilidad (CP/C)
o Estado de la Deuda Pública (EDP),
o Estado de Activos (EA),
o Cuenta Ahorro / Inversión / Financiamiento (AIF),
o Estadísticas de las Finanzas Públicas (EFP).
o Estados Financieros Consolidados (EEFFC):
o Estados Financieros Consolidados de Sector Público Uruguayo,
o Estado de Ejecución Presupuestaria de Gastos Consolidados (EEPGC),
o Estado de Ejecución Presupuestaria de Recursos Consolidados (EEPRC).
o Estados de Segmento
o Balancetes Mensuales
5.3.2.1.1 Desarrollo de manuales de contabilidad
A su vez, como parte del desarrollo de un marco normativo contable general, resulta
necesario elaborar un conjunto de manuales contables que sirvan como guía para la
aplicación de los principios contables definidos.
Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector
Gobierno General
El presente Manual partirá con la definición del MCC y que será la base sobre las que se
sustentarán la Políticas Contables Generales y tomando como referencia las normas
nacionales y las NICSP relacionadas con contabilidad se deberá desarrollar el Manual de
Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno
General (MCG y PCG), que tendrá como objetivo ser guía de aplicación en la materia para
todo el sector público no financiero y no empresarial, y en especial para el módulo contable .
Si bien las normas nacionales y las NICSP serán la referencia para la formulación del
presente Manual, también deberá considerarse el Manual de Estadísticas de Finanzas
Públicas 2001 del Fondo Monetario Internacional (FMI). En el supuesto caso de no contar
con normativa contable que trate un problema específico, se recurrirá a las Normas
Internacionales de Contabilidad (NIC) / Normas Internacionales de Información Financiera
(NIIF). Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma
separada. A fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye
como un requisito que debe elaborarse en el marco del desarrollo del SIIF2. El presente
Manual, dado que es funcional, debe desarrollarse previamente al desarrollo informático.
Modelo Conceptual del SIIF2 01/04/2014 103/203
REQ 5-45 Manual de Contabilidad Gubernamental y Políticas Contables Generales
para todo el Sector Gobierno General
El manual deberá desarrollar los siguientes contenidos:
a) Modelo Conceptual Contable
b) Contener las Políticas Contables Generales, a aplicar en las transacciones
gubernamentales, considerando:
reconocimiento,
medición,
exposición.
c) Estructurarse siguiendo el ordenamiento de los componentes de los EEFF a saber:
Activo,
Pasivo,
Patrimonio,
Gastos,
Ingresos, y
Presentación de EEFF.
d) Definir en detalle las estructuras y contenidos de los EEFF.
Manual de Normas Contables Particulares de Contabilidad y Procedimientos Contables
Toda organización necesita contar con manuales de los procedimientos a ser aplicados en
sus circuitos administrativo-financieros, por cuya razón dichos documentos deben estar
sustentados en el Manual de Contabilidad Gubernamental y Políticas Contables Generales
para todo el Sector Gobierno General. Los procedimientos deben ser desarrollados tomando
en cuenta las mejores prácticas contables - administrativas que permitan la integración del
sistema de administraciones financieras consolidadas con las Normas Contables.
Contar con manuales de procedimientos es un componente íntimamente vinculado al sistema
de control interno. Dichos manuales se elaboran para obtener una información detallada,
ordenada, sistemática e integral que contenga todas las instrucciones, responsabilidades e
información sobre políticas, funciones, sistemas y procedimientos de las distintas
operaciones o actividades que se realizan en una organización.
Definir los procedimientos contables implica formar los pilares para poder desarrollar
adecuadamente las actividades inherentes a la contabilidad gubernamental, estableciendo
las correspondientes responsabilidades para los encargados de todas las áreas y sub-áreas,
generando información útil y necesaria, estableciendo medidas de seguridad, control y
autocontrol y objetivos que participen en el cumplimiento de la función financiera, partiendo
del relevamiento de los procedimientos actuales, los cuales serán el punto de partida y el
principal soporte para llevar a cabo los cambios que se requieren para alcanzar y ratificar la
eficiencia, efectividad, eficacia y economía en todos los procesos.
Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A
fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un
requisito que debe elaborarse en el marco del desarrollo del SIIF2. El presente Manual debe
desarrollarse en forma concomitante al desarrollo informático del SIIF2.
Modelo Conceptual del SIIF2 01/04/2014 104/203
REQ 5-46 Manual de Normas Particulares de Contabilidad y Procedimientos Contables
El Manual se deberá estructurar conteniendo como mínimo los siguientes elementos:
a) Ingresos:
de transacciones sin contraprestación34
; y
de transacciones con contraprestación35
.
b) Gastos no financieros.
c) Operaciones financieras y movimiento de fondos:
de Deuda Pública;
de Tesorería y administración de fondos;
desembolsos de préstamos y
Otras operaciones financieras.
d) Bienes del Estado.
Almacenes (Inventarios);
Bienes de Uso (Propiedades, planta y equipo);
Propiedades de inversión;
Activos biológicos; y
Activos intangibles.
e) Normas particulares de revelación contable (agrupamiento y exposición).
5.3.2.1.2 Gestión de Almacenes y Bienes
El Módulo Contable contemplará en su desarrollo dos sub-módulos adicionales: (i)
almacenes y (ii) Bienes (Activo fijos y Otros). Dada la importancia de los sub-módulos resulta
necesario elaborar el Manual de Activos, donde se determinarán funcionalmente los criterios
y procedimientos de registro de los bienes a fin de posibilitar su custodia y mantener un
adecuado sistema de información y control sobre su utilización y estado de mantenimiento.
Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A
fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un
requisito que debe elaborarse en el marco del desarrollo del SIIF2
REQ 5-47 Manual de activos
El Manual de Activos debe cumplir con lo requerido en el Manual de Contabilidad
Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General” y
comprenderá su normas contables particulares así como los procedimientos a cumplir para
las: altas de bienes (por adquisición, arrendamiento financiero, construcción, donación o por
otro título), bajas de bienes (transferencias, ventas, reasignación, deterioros físicos y legales,
34
NICSP N° 23: “Ingresos de transacciones sin contraprestación (impuestos y transferencias)”:
establece: son aquellos que provienen del uso de los poderes soberanos, de subvenciones y de
donaciones.
35 NICSP N° 9: “Ingresos de transacciones con contraprestación”: establece que son aquéllos por los
que la entidad recibe activos o servicios y le asigna directamente un valor aproximadamente igual al
que la otra parte intercambia.
Modelo Conceptual del SIIF2 01/04/2014 105/203
declaraciones de bienes en desuso y otras) y modificaciones (cualquier cambio en los bienes
que incrementen o disminuyan su valor). También deberá incluir las políticas de toma de
inventarios, el tratamiento de las amortizaciones / depreciaciones, deterioros y revalúo si los
hubiera.
5.3.2.1.3 Consolidación de la Información Financiera
Es de destacar que la consolidación de la información financiera del país es el último eslabón
de una cadena de normas, procesos y procedimientos previos, tanto presupuestarios como
contables y, como tal, es el que recibe el impacto positivo o negativo de los eslabones
anteriores (normas, procesos, procedimientos), por cuyo motivo debería ser realizado al final
del ciclo de administración financiera.
El enfoque internacional dado a la consolidación de la información financiera surge de las
NICSP como así también de lo establecido en el MEFP/ 2001 del FMI y el enfoque nacional
sustentado en el marco legal vigente en el país. Para la normativa internacional, la
información consolidada del Sector Público permite cumplimentar el objetivo principal de
tener a dicho sector como una sola entidad económica o entidad informante.
Por lo expuesto, el hecho de disponer de las “normas y procedimientos de consolidación”
será necesario, fundamentalmente, para los funcionarios de la CGN la cual, como “Unidad de
Consolidación Principal”, cuente con una guía para hacer oportuno, eficaz y eficiente el
proceso de consolidación de la información financiera del Sector Público Uruguayo.
El proceso de consolidación contable en el Sector Público está orientado, básicamente, a
estructurar la información en una forma lógica y razonable, que permitirá su revelación y
análisis como una sola unidad (entidad económica), sin perjuicio de la revelación y análisis
sectorial e institucional.
Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A
fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un
requisito que debe elaborarse en el marco del desarrollo del SIIF2. El presente Manual debe
desarrollarse en forma concomitante al desarrollo informático del SIIF2.
REQ 5-48 Manual de Consolidación de la Información Financiera
El Manual de consolidación deberá contener, como mínimo, lo siguiente:
a) La Estructura de consolidación del Sector Público Uruguayo, sustentada en el
Manual de Estadísticas de Finanzas Públicas del FMI y armonizada con lo requerido
en el REQ 4-6 Estructura desde las Finanzas Públicas.
b) Definir, en función del Marco Conceptual Contable (MCC) y de los requerimientos
nacionales los EEFFC, que como mínimo deberá contemplar:
Estado de Situación Financiera Consolidado (ESFC),
Estado de Rendimiento Financiero Consolidado (ERFC),
Estado de Flujos de Efectivo Consolidado (EFEC),
Estado de Ejecución del Presupuesto de Ingresos por Origen Consolidado
(EEPGC),
Estado de Ejecución del Presupuesto de Gastos por Objeto Consolidado
(EEPRC),
Cuenta Ahorro – Inversión – Financiamiento Consolidado (AIFC), y
Notas a los EEFFC.
Modelo Conceptual del SIIF2 01/04/2014 106/203
c) Establecer la Metodología de Consolidación que como mínimo deberá contemplar:
Los Métodos de Consolidación a considerar, de acuerdo al tipo de entidad;
Definir las operaciones por cada transacción presupuestaria / contable en:
o Internas,
o Intrasectoriales36
,
o Intersectoriales37
.
Determinar las etapas del proceso de consolidación, que como mínimo deberá
contener:
o Homogeneización,
o Conciliación entre entidades,
o Ajustes,
o Agregaciones,
o Eliminaciones
5.3.2.1.4 Matriz de conversión presupuesto contabilidad
Los desarrollos de los manuales requeridos en los puntos anteriores impactarán en el
funcionamiento de la Matriz de Conversión Presupuesto /Contabilidad (MCP/C), pero es
importante definir su funcionamiento en forma previa a su desarrollo informático y funcional,
que será la base para el proceso de conversión.
La matriz deberá exponer todos los asientos que surgen de las transacciones
presupuestarias y no presupuestarias y, con dicha base, se producirán, por agregación de la
información previamente almacenada, los diferentes tipos de estados financieros y
presupuestarios que se le requieren a la contabilidad gubernamental, el presupuesto, la
tesorería y deuda pública.
Cabe destacar que la referida matriz constituye en sí misma el nexo conductor que garantiza
que las transacciones se registren una sola vez en el sistema y que, por conversión a través
de la propia matriz al lenguaje de diferentes clasificadores, pueda explotarse la información
desde distintas ópticas.
Si bien el porcentaje mayor de transacciones se originan en el presupuesto, la matriz deberá
contemplar el ingreso de los datos de aquellas transacciones que tienen impacto contable no
presupuestario, por lo cual las unidades ejecutoras deberán poder hacer dichos registros
desde el lugar más próximo a la transacción, más allá de las transacción que estén
restringidas sólo a la CGN (Unidad Rectora Contabilidad). La matriz deberá contar con un
Manual funcional y deberá desarrollarse en forma conjunta con el desarrollo del SIIF2.
La matriz debe tener en cuenta el momento del conciliado en el Banco para generar las
disponibilidades financieras de la administración de cada Ministerio.
REQ 5-49 Manual funcional de la Matriz de Conversión Presupuesto /Contabilidad
36
Real Academia Española: intra: Significa 'dentro de', 'en el interior'. 37
Real Academia Española: inter: Significa. 'entre' o 'en medio'.
Modelo Conceptual del SIIF2 01/04/2014 107/203
El Manual funcional de la matriz de conversión, se sustentará fundamentalmente en el
Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector
Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos
Contables y deberá cumplir y contener, como mínimo los siguientes datos y premisas:
a) generará los asientos (partida doble) en el Módulo Contable en forma simultánea al
registro de la ejecución presupuestaria, en los momentos de devengado, mandado a
pagar y pagado para los gastos y , devengado y recaudado para los recursos,
b) integrará los clasificadores presupuestarios (recursos y gastos) con el plan de
cuentas contable, estableciendo el nivel de integración tanto para los recursos como
para los gastos,
c) incluirá todas las transacciones posibles que se puedan realizar en el Sector Público
Uruguayo,
d) permitirá generar la salida requerida para formular los EEFF,
el Libro Diario,
el Libro Mayor,
los Mayores Auxiliares necesarios, que en principio pueden corresponder a cada
tipo de operación, como por ejemplo:
o Mayor auxiliar por – Organismo
o Mayor auxiliar por – Recurso
o Mayor auxiliar por – Objeto del Gasto
o Mayor auxiliar por – Fuente de Financiamiento
o Mayor auxiliar por – Acreedor – Deudor - Beneficiario
o Mayor auxiliar por – Cuenta Bancaria, o
o Mayores auxiliares combinados.
5.3.2.2 Principales Ingresos al Módulo de Contabilidad
Tal como se ha manifestado en el presente Informe, el Módulo Contable tendrá la función de
núcleo integrador del SIIF2, por lo cual cuando las transacciones se devengan impactarán
directamente en dicho módulo, a efectos de garantizar que el mismo pueda producir la
información económica-financiera del Sector Público Uruguayo.
Cumpliendo con las Políticas Contables, el Módulo Contable deberá iniciar sus operaciones
con el registro de asientos de apertura de la gestión e ir intercalando actos presupuestarios,
financieros y económicos para terminar con la producción de los EEFF.
A efectos del presente Marco Conceptual, seguidamente se exponen por separado los
ingresos al Módulo Contable, dentro de cada uno de los cuales se desarrollará las
características principales del ingreso y las condiciones que deben cumplir. Los mismos se
ordenan de la siguiente forma:
1. ingresos de los módulos (principales o secundarios) integrantes del SIIF2,
2. ingresos de los sub-módulos contables,
3. ingresos de información provenientes de otras áreas.
Modelo Conceptual del SIIF2 01/04/2014 108/203
Ilustración 5-3 Principales Ingresos al Módulo Contable
5.3.2.2.1 Ingresos de los módulos (principales y secundarios) integrantes del SIIF2
El SIIF2 deberá considerar los siguientes ingresos de información, tanto de los módulos
principales como desde los módulos secundarios que lo componen.
REQ 5-50 Ingreso del Módulo de Presupuesto
Al inicio del año y luego de haber realizado en forma automática los asientos de apertura, el
Módulo Contable, debe tener como primer ingreso el realizado por la Unidad Rectora
Presupuesto que deberá comprender y cumplir con los siguientes momentos de registro:
Ingreso al Sistema desde el Módulo de
Presupuesto Momento de Registro
a) Distribución de los créditos aprobados, incluyendo sus
ajustes al inicio del ejercicio
Aprobado
b) Estimación de los Recursos Aprobado
c) Programación de los compromisos anuales aprobados Planificación de
Compromisos
d) Ajustes, realizados a lo largo del año, a los saldos
aprobados originalmente
Modificado/Ajustes a
Apertura
Es de aclarar que ninguno de los momentos ingresados en estas etapas tienen impacto
contable, pero será necesario ingresarlos al módulo por dos razones fundamentales, (i) para
que las Unidades Ejecutoras puedan afectar los saldos a medida que los ejecutan, ya que si
no cuentan con dichos saldos no podrán ejecutar sus presupuestos y deberán pedir
modificaciones al mismo, y (ii) para producir la información presupuestaria requerida al
módulo de contabilidad.
Más allá de la relación directa de la Unidad Rectora Presupuesto, a lo largo del año, también
se relacionan con el Módulo Contable las Unidades Ejecutoras a través de dos formas:
Modelo Conceptual del SIIF2 01/04/2014 109/203
a) a través del Módulo de Presupuesto :
comprometerán los gastos, el módulo verificará que exista saldo disponible de
crédito presupuestario y reservará el crédito.
ejecutarán sus gastos, al momento del devengado, afectando los créditos
presupuestarios que en forma automática obtendrán (a través de la MCP/C) los
correspondientes asientos contables generando una obligación de pago
inmediata por la recepción de bienes y servicios o por haberse cumplido los
requisitos administrativos dispuestos para los casos de gastos sin
contraprestación. Es en este momento donde nace el registro contable y donde
el presupuesto y la contabilidad se unen mientras que, por su lado, el sistema
verificará que exista registro previo del compromiso, confirmará la ejecución del
presupuesto y permitirá contar con información actualizada del nivel de deuda
exigible al comparar este monto con el monto de los pagos efectuados; se debe
prever que en la última etapa de la ejecución presupuestal puedan identificarse
diferentes tipos de ejecución (por ejemplo regularizaciones de anticipos,
certificados, deuda pública, ejecución fuera de la CUN, etc.)
mandarán a pagar considerando los momentos de Obligado Intervenido y
Obligado Priorizado respecto a cada Orden de Pago, ya intervenida por el
Tribunal de Cuentas a la Tesorería.
La Tesorería es quien realizará el pago directo al beneficiario final, emitiendo el
cheque o transfiriendo los fondos el gasto se dará por pagado en el sistema,
disminuyendo el saldo de la obligación contraída.
podrán realizar registros agrupando momentos en los siguientes casos:
o Compromiso y devengado simultáneos: registra la ejecución presupuestaria
en ambas etapas al mismo tiempo, debido a que existen operaciones de las
que se toma conocimiento cuando se reciben (Ejemplo: servicios básicos
como luz, agua, teléfono, etc.).
o Compromiso, devengado y pago simultáneos: registra la ejecución
presupuestaria en las tres etapas al mismo tiempo; debido a que existen
operaciones (Ejemplo: comisiones bancarias) de las que se toma
conocimiento cuando se recibe la información del débito bancario realizado
sin que se cuente con registro previo del compromiso y ni del devengado.
b) a través del Módulo Contable :
Si bien la CGN es la administradora de la MCP/C y es dicha institución la única
facultada para modificarla, el Módulo Contable deberá permitir el ingreso a los
registros contables a las Unidades Ejecutoras, limitándola solamente a su unidad, a
efectos de poder registrar aquellas operaciones que no tienen impacto
presupuestario (por ejemplo: amortizaciones, depreciaciones y revaluaciones de
bienes) y para realizar los ajustes que la CGN le puede llegar a solicitar al cierre del
ejercicio, a través de la confección de minutas contables. Dicho diseño está
sustentado en que son las Unidades Ejecutoras las responsables de sus registros y
la CGN no deberá asumir roles de registro que no le corresponden.
REQ 5-51 Ingreso del Módulo de Tesorería
El Módulo de Tesorería deberá contar con los procedimientos y funcionalidades destinadas a
la registración de los ingresos por parte de las Unidades Ejecutoras responsables de su
gestión, en especial a través de la DGI y la DNA. En el caso de los ingresos provenientes de
Modelo Conceptual del SIIF2 01/04/2014 110/203
Dirección Nacional de Lotería y Quinielas y Dirección General de Casinos corresponde
incorporarlos directamente al Módulo de Tesorería, quedando el registro a cargo de las
Unidades Ejecutoras de Lotería y Casinos, como el registro de los recursos propios de los
distintos organismos que componen el Subsector Gobierno Central, como se indica en el
punto 5.4 Módulo tesorería.
Los momentos de registros aplicados para los recursos, en una primera etapa serán por lo
percibido para ir paulatinamente incorporando el devengado de los mismos. A efectos de ir
pasando a dicho momento, se deberá tener presente lo siguiente38
:
Clasificación Tipo de ingreso Momento del Devengado
Ingresos con
Contraprestación
Prestación de servicios Por el grado de terminación
de la prestación (% de
terminación).
Venta de bienes Con la entrega de los
bienes
Ingresos por Alquileres De forma lineal a lo largo
del plazo del alquiler
Intereses Por el trascurso del tiempo
Ingresos sin
Contraprestación
Impuestos Cuando se genera el “hecho
imponible”(a)
Transferencias (subsidios) Cuando se perciben, por lo
cual los momentos de
percibido y devengado son
simultáneos (b)
Donaciones y legados
realizadas por terceros a la
entidad
Con la recepción de la
donación o legado
Venta de bienes, si la
transacción conlleva un precio
subvencionado
Con la recepción del bien
Contribuciones sociales Cuando se perciben, por lo
cual percibido y devengado
son simultáneos.
38
NICSP N° 9: “Ingresos de transacciones con contraprestación” y NICSP N° 23: “Ingresos de
transacciones sin contraprestación”.
Modelo Conceptual del SIIF2 01/04/2014 111/203
a) Generación del “hecho imponible”:
Si bien el hecho imponible, dependerá de cada impuesto y tasa, según lo establezca
el Código Tributario Uruguayo, en líneas generales se puede decir que el momento
del devengado de los ingresos se tratará en el orden siguiente:
A. Un recurso por impuesto se reconocerá cuando ocurra el hecho imponible y se
cumplan los criterios de reconocimiento del activo, a saber:
o la entidad gubernamental controla los ingresos como consecuencia de un
suceso pasado (el hecho imponible);
o se espera recibir beneficios económicos futuros o potencial de servicio de
esos ingresos; y
o es probable que la entrada de ingresos pueda ser medida con fiabilidad39
en
el momento que se genera el hecho imponible.
B. Si no se puede medir fiablemente en el momento que se genera el hecho
imponible, deberá buscarse el momento donde se pueda medir fiablemente40
(presentación de la liquidación, sucesión aprobada, etc.).
C. Si los pasos A y B no son posibles, se podrán utilizar “estimaciones” sustentadas
en juicios profesionales que determinen el momento del devengado, o
D. Por último, y luego de haber recorrido previamente los pasos anteriores (A, B y
C) y no se cuente con estimaciones confiables y, por ende, no se llegue a
determinar un momento fiable, se tomará el momento del percibido en el que
prevalezca por fiabilidad del registro.
b) Transferencias (subsidios):
En este caso se debe aplicar un criterio de prudencia en el ingreso y reconocerlo
cuando el activo es ingresado efectivamente a la entidad, por más que se cuente con
disposiciones administrativas que lo autoricen, dado que puede ocurrir que se cuente
con la documentación legal y no con los fondos para realizarla, o sea desde el punto
de vista del ingreso será con la percepción del mismo.
El módulo de recursos ingresará al Módulo Contable la siguiente información:
a) si el ingreso es por lo percibido:
imputación de ingresos: Es el proceso mediante el cual los ingresos percibidos
se imputan a los distintos conceptos de recursos, actualizando la cuenta
corriente del contribuyente,
los saldos de cuentas por cobrar impositiva que tengan las entidades
recaudadoras,
39
Por ejemplo, el hecho imponible en el impuesto sucesorio es en el momento de la muerte del
contribuyente, pero en dicho momento no se puede medir fiablemente. 40
Siguiendo con el ejemplo anterior, recién se podrá medir fiablemente en el momento que el juez dicte
la sucesión.
Modelo Conceptual del SIIF2 01/04/2014 112/203
ingresos producto de la cancelación de la cuentas por cobrar de los
contribuyentes
las cancelaciones, realizadas por los contribuyentes, de sus obligaciones por
compensación de créditos,
créditos a los contribuyentes por pago a plazo diferido o en parcialidades;
moratorias impositivas;
cobros por de intereses, multas y otros cargos;
reducción o condonación de multas;
cancelación de créditos por prescripción o insolvencia del deudor;
devolución de impuestos a los contribuyentes: (i) del mismo ejercicio y (ii) de
ejercicios anteriores; los cuales se pueden realizar en efectivo o en certificados;
los deterioros de las cuentas por cobrar41
(incobrabilidad); y
los diferentes estados en que se encuentren las cuentas por cobrar (morosos, en
gestión judicial, si son a corto, o largo plazo, etc.).
b) si el registro se hace por lo devengado se generará dicha cuenta en forma
automática en el módulo de contabilidad, que se ajustará por los ingresos reales al
mismo. En ambos casos el Módulo Contable deberá cumplimentar lo requerido en el
Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el
Sector Gobierno General” y en el Manual de Normas Particulares de Contabilidad y
Procedimientos Contables, es decir ajustar el saldo de cuentas por cobrar DGI por
los correspondientes deterioros (posibles incobrabilidades).
La percepción de los recursos se produce cuando los fondos ingresan a la Cuenta Única que
administra la Tesorería, en cuyo momento el Módulo Contable captará el percibido del
recurso, que si se mantiene el registro por lo percibido será el momento de ingreso y
registrará la ejecución del presupuesto de ingresos en la etapa del percibido, generando en
forma simultánea el asiento de partida doble que corresponda. Si se hace sobre base
devengada el recurso ya ingresó al módulo y debió generar una cuenta por cobrar que se
verá disminuida por el ingreso percibido.
La Unidad Rectora de Tesorería deberá conciliar los medios de pago (liberados con los
operadores en banco) con la imputación de acuerdo al catálogo de ingresos por concepto de
los fondos percibidos, para generar las partidas conciliatorias de egresos pendientes del
saldo del banco.
Según lo definido en el presente documento, las unidades que realizan los registros deben
estar lo más próximas posibles al evento que genera la transacción, resultando aconsejable
que el registro lo realicen directamente la Unidad Ejecutoras, en especial en la DGI y DNA.
En el caso de los ingresos provenientes de Dirección Nacional de Loterías y Quinielas y
Dirección General de Casinos correspondería incorporarlos directamente al módulo contable,
quedando el registro a cargo de las Unidades Ejecutoras de Lotería y Casino, como
asimismo el tratamiento de los recursos propios de los distintos organismos que conforman el
Gobierno Central. En el caso que este proceso requiera un proceso gradual de
implementación, el módulo de contabilidad del SIIF2 deberá poder capturar los datos
necesarios para la registración contable de los ingresos mediante mecanismos de
41
NICSP N° 29: “Instrumentos Financieros – Reconocimiento y Medición”.
Modelo Conceptual del SIIF2 01/04/2014 113/203
interoperación adecuados desde los sistemas de origen las entidades recaudadoras o bien
permitir el registro en forma directa sobre el módulo de contabilidad del SIIF2.
REQ 5-52 Ingreso del Módulo de Deuda Pública
La experiencia de varios países muestra que existen tres enfoques alternativos para el
desarrollo del Módulo de Deuda Pública:
Integrar todas las operaciones directamente en el Módulo Contable. En este caso el
desarrollo del Módulo de Deuda Pública opera como un sub-módulo del Módulo
Contable.
Realizar un desarrollo informático propio para la administración de la deuda pública
el cual se integra con el resto del Sistema de Administración Financiera mediante
interoperabilidad.
Implementar el Sistema de Gestión y Administración de la Deuda (SIGADE)
desarrollado por la Conferencia de las Naciones Unidas sobre Comercio y Desarrollo
(UNCTAD) y desarrollar las interfases específicas para su integración al resto del
Sistema de Administración Financiera.
En el caso del Uruguay el administrador de la deuda pública es el Banco Central de Uruguay
y por ende es dicha entidad la que cuenta con el correspondiente sistema de administración,
por lo cual se recomienda que dicho sistema sea quien deberá proveer al Módulo Contable,
por medio de mecanismos de interoperabilidad entre sistemas información para el registro
contable de la deuda pública y la registración de ingresos por préstamos, la cual se detalla en
5.5 Módulo de Deuda.
REQ 5-53 Ingreso del Módulo de Tesorería
La interrelación entre el Módulo de Tesorería y el Módulo Contable se produce,
fundamentalmente, en el momento de la recaudación de los ingresos y de los pagos de las
obligaciones, es decir cuando se produce un flujo real de fondos, más una serie de
operaciones que hacen al rol de la Tesorería. Dichos procesos serán como mínimo los
siguientes:
Registro de los recursos
El registro de los recursos se produce con la conciliación bancaria o recaudación de los mismos.
Es diferente la percepción desde el punto de vista presupuestal que se produce en la etapa
del percibido, cuando el contribuyente cancela su obligación. Se pueden establecer
operativamente dos etapas:
cuando se recaudan efectivamente (el contribuyente canceló su obligación
depositando los fondos respectivos en alguno de los agentes financieros
autorizados); y
cuando se produce la percepción definitiva, con el ingreso de los fondos en la Cuenta
Única que administra la Tesorería.
Con la conciliación bancaria se realiza el registro contable de los ingresos a la Tesorería. De
acuerdo al TOCAF art.12, se registra el percibido en la caja recaudadora, aunque esté
pendiente de depósito en el banco; cuando llega el dinero al banco, se hace el descargo de
la caja recaudadora por los recursos acreditados. Posteriormente, en caso de corresponder,
se regularizaran los débitos/créditos que haya realizado el agente financiero por gastos,
comisiones, a través de la conciliación bancaria. Se consideran recursos percibidos a la
Modelo Conceptual del SIIF2 01/04/2014 114/203
recepción de efectivo en Caja, depósitos de fondos en Bancos o cobros mediante títulos o
valores legalmente determinados.
En el momento de la percepción en la Tesorería, se registrará, en el Módulo Contable la
ejecución del presupuesto de recursos en la etapa del percibido y generará en forma
simultánea el asiento de partida doble que corresponda.
Constitución de Garantías
El Módulo de Tesorería recibe por sí o a través de sus auxiliares las garantías y debe
registrar a tales efectos los siguientes momentos contables:
si es recibida en documentos será un registro en el auxiliar de Valores en Garantía
para informar al cierre del ejercicio al Módulo Contable ;
si es recibida en efectivo (o vía retención) la Tesorería registrará contablemente el
ingreso del dinero contra una cuenta por pagar a Fondos de Terceros en Garantía.
Registro de los pagos
El registro de los pagos representa la liquidación de obligaciones exigibles, y se realizará
mediante la entrega de efectivo, emisión de cheques, órdenes bancarias, transferencias a
cuentas bancarias o pagos por notas (pago de la deuda pública). El registro de esta etapa
permitirá conocer el grado de cumplimiento de compromisos contraídos como obligaciones,
saldos disponibles en bancos, cheques u órdenes bancarias emitidas, entregadas y pagadas.
La Tesorería, como Unidad Rectora Tesorería, será la responsable del registro en el SIIF2 en
el momento de la generación del medio de pago y el módulo verificará la existencia de
disponibilidad en el libro Caja o en el libro Banco; afectando la etapa del pagado, registrará el
débito en el libro Caja o Banco; y generará automáticamente el asiento de partida doble para
la imputación indicada en la Orden de Pago respectiva.
Los pagos son, en general, gestionados y realizados por la Tesorería a través de
procedimientos de priorización y confirmación de las operaciones destinadas a cancelar con
la emisión del medio de pago correspondiente. Seguidamente se identifica, como mínimo los
tipos de pagos que se deberá contemplar dentro del SIIF2 y cómo afectan los mismos al
Módulo Contable:
Pagos presupuestarios en general:
El ordenamiento del pago o ejercicio del presupuesto es realizado por las Unidades
Ejecutoras de las dependencias y entidades con el mandado a pagar de la emisión de la
Orden de Pago (OP) e intervenida, que se emite por el ejercicio de las asignaciones
presupuestarias vigentes. Estos documentos son remitidos a la Tesorería para su
cancelación y es ésta quien registra el momento de pagado con la emisión del medio de
pago (cheque o transferencia bancaria) y es entonces cuando dicho registro impacta
automáticamente en el pagado de los registros presupuestarios y disminuye el pasivo en
la contabilidad. Toda OP mandada a pagar por las entidades y no pagada por la
Tesorería, queda como una deuda pendiente de pago.
Pago de Sueldos:
Modelo Conceptual del SIIF2 01/04/2014 115/203
Las cuentas por pagar producto de las liquidaciones realizadas por las Unidades
Ejecutoras, deberán ser realizadas directamente a los empleados por la Tesorería
General de la Nación a través de la Cuenta Única mediante transferencias bancarias.
Estas cuentas quedarán pagadas con dicha transferencia, a cuyo efecto la TGN deberá
recibir junto con las liquidaciones las nóminas de empleados conformadas por la Unidad
Ejecutora.
Los pagos deben realizarse por transferencia bancaria, directamente a la cuenta del
empleado y sólo para casos excepcionales se podrán realizar pagos a través de la
emisión de cheques automáticos.
Pagos del Servicio de la Deuda, Intereses y Comisiones del servicio de la deuda:
Los pagos de la amortización de la Deuda Pública, los intereses y comisiones del servicio
de la misma, que tendrán como beneficiario a los prestamistas de créditos o los agentes
financieros que atiendan dicho servicio de los valores y títulos, lo realiza en su etapa final
el Banco Central de Uruguay de acuerdo al cronograma previsto y en función de la
delegación del MEF como agente financiero de la administración del crédito público.
Pagos de Fondos Rotatorios:
Los “Fondos Rotatorios” constituyen un anticipo de fondos con reposición periódica de la
Tesorería, que se autoriza expresamente a cada una de las dependencias para que
cubran compromisos de carácter urgente, derivados del ejercicio de sus funciones,
programas y presupuestos autorizados. Los Fondos Rotatorios regularmente se pagan
con la emisión de cheques a favor de las Unidades Ejecutoras.
Con la emisión del medio de pago la Tesorería registra un movimiento contable en el
SIIF2 de “anticipos de fondos”, quedando una deuda registrada en cabeza de la Unidad
Ejecutora hasta tanto la misma lo rinda afectando las partidas presupuestarias
autorizadas para realizar dichos gastos. Con la rendición del Fondo Rotatorio se practica
el registro final de la ejecución del presupuesto y el pago.
Otros pagos no presupuestarios:
Existen otras causales que originan pagos no presupuestarios tales como el
otorgamiento de “anticipos” o “pagos a cuenta” dicho tipo de transacciones se tratarán
igual que los Fondos Rotatorios, quedando registrado en el SIIF2 una deuda hasta tanto
se complete la operación y se pueda afectar las partidas presupuestarias
correspondientes. Dentro de estas operatoria podemos encontrar:
Devolución de Garantías:
Cuando se termina la obra/proyecto o en los casos que se proceda a sustituirla por un nuevo
documento la Tesorería procederá a la devolución de las Garantías de acuerdo a:
si la devolución es de un documento de debe dar de baja en el auxiliar de Valores en
Garantía y ajustará el informe al cierre del ejercicio en el Módulo de Contabilidad.
si la garantía fue en efectivo debe registrarse contablemente la salida de fondos
(pago) dando de baja la deuda contraída en su ingreso en Fondos de Terceros en
Garantía.
Conciliación Bancaria de los pagos
Modelo Conceptual del SIIF2 01/04/2014 116/203
La conciliación bancaria de los pagos consiste en la comparación entre los movimientos
financieros incluidos por el Banco y los estados de las cuentas bancarias oficiales y los
movimientos financieros generados por la Tesorería en los Libros Bancos de las respectivas
cuentas.
El proceso de Conciliación Bancaria es responsabilidad de la Tesorería; dicho organismo, a
través del Módulo de Tesorería, deberá contar con un sub-módulo de conciliación a efectos
de que permita comparar los movimientos de créditos y débitos de cada cuenta informados
en los extractos bancarios con los registros de ingresos y egresos del libro banco con el
objetivo de establecer en forma diaria el saldo disponible de la Tesorería por cada cuenta e
identificar el detalle de movimientos registrados en las mismas que aún no han llegado al
Banco o se encuentran en tránsito (depósitos, cheques, transferencias, etc.) y los
movimientos efectuados por el banco que no cuentan con registro en la TGN (débitos,
gastos, comisiones bancarias, etc.). Estas diferencias dispararán automáticamente los
correspondientes asientos de ajuste a los saldos.
Valores en custodia
La Tesorería tiene la custodia de los derechos patrimoniales de los valores que representan
las inversiones financieras del Gobierno Uruguayo. La custodia comprende la guarda,
conservación y registro clasificado de los valores y la percepción de los dividendos, utilidades
o remanentes. Si bien la custodia de valores no tiene impacto en el registro contable, en
cambio sí lo tienen sus movimientos, por lo cual la Tesorería llevará el registro auxiliar de
estos derechos, de acuerdo a su naturaleza, e informará al Módulo Contable al cierre del
ejercicio las existencia de los mismos, como así también su cotización, a efectos de que la
CGN registre a dicho cierre el valor actual de las inversiones.
Las operaciones que la Tesorería ingresará al SIIF2 serán:
Compra de las inversiones financieras, realizadas por la Tesorería;
Cualquier ingreso que las mismas produzcan (dividendos);
Inversiones Financieras liquidadas que podrán generar una pérdida o una ganancia,
según resulte de la liquidación.
El desarrollo de este requisito debe realizarse en forma combinada con los Requisitos
definidos en 5.4 Módulo Tesorería.
REQ 5-54 Ingreso del Módulo de Recursos Humanos
El gasto en personal es el gasto más significativo del presupuesto y el Módulo de Recursos
Humanos debe ingresar al Módulo Contable las siguientes operaciones:
Compromiso anual: al inicio del ejercicio se realiza una liquidación anual que es la
base para el registro de la etapa del compromiso para los gastos de servicios
personales. Esta liquidación se realizará sobre el personal ocupado al inicio del
ejercicio y sobre la base de su condición ocupacional.
Actualización del compromiso: por novedades en la administración de personal ya
sea producto de: (i) el ingreso, (ii) egresos y (iii) control de licencias, franquicias,
permisos, asistencia, horas extras, etc., entre otras, y podrán modificar el
compromiso anual cuando de ellas se deriven nuevas obligaciones de pago por los
Modelo Conceptual del SIIF2 01/04/2014 117/203
servicios personales prestados. Será necesario que las novedades cuenten con
asignación presupuestaria para su posterior liquidación.
Liquidación de sueldos o nómina: El proceso de liquidación de nóminas comprende
el cálculo de la percepción ordinaria y extraordinaria del funcionario público por los
servicios prestados en un período de tiempo, así como también la generación de los
correspondientes aportes que el empleado debe realizar a la seguridad social y
aquellos pagos que el empleador deberá cumplir en función de la normativa legal
establecida.
Para la definición de la retribución al trabajador, se conjugarán las escalas salariales, los
puestos laborales, los beneficios socioeconómicos y las compensaciones extraordinarias.
Se ingresan, en forma previa a cada liquidación, las novedades en los conceptos a liquidar a
cada uno de los agentes y posteriormente se procede a realizar la liquidación, en forma
individual.
Con la liquidación se emiten simultáneamente los recibos de haberes, el resumen de
imputaciones que es la base para el devengamiento del gasto y el mandado a pagar con la
emisión de la Orden de Pago, así como el listado de pagos por banco, originando
automáticamente los asientos contables respectivos.
Beneficio Pos-empleo42
: Puede existir alguna entidad o Unidad Ejecutora, que según
la normativa del país, esté comprometida a pagar beneficios a los empleados
después que termina la relación laboral, como ser:
Pago de regímenes de jubilaciones especiales aplicados sólo al personal de la
institución (por ejemplo Fuerzas Armadas);
Compromiso de pagos de una cantidad determinada de sueldos al término de la
relación laboral;
Compromisos de pago de asistencia médica hasta su fallecimiento;
Otros compromisos de pago futuro.
Dichas entidades deberán ingresar al Módulo Contable la deuda actuarial a valor presente
que generará esas obligaciones, en la medida que la entidad mantenga los riesgos de
hacerse cargo de los pagos futuros, como así también identificará los activos con los que
atenderá dicha deuda futura. También deberá informar a la CGN por Nota las características
y normativa legal de dichos planes pos-empleo.
REQ 5-55 Ingreso del Sistema Nacional de Inversión Pública (SNIP)
El Sistema Nacional de Inversión Pública (SNIP) deberá interoperar con el Módulo Contable
del SIIF2 en los siguientes puntos relacionados al proceso de programas y proyectos de
inversión:
El SNIP enviará los Proyectos y Programas de Inversión que se incluirán en el
Proyecto de Presupuesto;
En el marco del proceso de planificación estratégica, se presentaran al SNIP los proyectos
de inversión. Posteriormente, se procederá a priorizar los proyectos que cuenten con
42
NICSP N° 25: “Beneficios a los Empleados”.
Modelo Conceptual del SIIF2 01/04/2014 118/203
conformidad técnica incluyendo en primer lugar los proyectos en ejecución y en segundo
lugar los proyectos nuevos.
Deberán incluirse:
los proyectos en ejecución por los montos a ejecutarse en el período; y
los proyectos a iniciarse en el período fiscal cuyo presupuesto se está formulando.
Este proceso se realiza en el SNIP tanto en instancia presupuestal como en rendición de
cuentas (en caso de haber modificaciones presupuestales), y se envía la información al SIIF2
de cada proyecto con su cronograma de inversión correspondiente a nivel de partida
presupuestal por componente.
Presupuesto Aprobado
Con posterioridad a la aprobación del presupuesto, y de rendición de cuentas (en caso
de haber modificaciones presupuestales), el SIIF2 enviará la información correspondiente
al SNIP de los montos definitivos aprobados para cada proyecto al nivel de detalle al que
fueron enviados originalmente.
Ejecución Financiera de los Proyectos
El SIIF2 deberá soportar y requerir en cada una de las etapas del proceso del gasto
(desde la afectación inclusive), la vinculación con la estructura SNIP de los Proyectos de
Inversión a nivel de Componentes. La ejecución financiera de los proyectos de inversión
a nivel del Componente se enviará periódicamente al SNIP.
Medición de la ejecución física de los Proyectos
En base a los criterios definidos por el SNIP en cuanto a medición física de los Proyectos a
través de sus Componentes, se enviará al SIIF2 la información correspondiente a la
estructura utilizada para su medición.
Ajuste de costos y modificaciones de Programas y proyectos de inversión
El ajuste de costos que se practique durante la ejecución de la obra se iniciara en el SNIP,
excluyendo los procesos de ajustes generales realizados en forma directa en el SIIF2, y será
la base para la actualización del registro del compromiso por los montos a certificar durante
el ejercicio vigente y los registros auxiliares donde se registran obligaciones futuras en el
SIIF2.
En caso que se resuelvan modificaciones a los proyectos que impliquen mayores costos, el
ingreso de éstos, una vez autorizados, modificará el presupuesto adjudicado de la
obra/proyecto y el compromiso respectivo por lo que corresponda ejecutar en el ejercicio
vigente y los registros auxiliares donde se registran obligaciones futuras tanto en el SIIF2
como en el SNIP. En resumen, toda modificación de asignación presupuestal para un
proyecto de inversión debe iniciar su gestión en el SNIP, excepto las de carácter general
realizadas en forma directa en el SIIF2. Posteriormente la información se envía al SIIF2 para
Modelo Conceptual del SIIF2 01/04/2014 119/203
obtener la aprobación y la consiguiente modificación del registro. Finalmente el SNIP recibe
la confirmación de la modificación del registro del SIIF2.
El desarrollo de este requisito debe realizarse en forma combinada con los Requisitos
definidos en 6.8 Sistema Nacional de Inversiones Públicas (SNIP).
REQ 5-56 Ingreso del SICE
La relación del SICE con el Módulo Contable no sólo se da por la transacciones sino también
por la integración del Catálogo de Bienes con el Plan de Cuentas Contable (Servicios,
Inventario, Activos Fijos, Activos Intangibles, y Activos Biológicos).
El presente módulo debe relacionarse directamente con los Sub-módulos de Almacenes y el
Sub-módulo de Bienes del Módulo de Contabilidad, mientras que la contratación de servicios
ingresará directamente al Módulo principal por la ejecución del presupuesto.
Las operaciones que los relacionan son:
Contratación:
Con la firma del contrato y la adjudicación de la contratación se afectará la etapa del
compromiso, teniendo en cuenta que las contrataciones pueden afectar a más de un
año, por lo cual también se deberán exponer en forma referencial los compromisos
multianuales.
Modificación de contratos:
Cualquier modificación autorizada por un contrato ya firmado, la cual implique
incrementar la cantidad de bienes solicitados, generará la correspondiente
modificación en el registro del compromiso.
Rescisión de contratos:
La rescisión del contrato supone la anulación parcial del registro del compromiso por
los montos no ejecutados del mismo. En caso que corresponda el reintegro de
fondos anticipados al proveedor o la aplicación de multas, corresponde además
informar la percepción de estos ingresos a la Tesorería o solicitar la ejecución de las
garantías.
Anticipos:
En caso que así lo establezcan las condiciones de la contratación se registrará
contablemente una Cuenta por Cobrar sin impacto presupuestario por el monto del
anticipo, hasta que se efectivice la primera entrega del contrato.
Recepción de bienes o certificación de servicios:
Las Unidad Ejecutoras identificadas en el contrato o un almacén autorizado recibirán
los bienes o certificarán la prestación de los servicios contratados, previa su
verificación física. La recepción de bienes se conformará con la información que
consta en el remito o, en caso de no existir éste, en las facturas de los proveedores
conformadas por la recepción de los bienes o prestación de los servicios. Estos
documentos, una vez conformados, constituyen el soporte para el registro del
momento contable del “devengado” y simultáneamente, en el caso de la adquisición
de bienes, dará el alta en el inventario del sub-módulo de Almacenes o en el sub-
módulo de Bienes, como así también la constitución de la correspondiente deuda
hasta que sea pagada.
Modelo Conceptual del SIIF2 01/04/2014 120/203
5.3.2.2.2 Ingresos de los sub-módulos contables
El Módulo Contable, a efectos de hacer más eficiente la administración de bienes en un
sentido amplio, contendrá dos sub-módulos, a saber:
El Sub-módulo de Almacenes,
El Sub-módulo de Bienes.
Sub-módulo de Almacenes
El sub-módulo de Almacenes tendrá por objetivo lograr la mayor economía, eficacia y
eficiencia en todas y cada una de las etapas del proceso de registro de los bienes destinados
a la venta43
o al consumo por parte de la entidad, identificando sus ingresos y salidas del
inventario, así como la responsabilidad de los agentes y funcionarios que autoricen, dirijan o
ejecuten las acciones de gestión y de disposición, en cuanto a su legitimidad, mérito o
conveniencia.
REQ 5-57 Sub módulo de Almacenes
Organización y Competencia: El presente sub-módulo será utilizado en forma
descentralizada por cada una de las Unidades Ejecutoras, que serán las responsables de su
administración y de la información que el mismo proporcione.
Normativa: El presente sub-módulo estará formulado de acuerdo a las normas dadas en el
Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector
Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos
Contables.
Bienes Comprendidos44
: Los bienes contemplados en el sub-módulo son:
Bienes de Cambio: son los bienes destinados a la venta o entrega a terceros, ya sea
en el mismo estado en que fueron adquiridos o después de haber producido en el
mismo un proceso de cambio (productos en proceso, productos terminados), sin
entrar a considerar en este proceso si se recibe por la entrega del bien
contraprestación igual, mayor o menor a la del bien entregado.
Bienes de Consumo: sonlosmateriales y suministros destinados a ser consumidos o
distribuidos en la prestación de servicios de las entidades gubernamentales,
incluyendo los asignados para la conservación y reparación de bienes de capital,
como así también los bienes adquiridos para su transformación y/o enajenación por
parte de las entidades que desarrollen actividades de carácter comercial, industrial
y/o servicios o entidades que vendan o distribuyan elementos adquiridos con fines
promocionales.
Características de los bienes: Dichos bienes deben cumplir con las siguientes características:
destinados al consumo final, intermedio, propio o de terceros, y
su tiempo de utilización debe ser dentro del ejercicio o dentro del proceso de la
obra/proyecto.
43
Venta: concepto utilizado en un sentido amplio, desde la entrega de un bien hasta la prestación del
servicio, más allá de que se reciba una contraprestación por la entrega de la cosa. 44
NICSP N° 12: “Inventarios”.
Modelo Conceptual del SIIF2 01/04/2014 121/203
Codificación: Es fundamental que el sub-módulo cuente con la codificación de bienes que
permita representar todo el universo de bienes y servicios, con la flexibilidad suficiente para
que las definiciones sean claras y precisas. Además, dicha codificación deberá poseer una
serie de datos asociados, de manera tal que pueda ser utilizada por todas aquellas áreas
involucradas en la administración de los bienes y servicios (presupuesto, compras y
contabilidad). Dicha codificación debe ser la misma que usa el Módulo de Contratación de
Bienes y Servicios.
Principales Procesos: Los procesos en el sub-módulo son contables comprendiendo los
siguientes:
Ingreso a Almacenes de los bienes:
El alta de los bienes en almacenes se produce con el ingreso de las compras o
donaciones recibidos (momento de devengado), mientras que el documento de
ingreso será el remito de recepción o la conformidad de la comisión de recepción (si
existiera). Si el bien recibido está integrado con contrataciones, el mismo ya se
encuentra imputado al código correspondiente a la compra del producto desde el
inicio de la contratación. De no coincidir el código con el bien recibido se deberá
hacer el ajuste correspondiente en la codificación contable (Plan de Cuentas
Contable).
Costeo de los bienes:
Los bienes ingresados a almacenes se ejecutarán con el ingreso del bien y se
devengarán generando la ejecución del presupuesto y el registro contable en forma
simultánea, de tal forma que la MCP/C deberá contemplar que si bien ambos nacen
en el momento del devengado, para la ejecución del presupuesto es un gasto y para
la ejecución contable es un activo y se mantendrá en el mismo hasta que se venda o
se consuma, momento en que se afectará a resultados.
En esta etapa también se deberá verificar que en la factura estén todos los costos
que se establezcan en el Manual de Contabilidad Gubernamental y Políticas
Contables Generales para todo el Sector Gobierno General y en el Manual de
Normas Particulares de Contabilidad y Procedimientos Contables, ya que de no ser
así deberá hacerse el ajuste contable correspondiente para incluir todos los costos
requeridos en las Normas Contables.
El Manual de Activos establecerá el método de costeo a utilizar que podrá ser
general o específico para aquellos bienes de características especiales.
Salidas de los bienes,
Cuando los bienes salen de almacenes ya sea: (i) por venta, (ii) para consumo o (iii)
por deterioro, se deberá dar de baja los bienes afectando contablemente el resultado
del ejercicio en el que se realiza la salida.
Toma de inventario.
El sub-módulo de almacenes deberá contemplar la toma de inventario al cierre del
ejercicio sustentada en las normas enmarcadas en el Manual de Normas Particulares
de Contabilidad y Procedimientos Contables, sin perjuicio de garantizar en forma
permanente el conocimiento de las existencias.
Principales Salidas: Las salidas del sub-módulo de almacenes deberá contemplar como
mínimo lo siguiente:
Modelo Conceptual del SIIF2 01/04/2014 122/203
Saldos al inicio de los bienes de Bienes de Consumo y Bienes de Cambio;
Altas / Bajas del ejercicio,
Saldos en cualquier momento del ejercicio.
Saldos al cierre del ejercicio de Bienes de Consumo y Bienes de Cambio, y
Costo de los bienes en existencia y de las salidas,
Información para gestión de almacenes en áreas críticas, como por ejemplo la
hospitalaria.
Sub-módulo de Bienes
El sub-módulo de Bienes tendrá por objetivo lograr la mayor economía, eficacia y eficiencia
en todas y cada una de las etapas del proceso de registro de los bienes destinados al uso o
a la inversión por parte de la entidad, identificando:
el ingresos (alta);
las modificaciones;
las bajas del inventario;
los funcionarios responsables de su uso, y
la toma de inventario al cierre o en cualquier otro momento del ejercicio
REQ 5-58 Sub módulo de Bienes
Organización y Competencia: El presente sub-módulo será utilizado en forma
descentralizada por cada una de las Unidades Ejecutoras, que serán las responsables de su
administración y de la información que él mismo proporcione.
Normativa: El presente sub-módulo estará formulado de acuerdo a las normas dadas en el
Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector
Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos
Contables.
Bienes Comprendidos: Los bienes contemplados en el sub-módulo serán:
Activo fijo: Comprende el valor de los bienes de propiedad del ente público
adquiridos a cualquier título (compra, donación y arrendamiento financiero) o
construidos con el propósito de ser utilizados en la producción de bienes, prestación
de servicios o en el desarrollo de la función administrativa del cometido estatal.
Dentro del activo fijo se incluyen los siguientes bienes:
1. Bienes de Uso explotados45
: comprende las propiedades, planta y equipos
de propiedad del ente público, adquiridos por compra, por donación, por
arrendamiento financiero o construido con el propósito de ser utilizados por
las entidades gubernamentales. Dentro de dichos bienes son susceptibles de
identificación, entre otros, los siguientes:
Tierras y terrenos;
Edificios;
Maquinaria y equipos para la producción;
45
NICSP N° 17: “Propiedades, planta y equipo”.
Modelo Conceptual del SIIF2 01/04/2014 123/203
Equipos y mobiliario de oficina;
Activos cultivados.
2. Bienes de Uso concesionados46
: Son los Bienes de Uso descriptos en el
punto (1), que se encuentran en uso o explotación por parte de terceros en el
marco de concesiones de actividades, servicios o cometidos propios del
ente;
3. Propiedades de inversión47
: Comprende las tierras, terrenos y los edificios de
propiedad del ente público, adquiridos a cualquier título (compra, donación y
arrendamiento financiero) o construidos, además de los afectados a la
generación de plusvalía para el ente mediante la locación a terceros de su
uso y goce (alquiler) o por la tenencia con el objeto de incremento de valor;
4. Bienes de infraestructura48
: Comprende los bienes que cumplen la
característica de ser parte de un sistema en red, que pueden ser adquiridos a
cualquier título (compra, donación y arrendamiento financiero) o construidos
por el ente público, como ser: caminos, carreteras, autopistas, diques,
puentes, túneles, aeródromos, canales de riego, desagües o navegación,
sistemas de señales fijas o flotantes, redes de comunicaciones, de
distribución de energía, de agua, centrales generadoras de electricidad,
oleoductos, plazas y parques, recreos, etc., cuya administración la ejerce el
ente público para el uso y goce de la comunidad en general.
5. Bienes de infraestructura concesionados: Comprende los bienes descriptos
en el punto (4) que se encuentran en uso o explotación por parte de terceros
en el marco de concesiones de actividades, servicios o cometidos propios del
ente;
6. Bienes históricos y culturales: Comprende aquellos bienes que han sido
declarados históricos, culturales o del patrimonio nacional, tales como
inmuebles históricos, museos, monumentos y obras de arte, construidos por
el ente público en predios de su propiedad o adquiridos a cualquier título
(compra, donación y arrendamiento financiero), cuyo dominio y
administración la ejerce el ente público para el uso y goce de la comunidad
en general;
7. Recursos naturales: Comprende las reservas naturales en minas, canteras,
yacimientos, bosques y otro tipo de recursos de similar índole, que se
encuentren en uso o en condiciones de explotación, y
8. Obras/proyectos en Construcciones: Comprende la construcción o
ampliación de inmuebles, hasta el momento en que dichos bienes se
encuentren en condiciones de ser utilizados por el ente público para el
destino o afectación que corresponda al cometido estatal. Se incluyen toda
clase de obras/proyectos que permanecen con carácter de adherencia al
suelo formando parte de un modo indivisible, como así también las
ampliaciones y mejoras de construcciones ya existentes. Se consideran
como tales las edificaciones y locales para oficinas públicas, edificaciones
para salud, edificaciones para fines de seguridad, edificaciones educativas y
46
NICSP N° 32: “Concesión de Servicios Públicos”.
47 NICSP N° 16: “Propiedades de Inversión”.
48 NICSP N° 17: “Propiedades, planta y equipo”.
Modelo Conceptual del SIIF2 01/04/2014 124/203
culturales, edificaciones de viviendas, para actividades comerciales,
industriales y/o de servicios, edificaciones de bodegas, instalaciones varias,
caminos, diques, puentes, edificios, canales de riego, desagües o
navegación, sistemas de señales fijas o flotantes, redes de comunicaciones,
distribución de energía, de agua, fábricas, centrales generadoras de
electricidad, oleoductos, etc..
Activos Biológicos49
: Son los activos (animales vivos y plantas) que sufren una
transformación biológica a través de la actividad agrícola, para la venta o
distribución, por ejemplo ovejas, vacas, vides, árboles frutales, etc.
Activos Intangibles50
: son activos no monetarios, identificables y sin apariencia física,
por ejemplo software, patentes, derechos de propiedad, licencias, etc.
Características de los bienes: Dichos bienes deben cumplir con las siguientes características:
que su vida útil superior a un año,
que no se agotan en el primer uso, y
que no están destinados a la enajenación durante el curso normal de las actividades
del ente.
Codificación: Al igual que el Sub-módulo de Almacenes, la codificación debe ser la misma
que la que se usa en el Módulo de Contratación de Bienes y Servicios y que cumpla con las
condiciones y características descriptas en el Sub-módulo de Almacenes.
Principales Procesos: Los procesos en el sub-módulo son contables, comprendiendo los
siguientes:
Ingreso de los bienes (Alta):
El alta de los bienes puede ser producto de compras realizadas, donaciones
recibidas, transferencias recibidas, arrendamientos financieros o construidos por la
entidad. Corresponde mencionar que los bienes se devengarán con la entrega de los
mismos, siendo distintos los documentos de soporte según sea el alta de los bienes,
(escritura, boletos de compra venta, contrato de arrendamiento, certificado de
finalización de obra, factura, etc.)
El alta de un bien se dará siempre y cuando se cumpla con las siguientes
características:
o sea es probable que la entidad reciba beneficios económicos o potenciales
servicios asociados al activo; y
o el valor razonable o el costo del activo puedan ser medidos de forma fiable.
Valuación de los bienes:
La valuación de los bienes deberá cumplir con los criterios que se establezcan en
los: REQ 5-45 Manual de Contabilidad Gubernamental y Políticas Contables
Generales para todo el Sector Gobierno General, REQ 5-46 Manual de Normas
Particulares de Contabilidad y Procedimientos Contables y.REQ 5-47 Manual de
activos.
49
NICSP N° 27: “Agricultura”. 50
NICSP N° 31: “Activos Intangibles”.
Modelo Conceptual del SIIF2 01/04/2014 125/203
Salidas de los bienes:
Cuando los bienes salen de almacenes ya sea: (i) por venta, (ii) por deterioro, (iii) por
donación, se los deberá dar de baja afectando contablemente el resultado del
ejercicio en el que se realiza la salida.
Depreciaciones / Amortizaciones:
El Sub-módulo de Bienes deberá realizar en forma automática los cálculos de
depreciación y/o de amortización y deberá cumplir con los criterios establecidos en
los: REQ 5-45 Manual de Contabilidad Gubernamental y Políticas Contables
Generales para todo el Sector Gobierno General y REQ 5-46 Manual de Normas
Particulares de Contabilidad y Procedimientos Contables.
Deterioros:
El Sub-módulo de Bienes deberá contemplar el cálculo de deterioros51
, al margen del
cálculo de las depreciaciones o amortizaciones, como el reconocimiento de la
pérdida de valor del bien por diferentes razones (legales, tecnología, físicas) y el
correspondiente reconocimiento en el resultado del ejercicio, como así también el
recupero de dicho deterioro, superado que fuera dicho estado. El cálculo de deterioro
deberá cumplir con lo establecido en los: REQ 5-45 Manual de Contabilidad
Gubernamental y Políticas Contables Generales para todo el Sector Gobierno
General y REQ 5-46 Manual de Normas Particulares de Contabilidad y
Procedimientos Contables.
Datos mínimos a informar:
El Sub-módulo de Bienes deberá informar para cada uno de los bienes, como
mínimo, lo siguiente:
o Valores de Origen: comprende el valor de origen o de ingreso al patrimonio
de los bienes adquiridos a cualquier título, destinados al desarrollo de la
función administrativa o cometido estatal. En el caso de Edificios, se excluye
la porción correspondiente al valor del terreno.
o Depreciaciones acumuladas: comprende el valor acumulado de la pérdida en
concepto de cargos periódicos que sufren los bienes del activo fijo producto
del desgaste o pérdida de valor y potencial de servicio o de generación de
beneficios económicos futuros, de carácter normal y progresivo de los
mismos.
o Pérdidas por deterioro: comprende el menor valor estimado de los bienes del
activo fijo, resultante del reconocimiento de deterioros que representen
disminuciones imprevistas de su valor y de su potencial de servicio o de
generación de beneficios económicos futuros.
o Mejoras: comprende el valor de las inversiones realizadas con el propósito
de mejorar o ampliar el potencial de los bienes del activo fijo adquiridos a
cualquier título, los cuales están destinados al desarrollo de la función
administrativa o cometido estatal, y que como consecuencia de dichas
51
NICSP N° 21: “Deterioro del valor de activos no generadores de efectivo” y NICSP N° 26 “Deterioro
del valor de activos generadores de efectivo”.
Modelo Conceptual del SIIF2 01/04/2014 126/203
inversiones se produzca un incremento del valor de dichos bienes o de su
vida útil estimada.
o Porción terreno: comprende el valor de origen o de ingreso al patrimonio de
la porción del edificio atribuible al terreno sobre el que se encuentra
construido.
o Inversiones: comprende el valor de las inversiones realizadas con el
propósito de mejorar o ampliar la generación de beneficios económicos
futuros de los bienes del activo fijo, adquiridos a cualquier título, y que como
consecuencia de dichas inversiones se produzca un incremento del valor de
dichos bienes o de su vida útil estimada.
Toma de inventario.
El sub-módulo de bienes deberá contemplar la toma de inventario con una frecuencia
razonable y en función de las normas enmarcadas en el REQ 5-46 Manual de
Normas Particulares de Contabilidad y Procedimientos Contables.
El inventario de bienes alcanza a todos los bienes registrables tanto en uso como en
desuso, especificando su identificación, descripción, ubicación geográfica, estado de
conservación, valuación, responsables de su administración y custodia o uso, a partir
del procesamiento de las fichas individuales por bien.
El inventario inicial se constituye con la conformación de la base de datos que
contiene todos los bienes inventariados a nivel de las dependencias y entidades,
aplicando para su valorización la metodología que se determine específicamente
para ello.
Posteriormente, el inventario se actualizará en forma permanente mediante el
registro de las adquisiciones de bienes de uso que se realicen durante cada ejercicio
presupuestario o por altas extra-presupuestarias, así como por los movimientos que
los mismos presenten en cada período. Las operaciones de incorporación por vía
presupuestaria se registrarán al valor de origen (adquisición) del bien.
Responsables.
Los responsables patrimoniales por su uso o custodia serán aquellos que tienen
asignados los bienes para su aplicación en los diferentes procesos productivos. Se
establecerá un padrón de agentes públicos autorizados a administrar o usar los
bienes del Estado. Este registro relaciona a los tenedores (personas físicas) con el
subsistema de recursos humanos (identificación de la ficha única del trabajador
correspondiente) y genera el registro de responsables por la administración, uso o
custodia de los bienes.
Principal Salida: La salida del sub-módulo de bienes deberá ser el Estado Complementario:
Estado de Bienes (EB) que, como mínimo, deberá contener la siguiente información:
Información detallada por cada bien;
El importe de los desembolsos reconocidos en libros para obras/proyectos en
construcción,
El saldo al inicio, discriminando las pérdidas por deterioro que haya tenido.
Detallar los movimientos del ejercicio, reflejando:
o Inversiones, (Altas)
o Disposiciones (Bajas)
o Revalúo (incremento y disminuciones)
Modelo Conceptual del SIIF2 01/04/2014 127/203
o Pérdida por deterioro
o Reversión de la pérdida por deterioro
El saldo al cierre producto de los movimientos acontecidos en el ejercicio,
Depreciación/Amortización del período,
Depreciación/Amortización acumulada, y
Valor residual final.
5.3.2.2.3 Ingresos de información provenientes de otras áreas
El Módulo Contable necesitará información de otras áreas del sector público a efectos de
cumplimentar los registros de las contingencias que deberán ser informadas por las
correspondientes áreas jurídicas, que deberán informar:
Estados de Juicios a favor del Estado (primera instancia, cámara, instancia final)
Estados de Juicios en contra del Estado (primera instancia, cámara, instancia final),
Montos reclamados en los juicios vigentes, y
Opinión jurídica sobre la posible resolución de los juicios
REQ 5-59 Contingencias
El Módulo Contable deberá contemplar el ingreso y registro de contingencias en función de
las normativas establecidas en el “Manual de Contabilidad Gubernamental y Políticas
Contables Generales para todo el Sector Gobierno General” y en el “Manual de Normas
Particulares de Contabilidad y Procedimientos Contables”.
5.3.2.2.4 Rendición de cuentas
La rendición de cuentas en materia de administración financiera gubernamental y, en
especial, en lo inherente al Módulo Contable, resulta de fundamental importancia para lograr
la transparencia y confiabilidad de la gestión, en la medida que dicho objetivo se sustente en
un modelo acorde con las características contempladas en el presente Informe.
REQ 5-60 Rendición de cuentas
En el caso de Uruguay el envío de la Rendición de Cuentas y Balance de Ejecución
Presupuestal a la Asamblea General o Junta Departamental, con copia al Tribunal de
Cuentas, seis meses a posteriori de cerrado el ejercicio, no garantiza por si sólo un hecho la
confiabilidad de la información contenida en sus estados y cuadros, sino que se requiere que
tanto dicha rendición anual de cuentas como la que pueda necesitarse periódica y
automáticamente, tenga el sustento conceptual y el enfoque integrado de sistemas que
garantice su confiabilidad y demás atributos que dicha información amerite
Complementariamente, resulta indispensable contar con un adecuado régimen de acceso a
la información pública (Ley N° 18.831), por el cual los sujetos obligados deberán prever la
adecuada organización, sistematización y disponibilidad de la información en su poder,
asegurando un amplio y fácil acceso a los interesados. Por lo tanto, el SIIF2 deberá
desarrollar los mecanismos y reportes necesarios para el proceso de Rendición de Cuentas
de acuerdo a la normativa vigente en la materia.
Modelo Conceptual del SIIF2 01/04/2014 128/203
5.3.2.2.5 Conciliación Bancaria
REQ 5-58 Conciliación Bancaria
El sistema deberá proveer todas las funcionalidades necesarias para efectuar la conciliación
bancaría de las cuentas bancarias administradas de la Tesorería General de la Nación así
como la conciliación bancaria de las cuentas bancarias administradas en forma directa por
los Incisos. Este módulo debe permitir comparar los movimientos de créditos y débitos de
cada cuenta bancaria informada en los extractos bancarios con los registros de los ingresos y
egresos del libro banco, con el fin de establecer en forma diaria el saldo disponible en cada
cuenta. Las diferencias de movimientos registrados en el extracto bancario con los registros
en el libro banco deben generar los correspondientes asientos de ajustes, los cuales deben
ser aprobados por un usuario con el rol aprobador autorizado.
En el desarrollo de esta funcionalidad deberán considerarse la funcionalidad actual del actual
sub-módulo de rendición de cuentas del SIIF 1.
5.3.2.2.6 Emisión de Cuentas Nacionales
El Banco Central de Uruguay elabora las Cuentas Nacionales sobre la base acumulativa de
tres clases:
Cuenta Capital (incluye Ahorro Neto)
Cuenta Financiera (incluye préstamo o endeudamiento neto)
Cuenta de Otras variaciones de Activos
Considerando esta información requerida, el SIIF2 deberá generar los insumos necesarios,
en los casos que corresponda, para la emisión de las Cuentas Nacionales.
REQ 5-61 Emisión de Cuentas Nacionales
La información contable del SIIF2 deberá ser insumo para el BCU con el fin este último sea
usuario de las siguientes salidas, que surgen de los mismos elementos que componen los
EEFF que elabora la CGN, a saber:
Activos Pasivos
Dinero legal y depósitos Préstamos
No Financieros Valores de distintas acciones
Productivos Acciones y otras participaciones de capital
No productivos Reservas Técnicas de Seguros
Fijos Otras cuentas por pagar
Existencias
Objetos valiosos
Otras cuentas por cobrar
Reservas técnicas de seguros
Modelo Conceptual del SIIF2 01/04/2014 129/203
Lo mismo deberá ocurrir con las clasificaciones de información utilizadas por el BCU a nivel
de actividad económica, productos y funciones del Gobierno, para todo lo cual resulta
necesario que dicha entidad financiera central disponga de los EEFF del Sector Público.
5.3.3 Esquema general de Integración del Módulo Contable con los
Módulos principales y secundarios del SIIF2
5.3.3.1 Integración con los módulos principales
Módulo de Contabilidad
Módulos con los
que se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Principales
Presupuesto
desde Unidad
Rectora
Presupuesto
Distribución de los
créditos autorizados para
gastar
Apertura del SIIF2 al
inicio del quinquenio
y al inicio del cada
año.
Presupuesto
Aprobado Distribución de los
recursos estimados
Programación de los
compromisos anuales
aprobados
Cuotas de
Compromiso
Cuotas de
Compromiso
aprobadas para el
año.
Modificaciones
Presupuestarias
Modificaciones por
compensación,
incremento y
reducción de
recursos y/o gastos
aprobados en el
presupuesto.
Presupuesto
Modificado
Modificaciones a la
programación de los
compromisos anuales
aprobados
Modificaciones a los
compromisos
estimados para los
gastos
Cuotas de
Compromiso
Modificadas.
Presupuesto
desde las
Unidades
Ejecutoras
Gastos en Personal anual Valoración anual de
la planta ocupada al
inicio del ejercicio
Comprometido
Modificaciones al gasto
en personal anual
Valorización de las
altas desde la fecha
de alta al cierre del
ejercicio, y
Valorización de las
bajas hasta la fecha
del cierre del
Compromiso
modificado
Modelo Conceptual del SIIF2 01/04/2014 130/203
Módulo de Contabilidad
Módulos con los
que se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Principales
ejercicio
Prestación del servicio Conformidad de la
prestación del
servicio prestado
Devengado
Envío de las liquidaciones
de sueldos aprobadas
Emisión de la orden
de pago autorizada
Mandado a pagar
Formalización del Pago La Tesorería realiza
las Transferencia
bancaria
directamente al
beneficiario final
(funcionario)
Pagado
Prestación de servicios
personales
Conformidad de la
prestación del
servicio prestado
Devengado
Orden de paga
aprobada
Mandado a pagar
La Tesorería realiza
las Transferencia
bancaria
directamente al
beneficiario final
Pagado
Prestación de servicios
no personales
Conformidad de la
prestación del
servicio prestado
Devengado
Orden de Pago
aprobada
Mandado a pagar
La Tesorería realiza
las Transferencia
bancaria
directamente al
beneficiario final
Pagado
Servicios Básicos
normales y habituales
Entrada de la
factura
Compromiso y
Devengado
Orden de Pago
aprobada
Mandado a pagar
La Tesorería realiza Pagado
Modelo Conceptual del SIIF2 01/04/2014 131/203
Módulo de Contabilidad
Módulos con los
que se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Principales
las Transferencia
bancaria
directamente al
beneficiario final
Adquisiciones de Bienes Ingreso del Bien
conformado
Devengado
Orden de Pago
aprobada
Mandado a pagar
La Tesorería realiza
las Transferencia
bancaria
directamente al
beneficiario final
Pagado
Transferencias por
subsidios
Resolución que
aprueba la
transferencia
Compromiso
Con la emisión de la
Orden de pago
aprobada
Devengado y
Mandado a Pago
La Tesorería realiza
las Transferencia
bancaria
directamente al
beneficiario final
Pagado
Recaudaciones Recursos devengado de
Impuestos
Generación del
hecho imponible
Devengado
Recursos liquidado
Presentación de la
liquidación de los
impuestos
Ingresos cobrados Ingreso de montos
por impuestos
ingresados a las
cuentas
recaudadoras
Percibido
Recursos distintos a
impuestos
Cuando se genera
el hecho imponible
Devengado
Créditos a favor de la
Estado
Por los créditos de
los impuestos
Devengado
Modelo Conceptual del SIIF2 01/04/2014 132/203
Módulo de Contabilidad
Módulos con los
que se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Principales
impagos no
registrado por lo
devengado
Devolución de impuestos
de ejercicios anteriores
Cheque entregado o
transferencia
bancaria ordenada
Pagado
Conciliación de Saldos Extractos bancarios
con la información
detallada por
impuesto registrada
en el módulo
Comprometido /
devengado y
pagado
Tesorería Ingresos percibidos de
impuestos
Monto ingresado a
la Cuenta Única
Banco o Caja
Percibido
Otros ingresos percibidos
Montos pagados que
tengan o no impacto
presupuestarios
Por la emisión del
medio de pago
(Cheque) o
transferencia
bancaria
Pagado
Cancelación de Servicios
Personales y no
Personales
Cancelación por compra
de bienes
Cancelación de
Transferencias
(Subsidios)
Fondos Rotatorios
autorizados Anticipo de fondo Pagado
Rendición de los fondos
rotatorios
liquidación de los
fondos rotatorios
Devengado
Desembolso de
Préstamos
Monto ingresado a
la Cuenta única
Banco o Caja
Percibido
Servicio de la Deuda Orden de pago por
nota de los
intereses y/o
amortización de la
deuda
Mandado a Pagar
Modelo Conceptual del SIIF2 01/04/2014 133/203
Módulo de Contabilidad
Módulos con los
que se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Principales
Avales caídos
(cancelación de avales)
Orden de pago por
nota de los
intereses y/o
amortización de la
deuda
Mandado a Pagar
Liquidación de los
sueldos
Transferencias
bancarias directa a
los empleados52
Pagado
Retenciones Cancelación de las
retenciones Pagado
Conciliaciones Bancarias
Extractos bancarios
Comprometido /
Devengado /
Pagado
Deuda Pública Acuerdos de Préstamos Firma del acuerdo
de desembolso Compromiso
Avales acordados
Prestamistas ponen a
disposición los fondos del
préstamo
Disposición de los
fondos
Devengado
Cancelación de avales Por la transferencia
Bancaria realizada
por el Banco Central
Pagado
Emisión de Bonos /
LETES
Colocación de los
Bonos y LETES en
el mercado
Devengado
Desembolso de
Préstamos
Ingresos de
Préstamos a otras
cuentas Bancarias
distintas de la
Cuenta Única.
Percibido
Cronogramas de
Intereses Presupuesto
aprobado Compromiso
Cronogramas de la
52
En el caso de que los pagos los realice la entidad y no la Tesorería sería un Mandado a Pagar para
la tesorería y Pagado cuando las instituciones hacen la transferencia a los empleados.
Modelo Conceptual del SIIF2 01/04/2014 134/203
Módulo de Contabilidad
Módulos con los
que se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Principales
Amortización de la Deuda
Intereses devengados al
cierre
Por el transcurso del
tiempo dentro del
ejercicio
Devengado
Adquisición de
Instrumentos Financieras
(activos, pasivos o
patrimonio)
Por el acuerdo
firmado por la
adquisición o por el
momento donde se
genera el derecho o
la obligación
Devengado
Proceso de conciliación Por los pagos
realizados por el
Banco Central y las
Notas emitidas por
la Tesorería
Pagado
5.3.3.2 Integración con los módulos secundarios
Módulo de Contabilidad
Módulos con los que
se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Secundarios
Recursos Humanos Aprobación del
presupuesto
aprobado por año
Distribución de
créditos
Aprobado
Programación de los
compromisos
anuales aprobados
Cuotas de
Compromiso
Cuotas de
Compromiso
aprobadas para el
año.
Modificación a la
programación de
compromisos
Modificación de la
cuota
Cuota de
compromiso
modificada
Prestación de
servicios
Liquidación mensual
de Salarios
Devengado
Liquidación de
Salarios aprobado
Mandado a pagar
Contrataciones de Diseño de Catálogos Catálogo de Bienes
Modelo Conceptual del SIIF2 01/04/2014 135/203
Módulo de Contabilidad
Módulos con los que
se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Secundarios
Bienes y Servicios
SICE
de Bienes con el Objeto del
Gasto y Plan de
Cuentas Contable
Compra de bienes
Con la firma del
contrato
Compromiso anual +
Compromisos
Multianuales en
forma referencial
Compromiso
Modificación de
contrataos Acuerdo firmado Compromiso
Ingreso de bienes de
consumo
Con la recepción del
bien Devengado
Ingreso de Activo
Fijo
Con la posesión del
activo y control
sobre el mismo
Devengado
Contratación de
Servicios
Con la firma del
contrato Compromiso
Prestación del
Servicio
Con la prestación
del servicio,
proporcional al
tiempo prestado
Devengado
Almacenes Ingresos de los
bienes de consumo
Remito o factura
conformada
Devengado
Valuación de
inventario
Autorización de
ajustes de los costos
Devengado
Baja de bienes por
venta o por consumo
Entrega o venta de
bienes
Devengado
Transferencia de
bienes
Normativa que
autoriza la
transferencia
Devengado
Toma de inventario Documento de
ajustes
Devengado
Bienes Activos fijos
adquiridos
Con la posesión del
activo y control
sobre el mismo
Devengado
Activos fijos
arrendados
Con el contrato de
arrendamiento
Comprometido
Modelo Conceptual del SIIF2 01/04/2014 136/203
Módulo de Contabilidad
Módulos con los que
se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Secundarios
financieramente financiero
Ingreso del activo al
inventario
Devengado
Activos fijos donados Ingreso del activo
fijo donado
Devengado
Análisis de deterioros Informe de
deterioros
Devengado
Cálculos de
Amortización
Cierre del ejercicio
cálculo de
amortización
Devengado
Valuación de Activos
Fijos
Identificación de la
valuación de los
bienes
Devengado
Baja de bienes Baja de los saldos
en libros
Devengado
Tratamiento de las
mejoras como gastos
Ejecución del
presupuesto
autorizado
Devengado
Activación de las
mejoras
Autorización de
ajustes de los costos
Devengado
Bienes en Comodato Contrato de
Comodato
Cierre del ejercicio
para informar en
Nota a los Estados
Financieros
Alta de
Obra/proyecto
Pública
Contrato firmado Compromiso anual +
Compromisos
Multianuales en
forma referencial
Certificado final de
obra/proyecto
Devengado
Alta de Bienes de
Infraestructura
Valuación de los
bienes
Devengado
Bienes
Concesionados
Firma del contrato
de concesión
Compromiso anual +
Compromisos
Multianuales en
forma referencial
Modelo Conceptual del SIIF2 01/04/2014 137/203
Módulo de Contabilidad
Módulos con los que
se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Secundarios
Ejecución del
contrato de
concesión
Devengado
Inversión Pública Adjudicación de las
Obras/proyectos
anuales Firma del contrato
de obra /proyecto
Compromiso
Adjudicación de las
Obras/proyectos
plurianuales
Compromiso anual +
Compromisos
Multianuales en
forma referencial
Ejecución de las
Obras/proyectos
Certificado de
avance de
obra/proyecto
Devengado
Anticipos de fondos Autorización de los
anticipos, salidas de
fondos
Pagado
Ajuste de costos y
modificaciones de
obra/proyectos
Adenda del contrato
de obra/proyecto.
Compromiso
Medición y
liquidación de ajustes
de costos y
modificaciones
Certificado de
avance de
obra/proyecto y
firma de contador
aprobando la
distribución de los
costos.
Devengado
Terminación de la
obra/proyecto
Certificado final de
obra/proyecto que
genera:
Baja de
Obras/proyectos en
proceso u Obras en
construcción
Alta del Activo Fijo o
Entrega de la
obra/proyecto a un
tercero.
Devengado
Modelo Conceptual del SIIF2 01/04/2014 138/203
Módulo de Contabilidad
Módulos con los que
se integra
Procesos Punto de
Integración
Momento de
registro
Integración con los Módulos Secundarios
Constitución de
Garantías de
obra/proyecto en
efectivo
Ingresos de fondos
Constitución de la
deuda Fondos de
Terceros en
Garantía
Percibido
Devolución de
garantías de
obra/proyecto en
efectivo
Salida de fondos
Baja de la deuda
Fondos de Terceros
en Garantía
Pagado
5.4 Módulo tesorería
En el presente apartado se describen los objetivos y requerimientos a tener en cuenta para el
módulo tesorería. Los aspectos relacionados a la integración del módulo de tesorería con el
resto de los módulos se detallan en los apartados de correspondientes a los módulos de
presupuesto y contabilidad.
5.4.1 Objetivos
El módulo de tesorería53
debe contemplar las funcionalidades necesarias para el registro y la
gestión asociada a la recaudación y pago de todos los recursos que forman parte de la
gestión del presupuesto:
El Módulo de Tesorería debe considerar los siguientes principios para su adecuado
funcionamiento:
a) Eficiencia: La gestión de tesorería debe velar por la administración de los fondos
públicos, cualquiera que sea la fuente de financiamiento y uso de los mismos, y de
los títulos y valores en custodia, programando oportunamente los compromisos,
obligaciones y pagos para ejecutar el presupuesto de gastos, viabilizando su óptima
aplicación y realizando un seguimiento permanente, minimizando costos de
funcionamiento.
b) Prudencia: Toda la gestión de tesorería se debe realizar bajo un estricto criterio de
prudencia, minimizando los riegos en el proceso de administración y obtención de
rendimientos de los recursos públicos.
c) Oportunidad: La ejecución de los procedimientos relacionados a la tesorería deben
realizarse utilizando los mecanismos más idóneos que aseguran la pronta
53
No debe confundirse el Módulo de Tesorería con la propia TGN. Si bien la mayoría de
funcionalidades del Módulo de Tesorería serán utilizadas principalmente por funcionarios de la TGN ello
no quita que este módulo cuente con funcionalidades que deben ser operadas por funcionarios ajenos
a la TGN.
Modelo Conceptual del SIIF2 01/04/2014 139/203
disponibilidad de los recursos en un marco de eficiencia, otorgando una mayor
previsibilidad a las fechas de pago de las obligaciones del Estado, que mejoren la
transparencia de la gestión financiera.
d) Unidad de Caja: Los ingresos públicos se acreditarán en una Cuenta Única del
Tesoro, independientemente del concepto u origen de los mismos, y contra dicha
cuenta se debitaran todos los pagos que correspondan realizar según las
obligaciones legalmente asumidas por las Entidades Públicas.
5.4.2 Requisitos
Actualmente en la Tesorería General de la Nación existen un conjunto de subsistemas en
producción que dan respuesta a las distintas funcionalidades que relativas a la gestión de los
recursos y pagos del presupuesto. Por lo tanto, a continuación se detallan los requisitos
generales que el módulo de tesorería del SIIF2 debe cumplir, así como los requisitos
particulares de las funcionalidades desarrolladas por la Tesorería General.
5.4.2.1 Gestión de los recursos
REQ 5-62 Percepción de recursos
El módulo de Tesorería deberá contener todos los procedimientos y funcionalidades
necesarias para una correcta percepción y registración de los ingresos del presupuesto. Se
consideran recursos percibidos a la recepción de efectivo en Caja, depósitos de fondos en
Bancos autorizados para efectuar esta recaudación o cobros mediante títulos, valores o
certificados legalmente determinados. En el momento de la percepción de los recursos, se
registrará en el módulo contable la ejecución del presupuesto de recursos en la etapa del
percibido, generándose en forma automática el asiento por partida doble que corresponda.
REQ 5-63 Registración de los recursos
El módulo de Tesorería deberá contar con los procedimientos y funcionalidades destinadas a
la registración de los recursos por parte de la Unidades Ejecutoras responsables de su
gestión, en especial, a través de la DGI y Aduana. En el caso de los ingresos provenientes
de Lotería y Casino corresponde incorporarlos directamente al módulo de tesorería,
quedando el registro a cargo de las Unidades Ejecutoras de Lotería y Casino, como
asimismo el tratamiento de los recursos propios de los distintos organismos que conforman el
Gobierno Central.
En el caso que este proceso requiera un proceso gradual de implementación, el módulo de
contabilidad del SIIF2 deberá poder capturar los datos necesarios para la registración
contable de los ingresos mediante mecanismos de interoperación adecuados desde los
sistemas de origen las entidades recaudadoras o bien permitir el registro en forma directa
sobre módulo de tesorería del SIIF2.
REQ 5-64 Recursos por Desembolsos de Prestamos
En base a los movimientos de la cuenta banco y la información suministrada por el módulo
de deuda, el módulo de tesorería deberá registrar el monto ingresado por desembolso de
préstamos en la Cuenta Única en el momento del percibido, realizando el correspondiente
asiento contable en el módulo contable y la registración presupuestaria en el módulo
presupuestario en forma automática.
Modelo Conceptual del SIIF2 01/04/2014 140/203
REQ 5-65 Fuentes de financiamiento por Emisión de Deuda
En base a la información de las colocaciones de Bonos y LETES, los movimientos de la
cuenta banco y la información suministrada por el módulo de deuda, el módulo de tesorería
deberá registrar el monto ingresado por emisión de deuda en la Cuenta Única en el momento
del devengado y percibido en forma simultaneo, realizando el correspondiente asiento
contable en el módulo contable y la registración presupuestaria en el módulo presupuestario
en forma automática.
REQ 5-66 Conciliación de recursos
El módulo de Tesorería deberá contar con los procedimientos y funcionalidades destinadas a
la conciliación de recursos a través de los extractos bancarios con el fin de permitir identificar
y clasificar el origen de los recursos por Inciso de origen a nivel de Unidad Ejecutora.
REQ 5-67 Gestión de la disponibilidad financiera de los Incisos
El módulo de Tesorería deberá contar con los procedimientos y funcionalidades destinadas
a, una vez conciliados los recursos provenientes de los Incisos a nivel de Unidad Ejecutora
mediante el extracto bancario de la Cuenta Única del Tesoro, proceder a la habilitación de la
disponibilidad financiera de dichos recursos en el módulo de presupuesto, la cual deberá ser
validada con la existencia de crédito presupuestario para proceder a su utilización.
REQ 5-68 Gestión Garantías
El módulo de Tesorería deberá contar con los procedimientos y funcionalidades necesarias
para la administración de Garantías. Para ello debe contar con funcionalidades que permitan
registrar los principales datos de cada Garantía, como por ejemplo fecha de vencimiento,
monto, proyecto o programa asociado, entre otras características, permitiendo al usuario una
correcta gestión de este instrumento. Dependiendo de su forma de constitución las Garantía
se deben generar distintos movimientos en el módulo contable, Si la Garantía es
documentada, será registrada en un registro auxiliar de Valores en Garantía, mientras que si
es constituida en efectivo, se registrará contablemente en una cuenta de Fondos de Tercero
en Garantía.
5.4.2.2 Gestión de los egresos
Considerando que actualmente el SIIF le brinda soporte a las funciones de la Cuenta Única
del Tesoro, el SIIF2 debe considerar en detalle la optimización de su actual forma de
funcionamiento, en forma conjunta a la optimización de las funcionalidades actualmente en
producción relativas a los egresos, como por ejemplo el control de los valores de los
arrendamientos oficiales de inmuebles a cargo del Gobierno Central o el clearing de pagos
relativos a servicios públicos.
REQ 5-69 Programación financiera de los pagos
En base a los compromisos y devengos de gastos registrados en el módulo de presupuesto
el módulo de Tesorería, en conjunto con la información de los recursos disponibles en la
Cuenta Única del Tesoro, el SIIF2 deberá contar con las funcionalidades necesarias para
contar con una programación financiera de los pagos a realizar en forma mensual.
REQ 5-70 Plan de Caja
En función de los gastos devengados, las transacciones que se encuentran en estado
obligado intervenido y el cupo de pago informado por la Tesorería General de la Nación, el
módulo de Tesorería deberá contar con los procedimientos y funcionalidades necesarias
Modelo Conceptual del SIIF2 01/04/2014 141/203
para que los Incisos, a nivel de Unidad Ejecutora prioricen los pagos a realizar en el
momento del Mandado a Pagar - Obligado Intervenido, generándose el Mandado a Pagar-
Obligado Priorizado. En base a esta información el sistema deberá conformar el Plan de Caja
con una desagregación de pagos diaria. El Plan de Caja será aprobado por la Tesorería
General de la Nación.
REQ 5-71 Medios de Pagos
En base al Plan de Caja aprobado por la Tesorería General de la Nación, el SIIF2 deberá
permitir el pago de las obligaciones autorizadas mediante distintos medios de pagos,
utilizando preferentemente transferencias bancarias, la cual debe funcionar para todas las
entidades del Sistema Financiero, o eventualmente mediante la emisión de cheques
automáticos.
REQ 5-72 Registro de pagos presupuestarios
El sistema deberá contar con las funcionalidades necesarias para gestionar los pagos
asociados a transacciones presupuestarias. Para ello deberá generar las Ordenes de Pago
correspondientes a transacciones devengadas y mandadas a pagar en estado Obligado
Priorizado, validando la existencia de disponibilidad presupuestaria para todas las fuentes de
financiamiento, y la disponibilidad financiera, excepto para la fuente de financiamiento Rentas
Generales, , en el libro Caja o en el Libro Bancos según corresponde, afectando la etapa del
pagado, registrando el débito correspondiente y generando en forma automática el asiento
por partida doble para la imputación indicada en el Orden de Pago.
REQ 5-73 Registro de pagos no presupuestarios
El sistema deberá contar con las funcionalidades necesarias para gestionar los pagos
asociados a transacciones no presupuestarias, tales como el otorgamiento de anticipos,
pagos a cuentas o devoluciones de garantías. Este tipo de movimientos serán registrados en
el sistema como una deuda hasta tanto se complete la operación y se puedan afectar las
partidas presupuestarias correspondientes.
REQ 5-74 Pagado y Percibido por Objeto y Programa Presupuestario
El sistema deberá contener información detallada de los montos pagos y percibidos por
objeto del Clasificador Presupuestario y por programa presupuestario. Para ello los datos
presupuestarios deben mantenerse en la cartera financiera del módulo contable, generando
tantas líneas como programas presupuestarios se identifiquen al momento de realizar el
compromiso y el devengo. Esta desagregación permitirá contar con información del pagado
por objeto del clasificador presupuestario y por programa presupuestario.
REQ 5-75 Devolución al crédito o Pago (Reversión de Pagos)
El sistema deberá contener las funcionalidades necesarias que permitan la gestión y
autorización de reversos en los pagos realizados por error, registrando todos los movimientos
contables y presupuestarios necesarios para realizar esta operación.
Para ello el sistema generará un documento de “devolución al crédito” o de “devolución al
pago”, y cuando detecte por conciliación bancaria el depósito correspondiente procederá
según haya escogido el usuario a reversar el pago o a reversar toda la cadena
presupuestaria hasta restituir el crédito presupuestal.
Modelo Conceptual del SIIF2 01/04/2014 142/203
REQ 5-76 Anulación y reimpresión de cheques
El sistema deberá contener las funcionalidades necesarias que permitan la anulación y
reimpresión de cheques, ya sea por error o caducidad de los mismos, registrando todos los
movimientos contables necesarios para realizar esta operación.
REQ 5-77 Pagos de Servicios de la Deuda
La deuda de intereses y amortizaciones es administrada por el Banco Central, el cual
informará estos movimientos al SIIF2 mediante la interoperación que se defina.
REQ 5-78 Pago de Retenciones
El sistema deberá contener las funcionalidades necesarias para gestionar el pago de
retenciones a favor de terceros al efectuar la cancelación de una obligación, considerando el
tratamiento diferenciado para cada concepto de retenciones.
Estas retenciones pueden generar el movimiento de fondos, como por ejemplo pago una
cooperativa. Otro tipo de retenciones no generan movimientos de fondos, como por ejemplo
el pago por parte de un Inciso a un tercero que se compensa con obligaciones del tercero en
la DGI o en el BPS.
REQ 5-79 Gestión de Fondos Rotatorios
De acuerdo a la normativa vigente, el sistema debe contar con las funcionalidades
necesarias para una adecuada gestión de los Fondos Rotatorios autorizados para los Incisos
a nivel de Unidad Ejecutora.
La funcionalidad de gestión de fondos rotatorios debe permitir la ejecución de operaciones
normales o de regularización de fondos. El módulo debe realizar en forma automática al
inicio del ejercicio el cálculo de la disponibilidad de fondos rotatorios para cada Inciso en
base a la duodécima parte del crédito presupuestal menos la diferencia que se arrastra del
ejercicio anterior y debe liberar una operación de tesorería desde la CUN a las cuentas de los
Incisos. Esta funcionalidad debe registrar la autorización de los fondos rotatorios como
anticipo de fondos y su liquidación, al momento de devengar dicha liquidación, en el módulo
contable.
REQ 5-80 Valores en Custodia
La custodia comprende la guarda, conservación y registro clasificado de los valores y la
percepción de los dividendos, utilidades o remanentes. El módulo de tesorería debe registrar
los movimientos generados por los valores en custodia en un registro auxiliar, de acuerdo a
su naturaleza, para informar el cierre del ejercicio contable la existencia de los mismos y su
cotización a fin de registrar el valor de las inversiones cuando corresponda.
REQ 5-81 Pago de Suministros en formato clearing
El sistema debe contener las funcionalidades necesarias para que los Incisos, a nivel de
Unidad Ejecutora, puedan registrar en forma específica los pagos correspondientes a los
suministros mediante el mecanismo o de pago denominado “Clearing de Suministros”. El
“Clearing de Suministros” es un mecanismo de compensación de deudas por parte de los
distintos Incisos, mediante el cual se generan operaciones de adelanto de tesorería que
posteriormente se regularizan. Para dar soporte a este mecanismo de pago, el sistema debe
contar con un repositorio de datos que permita efectuar un proceso de clearing entre los
débitos y créditos generados por cada empresa pública proveedora de servicios públicos,
con el fin de emitir la orden de pago por parte de la Tesorería General de la Nación por el
Modelo Conceptual del SIIF2 01/04/2014 143/203
valor neto a los débitos y créditos realizados. Cada operación de tesorería tiene un
beneficiario original, el que surge de la obligación, y un beneficiario final, que surge del
proceso de clearing, el cual puede ser igual o diferente.
5.4.2.3 Roles del módulo de tesorería
Una adecuada definición de roles es clave para el correcto funcionamiento del SIIF2 en
régimen. Para ello los roles del módulo de tesorería deben ser claramente definidos en la
etapa de diseño del sistemas en base a los roles generales señalados a continuación.
REQ 5-82 Rol generador de transacciones
El sistema contemplará la definición de un rol de usuario habilitado para generar
transacciones en el módulo de tesorería.
REQ 5-83 Rol aprobador de transacciones
El sistema contemplará la definición de un rol de usuario habilitado para aprobar
transacciones en el módulo de tesorería. En la definición de este rol se debe prestar especial
atención a la existencia de la etapa de Mandado a Pagar – Obligado Intervenido y Mandado
a Pagar – Obligado Priorizado, las cuales generan la necesidad de definir roles aprobadores
con atributos diferentes. A su vez, se deben considerar privilegios asociados a transacciones
no presupuestarias de la tesorería, como por ejemplo los incrementos de Fondos Rotatorios.
REQ 5-84 Reversión de transacciones
En todos los casos los roles deberán tener privilegios asociados a la reversión de
transacciones, las cuales deben estar asociadas a su rol original. Es decir el rol generador
podrá solo generar reversiones, mientras que será el rol aprobador quien cuenta con los
privilegios necesarios para aprobar la reversión.
5.5 Módulo deuda
En el presente apartado se describen los objetivos y requerimientos referidos al módulo
deuda. Los aspectos referidos a la integración del módulo de deuda con el resto de los
módulos del SIIF2 se detallan en los apartados de correspondientes a los módulos de
presupuesto y contabilidad.
5.5.1 Objetivos
El módulo de deuda debe contemplar las funcionalidades necesarias para el registro y la
ejecución de las operaciones de crédito público que realiza el Estado en el marco de las
autorizaciones legales correspondientes, así como la ejecución de las operaciones
destinadas al pago de los servicios de la deuda.
El Módulo de Deuda debe considerar los siguientes principios para su adecuado
funcionamiento:
a) Eficiencia y prudencia: El endeudamiento público tiene como objetivo fundamental
cubrir los requerimientos de financiamiento del sector público al más bajo costo
posible, optimizando los recursos y sujeto al menor grado de riesgo posible.
b) Transparencia: El proceso de endeudamiento público debe llevarse a cabo con
oportunidad, transparencia, procurando el acceso oportuno a información veraz,
comprensible y confiable.
Modelo Conceptual del SIIF2 01/04/2014 144/203
c) Oportunidad: La ejecución de los procedimientos relacionados a la gestión de la
deuda deben realizarse utilizando los mecanismos más idóneos que aseguran la
pronta disponibilidad de los recursos en un marco de eficiencia, otorgando una
mayor previsibilidad a las fechas de pago de las obligaciones del Estado, que
mejoren la transparencia de la gestión financiera.
Bajo la estructura institucional actual de la República Oriental del Uruguay la gestión de la
Deuda Pública se realiza en forma coordinada por el Banco Central, el Ministerio de
Economía y Finanzas y la Contaduría General de la República. Por lo tanto, los requisitos del
SIIF2 deben considerar esta forma de funcionamiento.
5.5.2 Requisitos
En el caso del Uruguay el administrador de la deuda pública es el Banco Central de la
República del Uruguay y por ende es dicha entidad la que cuenta con el correspondiente
sistema de administración, por lo tanto se recomienda como parte de la definición del Modelo
Conceptual de Alto Nivel del SIIF2 que dicho sistema se quien provea información al SIIF2.
Considerando esta definición, en el próximo apartado se indican la información que el
sistema de administración de la deuda pública del Banco Central deberá proveer al módulo
de deuda del SIIF2.
5.5.2.1 Información sobre recursos provenientes de operaciones de deuda
REQ 5-85 Ingresos de recursos por operaciones de crédito público
El sistema de administración de la deuda pública del Banco Central deberá remitir
información al módulo de deuda del SIIF2 de los siguientes aspectos referidos a los ingresos
generados por operaciones de crédito público:
Propuesta de Calendarización de Ingresos (Financiamiento);
Emisión de Valores y Títulos;
Colocación de Valores y Títulos;
Autorización de endeudamiento de las entidades del sector público uruguayo;
Otorgamiento de garantías y avales;
Caídas de garantías y avales otorgados.
Con el fin de gestionar esta información, el módulo de deuda del SIIF2 deberá contar con un
repositorio de datos que permita almacenar y gestionar esta información, registrando los
movimientos correspondientes en el módulo de presupuesto y en el módulo de contabilidad.
REQ 5-86 Contratación y desembolsos de Préstamos
El sistema de administración de la deuda pública del Banco Central deberá remitir
información al módulo de deuda del SIIF2 de los siguientes aspectos referidos a la
contratación y desembolsos de préstamos de crédito público:
Contratación de préstamos (compromiso);
Desembolso de préstamos (devengado);
Ingreso efectivo (percibido).
Con el fin de gestionar esta información, el módulo de deuda del SIIF2 deberá contar con un
repositorio de datos que permita almacenar y gestionar esta información, registrando los
movimientos correspondientes en el módulo de presupuesto y en el módulo de contabilidad.
Modelo Conceptual del SIIF2 01/04/2014 145/203
5.5.2.2 Información sobre gastos asociados a operaciones de deuda
REQ 5-87 Egresos por operaciones de crédito público
El sistema de administración de la deuda pública del Banco Central deberá remitir
información gastos asociados a las operaciones de deuda al módulo de deuda del SIIF2 de
los siguientes aspectos:
Propuesta de Calendarización de egresos (servicios de la deuda e Intereses);
Adecuaciones presupuestarias de intereses y comisiones;
Ejecución del gasto relacionado con el servicio de amortizaciones de la deuda;
Compromiso;
Devengado;
Mandado a pagar;
Pagado.
Ejecución del gasto relacionado con el servicio de intereses y comisiones de la
deuda:
Compromiso;
Devengado;
Mandado a pagar;
Pagado
Regularización y ajuste por variación de tipo de cambio emitidas para el servicio de
amortización de la deuda;
Regularización y ajustes por variación de tipo de cambio u otras variables
contempladas en los servicios de intereses y comisiones de la deuda;
Recupero de avales y garantías por pago del deudor principal;
5.5.2.3 Información sobre gestión de la deuda pública
REQ 5-88 Información de la gestión de la deuda pública
El MEF cuenta en su estructura organizativa con un área responsable de la gestión de la
deuda pública. Esté área, mediante mecanismos de interoperabilidad, vía up load o web
services, o través de los sistemas del Banco Central en su carácter de Agente Financiero de
la República Oriental del Uruguay, deberá enviar información al módulo de deuda del SIIF2
sobre los siguientes aspectos:
Adquisición de Instrumentos Derivados tales como: Contrato a término (forwards),
Contratos a futuros, Permutas Financieras (Swaps) y/o con Opción
Adquisición de Instrumentos de Patrimonio tales como compra de acciones o
participaciones en entidades.
Cualquier Inversión que realice el Gobierno Uruguayo en Instrumentos Financieros,
En caso que no sea posible ingresar esta información en forma automática, deberá ser
ingresada en forma directa mediante pantallas de captura de datos al SIIF2.
Modelo Conceptual del SIIF2 01/04/2014 146/203
6. Integración sistemas de apoyo transversales
En este apartado se especifican los sistemas con los que interoperará el SIIF2, los que son
esquematizados en la Ilustración 6-1 Esquema General de Interoperación para el SIIF2. Para
cada sistema se presenta una breve descripción de sus principales objetivos, las
interacciones detectadas como relevantes y los impactos o riesgos que los volúmenes de
información, requeridos por la interoperación, podrían poner sobre la infraestructura y el
diseño del sistema.
Ilustración 6-1 Esquema General de Interoperación para el SIIF2
El diseño propuesto en la ilustración es claramente uniforme en torno a una propuesta de
interacción exclusivamente centrada en servicios Web, comunicados mediante el
encadenamiento de un bus local a la CGN, con la plataforma de Gobierno Electrónico de la
AGESIC. Incluso este esquema es utilizado para sistemas que están actualmente alojados
dentro de la CGN.
La arquitectura propuesta tiende a inhibir el desempeño de la aplicación – en términos de
tiempos de respuesta (en adelante referidos como latencia) y niveles de procesamiento por
segundo (en adelante referido como throughput) – si se compara con alternativas como la
carga directa entre bases de datos vía procedimientos ETL, o la comunicación mediante
protocolos propietarios en modalidad RPC o EDI, por lo que su implementación requiere de
un cuidadoso dimensionamiento de la infraestructura y la realización temprana de pruebas de
desempeño durante el desarrollo del SIIF2. La razón por la que se estima como la alternativa
más adecuada se debe a que, durante el análisis de los sistemas transversales realizado, se
percibió un alto dinamismo en las iniciativas de modernización del Estado, en la que hay
sistemas que están siendo trasladados a unidades organizativas diferentes, sistemas que se
están siendo remplazados por alternativas de mayor cobertura funcional, e incluso se están
implantando en algunas unidades ejecutoras sistemas GRP en base a alternativas de
mercado.
Modelo Conceptual del SIIF2 01/04/2014 147/203
En este escenario de alto cambio, la reducción del acoplamiento entre sistemas, el adecuado
gobierno de los activos de las Tecnologías de la Información (que en el caso de esta
propuesta, se podría enfocar en el gobierno de activos SOA), y la estandarización de las
interfaces entre los sistemas, pueden resultar factores más críticos y más difíciles de
controlar que la perdida de desempeño derivada del cambio de paradigma, por lo que la
propuesta prioriza estos factores primero y presenta desde ya los factores de riesgo
(asociados al desempeño) que deben ser cuidados durante el desarrollo del SIIF2.
6.1 Visión Global y Plataforma de Gobierno Electrónico (PGE)
La PGE apoya y promueve la implementación de servicios de gobierno electrónico en
Uruguay. Esta plataforma fue construida y es administrada por la Agencia de Gobierno
Electrónico y Sociedad de la Información (AGESIC).
Es una plataforma orientada a servicios Web basados en SOAP y posee un conjunto de
componentes destinados a soportar y promover la interoperación entre las instituciones. Sus
principales componentes son: el Sistema de Seguridad, el Sistema de Gestión de Metadatos
y la plataforma de Middleware.
Para la arquitectura del SIIF2 se propone que la interoperación con las demás entidades del
gobierno, ya sea para el consumo o provisión de servicios, será siempre a través de la PGE,
con el fin de aprovechar la infraestructura, el soporte y el conocimiento disponible en la
plataforma y la AGESIC, y debido a que el alineamiento con este tipo de iniciativas reducirá
los riesgos de incompatibilidades y problemas de interoperación.
El trabajo mediante la PGE impone requerimientos técnicos al middleware que se utilice para
el desarrollo del SIIF2, ya que se requiere de protocolos especializados, como por ejemplo
WS-Trust. Los elementos descritos en la Arquitectura Tecnológica Base para el SIIF2,
plantean explícitamente todos los requerimientos que debe cumplir el middleware, para evitar
incompatibilidades en su implementación.
Para maximizar el potencial de interoperabilidad, el trabajo con la PGE sugiere adherencia a
las especificaciones WS-I Basic Profile, el WS-I Basic Security Profile, WS-trust y WS-
addressing, que son patrocinadas por organismos de reconocimiento mundial en la materia.
El alto incremento al potencial de interoperación que se logra con la adherencia a estas
especificaciones hace que esta sea un requisito para el SIIF2. A su vez, también se deben
utilizar los metadatos definidos al momento de la implantación.
La PGE tiene capacidad de manejar archivos de hasta 50 MB, y se estima que los mensajes
de menos de 5MB son procesados en menos de un segundo. A su vez, la disponibilidad
declarada para la plataforma es de un 99,9%. Junto a la PGE, la AGESIC provee de una red
de alta velocidad, denominada REDuy que provee accesos de hasta 100Mbps.
Por lo tanto, considerado estos beneficios y potencialidades de las PGE la propuesta de
interoperación del SIIF2 con el resto de los sistemas transversales relacionados a la
administración financiera pública se realiza sobre la base de su utilización.
6.2 Sistema de Compras y Contrataciones Estatales (SICE)
6.2.1 Características funcionales
El SICE apoya todas las etapas de los procesos de adquisiciones en el Estado. Permite el
análisis de las diferentes etapas del proceso de compra: pedidos, armado de la compra,
Modelo Conceptual del SIIF2 01/04/2014 148/203
llamado a proveedores, ofertas, adjudicación y facturación; la identificación de la unidad
organizativa generadora del pedido y por objeto del gasto; la interacción con el sitio de
publicaciones de forma de habilitar la publicación de los llamados y las adjudicaciones.
El SICE tiene una relación de alta relevancia respecto a las interoperaciones del SIIF2.
Ambos sistemas intercambian información en diversos puntos del proceso de compra, como
por ejemplo: el armado de compra y su afectación, la preparación de la compra y su reflejo
en un compromiso, y la recepción de la factura tras una orden de compra, para el
reconocimiento de la obligación.
6.2.2 Características técnicas
SICE tiene más de 1.600 cuentas activas de usuarios, los que en los últimos 12 meses
generaron un volumen de transacciones hacia el SIIF 1 que superó las 165.000. El volumen
de transacciones manifiesta una marcada estacionalidad, en la que aparece una
concentración de movimientos al final de año.
Para poder brindar adecuados niveles de servicio, el diseño y dimensionamiento de la
interacción con SICE debiera considerar que este sistema aumentará los requerimientos de
throughput en al menos 0,05 transacciones por segundo.
Con respecto al tamaño esperado de las transacciones, estas tienen una amplia variabilidad
dependiendo del tipo y proceso que soporten. Por ejemplo, las facturas viajan como
auxiliares para el registro de las obligaciones. En el caso de Facturas Electrónicas viajarán
los datos definidos para estas de acuerdo a los estándares definidos por la DGI pero en el
caso de Facturas No Electrónicas, lo transmitido refleja una factura física (imagen).
La variabilidad del tamaño de la información transmitida hace recomendable establecer
límites de tamaño máximo de archivo de entrada a nivel de infraestructura de hardware, no
estableciendo de antemano límites y controles dentro del SIIF2.
El SICE es un sistema construido en Java EE, que utiliza el servidor JBoss 6.1 sobre una
base de datos Oracle 10g (10.2).
REQ 6-1 Interoperación SIIF2 - SICE
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Compras y Contrataciones Estatales. Para ello se debe
considerar que el SICE tiene una relación de alta relevancia respecto a las interoperaciones
del SIIF2. Ambos sistemas intercambian información en diversos puntos del proceso de
compra, como por ejemplo: el armado de compra y su afectación, la preparación de la
compra y su reflejo en un compromiso, y la recepción de la factura tras una orden de compra,
para el reconocimiento de la obligación son procesos que implican intercambio de
información entre ambos sistemas, los cuales deben mantenerse en el desarrollo del SIIF2.
6.3 Sistema Lucia (DNA)
6.3.1 Características funcionales
Lucia es un sistema de Gestión Integrada Aduanera para el control de las operaciones
aduaneras de importación, exportación y tránsito de mercaderías en territorio uruguayo.
El sistema Lucia, si bien recibe pagos, no tiene actualmente relación directa con el SIIF2,
sino que envía información al sistema de información financiera a través del Banco de la
Modelo Conceptual del SIIF2 01/04/2014 149/203
República Oriental del Uruguay (BROU) sobre cuentas del Ministerio de Economía y
Finanzas. El BROU por su parte envía al SIIF información agregada de los movimientos de
ingreso que llegan por la aduana.
6.3.2 Características técnicas
Trabaja en función de mensajería en formatos propietarios EDI, a través de los cuales recibe
las declaraciones aduaneras, las valida y las procesa.
La situación descrita desea ser cambiada por la CGN, por una interoperación que permita
capturar la información agregada de las transacciones de la Aduana, la cual debe contar con
el respaldo del detalle delas transacciones en el sistema Lucia. Las operaciones realizadas
por la aduana superan las 400.000 al año, y tienen una tasa de crecimiento anual de
aproximadamente un 10%.
REQ 6-2 Interoperación SIIF2 - Lucía
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información agregada con el Sistema Lucía, el cual debe contar con el detalle de las
transacciones en dicho sistema
6.4 Sistemas de la Dirección General Impositiva (DGI)
6.4.1 Características funcionales
Los sistemas de la Dirección General Impositiva (que resultan de interés para el presente
análisis) soportan los procesos relacionados con la recaudación tributaria en la nación y su
relación con CGN se centra en la alimentación de la cuenta de recaudación.
Al igual que el caso del sistema Lucia, la DGI actualmente entrega información agregada a la
CGN. Una adecuada implementación de una interfaz de interoperabilidad en el SIIF2 debiera
manejar adecuadamente la sincronización entre los planes de cuentas de ambos sistemas y
contribuir a acelerar los plazos de cierre mensual, que hoy toman cuatro meses.
6.4.2 Características técnicas
Debido a que la frecuencia de comunicación requerida con las DGI es de sólo una vez al día
(no se especificó que se necesitara una comunicación en línea), los impactos sobre la
infraestructura pueden ser mitigados utilizando cargas nocturnas.
REQ 6-3 Interoperación SIIF2 – Sistemas de Recaudación de DGI
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información agregada con los Sistemas de Recaudación de la DGI, el cual debe contar
con el detalle de las transacciones en dicho sistema.
REQ 6-4 Interoperación SIIF2 – Sistemas de Retenciones DGI
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información referente a las retenciones de impuestos realizadas en el SIIF2 y que deben
ser informadas en forma diaria a la DGI.
Modelo Conceptual del SIIF2 01/04/2014 150/203
REQ 6-5 Interoperación SIIF2 – Sistemas de Resguardos DGI
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información referente a los resguardos asociados a las retenciones de impuestos
realizadas a los proveedores en el SIIF2 y que deben ser informadas en forma mensual a la
DGI.
REQ 6-6 Interoperación SIIF2 – Sistema de Certificado de Crédito de DGI
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Certificados de Crédito de DGI.
REQ 6-7 Interoperación SIIF2 – Sistema de Certificado Único de Empresa de DGI
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Certificado Único de Empresa de DGI.
6.5 Registro Único de Proveedores del Estado (RUPE)
6.5.1 Características funcionales
El RUPE permite registrar y mantener la información actualizada de todas las personas
jurídicas interesadas en contratar con el Estado. Su objetivo es disponibilizar toda la
información relevante para los organismos públicos al momento de contratar una empresa,
brindando acceso a la misma desde un solo lugar y de forma inmediata. Además, los
proveedores tienen acceso a la información que de ellos conste en el registro, sin necesidad
de solicitud previa.
La Agencia de Compras y Contrataciones del Estado (ACCE) es responsable del desarrollo,
funcionamiento y mantenimiento del RUPE.
6.5.2 Características técnicas
En la actualidad los servicios del RUPE se encuentras disponibles a través de la PGE. En
particular utiliza el servicio de novedades de la plataforma. Una vez recibida la novedad de
un cambio en la información de un proveedor, se deben consumir los servicios propios del
RUPE para actualizar la información.
REQ 6-8 Interoperación SIIF2 – RUPE
El sistema deberá proveer los mecanismos necesarios para permitir suscribirse al servicio de
novedades del Registro Único de Proveedores del Estado (RUPE) en modalidad Push
(Notificación). A partir de la recepción de las novedades que necesitan ser procesadas por el
SIIF2, se deberá consumir los servicios propios de información del RUPE.
Entre la información que se debe consumir está: datos generales del beneficiario, cuentas
bancarias y sanciones.
6.6 Sistema de Distribución del Gasto (SDG)
6.6.1 Características funcionales
El SDG es un sistema que permite el ingreso periódico de información sobre la distribución
por Unidad Organizativa del presupuesto ejecutado en el SIIF en cada trimestre del año, así
como la definición y cuantificación de los productos realizados en cada Unidad Organizativa.
Modelo Conceptual del SIIF2 01/04/2014 151/203
6.6.2 Características técnicas
En la actualidad el SDG requiere información del SIIF2 de cada Unidad Ejecutora por cada
trimestre. El tamaño de las cargas se estima en aproximadamente 500.000 transacciones.
Esta carga se hace actualmente utilizando directamente las bases de datos de producción, lo
que genera una situación de acoplamiento que hacen que cualquier cambio en el SIIF2
ponga en riesgo la integridad de la información manejada en el SDG (se requiere la
interpretación de parte de la información por expertos).
Los impactos de cambiar el actual esquema de carga de información a una arquitectura
orientada a servicios pueden ser en gran medida eliminados si se mantiene la periodicidad
trimestral o se reduce a una periodicidad mensual de la carga, ya que en este caso la
transmisión puede hacerse durante la noche o en un itinerario programado donde se
evidencie un mínimo impacto sobre los usuarios transaccional de ambos sistemas.
El SDG es un sistema hecho en Visual Basic 5, sobre una base de datos Oracle 10g., que se
encuentra en un proceso de actualización mediante el desarrollo de una interfaz web
utilizando GeneXus para Java.
REQ 6-9 Interoperación SIIF2 – SDG
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Distribución del Gasto (SDG) con una periodicidad mensual
a nivel de Unidad Ejecutora y/o Unidad Organizativa.
6.7 Sistema de Presentación del Articulado (SPA)
6.7.1 Características funcionales
El SPA es utilizado por los Incisos y Unidades Ejecutoras para introducir la justificación y los
textos de los artículos a ser incorporados en el Presupuesto, y en las instancias anuales de
rendición de cuentas.
La información del articulado es cargada en el SIIF una vez al año, y de esta se obtiene la
asignación presupuestaria asociada a los artículos cuando corresponde.
6.7.2 Características técnicas
El volumen de información manejado por el SPA (la cual a modo de ejemplo en el año 2012
fue de 300 artículos con asignación presupuestaria para 10 partidas) y la frecuencia de carga
no debieran generar requerimientos significativos en infraestructura para la implementación
de la interoperabilidad con el SIIF2. La única consideración que se debe tener al momento de
diseñar la interfaz es que esta debe permitir la división de la carga en múltiples invocaciones
(no tratar de cargar toda la información en una sola invocación), ya que de no contar con esta
capacidad, el proceso de carga puede verse afectado por time outs de comunicación.
REQ 6-10 Interoperación SIIF2 - SPA
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Presentación del Articulado.
Modelo Conceptual del SIIF2 01/04/2014 152/203
6.8 Sistema Nacional de Inversiones Públicas (SNIP)
6.8.1 Características funcionales
El SNIP es el sistema destinado a mejorar la calidad de la inversión pública del Uruguay,
optimizando y mejorando la eficiencia y el control del gasto público asociado a la inversión
pública.
El SNIP tiene la capacidad de soportar todo el ciclo de vida de un proyecto de inversión, y
entre sus objetivos busca que las Unidades Ejecutoras, previo al otorgamiento de los
recursos presupuestales, tengan desarrollada la etapa de pre inversión, y que una vez
transcurrida la evaluación del proyecto, se cumplan las condiciones para obtener recursos y
ejecutar el proyecto.
Una vez puesto en completo funcionamiento, el SNIP remplazará el Sistema de Información
y Seguimiento de Inversión (SISI), el que con más de 560 usuarios, es el sistema
actualmente utilizado para el seguimiento de las iniciativas de inversión, pero cuyo alcance
funcional es menor.
En relación al SIIF2, se espera que este tenga la capacidad de tomar los proyectos desde el
SNIP e integrarlos al presupuesto, mantener sincronizada la información de los techos
presupuestarios y, en general, mantener la consistencia con la CGN a nivel de los recursos
de los proyectos de inversión y vincular el presupuesto y la ejecución de los Proyectos de
Inversión a nivel Componentes.
Por otra parte, la información de la ejecución de los proyectos es relevante para el SNIP, por
lo que se prevé la necesidad de que el SIIF2 cuente con mecanismos para informar los
niveles de ejecución asociados a los proyectos de inversión a nivel de componentes. La
periodicidad de esta actualización debe ser diaria.
Por último, es importante la implementación de mecanismos que garanticen que la
información de los proyectos esté constantemente sincronizada entre ambos sistemas, por
ejemplo a nivel de la estructura de partidas de los proyectos.
La lógica de trabajo del SNIP impone cambios a la forma de trabajar con los proyectos de
inversión. A modo de ejemplo, hoy se manejan alrededor de 700 proyectos de inversión, pero
son proyectos presupuestales, y agregan información de varios proyectos. En el nuevo SNIP,
cada proyecto será tratado en detalle y de manera individual, lo que se estima llevaría este
número a más de 1.000.
6.8.2 Características técnicas
Considerando las características funcionales y teniendo en cuenta que el SNIP no registra
los detalles de cada transacción del SIIF2, sino que trabaja con información a nivel de
Componentes, los que deberán correlacionarse con Objetos del Gasto, se estima desde un
punto de vista técnico que la interoperación con este sistema no impondrá cargas
destacables ni de throughput, ni de tamaño de archivos.
El SNIP está construido en C++.Net, y cuenta con capacidad para el consumo y provisión de
servicios Web, por lo que no se anticipan problemas de tecnológicos para la implementación
los contratos que se definan en el SIIF2.
Modelo Conceptual del SIIF2 01/04/2014 153/203
REQ 6-11 Interoperación SIIF2 - SNIP
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema Nacional de Inversiones Públicas (SNIP).
6.9 Sistema de RR.HH (SGH-SLH)
6.9.1 Características funcionales
El SGH apoya la gestión de los recursos humanos del Gobierno, que incluye la estructura
organizativa y los puestos de trabajo para todos los vínculos contractuales de los Incisos y
Unidades Ejecutoras del presupuesto nacional y los datos personales y funcionales de
quienes ocupan las plazas definidas en la estructura formal. Se trabaja en 3 niveles en
paralelo: formal, real y retributivo que reflejan respectivamente lo establecido por la
normativa, el funcionamiento real y la forma en que se estructura el pago de haberes.
En el ingreso de la información se controla la estructura institucional, los datos de las partidas
presupuestales y las normas legales en los clasificadores del SIIF. Los movimientos
controlados por la CGN en el SGH del rubro 0 se reflejan automáticamente en los créditos de
las partidas presupuestales del SIIF.
Las partidas retributivas personales se integran en el SLH el cual incorpora los descuentos,
las retenciones legales, cálculos de multas y licencias, etc., para realizar la liquidación de
sueldos. Una vez finalizada la liquidación se pueden emitir los recibos y planillas para los
controles requeridos y se generan los datos para los cajeros, la historia laboral del BPS, el
sistema automático de créditos del BROU, las cuentas corrientes de aguinaldo e IRPF, el
sistema de transporte metropolitano y otras salidas para el resto de los involucrados. Se
prevé la confección de la Obligación de la liquidación automáticamente en el SIIF.
Actualmente el SGH se divide en 2 módulos principales. El primer módulo es responsable de
gestionar los aspectos financiero-contables en relación al SIIF y la interrelación con el SLH, y
está radicado en CGN. El segundo módulo maneja todos los demás aspectos relacionados
con la gestión humana, como la planificación de la dotación, capacitación, gestión de la
carrera funcionaria, etc., es llevada en un nuevo proyecto, denominado SGH 2.0, que está
bajo la gestión de la Oficina Nacional del Servicio Civil.
El SIIF2, al igual que la versión actual, trabajara con el módulo centrado en la parte financiera
contable de la gestión de los RRHH.
6.9.2 Características técnicas
La actual integración entre el SIIF y el SGH es vía procesos por lotes entre bases de datos.
Si bien este esquema puede ser mantenido para el nuevo proyecto, se recomienda evaluar
tempranamente en el desarrollo la conveniencia de llevarlo a servicios Web. Esta evaluación
deberá hacerse sobre la consideración de que si la integración se realiza vía SOA, su
desempeño será considerablemente menor que la alternativa basada en procesos ETL, sin
embargo, también será considerablemente más flexible y contribuirá de mayor manera a la
agilidad organizacional y la orientación a procesos dentro de la CGN.
Con respecto a los riesgos asociados a un aumento en los requerimientos de infraestructura
de cambiarse a un esquema basado en SOA, si bien los requerimientos de infraestructura
probablemente deban ser revisados en base a pruebas de desempeño que se realicen sobre
Modelo Conceptual del SIIF2 01/04/2014 154/203
los servicios construidos, debido a la periodicidad mensual de la carga de información de los
pagos de nóminas, no debiera incrementar los requerimientos de manera significativa.
REQ 6-12 Interoperación SIIF2 – SGH-SLH
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Gestión de los Recursos Humanos (SGH-SLH).
6.10 Sistema de Planificación Estratégica y Evaluación (SPE)
6.10.1 Características funcionales
El SPE recoge la Planificación Estratégica de los distintos Incisos, bajo una lógica de Áreas
Programáticas, Programas y Objetivos de Programa.
En este sistema, que remplaza al Sistema de Evaluación (SEV), se definen objetivos del
quinquenio en base al presupuesto y cada año se realizan las rendiciones de lo ocurrido en
el periodo anterior, y se ajusta planificación para el año siguiente
La interacción entre el SPE y el SIIF2 es puntual pero crítica, en el SPE se definen los
programas y esta información debe mantenerse consistente y coordinada con la información
capturada por el SIIF2. También en el SPE se definen los Objetivos Estratégicos e
Indicadores asociados a los Programas. Por lo tanto es muy relevante que las estructuras de
datos de ambos sistemas sean compatibles para el intercambio de información.
6.10.2 Características técnicas
En base a las características funcionales de la interoperación entre el SPE y el SIIF2, no se
anticipan necesidades de throughput o latencia que impacten significativamente la
infraestructura del sistema.
El SPE es un sistema construido en tecnología GeneXus para Java sobre una base de datos
Oracle 10g.
REQ 6-13 Interoperación SIIF2 – SPE
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el Sistema de Planificación Estratégica y Evaluación (SPE).
6.11 Sistemas del BROU
6.11.1 Características funcionales
El e-BROU permite realizar transferencias en forma electrónica desde las cuentas del tesoro
a las cuentas de los proveedores del estado.
Desde el sistema central del BROU se envía información necesaria para realizar las
conciliaciones bancarias de pagos y de recaudación, así como el estado de las cuentas del
Gobierno.
6.11.2 Características técnicas
El acceso al sistema e-BROU se realiza a través de la página web del banco. Este sistema
permite autenticar mediante contraseña o utilizando certificado digital.
Modelo Conceptual del SIIF2 01/04/2014 155/203
La información enviada desde el sistema central del BROU se realiza adjuntando archivos a
mails.
REQ 6-14 Interoperación SIIF2 – e-BROU
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con el sistema e-BROU de forma segura, para realizar transferencias
electrónicas.
REQ 6-15 Interoperación SIIF2 – BROU
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con los Sistemas centrales del BROU. Esta información es necesaria para
realizar las conciliaciones bancarias de pagos y de recaudación, así como conocer el estado
de las cuentas del Gobierno.
6.12 Sistemas del BCU
6.12.1 Características funcionales
Las transferencias en forma electrónica desde las cuentas del tesoro a las cuentas de los
proveedores del estado en los bancos privados se realizan a través del Sistema Central de
Liquidaciones (AGATA). A su vez el BCU se encuentra en proceso de migración de este
sistema hacia los Sistemas RTS/X y DEPO/X.
Desde el sistema central del BCU se envía información necesaria para realizar las
conciliaciones bancarias de pagos y de desembolsos de préstamos de Organismos
Internacionales.
A su vez el BCU cuenta con sistemas que permiten obtener información necesaria para
alimentar el módulo de Deuda Pública.
6.12.2 Características técnicas
El intercambio de información para las transferencias electrónicas con el Sistema AGATA se
realiza a través de Web-Services.
REQ 6-16 Interoperación SIIF2 – Sistema de Pago del BCU
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con los sistemas de pago del BCU, para realizar transferencias electrónicas.
REQ 6-17 Interoperación SIIF2 – BCU
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con los Sistemas centrales del BCU. Esta información es necesaria para
realizar las conciliaciones bancarias de pagos y de desembolsos de préstamos de
Organismos Internacionales.
REQ 6-18 Interoperación SIIF2 – Sistemas de Deuda Pública del BCU
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con los Sistemas de Deuda Pública del BCU.
Modelo Conceptual del SIIF2 01/04/2014 156/203
6.13 Sistemas del BPS
6.13.1 Características funcionales
El BPS emite el certificado común vigente de contribuyente. El SIIF2 necesita contar la
información de estos certificados de que serán controlados al momento de generar pagos.
6.13.2 Características técnicas
En la actualidad el BPS brinda estos servicios a través de la PGE.
REQ 6-19 Interoperación SIIF2 – BPS
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con los sistemas de certificado común de contribuyente del BPS.
6.14 Sistemas GRP
6.14.1 Características funcionales
El gobierno de Uruguay actualmente se encuentra en un proceso de fortalecimiento de las
capacidades institucionales de los Incisos en aéreas tales como gestión presupuestaria,
financiera, patrimonial, de abastecimiento y de inventario de activo fijo y de materiales.
En este contexto, la AGESIC se encuentra liderando un plan de implantación de una solución
de mercado tipo GRP a nivel de los Incisos con el fin de cubrir su gestión institucional. Este
plan de implantación consta de múltiples fases, y tiene como objetivo final que el sistema
GRP se encuentre disponible en más de diez Unidades Ejecutoras.
La integración entre el SIIF2 y estos sistemas GRP es muy relevante, ya que gran cantidad
los eventos de negocio que deben tener un reflejo financiero, presupuestario serán
capturados en el GRP, en vez de la interfaz Web del SIIF2, por lo que luego deberán ser
propagados al SIIF2 vía interoperabilidad.
Esta modalidad de trabajo – el GRP como cara visible a los usuarios institucionales, y una
transmisión posterior al SIIF2 – tiene como beneficio que la infraestructura requerida para la
operación del SIIF2 se reduce, ya que toda la demanda que se deriva de la interacción entre
el usuario y el sistema es absorbida por el GRP, y reemplazada por interoperaciones de
menor frecuencia. Sin embargo, para lograr este beneficio, se requiere de un cuidadoso
diseño de los contratos de interoperación, prestando especial atención a los procesos de
validación e intercambio de información entre los dos sistemas.
6.14.2 Características técnicas
La interoperación entre el SIIF2 y los sistemas de tipo GRP con cobertura institucional es una
de las más importantes y técnicamente exigentes a desarrollar. Si se considera que el SIIF 1
tuvo casi 1.800.000 transacciones durante el 2011, la demanda generada por los sistemas
GRP institucionales cuanto a registro de transacciones debiera ser menor a esta cifra (no
todas las instituciones tendrán necesariamente un GRP, ya que el SIIF2 brindara una
alternativa para aquellas que no requieran su implantación). Dado esto, la demanda
generada por los sistemas GRP debiera poder ser atendida aumentando los requerimientos
de throughput en al menos 0,5 transacciones por segundo.
Modelo Conceptual del SIIF2 01/04/2014 157/203
Con respecto al tamaño de las transacciones, es recomendable establecer acuerdos de
niveles de servicio que fomenten la transmisión de transacciones de bajo tamaño (menos de
1 mega por transacción). Debido a que, por ejemplo, los movimientos contables del sistema
pueden tener relaciones 1 a n con sus auxiliares, no se recomienda que las interfaces
consideren más de un movimiento por invocación, ya que poner múltiples movimientos en
una sola llamada a servicios Web puede traer problemas de latencia excesiva, time outs, o
reducción de la capacidad de escalamiento horizontal .
El GRP actualmente en implantación es el sistema K2B, construido en tecnología GeneXus.
REQ 6-20 Interoperación SIIF2 – GRP de Cobertura Institucional
El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado
de información con sistemas GRP de cobertura institucional, definiendo todos los procesos y
mecanismos de validación a nivel funcional y tecnológico que permitan las interoperación
entre ambos sistemas, considerando al SIIF2 como el sistema maestro. En el desarrollo de
este requisito se deben considerar todos los aspectos señalados en 3.9.1 Interoperabilidad
institucional
Modelo Conceptual del SIIF2 01/04/2014 158/203
7. Modelado BPM del ciclo presupuestario
La presente Sección contiene la situación actual (“As Is”) de los principales procesos del ciclo
presupuestario modelados según metodología BPM. El objetivo de este punto es representar
gráficamente el ciclo presupuestario, con el fin de ser incorporado como Anexo en los
Términos de Referencia con el objetivo de permitir a los posibles proveedores tener una idea
de alto nivel del flujo de funcionamiento actual de dichos procesos.
7.1 Situación actual del SIIF
El Sector Gobierno General de la República del Uruguay se organiza en los siguientes
grupos:
Poderes del Estado: Legislativo, Judicial y Ejecutivo, el cual se conforma por los
Ministerios y constituyen la denominada Administración Central.
Tribunal de Cuentas (TC), Corte Electoral (CE) y el Tribunal de lo Contencioso-
Administrativo (TCA), que cuentan con autonomía técnica por la naturaleza de sus
funciones.
Administración Descentralizada, conformada por los los Entes Autónomos y
Servicios Descentralizados.
Fondos de la Seguridad Social.
Gobiernos Departamentales.
Ilustración 7-1 Estructura del sector público
Modelo Conceptual del SIIF2 01/04/2014 159/203
El sector público se caracteriza por:
Contar con Organismos creados con distintos tipos de autonomía funcional o
financiera, lo que repercute en los sistemas de información y en la gestión
financiera54
:
o Los organismos que pertenecen a la Administración Central, sin autonomía
funcional y financiera;
o Los Entes del Art. 220 de la Constitución, tienen autonomía funcional pero no
financiera;
o Por último, se encuentran los que tienen autonomía funcional y financiera
(Entes del Art. 221 de la Constitución y Gobiernos Departamentales).
Existencia de Normativa vigente común a todo el sector público para la
administración y gestión financiera, distinguiéndose 3 cuerpos normativos: la
Constitución de la República, el Texto Ordenado de Contabilidad y Administración
Financiera (TOCAF), y el Texto Ordenado de Inversiones (TOI), estos últimos son el
resultado de las sucesivas sanciones de las leyes de Presupuesto quinquenal y
Rendición de Cuentas que actualizan alguno de los artículos originales.
Los siguientes procesos de la gestión financiera:
Formulación, discusión y sanción del presupuesto.
Se distinguen los siguientes tipos de presupuestos: Nacional, el de los Gobiernos
Departamentales, el de las empresas o entes del Estado (art. 221 de la Constitución)
y el del Poder Legislativo.
El presupuesto nacional incluye la Administración Central y los organismos del
artículo 220 de la Constitución (ANEP55
, UDELAR56
, ASSE, UTEC, PJ, TC, TCA, CE
e INAU). Combina un sistema de caja con el devengamiento de los egresos por
gasto o inversiones.
Asignación del presupuesto a cada organismo: este paso es responsabilidad de la
CGN y consiste en la apertura de los créditos presupuestales aprobados y luego la
asignación de fondos mediante un sistema de cuotas periódicas, que habrá de
organizarse en base al preventivo de caja y a la programación de la ejecución de
desembolsos que deben ser realizados para el cumplimiento de los respectivos
programas, proyectos y actividades57
.
Ejecución y registro de las erogaciones (gastos e inversiones):
Afectación preventiva – se corresponde con la reserva del crédito para atender el
gasto (autorización para gastar del Jerarca ministerial).
Compromiso – cuando se adjudica la compra. Se dispone definitivamente el crédito
para la actividad prevista (libramiento de la orden de compra)
54
Ob. cit., pág. 69. 55
ANEP: Administración Nacional de Educación Pública. 56
UDELAR: Universidad de la República. 57
Art. 34 de la Ley Nº 15.767 del 13 de setiembre de 1985.
Modelo Conceptual del SIIF2 01/04/2014 160/203
Obligado (devengado) – es la etapa de la determinación de la suma cierta que
deberá pagarse, previa verificación de la real prestación del servicio o de la
recepción conforme del bien adquirido.
Enviado a pagar – en la intervención de la obligación, se produce una vez realizados
los controles previos de legalidad por parte del Tribunal de Cuentas de la República
(Central y delegaciones), generando la deuda de Tesoro.
Priorizado – constituye la disposición del cupo para el pago efectivo de la obligación
intervenida. Esta etapa está a cargo del Gerente Financiero de cada inciso y tiene
como límite el cupo mensual asignado por la Tesorería General de la Nación, en
consonancia con el programa financiero.
Pago entregado o enviado – cuando se procede a la cancelación definitiva de la obligación.
Control y evaluación:
Control:
Se aplican controles preventivos, concomitantes y posteriores.
Los primeros los ejecuta la Contaduría General que controla la intervención preventiva de
todos los gastos y pagos; el control preventivo y concomitante es responsabilidad del órgano
de control interno que es la Contaduría General de la Nación.
Mientras la Auditoría Interna de la Nación (AIN), realiza controles esporádicos a solicitud del
Poder Ejecutivo.
El Tribunal de Cuentas, que es el responsable del control externo, realiza los tres tipos de
controles e informa al Poder Legislativo.
Evaluación:
Es realizada por la OPP que comprende la evaluación técnica del presupuesto por resultados
de forma que se pueda evaluar la eficacia y eficiencia del sector público58
, elabora la
metodología de evaluación, releva la información de los indicadores de gestión y la
presentación al Parlamento, debe asesora a las unidades ejecutoras en la formulación de
metas e indicadores para medir el desempeño; y posteriormente revisar el cumplimiento de
los objetivos y metas a través de los indicadores.
Asimismo, el artículo 93 del TOCAF plantea que “todos los actos y operaciones
comprendidos en la presente ley deberán realizarse y registrarse mediante la utilización de
un sistema uniforme de documentación y procesamiento electrónico de datos, con los
requisitos que establezca la Contaduría General de la Nación y reflejarse en cuentas,
estados demostrativos y balances que permitan su medición y juzgamiento.” Se establece en
el artículo 100 del TOCAF que, “la Contaduría General de la Nación, previa conformidad del
Tribunal de Cuentas, definirá los principios, normas, procedimientos, plan de cuentas, así
como los registros auxiliares que sean necesarios y las formas de registro que regirán con
carácter obligatorio para todos los organismos públicos".
58
Art. 143 de la Ley 16.736 de 6 de enero de 1996.
Modelo Conceptual del SIIF2 01/04/2014 161/203
En síntesis, la normativa autoriza la participación de la Contaduría General de la Nación
como actor clave en el asesoramiento y gestión de las finanzas públicas.
Sin perjuicio de ello, existen otros actores claves y responsables también de la gestión de los
procesos que integran la administración financiera, como por ejemplo la Asesoría
Macroeconómica, la Unidad de Presupuesto Nacional, la Tesorería General de la Nación
pertenecientes al Ministerio de Economía y Finanzas, así como la Oficina de Planeamiento y
Presupuesto que depende de la Presidencia. Cabe mencionar que desde otro punto de vista,
es clave la participación de los actores operativos del proceso que se encuentran en las
distintas unidades ejecutoras que conforman el sector público.
A continuación se relaciona el macroproceso presupuestario con los actores involucrados en
su ejecución y control, y los subsistemas del SIIF que los sistematizan:
Proceso Adm.
Financiera
Actores involucrados y
actividades contempladas Actores que ejecutan el control
Formulación,
discusión y
sanción del
presupuesto.
Instituciones que conforman el
Presupuesto Nacional:
Administración Central y
organismos del artículo 220 de
la Constitución
Poder Ejecutivo a través del MEF y
CGN en aspectos técnicos y
operativos, y de la OPP en gastos de
inversión y planificación estratégica.
Presupuesto Gobiernos
Departamentales: Intendencias
y Juntas Departamentales, TC
y eventualmente Poder
Ejecutivo
Juntas Departamentales
Entes del Estado contemplados
en el Art. 221 de la
Constitución: Entes del Poder
Ejecutivo con asesoramiento de
OPP, TC y eventualmente
Poder Legislativo
OPP (monitoreo), TC y Poder
Legislativo
Instituciones que conforman el
Presupuesto Nacional:
Asignación de créditos
presupuestales a cada
organismo.
CGN y OPP
CGN (control interno)
Ejecución y
registro del gasto
e inversiones.
Organismos MEF/CGN
OPP (inversión)
y TC (control externo previo,
concomitante y posterior)
Control y
Evaluación.
CGN, OPP, AIN y TC CGN (control interno previo y
concomitante)
AIN (control interno posterior),
OPP (monitoreo de inversión asesora
Modelo Conceptual del SIIF2 01/04/2014 162/203
al Poder Ejecutivo y evalúa el
cumplimiento de objetivos) y
Tribunal de Cuentas (control externo
previo, concomitante y posterior)
7.2 Descripción del macroproceso presupuestario
El macroproceso presupuestario es complejo debido a la gran cantidad de actores con
distintos grado de responsabilidad que intervienen en la ejecución de los mismos y cuentan
con necesidades diferentes.
Los procesos que componen el macroproceso en el ámbito del Poder Ejecutivo son:
Formulación
Ejecución
Control y evaluación
Si se analiza desde el punto de vista cronológico, el macroproceso presupuestario uruguayo
se caracteriza por basarse en un presupuesto quinquenal que se formula al inicio del período
de Gobierno y se separa en ejercicios anuales que coinciden con el año civil59
. Este
presupuesto será elaborado por el Poder Ejecutivo con el asesoramiento de la Oficina de
Planeamiento y Presupuesto y debe presentarlo al Poder Legislativo antes de los 6 primeros
meses del inicio del período de Gobierno. Cabe destacar, que el articulado puede considerar
la vigencia retroactiva del presupuesto a partir del ejercicio en curso.
Asimismo, el Poder Ejecutivo rinde cuentas anualmente al Poder Legislativo, dentro de los
seis meses vencidos de la ejecución del ejercicio anual. Por este motivo consideramos
conveniente utilizar un cronograma para visualizar los tiempos y el impacto que tiene en la
toma de decisiones no sólo a nivel de unidad ejecutora sino de país.
Ilustración 7-2 El ciclo presupuestario
El Presupuesto Quinquenal se formula para el período de Gobierno, desde el año 1 al 5. Por
disposición constitucional, el Año 1 (primer año de gobierno), se inicia con los créditos de
apertura del Año 5 del período anterior, hasta que se apruebe el nuevo Presupuesto
Quinquenal, el que puede incluso modificar el año en curso, o sea Año 1. Dicho de otra forma
59
Art. 214 de la Constitución de la República
Periodo de Gobierno
Vigencia del Presupuesto Quinquenal
Formulación Presupuesto Quinquenal
Ejercicio año 1
Revisión y Apertura de Créditos Presupuestales
Ejecución del Presupuesto
Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1)
Ejercicio año 2
Revisión y Apertura de Créditos Presupuestales
Ejecución del Presupuesto
Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1)
Ejercicio año 3
Revisión y Apertura de Créditos Presupuestales
Ejecución del Presupuesto
Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1)
Ejercicio año 4
Revisión y Apertura de Créditos Presupuestales
Ejecución del Presupuesto
Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1)
Ejercicio año 5
Revisión y Apertura de Créditos Presupuestales
Ejecución del Presupuesto
Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1)
(1): Incluye control y evaluación.
Año 5Actividad
Año 1 Año 2 Año 3 Año 4
Inicio GobiernoInicio Gobierno
Modelo Conceptual del SIIF2 01/04/2014 163/203
cuando se inicia el período de Gobierno, los créditos del Año 1 fueron abiertos por los
mismos valores de apertura del Año 5 del periodo del gobierno anterior.
7.2.1 Formulación
Los principales elementos del proceso de Formulación del Presupuesto pueden resumirse en
la siguiente ficha:
Ilustración 7-3 Formulación
Como resultado de este proceso surge el presupuesto .Por su parte, los créditos se
desagregan en grupo, subgrupo, objeto del gasto y auxiliar.
La estructura del Presupuesto establecida en el artículo 214 de la Constitución contiene:
Los gastos corrientes e inversiones del Estado distribuidos en cada inciso por
programa.
Los escalafones y sueldos funcionales distribuidos en cada inciso por programa.
Los recursos y la estimación de su producido, así como el porcentaje que, sobre el
monto total de recursos, corresponderá a los Gobiernos Departamentales.
Las normas para la ejecución e interpretación del presupuesto.
En el Anexo II (Fichas de Procesos: Actividades) se describen las actividades necesarias, los
actores que intervienen y el soporte utilizado para llevarlas a cabo.
En el Anexo III (Modelado BPM) se realiza el modelado de procesos del ciclo presupuestario
identificando en un primer nivel los Macroprocesos de Formulación Presupuestaria,
Aprobación, Ejecución Presupuestaria y Evaluación Presupuestaria. Cada uno de estos
Macroprocesos es explotado hasta un nivel dos de la metodología BPM bajo los procesos
actuales (As Is).
Modelo Conceptual del SIIF2 01/04/2014 164/203
7.2.2 Ejecución presupuestal y financiera
En cuanto a la ejecución del presupuesto, es posible sintetizarlo en el siguiente cuadro:
Ilustración 7-4 Ejecución presupuestal
En el proceso están reflejadas las principales tareas de la ejecución presupuestal del gasto y
de recursos; faltan algunas que están como funcionalidades en el SIIF (ejemplo:
arrendamientos), el proceso de asignaciones presupuestales que se hace durante el año (sin
ser los refuerzos de rubros) y las modificaciones presupuestales que se generan
automáticamente por interface con el SGH y arrendamientos oficiales.
En el Anexo II (Fichas de Procesos: Actividades) se describen las actividades necesarias, los
actores que intervienen y el soporte utilizado para llevarlas a cabo.
En el Anexo III (Modelado BPM) se realiza el modelado de procesos del ciclo presupuestario
identificando en un primer nivel los Macroprocesos de Formulación Presupuestaria,
Aprobación, Ejecución Presupuestaria y Evaluación Presupuestaria. Cada uno de estos
Macroprocesos es explotado hasta un nivel dos de la metodología BPM bajo los procesos
actuales (As Is).
Modelo Conceptual del SIIF2 01/04/2014 165/203
7.2.3 Control y evaluación
En cuanto al control y evaluación del presupuesto es posible sintetizarlo en el siguiente
cuadro:
Ilustración 7-5 Evaluación y control
Como resultado de este proceso la CGN deberá formular la Rendición de Cuentas y el
Balance de Ejecución Presupuestal que deberá contener los siguientes estados
demostrativos60
:
1. Del grado de cumplimiento de los objetivos y metas programados, indicando las
previstas y alcanzadas y su costo resultante.
2. Del resultado del ejercicio, por comparación entre los compromisos contraídos para
gastos de funcionamiento más los compromisos contraídos que responden a gastos
ejecutados para inversión con las sumas efectivamente recaudadas para la
financiación de dichos gastos.
3. De la ejecución del presupuesto con relación a los créditos indicando:
a) Monto del crédito original.
b) Modificaciones introducidas en el transcurso del ejercicio.
c) Monto definitivo al cierre del ejercicio.
d) Compromisos contraídos, y, en su caso, ejecución de las inversiones.
e) Saldo no utilizado.
60
Artículo 96 del TOCAF o artículo 214 de la Constitución de la República.
Modelo Conceptual del SIIF2 01/04/2014 166/203
f) Complementariamente, los compromisos referidos a gastos de inversión
contraídos y no ejecutados en el ejercicio, indicando los que tienen crédito
para el ejercicio siguiente y aquellos que no teniéndolo deban ser
reprogramados.
4. De la ejecución del presupuesto con relación al cálculo de recursos por cada clase
de ingresos, indicando:
a) Monto calculado.
b) Monto efectivamente recaudado.
c) Diferencia entre lo calculado y lo recaudado.
5. De la aplicación de los recursos al destino para el que fueron instituidos, indicando el
monto de las afectaciones especiales con respecto a cada clase de ingresos.
6. Del movimiento de fondos y valores, indicando:
a) Existencias al iniciarse el ejercicio.
b) Ingresos.
c) Egresos.
d) Existencias al cierre del ejercicio.
7. De la situación del tesoro, indicando los valores activos, los pasivos y el saldo.
8. De la Deuda Pública, clasificada en consolidada y flotante, indicando las emisiones
de empréstitos y otras operaciones a largo plazo y la Deuda Pública en circulación al
principio y al cierre del ejercicio.
9. De las fuentes de financiamiento que se han utilizado en el ejercicio.
En el Anexo II (Fichas de Procesos: Actividades) se describen las actividades necesarias, los
actores que intervienen y el soporte utilizado para llevarlas a cabo.
En el Anexo III (Modelado BPM) se realiza el modelado de procesos del ciclo presupuestario
identificando en un primer nivel los Macroprocesos de Formulación Presupuestaria,
Aprobación, Ejecución Presupuestaria y Evaluación Presupuestaria. Cada uno de estos
Macroprocesos es explotado hasta un nivel dos de la metodología BPM bajo los procesos
actuales (As Is).
Modelo Conceptual del SIIF2 01/04/2014 167/203
8. Arquitectura Tecnológica del Sistema
En este apartado se describen los elementos tecnológicos que conforman la plataforma base
para el desarrollo del SIIF2.
El desarrollo de una nueva versión del sistema brinda la oportunidad de aprovechar al
máximo las ventajas que las nuevas tecnologías pueden ofrecer, en términos de:
interoperabilidad, flexibilidad y agilidad para atender los requerimientos cambiantes de las
instituciones, desempeño, seguridad, etc. Sin embargo, la gran cantidad de alternativas
disponibles en el mercado hacen muy difícil decidir cuales piezas son realmente necesarias
para construir el sistema, lo que sin una adecuada guía pone a los responsables del proyecto
en riesgo de adquirir lo que no se necesita, o peor aún, no adquirir un elemento que, ya
avanzado el desarrollo, resulta imprescindible.
El objetivo de este apartado es presentar el diseño arquitectónico base para soportar el
desarrollo y posterior operación del SIIF2. Se denomina “Arquitectura Tecnológica Base”
debido a que establece las estructuras fundamentales sobre las cuales se podrá definir y
refinar la arquitectura completa del sistema. Los contenidos definidos en este diseño
permitirán anticiparse a problemáticas técnicas que recurrentemente aparecen en desarrollos
de gran escala.
La base tecnológica definida se centra en las piezas de middleware sobre las que se
ejecutará el SIIF2, e identifica todas las que se necesitarán para manifestar los atributos de
calidad del sistema detectados como requerimientos en la fase de análisis de este proyecto.
Cada pieza es descrita de manera conceptual y sin sesgos hacia proveedores particulares,
manteniendo una independencia tecnológica.
Las distintas piezas de la plataforma se describen en base a seis capas:
1. Presentación, cuyos elementos soportan la ejecución de los componentes de la
interfaz de usuario de los distintos módulos del sistema.
2. Negocio, cuyos elementos soportan la ejecución de los componentes que
encapsulan los procesos, la lógica y las reglas de negocio más invariables del sector
público, en el dominio presupuestario, deuda pública, financiero y contable.
3. Datos, cuyos elementos permiten el almacenamiento y manipulación de la
información persistente del sistema.
4. Integración, cuyos elementos soportan la ejecución de los componentes que
permiten la interoperación entre elementos internos y sistemas externos.
5. Seguridad, cuyos componentes permiten otorgar los niveles requeridos de
identificación, aseguramiento, no repudio e integridad al sistema.
Adicionalmente, la arquitectura base incorpora componentes de monitorización, que no
influyen mayormente en el desarrollo del sistema, pero resultan altamente relevantes para su
correcta operación.
Para cada componente, se presenta:
Un diagrama de presentación, donde el componente abordado aparece en color azul,
y está relacionado de uno o más componentes presentados en color gris. Los
componentes que aparecen en gris deben estar presentes y adecuadamente
Modelo Conceptual del SIIF2 01/04/2014 168/203
integrados al componente central, para que éste se comporte y trabaje de acuerdo a
los supuestos establecidos para este diseño arquitectónico.
Una descripción general de las capacidades del componente y el razonamiento que
llevó a su inclusión en la plataforma.
Una lista de requerimientos tecnológicos de alto nivel que deben satisfacer las
alternativas de mercado que se consideren para manifestar uno o más de los
componentes definidos en el documento.
Ilustración 8-1 Capas de la plataforma de middleware de la arquitectura base
8.1 Capa de Presentación
En esta sección se presentan los elementos que soportan la ejecución de los componentes
de la interfaz de usuario de los distintos módulos del sistema.
Modelo Conceptual del SIIF2 01/04/2014 169/203
8.1.1 Portal Web 2.0
Ilustración 8-2 Portal Web 2.0
El Portal Web 2.0 permite la creación de interfaces de usuario altamente configurables. Tiene
la capacidad de mezclar contenidos de múltiples fuentes, como por ejemplo: contenidos del
SIIF2, contenidos de sistemas externos, sistemas de generación de reportes, contenido
generado por middleware especializado, contenido estático, etc., permitiendo la creación de
interfaces mucho más sofisticadas, usables y ricas en funcionalidad que las que se pueden
lograr con tecnologías más tradicionales. Los nuevos portales Web 2.0 traen además
componentes previamente construidos que permiten una interacción bidireccional con sus
usuarios, y que pueden ser utilizados para dar soporte en línea (vía chats), recoger opiniones
(con foros), e incluso, permitir que el usuario modifique parte del contenido que se publica en
el portal, para así fomentar el trabajo colaborativo (wikis, blogs, etc.).
Por último, el portal permite la personalización de su interfaz, permitiendo que cada usuario o
institución configure sus contenidos de acuerdo a sus preferencias y necesidades.
La plataforma considera a esta pieza como el punto central de acceso a sus usuarios. A
través del portal, se presentan todos los contenidos y accesos a funcionalidades del Sistema,
según los lineamientos de usabilidad que definan qué contenidos serán presentados en el
portal y qué contenidos serán accedidos desde el portal.
REQ 8-1 Portal Web 2.0
Debe proveer funcionalidades que permiten un completo soporte para la administración
centralizada de sus contenidos. Con este fin, también debe poder integrarse al motor de
gestión de contenidos que se escoja para la plataforma.
Debe proveer mecanismos, como por ejemplo interfaces de desarrollo de aplicaciones
(API, por el inglés ApplicationProgramming Interface), para la creación dinámica de
aplicaciones web (centradas en tecnologías de portlets, webpartso equivalentes).
Modelo Conceptual del SIIF2 01/04/2014 170/203
Debe proveer de herramientas para desarrollo rápido de contenidos (como asistentes,
componentes parametrizables y mecanismos de clonación de contenidos).
Debe proveer componentes Web 2.0 pre construidos, que permitan soportar el trabajo
colaborativo y la interacción bidireccional con sus usuarios, como por ejemplo: chats,
foros, soportar el protocolo RSS, etc.
Debe poder soportar múltiples sitos activos al mismo tiempo.
Debe brindar mecanismos para el despliegue de contenidos en diferentes formatos,
documentos, contenido no estructurado, XML, HTML e imágenes.
Debe soportar el despliegue de sus contenidos mediante los protocolos HTTP, HTTPS.
Debe soportar el trabajo con contenidos desarrollados bajo el estándar WSRP 2.0.
Debe soportar la integración con servicios de correo (SMTP).
Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y
de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe proveer mecanismos de autorización de granularidad fina que puedan ser
aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma.
Debe soportar autenticación mediante los mecanismos de SSO que se elijan para la
plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
Debe proveer de mecanismos respaldo de contenidos, o de mecanismos que le permitan
conectarse con un sistema de respaldo para delegar estas actividades.
8.1.2 Servidor Web
Ilustración 8-3 Servidor Web
El servidor de aplicaciones es el componente de la plataforma encargado de desplegar gran
parte de los elementos de interfaz de usuario.
El uso de servidores web permite anticiparse a potenciales problemas de rendimiento y
escalabilidad debido a su capacidad de operar en clústeres que pueden ser escalados
horizontalmente y de independizarse de la capa de lógica de negocio.
Modelo Conceptual del SIIF2 01/04/2014 171/203
REQ 8-2 Servidor Web
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
Debe brindar mecanismos de reconfiguración dinámica de clústeres, que permita iniciar y
detener instancias en base a demanda, y pueda detectar la llegada de nuevas instancias
a la red.
Debe brindar mecanismos para “hotdeployment” de las aplicaciones web, que permita el
despliegue e instalación de los desarrollos sin interrupción de los servicios prestados por
la plataforma.
Debe permitir la ejecución de múltiples versiones de una misma aplicación.
Debe soportar mecanismos para la gestión automática de sus recursos, que permitan la
liberación automática de los que puedan quedar tomados por problemas de
programación.
Debe tener la capacidad de delegación del balanceo a dispositivos de hardware
externos.
Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y
de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe proveer mecanismos de autorización de granularidad fina que puedan ser
aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma.
Debe soportar autenticación mediante los mecanismos de SSO que se elijan para la
plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe soportar los protocolos que permitan la generación de contenido que pueda ser
desplegado en el portal Web 2.0 seleccionado para la plataforma.
8.2 Capa de Negocios
En esta sección se presentan los elementos soportan la ejecución de los componentes que
encapsulan la lógica y las reglas de negocio más invariables del sector público, en el dominio
presupuestario, financiero y contable.
8.2.1 Servidor de Aplicaciones
Ilustración 8-4 Servidor de Aplicaciones
Modelo Conceptual del SIIF2 01/04/2014 172/203
El servidor de aplicaciones es el componente de la plataforma encargado de proveer
servicios tales como: acceso a las fuentes de datos, soporte de transacciones y
administración de sistemas distribuidos de gran escala.
Su incorporación en la plataforma, ya sea para la implementación de componentes
concebidos bajo un estilo arquitectónico multicapas o uno orientados a servicios, permite
brindar a la arquitectura SIIF2 de mayores niveles de integridad a nivel de datos y de código,
pues permiten la centralización de la lógica en un grupo controlado de nodos, lo que a su vez
reduce el riesgo de que versiones inconsistentes del código se ejecuten de manera
descontrolada.
Por otra parte, el uso de servidores de aplicación permite anticiparse a potenciales
problemas de rendimiento y escalabilidad, debido a una mejor utilización de recursos
compartidos y su capacidad de operar en clústeres que pueden ser escalados
horizontalmente.
El servidor de aplicaciones cumple un rol fundamental en la plataforma, pues es el ambiente
de ejecución donde se despliegan la mayoría de los componentes que encapsularán la lógica
del negocio, así como gran parte de los servicios Web.
REQ 8-3 Servidor de Aplicaciones
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster)
Debe brindar mecanismos de reconfiguración dinámica de clústeres, que permita iniciar y
detener instancias en base a demanda, y pueda detectar la llegada de nuevas instancias
a la red.
Debe brindar mecanismos para hotdeployment de las aplicaciones, que permita el
despliegue e instalación de los desarrollos sin interrupción de los servicios prestados por
la plataforma.
Debe permitir la ejecución de múltiples versiones de una misma aplicación.
Debe proveer servicios para el procesamiento de transacciones distribuidas en el
estándar XA (del inglés eXtendedArchitecture).
Debe proveer servicios de mensajería robusta, y soporte colas de mensajería XA.
Debe proveer mecanismos para la ejecución y gestión punta a punta de procesos por
lotes.
Debe incorporar mecanismos que permitan la persistencia de las colas de mensajería en
bases de datos, y proveer mecanismos de manejo de las colas frente a una
indisponibilidad de la base de datos.
Debe soportar mecanismos para la gestión automática de sus recursos, que permitan la
liberación automática de los que puedan quedar tomados por problemas de
programación.
Debe soportar todos los protocolos necesarios para la ejecución de servicios Web
basados en el WS-I Basic Profile, en todas las versiones del perfil.
Debe soportar la capacidad de delegación del balanceo a dispositivos de hardware
externos.
Debe soportar integrarse a componentes de seguridad que se elijan para la plataforma, y
de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe soportar mecanismos de autorización de granularidad fina que puedan ser
aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma.
Modelo Conceptual del SIIF2 01/04/2014 173/203
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
8.2.2 Reglas de Negocio
Ilustración 8-5 Reglas de Negocio
Las Reglas de Negocio se centran en la implementación y modificación de las reglas de los
procesos de negocio – como por ejemplo las validaciones y los flujos de decisión que existen
en los procesos de las instituciones – de manera independiente y separada del código de la
aplicación. Esta independencia entre las reglas y el código permite que las reglas puedan ser
cambiadas sin tener que recompilar, reinstalar o reiniciar el sistema. Es decir, permiten una
modificación altamente dinámica del comportamiento implementado. Incorpora además
funcionalidades que permiten que las reglas sean ingresadas y modificadas por analistas de
negocio, sin exigir conocimientos de programación (aunque puede contar con opciones
avanzadas que permiten además la programación de reglas complejas).
Este componente complementa los objetivos perseguidos con la incorporación de los
componentes de negocio, y se utilizará para la implementación de las reglas de negocio que
los expertos de la institución identifiquen como altamente dinámicas y variables. Es decir, no
todas las reglas de negocio se implementan en este componente, sino que sólo aquellas
cuyo dinamismo justifica ponerlas fuera del código.
La incorporación de este componente fomentará aún más la capacidad de modificación del
sistema, así como su capacidad de reflejar más fácilmente los procesos institucionales
soportados por el SIIF2 y de acomodar sus cambios.
REQ 8-4 Reglas de Negocio
Debe proveer mecanismos que permitan almacenar las políticas y las normas de negocio
definidas por los analistas de la CGN u otro conocimiento, codificado en reglas del tipo
si/entonces y tablas de decisiones.
Debe proveer un editor de reglas con una interfaz de usuario que permita la definición, de
manera sencilla, de una regla de negocio o una política. Esta interfaz debe estar
orientada a analistas de negocio sin conocimientos de programación.
Modelo Conceptual del SIIF2 01/04/2014 174/203
Debe poder ejecutar las reglas que en él se defina, realizando las tareas definidas en la
regla o evaluando las políticas registradas en el repositorio en función de la información a
la que se relaciona.
Debe permitir la automatización de la ejecución de las reglas y políticas mediante
esquemas de inferencia, que tomen en cuenta más de un parámetro o condición para la
ejecución de una regla, o mediante esquemas reactivos, que esperen el cumplimiento de
alguna condición para la ejecución de una regla o política.
Debe habilitar la construcción de reglas, validaciones y programación de eventos
mediante APIs, que permitan además su integración con el código del SIIF2.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
8.2.3 Monitor de Actividades de Negocio
Ilustración 8-6 Monitor de Actividades de Negocio
El Monitor de Actividades de Negocio es un componente que permite recoger métricas
asociadas a la ejecución de los procesos de negocio, y alimentar con ellas a cuadros de
control e indicadores. Trabaja en base conjunto con la capa de negocios, ya que las métricas
que captura son arrojadas por sensores que se ejecutan sobre él. Trabaja además en
conjunto con el portal Web 2.0, donde son desplegados los cuadros de mando y los reportes
de indicadores.
El monitor de actividades de negocio cuenta con mecanismos para establecer alertas, para
definir indicadores personalizados, y para definir respuestas automáticas que activen de
manera proactiva o reactiva procesos y actividades en función de umbrales y parámetros de
comportamiento.
Este rol complementa las capacidades de la plataforma al darle mayor visibilidad a los
procesos que se ejecutan sobre ella. La información que provee permite a usuarios de los
distintos incisos y unidades ejecutoras, a nivel de jefatura y directivos ver en tiempo real
cómo los procesos y actividades de la institución están siendo llevados a cabo en el día a
día.
Modelo Conceptual del SIIF2 01/04/2014 175/203
REQ 8-5 Monitor de Actividades de Negocio
Debe contar con mecanismos que permitan la definición de cuadros de mando, reportes
y alarmas a usuarios sin conocimientos en programación.
Debe poder capturar la información de ejecución de los procesos monitorizados en
tiempo real.
Debe poder generar reportes en tiempo real, que permitan la actualización de los
resultados de la medición en el momento que aparece nueva información. Esto aplica a
cuadros de mando y alertas.
Debe poder integrarse con el Motor ETL para el manejo y procesamiento de grandes
volúmenes de información.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
Debe contar con mecanismos que le permitan desplegar todos sus informes y contenidos
en el portal Web 2.0 seleccionado para la plataforma.
8.2.4 Motor de Inteligencia de Negocios
Ilustración 8-7 Motor de Inteligencia de Negocios
El Motor de Inteligencia de Negocios provee herramientas para transformar los datos de los
distintos repositorios del sistema en información adecuada, en contenido y formato, para
apoyar de manera efectiva la toma de decisiones. En particular, entrega bloques de
construcción para el desarrollo de informes de gestión, cuadros de mando, paneles de
indicadores claves de gestión, etc., y otorga a los usuarios capacidades para la elaboración
de sus propios informes y para realizar análisis personalizados de información.
Esta pieza se utilizará para generar los reportes para los usuarios directivos y de alta gestión
del SIIF2 y constituye la pieza central propuesta para la implementación del SIIF2
Agregación, mediante la cual se podrán implementar los reportes analíticos, estratégicos y
los análisis de inteligencia de negocios. Este tipo de middleware generalmente provee de
mecanismos que permitirán la implementación de los requisitos de alarmas financieras del
sistema y la implementación de la exportación de los reportes a formatos como, por ejemplo,
PDF. Trabajará obteniendo la información principalmente del almacén de datos de la CGN,
que es un repositorio especial para procesamiento analítico, que correrá sobre el motor de
bases de datos (este almacén de datos se denomina técnicamente "data mart ROLAP", por
Modelo Conceptual del SIIF2 01/04/2014 176/203
las siglas del inglés de Procesamiento Analítico en Línea bajo tecnología Relacional), y que a
su vez se alimentará mediante un motor de extracción, transformación y carga.
REQ 8-6 Motor de Inteligencia de Negocios
La CGN ya cuenta con un Motor de Inteligencia de Negocios. Los siguientes requerimientos
son planteados en la eventualidad que se requiriera su reemplazo.
Debido a la pérdida de conocimiento organizacional que se produciría con un cambio del
producto, su remplazo no se recomienda. En cambio, se recomienda evaluar la actualización
a la versión más reciente.
Debe proveer de un ambiente para la creación de reportes, que permita la definición de
reportes dinámicos e interactivos. Los reportes deben poder incorporar formatos variados
de presentación como por ejemplo tablas y gráficos, los que se actualicen
automáticamente de acuerdo a los datos almacenados en los repositorios de la
aplicación.
Debe brindar soporte para la construcción de reportes analíticos, donde sea posible
interactuar con la estructura de la información almacenada en los repositorios,
permitiendo reordenar la información de acuerdo a las necesidades del análisis, realizar
pivoteo de filas y columnas, y mantener los datos calculados para la presentación.
Debe proveer de componentes y conectores que permiten acceder a fuentes de distintas
fuentes de información como: las bases de datos relacionales de sistemas
transaccionales, el almacén de datos de la CGN, archivos de datos, etc.
Debe contar con mecanismos de soporte para la creación y subscripción de alertas y
alarmas de negocio.
Debe proveer mecanismos de administración de modelos de datos, que den soporte a
los reportes e informes y permitan separar el espacio de publicación de un reporte, de su
ambiente de administración y construcción.
Debe proveer componentes que permitan el acceso a sus contenidos y a sus
funcionalidades por el portal Web 2.0 seleccionado para la plataforma.
Debe tener mecanismos que permitan la integración con herramientas de oficina como
por ejemplo Microsoft Office, que permitan visualizar reportes en el equipo local del
usuario.
Debe poder integrarse a los componentes de seguridad que se elijan para la plataforma,
y de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe proveer mecanismos de autorización de granularidad fina que puedan ser
aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma.
Debe soportar la autenticación mediante los mecanismos de SSO que se elijan para la
plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
Modelo Conceptual del SIIF2 01/04/2014 177/203
8.2.5 Motor de Gestión de Datos Maestros
Ilustración 8-8 Motor de Gestión de Datos Maestros
El Motor de Gestión de Datos Maestros es un componente que implementa opciones para
administrar estructuras jerárquicas de información y atributos de uso común, permitiendo su
utilización en múltiples sistemas de la institución, y resguardando la integridad de la
información que se está distribuyendo mediante un repositorio único de datos maestros.
Con este componente la CGN puede consolidar, compartir, gobernar e identificar las
relaciones de sus datos maestros, y puede administrar los cambios de sus jerarquías y
relaciones. Con esto se hace posible la implementación de un proceso de gestión de los
cambios y el control el impacto que estos puedan tener, no sólo en el SIIF2, sino que en
todas las aplicaciones de la CGN que usen esta información.
El motor también permite fusionar datos jerárquicos de orígenes distintos, estableciendo las
relaciones y dependencias identificadas, dejando disponibles esta nueva información a la
Institución. Sus capacidades permiten apoyar vía middleware la implementación de los
requerimientos de Configuración del sistema. Debido a que junto a las estructuras jerárquicas
este middleware permite gestionar las relaciones entre ellas, su utilización brinda un apoyo
extra para la implementación de la integración entre el clasificador presupuestario y el plan
de cuentas contables.
En general, mucha información manejada en las instituciones de gobierno tiende a ser
utilizada y replicada en distintos sistemas. Por ejemplo, es recurrente que lo catálogos donde
se define la estructura de las instituciones del gobierno y los códigos que identifican a cada
una, los catálogos donde se definen los códigos de cuentas contables, o los catálogos donde
se definen los clasificadores presupuestarios, se almacenen en más de una base de datos.
Estos catálogos de información además tienen relaciones entre sí (por ejemplo, existen
relaciones entre el presupuesto y la contabilidad, o entre los catálogos de insumos y los
catálogos de cuentas contables, etc.). Cuando la información de uno de estos catálogos
cambia, muchas veces más de un sistema queda desactualizado, y se tienden a crear
inconsistencias de información a nivel de negocio muy difíciles de detectar y corregir. La
situación se hace mucho más compleja si se tiene en cuenta que en ocasiones hay cambios
mayores en este tipo de datos maestros, como por ejemplo cambios completos del plan de
cuentas de la Nación, creación de nuevos incisos, etc.
Modelo Conceptual del SIIF2 01/04/2014 178/203
Las responsabilidades del motor de gestión de datos maestros son:
Ser la “fuente única de la verdad” para esta información de impacto en múltiples
sistemas.
Ser el punto donde se centralicen los cambios tanto de sus valores como de sus las
relaciones.
Ser el mecanismo que se encargue de distribuir de manera íntegra y consistente esta
información al SIIF2 y cada sistema donde se requiera.
REQ 8-7 Motor de Gestión de Datos Maestros
Deben utilizarse los metadatos definidos y publicados en el catálogo de metadatos del
Estado administrado por AGESIC.
Debe permitir el almacenamiento centralizado, en una base de datos, de los dominios y
nodos definidos para las jerarquías registradas en la aplicación, basado en un modelo
abierto para el registro de los metadatos que definen estas estructuras.
Debe proveer de mecanismos de administración de los metadatos, que permitan el
registro de las relaciones entre nodos y dominios registrados.
Debe implementar todas las funcionalidades que permitan la apropiada gestión de los
atributos y propiedades de los datos maestros. Estos mecanismos deben permitir la
definición de propiedades y características centrales que pueden ser asociadas a los
nodos registrados. Debe además permitir la configuración de los dominios de manera
central.
Debe incorporar mecanismos para la validación, al momento de su ingreso, de la
consistencia de la información contenida en los nodos y dominios.
Debe proveer una plataforma central de administración, con acceso vía Web, para el
manejo de las estructuras y los datos definidos, y que permita controlar eficazmente la
proliferación de estas definiciones.
Debe proveer de mecanismos de análisis de los datos maestros registrados, mediante
herramienta analíticas que permitan identificar relaciones y problemas.
Debe proveer de herramientas de migración de datos preferentemente basadas en
estándares como XML que permitan compartir las estructuras definidas en la aplicación
con el resto de las aplicaciones de la CGN.
Debe proveer mecanismos de administración de mezclas de información, que permitan la
importación de datos mediante mezcla o remplazo de nodos. Debe además proveer
mecanismos de automatización de cambios diferenciales para jerarquías existentes.
Debe proveer de servicios Web que permitan acceder a la información de los datos
maestros que se dispongan y facilitar así la integración con otros componentes.
Debe incorporar mecanismos que permitan soportar los procesos de cambio de las
jerarquías y dominios, mediante el registro de datos y metadatos para las estructuras
definidas, el análisis de las relaciones existentes entre las estructuras almacenadas y, en
base a esta información, permitir la administración de la liberación de nuevas versiones.
Debe poder integrarse a los componentes de seguridad que se elijan para la plataforma,
y de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe proveer mecanismos de autorización de granularidad fina que puedan ser
aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Modelo Conceptual del SIIF2 01/04/2014 179/203
8.3 Capa de Datos
En esta sección se presentan los elementos permiten el almacenamiento y manipulación de
la información persistente del sistema.
8.3.1 Motor de Bases de Datos Relacionales
Ilustración 8-9 Motor de Bases de Datos
El Motor de Bases de Datos Relacionales es el componente encargado soportar el
almacenamiento de los datos estructurados que se utilizan en el sistema. Para ello ofrece
mecanismos, como por ejemplo esquemas y tablas relacionales, que permiten reflejar la
estructura de las entidades que se almacenan y las relaciones entre sus atributos,
asegurando la consistencia de los datos de acuerdo a esta lógica. El motor permite la
definición de dominios de información y relaciones entre ellos, también implementa
habilidades básicas de gestión de estos dominios, que permiten crear, actualizar, borrar y
leer la información almacenada. Además, provee de soporte para generar procedimientos,
funciones y diversos mecanismos para el manejo y el acceso a los datos almacenados. Por
último, brinda mecanismos de respaldo, recuperación y administración de la información
almacenada.
Esta es una de las piezas más básicas y centrales del sistema, y es donde se mantendrán la
mayoría de los repositorios de datos del SIIF2, tanto de sus componentes transaccionales,
como de sus sistemas analíticos61
. Su uso no se restringe a los componentes desarrollados,
ya que varios componentes de middleware de la plataforma, como por ejemplo los
repositorios de credenciales, requieren de un motor de bases de datos para poder trabajar.
REQ 8-8 Motor de Bases de Datos Relacionales
Debido a que la CGN ya tiene un motor de bases datos relacionales y lo utiliza en varios de
sus sistemas actuales, no se recomienda un reemplazo, sino una actualización del existente
a su versión más reciente. La base de datos Oracle actualmente en uso en la CGN, permite
satisfacer todos los requerimientos que se mencionan a continuación. Sin embargo, se
61
Del levantamiento realizado para la plataforma del SIIF2, no se identificaron necesidades que
justifiquen la utilización de otras tecnologías para la construcción de bases de datos, como por ejemplo
los motores multidimensionales o los motores para el almacenamiento de objetos. Todas las
necesidades detectadas pueden ser cubiertas con sólo tecnología de bases de datos relacionales.
Modelo Conceptual del SIIF2 01/04/2014 180/203
recomienda implementar el motor con las opciones para replicación de datos, para utilizarlos
por ejemplo para la construcción de repositorios de datos operacionales, que permiten hacer
más eficientes los mecanismos de generación de reportes operacionales. Además, se
recomienda implementar la base de datos con mecanismos de particionamiento, y diseñar
los esquemas para que los aprovechen, con el fin de mejorar el desempeño de los módulos
transaccionales.
Debe proveer de mecanismos de seguridad de acceso.
Debe proveer de mecanismos de protección ante desastres mediante la descarga de las
operaciones de uso intensivo de recursos a una sola base de datos (stand-byfísica).
Debe proveer mecanismos de recuperar versiones anteriores de los datos.
Debe soportar la utilización de cintas de alto rendimiento para copias de seguridad de las
base de datos.
Debe poder trabajar con aplicaciones que corran sobre clústeres, permitiendo que
múltiples nodos establezcan múltiples conexiones.
Debe permitir soportar la creación de bases de datos para procesamiento analítico en
línea (OLAP).
Debe permitir la ejecución de procedimientos almacenados, funciones y triggers.
Debe proveer mecanismos de caché inteligente basados en la frecuencia de uso de los
datos.
Debe proveer mecanismos de auditoría que no generen distorsiones en la operación de
la base de datos.
Debe proveer herramientas u opciones que permitan el cifrado de los datos.
Debe proveer herramientas u opciones que permitan la replicación automática y en línea
de los contenidos de una base de datos.
Debe proveer mecanismos para la definición de particiones lógicas de esquemas.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento tanto horizontal (en base a topologías de
clúster), como vertical (en base a aumento de las capacidades del nodo en el que se
ejecuta).
8.3.2 Repositorio de Contenidos
Ilustración 8-10 Motor de Gestión de Contenidos
El Repositorio de Contenidos es un componente especializado en el trabajo con contenido no
estructurado (en contraste con el Motor de Bases de Datos presentado, que se especializa
Modelo Conceptual del SIIF2 01/04/2014 181/203
en el manejo de información estructurada). Estos contenidos pueden ser archivos en
diferentes formatos, como por ejemplo PDF, documentos Word, texto plano, etc. Pueden ser
también archivos multimedia, como videos e imágenes.
REQ 8-9 Repositorio de Contenidos
Debe proveer funcionalidades para el almacenado y recuperación de contenidos anexos
durante todo el ciclo de vida de los documentos que se gestionen en el sistema.
Debe proveer funcionalidades para que los usuarios del puedan sistema puedan acceder
a los contenidos almacenados de acuerdo a sus privilegios y roles.
Debe poder trabajar con más de una almacén de información, como por ejemplo bases
de datos y sistemas de archivos.
Debe proveer métodos de acceso acorde con los mecanismos de usabilidad del sistema.
Debe proveer servicios Web para el acceso a sus contenidos.
Debe proveer marcos de aplicación para la organización de documentos que permitan
realizar agrupaciones lógicas, configurar almacenamientos jerárquicos.
Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y
de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe proveer mecanismos de autorización de granularidad fina que puedan ser
aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma.
Debe soportar autenticación mediante los mecanismos de SSO que se elijan para la
plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
Debe proveer componentes que permitan el acceso a sus contenidos y a sus
funcionalidades por el portal Web 2.0 seleccionado para la plataforma.
8.3.3 Motor de Extracción Transformación y Carga
Ilustración 8-11 Motor de Extracción, Transformación y Carga
Este motor de Extracción, Transformación y Carga (más conocido como motor ETL, por el
inglés Extraction–Transformation–Load), brinda el soporte para preparar y mover la
información de negocio entre los distintos repositorios de datos del sistema. Provee
capacidades para:
Modelo Conceptual del SIIF2 01/04/2014 182/203
conectarse a múltiples fuentes de información, mediante distintos estándares y
adaptadores.
describir y configurar las transformaciones necesarias para poder cargar la
información a los repositorios de destino.
gestionar la ejecución del proceso de carga, e identificar los problemas que pudieran
surgir, lo que otorga mayor control y fiabilidad a estas actividades.
Esta pieza provee uno de los mecanismos que se espera se utilizarán para la obtención de la
información que necesitan los distintos componentes del SIIF2 (el otro son servicios Web).
En la propuesta para el sistema, el uso de ETL se limita a actividades de procesamiento por
lotes de grandes volúmenes, como por ejemplo la replicación de los datos operacionales a
repositorios de generación de reportes, o hacia el almacén de datos de la CGN. En este
contexto, el motor ETL es un componente central para el traspaso y limpieza de la
información contenida en bases de datos de procesamiento transaccional a las bases de
datos de procesamiento analítico que soportarán los reportes de gestión y el análisis de
inteligencia de negocios.
REQ 8-10 Motor de Extracción, Transformación y Carga
Debe proveer un entorno de diseño de cargas que no requiera conocimientos avanzados
de programación.
Debe proveer mecanismos de simulación y gestión del código generado.
Debe proveer mecanismos de conexión para múltiples tipos de fuentes, que trabajen con
contenido de distintas marcas de motores de bases de datos, sistemas de archivos,
archivos planos, sistemas ERP, sistemas CRM, sistemas B2B, archivos XML,
repositorios LDAP, fuentes JDBC u ODBC, etc.
Debe proveer mecanismos de lectura asincrónica de la información.
Debe proveer funcionalidades para soportar la gestión y la administración unificada del
proceso ETL, permitiendo a través de su consola importar y exportar a repositorios de
datos, la administración en tiempo real de las operaciones, la monitorización de las
sesiones ETL, el diagnóstico de errores, el diseño de artefactos y la generación de
informes.
Debe proveer un soporte mejorado para procesamiento analítico en línea, y una API que
puede ser utilizada directamente en aplicaciones.
Modelo Conceptual del SIIF2 01/04/2014 183/203
8.4 Capa de Integración
En esta sección se describen los elementos que soportan la ejecución de los componentes
que permiten la interoperación, tanto entre los elementos internos del SIIF2, como con
sistemas externos.
8.4.1 Bus de Servicios
Ilustración 8-12 Bus de Servicios
El Bus de Servicios es un componente que brinda una serie de mecanismos de soporte para
la implementación de la interacción y la comunicación – basada en el intercambio de
mensajes – entre los distintos servicios Web, tanto internos como externos al sistema. Sus
capacidades de transformación de datos, formatos, protocolos, unido a sus capacidades de
control de tráfico, enrutamiento y enriquecimiento de la información, lo hacen un componente
de gran valor técnico para la adecuada implementación de una arquitectura orientada a
servicios, que no sólo le permita a la CGN construir sistemas altamente flexibles y de bajos
niveles de acoplamiento, sino también capaces de conectarse e interoperar con sistemas de
otras instituciones, facilitando la implementación de los requerimientos de interoperabilidad
institucional y transversal.
Durante el levantamiento de información realizado para el sistema, se detectaron múltiples
necesidades de integración con sistemas externos, las que llevarán a la construcción de
múltiples proveedores de servicios Web, así como también de mecanismos para el consumo
Modelo Conceptual del SIIF2 01/04/2014 184/203
de servicios Web provistos por entidades externas a la CGN. La plataforma propuesta asume
un uso intensivo del bus, tanto para la comunicación entre servicios Web internos, como para
la comunicación con el exterior. Si dos servicios Web del sistema quieren intercambiar
información, deben hacerlo a través del bus62
. La propuesta también asume que, en el caso
de la comunicación con sistemas externos al SIIF2, el bus de la CGN se comunicará con la
Plataforma de Servicios Electrónicos del Estado provista por la AGESIC.
Los adaptadores que brinda el bus de servicios brindan la oportunidad de conectar fuentes
de información en sistemas que probablemente no puedan reconstruidos ni modificados para
trabajar en base al consumo y provisión de servicios.
REQ 8-11 Bus de Servicios
Debe soportar todos los protocolos estándar de definición de servicios Web definidos en
el WS-I Basic Profile en todas sus versiones.
Debe poder integrarse con el Motor de Gestión de Políticas de Servicio para el trabajo
con protocolos de servicios más avanzados, como por ejemplo WS-Trust, WS-Security y
WS-Addressing.
Debe brindar mecanismos de publicación y subscripción para múltiples orígenes y
destinos de información.
Debe brindar mecanismos de enrutamiento de mensajes, que permitan determinar el
servicio de destino de un mensaje entrante, y permitan gestionar los cambios que
puedan ocurrir en un servicio publicado en el Bus.
Debe permitir modalidades síncronas y asíncronas de despacho.
Debe proveer mecanismos de transformación de mensajes, que permitan adaptar los
mensajes generados en el origen para que cumplan con una o más características en el
destino.
Debe proveer mecanismos de aprovisionamiento de servicios, que permitan gestionar el
portafolio de servicios Web de CGN, sus versiones y los cambios que estos pudieran
implicar.
Debe brindar mecanismos de apoyo para la gestión de los acuerdos de niveles de
servicio establecidos para el SIIF2. Debe brindar herramientas que permitan la
monitorización del rendimiento de un servicio Web particular y permitir implementar
compromisos para su comportamiento y desempeño.
Debe proveer mecanismos de soporte y adaptación de protocolos de transporte de
mensajes.
Debe proveer mecanismos que permitan un rápido despliegue de los servicios Web
definidos para la integración de la plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
62
Aunque técnicamente es posible hacer una comunicación directa entre dos servicios Web y no utilizar
un bus, esto inhabilitará posibilidades como la virtualización de puntos de acceso, la capacidad de
incorporar aspectos de monitorización para el control de SLAs, etc.
Modelo Conceptual del SIIF2 01/04/2014 185/203
8.4.2 Motor de Gestión de Políticas de Servicios Web
Ilustración 8-13 Motor de Gestión de Políticas de Servicios Web
El Motor de Gestión de Políticas de Servicios Web permite el trabajo con varios de los
protocolos para servicios Web denominados de segunda generación, o protocolos WS-*, los
que permiten, por ejemplo, incorporar mecanismos de seguridad63
, soportar mecanismos de
comunicación robusta, definir políticas para la gestión de niveles de servicio, etc.
Junto con tener la capacidad de actuar como punto de control de las políticas de seguridad
(PEP por el inglés Policy Enforcement Point), este componente permite definirlas,
gestionarlas, y almacenarlas centralizadamente. Permite además aplicar una misma política
a uno o más servicios, por separado o como grupo, lo que contribuye importantemente al
adecuado gobierno de los activos SOA en la organización.
El Motor de Gestión de Políticas de Servicios Web permite incorporar, a nivel de los
mensajes que fluyen en un sistema orientado a servicios, consideraciones de autenticación,
autorización, confidencialidad, integridad y no repudio.
La plataforma utiliza a este componente como un refuerzo a los mecanismos de seguridad,
orientado específicamente para el trabajo con servicios Web. Trabaja directamente con el
Bus de Servicios, dotándolo de capacidad para el trabajo con protocolos avanzados, y
conectándose con los repositorios de credenciales y los mecanismos de identificación y
control de acceso. La incorporación de este componente permitirá complementar el conjunto
de protocolos para servicios Web soportados por la plataforma del SIIF2 y así asegurar, por
ejemplo, que se pueda trabajar fluidamente a través de la PGE.
REQ 8-12 Motor de Gestión de Políticas de Servicios Web
Debe brindar mecanismos para la administración de políticas de servicios Web,
habilitando su almacenamiento y mantención de acuerdo a los estándares soportados.
Debe proveer de mecanismos que permitan monitorizar la ejecución de las políticas
definidas y asociadas a los servicios.
Debe permitir el trabajo con los siguientes estándares:
Todos los definidos por el WS-I Basic Profile, en todas las versiones del perfil.
63
La seguridad en servicios Web tiene requerimientos extra que no son satisfechos por los otros
componentes de seguridad mencionados previamente para la plataforma.
Modelo Conceptual del SIIF2 01/04/2014 186/203
Todos los definidos por el WS-IBasic Security Profile, en todas las versiones del
perfil.
Todos los que se requieran para tener una compatibilidad completa con la PGE.
Debe poder integrarse a los componentes de seguridad que se elijan para la plataforma,
y de utilizarlos para delegar las actividades de identificación (incluyendo SSO) y control
de acceso para autorización de granularidad gruesa y fina de los servicios Web.
Alternativamente, de no poder integrarse, debe proveer de mecanismos que cumplan
todos los requerimientos de seguridad del sistema.
Debe poder ser aprovisionado por el Motor de Aprovisionamiento escogido para la
plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
8.5 Capa de Seguridad
Esta sección describe los componentes de la plataforma que permiten otorgar al SIIF2 los
niveles adecuados de identificación, aseguramiento, no repudio e integridad.
8.5.1 Mecanismo de Identificación
Ilustración 8-14 Mecanismo de Identificación
El Mecanismo de Identificación se encarga solicitar y validar las credenciales que presenten
los sistemas externos o usuarios que deseen acceder al sistema, con el fin de establecer si
son auténticas. Trabajando con otros componentes de la plataforma, como por ejemplo los
repositorios de credenciales y los mecanismos de autorización, permite implementar
mecanismos para la acreditación de las entidades de quienes intentan acceder al sistema,
información que puede ser utilizada posteriormente para auditoría y control de acceso.
Esta pieza es imprescindible para la implementación de niveles de seguridad acordes a una
aplicación como el SIIF2. En la plataforma constituye el punto central para la acreditación de
la identidad previa al acceso a los recursos del sistema.
Se asume que estará conectado directamente al primer punto de acceso de la aplicación, ya
sea este un dispositivo especializado (como por ejemplo un balanceador de hardware con
Modelo Conceptual del SIIF2 01/04/2014 187/203
capacidad de proxy reverso), o un componente más genérico (como por ejemplo un servidor
Web con módulos adicionados para este fin).
REQ 8-13 Mecanismo de Identificación
Debe soportar mecanismos de autenticación por usuario y contraseña.
Debe soportar mecanismos de autenticación en base a certificados X.509.
Debe soportar mecanismos de autenticación en base a una infraestructura de clave
pública que pueda ser validada en línea contra una Entidad Certificadora acreditada por
el Gobierno.
Debe poder integrarse con los demás mecanismos de seguridad escogidos para la
plataforma.
Debe poder obtener las credenciales para el control de acceso de los directorios de
credenciales seleccionados para la plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
8.5.2 Mecanismo de Single Sign–on
Ilustración 8-15 Mecanismo de Single Sign-on
El mecanismo de Single Sign–on amplía las capacidades del mecanismo de identificación,
permitiendo compartir de manera transparente la identidad de un usuario entre diferentes
componentes del sistema, e incluso entre distintos sistemas. Debido a que las diferentes
piezas del sistema se construyen en función de diferentes piezas de middleware (o de
software de aplicación), y estas pueden manejar la autenticación de sus usuarios de manera
diferente, en ausencia de este componente probablemente el usuario tenga que ingresar
múltiples veces su identificación y contraseña, lo que se transformará rápidamente en una
molestia.
La plataforma del SIIF2 incorpora a esta pieza para mejorar tanto la seguridad como la
usabilidad del sistema, y es la encargada de lograr que a cada usuario se le pregunten sus
credenciales una única vez, haciéndose cargo de cualquiera necesidad de reingreso de esta
información, logrando que el hecho de que hayan múltiples sistemas conectados, con
Modelo Conceptual del SIIF2 01/04/2014 188/203
diferentes mecanismos de manejo de su identidad, sea transparente para el usuario y no
impacte la fluidez de su trabajo.
REQ 8-14 Mecanismo de Single Sign-on
Debe estar integrado, o poder Integrarse al mecanismo de Identificación seleccionado
para la plataforma
Debe poder trabajar, como mínimo, bajo protocolos HTTP y HTTPS.
Debe proveer soporte para utilización SAML en su versión 1.0, 1.1 y 2.0.
8.5.3 Mecanismo de Autorización
Ilustración 8-16 Mecanismo de Autorización
El Mecanismo de Autorización se encarga de resguardar la utilización de los recursos del
sistema. Trabajando con otros componentes de la plataforma, como por ejemplo los
repositorios de credenciales y el mecanismo de identificación, permite implementar un
adecuado control de acceso a los recursos del sistema, permitiendo la definición y control de
políticas de acceso, que habiliten su utilización a los usuarios que cuenten con los privilegios
adecuados, y restrinjan su utilización a quienes no los tengan. Incorpora además
mecanismos de auditoría que permitirán hacer seguimiento de actividades sospechosas,
intentos de acceso no autorizado y análisis forense tras ataques de seguridad.
Al igual que el mecanismo de identificación, esta pieza es imprescindible para la
implementación de niveles de seguridad acordes a una aplicación como el SIIF2. En la
plataforma constituye el punto central para el control de acceso de cada uno de los recursos.
Se asume que estará conectado directamente al primer punto de acceso de la aplicación, ya
sea este un dispositivo especializado (como por ejemplo un balanceador de hardware con
capacidad de proxy reverso), o un componente más genérico (como por ejemplo un servidor
Web con módulos adicionados para este fin). Sin embargo, por motivos de desempeño, se
sugiere que su utilización se restrinja al control de acceso de granularidad gruesa, dejando el
control de acceso de granularidad fina a cada uno de los componentes de la plataforma que
permitan esta funcionalidad.
Modelo Conceptual del SIIF2 01/04/2014 189/203
REQ 8-15 Mecanismo de Autorización
Debe proveer mecanismos que permitan la gestión centralizada de las políticas de
acceso
Debe proveer mecanismos que permitan la efectiva aplicación y control de las políticas
de acceso.
Debe permitir la definición de zonas de seguridad para Single Sign–on.
Debe proveer de un modelo de políticas nativas y además políticas compartidas entre
componentes.
Debe proveer de mecanismos que permitan probar las políticas antes de ponerlas en
producción
Debe proveer de un mecanismo de auditoría para cada uno de los componentes del
sistema que se requiera.
Debe proveer mecanismos que permitan la definición de métricas e indicadores para la
monitorización del desempeño del mecanismo de control de acceso.
Debe soporta la integración con servicios de seguridad vía tokens.
Debe proveer de una API para los desarrolladores de componentes de seguridad y que
permita su acceso programático por los componentes que se desarrollen para el SIIF2.
Debe poder obtener las credenciales para el control de acceso de los directorios de
credenciales seleccionados para la plataforma.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
8.5.4 Directorios de Credenciales
Ilustración 8-17 Directorios de Credenciales
Un Directorio de Credenciales es un repositorio especializado para el almacenamiento de
credenciales de seguridad – tanto de identificación, como de control de acceso – de los
usuarios y componentes del sistema, y que maneja estructuras optimizadas para su fácil
manejo y administración. Debido a que los datos contenidos en un directorio de credenciales
normalmente se leen mucho más de lo que se escriben, los directorios no implementan
normalmente los complicados esquemas para transacciones de los motores de bases de
Modelo Conceptual del SIIF2 01/04/2014 190/203
datos64
. Las actualizaciones en un directorio también son usualmente cambios sencillos y no
de grandes volúmenes de datos.
La plataforma del SIIF2 considera a esta pieza como el elemento principal de
almacenamiento de credenciales de seguridad. Aunque todas las credenciales de
identificación pueden ser almacenadas en un mismo esquema, no siempre esto es posible
para las credenciales de autorización, pues estas pueden ser dependientes del producto que
las utilice. Es por esto que se anticipa que habrá varias instancias de este tipo de
componente en producción.
Por lo que sí se debe velar, es que el repositorio de credenciales de identificación sea único,
para evitar tener que incorporar innecesariamente middleware para la virtualización de
directorios, y de complicar innecesariamente los mecanismos de aprovisionamiento.
REQ 8-16 Directorios de Credenciales
Debe proveer soporte para almacenamiento en múltiples contextos de seguridad.
Debe proveer soporte para la administración centralizada de recursos para el sistema.
Debe proveer soporte para su integración con otros directorios.
Debe proveer mecanismos para replicación de datos a múltiples directorios de servicios.
Debe soportar los estándares LDAP v3, Microsoft ADS o el que se requiera para que
todos los componentes de la plataforma puedan acceder de manera estándar.
Debe permitir que las credenciales con las que trabaja sean abastecidas por el Motor de
Aprovisionamiento escogido para la plataforma.
Capacidad para la seguridad de datos en transporte, almacenamiento y respaldo.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activo-
activo) y con capacidad de escalamiento horizontal (en base a topologías de clúster).
8.5.5 Mecanismo de Aprovisionamiento de Usuarios
Ilustración 8-18 Mecanismo de Aprovisionamiento de Usuarios
64
Técnicamente es válido, sin embargo, usar un motor de bases de datos relacional como back end
para un directorio de credenciales.
Modelo Conceptual del SIIF2 01/04/2014 191/203
El Mecanismo de Aprovisionamiento de Usuarios entrega soporte para la administración
segura de los recursos del sistema, tales como las cuentas de usuarios y sus privilegios de
acceso. Apoya en cada etapa de la administración del ciclo de vida de las identidades y los
roles en la aplicación, permitiendo su correcta asignación a los usuarios del sistema, y la
habilitación de esta información a los componentes que la requieran.
La utilización de este componente permite tanto la centralización de la administración de los
recursos del sistema (que el equipo de la CGN lleve la administración de todas las
credenciales), como la segregación controlada de las responsabilidades de administración a
otros instituciones (que la CGN pueda definir administradores pertenecientes a las incisos
usuarios del SIIF2, y sean estos quienes lleven la administración de sus respectivos
usuarios), fomentando fuertemente la eficiencia en la operación productiva del sistema. Es
importante destacar que el soporte de la administración descentralizada, impone el
requerimiento de que el Motor de Aprovisionamiento cuente con un Mecanismo de
Autorización Descentralizada, y que este pueda ser integrado al portal de la plataforma o,
como mínimo, presentado vía una aplicación Web.
La plataforma considera a esta pieza como el ambiente donde se efectuaran todas las
configuraciones que necesite el sistema, en lo referente a la asignación de los recursos,
usuarios y roles. A través de una interfaz web de administración, permitirá de forma rápida el
bloqueo o autorización de funciones a un usuario o un grupo de éstos. También permitirá la
integración con diferentes fuentes de credenciales de seguridad (como por ejemplo
servidores LDAP o Active Directory), lo que facilitará su integración y le otorgará flexibilidad
mayor en cuanto al aprovisionamiento de usuarios. Tras el levantamiento realizado, se debe
considerar como deseable, más no requerido que este componente pueda ser desplegado en
una topología multicapas, y en clúster, permitiendo anticiparse a potenciales problemas de
rendimiento y escalabilidad.
REQ 8-17 Mecanismo de Aprovisionamiento de Usuarios
Debe proveer soporte para todo el ciclo de vida de la identidad y los roles del sistema.
Debe proveer soporte para todo el ciclo de vida de las políticas de acceso de la
aplicación.
Debe proveer un mecanismo de autogestión de credenciales, o tener la capacidad de
integrarse a uno.
Debe proveer mecanismos que permitan la segregación de responsabilidades de
administración de usuarios y accesos. La interfaz de este mecanismo debe poder ser
desplegada o invocada desde el portal Web del sistema.
Debe proveer soporte para servicios de reconciliación ante conflictos en la gestión de sus
recursos.
Debe proveer soporte para definiciones de seguridad orientadas servicios.
Debe poder conectarse y aprovisionar los directorios de credenciales que se escojan
para la plataforma.
Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y
de utilizarlos para delegar las actividades de identificación y control de acceso para
autorización de granularidad gruesa a sus contenidos.
Debe proveer mecanismos de autorización de granularidad fina.
Debe proveer mecanismos que permitan la monitorización de comportamiento y salud
mediante el monitor que se seleccione para la plataforma.
Modelo Conceptual del SIIF2 01/04/2014 192/203
Debe permitir desplegar su mecanismo de autogestión de credenciales en el portal Web
2.0, o como alternativa, este mecanismo debe ser una aplicación Web que pueda ser
integrada con los mecanismos de seguridad y monitorización de la plataforma.
8.5.6 Mecanismo de Autogestión de Credenciales
Ilustración 8-19 Mecanismo de Autogestión de Credenciales
El Mecanismo de Autogestión de Credenciales permite a los mismos usuarios modificar su
información personal en el sistema, como por ejemplo sus datos de contacto, su contraseña,
etc., mediante funcionalidades de fácil uso, y provistas de manera segura a través de la
Internet. Este componente generalmente viene incluido como parte de otros productos de
seguridad.
La plataforma incluye esta pieza debido a la experiencia que se ha tenido en otros sistemas
de gran escala similares al SIIF2, donde la administración de la información de los usuarios
se vuelve una tarea de consumo intensivo de recursos humanos. La incorporación de esta
pieza permitirá reducir la demanda sobre la mesa de ayuda que se implemente para el SIIF2,
debido a que permitirá a los propios usuarios resolver solicitudes de cambio de claves y
solicitudes por problemas de acceso, lo que se traducirá en una reducción importante y
cuantificable de los costos asociados al soporte del sistema.
REQ 8-18 Mecanismo de Autogestión de Credenciales
Debe poder integrarse o estar integrado al mecanismo de aprovisionamiento de la
plataforma.
Debe incluir mecanismos que permitan el aprovisionamiento automático de los cambios
que se introduzcan en función de este componente.
Debe poder trabajar con los mecanismos de integración con los componentes de la suite,
como por ejemplo, Single Sign-on, el Mecanismo de Autorización y los Directorios de
Credenciales.
Debe permitir su despliegue seguro en el portal Web 2.0, o como alternativa, este
mecanismo debe ser una aplicación Web que pueda ser integrada con los mecanismos
de seguridad y monitorización de la plataforma.
Modelo Conceptual del SIIF2 01/04/2014 193/203
8.6 Elementos Arquitectónicos de Monitoreo
Esta sección define los componentes de monitorización de la plataforma, que si bien no
influenciaran mayormente el desarrollo del sistema, resultan altamente relevantes para su
correcta operación.
8.6.1 Monitor de Infraestructura
Ilustración 8-20 Monitor de Infraestructura
El Monitor de Infraestructura es el encargado de entregar una visión unificada del
rendimiento y la salud de cada uno de los componentes de middleware del sistema65
.
También permite la gestión centralizada de su configuración, la supervisión de sus niveles de
servicios y provee de operaciones de automatización para mejorar la eficiencia de sus
operarios. Mediante mecanismos de ajuste inteligente de la configuración del middleware
subyacente, permite mejorar el rendimiento y disponibilidad de las aplicaciones y servicios
Web, reduciendo tiempos de inactividad de las infraestructura y reduciendo el costo de
administración de la plataforma.
La plataforma considera a esta pieza como un elemento clave para su correcta operación,
debido a que el gran número de componentes que la conforman hace que la monitorización y
administración sean notablemente complejas, lo que en ausencia de un componente como
éste, elevan los riesgos de errores, y de detección tardía de malfuncionamientos e
indisponibilidades.
Todos los grandes proveedores de tecnologías de middleware ofrecen algún tipo de sistema
de monitorización. Sin embargo, generalmente están optimizados para trabajar con
middleware de un mismo proveedor, lo que hace inconveniente mezclar middleware de
distintas marcas.
65
La plataforma sólo define este componente para la monitorización del middleware. Se asume que
existirán mecanismos para la monitorización de la infraestructura de hardware, pero su definición esta
fuera del alcance de este documento.
Modelo Conceptual del SIIF2 01/04/2014 194/203
En consideración a lo anterior, de seleccionarse múltiples proveedores para distintos
componentes de middleware, se deberá incorporar dentro de los requerimientos de los
distintos productos la capacidad de generar métricas que puedan ser capturadas por el
mecanismo de monitorización.
REQ 8-19 Monitor de Infraestructura
Debe proveer mecanismos de monitorización centralizada del desempeño y el estado de
la plataforma, que puedan ser configurados para permitir la monitorización de los
acuerdos de niveles de servicio que se comprometan para el SIIF2.
Debe proveer mecanismos de monitorización centralizada de la salud de las instancias, y
mecanismos para la mitigación automática de los problemas de disponibilidad.
Debe proveer un API y conectores que permitan desarrollar generadores de métricas
para monitorización.
Debe poder generar reportes de periodicidad configurable, que permitan la actualización
de los resultados de la medición en el momento que aparece nueva información.
Debe contar con mecanismos que permitan la parametrización y especialización de los
reportes que genere, por parte de usuarios sin conocimientos avanzados de
programación.
Debe poder capturar la información los elementos monitorizados en base a una
periodicidad configurable.
Debe poder detectar automáticamente cambios en las condiciones de la infraestructura.
8.6.2 Monitor de Uso del Sistema
Ilustración 8-21 Monitor de Uso del Sistema
Este componente recopila información acerca de la utilización y acceso a las distintas
páginas del sistema, y permite analizar la información de la actividad generada en los
servidores de la institución.
Con esta pieza, es posible tener información clara acerca del comportamiento de los usuarios
del sistema, lo que resulta extremadamente valioso en los períodos tempranos de salida a
producción e implantación del sistema, ya que permite tener información oportuna de la tasa
de adopción por parte de las instituciones usuarias.
La incorporación de este componente en la plataforma del SIIF2 tiene razones políticas y
técnicas. Las estadísticas que genera permite entregar a las autoridades información clara y
precisa acerca de, por ejemplo, los lugares del país de donde se está accediendo al sistema,
los momentos del día donde hay más utilización, y el número de usuarios por inciso o unidad
ejecutora que se está soportando, etc. Este tipo de información comienza a ser de gran valor
Modelo Conceptual del SIIF2 01/04/2014 195/203
a partir de las pruebas beta del sistema, y se vuelve mucho más relevante durante su periodo
de implantación, donde junto con permitir mostrar avances en este proceso, permite
anticiparse a las demandas de hardware que progresivamente ira teniendo el sistema.
REQ 8-20 Monitor de Uso del Sistema
Debe proveer de mecanismos de captura de información, mediante un componente que
pueda ser invocado desde las páginas cliente del portal escogido para la plataforma,
como por ejemplo un script en lenguaje JavaScript, para la captura de las métricas de
utilización del sistema. Este mecanismo de captura debe ser configurable y debe poder
ser localizado en cada una de las pantallas que se desee monitorear.
Debe proveer de un mecanismo de envío de las métricas, mediante el protocolo HTTP o
HTTPS, a un servidor de información central.
Debe proveer de un ambiente de despliegue de reportes, informes, gráficos e
información analítica de resultados. Este ambiente debe permitir configurar las salidas de
información de acuerdo a las necesidades de la CGN.
Debe permitir la configuración de la frecuencia de captura de las métricas y la generación
de informes.
8.7 Consideraciones sobre la Arquitectura
Diversas situaciones pueden hacer que la plataforma propuesta no pueda ser implementada
en el desarrollo del SIIF2. A modo de ejemplo, pueden existir limitaciones tecnológicas,
debido a las características del ambiente de producción, operativas, debido a la
disponibilidad de personal de la CGN para operar los componentes, limitaciones
presupuestarias, etc. También por el lado del proveedor pueden aparecer limitaciones, como
por ejemplo la falta de conocimientos para poder trabajar con algún componente específico.
Esta sección presenta algunos elementos extras a la definición de la plataforma de
middleware, destinados a apoyar la toma de decisiones ante la eventualidad de que la
plataforma no pueda ser implementada exactamente como se plantea, o se considere
inconveniente hacerlo por algún otro factor. En particular se presenta un ejemplo de alto nivel
de un despliegue factible para la plataforma, y un análisis de las situaciones que de éste se
desprenden, y una tabla respecto de recomendaciones acerca de que componentes podrían
ser descartados en la eventualidad de limitaciones.
8.7.1 Ejemplo de topología de despliegue para la plataforma
La Ilustración 8- 22 Modelo de ejemplo de topología de despliegue de la Plataforma de
Middleware del SIIF2 presenta un modelo de despliegue para la plataforma del SIIF266
.
Debido a que las ofertas de middleware en el mercado tienen diferentes limitaciones,
características y requerimientos dependiendo de su marca, y que no es posible esta
66
Las líneas de unión entre las distintas instancias de nodos de despliegues se denominan links, e
indican que los nodos conectados pueden transmitir entre sí mensajes y señales. En los diagramas de
las secciones anteriores, las líneas representan relaciones conceptuales entre los componentes, que se
manifiestan como conectores entre sus instancias. La relación entre links y conectores no es uno a uno,
ya que múltiples conectores pueden manifestarse a través de un mismo link. El nivel de abstracción
entre este modelo y los anteriores es diferente, y su explicación detallada está disponible en la
especificación de UML 2.4.1.
Modelo Conceptual del SIIF2 01/04/2014 196/203
variabilidad de capturar sin tener que entrar en los detalles específicos de la oferta de cada
proveedor, este diagrama debe ser considerado sólo como un ejemplo, y se recomienda
revisarlo una vez implementada la línea base arquitectónica para el sistema.
Ilustración 8- 22 Modelo de ejemplo de topología de despliegue de la Plataforma de Middleware del SIIF2
El diagrama permite identificar algunas situaciones que con un alto grado de probabilidad se
manifiesten, independientemente del proveedor de tecnología, y que en consecuencia deben
ser consideradas antes de la adquisición de los distintos componentes:
Gran cantidad de piezas de middleware, como por ejemplo el portal, el repositorio de
contenidos, etc., requieren de una base de datos de infraestructura para operar.
Debido a que algunos de ellos se instalan en segmentos de red más inseguros, , se
deberá decidir si se instala un repositorio de propósito específico para las
necesidades del middleware, o se harán excepciones a las políticas de acceso (a
nivel de cortafuegos, por ejemplo), para que un middleware que está en un segmento
de red más expuesto pueda acceder a los repositorios de bases de datos. La
decisión incidirá directamente en los costos de licenciamiento de bases de datos. Se
recomienda considerar una instalación compartida de estas bases de datos de
infraestructura, dentro de la misma instancia que el sistema transaccional, con el fin
Modelo Conceptual del SIIF2 01/04/2014 197/203
de tener una topología de despliegue más sencilla, reducir el número de licencias al
mínimo necesario para operar adecuadamente67
, a costo de tener que incorporar
más excepciones al firewall.
La diversidad de piezas implica nuevos conocimientos de administración, mayor
necesidad de consultorías de instalación, configuración y ajuste, así como mayor
tiempo involucrado para la salida a producción. Se debe tener presente que la
habilitación de un ambiente de este tipo puede tomar más de seis meses de trabajo,
además del tiempo de adquisición y habilitación de los ambientes de hardware.
En la medida de que existan competencias internas, o que puedan ser adquiridas en
el mercado local, se recomienda la utilización de tecnologías de virtualización para
los nodos que alojarán los productos de middleware, pues la experiencia en
proyectos anteriores permite afirmar que los niveles de flexibilidad, disponibilidad y
aprovechamiento de los recursos de hardware pueden ser mucho mayores que si
sólo se trabaja con nodos físicos. En tiempo de desarrollo, donde pueden aparecer
necesidades de múltiples ambientes en paralelo, el uso de virtualización puede evitar
los retrasos derivados de su indisponibilidad. Sin embargo, se debe tener en cuenta
que los proveedores de middleware tienen esquemas de licenciamiento diferentes
para ambientes virtualizados, los cuales deben ser abordados durante la negociación
de compra para evitar costos no anticipados.
No se recomienda virtualizar los nodos de bases de datos, debido a que se ha
observado que esta es una práctica de poco uso en la industria y probablemente
haya poca experiencia local.
En la topología se puede apreciar que aparecen dos buses encadenados (los dos
internos a la CGN). El bus más exterior está centrado en mediar la interoperación
con los sistemas externos al SIIF2 y, en general, a la CGN. Para este bus se asume
una potencial necesidad de transformación de protocolos, formatos e incluso
enriquecimiento de información. Además, en este bus se asume se argumentarán los
mensajes con protocolos WS-* requeridos por instituciones como por ejemplo la
AGESIC (WS-Security, WS-Trust, etc.).
El segundo bus tiene como fin mediar entre los servicios internos para la CGN,
donde se asume confianza entre ellos, delegando temas como el control de acceso,
firma electrónica, encriptación, etc. al perímetro resguardado por el bus externo. Una
topología de este tipo permite aprovechar los beneficios de un bus de servicios de
manera local al SIIF2, mejorando así la latencia en la comunicación de los servicios
que no necesiten salir al exterior. Con este bus, se pueden incorporar
funcionalidades transversales (logging, captura de SLAs, encolamiento, e incluso
manejo transaccional, etc.), como aspectos del sistema, además de tener la
capacidad de incorporar adaptadores a sistemas legados.
La topología de buses encadenados es completamente opcional (así como el uso de
un esquema de seguridad perimetral), y se puede construir el SIIF2 incluso sin un
bus de servicios, conectando sus servicios Web construidos en modalidad punto a
punto. La topología propuesta permite, a costo de más licencias y mayor complejidad
topológica, lograr una mejor separación de preocupaciones y la capacidad de
67
Instalar otro servidor de bases de datos en una zona de red más expuesta, para atender las
necesidades del middleware de estas capas, no solo es innecesario, sino que implicará adquirir más
licencias de bases de datos, y tener que administrar más instancias.
Modelo Conceptual del SIIF2 01/04/2014 198/203
implementar funcionalidades transversales con un fuerte nivel de apalancamiento en
base a middleware, reduciendo así los riesgos inherentes a los desarrollos a medida.
En el diagrama se puede apreciar que el único componente destinado a presentar
contenidos a los usuarios del sistema es el portal. En este esquema, tanto los
usuarios de inteligencia de negocios, como los operacionales accederían a sus
respectivas funcionalidades utilizando un mismo tipo de middleware, lo que facilitaría
la estandarización de la presentación de los contenidos, no sólo del SIIF2, sino de
cualquier sistema que se construyera bajo este esquema.
Un mayor apalancamiento en base a middleware, tiene como riesgo el tener que
lidiar con esquemas de seguridad no integrados para las distintas piezas. Esto puede
llevar a la necesidad de tener que incorporar mecanismos de single sign-on incluso
dentro del mismo SIIF2. Un ejemplo de esto es la relación entre el portal y el sistema
de gestión de contenidos, o entre el portal y el sistema de inteligencia de negocios.
La complejidad producto de la gran cantidad de componentes se puede ver
fuertemente incrementada si los componentes pertenecen a distintos proveedores,
debido a que a los esfuerzos de instalación deben sumarse los de integración, que
probablemente requieran distintas empresas consultoras. Producto de esto, resulta
altamente recomendable elegir un solo proveedor para todas las piezas.
Las consideraciones presentadas, y las que de seguro aparecerán una vez escogido el
proveedor de tecnología, hacen recomendable limitar las adquisiciones de middleware a lo
estrictamente necesario para tener soporte en el desarrollo y realizar un adecuado
dimensionamiento de la plataforma completa. Esto hará que, en el peor caso, los costos en
esta área se limiten a lo requerido para armar los clústeres en aquellas piezas que así lo
requieren para asegurar su alta disponibilidad68
. Se recomienda comprar el total de las
licencias sólo después de haber realizado pruebas de dimensionamiento sobre, el código de
la línea base de la arquitectura, que en una metodología como RUP (con SOMA para la parte
de servicios Web), debiera ocurrir antes de que se haya incurrido en, aproximadamente, el
30% del esfuerzo de desarrollo.
8.7.2 Tabla de recomendaciones ante contingencias que impidan la
adquisición de un componente de la plataforma.
La siguiente tabla clasifica los distintos componentes de la plataforma en función de la
criticidad percibida para el logro de los atributos de calidad identificados para el SIIF2. Las
categorías utilizadas son las siguientes:
Requerido: Sin el componente, resulta muy poco probable el logro de los objetivos
del proyecto en plazos razonables. Los elementos en esta categoría constituyen la
plataforma más básica para la construcción del sistema
Altamente recomendado: El componente otorga niveles de apalancamiento que
resultan muy difíciles de lograr mediante programación a medida. Sacarlos de la
plataforma requerirá de programación especializada y hará difícil el cumplimiento de
los requerimientos técnicos del proyecto.
68
Hay proveedores de middleware que incluso permiten trabajar sin comprar licencias mientras su uso
sea para desarrollo o prototipado. En este caso, sólo habría que adquirir soporte en las piezas que se
requiriesen.
Modelo Conceptual del SIIF2 01/04/2014 199/203
Recomendado: El componente puede ser reemplazado por desarrollos a la medida
dentro de los tiempos del proyecto, o por mecanismos provistos por otras piezas
dentro de la misma plataforma69
, sin embargo, su incorporación no sólo apalanca el
desarrollo, sino que permite incorporar a la CGN nuevas capacidades institucionales
que pueden ser aprovechadas no sólo para el SIIF2, sino que para otros sistemas a
desarrollar. Los componentes en esta categoría fueron incorporados no sólo
pensando en el desarrollo del SIIF2, sino que en establecer una plataforma unificada
para éste y los futuros sistemas en la CGN.
A considerar: El componente no incide directamente en el desarrollo del SIIF2, sino
que de manera indirecta, debido a que refuerza áreas como su operación,
manutención e implantación. La excepción a esto es el sistema de Gestión de Datos
Maestros, que aunque provee funcionalidades que directamente inciden en el
desarrollo, se asigna a esta categoría dado que su alto costo potencial hace
aconsejable que se evalúe su incorporación, considerando que el retorno a la
inversión asociada no se dará tras la implementación del SIIF2, sino que a medida
que se utilice de manera creciente en nuevos desarrollos.
En base a esta taxonomía, la inclusión de los componentes se valora en la siguiente tabla:
Componente Criticidad
Servidor de Aplicaciones Requerido
Motor de Bases de Datos Relacionales Requerido
Motor de Inteligencia de Negocios Altamente recomendado
Bus de Servicios Altamente Recomendado
Motor de Gestión de Políticas de Servicios Web Altamente Recomendado
Portal Web 2.0 Recomendado
Motor de Gestión de Contenidos Recomendado
Motor de Extracción, Transformación y Carga Recomendado
Motor de Orquestación de Procesos de Negocio Recomendado
Mecanismo de Identificación Recomendado
Mecanismo de Single Sign-On Recomendado
Mecanismo de Autorización Recomendado
Directorios de Credenciales Recomendado
Motor de Reglas de Negocio Recomendado
Motor de Actividades de Negocio Recomendado
69
A modo de ejemplo, los servidores de aplicaciones traen mecanismos de identificación y control de
acceso. Si bien estos no tienen las mismas capacidades que un middleware dedicado, a través de ellos
es posible cumplir con parte de los requisitos en esta área.
Modelo Conceptual del SIIF2 01/04/2014 200/203
Mecanismos de Aprovisionamiento A considerar
Mecanismos de Autogestión de Claves A considerar
Monitor de Infraestructura A considerar
Motor de Gestión de Datos Maestros A considerar
Monitor de Uso del Sistema A considerar
Se podría aumentar la criticidad de los siguientes componentes, siempre que el costo lo
permita, dado que existe un gran riesgo en el tiempo de implementación y lo que no lo
brinden los componentes automáticamente, hay que desarrollarlo a mano:
Motor de Inteligencia de negocios.
Motor de Extracción, Transformación y Carga.
Motor de Orquestación de Procesos de Negocios.
Mecanismo de Single-Sign-On.
Modelo Conceptual del SIIF2 01/04/2014 201/203
9. Evaluación normativa
Este capítulo de Evaluación normativa se divide en un Anexo y dos sub-apartados. En el
Anexo I (Normativa Relacionada) se transcriben las normas que han sido identificadas y
seleccionadas como relevantes, y en los dos sub-apartados las normas relevantes son
evaluadas y se esboza el contenido sugerido para la nueva normativa a emitir.
Como se había anticipado, esta tarea permite comparar el marco jurídico vigente con el
modelo conceptual, a efectos de examinar su pertinencia y analizar la necesidad o
conveniencia de cambios al mismo.
9.1 Evaluación de las normas relevantes
Como señala la moderna Ciencia de la legislación -disciplina que tiene por objeto el estudio
de la norma jurídica desde su origen en las demandas sociales hasta su aplicación- en la
actualidad los marcos jurídicos se encuentran contenidos en una enorme documentación
acumulada en el tiempo, que plantea una necesidad de racionalidad70
, a efectos de
contrarrestar la llamada contaminación legislativa71
.
La racionalidad también tiene que ver con elegir las soluciones más adecuadas según los
fines previstos.
Las normas tienen racionalidad con respecto al fin cuando se adecuan a las políticas sociales
elegidas.
La nueva normativa deberá evitar toda “contaminación legislativa”, esto es, deberá
contemplar la necesidad de racionalidad, que permita la eliminación de las llamadas
“escorias” (normas derogadas o desaplicadas), además de ser consistente con el modelo
conceptual formulado.
Aunque es difícil concretar la idea rousseauniana de la existencia de “tan pocas normas que
un hombre pudiera memorizarlas”, debe tenderse a que las normas jurídicas sean sólo las
necesarias, avaras en palabras, concisas en sus términos, precisas en su forma y, sobre
todo, rápidamente cognoscibles.
Si pensamos que una de las características más importantes de la norma jurídica es que
debe atender ante todo al usuario, esto es, al sujeto que tiene que utilizarla -sea un
ciudadano común, un funcionario o un abogado- llegamos a que se torna en un sistema
informativo, por lo que debe dotarse de las cualidades propias de los modernos sistemas
informativos.
En este contexto, uno de los temas más importantes con vistas a la confección de textos
normativos adecuados es su evaluación: evaluación a priori pero que debe tener los criterios
70
Se han realizado esfuerzos en este sentido, como el de la Comisión nombrada por el gobierno inglés,
que produjo el estudio que lleva el título de “La preparación de las leyes”, conocido como Renton
Report (1975); o el de las diez proposiciones para una legislación en orden, contenidas en el checklist
de la OCED, según resolución de 1995. 71
Expresión acuñada por Martino a partir de 1975 Martino, A. A. – La contaminación legislativa, en
“Anuario de sociología y psicología jurídicas”, Barcelona, 1977.
Modelo Conceptual del SIIF2 01/04/2014 202/203
de evaluación a posteriori, ya que una norma jurídica nace para encaminar conductas hacia
un cierto objetivo.
Lo primero que debe evaluarse es si lo logra; lo segundo es con cuáles costos y con qué
cobertura financiera.
A estos criterios clásicos de evaluación se agregan otros dos irrenunciables: la economía
legislativa, esto es formular una norma sólo si es imprescindible, y la simplificación de los
procedimientos para empresas y ciudadanos.
Examinadas las normas identificadas y seleccionadas como relevantes, se aprecia que -con
un enfoque consistente con los criterios que vienen de enunciarse - resultaría idóneo y
suficiente el dictado de una buena disposición reglamentaria (en el marco de lo
dispuesto en el artículo 168, numeral 4º de la Constitución de la República).
Debería existir una norma de rango legal y de tipo programático para después aprobar el
Decreto Reglamentario.
Esta norma recogerá el modelo conceptual formulado y -en los aspectos de “reserva de ley”
(creación o modificación institucional, de cargos, presupuestarios, o de afectación de
derechos) que no puedan resolverse por la vía de Decreto- se procederá a la formulación del
proyecto legal que al efecto resulte imprescindible.
9.2 Principales Contenidos en la Normativa a Dictar
La normativa preverá la nueva conformación del SIIF2, con base en los criterios de
integración a nivel conceptual e interoperabilidad plena de los módulos y sistemas que lo
integran, bajo un enfoque de procesos de negocio, con fines de generación de información
financiero contable oportuna, relevante y confiable, impactando sobre la gestión diaria del
sector público, tanto a nivel de los Ministerios y Unidades Operativas como a nivel de las
autoridades de la CGN y del MEF para la toma de decisiones y rendición de cuentas.
A estos efectos, el proyecto incluirá un capítulo conteniendo los principios rectores y
objetivos del SIIF2, entre los cuales cabe mencionar:
La integración e interoperabilidad del SIIF2 con el resto de los sistemas del Sector
Público (SICE, Aduanas, DGI, RUPE, SDG, SPA, SNIP, SGH, SPE y Sistemas GRP)
La centralización normativa y la descentralización operativa.
El empleo de tecnologías de la información y comunicación (TICs), bajo la forma de
Sistemas Integrados de Administración Financiera (SIAF), con el fin de apoyar las
decisiones presupuestarias, las responsabilidades de la gestión de los recursos
públicos y la mejora del desempeño de las entidades públicas, así como la
preparación de los Estados Financieros, que incluyen los estados contables, los
estados de ejecución presupuestaria, los informes de flujos de fondos, el estado de
la deuda pública y el estado de activos fijos.
Su funcionamiento en base a una estrategia de desarrollo consistente y sólida,
sustentada en un modelo conceptual que precisa el alcance funcional del sistema, la
definición de la arquitectura de base a utilizar y la programación de las fases de
desarrollo respectivas.
La disciplina fiscal, generando información financiera oportuna para monitorear y
controlar la evolución del gasto público en línea con las capacidades actuales y
proyectadas de financiamiento del sector público.
Modelo Conceptual del SIIF2 01/04/2014 203/203
La eficiencia en la asignación y captación de los recursos, generando mayor y mejor
información para la toma de decisiones sobre la priorización de políticas y programas
públicos en distintos niveles de la Administración.
La eficiencia operacional, proporcionando herramientas prácticas que faciliten la
gestión de los recursos financieros y brinden información oportuna y relevante para
la toma de decisiones a nivel operativo en los Incisos.
La eficiencia en la rendición de cuentas, generando información contable oportuna y
confiable que le permita dar mayor transparencia a la rendición de las cuentas
públicas.
El proyecto también incluirá un capítulo relacionado con la estructura organizativa financiera
de las instituciones del sector público, considerando las siguientes dimensiones:
Finanzas Públicas
Presupuesto
Administración Financiera
Contabilidad.
En ese capítulo se precisarán las responsabilidades en relación con el funcionamiento del
SIIF2, que se asignan a las Unidades Organizativas, las Unidades Ejecutoras y las llamadas
Unidades Rectoras (entidades centralizadas responsables de formular las normativas del
funcionamiento del SIIF2): Unidad Rectora Presupuesto, Unidad Rectora Tesorería, Unidad
Rectora Contabilidad, Unidad Rectora Deuda Pública, Unidad Rectora Compras y
Contrataciones, Unidad Rectora Recursos, Unidad Rectora Inversión Pública y Unidad
Rectora Recursos Humanos.
También se precisarán las entidades responsables de la emisión de los estados financieros,
para lo que serán agrupadas por “Entes Contables”, conforme al modelo conceptual.
Considerando el principio de separación de poderes y los grados de descentralización y
autonomía de las entidades involucradas, se evaluará, como se ha adelantado, la necesidad
de promover las modificaciones legislativas que resulten necesarias a efectos de que dicha
asignación de responsabilidades resulte vinculante en todos los casos.
También se proyectará la modificación normativa necesaria para la utilización del Clasificador
Presupuestario y Plan de Cuentas Contables complementarios e integrados.
Por otra parte, se deberá analizar a nivel político la pertinencia de incluir en la normativa
proyectada la referencia a los cuatro módulos principales previstos en el modelo conceptual.
Top Related