Open Contracting
DESCRIPCIÓN DEL ESTÁNDAR OPEN CONTRACTING
Open Contracting es un estándar internacional para la publicación de datos de Contrataciones Públicas. Uno de los principios fundamentales que Open Contracting persigue es alentar a los publicadores de datos a divulgar de forma proactiva información y datos sobre todas las etapas de una contratación pública o licitación.
El estándar fue desarrollado para permitir a los proveedores de información compartir la mayor cantidad posible de información como datos estructurados, es decir, datos estandarizados reutilizables.
Debido a la utilidad e innovación del estándar propuesto, la DNCP adopta como uno de sus objetivos, dentro del proceso de apertura de datos, la publicación de la información de contrataciones públicas utilizando el estándar Open Contracting. La estructura, formato y definiciones de las clases y atributos correspondientes al estándar pueden encontrarse en las páginas de Open Contracting en http://ocds.open-contracting.org/standard/r/1__0__0/en/schema/reference/.
MODELO DE DATOS DE OPEN CONTRACTING
El modelo de datos de Open Contracting se encuentra preparado para registrar todo el proceso de Contrataciones Públicas.
El primer paso para publicar datos de Contrataciones Públicas es identificar el proceso de contratación en los datos. Un proceso de contratación une información sobre diferentes etapas o fases relacionadas a la vida útil de un contrato, a partir de la planificación, progresando a través de las etapas de iniciación y ejecución, y finalizando cuando se termina un contrato o se cierra de algún modo. En la Figura 1 pueden verse las diferentes etapas del proceso y la relación entre ellas.
Figura 1. Etapas del proceso de contratación
Etapas del proceso de contratación
En el estándar Open Contracting (OCDS) debe existir un identificador único para el proceso de contratación, y un Open Contracting ID (OCID) asociado. El Open Contracting ID es identificador global único para un proceso de contratación otorgado.
Todo proceso de contratación inicia con una planificación (planning), seguido de una convocatoria (tender). Luego, pueden existir múltiples adjudicaciones (awards), contratos (contracts) e implementaciones (implementations) asociados al mismo proceso.
A continuación de detallan cada una de las etapas.
- Planning
Esta sección puede ser usada para describir los antecedentes de un proceso de contratación y puede incluir detalles del presupuesto del que se extraen los fondos o proyectos relacionados. Todo proceso de contratación posee una única planificación, dicha planificación tiene un presupuesto (budget) asociado donde finalmente se indica el valor o monto estimado para dicha planificación. Un diagrama de los componentes principales de clase planificación puede verse en la Figura 2.
Figura 2. Componentes de la clase “planning”.
- Tender
Esta sección incluye detalles del anuncio de que una organización tiene la intención de abastecerse de algunos bienes o servicios, y establecer uno o más contrato (s) para estos. Como en el caso de la planificación, todo proceso de contratación posee una única convocatoria, dicha convocatoria tiene asociada la organización involucrada en el proceso. Además, la convocatoria indica los ítems requeridos, el período establecido, los documentos utilizados, las adendas que pudieran haberse realizado sobre la convocatoria original y la lista de hitos.
Figura 3. Componentes de la clase “tender”.
- Award
Esta sección se utiliza para anunciar las adjudicaciones emitidas para esta licitación. Todo proceso de contratación puede involucrar una o más adjudicaciones, dichas adjudicaciones indican para cada proveedor (organización) los ítems adjudicados, el valor o monto adjudicado y los documentos asociados al proceso.
Figura 4. Componentes de la clase “award”.
- Contract
Esta sección se utiliza para proporcionar detalles de los contratos que se han celebrado. Todo proceso de contratación puede involucrar uno o más contratos, cada uno de los cuales debe estar asociado a una adjudicación específica. El proveedor (organización) adjudicado está indicado en la adjudicación, no así en el contrato. El contrato también indica los ítems adjudicados, los documentos asociados al proceso y la implementación del contrato. La implementación del contrato contiene información acerca de los hitos, las transacciones realizadas y los documentos utilizados.
Figura 5. Componentes de la clase “contract”.
Componentes del estándar
Existen una serie de componentes clave, en particular, los releases y los records son la columna vertebral del estándar. Por otro lado, los documentos también tienen un papel importante en el mundo de la contratación.
- Releases
Para fomentar la mayor apertura de información el estándar está preparado para publicar la información en tiempo real. En cada etapa del proceso de contratación, o con cada cambio que ocurra sobre los datos, el estándar prevé la publicación de esa nueva porción de información mediante releases.
Los releases son acumulativos, es decir, durante un proceso de contratación se pueden proporcionar uno o más releases, por ejemplo: describir una licitación, anunciar la adjudicación de contratos y proporcionar actualizaciones sobre los mismos.
Una vez que un release ha sido publicado no puede cambiar. La información actualizada debe ser compartida a través de un nuevo release.
Los releases pueden ser publicados a través de un único sistema o de manera distribuida por diferentes sistemas, pero todos éstos deben estar relacionados a partir de su Open Contracting ID (OCID).
Esquema de release en formato JSON:
{
“ocid”: “”,
“id”: “”,
"date": "",
"tag": [],
"initiationType": "tender",
"planning": {},
"tender": {},
"buyer": {},
"awards": [],
"contracts": [],
"language": "string"
}
- Records
Un registro (record) de contratación provee una instantánea del proceso de contratación en un punto dado en el tiempo, que reúne todas las versiones por las cuales pasó ese proceso en un solo lugar.
Un record contienen tres elementos clave: una lista de todos los releases asociados a un proceso de contratación en particular, un release compilado que contiene la última versión de los datos y una versión histórica de releases que contiene la historia con todos los cambios realizados sobre los datos.
Como mínimo esto puede ser una lista de enlaces a los releases accesibles en la web con el fin de que terceras personas puedan generar y verificar la información de todo el proceso de contratación publicado. Esquema de record en formato JSON:
{
“ocid”: “”,
“releases”: [],
"compiledRelease": {},
"versionedRelease": {}
}
- Release package
Un release package es un esquema de agrupación para la publicación de releases, describe el documento contenedor y metadatos para la publicación de releases. Un ejemplo de release package puede verse en la Figura 6.
Esquema de release package en formato JSON:
{
"uri": "",
"publishedDate": "",
"publisher": {
"scheme": "",
"id": "",
"name": "",
"legalName": "",
"uri": ""
},
"license": "",
"publicationPolicy": "",
"releases": [
{
“ocid”: “”,
“id”: “”,
"date": "",
"tag": [],
"initiationType": "tender",
"planning": {},
"tender": {},
"buyer": {},
"awards": [],
"contracts": [],
"language": "string"
}
]
}
- Record package
Un record package es un esquema de agrupación para la publicación de records, describe el documento contenedor y metadatos para la publicación de records. Un ejemplo de record package puede verse en la Figura 7.
Esquema de record package en formato JSON:
{
"packages": [],
"records": [
{
“ocid”: “”,
“releases”: [],
"compiledRelease": {},
"versionedRelease": {}
}
]
}
Figura 6. Release package.
Figura 7. Record package.
APLICACIÓN DEL ESTÁNDAR OPEN CONTRACTING A LOS DATOS DE CONTRATACIONES PÚBLICAS DEL PARAGUAY
Como parte del proceso de apertura de datos la DNCP decide publicar sus datos con el formato establecido por el estándar Open Contracting, para ello se divide la publicación y disponibilización de los datos de dos maneras distintas: API de servicios y descarga de archivos estáticos.
La API de servicios tiene como finalidad disponibilizar los datos en tiempo real de las planificaciones, convocatorias, adjudicaciones, contratos y modificaciones de contratos. Por otro lado, la descarga de archivos estáticos tiene como finalidad disponibilizar los datos históricos de los procesos de licitación por año en archivos JSON, desde el 2010 en adelante. Esto permite obtener el histórico de cambios realizados sobre los diferentes procesos de contratación.
La diferencia entre la API de servicios y los archivos estáticos es que la primera permite obtener los datos en tiempo real, es decir, siempre será retornado el estado final de los datos; sin embargo, la segunda permite obtener los datos a través de los años, es decir, hace posible reconstruir la historia de los procesos de contratación.
Esto quiere decir que si una convocatoria del 2014 cambio una o más veces con el paso del tiempo, con la API de servicios se obtendrá el estado actual de dicha convocatoria. Sin embargo, por medio de los archivos estáticos se podrá obtener el estado inicial de esa convocatoria y todos los cambios que fueron ocurriendo sobre la misma, con lo que finalmente se podrá construir la historia de cambios de la convocatoria.
La DNCP, por medio de su Dirección de Informática, realizó el pedido del Open Contracting ID a la autoridades correspondientes. Como resultado le fue asignado el siguiente OCID: ocds-03ad3f, el cual será utilizado para identificar los releases y records generados tanto por la API de servicios como por los archivos estáticos.
Para la utilización del OCID es necesario completar el prefijo ocds-03ad3f asignado con el identificador del proceso de licitación propio de la DNCP (número de licitación). Con esto el OCID definitivo es de la forma ocds-03ad3f-<numero_licitacion>, por ejemplo ocds-03ad3f-193399.
PATRONES DE PUBLICACIÓN
El estándar Open Contracting define tres niveles de publicación de datos, los cuales se detallan a continuación.
Básico
Licenciamiento
La publicación de datos bajo licencias abiertas es importante puesto que detallan los permisos de acceso, uso y reuso que se tienen sobre los datos. De no contar con una licencia, las restricciones de reutilización pueden impedir la realización de muchos casos de uso interesantes que pueden llevarse a cabo con los datos.
Políticas de publicación
La publicación de datos de contrataciones implica la toma de una serie de decisiones sobre los datos, los documentos a incluir y cómo clasificar y categorizar la información publicada. Para permitir a los usuarios entender las opciones que un publicador ha hecho, debe proporcionarse una página web pública o un documento que detalla las decisiones que se han tomado en relación a las cuestiones que se describen a continuación:
- Responsable de proporcionar los datos, incluyendo detalles y ubicación de contacto.
- Generación de los datos y frecuencia de generación.
- Exclusiones de datos.
- Listas de códigos personalizados utilizados.
- Planes de desarrollo futuros.
Proveer registros completos
Un record básico con el formato del estándar Open Contracting puede listar todos los releases asociados a un proceso de contratación en particular. Sin embargo, un record completo provee además un release compilado que muestra el estado actual del proceso.
Publicación amigable
Los releases y records proveen un acceso masivo a un conjunto de datos de contrataciones. Sin embargo, los archivos de gran tamaño pueden ser difíciles de descargar y procesar. Algunas buenas prácticas son: generar archivos de menos de un 1Gb de tamaño, generar archivos comprimidos, publicar los archivos segmentados (por año, mes o identificador del proceso de contratación, por ejemplo), entre otros. ###Avanzado
Soporte para descubrimiento
Existen muchas organizaciones que deberían ser capaces de publicar datos de contrataciones, por esto, el mantenimiento de un registro central de todos los datos publicados no es práctico. Para solucionar esto, Open Contracting propone un patrón común para el descubrimiento de datos. Para el descubrimiento de datos en grandes cantidades (bulk) se propone la utilización de un archivo data.json con la la estructura proveída por Project Open Data y para el descubrimiento de releases individuales propone el uso de feeds mediante canales RSS.
NIVELES DE PUBLICACIÓN
Los datos abiertos han establecido buenas prácticas en cuanto a la publicación de datos en la web. Complementariamente a los niveles de publicación básico, intermedio y avanzado, Open Contracting ha mapeado el estándar contra el esquema de cinco estrellas de Tim Berners-Lee. Cada aumento de nivel hace que los datos sean más accesibles, reutilizables y valiosos. Finalmente, se obtiene la siguiente clasificación:
Una estrella: Subida de información básica de contrataciones a la web
Este nivel requiere la publicación básica de contrataciones en la web, en cualquier estructura y formato.
Dos estrellas: Proveer datos de contrataciones procesables por máquinas
Este nivel requiere la publicación de los datos de contrataciones en formatos que puedan ser procesados automáticamente por máquinas, como JSON y CSV.
Tres estrellas: Proveer datos estructurados usando estándares abiertos
Este nivel requiere la publicación de datos en formatos abiertos y en base al esquema definido por Open Contracting. Utilizando dicho esquema, terceras partes pueden re usar los datos efectivamente. Esto puede llevarse a cabo mediante la publicación de archivos estáticos u otras interfaces como APIs de servicios.
Cuatro estrellas: Usar mejores prácticas de publicación de datos en la web
Este nivel requiere la publicación de releases y records a través de una URI identificable unívocamente en la web. Además, requiere la publicación de feeds que detallen la información que ha sido recientemente actualizada.
Cinco estrellas: Hacer referencia a otros conjuntos de datos
Este nivel requiere la utilización de URIs dentro del conjunto de datos para identificar elementos de otros conjuntos de datos, recurriendo a los datos publicados en la web por otras organizaciones. Esto permite la integración y mantenibilidad entre sistemas.
MODELO DE DATOS DE CONTRATACIONES DEL PARAGUAY
A continuación se describen las principales diferencias entre las etapas del proceso de contratación del modelo de datos del estándar Open Contracting y el modelo de datos de Contrataciones Públicas del Paraguay.
Planificaciones (planning)
Para las planificaciones (plannings) sólo se agregó el atributo url para poder identificar el servicio que es utilizado para generar la planificación en sí
Ejemplo
"releases": [{
"language": "es",
"ocid": "ocds-03ad3f-193399",
"id": "193399-adquisicion-scanner-planning",
"date": "2016-03-08T14:50:27-03:00",
"tag": ["planning"],
"initiationType": "tender",
"planning": {
"budget": {
"description": "Adquisición de Scanner",
"amount": {
"amount": null,
"currency": "PYG"
}
},
url": "https://www.contrataciones.gov.py/datos/id/planificaciones/193399-adquisicion-scanner"
}
}]
Convocatorias (tender)
Tal como se mencionó en la sección 1, el modelo de datos del estándar Open Contracting prevé la existencia de una única convocatoria (tender) por cada proceso de contratación. Esto difiere del modelo de datos de Contrataciones Públicas del Paraguay, puesto que en Paraguay para un mismo proceso de contratación puede existir más de una convocatoria, con la salvedad de que sólo una de ellas puede estar activa a la vez. Este esquema puede verse en el ejemplo de la Figura 8.
Figura 8. Convocatorias en el proceso de Contrataciones de Paraguay.
La solución adoptada es crear un release por cada convocatoria correspondiente a un proceso de contratación en particular. La forma en que dichos releases pueden agruparse es el OCID, debido a que todos contienen el mismo número de licitación.
Además, se agregó el atributo url, que corresponde a la url del servicio utilizado para construir la convocatoria (tender)
"releases": [{
"language": "es",
"ocid": "ocds-03ad3f-272219",
"id": "272219-adquisicion-softwares-tercer-llamado",
"date": "2015-11-26T10:18:57-03:00",
"tag": [
"planning",
"tender",
"award",
"contract"
],
"initiationType": "tender",
"planning": {
...
},
"tender": {
"id": "272219-adquisicion-softwares-tercer-llamado",
"title": "Adquisición de softwares - Tercer Llamado",
"status": "complete",
"url": "https://www.contrataciones.gov.py/datos/id/convocatorias/272219-adquisicion-softwares-tercer-llamado",
...
},
"award": [...],
"contract": [...]
}]
Lotes e ítems
El modelo de datos del estándar Open Contracting tiene en cuenta la existencia ítems, los cuales están incluidos como atributos en las etapas de convocatoria, adjudicación y contrato. Sin embargo, no se prevé la existencia de lotes. Esto difiere del modelo de Contrataciones del Paraguay, en el cual se utilizan los lotes como unidades lógicas de agrupación de ítems.
Esta agrupación lógica definida como “lotes” tiene importancia al momento de realizar las adjudicaciones, dado que las adjudicaciones a un proveedor pueden ser por lotes o por ítems.
La solución adoptada es agregar una clase lote que indique los items que le corresponden. Esta clase lote será incluida tanto en la convocatorias (tender) como en los contratos (contract).
Ejemplo
"tender": {
"id": "272219-adquisicion-softwares-tercer-llamado",
"title": "Adquisición de softwares - Tercer Llamado",
"status": "complete",
"lots": [
{
"id": "nYZlDIKXpLc%3D",
"title": "Lote 1",
"items": [
"m7w377ckCB0%3D",
"QY5z%2F8V1pz0%3D",
"QAI5ZeUlf7g%3D",
"ZLORWaruc60%3D",
"rgzXi3e6VwU%3D",
"%2FVMPBHpdRvk%3D"
]
}],
"items": [
{
"description": "Licencias de Software - Kit para Instituciones Educativas",
"id": "m7w377ckCB0%3D",
"classification": {
"schema": "UNSPSC",
"id": "UNSPSC",
"description": "United Nations Standard Products and Services Code",
"uri": "http://www.unspsc.org/codeset-downloads"
},
"quantity": 1,
"unit": {
"name": "UNI",
"value": {
"amount": null,
"currency": "PYG"
}
}
},
... ]
...
}
Adjudicación (award) y Contrato (contract)
En el modelo de Contrataciones de Paraguay, una convocatoria resulta en una única adjudicación. Dicha adjudicación puede tener múltiples proveedores adjudicados, y lotes e ítems específicos adjudicados. Diferentes contratos son realizados para cada uno de estos proveedores como puede verse en el ejemplo de la Figura 9.
Figura 9. Adjudicaciones y contratos en el proceso de Contrataciones de Paraguay.
Sin embargo, en el estándar Open Contracting, el proveedor está relacionado a nivel de adjudicación en lugar de contrato.
La solución adoptada es agregar el atributo proveedor a la clase contrato, a modo de poder identificar al proveedor de cada contrato en particular, utilizando la misma clase proveedor (supplier) proveída por el estándar.
Además, se agrega el atributo:
“dncpContractCode”: “RL-12001-12-0012”
Donde,
- dncpContractCode es el código de contratación utilizado en Paraguay por la DNCP (Dirección Nacional de Contrataciones Públicas del Paraguay).
También, se agregó el atributo url a la adjudicación que corresponde a la url del servicio utilizado para construir la adjudicación (award)
Ejemplo
"contract": [{
"id": "246807-11-setiembre-srl-4",
"awardID": "246807-adqusicion-guantes-otros-insumos-medicos",
"dncpContractCode": "CD-13003-13-70684",
"title": "ADQUSICION DE GUANTES Y OTROS INSUMOS MEDICOS ",
"status": "active",
...
"suppliers": {
"name": "11 DE SETIEMBRE SRL",
"identifiers": {
"id": "80028024-5",
"legalName": "11 DE SETIEMBRE SRL"
}
},
...
}]
Adendas (amendments)
Las adendas en Paraguay son tratadas de una manera muy particular que difiere en gran medida con el modelo de adendas de Open Contracting.
En Paraguay, las adendas son modificaciones o extensiones realizadas a los contratos. Estas adendas tienen un código de contratación nuevo y se encuentran relacionadas al contrato del cual extienden como se puede verse en el ejemplo de la Figura 10.
Figura 10. Ejemplo de Adendas en el proceso de Contrataciones de Paraguay.
Las adendas pueden ser de varios tipos, entre los que se distinguen:
- Ampliación de montos: cuando el Contratante y Proveedor, requieren mayor cantidad a lo adjudicado originalmente o y en caso de obras además podría incluir nuevos rubros en relación a lo originalmente contratado, lo cual significa un mayor valor.
- Ampliación de Plazos: cuando la vigencia o finalización del contrato se extiende más de lo originalmente previsto.
- Reajustes: cuando varían los precios originalmente contratados, manteniendo la cantidad contratada (pagar más por lo mismo), desde el punto de vista del sistema la única diferencia con la ampliación de monto es que se selecciona un tipo distinto de modificación.
- Otros: cualquier cambio, adición o enmienda a los contratos ya suscritos.
Este modelo hace que, por ejemplo, una adenda de monto especifique el monto por el cual se está extiendo el contrato o una adenda de plazos especifique el tiempo adherido a al plazo original.
Sin embargo, en el modelo de Open Contracting, las adendas significan cambios en los atributos de un contrato en particular y sobre escriben su valor.
La solución adoptada es presentar los datos de una adenda por medio de la clase contratos, incluyendo los siguientes atributos:
“extendsContractID”: “207002-armin-hahner-stollmaier-21”, “dncpContractCode”: “RL-12001-12-0012”, “dncpAmendmentType”: “Renovación de Alquiler de Inmueble”,
Donde,
- extendsContractID hace referencia al contrato del cual extiende la adenda,
- dncpContractCode es el código de contratación utilizado en Paraguay por la DNCP (Dirección Nacional de Contrataciones Públicas del Paraguay),
- dncpAmendmentType es el tipo de adenda que puede ser escogido de una lista predefinida de tipos de adendas utilizadas en Paraguay por la DNCP,
- el atributo title tendrá como prefijo la palabra “Adenda”, y el sufijo tendrá el mismo título que el contrato referenciado por el atributo extendsContractID.
Por último, el atributo initiationType del release correspondiente será “contractAmendment”.
Ejemplo
"releases": [
{
"language": "es",
"ocid": "ocds-03ad3f-207002",
"id": "207002-armin-hahner-stollmaier-21-renovacion-contractAmendment",
"date": "2015-11-26T10:43:35-03:00",
"tag": [
"contractAmendment"
],
"initiationType": "tender",
"contract": [{
"id": "207002-armin-hahner-stollmaier-21-renovacion",
"extendsContractID": "207002-armin-hahner-stollmaier-21",
"dncpContractCode": "RL-12001-12-0012",
"dncpAmendmentType": "Renovación de Alquiler de Inmueble",
"title": "Contract Amendment: Ad Referendum - Alquileres para la SNNA",
"status": "active",
"value": {
"amount": 12780000,
"currency": "PYG"
},
"dateSigned": "2012-03-14 16:58:40.265507",
...
}]
}]
API DE SERVICIOS
Se disponibiliza una API de servicios, accesible a través del Portal de Datos Abiertos de la DNCP, a partir de la cual se podrá obtener:
- Por cada fase de la licitación (planificación, convocatoria, adjudicación y contrato) el release-package (de un único release) de cada una de estas fases con todos los elementos o atributos que corresponda.
- Por cada licitación (dado su OCID o número de licitación) el record-package que agrupará todas las fases de la licitación, el cual en su versión compilada contendrá el ciclo completo de la licitación.
A continuación se detallan los servicios incluidos en la API:
- Planning: este servicio retorna los datos de la planificación en el formato de release-package establecido por el estándar Open Contracting. Entre los parámetros del servicio se incluye la clave OAuth (Requerido. Dejando vacío este parámetro solo se permiten 4 llamados por segundo para propósitos de testing) de autenticación y el id de la planificación. El id de la planificación puede ser obtenido de la columna id de los archivos CSV por año publicados en el Portal en http://www.contrataciones.gov.py/datos/planificaciones .
- Tender: este servicio retorna los datos de la convocatoria en el formato de release-package establecido por el estándar Open Contracting. Entre los parámetros del servicio se incluye la clave OAuth (Requerido. Dejando vacío este parámetro solo se permiten 4 llamados por segundo para propósitos de testing) de autenticación y el id de la convocatoria. El id de la convocatoria puede ser obtenido de la columna id de los archivos CSV por año publicados en el Portal en https://www.contrataciones.gov.py/datos/convocatorias .
- Award: este servicio retorna los datos de la adjudicación en el formato de release-package establecido por el estándar Open Contracting. Entre los parámetros del servicio se incluye la clave OAuth (Requerido. Dejando vacío este parámetro solo se permiten 4 llamados por segundo para propósitos de testing) de autenticación y el id de la adjudicación. El id de la adjudicación puede ser obtenido de la columna id de los archivos CSV por año publicados en el Portal en https://www.contrataciones.gov.py/datos/adjudicaciones .
- Contract: este servicio retorna los datos del contrato en el formato de release-package establecido por el estándar Open Contracting. Entre los parámetros del servicio se incluye la clave OAuth (Requerido. Dejando vacío este parámetro solo se permiten 4 llamados por segundo para propósitos de testing) de autenticación y el id del contrato. El id del contrato puede ser obtenido de la columna id de los archivos CSV por año publicados en el Portal en https://www.contrataciones.gov.py/datos/contratos .
- Amendments: este servicio retorna los datos de la modificación de contrato en el formato de release-package establecido por el estándar Open Contracting. Entre los parámetros del servicio se incluye la clave OAuth (Requerido. Dejando vacío este parámetro solo se permiten 4 llamados por segundo para propósitos de testing) de autenticación y el id de la modificación de contrato. El id de la modificación de contrato puede ser obtenido de la columna id de los archivos CSV por año publicados en el Portal en https://www.contrataciones.gov.py/datos/modificaciones .
- Record-package: este servicio retorna los datos de un proceso de contratación en el formato de record-package establecido por el estándar Open Contracting. Entre los parámetros del servicio se incluye la clave OAuth (Requerido. Dejando vacío este parámetro solo se permiten 4 llamados por segundo para propósitos de testing) de autenticación y el OCID o número de licitación. El número de licitación puede ser obtenido de la columna “id_llamado” de cualquiera de los CSV por año publicados en el Portal en https://www.contrataciones.gov.py/datos/data .
Para acceder a la documentación de la API de servicior hacer click en la acción “Documentación” en la sección “Open Contracting” en la lista de Conjuntos de datos de la DNCP (Figura 11).
Figura 11. Acceso a la Documentación de la API de Servicios.
La documentación de los servicios se encuentra disponible en la sección “Servicios del Estándar Open Contracting” disponible en https://www.contrataciones.gov.py/datos/api/v2/#!/ocds como se muestra en la Figura 12.
Figura 12. Sección de Servicios del estándar Open Contracting.
Para realizar una llamada de ejemplo al servicio “tender” (al igual que para “planning”, “award”, “contract” y “amendment”) deben completarse los parámetros indicados en la Figura 13. El parámetro “Authorization” puede omitirse en caso de realizar llamadas de prueba con lo cual se tiene un límite de 4 (cuatro) peticiones por segundo; para propósitos de desarrollo y producción este parámetro es obligatorio.
Figura 13. Parámetros del servicio de convocatorias.
Hacer click en el botón “Try it out” como se muestra en la Figura 14 para ejecutar la llamada al servicio.
Figura 14. Llamada al servicio de convocatorias.
Luego, la respuesta del servicio podrá ser vista como se muestra en la Figura 15.
Figura 15. Ejemplo de respuesta del servicio de convocatorias.
Por último, para ejecutar la llamada al servicio para obtener el record-package puede pasarse como parámetro tanto el OCID como el número de licitación, como se muestra en las figuras 16 y 17 respectivamente.
Figura 16. Parámetros del servicio para obtener un record-package dado el número de licitación.
Figura 17. Parámetros del servicio para obtener un record-package dado el OCID.