> ## 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. # Gerenciando prazos > Gerencie os prazos regulatórios no Reporter — acompanhe entregas futuras e vencidas, receba notificações e mantenha sua operação em conformidade. Um **prazo** é a camada de acompanhamento do Reporter para entregas de relatórios. Enquanto os templates definem *como* um relatório se parece e a geração de relatórios produz a *saída*, um prazo registra *quando* um relatório vence e se ele foi entregue. Cada prazo representa uma obrigação de entrega — normalmente uma submissão regulatória ou um relatório de negócio recorrente — e pode, opcionalmente, estar vinculado ao template usado para cumpri-lo. Os prazos não geram relatórios por si só. Eles ficam ao lado do [ciclo de vida de relatórios](/pt/reporter/reporter-quick-start#the-reporting-lifecycle) como um rastreador operacional, para que as equipes vejam de relance o que está `pending` (pendente), `overdue` (vencido) ou já `delivered` (entregue). ## Por que os prazos existem *** A geração de relatórios responde *como* e *o quê*. Os prazos respondem *quando* e *se foi cumprido*. Sem uma camada de acompanhamento, uma equipe pode produzir relatórios perfeitos e ainda perder uma janela de submissão, porque nada no próprio motor de relatórios sabe que um relatório estava *vencendo*. Os prazos resolvem um problema de conformidade de entrega. Eles transformam obrigações de relatório recorrentes em compromissos rastreados e datados, para que nada passe despercebido: * **Obrigações regulatórias de relatório** — muitas submissões precisam chegar a um regulador em um cronograma fixo. Um prazo registra essa obrigação, sua recorrência e seu estado de entrega, para que uma submissão perdida ou atrasada fique visível antes de se tornar um incidente de conformidade. * **SLAs internos** — relatórios de negócio recorrentes frequentemente carregam compromissos internos ("o financeiro recebe o pacote de fechamento mensal até o dia 5"). Os prazos tornam esses compromissos explícitos e mensuráveis. * **Trilhas de auditoria para entrega** — como cada prazo registra `deliveredAt` e percorre `pending` → `overdue` → `delivered`, ele deixa um histórico auditável de *quando* cada obrigação foi satisfeita, não apenas que um relatório existe. ## Quem usa os prazos *** Os prazos são uma ferramenta de negócio e conformidade sobreposta ao motor de relatórios. Usuários típicos incluem: * Uma **fintech entregando relatórios regulatórios ao BACEN** em cronogramas mensais ou anuais fixos, usando prazos para garantir que cada janela de submissão seja rastreada e cumprida. * Uma **equipe de tesouraria ou financeiro** acompanhando entregas de relatórios mensais recorrentes, usando o calendário e a visão de status para confirmar que cada saída de rotina foi enviada no prazo. * Um **responsável por conformidade** monitorando obrigações vencidas em toda a organização, filtrando pelo status `overdue` para identificar qualquer coisa em risco antes que ela escale. Para essas equipes, o valor não está em produzir o relatório — esse é o trabalho do motor de relatórios — mas em *conhecer o panorama de obrigações*: o que está por vir, o que está atrasado e o que está concluído. ## Como os prazos se encaixam no fluxo do Reporter *** Os prazos envolvem relatórios e fontes de dados para adicionar uma **camada de status de entrega** sobre o motor de relatórios. As Fontes de Dados fornecem os dados, os Templates definem a saída e o ciclo de vida de relatórios produz o arquivo. Um prazo fica acima de tudo isso: ele vincula (opcionalmente) ao template que cumpre a obrigação, observa a data de vencimento e expõe um único status que diz ao negócio se a obrigação foi cumprida. Na prática, isso significa que os prazos são *não intrusivos*. Eles nunca disparam, geram ou enviam um relatório — eles observam e registram. Você ainda gera relatórios pelo ciclo de vida normal; o prazo é simplesmente o rastreador que transforma essa atividade em um status de entrega claro no qual o resto da organização pode confiar. ## O que um prazo acompanha *** Cada prazo captura a data de vencimento de uma obrigação de relatório, além dos metadados que sua equipe precisa para gerenciá-la: | Campo | Descrição | | ------------------ | ------------------------------------------------------------------------------------ | | `name` | Nome legível do prazo (por exemplo, *Relatório Regulatório Mensal*). | | `description` | Descrição opcional mais longa da obrigação. | | `type` | Classificação do prazo, como `regulatory` ou `custom`. | | `frequency` | Com que frequência o prazo se repete, como `monthly` ou `annual`. | | `dueDate` | Quando o relatório vence, no formato RFC 3339. | | `color` | Cor hexadecimal usada para identificar visualmente o prazo nos dashboards. | | `notifyDaysBefore` | Número de dias antes da data de vencimento em que as notificações começam. | | `monthsOfYear` | Meses (1–12) em que o prazo se aplica. | | `templateId` | UUID opcional do [template](/pt/reporter/using-reporter) usado para cumprir o prazo. | | `active` | Se o prazo está atualmente ativo. | O Reporter também mantém campos somente leitura em cada prazo — `id`, `status` (`pending`, `overdue` ou `delivered`), `deliveredAt`, `templateName`, `createdAt` e `updatedAt`. Inclua um cabeçalho `Authorization: Bearer ` em cada requisição de prazo quando o [Access Manager](/pt/platform/access-manager/access-manager) estiver habilitado no seu ambiente. ## Criando um prazo *** Crie um prazo com o endpoint [Create a Deadline](/pt/reference/reporter/create-deadline) (`POST /v1/deadlines`). Os campos obrigatórios são `name`, `type`, `frequency`, `dueDate` e `color`. Os campos restantes são opcionais — defina `templateId` para vincular o prazo ao template que o cumpre, e `notifyDaysBefore` para controlar quando os lembretes começam. ```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 } ``` Uma requisição bem-sucedida retorna `201 Created` com o prazo completo, incluindo seu `id` gerado e um `status` inicial. Referência da API: [Create a Deadline](/pt/reference/reporter/create-deadline) ## Listando prazos *** Recupere os prazos com o endpoint [Retrieve Deadlines](/pt/reference/reporter/retrieve-deadlines) (`GET /v1/deadlines`). Os resultados são paginados e podem ser filtrados por status. | Parâmetro de consulta | Descrição | Padrão | | --------------------- | ----------------------------------------------- | ------ | | `status` | Filtra por `pending`, `overdue` ou `delivered`. | — | | `limit` | Número de registros por página (inteiro ≥ 1). | `10` | | `page` | Número da página a retornar (inteiro ≥ 1). | `1` | Por exemplo, para listar prazos vencidos, dez por página: ``` GET /v1/deadlines?status=overdue&limit=10&page=1 ``` A resposta contém um array `items` mais `page`, `limit` e `total` para paginação. Referência da API: [Retrieve Deadlines](/pt/reference/reporter/retrieve-deadlines) ## Atualizando um prazo *** Atualize um prazo existente com o endpoint [Update a Deadline](/pt/reference/reporter/update-deadline) (`PATCH /v1/deadlines/{id}`). Apenas os campos incluídos no corpo da requisição são alterados, então você pode enviar um payload parcial — por exemplo, para adiar uma data de vencimento ou desativar um prazo: ```json theme={null} { "dueDate": "2026-06-30T23:59:59Z", "notifyDaysBefore": 10, "active": false } ``` Uma requisição bem-sucedida retorna `200 OK` com o prazo atualizado. Referência da API: [Update a Deadline](/pt/reference/reporter/update-deadline) ## Excluindo um prazo *** Remova um prazo que você não precisa mais acompanhar com o endpoint [Delete a Deadline](/pt/reference/reporter/delete-deadline) (`DELETE /v1/deadlines/{id}`). Uma requisição bem-sucedida retorna `204 No Content`. Referência da API: [Delete a Deadline](/pt/reference/reporter/delete-deadline) ## Marcando um prazo como entregue *** Quando o relatório por trás de um prazo for arquivado ou enviado, marque o prazo como entregue com o endpoint [Deliver a Deadline](/pt/reference/reporter/deliver-deadline) (`PATCH /v1/deadlines/{id}/deliver`). Esta é a ação que fecha o ciclo no fluxo de acompanhamento: ela move o `status` do prazo para `delivered` e carimba `deliveredAt`. ```json theme={null} { "delivered": true } ``` Como `delivered` é um booleano, o mesmo endpoint também pode reverter a ação — envie `"delivered": false` para reabrir um prazo que foi marcado como entregue por engano. Uma requisição bem-sucedida retorna `200 OK` com o prazo atualizado. Entregar um prazo é apenas uma ação de acompanhamento. Ela registra que a obrigação foi cumprida — não gera nem envia o relatório subjacente. Gere o relatório pelo [ciclo de vida de relatórios](/pt/reporter/reporter-quick-start) e, em seguida, marque o prazo como entregue para manter seu rastreador preciso. Referência da API: [Deliver a Deadline](/pt/reference/reporter/deliver-deadline) ## Como os prazos se encaixam no fluxo *** Uma obrigação típica passa por estes estados: Registre a obrigação com sua data de vencimento, frequência e template opcional. Ele aparece como `pending` até a data de vencimento e, em seguida, como `overdue` se o relatório não tiver sido entregue a tempo. Produza o relatório pelo [ciclo de vida de relatórios](/pt/reporter/reporter-quick-start) normal, usando o template vinculado. Chame o endpoint de entrega para definir o `status` como `delivered` e registrar `deliveredAt`. ## Próximos passos *** Percorra o ciclo de vida de relatórios que os prazos acompanham. Construa os templates que cumprem seus prazos. Templates prontos para uso para relatórios regulatórios brasileiros. Referência completa de requisição e resposta para cada endpoint de prazo.