Seu Template de dados de compras ao pagamento: processamento de faturas
Seu Template de dados de compras ao pagamento: processamento de faturas
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações de extração para SAP S/4HANA
Purchase to Pay - Atributos do processamento de faturas
| Nome | Descrição | ||
|---|---|---|---|
| Número da fatura InvoiceNumber | O 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 de processo coesa. No Process Mining, esse atributo é fundamental para acompanhar a jornada completa de cada fatura. Ele permite reconstruir todo o fluxo do processo, desde o recebimento até o pagamento final, possibilitando a análise de tempos de ciclo, gargalos e variações do processo no nível de cada fatura. Por que isso importa É a chave essencial para conectar todos os eventos relacionados, permitindo rastrear completamente o ciclo de vida de uma fatura no sistema. Onde obter Este é 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 registro de data e hora que indica exatamente quando uma atividade específica aconteceu. 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, registros de data e hora precisos são usados para medir KPIs de performance, como 'Tempo médio do ciclo da fatura' e 'Tempo do ciclo de aprovação da fatura'. Ao analisar o tempo decorrido entre as atividades, as organizações podem localizar gargalos em que as faturas estão atrasando e identificar oportunidades para acelerar o processo. Por que isso importa Este registro de data e hora é a base de todas as análises orientadas por tempo, incluindo o monitoramento da performance, a identificação de gargalos e o acompanhamento de SLAs. Onde obter Normalmente obtido 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 | |||
| Nome da atividade ActivityName | O nome da atividade de negócio ou do evento ocorrido em um momento específico para uma fatura. | ||
| Descrição O nome da atividade descreve uma etapa específica ou uma alteração de status no ciclo de vida do processamento da fatura. Exemplos incluem 'Documento da fatura criado', 'Fatura enviada para aprovação', 'Bloqueio de pagamento definido' e 'Pagamento executado'. Este atributo é essencial para construir 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, loops de retrabalho e variações do processo que não estão em conformidade. Ele é a base de qualquer análise de Process Mining. Por que isso importa Ele define as etapas do processo, permitindo visualizar mapas de processo e analisar fluxos e variações do processo. Onde obter Derivado de uma combinação de códigos de transação SAP (SY-TCODE), status de objetos de documentos de alteração (CDHDR/CDPOS) e valores específicos de campos que indicam alterações de status. Exemplos Fatura estacionadaFatura aprovadaPagamento executado | |||
| Código da empresa CompanyCode | A unidade organizacional que representa uma empresa legalmente independente para a qual são elaboradas demonstrações financeiras. | ||
| Descrição O código da empresa é uma unidade organizacional fundamental no SAP Finance. Cada fatura é atribuída a um código de empresa específico, que determina a entidade legal responsável pela transação. No Process Mining, filtrar ou comparar por código da 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 Ele permite segmentar e comparar a performance do processamento de faturas entre diferentes entidades legais ou localizações geográficas da organização. Onde obter Este é um campo padrão na tabela de cabeçalho de documentos BKPF, campo BUKRS. Exemplos 1000US01DE01 | |||
| Data de vencimento do pagamento PaymentDueDate | A data até a qual a fatura deve ser paga para evitar atraso. | ||
| Descrição A data de vencimento do pagamento é a data calculada em que o pagamento ao fornecedor deve ser realizado, com base na data da fatura e nas condições de pagamento acordadas. Ela funciona como um prazo crítico no processo. Este atributo é essencial para o KPI 'Taxa de pagamentos no prazo' e para o Dashboard 'Performance de pagamentos por fornecedor'. 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 os fornecedores e sua reputação financeira. Por que isso importa É a principal referência para medir a performance dos pagamentos no prazo, algo crucial para manter bons relacionamentos com os fornecedores e evitar multas por atraso. Onde obter Essa data geralmente está disponível diretamente no item de linha do fornecedor na tabela BSEG, campo ZFBDT (data-base para o cálculo do vencimento). A data líquida de vencimento é calculada a partir dessa data-base e das condições de pagamento. Exemplos 2023-05-302023-06-152023-07-01 | |||
| Motivo do bloqueio de pagamento PaymentBlockReason | Um 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 é fundamental 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, permitindo ações corretivas direcionadas. Por que isso importa Fornece a causa-raiz específica dos bloqueios de pagamento, permitindo uma análise direcionada para reduzir atrasos e melhorar o processamento correto na primeira tentativa. Onde obter Localizado no item de linha do fornecedor da tabela BSEG, campo ZLSPR (chave de bloqueio de pagamento). Exemplos RIA | |||
| Nome do usuário UserName | O ID do usuário SAP da pessoa ou do sistema que executou a atividade. | ||
| Descrição Este atributo identifica o usuário que executou uma transação específica ou criou um documento. Ele pode ser o ID de um usuário ou o ID de um sistema para jobs automatizados em lote. Analisar 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 frequentemente com exceções ou quais faturas são processadas automaticamente, como pelo usuário 'BATCHUSER', algo essencial para calcular o KPI 'Taxa de automação de faturas'. Por que isso importa Ele atribui 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 obter Obtido 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 fornecedor ou credor associado à fatura. Ele conecta a transação da fatura aos dados mestres do fornecedor. Este atributo é fundamental para análises centradas no fornecedor, como avaliar a 'Performance de pagamentos por fornecedor' 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 os 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 obter Normalmente encontrado na tabela de segmentos de documentos contábeis 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 conecta a fatura do fornecedor ao pedido de compra (PO) original. Essa conexão é fundamental para o processo de conferência de três vias, que verifica a fatura em relação ao pedido de compra e ao recebimento da mercadoria. Analisar por esse atributo ajuda a entender problemas relacionados a faturas vinculadas ou não a pedidos de compra. Ele é essencial para investigar divergências de conferência e entender a eficiência da etapa de compras do processo. Por que isso importa Conecta a fatura ao processo de compras, algo essencial para analisar divergências de conferência e a conformidade com pedidos de compra. Onde obter Essa informação normalmente é encontrada na tabela de segmentos de documentos BSEG, campo EBELN (número do documento de compras). Exemplos 450000123445000056784500009012 | |||
| 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' normalmente representa uma fatura padrão de fornecedor, enquanto 'KG' pode representar uma nota de crédito de fornecedor. Analisar por tipo de documento permite segmentar o processo para entender como diferentes tipos de transação são tratados. Por exemplo, o processo de uma nota de crédito pode ser significativamente diferente do processo de uma fatura padrão. Essa segmentação fornece insights de processo mais precisos e relevantes. Por que isso importa Ele ajuda a diferenciar vários tipos de transações financeiras, como faturas padrão e notas de crédito, que geralmente seguem caminhos diferentes no processo. Onde obter Encontrado na tabela de cabeçalho de documentos BKPF, campo BLART. Exemplos KRREKG | |||
| Valor da fatura AmountInCompanyCodeCurrency | O valor bruto total da fatura na moeda local do código da empresa. | ||
| Descrição Este atributo representa o valor total da fatura. Ele é uma métrica importante para entender o impacto financeiro e a escala da operação de processamento de faturas. Analisar os valores das faturas ajuda a priorizar faturas de alto valor para um processamento mais rápido, identificar tendências de gastos e relacionar problemas do processo ao valor financeiro. Por exemplo, pode ser usado para investigar se faturas de alto valor têm maior probabilidade de ser bloqueadas ou de apresentar tempos de aprovação mais longos. Por que isso importa 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 Esse valor normalmente é 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 | O código que define as condições de pagamento acordadas com o fornecedor, como datas de vencimento e períodos de desconto. | ||
| Descrição As condições de pagamento definem as regras para pagar uma fatura, incluindo eventuais descontos disponíveis para pagamento antecipado. Por exemplo, 'Z030' pode significar 'Pagável em até 30 dias, líquido'. 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 pagamento antecipado, apoiando diretamente o KPI 'Taxa de aproveitamento de descontos por pagamento antecipado'. Por que isso importa Define as regras para datas de vencimento e descontos, impactando diretamente os KPIs de pagamentos no prazo e a gestão do capital de giro. Onde obter Encontrado no item de linha do fornecedor na tabela BSEG, campo ZTERM (chave das condições de pagamento). Exemplos 0001Z030NT60 | |||
| Contagem de ciclos de aprovação ApprovalCycleCount | A quantidade 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. Uma contagem maior que um indica que a fatura foi rejeitada ou devolvida pelo menos uma vez, exigindo um novo ciclo de aprovação. Este atributo apoia diretamente o KPI 'Taxa de aprovação na primeira tentativa'. Ao analisar faturas com muitas etapas de aprovação, as organizações podem identificar os motivos das aprovações malsucedidas, 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 de aprovação. Onde obter Calculado contando as ocorrências da atividade 'Fatura enviada para aprovação' para cada InvoiceNumber 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 informada pelo fornecedor na fatura. Ela é usada como ponto de partida para calcular a data de vencimento do pagamento com base nas condições de pagamento acordadas. Na análise, essa data é fundamental para cálculos financeiros, como determinar a idade da fatura e a elegibilidade para descontos por pagamento antecipado. Ela é uma entrada importante para o KPI 'Taxa de aproveitamento de descontos por pagamento antecipado'. Por que isso importa Serve como base para calcular as condições de pagamento e as datas de vencimento, algo essencial para gerenciar o capital de giro e aproveitar descontos. Onde obter Encontrada na tabela de cabeçalho de documentos BKPF, campo BLDAT (data do documento). Exemplos 2023-04-122023-05-152023-06-20 | |||
| É automatizado IsAutomated | Um indicador que informa se uma atividade foi executada 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 sucesso de suas iniciativas de automação, identificar novas oportunidades para reduzir o esforço manual e melhorar a eficiência. Por que isso importa Distingue atividades manuais de atividades conduzidas pelo sistema, algo fundamental para medir as taxas de automação e identificar oportunidades de automação adicional. Onde obter Derivado do atributo UserName. Um mapeamento ou uma regra é criado para classificar IDs de usuários específicos como 'automatizados'. Exemplos truefalse | |||
| É pago no prazo IsPaidOnTime | Um indicador verdadeiro quando a fatura foi paga na data de vencimento ou antes dela. | ||
| Descrição Este atributo booleano resulta da comparação entre a data real do pagamento, o registro de data e hora da atividade 'Pagamento executado', e a 'Data de vencimento do pagamento'. Ele fornece um resultado binário claro para o status de pagamento de cada fatura. Este é o cálculo principal do KPI 'Taxa de pagamentos no prazo'. Ele permite filtrar e analisar facilmente as características dos pagamentos atrasados, como fornecedores, códigos de empresa ou valores de fatura frequentemente associados a atrasos. Por que isso importa Mede diretamente o cumprimento das condições de pagamento, um KPI fundamental para a gestão do relacionamento com fornecedores e das operações financeiras. Onde obter Calculado comparando o EventTime da atividade 'Pagamento executado' com o atributo PaymentDueDate. (Payment Date <= PaymentDueDate). Exemplos truefalse | |||
| É retrabalho IsRework | Um indicador que informa 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 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 os analistas isolem 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 nos quais o trabalho precisa ser repetido, ajudando a quantificar desperdícios e localizar as causas-raiz das exceções do processo. Onde obter Calculado com base na sequência de atividades do Event Log. Por exemplo, se 'Fatura rejeitada' ocorrer no rastreamento de uma fatura, este indicador será definido como verdadeiro. Exemplos truefalse | |||
| ID do sistema de origem SourceSystemId | O 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, ele permite comparar a performance do processo entre diferentes sistemas ou regiões. Também garante a proveniência 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 Ele fornece contexto sobre a origem dos dados, algo essencial para a governança de dados e para comparar processos entre diferentes sistemas ou unidades da empresa. Onde obter Esse valor normalmente é derivado do ID do sistema SAP (sy-sysid) durante a extração dos 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 for contabilizada incorretamente, ela geralmente é estornada. O código do motivo do estorno explica por que essa ação foi realizada, por exemplo, 'Data de contabilização incorreta' ou 'Erro de entrada de dados'. Analisar os motivos dos estornos ajuda a identificar padrões de erros no processo de contabilização de faturas. Esse insight pode ser usado para melhorar treinamentos, aprimorar controles do sistema ou resolver problemas recorrentes que geram retrabalho financeiro e esforço administrativo. Por que isso importa Explica por que as faturas foram canceladas, fornecendo um insight direto sobre as fontes de erro e retrabalho no processo de contabilização. 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, normalmente representando 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 conexão definitiva entre uma fatura e seu pagamento. Ele é usado para identificar a atividade 'Pagamento executado' e seu registro de data e hora correspondente, algo essencial para calcular o tempo do ciclo de ponta a ponta e a taxa de pagamentos no prazo. Por que isso importa Confirma que uma fatura foi paga e a conecta à transação de pagamento específica, algo fundamental para analisar o tempo de ciclo e a performance dos pagamentos. Onde obter Encontrado na tabela de segmentos de documentos BSEG, campo AUGBL (número do documento de compensação). Exemplos 150000000115000000231500000088 | |||
| Registro de data e hora 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 horário do evento de extração dos dados. Ele indica o nível de atualização dos dados analisados na ferramenta de Process Mining. Na análise, ele é usado para entender a atualidade dos insights gerados. É fundamental para os Dashboards de monitoramento operacional, garantindo que as decisões sejam baseadas em informações atualizadas e ajudando a gerenciar os ciclos de atualização dos dados. Por que isso importa Indica o nível de atualização dos dados, garantindo que a análise e os relatórios usem as informações mais recentes disponíveis. Onde obter Este não é um campo SAP. Ele é gerado e adicionado pela ferramenta de extração de dados ou pelo processo de ETL no momento da extração. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
Purchase to Pay - Atividades de processamento de faturas
| Atividade | Descrição | ||
|---|---|---|---|
| Documento de fatura criado | Este é o primeiro evento, marcando a criação de um documento de fatura no SAP. Ele pode ser capturado quando um usuário salva um novo documento de fatura, que pode estar em estado estacionado ou pré-lançado. | ||
| 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 demais é essencial para medir o tempo 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, normalmente BKPF ou RBKP para faturas de logística. O código de transação (BKPF-TCODE), como FB60, MIRO ou MIR7, indica o método de criação. Captura Use o timestamp de criação de BKPF-CPUDT e BKPF-CPUTM para o documento de fatura. Tipo de evento explicit | |||
| Fatura aprovada | Esta atividade indica que a fatura foi aprovada pela autoridade designada. Ela é capturada quando o Workflow de aprovação é concluído 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 essa atividade ajuda a localizar aprovadores ou etapas lentas do processo. Onde obter Isso pode ser inferido a partir da etapa final de liberação em um Workflow do SAP ou do acompanhamento de alterações nos campos de status de liberação em tabelas associadas à fatura ou ao documento de compras. Captura Infira esse evento a partir de eventos de conclusão do Workflow ou de alterações no campo de status de liberação do documento. Tipo de evento inferred | |||
| Fatura contabilizada | Este é um evento financeiro importante, no qual a fatura estacionada ou aprovada é contabilizada formalmente no razão geral. Essa ação reconhece o passivo com o fornecedor. | ||
| Por que isso importa A contabilização é 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 a contabilização é uma medida importante da eficiência do processamento interno. Onde obter Este evento é identificado pela data de contabilização (BKPF-BUDAT) no cabeçalho do documento. Para documentos estacionados primeiro, a transição para o status contabilizado fornece o registro de data e hora do evento. Captura Use a data de contabilização (BKPF-BUDAT) como o registro de data e hora do evento. Tipo de evento explicit | |||
| Fatura estornada | Uma atividade que representa o estorno de um documento de fatura contabilizado anteriormente. Este é um evento terminal para uma fatura incorreta, que geralmente é lançada novamente de forma correta. | ||
| Por que isso importa Os estornos indicam erros críticos que não foram identificados antes no processo. Acompanhar sua frequência e suas causas-raiz é essencial para melhorar o processo e reduzir imprecisões financeiras. Onde obter Um estorno é identificado quando um documento de estorno é criado. O cabeçalho do documento original (BKPF) conterá o número do documento de estorno (BKPF-STBLG), e vice-versa. A data de contabilização do documento de estorno é o horário do evento. Captura Identifique os documentos que têm um valor no campo BKPF-STBLG e use a data de contabilização do documento de estorno. Tipo de evento explicit | |||
| Pagamento executado | Esta é a atividade final do processo padrão, na qual o pagamento é realizado e a fatura é compensada. Isso significa que os recursos foram pagos ao fornecedor. | ||
| Por que isso importa Isso marca o fim do ciclo de vida da fatura P2P. É essencial para calcular o tempo total do ciclo de ponta a ponta e medir a performance dos pagamentos no prazo em relação à data de vencimento. Onde obter Este evento é capturado a partir das 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 definido | Uma atividade em que um bloqueio é colocado intencionalmente em uma fatura para impedir seu pagamento. Isso geralmente ocorre devido a divergências de preço ou quantidade ou a uma nota de crédito pendente. | ||
| Por que isso importa Os bloqueios de pagamento são uma das principais causas de pagamentos atrasados e disputas com fornecedores. Analisar sua frequência, duração e motivos é essencial para melhorar as taxas de pagamento pontual. Onde obter Este evento é capturado acompanhando as alterações no campo Payment Block Key (BSEG-ZLSPR) do item da fatura. Os registros de alteração em CDHDR e CDPOS fornecem a data e hora e o usuário responsáveis pela definição do bloqueio. Captura Identifique quando o campo BSEG-ZLSPR é preenchido por meio dos documentos de alteração (CDHDR/CDPOS). Tipo de evento explicit | |||
| Bloqueio de pagamento removido | Representa a resolução de um problema, quando um bloqueio de pagamento definido anteriormente é removido. Com isso, a fatura volta a estar elegível para pagamento. | ||
| Por que isso importa O tempo entre a aplicação e a remoção de um bloqueio representa o tempo de resolução de uma exceção do processo. Reduzir essa duração é essencial para melhorar a eficiência e o relacionamento com os fornecedores. Onde obter Este evento é capturado quando o campo Payment Block Key (BSEG-ZLSPR) é limpo. Essa alteração é registrada nas tabelas CDHDR e CDPOS, fornecendo um registro de data e hora para a remoção. Captura Identifique quando o campo BSEG-ZLSPR é limpo por meio dos documentos de alteração (CDHDR/CDPOS). Tipo de evento explicit | |||
| Dados da fatura atualizados | Esta atividade reflete uma alteração feita no documento da fatura após sua criação inicial. Isso é comum durante 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 de qualidade dos dados no ponto de entrada. Acompanhar essas alterações ajuda a quantificar o esforço gasto em correções e identificar erros recorrentes. Onde obter As alterações nos campos principais são registradas nas tabelas de documentos de alteração do SAP, CDHDR, de cabeçalho, e CDPOS, de item. Os eventos podem ser gerados filtrando as alterações do 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 da fatura. Geralmente, ela é inferida quando o status da fatura muda para “aguardando aprovação” ou quando um item de Workflow é gerado. | ||
| Por que isso importa 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 Normalmente, isso é inferido a partir do início de um SAP Business Workflow, na tabela SWW_WI2OBJ, vinculado ao objeto da fatura, como BUS2081, ou de uma alteração em um campo de status personalizado no cabeçalho do documento. Captura Infira esse evento a partir da criação de um item de Workflow relacionado ao documento da fatura. Tipo de evento inferred | |||
| Fatura estacionada | Representa uma fatura que foi inserida no sistema, mas ainda não foi lançada no razão geral. O estacionamento é usado para salvar faturas incompletas ou para revisá-las posteriormente antes do lançamento. | ||
| Por que isso importa O estacionamento indica uma pausa deliberada no processo. Acompanhar a duração e a frequência das faturas estacionadas 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 por meio de transações de estacionamento, como MIR7 e FV60, ou pela verificação de campos de status específicos na tabela BKPF ou em tabelas dedicadas a documentos estacionados, como VBKPF. Captura Identifique documentos criados por meio de transações de estacionamento ou verifique se há um status de documento estacionado. Tipo de evento explicit | |||
| Fatura rejeitada | Representa a rejeição de uma fatura durante o processo de aprovação. Esse evento inicia um retrabalho, exigindo correção e reenvio. | ||
| Por que isso importa As rejeições de faturas são um indicador importante de ineficiência do processo e problemas de qualidade dos dados. Analisar a frequência e os motivos das rejeições ajuda a identificar oportunidades de melhoria e treinamento. Onde obter Isso é inferido a partir de atualizações específicas de status em um Workflow do SAP, como o status “rejeitada”, ou de eventos que cancelam o Workflow de aprovação atual e devolvem a fatura ao processador. Captura Infira esse evento a partir de alterações no status do Workflow que indiquem 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. Ele é derivado da comparação entre dois campos de data. | ||
| Por que isso importa Esta atividade apoia diretamente os KPIs de pagamentos no prazo e ajuda a identificar fornecedores ou unidades de negócio com pagamentos atrasados frequentes, o que pode prejudicar o relacionamento com os fornecedores e gerar multas. Onde obter Isso é calculado comparando a data de compensação (BSEG-AUGDT) com a data líquida de vencimento. A data de vencimento é calculada a partir da data-base (BSEG-ZFBDT) e das condições de pagamento (BSEG-ZTERM). Captura Derive 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 como parte de uma execução de pagamentos. 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 no processo de execução de pagamentos, nas aprovações ou na comunicação com o banco. Onde obter Essa informação pode ser encontrada nas tabelas de execução de pagamentos, 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 registro de data e hora. Captura Identifique quando uma fatura aparece na tabela REGUP a partir de uma execução de proposta de pagamento. Tipo de evento explicit | |||
Guias de extração
Etapas
- Pré-requisitos e autorização: garanta que o usuário responsável pela extração tenha as autorizações necessárias no SAP S/4HANA para acessar as CDS Views exigidas. As principais Views incluem
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. O usuário também precisará de permissões para executar consultas pela interface escolhida, como um serviço OData ou uma conexão SQL direta. - Identifique o método de conexão: determine como você se conectará ao sistema SAP S/4HANA para executar a consulta SQL. Os métodos comuns incluem 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 permitido pelas políticas de segurança da sua organização.
- Defina os parâmetros da extração: antes de executar a consulta, defina os principais parâmetros. Especifique o período da extração, por exemplo,
CreationDateentre'YYYY-MM-DD'e'YYYY-MM-DD'. Identifique também os valores específicos deCompanyCodeque você quer incluir para limitar o escopo da extração. - Personalize a consulta SQL: copie a consulta SQL fornecida para o cliente SQL ou a ferramenta de extração escolhida. Revise cuidadosamente os placeholders, como
'{StartDate}','{EndDate}'e('{CompanyCode1}', '{CompanyCode2}'). Substitua esses placeholders pelos valores reais definidos na etapa anterior. Talvez também seja necessário ajustar os nomes dos campos de status do Workflow com base na configuração específica do seu 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 ser abrangente e pode levar bastante tempo, dependendo do volume de dados e do período selecionado. Monitore a execução para identificar possíveis erros ou timeouts.
- Revise os resultados iniciais: quando a consulta for concluída, faça uma revisão rápida da saída. Verifique se as colunas
InvoiceNumber,ActivityNameeEventTimeestão preenchidas. Confirme se há várias atividades diferentes na colunaActivityName, e não apenas 'Invoice Document Created'. - Trate a transformação dos dados: a consulta foi estruturada para produzir um Event Log limpo. Ainda assim, confirme se a coluna
EventTimeestá em um formato de timestamp consistente, comoYYYY-MM-DDTHH:MM:SS. Quando necessário, a consulta fornecida combina campos de data e hora em um único timestamp. - Exporte os dados: exporte o conjunto final de resultados da sua ferramenta para um arquivo CSV (valores separados por vírgula). Esse formato é compatível com ferramentas de Process Mining, incluindo o ProcessMind.
- Prepare o upload: antes do upload, 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 exigidos:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodeetc. - Faça o upload no ProcessMind: envie o arquivo CSV preparado para seu projeto de Process Mining. Mapeie as colunas do arquivo para os campos correspondentes de ID do caso, nome da atividade e timestamp na configuração do modelo de dados da ferramenta.
Configuração
- CDS Views usadas: as principais fontes de dados são CDS Views padrão do SAP. As Views principais são
I_InvoiceDocumentpara dados de cabeçalho,I_OperationalAcctgDocItempara lançamentos financeiros e detalhes de compensação, eI_ChangeDocumentcomI_ChangeDocumentItempara acompanhar alterações históricas nos atributos da fatura, como bloqueios de pagamento e status do Workflow. - Filtragem por período: é fundamental filtrar os dados por um período específico para controlar a performance. A consulta fornecida usa um placeholder para
CreationDatena ViewI_InvoiceDocument. Um bom ponto de partida é usar dados de um período de 3 a 6 meses. - Filtro por código da empresa: para garantir que a extração seja relevante e administrável, filtre sempre por um ou mais
CompanyCode. A consulta inclui o placeholderWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para essa finalidade. - Filtro por tipo de documento: você pode refinar ainda mais a extração filtrando por
InvoiceDocumentType. Por exemplo, talvez queira incluir faturas padrão de fornecedores (RE), mas excluir notas de crédito. Esse filtro pode ser adicionado à cláusulaWHEREda CTE inicial. - Pré-requisitos: o usuário que executa 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: extrair dados das tabelas de documentos de alteração (
I_ChangeDocument,I_ChangeDocumentItem) pode exigir bastante da performance. Aplicar filtros rigorosos por data, código da 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
- Confirme se o acesso direto de leitura ao tenant ou esquema do banco de dados SAP HANA foi aprovado e obtenha um usuário de banco de dados somente leitura com autorização para as tabelas SAP necessárias e para quaisquer tabelas aprovadas de histórico de alterações ou Workflow. Use o SAP HANA Database Explorer, o 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 Workflow, estacionamento, proposta de pagamento, execução de pagamento, histórico de alterações e histórico de bloqueios de pagamento podem usar objetos específicos da versão ou do cliente. Substitua cada placeholder entre colchetes na consulta por objetos verificados no catálogo do sistema e com a semântica de negócio relevante.
- Defina o período da 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 datas de vencimento ou pagamentos atrasados puderem ocorrer fora do período de criação da fatura.
- Identifique os casos de fatura usando a chave de fatura configurada. A consulta usa InvoiceNumber como identificador do caso e o combina internamente com o código da empresa e o exercício fiscal quando necessário para evitar colisões. Confirme se a definição de negócio exige um exercício fiscal ou código da empresa adicional no identificador do caso do ProcessMind.
- Mapeie 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 do documento contábil e ACDOCA para fornecedor, valor, documento de compras, compensação e informações contábeis relacionadas ao pagamento, quando disponíveis. Não presuma que todos os campos estejam preenchidos em todos os cenários de lançamento.
- Mapeie os eventos de fatura estacionada, aprovação, rejeição, atualização, bloqueio de pagamento, reversão, proposta e execução de pagamento a partir das fontes específicas do sistema que foram verificadas. Substitua as Views de origem de placeholder por Views ou tabelas aprovadas que exponham timestamps dos eventos, referências de fatura, usuários, status e valores antigos e novos. Cada atividade deve 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. Revise 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 joins irrestritos entre tabelas grandes de lançamentos e histórico.
- Valide o resultado usando as verificações descritas abaixo. Confirme se todas as colunas obrigatórias estão presentes, se EventTime está preenchido para todos os eventos, se InvoiceNumber está preenchido para todos os casos e se os 13 nomes de atividades aparecem quando há dados correspondentes na fonte.
- Exporte o resultado como um arquivo delimitado compatível com o ProcessMind, de preferência um CSV em UTF-8, com uma linha por evento e as colunas InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason e PurchasingDocument. Preserve os timestamps em um fuso horário consistente e mantenha os zeros à esquerda nos identificadores.
- Faça o upload do Event Log no ProcessMind e configure InvoiceNumber como identificador do caso, ActivityName como coluna da atividade e EventTime como coluna do timestamp. Se a configuração do ProcessMind aceitar chaves adicionais de caso, use a mesma política de chave composta aplicada durante a extração.
Configuração
- Período: use um período móvel de três a seis meses para a extração inicial. Inclua histórico adicional quando eventos de aprovação, pagamento, compensação, reversão ou pagamento atrasado puderem ocorrer após o período de criação da fatura.
- Escopo da empresa: filtre por [Company code filter] e valide 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 reversões no processo de destino.
- Identificador do caso: use InvoiceNumber conforme exigido pela definição do processo. Quando os números das faturas não forem globalmente exclusivos, mantenha o código da empresa e o exercício fiscal no resultado da fonte ou configure uma chave composta de caso de acordo com o modelo do ProcessMind.
- Fontes dos eventos: verifique as fontes físicas das alterações de status do Workflow, 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 Workflow e as extensões do cliente.
- Política de timestamps: selecione o timestamp do evento de negócio, e não o timestamp da extração. Documente o fuso horário e converta todos os timestamps dos eventos de forma consistente antes do upload.
- Política de valores: use o valor na moeda da empresa e confirme se a fonte selecionada armazena os sinais de débito e crédito de forma consistente. Evite somar linhas contábeis sem validar a regra de agregação para o caso da fatura.
- Política de pagamentos: defina se Payment Executed significa compensação, lançamento do documento de pagamento, execução bancária ou outro marco de negócio. Use a fonte que corresponda à definição de processo acordada.
- Pagamento atrasado: emita Late Payment Executed somente quando Payment Executed ocorrer depois de PaymentDueDate. A consulta calcula esse evento explicitamente e não depende de inferência 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, analise os planos de consulta e materialize Views intermediárias aprovadas se o histórico da fonte for grande.
- Pré-requisitos: conectividade direta com o SAP HANA, autorização de leitura para todos os objetos selecionados, permissão para inspecionar metadados e acesso aos dados relevantes de Contas a Pagar, Razão Geral, compras, Workflow 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.
a 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: faça login no sistema SAP S/4HANA. Abra a transação
SE38(Editor ABAP). - Crie o programa: informe um nome para o novo programa no campo Programa, por exemplo,
Z_PM_INVOICE_EXTRACT, e clique no botão 'Criar'. Informe um título, defina o Tipo como 'Programa executável' e salve-o em um pacote adequado. - Defina a estrutura do programa e a tela de seleção: no editor, defina as estruturas de dados da saída final do Event Log. Em seguida, crie uma tela de seleção para permitir que os usuários informem parâmetros como o período da data de entrada da fatura, os códigos da empresa e os tipos de documento. Isso torna o programa reutilizável e flexível.
- Implemente a lógica de seleção de dados: escreva as instruções SQL ABAP principais para selecionar dados das várias tabelas SAP. O programa consultará sequencialmente cada uma das 13 atividades exigidas.
- Extraia os dados de cabeçalho e itens: para eventos fundamentais, como 'Invoice Document Created' e 'Invoice Posted', selecione dados de tabelas principais, como
RBKP(cabeçalho da fatura logística) eBKPF(cabeçalho do documento contábil). - Extraia os dados de documentos de alteração: para atividades como 'Payment Block Set' e 'Payment Block Removed', consulte as tabelas de documentos de alteração
CDHDR(cabeçalho do documento de alteração) eCDPOS(itens do documento de alteração). Você precisará identificar alterações em campos específicos, por exemplo,ZLSPRna tabelaBSEG. - Extraia os dados de pagamento: para capturar atividades relacionadas a pagamentos, consulte tabelas como
REGUP(itens processados pelo programa de pagamentos) para propostas de pagamento eBSAK(itens de fornecedores compensados) para pagamentos executados. Diferencie 'Late Payment Executed' comparando a data de compensação (AUGDT) com a data líquida de vencimento (ZFBDT). - Extraia os dados do Workflow: para atividades de aprovação, consulte tabelas do SAP Business Workflow, como
SWW_WI2OBJ, para vincular itens do Workflow a objetos de fatura. Essa parte depende muito da configuração específica do seu Workflow e pode exigir adaptações significativas. - Unifique os dados no formato de Event Log: para cada atividade selecionada, formate os dados em uma estrutura comum de tabela interna. Cada linha dessa tabela representa um único 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. Recomenda-se o formato CSV. - Agende e execute: execute o programa em primeiro plano para testes usando
F8. Para execuções em produção, agende-o como um job em segundo plano pela transaçãoSM36, para rodar fora do horário de pico e evitar impactos na performance do sistema. - Recupere e faça o upload: use a transação
AL11para acessar o diretório do servidor de aplicações onde o arquivo foi salvo. Baixe o arquivo para seu sistema local. Confirme se ele está codificado em UTF-8 e formatado corretamente antes de fazer o upload para a ferramenta de Process Mining.
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, recomenda-se um período de 3 a 6 meses para manter o volume de dados administrável. - Código da empresa (BUKRS): é fundamental filtrar por um ou mais códigos da empresa. Extrair dados de todos os códigos de uma organização grande pode gerar tempos de execução muito longos e arquivos grandes.
- Tipo de documento (BLART): filtre pelos tipos de documento relevantes para isolar as faturas de fornecedores. Os tipos comuns incluem 'RE' (fatura: bruto) e 'KR' (fatura de fornecedor). Isso ajuda a excluir documentos irrelevantes da 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 ter parâmetros para definir o caminho do arquivo de saída no servidor de aplicações e o delimitador de campos, como vírgula ou ponto e vírgula.
- Pré-requisitos: o usuário ou a conta do sistema que executa este programa precisa de acesso de desenvolvedor para criar e executar programas ABAP pela
SE38, além de autorizações amplas de leitura para tabelas de FI, MM e Basis, incluindoBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSe tabelas do 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. Pronto para começar?
Comece a otimizar o processamento de faturas hoje. Este Template é o primeiro passo para alcançar melhorias operacionais significativas e mais eficiência.
Otimize agora o processamento de faturas P2P no SAP S/4HANA
Encontre gargalos e reduza o tempo do ciclo das faturas em 30% ou mais.
Não é necessário cartão de crédito. Configure em poucos minutos.