Modelo Conceptual del SIIF2

Transcripción

1 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

2 Índice de Contenidos 1. INTRODUCCIÓN RESUMEN EJECUTIVO MODELO CONCEPTUAL DE ALTO NIVEL DEL SISTEMA INTEGRADO DE INFORMACIÓN FINANCIERA Introducción Objetivos del sistema Alcance del sistema Esponsorización y éxito del proyecto Apoyo de las Máximas Autoridades Fortalecimiento de las capacidades internas del sector público para el desarrollo del SIAF Comité de Usuarios Requisitos generales del SIIF Cobertura institucional Trazabilidad Roles y perfiles Seguridad Performance y escalabilidad Consistencia e integridad de la información Clasificadores Clasificadores principales Clasificadores secundarios Propiedades institucionales Nivel de captura de las transacciones Captura a nivel institucional: Unidad Organizativa Estado de las transacciones Visibilidad sobre ejercicios futuros Base devengado Gestión de múltiples monedas Pantallas de usuario Documentación del sistema Mapa de módulos principales Estructura de Alto Nivel: SIIF2 Transaccional y SIIF2 Agregación SIIF2 Transaccional SIIF2 Agregación Funciones de soporte a la gestión financiera Orientación a documentos de negocio Seguimiento administrativo Alarmas financieras Funciones de soporte a la operación Compromisos de Ejercicios futuros Automatización de tareas Funciones de soporte para el control y auditoría Configuración Reportabilidad Introducción a la reportabilidad Requisitos generales a la reportabilidad Estructura de la capa de datos Búsquedas... 51

3 3.8.3 Reportes operativos Reportes analíticos Área de análisis Reportes estratégicos Listado de los principales reportes Interoperabilidad Interoperabilidad institucional Interoperabilidad transversal INTEGRACIÓN PRESUPUESTARIA Y CONTABLE: PRINCIPALES CONCEPTOS Y DEFINICIONES Centralización normativa y descentralización operativa Integración del sistema Núcleo integrador del sistema Requisitos mínimos para la integración Universalidad del registro de transacciones con efectos económicofinancieros Registro único Estructura organizativa financiera de las instituciones del Sector Público Estructura desde las Finanzas Públicas Estructura desde el Presupuesto Estructura desde la Administración Financiera Estructura desde la Contabilidad Clasificador Presupuestario y Plan de Cuentas Contables complementarios e integrados Clasificadores Presupuestarios Planes de Cuentas Contable Catálogos de Bienes Interrelación de la Clasificación Presupuestaria, Planes de Cuentas Contable y otros Sistemas Matriz de conversión presupuesto contabilidad Momentos de Registro Para los Gastos Para los Recursos Base del devengado Mandado a Pagar Pagado INTEGRACIÓN DE LOS MÓDULOS PRINCIPALES Visión global Módulo presupuestario Objetivos Requisitos Formulación Ejecución Evaluación Integración Presupuesto y contabilidad Presupuesto y tesorería Presupuesto y gestión de la deuda Módulo contable Objetivos... 99

4 5.3.2 Requisitos Marco Normativo Contable Principales Ingresos al Módulo de Contabilidad Esquema general de Integración del Módulo Contable con los Módulos principales y secundarios del SIIF Integración con los módulos principales Integración con los módulos secundarios Módulo tesorería Objetivos Requisitos Gestión de los recursos Gestión de los egresos Roles del módulo de tesorería Módulo deuda Objetivos Requisitos Información sobre recursos provenientes de operaciones de deuda Información sobre gastos asociados a operaciones de deuda Información sobre gestión de la deuda pública INTEGRACIÓN SISTEMAS DE APOYO TRANSVERSALES Visión Global y Plataforma de Gobierno Electrónico (PGE) Sistema de Compras y Contrataciones Estatales (SICE) Características funcionales Características técnicas Sistema Lucia (DNA) Características funcionales Características técnicas Sistemas de la Dirección General Impositiva (DGI) Características funcionales Características técnicas Registro Único de Proveedores del Estado (RUPE) Características funcionales Características técnicas Sistema de Distribución del Gasto (SDG) Características funcionales Características técnicas Sistema de Presentación del Articulado (SPA) Características funcionales Características técnicas Sistema Nacional de Inversiones Públicas (SNIP) Características funcionales Características técnicas Sistema de RR.HH (SGH-SLH) Características funcionales Características técnicas Sistema de Planificación Estratégica y Evaluación (SPE) Características funcionales Características técnicas

5 6.11 Sistemas del BROU Características funcionales Características técnicas Sistemas del BCU Características funcionales Características técnicas Sistemas del BPS Características funcionales Características técnicas Sistemas GRP Características funcionales Características técnicas MODELADO BPM DEL CICLO PRESUPUESTARIO Situación actual del SIIF Descripción del macroproceso presupuestario Formulación Ejecución presupuestal y financiera Control y evaluación ARQUITECTURA TECNOLÓGICA DEL SISTEMA Capa de Presentación Portal Web Servidor Web Capa de Negocios Servidor de Aplicaciones Reglas de Negocio Monitor de Actividades de Negocio Motor de Inteligencia de Negocios Motor de Gestión de Datos Maestros Capa de Datos Motor de Bases de Datos Relacionales Repositorio de Contenidos Motor de Extracción Transformación y Carga Capa de Integración Bus de Servicios Motor de Gestión de Políticas de Servicios Web Capa de Seguridad Mecanismo de Identificación Mecanismo de Single Sign on Mecanismo de Autorización Directorios de Credenciales Mecanismo de Aprovisionamiento de Usuarios Mecanismo de Autogestión de Credenciales Elementos Arquitectónicos de Monitoreo Monitor de Infraestructura Monitor de Uso del Sistema Consideraciones sobre la Arquitectura Ejemplo de topología de despliegue para la plataforma Tabla de recomendaciones ante contingencias que impidan la adquisición de un componente de la plataforma

6 9. EVALUACIÓN NORMATIVA Evaluación de las normas relevantes Principales Contenidos en la Normativa a Dictar

7 Índice de Ilustraciones Ilustración 3-1 Diagrama de estados de las transacciones Ilustración 3-2 Estructura de los módulos principales del SIIF Ilustración 3-3 Estructura de la capa de datos para la reportabilidad Ilustración 4-1 La contabilidad como núcleo integrador del sistema Ilustración 5-1 Estructura de los módulos principales del SIIF Ilustración 5-2 Marco Normativo Contable Ilustración 5-3 Principales Ingresos al Módulo Contable Ilustración 6-1 Esquema General de Interoperación para el SIIF Ilustración 7-1 Estructura del sector público Ilustración 7-2 El ciclo presupuestario Ilustración 7-3 Formulación Ilustración 7-4 Ejecución presupuestal Ilustración 7-5 Evaluación y control Ilustración 8-1 Capas de la plataforma de middleware de la arquitectura base Ilustración 8-2 Portal Web Ilustración 8-3 Servidor Web Ilustración 8-4 Servidor de Aplicaciones Ilustración 8-5 Reglas de Negocio Ilustración 8-6 Monitor de Actividades de Negocio Ilustración 8-7 Motor de Inteligencia de Negocios Ilustración 8-8 Motor de Gestión de Datos Maestros Ilustración 8-9 Motor de Bases de Datos Ilustración 8-10 Motor de Gestión de Contenidos Ilustración 8-11 Motor de Extracción, Transformación y Carga Ilustración 8-12 Bus de Servicios Ilustración 8-13 Motor de Gestión de Políticas de Servicios Web Ilustración 8-14 Mecanismo de Identificación Ilustración 8-15 Mecanismo de Single Sign-on Ilustración 8-16 Mecanismo de Autorización Ilustración 8-17 Directorios de Credenciales Ilustración 8-18 Mecanismo de Aprovisionamiento de Usuarios Ilustración 8-19 Mecanismo de Autogestión de Credenciales Ilustración 8-20 Monitor de Infraestructura Ilustración 8-21 Monitor de Uso del Sistema

8 Ilustración 8-22 Modelo de ejemplo de topología de despliegue de la Plataforma de Middleware del SIIF

9 Índice de Requisitos REQ 3-1 Alcance del sistema REQ 3-2 Cobertura institucional REQ 3-3 Trazabilidad REQ 3-4 Roles y perfiles REQ 3-5 Usuarios con distintos cometidos REQ 3-6 Seguridad REQ 3-7 Performance REQ 3-8 Escalabilidad REQ 3-9 Consistencia e integridad de la información REQ 3-10 Estructura de los clasificadores REQ 3-11 Flexibilidad de los clasificadores REQ 3-12 Variabilidad de los clasificadores REQ 3-13 Trazabilidad temporal de los clasificadores REQ 3-14 Propiedad de los clasificadores principales REQ 3-15 Repercusión en otros sistemas transversales REQ 3-16 Propiedad de los clasificadores secundarios REQ 3-17 Límites a los clasificadores secundarios REQ 3-18 Efecto de los clasificadores secundarios en SIIF2 agregación REQ 3-19 Propiedad de las propiedades institucionales REQ 3-20 Límites a las propiedades institucionales REQ 3-21 Estructura de las propiedades institucionales REQ 3-22 Efecto de las propiedades institucionales en SIIF2 agregación REQ 3-23 Nivel de captura de las transacciones REQ 3-24 Captura a nivel de Unidad Ejecutora y/o Unidad Organizativa REQ 3-25 Estado de las transacciones REQ 3-26 Visibilidad sobre ejercicios futuros REQ 3-27 Base devengado REQ 3-28 Gestión de múltiples monedas REQ 3-29 Pantallas de usuario REQ 3-30 Documentación del sistema REQ 3-31 Captura de Transacciones orientada a Documentos de Negocio REQ 3-32 Captura y Gestión de Documentación de Respaldo REQ 3-33 Gestión Documental REQ 3-34 Definición y Parametrización de Alarmas Financieras REQ 3-35 Registro y traspaso de compromisos que afectan ejercicios futuros... 47

10 REQ 3-36 Automatización de Tareas y Cálculos repetitivos REQ 3-37 Bandeja de Entrada de Tareas REQ 3-38 Funcionalidades automatizadas de control y auditoria REQ 3-39 Sistema configurable REQ 3-40 Exportación a planilla y documento REQ 3-41 Perfil de usuario y acceso a los reportes REQ 3-42 Características tecnológicas de la reportabilidad REQ 3-43 Oportunidad de la información para la reportabilidad REQ 3-44 Estructura de la capa de datos REQ 3-45 Búsquedas y Entidades REQ 3-46 Esquema de los reportes de búsqueda REQ 3-47 Filtros simples y avanzados para las búsquedas REQ 3-48 Área de resultados REQ 3-49 Paginación del área de resultados REQ 3-50 Ordenación del área de resultados REQ 3-51 Acceso al detalle de la transacción REQ 3-52 Requisitos de los reportes operativos comunes a los reportes de búsqueda REQ 3-53 Cobertura institucional de los reportes operativos REQ 3-54 Adaptación a la plataforma de BI REQ 3-55 Requisitos de los reportes analíticos comunes a otros reportes REQ 3-56 Cobertura institucional de los reportes analíticos REQ 3-57 Metadata disponible para análisis REQ 3-58 Requisitos de los reportes estratégicos comunes a otros reportes REQ 3-59 Elementos gráficos REQ 3-60 Listado de reportes REQ 3-61 Economía de reportes REQ 3-62 Plataforma de interoperabilidad REQ 3-63 Integridad y coherencia de la estructura de datos REQ 3-64 Normas de interoperación a cargo del SIIF REQ 3-65 Conjunto único de servicios web de interoperación REQ 3-66 Catálogos básicos e interoperación REQ 3-67 Interoperabilidad institucional modular REQ 3-68 Mecanismos de interoperabilidad vía up load REQ 3-69 Sistemas institucionales no aptos para la interoperación REQ 3-70 Interoperación transversal REQ 4-1 Administrador del Sistema... 64

11 REQ 4-2 Universalidad del registro REQ 4-3 Registro único de efectos múltiples REQ 4-4 Estructura de las unidades de registro REQ 4-5 Procedimientos de registro REQ 4-6 Estructura desde las Finanzas Públicas REQ 4-7 Estructura desde el Presupuesto REQ 4-8 Estructura desde la administración financiera REQ 4-9 Unidades Rectoras, Unidades Ejecutoras y Unidades Organizativas REQ 4-10 Entes Contables REQ 4-11 Unidades Ejecutoras Registración Contable REQ 4-12 Unidad de Consolidación REQ 4-13 Desarrollo de Clasificadores Presupuestarios y Plan de Cuentas Contables REQ 4-14 Sustento normativo de los Clasificadores Presupuestarios REQ 4-15 Estructura de los Clasificadores Presupuestarios REQ 4-16 Estructura Institucional REQ 4-17 Estructura por Objeto del Gasto REQ 4-18 Estructura de Recursos REQ 4-19 Sustento normativo del Plan de Cuentas Contable REQ 4-20 Estructura del Plan de Cuentas Contable REQ 4-21 Estructura del Catálogo de Bienes REQ 4-22 Integración del Clasificador Presupuestario, del Catálogo de Bienes y Plan de Cuentas Contable REQ 4-23 Desarrollo de la matriz de conversión presupuesto / contabilidad REQ 5-1 Generación del presupuesto Ley REQ 5-2 Transmisión de las leyes en materia Presupuestal al módulo de ejecución REQ 5-3 Gestión completa del ciclo quinquenal REQ 5-4 Crédito inicial y modificaciones REQ 5-5 Solicitud de modificaciones REQ 5-6 Distribución de créditos por Unidad Ejecutora y Unidad Operativa REQ 5-7 Funcionalidad de Topes y Abatimientos REQ 5-8 Etapas de ejecución presupuestaria de los gastos REQ 5-9 Lógica de cadena presupuestaria REQ 5-10 Prudencia presupuestaria REQ 5-11 Información requerida por cada entidad REQ 5-12 Captura de información orientada a documentos de negocio REQ 5-13 Arrastre de información a lo largo de la cadena REQ 5-14 Obligaciones y pagos sin compromiso... 92

12 REQ 5-15 Compromisos que impactan en ejercicios futuros REQ 5-16 Programa de ejecución REQ 5-17 Estados y modificaciones de las transacciones REQ 5-18 Cartera financiera REQ 5-19 Gestión multimoneda REQ 5-20 Ejecución de gastos asociados a la Gestión Humana REQ 5-21 Ejecución de gastos asociados a Bienes de Uso y Consumo REQ 5-22 Ejecución de gastos asociados a Inversión REQ 5-23 Ejecución de Proyectos Internacionales REQ 5-24 Arrendamientos Oficiales REQ 5-25 Gestión de Fondos Rotatorios REQ 5-26 Generación y Envío de Resguardos de Retenciones a DGI REQ 5-27 Cierre de ejercicio REQ 5-28 Transacciones asociadas a recursos REQ 5-29 Unidades de registro asociadas a recursos REQ 5-30 Etapas de ejecución presupuestaria de los recursos REQ 5-31 Rol generador de transacciones REQ 5-32 Rol aprobador de transacciones REQ 5-33 Rol interventor de transacciones REQ 5-34 Reversión de transacciones REQ 5-35 Orientación a programas y objetivos estratégicos REQ 5-36 Elementos comunes entre la ejecución y la evaluación REQ 5-37 Ejecución como fuente de información financiera para la evaluación 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 REQ 5-40 Actualización del plan de caja a partir de las obligaciones intervenidas REQ 5-41 Generación de transacciones de pago presupuestario a partir del pago de tesorería REQ 5-42 Generación de fuentes de financiamiento a partir de la emisión de deuda REQ 5-43 Generación de transacciones presupuestarias de gasto a partir del servicio de la deuda REQ 5-44 Estados Financieros (EEFF) a producir 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 REQ 5-47 Manual de activos REQ 5-48 Manual de Consolidación de la Información Financiera

13 REQ 5-49 Manual funcional de la Matriz de Conversión Presupuesto /Contabilidad REQ 5-50 Ingreso del Módulo de Presupuesto REQ 5-51 Ingreso del Módulo de Tesorería REQ 5-52 Ingreso del Módulo de Deuda Pública REQ 5-53 Ingreso del Módulo de Tesorería REQ 5-54 Ingreso del Módulo de Recursos Humanos REQ 5-55 Ingreso del Sistema Nacional de Inversión Pública (SNIP) REQ 5-56 Ingreso del SICE REQ 5-57 Sub módulo de Almacenes REQ 5-58 Sub módulo de Bienes REQ 5-59 Contingencias REQ 5-60 Rendición de cuentas REQ 5-61 Emisión de Cuentas Nacionales REQ 5-62 Percepción de recursos REQ 5-63 Registración de los recursos REQ 5-64 Recursos por Desembolsos de Prestamos REQ 5-65 Fuentes de financiamiento por Emisión de Deuda REQ 5-66 Conciliación de recursos REQ 5-67 Gestión de la disponibilidad financiera de los Incisos REQ 5-68 Gestión Garantías REQ 5-69 Programación financiera de los pagos REQ 5-70 Plan de Caja REQ 5-71 Medios de Pagos REQ 5-72 Registro de pagos presupuestarios REQ 5-73 Registro de pagos no presupuestarios REQ 5-74 Pagado y Percibido por Objeto y Programa Presupuestario REQ 5-75 Devolución al crédito o Pago (Reversión de Pagos) REQ 5-76 Anulación y reimpresión de cheques REQ 5-77 Pagos de Servicios de la Deuda REQ 5-78 Pago de Retenciones REQ 5-79 Gestión de Fondos Rotatorios REQ 5-80 Valores en Custodia REQ 5-81 Pago de Suministros en formato clearing REQ 5-82 Rol generador de transacciones REQ 5-83 Rol aprobador de transacciones REQ 5-84 Reversión de transacciones

14 REQ 5-85 Ingresos de recursos por operaciones de crédito público REQ 5-86 Contratación y desembolsos de Préstamos REQ 5-87 Egresos por operaciones de crédito público REQ 5-88 Información de la gestión de la deuda pública REQ 6-1 Interoperación SIIF2 - SICE REQ 6-2 Interoperación SIIF2 - Lucía REQ 6-3 Interoperación SIIF2 Sistemas de Recaudación de DGI REQ 6-4 Interoperación SIIF2 Sistemas de Retenciones DGI REQ 6-5 Interoperación SIIF2 Sistemas de Resguardos DGI REQ 6-6 Interoperación SIIF2 Sistema de Certificado de Crédito de DGI REQ 6-7 Interoperación SIIF2 Sistema de Certificado Único de Empresa de DGI REQ 6-8 Interoperación SIIF2 RUPE REQ 6-9 Interoperación SIIF2 SDG REQ 6-10 Interoperación SIIF2 - SPA REQ 6-11 Interoperación SIIF2 - SNIP REQ 6-12 Interoperación SIIF2 SGH-SLH REQ 6-13 Interoperación SIIF2 SPE REQ 6-14 Interoperación SIIF2 e-brou REQ 6-15 Interoperación SIIF2 BROU REQ 6-16 Interoperación SIIF2 Sistema de Pago del BCU REQ 6-17 Interoperación SIIF2 BCU REQ 6-18 Interoperación SIIF2 Sistemas de Deuda Pública del BCU REQ 6-19 Interoperación SIIF2 BPS REQ 6-20 Interoperación SIIF2 GRP de Cobertura Institucional REQ 8-1 Portal Web REQ 8-2 Servidor Web REQ 8-3 Servidor de Aplicaciones REQ 8-4 Reglas de Negocio REQ 8-5 Monitor de Actividades de Negocio REQ 8-6 Motor de Inteligencia de Negocios REQ 8-7 Motor de Gestión de Datos Maestros REQ 8-8 Motor de Bases de Datos Relacionales REQ 8-9 Repositorio de Contenidos REQ 8-10 Motor de Extracción, Transformación y Carga REQ 8-11 Bus de Servicios REQ 8-12 Motor de Gestión de Políticas de Servicios Web

15 REQ 8-13 Mecanismo de Identificación REQ 8-14 Mecanismo de Single Sign-on REQ 8-15 Mecanismo de Autorización REQ 8-16 Directorios de Credenciales REQ 8-17 Mecanismo de Aprovisionamiento de Usuarios REQ 8-18 Mecanismo de Autogestión de Credenciales REQ 8-19 Monitor de Infraestructura REQ 8-20 Monitor de Uso del Sistema

16 1. Introducción Este documento está compuesto por la presente Introducción, seguida por el Resumen Ejecutivo que conforma la Sección 2. El resto del contenido está conformado por la Sección 3 Modelo Conceptual de Alto Nivel, la Sección 4 que se refiere a la Integración Presupuestaria y Contable, mientras que la Sección 5 contiene la Integración de los Principales Módulos. Posteriormente la Sección 6 se refiere a la Integración con los Sistemas de Apoyo Transversales, la Sección 7 al Modelado en BPM y la Sección 8 a la Arquitectura Tecnológica del Sistema, Finalmente la Sección 9 esta compuesta por la Evaluación normativa. Para la elaboración de este documento base fueron entrevistados funcionarios de la Contaduría General de la Nación CGN -, Tesorería General de la Nación TGN -, Ministerio de Economía y Finanzas MEF-, Oficina de Planeamiento y Presupuesto OPP - y la Agencia para el Desarrollo del Gobierno de Gestión Electrónica y la Sociedad de la Información y del Conocimiento AGESIC -, así como funcionarios de varias Unidades Ejecutoras de la Administración Central. Modelo Conceptual del SIIF2 01/04/ /203

17 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 El SIIF actual se encuentra en operaciones desde el año 1999, y desde su entrada a producción a la fecha se incorporaron distintos módulos al núcleo inicial. El SIIF actual es un sistema desarrollado en base a funciones, y no a procesos y, si bien cuenta con las principales funciones de un SIAF, éstas tienen un bajo nivel de integración entre ellas, en especial en relación a la integración presupuestaria contable. Por último cabe mencionar que a nivel de plataforma tecnológica es un sistema cliente-servidor, en base a tecnología de la década pasada. I. Principales Problemas del SIIF Actual Producto de dicho diagnóstico se detectaron una serie de problemas estructurales y de sistema entre los cuales es posible mencionar los siguientes: Problemas estructurales del SIIF actual. Ausencia de un Modelo Conceptual que defina en forma precisa el alcance, las principales funcionalidades en forma integrada y cobertura del SIIF. Presencia de una arquitectura tecnológica base no consolidada, que no presenta elementos comunes para sus distintos módulos. Excesiva fragmentación de los módulos del SIIF=> visión de funciones y no de procesos. Ausencia de procesos y mecanismos necesarios para la integración financiero - contable en forma automática. Disociación entre la programación y ejecución financiera (SEG) con la información de metas e indicadores (SEV) y avance físico de obras/proyectos. Ausencia de una política integral de control interno. Problemas a nivel de sistemas del SIIF actual. Diferencias en las cifras presupuestarias del SIP (valores históricos) y SEG (valores nominales). Doble digitación de la misma información en distintos módulos del sistema. Información poco oportuna. El módulo contable (SIC) no se desarrolló por completo, por lo tanto no es posible generar los informes financieros y contables en forma automática desde el sistema. Registros de ingresos y de pago de la deuda con bajo nivel de integración al SIIF. Debilidades en su capacidad de generación de Reportes (imposibilidad de obtener reportes a una fecha distinta a la actual). Generación manual de informes a partir de extracciones de la Base de Datos. Bajo nivel de integración con sistemas de apoyo, como por ejemplo el Sistema de Compras (SICE) y el Sistema de Inversión Pública (SISI). En resumen, el SIIF actual está conformado por una serie de módulos y sistemas, los cuales no presentan una integración a nivel conceptual a la vez que no existe una interoperabilidad plena entre ellos bajo un enfoque de procesos de negocio. Esta situación afecta la generación de información financiero contable oportuna, relevante y confiable, impactando sobre la gestión diaria del sector público, tanto a nivel de los Ministerios y Unidades Operativas como a nivel de las autoridades de la CGN y del MEF para la toma de decisiones Modelo Conceptual del SIIF2 01/04/ /203

18 y rendición de cuentas (desde el 2008 hubo una mejora que fue la incorporación del SAI- CGN (BI)). II. El SIIF2 Un instrumento central para la gestión financiera contable del sector público es la utilización de tecnologías de la información y comunicación (TICs), bajo la forma de Sistemas Integrados de Administración Financiera (SIAF). El concepto SIAF hace referencia al uso de TICs en la gestión financiera con el fin de apoyar las decisiones presupuestarias, las responsabilidades de la gestión de los recursos públicos y la mejora del desempeño de las entidades públicas, así como la preparación de los Estados Financieros, que incluyen los estados contables, los estados de ejecución presupuestaria, los informes de flujos de fondos, el estado de la deuda pública y el estado de activos fijos. Un proyecto de fortalecimiento de este tipo de sistema, como es el caso del Sistema Integrado de Información Financiera del Ministerio de Economía y Finanzas de la República Oriental del Uruguay requiere la definición de una estrategia de desarrollo consistente y sólida. Para ello es necesario el desarrollo de un Modelo Conceptual, que establezca con precisión el alcance funcional del sistema, la definición de la arquitectura de base a utilizar y la programación de las fases de desarrollo necesarias para desarrollar una nueva versión del SIIF. En líneas generales un Modelo Conceptual (MC) debe definir los objetivos, el alcance y la cobertura del SIAF, junto con una visión general del marco de la gestión financiera pública, los principales requisitos de los usuarios y los procesos clave de la gestión financiero contable que el sistema de información debe apoyar, junto a la definición de la arquitectura tecnológica de base para su desarrollo. Objetivos del sistema Disciplina fiscal, generando información financiera oportuna para monitorear y controlar la evolución del gasto público en línea con las capacidades actuales y proyectadas de financiamiento del Sector Público. Eficiencia en la asignación y captación de los recursos, generando mayor y mejor información para la toma de decisiones sobre la priorización de políticas y programas públicos en distintos niveles de la Administración Pública. Eficiencia operacional, proporcionando herramientas prácticas que faciliten la gestión de los recursos financieros y brinden información oportuna y relevante para la toma de decisiones a nivel operativo en los Incisos. Eficiencia en la rendición de cuentas, generando información contable oportuna y confiable que le permita dar mayor transparencia a la rendición de las cuentas públicas. Alcance En términos generales el alcance del SIIF2 se compone de un conjunto de módulos principales, los cuales contienen principalmente las funcionalidades financiero contable que operan de forma integrada. Estos módulos son: presupuesto, contabilidad, tesorería y crédito público. A su vez, el SIIF2 cuenta con el apoyo de un conjunto de módulos complementarios, los cuales se interrelacionan con los módulos principales. Estos módulos son gestión de Modelo Conceptual del SIIF2 01/04/ /203

19 recursos humanos, compras y contrataciones, recursos, inversión pública y administración de bienes, entre otros. Una adecuada interoperación entre los módulos principales y los módulos complementarios permite una gestión pública más eficiente, al evitar, por ejemplo, la doble registración de la información en distintos sistemas asegurando su consistencia. A su vez, fortalece el ambiente de control sobre las finanzas públicas, generando un registro presupuestario y contable, sobre la base del devengado, que permita relacionar en forma directa las operaciones que generan (deudas) o pueden generar (contingencias) obligaciones para el Estado y la disponibilidad presupuestaria necesaria para afrontar las mismas, evitando la generación de deuda flotante no registrada, que distorsiona la situación fiscal. A su vez permite registrar de forma oportuna las variaciones del patrimonio del sector público. Esponsorización y éxito del proyecto En forma concurrente a la definición del Modelo Conceptual, existen una serie de condicionantes que promueven el éxito del proceso de desarrollo e implantación del SIIF2. Es necesario tener presente que estas condiciones no garantizan por sí solas su reforma exitosa, pero su ausencia condiciona fuertemente las posibilidades de éxito. Entre los factores más relevantes es posible mencionar el apoyo de las máximas autoridades y la participación de los usuarios finales del sistema a lo largo del proceso, junto al fortalecimiento de capacidades institucionales del sector público. El desarrollo de estas actividades por parte del MEF es de suma relevancia en el caso del desarrollo del SIIF2. III. Principales Aspectos del Modelo Conceptual del SIIF2 El SIIF2 tendrá como cobertura la Administración Central (Incisos 02 al 15, 20 al 24 y 30), los Organismos del Articulo 220 de la Constitución (Poder Judicial, Tribunal de Cuentas, Corte Electoral, Tribunal de lo Contencioso Administrativo, ANEP, UDELAR, INAU, ASSE, UTEC) y Poder Legislativo. Además, se debe tener en cuenta que a nivel del Módulo de Contabilidad debe realizarse la consolidación del Sector Público, por lo cual es necesario contemplar al resto de las entidades que por si mismas son entes contables. Los requisitos de alto nivel que el SIIF2 deberá cumplir son: trazabilidad, seguridad, uso de clasificadores principales y secundarios, visibilidad sobre ejercicios futuros, gestión de múltiples monedas, conjunto de pantallas de usuario uniforme y la generación de una documentación exhaustiva que asegura su mantención. El SIIF2 contará con dos grandes bloques a alto nivel: el SIIF2 Transaccional y SIIF2 Agregación. El SIIF2 Transaccional es el sistema de operación diaria para el registro de todas las transacciones detalladas que se generan asociadas a la administración y el manejo de las finanzas de las instituciones dentro de ámbito de cobertura. Su función principal es constituir un registro único, oportuno y veraz de todas las transacciones presupuestarias, contables, de tesorería y de servicio a la deuda realizadas como resultado de la operativa habitual de la administración de las finanzas públicas. A su vez debe permitir a los funcionarios encargados de la intervención y auditoría observar el correcto funcionamiento y el cumplimiento de la legalidad en cada una de las operaciones realizadas. Modelo Conceptual del SIIF2 01/04/ /203

20 Por su parte, el SIIF2 Agregación se encarga de aglutinar y almacenar toda la información de detalle obtenida a través del SIIF2 Transaccional y prepararla para que pueda ser explotada en forma de reportes orientados a usuarios tácticos y estratégicos. El SIIF2 Agregación proporcionará información de cada uno de los incisos así como información consolidada de todas las instituciones del ámbito de cobertura, la cual será de gran utilidad para la toma de decisiones tanto por parte de los incisos como de los Organismos Rectores. Desde el SIIF2 Agregación se contará con todos los elementos necesarios para poder realizar los Estados Financieros del Gobierno Central Consolidado, como así también los Estados Financieros Individuales de cada uno de los entes contables definidos en el ámbito de cobertura del SIIF2. De forma más precisa, el SIIF2 Transaccional se organiza en cuatro módulos principales, Presupuesto, Contabilidad, Deuda y Tesorería. Presupuesto: que contempla la formulación, la ejecución, las asignaciones y la evaluación presupuestaria. Contabilidad: que ejerce de núcleo integrador del sistema puesto que el resto de subsistemas impactan en ella de forma constante. Tesorería: que gestiona la Cuenta Única, el plan de caja, la ejecución de los pagos y cobros y el registro de los ingresos. Deuda: el módulo de deuda que registra tanto las emisiones como la gestión del servicio de la deuda. Además el SIIF2 deberá proporcionar funciones de soporte a la gestión financiera. La definición de optimizaciones en aspectos relacionados a la usabilidad del SIIF2 que mejoren la interacción del usuario con el sistema bajo un entorno de uso amigable, es un aspecto central en el momento de promover mejoras en las funciones de soporte a la gestión financiera. En los casos donde el sistema se encuentra orientado al registro de transacciones financieras-contables y no al apoyo de los procesos financieros, es posible observar la mala práctica de acumular información a lo largo del mes, y sólo concentrar su registro en el sistema, generalmente en las áreas de contabilidad, en las fechas cercanas al cierre presupuestario / contable mensual. Por ello se propone la inclusión de las siguientes funcionalidades que mejoren en forma sustantiva la usabilidad del SIIF2: orientación a documentos de negocio, seguimiento administrativo y alarmas financieras. Como parte del desafío de modificar el enfoque del SIIF actual, desde un sistema orientado a las funciones a un sistema orientado a los procesos, el SIIF2 deberá incorporar funcionalidades de apoyo a la operación financiero contable es un factor que promueve este cambio de orientación promoviendo la captura de información en forma oportuna. Para ello el sistema debe registrar información de los montos comprometidos para ejercicios posteriores al vigente y debe también automatizar la mayor cantidad posible de tareas realizadas por los usuarios en forma repetitiva basados en cálculos realizados sobre algoritmos simples. El SIIF actual presenta debilidades en las funciones de apoyo específicas para las tareas de auditoría, tanto para las realizadas por el Tribunal de Cuentas como por los órganos internos de auditoría. El SIIF2 debe permitir automatizar la realización de las funciones de control y auditoría tanto de los órganos de control externos como internos. La cobertura institucional tiene necesidades de gestión particulares motivadas por la diversidad de servicios que el aparato estatal presta a la ciudadanía. Ello implica que el SIIF2, tanto en el registro de la información, como en la explotación de la misma debe ser Modelo Conceptual del SIIF2 01/04/ /203

21 capaz de acomodar estas diferencias a través de funcionalidades avanzadas de Configuración. Sólo así el sistema aportará valor a los Incisos y Unidades Ejecutoras, al respetar, en la medida de lo posible, sus particularidades. Un sistema que no contemple este aspecto aporta un gran valor a los Órganos Rectores pero un valor cuestionable a las distintas entidades públicas, desincentivando su utilización. La reportabilidad es uno de los elementos principales de todo sistema de información y constituye uno de los productos que mayor valor añadido ofrece tanto al usuario operativo como al usuario estratégico. En la definición de reportabilidad del SIIF2 distinguimos cinco tipos de reportes distintos: Reporte de búsqueda: reportes asociados al sistema transaccional que permite obtener listados de las principales entidades del sistema según un conjunto de filtros predefinidos. El usuario objetivo es todo aquel que use el sistema transaccional para registrar la información o auditar la información registrada. Reporte operativo: reportes asociados a la operación de una unidad ejecutora. Permite ver información con mayor nivel de transformación que las búsquedas. El usuario objetivo es tanto un responsable de unidad ejecutora como un perfil operativo al interior de la unidad ejecutora. Reporte analítico: reportes que permiten ver información a nivel de inciso o de todas las instituciones del ámbito de cobertura del SIIF2. Permiten ver información con mayor nivel de transformación que los reportes operativos. El usuario objetivo es un perfil táctico o estratégico con responsabilidad de análisis sobre un inciso o incluso sobre el conjunto de incisos. Reporte estratégico: reportes que permiten ver información a nivel de inciso de toda la administración central. Presentan información en base a indicadores y gráficos que permiten monitorear los principales objetivos de gestión y gobierno. El usuario objetivo es un perfil estratégico con responsabilidad de análisis sobre la administración central normalmente perteneciente a los OO.RR. Área de análisis: el área de análisis es un lienzo en blanco donde el usuario tiene acceso a las medidas y dimensiones de análisis a partir de las cuales se genera la reportabilidad analítica y estratégica. Sobre los datos almacenados el usuario puede crear sin restricción sus análisis ad-hoc combinando a su libre voluntad las métricas y dimensiones disponibles. El usuario objetivo es un perfil con un nivel de usuario avanzado de herramientas de Inteligencia de Negocio (BI) que da soporte analítico a niveles directivos del MEF o de los Incisos. Considerando la mayor utilización de sistemas de información en el ámbito público es cada vez es más crítico que dichos sistemas tengan la capacidad de intercambiar información entre ellos. En un SIAF este aspecto es de vital importancia puesto que en muchos casos depende de la capacidad de interoperar que dicho sistema sea integrado o no. La interoperabilidad es una capacidad indispensable para el SIIF2. Esta funcionalidad se desarrollará potenciando y/o aprovechando la plataforma de interoperación del estado uruguayo desarrollada por la AGESIC en todos los casos que sea posible. IV. Principales Aspectos de la Integración Presupuestaria y Contable El Módulo de Presupuesto y el Módulo Contable son partes esenciales -no las únicas-, del Sistema Integrado de Administración Financiera, como es el caso del SIIF2. Ambos tienen elementos propios y comunes, pero uno se complementa con el otro, por lo cual deben Modelo Conceptual del SIIF2 01/04/ /203

22 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 1. Cuenta Corriente (ingresos corrientes menos los gastos corrientes) Plan de Cuentas Contable 1. Directamente relacionadas con las Cuentas de Resultado (ingresos / gastos) 2. Cuenta de Capital (ingresos de capital menos los gastos de capital) 2.1 Ingresos de Capital 2.1 Disminución de Activo no corriente 2.2 Gastos de Capital 2.2 Incremento en el Activo no corriente 3. Financiamiento (fuente menos aplicaciones) 3.1 Fuentes 3.1 Incrementos de Activos Corrientes contra incrementos de Pasivos no Corrientes o Patrimonio. 3.2 Aplicaciones Financieras 3.2 Disminuciones de Activos Corrientes contra disminuciones de Pasivos Corrientes y Pasivos no Corrientes. El SIIF2 requiere sustentarse en el principio conceptual y organizativo de centralización normativa y descentralización operativa. Esto implica que se concentren las funciones de diseño de políticas, dictado de normas y metodologías, así como las funciones de evaluación, y se desconcentren las funciones operativas o de gestión. La centralización normativa significa: Definir las políticas generales que enmarcan el funcionamiento de cada uno de los módulos; Elaborar y supervisar el cumplimiento de las normas, metodologías y procedimientos generales y comunes que regulan la operatoria del sistema, sin perjuicio de las adaptaciones que deban realizarse en forma descentralizada en función a las particularidades de determinadas agencias públicas; Administrar el sistema y producir la información relevante que le corresponda a éste; Evaluar el cumplimiento de las políticas. Modelo Conceptual del SIIF2 01/04/ /203

23 La descentralización operativa significa: Fortalecer la capacidad administrativa de las dependencias y entidades públicas para que puedan ejecutar eficientemente sus objetivos, metas y programas en el marco de las políticas definidas centralizadamente. Bajo el Modelo Conceptual del SIIF2, el Módulo de Contabilidad debe cumplir la función de núcleo integrador del mismo, dado que cuando las transacciones se devengan, cualquiera sea su módulo de origen, impactan en la contabilidad (registro contable), aún aquellas que no tengan efecto presupuestario, las cuales son de carácter económico. El SIIF2, desarrollado con esta concepción, permitirá que los distintos Estados Financieros que se elaboren sean coherentes entre sí, al ser originados en la misma fuente informativa, permitiendo además el acoplamiento modular y automático de la información necesaria para las estadísticas fiscales como por ejemplo las utilizadas en el Sistema de Cuentas Nacionales de las Naciones Unidas o para las Estadísticas de las Finanzas Públicas del Fondo Monetario Internacional, los cuales deben derivarse de la misma fuente informativa. Este cambio es un avance sustancial con respecto a la actual versión del SIIF, la cual no cuenta con la posibilidad de generar este tipo de información. Los requisitos mínimos que debe cumplir el SIIF2 para que el módulo contable sea el núcleo integrador se relacionan en forma directa con la forma de registro de las transacciones con efectos económico- financieros, la cual debe cumplir con las siguientes premisas: Registro único de cada transacción; Definir claramente la estructura organizativa financiera del Sector Público; Clasificadores Presupuestarios y Planes de Cuentas Contable complementarios e integrados; Matriz de conversión presupuesto / contabilidad desarrollada; Definición precisa de los momentos de registro. V. Módulos principales del SIIF2 Como fuera señalado anteriormente, el SIIF2 está compuesto por cuatro módulos principales: Presupuesto, Contabilidad, Tesorería y Gestión de la Deuda. Esta composición difiere en un punto central con la estructura actual del SIIF, el cual no cuenta con el Módulo de Contabilidad desarrollado en forma completa. Esto genera en la actualidad la imposibilidad de generar todos los Estados Financieros en forma automática desde el propio SIIF. En forma esquemática, en los siguientes puntos se detallan las funcionalidades centrales de los módulos principales del SIIF2. Módulo Presupuestario El módulo de presupuesto del SIIF2 contempla las funcionalidades necesarias para el registro y la gestión asociada a todo el ciclo presupuestario, tanto para gastos como para ingresos, considerando las etapas del ciclo presupuestario de la siguiente forma: La formulación presupuestaria: original del presupuesto quinquenal de la República Oriental del Uruguay y las formulaciones anuales actualizadas mediante el ajuste de los valores e indicadores y las sucesivas rendiciones de cuentas, los que generarán los créditos disponibles para los ejercicios sucesivos del quinquenio. Modelo Conceptual del SIIF2 01/04/ /203

24 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 Módulo Contable Ilustración 1 Estructura de los módulos principales del SIIF2 En el Sector Público, la contabilidad denominada gubernamental requiere de la definición de criterios técnicos específicos concordantes con los fines propios de las instituciones públicas, al tiempo que demanda una práctica armónica e integrada con distintos procesos de administración y producción de información. En ese sentido, debe asegurarse una coherencia relacional y permanente integración de la contabilidad con los aspectos de índole presupuestaria, de caja, de la recaudación, de administración de la deuda pública, de compras, de bienes y, en general, con todo proceso de las instituciones públicas que Modelo Conceptual del SIIF2 01/04/ /203

25 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 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 y Uno de los aspectos fundamentales es que todo registro de un devengo presupuestario sea acompañado de forma automática en el sistema por el asiento contable asociado a dicho movimiento. Modelo Conceptual del SIIF2 01/04/ /203

26 Módulo de Tesorería El módulo de tesorería debe contemplar las funcionalidades necesarias para el registro y la gestión asociada a la recaudación y pago de todos los recursos que forman parte de la gestión del presupuesto. De cara a su adecuado funcionamiento deberá desarrollarse siguiendo los siguientes principios: Eficiencia: La gestión de tesorería debe velar por la administración de los fondos públicos, cualquiera que sea la fuente de financiamiento y uso de los mismos, y de los títulos y valores en custodia, programando oportunamente los compromisos, obligaciones y pagos para ejecutar el presupuesto de gastos, viabilizando su óptima aplicación y realizando un seguimiento permanente, minimizando costos de funcionamiento. Prudencia: Toda la gestión de tesorería se debe realizar bajo un estricto criterio de prudencia, minimizando los riegos en el proceso de administración y obtención de rendimientos de los recursos públicos. Oportunidad: La ejecución de los procedimientos relacionados a la tesorería deben realizarse utilizando los mecanismos más idóneos que aseguran la pronta disponibilidad de los recursos en un marco de eficiencia, otorgando una mayor previsibilidad a las fechas de pago de las obligaciones del Estado, que mejoren la transparencia de la gestión financiera. Unidad de Caja: Los ingresos públicos se acreditarán en una Cuenta Única del Tesoro, independientemente del concepto u origen de los mismos, y contra dicha cuenta se debitaran todos los pagos que correspondan realizar según las obligaciones legalmente asumidas por las Entidades Públicas. El detalle de los requisitos necesarios para el correcto funcionamiento de este módulo se encuentra en la sección Módulo de Deuda El Módulo de Deuda debe contemplar las funcionalidades necesarias para el registro y la ejecución de las operaciones de crédito público que realiza el Estado en el marco de las autorizaciones legales correspondientes, así como la ejecución de las operaciones destinadas al pago de los servicios de la deuda. Bajo la estructura institucional actual de la República Oriental del Uruguay la gestión de la Deuda Pública se realiza en forma coordinada por el Banco Central y el Ministerio de Economía y Finanzas. Por lo tanto, los requisitos del SIIF2 deben considerar esta forma de funcionamiento. El Módulo de Deuda debe considerar los siguientes principios para su adecuado funcionamiento: Eficiencia y prudencia: El endeudamiento público tiene como objetivo fundamental cubrir los requerimientos de financiamiento del sector público al más bajo costo posible, optimizando los recursos y sujeto al menor grado de riesgo posible. Transparencia: El proceso de endeudamiento público debe llevarse a cabo con oportunidad, transparencia, procurando el acceso oportuno a información veraz, comprensible y confiable. Modelo Conceptual del SIIF2 01/04/ /203

27 Oportunidad: La ejecución de los procedimientos relacionados a la gestión de la deuda deben realizarse utilizando los mecanismos más idóneos que aseguran la pronta disponibilidad de los recursos en un marco de eficiencia, otorgando una mayor previsibilidad a las fechas de pago de las obligaciones del Estado, que mejoren la transparencia de la gestión financiera. El detalle de los requisitos necesarios para el correcto funcionamiento de este módulo se encuentra en la sección VI. Integración de los sistemas de apoyo transversales La capacidad de interoperar del SIIF2 con el resto de los sistemas del sector público es una característica fundamental del nuevo sistema. Por esta razón, en la Sección 6 del documento se especifican en forma detallada los sistemas con los que interoperará el SIIF2. Para cada sistema se presenta una breve descripción de sus principales objetivos, las interacciones detectadas como relevantes y los impactos o riesgos que los volúmenes de información, requeridos por la interoperación, podrían poner sobre la infraestructura y el diseño del sistema. Los sistemas requeridos para interoperar son: Sistema de Compras y Contrataciones Estatales (SICE) Sistema Lucia (DNA) Sistemas de la Dirección General Impositiva (DGI) Registro Único de Proveedores del Estado (RUPE) Sistema de Distribución del Gasto (SDG) Sistema de Presentación del Articulado (SPA) Sistema Nacional de Inversiones Públicas (SNIP) Sistema de RR.HH (SGH-SLH) Sistema de Planificación Estratégica y Evaluación (SPE) Sistemas del BROU Sistemas del BCU Sistemas del BPS Sistemas GRP VII. Modelado BPM del ciclo presupuestario El modelado de alto nivel del ciclo presupuestario pretende mostrar en forma gráfica el funcionamiento actual y donde corresponda, las modificaciones sugeridas al ciclo de gestión del gasto público. De esta forma, la Sección 7 del documento contiene la situación actual ( As Is ) de los principales procesos del ciclo presupuestario modelados según metodología BPM. En forma adicional al objetivo antes señalado, esta Sección tiene como objetivo secundario representar gráficamente el ciclo presupuestario, con el fin de ser incorporado como Anexo en los Términos de Referencia y permitir a los potenciales proveedores tener una idea de alto nivel del flujo de funcionamiento actual de dichos procesos. Modelo Conceptual del SIIF2 01/04/ /203

28 VIII. Arquitectura tecnológica de base del sistema La definición de la arquitectura tecnológica de base es un aspecto central en la definición del SIIF2. Por este motivo, en la Sección 8 se describen en detalle los elementos tecnológicos que conforman la plataforma base propuesta para el SIIF2. El objetivo de este apartado es presentar el diseño arquitectónico base para soportar el desarrollo y posterior operación del SIIF2. Se denomina Arquitectura Tecnológica Base debido a que establece las estructuras fundamentales sobre las cuales se podrá definir y refinar la arquitectura completa del sistema. Los contenidos definidos en este diseño permitirán anticiparse a problemáticas técnicas que recurrentemente aparecen en desarrollos de gran escala. La base tecnológica definida se centra en las piezas de middleware sobre las que se ejecutará el SIIF2, e identifica todas las que se necesitarán para manifestar los atributos de calidad del sistema detectados como requerimientos en la fase de análisis de este proyecto. Las distintas piezas de la plataforma se describen en base a seis capas: Presentación, cuyos elementos soportan la ejecución de los componentes de la interfaz de usuario de los distintos módulos del sistema. Negocio, cuyos elementos soportan la ejecución de los componentes que encapsulan la lógica y las reglas de negocio más invariables del sector público, en el dominio presupuestario, financiero y contable. Datos, cuyos elementos permiten el almacenamiento y manipulación de la información persistente del sistema. Gestión de procesos, cuyos elementos soportan la ejecución de los componentes que capturan la lógica y las reglas de negocio más dinámicas del sector público, y que permiten implementar, monitorizar y optimizar los procesos institucionales de manera altamente flexible y configurable. Integración, cuyos elementos soportan la ejecución de los componentes que permiten la interoperación entre elementos internos y sistemas externos. Seguridad, cuyos componentes permiten otorgar los niveles requeridos de identificación, aseguramiento, no repudio e integridad al sistema. IX. Evaluación normativa En esta sección del documento se realiza un análisis de la normativa existente y relevante a los efectos del SIIF2. A partir de esta identificación normativa se realizó un análisis de los requerimientos establecidos por el Modelo Conceptual diseñado a los efectos de determinar los casos que requieran ser normados para entrar en funcionamiento. De este análisis se concluye que bastaría de una disposición reglamentaria bajo la forma de un Decreto reglamentario del Poder Ejecutivo y se presenta un esbozo del contenido a incluir en el mismo. Modelo Conceptual del SIIF2 01/04/ /203

29 XI. Comentarios Finales El desarrollo de un Modelo Conceptual que defina en forma precisa el alcance, la forma de funcionamiento integrado de las principales funcionalidades financiero contable y el ámbito de cobertura del SIIF2 es un pre requisito indispensable para la etapa de desarrollo del sistema de información. Como resultado de las actividades realizadas por el equipo consultor es posible plantear que actualmente la CGN cuenta con una base sólida de definiciones conceptuales que permitirán desarrollar de manera adecuada los Términos de Referencia para contratar el desarrollo del SIIF2. En especial se debe mencionar los siguientes aspectos contemplados en el Modelo Conceptual elaborado: Desarrollo de los conceptos fundamentales para la integración presupuestaria contable, núcleo central para lograr una gestión presupuestaria en base devengado, iniciando este proceso por una gestión presupuestaria en base caja modificada, donde ciertos gastos e ingresos se registran bajo el concepto de devengado y otros permanecen bajo el concepto de percibido, en especial los ingresos, de acuerdo a los principios recomendados por las IPSAS. Propuesta de una visión integrada del SIIF2, bajo un enfoque de procesos en lugar del actual enfoque de funciones, el cual tiene como consecuencia la doble digitación de información en el mismo sistema o la inconsistencia de información entre los distintos sistemas que componen el actual SIIF. Definición de un módulo de reportabilidad con más y mejores funcionalidades que las actualmente ofrecidas por el SIIF, con el fin de apoyar tanto la gestión a nivel de los Incisos como la gestión fiscal del MEF. Fortalecimiento de los procesos de control, automatizando en forma especifica dentro del sistema el momento del intervenido por parte del Tribunal de Cuentas, así como del proceso de Rendición de Cuentas mediante la generación de los Estados Financieros en forma automática desde el propio sistema. Incremento de las capacidades de interoperabilidad del SIIF2 con el resto de los sistemas del sector público, como por ejemplo el sistema de compras y contrataciones, como también con sistemas de gestión institucionales, como el proyecto GRP impulsado por la AGESIC. Este incremento de capacidad de interoperación será consecuencia tanto del enfoque funcional como de la arquitectura tecnológica de base propuesta. Modelo Conceptual del SIIF2 01/04/ /203

30 3. Modelo Conceptual de alto nivel del Sistema Integrado de Información Financiera 3.1 Introducción Un instrumento central para la gestión financiera contable del sector público es la utilización de tecnologías de la información y comunicación (TICs), bajo la forma de Sistemas Integrados de Administración Financiera (SIAF). En forma estilizada, el SIAF es una herramienta que permite la gestión sistemática e integrada de los recursos públicos, y la información generada por el sistema actúa como instrumento que facilita la toma de decisiones, promoviendo una gestión del gasto público más eficaz, eficiente y transparente. En este contexto el concepto SIAF hace referencia al uso de TICs en la gestión financiera con el fin de apoyar las decisiones presupuestarias, las responsabilidades de la gestión de los recursos públicos y la mejora del desempeño de las entidades públicas, así como la preparación de los Estados Financieros, que incluyen los estados contables, los estados de ejecución presupuestaria, los informes de flujos de fondos, el estado de la deuda pública y el estado de activos fijos. Un proyecto de fortalecimiento de este tipo de sistema, como es el caso del Sistema Integrado de Información Financiera (SIIF) del Ministerio de Economía y Finanzas de la República Oriental del Uruguay requiere la definición de una estrategia de desarrollo consistente y sólida. Para ello es necesario el desarrollo de un Modelo Conceptual, que establezca con precisión el alcance funcional del sistema, la definición de la arquitectura de base a utilizar y la programación de las fases de desarrollo necesarias para implementar el SIIF2. En líneas generales un Modelo Conceptual (MC) debe definir los objetivos, el alcance y la cobertura del SIAF, junto con una visión general del marco de la gestión financiera pública, los principales requisitos de los usuarios y los procesos clave de la gestión financiero contable que el sistema de información debe apoyar, junto a la definición de la arquitectura tecnológica de base para su desarrollo. Es muy importante considerar que el MC difiere de las especificaciones detalladas del sistema de información. Las definiciones del MC proveen el marco general para la elaboración de los requisitos funcionales más detallados, los cuales deben ser elaborados en la fase de desarrollo del sistema. Pero si es de suma importancia que este instrumento establezca con precisión las principales reglas de negocio del ciclo presupuestario y su integración con la contabilidad. En el caso particular del SIIF2, el MC debe sustentarse en la aplicación del principio de centralización normativa y descentralización operativa, dimensión clave para definir el alcance del sistema de información, como así también definir las reglas de negocio relativas al proceso de ejecución presupuestaria y contable, considerando con especial atención las relativas al proceso de integración automático del ciclo financiero contable (presupuesto/contabilidad/tesorería/deuda pública) que rige la gestión financiera pública, con un enfoque de base devengado para los gastos y recursos o base caja modificado para los recursos. Así, en el MC se deben detallar con precisión las principales definiciones funcionales, que interrelacionan la cadena financiero contable en las distintas etapas Modelo Conceptual del SIIF2 01/04/ /203

31 presupuestarias 1 (aprobado, modificado y comprometido), contables (devengado y obligado) y tesorería (pagado), como así también las reglas correspondientes a los procesos de cierre y apertura anual presupuestario y contable de cada ejercicio fiscal y considerar la revisión de los principales conceptos que dan soporte a la implementación de un Sistema de Cuenta Única del Tesoro, instrumento clave para realizar una gestión moderna de caja. A su vez, el MC debe indicar con precisión cuáles serán las salidas del sistema, en especial las salidas contables definiendo los Estados Financieros que contendrán los estados básicos más los estados complementarios necesarios para una rendición de cuentas transparente sustentadas por una parte, en el cumplimiento de la normativa nacional referente a las responsabilidades dentro del sector público, y, por otra parte, en los lineamientos internacionales contable dados por la IFAC (Normas Internacionales de Contabilidad para el Sector Público) y para apoyar la gestión de la política fiscal en el Manual de Estadísticas de Finanzas Públicas del FMI y el Manual de Cuentas Nacionales de las Naciones Unidas. Todo ello permitirá la generación de información relevante, oportuna y confiable para la toma de decisiones y para la rendición de cuentas. Realizar este conjunto de definiciones funcionales implica una revisión de la aplicación de los criterios normativos tanto a nivel de procesos como a nivel de los sistemas de información actualmente en uso, así como una revisión del marco normativo de la gestión financiera pública En ciertas ocasiones, los criterios normativos de las etapas básicas de la gestión financiera pública presentan ciertas debilidades que deben ser fortalecidas. En otros casos, el marco normativo presenta ciertas interpretaciones a nivel de procesos y/o implementación en los sistemas de información que deben ser revisadas para optimizar la gestión del gasto público. A nivel de implementación de los sistemas de información, el SIIF, al igual que otros SIAF en la región es un sistema orientado a las funciones, que contiene, por ejemplo, un módulo de presupuesto y un módulo de pagos, con baja integración entre ellos, en lugar de ser un sistema de información orientado a los procesos, el cual refleja de mejor forma el flujo habitual de la gestión financiera en forma integrada. Un sistema orientado a procesos busca, por ejemplo, generar en forma automática, a partir de la captura de información en base a documentos de negocio (por ejemplo contratos o facturas), la cadena presupuestaria contable que maximice la utilización de la información heredada en el mismo sistema, evitando su doble digitación, ya sea en el mismo SIAF o en otros sistemas relacionados, como por ejemplo el sistema de inversión pública. Si bien el MC debe contener las definiciones funcionales más relevantes para la integración de los módulos principales que componen el SIAF (presupuesto, contabilidad, tesorería y deuda pública), también es necesario que el MC explicite con un mayor nivel de detalle las principales características funcionales del sistema y su arquitectura tecnológica de base para el desarrollo del SIIF2. En relación a las principales características funcionales, partiendo de la integración automática entre el Clasificador Presupuestario y el Plan de Cuentas Contables y continuando con las funcionalidades básicas destinadas a registrar la ejecución presupuestaria con la obtención del registro contable en forma automática, un SIAF también 1 En esta sección se indican en forma genérica las distintas etapas presupuestarias y contables, que incluyen tanto gastos como recursos, las cuales son detalladas en la Sección IV y Sección V. Modelo Conceptual del SIIF2 01/04/ /203

32 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 Objetivos del sistema El SIIF2 debe transformarse en una potente herramienta para la gestión del Presupuesto Nacional y de la Rendición de Cuentas en la República Oriental del Uruguay, promoviendo el logro de los principales objetivos de la gestión moderna del gasto público. Disciplina fiscal, contando con información oportuna para monitorear y controlar la evolución del gasto público en línea con las capacidades actuales y proyectadas de financiamiento del Sector Público. Eficiencia en la asignación y captación de los recursos, generando mayor y mejor información para la toma de decisiones sobre la priorización de políticas y programas públicos en distintos niveles de la Administración Pública. Eficiencia operacional, proporcionando herramientas prácticas que faciliten la gestión de los recursos financieros y brinden información oportuna y relevante para la toma de decisiones a nivel operativo en los Incisos. Eficiencia en la rendición de cuentas, generando información contable oportuna y confiable que le permita dar mayor transparencia a las cuentas públicas. Modelo Conceptual del SIIF2 01/04/ /203

33 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 Alcance del sistema Todos estos atributos conceptuales de un SIAF se plasman en un sistema de información concreto, el cual está compuesto por un conjunto de subsistemas o módulos, los cuales se rigen por principios generales y reglas de negocio que reflejan las normas presupuestarias y contable que establezca el Órgano Rector y ordenan su funcionamiento, asegurando la calidad y confiabilidad de la información producida. En términos generales el alcance del SIIF2 se compone de un conjunto de módulos principales que operan interrelacionados. Estos módulos son: presupuesto, contabilidad, tesorería y deuda pública. A su vez, el SIAF cuenta con el apoyo de un conjunto de módulos complementarios, los cuales se interrelacionan con los módulos principales. Estos módulos son gestión de recursos humanos, compras y contrataciones, recursos, inversión pública y administración de bienes, entre otros. Una adecuada interoperación entre los módulos principales y los módulos complementarios permite una gestión pública más eficiente, al evitar, por ejemplo, la doble registración de la información en distintos sistemas asegurando su consistencia. A su vez, fortalece el ambiente de control sobre las finanzas públicas, generando un registro presupuestario y contable, sobre la base del devengado, que permita relacionar en forma directa las operaciones que generan (deudas) o pueden generar (contingencias) obligaciones para el Modelo Conceptual del SIIF2 01/04/ /203

34 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 preestablecidos 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 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 Apoyo de las Máximas Autoridades. Para el desarrollo de un proyecto de fortalecimiento de la gestión financiera pública es un prerrequisito contar con el apoyo de las autoridades del Ministerio de Economía y Finanzas. Estos actores son los usuarios finales de la información generada por el SIIF2 a nivel global. Contar con información oportuna, relevante y confiable es una potente herramienta para el manejo de la política fiscal, tanto en épocas de restricciones como de expansiones económicas. A su vez, en el aparato estatal el rol del Ministerio de Economía y Finanzas es de suma relevancia sobre el resto de los Ministerios. Por esta razón una iniciativa lanzada y apoyada por las autoridades económicas tiene mayores probabilidades de éxito, considerando a su vez que estos proyectos tienen una duración promedio de 4/6 años. Modelo Conceptual del SIIF2 01/04/ /203

35 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 Comité de Usuarios Es muy importante que desde el inicio de la etapa de desarrollo del SIIF2 se ponga en funcionamiento un Comité de Usuarios integrado por futuros usuarios del sistema provenientes de distintas instituciones públicas. Este comité deberá reunirse en forma periódica con el Equipo Ejecutor del Proyecto, funcionando como instancia de consulta y validación de las distintas fases del desarrollo. Esta actividad permite, por un lado contar con el punto de vista del usuario del sistema y por otra parte, comunicar las ventajas de la nueva versión del sistema a los participantes de las instituciones, iniciando de esta forma el necesario proceso de gestión del cambio y capacitación que esta iniciativa demanda. Estas condiciones ponen de relieve que el proyecto de fortalecimiento del SIIF2 requiere ser desarrollado sobre la base de requisitos de orden técnico pero sin desconocer la importancia de las condiciones contextuales y políticas. Las reformas no pueden ser desplegadas exclusivamente sobre las innovaciones del sistema de información y desarrollos conceptuales y metodológicos, sino que debe tener tanto el respaldo del máximo nivel político como el compromiso de los cuadros burocráticos del Estado, para lo cual es necesario definir una adecuada estrategia de gestión del cambio. Tener presente esta combinación de factores contribuirá en gran medida a llevar adelante exitosamente el proceso de modernización del SIIF. 3.2 Requisitos generales del SIIF2 En este apartado se describen requisitos generales y de alto nivel que el SIIF2 deberá cumplir en su globalidad con el fin de cumplir con los objetivos antes descritos. Modelo Conceptual del SIIF2 01/04/ /203

36 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 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 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) Seguridad Los mecanismos de seguridad son críticos en un SIAF tanto por la importancia intrínseca de la información que contienen, como por las consecuencias legales que entrañan, sin olvidar el impacto práctico evidente que el uso del sistema puede tener (i.e. gatillar pagos automáticos). Modelo Conceptual del SIIF2 01/04/ /203

37 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 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) Consistencia e integridad de la información El repositorio central del SIIF2 debe mantener consistencia e integridad de datos permanente. El sistema debe operar en forma consistente y repetible según los requisitos funcionales de negocio. REQ 3-9 Consistencia e integridad de la información El repositorio central de datos del sistema transaccional debe mantener consistencia e integridad de datos permanente. Esta consistencia debe asegurarse a pesar de fallas técnicas o caídas de otros componentes del sistema. Todas las transacciones del sistema deben persistir en la base de datos, de un estado consistente a un nuevo estado consistente en forma atómica. Modelo Conceptual del SIIF2 01/04/ /203

38 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 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 Clasificadores principales Son clasificadores principales aquellos definidos por el marco legal, normativo y organizativo del estado y de uso general por todos los incisos de la cobertura. Todos los clasificadores que contempla el actual SIIF son clasificadores principales. A modo de ejemplo y sin perjuicio de otros son clasificadores principales para el sistema el clasificador institucional, el de programa presupuestario, el de objeto del gasto, el de recursos y el plan de cuentas contable. REQ 3-14 Propiedad de los clasificadores principales Los clasificadores principales son propiedad del Órgano Rector y de estos depende su definición inicial y cualquier modificación posterior a los mismos. Modelo Conceptual del SIIF2 01/04/ /203

39 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 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 Propiedades institucionales Si bien las propiedades institucionales no son clasificadores, constituyen también una facilidad a la gestión y operación de los incisos. Permiten que el registro de información en el SIIF2 se adapte de forma más fiel a las particularidades de cada inciso aportando mayor riqueza a la información registrada. Un ejemplo claro de la necesidad de propiedades institucionales sucede actualmente en el Ministerio de Salud Pública. Dada su operativa habitual utilizan el campo de resumen de la obligación para registrar información que les ahorra en ocasiones recurrir a consultar el expediente en papel. Esta información que ahora guardan de manera desestructurada y que no responde a una necesidad común a toda la cobertura del sistema sino que es particular se resuelve mediante la orquestación de propiedades institucionales. Así una propiedad institucional es un campo de información estructurada que se incluye al registro de la transacción según la definición particular de cada inciso. REQ 3-19 Propiedad de las propiedades institucionales Las propiedades institucionales son propiedad de los incisos y de ellos depende su definición inicial y cualquier modificación posterior a los mismos. Las propiedades institucionales serán almacenadas y conservadas de forma centralizada en el SIIF2. Modelo Conceptual del SIIF2 01/04/ /203

40 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 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 Captura a nivel institucional: Unidad Organizativa Este requisito tiene un efecto particular para el clasificador institucional. Actualmente el SIIF 1 captura la información a nivel de Unidad Ejecutora y no contempla la Unidad Organizativa. Muchos incisos requieren para su gestión interna la posibilidad de distribuir el gasto a nivel de Unidad Organizativa e incluso existe un sistema (el SDG) que se encarga de hacer esta distribución de forma aproximada y a posteriori. El SIIF2 capturará en origen la información a nivel de Unidad Organizativa. Esto en algunos casos (una minoría) puede implicar la necesidad de explotar algunas transacciones generando un trabajo de registro adicional. En todo caso este efecto siempre puede ser mitigado asignando ciertos gastos de impacto compartido a una Unidad Organizativa central y la decisión puede tomarse al interior de cada inciso. REQ 3-24 Captura a nivel de Unidad Ejecutora y/o Unidad Organizativa El SIIF2 capturará las transacciones según el catálogo institucional a nivel de Unidad Ejecutora y/o Unidad Organizativa como mínimo. Modelo Conceptual del SIIF2 01/04/ /203

41 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. REQ 3-25 Estado de las transacciones Ilustración 3-1 Diagrama de estados de las transacciones Todas las transacciones de todos los módulos del SIIF2 contemplaran el esquema de estados definido arriba. Deberá preverse un rol adicional entre aprobador e interventor, dado que el Cr. Central debe aprobar los registros verificados por el Gerente Financiero, pero no bajo el rol de interventor. Modelo Conceptual del SIIF2 01/04/ /203

42 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 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 Gestión de múltiples monedas Si bien el presupuesto de la República Oriental del Uruguay está expresado enteramente en pesos (UYU) durante la ejecución habitual del mismo se producen movimientos en distintas monedas. El sistema deberá permitir gestionar está situación de forma efectiva, distinguiendo entre el costo asociado al bien o servicio adquirido de la eventual diferencia financiera atribuible a variaciones de tipo de cambio. Todo ello no impide que la contabilidad será manejada enteramente en pesos (UYU). REQ 3-28 Gestión de múltiples monedas El sistema permitirá la gestión de múltiples monedas de forma eficiente según lo descrito en el presente apartado. Modelo Conceptual del SIIF2 01/04/ /203

43 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 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 principales 2 : Presupuesto: que contempla la formulación y las etapas parlamentarias, la ejecución, las asignaciones, las modificaciones durante el ejercicio y la evaluación presupuestaria incluyendo las Rendiciones de Cuenta. Contabilidad: que ejerce de núcleo integrador del sistema puesto que el resto de subsistemas impactan en ella de forma constante. Tesorería: que gestiona el plan de caja, la ejecución de los pagos y cobros y el registro de los ingresos. Deuda: el módulo de deuda que registra tanto las emisiones como la gestión del servicio de la deuda. 2 El detalle exhaustivo de cada uno de los módulos se encuentra en la sección 5. Modelo Conceptual del SIIF2 01/04/ /203

44 Ilustración 3-2 Estructura de los módulos principales del SIIF2 Es importante aclarar que ser un módulo principal no significa necesariamente que se deba construir un aplicativo específico que responda a los requisitos funcionales sino que la información asociada al mismo debe estar contenida de forma explícita y detallada en la base de datos del SIIF2. En el caso uruguayo se dan dos situaciones completamente diferenciadas para el módulo de contabilidad y para el módulo de deuda que sirven para ilustrar este concepto. En estos momentos no hay ningún aplicativo que pueda dar respuesta a las necesidades contables. El nuevo SIIF2 deberá por tanto realizar lo siguiente: Contemplar el diseño de un modelo de datos que permita almacenar esta información. Desarrollar una aplicación que permita al usuario registrar todos los movimientos contables económicos y financieros. Sin embargo, el caso del módulo de deuda es completamente opuesto. El Banco Central del Uruguay ya dispone de un sistema completo y autónomo para la gestión operativa del servicio de deuda. En este caso el SIIF2 deberá: Contemplar el diseño de un modelo de datos que permita almacenar esta información. Realizar el desarrollo de un mecanismo de interoperación para capturar en ese modelo las de transacciones introducidas en el sistema de gestión de la deuda del Banco Central con el detalle que se defina. Modelo Conceptual del SIIF2 01/04/ /203

45 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 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 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 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 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 SIIF Funciones de soporte a la gestión financiera La definición de mejoras en aspectos relacionados a la usabilidad del SIIF2 que mejoren la interacción del usuario con el sistema bajo un entorno de uso amigable, es un aspecto central en el momento de promover mejoras en las funciones de soporte a la gestión financiera. En los casos donde el sistema se encuentra orientado al registro de transacciones Modelo Conceptual del SIIF2 01/04/ /203

46 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 SIIF 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 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 Alarmas financieras REQ 3-34 Definición y Parametrización de Alarmas Financieras El sistema debe permitir definir un conjunto de alarmas financieras que permiten desencadenar alertas para el usuario ante eventos administrativos o de gestión, según criterios parametrizables por institución. 3.5 Funciones de soporte a la operación Como parte del desafío de modificar el enfoque del SIIF2 actual, desde un sistema orientado a las funciones a un sistema orientado a los procesos, la incorporación de funcionalidades de apoyo a la operación financiero contable es un factor que promueve este cambio de orientación promoviendo la captura de información en forma oportuna. Modelo Conceptual del SIIF2 01/04/ /203

47 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 Automatización de tareas REQ 3-36 Automatización de Tareas y Cálculos repetitivos En base al análisis de los principales procesos de negocio el sistema debe automatizar la mayor cantidad posible de tareas realizadas por los usuarios en forma repetitiva basados en cálculos realizados sobre algoritmos simples. REQ 3-37 Bandeja de Entrada de Tareas El sistema debe contener una Bandeja de Entrada de Tareas, en la cual se debe reflejar las tareas pendientes de cada usuario, así como los avisos de las alarmas financieras que corresponden a cada tipo de rol. 3.6 Funciones de soporte para el control y auditoría El SIIF actual presenta debilidades en las funciones de apoyo específicas para las tareas de auditoría, tanto para las realizadas por el Tribunal de Cuentas como por los órganos internos de auditoría. Habitualmente cuando un órgano de control inicia una auditoría debe solicitar los antecedentes en formato impreso, así como la generación de claves de usuarios que le permitan acceder al sistema de administración financiera para realizar sus tareas de control. El SIIF2 debe permitir automatizar la realización de las tareas de control tanto de los órganos de control externos como internos. REQ 3-38 Funcionalidades automatizadas de control y auditoria El sistema debe brindar funcionalidades automatizadas de control y auditoria que permitan consultar on-line información sobre las transacciones financieras, así como sobre la documentación de soporte contenida en el sistema de información, de manera específica para los órganos de control. A modo de ejemplo es posible mencionar la generación de roles de auditoria con acceso de solo lectura a toda la información, la definición de criterios de búsqueda ad hoc para actividades de auditoria y la capacidad de consultar información de soporte almacenada en el sistema. 3.7 Configuración La cobertura institucional tiene necesidades de gestión distintas motivadas por la diversidad de servicios que prestan a la ciudadanía. Ello implica que el SIIF2, tanto en el registro de la información, como en la explotación de la misma debe ser capaz de acomodar estas diferencias. Sólo así el sistema aportará valor a los incisos y unidades ejecutoras. Un sistema que no contemple este aspecto aporta un gran valor a los Órganos Rectores pero un valor cuestionable a las distintas entidades públicas. Modelo Conceptual del SIIF2 01/04/ /203

48 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 Introducción a la reportabilidad Distinguimos cuatro tipos de reportes en el marco de un SIAF que procedemos a definir: Reporte de búsqueda: reportes asociados al sistema transaccional que permite obtener listados de las principales entidades del sistema según un conjunto de filtros predefinidos. El usuario objetivo es todo aquel que use el sistema transaccional para registrar la información o auditar la información registrada. Reporte operativo: reportes asociados a la operación de una unidad ejecutora. Permite ver información con mayor nivel de transformación que las búsquedas. El usuario objetivo es tanto un responsable de unidad ejecutora como un perfil operativo al interior de la unidad ejecutora. Reporte analítico: reportes que permiten ver información a nivel de inciso o de toda la administración central. Permiten ver información con mayor nivel de transformación que los reportes operativos. Puede haber reportes con igual diseño a la vez en la reportabilidad operativa y la analítica. El usuario objetivo es un perfil táctico o estratégico con responsabilidad de análisis sobre un inciso o incluso sobre la administración central. Modelo Conceptual del SIIF2 01/04/ /203

49 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 Requisitos generales a la reportabilidad Antes de pasar a las particularidades de cada uno de estos tipos de reportabilidad hay una serie de requisitos que deben ser cumplidos por todas ellas y que procedemos a describir: REQ 3-40 Exportación a planilla y documento Todos los reportes generados por el sistema deberán ser exportables a planilla y documento. La exportación a documento deberá ser lo más fiel posible a lo que el usuario ve en pantalla y deberá generarse en formato abierto. La exportación a planilla deberá ser lo más orientada posible a trabajar los datos (cada dato en una celda, ausencia de celdas combinadas, respeto a los formatos numéricos y de fecha) y deberá generarse en formato abierto. REQ 3-41 Perfil de usuario y acceso a los reportes El acceso a cada reporte individual quedará determinado por el perfil del usuario. Asimismo se determinará también el conjunto de datos al que tiene acceso (visibilidad sobre la Unidad Organizativa, la Unidad Ejecutora, el Inciso o toda la Administración). REQ 3-42 Características tecnológicas de la reportabilidad Los reportes de búsqueda se desarrollarán sobre la misma arquitectura tecnológica que el sistema transaccional. Se recomienda, en caso de que se decida utilizar una plataforma de BI (comercial o no) que los reportes estratégicos, los analíticos y el área de análisis se desarrollen sobre la plataforma de BI. Los reportes operativos pueden ser desarrollados sobre la arquitectura del transaccional o sobre la plataforma de BI. La definición funcional detallada permitirá decidir cuál de las dos opciones es más conveniente. REQ 3-43 Oportunidad de la información para la reportabilidad Los reportes de búsqueda deberán proporcionar información en tiempo real. No puede haber desfase alguno entre la introducción de la transacción y la visualización de la misma a través de las búsquedas. Los reportes operativos deberán proporcionar información en tiempo real. Si condicionantes tecnológicos no lo permiten deberá haber el mínimo desfase (minutos). Los reportes analíticos, estratégicos y el área de análisis ofrecerán información del día anterior (d-1). Modelo Conceptual del SIIF2 01/04/ /203

50 Estructura de la capa de datos La capa de datos del SIIF2 responderá como minino a la estructura mostrada en la Ilustración 3-3, la cual se presenta a modo ilustrativo. Ilustración 3-3 Estructura de la capa de datos para la reportabilidad Capa de datos (repositorios): (I) BD SIIF2: Repositorio único de toda la información transaccional de los módulos principales del SIIF2. (II) DW relacional: DW relacional para la reportabilidad operativa. (III) Esquema agregado: Esquema adaptado a la reportabilidad operativa. (IV) Esquema replicado: Copia idéntica del repositorio transaccional. Esto permite aislar el efecto en performance de las búsquedas y la reportabilidad operativa de la transaccionalidad del sistema. (V) DW multidimensional: DW multidimensional del SIIF2. (VI) Cubos multidimensionales: Cubos analíticos para la explotación de información. Modelo Conceptual del SIIF2 01/04/ /203

51 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 (B) Área de análisis: definido en el apartado (C) Reportes estratégicos: definido en el apartado 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 (F) Reportabilidad operativa: definido en el apartado 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 Búsquedas Los reportes de búsqueda son reportes asociados al sistema transaccional que permiten obtener listados de las principales entidades del sistema según un conjunto de filtros predefinidos. El usuario objetivo es todo aquel que use el sistema transaccional para registrar la información o auditar la información registrada. REQ 3-45 Búsquedas y Entidades Existirá un reporte de búsqueda por cada entidad principal del sistema (i.e. búsqueda de afectaciones, búsqueda de compromisos, búsqueda de obligaciones, búsqueda de asientos contables, etc.). Modelo Conceptual del SIIF2 01/04/ /203

52 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 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 Reportes operativos Los reportes operativos son reportes asociados a la operación de una unidad ejecutora. Permiten ver información con un mayor nivel de transformación que las búsquedas. El usuario objetivo es tanto un responsable de unidad ejecutora como un perfil operativo al interior de la unidad ejecutora. La definición detallada de los reportes operativos a construir y sus características funcionales deberá realizarse durante el proyecto de desarrollo del sistema, sin embargo ciertos requisitos de alto nivel pueden definirse en este momento: Modelo Conceptual del SIIF2 01/04/ /203

53 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 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 Área de análisis El área de análisis es un lienzo en blanco donde el usuario tiene acceso a las medidas y dimensiones de análisis a partir de las cuales se genera la reportabilidad analítica y estratégica. Desde ahí el usuario puede crear sin restricción sus análisis ad-hoc combinando a su libre voluntad las métricas y dimensiones disponibles. Modelo Conceptual del SIIF2 01/04/ /203

54 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 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 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 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 entidad 3. Visualización de la transacción: Proporciona en formato imprimible la información básica de cabecera y detalle de una transacción. 3 Se entiende por entidad las distintas entidades de negocio del modelo de Entidad Relación del sistema. Por ejemplo: las afectaciones, los compromisos, las obligaciones, los beneficiarios. Modelo Conceptual del SIIF2 01/04/ /203

55 Reportabilidad operativa: o Libro de diario contable: Proporciona el listado de transacciones de contabilidad que cumplen los filtros del reporte, ordenadas por fecha y folio y con el detalle de los montos al debe y haber por cuenta contable. o Libro de mayor contable: Proporciona para los filtros seleccionados del reporte el saldo final de las cuentas contables seleccionadas así como la posibilidad de ver los asientos contables que contribuyen al saldo de cada cuenta. o Detalle presupuestario: Proporciona el listado de transacciones de afectación o compromiso u obligación (según se elija) que cumplen los filtros del reporte, ordenadas por fecha y folio con la posibilidad de acceder al detalle de los conceptos presupuestarios de cada transacción. o Detalle de saldos presupuestarios: Proporciona para los filtros seleccionados del reporte el saldo final de cada concepto presupuestario así como la posibilidad de ver el conjunto de transacciones presupuestarias que contribuyen a dicho saldo. Este reporte existe para cada una de los tres tipos de transacciones presupuestarias. o Cartera financiera presupuestaria: Proporciona, para los filtros seleccionados, por principal o beneficiario el saldo de afectación (o compromiso, devengado y obligado según se elija) y el detalle de transacciones que contribuyen a dicho saldo. o Cartera financiera contable: Proporciona, para los filtros seleccionados, por principal o beneficiario el saldo contable y el detalle de asientos contables que contribuyen a dicho saldo. o Cartera financiera bancaria: Proporciona, para los filtros seleccionados, por cuenta bancaria el saldo contable y el detalle de movimientos bancarios que contribuyen a dicho saldo. o Reporte de conciliación bancaria: Proporciona para los filtros seleccionados, por cuenta bancaria, la diferencia entre el saldo contable y bancario y el detalle de movimientos no conciliados que contribuyen a generar dicha diferencia. Reportabilidad analítica: o Estado de ejecución presupuestaria: Proporciona para los filtros seleccionados la visión completa del clasificador de gasto y muestra en columnas los créditos, el afectado, el comprometido, el obligado y el pagado. El reporte permitirá realizar drill-down a través del clasificador de gasto. El reporte debe ofrecer también una visión equivalente para el estado de ejecución de los recursos. o Balance de sumas y saldos contables: Proporciona para los filtros seleccionados la visión completa del plan de cuentas contable y muestra en columnas el saldo inicial, los débitos, los créditos y el saldo final de cada cuenta o grupo de cuentas. El reporte permitirá realizar drill-down a través del plan de cuentas contable. o Estado de Situación Financiera: Proporciona para los filtros seleccionados los saldos de carteras netas, disponibilidades y anticipos y depósitos. o Estado de la Deuda Pública: Proporciona para los filtros seleccionados los saldos de deuda agrupados por tipo y vencimiento. Modelo Conceptual del SIIF2 01/04/ /203

56 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 Interoperabilidad institucional La interoperabilidad institucional es la que se produce entre los módulos principales del SIIF2 y soluciones verticales de GRP que las distintas entidades públicas del ámbito de cobertura puedan tener en funcionamiento. Cuando una institución ya disponga de un GRP, o en el caso de que decida en un futuro implantar este tipo de sistema, el SIIF2 permitirá la interoperación entre este tipo de sistemas evitando al usuario la doble digitación de información. Las posibilidades de interoperación institucional se desarrollarán bajo el siguiente conjunto de requisitos: REQ 3-63 Integridad y coherencia de la estructura de datos La estructura y el contenido de la base de datos transaccional del SIIF2 debe ser íntegra (contener los datos de toda la cobertura), coherente, consistente y completa. Las Modelo Conceptual del SIIF2 01/04/ /203

57 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 Interoperabilidad transversal La interoperabilidad transversal es la que se produce entre los módulos principales del SIIF2 y sistemas transversales a la cobertura del sistema, como por ejemplo el SICE y el SNIP. El conjunto de sistemas con los que el SIIF2 interoperará transversalmente así como el alcance funcional de alto nivel de dicha interoperación se detallará en el apartado 6 del documento. Modelo Conceptual del SIIF2 01/04/ /203

58 REQ 3-70 Interoperación transversal El SIIF2 deberá desarrollar las capacidades funcionales y tecnológicas de interoperación para intercambiar información con sistemas de cobertura transversal en el ámbito público, como por ejemplo el SICE. La interoperación transversal deberá desarrollarse en ambos sentidos y será indispensable el uso de los catálogos básicos propietarios de cada uno de los sistemas de cobertura transversal. De acuerdo al avance hasta el momento del cierre del Modelo Conceptual es posible mencionar como ejemplo de los catálogos básicos para el SIIF2, el clasificador Presupuestario y el Plan de Cuentas, para el SICE el catálogo de Bienes y Servicios y para el RUPE el catálogo de Proveedores. Modelo Conceptual del SIIF2 01/04/ /203

59 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ógicamente 4 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 1. Cuenta Corriente (ingresos corrientes menos los gastos corrientes) Plan de Cuentas Contable 1. Directamente relacionadas con las Cuentas de Resultado (ingresos / gastos) 2. Cuenta de Capital (ingresos de capital menos los gastos de capital) 2.1 Ingresos de Capital 2.1 Disminución de Activo no corriente 2.2 Gastos de Capital 2.2 Incremento en el Activo no corriente 3. Financiamiento (fuente menos aplicaciones) 3.1 Fuentes 3.1 Incrementos de Activos Corrientes contra incrementos de Pasivos no Corrientes o Patrimonio. 3.2 Aplicaciones Financieras 3.2 Disminuciones de Activos Corrientes contra disminuciones de Pasivos Corrientes y Pasivos no Corrientes. La integración del presupuesto y la contabilidad es una exigencia para concretar el objetivo de un moderno Estado que requiere a los administradores públicos proveer el suministro de información accesible, oportuna y transparente de su gestión, para lo cual los clásicos 4 Estado Eficiente Administración Financiera Gubernamental Un enfoque sistémico José María Las Heras Editorial Buyatti Argentina. Modelo Conceptual del SIIF2 01/04/ /203

60 esquemas de información de la actividad estatal demostraron ser inadecuados en cuanto a la cantidad, calidad, confiabilidad y oportunidad de la información suministrada. En tal sentido, la visión sistémica, que permite ver a la organización como un todo, tanto con relación a la influencia de contexto como en la interdependencia de sus distintos componentes, resulta ser una herramienta significativa para el cumplimiento de los modernos requisitos gubernamentales. Como primer criterio, la visión sistémica es fundamental para la comprensión de la problemática de las organizaciones estatales, pero es necesario contar con un segundo enfoque que permita abarcar niveles desagregados de administración, para lo cual se recurre a los lineamientos proporcionados por la Teoría General de Sistemas, que aporta al Modelo Conceptual el enfoque necesario para conceptualización y el desarrollo en un nuevo SIIF. En este marco se entiende como sistema a: un conjunto de eventos o sucesos que no pueden ser divididos en forma independientemente, dado que, en caso contrario, se arriesgan tres importantes atributos, a saber: (i) cada parte (módulo) del sistema tiene propiedades que se pierden cuando se separan del sistema (ii) cada sistema tiene propiedades esenciales que no poseen ninguna de sus partes integrantes y (iii) ambos pierden el objetivo común. El enfoque de sistemas también suministra dos aportes sustanciales para organizar el flujo de datos y la producción de información dentro del SIIF2, los cuales son: Criterio de centralización normativa y descentralización operativa; Integración de sistemas. 4.1 Centralización normativa y descentralización operativa El SIIF2 requiere sustentarse en el principio conceptual y organizativo de centralización normativa y descentralización operativa. Esto implica que se concentren las funciones de diseño de políticas, dictado de normas y metodologías, así como las funciones de evaluación, y se desconcentren las funciones operativas o de gestión. Para garantizar el éxito en la aplicación de este principio, es importante que exista una clara delimitación de competencias, funciones y responsabilidades entre los Órganos Rectores y los ejecutores, evitando así la concurrencia, dispersión y superposición de múltiples organismos en la administración de los recursos públicos. La centralización normativa significa: Definir las políticas generales que enmarcan el funcionamiento de cada uno de los módulos; Elaborar y supervisar el cumplimiento de las normas, metodologías y procedimientos generales y comunes que regulan la operatoria del sistema, sin perjuicio de las adaptaciones que deban realizarse en forma descentralizada en función de las particularidades de determinadas agencias públicas; Administrar el sistema y producir la información relevante que le corresponda a éste; Evaluar el cumplimiento de las políticas. La descentralización operativa significa: Fortalecer la capacidad administrativa de las dependencias y entidades públicas para que puedan ejecutar eficientemente sus objetivos, metas y programas en el marco de las políticas definidas centralizadamente. Modelo Conceptual del SIIF2 01/04/ /203

61 El equilibrio entre la centralización normativa y la descentralización operativa debe funcionar como garantía de un eficiente funcionamiento de cada módulo y del SIIF2 en su conjunto. 4.2 Integración del sistema En función a lo expuesto anteriormente, los sistemas de información están integrados cuando es posible fusionar los distintos módulos de cada área objeto de estudio y formar un solo sistema, a partir de la identificación de sus elementos básicos, sin que cada uno de ellos pierda su identidad. Cuando las partes de un sistema están debidamente integradas, el total opera en forma más eficaz y eficiente de lo que lo hacía la suma de las partes. Igualmente, vale señalar que la calidad de una de las partes de un sistema condiciona la calidad del resto de las partes que lo integran, dados los lineamientos de la misma teoría de sistemas. No siempre es sencillo diseñar un sistema integrado, ya que en muchos casos se deben fusionar módulos afectados por diversos enfoques, principios, criterios, normas y técnicas específicas. Para ello, se requiere una adecuada armonización conceptual, normativa, funcional y operativa previa. En el caso de la administración financiera pública, el diseño de un SIIF2 es factible en la medida que las normas que regulan los diferentes sistemas que lo componen sean coherentes entre sí y que se den adecuadas respuestas técnicas para relacionar los diferentes tipos de información (presupuestaria, financiera, patrimonial, económica) que la conforman. La integración del sistema no se limita a implementar una mera técnica de agregación de módulos o a un rediseño de procesos; menos aún a una técnica de procesamiento de la información, restringida al ámbito de competencia específica de las unidades de informática. El concepto presupone y necesita estar enmarcado dentro de una visión y una estrategia de organización permeable al cambio, por lo que se exige el liderazgo y compromiso de todos los niveles intervinientes, tanto de los directivos como de los profesionales y administrativos y una lucha permanente contra la resistencia a cambiar para mantener el trabajo individual versus una gestión integrada. La integración implica un concepto moderno de organización sustentada en la visión sistémica e integrada y, por ende, ello lleva necesariamente a un nuevo modelo conceptual y organizacional y a una nueva forma de gestión de la administración financiera. Dentro de los cambios que resultan recomendables implementar en el modelo organizacional, a efectos de la integración de la información financiera, se pueden mencionar sintéticamente los siguientes: Modelo Conceptual del SIIF2 01/04/ /203

62 De A Información producida individualmente como poder de un área o un funcionario Trabajo en red como poder de la organización Trabajo aislado e individual Trabajo en comités de coordinación Fuertes esfuerzos individuales y aislados para producción de información parcializada Menores esfuerzos individuales pero coordinados y unidos para producir información integral e integrada de mayor calidad Controles formales de ejecución o desempeño Funcionarios con autonomía y responsabilidad en función de resultados Reconocimiento y promoción según indicadores de cantidad de insumos manejados individualmente Reconocimiento y promoción a nivel de equipo según la contribución al logro de las metas de mejoras colectivas 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. Modelo Conceptual del SIIF2 01/04/ /203

63 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. Núcleo Integrador del Sistema Alta, bajas, modificaciones de bienes Compra y venta de bienes Servicios Contrataciones de personal, Alquileres, Servicio de limpieza, Luz, gas, TE, etc. Ingresos Contabilidad Pagos Salarios Pagos a proveedores, Pagos al exterior, etc. Sueldos al personal, SAC, premios, etc. Recaudación de impuestos, Lotería / Casino, Renta de la Propiedad, Venta de Bines / Servicios, etc. Obras Deuda Cancelación de deuda, avales, intereses Préstamos Certificados de Obras, altas, concesiones, etc. Ilustración 4-1 La contabilidad como núcleo integrador del sistema El módulo de contabilidad, bajo el concepto de núcleo integrador, debe cumplir con una serie de atributos, entre los que se destacan los siguientes: Integridad: requiere cubrir la totalidad de las operaciones financieras y no financieras de repercusión patrimonial, sean del ámbito presupuestario o no presupuestario; Unicidad: consiste, fundamentalmente, en el registro único de los datos, los que deben ser ingresados al sistema una sola vez en el lugar donde ocurren las respectivas transacciones; Confiabilidad: debe ofrecer certeza de los datos, los hechos y las cifras, sustentados en marcos normativos y procedimientos fiables; Oportunidad: posibilita la obtención de información presupuestaria, contable y financiera actualizada en forma permanente; Verificación: posibilita el control de la calidad de la información mediante la inclusión de pistas de auditorías incluidas en todos los procesos (ver 3.2.2); Transparencia: requiere ofrecer información sobre la gestión financiera en forma clara, uniforme y pública; Modelo Conceptual del SIIF2 01/04/ /203

64 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 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 Registro único Todo movimiento económico-financiero presenta variadas facetas por las cuales puede analizarse, ya que dichos movimientos tienen efectos presupuestarios, contables y de flujo de fondos entre otros. Sin embargo, esta posibilidad de múltiple puntos de vista de análisis no implica la realización de tres o más registros. Por el contrario, implica la realización de un solo registro a efectos de garantizar la congruencia de cifras entre los distintos componentes de la administración financiera gubernamental y a la vez reducir el excesivo trabajo de registro. A efectos de que el SIIF2 sea eficiente y genere confiabilidad de la información suministrada, todas las transacciones con incidencia económico-financiera que realicen las entidades gubernamentales deben ingresarse una sola vez al sistema, eliminando la duplicidad de registros y por ende de datos, para una misma transacción. Modelo Conceptual del SIIF2 01/04/ /203

65 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 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 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 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 , como último Manual aprobado y en vigencia, si al momento del desarrollo del sistema existiera una actualización del mismo deberá estar sustentado en el último aprobado por el FMI. Modelo Conceptual del SIIF2 01/04/ /203

66 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 de Empresas/ Entidades Sector de Empresas no Financieras 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. 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 Gobierno General Comprende las entidades cuya actividad primaria es desempeñar las funciones de gobierno. Comprende las entidades creadas con el objeto de producir bienes y servicios no financieros para el mercado. Sector de Entidades Financieras Comprende las entidades cuya actividad es prestar servicios financieros para el mercado. 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. Empresas Públicas no Financieras 6 Entidades Financieras (incluyendo el Banco Central del Uruguay) 7 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 Entidades Financieras: Constitución de la República Oriental del Uruguay - Artículo: 196. Modelo Conceptual del SIIF2 01/04/ /203

67 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 Social 8 Comprende todas las unidades institucionales que realizan la gestión de un sistema de seguridad social. Sector Gobierno Departamental 9 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: Gobiernos Departamentales: Constitución de la República Oriental del Uruguay Artículo: 262. Modelo Conceptual del SIIF2 01/04/ /203

68 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 Estructura desde la Administración Financiera Sobre la base de la centralización normativa y descentralización operativa será necesario estructurar al Sector Público Uruguayo a efectos del adecuado funcionamiento de la Administración Financiera. REQ 4-8 Estructura desde la administración financiera La estructura bajo el concepto de la Administración Financiera, deberá contemplar las siguientes agrupaciones: Gobierno Central sin BPS, normalmente integrado por los tres poderes del Estado (Legislativo, Judicial y Ejecutivo), con sus distintas jurisdicciones responsables de la prestación de servicios para satisfacer las demandas comunitarias esenciales y acciones de regulación y de control, conforme a los siguientes sustentos: Financiamiento; se deriva de la función de recaudación que es asignada al Estado y el crédito público (deuda pública y endeudamiento), Personería jurídica: surge del origen fundacional del Estado expresado a través de la Constitución, y Patrimonio: comprende la sumatoria del conjunto de las instituciones de los tres poderes que lo integran. Organismos descentralizados, creados por normas especiales, asignándoles una determinada función (tradicionalmente inherentes a la administración central) y que por razones de mayor eficiencia y eficacia requieren una administración autónoma, siendo necesarios asignarles: Personería jurídica, Patrimonio propio Financiamiento: puede ser por recursos propios o por transferencias del Tesoro. Organismos autónomos, creados por leyes específicas por las cuales tienen autonomía en las decisiones, aunque no en todos los casos autarquía, mientras que el origen de los recursos puede provenir principalmente del tesoro. Gobiernos Departamentales También se pueden incluir dentro de este grupo a los Gobiernos Municipales Empresas y Sociedades Estatales, organizadas de acuerdo a las normas de carácter comercial, por lo cual actúan en el mercado y se suelen financiar total o parcialmente por el precio de las tarifas. REQ 4-9 Unidades Rectoras, Unidades Ejecutoras y Unidades Organizativas El SIIF2 deberá contemplar las siguientes unidades para su funcionamiento: Unidades Rectoras: Formadas por las entidades centralizadas responsables de formular las normativas del funcionamiento del SIIF2, a saber: Modelo Conceptual del SIIF2 01/04/ /203

69 Unidad Rectora Presupuesto: es la unidad responsable de definir el conjunto de principios, normas, procedimientos y dictar las pautas que se aplicarán a instituciones, procesos y procedimientos del módulo de presupuesto del SIIF2. A su vez, ingresará al SIIF2 el presupuesto de ingresos y egresos, quinquenal y anual, aprobado por la Legislatura como así también las modificaciones autorizadas a dichos presupuestos. Unidad Rectora Tesorería: es la unidad responsable de definir el conjunto de principios, normas, procedimientos y dictar las pautas que se aplicarán a instituciones, procesos y procedimientos del módulo de tesorería del SIIF2. A su vez, administrará en el SIIF2 los recursos del Tesoro así como los pagos realizados por el Tesoro y todos los ajustes relacionados con cualquiera de dichos movimientos. Unidad Rectora Contabilidad: Administrará el SIIF2 en forma general, velando por su integridad como sistema integrado de administración financiera pública. A su vez, es la unidad responsable de definir el conjunto de principios, normas, procedimientos y dictar las pautas que se aplicarán a instituciones, procesos y procedimientos del módulo de contabilidad del SIIF2, e ingresará al sistema los asientos de apertura y cierre del ejercicio en forma automática y tendrá como responsabilidad emitir los EEFF. Unidad Rectora Deuda Pública: es la unidad responsable de definir el conjunto de principios, normas, procedimientos y dictar las pautas que se aplicarán a instituciones, procesos y procedimientos del módulo de deuda pública del SIIF2. A su vez, ingresará al SIIF2 las transacciones de amortización de deuda, intereses, préstamos, colocación de títulos públicos e inversiones financieras, en forma directa o mediante mecanismos de interoperabilidad. Unidad Rectora Compras y Contrataciones: es la unidad responsable de definir el conjunto de principios, normas, procedimientos y dictar las pautas que se aplicarán a instituciones, procesos y procedimientos del Sistema de Compras y Contrataciones Estatales (SICE), asegurando que los mecanismos de integración entre el proceso de compras y adquisiciones, el registro único de proveedores del estado, y el proceso financiero contable, gestionado en el SIIF2. Permita registrar en forma oportuna los compromisos de recursos y las variaciones al patrimonio generadas por el proceso de compras y adquisiciones. Unidad/es Rectora/s de Recursos: Será/n el/las área/s responsable/s de definir el conjunto de principios, leyes, normas, instituciones, procesos y procedimientos que intervienen o se utilizan en la determinación de los ingresos, su percepción en forma voluntaria, la identificación de incumplimientos y el cumplimiento forzado del conjunto de fuentes de ingresos por contribuciones con incidencia económica y/o financiera para el Tesoro Nacional. Informará los ingresos devengados y percibidos en sus respectivas áreas (DGI, Aduanas, Casino, Lotería), así como los créditos que los mismos generen. Unidad Rectora Inversión Pública: Será el área responsable del conjunto de principios, leyes, normas, instituciones, procesos y procedimientos que regulan, intervienen o se aplican para la identificación, preparación, evaluación de prefactibilidad y de factibilidad, ejecución (por contrato o por administración) y evaluación de los proyectos y programas de inversión. Informará sobre los presupuestos de obras/proyectos y el avance de las mismas imputando los costos correspondientes. Unidad Rectora Recursos Humanos: Será el área responsable de la emisión de leyes, normas, instituciones, procesos y procedimientos que intervienen o se aplican Modelo Conceptual del SIIF2 01/04/ /203

70 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) 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 Financieros 11 (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 Estados Financieros: Nombre dado por las Normas Internacionales de Contabilidad para el Sector Público (NICSP) a un conjunto completo de Estados según lo define la NICSP N 1 Presentación de Estados Financieros, concepto este mucho más amplio que el conocido como Estado Contables. Modelo Conceptual del SIIF2 01/04/ /203

71 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 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 o o Responsable firmante: Contaduría General de la Nación Concepto: Ente Contable madre al cual se consolidará o integrará la información contable del resto del Sector Público. Entidades comprendidas: Servicios Descentralizados del dominio industrial y comercial, conforme a las siguientes denominaciones a nivel individual: Administración Nacional de Telecomunicaciones (ANTEL), Administración Nacional de Puertos (ANP), Administración Nacional de Correos (ANC) y Administración de las Obras Sanitarias del Estado (OSE), y Entes Autónomos del dominio industrial, comercial y financiero, además del Banco Central de Uruguay (BCU), Banco de la República Oriental del Uruguay (BROU), Instituto Nacional de Colonización (INC), Banco de Previsión Social (BPS), Administración Nacional de Combustibles y Portland (ANCAP), Administración Nacional de Usinas y Trasmisiones Eléctricas (UTE), Agencia Nacional de Vivienda (ANV), Banco de Seguros del Estado (BSE) y Banco Hipotecario del Uruguay (BHU), Administración de Ferrocarriles del Estado (AFE) y Primeras Líneas de Navegación Aerea (Pluna) 12. Entes Contables de los siguientes Subsectores: Empresas Públicas Financieras y No Financieras, Descentralizado y Fondos de la Seguridad Social 12 En el caso de ANEP, UDELAR, INAU, y ASSE se está revisando con el Tribunal de Cuentas su forma de incorporación dentro del Ente Contable del Sector Gobierno Central. Modelo Conceptual del SIIF2 01/04/ /203

72 o o 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. Concepto: Entes Contables separados e individuales para cada entidad gubernamental según sean sus características. 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 controlen 13 a dichas entidades, como ser el caso de las Empresas Públicas con subsidiarias o los Gobiernos Departamentales que tengan los Municipios, en cuyo caso deberán estructurarse Centros de Consolidación de carácter secundarios y que responderán a la Unidad de Consolidación Principal. 13 Control bajo el concepto de la NICSP N 6 Estados Financieros Consolidados y Separados. Modelo Conceptual del SIIF2 01/04/ /203

73 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 o o o Clasificador Presupuestario: Manual de Estadísticas de las Finanzas Públicas (2001) del Fondo Monetario Internacional; y 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); Deben ser desarrollados en forma conjunta; Mantenidos en forma constante, y con una frecuencia de actualización en función de la necesidad que de ellas se tenga, por lo cual deberán contar con la suficiente flexibilidad que permita incorporar las nuevas transacciones Modelo Conceptual del SIIF2 01/04/ /203

74 o originadas por futuras operaciones, ya que solamente de esta forma se garantizará la vital comparabilidad 14 de los ejercicios económicos; 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 Clasificadores Presupuestarios Los Clasificadores Presupuestarios constituyen la estructura funcional donde se sustentarán en el SIIF2. Dichos clasificadores permitirán organizar y presentar todas las operaciones desarrolladas en el ámbito del Sector Público Uruguayo, conformando un sistema de información realmente ajustado a las necesidades integrales del Gobierno, llevando estadísticas sobre los sectores públicos nacionales y posibilitando un análisis objetivo de las acciones ejecutadas por dicho Sector. Por lo expuesto, el conjunto de clasificaciones presupuestarias representará una herramienta fundamental para el registro de la información relativa al proceso de recursos y gastos de la actividad pública, debiendo responder cada clasificador a un propósito u objetivo determinado; sin perjuicio de que, en su diseño, deben considerarse las necesarias interrelaciones que existen entre todos ellos a los fines de enriquecer el análisis y evaluación de la ejecución presupuestaria. A fin de precisar las interrelaciones de los clasificadores entre sí, es necesario distinguir los clasificadores primarios, a través de los cuales se registra cada transacción, sea ésta de recurso o de gasto, de los clasificadores derivados, que surgen de la combinación de dos o más clasificadores. Es decir en el caso de los clasificadores derivados se estructuran automáticamente por combinación de los clasificadores primarios y, por lo tanto, no se capturan al momento de registrar cada transacción u otro flujo en particular. Los objetivos que deben cumplir los clasificadores presupuestarios son los siguientes: Contar con clasificaciones presupuestarias que permitan tener un lenguaje único para toda la administración financiera del país. Posibilitar su integración con otros clasificadores, planes y catálogos. Permitir la obtención de información consolidada del Sector Público Uruguayo. Contribuir al fortalecimiento de los procesos de toma de decisiones y de rendiciones de cuentas. Garantizar una administración financiera transparente. Dotar a las entidades del Gobierno General de una herramienta de Administración Financiera que les brinde información útil, confiable y oportuna, a los fines de lograr una adecuada gestión. 14 Comparabilidad: Objetivo de los EEFF según las NICSP. Modelo Conceptual del SIIF2 01/04/ /203

75 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 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 Financiamiento Geográfico 15 de Primarios 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 del FMI 15 Clasificador Geográfico: deberá contemplar las necesidades de clasificación geográficas que puedan llegar a tener las instituciones , como último Manual aprobado y en vigencia, si al momento del desarrollo del sistema existiera una actualización del mismo deberá estar sustentado en el último aprobado por el FMI. Modelo Conceptual del SIIF2 01/04/ /203

76 Clasificadores Presupuestarios Por Carácter Económico Secundarios Gastos Por Objeto Primarios Por Carácter Económico Derivados Por Programática Categoría 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 ordenamiento 17 : 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 Subsector Gobierno Central Subsector Gobierno Descentralizado Fondos de la Seguridad Social 17 Los ejemplos dados desde el punto 6 a 8 son a efectos ejemplificativos. Modelo Conceptual del SIIF2 01/04/ /203

77 Municipios 6: Jurisdicciones: 1 dígito Poder Ejecutivo Poder Legislativo Poder Judicial Organismos de Control 7: Instituciones: 3 dígitos Presidencia de la República Ministerio de Defensa Nacional Ministerio de Economía y Finanzas 8: Unidad Ejecutora: 3 dígitos Servicios de Apoyo a la Presidencia de la República 9: Unidad Organizativa: 2 dígitos Unidad Organizativa Despacho Presidente Unidad Organizativa Ceremonial y Protocolo El presente clasificador debe ser abierto (no taxativo y definitivo), razón por la cual se incluirá la especificación Otros, con el código 99 como identificación distintiva. Dicho código sólo podrá ser utilizado por la CGN a efectos de hacer flexible el mismo (debiendo establecer, asimismo, la correspondiente relación con los clasificadores derivados). Dicha flexibilidad tiene por objeto permitir su adecuación a las diversas situaciones que se presenten. REQ 4-17 Estructura por Objeto del Gasto El Clasificador por Objeto del Gasto deberá ser diseñado e implementado con un nivel de desagregación tal que permita que sus cuentas faciliten el registro único de todas las transacciones públicas con incidencia económico-financiera. La estructura del Clasificador por Objeto del Gasto deberá contener una apertura mínima de cinco (5) niveles, con nueve (9) dígitos, debiendo asegurarse su agrupamiento y ordenamiento sobre criterios lógicos predefinidos, pudiendo resultar necesario incorporar niveles adicionales en partidas que por su naturaleza así lo demanden a efectos de garantizar la integración de la información financiera, conforme al siguiente enfoque: Modelo Conceptual del SIIF2 01/04/ /203

78 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 Planes de Cuentas Contable A efectos de viabilizar el registro y procesamiento sistemático de los flujos económicofinancieros en la contabilidad, se requiere de clasificadores Planes de Cuentas que permitan catalogar y agrupar los cambios experimentados por las principales variables que determinan y resultan del desempeño de un ente, atendiendo a una precisa tipificación de la naturaleza de dichos flujos, de manera tal que las agregaciones y desagregaciones de información que surjan de la aplicación de tales Planes, exterioricen conjuntos homogéneos Modelo Conceptual del SIIF2 01/04/ /203

79 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 consolidada 18, según lo establece la NICSP Nº 6 Estados Financieros Consolidados y Separados, al tiempo que viabilizará y facilita el proceso de consolidación, toda vez que: permite la identificación en forma precisa de componentes significativos de los EEFF según el nivel de la institución pública de que se trate; permite la identificación en forma precisa de las partidas de créditos y deudas intergubernamentales; permite la apertura a octavo nivel de mayores niveles de desagregación, siendo a tales efectos indispensable, a los fines de consolidación, la catalogación de las partidas de créditos y deudas y de resultados por transacciones intergubernamentales, según los clasificadores que identifiquen en forma precisa cada institución. REQ 4-20 Estructura del Plan de Cuentas Contable La estructura del Plan de Cuentas Contable del SIIF2 deberá desarrollarse sobre la base de una apertura mínima a siete (7) niveles, alcanzando un total de (15) dígitos, deberá cumplir con las siguientes agrupaciones de: (i) clase, (ii) grupo, (iii) cuenta; (iv) subcuenta y (v) Subcuenta anexa. A efectos de cubrir acabadamente necesidades de información adicional a las previstas en las aperturas a nivel de subcuentas, y que pueden variar de una institución pública a otra, se considera la existencia en el séptimo nivel de un Auxiliar, como se expone en el siguiente Cuadro: Nivel Agrupación Digito Aperturas 1 Clase un dígito ACTIVO, PASIVO, PATRIMONIO, INGRESOS y GASTOS 2 Grupo un dígito ACTIVO, PASIVO: Corriente y No corriente; PATRIMONIO: Patrimonio público e Intereses minoritarios INGRESOS: Impuestos, Contribuciones sociales, Multas, sanciones, remates y confiscaciones de origen no tributario, Ingresos y resultados positivos por ventas, Ingresos de la propiedad, Transferencias, Otros 18 Cumplimiento del Decreto Nª 103/91 a efectos de lograr la consolidación del Sector Público. Modelo Conceptual del SIIF2 01/04/ /203

80 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 Cuenta 20 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) Catálogos de Bienes Es fundamental que el SIIF2 cuente con un sistema de codificación que permita representar todo el universo tanto de bienes de consumo como los activos fijos, con la flexibilidad suficiente para que las definiciones sean claras y precisas. Además, dicha codificación deberá poseer una serie de datos asociados, de manera tal que pueda ser utilizada por todas aquellas áreas involucradas en la administración de los bienes (presupuesto, compras y contabilidad). Así, el SIIF2 contemplará la correspondiente codificación de los bienes de tal modo que permita su integración en forma automática con el presupuesto y la contabilidad a efectos de obtener información homogénea partiendo desde su compra, su ingreso al inventario (alta de los bienes) y, por ende, su registro presupuestario y contable, incluyendo las variaciones acaecidas en los inventarios de los mismos. Para cumplir con dicho requerimiento del SIIF2, el catálogo de bienes debe responder y contener la apertura solicitada tanto por el Objeto del Gasto Presupuestario, como de la apertura del Plan de Cuentas Contable en lo relacionado a los activos (bienes de uso, bienes de infraestructura, bienes intangibles, activos biológicos, bienes de consumo, etc.). La integración a realizar debe ser automática por lo cual se recomienda que dicha relación se establezca para el alcance de todos los bienes a efectos minimizar las modificaciones posteriores, por tal motivo se podrá tomar el catálogo actualmente vigente en la medida que cumpla con lo dicho y en especial que su alcance sea total o se podrá tomar el de las 19 Sólo se toma una cuenta a modo de ejemplo. 20 Nivel a efectos de consolidación de la información. Modelo Conceptual del SIIF2 01/04/ /203

81 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 o o o o o Código de Segmento, Código de Familia, Código de Clase, Código de Material, y Datos Asociados. Es recomendable que el catálogo tenga como mínimo la estructura de ocho (8) dígitos, dividido para las dos partes identificadas, a saber: De 4 dígitos, que identificará la clase de objeto, De otros 4 dígitos, que aglutinará las características particulares de todos los elementos pertenecientes al objeto o clase genérica y o También será necesario que cuente con datos asociados donde cada objeto integrante del catálogo contará con una serie de datos adicionales asociados a los efectos de su integración. De esta manera se definirá: Serie de datos a los efectos del inventario, Serie de datos que posibiliten la administración de bienes, Serie de datos que posibiliten la gestión de compras, El conjunto de series de datos, que proveerán información para la gestión, toma de decisiones y control. Modelo Conceptual del SIIF2 01/04/ /203

82 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 Datos asociados Material Modelo Conceptual del SIIF2 01/04/ /203

83 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 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: Para los Gastos Aprobado El Presupuesto aprobado es la autorización para gastar o monto autorizado 21 de crédito derivado de leyes de asignación presupuestaria, otorgada por el Poder Legislativo Modificado Es el presupuesto aprobado por el Poder Legislativo que ha sido modificado a posteriori 22 con la correspondiente autorización. Las modificaciones pueden ser realizadas por la Legislatura o a quien ella delegue. 21 Artículo 95 del TOCAF. 22 Artículo 95 del TOCAF. Modelo Conceptual del SIIF2 01/04/ /203

84 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 Comprometido 23 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 Para los Recursos Estimados 25 Son los cálculos iniciales de los recursos que se estima recaudar en el ejercicio Modificados 26 Son las modificaciones realizadas a las estimaciones originales de recursos presupuestarios Devengado (Tratado en el punto 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 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 Conciliado en el Banco Es el momento en que lo conciliado alimenta la disponibilidad financiera de los fondos de libre disponibilidad de los Ministerios Base del devengado Los EEFF deben presentarse sobre base devengada tanto en gastos como en recursos pudiendo para estos últimos, y hasta tanto se perfeccione el registro de los recursos 23 Artículo 95 del TOCAF. 24 Artículo 14 del TOCAF. 25 Artículo 95 del TOCAF. 26 Artículo 95 del TOCAF. 27 Artículo 12 del TOCAF. Modelo Conceptual del SIIF2 01/04/ /203

85 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) 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 Unidas 29 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 a. Posibles bases de registro. 29 Sistema de Cuentas Nacionales Momento de registro. Modelo Conceptual del SIIF2 01/04/ /203

86 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 , expone los beneficios de la contabilidad de acumulación (o devengo), entre los que se mencionan: Es útil tanto para la responsabilidad como para la toma de decisiones. Los informes financieros preparados conforme a base de acumulación (o devengo) les permiten a los usuarios: Evaluar la responsabilidad para todos los recursos que controla la entidad y la implementación de esos recursos. Evaluar la situación y el rendimiento financieros, y los flujos de efectivo de la entidad. Tomar decisiones sobre si proporcionar recursos o mantener relaciones comerciales con la entidad. A un nivel más detallado, la presentación de informes de base contable de acumulación (o devengo) permitirán, entre otros, informar sobre: exponer la situación financiera general y los activos y pasivos actualmente disponibles; demostrar su responsabilidad ante el público por la administración de sus activos y pasivos reconocidos en los estados financieros; planificar el pago o la cancelación de los pasivos existentes; ofrecer un marco uniforme para la identificación de pasivos existentes y pasivos potenciales o contingentes; facilitar una mejor administración de los activos, lo que incluye un mejor mantenimiento, políticas de reemplazo más apropiadas, identificación y eliminación de los activos excedentes, y una mejor administración de los riesgos como fluctuaciones en el valor de los pasivos; poner de manifiesto el impacto de las decisiones financieras sobre el patrimonio y los activos netos, pudiendo llevar a que las entidades del sector público, al tomar decisiones financieras, adopten una visión más a largo plazo de lo que generalmente es posible al basarse en informes de efectivo o de efectivo modificado. 30 Transición de la base contable de acumulación (o devengo):v Directrices para entidades del Sector Público. Modelo Conceptual del SIIF2 01/04/ /203

87 Desde el punto de vista legal, en el caso de Uruguay 31, 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 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 Pagado Se considerará pagada una obligación cuando la Tesorería emita los medios de pago correspondientes (por ejemplo cheque o transferencia bancaria). En el caso de Pago por Nota, se imputará previo al mandado a pagar y el pagado definitivo cuando se realice la transferencia bancaria. En resumen, los momentos que se deben implementar e identificar dentro del SIIF2 son los detallados a continuación: 31 TOCAF: Art. 20º. Los créditos presupuestales se considerarán ejecutados cuando se devenguen los gastos para los cuales han sido destinados. Se entiende que los gastos se devengan cuando surge la obligación de pago por el cumplimiento de un servicio o de una prestación. Modelo Conceptual del SIIF2 01/04/ /203

88 Concepto Momentos Presupuestario Contable Gastos Aprobado Modificado Afectación Preventiva Compromiso Devengado Mandado a Pagar Pagado Devengado Mandado a pagar Pagado Recursos Estimado Modificado Devengado Percibido Devengado Percibido De tal forma, los procesos administrativo-financieros que originan recursos y fuentes (fuentes) y gastos y aplicaciones (usos) tienen un momento o etapa clave de sus respectivas transacciones, el devengado, el cual permite integrar los registros del presupuesto y la contabilidad y de esa forma el SIIF2 producirá información presupuestaria, financiera y económica en forma automática. Modelo Conceptual del SIIF2 01/04/ /203

89 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. 5.2 Módulo presupuestario Ilustración 5-1 Estructura de los módulos principales del SIIF2 En el presente apartado se describen los objetivos, requerimientos y aspectos de integración a tener en cuenta para el módulo presupuestario Objetivos El módulo de presupuesto debe contemplar las funcionalidades necesarias para el registro y la gestión asociada a todo el ciclo presupuestario, tanto para gastos como para ingresos, considerando las etapas del ciclo presupuestario de la siguiente forma: La formulación presupuestaria: original del presupuesto quinquenal de la República Oriental del Uruguay y las formulaciones anuales actualizadas mediante el ajuste de los valores e indicadores y las sucesivas rendiciones de cuentas, los que generarán los créditos disponibles para los ejercicios sucesivos dentro del quinquenio. Modelo Conceptual del SIIF2 01/04/ /203

90 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 Requisitos Actualmente en Uruguay existen subsistemas en producción que dan respuesta a las fases de formulación y evaluación presupuestaria, por ello en el presente documento el esfuerzo se focaliza en detallar los requisitos funcionales de la fase de ejecución presupuestaria. Aun así se incluyen también requisitos de muy alto nivel para la formulación y la evaluación que todo SIAF debe cumplir. Modelo Conceptual del SIIF2 01/04/ /203

91 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 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 Ejecución de los gastos REQ 5-4 Crédito inicial y modificaciones El módulo de ejecución del SIIF2 tomará como punto de partida de la ejecución los créditos de la Ley de Presupuesto aprobada. El sistema deberá permitir gestionar el ciclo de modificaciones presupuestales incrementos, disminuciones y reasignaciones - y contar en todo momento con el crédito vigente (inicial + modificaciones) y el crédito disponible (vigente afectaciones). REQ 5-5 Solicitud de modificaciones El sistema deberá contar con funcionalidades que permitan gestionar el proceso de solicitud y aprobación de modificaciones presupuestales incrementos, disminuciones y reasignaciones tanto en los Incisos como en los Órganos Rectores de acuerdo al marco legal vigente. REQ 5-6 Distribución de créditos por Unidad Ejecutora y Unidad Operativa El sistema deberá ofrecer la posibilidad de distribuir los créditos presupuestales de cada programa y objeto del gasto por Unidad Ejecutora y/o por Unidad Operativa según las necesidades de cada Inciso que conforma la Ley de Presupuesto. REQ 5-7 Funcionalidad de Topes y Abatimientos El sistema debe permitir en casos excepcionales y a perfiles seleccionados fijar topes de ejecución de manera selectiva a los objetos de ejecución del gasto que el usuario indique. Este tope puede ser fijado para cada objeto de forma porcentual o absoluta. Modelo Conceptual del SIIF2 01/04/ /203

92 REQ 5-8 Etapas de ejecución presupuestaria de los gastos El sistema deberá contemplar la existencia de cinco etapas de ejecución presupuestaria en el caso de los gastos: i) afectación preventiva, ii) compromiso, iii) devengado (obligado verificado), iv) mandado a pagar (que incluye obligado intervenido y obligado priorizado) y v) pagado. El punto de partida de la cadena presupuestaria serán los créditos vigentes de la ley de presupuesto con sus posteriores actualizaciones. REQ 5-9 Lógica de cadena presupuestaria De una entidad (o etapa) cualquiera de la cadena presupuestaria se podrá encadenar entidades (etapas) de la siguiente fase de ejecución respetando siempre que la suma de montos de entidades de una etapa posterior sea menor o igual al monto de la entidad precedente. REQ 5-10 Prudencia presupuestaria Las transacciones de la cadena presupuestaria en estado generado reservarán crédito de la transacción previa. En caso de ser anuladas se liberará el crédito asociado. Este principio permite evitar conflictos en caso de aprobación masiva de transacciones generadas. REQ 5-11 Información requerida por cada entidad La información requerida por cada entidad (afectación preventiva, compromiso, devengado, etc.) deberá ser definida en detalle durante la fase de levantamiento funcional del proyecto de implementación del sistema. Deberán contemplarse por lo menos el objeto del gasto, el año, la fecha, la unidad organizativa, el área programática, el programa, el proyecto, fuente de financiamiento, moneda y el monto entre otros. REQ 5-12 Captura de información orientada a documentos de negocio La captura de información deberá realizarse orientada a los documentos de negocio que soportan el proceso (por ejemplo licitaciones, órdenes de compra, facturas, notas de crédito) De esta manera el usuario que registra información del sistema deberá operar bajo la premisa que está introduciendo una factura en el sistema en vez de que está dando de alta una obligación. El sistema contemplará igualmente la posibilidad de entrar información de forma neutra (sin asociarlo a un documento de negocio). REQ 5-13 Arrastre de información a lo largo de la cadena La información capturada deberá heredarse a lo largo de la cadena de forma que toda la información común entre, por ejemplo, una afectación preventiva y un compromiso, no deba volver a introducirse. La información se capturará siempre en el primer momento en que esté disponible (i.e. adjudicación de una compra en el momento del compromiso, ingreso de bien en el momento del devengado, el envío a la tesorería para el pago en el momento de la obligación y por último la cancelación de la factura en el momento del pago). REQ 5-14 Obligaciones y pagos sin compromiso El sistema ofrecerá facilidades a los usuarios, en los casos que la normativa lo permita, para realizar obligaciones y pagos directamente desde la afectación preventiva sin necesidad de realizar todos los pasos de la cadena presupuestaria. El sistema generará el compromiso y el devengo correspondiente para que la consistencia de datos de la cadena presupuestaria se mantenga de forma transparente para el usuario final. Modelo Conceptual del SIIF2 01/04/ /203

93 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 Estado de las transacciones REQ 3-25 Estado de las transacciones. Las transacciones aprobadas sólo serán modificables a través de transacciones de ajustes que pasen por el mismo circuito de validación que la transacción original. No se permitirá la existencia simultánea de ajustes en estado generado. Para poder reajustar una transacción será obligatorio que todos los ajustes previos estén aprobados. REQ 5-18 Cartera financiera La información asociada al proveedor (y la posible existencia de un beneficiario) se manejará en una sub-entidad independiente asociada al compromiso, al devengo y al pago. Esto permitirá ofrecer reportabilidad de mayor riqueza relativa a los proveedores de la cobertura. REQ 5-19 Gestión multimoneda La ejecución de gasto en moneda extranjera se controlará en base a tipos de cambio provisionales en las etapas de afectación y compromiso. En el momento de la obligación se registrará el asiento contable asociado en base al tipo de cambio del momento. Cualquier diferencia generada por tipo de cambio, tanto a favor o en contra, producida por variaciones en el tipo de cambio entre los momentos de obligación y pago tendrá su correspondiente impacto financiero, generándose el movimiento contable correspondiente. REQ 5-20 Ejecución de gastos asociados a la Gestión Humana La ejecución de gastos asociados a los sueldos de los funcionarios deberá contemplar los escenarios de interoperación necesarios para poder generar, a partir de la información del SGH-SLH, los compromisos asociados al pago de los sueldos de todo el ejercicio fiscal y el devengamiento mensual del gasto. REQ 5-21 Ejecución de gastos asociados a Bienes de Uso y Consumo La ejecución de gastos asociados a los Bienes de Uso y Consumo deberá contemplar los escenarios de interoperación necesarios para integrarse con el SICE, a través del catálogo de cuentas relacionado con el objeto del gasto y el plan de cuenta contable y de los procedimientos a efectos de generar los compromisos, devengamiento y pagos asociados a los procesos de licitación manejados por el SICE. Modelo Conceptual del SIIF2 01/04/ /203

94 REQ 5-22 Ejecución de gastos asociados a Inversión La ejecución de gastos asociados a los proyectos de Inversión deberá contemplar los escenarios de interoperación necesarios para generar las transacciones asociadas de forma consistente los criterios y la información que maneja el SNIP. REQ 5-23 Ejecución de Proyectos Internacionales El sistema deberá contar con las funcionalidades necesarias para gestionar los proyectos financiados por organismos multilaterales. Para ello deberá contar con un repositorio que contenga la información del préstamo o proyecto permitiendo su rendición y generación en forma automática de los reportes solicitados por dichos organismos. Los pagos asociados a la ejecución de dichos recursos quedarán automáticamente asociados a las cuentas corrientes creadas a tal efecto. Esta funcionalidad debe contar con los desarrollos necesarios para interoperar con el Sistema de Proyectos Internacionales cuando el mismo se encuentre operativo. REQ 5-24 Arrendamientos Oficiales El sistema debe contar con las funcionalidades necesarias para registrar, gestionar y validar los pagos de los alquileres mensuales que surgen de los contratos de arrendamientos oficiales. Para ello deberá contar con un repositorio de datos que contenga la información correspondiente a los contratos de arrendamientos oficiales, generando información que permita controlar en forma restrictiva las obligaciones que los Incisos a nivel de Unidad Ejecutora registren en el sistema correspondiente al pago de alquileres. Esta funcionalidad debe funcionar en forma interdependiente con el módulo presupuestario y el módulo contable para registrar los movimientos contables y presupuestarios correspondientes en forma automática. Al inicio del ejercicio la funcionalidad en base a la información del repositorio generara todas las afectaciones y compromisos del ejercicio y generara periódicamente las obligaciones correspondientes. REQ 5-25 Gestión de Fondos Rotatorios De acuerdo a la normativa vigente, el sistema debe contar con las funcionalidades necesarias para una adecuada gestión de los Fondos Rotatorios autorizados para los Incisos a nivel de Unidad Ejecutora. La funcionalidad de gestión de fondos rotatorios debe permitir la ejecución de operaciones normales o de regularización de fondos. El módulo debe realizar en forma automática al inicio del ejercicio el cálculo de la disponibilidad de fondos rotatorios para cada Inciso en base a la duodécima parte del crédito presupuestal menos la diferencia que se arrastra del ejercicio anterior y debe liberar una operación de tesorería desde la CUN a las cuentas de los Incisos. Esta funcionalidad debe registrar la autorización de los fondos rotatorios como anticipo de fondos y su liquidación, al momento de devengar dicha liquidación, en el módulo contable. REQ 5-26 Generación y Envío de Resguardos de Retenciones a DGI El sistema deberá generar en forma automática los resguardos asociados a las retenciones de impuestos (por ejemplo: IVA, IRPF no dependientes, IRPF arrendamientos, etc.). La información de estos resguardos generados deberá ser enviada a la DGI en un formato establecido por dicho Organismo. Modelo Conceptual del SIIF2 01/04/ /203

95 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 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ómicofinancieras sobre las variables propias del organismo que se tienen en consideración para la estimación. REQ 5-28 Transacciones asociadas a recursos El SIIF2 debe contar con los mecanismos necesarios para que en el componente recursos del Módulo de Presupuesto las áreas que realizarán transacciones que son registradas en el Sistema sean las siguientes: DGI, DNA, Dirección Nacional de Loterías, Dirección General de Casinos, TGN, Cajas Paraestatales, Incisos, BROU, BCU, Otros REQ 5-29 Unidades de registro asociadas a recursos El SIIF2 debe contar con los mecanismos necesarios para que en el componente recursos del Módulo de Presupuesto las unidades de registros se encuentren lo más próximas posibles al evento que genera la transacción, resultando aconsejable que el registro lo realice directamente la Unidad Rectora Recursos, a través de sus entidades públicas dependientes, en especial, a través de la DGI y DNA. En el caso de los ingresos provenientes de Dirección Nacional de Loterías y Quinielas y Dirección General de Casinos correspondería incorporarlos directamente al módulo presupuestal, quedando el registro a cargo de las Unidades Ejecutoras de Dirección Nacional de Loterías y Quinielas y Dirección General de Casinos, como asimismo el tratamiento de los recursos propios de los distintos Incisos que conforman el Gobierno Central. En el caso que este proceso requiera un proceso gradual de implementación, el módulo de presupuesto del SIIF2 deberá poder capturar los datos necesarios para la registración presupuestaria de los ingresos mediante mecanismos de interoperación adecuados desde los sistemas de origen de las entidades recaudadoras o bien permitir el registro en forma directa sobre el módulo de presupuesto del SIIF2. Modelo Conceptual del SIIF2 01/04/ /203

96 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 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 Evaluación La adecuada integración de la evaluación al ciclo presupuestario es clave para una adecuada gestión del presupuesto público. No contar con una fase de evaluación que retroalimente al ciclo presupuestario genera habitualmente la presencia de presupuestos inerciales, donde la formulación y ejecución presupuestaria no consideran la información de los ejercicios anteriores. REQ 5-35 Orientación a programas y objetivos estratégicos El sub-módulo de evaluación deberá apoyar a la gestión orientada a objetivos estratégicos e indicadores asociados a los distintos programas presupuestarios (que en algunos casos pueden ser transversales a varios incisos). La información sobre gestión estratégica a considerar por el módulo de evaluación es la definida en el Sistema de Planificación Estratégica y Evaluación (SPE). REQ 5-36 Elementos comunes entre la ejecución y la evaluación El clasificador de programas presupuestarios deberá ser de uso y mantención común a ambos sub-módulos de manera que la evaluación en base a estos criterios a partir de la información de ejecución pueda realizarse de forma transparente. Modelo Conceptual del SIIF2 01/04/ /203

97 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 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 submódulo de ejecución presupuestaria 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 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 Presupuesto y gestión de la deuda REQ 5-42 Generación de fuentes de financiamiento a partir de la emisión de deuda Las transacciones de emisión de deuda originada para la captación de recursos generarán el conjunto de transacciones de los correspondientes ingresos presupuestarios. Se realizará Modelo Conceptual del SIIF2 01/04/ /203

98 una ejecución simultánea de devengo y percibido asociado al monto y características de la emisión realizada. REQ 5-43 Generación de transacciones presupuestarias de gasto a partir del servicio de la deuda Al inicio de ejercicio y en base al inventario de instrumentos de deuda registrados por el Banco Central del Uruguay (BCU) o por la Unidad de Gestión de Deuda del MEF se registrarán las afectaciones y compromisos asociadas al servicio de la misma. El sistema permitirá registrar sus devengamientos, las obligaciones y pagos asociados a la misma a medida que dichos eventos económicos se produzcan, ya sea mediante interoperabilidad o captura directa de datos. 5.3 Módulo contable En el Sector Público, la contabilidad denominada gubernamental requiere de la definición de criterios técnicos específicos concordantes con los fines propios de las instituciones públicas, al tiempo que demanda una práctica armónica e integrada con distintos procesos de administración y producción de información. En ese sentido, debe asegurarse una coherencia relacional y permanente integración de la contabilidad con los aspectos de índole presupuestaria, de caja, de la recaudación, de administración de la deuda pública, de compras, de bienes y, en general, con todo proceso de las instituciones públicas que implique, directa o indirectamente, variaciones o explicación de variaciones en la situación económico-financiera del ente. El rol de la contabilidad gubernamental en este nuevo milenio ha cambiado, ha crecido y, conceptualmente, se ha jerarquizado producto del nuevo enfoque dado a la Administración Financiera donde, entre otros aspectos, la Contabilidad Gubernamental es el sistema integrador de toda la información sobre transacciones y flujos no transaccionales que hacen a la gestión administrativo-financiera del Estado. Por lo expuesto el Módulo Contable, se concibe como: el conjunto de principios, normas, organismos, y procedimientos técnicos utilizados para registrar, valuar, procesar, exponer e informar sobre las transacciones producidas por los ejecutores del gasto e ingreso público y los hechos económicos que afecten o puedan llegar a afectar el patrimonio público. Concordantemente, el TOCAF (artículo 93) establece que el sistema de contabilidad gubernamental comprende el conjunto de principios, órganos, normas y procedimientos técnicos utilizados para recopilar, valuar, procesar y exponer los hechos económicos y financieros que puedan tener efectos en la Hacienda Pública. De esta forma, el Módulo Contable, así concebido, habrá de producir información oportuna, objetiva y confiable para la toma de decisiones y para terceros, por cuyo motivo cobra vital relevancia en la Administración Pública, tanto a los fines de la gestión como de la rendición anual de cuentas. Es en ese sentido, que el procesamiento contable, desarrollado sobre la base de un marco funcional sustentado en normas contables confiables está en condiciones de garantizar la transparencia en la producción de información pública y, por ende, en la gestión de gobierno. Modelo Conceptual del SIIF2 01/04/ /203

99 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 Objetivos El Módulo Contable tiene como objetivo principal Producir, en tiempo y forma los Estados Financieros (EEFF) necesarios para mostrar los resultados de la gestión presupuestaria y económica, así como la situación patrimonial de las organizaciones públicas, a efectos de que la misma permita la toma de decisiones y fundamentalmente producir la Rendición de Cuentas del Gobierno Uruguayo dentro de un marco de absoluta transparencia. A modo de complemento, el objetivo principal del Módulo Contable, cuenta con objetivos específicos tales como: Ser el núcleo integrador del SIIF2, Registrar sistemáticamente todas las transacciones que se produzcan y afecten o puedan afectar el Patrimonio de entidades del Estado Uruguayo, Procesar y producir información financiera para la toma de decisiones por los responsables de la gestión financiera pública y para los terceros interesados en la misma, Presentar la información contable necesaria para facilitar las tareas de control, sean éstas internas o externas, Estar orientado a la obtención de costos de las actividades del Sector Público; Permitir que la información que se procese y produzca sobre el Sector Público Uruguayo se integre al Sistema de Cuentas Nacionales, Llevar la contabilidad centralizada dentro del siguiente ámbito de cobertura: Administración Central (Incisos 02 al 15, 20 al 24 y 30), los Organismos del Articulo 220 de la Constitución (Poder Judicial, Tribunal de Cuentas, Corte Electoral, Tribunal de lo Contencioso Administrativo, ANEP, UDELAR INAU, ASSE, UTEC) y Poder Legislativo, Modelo Conceptual del SIIF2 01/04/ /203

100 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 EEFF 32 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 EEFF 33 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 SIIF 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 Marco Normativo Contable El Módulo Contable debe estar sustentado en un marco normativo contable que otorgue confiabilidad al mismo, por lo cual necesita una serie de manuales funcionales, que se complementan con los requeridos en la Sección 4. Integración del Sistema, (diseño de los clasificadores presupuestarios integrados con el plan de cuentas contable y el desarrollo de la matriz de conversión presupuesto/contabilidad), del presente Informe, que deberán estar diseñados previamente al desarrollo tecnológico, a saber: 32 NICSP N 6: Estados Consolidados y Separados. 33 NICSP N 22: Revelación de Información Financiera sobre el Sector Gobierno General. Modelo Conceptual del SIIF2 01/04/ /203

101 Ilustración 5-2 Marco Normativo Contable La Contabilidad Gubernamental moderna a nivel internacional no sólo requiere un Módulo Contable para su funcionamiento sino también un cuerpo normativo que lo sustente. Las modernas corrientes contables dejan de lado aquellos tradicionales Principios de Contabilidad Generalmente Aceptados para incluirlos en un marco aún mayor, el cual es posible denominar como Marco Conceptual Contable (MCC) constituyendo este marco la guía general para una buena implementación de la Contabilidad Gubernamental. El MCC actúa, entonces, como guía y regulador normativo que posibilita superar la dispersión existente en materia de exposición y contenidos de la información financiera, tanto del Gobierno Central como de los Gobiernos Departamentales, dada la variedad de circunstancias sociales, económico-financieras y jurídicas del país. En tal sentido, se requiere que el Módulo Contable cuente con un Marco Conceptual Contable que se desarrolle sobre la base de la normativa nacional relacionada con la contabilidad, de los contenidos conceptuales de las Normas Internacionales de Contabilidad del Sector Público (NICSP) emitidas por el Consejo de Normas Internacionales de Contabilidad del Sector Público (IPSASB por su sigla en inglés), de la Federación Internacional de Contadores (IFAC por su sigla en inglés) como así también considerar los conceptos definidos por el Consejo de Normas Internacionales de Contabilidad (IASB por su sigla en inglés). El MCC debe definir cuáles serán los EEFF a producir desde el Módulo Contable (salidas del sistema), que como mínimo deberá contemplar los estados señalados en el Requisito indicado a continuación. Modelo Conceptual del SIIF2 01/04/ /203

102 REQ 5-44 Estados Financieros (EEFF) a producir Estados Financieros mínimos a producir por el SIIF2: Estados Principales: o o o o o o o Estado de Situación Financiera (ESF), Estado de Rendimiento Financiero (ERF), Estado de Cambios en el Patrimonio (ECP), Estado de Flujos de Efectivo (EFE), Estado de Ejecución Presupuestaria de Gastos (EEPG), Estado de Ejecución Presupuestaria de Recursos (EEPR), Notas a los Estados Financieros (Notas) Estados Complementarios: o o o o o o o o o o o Compatibilidad Presupuesto / Contabilidad (CP/C) Estado de la Deuda Pública (EDP), Estado de Activos (EA), Cuenta Ahorro / Inversión / Financiamiento (AIF), Estadísticas de las Finanzas Públicas (EFP). Estados Financieros Consolidados (EEFFC): Estados Financieros Consolidados de Sector Público Uruguayo, Estado de Ejecución Presupuestaria de Gastos Consolidados (EEPGC), Estado de Ejecución Presupuestaria de Recursos Consolidados (EEPRC). Estados de Segmento Balancetes Mensuales Desarrollo de manuales de contabilidad A su vez, como parte del desarrollo de un marco normativo contable general, resulta necesario elaborar un conjunto de manuales contables que sirvan como guía para la aplicación de los principios contables definidos. Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General El presente Manual partirá con la definición del MCC y que será la base sobre las que se sustentarán la Políticas Contables Generales y tomando como referencia las normas nacionales y las NICSP relacionadas con contabilidad se deberá desarrollar el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General (MCG y PCG), que tendrá como objetivo ser guía de aplicación en la materia para todo el sector público no financiero y no empresarial, y en especial para el módulo contable. Si bien las normas nacionales y las NICSP serán la referencia para la formulación del presente Manual, también deberá considerarse el Manual de Estadísticas de Finanzas Públicas 2001 del Fondo Monetario Internacional (FMI). En el supuesto caso de no contar con normativa contable que trate un problema específico, se recurrirá a las Normas Internacionales de Contabilidad (NIC) / Normas Internacionales de Información Financiera (NIIF). Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un requisito que debe elaborarse en el marco del desarrollo del SIIF2. El presente Manual, dado que es funcional, debe desarrollarse previamente al desarrollo informático. Modelo Conceptual del SIIF2 01/04/ /203

103 REQ 5-45 Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General El manual deberá desarrollar los siguientes contenidos: a) Modelo Conceptual Contable b) Contener las Políticas Contables Generales, a aplicar en las transacciones gubernamentales, considerando: reconocimiento, medición, exposición. c) Estructurarse siguiendo el ordenamiento de los componentes de los EEFF a saber: Activo, Pasivo, Patrimonio, Gastos, Ingresos, y Presentación de EEFF. d) Definir en detalle las estructuras y contenidos de los EEFF. Manual de Normas Contables Particulares de Contabilidad y Procedimientos Contables Toda organización necesita contar con manuales de los procedimientos a ser aplicados en sus circuitos administrativo-financieros, por cuya razón dichos documentos deben estar sustentados en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General. Los procedimientos deben ser desarrollados tomando en cuenta las mejores prácticas contables - administrativas que permitan la integración del sistema de administraciones financieras consolidadas con las Normas Contables. Contar con manuales de procedimientos es un componente íntimamente vinculado al sistema de control interno. Dichos manuales se elaboran para obtener una información detallada, ordenada, sistemática e integral que contenga todas las instrucciones, responsabilidades e información sobre políticas, funciones, sistemas y procedimientos de las distintas operaciones o actividades que se realizan en una organización. Definir los procedimientos contables implica formar los pilares para poder desarrollar adecuadamente las actividades inherentes a la contabilidad gubernamental, estableciendo las correspondientes responsabilidades para los encargados de todas las áreas y sub-áreas, generando información útil y necesaria, estableciendo medidas de seguridad, control y autocontrol y objetivos que participen en el cumplimiento de la función financiera, partiendo del relevamiento de los procedimientos actuales, los cuales serán el punto de partida y el principal soporte para llevar a cabo los cambios que se requieren para alcanzar y ratificar la eficiencia, efectividad, eficacia y economía en todos los procesos. Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un requisito que debe elaborarse en el marco del desarrollo del SIIF2. El presente Manual debe desarrollarse en forma concomitante al desarrollo informático del SIIF2. Modelo Conceptual del SIIF2 01/04/ /203

104 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ón 34 ; y de transacciones con contraprestación 35. 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) Gestión de Almacenes y Bienes El Módulo Contable contemplará en su desarrollo dos sub-módulos adicionales: (i) almacenes y (ii) Bienes (Activo fijos y Otros). Dada la importancia de los sub-módulos resulta necesario elaborar el Manual de Activos, donde se determinarán funcionalmente los criterios y procedimientos de registro de los bienes a fin de posibilitar su custodia y mantener un adecuado sistema de información y control sobre su utilización y estado de mantenimiento. Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un requisito que debe elaborarse en el marco del desarrollo del SIIF2 REQ 5-47 Manual de activos El Manual de Activos debe cumplir con lo requerido en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General y comprenderá su normas contables particulares así como los procedimientos a cumplir para las: altas de bienes (por adquisición, arrendamiento financiero, construcción, donación o por otro título), bajas de bienes (transferencias, ventas, reasignación, deterioros físicos y legales, 34 NICSP N 23: Ingresos de transacciones sin contraprestación (impuestos y transferencias) : establece: son aquellos que provienen del uso de los poderes soberanos, de subvenciones y de donaciones. 35 NICSP N 9: Ingresos de transacciones con contraprestación : establece que son aquéllos por los que la entidad recibe activos o servicios y le asigna directamente un valor aproximadamente igual al que la otra parte intercambia. Modelo Conceptual del SIIF2 01/04/ /203

105 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 Consolidación de la Información Financiera Es de destacar que la consolidación de la información financiera del país es el último eslabón de una cadena de normas, procesos y procedimientos previos, tanto presupuestarios como contables y, como tal, es el que recibe el impacto positivo o negativo de los eslabones anteriores (normas, procesos, procedimientos), por cuyo motivo debería ser realizado al final del ciclo de administración financiera. El enfoque internacional dado a la consolidación de la información financiera surge de las NICSP como así también de lo establecido en el MEFP/ 2001 del FMI y el enfoque nacional sustentado en el marco legal vigente en el país. Para la normativa internacional, la información consolidada del Sector Público permite cumplimentar el objetivo principal de tener a dicho sector como una sola entidad económica o entidad informante. Por lo expuesto, el hecho de disponer de las normas y procedimientos de consolidación será necesario, fundamentalmente, para los funcionarios de la CGN la cual, como Unidad de Consolidación Principal, cuente con una guía para hacer oportuno, eficaz y eficiente el proceso de consolidación de la información financiera del Sector Público Uruguayo. El proceso de consolidación contable en el Sector Público está orientado, básicamente, a estructurar la información en una forma lógica y razonable, que permitirá su revelación y análisis como una sola unidad (entidad económica), sin perjuicio de la revelación y análisis sectorial e institucional. Este manual puede formar parte del desarrollo del SIIF2 o elaborarse en forma separada. A fin de dar una visión comprehensiva del SIIF2 en este documento se lo incluye como un requisito que debe elaborarse en el marco del desarrollo del SIIF2. El presente Manual debe desarrollarse en forma concomitante al desarrollo informático del SIIF2. REQ 5-48 Manual de Consolidación de la Información Financiera El Manual de consolidación deberá contener, como mínimo, lo siguiente: a) La Estructura de consolidación del Sector Público Uruguayo, sustentada en el Manual de Estadísticas de Finanzas Públicas del FMI y armonizada con lo requerido en el REQ 4-6 Estructura desde las Finanzas Públicas. b) Definir, en función del Marco Conceptual Contable (MCC) y de los requerimientos nacionales los EEFFC, que como mínimo deberá contemplar: Estado de Situación Financiera Consolidado (ESFC), Estado de Rendimiento Financiero Consolidado (ERFC), Estado de Flujos de Efectivo Consolidado (EFEC), Estado de Ejecución del Presupuesto de Ingresos por Origen Consolidado (EEPGC), Estado de Ejecución del Presupuesto de Gastos por Objeto Consolidado (EEPRC), Cuenta Ahorro Inversión Financiamiento Consolidado (AIFC), y Notas a los EEFFC. Modelo Conceptual del SIIF2 01/04/ /203

106 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 Intrasectoriales 36, o Intersectoriales 37. Determinar las etapas del proceso de consolidación, que como mínimo deberá contener: o o o o o Homogeneización, Conciliación entre entidades, Ajustes, Agregaciones, Eliminaciones Matriz de conversión presupuesto contabilidad Los desarrollos de los manuales requeridos en los puntos anteriores impactarán en el funcionamiento de la Matriz de Conversión Presupuesto /Contabilidad (MCP/C), pero es importante definir su funcionamiento en forma previa a su desarrollo informático y funcional, que será la base para el proceso de conversión. La matriz deberá exponer todos los asientos que surgen de las transacciones presupuestarias y no presupuestarias y, con dicha base, se producirán, por agregación de la información previamente almacenada, los diferentes tipos de estados financieros y presupuestarios que se le requieren a la contabilidad gubernamental, el presupuesto, la tesorería y deuda pública. Cabe destacar que la referida matriz constituye en sí misma el nexo conductor que garantiza que las transacciones se registren una sola vez en el sistema y que, por conversión a través de la propia matriz al lenguaje de diferentes clasificadores, pueda explotarse la información desde distintas ópticas. Si bien el porcentaje mayor de transacciones se originan en el presupuesto, la matriz deberá contemplar el ingreso de los datos de aquellas transacciones que tienen impacto contable no presupuestario, por lo cual las unidades ejecutoras deberán poder hacer dichos registros desde el lugar más próximo a la transacción, más allá de las transacción que estén restringidas sólo a la CGN (Unidad Rectora Contabilidad). La matriz deberá contar con un Manual funcional y deberá desarrollarse en forma conjunta con el desarrollo del SIIF2. La matriz debe tener en cuenta el momento del conciliado en el Banco para generar las disponibilidades financieras de la administración de cada Ministerio. REQ 5-49 Manual funcional de la Matriz de Conversión Presupuesto /Contabilidad 36 Real Academia Española: intra: Significa 'dentro de', 'en el interior'. 37 Real Academia Española: inter: Significa. 'entre' o 'en medio'. Modelo Conceptual del SIIF2 01/04/ /203

107 El Manual funcional de la matriz de conversión, se sustentará fundamentalmente en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos Contables y deberá cumplir y contener, como mínimo los siguientes datos y premisas: a) generará los asientos (partida doble) en el Módulo Contable en forma simultánea al registro de la ejecución presupuestaria, en los momentos de devengado, mandado a pagar y pagado para los gastos y, devengado y recaudado para los recursos, b) integrará los clasificadores presupuestarios (recursos y gastos) con el plan de cuentas contable, estableciendo el nivel de integración tanto para los recursos como para los gastos, c) incluirá todas las transacciones posibles que se puedan realizar en el Sector Público Uruguayo, d) permitirá generar la salida requerida para formular los EEFF, el Libro Diario, el Libro Mayor, los Mayores Auxiliares necesarios, que en principio pueden corresponder a cada tipo de operación, como por ejemplo: o o o o o o o Mayor auxiliar por Organismo Mayor auxiliar por Recurso Mayor auxiliar por Objeto del Gasto Mayor auxiliar por Fuente de Financiamiento Mayor auxiliar por Acreedor Deudor - Beneficiario Mayor auxiliar por Cuenta Bancaria, o Mayores auxiliares combinados Principales Ingresos al Módulo de Contabilidad Tal como se ha manifestado en el presente Informe, el Módulo Contable tendrá la función de núcleo integrador del SIIF2, por lo cual cuando las transacciones se devengan impactarán directamente en dicho módulo, a efectos de garantizar que el mismo pueda producir la información económica-financiera del Sector Público Uruguayo. Cumpliendo con las Políticas Contables, el Módulo Contable deberá iniciar sus operaciones con el registro de asientos de apertura de la gestión e ir intercalando actos presupuestarios, financieros y económicos para terminar con la producción de los EEFF. A efectos del presente Marco Conceptual, seguidamente se exponen por separado los ingresos al Módulo Contable, dentro de cada uno de los cuales se desarrollará las características principales del ingreso y las condiciones que deben cumplir. Los mismos se ordenan de la siguiente forma: 1. ingresos de los módulos (principales o secundarios) integrantes del SIIF2, 2. ingresos de los sub-módulos contables, 3. ingresos de información provenientes de otras áreas. Modelo Conceptual del SIIF2 01/04/ /203

108 Ilustración 5-3 Principales Ingresos al Módulo Contable 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 a) Distribución de los créditos aprobados, incluyendo sus ajustes al inicio del ejercicio Momento de Registro 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 Apertura a Es de aclarar que ninguno de los momentos ingresados en estas etapas tienen impacto contable, pero será necesario ingresarlos al módulo por dos razones fundamentales, (i) para que las Unidades Ejecutoras puedan afectar los saldos a medida que los ejecutan, ya que si no cuentan con dichos saldos no podrán ejecutar sus presupuestos y deberán pedir modificaciones al mismo, y (ii) para producir la información presupuestaria requerida al módulo de contabilidad. Más allá de la relación directa de la Unidad Rectora Presupuesto, a lo largo del año, también se relacionan con el Módulo Contable las Unidades Ejecutoras a través de dos formas: Modelo Conceptual del SIIF2 01/04/ /203

109 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 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.). Compromiso, devengado y pago simultáneos: registra la ejecución presupuestaria en las tres etapas al mismo tiempo; debido a que existen operaciones (Ejemplo: comisiones bancarias) de las que se toma conocimiento cuando se recibe la información del débito bancario realizado sin que se cuente con registro previo del compromiso y ni del devengado. b) a través del Módulo Contable : Si bien la CGN es la administradora de la MCP/C y es dicha institución la única facultada para modificarla, el Módulo Contable deberá permitir el ingreso a los registros contables a las Unidades Ejecutoras, limitándola solamente a su unidad, a efectos de poder registrar aquellas operaciones que no tienen impacto presupuestario (por ejemplo: amortizaciones, depreciaciones y revaluaciones de bienes) y para realizar los ajustes que la CGN le puede llegar a solicitar al cierre del ejercicio, a través de la confección de minutas contables. Dicho diseño está sustentado en que son las Unidades Ejecutoras las responsables de sus registros y la CGN no deberá asumir roles de registro que no le corresponden. REQ 5-51 Ingreso del Módulo de Tesorería El Módulo de Tesorería deberá contar con los procedimientos y funcionalidades destinadas a la registración de los ingresos por parte de las Unidades Ejecutoras responsables de su gestión, en especial a través de la DGI y la DNA. En el caso de los ingresos provenientes de Modelo Conceptual del SIIF2 01/04/ /203

110 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 siguiente 38 : Clasificación Tipo de ingreso Momento del Devengado Ingresos Contraprestación con 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 Contraprestación sin Impuestos Cuando se genera el hecho imponible (a) Transferencias (subsidios) Cuando se perciben, por lo cual los momentos de percibido y devengado son simultáneos (b) Donaciones y legados realizadas por terceros a la entidad Con la recepción de la donación o legado Venta de bienes, si la transacción conlleva un precio subvencionado Con la recepción del bien Contribuciones sociales Cuando se perciben, por lo cual percibido y devengado son simultáneos. 38 NICSP N 9: Ingresos de transacciones con contraprestación y NICSP N 23: Ingresos de transacciones sin contraprestación. Modelo Conceptual del SIIF2 01/04/ /203

111 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 o o la entidad gubernamental controla los ingresos como consecuencia de un suceso pasado (el hecho imponible); se espera recibir beneficios económicos futuros o potencial de servicio de esos ingresos; y es probable que la entrada de ingresos pueda ser medida con fiabilidad 39 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 fiablemente 40 (presentación de la liquidación, sucesión aprobada, etc.). C. Si los pasos A y B no son posibles, se podrán utilizar estimaciones sustentadas en juicios profesionales que determinen el momento del devengado, o D. Por último, y luego de haber recorrido previamente los pasos anteriores (A, B y C) y no se cuente con estimaciones confiables y, por ende, no se llegue a determinar un momento fiable, se tomará el momento del percibido en el que prevalezca por fiabilidad del registro. b) Transferencias (subsidios): En este caso se debe aplicar un criterio de prudencia en el ingreso y reconocerlo cuando el activo es ingresado efectivamente a la entidad, por más que se cuente con disposiciones administrativas que lo autoricen, dado que puede ocurrir que se cuente con la documentación legal y no con los fondos para realizarla, o sea desde el punto de vista del ingreso será con la percepción del mismo. El módulo de recursos ingresará al Módulo Contable la siguiente información: a) si el ingreso es por lo percibido: imputación de ingresos: Es el proceso mediante el cual los ingresos percibidos se imputan a los distintos conceptos de recursos, actualizando la cuenta corriente del contribuyente, los saldos de cuentas por cobrar impositiva que tengan las entidades recaudadoras, 39 Por ejemplo, el hecho imponible en el impuesto sucesorio es en el momento de la muerte del contribuyente, pero en dicho momento no se puede medir fiablemente. 40 Siguiendo con el ejemplo anterior, recién se podrá medir fiablemente en el momento que el juez dicte la sucesión. Modelo Conceptual del SIIF2 01/04/ /203

112 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 cobrar 41 (incobrabilidad); y los diferentes estados en que se encuentren las cuentas por cobrar (morosos, en gestión judicial, si son a corto, o largo plazo, etc.). b) si el registro se hace por lo devengado se generará dicha cuenta en forma automática en el módulo de contabilidad, que se ajustará por los ingresos reales al mismo. En ambos casos el Módulo Contable deberá cumplimentar lo requerido en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos Contables, es decir ajustar el saldo de cuentas por cobrar DGI por los correspondientes deterioros (posibles incobrabilidades). La percepción de los recursos se produce cuando los fondos ingresan a la Cuenta Única que administra la Tesorería, en cuyo momento el Módulo Contable captará el percibido del recurso, que si se mantiene el registro por lo percibido será el momento de ingreso y registrará la ejecución del presupuesto de ingresos en la etapa del percibido, generando en forma simultánea el asiento de partida doble que corresponda. Si se hace sobre base devengada el recurso ya ingresó al módulo y debió generar una cuenta por cobrar que se verá disminuida por el ingreso percibido. La Unidad Rectora de Tesorería deberá conciliar los medios de pago (liberados con los operadores en banco) con la imputación de acuerdo al catálogo de ingresos por concepto de los fondos percibidos, para generar las partidas conciliatorias de egresos pendientes del saldo del banco. Según lo definido en el presente documento, las unidades que realizan los registros deben estar lo más próximas posibles al evento que genera la transacción, resultando aconsejable que el registro lo realicen directamente la Unidad Ejecutoras, en especial en la DGI y DNA. En el caso de los ingresos provenientes de Dirección Nacional de Loterías y Quinielas y Dirección General de Casinos correspondería incorporarlos directamente al módulo contable, quedando el registro a cargo de las Unidades Ejecutoras de Lotería y Casino, como asimismo el tratamiento de los recursos propios de los distintos organismos que conforman el Gobierno Central. En el caso que este proceso requiera un proceso gradual de implementación, el módulo de contabilidad del SIIF2 deberá poder capturar los datos necesarios para la registración contable de los ingresos mediante mecanismos de 41 NICSP N 29: Instrumentos Financieros Reconocimiento y Medición. Modelo Conceptual del SIIF2 01/04/ /203

113 interoperación adecuados desde los sistemas de origen las entidades recaudadoras o bien permitir el registro en forma directa sobre el módulo de contabilidad del SIIF2. REQ 5-52 Ingreso del Módulo de Deuda Pública La experiencia de varios países muestra que existen tres enfoques alternativos para el desarrollo del Módulo de Deuda Pública: Integrar todas las operaciones directamente en el Módulo Contable. En este caso el desarrollo del Módulo de Deuda Pública opera como un sub-módulo del Módulo Contable. Realizar un desarrollo informático propio para la administración de la deuda pública el cual se integra con el resto del Sistema de Administración Financiera mediante interoperabilidad. Implementar el Sistema de Gestión y Administración de la Deuda (SIGADE) desarrollado por la Conferencia de las Naciones Unidas sobre Comercio y Desarrollo (UNCTAD) y desarrollar las interfases específicas para su integración al resto del Sistema de Administración Financiera. En el caso del Uruguay el administrador de la deuda pública es el Banco Central de Uruguay y por ende es dicha entidad la que cuenta con el correspondiente sistema de administración, por lo cual se recomienda que dicho sistema sea quien deberá proveer al Módulo Contable, por medio de mecanismos de interoperabilidad entre sistemas información para el registro contable de la deuda pública y la registración de ingresos por préstamos, la cual se detalla en 5.5 Módulo de Deuda. REQ 5-53 Ingreso del Módulo de Tesorería La interrelación entre el Módulo de Tesorería y el Módulo Contable se produce, fundamentalmente, en el momento de la recaudación de los ingresos y de los pagos de las obligaciones, es decir cuando se produce un flujo real de fondos, más una serie de operaciones que hacen al rol de la Tesorería. Dichos procesos serán como mínimo los siguientes: Registro de los recursos El registro de los recursos se produce con la conciliación bancaria o recaudación de los mismos. Es diferente la percepción desde el punto de vista presupuestal que se produce en la etapa del percibido, cuando el contribuyente cancela su obligación. Se pueden establecer operativamente dos etapas: cuando se recaudan efectivamente (el contribuyente canceló su obligación depositando los fondos respectivos en alguno de los agentes financieros autorizados); y cuando se produce la percepción definitiva, con el ingreso de los fondos en la Cuenta Única que administra la Tesorería. Con la conciliación bancaria se realiza el registro contable de los ingresos a la Tesorería. De acuerdo al TOCAF art.12, se registra el percibido en la caja recaudadora, aunque esté pendiente de depósito en el banco; cuando llega el dinero al banco, se hace el descargo de la caja recaudadora por los recursos acreditados. Posteriormente, en caso de corresponder, se regularizaran los débitos/créditos que haya realizado el agente financiero por gastos, comisiones, a través de la conciliación bancaria. Se consideran recursos percibidos a la Modelo Conceptual del SIIF2 01/04/ /203

114 recepción de efectivo en Caja, depósitos de fondos en Bancos o cobros mediante títulos o valores legalmente determinados. En el momento de la percepción en la Tesorería, se registrará, en el Módulo Contable la ejecución del presupuesto de recursos en la etapa del percibido y generará en forma simultánea el asiento de partida doble que corresponda. Constitución de Garantías El Módulo de Tesorería recibe por sí o a través de sus auxiliares las garantías y debe registrar a tales efectos los siguientes momentos contables: si es recibida en documentos será un registro en el auxiliar de Valores en Garantía para informar al cierre del ejercicio al Módulo Contable ; si es recibida en efectivo (o vía retención) la Tesorería registrará contablemente el ingreso del dinero contra una cuenta por pagar a Fondos de Terceros en Garantía. Registro de los pagos El registro de los pagos representa la liquidación de obligaciones exigibles, y se realizará mediante la entrega de efectivo, emisión de cheques, órdenes bancarias, transferencias a cuentas bancarias o pagos por notas (pago de la deuda pública). El registro de esta etapa permitirá conocer el grado de cumplimiento de compromisos contraídos como obligaciones, saldos disponibles en bancos, cheques u órdenes bancarias emitidas, entregadas y pagadas. La Tesorería, como Unidad Rectora Tesorería, será la responsable del registro en el SIIF2 en el momento de la generación del medio de pago y el módulo verificará la existencia de disponibilidad en el libro Caja o en el libro Banco; afectando la etapa del pagado, registrará el débito en el libro Caja o Banco; y generará automáticamente el asiento de partida doble para la imputación indicada en la Orden de Pago respectiva. Los pagos son, en general, gestionados y realizados por la Tesorería a través de procedimientos de priorización y confirmación de las operaciones destinadas a cancelar con la emisión del medio de pago correspondiente. Seguidamente se identifica, como mínimo los tipos de pagos que se deberá contemplar dentro del SIIF2 y cómo afectan los mismos al Módulo Contable: Pagos presupuestarios en general: El ordenamiento del pago o ejercicio del presupuesto es realizado por las Unidades Ejecutoras de las dependencias y entidades con el mandado a pagar de la emisión de la Orden de Pago (OP) e intervenida, que se emite por el ejercicio de las asignaciones presupuestarias vigentes. Estos documentos son remitidos a la Tesorería para su cancelación y es ésta quien registra el momento de pagado con la emisión del medio de pago (cheque o transferencia bancaria) y es entonces cuando dicho registro impacta automáticamente en el pagado de los registros presupuestarios y disminuye el pasivo en la contabilidad. Toda OP mandada a pagar por las entidades y no pagada por la Tesorería, queda como una deuda pendiente de pago. Pago de Sueldos: Modelo Conceptual del SIIF2 01/04/ /203

115 Las cuentas por pagar producto de las liquidaciones realizadas por las Unidades Ejecutoras, deberán ser realizadas directamente a los empleados por la Tesorería General de la Nación a través de la Cuenta Única mediante transferencias bancarias. Estas cuentas quedarán pagadas con dicha transferencia, a cuyo efecto la TGN deberá recibir junto con las liquidaciones las nóminas de empleados conformadas por la Unidad Ejecutora. Los pagos deben realizarse por transferencia bancaria, directamente a la cuenta del empleado y sólo para casos excepcionales se podrán realizar pagos a través de la emisión de cheques automáticos. Pagos del Servicio de la Deuda, Intereses y Comisiones del servicio de la deuda: Los pagos de la amortización de la Deuda Pública, los intereses y comisiones del servicio de la misma, que tendrán como beneficiario a los prestamistas de créditos o los agentes financieros que atiendan dicho servicio de los valores y títulos, lo realiza en su etapa final el Banco Central de Uruguay de acuerdo al cronograma previsto y en función de la delegación del MEF como agente financiero de la administración del crédito público. Pagos de Fondos Rotatorios: Los Fondos Rotatorios constituyen un anticipo de fondos con reposición periódica de la Tesorería, que se autoriza expresamente a cada una de las dependencias para que cubran compromisos de carácter urgente, derivados del ejercicio de sus funciones, programas y presupuestos autorizados. Los Fondos Rotatorios regularmente se pagan con la emisión de cheques a favor de las Unidades Ejecutoras. Con la emisión del medio de pago la Tesorería registra un movimiento contable en el SIIF2 de anticipos de fondos, quedando una deuda registrada en cabeza de la Unidad Ejecutora hasta tanto la misma lo rinda afectando las partidas presupuestarias autorizadas para realizar dichos gastos. Con la rendición del Fondo Rotatorio se practica el registro final de la ejecución del presupuesto y el pago. Otros pagos no presupuestarios: Existen otras causales que originan pagos no presupuestarios tales como el otorgamiento de anticipos o pagos a cuenta dicho tipo de transacciones se tratarán igual que los Fondos Rotatorios, quedando registrado en el SIIF2 una deuda hasta tanto se complete la operación y se pueda afectar las partidas presupuestarias correspondientes. Dentro de estas operatoria podemos encontrar: Devolución de Garantías: Cuando se termina la obra/proyecto o en los casos que se proceda a sustituirla por un nuevo documento la Tesorería procederá a la devolución de las Garantías de acuerdo a: si la devolución es de un documento de debe dar de baja en el auxiliar de Valores en Garantía y ajustará el informe al cierre del ejercicio en el Módulo de Contabilidad. si la garantía fue en efectivo debe registrarse contablemente la salida de fondos (pago) dando de baja la deuda contraída en su ingreso en Fondos de Terceros en Garantía. Conciliación Bancaria de los pagos Modelo Conceptual del SIIF2 01/04/ /203

116 La conciliación bancaria de los pagos consiste en la comparación entre los movimientos financieros incluidos por el Banco y los estados de las cuentas bancarias oficiales y los movimientos financieros generados por la Tesorería en los Libros Bancos de las respectivas cuentas. El proceso de Conciliación Bancaria es responsabilidad de la Tesorería; dicho organismo, a través del Módulo de Tesorería, deberá contar con un sub-módulo de conciliación a efectos de que permita comparar los movimientos de créditos y débitos de cada cuenta informados en los extractos bancarios con los registros de ingresos y egresos del libro banco con el objetivo de establecer en forma diaria el saldo disponible de la Tesorería por cada cuenta e identificar el detalle de movimientos registrados en las mismas que aún no han llegado al Banco o se encuentran en tránsito (depósitos, cheques, transferencias, etc.) y los movimientos efectuados por el banco que no cuentan con registro en la TGN (débitos, gastos, comisiones bancarias, etc.). Estas diferencias dispararán automáticamente los correspondientes asientos de ajuste a los saldos. Valores en custodia La Tesorería tiene la custodia de los derechos patrimoniales de los valores que representan las inversiones financieras del Gobierno Uruguayo. La custodia comprende la guarda, conservación y registro clasificado de los valores y la percepción de los dividendos, utilidades o remanentes. Si bien la custodia de valores no tiene impacto en el registro contable, en cambio sí lo tienen sus movimientos, por lo cual la Tesorería llevará el registro auxiliar de estos derechos, de acuerdo a su naturaleza, e informará al Módulo Contable al cierre del ejercicio las existencia de los mismos, como así también su cotización, a efectos de que la CGN registre a dicho cierre el valor actual de las inversiones. Las operaciones que la Tesorería ingresará al SIIF2 serán: Compra de las inversiones financieras, realizadas por la Tesorería; Cualquier ingreso que las mismas produzcan (dividendos); Inversiones Financieras liquidadas que podrán generar una pérdida o una ganancia, según resulte de la liquidación. El desarrollo de este requisito debe realizarse en forma combinada con los Requisitos definidos en 5.4 Módulo Tesorería. REQ 5-54 Ingreso del Módulo de Recursos Humanos El gasto en personal es el gasto más significativo del presupuesto y el Módulo de Recursos Humanos debe ingresar al Módulo Contable las siguientes operaciones: Compromiso anual: al inicio del ejercicio se realiza una liquidación anual que es la base para el registro de la etapa del compromiso para los gastos de servicios personales. Esta liquidación se realizará sobre el personal ocupado al inicio del ejercicio y sobre la base de su condición ocupacional. Actualización del compromiso: por novedades en la administración de personal ya sea producto de: (i) el ingreso, (ii) egresos y (iii) control de licencias, franquicias, permisos, asistencia, horas extras, etc., entre otras, y podrán modificar el compromiso anual cuando de ellas se deriven nuevas obligaciones de pago por los Modelo Conceptual del SIIF2 01/04/ /203

117 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-empleo 42 : Puede existir alguna entidad o Unidad Ejecutora, que según la normativa del país, esté comprometida a pagar beneficios a los empleados después que termina la relación laboral, como ser: Pago de regímenes de jubilaciones especiales aplicados sólo al personal de la institución (por ejemplo Fuerzas Armadas); Compromiso de pagos de una cantidad determinada de sueldos al término de la relación laboral; Compromisos de pago de asistencia médica hasta su fallecimiento; Otros compromisos de pago futuro. Dichas entidades deberán ingresar al Módulo Contable la deuda actuarial a valor presente que generará esas obligaciones, en la medida que la entidad mantenga los riesgos de hacerse cargo de los pagos futuros, como así también identificará los activos con los que atenderá dicha deuda futura. También deberá informar a la CGN por Nota las características y normativa legal de dichos planes pos-empleo. REQ 5-55 Ingreso del Sistema Nacional de Inversión Pública (SNIP) El Sistema Nacional de Inversión Pública (SNIP) deberá interoperar con el Módulo Contable del SIIF2 en los siguientes puntos relacionados al proceso de programas y proyectos de inversión: El SNIP enviará los Proyectos y Programas de Inversión que se incluirán en el Proyecto de Presupuesto; En el marco del proceso de planificación estratégica, se presentaran al SNIP los proyectos de inversión. Posteriormente, se procederá a priorizar los proyectos que cuenten con 42 NICSP N 25: Beneficios a los Empleados. Modelo Conceptual del SIIF2 01/04/ /203

118 conformidad técnica incluyendo en primer lugar los proyectos en ejecución y en segundo lugar los proyectos nuevos. Deberán incluirse: los proyectos en ejecución por los montos a ejecutarse en el período; y los proyectos a iniciarse en el período fiscal cuyo presupuesto se está formulando. Este proceso se realiza en el SNIP tanto en instancia presupuestal como en rendición de cuentas (en caso de haber modificaciones presupuestales), y se envía la información al SIIF2 de cada proyecto con su cronograma de inversión correspondiente a nivel de partida presupuestal por componente. Presupuesto Aprobado Con posterioridad a la aprobación del presupuesto, y de rendición de cuentas (en caso de haber modificaciones presupuestales), el SIIF2 enviará la información correspondiente al SNIP de los montos definitivos aprobados para cada proyecto al nivel de detalle al que fueron enviados originalmente. Ejecución Financiera de los Proyectos El SIIF2 deberá soportar y requerir en cada una de las etapas del proceso del gasto (desde la afectación inclusive), la vinculación con la estructura SNIP de los Proyectos de Inversión a nivel de Componentes. La ejecución financiera de los proyectos de inversión a nivel del Componente se enviará periódicamente al SNIP. Medición de la ejecución física de los Proyectos En base a los criterios definidos por el SNIP en cuanto a medición física de los Proyectos a través de sus Componentes, se enviará al SIIF2 la información correspondiente a la estructura utilizada para su medición. Ajuste de costos y modificaciones de Programas y proyectos de inversión El ajuste de costos que se practique durante la ejecución de la obra se iniciara en el SNIP, excluyendo los procesos de ajustes generales realizados en forma directa en el SIIF2, y será la base para la actualización del registro del compromiso por los montos a certificar durante el ejercicio vigente y los registros auxiliares donde se registran obligaciones futuras en el SIIF2. En caso que se resuelvan modificaciones a los proyectos que impliquen mayores costos, el ingreso de éstos, una vez autorizados, modificará el presupuesto adjudicado de la obra/proyecto y el compromiso respectivo por lo que corresponda ejecutar en el ejercicio vigente y los registros auxiliares donde se registran obligaciones futuras tanto en el SIIF2 como en el SNIP. En resumen, toda modificación de asignación presupuestal para un proyecto de inversión debe iniciar su gestión en el SNIP, excepto las de carácter general realizadas en forma directa en el SIIF2. Posteriormente la información se envía al SIIF2 para Modelo Conceptual del SIIF2 01/04/ /203

119 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 submódulo de Bienes, como así también la constitución de la correspondiente deuda hasta que sea pagada. Modelo Conceptual del SIIF2 01/04/ /203

120 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 venta 43 o al consumo por parte de la entidad, identificando sus ingresos y salidas del inventario, así como la responsabilidad de los agentes y funcionarios que autoricen, dirijan o ejecuten las acciones de gestión y de disposición, en cuanto a su legitimidad, mérito o conveniencia. REQ 5-57 Sub módulo de Almacenes Organización y Competencia: El presente sub-módulo será utilizado en forma descentralizada por cada una de las Unidades Ejecutoras, que serán las responsables de su administración y de la información que el mismo proporcione. Normativa: El presente sub-módulo estará formulado de acuerdo a las normas dadas en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos Contables. Bienes Comprendidos 44 : Los bienes contemplados en el sub-módulo son: Bienes de Cambio: son los bienes destinados a la venta o entrega a terceros, ya sea en el mismo estado en que fueron adquiridos o después de haber producido en el mismo un proceso de cambio (productos en proceso, productos terminados), sin entrar a considerar en este proceso si se recibe por la entrega del bien contraprestación igual, mayor o menor a la del bien entregado. Bienes de Consumo: sonlosmateriales y suministros destinados a ser consumidos o distribuidos en la prestación de servicios de las entidades gubernamentales, incluyendo los asignados para la conservación y reparación de bienes de capital, como así también los bienes adquiridos para su transformación y/o enajenación por parte de las entidades que desarrollen actividades de carácter comercial, industrial y/o servicios o entidades que vendan o distribuyan elementos adquiridos con fines promocionales. Características de los bienes: Dichos bienes deben cumplir con las siguientes características: destinados al consumo final, intermedio, propio o de terceros, y su tiempo de utilización debe ser dentro del ejercicio o dentro del proceso de la obra/proyecto. 43 Venta: concepto utilizado en un sentido amplio, desde la entrega de un bien hasta la prestación del servicio, más allá de que se reciba una contraprestación por la entrega de la cosa. 44 NICSP N 12: Inventarios. Modelo Conceptual del SIIF2 01/04/ /203

121 Codificación: Es fundamental que el sub-módulo cuente con la codificación de bienes que permita representar todo el universo de bienes y servicios, con la flexibilidad suficiente para que las definiciones sean claras y precisas. Además, dicha codificación deberá poseer una serie de datos asociados, de manera tal que pueda ser utilizada por todas aquellas áreas involucradas en la administración de los bienes y servicios (presupuesto, compras y contabilidad). Dicha codificación debe ser la misma que usa el Módulo de Contratación de Bienes y Servicios. Principales Procesos: Los procesos en el sub-módulo son contables comprendiendo los siguientes: Ingreso a Almacenes de los bienes: El alta de los bienes en almacenes se produce con el ingreso de las compras o donaciones recibidos (momento de devengado), mientras que el documento de ingreso será el remito de recepción o la conformidad de la comisión de recepción (si existiera). Si el bien recibido está integrado con contrataciones, el mismo ya se encuentra imputado al código correspondiente a la compra del producto desde el inicio de la contratación. De no coincidir el código con el bien recibido se deberá hacer el ajuste correspondiente en la codificación contable (Plan de Cuentas Contable). Costeo de los bienes: Los bienes ingresados a almacenes se ejecutarán con el ingreso del bien y se devengarán generando la ejecución del presupuesto y el registro contable en forma simultánea, de tal forma que la MCP/C deberá contemplar que si bien ambos nacen en el momento del devengado, para la ejecución del presupuesto es un gasto y para la ejecución contable es un activo y se mantendrá en el mismo hasta que se venda o se consuma, momento en que se afectará a resultados. En esta etapa también se deberá verificar que en la factura estén todos los costos que se establezcan en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos Contables, ya que de no ser así deberá hacerse el ajuste contable correspondiente para incluir todos los costos requeridos en las Normas Contables. El Manual de Activos establecerá el método de costeo a utilizar que podrá ser general o específico para aquellos bienes de características especiales. Salidas de los bienes, Cuando los bienes salen de almacenes ya sea: (i) por venta, (ii) para consumo o (iii) por deterioro, se deberá dar de baja los bienes afectando contablemente el resultado del ejercicio en el que se realiza la salida. Toma de inventario. El sub-módulo de almacenes deberá contemplar la toma de inventario al cierre del ejercicio sustentada en las normas enmarcadas en el Manual de Normas Particulares de Contabilidad y Procedimientos Contables, sin perjuicio de garantizar en forma permanente el conocimiento de las existencias. Principales Salidas: Las salidas del sub-módulo de almacenes deberá contemplar como mínimo lo siguiente: Modelo Conceptual del SIIF2 01/04/ /203

122 Saldos al inicio de los bienes de Bienes de Consumo y Bienes de Cambio; Altas / Bajas del ejercicio, Saldos en cualquier momento del ejercicio. Saldos al cierre del ejercicio de Bienes de Consumo y Bienes de Cambio, y Costo de los bienes en existencia y de las salidas, Información para gestión de almacenes en áreas críticas, como por ejemplo la hospitalaria. Sub-módulo de Bienes El sub-módulo de Bienes tendrá por objetivo lograr la mayor economía, eficacia y eficiencia en todas y cada una de las etapas del proceso de registro de los bienes destinados al uso o a la inversión por parte de la entidad, identificando: el ingresos (alta); las modificaciones; las bajas del inventario; los funcionarios responsables de su uso, y la toma de inventario al cierre o en cualquier otro momento del ejercicio REQ 5-58 Sub módulo de Bienes Organización y Competencia: El presente sub-módulo será utilizado en forma descentralizada por cada una de las Unidades Ejecutoras, que serán las responsables de su administración y de la información que él mismo proporcione. Normativa: El presente sub-módulo estará formulado de acuerdo a las normas dadas en el Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General y en el Manual de Normas Particulares de Contabilidad y Procedimientos Contables. Bienes Comprendidos: Los bienes contemplados en el sub-módulo serán: Activo fijo: Comprende el valor de los bienes de propiedad del ente público adquiridos a cualquier título (compra, donación y arrendamiento financiero) o construidos con el propósito de ser utilizados en la producción de bienes, prestación de servicios o en el desarrollo de la función administrativa del cometido estatal. Dentro del activo fijo se incluyen los siguientes bienes: 1. Bienes de Uso explotados 45 : comprende las propiedades, planta y equipos de propiedad del ente público, adquiridos por compra, por donación, por arrendamiento financiero o construido con el propósito de ser utilizados por las entidades gubernamentales. Dentro de dichos bienes son susceptibles de identificación, entre otros, los siguientes: Tierras y terrenos; Edificios; Maquinaria y equipos para la producción; 45 NICSP N 17: Propiedades, planta y equipo. Modelo Conceptual del SIIF2 01/04/ /203

123 Equipos y mobiliario de oficina; Activos cultivados. 2. Bienes de Uso concesionados 46 : 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ón 47 : 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 infraestructura 48 : Comprende los bienes que cumplen la característica de ser parte de un sistema en red, que pueden ser adquiridos a cualquier título (compra, donación y arrendamiento financiero) o construidos por el ente público, como ser: caminos, carreteras, autopistas, diques, puentes, túneles, aeródromos, canales de riego, desagües o navegación, sistemas de señales fijas o flotantes, redes de comunicaciones, de distribución de energía, de agua, centrales generadoras de electricidad, oleoductos, plazas y parques, recreos, etc., cuya administración la ejerce el ente público para el uso y goce de la comunidad en general. 5. Bienes de infraestructura concesionados: Comprende los bienes descriptos en el punto (4) que se encuentran en uso o explotación por parte de terceros en el marco de concesiones de actividades, servicios o cometidos propios del ente; 6. Bienes históricos y culturales: Comprende aquellos bienes que han sido declarados históricos, culturales o del patrimonio nacional, tales como inmuebles históricos, museos, monumentos y obras de arte, construidos por el ente público en predios de su propiedad o adquiridos a cualquier título (compra, donación y arrendamiento financiero), cuyo dominio y administración la ejerce el ente público para el uso y goce de la comunidad en general; 7. Recursos naturales: Comprende las reservas naturales en minas, canteras, yacimientos, bosques y otro tipo de recursos de similar índole, que se encuentren en uso o en condiciones de explotación, y 8. Obras/proyectos en Construcciones: Comprende la construcción o ampliación de inmuebles, hasta el momento en que dichos bienes se encuentren en condiciones de ser utilizados por el ente público para el destino o afectación que corresponda al cometido estatal. Se incluyen toda clase de obras/proyectos que permanecen con carácter de adherencia al suelo formando parte de un modo indivisible, como así también las ampliaciones y mejoras de construcciones ya existentes. Se consideran como tales las edificaciones y locales para oficinas públicas, edificaciones para salud, edificaciones para fines de seguridad, edificaciones educativas y 46 NICSP N 32: Concesión de Servicios Públicos. 47 NICSP N 16: Propiedades de Inversión. 48 NICSP N 17: Propiedades, planta y equipo. Modelo Conceptual del SIIF2 01/04/ /203

124 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ógicos 49 : 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 Intangibles 50 : 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 o sea es probable que la entidad reciba beneficios económicos o potenciales servicios asociados al activo; y el valor razonable o el costo del activo puedan ser medidos de forma fiable. Valuación de los bienes: La valuación de los bienes deberá cumplir con los criterios que se establezcan en los: REQ 5-45 Manual de Contabilidad Gubernamental y Políticas Contables Generales para todo el Sector Gobierno General, REQ 5-46 Manual de Normas Particulares de Contabilidad y Procedimientos Contables y.req 5-47 Manual de activos. 49 NICSP N 27: Agricultura. 50 NICSP N 31: Activos Intangibles. Modelo Conceptual del SIIF2 01/04/ /203

125 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 deterioros 51, 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 o o 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. 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. 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. Mejoras: comprende el valor de las inversiones realizadas con el propósito de mejorar o ampliar el potencial de los bienes del activo fijo adquiridos a cualquier título, los cuales están destinados al desarrollo de la función administrativa o cometido estatal, y que como consecuencia de dichas 51 NICSP N 21: Deterioro del valor de activos no generadores de efectivo y NICSP N 26 Deterioro del valor de activos generadores de efectivo. Modelo Conceptual del SIIF2 01/04/ /203

126 o o inversiones se produzca un incremento del valor de dichos bienes o de su vida útil estimada. 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. 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 o o Inversiones, (Altas) Disposiciones (Bajas) Revalúo (incremento y disminuciones) Modelo Conceptual del SIIF2 01/04/ /203

127 o o Pérdida por deterioro 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 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 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 ), por el cual los sujetos obligados deberán prever la adecuada organización, sistematización y disponibilidad de la información en su poder, asegurando un amplio y fácil acceso a los interesados. Por lo tanto, el SIIF2 deberá desarrollar los mecanismos y reportes necesarios para el proceso de Rendición de Cuentas de acuerdo a la normativa vigente en la materia. Modelo Conceptual del SIIF2 01/04/ /203

128 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 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 Dinero legal y depósitos No Financieros Productivos No productivos Fijos Pasivos Préstamos Valores de distintas acciones Acciones y otras participaciones de capital Reservas Técnicas de Seguros Otras cuentas por pagar Existencias Objetos valiosos Otras cuentas por cobrar Reservas técnicas de seguros Modelo Conceptual del SIIF2 01/04/ /203

129 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 Esquema general de Integración del Módulo Contable con los Módulos principales y secundarios del SIIF 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 Distribución de los recursos estimados Apertura del SIIF2 al inicio del quinquenio y al inicio del cada año. Presupuesto Aprobado Programación de los compromisos anuales aprobados Cuotas Compromiso de 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 Compromiso Modificadas. de Presupuesto desde Unidades Ejecutoras las Gastos en Personal anual Modificaciones al gasto en personal anual Valoración anual de la planta ocupada al inicio del ejercicio Valorización de las altas desde la fecha de alta al cierre del ejercicio, y Comprometido Compromiso modificado Valorización de las bajas hasta la fecha del cierre del Modelo Conceptual del SIIF2 01/04/ /203

130 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Principales ejercicio Prestación del servicio Conformidad de la prestación del servicio prestado Devengado Envío de las liquidaciones de sueldos aprobadas Emisión de la orden de pago autorizada Mandado a pagar Formalización del Pago La Tesorería realiza las Transferencia bancaria directamente al beneficiario final (funcionario) Pagado Prestación de servicios personales Conformidad de la prestación del servicio prestado Devengado Orden de paga aprobada Mandado a pagar La Tesorería realiza las Transferencia bancaria directamente al beneficiario final Pagado Prestación de servicios no personales Conformidad de la prestación del servicio prestado Devengado Orden de Pago aprobada Mandado a pagar La Tesorería realiza las Transferencia bancaria directamente al beneficiario final Pagado Servicios Básicos normales y habituales Entrada de la factura Compromiso Devengado y Orden de Pago aprobada Mandado a pagar La Tesorería realiza Pagado Modelo Conceptual del SIIF2 01/04/ /203

131 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Principales las Transferencia bancaria directamente al beneficiario final Adquisiciones de Bienes Ingreso del Bien conformado Orden de Pago aprobada La Tesorería realiza las Transferencia bancaria directamente al beneficiario final Devengado Mandado a pagar Pagado Transferencias subsidios por Resolución aprueba transferencia que la Compromiso Con la emisión de la Orden de pago aprobada La Tesorería realiza las Transferencia bancaria directamente al beneficiario final Devengado Mandado a Pago Pagado y Recaudaciones Recursos devengado de Impuestos Generación hecho imponible del Devengado Recursos liquidado Ingresos cobrados Recursos distintos a impuestos Créditos a favor de la Estado Presentación de la liquidación de los impuestos Ingreso de montos por impuestos ingresados a las cuentas recaudadoras Cuando se genera el hecho imponible Por los créditos de los impuestos Percibido Devengado Devengado Modelo Conceptual del SIIF2 01/04/ /203

132 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Principales impagos no registrado por lo devengado Devolución de impuestos de ejercicios anteriores Conciliación de Saldos Tesorería Ingresos percibidos de impuestos Otros ingresos percibidos Montos pagados que tengan o no impacto presupuestarios Cancelación de Servicios Personales y no Personales Cancelación por compra de bienes Cheque entregado o transferencia bancaria ordenada Extractos bancarios con la información detallada por impuesto registrada en el módulo Monto ingresado a la Cuenta Única Banco o Caja Por la emisión del medio de pago (Cheque) o transferencia bancaria Pagado Comprometido / devengado y pagado Percibido Pagado Cancelación Transferencias (Subsidios) de Fondos autorizados Rotatorios Anticipo de fondo Pagado Rendición de los fondos rotatorios liquidación de los fondos rotatorios Devengado Desembolso Préstamos de Monto ingresado a la Cuenta única Banco o Caja Percibido Servicio de la Deuda Orden de pago por nota de los intereses y/o amortización de la deuda Mandado a Pagar Modelo Conceptual del SIIF2 01/04/ /203

133 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Principales Avales caídos (cancelación de avales) Orden de pago por nota de los intereses y/o amortización de la deuda Mandado a Pagar Liquidación de los sueldos Transferencias bancarias directa a los empleados 52 Pagado Retenciones Cancelación de las retenciones Pagado Conciliaciones Bancarias Extractos bancarios Comprometido / Devengado / Pagado Deuda Pública Acuerdos de Préstamos Avales acordados Firma del acuerdo de desembolso Compromiso 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 Préstamos de Ingresos de Préstamos a otras cuentas Bancarias distintas de la Cuenta Única. Percibido Cronogramas de Intereses Cronogramas de la Presupuesto aprobado Compromiso 52 En el caso de que los pagos los realice la entidad y no la Tesorería sería un Mandado a Pagar para la tesorería y Pagado cuando las instituciones hacen la transferencia a los empleados. Modelo Conceptual del SIIF2 01/04/ /203

134 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Principales Amortización de la Deuda Intereses devengados al cierre Adquisición de Instrumentos Financieras (activos, pasivos o patrimonio) Por el transcurso del tiempo dentro del ejercicio Por el acuerdo firmado por la adquisición o por el momento donde se genera el derecho o la obligación Devengado Devengado Proceso de conciliación Por los pagos realizados por el Banco Central y las Notas emitidas por la Tesorería Pagado Integración con los módulos secundarios Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Secundarios Recursos Humanos Aprobación del presupuesto aprobado por año Distribución créditos de Aprobado Programación de los compromisos anuales aprobados Cuotas Compromiso de Cuotas de Compromiso aprobadas para el año. Modificación a la programación de compromisos Modificación de la cuota Cuota compromiso modificada de Prestación servicios de Liquidación mensual de Salarios Devengado Liquidación de Salarios aprobado Mandado a pagar Contrataciones de Diseño de Catálogos Catálogo de Bienes Modelo Conceptual del SIIF2 01/04/ /203

135 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Bienes y Servicios SICE Integración con los Módulos Secundarios 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 contrataos de Acuerdo firmado Compromiso Ingreso de bienes de consumo Ingreso de Activo Fijo Con la recepción del bien Con la posesión del activo y control sobre el mismo Devengado Devengado Contratación Servicios de Con la firma del contrato Compromiso Prestación Servicio del 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 inventario de Autorización de ajustes de los costos Devengado Baja de bienes por venta o por consumo Entrega o venta de bienes Devengado Transferencia bienes de Normativa autoriza transferencia que la 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 arrendados fijos Con el contrato de arrendamiento Comprometido Modelo Conceptual del SIIF2 01/04/ /203

136 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Secundarios financieramente financiero Ingreso del activo al inventario Activos fijos donados Ingreso del activo fijo donado Análisis de deterioros Informe de deterioros Devengado Devengado Devengado Cálculos Amortización de Cierre del ejercicio cálculo de amortización Devengado Valuación de Activos Fijos Baja de bienes Identificación de la valuación de los bienes Baja de los saldos en libros Devengado Devengado Tratamiento de las mejoras como gastos Ejecución presupuesto autorizado del 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 Obra/proyecto Pública de Contrato firmado Compromiso anual + Compromisos Multianuales en forma referencial Alta de Bienes de Infraestructura Bienes Concesionados Certificado final de obra/proyecto Valuación de los bienes Firma del contrato de concesión Devengado Devengado Compromiso anual + Compromisos Multianuales en forma referencial Modelo Conceptual del SIIF2 01/04/ /203

137 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Secundarios Ejecución contrato concesión del de Devengado Inversión Pública Adjudicación de las Obras/proyectos anuales Adjudicación de las Obras/proyectos plurianuales Firma del contrato de obra /proyecto Compromiso Compromiso anual + Compromisos Multianuales en forma referencial Ejecución de las Obras/proyectos Certificado avance obra/proyecto de de Devengado Anticipos de fondos Ajuste de costos y modificaciones de obra/proyectos Medición y liquidación de ajustes de costos y modificaciones Terminación de la obra/proyecto Autorización de los anticipos, salidas de fondos Adenda del contrato de obra/proyecto. Certificado de avance de obra/proyecto y firma de contador aprobando la distribución de los costos. 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. Pagado Compromiso Devengado Devengado Modelo Conceptual del SIIF2 01/04/ /203

138 Módulo de Contabilidad Módulos con los que se integra Procesos Punto de Integración Momento de registro Integración con los Módulos Secundarios Constitución Garantías obra/proyecto efectivo de de en Ingresos de fondos Constitución de la deuda Fondos de Terceros en Garantía Percibido Devolución garantías obra/proyecto efectivo de de en 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 Objetivos El módulo de tesorería 53 debe contemplar las funcionalidades necesarias para el registro y la gestión asociada a la recaudación y pago de todos los recursos que forman parte de la gestión del presupuesto: El Módulo de Tesorería debe considerar los siguientes principios para su adecuado funcionamiento: a) Eficiencia: La gestión de tesorería debe velar por la administración de los fondos públicos, cualquiera que sea la fuente de financiamiento y uso de los mismos, y de los títulos y valores en custodia, programando oportunamente los compromisos, obligaciones y pagos para ejecutar el presupuesto de gastos, viabilizando su óptima aplicación y realizando un seguimiento permanente, minimizando costos de funcionamiento. b) Prudencia: Toda la gestión de tesorería se debe realizar bajo un estricto criterio de prudencia, minimizando los riegos en el proceso de administración y obtención de rendimientos de los recursos públicos. c) Oportunidad: La ejecución de los procedimientos relacionados a la tesorería deben realizarse utilizando los mecanismos más idóneos que aseguran la pronta 53 No debe confundirse el Módulo de Tesorería con la propia TGN. Si bien la mayoría de funcionalidades del Módulo de Tesorería serán utilizadas principalmente por funcionarios de la TGN ello no quita que este módulo cuente con funcionalidades que deben ser operadas por funcionarios ajenos a la TGN. Modelo Conceptual del SIIF2 01/04/ /203

139 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 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 Gestión de los recursos REQ 5-62 Percepción de recursos El módulo de Tesorería deberá contener todos los procedimientos y funcionalidades necesarias para una correcta percepción y registración de los ingresos del presupuesto. Se consideran recursos percibidos a la recepción de efectivo en Caja, depósitos de fondos en Bancos autorizados para efectuar esta recaudación o cobros mediante títulos, valores o certificados legalmente determinados. En el momento de la percepción de los recursos, se registrará en el módulo contable la ejecución del presupuesto de recursos en la etapa del percibido, generándose en forma automática el asiento por partida doble que corresponda. REQ 5-63 Registración de los recursos El módulo de Tesorería deberá contar con los procedimientos y funcionalidades destinadas a la registración de los recursos por parte de la Unidades Ejecutoras responsables de su gestión, en especial, a través de la DGI y Aduana. En el caso de los ingresos provenientes de Lotería y Casino corresponde incorporarlos directamente al módulo de tesorería, quedando el registro a cargo de las Unidades Ejecutoras de Lotería y Casino, como asimismo el tratamiento de los recursos propios de los distintos organismos que conforman el Gobierno Central. En el caso que este proceso requiera un proceso gradual de implementación, el módulo de contabilidad del SIIF2 deberá poder capturar los datos necesarios para la registración contable de los ingresos mediante mecanismos de interoperación adecuados desde los sistemas de origen las entidades recaudadoras o bien permitir el registro en forma directa sobre módulo de tesorería del SIIF2. REQ 5-64 Recursos por Desembolsos de Prestamos En base a los movimientos de la cuenta banco y la información suministrada por el módulo de deuda, el módulo de tesorería deberá registrar el monto ingresado por desembolso de préstamos en la Cuenta Única en el momento del percibido, realizando el correspondiente asiento contable en el módulo contable y la registración presupuestaria en el módulo presupuestario en forma automática. Modelo Conceptual del SIIF2 01/04/ /203

140 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 Gestión de los egresos Considerando que actualmente el SIIF le brinda soporte a las funciones de la Cuenta Única del Tesoro, el SIIF2 debe considerar en detalle la optimización de su actual forma de funcionamiento, en forma conjunta a la optimización de las funcionalidades actualmente en producción relativas a los egresos, como por ejemplo el control de los valores de los arrendamientos oficiales de inmuebles a cargo del Gobierno Central o el clearing de pagos relativos a servicios públicos. REQ 5-69 Programación financiera de los pagos En base a los compromisos y devengos de gastos registrados en el módulo de presupuesto el módulo de Tesorería, en conjunto con la información de los recursos disponibles en la Cuenta Única del Tesoro, el SIIF2 deberá contar con las funcionalidades necesarias para contar con una programación financiera de los pagos a realizar en forma mensual. REQ 5-70 Plan de Caja En función de los gastos devengados, las transacciones que se encuentran en estado obligado intervenido y el cupo de pago informado por la Tesorería General de la Nación, el módulo de Tesorería deberá contar con los procedimientos y funcionalidades necesarias Modelo Conceptual del SIIF2 01/04/ /203

141 para que los Incisos, a nivel de Unidad Ejecutora prioricen los pagos a realizar en el momento del Mandado a Pagar - Obligado Intervenido, generándose el Mandado a Pagar- Obligado Priorizado. En base a esta información el sistema deberá conformar el Plan de Caja con una desagregación de pagos diaria. El Plan de Caja será aprobado por la Tesorería General de la Nación. REQ 5-71 Medios de Pagos En base al Plan de Caja aprobado por la Tesorería General de la Nación, el SIIF2 deberá permitir el pago de las obligaciones autorizadas mediante distintos medios de pagos, utilizando preferentemente transferencias bancarias, la cual debe funcionar para todas las entidades del Sistema Financiero, o eventualmente mediante la emisión de cheques automáticos. REQ 5-72 Registro de pagos presupuestarios El sistema deberá contar con las funcionalidades necesarias para gestionar los pagos asociados a transacciones presupuestarias. Para ello deberá generar las Ordenes de Pago correspondientes a transacciones devengadas y mandadas a pagar en estado Obligado Priorizado, validando la existencia de disponibilidad presupuestaria para todas las fuentes de financiamiento, y la disponibilidad financiera, excepto para la fuente de financiamiento Rentas Generales,, en el libro Caja o en el Libro Bancos según corresponde, afectando la etapa del pagado, registrando el débito correspondiente y generando en forma automática el asiento por partida doble para la imputación indicada en el Orden de Pago. REQ 5-73 Registro de pagos no presupuestarios El sistema deberá contar con las funcionalidades necesarias para gestionar los pagos asociados a transacciones no presupuestarias, tales como el otorgamiento de anticipos, pagos a cuentas o devoluciones de garantías. Este tipo de movimientos serán registrados en el sistema como una deuda hasta tanto se complete la operación y se puedan afectar las partidas presupuestarias correspondientes. REQ 5-74 Pagado y Percibido por Objeto y Programa Presupuestario El sistema deberá contener información detallada de los montos pagos y percibidos por objeto del Clasificador Presupuestario y por programa presupuestario. Para ello los datos presupuestarios deben mantenerse en la cartera financiera del módulo contable, generando tantas líneas como programas presupuestarios se identifiquen al momento de realizar el compromiso y el devengo. Esta desagregación permitirá contar con información del pagado por objeto del clasificador presupuestario y por programa presupuestario. REQ 5-75 Devolución al crédito o Pago (Reversión de Pagos) El sistema deberá contener las funcionalidades necesarias que permitan la gestión y autorización de reversos en los pagos realizados por error, registrando todos los movimientos contables y presupuestarios necesarios para realizar esta operación. Para ello el sistema generará un documento de devolución al crédito o de devolución al pago, y cuando detecte por conciliación bancaria el depósito correspondiente procederá según haya escogido el usuario a reversar el pago o a reversar toda la cadena presupuestaria hasta restituir el crédito presupuestal. Modelo Conceptual del SIIF2 01/04/ /203

142 REQ 5-76 Anulación y reimpresión de cheques El sistema deberá contener las funcionalidades necesarias que permitan la anulación y reimpresión de cheques, ya sea por error o caducidad de los mismos, registrando todos los movimientos contables necesarios para realizar esta operación. REQ 5-77 Pagos de Servicios de la Deuda La deuda de intereses y amortizaciones es administrada por el Banco Central, el cual informará estos movimientos al SIIF2 mediante la interoperación que se defina. REQ 5-78 Pago de Retenciones El sistema deberá contener las funcionalidades necesarias para gestionar el pago de retenciones a favor de terceros al efectuar la cancelación de una obligación, considerando el tratamiento diferenciado para cada concepto de retenciones. Estas retenciones pueden generar el movimiento de fondos, como por ejemplo pago una cooperativa. Otro tipo de retenciones no generan movimientos de fondos, como por ejemplo el pago por parte de un Inciso a un tercero que se compensa con obligaciones del tercero en la DGI o en el BPS. REQ 5-79 Gestión de Fondos Rotatorios De acuerdo a la normativa vigente, el sistema debe contar con las funcionalidades necesarias para una adecuada gestión de los Fondos Rotatorios autorizados para los Incisos a nivel de Unidad Ejecutora. La funcionalidad de gestión de fondos rotatorios debe permitir la ejecución de operaciones normales o de regularización de fondos. El módulo debe realizar en forma automática al inicio del ejercicio el cálculo de la disponibilidad de fondos rotatorios para cada Inciso en base a la duodécima parte del crédito presupuestal menos la diferencia que se arrastra del ejercicio anterior y debe liberar una operación de tesorería desde la CUN a las cuentas de los Incisos. Esta funcionalidad debe registrar la autorización de los fondos rotatorios como anticipo de fondos y su liquidación, al momento de devengar dicha liquidación, en el módulo contable. REQ 5-80 Valores en Custodia La custodia comprende la guarda, conservación y registro clasificado de los valores y la percepción de los dividendos, utilidades o remanentes. El módulo de tesorería debe registrar los movimientos generados por los valores en custodia en un registro auxiliar, de acuerdo a su naturaleza, para informar el cierre del ejercicio contable la existencia de los mismos y su cotización a fin de registrar el valor de las inversiones cuando corresponda. REQ 5-81 Pago de Suministros en formato clearing El sistema debe contener las funcionalidades necesarias para que los Incisos, a nivel de Unidad Ejecutora, puedan registrar en forma específica los pagos correspondientes a los suministros mediante el mecanismo o de pago denominado Clearing de Suministros. El Clearing de Suministros es un mecanismo de compensación de deudas por parte de los distintos Incisos, mediante el cual se generan operaciones de adelanto de tesorería que posteriormente se regularizan. Para dar soporte a este mecanismo de pago, el sistema debe contar con un repositorio de datos que permita efectuar un proceso de clearing entre los débitos y créditos generados por cada empresa pública proveedora de servicios públicos, con el fin de emitir la orden de pago por parte de la Tesorería General de la Nación por el Modelo Conceptual del SIIF2 01/04/ /203

143 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 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 Objetivos El módulo de deuda debe contemplar las funcionalidades necesarias para el registro y la ejecución de las operaciones de crédito público que realiza el Estado en el marco de las autorizaciones legales correspondientes, así como la ejecución de las operaciones destinadas al pago de los servicios de la deuda. El Módulo de Deuda debe considerar los siguientes principios para su adecuado funcionamiento: a) Eficiencia y prudencia: El endeudamiento público tiene como objetivo fundamental cubrir los requerimientos de financiamiento del sector público al más bajo costo posible, optimizando los recursos y sujeto al menor grado de riesgo posible. b) Transparencia: El proceso de endeudamiento público debe llevarse a cabo con oportunidad, transparencia, procurando el acceso oportuno a información veraz, comprensible y confiable. Modelo Conceptual del SIIF2 01/04/ /203

144 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 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 SIIF Información sobre recursos provenientes de operaciones de deuda REQ 5-85 Ingresos de recursos por operaciones de crédito público El sistema de administración de la deuda pública del Banco Central deberá remitir información al módulo de deuda del SIIF2 de los siguientes aspectos referidos a los ingresos generados por operaciones de crédito público: Propuesta de Calendarización de Ingresos (Financiamiento); Emisión de Valores y Títulos; Colocación de Valores y Títulos; Autorización de endeudamiento de las entidades del sector público uruguayo; Otorgamiento de garantías y avales; Caídas de garantías y avales otorgados. Con el fin de gestionar esta información, el módulo de deuda del SIIF2 deberá contar con un repositorio de datos que permita almacenar y gestionar esta información, registrando los movimientos correspondientes en el módulo de presupuesto y en el módulo de contabilidad. REQ 5-86 Contratación y desembolsos de Préstamos El sistema de administración de la deuda pública del Banco Central deberá remitir información al módulo de deuda del SIIF2 de los siguientes aspectos referidos a la contratación y desembolsos de préstamos de crédito público: Contratación de préstamos (compromiso); Desembolso de préstamos (devengado); Ingreso efectivo (percibido). Con el fin de gestionar esta información, el módulo de deuda del SIIF2 deberá contar con un repositorio de datos que permita almacenar y gestionar esta información, registrando los movimientos correspondientes en el módulo de presupuesto y en el módulo de contabilidad. Modelo Conceptual del SIIF2 01/04/ /203

145 Información sobre gastos asociados a operaciones de deuda REQ 5-87 Egresos por operaciones de crédito público El sistema de administración de la deuda pública del Banco Central deberá remitir información gastos asociados a las operaciones de deuda al módulo de deuda del SIIF2 de los siguientes aspectos: Propuesta de Calendarización de egresos (servicios de la deuda e Intereses); Adecuaciones presupuestarias de intereses y comisiones; Ejecución del gasto relacionado con el servicio de amortizaciones de la deuda; Compromiso; Devengado; Mandado a pagar; Pagado. Ejecución del gasto relacionado con el servicio de intereses y comisiones de la deuda: Compromiso; Devengado; Mandado a pagar; Pagado Regularización y ajuste por variación de tipo de cambio emitidas para el servicio de amortización de la deuda; Regularización y ajustes por variación de tipo de cambio u otras variables contempladas en los servicios de intereses y comisiones de la deuda; Recupero de avales y garantías por pago del deudor principal; Información sobre gestión de la deuda pública REQ 5-88 Información de la gestión de la deuda pública El MEF cuenta en su estructura organizativa con un área responsable de la gestión de la deuda pública. Esté área, mediante mecanismos de interoperabilidad, vía up load o web services, o través de los sistemas del Banco Central en su carácter de Agente Financiero de la República Oriental del Uruguay, deberá enviar información al módulo de deuda del SIIF2 sobre los siguientes aspectos: Adquisición de Instrumentos Derivados tales como: Contrato a término (forwards), Contratos a futuros, Permutas Financieras (Swaps) y/o con Opción Adquisición de Instrumentos de Patrimonio tales como compra de acciones o participaciones en entidades. Cualquier Inversión que realice el Gobierno Uruguayo en Instrumentos Financieros, En caso que no sea posible ingresar esta información en forma automática, deberá ser ingresada en forma directa mediante pantallas de captura de datos al SIIF2. Modelo Conceptual del SIIF2 01/04/ /203

146 6. Integración sistemas de apoyo transversales En este apartado se especifican los sistemas con los que interoperará el SIIF2, los que son esquematizados en la Ilustración 6-1 Esquema General de Interoperación para el SIIF2. Para cada sistema se presenta una breve descripción de sus principales objetivos, las interacciones detectadas como relevantes y los impactos o riesgos que los volúmenes de información, requeridos por la interoperación, podrían poner sobre la infraestructura y el diseño del sistema. Ilustración 6-1 Esquema General de Interoperación para el SIIF2 El diseño propuesto en la ilustración es claramente uniforme en torno a una propuesta de interacción exclusivamente centrada en servicios Web, comunicados mediante el encadenamiento de un bus local a la CGN, con la plataforma de Gobierno Electrónico de la AGESIC. Incluso este esquema es utilizado para sistemas que están actualmente alojados dentro de la CGN. La arquitectura propuesta tiende a inhibir el desempeño de la aplicación en términos de tiempos de respuesta (en adelante referidos como latencia) y niveles de procesamiento por segundo (en adelante referido como throughput) si se compara con alternativas como la carga directa entre bases de datos vía procedimientos ETL, o la comunicación mediante protocolos propietarios en modalidad RPC o EDI, por lo que su implementación requiere de un cuidadoso dimensionamiento de la infraestructura y la realización temprana de pruebas de desempeño durante el desarrollo del SIIF2. La razón por la que se estima como la alternativa más adecuada se debe a que, durante el análisis de los sistemas transversales realizado, se percibió un alto dinamismo en las iniciativas de modernización del Estado, en la que hay sistemas que están siendo trasladados a unidades organizativas diferentes, sistemas que se están siendo remplazados por alternativas de mayor cobertura funcional, e incluso se están implantando en algunas unidades ejecutoras sistemas GRP en base a alternativas de mercado. Modelo Conceptual del SIIF2 01/04/ /203

147 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 SIIF 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 WSaddressing, 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) Características funcionales El SICE apoya todas las etapas de los procesos de adquisiciones en el Estado. Permite el análisis de las diferentes etapas del proceso de compra: pedidos, armado de la compra, Modelo Conceptual del SIIF2 01/04/ /203

148 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 Características técnicas SICE tiene más de cuentas activas de usuarios, los que en los últimos 12 meses generaron un volumen de transacciones hacia el SIIF 1 que superó las 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 SIIF Sistema Lucia (DNA) Características funcionales Lucia es un sistema de Gestión Integrada Aduanera para el control de las operaciones aduaneras de importación, exportación y tránsito de mercaderías en territorio uruguayo. El sistema Lucia, si bien recibe pagos, no tiene actualmente relación directa con el SIIF2, sino que envía información al sistema de información financiera a través del Banco de la Modelo Conceptual del SIIF2 01/04/ /203

149 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 Características técnicas Trabaja en función de mensajería en formatos propietarios EDI, a través de los cuales recibe las declaraciones aduaneras, las valida y las procesa. La situación descrita desea ser cambiada por la CGN, por una interoperación que permita capturar la información agregada de las transacciones de la Aduana, la cual debe contar con el respaldo del detalle delas transacciones en el sistema Lucia. Las operaciones realizadas por la aduana superan las al año, y tienen una tasa de crecimiento anual de aproximadamente un 10%. REQ 6-2 Interoperación SIIF2 - Lucía El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información agregada con el Sistema Lucía, el cual debe contar con el detalle de las transacciones en dicho sistema 6.4 Sistemas de la Dirección General Impositiva (DGI) Características funcionales Los sistemas de la Dirección General Impositiva (que resultan de interés para el presente análisis) soportan los procesos relacionados con la recaudación tributaria en la nación y su relación con CGN se centra en la alimentación de la cuenta de recaudación. Al igual que el caso del sistema Lucia, la DGI actualmente entrega información agregada a la CGN. Una adecuada implementación de una interfaz de interoperabilidad en el SIIF2 debiera manejar adecuadamente la sincronización entre los planes de cuentas de ambos sistemas y contribuir a acelerar los plazos de cierre mensual, que hoy toman cuatro meses Características técnicas Debido a que la frecuencia de comunicación requerida con las DGI es de sólo una vez al día (no se especificó que se necesitara una comunicación en línea), los impactos sobre la infraestructura pueden ser mitigados utilizando cargas nocturnas. REQ 6-3 Interoperación SIIF2 Sistemas de Recaudación de DGI El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información agregada con los Sistemas de Recaudación de la DGI, el cual debe contar con el detalle de las transacciones en dicho sistema. REQ 6-4 Interoperación SIIF2 Sistemas de Retenciones DGI El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información referente a las retenciones de impuestos realizadas en el SIIF2 y que deben ser informadas en forma diaria a la DGI. Modelo Conceptual del SIIF2 01/04/ /203

150 REQ 6-5 Interoperación SIIF2 Sistemas de Resguardos DGI El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información referente a los resguardos asociados a las retenciones de impuestos realizadas a los proveedores en el SIIF2 y que deben ser informadas en forma mensual a la DGI. REQ 6-6 Interoperación SIIF2 Sistema de Certificado de Crédito de DGI El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema de Certificados de Crédito de DGI. REQ 6-7 Interoperación SIIF2 Sistema de Certificado Único de Empresa de DGI El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema de Certificado Único de Empresa de DGI. 6.5 Registro Único de Proveedores del Estado (RUPE) Características funcionales El RUPE permite registrar y mantener la información actualizada de todas las personas jurídicas interesadas en contratar con el Estado. Su objetivo es disponibilizar toda la información relevante para los organismos públicos al momento de contratar una empresa, brindando acceso a la misma desde un solo lugar y de forma inmediata. Además, los proveedores tienen acceso a la información que de ellos conste en el registro, sin necesidad de solicitud previa. La Agencia de Compras y Contrataciones del Estado (ACCE) es responsable del desarrollo, funcionamiento y mantenimiento del RUPE Características técnicas En la actualidad los servicios del RUPE se encuentras disponibles a través de la PGE. En particular utiliza el servicio de novedades de la plataforma. Una vez recibida la novedad de un cambio en la información de un proveedor, se deben consumir los servicios propios del RUPE para actualizar la información. REQ 6-8 Interoperación SIIF2 RUPE El sistema deberá proveer los mecanismos necesarios para permitir suscribirse al servicio de novedades del Registro Único de Proveedores del Estado (RUPE) en modalidad Push (Notificación). A partir de la recepción de las novedades que necesitan ser procesadas por el SIIF2, se deberá consumir los servicios propios de información del RUPE. Entre la información que se debe consumir está: datos generales del beneficiario, cuentas bancarias y sanciones. 6.6 Sistema de Distribución del Gasto (SDG) Características funcionales El SDG es un sistema que permite el ingreso periódico de información sobre la distribución por Unidad Organizativa del presupuesto ejecutado en el SIIF en cada trimestre del año, así como la definición y cuantificación de los productos realizados en cada Unidad Organizativa. Modelo Conceptual del SIIF2 01/04/ /203

151 6.6.2 Características técnicas En la actualidad el SDG requiere información del SIIF2 de cada Unidad Ejecutora por cada trimestre. El tamaño de las cargas se estima en aproximadamente transacciones. Esta carga se hace actualmente utilizando directamente las bases de datos de producción, lo que genera una situación de acoplamiento que hacen que cualquier cambio en el SIIF2 ponga en riesgo la integridad de la información manejada en el SDG (se requiere la interpretación de parte de la información por expertos). Los impactos de cambiar el actual esquema de carga de información a una arquitectura orientada a servicios pueden ser en gran medida eliminados si se mantiene la periodicidad trimestral o se reduce a una periodicidad mensual de la carga, ya que en este caso la transmisión puede hacerse durante la noche o en un itinerario programado donde se evidencie un mínimo impacto sobre los usuarios transaccional de ambos sistemas. El SDG es un sistema hecho en Visual Basic 5, sobre una base de datos Oracle 10g., que se encuentra en un proceso de actualización mediante el desarrollo de una interfaz web utilizando GeneXus para Java. REQ 6-9 Interoperación SIIF2 SDG El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema de Distribución del Gasto (SDG) con una periodicidad mensual a nivel de Unidad Ejecutora y/o Unidad Organizativa. 6.7 Sistema de Presentación del Articulado (SPA) Características funcionales El SPA es utilizado por los Incisos y Unidades Ejecutoras para introducir la justificación y los textos de los artículos a ser incorporados en el Presupuesto, y en las instancias anuales de rendición de cuentas. La información del articulado es cargada en el SIIF una vez al año, y de esta se obtiene la asignación presupuestaria asociada a los artículos cuando corresponde Características técnicas El volumen de información manejado por el SPA (la cual a modo de ejemplo en el año 2012 fue de 300 artículos con asignación presupuestaria para 10 partidas) y la frecuencia de carga no debieran generar requerimientos significativos en infraestructura para la implementación de la interoperabilidad con el SIIF2. La única consideración que se debe tener al momento de diseñar la interfaz es que esta debe permitir la división de la carga en múltiples invocaciones (no tratar de cargar toda la información en una sola invocación), ya que de no contar con esta capacidad, el proceso de carga puede verse afectado por time outs de comunicación. REQ 6-10 Interoperación SIIF2 - SPA El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema de Presentación del Articulado. Modelo Conceptual del SIIF2 01/04/ /203

152 6.8 Sistema Nacional de Inversiones Públicas (SNIP) Características funcionales El SNIP es el sistema destinado a mejorar la calidad de la inversión pública del Uruguay, optimizando y mejorando la eficiencia y el control del gasto público asociado a la inversión pública. El SNIP tiene la capacidad de soportar todo el ciclo de vida de un proyecto de inversión, y entre sus objetivos busca que las Unidades Ejecutoras, previo al otorgamiento de los recursos presupuestales, tengan desarrollada la etapa de pre inversión, y que una vez transcurrida la evaluación del proyecto, se cumplan las condiciones para obtener recursos y ejecutar el proyecto. Una vez puesto en completo funcionamiento, el SNIP remplazará el Sistema de Información y Seguimiento de Inversión (SISI), el que con más de 560 usuarios, es el sistema actualmente utilizado para el seguimiento de las iniciativas de inversión, pero cuyo alcance funcional es menor. En relación al SIIF2, se espera que este tenga la capacidad de tomar los proyectos desde el SNIP e integrarlos al presupuesto, mantener sincronizada la información de los techos presupuestarios y, en general, mantener la consistencia con la CGN a nivel de los recursos de los proyectos de inversión y vincular el presupuesto y la ejecución de los Proyectos de Inversión a nivel Componentes. Por otra parte, la información de la ejecución de los proyectos es relevante para el SNIP, por lo que se prevé la necesidad de que el SIIF2 cuente con mecanismos para informar los niveles de ejecución asociados a los proyectos de inversión a nivel de componentes. La periodicidad de esta actualización debe ser diaria. Por último, es importante la implementación de mecanismos que garanticen que la información de los proyectos esté constantemente sincronizada entre ambos sistemas, por ejemplo a nivel de la estructura de partidas de los proyectos. La lógica de trabajo del SNIP impone cambios a la forma de trabajar con los proyectos de inversión. A modo de ejemplo, hoy se manejan alrededor de 700 proyectos de inversión, pero son proyectos presupuestales, y agregan información de varios proyectos. En el nuevo SNIP, cada proyecto será tratado en detalle y de manera individual, lo que se estima llevaría este número a más de Características técnicas Considerando las características funcionales y teniendo en cuenta que el SNIP no registra los detalles de cada transacción del SIIF2, sino que trabaja con información a nivel de Componentes, los que deberán correlacionarse con Objetos del Gasto, se estima desde un punto de vista técnico que la interoperación con este sistema no impondrá cargas destacables ni de throughput, ni de tamaño de archivos. El SNIP está construido en C++.Net, y cuenta con capacidad para el consumo y provisión de servicios Web, por lo que no se anticipan problemas de tecnológicos para la implementación los contratos que se definan en el SIIF2. Modelo Conceptual del SIIF2 01/04/ /203

153 REQ 6-11 Interoperación SIIF2 - SNIP El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema Nacional de Inversiones Públicas (SNIP). 6.9 Sistema de RR.HH (SGH-SLH) Características funcionales El SGH apoya la gestión de los recursos humanos del Gobierno, que incluye la estructura organizativa y los puestos de trabajo para todos los vínculos contractuales de los Incisos y Unidades Ejecutoras del presupuesto nacional y los datos personales y funcionales de quienes ocupan las plazas definidas en la estructura formal. Se trabaja en 3 niveles en paralelo: formal, real y retributivo que reflejan respectivamente lo establecido por la normativa, el funcionamiento real y la forma en que se estructura el pago de haberes. En el ingreso de la información se controla la estructura institucional, los datos de las partidas presupuestales y las normas legales en los clasificadores del SIIF. Los movimientos controlados por la CGN en el SGH del rubro 0 se reflejan automáticamente en los créditos de las partidas presupuestales del SIIF. Las partidas retributivas personales se integran en el SLH el cual incorpora los descuentos, las retenciones legales, cálculos de multas y licencias, etc., para realizar la liquidación de sueldos. Una vez finalizada la liquidación se pueden emitir los recibos y planillas para los controles requeridos y se generan los datos para los cajeros, la historia laboral del BPS, el sistema automático de créditos del BROU, las cuentas corrientes de aguinaldo e IRPF, el sistema de transporte metropolitano y otras salidas para el resto de los involucrados. Se prevé la confección de la Obligación de la liquidación automáticamente en el SIIF. Actualmente el SGH se divide en 2 módulos principales. El primer módulo es responsable de gestionar los aspectos financiero-contables en relación al SIIF y la interrelación con el SLH, y está radicado en CGN. El segundo módulo maneja todos los demás aspectos relacionados con la gestión humana, como la planificación de la dotación, capacitación, gestión de la carrera funcionaria, etc., es llevada en un nuevo proyecto, denominado SGH 2.0, que está bajo la gestión de la Oficina Nacional del Servicio Civil. El SIIF2, al igual que la versión actual, trabajara con el módulo centrado en la parte financiera contable de la gestión de los RRHH Características técnicas La actual integración entre el SIIF y el SGH es vía procesos por lotes entre bases de datos. Si bien este esquema puede ser mantenido para el nuevo proyecto, se recomienda evaluar tempranamente en el desarrollo la conveniencia de llevarlo a servicios Web. Esta evaluación deberá hacerse sobre la consideración de que si la integración se realiza vía SOA, su desempeño será considerablemente menor que la alternativa basada en procesos ETL, sin embargo, también será considerablemente más flexible y contribuirá de mayor manera a la agilidad organizacional y la orientación a procesos dentro de la CGN. Con respecto a los riesgos asociados a un aumento en los requerimientos de infraestructura de cambiarse a un esquema basado en SOA, si bien los requerimientos de infraestructura probablemente deban ser revisados en base a pruebas de desempeño que se realicen sobre Modelo Conceptual del SIIF2 01/04/ /203

154 los servicios construidos, debido a la periodicidad mensual de la carga de información de los pagos de nóminas, no debiera incrementar los requerimientos de manera significativa. REQ 6-12 Interoperación SIIF2 SGH-SLH El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema de Gestión de los Recursos Humanos (SGH-SLH) Sistema de Planificación Estratégica y Evaluación (SPE) Características funcionales El SPE recoge la Planificación Estratégica de los distintos Incisos, bajo una lógica de Áreas Programáticas, Programas y Objetivos de Programa. En este sistema, que remplaza al Sistema de Evaluación (SEV), se definen objetivos del quinquenio en base al presupuesto y cada año se realizan las rendiciones de lo ocurrido en el periodo anterior, y se ajusta planificación para el año siguiente La interacción entre el SPE y el SIIF2 es puntual pero crítica, en el SPE se definen los programas y esta información debe mantenerse consistente y coordinada con la información capturada por el SIIF2. También en el SPE se definen los Objetivos Estratégicos e Indicadores asociados a los Programas. Por lo tanto es muy relevante que las estructuras de datos de ambos sistemas sean compatibles para el intercambio de información Características técnicas En base a las características funcionales de la interoperación entre el SPE y el SIIF2, no se anticipan necesidades de throughput o latencia que impacten significativamente la infraestructura del sistema. El SPE es un sistema construido en tecnología GeneXus para Java sobre una base de datos Oracle 10g. REQ 6-13 Interoperación SIIF2 SPE El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el Sistema de Planificación Estratégica y Evaluación (SPE) Sistemas del BROU Características funcionales El e-brou permite realizar transferencias en forma electrónica desde las cuentas del tesoro a las cuentas de los proveedores del estado. Desde el sistema central del BROU se envía información necesaria para realizar las conciliaciones bancarias de pagos y de recaudación, así como el estado de las cuentas del Gobierno Características técnicas El acceso al sistema e-brou se realiza a través de la página web del banco. Este sistema permite autenticar mediante contraseña o utilizando certificado digital. Modelo Conceptual del SIIF2 01/04/ /203

155 La información enviada desde el sistema central del BROU se realiza adjuntando archivos a mails. REQ 6-14 Interoperación SIIF2 e-brou El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con el sistema e-brou de forma segura, para realizar transferencias electrónicas. REQ 6-15 Interoperación SIIF2 BROU El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con los Sistemas centrales del BROU. Esta información es necesaria para realizar las conciliaciones bancarias de pagos y de recaudación, así como conocer el estado de las cuentas del Gobierno Sistemas del BCU Características funcionales Las transferencias en forma electrónica desde las cuentas del tesoro a las cuentas de los proveedores del estado en los bancos privados se realizan a través del Sistema Central de Liquidaciones (AGATA). A su vez el BCU se encuentra en proceso de migración de este sistema hacia los Sistemas RTS/X y DEPO/X. Desde el sistema central del BCU se envía información necesaria para realizar las conciliaciones bancarias de pagos y de desembolsos de préstamos de Organismos Internacionales. A su vez el BCU cuenta con sistemas que permiten obtener información necesaria para alimentar el módulo de Deuda Pública Características técnicas El intercambio de información para las transferencias electrónicas con el Sistema AGATA se realiza a través de Web-Services. REQ 6-16 Interoperación SIIF2 Sistema de Pago del BCU El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con los sistemas de pago del BCU, para realizar transferencias electrónicas. REQ 6-17 Interoperación SIIF2 BCU El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con los Sistemas centrales del BCU. Esta información es necesaria para realizar las conciliaciones bancarias de pagos y de desembolsos de préstamos de Organismos Internacionales. REQ 6-18 Interoperación SIIF2 Sistemas de Deuda Pública del BCU El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con los Sistemas de Deuda Pública del BCU. Modelo Conceptual del SIIF2 01/04/ /203

156 6.13 Sistemas del BPS Características funcionales El BPS emite el certificado común vigente de contribuyente. El SIIF2 necesita contar la información de estos certificados de que serán controlados al momento de generar pagos Características técnicas En la actualidad el BPS brinda estos servicios a través de la PGE. REQ 6-19 Interoperación SIIF2 BPS El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con los sistemas de certificado común de contribuyente del BPS Sistemas GRP Características funcionales El gobierno de Uruguay actualmente se encuentra en un proceso de fortalecimiento de las capacidades institucionales de los Incisos en aéreas tales como gestión presupuestaria, financiera, patrimonial, de abastecimiento y de inventario de activo fijo y de materiales. En este contexto, la AGESIC se encuentra liderando un plan de implantación de una solución de mercado tipo GRP a nivel de los Incisos con el fin de cubrir su gestión institucional. Este plan de implantación consta de múltiples fases, y tiene como objetivo final que el sistema GRP se encuentre disponible en más de diez Unidades Ejecutoras. La integración entre el SIIF2 y estos sistemas GRP es muy relevante, ya que gran cantidad los eventos de negocio que deben tener un reflejo financiero, presupuestario serán capturados en el GRP, en vez de la interfaz Web del SIIF2, por lo que luego deberán ser propagados al SIIF2 vía interoperabilidad. Esta modalidad de trabajo el GRP como cara visible a los usuarios institucionales, y una transmisión posterior al SIIF2 tiene como beneficio que la infraestructura requerida para la operación del SIIF2 se reduce, ya que toda la demanda que se deriva de la interacción entre el usuario y el sistema es absorbida por el GRP, y reemplazada por interoperaciones de menor frecuencia. Sin embargo, para lograr este beneficio, se requiere de un cuidadoso diseño de los contratos de interoperación, prestando especial atención a los procesos de validación e intercambio de información entre los dos sistemas Características técnicas La interoperación entre el SIIF2 y los sistemas de tipo GRP con cobertura institucional es una de las más importantes y técnicamente exigentes a desarrollar. Si se considera que el SIIF 1 tuvo casi transacciones durante el 2011, la demanda generada por los sistemas GRP institucionales cuanto a registro de transacciones debiera ser menor a esta cifra (no todas las instituciones tendrán necesariamente un GRP, ya que el SIIF2 brindara una alternativa para aquellas que no requieran su implantación). Dado esto, la demanda generada por los sistemas GRP debiera poder ser atendida aumentando los requerimientos de throughput en al menos 0,5 transacciones por segundo. Modelo Conceptual del SIIF2 01/04/ /203

157 Con respecto al tamaño de las transacciones, es recomendable establecer acuerdos de niveles de servicio que fomenten la transmisión de transacciones de bajo tamaño (menos de 1 mega por transacción). Debido a que, por ejemplo, los movimientos contables del sistema pueden tener relaciones 1 a n con sus auxiliares, no se recomienda que las interfaces consideren más de un movimiento por invocación, ya que poner múltiples movimientos en una sola llamada a servicios Web puede traer problemas de latencia excesiva, time outs, o reducción de la capacidad de escalamiento horizontal. El GRP actualmente en implantación es el sistema K2B, construido en tecnología GeneXus. REQ 6-20 Interoperación SIIF2 GRP de Cobertura Institucional El sistema deberá proveer los mecanismos necesarios para permitir el intercambio reglado de información con sistemas GRP de cobertura institucional, definiendo todos los procesos y mecanismos de validación a nivel funcional y tecnológico que permitan las interoperación entre ambos sistemas, considerando al SIIF2 como el sistema maestro. En el desarrollo de este requisito se deben considerar todos los aspectos señalados en Interoperabilidad institucional Modelo Conceptual del SIIF2 01/04/ /203

158 7. Modelado BPM del ciclo presupuestario La presente Sección contiene la situación actual ( As Is ) de los principales procesos del ciclo presupuestario modelados según metodología BPM. El objetivo de este punto es representar gráficamente el ciclo presupuestario, con el fin de ser incorporado como Anexo en los Términos de Referencia con el objetivo de permitir a los posibles proveedores tener una idea de alto nivel del flujo de funcionamiento actual de dichos procesos. 7.1 Situación actual del SIIF El Sector Gobierno General de la República del Uruguay se organiza en los siguientes grupos: Poderes del Estado: Legislativo, Judicial y Ejecutivo, el cual se conforma por los Ministerios y constituyen la denominada Administración Central. Tribunal de Cuentas (TC), Corte Electoral (CE) y el Tribunal de lo Contencioso- Administrativo (TCA), que cuentan con autonomía técnica por la naturaleza de sus funciones. Administración Descentralizada, conformada por los los Entes Autónomos y Servicios Descentralizados. Fondos de la Seguridad Social. Gobiernos Departamentales. Ilustración 7-1 Estructura del sector público Modelo Conceptual del SIIF2 01/04/ /203

159 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 financiera 54 : o o o Los organismos que pertenecen a la Administración Central, sin autonomía funcional y financiera; Los Entes del Art. 220 de la Constitución, tienen autonomía funcional pero no financiera; 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 (ANEP 55, UDELAR 56, 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 actividades 57. 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 ANEP: Administración Nacional de Educación Pública. 56 UDELAR: Universidad de la República. 57 Art. 34 de la Ley Nº del 13 de setiembre de Modelo Conceptual del SIIF2 01/04/ /203

160 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úblico 58, 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 de 6 de enero de Modelo Conceptual del SIIF2 01/04/ /203

161 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 Financiera Adm. Actores involucrados y actividades contempladas Actores que ejecutan el control Formulación, discusión sanción presupuesto. y del 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 Evaluación. y CGN, OPP, AIN y TC CGN (control interno previo y concomitante) AIN (control interno posterior), OPP (monitoreo de inversión asesora Modelo Conceptual del SIIF2 01/04/ /203

162 7.2 Descripción del macroproceso presupuestario al Poder Ejecutivo y evalúa el cumplimiento de objetivos) y Tribunal de Cuentas (control externo previo, concomitante y posterior) 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 civil 59. 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. Actividad Periodo de Gobierno Inicio Gobierno Año 1 Año 2 Año 3 Año 4 Año 5 Inicio Gobierno Vigencia del Presupuesto Quinquenal Formulación Presupuesto Quinquenal Ejercicio año 1 Revisión y Apertura de Créditos Presupuestales Ejecución del Presupuesto Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1) Ejercicio año 2 Revisión y Apertura de Créditos Presupuestales Ejecución del Presupuesto Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1) Ejercicio año 3 Revisión y Apertura de Créditos Presupuestales Ejecución del Presupuesto Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1) Ejercicio año 4 Revisión y Apertura de Créditos Presupuestales Ejecución del Presupuesto Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1) Ejercicio año 5 Revisión y Apertura de Créditos Presupuestales Ejecución del Presupuesto Elaboración de la Rendición de Cuentas y del Balance de Ejecución Presupuestal (1) (1): Incluye control y evaluación. 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 Modelo Conceptual del SIIF2 01/04/ /203

163 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 Formulación Los principales elementos del proceso de Formulación del Presupuesto pueden resumirse en la siguiente ficha: Ilustración 7-3 Formulación Como resultado de este proceso surge el presupuesto.por su parte, los créditos se desagregan en grupo, subgrupo, objeto del gasto y auxiliar. La estructura del Presupuesto establecida en el artículo 214 de la Constitución contiene: Los gastos corrientes e inversiones del Estado distribuidos en cada inciso por programa. Los escalafones y sueldos funcionales distribuidos en cada inciso por programa. Los recursos y la estimación de su producido, así como el porcentaje que, sobre el monto total de recursos, corresponderá a los Gobiernos Departamentales. Las normas para la ejecución e interpretación del presupuesto. En el Anexo II (Fichas de Procesos: Actividades) se describen las actividades necesarias, los actores que intervienen y el soporte utilizado para llevarlas a cabo. En el Anexo III (Modelado BPM) se realiza el modelado de procesos del ciclo presupuestario identificando en un primer nivel los Macroprocesos de Formulación Presupuestaria, Aprobación, Ejecución Presupuestaria y Evaluación Presupuestaria. Cada uno de estos Macroprocesos es explotado hasta un nivel dos de la metodología BPM bajo los procesos actuales (As Is). Modelo Conceptual del SIIF2 01/04/ /203

164 7.2.2 Ejecución presupuestal y financiera En cuanto a la ejecución del presupuesto, es posible sintetizarlo en el siguiente cuadro: Ilustración 7-4 Ejecución presupuestal En el proceso están reflejadas las principales tareas de la ejecución presupuestal del gasto y de recursos; faltan algunas que están como funcionalidades en el SIIF (ejemplo: arrendamientos), el proceso de asignaciones presupuestales que se hace durante el año (sin ser los refuerzos de rubros) y las modificaciones presupuestales que se generan automáticamente por interface con el SGH y arrendamientos oficiales. En el Anexo II (Fichas de Procesos: Actividades) se describen las actividades necesarias, los actores que intervienen y el soporte utilizado para llevarlas a cabo. En el Anexo III (Modelado BPM) se realiza el modelado de procesos del ciclo presupuestario identificando en un primer nivel los Macroprocesos de Formulación Presupuestaria, Aprobación, Ejecución Presupuestaria y Evaluación Presupuestaria. Cada uno de estos Macroprocesos es explotado hasta un nivel dos de la metodología BPM bajo los procesos actuales (As Is). Modelo Conceptual del SIIF2 01/04/ /203

165 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 demostrativos 60 : 1. Del grado de cumplimiento de los objetivos y metas programados, indicando las previstas y alcanzadas y su costo resultante. 2. Del resultado del ejercicio, por comparación entre los compromisos contraídos para gastos de funcionamiento más los compromisos contraídos que responden a gastos ejecutados para inversión con las sumas efectivamente recaudadas para la financiación de dichos gastos. 3. De la ejecución del presupuesto con relación a los créditos indicando: a) Monto del crédito original. b) Modificaciones introducidas en el transcurso del ejercicio. c) Monto definitivo al cierre del ejercicio. d) Compromisos contraídos, y, en su caso, ejecución de las inversiones. e) Saldo no utilizado. 60 Artículo 96 del TOCAF o artículo 214 de la Constitución de la República. Modelo Conceptual del SIIF2 01/04/ /203

166 f) Complementariamente, los compromisos referidos a gastos de inversión contraídos y no ejecutados en el ejercicio, indicando los que tienen crédito para el ejercicio siguiente y aquellos que no teniéndolo deban ser reprogramados. 4. De la ejecución del presupuesto con relación al cálculo de recursos por cada clase de ingresos, indicando: a) Monto calculado. b) Monto efectivamente recaudado. c) Diferencia entre lo calculado y lo recaudado. 5. De la aplicación de los recursos al destino para el que fueron instituidos, indicando el monto de las afectaciones especiales con respecto a cada clase de ingresos. 6. Del movimiento de fondos y valores, indicando: a) Existencias al iniciarse el ejercicio. b) Ingresos. c) Egresos. d) Existencias al cierre del ejercicio. 7. De la situación del tesoro, indicando los valores activos, los pasivos y el saldo. 8. De la Deuda Pública, clasificada en consolidada y flotante, indicando las emisiones de empréstitos y otras operaciones a largo plazo y la Deuda Pública en circulación al principio y al cierre del ejercicio. 9. De las fuentes de financiamiento que se han utilizado en el ejercicio. En el Anexo II (Fichas de Procesos: Actividades) se describen las actividades necesarias, los actores que intervienen y el soporte utilizado para llevarlas a cabo. En el Anexo III (Modelado BPM) se realiza el modelado de procesos del ciclo presupuestario identificando en un primer nivel los Macroprocesos de Formulación Presupuestaria, Aprobación, Ejecución Presupuestaria y Evaluación Presupuestaria. Cada uno de estos Macroprocesos es explotado hasta un nivel dos de la metodología BPM bajo los procesos actuales (As Is). Modelo Conceptual del SIIF2 01/04/ /203

167 8. Arquitectura Tecnológica del Sistema En este apartado se describen los elementos tecnológicos que conforman la plataforma base para el desarrollo del SIIF2. El desarrollo de una nueva versión del sistema brinda la oportunidad de aprovechar al máximo las ventajas que las nuevas tecnologías pueden ofrecer, en términos de: interoperabilidad, flexibilidad y agilidad para atender los requerimientos cambiantes de las instituciones, desempeño, seguridad, etc. Sin embargo, la gran cantidad de alternativas disponibles en el mercado hacen muy difícil decidir cuales piezas son realmente necesarias para construir el sistema, lo que sin una adecuada guía pone a los responsables del proyecto en riesgo de adquirir lo que no se necesita, o peor aún, no adquirir un elemento que, ya avanzado el desarrollo, resulta imprescindible. El objetivo de este apartado es presentar el diseño arquitectónico base para soportar el desarrollo y posterior operación del SIIF2. Se denomina Arquitectura Tecnológica Base debido a que establece las estructuras fundamentales sobre las cuales se podrá definir y refinar la arquitectura completa del sistema. Los contenidos definidos en este diseño permitirán anticiparse a problemáticas técnicas que recurrentemente aparecen en desarrollos de gran escala. La base tecnológica definida se centra en las piezas de middleware sobre las que se ejecutará el SIIF2, e identifica todas las que se necesitarán para manifestar los atributos de calidad del sistema detectados como requerimientos en la fase de análisis de este proyecto. Cada pieza es descrita de manera conceptual y sin sesgos hacia proveedores particulares, manteniendo una independencia tecnológica. Las distintas piezas de la plataforma se describen en base a seis capas: 1. Presentación, cuyos elementos soportan la ejecución de los componentes de la interfaz de usuario de los distintos módulos del sistema. 2. Negocio, cuyos elementos soportan la ejecución de los componentes que encapsulan los procesos, la lógica y las reglas de negocio más invariables del sector público, en el dominio presupuestario, deuda pública, financiero y contable. 3. Datos, cuyos elementos permiten el almacenamiento y manipulación de la información persistente del sistema. 4. Integración, cuyos elementos soportan la ejecución de los componentes que permiten la interoperación entre elementos internos y sistemas externos. 5. Seguridad, cuyos componentes permiten otorgar los niveles requeridos de identificación, aseguramiento, no repudio e integridad al sistema. Adicionalmente, la arquitectura base incorpora componentes de monitorización, que no influyen mayormente en el desarrollo del sistema, pero resultan altamente relevantes para su correcta operación. Para cada componente, se presenta: Un diagrama de presentación, donde el componente abordado aparece en color azul, y está relacionado de uno o más componentes presentados en color gris. Los componentes que aparecen en gris deben estar presentes y adecuadamente Modelo Conceptual del SIIF2 01/04/ /203

168 integrados al componente central, para que éste se comporte y trabaje de acuerdo a los supuestos establecidos para este diseño arquitectónico. Una descripción general de las capacidades del componente y el razonamiento que llevó a su inclusión en la plataforma. Una lista de requerimientos tecnológicos de alto nivel que deben satisfacer las alternativas de mercado que se consideren para manifestar uno o más de los componentes definidos en el documento. Ilustración 8-1 Capas de la plataforma de middleware de la arquitectura base 8.1 Capa de Presentación En esta sección se presentan los elementos que soportan la ejecución de los componentes de la interfaz de usuario de los distintos módulos del sistema. Modelo Conceptual del SIIF2 01/04/ /203

169 8.1.1 Portal Web 2.0 Ilustración 8-2 Portal Web 2.0 El Portal Web 2.0 permite la creación de interfaces de usuario altamente configurables. Tiene la capacidad de mezclar contenidos de múltiples fuentes, como por ejemplo: contenidos del SIIF2, contenidos de sistemas externos, sistemas de generación de reportes, contenido generado por middleware especializado, contenido estático, etc., permitiendo la creación de interfaces mucho más sofisticadas, usables y ricas en funcionalidad que las que se pueden lograr con tecnologías más tradicionales. Los nuevos portales Web 2.0 traen además componentes previamente construidos que permiten una interacción bidireccional con sus usuarios, y que pueden ser utilizados para dar soporte en línea (vía chats), recoger opiniones (con foros), e incluso, permitir que el usuario modifique parte del contenido que se publica en el portal, para así fomentar el trabajo colaborativo (wikis, blogs, etc.). Por último, el portal permite la personalización de su interfaz, permitiendo que cada usuario o institución configure sus contenidos de acuerdo a sus preferencias y necesidades. La plataforma considera a esta pieza como el punto central de acceso a sus usuarios. A través del portal, se presentan todos los contenidos y accesos a funcionalidades del Sistema, según los lineamientos de usabilidad que definan qué contenidos serán presentados en el portal y qué contenidos serán accedidos desde el portal. REQ 8-1 Portal Web 2.0 Debe proveer funcionalidades que permiten un completo soporte para la administración centralizada de sus contenidos. Con este fin, también debe poder integrarse al motor de gestión de contenidos que se escoja para la plataforma. Debe proveer mecanismos, como por ejemplo interfaces de desarrollo de aplicaciones (API, por el inglés ApplicationProgramming Interface), para la creación dinámica de aplicaciones web (centradas en tecnologías de portlets, webpartso equivalentes). Modelo Conceptual del SIIF2 01/04/ /203

170 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 activoactivo) 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 Servidor Web Ilustración 8-3 Servidor Web El servidor de aplicaciones es el componente de la plataforma encargado de desplegar gran parte de los elementos de interfaz de usuario. El uso de servidores web permite anticiparse a potenciales problemas de rendimiento y escalabilidad debido a su capacidad de operar en clústeres que pueden ser escalados horizontalmente y de independizarse de la capa de lógica de negocio. Modelo Conceptual del SIIF2 01/04/ /203

171 REQ 8-2 Servidor Web Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster). Debe brindar mecanismos de reconfiguración dinámica de clústeres, que permita iniciar y detener instancias en base a demanda, y pueda detectar la llegada de nuevas instancias a la red. Debe brindar mecanismos para hotdeployment de las aplicaciones web, que permita el despliegue e instalación de los desarrollos sin interrupción de los servicios prestados por la plataforma. Debe permitir la ejecución de múltiples versiones de una misma aplicación. Debe soportar mecanismos para la gestión automática de sus recursos, que permitan la liberación automática de los que puedan quedar tomados por problemas de programación. Debe tener la capacidad de delegación del balanceo a dispositivos de hardware externos. Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación y control de acceso para autorización de granularidad gruesa a sus contenidos. Debe proveer mecanismos de autorización de granularidad fina que puedan ser aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma. Debe soportar autenticación mediante los mecanismos de SSO que se elijan para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe soportar los protocolos que permitan la generación de contenido que pueda ser desplegado en el portal Web 2.0 seleccionado para la plataforma. 8.2 Capa de Negocios En esta sección se presentan los elementos soportan la ejecución de los componentes que encapsulan la lógica y las reglas de negocio más invariables del sector público, en el dominio presupuestario, financiero y contable Servidor de Aplicaciones Ilustración 8-4 Servidor de Aplicaciones Modelo Conceptual del SIIF2 01/04/ /203

172 El servidor de aplicaciones es el componente de la plataforma encargado de proveer servicios tales como: acceso a las fuentes de datos, soporte de transacciones y administración de sistemas distribuidos de gran escala. Su incorporación en la plataforma, ya sea para la implementación de componentes concebidos bajo un estilo arquitectónico multicapas o uno orientados a servicios, permite brindar a la arquitectura SIIF2 de mayores niveles de integridad a nivel de datos y de código, pues permiten la centralización de la lógica en un grupo controlado de nodos, lo que a su vez reduce el riesgo de que versiones inconsistentes del código se ejecuten de manera descontrolada. Por otra parte, el uso de servidores de aplicación permite anticiparse a potenciales problemas de rendimiento y escalabilidad, debido a una mejor utilización de recursos compartidos y su capacidad de operar en clústeres que pueden ser escalados horizontalmente. El servidor de aplicaciones cumple un rol fundamental en la plataforma, pues es el ambiente de ejecución donde se despliegan la mayoría de los componentes que encapsularán la lógica del negocio, así como gran parte de los servicios Web. REQ 8-3 Servidor de Aplicaciones Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster) Debe brindar mecanismos de reconfiguración dinámica de clústeres, que permita iniciar y detener instancias en base a demanda, y pueda detectar la llegada de nuevas instancias a la red. Debe brindar mecanismos para hotdeployment de las aplicaciones, que permita el despliegue e instalación de los desarrollos sin interrupción de los servicios prestados por la plataforma. Debe permitir la ejecución de múltiples versiones de una misma aplicación. Debe proveer servicios para el procesamiento de transacciones distribuidas en el estándar XA (del inglés extendedarchitecture). Debe proveer servicios de mensajería robusta, y soporte colas de mensajería XA. Debe proveer mecanismos para la ejecución y gestión punta a punta de procesos por lotes. Debe incorporar mecanismos que permitan la persistencia de las colas de mensajería en bases de datos, y proveer mecanismos de manejo de las colas frente a una indisponibilidad de la base de datos. Debe soportar mecanismos para la gestión automática de sus recursos, que permitan la liberación automática de los que puedan quedar tomados por problemas de programación. Debe soportar todos los protocolos necesarios para la ejecución de servicios Web basados en el WS-I Basic Profile, en todas las versiones del perfil. Debe soportar la capacidad de delegación del balanceo a dispositivos de hardware externos. Debe soportar integrarse a componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación y control de acceso para autorización de granularidad gruesa a sus contenidos. Debe soportar mecanismos de autorización de granularidad fina que puedan ser aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma. Modelo Conceptual del SIIF2 01/04/ /203

173 Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma Reglas de Negocio Ilustración 8-5 Reglas de Negocio Las Reglas de Negocio se centran en la implementación y modificación de las reglas de los procesos de negocio como por ejemplo las validaciones y los flujos de decisión que existen en los procesos de las instituciones de manera independiente y separada del código de la aplicación. Esta independencia entre las reglas y el código permite que las reglas puedan ser cambiadas sin tener que recompilar, reinstalar o reiniciar el sistema. Es decir, permiten una modificación altamente dinámica del comportamiento implementado. Incorpora además funcionalidades que permiten que las reglas sean ingresadas y modificadas por analistas de negocio, sin exigir conocimientos de programación (aunque puede contar con opciones avanzadas que permiten además la programación de reglas complejas). Este componente complementa los objetivos perseguidos con la incorporación de los componentes de negocio, y se utilizará para la implementación de las reglas de negocio que los expertos de la institución identifiquen como altamente dinámicas y variables. Es decir, no todas las reglas de negocio se implementan en este componente, sino que sólo aquellas cuyo dinamismo justifica ponerlas fuera del código. La incorporación de este componente fomentará aún más la capacidad de modificación del sistema, así como su capacidad de reflejar más fácilmente los procesos institucionales soportados por el SIIF2 y de acomodar sus cambios. REQ 8-4 Reglas de Negocio Debe proveer mecanismos que permitan almacenar las políticas y las normas de negocio definidas por los analistas de la CGN u otro conocimiento, codificado en reglas del tipo si/entonces y tablas de decisiones. Debe proveer un editor de reglas con una interfaz de usuario que permita la definición, de manera sencilla, de una regla de negocio o una política. Esta interfaz debe estar orientada a analistas de negocio sin conocimientos de programación. Modelo Conceptual del SIIF2 01/04/ /203

174 Debe poder ejecutar las reglas que en él se defina, realizando las tareas definidas en la regla o evaluando las políticas registradas en el repositorio en función de la información a la que se relaciona. Debe permitir la automatización de la ejecución de las reglas y políticas mediante esquemas de inferencia, que tomen en cuenta más de un parámetro o condición para la ejecución de una regla, o mediante esquemas reactivos, que esperen el cumplimiento de alguna condición para la ejecución de una regla o política. Debe habilitar la construcción de reglas, validaciones y programación de eventos mediante APIs, que permitan además su integración con el código del SIIF2. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster) Monitor de Actividades de Negocio Ilustración 8-6 Monitor de Actividades de Negocio El Monitor de Actividades de Negocio es un componente que permite recoger métricas asociadas a la ejecución de los procesos de negocio, y alimentar con ellas a cuadros de control e indicadores. Trabaja en base conjunto con la capa de negocios, ya que las métricas que captura son arrojadas por sensores que se ejecutan sobre él. Trabaja además en conjunto con el portal Web 2.0, donde son desplegados los cuadros de mando y los reportes de indicadores. El monitor de actividades de negocio cuenta con mecanismos para establecer alertas, para definir indicadores personalizados, y para definir respuestas automáticas que activen de manera proactiva o reactiva procesos y actividades en función de umbrales y parámetros de comportamiento. Este rol complementa las capacidades de la plataforma al darle mayor visibilidad a los procesos que se ejecutan sobre ella. La información que provee permite a usuarios de los distintos incisos y unidades ejecutoras, a nivel de jefatura y directivos ver en tiempo real cómo los procesos y actividades de la institución están siendo llevados a cabo en el día a día. Modelo Conceptual del SIIF2 01/04/ /203

175 REQ 8-5 Monitor de Actividades de Negocio Debe contar con mecanismos que permitan la definición de cuadros de mando, reportes y alarmas a usuarios sin conocimientos en programación. Debe poder capturar la información de ejecución de los procesos monitorizados en tiempo real. Debe poder generar reportes en tiempo real, que permitan la actualización de los resultados de la medición en el momento que aparece nueva información. Esto aplica a cuadros de mando y alertas. Debe poder integrarse con el Motor ETL para el manejo y procesamiento de grandes volúmenes de información. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster). Debe contar con mecanismos que le permitan desplegar todos sus informes y contenidos en el portal Web 2.0 seleccionado para la plataforma Motor de Inteligencia de Negocios Ilustración 8-7 Motor de Inteligencia de Negocios El Motor de Inteligencia de Negocios provee herramientas para transformar los datos de los distintos repositorios del sistema en información adecuada, en contenido y formato, para apoyar de manera efectiva la toma de decisiones. En particular, entrega bloques de construcción para el desarrollo de informes de gestión, cuadros de mando, paneles de indicadores claves de gestión, etc., y otorga a los usuarios capacidades para la elaboración de sus propios informes y para realizar análisis personalizados de información. Esta pieza se utilizará para generar los reportes para los usuarios directivos y de alta gestión del SIIF2 y constituye la pieza central propuesta para la implementación del SIIF2 Agregación, mediante la cual se podrán implementar los reportes analíticos, estratégicos y los análisis de inteligencia de negocios. Este tipo de middleware generalmente provee de mecanismos que permitirán la implementación de los requisitos de alarmas financieras del sistema y la implementación de la exportación de los reportes a formatos como, por ejemplo, PDF. Trabajará obteniendo la información principalmente del almacén de datos de la CGN, que es un repositorio especial para procesamiento analítico, que correrá sobre el motor de bases de datos (este almacén de datos se denomina técnicamente "data mart ROLAP", por Modelo Conceptual del SIIF2 01/04/ /203

176 las siglas del inglés de Procesamiento Analítico en Línea bajo tecnología Relacional), y que a su vez se alimentará mediante un motor de extracción, transformación y carga. REQ 8-6 Motor de Inteligencia de Negocios La CGN ya cuenta con un Motor de Inteligencia de Negocios. Los siguientes requerimientos son planteados en la eventualidad que se requiriera su reemplazo. Debido a la pérdida de conocimiento organizacional que se produciría con un cambio del producto, su remplazo no se recomienda. En cambio, se recomienda evaluar la actualización a la versión más reciente. Debe proveer de un ambiente para la creación de reportes, que permita la definición de reportes dinámicos e interactivos. Los reportes deben poder incorporar formatos variados de presentación como por ejemplo tablas y gráficos, los que se actualicen automáticamente de acuerdo a los datos almacenados en los repositorios de la aplicación. Debe brindar soporte para la construcción de reportes analíticos, donde sea posible interactuar con la estructura de la información almacenada en los repositorios, permitiendo reordenar la información de acuerdo a las necesidades del análisis, realizar pivoteo de filas y columnas, y mantener los datos calculados para la presentación. Debe proveer de componentes y conectores que permiten acceder a fuentes de distintas fuentes de información como: las bases de datos relacionales de sistemas transaccionales, el almacén de datos de la CGN, archivos de datos, etc. Debe contar con mecanismos de soporte para la creación y subscripción de alertas y alarmas de negocio. Debe proveer mecanismos de administración de modelos de datos, que den soporte a los reportes e informes y permitan separar el espacio de publicación de un reporte, de su ambiente de administración y construcción. Debe proveer componentes que permitan el acceso a sus contenidos y a sus funcionalidades por el portal Web 2.0 seleccionado para la plataforma. Debe tener mecanismos que permitan la integración con herramientas de oficina como por ejemplo Microsoft Office, que permitan visualizar reportes en el equipo local del usuario. Debe poder integrarse a los componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación y control de acceso para autorización de granularidad gruesa a sus contenidos. Debe proveer mecanismos de autorización de granularidad fina que puedan ser aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma. Debe soportar la autenticación mediante los mecanismos de SSO que se elijan para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster). Modelo Conceptual del SIIF2 01/04/ /203

177 8.2.5 Motor de Gestión de Datos Maestros Ilustración 8-8 Motor de Gestión de Datos Maestros El Motor de Gestión de Datos Maestros es un componente que implementa opciones para administrar estructuras jerárquicas de información y atributos de uso común, permitiendo su utilización en múltiples sistemas de la institución, y resguardando la integridad de la información que se está distribuyendo mediante un repositorio único de datos maestros. Con este componente la CGN puede consolidar, compartir, gobernar e identificar las relaciones de sus datos maestros, y puede administrar los cambios de sus jerarquías y relaciones. Con esto se hace posible la implementación de un proceso de gestión de los cambios y el control el impacto que estos puedan tener, no sólo en el SIIF2, sino que en todas las aplicaciones de la CGN que usen esta información. El motor también permite fusionar datos jerárquicos de orígenes distintos, estableciendo las relaciones y dependencias identificadas, dejando disponibles esta nueva información a la Institución. Sus capacidades permiten apoyar vía middleware la implementación de los requerimientos de Configuración del sistema. Debido a que junto a las estructuras jerárquicas este middleware permite gestionar las relaciones entre ellas, su utilización brinda un apoyo extra para la implementación de la integración entre el clasificador presupuestario y el plan de cuentas contables. En general, mucha información manejada en las instituciones de gobierno tiende a ser utilizada y replicada en distintos sistemas. Por ejemplo, es recurrente que lo catálogos donde se define la estructura de las instituciones del gobierno y los códigos que identifican a cada una, los catálogos donde se definen los códigos de cuentas contables, o los catálogos donde se definen los clasificadores presupuestarios, se almacenen en más de una base de datos. Estos catálogos de información además tienen relaciones entre sí (por ejemplo, existen relaciones entre el presupuesto y la contabilidad, o entre los catálogos de insumos y los catálogos de cuentas contables, etc.). Cuando la información de uno de estos catálogos cambia, muchas veces más de un sistema queda desactualizado, y se tienden a crear inconsistencias de información a nivel de negocio muy difíciles de detectar y corregir. La situación se hace mucho más compleja si se tiene en cuenta que en ocasiones hay cambios mayores en este tipo de datos maestros, como por ejemplo cambios completos del plan de cuentas de la Nación, creación de nuevos incisos, etc. Modelo Conceptual del SIIF2 01/04/ /203

178 Las responsabilidades del motor de gestión de datos maestros son: Ser la fuente única de la verdad para esta información de impacto en múltiples sistemas. Ser el punto donde se centralicen los cambios tanto de sus valores como de sus las relaciones. Ser el mecanismo que se encargue de distribuir de manera íntegra y consistente esta información al SIIF2 y cada sistema donde se requiera. REQ 8-7 Motor de Gestión de Datos Maestros Deben utilizarse los metadatos definidos y publicados en el catálogo de metadatos del Estado administrado por AGESIC. Debe permitir el almacenamiento centralizado, en una base de datos, de los dominios y nodos definidos para las jerarquías registradas en la aplicación, basado en un modelo abierto para el registro de los metadatos que definen estas estructuras. Debe proveer de mecanismos de administración de los metadatos, que permitan el registro de las relaciones entre nodos y dominios registrados. Debe implementar todas las funcionalidades que permitan la apropiada gestión de los atributos y propiedades de los datos maestros. Estos mecanismos deben permitir la definición de propiedades y características centrales que pueden ser asociadas a los nodos registrados. Debe además permitir la configuración de los dominios de manera central. Debe incorporar mecanismos para la validación, al momento de su ingreso, de la consistencia de la información contenida en los nodos y dominios. Debe proveer una plataforma central de administración, con acceso vía Web, para el manejo de las estructuras y los datos definidos, y que permita controlar eficazmente la proliferación de estas definiciones. Debe proveer de mecanismos de análisis de los datos maestros registrados, mediante herramienta analíticas que permitan identificar relaciones y problemas. Debe proveer de herramientas de migración de datos preferentemente basadas en estándares como XML que permitan compartir las estructuras definidas en la aplicación con el resto de las aplicaciones de la CGN. Debe proveer mecanismos de administración de mezclas de información, que permitan la importación de datos mediante mezcla o remplazo de nodos. Debe además proveer mecanismos de automatización de cambios diferenciales para jerarquías existentes. Debe proveer de servicios Web que permitan acceder a la información de los datos maestros que se dispongan y facilitar así la integración con otros componentes. Debe incorporar mecanismos que permitan soportar los procesos de cambio de las jerarquías y dominios, mediante el registro de datos y metadatos para las estructuras definidas, el análisis de las relaciones existentes entre las estructuras almacenadas y, en base a esta información, permitir la administración de la liberación de nuevas versiones. Debe poder integrarse a los componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación y control de acceso para autorización de granularidad gruesa a sus contenidos. Debe proveer mecanismos de autorización de granularidad fina que puedan ser aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Modelo Conceptual del SIIF2 01/04/ /203

179 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 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íticos 61. Su uso no se restringe a los componentes desarrollados, ya que varios componentes de middleware de la plataforma, como por ejemplo los repositorios de credenciales, requieren de un motor de bases de datos para poder trabajar. REQ 8-8 Motor de Bases de Datos Relacionales Debido a que la CGN ya tiene un motor de bases datos relacionales y lo utiliza en varios de sus sistemas actuales, no se recomienda un reemplazo, sino una actualización del existente a su versión más reciente. La base de datos Oracle actualmente en uso en la CGN, permite satisfacer todos los requerimientos que se mencionan a continuación. Sin embargo, se 61 Del levantamiento realizado para la plataforma del SIIF2, no se identificaron necesidades que justifiquen la utilización de otras tecnologías para la construcción de bases de datos, como por ejemplo los motores multidimensionales o los motores para el almacenamiento de objetos. Todas las necesidades detectadas pueden ser cubiertas con sólo tecnología de bases de datos relacionales. Modelo Conceptual del SIIF2 01/04/ /203

180 recomienda implementar el motor con las opciones para replicación de datos, para utilizarlos por ejemplo para la construcción de repositorios de datos operacionales, que permiten hacer más eficientes los mecanismos de generación de reportes operacionales. Además, se recomienda implementar la base de datos con mecanismos de particionamiento, y diseñar los esquemas para que los aprovechen, con el fin de mejorar el desempeño de los módulos transaccionales. Debe proveer de mecanismos de seguridad de acceso. Debe proveer de mecanismos de protección ante desastres mediante la descarga de las operaciones de uso intensivo de recursos a una sola base de datos (stand-byfísica). Debe proveer mecanismos de recuperar versiones anteriores de los datos. Debe soportar la utilización de cintas de alto rendimiento para copias de seguridad de las base de datos. Debe poder trabajar con aplicaciones que corran sobre clústeres, permitiendo que múltiples nodos establezcan múltiples conexiones. Debe permitir soportar la creación de bases de datos para procesamiento analítico en línea (OLAP). Debe permitir la ejecución de procedimientos almacenados, funciones y triggers. Debe proveer mecanismos de caché inteligente basados en la frecuencia de uso de los datos. Debe proveer mecanismos de auditoría que no generen distorsiones en la operación de la base de datos. Debe proveer herramientas u opciones que permitan el cifrado de los datos. Debe proveer herramientas u opciones que permitan la replicación automática y en línea de los contenidos de una base de datos. Debe proveer mecanismos para la definición de particiones lógicas de esquemas. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) 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) Repositorio de Contenidos Ilustración 8-10 Motor de Gestión de Contenidos El Repositorio de Contenidos es un componente especializado en el trabajo con contenido no estructurado (en contraste con el Motor de Bases de Datos presentado, que se especializa Modelo Conceptual del SIIF2 01/04/ /203

181 en el manejo de información estructurada). Estos contenidos pueden ser archivos en diferentes formatos, como por ejemplo PDF, documentos Word, texto plano, etc. Pueden ser también archivos multimedia, como videos e imágenes. REQ 8-9 Repositorio de Contenidos Debe proveer funcionalidades para el almacenado y recuperación de contenidos anexos durante todo el ciclo de vida de los documentos que se gestionen en el sistema. Debe proveer funcionalidades para que los usuarios del puedan sistema puedan acceder a los contenidos almacenados de acuerdo a sus privilegios y roles. Debe poder trabajar con más de una almacén de información, como por ejemplo bases de datos y sistemas de archivos. Debe proveer métodos de acceso acorde con los mecanismos de usabilidad del sistema. Debe proveer servicios Web para el acceso a sus contenidos. Debe proveer marcos de aplicación para la organización de documentos que permitan realizar agrupaciones lógicas, configurar almacenamientos jerárquicos. Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación y control de acceso para autorización de granularidad gruesa a sus contenidos. Debe proveer mecanismos de autorización de granularidad fina que puedan ser aprovisionados por el Motor de Aprovisionamiento escogido para la plataforma. Debe soportar autenticación mediante los mecanismos de SSO que se elijan para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster). Debe proveer componentes que permitan el acceso a sus contenidos y a sus funcionalidades por el portal Web 2.0 seleccionado para la plataforma Motor de Extracción Transformación y Carga Ilustración 8-11 Motor de Extracción, Transformación y Carga Este motor de Extracción, Transformación y Carga (más conocido como motor ETL, por el inglés Extraction Transformation Load), brinda el soporte para preparar y mover la información de negocio entre los distintos repositorios de datos del sistema. Provee capacidades para: Modelo Conceptual del SIIF2 01/04/ /203

182 conectarse a múltiples fuentes de información, mediante distintos estándares y adaptadores. describir y configurar las transformaciones necesarias para poder cargar la información a los repositorios de destino. gestionar la ejecución del proceso de carga, e identificar los problemas que pudieran surgir, lo que otorga mayor control y fiabilidad a estas actividades. Esta pieza provee uno de los mecanismos que se espera se utilizarán para la obtención de la información que necesitan los distintos componentes del SIIF2 (el otro son servicios Web). En la propuesta para el sistema, el uso de ETL se limita a actividades de procesamiento por lotes de grandes volúmenes, como por ejemplo la replicación de los datos operacionales a repositorios de generación de reportes, o hacia el almacén de datos de la CGN. En este contexto, el motor ETL es un componente central para el traspaso y limpieza de la información contenida en bases de datos de procesamiento transaccional a las bases de datos de procesamiento analítico que soportarán los reportes de gestión y el análisis de inteligencia de negocios. REQ 8-10 Motor de Extracción, Transformación y Carga Debe proveer un entorno de diseño de cargas que no requiera conocimientos avanzados de programación. Debe proveer mecanismos de simulación y gestión del código generado. Debe proveer mecanismos de conexión para múltiples tipos de fuentes, que trabajen con contenido de distintas marcas de motores de bases de datos, sistemas de archivos, archivos planos, sistemas ERP, sistemas CRM, sistemas B2B, archivos XML, repositorios LDAP, fuentes JDBC u ODBC, etc. Debe proveer mecanismos de lectura asincrónica de la información. Debe proveer funcionalidades para soportar la gestión y la administración unificada del proceso ETL, permitiendo a través de su consola importar y exportar a repositorios de datos, la administración en tiempo real de las operaciones, la monitorización de las sesiones ETL, el diagnóstico de errores, el diseño de artefactos y la generación de informes. Debe proveer un soporte mejorado para procesamiento analítico en línea, y una API que puede ser utilizada directamente en aplicaciones. Modelo Conceptual del SIIF2 01/04/ /203

183 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 Bus de Servicios Ilustración 8-12 Bus de Servicios El Bus de Servicios es un componente que brinda una serie de mecanismos de soporte para la implementación de la interacción y la comunicación basada en el intercambio de mensajes entre los distintos servicios Web, tanto internos como externos al sistema. Sus capacidades de transformación de datos, formatos, protocolos, unido a sus capacidades de control de tráfico, enrutamiento y enriquecimiento de la información, lo hacen un componente de gran valor técnico para la adecuada implementación de una arquitectura orientada a servicios, que no sólo le permita a la CGN construir sistemas altamente flexibles y de bajos niveles de acoplamiento, sino también capaces de conectarse e interoperar con sistemas de otras instituciones, facilitando la implementación de los requerimientos de interoperabilidad institucional y transversal. Durante el levantamiento de información realizado para el sistema, se detectaron múltiples necesidades de integración con sistemas externos, las que llevarán a la construcción de múltiples proveedores de servicios Web, así como también de mecanismos para el consumo Modelo Conceptual del SIIF2 01/04/ /203

184 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 bus 62. La propuesta también asume que, en el caso de la comunicación con sistemas externos al SIIF2, el bus de la CGN se comunicará con la Plataforma de Servicios Electrónicos del Estado provista por la AGESIC. Los adaptadores que brinda el bus de servicios brindan la oportunidad de conectar fuentes de información en sistemas que probablemente no puedan reconstruidos ni modificados para trabajar en base al consumo y provisión de servicios. REQ 8-11 Bus de Servicios Debe soportar todos los protocolos estándar de definición de servicios Web definidos en el WS-I Basic Profile en todas sus versiones. Debe poder integrarse con el Motor de Gestión de Políticas de Servicio para el trabajo con protocolos de servicios más avanzados, como por ejemplo WS-Trust, WS-Security y WS-Addressing. Debe brindar mecanismos de publicación y subscripción para múltiples orígenes y destinos de información. Debe brindar mecanismos de enrutamiento de mensajes, que permitan determinar el servicio de destino de un mensaje entrante, y permitan gestionar los cambios que puedan ocurrir en un servicio publicado en el Bus. Debe permitir modalidades síncronas y asíncronas de despacho. Debe proveer mecanismos de transformación de mensajes, que permitan adaptar los mensajes generados en el origen para que cumplan con una o más características en el destino. Debe proveer mecanismos de aprovisionamiento de servicios, que permitan gestionar el portafolio de servicios Web de CGN, sus versiones y los cambios que estos pudieran implicar. Debe brindar mecanismos de apoyo para la gestión de los acuerdos de niveles de servicio establecidos para el SIIF2. Debe brindar herramientas que permitan la monitorización del rendimiento de un servicio Web particular y permitir implementar compromisos para su comportamiento y desempeño. Debe proveer mecanismos de soporte y adaptación de protocolos de transporte de mensajes. Debe proveer mecanismos que permitan un rápido despliegue de los servicios Web definidos para la integración de la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster). 62 Aunque técnicamente es posible hacer una comunicación directa entre dos servicios Web y no utilizar un bus, esto inhabilitará posibilidades como la virtualización de puntos de acceso, la capacidad de incorporar aspectos de monitorización para el control de SLAs, etc. Modelo Conceptual del SIIF2 01/04/ /203

185 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 seguridad 63, soportar mecanismos de comunicación robusta, definir políticas para la gestión de niveles de servicio, etc. Junto con tener la capacidad de actuar como punto de control de las políticas de seguridad (PEP por el inglés Policy Enforcement Point), este componente permite definirlas, gestionarlas, y almacenarlas centralizadamente. Permite además aplicar una misma política a uno o más servicios, por separado o como grupo, lo que contribuye importantemente al adecuado gobierno de los activos SOA en la organización. El Motor de Gestión de Políticas de Servicios Web permite incorporar, a nivel de los mensajes que fluyen en un sistema orientado a servicios, consideraciones de autenticación, autorización, confidencialidad, integridad y no repudio. La plataforma utiliza a este componente como un refuerzo a los mecanismos de seguridad, orientado específicamente para el trabajo con servicios Web. Trabaja directamente con el Bus de Servicios, dotándolo de capacidad para el trabajo con protocolos avanzados, y conectándose con los repositorios de credenciales y los mecanismos de identificación y control de acceso. La incorporación de este componente permitirá complementar el conjunto de protocolos para servicios Web soportados por la plataforma del SIIF2 y así asegurar, por ejemplo, que se pueda trabajar fluidamente a través de la PGE. REQ 8-12 Motor de Gestión de Políticas de Servicios Web Debe brindar mecanismos para la administración de políticas de servicios Web, habilitando su almacenamiento y mantención de acuerdo a los estándares soportados. Debe proveer de mecanismos que permitan monitorizar la ejecución de las políticas definidas y asociadas a los servicios. Debe permitir el trabajo con los siguientes estándares: Todos los definidos por el WS-I Basic Profile, en todas las versiones del perfil. 63 La seguridad en servicios Web tiene requerimientos extra que no son satisfechos por los otros componentes de seguridad mencionados previamente para la plataforma. Modelo Conceptual del SIIF2 01/04/ /203

186 Todos los definidos por el WS-IBasic Security Profile, en todas las versiones del perfil. Todos los que se requieran para tener una compatibilidad completa con la PGE. Debe poder integrarse a los componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación (incluyendo SSO) y control de acceso para autorización de granularidad gruesa y fina de los servicios Web. Alternativamente, de no poder integrarse, debe proveer de mecanismos que cumplan todos los requerimientos de seguridad del sistema. Debe poder ser aprovisionado por el Motor de Aprovisionamiento escogido para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster). 8.5 Capa de Seguridad Esta sección describe los componentes de la plataforma que permiten otorgar al SIIF2 los niveles adecuados de identificación, aseguramiento, no repudio e integridad Mecanismo de Identificación Ilustración 8-14 Mecanismo de Identificación El Mecanismo de Identificación se encarga solicitar y validar las credenciales que presenten los sistemas externos o usuarios que deseen acceder al sistema, con el fin de establecer si son auténticas. Trabajando con otros componentes de la plataforma, como por ejemplo los repositorios de credenciales y los mecanismos de autorización, permite implementar mecanismos para la acreditación de las entidades de quienes intentan acceder al sistema, información que puede ser utilizada posteriormente para auditoría y control de acceso. Esta pieza es imprescindible para la implementación de niveles de seguridad acordes a una aplicación como el SIIF2. En la plataforma constituye el punto central para la acreditación de la identidad previa al acceso a los recursos del sistema. Se asume que estará conectado directamente al primer punto de acceso de la aplicación, ya sea este un dispositivo especializado (como por ejemplo un balanceador de hardware con Modelo Conceptual del SIIF2 01/04/ /203

187 capacidad de proxy reverso), o un componente más genérico (como por ejemplo un servidor Web con módulos adicionados para este fin). REQ 8-13 Mecanismo de Identificación Debe soportar mecanismos de autenticación por usuario y contraseña. Debe soportar mecanismos de autenticación en base a certificados X.509. Debe soportar mecanismos de autenticación en base a una infraestructura de clave pública que pueda ser validada en línea contra una Entidad Certificadora acreditada por el Gobierno. Debe poder integrarse con los demás mecanismos de seguridad escogidos para la plataforma. Debe poder obtener las credenciales para el control de acceso de los directorios de credenciales seleccionados para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster) Mecanismo de Single Sign on Ilustración 8-15 Mecanismo de Single Sign-on El mecanismo de Single Sign on amplía las capacidades del mecanismo de identificación, permitiendo compartir de manera transparente la identidad de un usuario entre diferentes componentes del sistema, e incluso entre distintos sistemas. Debido a que las diferentes piezas del sistema se construyen en función de diferentes piezas de middleware (o de software de aplicación), y estas pueden manejar la autenticación de sus usuarios de manera diferente, en ausencia de este componente probablemente el usuario tenga que ingresar múltiples veces su identificación y contraseña, lo que se transformará rápidamente en una molestia. La plataforma del SIIF2 incorpora a esta pieza para mejorar tanto la seguridad como la usabilidad del sistema, y es la encargada de lograr que a cada usuario se le pregunten sus credenciales una única vez, haciéndose cargo de cualquiera necesidad de reingreso de esta información, logrando que el hecho de que hayan múltiples sistemas conectados, con Modelo Conceptual del SIIF2 01/04/ /203

188 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 Mecanismo de Autorización Ilustración 8-16 Mecanismo de Autorización El Mecanismo de Autorización se encarga de resguardar la utilización de los recursos del sistema. Trabajando con otros componentes de la plataforma, como por ejemplo los repositorios de credenciales y el mecanismo de identificación, permite implementar un adecuado control de acceso a los recursos del sistema, permitiendo la definición y control de políticas de acceso, que habiliten su utilización a los usuarios que cuenten con los privilegios adecuados, y restrinjan su utilización a quienes no los tengan. Incorpora además mecanismos de auditoría que permitirán hacer seguimiento de actividades sospechosas, intentos de acceso no autorizado y análisis forense tras ataques de seguridad. Al igual que el mecanismo de identificación, esta pieza es imprescindible para la implementación de niveles de seguridad acordes a una aplicación como el SIIF2. En la plataforma constituye el punto central para el control de acceso de cada uno de los recursos. Se asume que estará conectado directamente al primer punto de acceso de la aplicación, ya sea este un dispositivo especializado (como por ejemplo un balanceador de hardware con capacidad de proxy reverso), o un componente más genérico (como por ejemplo un servidor Web con módulos adicionados para este fin). Sin embargo, por motivos de desempeño, se sugiere que su utilización se restrinja al control de acceso de granularidad gruesa, dejando el control de acceso de granularidad fina a cada uno de los componentes de la plataforma que permitan esta funcionalidad. Modelo Conceptual del SIIF2 01/04/ /203

189 REQ 8-15 Mecanismo de Autorización Debe proveer mecanismos que permitan la gestión centralizada de las políticas de acceso Debe proveer mecanismos que permitan la efectiva aplicación y control de las políticas de acceso. Debe permitir la definición de zonas de seguridad para Single Sign on. Debe proveer de un modelo de políticas nativas y además políticas compartidas entre componentes. Debe proveer de mecanismos que permitan probar las políticas antes de ponerlas en producción Debe proveer de un mecanismo de auditoría para cada uno de los componentes del sistema que se requiera. Debe proveer mecanismos que permitan la definición de métricas e indicadores para la monitorización del desempeño del mecanismo de control de acceso. Debe soporta la integración con servicios de seguridad vía tokens. Debe proveer de una API para los desarrolladores de componentes de seguridad y que permita su acceso programático por los componentes que se desarrollen para el SIIF2. Debe poder obtener las credenciales para el control de acceso de los directorios de credenciales seleccionados para la plataforma. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster) Directorios de Credenciales Ilustración 8-17 Directorios de Credenciales Un Directorio de Credenciales es un repositorio especializado para el almacenamiento de credenciales de seguridad tanto de identificación, como de control de acceso de los usuarios y componentes del sistema, y que maneja estructuras optimizadas para su fácil manejo y administración. Debido a que los datos contenidos en un directorio de credenciales normalmente se leen mucho más de lo que se escriben, los directorios no implementan normalmente los complicados esquemas para transacciones de los motores de bases de Modelo Conceptual del SIIF2 01/04/ /203

190 datos 64. Las actualizaciones en un directorio también son usualmente cambios sencillos y no de grandes volúmenes de datos. La plataforma del SIIF2 considera a esta pieza como el elemento principal de almacenamiento de credenciales de seguridad. Aunque todas las credenciales de identificación pueden ser almacenadas en un mismo esquema, no siempre esto es posible para las credenciales de autorización, pues estas pueden ser dependientes del producto que las utilice. Es por esto que se anticipa que habrá varias instancias de este tipo de componente en producción. Por lo que sí se debe velar, es que el repositorio de credenciales de identificación sea único, para evitar tener que incorporar innecesariamente middleware para la virtualización de directorios, y de complicar innecesariamente los mecanismos de aprovisionamiento. REQ 8-16 Directorios de Credenciales Debe proveer soporte para almacenamiento en múltiples contextos de seguridad. Debe proveer soporte para la administración centralizada de recursos para el sistema. Debe proveer soporte para su integración con otros directorios. Debe proveer mecanismos para replicación de datos a múltiples directorios de servicios. Debe soportar los estándares LDAP v3, Microsoft ADS o el que se requiera para que todos los componentes de la plataforma puedan acceder de manera estándar. Debe permitir que las credenciales con las que trabaja sean abastecidas por el Motor de Aprovisionamiento escogido para la plataforma. Capacidad para la seguridad de datos en transporte, almacenamiento y respaldo. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Debe permitir su despliegue en topologías de alta disponibilidad (en modalidad activoactivo) y con capacidad de escalamiento horizontal (en base a topologías de clúster) Mecanismo de Aprovisionamiento de Usuarios Ilustración 8-18 Mecanismo de Aprovisionamiento de Usuarios 64 Técnicamente es válido, sin embargo, usar un motor de bases de datos relacional como back end para un directorio de credenciales. Modelo Conceptual del SIIF2 01/04/ /203

191 El Mecanismo de Aprovisionamiento de Usuarios entrega soporte para la administración segura de los recursos del sistema, tales como las cuentas de usuarios y sus privilegios de acceso. Apoya en cada etapa de la administración del ciclo de vida de las identidades y los roles en la aplicación, permitiendo su correcta asignación a los usuarios del sistema, y la habilitación de esta información a los componentes que la requieran. La utilización de este componente permite tanto la centralización de la administración de los recursos del sistema (que el equipo de la CGN lleve la administración de todas las credenciales), como la segregación controlada de las responsabilidades de administración a otros instituciones (que la CGN pueda definir administradores pertenecientes a las incisos usuarios del SIIF2, y sean estos quienes lleven la administración de sus respectivos usuarios), fomentando fuertemente la eficiencia en la operación productiva del sistema. Es importante destacar que el soporte de la administración descentralizada, impone el requerimiento de que el Motor de Aprovisionamiento cuente con un Mecanismo de Autorización Descentralizada, y que este pueda ser integrado al portal de la plataforma o, como mínimo, presentado vía una aplicación Web. La plataforma considera a esta pieza como el ambiente donde se efectuaran todas las configuraciones que necesite el sistema, en lo referente a la asignación de los recursos, usuarios y roles. A través de una interfaz web de administración, permitirá de forma rápida el bloqueo o autorización de funciones a un usuario o un grupo de éstos. También permitirá la integración con diferentes fuentes de credenciales de seguridad (como por ejemplo servidores LDAP o Active Directory), lo que facilitará su integración y le otorgará flexibilidad mayor en cuanto al aprovisionamiento de usuarios. Tras el levantamiento realizado, se debe considerar como deseable, más no requerido que este componente pueda ser desplegado en una topología multicapas, y en clúster, permitiendo anticiparse a potenciales problemas de rendimiento y escalabilidad. REQ 8-17 Mecanismo de Aprovisionamiento de Usuarios Debe proveer soporte para todo el ciclo de vida de la identidad y los roles del sistema. Debe proveer soporte para todo el ciclo de vida de las políticas de acceso de la aplicación. Debe proveer un mecanismo de autogestión de credenciales, o tener la capacidad de integrarse a uno. Debe proveer mecanismos que permitan la segregación de responsabilidades de administración de usuarios y accesos. La interfaz de este mecanismo debe poder ser desplegada o invocada desde el portal Web del sistema. Debe proveer soporte para servicios de reconciliación ante conflictos en la gestión de sus recursos. Debe proveer soporte para definiciones de seguridad orientadas servicios. Debe poder conectarse y aprovisionar los directorios de credenciales que se escojan para la plataforma. Debe poder integrarse a componentes de seguridad que se elijan para la plataforma, y de utilizarlos para delegar las actividades de identificación y control de acceso para autorización de granularidad gruesa a sus contenidos. Debe proveer mecanismos de autorización de granularidad fina. Debe proveer mecanismos que permitan la monitorización de comportamiento y salud mediante el monitor que se seleccione para la plataforma. Modelo Conceptual del SIIF2 01/04/ /203

192 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 Mecanismo de Autogestión de Credenciales Ilustración 8-19 Mecanismo de Autogestión de Credenciales El Mecanismo de Autogestión de Credenciales permite a los mismos usuarios modificar su información personal en el sistema, como por ejemplo sus datos de contacto, su contraseña, etc., mediante funcionalidades de fácil uso, y provistas de manera segura a través de la Internet. Este componente generalmente viene incluido como parte de otros productos de seguridad. La plataforma incluye esta pieza debido a la experiencia que se ha tenido en otros sistemas de gran escala similares al SIIF2, donde la administración de la información de los usuarios se vuelve una tarea de consumo intensivo de recursos humanos. La incorporación de esta pieza permitirá reducir la demanda sobre la mesa de ayuda que se implemente para el SIIF2, debido a que permitirá a los propios usuarios resolver solicitudes de cambio de claves y solicitudes por problemas de acceso, lo que se traducirá en una reducción importante y cuantificable de los costos asociados al soporte del sistema. REQ 8-18 Mecanismo de Autogestión de Credenciales Debe poder integrarse o estar integrado al mecanismo de aprovisionamiento de la plataforma. Debe incluir mecanismos que permitan el aprovisionamiento automático de los cambios que se introduzcan en función de este componente. Debe poder trabajar con los mecanismos de integración con los componentes de la suite, como por ejemplo, Single Sign-on, el Mecanismo de Autorización y los Directorios de Credenciales. Debe permitir su despliegue seguro en el portal Web 2.0, o como alternativa, este mecanismo debe ser una aplicación Web que pueda ser integrada con los mecanismos de seguridad y monitorización de la plataforma. Modelo Conceptual del SIIF2 01/04/ /203

193 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 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 sistema 65. También permite la gestión centralizada de su configuración, la supervisión de sus niveles de servicios y provee de operaciones de automatización para mejorar la eficiencia de sus operarios. Mediante mecanismos de ajuste inteligente de la configuración del middleware subyacente, permite mejorar el rendimiento y disponibilidad de las aplicaciones y servicios Web, reduciendo tiempos de inactividad de las infraestructura y reduciendo el costo de administración de la plataforma. La plataforma considera a esta pieza como un elemento clave para su correcta operación, debido a que el gran número de componentes que la conforman hace que la monitorización y administración sean notablemente complejas, lo que en ausencia de un componente como éste, elevan los riesgos de errores, y de detección tardía de malfuncionamientos e indisponibilidades. Todos los grandes proveedores de tecnologías de middleware ofrecen algún tipo de sistema de monitorización. Sin embargo, generalmente están optimizados para trabajar con middleware de un mismo proveedor, lo que hace inconveniente mezclar middleware de distintas marcas. 65 La plataforma sólo define este componente para la monitorización del middleware. Se asume que existirán mecanismos para la monitorización de la infraestructura de hardware, pero su definición esta fuera del alcance de este documento. Modelo Conceptual del SIIF2 01/04/ /203

194 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 Monitor de Uso del Sistema Ilustración 8-21 Monitor de Uso del Sistema Este componente recopila información acerca de la utilización y acceso a las distintas páginas del sistema, y permite analizar la información de la actividad generada en los servidores de la institución. Con esta pieza, es posible tener información clara acerca del comportamiento de los usuarios del sistema, lo que resulta extremadamente valioso en los períodos tempranos de salida a producción e implantación del sistema, ya que permite tener información oportuna de la tasa de adopción por parte de las instituciones usuarias. La incorporación de este componente en la plataforma del SIIF2 tiene razones políticas y técnicas. Las estadísticas que genera permite entregar a las autoridades información clara y precisa acerca de, por ejemplo, los lugares del país de donde se está accediendo al sistema, los momentos del día donde hay más utilización, y el número de usuarios por inciso o unidad ejecutora que se está soportando, etc. Este tipo de información comienza a ser de gran valor Modelo Conceptual del SIIF2 01/04/ /203

195 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 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 SIIF2 66. 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 Modelo Conceptual del SIIF2 01/04/ /203

196 variabilidad de capturar sin tener que entrar en los detalles específicos de la oferta de cada proveedor, este diagrama debe ser considerado sólo como un ejemplo, y se recomienda revisarlo una vez implementada la línea base arquitectónica para el sistema. Ilustración 8-22 Modelo de ejemplo de topología de despliegue de la Plataforma de Middleware del SIIF2 El diagrama permite identificar algunas situaciones que con un alto grado de probabilidad se manifiesten, independientemente del proveedor de tecnología, y que en consecuencia deben ser consideradas antes de la adquisición de los distintos componentes: Gran cantidad de piezas de middleware, como por ejemplo el portal, el repositorio de contenidos, etc., requieren de una base de datos de infraestructura para operar. Debido a que algunos de ellos se instalan en segmentos de red más inseguros,, se deberá decidir si se instala un repositorio de propósito específico para las necesidades del middleware, o se harán excepciones a las políticas de acceso (a nivel de cortafuegos, por ejemplo), para que un middleware que está en un segmento de red más expuesto pueda acceder a los repositorios de bases de datos. La decisión incidirá directamente en los costos de licenciamiento de bases de datos. Se recomienda considerar una instalación compartida de estas bases de datos de infraestructura, dentro de la misma instancia que el sistema transaccional, con el fin Modelo Conceptual del SIIF2 01/04/ /203