Gobierno de España. Ministerio de Hacienda y Función Pública. Abre nueva ventana
Administración Presupuestaria

Preguntas frecuentes sobre la API

Preguntas frecuentes sobre los servicios electrónicos de intercambio de información relativa al Plan de Recuperación, Transformación y Resiliencia.

Información Preliminar

Disponibilidad de la API

Conexión y uso del servicio

Preguntas generales sobre la API

Información preliminar

¿Qué es CoFFEE y CoFFEE-MRR?

CoFFEE (Plataforma Común de Fondos Europeos) es la plataforma informática común para la gestión de fondos europeos. Está orientada a integrar los diversos módulos que dan soporte a la gestión de los fondos europeos competencia de la Secretaría General de Fondos Europeos (SGFE) en el marco financiero plurianual 2021-2027 (MFP 21-27). Es la evolución de los sistemas de información que dan soporte a la gestión del Fondo Europeo de Desarrollo Regional (FEDER) en los marcos financieros previos al 2021-2027, pero ha sido concebida para albergar el soporte a otros fondos y/o mecanismos.
CoFFEE-MRR es un módulo de CoFFEE que aprovecha la tecnología, los procesos transversales, los mecanismos de incorporación de la información, etc. de la plataforma, y que incorpora la funcionalidad necesaria para la planificación, la gestión y el seguimiento de las iniciativas asociadas al Mecanismo de Recuperación y Resiliencia, y en concreto al Plan de Recuperación, Transformación y Resiliencia (PRTR).

¿Cómo solicito el acceso a CoFFEE/CoFFEE-MRR?

El procedimiento para solicitar el acceso a los sistemas de la Administración Presupuestaria está descrito en la sección “Control de Accesos” del Portal de Administración Presupuestaria.

Disponibilidad de la API

¿Para qué sirve la API de CoFFEE?

Los servicios electrónicos se ponen en funcionamiento para facilitar a las entidades ejecutoras de las iniciativas dar cumplimiento a lo establecido en la normativa que regula el Plan, y en particular en la Orden HFP/1030/2021, de 29 de septiembre, por la que se configura el sistema de gestión del Plan de Recuperación, Transformación y Resiliencia (Orden de Gestión), y la Orden HFP/1031/2021, de 29 de septiembre, por la que se establece el procedimiento y formato de la información a proporcionar por las Entidades del Sector Público Estatal, Autonómico y Local para el seguimiento del cumplimiento de hitos y objetivos y de ejecución presupuestaria y contable de las medidas de los componentes del Plan de Recuperación, Transformación y Resiliencia (Orden de Intercambio), y está dirigida a las entidades que dispongan de capacidad y recursos para conectar sus propios sistemas de gestión con CoFFEE para proporcionar la información requerida.
Las entidades que no dispusieran de esa capacidad pueden incorporar la información de forma interactiva, para lo cual previamente deben solicitar el acceso.

¿Está la API REST ya disponible para conectarme?

La disponibilidad de la API se muestra en el espacio de “Formatos de intercambio” de CoFFEE en el Catálogo de Sistemas de Información.

¿Cuál es la última versión disponible?

Las diferentes versiones y su estado se encuentran disponibles en el espacio de“Formatos de intercambio” de CoFFEE en el Catálogo de Sistemas de Información.

¿Hay mecanismos alternativos al API para proporcionar información a la plataforma?

Sí, dependiendo del tipo de información a reportar, el sistema facilitará mecanismos para que la información se proporcione de forma interactiva por los usuarios que se conecten a él, y también mediante la incorporación (interactiva) de un archivo con todos los datos a tratar.
Naturalmente, CoFFEE realizará las mismas validaciones cuando se proporcione la información de forma masiva a través de la carga de un fichero.

¿Cuál es el formato de codificación del fichero JSON que se carga en CoFFEE?

La codificación es UTF-8.

Conexión y uso del servicio

¿Cómo solicito el acceso a la API y qué procedimiento desencadena?

Se puede solicitar el acceso a la API a través de la opción “Solicitar este servicio web”  del servicio web “CoFFEE-MRR Servicio de Intercambio” en el Catálogo de Servicios Web del Portal de Administración Presupuestaria, a partir del momento en que se anuncie que el servicio está disponible.
El procedimiento se puede resumir en estos puntos:
1.     El responsable del sistema que va a integrarse con CoFFEE solicita el acceso; durante el proceso se concreta el certificado electrónico que se usará para la comunicación segura.
2.     Un responsable funcional de CoFFEE en la Secretaría General de Fondos Europeos (SGFE), tras verificar la legitimidad del solicitante, aprueba la autorización.
3.     Los servicios técnicos de la Oficina de Informática Presupuestaria asignan un código de “usuario de servicio”. En colaboración con la SGFE, se asigna dentro de CoFFEE un perfil de acceso para dicho usuario de servicio, lo que determina el ámbito de información sobre la que podrá trabajar a través del intercambio electrónico.
4.     Se proporciona al contacto técnico del sistema que se quiere integrar con CoFFEE el código del usuario del servicio (denominado “idUsuario”), además de un código identificativo del propio servicio (“idAplicacion”), que deberá conservar para su uso en las invocaciones al servicio.
 

¿Cómo se logra la seguridad en el acceso?

Los servicios Web cliente se autenticarán mediante HTTPS/TLS (1.2 o superior). En concreto, se utilizará un certificado de sello de Administración, órgano o entidad de derecho público para actuación administrativa automatizada, o un certificado de sello electrónico cualificado derivado del Reglamento eIDAS, emitido en cualquier caso por alguno de los prestadores de servicios de certificación reconocidos por el servicio @Firma.

Durante el proceso organizativo de autorización de acceso se acuerda entre la Oficina de Informática Presupuestaria y el contacto técnico del organismo interesado el certificado que utilizará el extremo cliente del servicio

¿Cómo es una interacción típica con el servicio (una llamada a un método del API)?

Una vez ha finalizado el proceso de autorización del acceso, el sistema cliente está en condiciones de hacer uso del servicio. Para ello, toda interacción se llevará a cabo bajo una comunicación segura (TLS) utilizando el certificado de sello preacordado.
Cada llamada al servicio REST incluirá en la petición HTTP, además de los parámetros indicados en la documentación del propio servicio, dos parámetros adicionales (idUsuario e idAplicacion), que contendrán los valores que se facilitaron durante el proceso de configuración del acceso.

¿Pueden varias organizaciones utilizar el mismo certificado de sello para interactuar con el API?

Aunque no es habitual, esa posibilidad se habilita si se tramitan dos solicitudes de acceso, una por cada una de las organizaciones, y se configura el mismo certificado en ambas. En el proceso de autorización se creará y asignará un usuario de servicio (idUsuario) distinto para cada una de ellas, y se configurarán en CoFFEE los correspondientes perfiles que actúen en cada uno de los ámbitos.
Dado que cada petición al servicio incluye entre sus parámetros el código de usuario de servicio (idUsuario), CoFFEE podrá determinar el origen y podrá actuar en consecuencia, aplicando el perfil de seguridad correspondiente..
No obstante lo anterior, hay que tener en cuenta que si una de las organizaciones utilizara el idUsuario asignado a la otra, no existiría ningún mecanismo para identificar la suplantación, por lo que esta posibilidad se llevará a cabo a riesgo de las organizaciones cliente.

¿Hay límites establecidos para el uso del servicio?

Se han definido los siguientes límites:
  • Tamaño máximo de petición: 100MB.
  • Tamaño máximo de documento: 60MB.
  • Límite máximo de elementos en una colección: 100 elementos.
  • Número máximo de peticiones por segundo: 5 peticiones.

Preguntas generales sobre la API

¿Cuál es el formato de las fechas?

Se sigue la especificación OpenApi 3.0 que hace referencia a la definición RFC 3339, sección 5.6, por ejemplo2022-07-21.
Es importante destacar que algunas fechas solicitadas se deben especificar en trimestres.

¿Son todos los campos de la API obligatorios?

No, sólo son obligatorios aquellos campos que están marcados como tales (con un asterisco en rojo).

¿Puedo enviar múltiples declaraciones de ejecución contable en la misma llamada POST?

Sí, cada llamada puede contener varias declaraciones, como viene especificado en el tipo de datos “DeclaracionEjecucionFinanciera” del esquema.

En relación a las declaraciones de progreso de indicadores: el campo “fecha” (la fecha de referencia del progreso), ¿tiene que ser la fecha actual?

La fecha de referencia del progreso de un indicador es aquella en que se considera alcanzado el valor del indicador que se actualiza, y por tanto tiene que ser anterior o igual a la fecha actual, es decir, no se permiten fechas futuras.

¿Por qué en el caso de indicadores cuantitativos se informa la “variación” y en el caso de indicadores cualitativos se informa el “valor”?

Los indicadores son medidores del progreso y pueden ser cuantitativos (su valor es un dato numérico dentro de un rango) o cualitativos (pueden adoptar un valor de entre un conjunto cerrado de opciones)
  • En el caso de indicadores cuantitativos se debe informar la variación producida desde el valor anterior del indicador. Por ejemplo, si el indicador es “Número de vehículos eléctricos matriculados” y se ha pasado de 1000 a 3000 vehículos, se declarará “2000”.
  • En el caso de indicadores cualitativos se debe informar el nuevo valor que ha tomado de entre los posibles (inicio, en curso y finalizado).
El motivo por el que para los indicadores cuantitativos se proporciona la variación es que el sistema permite incorporar una justificación (textual y, opcionalmente, acompañada de archivos). Se entiende que en el momento de la declaración se está justificando el valor incrementado (o decrementado) de un indicador, y no el valor final alcanzado (en el ejemplo anterior, se justifican los 2000 vehículos que se han matriculado).
En el caso de los indicadores cualitativos, se produce un cambio en su estado, y por tanto se declara el estado alcanzado.

En relación a las declaraciones de ejecución contable: el campo “fechaContable” (La fecha de referencia del progreso), ¿puede ser una fecha posterior a la actual?

La fecha contable tiene que ser anterior o igual a la fecha actual, es decir, no se permiten fechas futuras.

¿Qué es la referencia de un instrumento jurídico?

En las declaraciones de ejecución contable se especifica una referencia del instrumento jurídico bajo el que se hace la declaración. El caso típico es un contrato o una subvención, pero todos los instrumentos previstos deben poder ser identificados.
La referencia es, por tanto, un código que identifica al instrumento jurídico concreto en el ámbito de la Actuación para la que se registra la ejecución.
Habitualmente la referencia coincide con el propio código del instrumento que establece la persona que lo da de alta en CoFFEE (bien sea por pantalla, carga masiva, ...).
Por ejemplo, en el caso de una subvención dada de alta en CoFFEE con el código BDNS "576282", la referencia es exactamente ese mismo código. O un contrato (no PLACSP) que se ha dado de alta en CoFFEE con el código de contrato "2023OIP45544", tendrá ese mismo código como referencia.
Sin embargo, hay un caso más complejo que es el de los contratos PLACSP, y que se trata específicamente en la siguiente cuestión.

¿Cómo se diferencia un contrato que está dado de alta en la Plataforma de Contratación del Sector Público (PLACSP) de uno que no lo está?

Los contratos PLACSP se identifican por tres códigos: código de órgano de contratación, código de licitación, y código de contrato (ver siguiente cuestión para una explicación detallada). Los contratos no PLACSP se identifican mediante un único código.
En las entradas de alta de contratos en CoFFEE, los dos tipos de contrato se identifican de forma separada.
Dado que las referencias de instrumentos jurídicos se hacen a través de un único campo, en el caso de contratos PLACSP (que, como se ha indicado, tienen tres códigos) la referencia corresponde a la concatenación de los tres valores utilizando el separador “~” entre ellos, incluso aunque los campos estuvieran vacíos.

¿Qué son los códigos órgano de contratación, de licitación y de contrato de PLACSP?

El código del órgano de contratación es un identificador que usa la Plataforma de Contratación del Sector Público (PLACSP) asociado a cada uno de los órganos (en PLACSP se denomina “ID Plataforma”). Cada órgano de contratación puede consultar el suyo propio en la pantalla de administrador del perfil “administrador del órgano de contratación” de PLACSP.
PLACSP1.PNG
Además, la Dirección General de Patrimonio del Estado publica periódicamente la relación de códigos en una hoja Excel que van actualizando.
En el caso de PLACSP y para cada órgano de contratación, los códigos de licitación y de contrato son los que identifican de forma única un contrato que se incorpora a la Plataforma de Contratos del Sector Público:
El código de licitación se corresponde con el Número de Expediente en la PLACSP, que es el número de expediente que proporciona cada órgano de contratación.
El código de contrato corresponde con el Contrato de la PLACSP. Es también un valor que determina el órgano de contratación. Corresponde a cada contrato dentro del expediente.
En cualquier caso, ambos son valores que proporciona el gestor a la PLACSP. Ambos se pueden ver en la siguiente imagen.
PLACSP2.PNG

¿Cuándo se cumplimenta el campo “Otras Fuentes de financiación”?

La información sobre otras fuentes de información se cumplimentará cuando la actuación a la que corresponde la operación esté financiada por alguna otra fuente, de manera adicional a la financiación con cargo al Mecanismo de Recuperación y Resiliencia. En este caso, se identificará el mecanismo o fondo que ha financiado la operación.

En el caso de envío de información contable, ¿tienen que estar dados de alta en CoFFEE previamente a la remisión de información los instrumentos jurídicos (contratos, subvenciones...) que se incluyan?

Sí, es necesario que los instrumentos jurídicos estén dados de alta en CoFFEE previamente a la remisión de la información contable. La API proporciona los servicios necesarios.

En el caso de envío de información contable, ¿tienen que estar dados de alta en CoFFEE previamente a la remisión de información los terceros (beneficiarios, contratistas, etc.) que se incluyan?

Sí, es necesario que los terceros estén dados de alta en CoFFEE previamente a la remisión de la información contable. La API proporciona los servicios necesarios.

En el caso de fases contables “barradas” (A/, D/, O/, AD/, ADO/, PR/, RE/), ¿los importes se deben reflejar en positivo o en negativo?

Los importes en documentos barrados son siempre positivos; la barra ya indica que los importes se tratarán contablemente en negativo.

Una vez enviada la información de ejecución contable o de progreso de indicadores: ¿Recibiré algún acuse de recibo?

Sí, el sistema proporcionará un acuse de recibo electrónico que permita la trazabilidad de las operaciones.

Cambios destacados de v1.3.1 a v1.5

Se listan los cambios destacados según el tipo de datos:
  • Todos los tipos:
    • codigoIniciativa es ahora codigoActuacion
  • Medida:
    • fechaInicio su valor es un trimestre
    • fechaFin su valor es un trimestre
  • Contrato:
    • contratoPLACSP es ahora codigoInstrumento, codigoLicitacion y codigoOrgano
    • contratoNoPLACSP es ahora codigoInstrumento
  • Subvencion:
    • convocatoriaBDNS es ahora codigoInstrumento
  • Iniciativa:
    • Separada en Proyecto, Subproyecto, SubproyectoInstrumental y Actuacion.
    • fechaInicio su valor es un trimestre
    • fechaFin su valor es un trimestre
  • DeclaracionFinanciera
  • DeclaracionProgresoIndicador
    • codigoIniciativa ahora se llama codigoOrigenProgreso
Por norma general, los campos desaparecidos no es necesario informarlos.

Cambios destacados de v1.5.0 a v1.5.1

  • Ruta:
    • Se ha actualizado la ruta POST /ejecucion/otros-instrumentos/destinatarios
    • Se han actualizado las rutas de detalle de un instrumento jurídico. El parámetro {referencia} se convierte en parámetro de query. Por ejemplo, GET /estructura/actuaciones/{codigo}/convenios/{referencia} se convierte en GET /estructura/actuaciones/{codigo}/convenios/detalle?referencia={referencia}
  • Actuacion:
    • Se ha actualizado el campo transferenciaDeRecursosEconomicosAOtroSubproyecto de Actuacion, se convierte en opcional.
    • Se ha añadido el campo hitosObjetivosCriticos a Actuacion.
    • Se ha actualizado el tipo del campo recursosEconomicos de Actución.
  • Subproyecto:
    • Se ha eliminado el campo costeEstimado de recursosEconomicos de Subproyecto.
  • SubproyectoInstrumental:
    • Se ha eliminado el campo costeEstimado de recursosEconomicos de SubproyectoInstrumental.

Cambios destacados de v1.5.1 a v1.5.2

  • codigoPropietario El parámetro codigoPropietario pasa a ser opcional en las siguientes rutas:
    • /v1.5/estructura/proyectos
    • /v1.5/estructura/subproyectos
    • /v1.5/estructura/subproyectos-instrumentales
    • /v1.5/estructura/actuaciones
    Si no va incluido, la lista contendrá todos los elementos del tipo correspondiente a los que el usuario tenga acceso.
  • proyecto Los subproyectos, subproyectos instrumentales y actuaciones incluyen un resumen del proyecto al que pertenecen (propiedad proyecto).

Preguntas generales sobre la API v2.0

¿Cómo obtengo el código único de un instrumento jurídico?

El código único de un instrumento jurídico se obtiene de tres formas:
  • Alta de instrumento jurídico: en la respuesta de la operación de alta se devuelve el código único asignado al instrumento jurídico. Por ejemplo: POST /v2.0/contratos
  • Consulta de instrumentos jurídicos de una actuación: el listado de instrumentos jurídicos incluye el código único de cada instrumento jurídico. GET /v2.0/actuaciones/{codigo}/instrumentos-juridicos
  • Consulta de código único: existe una utilidad para obtener el código único de un instrumento jurídico a partir del código de actuación y la referencia del instrumento jurídico. GET /v2.0/instrumentos-juridicos/utilidades/codigo-unico

¿Cómo se realiza la subida de documentos?

La subida de documentos consta de dos pasos:
  • Subida del documento: Se añade un documento nuevo al sistema y se obtiene el localizador necesario para otras operaciones. El documento se crea con el tipo PENDIENTE. Los documentos subidos y no asociados a un elemento serán borrados periódicamente. El servicio utilizado es: POST /v2.0/documentos
  • Asociación del documento con un elemento: El documento subido en el punto anterior se asocia a un elemento. En la asociación se indica el localizar el documento, el tipo efectivo y los metadatos adicionales. El servicio utilizado depende del elemento, por ejemplo, para añadir un documento a un contrato, el servicio es: POST /v2.0/contratos/{codigo-unico}/documentos
Si se desea asociar el mismo documento a varios elementos, solo es necesario realizar una vez la subida del documento pudiendo utilizar el localizador tantas veces como sea necesario.

Otras dudas

Tengo dudas funcionales sobre la gestión del Plan de Recuperación Transformación y Resiliencia y el sistema de gestión del mismo, ¿dónde puedo dirigirme?

La descripción del funcionamiento del Plan se articula con dos Órdenes Ministeriales:
  • Orden HFP/1030/2021, de 29 de septiembre, por la que se configura el sistema de gestión del Plan de Recuperación, Transformación y Resiliencia.
  • Orden HFP/1031/2021, de 29 de septiembre, por la que se establece el procedimiento y formato de la información a proporcionar por las Entidades del Sector Público Estatal, Autonómico y Local para el seguimiento del cumplimiento de hitos y objetivos y de ejecución presupuestaria y contable de las medidas de los componentes del Plan de Recuperación, Transformación y Resiliencia.

Tengo más dudas técnicas relacionadas con la API, ¿dónde puedo dirigirme?

Para el resto de dudas técnicas sobre la API REST de CoFFEE, se puede escribir un mensaje a la dirección de correo electrónico de soporte CoFFEE-Desarrollo@igae.hacienda.gob.es
Desde este buzón se atenderán exclusivamente consultas de carácter técnico referidas al intercambio de información con la plataforma.