> ## 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 se integra el gateway — los dos comandos que consume del motor de crédito, los cinco hechos de negocio que emite, su entrega por outbox agnóstica al destino, la ausencia de acoplamiento directo con el ledger y con webhooks, y su semántica de transporte e 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. Su contrato autoritativo es el flujo de eventos, no su superficie REST.

## Comandos que consume

***

El gateway consume **dos comandos** del motor de crédito, transportados como eventos por el backbone de streaming de la plataforma:

* una **solicitud de margen**, que pide el margen de nómina disponible de un trabajador;
* una **solicitud de averbação**, que pide registrar un contrato firmado con Dataprev.

Un comando que se decodifica pero **le falta su clave identificadora** — por ejemplo el CPF del trabajador — es terminal: se envía a la cola de mensajes muertos en lugar de relayarse a Dataprev.

## Hechos que emite

***

El gateway emite **cinco hechos de negocio**:

* el **margen** obtenido de un trabajador;
* un resultado de **averbação confirmada**;
* un resultado de **averbação rechazada**;
* una señal de **propuesta aceptada**, que indica al sistema de préstamos aguas abajo que origine;
* un registro de **conciliación** — uno por registro de escrituração o de liquidación.

Cada hecho lleva una única versión de esquema para todo el paquete, estampada de forma idéntica en los cinco en lugar de versionarse por evento.

## Entrega agnóstica al destino

***

El gateway escribe cada hecho en un **outbox transaccional** y relaya desde allí. **No posee enrutamiento por destino**: 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 sin que el gateway sepa ni le importe 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: el hecho de **propuesta aceptada** es el límite de traspaso, tras el cual el sistema de préstamos aguas abajo es dueño 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, para no perder precisión en el camino.
* **Las marcas de tiempo son UTC, RFC 3339.**
* **Ningún CPF cruza el hecho de conciliación.** Esto se garantiza por construcción: los tipos de registro de conciliación no tienen campo de CPF, el CPF presente en la fuente de escrituração se descarta en el normalizador, y las pruebas verifican que el payload serializado no contiene ningún CPF. El **número de contrato es la clave de coincidencia**, así que no hace falta ningún identificador personal aguas abajo. (Los hechos de margen y de propuesta aceptada *sí* llevan un CPF, porque cada uno se asocia a un trabajador o a una propuesta específicos.)
* 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.** Los eventos se entregan al menos una vez; la reentrega y los reinicios se deduplican a un no-op.
* **Ramas independientes.** En la conciliación, las ramas de escrituração y de repasse se procesan de forma independiente — una que falle nunca bloquea la otra.