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
- Atividades essenciais do processo para acompanhar
- Orientações passo a passo para extrair os dados
Atributos do processamento de faturas de contas a pagar
| Nome | Descrição | ||
|---|---|---|---|
| Atividade ActivityName | Nome de um evento ou etapa específica do processo que ocorreu durante o ciclo de processamento da fatura. | ||
| Descrição A atividade representa uma etapa ou ação específica do processo de Contas a Pagar, como 'Fatura recebida', 'Fatura lançada' ou 'Pagamento executado'. Essas atividades formam o mapa do processo. Analisar as atividades é essencial em Process Mining. Isso ajuda a visualizar o fluxo do processo, identificar caminhos frequentes, detectar desvios do processo padrão e medir a frequência e a duração de cada etapa. A sequência de atividades de uma fatura forma a trajetória dela pelo processo. Por que isso importa Define as etapas do processo e permite visualizar e analisar o fluxo, identificar gargalos e detectar ciclos de retrabalho. Onde encontrar 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 do fluxo de trabalho. Em geral, é necessário criar uma lógica de extração personalizada. Exemplos Fatura recebidaFatura aprovadaPagamento executadoFatura bloqueada para pagamento | |||
| Data e hora do evento EventTime | Data e hora exatas em que a atividade ocorreu. | ||
| Descrição A data e hora do evento correspondem à data e hora registradas para cada atividade e definem a sequência cronológica dos eventos de uma fatura. Esses dados são essenciais para entender o fluxo do processo e realizar análises baseadas em tempo. Na análise, a data e hora do evento são usadas para ordenar corretamente as atividades, calcular os tempos de ciclo entre etapas, identificar tempos de espera e analisar a performance do processo em diferentes períodos, como mês a mês. São a base de todos os KPIs relacionados à duração. Por que isso importa Registrar data e hora é essencial para ordenar os eventos cronologicamente e calcular métricas baseadas em tempo, como tempos de ciclo e durações, fundamentais para Process Mining. Onde encontrar 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 data e hora do log de alterações (CDHDR-UDATE/UTIME). Exemplos 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Fatura Invoice | Identificador exclusivo de um documento de fatura, usado como ID do caso principal no processo de Contas a Pagar. | ||
| Descrição A fatura é o objeto central que conecta todas as atividades relacionadas, do recebimento ao pagamento. No SAP S/4HANA, ela costuma ser identificada por uma chave composta formada pelo código da empresa (BUKRS), um número de documento exclusivo (BELNR) e o exercício fiscal (GJAHR). Analisar por fatura permite ter uma visão completa de todo o ciclo de vida. Isso é fundamental para calcular métricas como o tempo de ciclo total, identificar gargalos em faturas específicas e entender os diferentes caminhos que uma fatura pode percorrer no processo. Por que isso importa Identifica de forma exclusiva a trajetória de cada fatura, permitindo rastrear todo o seu ciclo de vida e analisar a performance do processo caso a caso. Onde encontrar 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 | |||
| Sistema de origem SourceSystem | Sistema do qual os dados foram extraídos. | ||
| Descrição Este 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, este campo é essencial para rastrear a linhagem dos dados e separá-los por origem. Ele garante que a análise seja feita no conjunto de dados correto e ajuda a diagnosticar problemas de qualidade dos dados, rastreando-os até a fonte. Por que isso importa Identifica a origem dos dados, essencial para a governança de dados, a solução de problemas e ambientes com vários sistemas. Onde encontrar Em geral, é um valor estático adicionado durante a extração dos dados para identificar a origem do conjunto de dados. Exemplos SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Este atributo informa a data e hora da extração ou atualização mais recente dos dados do SAP S/4HANA. É um campo de metadados essencial para entender o nível de atualização dos dados analisados. Essa informação ajuda você a saber o quanto a análise do processo está atualizada. Também permite alinhar expectativas sobre a latência dos dados e é importante para programar atualizações e manter a integridade dos dados. Por que isso importa Indica o nível de atualização dos dados, para que você saiba o quanto a análise do processo está atualizada. Onde encontrar Este valor é gerado e registrado 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 | Unidade organizacional responsável pelo processamento da fatura. | ||
| Descrição O 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 do Contas a Pagar, representa a entidade legal que deve o valor 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 áreas seguem os processos padrão e quais apresentam menor eficiência, tempos de ciclo mais longos ou mais retrabalho. Por que isso importa Permite comparar a performance do processo entre diferentes entidades legais e identificar problemas e boas práticas específicos de cada região ou unidade de negócio. Onde encontrar 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 | Data limite para pagar a fatura ao fornecedor. | ||
| Descrição A data de vencimento da fatura é o prazo para pagar o fornecedor e evitar multas por atraso, além de 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 envelhecimento dos pagamentos' e para o KPI 'Taxa de pagamentos em dia'. Ao comparar a data de vencimento com a data efetiva do pagamento, a análise revela se os pagamentos estão sendo feitos no prazo, antes ou depois dele, com consequências financeiras e para o relacionamento com fornecedores. Por que isso importa É o principal parâmetro para analisar pagamentos em dia, medir a performance dos pagamentos e avaliar o impacto no relacionamento com fornecedores e nas multas por atraso. Onde encontrar Esta data costuma ser calculada. A data líquida de vencimento fica 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 de usuário UserName | ID do usuário que realizou a atividade. | ||
| Descrição Este atributo registra o ID do usuário do SAP responsável por realizar uma atividade específica, como lançar, aprovar ou compensar uma fatura. Assim, ele vincula as etapas do processo a usuários específicos. Analisar por nome de usuário é essencial para entender a distribuição da carga de trabalho, identificar quem tem melhor performance e apontar usuários que podem precisar de treinamento adicional. Também é importante para analisar gargalos de aprovação nos Dashboards, pois ajuda a identificar quais aprovadores estão causando atrasos no processo. Por que isso importa Vincula as atividades a pessoas específicas, 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 encontrar Geralmente 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 | |||
| Nome do fornecedor VendorName | Nome do fornecedor que enviou a fatura. | ||
| Descrição Este atributo contém o nome oficial do fornecedor. Ele é vinculado pelo número do fornecedor armazenado no documento da fatura. A análise de fornecedores é essencial para gerenciar o relacionamento com eles e identificar problemas no processo relacionados a fornecedores específicos. Ela ajuda a responder perguntas como 'Quais fornecedores enviam mais faturas com divergências?' ou 'Estamos pagando pontualmente determinados fornecedores estratégicos?'. Junto com o número e o valor da fatura, este campo também é importante para detectar possíveis pagamentos duplicados. Por que isso importa Permite analisar a performance do processo por fornecedor, identificar fornecedores problemáticos e gerenciar com eficiência o relacionamento com fornecedores estratégicos. Onde encontrar Obtido da tabela mestre de dados de fornecedores LFA1 (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 | |||
| Número do pedido de compra PurchaseOrderNumber | Identificador exclusivo do pedido de compra associado à fatura, quando aplicável. | ||
| Descrição Este atributo vincula uma fatura a um pedido de compra (PO) pré-aprovado. A presença do número do pedido de compra é a base da conferência tripla entre pedido, fatura e recebimento de mercadorias. Este atributo é essencial para analisar a conformidade e a eficiência. Ele é usado para calcular o KPI 'Percentual de faturas sem pedido de compra', que mede a adesão às políticas de compras. Também é fundamental para o Dashboard 'Desempenho da conferência tripla', que permite analisar a conferência de faturas vinculadas a pedidos de compra. Por que isso importa Essencial para analisar a eficiência da conferência tripla e medir a conformidade com as políticas de compras, identificando faturas processadas sem pedido de compra. Onde encontrar 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 | Valor bruto total da fatura na moeda original do documento. | ||
| Descrição Este é o valor total da fatura enviada pelo fornecedor. Inclui o custo de produtos ou serviços, impostos e outras cobranças, antes de deduções ou descontos. O valor da fatura é um atributo financeiro essencial 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 valores elevados, e segmentar o processo, por exemplo: 'Faturas de alto valor seguem um fluxo de aprovação diferente?'. Também é essencial para identificar possíveis pagamentos duplicados. Por que isso importa Dá contexto financeiro ao processo, permitindo análises por valor, a priorização de faturas de alto valor e a quantificação dos impactos financeiros. Onde encontrar Encontrado em tabelas como RBKP-RMWWR (valor bruto da fatura) para faturas MM ou calculado a partir dos itens de linha em BSEG (campo WRBTR) para faturas FI. Exemplos 1500.00250.7512345.50 | |||
| Automatizada IsAutomated | Indicador que informa se a atividade foi realizada automaticamente pelo sistema, em vez de por uma pessoa. | ||
| Descrição Este atributo booleano diferencia as atividades iniciadas por pessoas daquelas executadas por tarefas do sistema, fluxos de trabalho ou bots. Por exemplo, uma execução automatizada de pagamentos ou o lançamento de uma fatura gerado pelo sistema seria marcado como automatizado. Analisar este 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 das etapas automatizadas e manuais e identificar outras oportunidades de automação. Por que isso importa Ajuda a medir o nível de automação do processo, analisar a eficácia da automação e identificar oportunidades de melhoria. Onde encontrar Derivado do nome de usuário, por exemplo, IDs de usuário do sistema como 'SAP_SYSTEM' ou 'BATCHUSER', ou de códigos de transação específicos associados a tarefas automatizadas. Exemplos truefalse | |||
| Condições de pagamento PaymentTerms | Condições acordadas com o fornecedor para pagar uma fatura, que muitas vezes incluem 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 significar 'Pagamento em até 30 dias, com desconto de 2% se pago em até 10 dias'. Este 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. A comparação com os descontos efetivamente obtidos revela oportunidades de economia perdidas e ajuda a medir 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 que deixaram de ser aproveitadas. Onde encontrar Encontrado nos itens de linha do fornecedor, na tabela BSEG-ZTERM ou no cabeçalho da fatura, em RBKP-ZTERM. Exemplos Z0010001NT30 | |||
| Data de compensação ClearingDate | Data em que o pagamento foi feito e a fatura foi baixada dos itens em aberto. | ||
| Descrição A data de compensação indica a liquidação financeira da fatura. É a data em que ocorre a atividade 'Pagamento compensado', que marca a etapa final da maioria dos processos de fatura concluídos com sucesso. Essa data é usada para calcular a data efetiva do pagamento e compará-la com a data de vencimento da fatura. Por isso, é essencial para calcular o KPI 'Taxa de pagamentos em dia' e para qualquer análise relacionada à performance de pagamentos. Ela também marca o fim 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 calcular o tempo de ciclo e como base para analisar os pagamentos em dia. Onde encontrar Encontrado nas tabelas de itens compensados, como BSAK-AUGDT para fornecedores. Exemplos 2023-10-282023-11-142024-01-09 | |||
| Desconto obtido DiscountTaken | Indicador booleano que informa se um desconto por pagamento antecipado foi aplicado. | ||
| Descrição Este atributo informa se um desconto financeiro foi efetivamente obtido no pagamento da fatura. Ele é essencial para medir a eficiência financeira do processo de contas a pagar. Este indicador é a base do KPI 'Taxa de aproveitamento de descontos por pagamento antecipado'. Ao filtrar as faturas elegíveis para desconto, de acordo com as condições de pagamento, e analisar este indicador, a empresa consegue calcular com precisão quanto economizou e quantas oportunidades de economia foram perdidas. Assim, obtém uma medida clara e quantificável da performance de contas a pagar. Por que isso importa Mede diretamente o aproveitamento dos descontos disponíveis por pagamento antecipado, que afeta diretamente o resultado financeiro da empresa. Onde encontrar Derivado da verificação de que o campo de valor do desconto (BSEG-SKNTO) é maior que zero no documento de pagamento. Exemplos truefalse | |||
| Moeda da fatura InvoiceCurrency | 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 está expresso. Ele fornece o contexto necessário para interpretar qualquer valor financeiro. 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, seja convertendo todos os valores para uma única moeda de relatório, seja segmentando a análise por moeda para entender as atividades financeiras de cada região. Por que isso importa Fornece o contexto necessário para interpretar o valor da fatura e permite análises e relatórios financeiros precisos, especialmente em contextos multinacionais. Onde encontrar Encontrado nas tabelas de cabeçalho do documento, principalmente em BKPF-WAERS ou RBKP-WAERS. Exemplos USDEURGBPJPY | |||
| Motivo do bloqueio BlockingReason | Motivo pelo qual uma fatura foi bloqueada para pagamento, indicando uma divergência. | ||
| Descrição Quando uma fatura não passa por uma validação durante a conferência tripla ou outras etapas de verificação, ela é bloqueada para pagamento. O motivo do bloqueio especifica o tipo de problema, como divergência de quantidade ou preço, ou falta de recebimento de mercadorias. Este atributo é fundamental para o Dashboard 'Análise de retrabalho por divergência em faturas'. Analisar a frequência dos diferentes motivos de bloqueio ajuda a identificar as causas raiz das ineficiências do processo. Por exemplo, se 'Divergência de preço' for um motivo frequente, isso pode indicar problemas nos dados mestres do sistema de compras. Por que isso importa Oferece insights diretos sobre as causas raiz das divergências em faturas e do retrabalho, permitindo direcionar as iniciativas de melhoria de processos. Onde encontrar Armazenado em tabelas de itens de linha da fatura, como RSEG, em campos iniciados por SPGR* (por exemplo, SPGRP, SPGRQ, SPGRT). Também pode ser encontrado em RBKP_BLOCKED. Exemplos Divergência de preçoDivergência de quantidadeFalta de recebimento de mercadorias | |||
| Número da fatura do fornecedor VendorInvoiceNumber | Número da fatura informado pelo fornecedor no documento. | ||
| Descrição Este é o número de referência do sistema contábil do próprio fornecedor, impresso na fatura física ou eletrônica. Ele é inserido manualmente ou capturado por OCR no recebimento da fatura. Este campo é muito importante para as operações e para as análises, especialmente no Dashboard 'Possíveis pagamentos duplicados de faturas'. Uma forma comum de 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. Esse é o principal identificador externo de uma fatura. Por que isso importa É um campo essencial para detectar possíveis pagamentos duplicados e serve como principal referência externa nas comunicações com os fornecedores. Onde encontrar Armazenado no campo 'Referência' do cabeçalho do documento, geralmente em BKPF-XBLNR. Exemplos INV-2023-9876733401120231015-001 | |||
| Pagamento em atraso IsLatePayment | 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 ou falso que informa se o pagamento da fatura foi feito após a data de vencimento oficial. Ele é calculado comparando a 'Data de compensação' com a 'Data de vencimento da fatura'. Esse indicador simplifica as análises do Dashboard 'Conformidade de pagamentos e envelhecimento' e do KPI 'Taxa de pagamentos em dia'. Ele permite filtrar e agregar dados com facilidade para contar os pagamentos em atraso, calcular o percentual de pagamentos em dia e identificar fornecedores ou códigos de empresa com altos índices de atraso. Por que isso importa Mede diretamente a conformidade com as condições de pagamento, simplifica o cálculo do KPI de pagamentos em dia e ajuda a identificar áreas com baixa performance de pagamento. Onde encontrar Atributo calculado. A lógica é: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Exemplos truefalse | |||
| Tipo de documento da fatura InvoiceDocumentType | Classificação do documento da fatura que determina como ele é processado no SAP. | ||
| Descrição O tipo de documento é um elemento importante da configuração do SAP que categoriza documentos contábeis. Por exemplo, 'KR' costuma ser usado para faturas de fornecedores, 'RE' para faturas MM e 'KG' para notas de crédito de fornecedores. Esse tipo determina aspectos como a faixa de numeração e os campos obrigatórios. Na análise do processo, filtrar por tipo de documento permite comparar os fluxos de diferentes tipos de fatura. Por exemplo, o processo de aprovação de uma nota de crédito pode ser diferente do de uma fatura padrão. Isso é útil para o Dashboard 'Variações no encaminhamento de faturas para aprovação'. Por que isso importa Permite segmentar o processo conforme o tratamento dado a cada tipo de fatura, revelando variações nos caminhos de processamento e nos tempos de ciclo. Onde encontrar Diretamente da tabela de cabeçalho do documento, campo BKPF-BLART. Exemplos KRREKG | |||
Atividades do processamento de faturas de contas a pagar
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura aprovada | A fatura recebeu todas as aprovações necessárias no sistema de fluxo de trabalho. Muitas vezes, esta é a última etapa antes de a fatura ser lançada ou liberada para pagamento. | ||
| Por que isso importa Este marco importante encerra o ciclo de aprovação. O tempo entre o encaminhamento e a aprovação é uma métrica essencial de eficiência. Onde encontrar Registrado nos logs do SAP Business Workflow como uma etapa de conclusão ou liberação final. Outra possibilidade é inferir o evento pela remoção de um bloqueio de pagamento após o encaminhamento. Coleta Extraia os eventos de conclusão do fluxo de trabalho dos logs do SAP ou identifique o evento final de 'liberação'. Tipo de evento explicit | |||
| Fatura bloqueada para pagamento | O sistema bloqueou a fatura, de forma automática ou manual, impedindo o pagamento. Isso geralmente ocorre por divergências de preço ou quantidade, ou pela 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 encontrar Este status é registrado explicitamente no campo de chave de bloqueio de pagamento (ZLSPR) do item do fornecedor no documento contábil (tabela BSEG). Coleta 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 seu impacto financeiro. Este é um possível 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 causas de falhas no processo, como envios duplicados ou dados incorretos na fatura, que podem indicar problemas em etapas anteriores. Onde encontrar Este evento é 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. Coleta 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 passa a ser um documento lançado, ou o lançamento é feito diretamente. | ||
| Por que isso importa Este é um marco financeiro essencial. Ele confirma a obrigação da empresa de pagar e costuma ser um pré-requisito para agendar o pagamento. Onde encontrar 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) em branco. Coleta Use a data de lançamento (BKPF-BUDAT) para documentos que não estejam estacionados (BKPF-BSTAT em branco). 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. Em geral, esse evento é registrado com base na data e hora de criação do cabeçalho do documento contábil. | ||
| Por que isso importa Como ponto de partida do processo, esta atividade é essencial para calcular o tempo de ciclo total da fatura e medir o throughput de todo o processo de Contas a Pagar. Onde encontrar Este evento é registrado a partir da tabela de cabeçalho do documento contábil (BKPF), usando a data de criação do documento (CPUDT) e a hora (CPUTM). Coleta Use a data e hora de criação (BKPF-CPUDT, BKPF-CPUTM) do documento da fatura. Tipo de evento explicit | |||
| Pagamento compensado | Esta atividade marca o encerramento definitivo da fatura, quando o pagamento e a fatura são conciliados no razão auxiliar. Isso indica que o processo foi concluído. | ||
| Por que isso importa Como etapa final do processo, esta atividade é essencial para calcular com precisão o tempo de ciclo total. Ela confirma que o passivo foi liquidado. Onde encontrar Este evento é registrado explicitamente quando o campo de data de compensação (AUGDT) é preenchido no item do fornecedor do documento da fatura (tabela BSEG). Coleta Use a data de compensação (BSEG-AUGDT) do item de linha da fatura. Tipo de evento explicit | |||
| Pagamento executado | O pagamento da fatura foi realizado. O evento é registrado quando a execução de pagamentos é concluída e um documento de pagamento é criado e lançado. | ||
| Por que isso importa Esta atividade é essencial para analisar o fluxo de caixa e medir o KPI 'Taxa de pagamentos em dia', comparando esta data com a data de vencimento da fatura. Onde encontrar Este evento é registrado com base na data de lançamento do documento de pagamento que compensa a fatura. O número do documento de pagamento está vinculado no campo de documento de compensação (AUGBL) do item de linha da fatura (BSEG). Coleta 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 | Evento calculado que indica que a data líquida de vencimento da fatura passou sem que um pagamento tenha sido compensado. Isso significa que o pagamento está atrasado ou vencido. | ||
| Por que isso importa Essencial para o Dashboard 'Conformidade e envelhecimento dos pagamentos', esta atividade ajuda a identificar e gerenciar proativamente faturas vencidas e analisar as causas raiz dos atrasos. Onde encontrar 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. Coleta Evento calculado, acionado quando a data e hora do evento são posteriores à 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. O evento é registrado quando o bloqueio de pagamento é removido da fatura. | ||
| Por que isso importa Acompanhar este ciclo de retrabalho é essencial para o Dashboard 'Análise de retrabalho por divergência em faturas'. Isso ajuda a quantificar o tempo e o esforço gastos na correção de erros. Onde encontrar Este evento é inferido por documentos de alteração que mostram a remoção de um bloqueio de pagamento. O histórico de alterações do campo BSEG-ZLSPR é a principal fonte. Coleta Identifique os documentos de alteração da tabela BSEG em que o campo ZLSPR muda de um valor preenchido para vazio. Tipo de evento inferred | |||
| Fatura encaminhada para aprovação | A fatura foi enviada para um fluxo de trabalho de aprovação, conforme as 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 na aprovação. Onde encontrar O evento pode ser registrado nos logs do SAP Business Workflow (tabelas SWW*), que registram o início de uma instância do fluxo de trabalho vinculada ao objeto da fatura, como BUS2081. Coleta Extraia os eventos de início do fluxo de trabalho dos logs do SAP (por exemplo, da tabela SWW_WIHEAD) vinculados ao documento da fatura. Tipo de evento explicit | |||
| Fatura estacionada | Indica que uma fatura foi inserida no sistema, mas ainda não foi lançada no razão geral. Muitas vezes, essa etapa é intencional: o documento incompleto é salvo para ser processado ou aprovado depois. | ||
| Por que isso importa Acompanhar as faturas estacionadas ajuda a identificar atrasos antes do início do lançamento formal e pode revelar problemas de preenchimento dos dados ou de validação inicial. Onde encontrar Este status é inferido pelo campo de status do documento no cabeçalho do documento contábil (BKPF-BSTAT = 'V' para estacionado). O evento ocorre quando o status é definido. Coleta 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 fluxo de aprovação. Em geral, essa ação devolve a fatura à pessoa responsável pelo processamento para correção ou esclarecimento. | ||
| Por que isso importa Acompanhar as rejeições revela ciclos de retrabalho no processo de aprovação e pode indicar problemas de conformidade com as políticas ou erros na classificação contábil da fatura. Onde encontrar Este evento é registrado como um resultado específico nos logs do SAP Business Workflow associados à fatura. Coleta Extraia dos logs do SAP os eventos de status 'rejeitada' do fluxo de trabalho. Tipo de evento explicit | |||
| Pedido de compra conferido | Esta atividade indica que a fatura foi conferida com sucesso com o pedido de compra correspondente. É uma etapa essencial da conferência tripla de faturas relacionadas a compras. | ||
| Por que isso importa Analisar esta atividade ajuda a medir a eficiência da conferência e é fundamental para os KPIs 'Desempenho da conferência tripla' e 'Percentual de faturas sem pedido de compra'. Onde encontrar Este evento é inferido quando um item de linha da fatura na tabela BSEG ou ACDOCA contém um número válido de pedido de compra (EBELN) e um item (EBELP). Coleta 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. | ||
| Por que isso importa Esta atividade mostra a transição de um passivo em aberto para um item em preparação ativa para pagamento, ajudando a analisar a eficiência das operações de pagamento. Onde encontrar 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). Coleta Identifique quando uma fatura aparece na tabela REGUP para uma execução de pagamentos identificada em REGUH. Tipo de evento explicit | |||
| Recebimento de mercadorias conferido | Esta atividade indica que as quantidades e os valores da fatura foram conferidos com sucesso com o documento de recebimento de mercadorias correspondente. É a validação final da conferência tripla. | ||
| Por que isso importa Acompanhar esta etapa ajuda a identificar ineficiências na conferência tripla e divergências entre as mercadorias recebidas e os itens cobrados pelo fornecedor. Onde encontrar Este evento é inferido pela presença de uma referência ao documento de material (recebimento de mercadorias) no item de linha da fatura, geralmente vinculada pelo histórico do item do pedido de compra. Coleta Inferido pela presença de uma referência ao documento de recebimento de mercadorias 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: Garanta que você tenha um usuário com acesso de leitura ao esquema do banco de dados SAP S/4HANA (geralmente SAPABAP1 ou similar), onde estão as visualizações CDS. Você precisará de uma ferramenta cliente SQL que se conecte ao banco de dados SAP HANA, como SAP HANA Studio, DBeaver ou outra ferramenta de consulta a bancos de dados.
- Identifique as principais visualizações CDS: As principais visualizações CDS para esta extração são I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails e I_PaymentProposalItem. Familiarize-se com os campos principais de cada uma.
- Defina o escopo da consulta: Abra o cliente SQL e conecte-se ao banco de dados SAP HANA. Antes de executar a consulta completa, defina o escopo da extração. Isso inclui configurar o identificador correto do sistema de origem, o período 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 cliente SQL. Ela usa Common Table Expressions (CTEs) para selecionar primeiro um conjunto inicial de faturas e, em seguida, criar um Event Log reunindo 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 de início e fim do 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ê quer analisar.
- Execute a consulta de extração: Execute a consulta SQL completa. Dependendo do volume de dados e do período selecionado, a execução pode levar de alguns minutos a várias horas.
- Revise os resultados preliminares: Quando a consulta terminar, revise as primeiras centenas de linhas do resultado. Confira a consistência dos dados, verifique se todas as colunas estão preenchidas como esperado e confirme se há diferentes valores de ActivityName.
- Exporte o Event Log: Exporte todo o conjunto de resultados do cliente SQL para um arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres. Dê um nome descritivo ao arquivo, por exemplo, sap_s4hana_ap_event_log.csv.
- Prepare o arquivo para carregamento: Antes de carregar os dados em uma ferramenta de Process Mining, confirme se os cabeçalhos das colunas no CSV correspondem exatamente aos nomes de atributos exigidos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName etc.
- Carregue os dados na ferramenta de Process Mining: Carregue o arquivo CSV gerado na sua plataforma de Process Mining e associe as colunas aos campos correspondentes de ID do caso, atividade e data e hora do evento.
Configuração
- Principais visualizações CDS: A extração combina visualizaçõ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 a data e hora exatas das alterações, como a inclusão ou remoção de um bloqueio de pagamento.
- I_WorkflowStatusDetails: para extrair eventos relacionados ao fluxo de aprovação de faturas.
- I_PaymentProposalItem: para identificar quando uma fatura é incluída em uma proposta de execução de pagamentos.
- I_Supplier: para complementar os dados com informações cadastrais do fornecedor, como VendorName.
- Filtro 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, para manter a performance em níveis administráveis.
- Filtros obrigatórios: Sempre filtre por CompanyCode. Analisar dados de todos os códigos de empresa de uma só vez pode ser muito lento e talvez não seja relevante para o negócio. Filtre também por JournalEntryType para selecionar apenas documentos relacionados a fornecedores (por exemplo, 'KR', 'RE').
- Pré-requisitos: O usuário que executa a consulta precisa ter autorização SELECT em todas as visualizações CDS usadas e no esquema HANA subjacente. O acesso ao nível da aplicação pela interface SAP GUI não é suficiente.
- Considerações de performance: Consultas diretas a 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.
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 há acesso direto de leitura ao esquema SAP HANA que contém as tabelas SAP S/4HANA relevantes. Obtenha a string de conexão, as credenciais, o nome do esquema e as autorizações necessárias para ler BKPF, ACDOCA e quaisquer tabelas adicionais configuradas para documentos estacionados, fluxo de aprovação, compras, recebimento de mercadorias, propostas de pagamento, compensações e estornos.
- Confirme o modelo técnico de dados no sistema de destino antes de executar a consulta. Valide os nomes físicos, os campos-chave, os campos de data e hora, as relações de estorno e pagamento e os dados persistidos do fluxo de aprovação usados pelo sistema. Substitua cada espaço reservado entre colchetes na consulta pelo objeto ou campo correspondente do sistema. Não presuma que os dados do fluxo de aprovação ou dos 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]. Comece com um período de três a seis meses e amplie-o depois de validar a performance e a integridade dos dados.
- Execute a consulta SQL em um cliente SQL SAP HANA aprovado, como 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 se Invoice é o identificador do caso, se ActivityName contém os 15 nomes de atividade exigidos, se EventTime está preenchido e apresenta uma sequência cronológica plausível, se SourceSystem identifica SAP S/4HANA e se LastDataUpdate contém a data e hora de atualização da extração. Revise eventos duplicados, relações de estorno e junções de documentos antes de carregar os dados.
- Aplique os mapeamentos específicos necessários para o sistema. Por exemplo, mapeie a origem configurada de documentos estacionados para Invoice Parked, a origem configurada do fluxo de aprovação para Invoice Routed For Approval, Invoice Approved e Invoice Rejected, e a origem configurada de pagamentos para Payment Proposal Created e Payment Executed. Preserve os identificadores de origem em colunas adicionais se precisar garantir a auditabilidade.
- Exporte o resultado como arquivo delimitado ou conjunto de resultados do banco de dados, com um evento por linha. Use a codificação UTF-8, mantenha as datas e horas em um único fuso horário, preserve os nomes exatos das colunas Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber e InvoiceDueDate e não agregue atividades por fatura.
- Carregue o Event Log no ProcessMind e configure Invoice como identificador do caso, ActivityName como coluna de atividade e EventTime como coluna de data e hora do evento. Verifique se os atributos opcionais estão associados aos campos correspondentes. Como o ProcessMind lê o Event Log como está, confirme que cada atividade que você quer visualizar já está 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 relevante na origem, conforme a atividade extraída. Amplie o período somente depois de validar o tempo de execução da consulta e o período de retenção da origem.
- Filtro por empresa: Configure [Company code filter] para limitar a extração aos códigos de empresa necessários. Se não for preciso restringir os dados, use uma seleção controlada de todas as empresas, em vez de executar 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 esquema 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 ao HANA precisa ser adaptada às aplicações ativadas, extensões, configuração do fluxo de aprovação e modelo de dados do sistema.
- Tratamento de data e hora: Normalize todas as datas e horas de origem para um único fuso horário. Quando houver apenas uma data, use um 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 reúna 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 à data e hora de avaliação configuradas e que não tenham um evento de compensação até esse momento. A consulta usa [Evaluation timestamp] nesse cálculo.
- Performance: Restrinja o período inicial e o escopo de empresas, filtre campos indexados ou relevantes para particionamento, evite selecionar colunas 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 a data e hora de execução da extração. Para carregamentos incrementais, mantenha um ponto de controle baseado na data e hora da alteração relevante na origem e inclua um período retroativo para capturar atualizações tardias e estornos.
- Pré-requisitos: Autorizações necessárias no banco de dados, acesso aprovado ao ambiente de produção, conhecimento da configuração do Universal Journal do sistema, acesso às origens configuradas de documentos estacionados, compras, recebimento de mercadorias, fluxo de aprovação, pagamentos, compensações e estornos, além das aprovações de licenciamento SAP ou governança aplicáveis.
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 planejamento: Antes de programar, trabalhe com analistas de negócios para confirmar as condições exatas de disparo e os campos de dados de cada uma das 15 atividades exigidas. Identifique as tabelas SAP relevantes, os tipos de documento (por exemplo, 'KR', 'RE') e os códigos de empresa que farão parte do escopo.
- Crie o programa ABAP: Abra o Editor ABAP 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 (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.
- Declare os 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.
- Selecione os dados principais: Inicie a lógica de extração selecionando o conjunto principal de faturas em RBKP (faturas de logística) e BKPF (faturas financeiras), com base nos critérios da tela de seleção. Armazene as chaves dessas faturas em uma tabela interna para orientar as consultas de dados subsequentes.
- Extraia as atividades em sequência: Para cada fatura do conjunto principal, faça uma série de consultas para encontrar as datas e horas 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 de 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.
- Implemente a lógica dos 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 a data e hora definidas como a data de vencimento.
- Transforme e complemente os dados: Ao coletar os dados de cada atividade, preencha todos os atributos obrigatórios. Isso inclui consultar os nomes dos fornecedores em LFA1, converter datas e horas em uma única string de data e hora (CONCATENATE...INTO...) e definir o valor de SourceSystem.
- Gere o arquivo de saída: Depois de processar todas as faturas e as atividades correspondentes e reuni-las 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 o arquivo e prepare-o para carregamento: Use o código de transação CG3Y para baixar o arquivo gerado do servidor de aplicações para seu computador. Salve-o em formato CSV com codificação UTF-8. Antes de carregar o arquivo na ferramenta de Process Mining, confira se os cabeçalhos das colunas correspondem aos atributos exigidos (Invoice, ActivityName, EventTime etc.).
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 usar de 6 a 12 meses de dados para a análise inicial.
- Código de 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 seja absolutamente 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 de logística).
- Modo de execução: Para grandes volumes de dados, execute o programa como um job em segundo plano (SM36/SM37) para evitar tempos limite no processo de diálogo em primeiro plano. Agende a execução fora dos horários de pico.
- Caminho do arquivo de saída: Parâmetro 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 executa o relatório precisa ter autorização para ler as tabelas FI, CO e MM (BKPF, BSEG, RBKP, RSEG, LFA1), as tabelas de alteração de documentos (CDHDR, CDPOS) e as tabelas do fluxo de aprovação. Também é necessário o objeto de autorização S_DATASET para gravar arquivos no servidor de aplicações.
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 aumentar a eficiência das operações de Contas a pagar. Comece hoje a simplificar e otimizar seu processo.
Evite 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 informar o cartão de crédito. Comece em poucos minutos.