> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Gestión de plazos > Rastrea cuándo vencen los informes regulatorios y de negocio con los plazos de Reporter: crea obligaciones recurrentes, monitorea su estado y márcalas como entregadas. Un **plazo** es la capa de rastreo de Reporter para las entregas de informes. Las plantillas definen *cómo* se ve un informe, y la generación de informes produce la *salida*. Un plazo registra *cuándo* vence un informe y su estado de entrega. Cada plazo representa una obligación de entrega, normalmente una presentación regulatoria o un informe de negocio recurrente. De forma opcional, puedes vincular un plazo a la plantilla que lo cumple. Los plazos no generan informes por sí mismos. Están junto al [ciclo de vida de la generación de informes](/es/products/reporter/reporter-quick-start#the-reporting-lifecycle) como un rastreador operativo, de modo que los equipos pueden ver qué está `pending`, `overdue` o ya `delivered`. ## Por qué existen los plazos *** La generación de informes responde *cómo* y *qué*. Los plazos responden *cuándo* y *si se cumplió*. Sin una capa de rastreo, un equipo puede producir informes perfectos y aun así perder una ventana de presentación. Nada en el propio motor de generación de informes sabe que un informe *vencía*. Los plazos resuelven un problema de cumplimiento de entrega. Convierten las obligaciones de generación de informes recurrentes en compromisos rastreados y con fecha, de modo que nada se pierda en silencio: * **Obligaciones regulatorias de generación de informes**: muchas presentaciones deben llegar a un regulador en un calendario fijo. Un plazo registra esa obligación, su recurrencia y su estado de entrega, de modo que una presentación perdida o tardía es visible antes de convertirse en un incidente de cumplimiento. * **SLA internos**: los informes de negocio recurrentes suelen llevar compromisos internos ("finanzas recibe el paquete de cierre mensual antes del día 5"). Los plazos hacen esos compromisos explícitos y medibles. * **Registros de auditoría para la entrega**: cada plazo registra `deliveredAt` y avanza por `pending` → `overdue` → `delivered`. Deja un historial auditable de *cuándo* se cumplió cada obligación, no solo que existe un informe. ## Quién usa los plazos *** Los plazos son una herramienta de negocio y cumplimiento que se agrega sobre el motor de generación de informes. Los usuarios típicos incluyen: * Una **fintech que entrega informes regulatorios a BACEN** en calendarios mensuales o anuales fijos. Usa plazos para rastrear y cumplir cada ventana de presentación. * Un **equipo de tesorería o finanzas** que rastrea entregas mensuales recurrentes de informes, usando el calendario y la vista de estado para confirmar que cada salida rutinaria salió a tiempo. * Un **oficial de cumplimiento** que monitorea obligaciones vencidas en toda la organización, filtrando por el estado `overdue` para detectar cualquier riesgo antes de que escale. Para estos equipos, el valor está en *conocer el panorama de obligaciones*: qué se acerca, qué está atrasado y qué ya se completó. ## Cómo encajan los plazos en el workflow de Reporter *** Los plazos envuelven los informes y las fuentes de datos para agregar una **capa de estado de entrega** sobre el motor de generación de informes. Las fuentes de datos proveen los datos, las plantillas definen la salida y el ciclo de vida de la generación de informes produce el archivo. Un plazo está por encima de todo eso. De forma opcional, se vincula a la plantilla que cumple la obligación, vigila la fecha de vencimiento y expone un único estado. El estado le indica al negocio si la obligación se cumplió. Los plazos son *no intrusivos*. Nunca activan, generan ni envían un informe. Observan y registran. Sigues generando informes mediante el ciclo de vida normal, y el plazo registra el estado de entrega. ## Qué rastrea un plazo *** Cada plazo captura la fecha de vencimiento de una obligación de informe, además de los metadatos que tu equipo necesita para administrarla: | Campo | Descripción | | ------------------ | -------------------------------------------------------------------------------------------------- | | `name` | Nombre legible del plazo (por ejemplo, *Monthly Regulatory Report*). | | `description` | Descripción más larga y opcional de la obligación. | | `type` | Clasificación del plazo, como `regulatory` o `custom`. | | `frequency` | Con qué frecuencia se repite el plazo, como `monthly` o `annual`. | | `dueDate` | Cuándo vence el informe, en formato RFC 3339. | | `color` | Color hexadecimal usado para identificar visualmente el plazo en los dashboards. | | `notifyDaysBefore` | Número de días antes de la fecha de vencimiento en que empiezan las notificaciones. | | `monthsOfYear` | Meses (1–12) en los que se aplica el plazo. | | `templateId` | UUID opcional de la [plantilla](/es/products/reporter/using-reporter) usada para cumplir el plazo. | | `active` | Si el plazo está activo actualmente. | Reporter también mantiene campos de solo lectura en cada plazo: `id`, `status` (`pending`, `overdue` o `delivered`), `deliveredAt`, `templateName`, `createdAt` y `updatedAt`. Incluye un encabezado `Authorization: Bearer ` en cada solicitud de plazo si tu entorno habilita [Access Manager](/es/platform/access-manager). ## Crear un plazo *** Crea un plazo con el endpoint [Crear un plazo](/es/reference/products/reporter/create-deadline) (`POST /v1/deadlines`). Los campos requeridos son `name`, `type`, `frequency`, `dueDate` y `color`. Los demás campos son opcionales. Configura `templateId` para vincular el plazo a la plantilla que lo cumple, y `notifyDaysBefore` para controlar cuándo empiezan los recordatorios. ```json theme={null} { "name": "Monthly Regulatory Report", "description": "Monthly regulatory compliance report", "type": "regulatory", "frequency": "monthly", "dueDate": "2026-03-31T23:59:59Z", "color": "#FF5733", "notifyDaysBefore": 5, "monthsOfYear": [1, 6], "templateId": "00000000-0000-0000-0000-000000000000", "active": true } ``` Una solicitud exitosa devuelve `201 Created` con el plazo completo, incluidos su `id` generado y un `status` inicial. Referencia de la API: [Crear un plazo](/es/reference/products/reporter/create-deadline) ## Listar plazos *** Recupera plazos con el endpoint [Recuperar plazos](/es/reference/products/reporter/retrieve-deadlines) (`GET /v1/deadlines`). El endpoint pagina los resultados, y puedes filtrarlos por estado. | Parámetro de consulta | Descripción | Valor predeterminado | | --------------------- | ---------------------------------------------- | -------------------- | | `status` | Filtra por `pending`, `overdue` o `delivered`. | — | | `limit` | Número de registros por página (entero ≥ 1). | `10` | | `page` | Número de página que se devuelve (entero ≥ 1). | `1` | Por ejemplo, para listar los plazos vencidos, diez por página: ``` GET /v1/deadlines?status=overdue&limit=10&page=1 ``` La respuesta contiene un array `items`, además de `page`, `limit` y `total` para la paginación. Referencia de la API: [Recuperar plazos](/es/reference/products/reporter/retrieve-deadlines) ## Actualizar un plazo *** Actualiza un plazo existente con el endpoint [Actualizar un plazo](/es/reference/products/reporter/update-deadline) (`PATCH /v1/deadlines/{id}`). El endpoint cambia solo los campos que están en el cuerpo de la solicitud, así que puedes enviar un payload parcial. Por ejemplo, para posponer una fecha de vencimiento o desactivar un plazo: ```json theme={null} { "dueDate": "2026-06-30T23:59:59Z", "notifyDaysBefore": 10, "active": false } ``` Una solicitud exitosa devuelve `200 OK` con el plazo actualizado. Referencia de la API: [Actualizar un plazo](/es/reference/products/reporter/update-deadline) ## Eliminar un plazo *** Elimina un plazo que ya no necesitas rastrear con el endpoint [Eliminar un plazo](/es/reference/products/reporter/delete-deadline) (`DELETE /v1/deadlines/{id}`). Una solicitud exitosa devuelve `204 No Content`. Referencia de la API: [Eliminar un plazo](/es/reference/products/reporter/delete-deadline) ## Marcar un plazo como entregado *** Después de presentar o enviar el informe detrás de un plazo, márcalo como entregado. Usa el endpoint [Entregar un plazo](/es/reference/products/reporter/deliver-deadline) (`PATCH /v1/deadlines/{id}/deliver`). Mueve el `status` del plazo a `delivered` y registra `deliveredAt`. ```json theme={null} { "delivered": true } ``` Como `delivered` es un booleano, el mismo endpoint también puede revertir la acción. Envía `"delivered": false` para reabrir un plazo que marcaste como entregado por error. Una solicitud exitosa devuelve `200 OK` con el plazo actualizado. Entregar un plazo solo rastrea la obligación. Registra que la obligación se cumplió. No genera ni envía el informe subyacente. Genera el informe mediante el [ciclo de vida de la generación de informes](/es/products/reporter/reporter-quick-start) y luego marca el plazo como entregado para mantener tu rastreador preciso. Referencia de la API: [Entregar un plazo](/es/reference/products/reporter/deliver-deadline) ## Cómo encajan los plazos en el workflow *** Una obligación típica avanza por estos estados: Registra la obligación con su fecha de vencimiento, su frecuencia y una plantilla opcional. Se muestra como `pending` hasta la fecha de vencimiento, y luego como `overdue` si no entregas el informe a tiempo. Produce el informe mediante el [ciclo de vida de la generación de informes](/es/products/reporter/reporter-quick-start) normal, usando la plantilla vinculada. Llama al endpoint de entrega para establecer `status` en `delivered` y registrar `deliveredAt`. ## Próximos pasos *** Recorre el ciclo de vida de generación de informes que rastrean los plazos. Construye las plantillas que cumplen tus plazos. Plantillas listas para usar en la generación de informes regulatorios brasileños. Referencia completa de solicitud y respuesta para cada endpoint de plazos.