modelo conceptual del nuevo siif - cgn.gub.uy · 4.4.4 clasificador presupuestario y plan de...

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.


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


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


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.


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


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


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.


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.


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


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.


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.



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.


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.



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.


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.


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.


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


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.


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


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.


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


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.


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.


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).


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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


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.


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).


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.


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


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.).


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:

http://www.google.com/


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.


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.


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.


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


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.


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.


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.


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.


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:


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


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;


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.


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.


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.


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.


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:


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


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


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


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.


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.


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”.


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


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.


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.


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.


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:


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


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.


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.


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.


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


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.


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.






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.


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.


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”.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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á


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.


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,


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”.


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.


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.


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.


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.



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.


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.



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.


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'.


El Manual funcional de la matriz de conversión, se sustentará fundamentalmente en el


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.


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:


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


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”.


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.


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”.


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


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:


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


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


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”.


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


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.


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



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”.


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:


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



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”.


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”.


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”.


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”.


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)


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.


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


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



Módulos con los

que se integra

Procesos Punto de

Integración

Momento de

registro


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


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



Módulos con los

que se integra

Procesos Punto de

Integración

Momento de

registro


las Transferencia

bancaria

directamente al

beneficiario final

Adquisiciones de Bienes Ingreso del Bien

conformado

Devengado

Orden de Pago

aprobada

Mandado a pagar


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


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



Módulos con los

que se integra

Procesos Punto de

Integración

Momento de

registro


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



Módulos con los

que se integra

Procesos Punto de

Integración

Momento de

registro


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.



Módulos con los

que se integra

Procesos Punto de

Integración

Momento de

registro


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ó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




se integra

Procesos Punto de

Integración

Momento de

registro


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




se integra

Procesos Punto de

Integración

Momento de

registro


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




se integra

Procesos Punto de

Integración

Momento de

registro


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




se integra

Procesos Punto de

Integración

Momento de

registro


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.


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.


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


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.


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


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.


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


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.


5.5.2.2 Información sobre gastos asociados a operaciones de deuda

REQ 5-87 Egresos por operaciones de crédito público


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.


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.


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,


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)


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


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.


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


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)


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.


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


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


de información referente a las retenciones de impuestos realizadas en el SIIF2 y que deben

ser informadas en forma diaria a la DGI.


REQ 6-5 Interoperación SIIF2 – Sistemas de Resguardos DGI


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


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


de información con el Sistema de Certificado Único de Empresa de DGI.

6.5 Registro Único de Proveedores del Estado (RUPE)


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.


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)


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.



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


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)


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.


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


de información con el Sistema de Presentación del Articulado.


6.8 Sistema Nacional de Inversiones Públicas (SNIP)


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.


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.


REQ 6-11 Interoperación SIIF2 - SNIP


de información con el Sistema Nacional de Inversiones Públicas (SNIP).

6.9 Sistema de RR.HH (SGH-SLH)


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.


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


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


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)


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.


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


de información con el Sistema de Planificación Estratégica y Evaluación (SPE).

6.11 Sistemas del BROU


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.


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.


La información enviada desde el sistema central del BROU se realiza adjuntando archivos a

mails.

REQ 6-14 Interoperación SIIF2 – e-BROU


de información con el sistema e-BROU de forma segura, para realizar transferencias

electrónicas.

REQ 6-15 Interoperación SIIF2 – BROU


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


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.


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


de información con los sistemas de pago del BCU, para realizar transferencias electrónicas.

REQ 6-17 Interoperación SIIF2 – BCU


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


de información con los Sistemas de Deuda Pública del BCU.


6.13 Sistemas del BPS


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.


En la actualidad el BPS brinda estos servicios a través de la PGE.

REQ 6-19 Interoperación SIIF2 – BPS


de información con los sistemas de certificado común de contribuyente del BPS.

6.14 Sistemas GRP


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.


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.


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


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


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


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.


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.


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


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




Ejercicio año 3




Ejercicio año 4




Ejercicio año 5




(1): Incluye control y evaluación.

Año 5Actividad

Año 1 Año 2 Año 3 Año 4

Inicio GobiernoInicio Gobierno


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).


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.







actuales (As Is).


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.


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.







actuales (As Is).


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


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.


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).


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.


REQ 8-2 Servidor Web



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.







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


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


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



Debe soportar mecanismos de autorización de granularidad fina que puedan ser





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.


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.





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.


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 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


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




Debe soportar la autenticación mediante los mecanismos de SSO que se elijan para la

plataforma.






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.


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.


y de utilizarlos para delegar las actividades de identificación y control de acceso para







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.


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.




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


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.







plataforma.





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:


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.


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


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.





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.


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.


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.


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.





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


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.





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


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.


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.





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


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.





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.


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 proveer mecanismos de autorización de granularidad fina.




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.


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.


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


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.


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


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.


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.


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.


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.


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.


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.


La eficiencia en la asignación y captación de los recursos, generando mayor y mejor


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.

modelo conceptual del nuevo siif - cgn.gub.uy · 4.4.4 clasificador presupuestario y plan de...

Documents