Seu Template de Dados de Processamento de Pagamentos
Seu Template de Dados de Processamento de Pagamentos
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Guia de extração para ACI Worldwide
Atributos de Processamento de Pagamentos
| Nome | Descrição | ||
|---|---|---|---|
| Event Timestamp EventTimestamp | A data e hora específica em que a atividade ocorreu. | ||
| Descrição Registra o momento exato em que um evento ocorreu no ambiente ACI. É usado para calcular métricas de tempo, como ciclos e taxas de processamento. A alta precisão é preferível para sequenciar etapas automáticas rápidas. Por que é importante Essencial para ordenar eventos e calcular durações de desempenho. Onde obter Consulte as colunas 'Created Date' ou 'Update Date' no histórico de transações ou tabelas de auditoria. Exemplos 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| ID da Transação de Pagamento PaymentTransactionId | O identificador exclusivo da instrução de pagamento no sistema ACI. | ||
| Descrição Serve como a chave central da análise, vinculando todos os eventos de um pagamento. Em sistemas ACI (como MTS ou UPP), corresponde ao número de referência único. Permite reconstruir toda a jornada do pagamento, da solicitação à liquidação. Por que é importante É o ID do Caso fundamental necessário para agrupar eventos discretos em instâncias de processo. Onde obter Verifique as tabelas de cabeçalho de transação, geralmente rotuladas como TRN_REF, REFERENCE_NUM ou UUID no log principal. Exemplos TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Nome da Atividade ActivityName | A etapa específica ou mudança de status ocorrida no ciclo do pagamento. | ||
| Descrição Este atributo define o nó do evento no mapa de processo. Na ACI, costuma derivar de códigos de status ou mudanças de estado no workflow. O mapeamento preciso desses estados técnicos para atividades de negócio legíveis é crucial. Por que é importante Define o fluxo do processo e é necessário para visualizar a sequência de operações. Onde obter Derivado de Códigos de Status (ex: 100=Criado, 200=Validado) ou colunas de Ação no Log de Auditoria. Exemplos Solicitação de Pagamento CriadaPagamento AutorizadoPagamento LiquidadoFalha no Pagamento | |||
| Canal de Processamento ProcessingChannel | O canal pelo qual o pagamento foi iniciado. | ||
| Descrição Indica o ponto de entrada do pagamento, como Mobile, Portal Web, API ou Upload de Arquivo. Ajuda na 'Análise de Variantes' para ver se canais específicos são mais propensos a erros. Por que é importante Segmenta o desempenho por método de entrada. Onde obter Cabeçalho da transação, em colunas como CHANNEL, SOURCE_TYPE ou INPUT_METHOD. Exemplos SWIFTInternet BankingMobile AppUpload de Arquivo | |||
| Código de Erro ErrorCode | O código gerado quando um pagamento falha ou exige reparo. | ||
| Descrição Captura o motivo específico para um evento de 'Falha no Pagamento' ou 'Erro Identificado'. Agrupar por este atributo no dashboard permite identificar as causas raiz mais comuns (ex: 'Saldo Insuficiente', 'Conta Inválida'). Por que é importante Essencial para a Análise de Causa Raiz de falhas no processo. Onde obter Logs de erro ou colunas de motivo de status, geralmente REASON_CODE ou RETURN_CODE. Exemplos R01AM04BE05TECH_ERR_001 | |||
| Data de Vencimento do Pagamento PaymentDueDate | A data limite para a liquidação ser considerada pontual. | ||
| Descrição Armazena a data de execução solicitada ou contratual. Ela é comparada com a data real de liquidação para calcular o KPI de 'Taxa de Pagamento no Prazo' e alimentar o dashboard de conformidade. Por que é importante O referencial para medir a conformidade de SLA e o desempenho no prazo. Onde obter Instruções da transação, como VALUE_DATE, EXECUTION_DATE ou DUE_DATE. Exemplos 2023-11-012023-11-05 | |||
| Departamento Department | O departamento interno responsável pela atividade atual. | ||
| Descrição Mapeia o Por que é importante Agrega o desempenho por função de negócio. Onde obter Derivado de tabelas de Usuários ou mapeamento de Hierarquia Organizacional. Exemplos OperaçõesComplianceTesourariaSuporte de TI | |||
| É Retrabalho IsRework | Flag indicando se o pagamento passou por atividades repetitivas. | ||
| Descrição Uma flag booleana calculada durante o processamento de dados. É definida como verdadeira se atividades como 'Detalhes de Pagamento Validados' ocorrerem mais de uma vez ou se um loop de erro for detectado. Isso alimenta o KPI de 'Taxa de Retrabalho de Pagamento'. Por que é importante Identifica rapidamente casos ineficientes sem a necessidade de consultas complexas de processo. Onde obter Computado no pipeline de dados verificando atividades duplicadas por caso. Exemplos verdadeirofalse | |||
| Moeda de Pagamento PaymentCurrency | O código ISO da moeda para o valor do pagamento. | ||
| Descrição Especifica a moeda do Por que é importante Necessário para interpretar o valor do pagamento corretamente. Onde obter Tabelas de detalhes, campos como CCY, CURRENCY_CODE ou ISO_CODE. Exemplos USDEURGBPJPY | |||
| Tempo de Ciclo Ponta a Ponta EndToEndCycleTime | A duração total da criação da solicitação até a liquidação. | ||
| Descrição Calcula a diferença de tempo entre 'Solicitação de Pagamento Criada' e 'Pagamento Liquidado'. Serve como métrica principal para o KPI de 'Tempo Médio de Ciclo de Transação' e análise geral de eficiência. Por que é importante A métrica principal de velocidade do processo. Onde obter Calculado: Timestamp(Pagamento Liquidado) - Timestamp(Solicitação de Pagamento Criada). Exemplos 2 dias 4 horas45 minutos12 segundos | |||
| Tipo de Pagamento PaymentType | A classificação do instrumento de pagamento. | ||
| Descrição Categoriza o pagamento (ex: Wire, ACH, SEPA, RTGS). Diferentes tipos têm SLAs e fluxos muito distintos. Este atributo é uma dimensão primária para filtrar o dashboard de 'Tempo de Ciclo de Pagamento Ponta a Ponta'. Por que é importante Crítico para distinguir entre fluxos de pagamento de alta velocidade e em lote (batch). Onde obter Cabeçalho da transação, campos como PMT_TYPE, INSTRUMENT_TYPE ou SERVICE_ID. Exemplos Domestic WireInternational WireACH CreditInstant Payment | |||
| Usuário do Evento EventUser | O ID do usuário ou agente do sistema responsável pela atividade. | ||
| Descrição Captura quem realizou a ação — seja um usuário humano (ex: aprovações) ou uma conta de sistema (ex: liquidação automática). Este atributo é vital para a 'Análise de Gargalos' para identificar se usuários ou filas específicas estão sobrecarregados. Por que é importante Permite análise de recursos e auditoria de segregação de funções. Onde obter Logs de auditoria ou colunas 'UpdatedBy' nas tabelas de transação. Exemplos SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Valor do Pagamento PaymentAmount | O valor monetário da transação de pagamento. | ||
| Descrição Indica o valor financeiro transferido. É um campo crítico para analisar o volume de processamento e priorizar gargalos. Pagamentos de alto valor costumam ter fluxos de aprovação mais rigorosos. Por que é importante Permite a segmentação por valor e o cálculo do volume total processado. Onde obter Tabelas de detalhes, campos como AMT, TRANS_AMOUNT ou PRINCIPAL_AMOUNT. Exemplos 1500.00250000.5050,001000000.00 | |||
| ID de Conciliação ReconciliationId | Identificador que vincula o pagamento ao livro razão ou registro de reconciliação. | ||
| Descrição ID preenchido na atividade 'Pagamento Conciliado'. Garante que o pagamento no motor de processamento bate com o lançamento contábil. A ausência deste ID em pagamentos liquidados indica falha na conciliação. Por que é importante Crítico para o dashboard de 'Eficiência de Reconciliação de Pagamentos'. Onde obter Tabelas de conciliação ou campos específicos como RECON_REF ou GL_REF. Exemplos REC-9921GL-Entry-2023-11 | |||
| Nome do Beneficiário BeneficiaryName | O nome da entidade que recebe o pagamento. | ||
| Descrição Identifica a contraparte na transação. Analisar este campo ajuda a identificar fornecedores ou clientes específicos associados a altos índices de retrabalho ou atrasos. Por que é importante Identifica o destino do pagamento, útil para análises centradas no cliente. Onde obter Linhas de detalhes do pagamento, campos como CREDITOR_NAME, BENE_NAME ou PAYEE. Exemplos Acme CorpGlobal Supplies LtdJohn Smith | |||
| Pagamento Atrasado? IsPaymentLate | Flag indicando se o pagamento foi liquidado após a data de vencimento. | ||
| Descrição Uma flag booleana que compara a data real de liquidação com a Por que é importante Simplifica relatórios de conformidade. Onde obter Calculado: SettlementDate > PaymentDueDate. Exemplos verdadeirofalse | |||
| Região de Origem OriginatingRegion | A região geográfica de origem da solicitação de pagamento. | ||
| Descrição Indica a localização física ou lógica do solicitante. Útil para verificar se regiões específicas seguem caminhos não padronizados ou têm taxas de rejeição maiores. Por que é importante Fornece contexto geográfico para o desempenho do processo. Onde obter Cabeçalho da transação, geralmente derivado do código da filial ou país. Exemplos América do NorteEMEAAPAC | |||
| Sistema de Origem SourceSystem | O nome do sistema de origem dos dados do evento. | ||
| Descrição Identifica o aplicativo ou módulo específico no ecossistema ACI Worldwide (ex: ACI MTS, ACI UPF) ou sistemas externos envolvidos. Isso é crucial ao cruzar dados de múltiplos livros ou quando o pagamento passa por câmaras de compensação externas. Por que é importante Fornece contexto sobre a origem da extração dos dados, útil para depurar a linhagem de dados. Onde obter Codificado durante a extração ou derivado de uma coluna SystemID, caso existam múltiplas instâncias. Exemplos ACI MTSACI UPPSAP GLSwift Gateway | |||
| Tempo de Ciclo de Aprovação ApprovalCycleTime | Duração gasta na fase de aprovação. | ||
| Descrição Calcula o tempo entre 'Pagamento Enviado para Aprovação' e 'Pagamento Aprovado' (ou Rejeitado). Esta métrica alimenta o dashboard de 'Análise de Tempo de Ciclo de Aprovação', destacando atrasos em etapas de decisão humana. Por que é importante Isola a parte do processo que depende de intervenção humana. Onde obter Calculado: Timestamp(Pagamento Aprovado) - Timestamp(Pagamento Enviado para Aprovação). Exemplos 4 horas15 minutos | |||
| Última Atualização de Dados LastDataUpdate | O timestamp de quando o registro foi extraído ou atualizado no modelo de dados. | ||
| Descrição Acompanha a atualização dos dados. Representa o momento técnico da ingestão, garantindo que o analista saiba se está vendo dados em tempo real ou históricos. Por que é importante Garante a atualidade dos dados e ajuda a identificar dados obsoletos nos dashboards. Onde obter Hora do sistema no momento da execução do script ETL. Exemplos 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Atividades de Processamento de Pagamentos
| Atividade | Descrição | ||
|---|---|---|---|
| Erro de Pagamento Identificado | Indica que o sistema detectou um problema com o pagamento, como dados inválidos ou alerta de conformidade. Este evento costuma ser registrado explicitamente com um código de erro. | ||
| Por que é importante Este ponto inicia toda a análise de retrabalho e exceções. É essencial para os dashboards de 'Análise de Falhas' e 'Tempo de Resolução de Erros'. Onde obter Procure entradas explícitas em uma tabela de log de erros ou mudança para 'Erro' ou 'Requer Correção' na tabela de transações, vinculadas ao ID da Transação. Captura Um evento explícito é registrado quando o motor de validação ou processamento do sistema sinaliza um erro. Tipo de evento explicit | |||
| Fundos Transferidos | Indica que foi recebida a confirmação da rede de pagamento de que os fundos foram debitados com sucesso da conta do pagador. Geralmente capturado via mensagem de status da rede. | ||
| Por que é importante Confirma a execução bem-sucedida do pagamento pela rede externa. Marca o início do período de liquidação e é um dado essencial para o KPI de 'Tempo Médio de Liquidação'. Onde obter Evento explícito disparado por mensagem de status (ex: MT103 do SWIFT ou confirmação ACH) que atualiza o registro do pagamento. Captura Registrado ao receber uma mensagem de confirmação externa da rede de compensação. Tipo de evento explicit | |||
| Pagamento Aprovado | Um marco importante onde um usuário autorizado aprova o pagamento, permitindo que ele prossiga para a execução. Geralmente capturado como um evento explícito quando o aprovador executa a ação na interface do sistema. | ||
| Por que é importante Este é um ponto de controle crítico e, muitas vezes, um gargalo. Analisar esperas antes desta etapa ajuda a identificar chances de acelerar os pagamentos. Onde obter Procure um evento explícito em uma tabela de log de aprovação ou uma mudança para 'Aprovado' na tabela principal vinculada a uma ação de usuário e timestamp. Captura Registrado quando um usuário autorizado conclui a ação de aprovação no sistema. Tipo de evento explicit | |||
| Pagamento Autorizado | Representa a autorização do sistema após a aprovação humana, verificando fundos ou regras de fraude. Pode ser um log explícito ou inferido pelo status de pronto para execução. | ||
| Por que é importante Ponto de controle crítico antes da movimentação dos fundos. Atrasos aqui podem indicar problemas de performance ou falhas em subsistemas de conformidade e fraude. Onde obter Verifique um log explícito em um log de processamento ou segurança do sistema. Alternativamente, pode ser inferido por uma atualização de status de 'Aprovado' para 'Autorizado para Pagamento'. Captura Registrado pelo motor de pagamentos do sistema após passar pelas verificações internas finais. Tipo de evento explicit | |||
| Pagamento Liquidado | A confirmação final de que o processo terminou e os fundos foram creditados ao beneficiário. Evento crítico que representa o fim bem-sucedido do ciclo de vida do pagamento. | ||
| Por que é importante Evento final de sucesso principal. Usado para calcular ciclos e taxas de transferência, sendo essencial para quase todos os Dashboards de desempenho. Onde obter Geralmente um evento explícito gravado ao receber a confirmação final da rede ou ao atualizar o razão interno. Captura Registrado ao receber um arquivo ou mensagem de liquidação final, atualizando o status para 'Liquidado'. Tipo de evento explicit | |||
| Solicitação de Pagamento Criada | Marca o início de uma nova transação na ACI Worldwide. Geralmente é um evento explícito gravado quando um usuário ou sistema envia uma solicitação de pagamento, gerando um ID único. | ||
| Por que é importante Evento inicial principal. Analisar o tempo desta atividade até a conclusão define o ciclo de vida ponta a ponta, essencial para medir a eficiência geral. Onde obter Provável evento explícito na tabela de transações ou log dedicado da ACI. Deve-se buscar o timestamp de criação associado ao ID da transação. Captura Identificado pelo registro de criação ou um evento explícito de 'Criar' no log de transações. Tipo de evento explicit | |||
| Detalhes do Pagamento Validados | Representa a conclusão de verificações automáticas ou manuais para garantir que detalhes como beneficiário e códigos bancários estejam corretos. Esta atividade costuma ser inferida pela mudança de status de 'Novo' para 'Validado'. | ||
| Por que é importante Mede a eficiência das validações iniciais. Atrasos aqui geram gargalos e aumentam a chance de erros de pagamento nas etapas seguintes. Onde obter Inferido de campos de mudança de status na tabela principal. Compare os timestamps entre o status 'Criado' e um status subsequente como 'Validado'. Captura Inferido por uma mudança no campo de status, por exemplo, de 'Inserido' para 'Validado'. Tipo de evento inferred | |||
| Erro de Pagamento Resolvido | Marca o ponto em que um erro identificado foi corrigido por um usuário e o pagamento foi reenviado. Costuma ser inferido quando o status muda de erro para processamento normal. | ||
| Por que é importante Esta atividade encerra o loop de exceção. O tempo entre 'Erro de Pagamento Identificado' e este evento define o ciclo de resolução, métrica vital de eficiência. Onde obter Inferido por uma mudança de status de um estado de 'Erro' para um estado de processamento como 'Aprovação Pendente' ou 'Validado'. Também pode ser um log de ação explícita do usuário. Captura Inferido por uma mudança de status saindo de um estado de erro, indicando que uma correção foi feita. Tipo de evento inferred | |||
| Falha no Pagamento | Um status terminal indicando que o pagamento não pôde ser concluído devido a um problema irrecuperável. É diferente de um erro resolvível e representa um estado final de falha definitiva. | ||
| Por que é importante Rastrear este evento final é crucial para calcular a taxa de falha. Analisar os motivos ajuda a melhorar a qualidade dos dados e as regras do processo. Onde obter Inferido por um status terminal final como 'Falhou', 'Cancelado' ou 'Rejeitado pelo Banco', que não sofre alteração posterior. Captura Inferido por um status de falha terminal no registro do pagamento. Tipo de evento inferred | |||
| Instrução de Pagamento Enviada | Marca o ponto em que a instrução de pagamento é compilada e transmitida para uma rede externa (SWIFT, ACH, SEPA). Os sistemas ACI registram essa entrega para fins de auditoria. | ||
| Por que é importante Este é o 'ponto de não retorno' para muitos pagamentos. Rastreá-lo ajuda a medir o tempo interno antes das dependências externas assumirem. Onde obter Quase sempre um evento explícito nos logs da ACI, incluindo muitas vezes um número de referência específico da rede. Captura Uma entrada de log explícita é criada quando a mensagem de pagamento é enviada para a rede externa. Tipo de evento explicit | |||
| Pagamento Conciliado | Representa a etapa contábil final onde a transação na ACI é batida com extratos bancários ou lançamentos no razão. Pode ser um evento explícito ou inferido por mudança de status. | ||
| Por que é importante Mede a eficiência do processo de conciliação de back-office. Atrasos aqui afetam a precisão contábil e podem ocultar problemas de liquidação. Onde obter Informação que pode vir de um módulo de conciliação da ACI ou de um ERP externo, capturada via atualização de status para 'Conciliado'. Captura Inferido por uma atualização de status final 'Reconciliado', ou por dados de reconciliação vinculados pelo ID do Pagamento. Tipo de evento inferred | |||
| Pagamento Confirmado | Representa o reconhecimento interno de que o pagamento foi processado e a confirmação recebida. Geralmente serve como gatilho para notificar o beneficiário ou outros sistemas. | ||
| Por que é importante Marco crucial para medir conformidade e taxa de pagamento no prazo. Fornece o timestamp exato de quando o pagamento é considerado executado. Onde obter Geralmente inferido pela mudança de status para 'Confirmado' ou 'Concluído' após o recebimento da confirmação da rede externa. Captura Inferido por uma mudança de status para 'Confirmado' ou 'Processado'. Tipo de evento inferred | |||
| Pagamento Enviado para Aprovação | Indica que o pagamento passou pela validação inicial e foi roteado para aprovação gerencial ou financeira. Geralmente capturado por uma mudança de status no workflow. | ||
| Por que é importante Marca o início do subprocesso de aprovação. Medir o tempo até 'Pagamento Aprovado' é crítico para a análise de ciclos de aprovação. Onde obter Derivado de uma alteração no campo de status do pagamento, como a mudança para 'Aprovação Pendente'. Captura Inferido por uma mudança de status para 'Aprovação Pendente' ou similar, com o timestamp correspondente. Tipo de evento inferred | |||
| Pagamento Rejeitado | Ocorre quando um aprovador nega a solicitação, exigindo correção e reenvio. É um evento explícito que trava o progresso e inicia um ciclo de retrabalho. | ||
| Por que é importante Identifica retrabalho e ineficiências. Rastrear a frequência de rejeições ajuda a diagnosticar problemas na qualidade inicial dos dados ou nas políticas de submissão. Onde obter Capturado como um evento explícito no log de aprovação ou uma mudança de status para 'Rejeitado' na tabela de transações. O evento pode incluir um código de motivo para a rejeição. Captura Registrado quando um aprovador conclui a ação de rejeição no sistema. Tipo de evento explicit | |||
Guias de Extração
Etapas
Acesse o Ambiente do Banco de Dados: Faça login na instância do SQL Server que hospeda o banco de dados ACI Postilion Realtime usando o SQL Server Management Studio (SSMS) ou um cliente compatível.
Identifique as Tabelas Principais: Localize as tabelas
post_tran(log de transações) epost_tran_cust(extensão de dados personalizados). Certifique-se de ter permissões deSELECTnesses objetos.Determine o Identificador de Caso: Esta extração utiliza o
retrieval_reference_nrcomo oPaymentTransactionId. Se sua implementação usar uma chave exclusiva diferente (comosystem_trace_audit_nrcombinado comtransmission_date_time), ajuste a seleção da consulta adequadamente.Configure os Parâmetros de Filtro: Abra a consulta fornecida abaixo. Localize as variáveis
@StartDatee@EndDateno topo do script. Defina-as para a janela de extração desejada (ex: os últimos 30 a 90 dias) para otimizar o desempenho.Revise a Lógica das Atividades: A consulta mapeia os tipos de mensagem ISO 8583 (ex: 0200, 0210) e códigos de resposta para as 14 atividades de Process Mining necessárias. Revise as instruções
CASEpara garantir que estejam alinhadas com suas configurações específicas de interface ACI.Execute a Consulta: Execute o script completo. A consulta utiliza
UNION ALLpara normalizar diferentes estados de transação em um único formato de log de eventos.Verifique a Saída de Dados: Verifique nos resultados as colunas obrigatórias:
PaymentTransactionId,ActivityNameeEventTimestamp. Garanta que nenhum campo crítico contenha valoresNULLinesperadamente.Exporte os Dados: Clique com o botão direito na grade de resultados no SSMS e salve a saída como um arquivo CSV (ex:
ACI_Payments_EventLog.csv).Formate para o ProcessMind: Abra o CSV e verifique se o
EventTimestampestá em um formato padrão (AAAA-MM-DD HH:MM:SS) e se oPaymentAmountcontém apenas valores numéricos.Upload: Importe o CSV verificado para o ProcessMind, mapeando as colunas para ID do Caso (Case ID), Atividade e Timestamp, respectivamente.
Configuração
- Intervalo de Datas: As tabelas
post_tranda ACI crescem muito rapidamente. É altamente recomendável limitar a extração a uma janela móvel de 3 meses ou usar troca de partição, se disponível. - Códigos de Resposta: A consulta assume que
rsp_code = '00'indica sucesso. Se sua instituição utiliza códigos diferentes para aprovação/sucesso (ex: '08' ou '10'), atualize os filtros. - Tipos de Mensagem (ISO 8583): O script depende de tipos de mensagem padrão (0100/0200 para Solicitações, 0210 para Respostas). Tipos de mensagens personalizados definidos em sua configuração
source_node_namepodem exigir ajustes. - Performance do Sistema: Esta consulta usa dicas
NOLOCKpara evitar o bloqueio do processamento de transações em tempo real. Não remova essas dicas em ambiente de produção. - Moedas: Os valores são extraídos como números brutos. Certifique-se de que o
tran_currency_codeseja usado se a normalização multimoeda for necessária durante a análise.
a Consulta de Exemplo sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL;