Seu Template de dados para compras ao pagamento: processamento de faturas
Seu Template de dados para compras ao pagamento: processamento de faturas
- Atributos recomendados para coletar
- Principais atividades para acompanhar
- Orientações de extração para SAP S/4HANA
Atributos de compras ao pagamento: processamento de faturas
| Nome | Descrição | ||
|---|---|---|---|
| Número da fatura InvoiceNumber | Identificador exclusivo do documento de fatura do fornecedor, usado como identificador principal do caso no 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, estacionamento, aprovação e pagamento, em uma única instância do processo. Em Process Mining, este atributo é fundamental para acompanhar a jornada completa de cada fatura. Ele permite reconstruir todo o fluxo do processo, do recebimento ao pagamento final, e analisar tempos de ciclo, gargalos e variações do processo para cada fatura. Por que isso importa É a chave essencial para conectar todos os eventos relacionados e acompanhar todo o ciclo de vida de uma fatura no sistema. Onde encontrar É o número do documento contábil, encontrado na tabela BKPF, campo BELNR. Exemplos 190000000119000000451900000132 | |||
| Horário do evento EventTime | A data e a hora exatas em que a atividade ocorreu. | ||
| Descrição O horário do evento é o timestamp que registra exatamente quando uma atividade específica ocorreu. Esses dados são essenciais para calcular durações, tempos de ciclo e tempos de espera entre diferentes etapas do processo. Na análise de Process Mining, timestamps precisos são usados para medir KPIs de performance, como 'Tempo médio de ciclo da fatura' e 'Tempo de ciclo da aprovação da fatura'. Ao analisar o tempo decorrido entre as atividades, as organizações podem localizar gargalos que atrasam as faturas e identificar oportunidades para acelerar o processo. Por que isso importa Este timestamp é a base de todas as análises relacionadas ao tempo, incluindo o monitoramento da performance, a identificação de gargalos e o acompanhamento de SLAs. Onde encontrar Geralmente, os dados vêm das tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item), usando os campos UDATE e UTIME. Para alguns eventos, podem 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 | |||
| Nome da atividade ActivityName | Nome da atividade de negócio ou do evento ocorrido em um momento específico no processamento de uma fatura. | ||
| Descrição O nome da atividade descreve uma etapa específica ou uma mudança de status no ciclo de vida do processamento da fatura. Alguns exemplos são 'Documento de fatura criado', 'Fatura enviada para aprovação', 'Bloqueio de pagamento definido' e 'Pagamento executado'. Este atributo é essencial para criar o mapa do processo, que representa visualmente o fluxo das atividades. Analisar a sequência, a frequência e a duração entre essas atividades ajuda a identificar gargalos, ciclos de retrabalho e variações do processo fora de conformidade. Ele é a base de qualquer análise de Process Mining. Por que isso importa Define as etapas do processo, permitindo visualizar mapas de processo e analisar fluxos e variações. Onde encontrar Derivado de uma combinação de códigos de transação do SAP (SY-TCODE), status de objetos de documentos de alteração (CDHDR/CDPOS) e valores de campos específicos que indicam mudanças de status. Exemplos Fatura estacionadaFatura aprovadaPagamento executado | |||
| Data de vencimento do pagamento PaymentDueDate | Data limite para pagar a fatura sem que ela fique em atraso. | ||
| Descrição A data de vencimento do pagamento é a data calculada para o pagamento ao fornecedor, com base na data da fatura e nas condições de pagamento acordadas. Ela funciona como um prazo essencial no processo. Este atributo é essencial para o KPI 'Taxa de pagamentos em dia' e o Dashboard 'Performance de pagamento dos fornecedores'. Ao comparar a data real do pagamento com a data de vencimento, a empresa pode medir sua capacidade de cumprir as obrigações de pagamento, o que afeta o relacionamento com fornecedores e sua reputação financeira. Por que isso importa É a principal referência para medir a performance dos pagamentos em dia, essencial para manter um bom relacionamento com fornecedores e evitar multas por atraso. Onde encontrar Esta data costuma estar disponível diretamente no item de linha do fornecedor na tabela BSEG, campo ZFBDT (data-base para cálculo do vencimento). A data líquida de vencimento é calculada com base nessa data e nas condições de pagamento. Exemplos 2023-05-302023-06-152023-07-01 | |||
| Empresa CompanyCode | Unidade organizacional que representa uma empresa legalmente independente para a qual são elaboradas demonstrações financeiras. | ||
| Descrição A empresa é 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. Em Process Mining, filtrar ou comparar por empresa é essencial para analisar a performance do processo entre diferentes unidades de negócio, entidades legais ou países. Isso ajuda a identificar diferenças regionais de eficiência, conformidade e níveis de automação, apoiando iniciativas de melhoria direcionadas. Por que isso importa Permite segmentar e comparar a performance do processamento de faturas entre diferentes entidades legais ou regiões da organização. Onde encontrar Este é um campo padrão da tabela de cabeçalho do documento BKPF, campo BUKRS. Exemplos 1000US01DE01 | |||
| Motivo do bloqueio de pagamento PaymentBlockReason | Código que indica por que uma fatura está bloqueada para pagamento. | ||
| Descrição Quando uma fatura é bloqueada para pagamento, este atributo informa o motivo específico do bloqueio, como 'Divergência de quantidade' ou 'Divergência de preço'. Esses motivos são configurados no SAP para padronizar o tratamento de exceções. Este atributo é essencial para o Dashboard 'Ocorrência e duração de bloqueios de pagamento'. Analisar a frequência dos diferentes motivos de bloqueio ajuda a identificar as causas raiz dos atrasos nos pagamentos, como problemas com fornecedores, materiais ou processos internos específicos, e permite definir ações corretivas direcionadas. Por que isso importa Informa a causa raiz específica dos bloqueios de pagamento, permitindo uma análise direcionada para reduzir atrasos e melhorar o processamento correto desde a primeira vez. Onde encontrar Localizado no item de linha do fornecedor da tabela BSEG, campo ZLSPR (chave de bloqueio de pagamento). Exemplos RIA | |||
| Nome de usuário UserName | ID do usuário SAP da pessoa ou do sistema que realizou a atividade. | ||
| Descrição Este atributo identifica o usuário que executou uma transação específica ou criou um documento. Pode ser o ID de uma pessoa ou o ID de um sistema usado em tarefas automatizadas em lote. A análise por usuário ajuda a entender a distribuição da carga de trabalho, identificar necessidades de treinamento e detectar comportamentos incomuns. Por exemplo, pode mostrar quais usuários lidam com exceções com frequência ou quais faturas são processadas automaticamente (por exemplo, pelo usuário 'BATCHUSER'), um dado essencial para calcular o KPI 'Taxa de automação de faturas'. Por que isso importa Associa as atividades do processo a usuários ou contas de sistema específicos, permitindo analisar a carga de trabalho, comparar a performance e detectar automações. Onde encontrar Obtido de campos como BKPF-USNAM (inserido por) ou CDHDR-USERNAME (alterado por). Exemplos SMITHJMUELLERTWF-BATCH | |||
| Número do fornecedor VendorNumber | Identificador exclusivo do fornecedor que enviou a fatura. | ||
| Descrição O número do fornecedor identifica o fornecedor ou credor associado à fatura. Ele conecta a transação da fatura aos dados mestres do fornecedor. Este atributo é essencial para análises centradas nos fornecedores, como avaliar a 'Performance de pagamento dos fornecedores' ou identificar fornecedores que enviam com frequência faturas problemáticas, gerando exceções ou bloqueios de pagamento. Ele ajuda a gerenciar o relacionamento com fornecedores e avaliar a confiabilidade deles. Por que isso importa Permite analisar a performance do processo por fornecedor, ajudando a identificar padrões, gerenciar relacionamentos e avaliar problemas relacionados aos fornecedores. Onde encontrar Geralmente, é encontrado na tabela de segmentos de documentos contábeis BSEG, campo LIFNR. Exemplos 100345700012V9832 | |||
| Pedido de compra PurchasingDocument | Número do pedido de compra relacionado à fatura. | ||
| Descrição O número do documento de compras conecta a fatura do fornecedor ao pedido de compra (PO) original. Essa conexão é fundamental para o processo de conciliação em três vias, que verifica a fatura em relação ao pedido de compra e ao recebimento de mercadorias. A análise deste atributo ajuda a entender problemas relacionados a faturas vinculadas ou não a pedidos de compra. É essencial para investigar divergências na conciliação e entender a eficiência da etapa de compras no processo. Por que isso importa Conecta a fatura ao processo de compras, o que é essencial para analisar divergências na conciliação e a conformidade com os pedidos de compra. Onde encontrar Esta informação geralmente é encontrada na tabela de segmentos de documentos BSEG, campo EBELN (número do documento de compras). Exemplos 450000123445000056784500009012 | |||
| Tipo de documento DocumentType | 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' geralmente representa uma fatura padrão de fornecedor, enquanto 'KG' pode indicar uma nota de crédito de fornecedor. A análise por tipo de documento permite segmentar o processo e entender como diferentes tipos de transação são tratados. Por exemplo, o processo de uma nota de crédito pode ser bem diferente do processo de uma fatura padrão. Essa segmentação gera insights mais precisos e relevantes sobre o processo. Por que isso importa Ajuda a diferenciar vários tipos de transações financeiras, como faturas padrão e notas de crédito, que costumam seguir fluxos de processo diferentes. Onde encontrar Encontrado na tabela de cabeçalho do documento BKPF, campo BLART. Exemplos KRREKG | |||
| Valor da fatura AmountInCompanyCodeCurrency | 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 de faturas. Analisar os valores das faturas ajuda a priorizar o processamento mais rápido das faturas de maior valor, identificar tendências de gastos e relacionar problemas do processo ao impacto financeiro. Por exemplo, permite investigar se faturas de alto valor têm mais chances de ser bloqueadas ou levam mais tempo para aprovação. Por que isso importa Fornece contexto financeiro para o processo e permite analisar os valores monetários, por exemplo, para identificar se faturas de alto valor são processadas de forma diferente. Onde encontrar Este valor geralmente é derivado da soma dos itens de linha relevantes na tabela BSEG, campo WRBTR (valor na moeda local). Exemplos 1500.75125000.00850.20 | |||
| Condições de pagamento PaymentTerms | Código que define as condições de pagamento acordadas com o fornecedor, como datas de vencimento e períodos para descontos. | ||
| Descrição As condições de pagamento definem as regras para pagar uma fatura, incluindo eventuais descontos por pagamento antecipado. Por exemplo, 'Z030' pode significar 'pagamento líquido em até 30 dias'. Este atributo é essencial para o planejamento financeiro e a otimização do capital de giro. Em Process Mining, ele é usado para calcular a 'Data de vencimento do pagamento' e determinar a elegibilidade para descontos por pagamento antecipado, contribuindo diretamente para o KPI 'Taxa de aproveitamento de descontos por pagamento antecipado'. Por que isso importa Define as regras para datas de vencimento e descontos, com impacto direto nos KPIs de pagamentos em dia e na gestão do capital de giro. Onde encontrar Encontrado no item de linha do fornecedor na tabela BSEG, campo ZTERM (chave das condições de pagamento). Exemplos 0001Z030NT60 | |||
| Data da fatura InvoiceDate | 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 informada pelo fornecedor na fatura. Ela é usada como ponto de partida para calcular a data de vencimento do pagamento com base nas condições acordadas. Na análise, essa data é fundamental para cálculos financeiros, como determinar o tempo de existência da fatura e a elegibilidade para descontos por pagamento antecipado. É um dado essencial para o KPI 'Taxa de aproveitamento de descontos por pagamento antecipado'. Por que isso importa Serve de base para calcular as condições de pagamento e as datas de vencimento, o que é essencial para gerenciar o capital de giro e aproveitar descontos. Onde encontrar Encontrada na tabela de cabeçalho do documento BKPF, campo BLDAT (data do documento). Exemplos 2023-04-122023-05-152023-06-20 | |||
| É automatizada IsAutomated | Indicador que informa se uma atividade foi realizada por um usuário de sistema automatizado. | ||
| Descrição Este atributo booleano é verdadeiro quando o usuário associado a uma atividade é uma conta de sistema ou de processamento em lote conhecida, como 'WF-BATCH' ou 'SAP_SYSTEM'. Ele ajuda a distinguir as etapas manuais das automatizadas. Este atributo é essencial para calcular o KPI 'Taxa de automação de faturas'. Ao analisar quais partes do processo são automatizadas, as organizações podem medir o resultado de suas iniciativas de automação e identificar outras oportunidades para reduzir o trabalho manual e melhorar a eficiência. Por que isso importa Distingue as atividades manuais das realizadas pelo sistema, algo fundamental para medir as taxas de automação e identificar oportunidades de automatizar ainda mais o processo. Onde encontrar Derivado do atributo UserName. Uma correspondência ou regra é criada para classificar IDs de usuário específicos como 'automatizados'. Exemplos truefalse | |||
| ID do sistema de origem SourceSystemId | Identificador do sistema SAP S/4HANA de origem do qual os dados foram extraídos. | ||
| Descrição Este atributo especifica o sistema de origem, por exemplo, 'S4H_PROD' ou 'ERP_EU'. Ele é especialmente importante em ambientes com várias instâncias de ERP ou uma combinação de sistemas legados e modernos. Na análise, permite comparar a performance do processo entre diferentes sistemas ou regiões. Também garante a rastreabilidade da origem dos dados e é essencial para a governança de dados e a solução de problemas quando dados de várias fontes são combinados em uma plataforma central de Process Mining. Por que isso importa Fornece contexto sobre a origem dos dados, essencial para a governança de dados e para comparar processos entre diferentes sistemas ou unidades da empresa. Onde encontrar Este valor geralmente é derivado do ID do sistema SAP (sy-sysid) durante a extração dos dados ou configurado como um valor estático no fluxo de ETL. Exemplos S4PS4H_PROD_100ECC_EU | |||
| Motivo do estorno ReversalReason | Código que indica o motivo do estorno de um documento de fatura. | ||
| Descrição Quando uma fatura é lançada incorretamente, ela costuma ser estornada. O código do motivo do estorno explica por que isso aconteceu, por exemplo, 'Data de lançamento incorreta' ou 'Erro de entrada de dados'. Analisar os motivos de estorno ajuda a identificar padrões de erro no processo de lançamento de faturas. Esse insight pode ser usado para melhorar o treinamento, reforçar os controles do sistema ou resolver problemas recorrentes que geram retrabalho financeiro e sobrecarga administrativa. Por que isso importa Explica por que as faturas foram canceladas e revela diretamente as fontes de erros e retrabalho no processo de lançamento. Onde encontrar Encontrado no cabeçalho do documento original na tabela BKPF, campo STGRD (motivo do estorno). Exemplos 010205 | |||
| Nº do documento de compensação. ClearingDocumentNumber | Número do documento que compensa a fatura, geralmente o documento de pagamento. | ||
| Descrição O número do documento de compensação conecta um item de fatura em aberto à transação que o compensa, quase sempre o documento de pagamento. Isso confirma que a fatura foi paga. Este atributo é a ligação definitiva entre uma fatura e seu pagamento. Ele é usado para identificar a atividade 'Pagamento executado' e o timestamp correspondente, essenciais para calcular o tempo total do processo e a taxa de pagamentos em dia. Por que isso importa Confirma que a fatura foi paga e a conecta à transação de pagamento específica, algo essencial para analisar o tempo de ciclo e a performance dos pagamentos. Onde encontrar Encontrado na tabela de segmentos de documentos BSEG, campo AUGBL (número do documento de compensação). Exemplos 150000000115000000231500000088 | |||
| Número de ciclos de aprovação ApprovalCycleCount | Número de vezes que 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 resultado maior que um indica que a fatura foi rejeitada ou devolvida pelo menos uma vez, exigindo um novo ciclo de aprovação. Este atributo contribui diretamente para o KPI 'Taxa de aprovação na primeira tentativa'. Ao analisar faturas com muitos ciclos de aprovação, as organizações podem identificar os motivos das reprovações, como informações insuficientes ou codificação incorreta, e tomar medidas para melhorar o processo. Por que isso importa Quantifica o retrabalho no subprocesso de aprovação, ajudando a medir a taxa de acerto na primeira tentativa e identificar os motivos das rejeições. Onde encontrar Calculado contando as ocorrências da atividade 'Fatura enviada para aprovação' para cada InvoiceNumber exclusivo. Exemplos 123 | |||
| Paga em dia IsPaidOnTime | Indicador verdadeiro quando a fatura é paga na data de vencimento ou antes dela. | ||
| Descrição Este atributo booleano resulta da comparação entre a data real do pagamento (o timestamp da atividade 'Pagamento executado') e a 'Data de vencimento do pagamento'. Ele apresenta um resultado claro, sim ou não, para o status do pagamento de cada fatura. Este é o cálculo central do KPI 'Taxa de pagamentos em dia'. Ele facilita a filtragem e a análise das características dos pagamentos atrasados, como fornecedores, empresas ou valores de fatura associados aos atrasos. Por que isso importa Mede diretamente o cumprimento das condições de pagamento, um KPI essencial para a gestão do relacionamento com fornecedores e das operações financeiras. Onde encontrar Calculado comparando o EventTime da atividade 'Pagamento executado' com o atributo PaymentDueDate. (Data do pagamento <= PaymentDueDate). Exemplos truefalse | |||
| Tem retrabalho IsRework | Indicador que informa se a 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 ciclos de retrabalho. O retrabalho é identificado por sequências específicas de atividades, por exemplo, '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 'Taxa de retrabalho de faturas'. Ele permite que analistas identifiquem e investiguem facilmente os casos com retrabalho para entender as causas raiz da ineficiência e do esforço manual repetido. Por que isso importa Identifica fluxos de processo ineficientes que exigem a repetição do trabalho, ajudando a quantificar o desperdício e localizar as causas raiz das exceções do processo. Onde encontrar Calculado com base na sequência de atividades do Event Log. Por exemplo, se 'Fatura rejeitada' aparecer no rastreamento de uma fatura, este indicador será definido como verdadeiro. Exemplos truefalse | |||
| Timestamp da extração ExtractionTimestamp | A data e a hora em que os dados foram extraídos do sistema de origem. | ||
| Descrição Este atributo registra o timestamp da extração dos dados. Ele indica o nível de atualização dos dados analisados na ferramenta de Process Mining. Na análise, ajuda a entender o quão recentes são os insights gerados. É essencial para os Dashboards de monitoramento operacional, pois garante que as decisões se baseiem em informações atualizadas e ajuda a gerenciar os ciclos de atualização dos dados. Por que isso importa Indica o nível de atualização dos dados e garante que as análises e os relatórios usem as informações mais recentes disponíveis. Onde encontrar Este não é um campo do SAP. A ferramenta de extração de dados ou o processo de ETL o gera e adiciona no momento da extração. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
Atividades de compras ao pagamento: processamento de faturas
| Atividade | Descrição | ||
|---|---|---|---|
| Documento de fatura criado | Este é o primeiro evento e marca a criação de um documento de fatura no SAP. Ele pode ser registrado quando um usuário salva um novo documento de fatura, que pode estar estacionado ou ainda não contabilizado. | ||
| Por que isso importa Esta atividade marca o início do ciclo de vida do processamento da fatura. Analisar o tempo entre este evento e os seguintes é essencial para medir o prazo total de processamento. Onde encontrar Este evento é registrado com base na 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 de transação (BKPF-TCODE), como FB60, MIRO ou MIR7, indica como o documento foi criado. Coleta Use a data e hora de criação em BKPF-CPUDT e BKPF-CPUTM para o documento de fatura. Tipo de evento explicit | |||
| Fatura aprovada | Esta atividade indica que a autoridade designada aprovou a fatura. Ela é registrada quando o fluxo de trabalho de aprovação termina com sucesso ou quando um indicador de liberação é definido. | ||
| Por que isso importa Este é um marco crítico que libera a fatura para pagamento. Atrasos nas aprovações são um gargalo comum, e acompanhar esta atividade ajuda a localizar aprovadores ou etapas lentas do processo. Onde encontrar Isso pode ser identificado pela etapa final de liberação em um fluxo de trabalho do SAP ou pelo acompanhamento de alterações nos campos de status de liberação das tabelas associadas à fatura ou ao documento de compras. Coleta Identifique a conclusão do fluxo de trabalho ou alterações no campo de status de liberação do documento. Tipo de evento inferred | |||
| Fatura contabilizada | Este é um evento financeiro importante: a fatura estacionada ou aprovada é contabilizada formalmente no razão geral. Essa ação reconhece o passivo com o fornecedor. | ||
| Por que isso importa O lançamento é um marco importante que separa a entrada e a aprovação dos dados da etapa de liquidação financeira. O tempo entre a criação da fatura e o lançamento é uma medida essencial da eficiência do processamento interno. Onde encontrar Este evento é identificado pela data de lançamento (BKPF-BUDAT) no cabeçalho do documento. Para documentos estacionados antes do lançamento, a mudança para o status lançado fornece o timestamp do evento. Coleta Use a data de lançamento (BKPF-BUDAT) como timestamp do evento. Tipo de evento explicit | |||
| Fatura estornada | Atividade que representa o estorno de um documento de fatura lançado anteriormente. Este é um evento final para uma fatura incorreta, que costuma ser lançada novamente com os dados corretos. | ||
| Por que isso importa Os estornos indicam erros críticos que não foram identificados antes no processo. Acompanhar sua frequência e as causas raiz é essencial para melhorar o processo e reduzir imprecisões financeiras. Onde encontrar O estorno é identificado quando um documento de estorno é criado. O cabeçalho do documento original (BKPF) contém o número do documento de estorno (BKPF-STBLG), e vice-versa. A data de lançamento do documento de estorno corresponde ao horário do evento. Coleta Identifique os documentos que têm um valor no campo BKPF-STBLG e use a data de lançamento do documento de estorno. Tipo de evento explicit | |||
| Pagamento executado | Esta é a atividade final do processo padrão: o pagamento é realizado e a fatura é compensada. Isso indica que os valores foram transferidos ao fornecedor. | ||
| Por que isso importa Este evento marca o fim do ciclo de vida da fatura P2P. Ele é essencial para calcular o tempo total do processo, de ponta a ponta, e medir a performance dos pagamentos em dia em relação à data de vencimento. Onde encontrar Este evento é registrado com base nas informações do documento de compensação do 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. Coleta Use a data de compensação (BSEG-AUGDT) do item de linha compensado do fornecedor. Tipo de evento explicit | |||
| Bloqueio de pagamento definido | Atividade em que um bloqueio é aplicado intencionalmente a uma fatura para impedir seu pagamento. Isso costuma ocorrer por divergências de preço ou quantidade ou por uma nota de crédito pendente. | ||
| Por que isso importa Bloqueios de pagamento são uma das principais causas de atrasos e disputas com fornecedores. Analisar a frequência, a duração e os motivos dos bloqueios é essencial para melhorar a pontualidade dos pagamentos. Onde encontrar Este evento é registrado pelo acompanhamento de alterações no campo Payment Block Key (BSEG-ZLSPR) do item da fatura. Os registros de alteração nas tabelas CDHDR e CDPOS informam a data e hora e o usuário responsável pela definição do bloqueio. Coleta Identifique quando o campo BSEG-ZLSPR é preenchido, usando os documentos de alteração (CDHDR/CDPOS). Tipo de evento explicit | |||
| Bloqueio de pagamento removido | Representa a resolução de um problema: um bloqueio de pagamento aplicado anteriormente é removido, e a fatura volta a ficar apta para pagamento. | ||
| Por que isso importa O intervalo entre a aplicação e a remoção de um bloqueio corresponde ao tempo de resolução de uma exceção do processo. Reduzir esse período é essencial para melhorar a eficiência e o relacionamento com os fornecedores. Onde encontrar Este evento é registrado quando o campo Payment Block Key (BSEG-ZLSPR) é apagado. Essa alteração fica registrada nas tabelas CDHDR e CDPOS, que informam a data e hora da remoção. Coleta Identifique quando o campo BSEG-ZLSPR é apagado, usando os documentos de alteração (CDHDR/CDPOS). Tipo de evento explicit | |||
| Dados da fatura atualizados | Esta atividade registra uma alteração feita no documento da fatura após sua criação. Isso é comum em ciclos de retrabalho após uma rejeição ou para corrigir erros. | ||
| Por que isso importa Atualizações frequentes indicam retrabalho e possíveis problemas na qualidade dos dados inseridos. Acompanhar essas alterações ajuda a quantificar o esforço dedicado às correções e identificar erros recorrentes. Onde encontrar As alterações em campos importantes são registradas nas tabelas de documentos de alteração do SAP: CDHDR (cabeçalho) e CDPOS (item). Os eventos podem ser gerados filtrando as alterações relacionadas ao objeto da fatura. Coleta Extraia das tabelas CDHDR e CDPOS os eventos de alteração relacionados ao objeto da fatura. Tipo de evento explicit | |||
| Fatura enviada para aprovação | Esta atividade marca o início do fluxo de trabalho formal de aprovação da fatura. Em geral, ela é identificada quando o status da fatura muda para 'aguardando aprovação' ou quando um item de fluxo de trabalho é gerado. | ||
| Por que isso importa Este é o ponto de partida para medir o tempo de ciclo de aprovação. Saber quando as aprovações começam é essencial para identificar gargalos no próprio fluxo de trabalho de aprovação. Onde encontrar Em geral, isso é identificado pelo início de um SAP Business Workflow (tabela SWW_WI2OBJ) vinculado ao objeto da fatura, como BUS2081, ou por uma alteração em um campo de status personalizado no cabeçalho do documento. Coleta Identifique a criação de um item de fluxo de trabalho relacionado ao documento da fatura. Tipo de evento inferred | |||
| Fatura estacionada | Representa uma fatura inserida no sistema, mas ainda não contabilizada no razão geral. O estacionamento permite salvar faturas incompletas ou deixá-las para revisão antes da contabilização. | ||
| Por que isso importa O estacionamento indica uma pausa intencional no processo. Acompanhar a duração e a frequência das faturas estacionadas ajuda a identificar as causas dos atrasos antes do início do ciclo formal de contabilização e aprovação. Onde encontrar Isso pode ser identificado por documentos criados com transações de estacionamento, como MIR7 e FV60, ou pela consulta a campos de status específicos na tabela BKPF ou em tabelas próprias para documentos estacionados, como VBKPF. Coleta Identifique documentos criados com transações de estacionamento ou verifique se o status do documento indica que ele está estacionado. Tipo de evento explicit | |||
| Fatura rejeitada | Representa a rejeição de uma fatura durante o processo de aprovação. Esse evento gera retrabalho, pois a fatura precisa ser corrigida e enviada novamente. | ||
| Por que isso importa Rejeições de faturas são um indicador importante de ineficiência do processo e problemas na qualidade dos dados. Analisar a frequência e os motivos das rejeições ajuda a identificar oportunidades de melhoria e treinamento. Onde encontrar Isso é identificado por atualizações específicas de status em um fluxo de trabalho do SAP, como o status 'rejeitada', ou por eventos que cancelam o fluxo de trabalho de aprovação atual e devolvem a fatura para quem está processando o documento. Coleta Identifique alterações no status do fluxo de trabalho que indiquem rejeição. Tipo de evento inferred | |||
| Pagamento executado com atraso | Este evento calculado ocorre quando o pagamento de uma fatura é executado após a data de vencimento calculada. Ele é determinado pela comparação de dois campos de data. | ||
| Por que isso importa Esta atividade contribui diretamente para os KPIs de pagamentos em dia e ajuda a identificar fornecedores ou unidades de negócio com pagamentos atrasados frequentes, o que pode prejudicar o relacionamento com fornecedores e gerar multas. Onde encontrar O cálculo compara a data de compensação (BSEG-AUGDT) com a data líquida de vencimento. A data de vencimento, por sua vez, é calculada com base na data-base (BSEG-ZFBDT) e nas condições de pagamento (BSEG-ZTERM). Coleta Determine comparando BSEG-AUGDT > (BSEG-ZFBDT + dias do prazo de pagamento). Tipo de evento calculated | |||
| Proposta de pagamento criada | A fatura é selecionada e incluída em uma proposta de pagamento durante uma execução de pagamento. Esta é a primeira etapa do processo automatizado de pagamento. | ||
| Por que isso importa Esta atividade indica a intenção de pagar. Atrasos entre esta etapa e a execução final do pagamento podem revelar problemas na execução do pagamento, nas aprovações ou na comunicação com o banco. Onde encontrar Essa informação pode ser encontrada nas tabelas de execução de pagamento, especificamente na REGUP, que contém os itens incluídos em uma proposta de pagamento. A data da execução na tabela REGUH correspondente fornece o timestamp. Coleta Identifique quando uma fatura aparece na tabela REGUP durante a execução de uma proposta de pagamento. Tipo de evento explicit | |||
Guias de extração
Etapas
- Pré-requisitos e autorização: Verifique se o usuário que fará a extração tem as autorizações necessárias no SAP S/4HANA para acessar as CDS Views exigidas. Entre as principais estão
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. O usuário também precisará de permissão para executar consultas pela interface escolhida, como um serviço OData ou uma conexão SQL direta. - Escolha o método de conexão: Defina como você vai se conectar ao sistema SAP S/4HANA para executar a consulta SQL. Entre as opções comuns estão SAP Data Services, SAP Data Intelligence, uma ferramenta ETL de terceiros com conector SAP ou uma conexão SQL direta ao banco de dados SAP HANA, se as políticas de segurança da organização permitirem.
- Defina os parâmetros de extração: Antes de executar a consulta, defina os principais parâmetros. Especifique o período de extração, por exemplo,
CreationDateentre'YYYY-MM-DD'e'YYYY-MM-DD'. Identifique também os valores deCompanyCodeque você quer incluir para limitar o escopo da extração de dados. - Personalize a consulta SQL: Copie a consulta SQL fornecida para o cliente SQL ou a ferramenta de extração escolhida. Confira os placeholders, como
'{StartDate}','{EndDate}'e('{CompanyCode1}', '{CompanyCode2}'). Substitua-os pelos valores definidos na etapa anterior. Talvez você também precise ajustar os nomes dos campos de status do fluxo de trabalho conforme a configuração específica do SAP. - Execute a consulta: Execute a consulta SQL completa no banco de dados SAP S/4HANA ou pela camada de serviço apropriada. A consulta foi criada para abranger vários dados e pode levar bastante tempo, dependendo do volume e do período selecionado. Acompanhe a execução para identificar possíveis erros ou tempos limite.
- Confira os resultados iniciais: Quando a consulta terminar, faça uma verificação rápida dos resultados. Confira se as colunas
InvoiceNumber,ActivityNameeEventTimeestão preenchidas. Verifique se a colunaActivityNamecontém diferentes atividades, e não apenas 'Invoice Document Created'. - Trate a transformação dos dados: A consulta está estruturada para gerar um Event Log em formato adequado. Ainda assim, confirme se a coluna
EventTimeusa um formato de timestamp consistente, comoYYYY-MM-DDTHH:MM:SS. Quando necessário, a consulta combina os campos de data e hora em um único timestamp. - Exporte os dados: Exporte o conjunto de resultados final da ferramenta para um arquivo CSV (valores separados por vírgula). Esse formato é compatível com ferramentas de Process Mining, incluindo o ProcessMind.
- Prepare os dados para carregamento: Antes de carregar os dados, confirme se o arquivo CSV usa codificação UTF-8 para evitar problemas com caracteres. Verifique se os cabeçalhos das colunas correspondem exatamente aos atributos necessários:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodeetc. - Carregue os dados no ProcessMind: Carregue o arquivo CSV preparado no seu projeto de Process Mining. No modelo de dados da ferramenta, associe as colunas do arquivo aos campos correspondentes de ID do caso, nome da atividade e timestamp.
Configuração
- CDS Views utilizadas: As principais fontes de dados são CDS Views padrão do SAP. Entre as principais estão
I_InvoiceDocument, para dados do cabeçalho;I_OperationalAcctgDocItem, para detalhes de lançamentos financeiros e compensações; eI_ChangeDocumentcomI_ChangeDocumentItem, para acompanhar alterações históricas em atributos da fatura, como bloqueios de pagamento e status do fluxo de trabalho. - Filtro por período: É essencial filtrar os dados por um período específico para controlar a performance. A consulta fornecida usa um placeholder para
CreationDatena viewI_InvoiceDocument. Para começar, recomendamos um período de 3 a 6 meses. - Filtro por código da empresa: Para manter a extração relevante e gerenciável, filtre sempre por um ou mais valores de
CompanyCode. A consulta inclui o placeholderWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para esse fim. - Filtro por tipo de documento: Você pode refinar a extração filtrando por
InvoiceDocumentType. Por exemplo, pode incluir faturas padrão de fornecedores (RE) e excluir notas de crédito. Adicione esse filtro à cláusulaWHEREda CTE inicial. - Pré-requisitos: O usuário que executar a consulta precisa de autorizações de visualização adequadas para documentos financeiros e de compras nos códigos de empresa especificados. O acesso ao banco de dados HANA subjacente por um 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 alteração (
I_ChangeDocument,I_ChangeDocumentItem) pode exigir bastante processamento. Aplique filtros rigorosos por data, código da empresa e classe de objeto (INCOMINGINVOICE) para evitar longos tempos de execução.
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
- Confirme se o acesso direto de leitura ao tenant SAP HANA ou ao esquema do banco de dados foi aprovado. Obtenha um usuário de banco de dados somente leitura, autorizado a acessar as tabelas SAP necessárias e quaisquer tabelas aprovadas de histórico de alterações ou fluxo de trabalho. Use SAP HANA Database Explorer, SAP HANA Studio ou um cliente SQL aprovado. Não use acesso de gravação em produção.
- Confirme os nomes físicos das tabelas e colunas no sistema S/4HANA de destino. ACDOCA, BKPF e RBKP são pontos de partida padrão, mas os objetos de fluxo de trabalho, estacionamento, proposta de pagamento, execução de pagamento, histórico de alterações e histórico de bloqueios de pagamento podem variar conforme a versão ou as personalizações do cliente. Substitua cada placeholder entre colchetes na consulta por objetos verificados no catálogo do sistema e que correspondam à semântica de negócio relevante.
- Defina o período de extração usando [Start timestamp] e [End timestamp]. Extraia um período suficientemente amplo de documentos e eventos, normalmente de três a seis meses, e amplie-o quando as datas de vencimento ou os pagamentos atrasados puderem ficar fora do período de criação da fatura.
- Identifique os casos de fatura usando a chave configurada para a fatura. A consulta usa InvoiceNumber como identificador do caso e, quando necessário, combina esse valor internamente com o código da empresa e o exercício fiscal para evitar duplicidades. Confirme se a definição de negócio exige incluir o exercício fiscal ou o código da empresa no identificador do caso do ProcessMind.
- Associe os dados de faturas lançadas de RBKP, BKPF e ACDOCA. Use RBKP para informações do cabeçalho da fatura, BKPF para timestamps e usuários dos documentos contábeis e ACDOCA para fornecedor, valor, documento de compras, compensação e informações contábeis relacionadas a pagamentos, quando disponíveis. Não presuma que todos os campos estejam preenchidos em todos os cenários de lançamento.
- Associe eventos de estacionamento, aprovação, rejeição, atualização, bloqueio de pagamento, estorno, proposta e execução de pagamento às fontes verificadas para o sistema. Substitua as views de origem indicadas como placeholders por views ou tabelas aprovadas que exponham timestamps dos eventos, referências às faturas, usuários, status e valores antigos e novos. Cada atividade precisa ser emitida como uma linha de evento explícita, pois o ProcessMind não infere eventos.
- Execute a consulta SQL completa em uma sessão de não produção ou somente leitura. Confira os planos de execução e restrinja a consulta por código da empresa, tipo de documento, exercício fiscal e timestamp do evento, quando apropriado. Evite junções sem restrições entre grandes tabelas de lançamentos e de histórico.
- Valide os resultados usando as verificações descritas abaixo. Confirme se todas as colunas necessárias estão presentes, se
EventTimeestá preenchido para cada evento, seInvoiceNumberestá preenchido para cada caso e se os 13 nomes de atividade aparecem quando há dados correspondentes nas fontes. - Exporte os resultados em um arquivo delimitado compatível com o ProcessMind, de preferência CSV em UTF-8, com uma linha por evento e as colunas InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason e PurchasingDocument. Mantenha os timestamps em um fuso horário consistente e preserve os zeros à esquerda nos identificadores.
- Carregue o Event Log no ProcessMind e configure InvoiceNumber como identificador do caso, ActivityName como coluna de atividade e EventTime como coluna de timestamp. Se a configuração do ProcessMind aceitar chaves adicionais para o caso, use a mesma política de chave composta aplicada na extração.
Configuração
- Período: Para a extração inicial, use um intervalo móvel de três a seis meses. Inclua um histórico maior quando eventos de aprovação, pagamento, compensação, estorno ou pagamento atrasado puderem ocorrer depois do período de criação da fatura.
- Escopo da empresa: Filtre por [Company code filter] e confirme se os códigos de empresa selecionados estão autorizados para a extração.
- Escopo dos documentos: Filtre por [Document type filter] e inclua os tipos de documento que representam faturas de fornecedores, notas de crédito, faturas estacionadas e estornos no processo em questão.
- Identificador do caso: Use InvoiceNumber, conforme exigido pela definição do processo. Quando os números das faturas não forem únicos globalmente, mantenha o código da empresa e o exercício fiscal nos resultados de origem ou configure uma chave composta para o caso de acordo com o modelo do ProcessMind.
- Fontes de eventos: Verifique as fontes físicas das alterações de status do fluxo de trabalho, decisões de aprovação, estacionamento, histórico de alterações, bloqueios de pagamento, propostas de pagamento e execução de pagamentos. Essas fontes variam conforme a versão do S/4HANA, o escopo ativado, o desenho do fluxo de trabalho e as extensões do cliente.
- Política de timestamp: Selecione o timestamp do evento de negócio, não o timestamp da extração. Documente o fuso horário e converta todos os timestamps dos eventos de forma consistente antes de carregar os dados.
- Política de valores: Use o valor na moeda do código da empresa e confirme se a fonte selecionada armazena os sinais de débito e crédito de forma consistente. Evite somar linhas do diário sem validar a regra de agregação para o caso da fatura.
- Política de pagamento: Defina se Pagamento executado significa compensação, lançamento do documento de pagamento, execução bancária ou outro marco de negócio. Use a fonte correspondente à definição de processo acordada.
- Pagamento atrasado: Registre Pagamento atrasado executado somente quando Pagamento executado ocorrer após PaymentDueDate. A consulta calcula esse evento explicitamente, sem depender de inferências do ProcessMind.
- Performance: Restrinja as leituras das fontes por data, código da empresa, tipo de documento e exercício fiscal relevante. Selecione apenas as colunas necessárias, examine os planos de consulta e materialize views intermediárias aprovadas se o histórico da fonte for extenso.
- Pré-requisitos: Conectividade direta com SAP HANA, autorização de leitura para todos os objetos selecionados, permissão para consultar metadados e acesso aos dados relevantes de Contas a pagar, Razão geral, compras, fluxo de trabalho e pagamentos. Confirme se as licenças SAP necessárias, as políticas de acesso ao banco de dados e as aprovações de proteção de dados estão em vigor.
- Segurança: Use um usuário técnico somente leitura, proteja os dados de fornecedores e pagamentos e siga as políticas da organização para transporte, auditoria, mascaramento e gerenciamento de credenciais.
Consulta de exemplo sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Etapas
- Acesse o editor ABAP: Entre no sistema SAP S/4HANA. Abra a transação
SE38(ABAP Editor). - Crie o programa: Informe um nome para o novo programa no campo Program, por exemplo,
Z_PM_INVOICE_EXTRACT, e clique no botão 'Create'. Informe um título, defina Type como 'Executable Program' e salve o programa em um pacote adequado. - Defina a estrutura do programa e a 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 que os usuários informem parâmetros como o período da data de entrada da fatura, os códigos de empresa e os tipos de documento. Assim, o programa poderá ser reutilizado e adaptado a diferentes necessidades.
- Implemente a lógica de seleção de dados: Escreva as instruções ABAP SQL principais para selecionar dados das diversas tabelas SAP. O programa consultará sequencialmente os dados de cada uma das 13 atividades necessárias.
- Extraia os dados do cabeçalho e dos itens: Para eventos básicos, como 'Documento da fatura criado' e 'Fatura lançada', selecione dados de tabelas principais, como
RBKP(cabeçalho da fatura logística) eBKPF(cabeçalho do documento contábil). - Extraia os dados dos documentos de alteração: Para atividades como 'Bloqueio de pagamento definido' e 'Bloqueio de pagamento removido', consulte as tabelas de documentos de alteração
CDHDR(cabeçalho do documento de alteração) eCDPOS(itens do documento de alteração). Identifique as alterações em campos específicos, comoZLSPRna tabelaBSEG. - Extraia os dados de pagamento: Para registrar atividades relacionadas a pagamentos, consulte tabelas como
REGUP(itens processados pelo programa de pagamento) para propostas de pagamento eBSAK(itens compensados de fornecedores) para pagamentos executados. Identifique 'Pagamento atrasado executado' comparando a data de compensação (AUGDT) com a data líquida de vencimento (ZFBDT). - Extraia os dados do fluxo de trabalho: Para atividades de aprovação, consulte tabelas do SAP Business Workflow, como
SWW_WI2OBJ, para associar itens do fluxo de trabalho aos objetos de fatura. Essa etapa depende muito da configuração específica do fluxo de trabalho e pode exigir adaptações significativas. - Unifique os dados no formato de Event Log: Para cada atividade selecionada, formate os dados em uma estrutura de tabela interna comum. Cada linha dessa tabela representa um evento e deve conter o identificador do caso (
InvoiceNumber),ActivityNameeEventTime, além de outros atributos recomendados. - Gere o arquivo de saída: Use as instruções ABAP
OPEN DATASET,TRANSFEReCLOSE DATASETpara gravar o conteúdo da tabela interna final em um arquivo simples no servidor de aplicações SAP. Recomendamos o formato CSV (valores separados por vírgula). - Agende e execute: Execute o programa em primeiro plano para testar (usando
F8). Para execuções em produção, agende-o como um job em segundo plano pela transaçãoSM36, em horários de menor movimento, para evitar impactos na performance do sistema. - Recupere e carregue o arquivo: Use a transação
AL11para acessar o diretório do servidor de aplicações onde o arquivo foi salvo. Baixe-o para seu sistema local. Antes de carregar os dados na ferramenta de Process Mining, confirme se o arquivo está codificado em UTF-8 e formatado corretamente.
Configuração
- Período: 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 manter o volume de dados gerenciável. - Código da empresa (BUKRS): É essencial filtrar por um ou mais códigos de empresa. Extrair dados de todos os códigos de uma grande organização pode resultar em tempos de execução muito longos e arquivos grandes.
- Tipo de documento (BLART): Filtre os tipos de documento relevantes para isolar as faturas de fornecedores. Entre os tipos comuns estão 'RE' (fatura bruta) e 'KR' (fatura de fornecedor). Isso ajuda a excluir documentos que não são relevantes para a análise.
- Conta do fornecedor (LIFNR): O programa pode incluir um filtro opcional para números específicos de fornecedores, útil para análises direcionadas ou testes.
- Configuração do arquivo de saída: O programa deve permitir definir o caminho do arquivo de saída no servidor de aplicações e o delimitador dos campos, como vírgula ou ponto e vírgula.
- Pré-requisitos: O usuário ou a conta do sistema que executar o programa precisa de acesso de desenvolvedor para criar e executar programas ABAP (pela transação
SE38) e de autorizações amplas de leitura para tabelas FI, MM e Basis, incluindoBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSe tabelas do fluxo de trabalho.
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. Pronto para começar?
Comece hoje a otimizar o processamento de faturas. Este Template é o primeiro passo para melhorar significativamente as operações e ganhar eficiência.
Otimize agora o processamento de faturas de compras ao pagamento no SAP S/4HANA
Identifique gargalos e reduza em 30% ou mais o tempo de ciclo das faturas.
Não é necessário cartão de crédito. Configure em poucos minutos.