Seu Template de Dados de Purchase to Pay - Processamento de Faturas
Seu Template de Dados de Purchase to Pay - Processamento de Faturas
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientações de extração para o SAP S/4HANA
Atributos do Processamento de Faturas - Purchase to Pay
| Nome | Descrição | ||
|---|---|---|---|
| Número da fatura InvoiceNumber | O identificador exclusivo do documento de fatura do fornecedor, servindo como o identificador principal do caso para o processo. | ||
| Descrição O Número da Fatura é o identificador exclusivo atribuído a cada fatura de fornecedor no SAP S/4HANA. Ele conecta todas as atividades relacionadas, como criação, parking, aprovação e pagamento, em uma única instância de processo coesa. No Process Mining, este atributo é fundamental para rastrear a jornada completa de cada fatura. Ele permite reconstruir todo o fluxo do processo, do recebimento ao pagamento final, possibilitando a análise de tempos de ciclo, gargalos e variações no nível de cada fatura individual. Por que é importante É a chave essencial para conectar todos os eventos relacionados, permitindo o rastreamento completo do ciclo de vida de uma fatura pelo sistema. Onde obter Este é o Número do Documento Contábil, encontrado na tabela BKPF, campo BELNR. Exemplos 190000000119000000451900000132 | |||
| Nome da Atividade ActivityName | O nome da atividade de negócio ou evento que ocorreu em um momento específico para uma fatura. | ||
| Descrição O Nome da Atividade descreve uma etapa específica ou mudança de status no ciclo de vida do processamento da fatura. Exemplos incluem 'Documento de Fatura Criado', 'Fatura Enviada para Aprovação', 'Bloqueio de Pagamento Definido' e 'Pagamento Executado'. Este atributo é crucial para construir o mapa de processo, que representa visualmente o fluxo de atividades. Analisar a sequência, frequência e duração entre essas atividades ajuda a identificar gargalos, loops de retrabalho e variações de processo fora de conformidade. É a espinha dorsal de qualquer análise de Process Mining. Por que é importante Define as etapas do processo, permitindo a visualização de mapas de processo e a análise de fluxos e variações. Onde obter Derivado de uma combinação de códigos de transação SAP (SY-TCODE), status de objetos de documentos de modificação (CDHDR/CDPOS) e valores de campos específicos que indicam mudanças de status. Exemplos Fatura EstacionadaFatura AprovadaPagamento Executado | |||
| Tempo do Evento EventTime | A data e hora precisas em que a atividade ocorreu. | ||
| Descrição O Event Time é o registro de data e hora que indica exatamente quando uma atividade aconteceu. Esse dado é essencial para calcular durações, tempos de ciclo e tempos de espera entre as etapas do processo. Nas análises de Process Mining, timestamps precisos são usados para medir KPIs de desempenho, como o 'Tempo Médio de Ciclo da Fatura'. Ao analisar o tempo decorrido entre as atividades, as empresas podem localizar gargalos onde as faturas ficam retidas e identificar chances de acelerar o processo. Por que é importante Este timestamp é a base de todas as análises temporais, incluindo monitoramento de performance, identificação de gargalos e acompanhamento de SLAs. Onde obter Geralmente extraído das tabelas de documentos de alteração CDHDR (Cabeçalho) e CDPOS (Item), usando os campos UDATE e UTIME. Para alguns eventos, pode vir das datas de criação ou entrada em tabelas como BKPF (CPUDT, CPUTM). Exemplos 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Código da Empresa CompanyCode | A unidade organizacional que representa uma empresa legalmente independente para a qual são criadas as demonstrações financeiras. | ||
| Descrição A Empresa (Company Code) é uma unidade organizacional fundamental no SAP Finance. Cada fatura é atribuída a uma empresa específica, que determina a entidade legal responsável pela transação. No Process Mining, filtrar ou comparar por Empresa é essencial para analisar o desempenho do processo em diferentes unidades de negócio ou países. Ajuda a identificar diferenças regionais de eficiência, conformidade e níveis de automação, apoiando iniciativas de melhoria direcionadas. Por que é importante Permite segmentar e comparar o desempenho do faturamento entre diferentes entidades legais ou localizações geográficas da organização. Onde obter Este é um campo padrão na tabela de cabeçalho do documento BKPF, campo BUKRS. Exemplos 1000US01DE01 | |||
| Data de Vencimento do Pagamento PaymentDueDate | A data limite para pagamento da fatura para evitar atrasos. | ||
| Descrição A Data de Vencimento do Pagamento é a data calculada em que o pagamento ao fornecedor deve ser feito, baseada na data da fatura e nos termos acordados. Serve como um prazo crítico no processo. Este atributo é essencial para o KPI de 'Taxa de Pagamento Pontual' e para o Dashboard de 'Desempenho de Pagamento de Fornecedores'. Ao comparar a data real com o vencimento, a empresa mede sua capacidade de cumprir obrigações, o que impacta o relacionamento com fornecedores e a reputação financeira. Por que é importante É o principal parâmetro para medir a performance de pagamentos em dia, o que é crucial para manter boas relações com fornecedores e evitar multas. Onde obter Esta data costuma estar disponível diretamente no item de linha do fornecedor na tabela BSEG, campo ZFBDT (Data base para cálculo de vencimento). O vencimento líquido é calculado a partir desta data base e dos termos de pagamento. Exemplos 2023-05-302023-06-152023-07-01 | |||
| Nome do Utilizador UserName | O ID de usuário SAP da pessoa ou sistema que realizou a atividade. | ||
| Descrição Este atributo identifica o usuário que executou uma transação ou criou um documento. Pode ser o ID de uma pessoa ou um ID de sistema para jobs automatizados. Analisar por usuário ajuda a entender a distribuição de carga, identificar necessidades de treinamento e detectar comportamentos incomuns. Por exemplo, pode destacar quais usuários tratam exceções com frequência ou quais faturas são processadas automaticamente (ex: usuário 'BATCHUSER'), o que é essencial para o KPI de 'Taxa de Automação de Faturas'. Por que é importante Atribui as atividades do processo a usuários ou contas de sistema específicos, permitindo análises de carga de trabalho, comparação de performance e detecção de automação. Onde obter Extraído de campos como BKPF-USNAM (Inserido por) ou CDHDR-USERNAME (Alterado por). Exemplos SMITHJMUELLERTWF-BATCH | |||
| Número do fornecedor VendorNumber | O identificador exclusivo do fornecedor que enviou a fatura. | ||
| Descrição O Número do Fornecedor identifica o parceiro associado à fatura e vincula a transação aos dados mestres do fornecedor. Este atributo é crítico para análises focadas no fornecedor, como avaliar o 'Desempenho de Pagamento' ou identificar fornecedores que enviam faturas problemáticas com frequência, gerando exceções ou bloqueios. Ajuda na gestão do relacionamento e na avaliação da confiabilidade dos parceiros. Por que é importante Permite analisar a performance por fornecedor, ajudando a identificar padrões, gerir parcerias e avaliar problemas relacionados a fornecedores específicos. Onde obter Costuma ser encontrado na tabela de segmento de documento contábil BSEG, campo LIFNR. Exemplos 100345700012V9832 | |||
| Pedido de Compra PurchasingDocument | O número do pedido de compra ao qual a fatura está relacionada. | ||
| Descrição O número do Documento de Compras vincula a fatura do fornecedor ao pedido de compra (PO) original. Este elo é fundamental para o processo de 'three-way match', que verifica a fatura contra o PO e o recebimento de mercadorias. Analisar por este atributo ajuda a entender problemas entre faturas com e sem pedido. É essencial para investigar discrepâncias na conferência e entender a eficiência da etapa de suprimentos do processo. Por que é importante Vincula a fatura ao processo de compras, o que é essencial para analisar divergências de conferência e conformidade com o pedido de compra (PO). Onde obter Esta informação costuma ser encontrada na tabela de segmento de documento BSEG, campo EBELN (Número do Documento de Compras). Exemplos 450000123445000056784500009012 | |||
| Razão de Bloqueio de Pagamento PaymentBlockReason | Um código que indica o motivo pelo qual uma fatura está bloqueada para pagamento. | ||
| Descrição Quando uma fatura é bloqueada para pagamento, este atributo fornece o motivo específico, como 'Discrepância de Quantidade' ou 'Diferença de Preço'. Esses motivos são configurados no SAP para padronizar o tratamento de exceções. Este atributo é fundamental para o Dashboard de 'Ocorrência e Duração de Bloqueios de Pagamento'. Analisar a frequência de diferentes motivos ajuda a identificar as causas raiz dos atrasos, como problemas com fornecedores específicos, materiais ou processos internos, permitindo ações corretivas direcionadas. Por que é importante Fornece a causa raiz específica para bloqueios de pagamento, permitindo análises direcionadas para reduzir atrasos e melhorar o processamento correto de primeira. Onde obter Localizado no item de linha do fornecedor da tabela BSEG, campo ZLSPR (Chave de Bloqueio de Pagamento). Exemplos RIA | |||
| Tipo de Documento DocumentType | Um código que classifica diferentes tipos de documentos contábeis, como faturas de fornecedores ou notas de crédito. | ||
| Descrição O Tipo de Documento é usado no SAP para distinguir diferentes transações de negócio. Por exemplo, 'KR' costuma representar uma fatura padrão de fornecedor, enquanto 'KG' pode ser uma nota de crédito. Analisar por tipo de documento permite segmentar o processo para entender como diferentes transações são tratadas. O processo de uma nota de crédito pode ser bem diferente de uma fatura padrão. Essa segmentação oferece Insights mais precisos e relevantes sobre o processo. Por que é importante Ajuda a diferenciar diversos tipos de transações financeiras, como faturas padrão e notas de crédito, que costumam seguir caminhos de processo distintos. Onde obter Encontrado na tabela de cabeçalho de documento BKPF, campo BLART. Exemplos KRREKG | |||
| Valor da Fatura AmountInCompanyCodeCurrency | O valor bruto total da fatura na moeda local da empresa. | ||
| Descrição Este atributo representa o valor total da fatura. É uma métrica essencial para entender o impacto financeiro e a escala da operação de processamento. Analisar os valores das faturas ajuda a priorizar documentos de alto valor para um processamento mais rápido, identificar tendências de gastos e correlacionar problemas de processo com o valor financeiro. Por exemplo, permite investigar se faturas de alto valor têm mais chance de serem bloqueadas ou demoram mais para serem aprovadas. Por que é importante Fornece contexto financeiro ao processo, permitindo análises baseadas em valor monetário, como identificar se faturas de alto valor são processadas de forma diferente. Onde obter Este valor costuma ser derivado da soma dos itens de linha relevantes na tabela BSEG, campo WRBTR (Valor em moeda local). Exemplos 1500.75125000.00850.20 | |||
| Condições de Pagamento PaymentTerms | O código que define as condições de pagamento acordadas com o fornecedor, como prazos e períodos de desconto. | ||
| Descrição Os Termos de Pagamento definem as regras para pagar uma fatura, incluindo eventuais descontos por pagamento antecipado. Por exemplo, 'Z030' pode significar 'Pagável em 30 dias líquidos'. Este atributo é essencial para o planejamento financeiro e a otimização do capital de giro. No Process Mining, ele é usado para calcular a 'Data de Vencimento do Pagamento' e determinar a elegibilidade para descontos por antecipação, apoiando diretamente o KPI de 'Taxa de Captura de Descontos por Antecipação'. Por que é importante Define as regras para datas de vencimento e descontos, impactando diretamente os KPIs de pontualidade e a gestão do capital de giro. Onde obter Encontrado no item de linha do fornecedor na tabela BSEG, campo ZTERM (Chave de Condição de Pagamento). Exemplos 0001Z030NT60 | |||
| Contagem de Ciclos de Aprovação ApprovalCycleCount | Uma contagem de quantas vezes uma fatura foi enviada para aprovação. | ||
| Descrição Esta métrica conta quantas vezes a atividade 'Fatura Enviada para Aprovação' ocorre para uma única fatura. Um valor maior que um indica que a fatura foi rejeitada ou enviada de volta pelo menos uma vez, exigindo um novo ciclo. Este atributo apoia diretamente o KPI de 'Taxa de Aprovação de Primeira'. Ao analisar faturas com muitos ciclos de aprovação, as empresas podem identificar os motivos das falhas (como informações insuficientes ou codificação incorreta) e agir para melhorar o processo. Por que é importante Quantifica o retrabalho no subprocesso de aprovação, ajudando a medir a taxa de acerto de primeira e a identificar motivos de rejeição nas aprovações. Onde obter Calculado contando as ocorrências da atividade 'Fatura Enviada para Aprovação' para cada número de fatura exclusivo. Exemplos 123 | |||
| Data da Fatura InvoiceDate | A data em que o fornecedor emitiu o documento da fatura. | ||
| Descrição A Data da Fatura, também conhecida como data do documento, é a data fornecida pelo fornecedor na fatura. É o ponto de partida para calcular o vencimento com base nos termos de pagamento acordados. Na análise, esta data é fundamental para cálculos financeiros, como determinar o envelhecimento da fatura (aging) e a elegibilidade para descontos por antecipação. É um dado essencial para o KPI de 'Taxa de Captura de Descontos por Antecipação'. Por que é importante Serve como base para calcular termos de pagamento e datas de vencimento, sendo essencial para gerir o capital de giro e capturar descontos. Onde obter Encontrado na tabela de cabeçalho de documento BKPF, campo BLDAT (Data do Documento). Exemplos 2023-04-122023-05-152023-06-20 | |||
| É Automatizado IsAutomated | Um sinalizador que indica se uma atividade foi realizada por um usuário de sistema automatizado. | ||
| Descrição Este atributo booleano é verdadeiro se o usuário associado a uma atividade for uma conta de sistema ou lote (batch), como 'WF-BATCH' ou 'SAP_SYSTEM'. Ajuda a distinguir etapas manuais de automatizadas. Este atributo é essencial para o KPI de 'Taxa de Automação de Faturas'. Ao analisar quais partes do processo são automáticas, as empresas podem medir o sucesso de suas iniciativas de automação e identificar novas oportunidades para reduzir o esforço manual e ganhar eficiência. Por que é importante Distingue entre atividades manuais e automáticas, o que é fundamental para medir taxas de automação e identificar oportunidades de melhoria. Onde obter Derivado do atributo UserName. Um mapeamento ou regra é criado para classificar IDs de usuários específicos como 'automatizados'. Exemplos verdadeirofalse | |||
| É pago no prazo IsPaidOnTime | Um sinalizador que é verdadeiro se a fatura foi paga dentro ou antes do prazo de vencimento. | ||
| Descrição Este atributo booleano é o resultado da comparação entre a data real de pagamento (timestamp da atividade 'Pagamento Executado') e a 'Data de Vencimento'. Fornece um resultado binário claro sobre o status de cada fatura. Este é o cálculo central para o KPI de 'Taxa de Pagamento Pontual'. Ele permite filtrar e analisar facilmente as características dos pagamentos atrasados, como fornecedores comuns, empresas ou valores de fatura associados aos atrasos. Por que é importante Mede diretamente a adesão às condições de pagamento, que é um KPI crítico para a gestão do relacionamento com fornecedores e operações financeiras. Onde obter Calculado comparando o EventTime da atividade 'Pagamento Executado' com o atributo PaymentDueDate. (Data de Pagamento <= Prazo de Vencimento). Exemplos verdadeirofalse | |||
| É Retrabalho IsRework | Um sinalizador que indica se uma fatura passou por atividades de retrabalho, como uma aprovação rejeitada ou a remoção de um bloqueio de pagamento. | ||
| Descrição Este atributo sinaliza faturas que passaram por um ou mais loops de retrabalho. O retrabalho é identificado por sequências específicas, como 'Fatura Aprovada' após 'Fatura Rejeitada', ou 'Bloqueio de Pagamento Removido' após 'Bloqueio de Pagamento Definido'. Este atributo simplifica o cálculo do KPI de 'Taxa de Retrabalho de Faturas'. Ele permite isolar e investigar facilmente casos com retrabalho para entender as causas raiz da ineficiência e do esforço manual repetido. Por que é importante Identifica fluxos ineficientes onde o trabalho precisa ser repetido, ajudando a quantificar o desperdício e a localizar as causas raiz das exceções no processo. Onde obter Calculado com base na sequência de atividades no event log. Por exemplo, se 'Fatura Rejeitada' ocorrer no rastro de uma fatura, este sinalizador será definido como verdadeiro. Exemplos verdadeirofalse | |||
| ID do sistema de origem SourceSystemId | O identificador do sistema SAP S/4HANA de origem de onde os dados foram extraídos. | ||
| Descrição Este atributo especifica o sistema de origem, como 'S4H_PROD' ou 'ERP_EU'. É importante em ambientes com múltiplas instâncias de ERP ou uma mistura de sistemas legados e modernos. Para análise, permite comparar o desempenho do processo entre sistemas ou regiões. Garante a procedência dos dados e é crucial para a governança e resolução de problemas quando dados de várias fontes são consolidados em uma plataforma central de Process Mining. Por que é importante Fornece contexto sobre a origem dos dados, o que é essencial para a governança de dados e para comparar processos entre sistemas ou unidades diferentes. Onde obter Este valor costuma ser derivado do ID do sistema SAP (sy-sysid) durante a extração de dados ou configurado como um valor estático no pipeline de ETL. Exemplos S4PS4H_PROD_100ECC_EU | |||
| Motivo do Estorno ReversalReason | Um código que indica o motivo pelo qual um documento de fatura foi estornado. | ||
| Descrição Se uma fatura é lançada incorretamente, ela costuma ser estornada. O código de Motivo de Estorno explica por que essa ação foi tomada (ex: 'Data de lançamento incorreta' ou 'Erro de digitação'). Analisar esses motivos ajuda a identificar padrões de erros no lançamento. Esse insight serve para melhorar treinamentos, aprimorar controles do sistema ou tratar problemas recorrentes que geram retrabalho financeiro e sobrecarga administrativa. Por que é importante Explica por que as faturas foram canceladas, fornecendo insights diretos sobre as fontes de erro e retrabalho no processo de lançamento. Onde obter Encontrado no cabeçalho do documento original na tabela BKPF, campo STGRD (Motivo do estorno). Exemplos 010205 | |||
| Nº do Documento de Compensação ClearingDocumentNumber | O número do documento que compensa a fatura, geralmente representando o documento de pagamento. | ||
| Descrição O Número do Documento de Compensação vincula um item de fatura aberto à transação que o compensa, que quase sempre é o documento de pagamento. Isso confirma que a fatura foi paga. Este atributo é o elo definitivo entre uma fatura e seu pagamento. É usado para identificar a atividade 'Pagamento Executado' e seu respectivo timestamp, sendo essencial para calcular o tempo de ciclo de ponta a ponta e a taxa de pagamento pontual. Por que é importante Confirma que uma fatura foi paga e a vincula à transação de pagamento específica, o que é fundamental para a análise de tempo de ciclo e performance de pagamento. Onde obter Encontrado na tabela de segmentos de documento BSEG, campo AUGBL (Número do Documento de Compensação). Exemplos 150000000115000000231500000088 | |||
| Tempo de Processamento de Fatura InvoiceProcessingTime | O tempo total decorrido da primeira à última atividade de uma fatura. | ||
| Descrição Esta métrica calcula a duração total para processar uma única fatura, geralmente da criação ou recebimento até o pagamento final. Fornece um resumo do tempo de ciclo de ponta a ponta por caso. Este atributo calculado é a base para o KPI de 'Tempo Médio de Ciclo da Fatura' e para o Dashboard de 'Tempo de Ciclo de Ponta a Ponta'. Ele permite identificar rapidamente os casos mais demorados e analisar fatores que contribuem para o prolongamento dos tempos de processamento. Por que é importante Mede a eficiência de ponta a ponta para cada fatura, destacando casos com durações excepcionalmente longas que exigem investigação. Onde obter Calculado pela diferença entre o timestamp do último evento e do primeiro evento para cada número de fatura exclusivo. Exemplos 10 days 4 hours25 dias e 1 hora5 dias e 8 horas | |||
| Timestamp da Extração ExtractionTimestamp | Data e hora em que os dados foram extraídos do sistema de origem. | ||
| Descrição Este atributo registra o timestamp da extração dos dados. Reflete o quão atualizados estão os dados analisados na ferramenta de Process Mining. Na análise, é usado para entender a recência dos Insights gerados. É crítico para Dashboards de monitoramento operacional, garantindo que as decisões baseiem-se em informações atuais e permitindo gerir ciclos de atualização de dados de forma eficaz. Por que é importante Indica o quão recentes são os dados, garantindo que as análises e relatórios se baseiem nas informações mais atuais disponíveis. Onde obter Este não é um campo SAP. Ele é gerado e adicionado pela ferramenta de extração de dados ou processo de ETL no momento da coleta de dados. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
Atividades do Processamento de Faturas - Purchase to Pay
| Atividade | Descrição | ||
|---|---|---|---|
| Documento de Fatura Criado | Este é o primeiro evento, marcando a criação de um documento de fatura no SAP. Pode ser capturado quando um usuário salva um novo documento, que pode estar em estado de parking ou pré-lançamento. | ||
| Por que é importante Esta atividade marca o início do ciclo de processamento da fatura. Analisar o tempo deste evento em relação aos outros é crucial para medir o lead time total de processamento. Onde obter Este evento é capturado a partir da data e hora de criação (CPUDT, CPUTM) na tabela de cabeçalho do documento, geralmente BKPF ou RBKP para faturas de logística. O código da transação (BKPF-TCODE), como FB60, MIRO ou MIR7, indica o método de criação. Captura Use o timestamp de criação dos campos BKPF-CPUDT e BKPF-CPUTM para o documento de fatura. Tipo de evento explicit | |||
| Fatura Aprovada | Esta atividade significa que a fatura foi aprovada pela autoridade designada. É capturada quando o workflow de aprovação termina com sucesso ou um indicador de liberação é definido. | ||
| Por que é importante Este é um marco crítico que desbloqueia a fatura para pagamento. Atrasos nas aprovações são um gargalo comum, e rastrear esta atividade ajuda a identificar aprovadores ou etapas lentas. Onde obter Isso pode ser inferido da etapa final de liberação em um workflow SAP ou rastreando alterações nos campos de status de liberação em tabelas associadas à fatura ou ao seu documento de compra. Captura Inferir a partir de eventos de conclusão de workflow ou mudanças no campo de status de liberação do documento. Tipo de evento inferred | |||
| Fatura Estornada | Uma atividade que representa o estorno de um documento de fatura lançado anteriormente. Este é um evento final para uma fatura incorreta, que geralmente é reinserida de forma correta depois. | ||
| Por que é importante Estornos indicam erros críticos que não foram detectados anteriormente. Acompanhar sua frequência e causas raiz é essencial para a melhoria de processos e redução de imprecisões financeiras. Onde obter Um estorno é identificado quando um documento de anulação é criado. O cabeçalho do documento original (BKPF) conterá o número do documento de estorno (BKPF-STBLG) e vice-versa. A data de lançamento do documento de estorno é considerada o Event Time. Captura Identifique documentos que possuem valor no campo BKPF-STBLG e utilize a data de lançamento do documento de estorno. Tipo de evento explicit | |||
| Fatura Lançada | Este é um evento financeiro fundamental onde a fatura parada ou aprovada é formalmente lançada no Livro Razão. Esta ação reconhece a obrigação com o fornecedor. | ||
| Por que é importante O lançamento é um marco importante que separa a entrada de dados e a aprovação da fase de liquidação financeira. O tempo entre a criação da fatura e o lançamento é uma métrica fundamental da eficiência do processamento interno. Onde obter Este evento é identificado pela Data de Lançamento (BKPF-BUDAT) no cabeçalho do documento. Para documentos que são primeiro parados (parked), a transição para o status de lançado fornece o timestamp do evento. Captura Use a data de lançamento (BKPF-BUDAT) como o timestamp do evento. Tipo de evento explicit | |||
| Pagamento Executado | Esta é a atividade final no processo padrão, onde o pagamento é feito e a fatura é compensada. Isso significa que os fundos foram desembolsados para o fornecedor. | ||
| Por que é importante Isso marca o fim do ciclo de vida da fatura P2P. É essencial para calcular o tempo total de ciclo de ponta a ponta e para medir o desempenho do pagamento pontual em relação ao vencimento. Onde obter Este evento é capturado pelas informações do documento de compensação no item de linha do fornecedor. A Data de Compensação (BSEG-AUGDT) e o Documento de Compensação (BSEG-AUGBL) indicam que o pagamento foi realizado. Captura Use a data de compensação (BSEG-AUGDT) do item de linha do fornecedor compensado. Tipo de evento explicit | |||
| Bloqueio de Pagamento Ativado | Uma atividade em que um bloqueio é colocado intencionalmente em uma fatura para impedir seu pagamento. Geralmente ocorre por divergências de preço ou quantidade, ou por uma nota de crédito pendente. | ||
| Por que é importante Bloqueios de pagamento são a principal causa de atrasos e disputas com fornecedores. Analisar a frequência, duração e motivos dos bloqueios é fundamental para melhorar as taxas de pagamento em dia. Onde obter Este evento é capturado rastreando mudanças no campo de Chave de Bloqueio de Pagamento (BSEG-ZLSPR) no item da fatura. Os logs de alteração em CDHDR e CDPOS fornecem o timestamp e o usuário que definiu o bloqueio. Captura Identifique quando o campo BSEG-ZLSPR é preenchido via documentos de modificação (CDHDR/CDPOS). Tipo de evento explicit | |||
| Bloqueio de Pagamento Removido | Representa a resolução de um problema, onde um bloqueio de pagamento definido anteriormente é removido, tornando a fatura elegível para pagamento novamente. | ||
| Por que é importante O tempo entre a definição e a remoção de um bloqueio representa o tempo de resolução de uma exceção. Encurtar essa duração é fundamental para melhorar a eficiência e a relação com fornecedores. Onde obter Este evento é capturado quando o campo de Chave de Bloqueio de Pagamento (BSEG-ZLSPR) é limpo. Esta alteração é registrada nas tabelas CDHDR e CDPOS, fornecendo o timestamp da remoção. Captura Identifique quando o campo BSEG-ZLSPR é limpo via documentos de modificação (CDHDR/CDPOS). Tipo de evento explicit | |||
| Dados da Fatura Atualizados | Esta atividade reflete uma alteração feita no documento após a criação inicial. É comum em ciclos de retrabalho após uma rejeição ou para corrigir erros. | ||
| Por que é importante Atualizações frequentes sinalizam retrabalho e possíveis problemas de qualidade de dados na entrada. Rastrear essas mudanças ajuda a quantificar o esforço gasto em correções e a identificar erros comuns. Onde obter As alterações em campos-chave são registradas nas tabelas de documentos de modificação do SAP, CDHDR (cabeçalho) e CDPOS (item). Os eventos podem ser gerados filtrando as alterações no objeto de fatura relevante. Captura Extraia eventos de alteração das tabelas CDHDR e CDPOS para o objeto de fatura. Tipo de evento explicit | |||
| Fatura Enviada para Aprovação | Esta atividade marca o início de um workflow formal de aprovação. Geralmente é inferida quando o status da fatura muda para 'pendente de aprovação' ou um item de workflow é gerado. | ||
| Por que é importante Este é o ponto de partida para medir o tempo do ciclo de aprovação. Entender quando as aprovações começam é essencial para identificar gargalos no próprio workflow de aprovação. Onde obter Isso costuma ser inferido do início de um SAP Business Workflow (tabela SWW_WI2OBJ) vinculado ao objeto da fatura (ex: BUS2081) ou uma alteração em um campo de status customizado no cabeçalho. Captura Inferir a partir da criação de um item de workflow relacionado ao documento de fatura. Tipo de evento inferred | |||
| Fatura Estacionada | Representa uma fatura inserida no sistema, mas ainda não lançada no livro razão. O 'parking' é usado para salvar faturas incompletas ou para revisão posterior antes do lançamento. | ||
| Por que é importante O "parking" (estacionamento de fatura) indica uma pausa deliberada no processo. Acompanhar a duração e a frequência das faturas paradas ajuda a identificar os motivos dos atrasos antes do início do ciclo formal de lançamento e aprovação. Onde obter Isso pode ser identificado por documentos criados via transações de parking (ex: MIR7, FV60) ou verificando campos de status específicos na tabela BKPF ou tabelas dedicadas a documentos parados, como VBKPF. Captura Identifique documentos criados via transações de pré-lançamento ou verifique o status de documento pré-lançado. Tipo de evento explicit | |||
| Fatura Rejeitada | Representa a rejeição de uma fatura durante o processo de aprovação. Este evento gera retrabalho, exigindo correção e reenvio. | ||
| Por que é importante Rejeições de faturas são um indicador chave de ineficiência e problemas de qualidade de dados. Analisar a frequência e os motivos das rejeições ajuda a identificar chances de melhoria e treinamento. Onde obter Isso é inferido de atualizações de status específicas em um workflow SAP, como um status de 'rejeitado', ou de eventos que cancelam o workflow de aprovação atual, enviando-o de volta ao processador. Captura Inferir a partir de mudanças de status do workflow que indicam rejeição. Tipo de evento inferred | |||
| Pagamento Atrasado Executado | Este é um evento calculado que ocorre quando o pagamento de uma fatura é executado após a data de vencimento calculada. É derivado da comparação de dois campos de data. | ||
| Por que é importante Esta atividade apoia diretamente os KPIs de pagamento pontual e ajuda a identificar fornecedores ou unidades com pagamentos atrasados frequentes, o que pode prejudicar parcerias e gerar multas. Onde obter Isso é calculado comparando a Data de Compensação (BSEG-AUGDT) com a Data de Vencimento Líquido. O vencimento é calculado a partir da Data Base (BSEG-ZFBDT) e dos termos de pagamento (BSEG-ZTERM). Captura Derivado da comparação BSEG-AUGDT > (BSEG-ZFBDT + dias da condição de pagamento). Tipo de evento calculated | |||
| Proposta de Pagamento Criada | A fatura é selecionada e incluída em uma proposta de pagamento como parte de uma execução de pagamento. Este é o primeiro passo no processo automatizado. | ||
| Por que é importante Esta atividade indica a intenção de pagar. Atrasos entre esta etapa e a execução final do pagamento podem revelar problemas no processo de execução, aprovações ou comunicação bancária. Onde obter Isso pode ser encontrado nas tabelas de execução de pagamento, especificamente na REGUP, que contém os itens da proposta. A data de execução na tabela REGUH correspondente fornece o timestamp. Captura Identifique quando uma fatura aparece na tabela REGUP em uma execução de proposta de pagamento. Tipo de evento explicit | |||
Guias de Extração
Etapas
- Pré-requisitos e Autorização: Certifique-se de que o usuário tenha as autorizações necessárias no SAP S/4HANA para acessar as views CDS requeridas. As principais são
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. Também são necessárias permissões para executar consultas via OData ou conexão SQL direta. - Identificar o Método de Conexão: Defina como você se conectará ao SAP S/4HANA para rodar a query SQL. Os métodos comuns incluem SAP Data Services, SAP Data Intelligence, ferramentas de ETL de terceiros ou conexão SQL direta ao banco SAP HANA, se permitido pelas políticas de segurança.
- Definir Parâmetros de Extração: Antes de rodar a query, defina os parâmetros principais. Especifique o intervalo de datas (ex:
CreationDateentre 'AAAA-MM-DD' e 'AAAA-MM-DD') e as empresas (CompanyCode) que deseja incluir para limitar o escopo. - Customizar a Query SQL: Copie a query SQL fornecida no seu cliente SQL ou ferramenta de extração. Revise os marcadores como
'{StartDate}','{EndDate}'e('{CompanyCode1}', '{CompanyCode2}'), substituindo-os pelos valores reais. Ajuste os nomes de campos de status de workflow se necessário para sua configuração SAP. - Executar a Consulta: Rode a query SQL completa no banco de dados ou camada de serviço. Por ser abrangente, a execução pode demorar conforme o volume de dados. Monitore se ocorrem erros ou timeouts.
- Revisar Resultados Iniciais: Após a conclusão, verifique se as colunas
InvoiceNumber,ActivityNameeEventTimeestão preenchidas. Confirme se há uma variedade de atividades na colunaActivityName, e não apenas a criação do documento. - Tratar a Transformação de Dados: A query já gera um formato de event log limpo. No entanto, garanta que a coluna
EventTimeesteja em um formato de timestamp consistente (ex:AAAA-MM-DDTHH:MM:SS). A query fornecida já combina campos de data e hora quando necessário. - Exportar os Dados: Exporte os resultados para um arquivo CSV. Esse formato é universalmente compatível com ferramentas de Process Mining, como o ProcessMind.
- Preparar para o Upload: Antes de carregar, confirme se o CSV usa codificação UTF-8 para evitar problemas de caracteres. Verifique se os cabeçalhos das colunas batem com os atributos exigidos:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Carregar no ProcessMind: Faça o upload do arquivo preparado no seu projeto de Process Mining. Mapeie as colunas do arquivo para os campos de ID de caso, nome da atividade e timestamp na configuração do modelo de dados.
Configuração
- CDS Views utilizadas: As principais fontes de dados são as views CDS padrão do SAP. As principais são a
I_InvoiceDocumentpara dados de cabeçalho, aI_OperationalAcctgDocItempara detalhes de lançamento financeiro e compensação, e as viewsI_ChangeDocumenteI_ChangeDocumentItempara rastrear mudanças históricas nos atributos da fatura, como bloqueios de pagamento e status de workflow. - Filtragem por intervalo de datas: É fundamental filtrar os dados por um período específico para garantir a performance. A consulta fornecida usa um marcador para a
CreationDatena viewI_InvoiceDocument. Recomendamos começar com um período de 3 a 6 meses de dados. - Filtro de Empresa (Company Code): Para que a extração seja relevante e gerenciável, filtre sempre por uma ou mais empresas (
CompanyCode). A consulta inclui o campoWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para essa finalidade. - Filtro de tipo de documento: Você pode refinar ainda mais a extração filtrando por
InvoiceDocumentType. Por exemplo, você pode incluir faturas de fornecedor padrão (RE), mas excluir notas de crédito. Isso pode ser adicionado à cláusulaWHEREda CTE inicial. - Pré-requisitos: O usuário que executa a consulta precisa de autorizações de exibição para documentos financeiros e de compras nas empresas especificadas. O acesso direto ao banco de dados HANA via cliente SQL não é padrão e exige permissões especiais.
- Considerações de performance: A extração de dados das tabelas de documentos de modificação (
I_ChangeDocument,I_ChangeDocumentItem) pode exigir muito do sistema. Aplicar filtros rígidos de data, empresa e classe de objeto (INCOMINGINVOICE) é essencial para evitar tempos de execução longos.
a Consulta de Exemplo sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Etapas
- Pré-requisitos e Autorização: Certifique-se de que o usuário tenha as autorizações necessárias no SAP S/4HANA para acessar as views CDS requeridas. As principais são
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. Também são necessárias permissões para executar consultas via OData ou conexão SQL direta. - Identificar o Método de Conexão: Defina como você se conectará ao SAP S/4HANA para rodar a query SQL. Os métodos comuns incluem SAP Data Services, SAP Data Intelligence, ferramentas de ETL de terceiros ou conexão SQL direta ao banco SAP HANA, se permitido pelas políticas de segurança.
- Definir Parâmetros de Extração: Antes de rodar a query, defina os parâmetros principais. Especifique o intervalo de datas (ex:
CreationDateentre 'AAAA-MM-DD' e 'AAAA-MM-DD') e as empresas (CompanyCode) que deseja incluir para limitar o escopo. - Customizar a Query SQL: Copie a query SQL fornecida no seu cliente SQL ou ferramenta de extração. Revise os marcadores como
'{StartDate}','{EndDate}'e('{CompanyCode1}', '{CompanyCode2}'), substituindo-os pelos valores reais. Ajuste os nomes de campos de status de workflow se necessário para sua configuração SAP. - Executar a Consulta: Rode a query SQL completa no banco de dados ou camada de serviço. Por ser abrangente, a execução pode demorar conforme o volume de dados. Monitore se ocorrem erros ou timeouts.
- Revisar Resultados Iniciais: Após a conclusão, verifique se as colunas
InvoiceNumber,ActivityNameeEventTimeestão preenchidas. Confirme se há uma variedade de atividades na colunaActivityName, e não apenas a criação do documento. - Tratar a Transformação de Dados: A query já gera um formato de event log limpo. No entanto, garanta que a coluna
EventTimeesteja em um formato de timestamp consistente (ex:AAAA-MM-DDTHH:MM:SS). A query fornecida já combina campos de data e hora quando necessário. - Exportar os Dados: Exporte os resultados para um arquivo CSV. Esse formato é universalmente compatível com ferramentas de Process Mining, como o ProcessMind.
- Preparar para o Upload: Antes de carregar, confirme se o CSV usa codificação UTF-8 para evitar problemas de caracteres. Verifique se os cabeçalhos das colunas batem com os atributos exigidos:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Carregar no ProcessMind: Faça o upload do arquivo preparado no seu projeto de Process Mining. Mapeie as colunas do arquivo para os campos de ID de caso, nome da atividade e timestamp na configuração do modelo de dados.
Configuração
- CDS Views utilizadas: As principais fontes de dados são as views CDS padrão do SAP. As principais são a
I_InvoiceDocumentpara dados de cabeçalho, aI_OperationalAcctgDocItempara detalhes de lançamento financeiro e compensação, e as viewsI_ChangeDocumenteI_ChangeDocumentItempara rastrear mudanças históricas nos atributos da fatura, como bloqueios de pagamento e status de workflow. - Filtragem por intervalo de datas: É fundamental filtrar os dados por um período específico para garantir a performance. A consulta fornecida usa um marcador para a
CreationDatena viewI_InvoiceDocument. Recomendamos começar com um período de 3 a 6 meses de dados. - Filtro de Empresa (Company Code): Para que a extração seja relevante e gerenciável, filtre sempre por uma ou mais empresas (
CompanyCode). A consulta inclui o campoWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para essa finalidade. - Filtro de tipo de documento: Você pode refinar ainda mais a extração filtrando por
InvoiceDocumentType. Por exemplo, você pode incluir faturas de fornecedor padrão (RE), mas excluir notas de crédito. Isso pode ser adicionado à cláusulaWHEREda CTE inicial. - Pré-requisitos: O usuário que executa a consulta precisa de autorizações de exibição para documentos financeiros e de compras nas empresas especificadas. O acesso direto ao banco de dados HANA via cliente SQL não é padrão e exige permissões especiais.
- Considerações de performance: A extração de dados das tabelas de documentos de modificação (
I_ChangeDocument,I_ChangeDocumentItem) pode exigir muito do sistema. Aplicar filtros rígidos de data, empresa e classe de objeto (INCOMINGINVOICE) é essencial para evitar tempos de execução longos.
a Consulta de Exemplo sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Etapas
- Acessar o Editor ABAP: Faça login no seu sistema SAP S/4HANA. Abra a transação
SE38(Editor ABAP). - Criar o Programa: Digite um nome para o seu novo programa no campo Programa (ex:
Z_PM_INVOICE_EXTRACT) e clique no botão 'Criar'. Dê um título, defina o Tipo como 'Programa Executável' e salve-o em um pacote apropriado. - Definir Estrutura do Programa e Tela de Seleção: No editor, defina as estruturas de dados para o event log final. Em seguida, crie uma tela de seleção para permitir que os usuários insiram parâmetros como intervalo de datas para entrada de faturas, empresas e tipos de documentos. Isso torna o programa flexível e reutilizável.
- Implementar a Lógica de Seleção de Dados: Escreva as instruções ABAP SQL para selecionar os dados das diversas tabelas SAP. O programa consultará sequencialmente cada uma das 13 atividades necessárias.
- Extrair Dados de Cabeçalho e Item: Para eventos fundamentais como 'Fatura Criada' e 'Fatura Lançada', selecione dados das tabelas primárias como
RBKP(Cabeçalho de Fatura de Logística) eBKPF(Cabeçalho de Documento Contábil). - Extrair Dados de Documentos de Modificação: Para atividades como 'Bloqueio de Pagamento Definido' e 'Bloqueio de Pagamento Removido', consulte as tabelas de modificação
CDHDReCDPOS. Você precisará identificar alterações em campos específicos, como oZLSPRna tabelaBSEG. - Extrair Dados de Pagamento: Para capturar atividades de pagamento, consulte tabelas como a
REGUPpara propostas de pagamento eBSAKpara pagamentos executados. Diferencie o 'Pagamento Atrasado Executado' comparando a data de compensação (AUGDT) com a data de vencimento líquido (ZFBDT). - Extrair Dados de Workflow: Para atividades de aprovação, consulte as tabelas de SAP Business Workflow (como a
SWW_WI2OBJ) para vincular itens de workflow aos objetos de fatura. Esta parte depende muito da sua configuração específica de workflow e pode exigir adaptações. - Unificar Dados no Formato de Event Log: Para cada atividade selecionada, formate os dados em uma estrutura de tabela interna comum. Cada linha representará um único evento e deve conter o identificador do caso (
InvoiceNumber),ActivityNameeEventTime, além de outros atributos recomendados. - Gerar o Arquivo de Saída: Use os comandos ABAP
OPEN DATASET,TRANSFEReCLOSE DATASETpara gravar o conteúdo da tabela interna em um arquivo simples no servidor de aplicação SAP. O formato CSV é o mais recomendado. - Agendar e Executar: Execute o programa em primeiro plano para testes (tecla
F8). Para execuções em produção, agende-o como um job de background via transaçãoSM36em horários de pouco movimento para não impactar a performance do sistema. - Recuperar e Carregar: Use a transação
AL11para navegar até o diretório do servidor onde o arquivo foi salvo. Baixe o arquivo para seu sistema local. Verifique se ele está codificado em UTF-8 antes de carregá-lo na ferramenta de Process Mining.
Configuração
- Intervalo de datas: Defina um período específico para a extração com base na data de entrada da fatura (
RBKP-CPUDT) ou na data de lançamento (BKPF-BUDAT). Para a análise inicial, recomendamos um período de 3 a 6 meses para garantir um volume de dados gerenciável. - Empresa (BUKRS): É fundamental filtrar por uma ou mais empresas. Extrair dados de todas as empresas de uma grande organização pode causar tempos de execução muito longos e gerar arquivos imensos.
- Tipo de documento (BLART): Filtre os tipos de documentos relevantes para isolar as faturas de fornecedores. Os tipos mais comuns incluem 'RE' (Fatura Bruta) e 'KR' (Fatura de Fornecedor). Isso ajuda a excluir documentos irrelevantes da análise.
- Conta do fornecedor (LIFNR): O programa permite incluir um filtro opcional para números específicos de fornecedores, o que é útil para análises direcionadas ou testes.
- Configuração do arquivo de saída: O programa deve ter parâmetros para definir o caminho do arquivo de saída no servidor de aplicação e o delimitador de campos (por exemplo, vírgula ou ponto e vírgula).
- Pré-requisitos: O usuário ou a conta de sistema que executa este programa precisa de acesso de desenvolvedor para criar e rodar programas ABAP (via
SE38) e autorizações de leitura abrangentes para as tabelas de FI, MM e Basis, incluindoBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSe tabelas de workflow.
a Consulta de Exemplo abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path.