Modelo de Dados: Processamento de Faturas de Contas a Pagar
O Seu Modelo de Dados para Processamento de Faturas de Contas a Pagar
- Atributos recomendados para análise abrangente
- Atividades-chave do processo para rastrear com eficácia
- Orientação passo a passo para extração de dados
Atributos do Processamento de Faturas de Contas a Pagar
| Nome | Descrição | ||
|---|---|---|---|
Activity ActivityName | O nome de um evento de negócio ou etapa específica que ocorreu no ciclo de vida do processamento da fatura. | ||
Descrição A Atividade representa uma etapa ou ação distinta dentro do 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 as atividades é fundamental para o process mining. Ele 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 dada fatura forma sua jornada no processo. Por que é importante Ele define as etapas do processo, permitindo a visualização e análise do fluxo do processo, a identificação de gargalos e a detecção de ciclos de retrabalho. Onde obter Derivado de várias fontes, incluindo mudanças de status de documento (ex: BKPF-BSTAT), documentos de alteração (tabelas CDHDR/CDPOS) ou logs de workflow. Isso geralmente requer uma lógica de extração personalizada. Exemplos Fatura RecebidaFatura AprovadaPagamento EfetuadoFatura Bloqueada para Pagamento | |||
Event Time EventTime | A data e hora exatas em que a atividade ocorreu. | ||
Descrição Event Time é o timestamp associado a cada atividade, fornecendo a sequência cronológica de eventos para uma fatura. Esses dados são essenciais para entender o fluxo do processo e realizar qualquer análise baseada em tempo. Na análise, o Event Time é usado para ordenar as atividades corretamente, calcular tempos de ciclo entre diferentes etapas, identificar tempos de espera e analisar o desempenho do processo em diferentes períodos (ex: mês a mês). É a base de todos os KPIs baseados em duração. Por que é importante Este timestamp é crítico para ordenar os eventos cronologicamente e calcular todas as métricas baseadas no tempo, como tempos de ciclo e durações, que são fundamentais para o Process Mining. Onde obter Originado de vários campos de data/hora em tabelas 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ção (CDHDR-UDATE/UTIME). Exemplos 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
Fatura Invoice | O identificador único para um documento de fatura, servindo como o ID de caso principal para o 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, trata-se tipicamente de uma chave composta pelo Código da Empresa (BUKRS), um Número de Documento único (BELNR) e o Ano Fiscal (GJAHR). Analisar por Fatura permite uma visão completa ponta a ponta do ciclo de vida da fatura. Isto é fundamental para calcular métricas chave como o tempo total de ciclo, identificar gargalos para faturas individuais e compreender os diferentes caminhos que uma fatura pode percorrer no processo. Por que é importante Ele identifica de forma única a jornada de cada fatura, tornando possível rastrear seu ciclo de vida completo e analisar o desempenho do processo caso a caso. Onde obter Esta é uma chave composta derivada das tabelas BKPF (Cabeçalho do Documento Contábil) ou RBKP (Cabeçalho do Documento: Recebimento de Fatura), utilizando os campos BUKRS, BELNR e GJAHR. Exemplos 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
Sistema de Origem SourceSystem | O sistema de onde os dados foram extraídos. | ||
Descrição Este atributo identifica a origem dos dados do processo. Para esta vista, o valor será tipicamente 'SAP S/4HANA'. Em ambientes com múltiplos ERPs ou sistemas integrados, este campo é crucial para a linhagem e segregação de dados. Assegura que a análise é realizada no dataset correto e ajuda a diagnosticar problemas de qualidade de dados, rastreando-os até à origem. Por que é importante Identifica a origem dos dados, o que é crucial para a governança de dados, solução de problemas e em ambientes multi-sistema. Onde obter Este é tipicamente um valor estático adicionado durante o processo de extração de dados para rotular a origem do conjunto de dados. Exemplos SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
Última Atualização de Dados LastDataUpdate | O timestamp que indica quando os dados para este registo foram atualizados pela última vez a partir do sistema de origem. | ||
Descrição Este atributo fornece a data e hora da extração ou atualização mais recente de dados do SAP S/4HANA. É um campo de metadados crucial para compreender a atualidade dos dados que estão sendo analisados. Esta informação é importante para que os usuários saibam quão atualizada está a análise do processo. Ajuda a gerenciar expectativas sobre a latência dos dados e é vital para o agendamento de atualizações de dados e a manutenção da integridade dos mesmos. Por que é importante Indica a atualização dos dados, garantindo que os usuários saibam o quão atualizada está a sua análise de processo. Onde obter Este valor é gerado e carimbado em cada registro no momento da extração de 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 (Company Code) é a menor unidade organizacional para a qual um conjunto completo e autônomo de contas pode ser elaborado para relatórios externos. No contexto de Contas a Pagar, representa a entidade jurídica que deve dinheiro ao fornecedor. A análise por Código da Empresa permite comparar o desempenho do processo entre diferentes entidades jurídicas dentro da organização. Isso ajuda a identificar quais partes do negócio estão seguindo processos padronizados e quais apresentam maior eficiência, tempos de ciclo mais longos ou taxas de retrabalho mais altas. Por que é importante Permite a comparação do desempenho do processo entre diferentes entidades legais, ajudando a identificar problemas e melhores práticas específicas de regiões ou unidades de negócio. Onde obter Encontrado nas tabelas de cabeçalho de documento, principalmente BKPF-BUKRS para faturas FI e RBKP-BUKRS para faturas MM. Exemplos 10001710US01DE01 | |||
Data de Vencimento da Fatura InvoiceDueDate | A data limite para o pagamento da fatura ao fornecedor. | ||
Descrição A Data de Vencimento da Fatura é o prazo limite para pagar o fornecedor, a fim de evitar multas por atraso e manter um bom relacionamento. Esta data é calculada com base na data base da fatura e nas condições de pagamento acordadas com o fornecedor. Esta data é essencial para o dashboard de 'Conformidade e Envelhecimento de Pagamentos' e para o KPI de 'Taxa de Pagamento Dentro do Prazo'. Ao comparar a data de vencimento com a data real de pagamento, a análise pode revelar se os pagamentos estão a ser feitos dentro do prazo, antecipadamente ou com atraso, o que acarreta consequências financeiras e relacionais diretas. Por que é importante Este é o fator principal para a análise de pagamentos no prazo, permitindo a medição do desempenho de pagamento e o seu impacto nos relacionamentos com fornecedores e nas multas por atraso. Onde obter Esta data é frequentemente calculada. A data de vencimento líquida encontra-se no campo BSEG-NETDT. Pode também 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 Utilizador UserName | O ID do utilizador da pessoa que realizou a atividade. | ||
Descrição Este atributo registra o ID de usuário SAP responsável pela execução de uma atividade específica, como lançamento, aprovação ou compensação de uma fatura. Ele vincula as etapas do processo a usuários individuais. A análise por Nome de Usuário é essencial para entender a distribuição da carga de trabalho, identificar os colaboradores de melhor desempenho e apontar usuários que possam precisar de treinamento adicional. Também é fundamental para analisar gargalos de aprovação em dashboards, pois ajuda a identificar quais aprovadores específicos estão causando atrasos no processo. Por que é importante Atribui atividades a indivíduos específicos, permitindo a análise do desempenho do usuário, da carga de trabalho e da conformidade com as políticas de segregação de funções. Onde obter Geralmente encontrado em tabelas de cabeçalho como BKPF-USNAM (Lançado por) ou em tabelas de documentos de alteração CDHDR-USERNAME (Alterado por). Exemplos ABROWNJSMITHAP_AUTOMATION | |||
Nome do Fornecedor VendorName | O nome do fornecedor que submeteu a fatura. | ||
Descrição Este atributo contém o nome oficial do fornecedor. Está ligado através do Número do Fornecedor armazenado no documento da fatura. A análise de fornecedores é crucial para gerir relacionamentos com fornecedores e identificar problemas de processo específicos de certos fornecedores. Pode ajudar a responder a perguntas como 'Que fornecedores submetem o maior número de faturas com discrepâncias?' ou 'Estamos a pagar consistentemente certos fornecedores estratégicos dentro do prazo?'. É também um campo chave, juntamente com o número e o valor da fatura, para detetar potenciais pagamentos duplicados. Por que é importante Permite analisar o desempenho do processo por fornecedor, ajudando a identificar problemas e gerenciar relacionamentos estratégicos. Onde obter Recuperado da tabela de dados mestre de fornecedores LFA1 (campo NAME1), através da ligação pelo Número do Fornecedor (LIFNR) encontrado em BKPF ou RBKP. Exemplos Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
Número da Ordem de Compra PurchaseOrderNumber | O identificador único do pedido de compra associado à fatura, se aplicável. | ||
Descrição Este atributo vincula uma fatura a um pedido de compra (PC) previamente aprovado. A presença de um número de pedido de compra é a base para o processo de conciliação de 3 vias (Pedido de Compra – Fatura – Recebimento de Mercadorias). Este é um atributo vital para análises de conformidade e eficiência. É utilizado para calcular o KPI 'Percentual de Faturas sem Pedido de Compra', que mede a aderência às políticas de aquisição. Também é fundamental para o dashboard de 'Desempenho da Conciliação de 3 Vias', permitindo a análise do processo de conciliação para faturas suportadas por um PC. Por que é importante Crucial para analisar a eficiência da conciliação de três vias e medir a conformidade com as políticas de compras, identificando faturas processadas sem um Pedido de Compra (PO). 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 do documento original. | ||
Descrição Este é o valor total da fatura conforme apresentado pelo fornecedor. Inclui o custo de bens ou serviços, impostos e quaisquer outros encargos, antes de quaisquer deduções ou descontos. O Valor da Fatura é um atributo financeiro crítico utilizado para uma ampla gama de análises. Ajuda a priorizar faturas de alto valor, a compreender o impacto financeiro dos atrasos no processo (por exemplo, multas por atraso em faturas de grande valor) e a segmentar o processo (por exemplo, 'As faturas de alto valor seguem um caminho de aprovação diferente?'). É também essencial para identificar potenciais pagamentos duplicados. Por que é importante Fornece contexto financeiro ao processo, permitindo análises baseadas em valor, priorização de faturas de alto valor e quantificação de impactos financeiros. Onde obter Encontrado em tabelas como RBKP-RMWWR (valor bruto da fatura) para faturas MM ou calculado a partir de itens de linha em BSEG (campo WRBTR) para faturas FI. Exemplos 1500.00250.7512345.50 | |||
Data de Compensação ClearingDate | A data em que um pagamento foi efetuado e a fatura foi liquidada 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', marcando a etapa final para a maioria dos percursos de fatura bem-sucedidos. Esta data é usada para calcular a data real de pagamento para comparação com a Data de Vencimento da Fatura. É, portanto, essencial para o cálculo do KPI de 'Taxa de Pagamento Dentro do Prazo' e para qualquer análise relacionada ao desempenho de pagamentos. Marca também o ponto final para o cálculo do tempo de ciclo ponta a ponta da fatura. Por que é importante Marca a liquidação final de uma fatura, servindo como ponto final para os cálculos de tempo de ciclo e a base para a análise de pagamentos em dia. Onde obter Encontrado nas tabelas de itens compensados, como BSAK-AUGDT para fornecedores. Exemplos 2023-10-282023-11-142024-01-09 | |||
Desconto Obtido DiscountTaken | Flag booleana que indica se um desconto por pagamento antecipado foi aplicado com sucesso. | ||
Descrição Este atributo indica se um desconto de pronto pagamento foi efetivamente aproveitado no momento da quitação da fatura. É um componente crucial para avaliar a eficiência financeira no processo de Contas a Pagar. Este indicador é a base do KPI 'Taxa de Captura de Descontos por Pagamento Antecipado'. Ao filtrar as faturas onde um desconto era possível (com base nas Condições de Pagamento) e analisar este atributo, uma empresa pode calcular com precisão quanto dinheiro foi economizado e quantas oportunidades de economia foram perdidas. Isso oferece uma medida clara e quantificável do desempenho do AP. Por que é importante Mede diretamente o sucesso na captura de descontos por pronto pagamento disponíveis, o que tem um impacto direto no resultado financeiro da empresa. Onde obter Derivado verificando se o campo de valor do desconto (BSEG-SKNTO) é maior que zero no documento de pagamento. Exemplos truefalse | |||
É Automatizado IsAutomated | Indica se a atividade foi realizada automaticamente pelo sistema, e não por um usuário humano. | ||
Descrição Este atributo booleano distingue entre atividades iniciadas por humanos e aquelas executadas por tarefas de sistema, workflows ou bots. Por exemplo, uma execução de pagamento automatizada ou um lançamento de fatura gerado pelo sistema seria marcado como automatizado. A análise deste atributo ajuda a compreender o nível de automação no processo de Contas a Pagar. Pode ser usado para medir o sucesso das iniciativas de automação, comparar a eficiência das etapas automatizadas em relação às manuais e identificar novas oportunidades para automação. Por que é importante Ajuda a medir o grau de automação no processo, possibilitando a análise da eficácia da automação e a identificação de oportunidades para melhoria contínua. Onde obter Derivado com base no Nome do Usuário (ex: IDs de usuário do sistema como 'SAP_SYSTEM' ou 'BATCHUSER') ou códigos de transação específicos associados a tarefas automatizadas. Exemplos truefalse | |||
É Pagamento em Atraso IsLatePayment | Flag booleana que indica se a fatura foi paga após sua data de vencimento. | ||
Descrição Este atributo calculado é um indicador simples de verdadeiro/falso que aponta se o pagamento de uma fatura foi realizado após a sua data de vencimento oficial. É derivado da comparação entre a 'Data de Compensação' e a 'Data de Vencimento da Fatura'. Este indicador simplifica a análise para o dashboard de 'Conformidade e Atraso de Pagamentos' e o KPI 'Taxa de Pagamento no Prazo'. Ele permite uma filtragem e agregação facilitadas para contabilizar o número de pagamentos em atraso, calcular a percentagem de pagamentos realizados no prazo e identificar fornecedores ou códigos de empresa com altas taxas de pagamentos atrasados. Por que é importante Mede diretamente a conformidade com as condições de pagamento, simplifica o cálculo do KPI de pagamento pontual e ajuda a identificar áreas com baixo desempenho de pagamento. Onde obter Atributo calculado. A lógica é: SE DataCompensação > DataVencimentoFatura ENTÃO verdadeiro SENÃO falso. Exemplos truefalse | |||
Moeda da Fatura InvoiceCurrency | O código da moeda para o valor da fatura (por exemplo, USD, EUR). | ||
Descrição Este atributo especifica a moeda na qual o Valor da Fatura é expresso. Ele oferece um contexto essencial para todos os valores financeiros. Em uma organização multinacional, analisar faturas sem considerar a sua moeda pode ser enganoso. Este campo permite o tratamento adequado dos dados financeiros, seja convertendo todos os valores para uma única moeda de reporte, seja segmentando a análise por moeda para compreender as atividades financeiras regionais. Por que é importante Fornece o contexto necessário para o Valor da Fatura, permitindo análises financeiras e relatórios precisos, especialmente em contextos multinacionais. Onde obter Encontrado nas tabelas de cabeçalho de documento, principalmente BKPF-WAERS ou RBKP-WAERS. Exemplos USDEURGBPJPY | |||
Motivo do Bloqueio BlockingReason | A razão pela qual uma fatura é bloqueada para pagamento, indicando uma discrepância. | ||
Descrição Quando uma fatura falha uma verificação de validação durante o 3-way match ou outras etapas de verificação, é bloqueada para pagamento. O Motivo de Bloqueio especifica a natureza do problema, como uma discrepância de quantidade, variação de preço ou falta de recebimento de mercadorias. Este atributo é crítico para o dashboard de 'Análise de Retrabalho por Discrepâncias 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 'Variação de preço' for um motivo comum, pode indicar problemas com os dados mestre no sistema de compras. Por que é importante Oferece insight direto nas causas-raiz de divergências de faturas e retrabalho, possibilitando esforços de melhoria de processo direcionados. Onde obter Armazenado em tabelas de itens de linha de fatura como RSEG, em campos que começam com SPGR* (p. ex., SPGRP, SPGRQ, SPGRT). Também pode ser encontrado em RBKP_BLOCKED. Exemplos Divergência de PreçoDivergência de QuantidadeEntrada de Mercadoria Ausente | |||
Número da Fatura do Fornecedor VendorInvoiceNumber | O número da fatura fornecido pelo fornecedor no seu documento. | ||
Descrição Este é o número de referência do sistema contábil do próprio fornecedor, conforme impresso no documento de fatura físico ou eletrônico. É inserido manualmente ou capturado via OCR durante o recebimento da fatura. Este campo é extremamente importante para fins operacionais e para análise, especialmente para o dashboard de 'Pagamentos de Faturas Duplicadas Potenciais'. Um método comum para detectar duplicidades é procurar múltiplos documentos de fatura internos que compartilham o mesmo Nome do Fornecedor, Número da Fatura do Fornecedor e Valor da Fatura. É a principal referência externa para uma fatura. Por que é importante É um campo chave para a detecção de potenciais pagamentos duplicados e serve como a principal referência externa para a comunicação com fornecedores. Onde obter Armazenado no campo 'Referência' no cabeçalho do documento, tipicamente BKPF-XBLNR. Exemplos INV-2023-9876733401120231015-001 | |||
Prazos de Pagamento PaymentTerms | As condições acordadas com o fornecedor para o pagamento de uma fatura, frequentemente incluindo oportunidades de desconto. | ||
Descrição As Condições de Pagamento definem as regras para as datas de vencimento dos pagamentos e potenciais descontos por pagamento antecipado. Por exemplo, um termo como 'Z001' pode corresponder a 'Pagável em 30 dias, 2% de desconto se pago em 10 dias'. Este atributo é a base para o dashboard 'Taxa de Captura de Desconto 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 aproveitados revela oportunidades de economia perdidas e mede a eficiência do processo de pagamento. Por que é importante É essencial para analisar oportunidades de desconto por pagamento antecipado, medir o desempenho financeiro do processo de pagamento e identificar economias perdidas. Onde obter Encontrado nos itens de linha do fornecedor, tabela BSEG-ZTERM, ou no cabeçalho da fatura em RBKP-ZTERM. Exemplos Z0010001NT30 | |||
Tempo de Processamento ProcessingTime | A duração de uma única atividade. | ||
Descrição Tempo de Processamento, ou duração da atividade, é o tempo decorrido entre o início e o fim de uma atividade. Esta métrica é calculada a partir dos dados do log de eventos. Esta medida calculada é crucial para o dashboard 'Duração da Atividade e Mapa de Calor de Retrabalho'. Ele ajuda a identificar quais etapas específicas do processo consomem mais tempo. Analisar os tempos de processamento pode destacar ineficiências, como etapas de aprovação longas ou atividades de resolução de divergências demoradas, orientando esforços de melhoria direcionados. Por que é importante Quantifica o tempo gasto em atividades individuais, ajudando a identificar as etapas mais demoradas e os gargalos no processo. Onde obter Calculado pela diferença entre o EventTime da atividade atual e o EventTime da atividade subsequente para a mesma fatura. Exemplos P2DT3H4MPT5HP7D | |||
Tipo de Documento da Fatura InvoiceDocumentType | Classificação do documento de fatura, que define como ele é processado no SAP. | ||
Descrição O Tipo de Documento é um elemento chave de configuração no SAP que categoriza documentos contabilísticos. Por exemplo, 'KR' é tipicamente usado para faturas de fornecedores, 'RE' para faturas MM e 'KG' para notas de crédito de fornecedores. Este tipo determina aspetos como o intervalo de numeração e quais campos são obrigatórios. Na análise de processo, filtrar por Tipo de Documento permite comparar os fluxos de processo para diferentes tipos de faturas. Por exemplo, o processo de aprovação para uma nota de crédito pode ser diferente do de uma fatura padrão. Isto é útil para o dashboard de 'Variantes de Encaminhamento de Aprovação de Faturas'. Por que é importante Permite segmentar o processo com base em como diferentes tipos de faturas são tratados, revelando variações nos caminhos e tempos de ciclo. Onde obter Diretamente da tabela de cabeçalho do documento, campo BKPF-BLART. Exemplos KRREKG | |||
Atividades de Processamento de Faturas de Contas a Pagar
| Atividade | Descrição | ||
|---|---|---|---|
Fatura Aprovada | A fatura recebeu todas as aprovações necessárias dentro do sistema de workflow. Esta é frequentemente a etapa final antes que uma fatura possa ser lançada ou desbloqueada para pagamento. | ||
Por que é importante Este marco chave marca o fim do ciclo de aprovação. O tempo entre o encaminhamento e a aprovação é uma métrica crítica para a eficiência. Onde obter Capturado dos logs do SAP Business Workflow como uma etapa de conclusão ou liberação final. Alternativamente, pode ser inferido da remoção de um bloqueio de pagamento após o roteamento. Captura Extraia eventos de conclusão de workflow dos logs de workflow SAP ou identifique o evento final de 'liberação'. Tipo de evento explicit | |||
Fatura Bloqueada para Pagamento | O sistema bloqueou a fatura, automaticamente ou manualmente, impedindo o seu pagamento. Isto deve-se tipicamente a discrepâncias de preço, quantidade ou aprovações em falta. | ||
Por que é importante Este é um indicador chave de problemas e retrabalho. A análise dos motivos e durações dos bloqueios ajuda a identificar as causas-raiz dos atrasos de pagamento e das ineficiências do processo. Onde obter Este é um status explícito registrado no campo Chave de Bloqueio de Pagamento (ZLSPR) no item de linha do fornecedor do documento contábil (tabela BSEG). Captura Registrado via documentos de alteração quando o campo BSEG-ZLSPR é preenchido com um motivo de bloqueio. Tipo de evento explicit | |||
Fatura Cancelada | O documento de fatura foi estornado, anulando efetivamente o seu impacto financeiro. Este é um estado final alternativo para o processo, frequentemente devido a lançamentos incorretos ou disputas com fornecedores. | ||
Por que é importante Acompanhar os cancelamentos ajuda a identificar as causas de falhas no processo, como envios duplicados ou dados incorretos da fatura, que podem indicar problemas nas etapas anteriores. Onde obter Este é registrado explicitamente quando um documento de estorno é criado. O cabeçalho do documento original (BKPF) terá o número do documento de estorno (STBLG) e o motivo do estorno preenchidos. Captura Identifique a data de lançamento do documento de estorno, que está vinculado no cabeçalho do documento original (BKPF-STBLG). Tipo de evento explicit | |||
Fatura Lançada | A fatura é registada formalmente na Contabilidade Geral, criando uma obrigação financeira. Um documento preliminar torna-se um documento lançado, ou é feito um lançamento direto. | ||
Por que é importante Este é um marco financeiro crítico. Ele confirma a obrigação de pagamento da empresa e é frequentemente um pré-requisito para o agendamento do pagamento. Onde obter Este evento é identificado pela Data de Lançamento (BUDAT) no cabeçalho do documento (BKPF). Um documento lançado possui um status de documento (BKPF-BSTAT) em branco. Captura Utilize o timestamp de lançamento (BKPF-BUDAT) para documentos que não estão estacionados (BKPF-BSTAT está em branco). Tipo de evento explicit | |||
Fatura Recebida | Esta atividade marca a criação de um documento de fatura no SAP, seja manual ou através de uma interface automatizada como OCR/VIM. Este evento é tipicamente registado a partir da data e hora de criação do cabeçalho do documento contabilístico. | ||
Por que é importante Como ponto de partida do processo, esta atividade é essencial para calcular o tempo de ciclo completo da fatura e medir a produtividade de todo o processo de Contas a Pagar. Onde obter Este evento é capturado da tabela de cabeçalho do documento contábil (BKPF), utilizando a data (CPUDT) e a hora (CPUTM) de criação do documento. Captura Utilize o timestamp de criação (BKPF-CPUDT, BKPF-CPUTM) para o documento da fatura. Tipo de evento explicit | |||
Pagamento Efetuado | Pagamento efetuado na fatura. Registrado após a conclusão da execução do pagamento e o lançamento do documento de pagamento. | ||
Por que é importante Esta atividade é crucial para a análise de cash flow e para medir o KPI de 'Taxa de Pagamento Dentro do Prazo', comparando esta data com a data de vencimento da fatura. Onde obter Este é capturado 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 (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 | |||
Pagamento Liquidado | Esta atividade marca o encerramento final da fatura, onde o pagamento e a fatura são reconciliados entre si no razão auxiliar. Isto significa que o processo está concluído. | ||
Por que é importante Como o fim definitivo do processo, esta atividade é essencial para o cálculo preciso do tempo de ciclo de ponta a ponta. Confirma que a obrigação foi liquidada. Onde obter Este é um evento explícito, marcado pelo preenchimento do campo Data de Compensação (AUGDT) no item de linha do fornecedor do documento da fatura (tabela BSEG). Captura Utilize a data de compensação (BSEG-AUGDT) do item de linha da fatura. Tipo de evento explicit | |||
Data de Vencimento da Fatura Expirada | Evento calculado que indica que a data de vencimento líquida da fatura expirou sem compensação de pagamento, sinalizando atraso. | ||
Por que é importante Essencial para o dashboard de 'Conformidade e Envelhecimento de Pagamentos', esta atividade ajuda a identificar e gerenciar proativamente faturas em atraso e analisar as causas raiz para pagamentos tardios. Onde obter Este não é um evento explícito no SAP. É calculado comparando a data atual do sistema com a Data de Vencimento Líquida (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 de vencimento líquida da fatura. Tipo de evento calculated | |||
Discrepância Resolvida | Esta atividade indica que um problema previamente identificado, que provavelmente causou um bloqueio de pagamento, foi investigado e resolvido. Isto é registado quando um bloqueio de pagamento é removido de uma fatura. | ||
Por que é importante Monitorizar este ciclo de retrabalho é crucial para o dashboard de 'Análise de Retrabalho por Discrepâncias em Faturas'. Ajuda a quantificar o tempo e o esforço despendidos na correção de erros. Onde obter Este é inferido de documentos de alteração que mostram a remoção de um bloqueio de pagamento. O log de alterações para o campo BSEG-ZLSPR é a fonte primária. Captura Identifique documentos de alteração para a tabela BSEG onde o campo ZLSPR é alterado de um valor para vazio. Tipo de evento inferred | |||
Fatura Encaminhada para Aprovação | A fatura foi submetida a um workflow para as aprovações necessárias, com base nas regras de negócio. Isto marca o início do subprocesso de aprovação. | ||
Por que é importante Esta atividade é o ponto de partida para medir o KPI de 'Tempo Médio de Aprovação de Faturas' e analisar gargalos de aprovação. Onde obter Pode ser capturado dos logs do SAP Business Workflow (tabelas SWW*) que registram o início de uma instância de workflow vinculada ao objeto da fatura (ex: BUS2081). Captura Extraia eventos de início de workflow dos logs de workflow SAP (ex: tabela SWW_WIHEAD) vinculados ao documento de 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. Este é frequentemente um passo intencional para salvar um documento incompleto para processamento ou aprovação posterior. | ||
Por que é importante Monitorizar faturas estacionadas ajuda a identificar atrasos antes do início do processo formal de lançamento e pode realçar problemas de integridade dos dados ou de validação inicial. Onde obter Este status é inferido do campo de status do documento no cabeçalho do documento contábil (BKPF-BSTAT = 'V' para Documento Estacionado). O evento ocorre quando o status é definido. Captura Identifique documentos de alteração para a tabela BKPF onde o campo BSTAT está definido como 'V' (Vor-erfasst/Pré-lançado). Tipo de evento inferred | |||
Fatura Rejeitada | Um aprovador rejeitou a fatura no workflow de aprovação. Isso geralmente a envia de volta ao processador para correção ou esclarecimento. | ||
Por que é importante Monitorizar as rejeições evidencia ciclos de retrabalho no processo de aprovação e pode indicar problemas de conformidade com a política ou de codificação incorreta da fatura. Onde obter Este é capturado como um evento de resultado específico dentro dos logs do Workflow de Negócios SAP associados à fatura. Captura Extraia eventos de status 'rejeitado' dos logs de workflow SAP. Tipo de evento explicit | |||
Pedido de Compra Conferido | Esta atividade significa que a fatura foi correspondida com sucesso a um pedido de compra correspondente. Esta é uma etapa crítica no processo de correspondência tripla para faturas baseadas em aquisições. | ||
Por que é importante Analisar esta atividade ajuda a medir a eficiência do processo de correspondência e é fundamental para os KPIs de '3-Way Matching Performance' e 'PO-Less Invoice Percentage'. Onde obter Este é inferido quando um item de linha da fatura nas tabelas BSEG ou ACDOCA contém um número (EBELN) e um item (EBELP) válidos de Pedido de Compra. Captura Inferido da presença de uma referência de Pedido de Compra (BSEG-EBELN) no documento de fatura no momento da criação. Tipo de evento inferred | |||
Proposta de Pagamento Criada | A fatura foi incluída numa proposta de pagamento como parte de um programa de pagamentos (por exemplo, F110). Está agora agendada para pagamento, aguardando a execução final do programa. | ||
Por que é importante Esta atividade mostra a transição de uma obrigação em aberto para um item que está a ser ativamente preparado 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 pagamento, especificamente REGUP (Itens Processados do Programa de Pagamento) e REGUH (Cabeçalho). Captura Identifique quando uma fatura aparece na tabela REGUP para uma execução de pagamento identificada em REGUH. Tipo de evento explicit | |||
Recibo de Mercadorias Correspondido | Esta atividade significa que as quantidades e valores da fatura foram correspondidos com sucesso a um documento de entrada de mercadoria correspondente. Esta é a validação final num cenário de correspondência tripla. | ||
Por que é importante Acompanhar este ponto ajuda a identificar ineficiências no processo de conferência tripla (3-way matching) e a detetar discrepâncias entre os bens recebidos e o que está a ser faturado pelo fornecedor. Onde obter Este é inferido da presença de uma referência de documento de material (recebimento de mercadorias) no item de linha da fatura, frequentemente vinculada através do histórico do item do pedido de compra. Captura Inferido da presença de uma referência de documento de Recebimento de Mercadoria no item de linha da fatura (ex: em RSEG para faturas MIRO). Tipo de evento inferred | |||
Guias de Extração
Etapas
- Pré-requisitos e Acesso: Certifique-se de ter um usuário com acesso de leitura ao esquema do banco de dados SAP S/4HANA (geralmente SAPABAP1 ou similar) onde as views CDS residem. Você precisará de uma ferramenta cliente SQL capaz de se conectar ao banco de dados SAP HANA, como SAP HANA Studio, DBeaver ou ferramentas de consulta de banco de dados similares.
- Identificar Views CDS Essenciais: As views CDS primárias para esta extração são I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails e I_PaymentProposalItem. Familiarize-se com seus campos-chave.
- Definir 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 sua extração. Isso envolve configurar o identificador correto do sistema de origem, o intervalo de datas para as faturas (CreationDateTime) e os Códigos da Empresa relevantes.
- Preparar a Consulta Principal: Copie a consulta SQL completa fornecida na seção query para o seu cliente SQL. A consulta usa Common Table Expressions (CTEs) para primeiro selecionar uma população base de faturas e, em seguida, constrói um log de eventos unindo dados para 15 atividades diferentes.
- Definir Parâmetros da Consulta: Na consulta SQL copiada, localize as variáveis de placeholder. Substitua '[YYYY-MM-DD]' pelas datas de início e fim do seu período de análise. Substitua '[Your Company Code 1]', '[Your Company Code 2]' pela lista de Códigos da Empresa SAP que você deseja analisar.
- Executar 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 para ser concluído.
- Revisar Resultados Preliminares: Assim que a consulta terminar, revise as primeiras centenas de linhas do resultado. Verifique a consistência dos dados, certifique-se de que todas as colunas estão preenchidas conforme o esperado e verifique se diferentes valores de ActivityName estão presentes.
- Exportar o Log de Eventos: Exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Certifique-se de que o arquivo esteja codificado em UTF-8 para evitar problemas de caracteres. Nomeie o arquivo de forma descritiva, por exemplo, sap_s4hana_ap_event_log.csv.
- Preparar para Upload: Antes de fazer o upload para uma ferramenta de process mining, confirme que os cabeçalhos das colunas no arquivo CSV correspondem exatamente aos nomes dos atributos exigidos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Fazer 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
- Principais Views CDS: A extração se baseia em uma combinação de CDS Views padrão do S/4HANA. As views principais são:
- I_JournalEntry & I_JournalEntryItem: Para cabeçalhos de documentos financeiros, itens, 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 de pedidos de compra e bloqueios de pagamento.
- I_ChangeDocument: Para rastrear o timestamp exato de mudanças, 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 em uma proposta de execução de pagamento.
- I_Supplier: Para enriquecer os dados com informações mestre de fornecedores, como VendorName.
- Filtro por Período: É fundamental aplicar um filtro de período para limitar o volume de dados. A consulta fornecida filtra por CreationDateTime na CTE Invoices_Base. Recomenda-se um período de 3 a 6 meses para uma análise inicial, para garantir um desempenho gerenciável.
- Filtros Obrigatórios: Sempre filtre por CompanyCode. Analisar dados de todas as empresas de uma só vez pode ser extremamente lento e não ser relevante para o negócio. Além disso, filtre por JournalEntryType para selecionar apenas documentos relacionados a fornecedores (ex.: 'KR', 'RE').
- Pré-requisitos: O usuário do banco de dados que executa a consulta deve ter autorização de SELECT em todas as CDS views utilizadas na consulta e no esquema HANA subjacente. O acesso em nível de aplicação no SAP GUI não é suficiente.
- Considerações de Desempenho: Consultas diretas em I_ChangeDocument podem ser intensivas em recursos. A consulta fornecida tenta mitigar isso pré-filtrando as faturas primeiro. Para conjuntos de dados muito grandes, considere executar a extração durante as horas de menor movimento ou em lotes menores de períodos.
a Consulta de Exemplo sql
`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
- Pré-requisitos e Acesso: Certifique-se de ter um usuário com acesso de leitura ao esquema do banco de dados SAP S/4HANA (geralmente SAPABAP1 ou similar) onde as views CDS residem. Você precisará de uma ferramenta cliente SQL capaz de se conectar ao banco de dados SAP HANA, como SAP HANA Studio, DBeaver ou ferramentas de consulta de banco de dados similares.
- Identificar Views CDS Essenciais: As views CDS primárias para esta extração são I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails e I_PaymentProposalItem. Familiarize-se com seus campos-chave.
- Definir 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 sua extração. Isso envolve configurar o identificador correto do sistema de origem, o intervalo de datas para as faturas (CreationDateTime) e os Códigos da Empresa relevantes.
- Preparar a Consulta Principal: Copie a consulta SQL completa fornecida na seção query para o seu cliente SQL. A consulta usa Common Table Expressions (CTEs) para primeiro selecionar uma população base de faturas e, em seguida, constrói um log de eventos unindo dados para 15 atividades diferentes.
- Definir Parâmetros da Consulta: Na consulta SQL copiada, localize as variáveis de placeholder. Substitua '[YYYY-MM-DD]' pelas datas de início e fim do seu período de análise. Substitua '[Your Company Code 1]', '[Your Company Code 2]' pela lista de Códigos da Empresa SAP que você deseja analisar.
- Executar 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 para ser concluído.
- Revisar Resultados Preliminares: Assim que a consulta terminar, revise as primeiras centenas de linhas do resultado. Verifique a consistência dos dados, certifique-se de que todas as colunas estão preenchidas conforme o esperado e verifique se diferentes valores de ActivityName estão presentes.
- Exportar o Log de Eventos: Exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Certifique-se de que o arquivo esteja codificado em UTF-8 para evitar problemas de caracteres. Nomeie o arquivo de forma descritiva, por exemplo, sap_s4hana_ap_event_log.csv.
- Preparar para Upload: Antes de fazer o upload para uma ferramenta de process mining, confirme que os cabeçalhos das colunas no arquivo CSV correspondem exatamente aos nomes dos atributos exigidos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Fazer 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
- Principais Views CDS: A extração se baseia em uma combinação de CDS Views padrão do S/4HANA. As views principais são:
- I_JournalEntry & I_JournalEntryItem: Para cabeçalhos de documentos financeiros, itens, 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 de pedidos de compra e bloqueios de pagamento.
- I_ChangeDocument: Para rastrear o timestamp exato de mudanças, 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 em uma proposta de execução de pagamento.
- I_Supplier: Para enriquecer os dados com informações mestre de fornecedores, como VendorName.
- Filtro por Período: É fundamental aplicar um filtro de período para limitar o volume de dados. A consulta fornecida filtra por CreationDateTime na CTE Invoices_Base. Recomenda-se um período de 3 a 6 meses para uma análise inicial, para garantir um desempenho gerenciável.
- Filtros Obrigatórios: Sempre filtre por CompanyCode. Analisar dados de todas as empresas de uma só vez pode ser extremamente lento e não ser relevante para o negócio. Além disso, filtre por JournalEntryType para selecionar apenas documentos relacionados a fornecedores (ex.: 'KR', 'RE').
- Pré-requisitos: O usuário do banco de dados que executa a consulta deve ter autorização de SELECT em todas as CDS views utilizadas na consulta e no esquema HANA subjacente. O acesso em nível de aplicação no SAP GUI não é suficiente.
- Considerações de Desempenho: Consultas diretas em I_ChangeDocument podem ser intensivas em recursos. A consulta fornecida tenta mitigar isso pré-filtrando as faturas primeiro. Para conjuntos de dados muito grandes, considere executar a extração durante as horas de menor movimento ou em lotes menores de períodos.
a Consulta de Exemplo sql
`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
- Especificação e projeto: Antes de começar a desenvolver, colabore com os analistas de negócios para confirmar as condições de gatilho e os campos de dados de cada uma das 15 atividades necessárias. Identifique as tabelas SAP relevantes, os tipos de documento (por exemplo, 'KR', 'RE') e os códigos da empresa incluídos no escopo.
- Criar programa ABAP: Abra o ABAP Editor pela transação SE38. Crie um novo programa executável, por exemplo, Z_PM_AP_INVOICE_EXTRACT. Dê um título descritivo e defina a aplicação como 'Contabilidade Financeira'.
- Definir tela de seleção: No programa, defina uma tela de seleção (usando as palavras‑chave PARAMETERS e SELECT-OPTIONS) para permitir que o usuário informe o período de extração (com base na data de criação da fatura), os códigos da empresa (BUKRS) e os tipos de documento da fatura (BLART). Inclua também um parâmetro para o caminho do arquivo de saída no servidor de aplicação.
- Declarações de dados: Defina uma estrutura de tabela interna alinhada ao formato final do Event Log (por exemplo, TY_EVENT_LOG), incluindo todos os atributos obrigatórios e recomendados. Declare tabelas internas para armazenar os dados selecionados de várias tabelas de origem do SAP, como BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS e REGUH.
- Seleção principal dos dados: Inicie a extração selecionando o conjunto principal de faturas em RBKP (faturas de Logística) e BKPF (faturas Financeiras), com base nos critérios informados na tela de seleção. Armazene as chaves primárias dessas faturas em uma tabela interna para direcionar as consultas subsequentes.
- Extrair atividades sequencialmente: Para cada fatura do conjunto principal, faça uma série de seleções para localizar os carimbos de data e hora e os detalhes de cada atividade de negócio. Por exemplo, consulte CDHDR e CDPOS para mudanças de bloqueio de pagamento, REGUH e REGUP para dados de execução de pagamentos e BKPF para detalhes de documentos de estorno. Acrescente um novo registro à tabela final do Event Log para cada atividade encontrada.
- Lógica para eventos calculados: Implemente lógica ABAP para atividades que não estão armazenadas diretamente em campos de tabela. Para o evento 'Vencimento da fatura ultrapassado', 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 ao vencimento, crie um novo registro de evento com o carimbo de data e hora definido para a data de vencimento.
- Transformação e enriquecimento: À medida que você coleta os dados de cada atividade, preencha todos os atributos obrigatórios. Isso inclui buscar o nome do fornecedor em LFA1, converter data e hora em um único carimbo de data e hora (CONCATENATE...INTO...) e definir o valor de SourceSystem.
- Gerar arquivo de saída: Depois de processar todas as faturas e suas atividades correspondentes e consolidá-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ção indicado na tela de seleção.
- Fazer o download e preparar o upload: Use a transação CG3Y para fazer o download do arquivo gerado do servidor de aplicação para sua máquina local. Garanta que o arquivo seja salvo em CSV codificado em UTF-8. Verifique se os cabeçalhos das colunas correspondem aos atributos exigidos (Invoice, ActivityName, EventTime, etc.) antes de fazer o upload para a ferramenta de Process Mining.
Configuração
- Intervalo de datas: Defina a opção de seleção P_CPUDT para a data de criação da fatura (BKPF-CPUDT ou RBKP-CPUDT). Para uma análise inicial, recomenda-se usar de 6 a 12 meses de dados.
- Código da empresa (P_BUKRS): Parâmetro obrigatório de SELECT-OPTIONS para filtrar códigos de empresa específicos. Processar todos os códigos de empresa de uma vez não é recomendável, a menos que seja realmente necessário.
- Tipo de documento da fatura (P_BLART): Parâmetro SELECT-OPTIONS para filtrar os tipos de documento relevantes. Exemplos comuns: 'KR' (fatura de fornecedor), 'KG' (nota de crédito do fornecedor), 'RE' (verificação de fatura logística).
- Modo de execução: Para grandes volumes, execute o programa como job em background (SM36/SM37) para evitar tempo limite na execução em primeiro plano. Agende a execução fora do horário de pico.
- Caminho do arquivo de saída: PARAMETER para informar o caminho e o nome do arquivo no servidor de aplicação SAP (por exemplo, no diretório /tmp/). O arquivo é gravado nesse local antes do download.
- Pré-requisitos: O usuário que executa o relatório precisa ter autorização para ler as tabelas de FI, CO e MM (BKPF, BSEG, RBKP, RSEG, LFA1), as tabelas de alterações (CDHDR, CDPOS) e as tabelas de workflow. Além disso, é necessário o objeto de autorização S_DATASET para gravar arquivos no servidor de aplicação.
a Consulta de Exemplo abap
`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.
`