> ## 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. # Cómo funciona Lerian SRC > Cómo Lerian SRC acepta una consulta, la envía a BACEN, trata la respuesta o el rechazo de BACEN, reintenta y mantiene los registros de la institución, la pista de evidencias y los casos de operador. Una consulta tiene uno de tres estados: `pending`, `completed` o `failed`. Lerian SRC acepta la consulta de inmediato y trabaja con BACEN después de responder a tu solicitud. ## Solicitud de consulta *** Tu sistema envía `POST /v1/src/consultations` con un header `X-Idempotency`. El cuerpo indica un documento y las preguntas que se hacen sobre él. | Campo | Significado | | - | - | | `document` | El CPF o CNPJ que se consulta. | | `documentType` | `CPF` o `CNPJ`. Debe corresponder al documento. | | `protectionTypes` | `account_opening`, `ownership_change` o ambos. | | `motivation` | El motivo de la consulta. `motivation.reference` es obligatorio. | | `subjectRole` | Opcional: `individual`, `company`, `holder` o `representative`. Sin él, Lerian SRC toma el rol de `documentType`. | | `companyConsultationId` | El id de la consulta de la empresa. Obligatorio para `holder` y `representative`. | Un `holder` o un `representative` es una persona que consultas para una empresa. Envía primero la consulta de la empresa. Luego envía la consulta de la persona, con `companyConsultationId` definido con el id que devolvió la consulta de la empresa. Una solicitud que no cumple estas reglas devuelve `422` con un código de `SRC-0004` a `SRC-0008`. Lerian SRC verifica la solicitud antes de aceptarla. Verifica los dígitos verificadores, el tipo de documento, los tipos de protección y la motivación. Una solicitud que no pasa una de estas verificaciones devuelve `422` con el código `SRC-0002`, y Lerian SRC no envía nada a BACEN. Una solicitud aceptada devuelve `202` con el `id` de la consulta y el estado `pending`. Lerian SRC almacena la consulta antes de enviar algo a BACEN, y publica el evento de aceptación. ## SRC0001: la consulta a BACEN *** Lerian SRC envía cada consulta aceptada a BACEN como un mensaje SRC0001. Cada 15 segundos, toma hasta 25 consultas que esperan su envío. Cada mensaje lleva el número de operación de la consulta. La API lo devuelve como `regulatoryOperationNumber`. Lerian SRC verifica cada mensaje contra el esquema de mensajes de BACEN antes de enviarlo. Si el mensaje no es válido para BACEN, Lerian SRC no lo envía. La consulta termina como `failed` con el código de rechazo `SRC-OUTBOUND-INVALID`, y Lerian SRC abre un caso de operador `invalid_outbound`. ## SRC0001R1: la respuesta de BACEN *** BACEN responde con un mensaje SRC0001R1. La respuesta lleva el código de control de BACEN y un veredicto para cada tipo de protección. Lerian SRC asocia la respuesta con su consulta y almacena los veredictos. La consulta pasa a `completed`, y Lerian SRC publica el evento de finalización. Un veredicto con `permitted` definido como `false` significa una restricción activa. Una respuesta que no corresponde a ninguna consulta del despliegue abre un caso de operador `orphan_response`. ## SRC0001E: el rechazo de BACEN *** BACEN puede rechazar una consulta con un mensaje SRC0001E. Lerian SRC pone el código de rechazo en una de tres clases: * **`transient`**: el código indica un estado temporal del riel. Lerian SRC envía la consulta de nuevo, dentro del presupuesto de intentos. Los códigos transitorios son `EGEN0021`, `EGEN0050`, `EGEN0152`, `EGEN0300`, `EGEN0301` y `EGEN1105`. * **`permanent`**: la consulta termina como `failed`. Corrige la causa y envía una nueva solicitud. * **`unknown`**: Lerian SRC no reconoce el código. La consulta termina como `failed`, igual que con un código permanente. Una consulta fallida lleva el código tal como BACEN lo envió, en `rejection.code`, y su clase en `rejection.classification`. Lerian SRC publica el evento de falla. ## Reintentos e indisponibilidad de BACEN *** Cuando un envío falla, o BACEN da un rechazo transitorio, Lerian SRC envía la consulta de nuevo. Si BACEN no responde a tiempo, Lerian SRC también envía la consulta de nuevo. Cada envío cuenta como un intento. Tres claves de configuración en tiempo de ejecución definen el presupuesto de intentos: | Clave | Predeterminado | Significado | | - | - | - | | `src.dispatch.max_attempts` | `8` | Intentos para cada consulta, de 1 a 20. | | `src.dispatch.backoff_initial` | `1m` | Espera antes del primer reintento, de `1s` a `1h`. | | `src.dispatch.backoff_ceiling` | `30m` | Espera más larga entre dos intentos, de `1m` a `24h`. | La espera se duplica después de cada intento, hasta el tope. Lerian SRC espera una respuesta durante 30 minutos, o durante el tope cuando el tope es más largo. Cuando una consulta usa todo su presupuesto, Lerian SRC deja de enviarla y abre un caso de operador `budget_exhausted`. La consulta sigue en `pending`. Cuando BACEN o el canal IBM MQ no está disponible, la API no devuelve un error. Lerian SRC sigue aceptando consultas, y estas quedan en `pending`. ## Registro de la institución *** Después de que una consulta se completa con una restricción activa, tu institución presenta un registro con `POST /v1/src/consultations/{id}/institution-record`. El registro tiene uno de dos tipos: | Tipo | Cuándo presentarlo | Campos que necesita | | - | - | - | | `exceptional_proceed` | Tu institución siguió con el contrato a pesar de la restricción activa. | `justification` y `circumstance` | | `refusal_explanation` | Tu institución rechazó, y el registro guarda la explicación que dio a la parte interesada. | `explanation` | Los dos tipos también necesitan `registeredBy`, que indica quién presenta el registro. Una presentación exitosa devuelve `201`. El registro no cambia los veredictos. Una consulta guarda un registro. Un segundo registro devuelve `409` con el código `SRC-0101`. Una consulta que no se completó con una restricción activa devuelve `409` con el código `SRC-0102`. ## Pista de evidencias *** Lerian SRC mantiene una pista de evidencias para cada consulta. | Operación | Qué devuelve | | - | - | | `GET /v1/src/evidence/consultations/{id}` | La pista de una consulta, registro por registro. | | `POST /v1/src/evidence` | Las consultas que tienen una pista, encontradas por período, id de consulta, código de control de BACEN o documento. | | `POST /v1/src/evidence/records` | Los registros individuales, encontrados por documento o por tipo de registro. | Para corregir un registro, envía `POST /v1/src/evidence/consultations/{id}/corrections`. Pon la posición del registro en `correctsSequence`, y el motivo en `reason`. Lerian SRC agrega la corrección a la pista como un nuevo registro y devuelve `201`. Si una corrección concurrente de la misma pista ocupa la posición primero, la solicitud devuelve `409` con el código `SRC-0104`. Lerian SRC no escribe nada. Reintenta la corrección.

Casos de operador

*** Un caso de operador es un elemento que tu back office debe ver. Cada caso indica su `leg`. Por ejemplo: | Leg | Qué pasó | Qué hace el cierre del caso | | - | - | - | | `invalid_outbound` | Lerian SRC se negó a enviar un mensaje que no es válido para BACEN. BACEN no lo recibió. | Registra que una persona vio el caso. Lerian SRC no repara nada y no envía nada. Corrige la causa y envía una nueva solicitud. | | `orphan_response` | Un mensaje de BACEN no correspondió a ninguna consulta del despliegue. | Registra que una persona examinó el mensaje. | | `budget_exhausted` | Una consulta usó todo su presupuesto de intentos. | No puedes cerrarlo. Si la respuesta de BACEN llega después, Lerian SRC registra la respuesta y el caso sale de la cola. | [Operación de Lerian SRC](/es/rails/src/src-operations#operator-cases) explica cómo listar y cerrar casos. Lerian SRC también publica un evento en cada cambio de estado. [Integración con Lerian SRC](/es/rails/src/src-integration#polling-and-events) lista los eventos. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.