Dados e relatórios

Cada transferência gera uma trilha de auditoria completa. Esta página descreve os dados disponíveis para relatórios, reconciliação e conformidade.

​

Quais dados são registrados por transferência

---

​

Ciclo de vida do status da transferência

---

​

TED OUT

• Cliente confirmou (CREATED) — o cliente confirmou a transferência, agora aguardando envio
• Enviada à rede bancária (PENDING) — mensagem enviada à JD Consultores, aguardando reconhecimento
• Processamento bancário (PROCESSING) — JD aceitou a transferência e a roteia
• Liquidada (COMPLETED) — transferência liquidada com sucesso no banco de destino
• Rejeitada (REJECTED) — JD retornou um erro de negócio (ex: dados de conta inválidos)
• Falhou (FAILED) — falha técnica (timeout ou indisponibilidade do serviço)
• Cancelada (CANCELLED) — cliente cancelou antes de a transferência ser enviada

​

TED IN

• Transferência detectada (RECEIVED) — mensagem recebida persistida, aguardando processamento interno
• Destinatário validado (PROCESSING) — o sistema credita a conta destinatária
• Valor creditado (COMPLETED) — conta destinatária creditada com sucesso

​

P2P

• Confirmada (CREATED) — transferência iniciada entre contas internas
• Processando (PROCESSING) — transação Midaz em andamento
• Liquidada (COMPLETED) — ambas as contas atualizadas com sucesso
• Falhou (FAILED) — erro de processamento
• Cancelada (CANCELLED) — cancelada antes do início do processamento

​

Revisão da tarifa antes da confirmação (somente TED OUT)

---

Para TED OUT, os clientes passam por um fluxo de duas etapas:

• Aguardando confirmação — o plugin calculou e apresentou a tarifa. O cliente ainda não a confirmou
• Processada — o cliente confirmou e o plugin criou a transferência
• Expirada — 24 horas se passaram sem confirmação

Os clientes podem revisar o custo total (valor + tarifa) antes de confirmar a transferência.

​

Histórico de status

---

O plugin registra cada transição de status com um timestamp, o estado anterior, o novo estado e um motivo para erros e cancelamentos. Isso fornece uma trilha de auditoria completa para cada transferência — quem alterou o quê e quando. O campo changedBy registra o ator que fez a transição — por exemplo, um processo do sistema ou um worker de reconciliação. Pode estar vazio.

​

Campos de reconciliação

---

Use estes campos para conciliar registros de transferência com seus extratos bancários:

​

Retenção de dados

---

​

Consultando seus dados

---

Use Listar Transferências para consultar transferências com os seguintes filtros:

• Por intervalo de datas — filtre por createdAt ou completedAt
• Por tipo — TED OUT, TED IN ou P2P
• Por status — ex: apenas transferências COMPLETED para reconciliação, ou FAILED para investigação

​

Para desenvolvedores

---

​

Armazenamento

O plugin armazena os dados de transferência em PostgreSQL. O campo recipientDetails usa JSONB. Esse campo contém as diferentes estruturas de dados para os destinatários de TED OUT, TED IN e P2P. O campo recipientAccountId referencia uma conta Midaz quando o destinatário é interno. Cada tenant tem seu próprio banco de dados, e a organização é o filtro principal dentro de um tenant. O plugin mantém os seguintes índices para os padrões de consulta comuns:

• (midaz_organization_id, created_at) para listagens paginadas.
• (midaz_organization_id, status, created_at) para filtros baseados em status.
• (control_number, date) (único) para consultas de reconciliação da JD.

A tabela de auditoria transfer_status_history usa um índice para fluxos de auditoria e investigação:

• (transfer_id, changed_at DESC) para o histórico em nível de transferência.

​

Deduplicação de TED IN recebido

Antes de processar uma transferência TED IN, o plugin armazena a mensagem bruta da JD na tabela JDIncomingMessage. Isso permite que o plugin recupere as transferências recebidas se o serviço falhar durante o processamento. Para evitar o processamento duplicado, a tabela aplica uma restrição única em sequenceNumber (o NumCabSeq da JD). Se a JD reentregar a mesma mensagem, o plugin a identifica automaticamente como duplicada e a ignora.

​

O que o plugin envia para o Midaz

O plugin registra cada movimentação liquidada no Midaz como uma transação de ledger, mas o Midaz guarda o lançamento contábil — não os detalhes bancários da transferência. A identidade da contraparte (banco, agência, conta, nome e documento do titular) e as referências BACEN (controlNumber, clearingControlNumber) ficam apenas no registro Transfer do plugin. Em uma TED IN, o crédito entra no ledger a partir da conta @external/BRL; a identidade do remetente não é codificada na transação Midaz. O que a transação Midaz carrega são metadados de correlação: Um crédito de devolução carrega adicionalmente refundKind, originalTransferId, devolutionCode e os números de controle originais. A correlação funciona nos dois sentidos:

• O registro da transferência armazena o midazTransactionId, então Consultar Transferência retorna o detalhe bancário completo de qualquer lançamento no ledger.
• A transação Midaz armazena o transferId nos metadados, então você pode listar transações Midaz filtrando por metadata.transferId para encontrar o lançamento de uma transferência.

Os metadados personalizados que você envia ao iniciar uma transferência TED OUT ou P2P são mesclados na transação Midaz como estão. As chaves transferId, transferType e initiationId são reservadas — os valores do plugin sempre prevalecem.

​

Relacionamentos entre entidades

O modelo de domínio de TED segue estes relacionamentos:

• Cada Transfer pertence a uma única organização e pode ter múltiplos registros de TransferStatusHistory.
• Transferências TED OUT podem se originar de uma PaymentInitiation no fluxo de transferência de duas etapas.
• Cada JDIncomingMessage pode criar no máximo um Transfer do tipo TED_IN.