Seu Template de dados para processamento de faturas de contas a pagar
Seu Template de dados para processamento de faturas de contas a pagar
- Atributos recomendados para uma análise completa
- Principais atividades do processo para acompanhar com eficiência
- Orientações passo a passo para a extração de dados
Atributos do processamento de faturas do Contas a Pagar
| Nome | Descrição | ||
|---|---|---|---|
| Atividade ActivityName | O nome de um evento ou etapa específica do negócio que ocorreu durante o ciclo de vida do processamento da fatura. | ||
| Descrição A atividade representa uma etapa ou ação distinta no processo de Contas a Pagar, como 'Fatura recebida', 'Fatura lançada' ou 'Pagamento executado'. Esses são os blocos de construção do mapa do processo. Analisar atividades é essencial para Process Mining. Isso ajuda a visualizar o fluxo do processo, identificar caminhos comuns, detectar desvios do processo padrão e medir a frequência e a duração de cada etapa. A sequência dessas atividades para uma determinada fatura forma sua jornada no processo. Por que isso importa Define as etapas do processo, permitindo visualizar e analisar o fluxo do processo, identificar gargalos e detectar ciclos de retrabalho. Onde obter Derivada de várias fontes, incluindo alterações no status do documento, por exemplo, BKPF-BSTAT, documentos de alteração, tabelas CDHDR/CDPOS ou logs de Workflow. Normalmente, isso exige uma lógica de extração personalizada. Exemplos Fatura recebidaFatura aprovadaPagamento executadoFatura bloqueada para pagamento | |||
| Fatura Invoice | O identificador exclusivo de um documento de fatura, que funciona como o ID de caso principal do processo de Contas a Pagar. | ||
| Descrição A fatura é o objeto central que conecta todas as atividades relacionadas, desde o recebimento até o pagamento. No SAP S/4HANA, normalmente é uma chave composta formada pelo Código da Empresa (BUKRS), por um Número de Documento exclusivo (BELNR) e pelo Exercício Fiscal (GJAHR). Analisar por fatura permite obter uma visão completa, de ponta a ponta, do ciclo de vida da fatura. Isso é fundamental para calcular métricas importantes, como o tempo total de ciclo, identificar gargalos em faturas individuais e entender os diferentes caminhos que uma fatura pode percorrer no processo. Por que isso importa Ele identifica exclusivamente a jornada de cada fatura, permitindo rastrear todo o seu ciclo de vida e analisar a performance do processo caso a caso. Onde obter É uma chave composta derivada das tabelas BKPF (cabeçalho do documento contábil) ou RBKP (cabeçalho do documento: recebimento da fatura), usando os campos BUKRS, BELNR e GJAHR. Exemplos 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Hora do evento EventTime | A data e a hora exatas em que a atividade ocorreu. | ||
| Descrição A hora do evento é o timestamp associado a cada atividade, fornecendo a sequência cronológica dos eventos de uma fatura. Esses dados são essenciais para entender o fluxo do processo e realizar qualquer análise baseada em tempo. Na análise, a hora do evento é usada para ordenar corretamente as atividades, calcular os tempos de ciclo entre diferentes etapas, identificar tempos de espera e analisar a performance do processo em diferentes períodos, como mês a mês. Ela é a base de todos os KPIs baseados em duração. Por que isso importa Esse timestamp é fundamental para ordenar cronologicamente os eventos e calcular todas as métricas baseadas em tempo, como tempos de ciclo e durações, essenciais para Process Mining. Onde obter Obtida de vários campos de data e hora nas tabelas do SAP, como Data de Criação (BKPF-CPUDT), Data de Lançamento (BKPF-BUDAT), Data de Compensação (BSAK-AUGDT) ou timestamps de logs de alterações (CDHDR-UDATE/UTIME). Exemplos 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Sistema de origem SourceSystem | O sistema do qual os dados foram extraídos. | ||
| Descrição Esse atributo identifica a origem dos dados do processo. Nesta visualização, o valor normalmente será 'SAP S/4HANA'. Em ambientes com vários ERPs ou sistemas integrados, esse campo é fundamental para a linhagem e a segregação dos dados. Ele garante que a análise seja realizada no conjunto de dados correto e ajuda a diagnosticar problemas de qualidade dos dados, rastreando-os até a origem. Por que isso importa Identifica a origem dos dados, algo fundamental para a governança de dados, a solução de problemas e os ambientes com vários sistemas. Onde obter Normalmente, é um valor estático adicionado durante o processo de extração de dados para identificar a origem do conjunto de dados. Exemplos SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Última atualização dos dados LastDataUpdate | O timestamp que indica quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Esse atributo fornece a data e a hora da extração ou atualização mais recente dos dados do SAP S/4HANA. É um campo de metadados fundamental para entender o nível de atualização dos dados analisados. Essa informação ajuda os usuários a saber quão atual é a análise do processo. Ela ajuda a gerenciar as expectativas sobre a latência dos dados e é essencial para programar atualizações e manter a integridade dos dados. Por que isso importa Indica o nível de atualização dos dados, garantindo que os usuários saibam quão atualizada está a análise do processo. Onde obter Esse valor é gerado e gravado em cada registro no momento da extração dos dados do sistema de origem. Exemplos 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Código da empresa CompanyCode | A unidade organizacional para a qual a fatura é processada. | ||
| Descrição Um código da empresa é a menor unidade organizacional para a qual é possível elaborar um conjunto completo e independente de contas para relatórios externos. No contexto de Contas a Pagar, ele representa a entidade legal que deve o dinheiro ao fornecedor. Analisar por código da empresa permite comparar a performance do processo entre diferentes entidades legais da organização. Isso ajuda a identificar quais partes do negócio seguem os processos padrão e quais apresentam maior eficiência, tempos de ciclo mais longos ou taxas de retrabalho mais altas. Por que isso importa Permite comparar a performance do processo entre diferentes entidades legais, ajudando a identificar problemas regionais ou específicos de unidades de negócio e as melhores práticas. Onde obter Encontrado nas tabelas de cabeçalho do documento, principalmente em BKPF-BUKRS para faturas FI e RBKP-BUKRS para faturas MM. Exemplos 10001710US01DE01 | |||
| Data de vencimento da fatura InvoiceDueDate | A data até a qual o pagamento da fatura deve ser feito ao fornecedor. | ||
| Descrição A data de vencimento da fatura é o prazo para pagar o fornecedor, evitar multas por atraso e manter um bom relacionamento. Essa data é calculada com base na data-base da fatura e nas condições de pagamento acordadas com o fornecedor. Essa data é essencial para o Dashboard 'Conformidade e Aging de Pagamentos' e para o KPI 'Taxa de Pagamentos Pontuais'. Ao comparar a data de vencimento com a data real de pagamento, a análise pode revelar se os pagamentos estão sendo feitos no prazo, antecipadamente ou com atraso, o que tem consequências financeiras e relacionais diretas. Por que isso importa É o principal fator da análise de pagamentos pontuais, permitindo medir a performance dos pagamentos e seu impacto nos relacionamentos com fornecedores e nas multas por atraso. Onde obter Essa data geralmente é calculada. A data líquida de vencimento está no campo BSEG-NETDT. Ela também pode ser derivada da data-base para pagamento (BSEG-ZFBDT) e das condições de pagamento (BSEG-ZTERM). Exemplos 2023-10-312023-11-152024-01-10 | |||
| Nome do fornecedor VendorName | O nome do fornecedor que enviou a fatura. | ||
| Descrição Esse atributo contém o nome oficial do fornecedor. Ele é vinculado por meio do número do fornecedor armazenado no documento da fatura. A análise de fornecedores é fundamental para gerenciar relacionamentos e identificar problemas de processo específicos de determinados fornecedores. Ela pode ajudar a responder perguntas como 'Quais fornecedores enviam mais faturas com divergências?' ou 'Estamos pagando determinados fornecedores estratégicos dentro do prazo de forma consistente?'. Também é um campo importante, junto com o número e o valor da fatura, para detectar possíveis pagamentos duplicados. Por que isso importa Permite analisar a performance do processo por fornecedor, ajudando a identificar fornecedores problemáticos e gerenciar relacionamentos estratégicos com eficiência. Onde obter Obtido na tabela de dados mestre de fornecedores LFA1, no campo NAME1, por meio do vínculo com o Número do Fornecedor (LIFNR) encontrado em BKPF ou RBKP. Exemplos Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Nome do usuário UserName | O ID do usuário que realizou a atividade. | ||
| Descrição Esse atributo registra o ID do usuário do SAP responsável por executar uma atividade específica, como lançar, aprovar ou compensar uma fatura. Ele vincula as etapas do processo a usuários individuais. Analisar por nome do usuário é essencial para entender a distribuição da carga de trabalho, identificar os profissionais com melhor performance e localizar usuários que podem precisar de treinamento adicional. Também é fundamental para analisar gargalos de aprovação nos Dashboards, pois ajuda a identificar quais aprovadores específicos estão causando atrasos no processo. Por que isso importa Atribui atividades a indivíduos específicos, permitindo analisar a performance dos usuários, a carga de trabalho e a conformidade com as políticas de segregação de funções. Onde obter Normalmente encontrado em tabelas de cabeçalho, como BKPF-USNAM (inserido por), ou em tabelas de documentos de alteração, como CDHDR-USERNAME (alterado por). Exemplos ABROWNJSMITHAP_AUTOMATION | |||
| Número do pedido de compra PurchaseOrderNumber | O identificador exclusivo do pedido de compra associado à fatura, quando aplicável. | ||
| Descrição Esse atributo vincula uma fatura a um pedido de compra previamente aprovado. A presença de um número de pedido de compra é a base do processo de conciliação em 3 vias, entre pedido de compra, fatura e recebimento de mercadoria. Esse é um atributo essencial para análises de conformidade e eficiência. Ele é usado para calcular o KPI 'Percentual de Faturas sem Pedido de Compra', que mede a aderência às políticas de compras. Também é fundamental para o Dashboard 'Performance da Conciliação em 3 Vias', permitindo analisar o processo de conciliação de faturas vinculadas a pedidos de compra. Por que isso importa Fundamental para analisar a eficiência da conciliação em 3 vias e medir a conformidade com as políticas de compras, identificando faturas processadas sem pedido de compra. Onde obter Encontrado nas tabelas de itens de linha da fatura, como RSEG-EBELN, para faturas MM, ou BSEG-EBELN, para faturas FI. Exemplos 45000012344500005678 | |||
| Valor da fatura InvoiceAmount | O valor bruto total da fatura na moeda original do documento. | ||
| Descrição É o valor total da fatura enviada pelo fornecedor. Inclui o custo de mercadorias ou serviços, impostos e outras cobranças, antes de quaisquer deduções ou descontos. O valor da fatura é um atributo financeiro fundamental para vários tipos de análise. Ele ajuda a priorizar faturas de alto valor, entender o impacto financeiro dos atrasos no processo, como multas por atraso em faturas de grande valor, e segmentar o processo, por exemplo: 'Faturas de alto valor seguem um caminho de aprovação diferente?'. Também é essencial para identificar possíveis pagamentos duplicados. Por que isso importa Fornece contexto financeiro ao processo, permitindo análises baseadas em valor, priorização de faturas de alto valor e quantificação dos impactos financeiros. Onde obter Encontrado em tabelas como RBKP-RMWWR (valor bruto da fatura) para faturas MM ou calculado a partir dos itens de linha em BSEG, no campo WRBTR, para faturas FI. Exemplos 1500.00250.7512345.50 | |||
| Condições de pagamento PaymentTerms | As condições acordadas com o fornecedor para pagar uma fatura, geralmente incluindo oportunidades de desconto. | ||
| Descrição As condições de pagamento definem as regras para as datas de vencimento e os possíveis descontos por pagamento antecipado. Por exemplo, uma condição como 'Z001' pode corresponder a 'Pagamento em até 30 dias, com desconto de 2% se pago em até 10 dias'. Esse atributo é a base do Dashboard 'Taxa de Aproveitamento de Descontos por Pagamento Antecipado'. Ao analisar as condições de pagamento, é possível identificar todas as faturas elegíveis para desconto. Comparar isso com os descontos efetivamente obtidos revela oportunidades de economia perdidas e mede a eficiência do processo de pagamento. Por que isso importa É essencial para analisar oportunidades de desconto por pagamento antecipado, medir a performance financeira do processo de pagamento e identificar economias perdidas. Onde obter Encontrado nos itens do fornecedor, na tabela BSEG-ZTERM, ou no cabeçalho da fatura, em RBKP-ZTERM. Exemplos Z0010001NT30 | |||
| Data de compensação ClearingDate | A data em que o pagamento foi realizado e a fatura foi compensada nos itens em aberto. | ||
| Descrição A data de compensação representa a liquidação financeira da fatura. É a data em que ocorre a atividade "Pagamento compensado", marcando a etapa final da maioria dos fluxos de faturas concluídos com sucesso. Essa data é usada para calcular a data real do pagamento e compará-la com a data de vencimento da fatura. Por isso, é essencial para calcular o KPI "Taxa de pagamentos no prazo" e para qualquer análise relacionada à performance de pagamentos. Ela também marca o ponto final do cálculo do tempo de ciclo completo da fatura. Por que isso importa Marca a liquidação final de uma fatura, servindo como ponto final para os cálculos de tempo de ciclo e como base para a análise de pagamentos no prazo. Onde obter Encontrado nas tabelas de itens compensados, como BSAK-AUGDT para fornecedores. Exemplos 2023-10-282023-11-142024-01-09 | |||
| Desconto aproveitado DiscountTaken | Um indicador booleano que informa se um desconto por pagamento antecipado foi aplicado com sucesso. | ||
| Descrição Este atributo informa se um desconto financeiro foi efetivamente aproveitado quando a fatura foi paga. Ele é um componente essencial para medir a eficiência financeira do processo de contas a pagar. Esse indicador é a base do KPI "Taxa de aproveitamento de descontos por pagamento antecipado". Ao filtrar as faturas em que havia possibilidade de desconto, com base nas condições de pagamento, e analisar esse indicador, a empresa consegue calcular com precisão quanto dinheiro foi economizado e quantas oportunidades de economia foram perdidas. Isso fornece uma medida clara e quantificável da performance de contas a pagar. Por que isso importa Mede diretamente o sucesso no aproveitamento dos descontos disponíveis por pagamento antecipado, com impacto direto no resultado financeiro da empresa. Onde obter Derivado da verificação de que o campo de valor do desconto (BSEG-SKNTO) é maior que zero no documento de pagamento. Exemplos truefalse | |||
| É automatizada IsAutomated | Um indicador que mostra se a atividade foi realizada automaticamente pelo sistema, e não por um usuário. | ||
| Descrição Esse atributo booleano diferencia as atividades iniciadas por pessoas daquelas executadas por jobs do sistema, Workflows ou bots. Por exemplo, uma execução automatizada de pagamentos ou um lançamento de fatura gerado pelo sistema seria marcado como automatizado. Analisar esse atributo ajuda a entender o nível de automação do processo de Contas a Pagar. Ele pode ser usado para medir o sucesso das iniciativas de automação, comparar a eficiência de etapas automatizadas e manuais e identificar novas oportunidades de automação. Por que isso importa Ajuda a medir o grau de automação do processo, permitindo analisar a eficácia da automação e identificar oportunidades de melhoria. Onde obter Derivado com base no Nome do Usuário, por exemplo, IDs de usuários do sistema como 'SAP_SYSTEM' ou 'BATCHUSER', ou em códigos de transação específicos associados a jobs automatizados. Exemplos truefalse | |||
| É pagamento atrasado IsLatePayment | Um indicador booleano que informa se a fatura foi paga após a data de vencimento. | ||
| Descrição Este atributo calculado é um indicador simples de verdadeiro/falso que informa se o pagamento de uma fatura foi realizado após a data oficial de vencimento. Ele é derivado da comparação entre a "Data de compensação" e a "Data de vencimento da fatura". Esse indicador simplifica a análise do Dashboard "Conformidade e aging de pagamentos" e do KPI "Taxa de pagamentos no prazo". Ele permite filtrar e agregar dados facilmente para contar os pagamentos atrasados, calcular o percentual de pagamentos no prazo e identificar fornecedores ou códigos de empresa com altas taxas de pagamentos atrasados. Por que isso importa Mede diretamente a conformidade com as condições de pagamento, simplifica o cálculo do KPI de pagamentos no prazo e ajuda a identificar áreas com baixa performance de pagamentos. Onde obter Atributo calculado. A lógica é: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Exemplos truefalse | |||
| Moeda da fatura InvoiceCurrency | O código da moeda do valor da fatura (por exemplo, USD, EUR). | ||
| Descrição Este atributo especifica a moeda em que o valor da fatura é denominado. Ele fornece o contexto essencial para todos os valores financeiros. Em uma organização multinacional, analisar faturas sem considerar a moeda pode levar a conclusões equivocadas. Este campo permite tratar os dados financeiros corretamente, convertendo todos os valores para uma única moeda de reporte ou segmentando a análise por moeda para entender as atividades financeiras regionais. Por que isso importa Fornece o contexto necessário para o valor da fatura, permitindo análises e relatórios financeiros precisos, especialmente em contextos multinacionais. Onde obter Encontrado nas tabelas do cabeçalho do documento, principalmente BKPF-WAERS ou RBKP-WAERS. Exemplos USDEURGBPJPY | |||
| Motivo do bloqueio BlockingReason | O motivo pelo qual uma fatura está bloqueada para pagamento, indicando uma divergência. | ||
| Descrição Quando uma fatura não passa por uma validação durante a conciliação em 3 vias ou em outras etapas de verificação, ela é bloqueada para pagamento. O Motivo do Bloqueio especifica a natureza do problema, como divergência de quantidade, variação de preço ou ausência de recebimento de mercadoria. Esse atributo é fundamental para o Dashboard 'Análise do Retrabalho por Divergência de Faturas'. Analisar a frequência dos diferentes motivos de bloqueio ajuda a identificar as causas raiz das ineficiências do processo. Por exemplo, se 'Variação de preço' for um motivo comum, isso pode apontar para problemas nos dados mestre do sistema de compras. Por que isso importa Fornece um insight direto sobre as causas raiz das divergências e do retrabalho nas faturas, permitindo iniciativas direcionadas de melhoria do processo. Onde obter Armazenado em tabelas de itens de fatura, como RSEG, em campos que começam com SPGR* (por exemplo, SPGRP, SPGRQ, SPGRT). Também pode ser encontrado em RBKP_BLOCKED. Exemplos Divergência de preçoDivergência de quantidadeRecebimento de mercadoria ausente | |||
| Número da fatura do fornecedor VendorInvoiceNumber | O número da fatura informado pelo fornecedor no documento. | ||
| Descrição Este é o número de referência do próprio sistema contábil do fornecedor, impresso no documento físico ou eletrônico da fatura. Ele é inserido manualmente ou capturado por OCR durante o recebimento da fatura. Este campo é extremamente importante para fins operacionais e de análise, especialmente para o Dashboard "Pagamentos potencialmente duplicados de faturas". Um método comum para detectar duplicidades é procurar vários documentos internos de fatura que tenham o mesmo nome do fornecedor, número da fatura do fornecedor e valor da fatura. É a principal referência externa de uma fatura. Por que isso importa É um campo essencial para detectar possíveis pagamentos duplicados e funciona como a principal referência externa nas comunicações com os fornecedores. Onde obter Armazenado no campo "Referência" do cabeçalho do documento, normalmente BKPF-XBLNR. Exemplos INV-2023-9876733401120231015-001 | |||
| Tipo de documento da fatura InvoiceDocumentType | Uma classificação do documento da fatura que controla como ele é processado no SAP. | ||
| Descrição O Tipo de Documento é um elemento de configuração importante no SAP que categoriza documentos contábeis. Por exemplo, 'KR' é normalmente usado para faturas de fornecedores, 'RE' para faturas MM e 'KG' para notas de crédito de fornecedores. Esse tipo determina aspectos como o intervalo de numeração e os campos obrigatórios. Na análise do processo, filtrar por Tipo de Documento permite comparar os fluxos de processo de diferentes tipos de fatura. Por exemplo, o processo de aprovação de uma nota de crédito pode ser diferente do processo de uma fatura padrão. Isso é útil para o Dashboard 'Variantes de Encaminhamento para Aprovação de Faturas'. Por que isso importa Permite segmentar o processo com base na forma como diferentes tipos de fatura são tratados, revelando variações nos caminhos de processamento e nos tempos de ciclo. Onde obter Diretamente da tabela de cabeçalho do documento, no campo BKPF-BLART. Exemplos KRREKG | |||
Atividades do processamento de faturas do Contas a Pagar
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura aprovada | A fatura recebeu todas as aprovações necessárias no sistema de Workflow. Muitas vezes, essa é a etapa final antes de a fatura ser lançada ou desbloqueada para pagamento. | ||
| Por que isso importa Esse marco importante marca o fim do ciclo de aprovação. O tempo entre o encaminhamento e a aprovação é uma métrica crítica de eficiência. Onde obter Capturado nos logs do SAP Business Workflow como uma etapa de conclusão ou liberação final. Como alternativa, pode ser inferido pela remoção de um bloqueio de pagamento após o encaminhamento. Captura Extraia os eventos de conclusão do Workflow dos logs de Workflow do SAP ou identifique o evento final de 'liberação'. Tipo de evento explicit | |||
| Fatura bloqueada para pagamento | O sistema bloqueou a fatura automática ou manualmente, impedindo seu pagamento. Isso normalmente ocorre devido a divergências de preço ou quantidade, ou à falta de aprovações. | ||
| Por que isso importa Este é um indicador importante de problemas e retrabalho. Analisar os motivos e a duração dos bloqueios ajuda a identificar as causas raiz dos atrasos nos pagamentos e das ineficiências do processo. Onde obter Este é um status explícito registrado no campo Chave de Bloqueio de Pagamento (ZLSPR) do item do fornecedor no documento contábil, na tabela BSEG. Captura Registrado por meio de documentos de alteração quando o campo BSEG-ZLSPR é preenchido com um motivo de bloqueio. Tipo de evento explicit | |||
| Fatura cancelada | O documento da fatura foi estornado, anulando efetivamente seu impacto financeiro. Esse é um estado final alternativo do processo, geralmente causado por lançamentos incorretos ou disputas com fornecedores. | ||
| Por que isso importa Acompanhar os cancelamentos ajuda a identificar motivos de falhas no processo, como envios duplicados ou dados incorretos na fatura, que podem apontar para problemas nas etapas anteriores. Onde obter Isso é registrado explicitamente quando um documento de estorno é criado. O cabeçalho do documento original (BKPF) terá preenchidos o número do documento de estorno (STBLG) e o motivo do estorno. Captura Identifique a data de lançamento do documento de estorno, vinculado no cabeçalho do documento original (BKPF-STBLG). Tipo de evento explicit | |||
| Fatura lançada | A fatura é registrada formalmente no razão geral, criando um passivo financeiro. Um documento estacionado se torna um documento lançado, ou um lançamento direto é realizado. | ||
| Por que isso importa Este é um marco financeiro crítico. Ele confirma a obrigação da empresa de pagar e geralmente é um pré-requisito para programar o pagamento. Onde obter Este evento é identificado pela Data de Lançamento (BUDAT) no cabeçalho do documento (BKPF). Um documento lançado tem o status do documento (BKPF-BSTAT) vazio. Captura Use o timestamp de lançamento (BKPF-BUDAT) para documentos que não estejam estacionados (BKPF-BSTAT vazio). Tipo de evento explicit | |||
| Fatura recebida | Esta atividade marca a criação de um documento de fatura no SAP, manualmente ou por meio de uma interface automatizada, como OCR/VIM. Esse evento normalmente é capturado a partir da data e hora de criação do cabeçalho do documento contábil. | ||
| Por que isso importa Como ponto inicial do processo, esta atividade é essencial para calcular o tempo de ciclo completo da fatura e medir o throughput de todo o processo de Contas a Pagar. Onde obter Este evento é capturado na tabela de cabeçalho do documento contábil (BKPF), usando a data de criação do documento (CPUDT) e a hora de criação (CPUTM). Captura Use o timestamp de criação (BKPF-CPUDT, BKPF-CPUTM) do documento da fatura. Tipo de evento explicit | |||
| Pagamento compensado | Esta atividade marca o encerramento final da fatura, quando o pagamento e a fatura são conciliados entre si no razão auxiliar. Isso indica que o processo foi concluído. | ||
| Por que isso importa Como encerramento definitivo do processo, esta atividade é essencial para calcular com precisão o tempo de ciclo completo. Ela confirma que o passivo foi liquidado. Onde obter Este é um evento explícito, marcado pelo preenchimento do campo Data de Compensação (AUGDT) no item do fornecedor do documento da fatura, na tabela BSEG. Captura Use a data de compensação (BSEG-AUGDT) do item de linha da fatura. Tipo de evento explicit | |||
| Pagamento executado | Um pagamento foi realizado para a fatura. Isso é capturado quando a execução de pagamentos é concluída e um documento de pagamento é criado e lançado. | ||
| Por que isso importa Esta atividade é fundamental para a análise do fluxo de caixa e para medir o KPI 'Taxa de Pagamentos Pontuais', comparando esta data com a data de vencimento da fatura. Onde obter Isso é capturado a partir da data de lançamento do documento de pagamento que compensa a fatura. O número do documento de pagamento é vinculado no campo de documento de compensação (AUGBL) do item de linha da fatura, na tabela BSEG. Captura Identifique a data de lançamento (BUDAT) do documento de pagamento que compensa o item de linha da fatura. Tipo de evento explicit | |||
| Data de vencimento da fatura ultrapassada | Um evento calculado que indica que a data líquida de vencimento da fatura passou sem que um pagamento fosse compensado. Isso indica uma situação de pagamento atrasado ou vencido. | ||
| Por que isso importa Essencial para o Dashboard 'Conformidade e Aging de Pagamentos', esta atividade ajuda a identificar e gerenciar proativamente faturas vencidas e analisar as causas raiz dos pagamentos atrasados. Onde obter Este não é um evento explícito no SAP. Ele é calculado comparando a data atual do sistema com a Data Líquida de Vencimento, calculada a partir de BSEG-ZFBDT, ou da data-base e das condições de pagamento. Captura Evento calculado acionado quando o timestamp do evento é posterior à data líquida de vencimento da fatura. Tipo de evento calculated | |||
| Divergência resolvida | Esta atividade indica que um problema identificado anteriormente, que provavelmente causou um bloqueio de pagamento, foi investigado e resolvido. Ela é capturada quando um bloqueio de pagamento é removido de uma fatura. | ||
| Por que isso importa Acompanhar esse ciclo de retrabalho é fundamental para o Dashboard 'Análise do Retrabalho por Divergência de Faturas'. Isso ajuda a quantificar o tempo e o esforço gastos na correção de erros. Onde obter Isso é inferido a partir de documentos de alteração que mostram a remoção de um bloqueio de pagamento. O log de alterações do campo BSEG-ZLSPR é a principal fonte. Captura Identifique os documentos de alteração da tabela BSEG em que o campo ZLSPR mudou de um valor para vazio. Tipo de evento inferred | |||
| Fatura encaminhada para aprovação | A fatura foi enviada para um Workflow para as aprovações necessárias, com base nas regras de negócio. Isso marca o início do subprocesso de aprovação. | ||
| Por que isso importa Esta atividade é o ponto de partida para medir o KPI 'Tempo Médio de Aprovação de Faturas' e analisar gargalos de aprovação. Onde obter Pode ser capturada nos logs do SAP Business Workflow, nas tabelas SWW*, que registram o início de uma instância de Workflow vinculada ao objeto da fatura, por exemplo, BUS2081. Captura Extraia os eventos de início do Workflow dos logs de Workflow do SAP, por exemplo, da tabela SWW_WIHEAD, vinculados ao documento da fatura. Tipo de evento explicit | |||
| Fatura estacionada | Representa uma fatura que foi inserida no sistema, mas ainda não foi lançada no razão geral. Muitas vezes, essa é uma etapa intencional para salvar um documento incompleto e processá-lo ou aprová-lo posteriormente. | ||
| Por que isso importa Acompanhar faturas estacionadas ajuda a identificar atrasos antes do início do lançamento formal e pode revelar problemas de completude dos dados ou de validação inicial. Onde obter Esse status é inferido a partir do campo de status do documento no cabeçalho do documento contábil (BKPF-BSTAT = 'V' para estacionado). O evento ocorre quando o status é definido. Captura Identifique os documentos de alteração da tabela BKPF em que o campo BSTAT está definido como 'V' (Vor-erfasst/Pré-inserido). Tipo de evento inferred | |||
| Fatura rejeitada | Um aprovador rejeitou a fatura durante o Workflow de aprovação. Essa ação normalmente envia a fatura de volta ao responsável pelo processamento para correção ou esclarecimento. | ||
| Por que isso importa Acompanhar as rejeições destaca os ciclos de retrabalho no processo de aprovação e pode indicar problemas de conformidade com políticas ou de codificação incorreta da fatura. Onde obter Isso é capturado como um evento de resultado específico nos logs do SAP Business Workflow associados à fatura. Captura Extraia os eventos de status 'rejeitado' do Workflow nos logs de Workflow do SAP. Tipo de evento explicit | |||
| Pedido de compra conciliado | Esta atividade indica que a fatura foi conciliada com sucesso com um pedido de compra correspondente. Essa é uma etapa crítica do processo de conciliação em 3 vias para faturas baseadas em compras. | ||
| Por que isso importa Analisar esta atividade ajuda a medir a eficiência do processo de conciliação e é fundamental para os KPIs 'Performance da Conciliação em 3 Vias' e 'Percentual de Faturas sem Pedido de Compra'. Onde obter Isso é inferido quando um item de linha da fatura na tabela BSEG ou ACDOCA contém um número de pedido de compra (EBELN) e um item (EBELP) válidos. Captura Inferido pela presença de uma referência a pedido de compra (BSEG-EBELN) no documento da fatura no momento da criação. Tipo de evento inferred | |||
| Proposta de pagamento criada | A fatura foi incluída em uma proposta de pagamento como parte de uma execução de pagamentos, por exemplo, F110. Agora ela está programada para pagamento, aguardando a execução final da rodada. | ||
| Por que isso importa Esta atividade mostra a transição de um passivo em aberto para um item sendo preparado ativamente para pagamento, ajudando a analisar a eficiência das operações de pagamento. Onde obter Este evento é registrado explicitamente nas tabelas de dados da execução de pagamentos, especificamente REGUP (itens processados pelo programa de pagamentos) e REGUH (cabeçalho). Captura Identifique quando uma fatura aparece na tabela REGUP em uma execução de pagamentos identificada em REGUH. Tipo de evento explicit | |||
| Recebimento de mercadoria conciliado | Esta atividade indica que as quantidades e os valores da fatura foram conciliados com sucesso com um documento de recebimento de mercadoria correspondente. Essa é a validação final em um cenário de conciliação em 3 vias. | ||
| Por que isso importa Acompanhar isso ajuda a identificar ineficiências no processo de conciliação em 3 vias e divergências entre as mercadorias recebidas e o que está sendo faturado pelo fornecedor. Onde obter Isso é inferido pela presença de uma referência a documento de material, ou recebimento de mercadoria, no item de linha da fatura, geralmente vinculada ao histórico do item do pedido de compra. Captura Inferido pela presença de uma referência a documento de recebimento de mercadoria no item de linha da fatura, por exemplo, em RSEG para faturas MIRO. Tipo de evento inferred | |||
Guias de extração
Etapas
- Pré-requisitos e acesso: confirme que você tem um usuário com acesso de leitura ao schema do banco de dados SAP S/4HANA, normalmente SAPABAP1 ou similar, onde estão as CDS views. Você precisará de uma ferramenta cliente SQL que consiga se conectar ao banco de dados SAP HANA, como SAP HANA Studio, DBeaver ou outra ferramenta de consulta de banco de dados semelhante.
- Identifique as CDS views principais: as CDS views principais para essa extração são I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails e I_PaymentProposalItem. Familiarize-se com os campos principais dessas views.
- Defina o escopo da consulta: abra seu cliente SQL e conecte-se ao banco de dados SAP HANA. Antes de executar a consulta completa, defina o escopo da extração. Isso envolve configurar o identificador correto do sistema de origem, o intervalo de datas das faturas (CreationDateTime) e os códigos de empresa relevantes.
- Prepare a consulta principal: copie a consulta SQL completa fornecida na seção de consulta para o seu cliente SQL. A consulta usa Common Table Expressions (CTEs) para primeiro selecionar uma população-base de faturas e depois construir um Event Log unificando os dados de 15 atividades diferentes.
- Defina os parâmetros da consulta: na consulta SQL copiada, localize as variáveis de espaço reservado. Substitua '[YYYY-MM-DD]' pelas datas inicial e final do seu período de análise. Substitua '[Your Company Code 1]' e '[Your Company Code 2]' pela lista de códigos de empresa SAP que você deseja analisar.
- Execute a consulta de extração: execute a consulta SQL completa. Dependendo do volume de dados e do intervalo de datas selecionado, isso pode levar de alguns minutos a várias horas.
- Revise os resultados preliminares: quando a consulta terminar, revise as primeiras centenas de linhas da saída. Verifique a consistência dos dados, confirme se todas as colunas foram preenchidas conforme esperado e valide se há diferentes valores de ActivityName.
- Exporte o Event Log: exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Confirme que o arquivo está codificado em UTF-8 para evitar problemas com caracteres. Dê ao arquivo um nome descritivo, por exemplo, sap_s4hana_ap_event_log.csv.
- Prepare o upload: antes de fazer o upload para uma ferramenta de Process Mining, confirme se os cabeçalhos das colunas no arquivo CSV correspondem exatamente aos nomes de atributos exigidos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName etc.
- Faça o upload para a ferramenta de Process Mining: faça o upload do arquivo CSV gerado para sua plataforma de Process Mining, mapeando as colunas para os campos correspondentes de ID do caso, atividade e timestamp.
Configuração
- Visões CDS principais: a extração depende de uma combinação de visões CDS padrão do S/4HANA. As principais são:
- I_JournalEntry e I_JournalEntryItem: para cabeçalhos e itens dos documentos financeiros, detalhes de lançamento e informações de compensação.
- I_SupplierInvoiceAPI01: para detalhes específicos de faturas de MM (Logística), incluindo referências a pedidos de compra e bloqueios de pagamento.
- I_ChangeDocument: para acompanhar o registro exato de data e hora das alterações, como a definição ou remoção de um bloqueio de pagamento.
- I_WorkflowStatusDetails: para extrair eventos relacionados ao Workflow de aprovação de faturas.
- I_PaymentProposalItem: para identificar quando uma fatura é incluída na proposta de uma execução de pagamentos.
- I_Supplier: para enriquecer os dados com informações do cadastro de fornecedores, como VendorName.
- Filtragem por período: é fundamental aplicar um filtro de período para limitar o volume de dados. A consulta fornecida filtra CreationDateTime na CTE Invoices_Base. Para a análise inicial, recomenda-se um período de 3 a 6 meses, garantindo uma performance adequada.
- Filtros obrigatórios: filtre sempre por CompanyCode. Analisar dados de todos os códigos de empresa de uma só vez pode ser extremamente lento e talvez não seja relevante para o negócio. Filtre também por JournalEntryType para selecionar apenas documentos relacionados a fornecedores, como 'KR' e 'RE'.
- Pré-requisitos: o usuário do banco de dados que executará a consulta precisa ter autorização SELECT em todas as visões CDS usadas e no schema HANA subjacente. O acesso no nível da aplicação pela SAP GUI não é suficiente.
- Considerações de performance: consultas diretas em I_ChangeDocument podem consumir muitos recursos. A consulta fornecida tenta reduzir esse impacto filtrando primeiro as faturas. Para conjuntos de dados muito grandes, considere executar a extração fora dos horários de pico ou em lotes com períodos menores.
a Consulta de exemplo sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X'; Etapas
- Confirme se o acesso direto de leitura ao esquema SAP HANA que contém as tabelas relevantes do SAP S/4HANA está disponível. Obtenha a string de conexão, as credenciais, o nome do esquema e a autorização necessários para ler BKPF, ACDOCA e quaisquer tabelas adicionais configuradas para dados de documentos estacionados, fluxo de trabalho, compras, recebimento de mercadorias, propostas de pagamento, compensação e estornos.
- Confirme o modelo técnico de dados no sistema de destino antes da execução. Valide os nomes físicos, os campos-chave, os campos de timestamp, as relações de estorno, as relações de pagamento e a persistência do fluxo de trabalho usados pelo sistema. Substitua cada marcador entre colchetes na consulta pelo objeto ou campo correspondente do sistema. Não presuma que os dados de fluxo de trabalho ou de documentos estacionados estejam armazenados em uma única tabela universal.
- Configure os parâmetros de extração. Defina [Start date], [End date], [Company code filter], [Document type filter] e [Schema name]. Use inicialmente um intervalo de três a seis meses e amplie-o depois que a performance e a integridade dos dados forem validadas.
- Execute a consulta SQL em um cliente SQL SAP HANA aprovado, como o SAP HANA Database Explorer ou outra ferramenta autorizada de execução de SQL. A consulta gera uma linha para cada atividade extraída explicitamente e não depende do ProcessMind para inferir eventos.
- Valide o conjunto de resultados. Confirme que Invoice é o identificador do caso, que ActivityName contém os 15 nomes de atividade obrigatórios, que EventTime está preenchido e em uma ordem cronológica plausível, que SourceSystem identifica o SAP S/4HANA e que LastDataUpdate contém o timestamp de atualização da extração. Revise eventos duplicados, relações de estorno e combinações de documentos antes de carregar os dados.
- Aplique os mapeamentos específicos do sistema que forem necessários. Por exemplo, mapeie a fonte configurada de documentos estacionados para Invoice Parked, a fonte configurada do fluxo de trabalho para Invoice Routed For Approval, Invoice Approved e Invoice Rejected, e a fonte configurada de pagamentos para Payment Proposal Created e Payment Executed. Preserve os identificadores de origem em colunas adicionais se a auditabilidade for necessária.
- Exporte o resultado como um arquivo delimitado ou um conjunto de resultados do banco de dados, com um evento por linha. Use a codificação UTF-8, preserve os timestamps em um fuso horário consistente, mantenha os nomes exatos das colunas Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber e InvoiceDueDate e não agregue as atividades por fatura.
- Carregue o registro de eventos no ProcessMind e configure Invoice como o identificador do caso, ActivityName como a coluna de atividade e EventTime como a coluna de data e hora do evento. Verifique se os atributos opcionais estão mapeados para os campos correspondentes. Como o ProcessMind lê o registro de eventos como está, confirme que toda atividade que você pretende visualizar já esteja presente em uma linha antes do carregamento.
Configuração
- Período: comece com três a seis meses. Use a data de lançamento, a data de criação do documento ou a data do evento de origem relevante, de acordo com a atividade extraída. Amplie o período somente depois de validar o tempo de execução da consulta e a retenção na origem.
- Filtro por empresa: configure [Company code filter] para restringir a extração aos códigos de empresa necessários. Se nenhuma restrição for necessária, use uma seleção controlada de todas as empresas em vez de uma consulta de produção sem restrições.
- Filtro por documento: configure [Document type filter] somente depois de confirmar os tipos de documento usados para faturas de fornecedores, notas de crédito, documentos estacionados, documentos de pagamento e estornos no sistema de destino.
- Mapeamento de schema e objetos: substitua [Schema name] e cada objeto ou campo de origem entre colchetes por valores verificados no sistema SAP S/4HANA de destino. Uma consulta direta no HANA precisa ser adaptada às aplicações ativadas, extensões, desenho do Workflow e modelo de dados do sistema.
- Tratamento de data e hora: normalize todos os registros de data e hora de origem para um único fuso horário. Quando houver apenas uma data, use um componente de horário padrão documentado e registre essa limitação no dicionário de dados.
- Semântica dos eventos: extraia cada atividade como uma linha separada. Não consolide várias atividades em um único registro de fatura e não espere que o ProcessMind derive eventos de correspondência, aprovação, vencimento ou compensação.
- Evento de vencimento: gere Invoice Due Date Passed somente para faturas cuja data de vencimento seja anterior ao registro de data e hora de avaliação configurado e que não tenham um evento de compensação até esse momento. A consulta usa [Evaluation timestamp] para esse cálculo.
- Performance: restrinja o período e o escopo de empresas iniciais, filtre campos relevantes para índices ou particionamento, evite projeções amplas desnecessárias e execute a consulta durante uma janela de relatórios aprovada. Considere preparar subconjuntos dos dados de origem se a consulta de produção ultrapassar o tempo de execução acordado.
- Estratégia de atualização: defina LastDataUpdate como o registro de data e hora da execução da extração. Para cargas incrementais, mantenha um watermark baseado no registro de data e hora da alteração relevante na origem e inclua um período de retrocesso para capturar atualizações tardias e estornos.
- Pré-requisitos: autorizações necessárias no banco de dados, acesso aprovado à produção, conhecimento da configuração do Universal Journal no sistema, acesso às fontes configuradas de documentos estacionados, compras, recebimento de mercadorias, Workflow, pagamentos, compensação e estornos, além de eventuais aprovações de licenciamento ou governança da SAP.
a Consulta de exemplo sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Etapas
- Especificação e desenho: antes de programar, trabalhe com os analistas de negócio para confirmar as condições exatas de acionamento e os campos de dados de cada uma das 15 atividades obrigatórias. Identifique as tabelas SAP relevantes, os tipos de documento, como 'KR' e 'RE', e os códigos de empresa que farão parte do escopo.
- Crie o programa ABAP: abra o ABAP Editor usando o código de transação SE38. Crie um novo programa executável, por exemplo, Z_PM_AP_INVOICE_EXTRACT. Informe um título descritivo e defina a aplicação como 'Financial Accounting'.
- Defina a tela de seleção: no programa, defina uma tela de seleção, usando as palavras-chave PARAMETERS e SELECT-OPTIONS, para permitir que os usuários especifiquem o período de extração, com base na data de criação da fatura, os códigos de empresa de destino (BUKRS) e os tipos de documento de fatura relevantes (BLART). Inclua também um parâmetro para o caminho do arquivo de saída no servidor de aplicações.
- Declarações de dados: defina uma estrutura de tabela interna que corresponda ao formato final do Event Log, por exemplo, TY_EVENT_LOG, incluindo todos os atributos obrigatórios e recomendados. Declare tabelas internas para armazenar dados selecionados de várias tabelas de origem SAP, como BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS e REGUH.
- Seleção principal de dados: inicie a lógica de extração selecionando o conjunto principal de faturas de RBKP (faturas logísticas) e BKPF (faturas financeiras), com base nos critérios da tela de seleção. Armazene as chaves principais das faturas em uma tabela interna para orientar as consultas de dados seguintes.
- Extraia as atividades em sequência: para cada fatura do conjunto principal, faça uma série de seleções para encontrar os registros de data e hora e os detalhes de cada atividade de negócio. Por exemplo, consulte CDHDR e CDPOS para alterações em bloqueios de pagamento, REGUH e REGUP para dados da execução de pagamentos e BKPF para detalhes de documentos de estorno. Adicione um novo registro à tabela final do Event Log para cada atividade encontrada.
- Lógica para eventos calculados: implemente a lógica ABAP para atividades que não estão armazenadas diretamente em um campo de tabela. Para o evento 'Invoice Due Date Passed', use a data de vencimento da fatura (BSEG-ZFBDT + condições de pagamento) e a data de compensação (BSEG-AUGDT). Se a data de compensação for posterior à data de vencimento, crie um novo registro de evento com o registro de data e hora definido como a data de vencimento.
- Transformação e enriquecimento dos dados: à medida que você coleta os dados de cada atividade, preencha todos os atributos obrigatórios. Isso envolve buscar os nomes dos fornecedores em LFA1, converter datas e horários em uma única string de registro de data e hora (CONCATENATE...INTO...) e definir o valor de SourceSystem.
- Gere o arquivo de saída: depois que todas as faturas e suas atividades correspondentes forem processadas e coletadas na tabela interna final, use as instruções OPEN DATASET, LOOP AT ... TRANSFER e CLOSE DATASET para gravar os dados em um arquivo no caminho do servidor de aplicações especificado na tela de seleção.
- Baixe e prepare para o upload: use o código de transação CG3Y para baixar o arquivo gerado do servidor de aplicações para o seu computador. Confirme que o arquivo está salvo no formato CSV com codificação UTF-8. Verifique se os cabeçalhos das colunas correspondem aos atributos obrigatórios, como Invoice, ActivityName, EventTime etc., antes de fazer o upload para a ferramenta de Process Mining.
Configuração
- Período: defina a opção de seleção P_CPUDT para a data de criação da fatura (BKPF-CPUDT ou RBKP-CPUDT). Recomenda-se um período de 6 a 12 meses para a análise inicial.
- Código da empresa (P_BUKRS): parâmetro SELECT-OPTIONS obrigatório para filtrar códigos de empresa específicos. Não é recomendável processar todos os códigos de empresa de uma só vez, a menos que isso seja realmente necessário.
- Tipo de documento da fatura (P_BLART): parâmetro SELECT-OPTIONS para filtrar os tipos de documento de fatura relevantes. Os tipos comuns incluem 'KR' (fatura de fornecedor), 'KG' (nota de crédito de fornecedor) e 'RE' (verificação de fatura logística).
- Modo de execução: o programa deve ser executado como um job em segundo plano (SM36/SM37) para grandes volumes de dados, evitando timeouts no processo de diálogo em primeiro plano. Programe a execução fora dos horários de pico.
- Caminho do arquivo de saída: um PARAMETER para especificar o caminho e o nome do arquivo no servidor de aplicações SAP, por exemplo, no diretório /tmp/. O arquivo será gravado nesse local antes de ser baixado.
- Pré-requisitos: o usuário que executar o relatório precisa ter autorização para ler as tabelas de FI, CO e MM (BKPF, BSEG, RBKP, RSEG, LFA1), as tabelas de documentos de alteração (CDHDR, CDPOS) e as tabelas de Workflow. Além disso, o objeto de autorização S_DATASET é necessário para gravar arquivos no servidor de aplicações.
a Consulta de exemplo abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM. Pronto para começar?
Use este Template para dar início à sua iniciativa de Process Mining e liberar ganhos significativos de eficiência nas operações de contas a pagar. Comece hoje sua jornada rumo a um processo mais otimizado e simplificado.
Acabe com as multas por atraso: otimize hoje o processamento de faturas de contas a pagar
Reduza os custos de processamento em 60% e elimine pagamentos duplicados com facilidade.
Não é necessário cartão de crédito. Comece em poucos minutos.