Seu Template de dados de processamento de pagamentos
Seu Template de dados de processamento de pagamentos
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração de dados da ACI Worldwide
Atributos do processamento de pagamentos
| Nome | Descrição | ||
|---|---|---|---|
| Data e hora do evento EventTimestamp | A data e a hora exatas em que a atividade ocorreu. | ||
| Descrição Este atributo registra o momento exato em que um evento ocorreu no ambiente ACI. Ele é usado para calcular todas as métricas baseadas em tempo, incluindo tempos de ciclo, duração das aprovações e taxas de processamento. É preferível usar alta precisão, em milissegundos, para ordenar corretamente etapas automatizadas que ocorrem em rápida sequência. Por que isso importa Essencial para ordenar eventos e calcular a duração das etapas. Onde encontrar Consulte as colunas 'Data de criação' ou 'Data de atualização' no histórico de transações ou nas 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 | Identificador exclusivo da instrução de pagamento no sistema ACI. | ||
| Descrição Este atributo é a chave central da análise de Process Mining, vinculando todos os eventos relacionados a uma única solicitação de pagamento. Nos sistemas ACI Worldwide, como MTS ou UPP, corresponde ao número de referência exclusivo atribuído à transação no momento do registro. Com ele, é possível reconstruir toda a jornada do pagamento, da solicitação inicial à validação, aprovação e liquidação final. Por que isso importa É o ID do caso fundamental para agrupar eventos individuais em instâncias do processo. Onde encontrar Verifique as tabelas de cabeçalho de transações, geralmente com campos chamados TRN_REF, REFERENCE_NUM ou UUID no log principal de transações. Exemplos TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Nome da atividade ActivityName | A etapa específica ou a mudança de status ocorrida no ciclo de vida do pagamento. | ||
| Descrição Este atributo define o nó do evento no mapa do processo, como 'Solicitação de pagamento criada' ou 'Fundos transferidos'. Nos sistemas ACI, costuma ser derivado de códigos de status, tipos de operação do log de auditoria ou mudanças de estado do fluxo de trabalho. Mapear corretamente esses estados técnicos para atividades de negócio compreensíveis é essencial para uma visualização útil. Por que isso importa Define o fluxo do processo e é necessário para visualizar a sequência de operações. Onde encontrar Derivado de códigos de status (por exemplo, 100=Criado, 200=Validado) ou de colunas de ação do log de auditoria. Exemplos Solicitação de pagamento criadaPagamento autorizadoPagamento liquidadoPagamento não realizado | |||
| Canal de processamento ProcessingChannel | O canal pelo qual o pagamento foi iniciado. | ||
| Descrição Indica o ponto de entrada do pagamento, como aplicativo móvel, portal web, API ou envio de arquivo. Na análise de variantes do processo de pagamento, ajuda a identificar se determinados canais estão mais sujeitos a erros ou atrasos. Por que isso importa Permite comparar a performance por método de entrada. Onde encontrar Cabeçalho da transação, geralmente em colunas chamadas CHANNEL, SOURCE_TYPE ou INPUT_METHOD. Exemplos SWIFTInternet bankingAplicativo móvelEnvio de arquivo | |||
| Código de erro ErrorCode | O código gerado quando um pagamento falha ou precisa ser corrigido. | ||
| Descrição Registra o motivo específico de um evento 'Pagamento não realizado' ou 'Erro no pagamento identificado'. Agrupar por esse atributo no Dashboard 'Análise de falhas e retrabalho em pagamentos' ajuda a identificar as causas raiz mais comuns das falhas, como 'Fundos insuficientes' ou 'Conta inválida'. Por que isso importa Essencial para a análise de causa raiz das falhas do processo. Onde encontrar Logs de erros ou colunas de motivo do status, geralmente REASON_CODE ou RETURN_CODE. Exemplos R01AM04BE05TECH_ERR_001 | |||
| Data de vencimento do pagamento PaymentDueDate | A data limite para liquidar o pagamento dentro do prazo. | ||
| Descrição Armazena a data de execução contratual ou solicitada. Essa data é comparada com a data real de liquidação para calcular o KPI 'Taxa de pagamentos no prazo' e alimentar o Dashboard 'Conformidade com a data de vencimento do pagamento'. Por que isso importa Referência para medir a conformidade com o SLA e o desempenho no cumprimento dos prazos. Onde encontrar Instruções da transação, geralmente nos campos 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 Relaciona Por que isso importa Agrega a performance por função de negócio. Onde encontrar Derivado de tabelas de usuários ou do mapeamento da hierarquia organizacional. Exemplos OperaçõesComplianceTesourariaSuporte de TI | |||
| É retrabalho IsRework | Indicador que mostra se o pagamento passou por atividades repetidas. | ||
| Descrição Indicador booleano calculado durante o processamento dos dados. Seu valor é definido como verdadeiro quando atividades como 'Dados do pagamento validados' ocorrem mais de uma vez ou quando é detectado um ciclo de erro. Esse indicador alimenta o KPI 'Taxa de retrabalho em pagamentos'. Por que isso importa Identifica rapidamente casos ineficientes, sem consultas complexas ao processo. Onde encontrar Calculado no pipeline de dados, verificando se há atividades duplicadas por caso. Exemplos truefalse | |||
| Moeda do pagamento PaymentCurrency | O código ISO da moeda do pagamento. | ||
| Descrição Especifica a moeda em que Por que isso importa Necessário para interpretar corretamente o valor do pagamento. Onde encontrar Tabelas de detalhes da transação, geralmente com campos como CCY, CURRENCY_CODE ou ISO_CODE. Exemplos USDEURGBPJPY | |||
| Tipo de pagamento PaymentType | A classificação do instrumento de pagamento. | ||
| Descrição Classifica o pagamento, por exemplo, como transferência bancária, ACH, SEPA ou RTGS. Os diferentes tipos de pagamento costumam ter SLAs e fluxos de processo bastante distintos. Este atributo é uma dimensão importante para filtrar o Dashboard 'Análise do tempo de ciclo de ponta a ponta do pagamento'. Por que isso importa Essencial para diferenciar fluxos de pagamento rápidos de fluxos processados em lote. Onde encontrar Cabeçalho da transação, com campos como PMT_TYPE, INSTRUMENT_TYPE ou SERVICE_ID. Exemplos Transferência bancária nacionalTransferência bancária internacionalCrédito ACHPagamento instantâneo | |||
| Usuário do evento EventUser | O ID do usuário ou do agente do sistema responsável pela atividade. | ||
| Descrição Registra quem realizou a ação, seja uma pessoa, como no caso de aprovações, ou uma conta do sistema, como na liquidação automatizada. Este atributo é essencial para a Análise de gargalos, pois ajuda a identificar usuários ou filas sobrecarregados. Por que isso importa Permite analisar recursos e auditar a segregação de funções. Onde encontrar Logs de auditoria ou colunas 'UpdatedBy' nas tabelas de transações. 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 importante para analisar o 'Volume de pagamentos' e priorizar gargalos. Pagamentos de alto valor costumam passar por etapas de aprovação mais rigorosas, que podem ser analisadas por variante, em comparação com fluxos automatizados de baixo valor. Por que isso importa Permite segmentar os pagamentos por valor e calcular o volume total processado. Onde encontrar Tabelas de detalhes da transação, geralmente com campos como AMT, TRANS_AMOUNT ou PRINCIPAL_AMOUNT. Exemplos 1500.00250000.5050.001000000.00 | |||
| ID da conciliação ReconciliationId | Identificador que vincula o pagamento ao razão contábil ou ao registro de conciliação. | ||
| Descrição Este ID é preenchido quando ocorre a atividade 'Pagamento conciliado'. Ele garante que o pagamento no mecanismo de processamento corresponda ao lançamento no sistema contábil. Se esse ID estiver ausente em pagamentos liquidados, isso indica falhas na conciliação. Por que isso importa Essencial para o Dashboard 'Eficiência da conciliação de pagamentos'. Onde encontrar 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 da transação. Analisar esse campo pode ajudar a identificar fornecedores ou clientes específicos associados a altos índices de retrabalho ou atrasos, contribuindo para a 'Análise de falhas e retrabalho em pagamentos'. Por que isso importa Identifica o destinatário do pagamento e é útil para análises centradas no cliente. Onde encontrar Linhas de detalhes do pagamento, com campos como CREDITOR_NAME, BENE_NAME ou PAYEE. Exemplos Acme CorpGlobal Supplies LtdJohn Smith | |||
| Pagamento atrasado IsPaymentLate | Indicador que mostra se o pagamento foi liquidado após a data de vencimento. | ||
| Descrição Indicador booleano que compara a data real de liquidação com Por que isso importa Simplifica os relatórios de conformidade. Onde encontrar Calculado como: SettlementDate > PaymentDueDate. Exemplos truefalse | |||
| Região de origem OriginatingRegion | A região geográfica de onde veio a solicitação de pagamento. | ||
| Descrição Indica a localização física ou lógica de quem solicitou o pagamento. Na análise de variantes do processo de pagamento, ajuda a identificar se determinadas regiões seguem caminhos fora do padrão ou têm taxas de rejeição mais altas. Por que isso importa Fornece contexto geográfico para analisar a performance do processo. Onde encontrar Cabeçalho da transação, geralmente derivado do código da filial ou do país. Exemplos América do NorteEMEAAPAC | |||
| Sistema de origem SourceSystem | O nome do sistema de onde vieram os dados do evento. | ||
| Descrição Identifica o aplicativo ou módulo específico do ecossistema ACI Worldwide, como ACI MTS ou ACI UPF, ou os sistemas externos envolvidos no fluxo. Isso é especialmente importante ao combinar dados de vários livros contábeis ou quando o pagamento passa por câmaras de compensação externas. Por que isso importa Indica a origem dos dados extraídos e ajuda a depurar a linhagem dos dados. Onde encontrar Definido durante a extração ou derivado de uma coluna SystemID, caso existam várias instâncias. Exemplos ACI MTSACI UPPSAP GLGateway Swift | |||
| Tempo de ciclo da aprovação ApprovalCycleTime | Tempo gasto na etapa de aprovação. | ||
| Descrição Calcula o intervalo entre 'Pagamento enviado para aprovação' e 'Pagamento aprovado' ou rejeitado. Essa métrica alimenta o Dashboard 'Análise do tempo de ciclo da aprovação de pagamentos' e destaca atrasos nas etapas que dependem de decisões humanas. Por que isso importa Isola a parte do processo que depende de pessoas. Onde encontrar Calculado como: data e hora(Pagamento aprovado) - data e hora(Pagamento enviado para aprovação). Exemplos 4 horas15 minutos | |||
| Última atualização dos dados LastDataUpdate | A data e a hora em que o registro foi extraído ou atualizado pela última vez no modelo de dados. | ||
| Descrição Acompanha a atualização dos dados usados na análise. Não representa o horário de um evento do processo, mas o momento técnico da ingestão dos dados. Assim, os analistas sabem se estão consultando dados em tempo real ou registros históricos. Por que isso importa Ajuda a manter os dados atualizados e a identificar dados desatualizados nos Dashboards. Onde encontrar Horário do sistema no momento da execução do script de ETL. Exemplos 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Atividades do processamento de pagamentos
| Atividade | Descrição | ||
|---|---|---|---|
| Erro no pagamento identificado | Indica que o sistema detectou um problema no pagamento em alguma etapa, como dados inválidos ou um alerta de conformidade. Em geral, esse evento é registrado explicitamente com um código de erro associado. | ||
| Por que isso importa Esta atividade é o ponto de partida para analisar retrabalho e tratamento de exceções. Ela é essencial para os Dashboards 'Análise de falhas e retrabalho em pagamentos' e 'Tempo de ciclo da resolução de erros'. Onde encontrar Procure registros explícitos em uma tabela de log de erros ou uma mudança de status para 'Erro' ou 'Requer correção' na tabela de transações. Esses eventos devem estar vinculados ao ID da transação de pagamento. Coleta Um evento explícito é registrado quando o mecanismo de validação ou processamento do sistema sinaliza um erro. Tipo de evento explicit | |||
| Pagamento aprovado | Um marco importante em que um usuário autorizado aprova o pagamento, permitindo que ele siga para execução. Em geral, isso é registrado como um evento explícito quando a pessoa responsável pela aprovação realiza a ação na interface do sistema. | ||
| Por que isso importa Esta atividade é um ponto de controle importante e costuma ser um gargalo significativo. Analisar o tempo de espera antes desta etapa e a duração do ciclo de aprovação ajuda a identificar oportunidades para agilizar os pagamentos. Onde encontrar Procure um evento explícito em uma tabela de registros de aprovação ou uma alteração de status para 'Aprovado' na tabela principal de transações, vinculada à ação de um usuário específico e à respectiva data e hora. Coleta Registrado quando um usuário autorizado conclui a aprovação no sistema. Tipo de evento explicit | |||
| Pagamento autorizado | Representa a autorização do pagamento pelo sistema após a aprovação humana, com a verificação dos recursos ou a checagem de regras antifraude. Pode ser uma entrada explícita no registro ou ser inferida por uma alteração de status que indique que o pagamento está pronto para execução. | ||
| Por que isso importa Este é um ponto de controle crítico antes de instruir a movimentação dos recursos. Atrasos nesta etapa podem indicar problemas de performance do sistema ou dificuldades nos subsistemas de conformidade e prevenção a fraudes. Onde encontrar Procure um registro explícito no log de processamento ou de segurança do sistema. Como alternativa, a etapa pode ser inferida pela atualização do status de 'Aprovado' para 'Autorizado para pagamento'. Coleta Registrado pelo mecanismo de pagamentos do sistema após a conclusão das verificações internas finais. Tipo de evento explicit | |||
| Pagamento liquidado | A confirmação final de que o processo de pagamento foi concluído e os recursos foram creditados ao beneficiário, encerrando a transação. Este é um evento crítico que representa o fim bem-sucedido do ciclo de pagamento. | ||
| Por que isso importa Este é o principal evento de encerramento bem-sucedido do processo. Ele é usado para calcular o tempo de ciclo geral e a capacidade de processamento, além de ser essencial para quase todos os Dashboards de performance de ponta a ponta. Onde encontrar Em geral, é um evento explícito registrado quando a rede envia uma mensagem de confirmação da liquidação final ou quando o razão interno é atualizado para indicar que a transação foi concluída. Coleta Registrado ao receber um arquivo ou uma mensagem de liquidação final, atualizando o status para 'Liquidado'. Tipo de evento explicit | |||
| Recursos transferidos | Indica que a rede de pagamentos confirmou o débito dos recursos da conta do pagador. Em geral, isso é registrado a partir de uma mensagem de status recebida da rede. | ||
| Por que isso importa Confirma que a rede externa executou o pagamento com sucesso. Marca o início do período de liquidação e é um dado essencial para o KPI 'Tempo médio de liquidação dos pagamentos'. Onde encontrar Este é um evento explícito, acionado por uma mensagem de atualização de status recebida, como uma MT103 da SWIFT ou uma confirmação ACH, que atualiza o registro do pagamento. Coleta Registrado quando uma mensagem de confirmação externa é recebida da rede de compensação. Tipo de evento explicit | |||
| Solicitação de pagamento criada | Esta atividade marca o início de uma nova transação de pagamento no sistema ACI Worldwide. Em geral, é um evento explícito registrado quando um usuário ou sistema anterior envia uma solicitação de pagamento, criando um novo registro de transação com um ID exclusivo. | ||
| Por que isso importa Este é o principal evento de início do processo de pagamento. Analisar o tempo entre esta atividade e a conclusão permite calcular o tempo de ciclo de ponta a ponta, essencial para medir a eficiência geral do processo. Onde encontrar Provavelmente, este é um evento explícito registrado na tabela principal de transações ou em um Event Log dedicado da ACI. Procure a data e hora de criação associada ao ID de transação de pagamento. Coleta Identificado pelo registro de criação ou por um evento explícito de 'Criação' no registro de transações. Tipo de evento explicit | |||
| Detalhes do pagamento validados | Representa a conclusão das verificações automáticas ou manuais que confirmam se os dados do pagamento, como as informações do beneficiário e os códigos bancários, estão corretos. Muitas vezes, essa atividade é inferida pela mudança de status da transação de 'Novo' para 'Validado' ou 'Aguardando aprovação'. | ||
| Por que isso importa Acompanha a eficiência das etapas iniciais de validação de dados. Atrasos nessa fase podem criar gargalos nas etapas seguintes e aumentar a probabilidade de erros de pagamento. Onde encontrar Inferido pelos campos de alteração de status na tabela principal de transações de pagamento. Compare as datas e horas dos status 'Criado' e 'Validado', ou de um status semelhante. Coleta Inferido pela alteração do campo de status do pagamento, por exemplo, de 'Inserido' para 'Validado'. Tipo de evento inferred | |||
| Erro no pagamento resolvido | Marca o momento em que um usuário corrige um erro identificado anteriormente e o pagamento é enviado novamente para processamento. Muitas vezes, isso é inferido quando o status do pagamento muda de um estado de erro para um estado normal de processamento. | ||
| Por que isso importa Esta atividade encerra o ciclo de tratamento da exceção. O intervalo entre 'Erro no pagamento identificado' e este evento corresponde ao tempo de ciclo da resolução de erros, uma medida importante da eficiência operacional. Onde encontrar Inferido a partir da mudança de um status 'Erro' para um status de processamento, como 'Aguardando aprovação' ou 'Validado'. Também pode ser registrado explicitamente como uma ação do usuário. Coleta Inferido a partir da mudança de um status de erro para outro status, indicando que uma correção foi feita. Tipo de evento inferred | |||
| Instrução de pagamento enviada | Marca o momento em que a instrução de pagamento é preparada e enviada a uma rede externa de pagamentos, como SWIFT, ACH ou SEPA. Os sistemas da ACI registram explicitamente essa transferência para fins de auditoria e rastreamento. | ||
| Por que isso importa Para muitos tipos de pagamento, este é o ponto sem volta. Acompanhar essa etapa ajuda a medir o tempo de processamento interno antes de o processo depender de fatores externos. Onde encontrar Quase sempre, este é um evento explícito registrado nos logs de transações ou de mensagens da ACI, muitas vezes com um número de referência específico da rede. Coleta Uma entrada explícita é criada no registro quando a mensagem de pagamento é enviada à rede externa. Tipo de evento explicit | |||
| Pagamento conciliado | Representa a etapa contábil final, em que a transação de pagamento registrada no ACI é comparada com extratos bancários ou lançamentos contábeis. Pode ser um evento explícito de um módulo de conciliação ou ser inferido a partir de uma mudança de status. | ||
| Por que isso importa Esta atividade mede a eficiência do processo de conciliação do back-office. Atrasos nessa etapa podem afetar a precisão dos relatórios financeiros e ocultar problemas com pagamentos ainda não liquidados. Onde encontrar Essas informações podem vir de um módulo de conciliação dedicado no ACI ou de um sistema ERP externo. Elas podem ser capturadas por meio de uma atualização do registro do pagamento para o status 'Conciliado'. Coleta Inferido a partir de uma atualização final para o status 'Conciliado' ou de dados de conciliação associados pelo ID do pagamento. Tipo de evento inferred | |||
| Pagamento confirmado | Representa a confirmação interna de que o pagamento foi processado com sucesso e de que a confirmação foi recebida. Muitas vezes, essa etapa aciona uma notificação ao beneficiário ou a outros sistemas internos. | ||
| Por que isso importa Este marco é essencial para medir a conformidade com as datas de vencimento e a taxa de pagamentos em dia. Ele registra claramente quando a organização considera que o pagamento foi executado com sucesso. Onde encontrar Em geral, é inferido pela alteração do status na tabela de transações de pagamento para 'Confirmado' ou 'Concluído', após o recebimento da confirmação da rede externa. Coleta Inferido pela alteração do 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 encaminhado para a aprovação necessária da gestão ou da área financeira. Em geral, isso é registrado por uma alteração de status no fluxo de trabalho de pagamentos. | ||
| Por que isso importa Esta etapa marca o início do subprocesso de aprovação. Medir o tempo entre este ponto e 'Pagamento aprovado' é essencial para o Dashboard 'Análise do tempo de ciclo de aprovação de pagamentos'. Onde encontrar Identificado pela alteração do campo de status do pagamento nos dados da transação, como a mudança para 'Aguardando aprovação'. Coleta Inferido pela alteração do status para 'Aguardando aprovação' ou similar, junto com a data e hora correspondente. Tipo de evento inferred | |||
| Pagamento não realizado | Status final que indica que o pagamento não pôde ser concluído devido a um problema irrecuperável. Diferentemente de um erro que pode ser corrigido, representa uma falha definitiva. | ||
| Por que isso importa Acompanhar esse evento final é essencial para calcular a taxa geral de falhas nos pagamentos. Analisar os motivos das falhas pode ajudar a melhorar a qualidade dos dados e as regras do processo. Onde encontrar Inferido a partir de um status final, como 'Falhou', 'Cancelado' ou 'Rejeitado pelo banco', nos dados da transação, que não muda depois. Coleta Inferido a partir de um status de falha final no registro do pagamento. Tipo de evento inferred | |||
| Pagamento rejeitado | Ocorre quando a pessoa responsável pela aprovação rejeita a solicitação de pagamento, geralmente exigindo correção e reenvio. Esse evento explícito interrompe o andamento do pagamento e inicia um ciclo de retrabalho. | ||
| Por que isso importa Identifica retrabalho e ineficiências do processo. Acompanhar a frequência das rejeições ajuda a diagnosticar problemas na qualidade inicial dos dados ou nas políticas de envio, apoiando a análise de retrabalho. Onde encontrar Registrado como evento explícito no registro de aprovações ou como alteração de status para 'Rejeitado' na tabela de transações. O evento pode incluir um código com o motivo da rejeição. Coleta Registrado quando a pessoa responsável pela aprovação conclui a rejeição no sistema. Tipo de evento explicit | |||
Guias de extração
Etapas
Acesse o ambiente do banco de dados: entre 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(registro de transações) epost_tran_cust(extensão de dados personalizados). Confirme se você tem permissãoSELECTnesses objetos.Defina o identificador do caso: esta extração usa
retrieval_reference_nrcomoPaymentTransactionId. Se sua implementação usar outra chave exclusiva, comosystem_trace_audit_nrcombinado comtransmission_date_time, ajuste a seleção da consulta.Configure os parâmetros de filtro: abra a consulta abaixo. Localize as variáveis
@StartDatee@EndDateno início do script e defina o período de extração desejado, por exemplo, os últimos 30 a 90 dias, para otimizar a performance.Revise a lógica das atividades: a consulta mapeia os tipos de mensagem ISO 8583, como 0200 e 0210, e os códigos de resposta para as 14 atividades necessárias de Process Mining. Revise as instruções
CASEpara confirmar se correspondem às configurações específicas da sua interface ACI.Execute a consulta: execute o script completo. A consulta usa
UNION ALLpara normalizar diferentes estados de transação em um único formato de Event Log.Verifique os dados de saída: confira se os resultados contêm as colunas necessárias:
PaymentTransactionId,ActivityNameeEventTimestamp. Verifique se algum campo crítico contém valoresNULLinesperados.Exporte os dados: clique com o botão direito na grade de resultados do SSMS e salve a saída como arquivo CSV, por exemplo,
ACI_Payments_EventLog.csv.Formate os dados para o ProcessMind: abra o CSV e confirme se
EventTimestampestá no formato padrão (YYYY-MM-DD HH:MM:SS) e sePaymentAmountcontém apenas valores numéricos.Carregue os dados: importe o CSV verificado para o ProcessMind e mapeie as colunas para ID do caso, Atividade e Timestamp, respectivamente.
Configuração
- Intervalo de datas: as tabelas
post_tranda ACI crescem muito rapidamente. Recomenda-se limitar a extração a um período móvel de 3 meses ou usar a troca de partições, se disponível. - Códigos de resposta: a consulta considera que
rsp_code = '00'indica sucesso. Se sua instituição usar outros códigos de aprovação ou sucesso, como '08' ou '10', atualize os filtros. - Tipos de mensagem (ISO 8583): o script usa tipos de mensagem padrão (0100/0200 para solicitações e 0210 para respostas). Tipos personalizados definidos na configuração
source_node_namepodem exigir ajustes. - Performance do sistema: esta consulta usa dicas
NOLOCKpara evitar bloqueios no processamento de transações em tempo real. Não remova essas dicas em um ambiente de produção. - Moedas: os valores são extraídos sem conversão. Se precisar padronizar várias moedas durante a análise, use
tran_currency_code.
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; Pronto para começar?
Use este Template como guia para começar a extrair os dados do processamento de pagamentos. Descubra insights valiosos e aumente a eficiência dos seus fluxos de trabalho financeiros hoje mesmo.
Simplifique o processamento de pagamentos: comece agora seu teste grátis
Elimine exceções nos pagamentos e alcance 98% de processamento direto.
Não é necessário informar cartão de crédito. Configuração em poucos minutos.