Datos e informes

Cada transferencia genera un registro de auditoría completo. Esta página describe los datos disponibles para informes, conciliación y cumplimiento.

​

Qué datos se registran por transferencia

---

​

Ciclo de vida del estado de la transferencia

---

​

TED OUT

• Cliente confirmó (CREATED): el plugin creó la transferencia y aplicó una retención sobre monto + comisión
• Preparando el envío (PENDING): el plugin prepara el mensaje para JD
• Procesamiento bancario (PROCESSING): el plugin envió la transferencia a JD y espera el resultado de la liquidación. Un timeout mantiene la transferencia aquí mientras la conciliación le pregunta a JD el resultado. Una transferencia que JD todavía responde como pendiente después de 24 horas en conciliación se queda aquí con la retención (estado de conciliación MANUAL_REVIEW)
• Liquidada (COMPLETED): el STR liquidó la transferencia y el plugin confirmó la retención
• Rechazada (REJECTED): JD o el STR rechazó la transferencia, y el plugin liberó la retención
• Fallida (FAILED): el ledger rechazó la retención, o la conciliación no pudo liquidar la transferencia. Cuando la conciliación se detiene después de su último intento, la retención se mantiene y un operador resuelve la transferencia (estado de conciliación MANUAL_REVIEW)
• Cancelada (CANCELLED): la transferencia se canceló desde CREATED o PENDING, y el plugin liberó la retención

​

TED IN

• Transferencia detectada (RECEIVED): mensaje entrante persistido, pendiente de procesamiento interno
• Receptor validado (PROCESSING): el sistema acredita la cuenta receptora
• Monto acreditado (COMPLETED): la cuenta receptora se acreditó con éxito
• Fallida (FAILED): el ledger rechazó el crédito, o el banco emisor hizo un chargeback de un crédito completado

​

P2P

• Confirmada (CREATED): el cliente confirmó la transferencia entre cuentas internas
• Procesando (PROCESSING): transacción de Midaz en curso
• Liquidada (COMPLETED): ambas cuentas se actualizaron con éxito
• Fallida (FAILED): el ledger rechazó el asiento

​

Revisión de la comisión antes de la confirmación

---

Para TED OUT y P2P, los clientes pasan por un flujo de dos pasos:

• Pendiente de confirmación: el plugin calculó y presentó la comisión. El cliente todavía no la confirmó
• Procesada: el cliente confirmó y el plugin creó la transferencia
• Expirada: la iniciación expiró sin confirmación. Una iniciación es válida durante 24 horas. Una iniciación de TED OUT expira antes, al cierre de la ventana de operación de ese día

Los clientes pueden revisar la comisión antes de confirmar la transferencia.

​

Historial de estados

---

El plugin registra cada transición de estado. Get Transfer las devuelve en statusHistory, cada una con el estado anterior, el estado nuevo, una marca de tiempo y un motivo cuando corresponde.

​

Campos de conciliación

---

Usa estos campos para hacer coincidir los registros de transferencia con tus extractos bancarios:

​

Retención de datos

---

​

Consulta de tus datos

---

Usa List Transfers para consultar transferencias con los siguientes filtros:

• Por fecha de creación: createdFrom y createdTo
• Por tipo: TED_OUT, TED_IN, un tipo de crédito al cliente, P2P, CROSS_CORE o CROSS_CORE_IN. TED_IN no selecciona los créditos al cliente ni los créditos entre cores
• Por estado: p. ej., solo transferencias COMPLETED para la conciliación, o FAILED para investigación
• Por estado de conciliación: reconciliationStatus
• Por monto: minAmount y maxAmount
• Por ledger: ledgerId. Coincide con el ledger del pagador o, en un P2P entre dos ledgers, con el ledger del destinatario

​

Para desarrolladores

---

​

Almacenamiento

El plugin guarda los datos de transferencia en PostgreSQL. El campo recipientAccountId referencia una cuenta de Midaz cuando el receptor es interno. La organización es el filtro principal.

​

Deduplicación de TED entrantes

Antes de procesar una transferencia TED IN, el plugin guarda el mensaje JD sin procesar. Esto permite que el plugin recupere las transferencias entrantes si el servicio falla durante el procesamiento. Cada mensaje guardado es único por el NumCabSeq de JD. Si JD vuelve a entregar el mismo mensaje, el plugin lo identifica como duplicado y lo ignora.

​

Qué envía el plugin a Midaz

El plugin registra cada movimiento liquidado en Midaz como una transacción del ledger, pero Midaz guarda el asiento contable, no los datos bancarios de la transferencia. La identidad de la contraparte (banco, sucursal, cuenta, nombre del titular y documento) y las referencias de BACEN (controlNumber, clearingControlNumber) viven solo en el registro Transfer del plugin. En una TED IN, el crédito entra al ledger desde la cuenta @external/BRL. La identidad del emisor no se codifica en la transacción de Midaz. El plugin escribe solo metadatos de correlación en la transacción de Midaz: La correlación funciona en ambas direcciones:

• El registro de la transferencia guarda midazTransactionId, así que Get Transfer devuelve el detalle bancario completo de cualquier asiento del ledger.
• La transacción de Midaz guarda el identificador de la transferencia en metadata.aggregateId, así que puedes filtrar transacciones de Midaz por él para encontrar el asiento del ledger de una transferencia.

Los metadatos personalizados que envías al iniciar una transferencia TED OUT o P2P nunca llegan a Midaz. El plugin los guarda en la transferencia y los devuelve como clientMetadata.

​

Relaciones entre entidades

El modelo de dominio de TED sigue estas relaciones:

• Cada Transfer pertenece a una sola organización de Midaz y puede tener varios registros TransferStatusHistory.
• Las transferencias TED OUT y P2P se originan en una PaymentInitiation en el flujo de transferencia de dos pasos.
• Cada JDIncomingMessage puede crear como máximo una Transfer de tipo TED_IN.