> ## 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. # Integración con Lerian Consignado — Dataprev > Cómo Lerian Consignado se integra con tu motor de crédito: los comandos que consume, los hechos de negocio que emite, su outbox agnóstico al destino y su idempotencia. Lerian Consignado — Dataprev es **event-first** en su borde con la plataforma. Consume comandos del motor de crédito y emite hechos de negocio. No hace llamadas directas al ledger ni aloja consumidores de webhook. El flujo de eventos es su contrato autoritativo, no su superficie REST. ## Comandos que consume *** El motor de crédito envía al gateway **cuatro comandos** como eventos por el backbone de streaming de la plataforma: * una **solicitud de margen** pide el margen de nómina disponible de un trabajador * una **solicitud de averbação** pide registrar un contrato firmado con Dataprev * una **solicitud de exclusão** pide cancelar una averbação registrada * una **solicitud de redirecionamento** pide redirigir un contrato a otro acreedor Los flujos de exclusão y redirecionamento siguen limitados a desarrollo. Ambos adaptadores se entregan como fakes y siguen deshabilitados por defecto hasta la homologación. Un comando que se decodifica pero **carece de su clave identificadora** — por ejemplo el CPF del trabajador — es terminal. El gateway lo envía a la cola de mensajes muertos y no lo relaya a Dataprev. ## Hechos que emite *** El gateway emite **quince hechos de negocio**: * una **oferta de solicitud de préstamo** descubierta (solicitação) — retransmitida para que el prestamista decida si oferta * el **margen** obtenido de un trabajador * una **alerta de ausencia del trabajador** (afastamento) — una por elemento de alerta en una lectura de margen * un testigo de **propuesta aceptada** — la lectura posterior a la averbação de lo que el riel registró * un resultado de **averbação confirmada** * un resultado de **averbação rechazada** * un traspaso de **contrato registrado** — el único hecho que registra un contrato aguas abajo * un hecho de **desembolso confirmado** — el cliente confirma que el trabajador ya recibió el pago * un resultado de **exclusão confirmada** * un resultado de **exclusão rechazada** * un registro de **conciliación** — uno por registro de escrituração o de liquidación * un **informe de situación laboral** de un trabajador * un resultado de **redirecionamento confirmado** * un resultado de **redirecionamento rechazado** * un hecho de **throughput modificado** — cambia la capacidad de solicitudes salientes del tenant Los hechos comparten una versión de esquema para todo el paquete, con una excepción: el testigo de propuesta aceptada lleva su propia versión mayor y publica en un tópico con sufijo de versión. La clave de catálogo de un hecho no es su nombre de tópico. El tópico se deriva del segmento de aplicación del propio gateway más el recurso y el evento del hecho. Consulta la [referencia de eventos de consignado](/es/reference/events/consignado) para el mapeo completo. ## Entrega agnóstica al destino *** El gateway escribe cada hecho en un **outbox transaccional** y relaya desde allí —nunca directo al broker, por ninguna vía. Publica cada hecho en su propio tópico, pero **no posee enrutamiento de consumidores**: un hub de streaming aguas abajo decide qué sistema recibe cada hecho. El mismo hecho puede distribuirse a un ledger, a un almacén de conciliación o a un sistema de préstamos. El gateway no sabe ni le importa quién lo consume. ## Sin acoplamiento directo con el ledger ni con webhooks *** El gateway **no hace llamadas directas a Midaz** y **no aloja consumidores de webhook**. El contacto con el prestatario fuera de la plataforma está fuera de alcance. Los sistemas de préstamos aguas abajo son dueños de la originación y de cualquier comunicación con el prestatario. ## En el transporte *** * **El dinero y las tasas cruzan como cadenas decimales**, nunca como coma flotante, lo que mantiene la precisión completa en el camino. * **Las marcas de tiempo son UTC, RFC 3339.** * **La identidad del trabajador viaja dentro de los registros de conciliación, nunca en la referencia visible en los logs.** El **número de contrato es la clave de coincidencia**, y cada registro puede llevar además el CPF y la matrícula del trabajador: un registro cuyo número de contrato no coincide con nada en el libro del consumidor es exactamente la excepción que el feed existe para levantar, así que el registro sigue nombrando al trabajador por el que movió dinero. El sujeto del evento queda como una referencia del riel y nunca lleva al trabajador. * El **repasse** de la CEF liquida **por movimiento diario, no por contrato**, así que la conciliación del lado bancario se basa en el identificador de la transferencia y no en el número de contrato. ## Semántica de entrega *** * **Idempotente por sujeto inmutable.** Cada registro y cada liquidación lleva un identificador inmutable. Reprocesarlo es un no-op aguas abajo. * **Al menos una vez.** El gateway entrega cada evento al menos una vez. La reentrega y los reinicios se deduplican a un no-op. * **Ramas independientes.** En la conciliación, el gateway procesa las ramas de escrituração y de repasse de forma independiente. Un fallo en una nunca bloquea la otra.