Seu Template de dados de processamento de pagamentos de Contas a Pagar
Seu Template de dados de processamento de pagamentos de Contas a Pagar
- Atributos essenciais para análise de fornecedores e pagamentos
- Marcos essenciais do processo para o ciclo de pagamento
- Lógica especializada de extração para sistemas SAP S/4HANA
Atributos do processamento de pagamentos de contas a pagar
| Nome | Descrição | ||
|---|---|---|---|
| Atividade Activity | A tarefa específica ou alteração de status do evento registrada para a fatura. | ||
| Descrição Esse atributo representa as etapas distintas do processo que ocorrem durante o ciclo de vida da fatura. Ele captura eventos como criação, lançamento, bloqueio, aprovação e compensação da fatura. Os nomes das atividades são derivados de códigos de transação, entradas de logs de alteração ou atualizações de status do Workflow encontradas no sistema de origem. Na análise, esse campo é essencial para mapear a variante do fluxo do processo. Ele permite que o mecanismo de Process Mining visualize a sequência de etapas, identifique loops de retrabalho e determine onde o processo se desvia do caminho padrão. É o componente central do Event Log. Por que isso importa Ele define os nós do mapa do processo, permitindo visualizar o Workflow e os gargalos. Onde obter Derivado de códigos de transação (TCODE) ou do cabeçalho (CDHDR) e item (CDPOS) do documento de alteração Exemplos Fatura lançadaBloqueio de pagamento aplicadoExecução dos pagamentos realizadaFatura compensada | |||
| Hora do evento EventTime | O carimbo de data e hora exato em que a atividade ocorreu. | ||
| Descrição A Hora do evento registra a data e a hora específicas em que uma atividade foi gravada no banco de dados do SAP. Ela fornece a dimensão temporal necessária para ordenar os eventos sequencialmente dentro de um caso. Esse carimbo de data e hora geralmente é construído combinando os campos de data e hora da CPU nos logs do sistema ou nos cabeçalhos dos documentos. Na análise, esse atributo é essencial para calcular tempos de ciclo, duração e throughput. Ele permite medir os intervalos entre as etapas, como o tempo entre o recebimento da fatura e a aprovação final, o que é fundamental para identificar gargalos e avaliar a performance de KPIs como o tempo médio de aprovação de faturas. Por que isso importa Ele fornece a ordem cronológica dos eventos e é a base de todos os cálculos de performance baseados em tempo. Onde obter Campo CPUDT (Data de entrada) e CPUTM (Hora de entrada) da tabela SAP BKPF, ou campos UDATE e UTIME da CDHDR Exemplos 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Número da fatura InvoiceNumber | O identificador exclusivo da fatura do fornecedor que está sendo processada. | ||
| Descrição O Invoice Number é a chave primária para acompanhar o ciclo de vida de um item a pagar no sistema SAP S/4HANA. Ele se refere especificamente ao número do documento contábil gerado quando a fatura é lançada no Razão Geral. Na terminologia padrão do SAP, corresponde ao Document Number (BELNR) encontrado em um Company Code e Fiscal Year específicos. Na análise de processos, esse atributo funciona como o Case ID. Ele conecta todas as atividades distintas, desde o recebimento e o estacionamento inicial da fatura, passando por vários bloqueios e alterações de aprovação, até o pagamento de compensação final. O agrupamento dos eventos por esse identificador permite que os analistas reconstruam o histórico completo, de ponta a ponta, de cada obrigação de pagamento. Por que isso importa Ele funciona como o Case ID definitivo, permitindo reconstruir o fluxo do processo de pagamento de ponta a ponta. Onde obter Campo BELNR da tabela SAP BKPF (cabeçalho do documento contábil) ou campo BELNR da ACDOCA Exemplos 1900000523510000289119000006015100003002 | |||
| Sistema de origem SourceSystem | O identificador da instância do SAP S/4HANA de onde os dados foram originados. | ||
| Descrição Esse atributo identifica a instalação ou o cliente específico do ERP de onde os dados do processo foram extraídos. Em ambientes com várias instâncias do SAP ou sistemas legados operando em paralelo, esse campo mantém a linhagem dos dados e permite comparações entre sistemas. Na análise, esse campo funciona como um filtro de alto nível. Ele ajuda os analistas a separar os dados ao comparar a performance entre diferentes instalações regionais do sistema ou ao validar a consistência dos dados durante projetos de migração. Isso garante que as variações do processo atribuídas à configuração do sistema sejam devidamente contextualizadas. Por que isso importa Ele diferencia as fontes de dados em ambientes com vários sistemas, garantindo uma segmentação precisa. Onde obter ID do sistema (SY-SYSID) no contexto da instalação do SAP Exemplos SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Última atualização dos dados LastDataUpdate | O carimbo de data e hora que indica quando o registro foi extraído ou atualizado pela última vez. | ||
| Descrição Última atualização dos dados marca o momento em que os dados foram carregados com sucesso na plataforma de Process Mining. Ela não representa o momento do evento de negócio, mas a atualização do próprio conjunto de dados. Isso é essencial para manter a confiança nos Dashboards analíticos. Na análise, esse atributo ajuda os usuários a entenderem o quão atuais são as informações exibidas. Ele é especialmente importante ao monitorar Dashboards quase em tempo real, como o de análise de bloqueios de pagamentos, garantindo que as decisões sejam tomadas com base no estado mais recente do sistema SAP S/4HANA. Por que isso importa Ele informa a atualização dos dados, algo essencial para Dashboards operacionais. Onde obter Gerado pelo processo de ETL/extração Exemplos 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Código da empresa CompanyCode | A unidade organizacional para a qual são criados o balanço patrimonial e a demonstração de resultados. | ||
| Descrição O Company Code representa a entidade contábil independente dentro da empresa. É a unidade organizacional central da contabilidade externa e é usado para estruturar os dados financeiros. Cada fatura é atribuída a exatamente um Company Code. Na análise, esse atributo permite segmentar KPIs por entidade legal ou região. Ele é usado nos Dashboards para comparar a eficiência das equipes de contas a pagar em diferentes subsidiárias. Por exemplo, ajuda a identificar se uma filial tem uma taxa maior de bloqueios manuais de pagamentos em comparação com o padrão corporativo. Por que isso importa Ele segmenta o processo por entidade legal, facilitando o benchmarking interno. Onde obter Campo BUKRS da tabela SAP BKPF Exemplos US01DE1010002000 | |||
| Data de compensação ClearingDate | A data em que a fatura foi compensada por meio do pagamento. | ||
| Descrição A data de compensação registra quando o item em aberto no razão de Contas a Pagar foi baixado, normalmente por uma execução de pagamento ou por um lançamento manual. Isso marca, na prática, o fim do passivo. Na análise, esse atributo é usado para calcular o tempo de ciclo final do processo. É o timestamp usado para a atividade "Pagamento compensado" e é comparado à data líquida de vencimento para determinar a performance de pagamento no prazo. Ele alimenta diretamente o Dashboard de eficiência da compensação de pagamentos. Por que isso importa Ela marca a conclusão do processo de pagamento e é usada para determinar se o pagamento foi feito no prazo. Onde obter Campo AUGDT da tabela SAP BSEG ou AUGDT Exemplos 2023-11-012023-11-15 | |||
| Data líquida de vencimento NetDueDate | A data calculada até a qual a fatura deve ser paga para evitar multas. | ||
| Descrição A data líquida de vencimento é o prazo final para o pagamento. Ela é calculada somando o número máximo de dias da condição de pagamento à data-base. Embora às vezes seja armazenada explicitamente, geralmente é um campo calculado nas visões de análise. Na análise, ela é a principal referência do rastreador de pagamentos atrasados e multas. Comparar a data de compensação real com a data líquida de vencimento gera a métrica "Dias de atraso no pagamento", que ajuda a quantificar a eficiência da equipe de Contas a Pagar e o risco de atritos com fornecedores. Por que isso importa É o prazo-alvo do processo. Não cumpri-lo afeta a classificação de crédito e gera custos. Onde obter Calculada: Data-base + número máximo de dias da condição de pagamento (ZBD1T/ZBD2T/ZBD3T) Exemplos 2023-11-302023-12-01 | |||
| Motivo do bloqueio de pagamento PaymentBlockReason | O código que indica por que uma fatura está bloqueada para pagamento. | ||
| Descrição Esse atributo contém o código específico do motivo aplicado a uma fatura que impede que ela seja selecionada pela execução automática dos pagamentos. Os exemplos incluem 'A' para bloqueada para pagamento, 'R' para verificação de fatura ou bloqueios manuais definidos pelos usuários. Na análise, esse campo é o principal direcionador do Dashboard de análise de bloqueios manuais de pagamentos. Ao agregar a frequência dos diferentes motivos de bloqueio, a organização pode diagnosticar problemas sistêmicos, como variações frequentes de preço ou recebimentos de mercadorias ausentes, que estão atrasando o processo de pagamento. Por que isso importa Ele identifica a causa específica das interrupções do processo, permitindo uma análise direcionada das causas-raiz. Onde obter Campo ZLSPR da tabela SAP BSEG Exemplos ABR* | |||
| Nome de usuário UserName | O ID do usuário que executou a atividade específica. | ||
| Descrição O Nome de usuário registra o ID de login da pessoa ou do agente do sistema responsável por executar uma etapa do processo. Pode ser um usuário manual inserindo dados ou o ID de um job em segundo plano, por exemplo, 'BATCH_USER', executando tarefas automatizadas. Na análise, esse atributo permite calcular a taxa de automação das atividades. Ao diferenciar usuários humanos de contas do sistema, os analistas podem medir o nível de automação do processo. Ele também é usado no Dashboard de distribuição de pontos de intervenção manual para avaliar a carga de trabalho entre as equipes. Por que isso importa Ele diferencia o trabalho manual do automatizado, permitindo calcular a taxa de automação. Onde obter Campo USNAM da tabela SAP BKPF ou campo USERNAME da CDHDR Exemplos BSMITHWF-BATCHRJONES | |||
| Número do fornecedor VendorNumber | O identificador exclusivo do fornecedor associado à fatura. | ||
| Descrição O Número do fornecedor corresponde à conta específica do credor no sub-razão do SAP. Ele conecta a fatura aos dados mestres que contêm termos de pagamento, dados bancários e informações de contato. No S/4HANA, geralmente está vinculado ao conceito de Business Partner, mas mantém o nome de campo legado LIFNR em muitas tabelas. Na análise, esse atributo é fundamental para o Dashboard de conformidade com os termos de pagamento dos fornecedores. Ele permite que os analistas agreguem a performance do processo por fornecedor, identificando fornecedores específicos que causam bloqueios, variações de preço ou atrasos de forma recorrente. Ele apoia decisões estratégicas de sourcing e a gestão do relacionamento com fornecedores. Por que isso importa Ele permite agregar a performance por fornecedor, algo essencial para identificar as causas-raiz dos atrasos. Onde obter Campo LIFNR da tabela SAP BKPF ou campo LIFNR da ACDOCA Exemplos 100050VEND-US-99200400 | |||
| Pagamento está atrasado IsLatePayment | Um indicador booleano que mostra se o pagamento foi feito depois da data líquida de vencimento. | ||
| Descrição Este atributo calculado retorna verdadeiro quando a data de compensação é estritamente posterior à data líquida de vencimento. Ele funciona como um classificador binário da performance do processo. Na análise, esse indicador é usado para contar os casos não conformes do KPI de frequência de multas por pagamento atrasado. Ele simplifica a criação de Dashboards, permitindo contar os valores "Verdadeiro" sem exigir cálculos complexos de datas na camada de visualização. Por que isso importa Ele simplifica o cálculo dos KPIs de performance de pagamentos no prazo. Onde obter Calculado: Data de compensação > Data líquida de vencimento Exemplos truefalse | |||
| Sem intervenção manual IsTouchless | Um indicador booleano que mostra se a fatura foi processada sem intervenção manual. | ||
| Descrição Este atributo é calculado analisando o fluxo de eventos de um caso. Se o caso contiver apenas atividades automatizadas, como usuário "system" ou determinados TCODES de background, e não tiver alterações ou bloqueios manuais, ele será classificado como touchless. Na análise, essa é a principal métrica do KPI de taxa de faturas touchless. Ela permite acompanhar o sucesso das iniciativas de automação e identificar quais tipos de caso, por fornecedor ou região, por exemplo, estão fluindo pelo sistema sem intervenção humana. Por que isso importa É a principal medida da automação e da eficiência do processo. Onde obter Calculado com base na sequência de atividades e nos tipos de usuário Exemplos truefalse | |||
| Termos de pagamento PaymentTerms | A chave que representa as condições acordadas para pagamento e descontos. | ||
| Descrição Os Termos de pagamento definem quando uma fatura vence e se há descontos financeiros para pagamento antecipado. Esse código, por exemplo, 'Z001', corresponde a regras como 'Líquido em 30 dias' ou '2% em 10 dias, líquido em 30 dias'. Ele é copiado do cadastro mestre do fornecedor para a fatura, mas pode ser alterado manualmente. Na análise, esse atributo é central para os Dashboards de otimização de descontos por pagamento antecipado e de conformidade com os termos de pagamento dos fornecedores. Ele permite que o sistema calcule a data-base de vencimento e identifique se o pagamento foi feito dentro da janela ideal para capturar a economia. Por que isso importa Ele determina o prazo esperado e os incentivos financeiros, sendo essencial para a análise de descontos. Onde obter Campo ZTERM da tabela SAP BSEG Exemplos Z001NT300001 | |||
| Tipo de documento DocumentType | Classifica o documento contábil, por exemplo, fatura de fornecedor, pagamento ou nota de crédito. | ||
| Descrição O Tipo de documento é um código de dois caracteres no SAP que classifica a transação contábil. Os tipos comuns incluem 'KR' para faturas de fornecedores, 'KZ' para pagamentos a fornecedores e 'RE' para recebimento bruto de fatura. Ele determina o intervalo de numeração e o status dos campos do documento. Na análise, esse atributo é usado para filtrar o escopo do processo. Por exemplo, um analista pode querer excluir notas de crédito para se concentrar exclusivamente na eficiência dos pagamentos enviados. Ele também ajuda a identificar a composição dos tipos de transação processados e apoia o Dashboard de complexidade das variantes do processo. Por que isso importa Ele categoriza o caso, diferenciando fatura e nota de crédito, e permite uma análise filtrada. Onde obter Campo BLART da tabela SAP BKPF Exemplos KRREKZKG | |||
| Valor da fatura InvoiceAmount | O valor bruto total da fatura na moeda do documento. | ||
| Descrição Esse atributo reflete o valor financeiro da fatura registrado no documento de origem. Ele representa a obrigação que deve ser liquidada com o fornecedor. No SAP S/4HANA, geralmente é armazenado no campo Amount in Document Currency. Na análise, o Valor da fatura é usado para priorizar o trabalho. Dashboards como o de distribuição de pontos de intervenção manual usam esse campo para destacar se atividades manuais que exigem muito esforço estão sendo desperdiçadas em faturas de baixo valor. Ele permite que a organização concentre os esforços de otimização em transações de alto valor, nas quais as falhas do processo representam um risco financeiro maior. Por que isso importa Ele representa o peso financeiro do caso, essencial para priorizar ineficiências de alto valor no processo. Onde obter Campo WRBTR da tabela SAP BKPF ou BSEG Exemplos 1500.00250.5010000.00 | |||
| Ano fiscal FiscalYear | O ano fiscal ao qual a fatura pertence. | ||
| Descrição O ano fiscal é um período usado para os relatórios financeiros. Junto com o código da empresa e o número do documento, ele forma a chave primária composta de um documento financeiro no SAP. Na análise, ele é necessário para identificar casos de forma exclusiva, mas também permite relatórios comparativos entre anos. Assim, o Case ID "Número da fatura" continua exclusivo ao longo de décadas de histórico de dados. Por que isso importa Requisito técnico para identificar casos de forma exclusiva no SAP FI. Onde obter Campo GJAHR da tabela SAP BKPF Exemplos 20232024 | |||
| Data-base BaselineDate | A data a partir da qual as condições de pagamento são aplicadas e as datas de vencimento são calculadas. | ||
| Descrição A data-base é o ponto de partida para calcular a data líquida de vencimento e os períodos de desconto à vista. Normalmente, ela corresponde à data da fatura ou à data de lançamento, dependendo da configuração e dos dados mestres do fornecedor. Na análise, essa data é um pré-requisito técnico para calcular o status "Está atrasado". Erros na data-base costumam levar a pagamentos antecipados, com impacto no fluxo de caixa, ou a pagamentos atrasados, com risco de multas. Verificar a precisão dessa data faz parte da análise de conformidade das condições de pagamento do fornecedor. Por que isso importa É o ponto de referência para todos os cálculos de vencimento. Onde obter Campo ZFBDT da tabela SAP BSEG Exemplos 2023-10-012023-10-15 | |||
| Dias do primeiro desconto à vista CashDiscountDays1 | O número de dias a partir da data-base durante os quais o primeiro desconto à vista está disponível. | ||
| Descrição Este atributo define a janela para as condições de pagamento mais favoráveis, como o "10" em "2% 10, líquido em 30 dias". Ele vem das condições armazenadas no item da fatura. Na análise, ele ajuda a determinar a "Data-alvo" do otimizador de descontos por pagamento antecipado. Se a fatura for compensada dentro dessa janela, o desconto será obtido. Esse campo ajuda a medir o custo de oportunidade de ciclos de processamento lentos. Por que isso importa Ele define a janela de oportunidade para obter economia financeira. Onde obter Campo ZBD1T da tabela SAP BSEG Exemplos 10140 | |||
| Documento de compras PurchasingDocument | O número do pedido de compra associado à fatura. | ||
| Descrição Este atributo vincula a fatura ao processo de compras anterior. Ele contém o número do pedido de compra (PO) usado na conferência da fatura. Nem todas as faturas, como despesas diversas, terão uma referência de PO. Na análise, este campo é essencial para a análise da taxa de Three Way Match. Ele permite separar as faturas associadas a POs das faturas sem PO, que normalmente seguem Workflows de aprovação muito diferentes. Também facilita o Process Mining de ponta a ponta, conectando os dados de Contas a Pagar aos dados de Compras. Por que isso importa Ele conecta Contas a Pagar a Compras, permitindo a análise de Three Way Match e a extensão do processo. Onde obter Campo EBELN da tabela SAP BSEG Exemplos 45000012344500009876 | |||
| Moeda Currency | O código da moeda associado ao valor da fatura. | ||
| Descrição O atributo Moeda especifica a denominação do Valor da fatura, como USD, EUR ou GBP. Ele permite interpretar corretamente os valores financeiros e é essencial ao agregar dados de diferentes Company Codes internacionais. Na análise, esse campo garante que os KPIs financeiros sejam calculados corretamente. Ele é frequentemente usado para normalizar os valores em uma moeda de relatório para Dashboards globais. Sem esse atributo, métricas agregadas como Gasto total ou Valor médio da fatura não teriam significado em um ambiente com várias moedas. Por que isso importa Ele contextualiza os valores financeiros, algo essencial para relatórios globais precisos. Onde obter Campo WAERS da tabela SAP BKPF Exemplos USDEURGBPJPY | |||
| Percentual do primeiro desconto à vista CashDiscountPercentage1 | O percentual de desconto disponível quando o pagamento é feito dentro do primeiro período de desconto. | ||
| Descrição Este atributo representa o incentivo financeiro oferecido pelo fornecedor para pagamentos antecipados, como o "2" em "2% 10". Na análise, ele é usado para calcular o valor do "Desconto à vista potencial". Multiplicando esse percentual pelo valor da fatura, os Dashboards podem mostrar o total que deixa de ser economizado devido às ineficiências do processo, apoiando o business case para automação. Por que isso importa Ele quantifica o potencial de economia, sendo essencial para os cálculos de ROI. Onde obter Campo ZBD1P da tabela SAP BSEG Exemplos 2.03.00.0 | |||
| Valor do desconto perdido DiscountLostAmount | O valor monetário dos descontos à vista disponíveis, mas não aproveitados. | ||
| Descrição Este atributo calculado representa o "dinheiro deixado na mesa". Ele é obtido verificando se o pagamento foi feito depois do prazo do desconto e, nesse caso, calculando o valor do percentual de desconto perdido aplicado ao valor da fatura. Na análise, essa é uma métrica financeira essencial para o otimizador de descontos por pagamento antecipado. Ela quantifica o custo da ineficiência em valores monetários, oferecendo um business case convincente para melhorias no processo. Por que isso importa Ele quantifica a perda financeira direta causada pelos atrasos do processo. Onde obter Calculado: se Data de compensação > Data do desconto, então Valor da fatura * Percentual de desconto Exemplos 30.000.00150.00 | |||
Atividades do processamento de pagamentos de contas a pagar
| Atividade | Descrição | ||
|---|---|---|---|
| Bloqueio de pagamento aplicado | Indica que um bloqueio de pagamento foi definido no item de linha da fatura, impedindo que ele seja selecionado pela execução dos pagamentos. Isso é capturado monitorando alterações no campo ZLSPR da tabela BSEG por meio de documentos de alteração. | ||
| Por que isso importa Os bloqueios são a principal causa de pagamentos atrasados e atritos no processo, afetando diretamente o Dashboard de análise de bloqueios manuais de pagamentos. Onde obter Tabelas CDPOS e CDHDR (documentos de alteração), procurando atualizações no campo BSEG-ZLSPR. Captura Registrado quando os registros da CDPOS são alterados em ZLSPR Tipo de evento explicit | |||
| Bloqueio de pagamento removido | Indica que um bloqueio de pagamento aplicado anteriormente foi removido, liberando efetivamente a fatura para pagamento. Isso é identificado quando o campo ZLSPR na BSEG muda de um valor para nulo ou vazio. | ||
| Por que isso importa Frequentemente funciona como um indicador de 'Fatura aprovada' em sistemas sem logs explícitos de Workflow, marcando o fim do período de gargalo. Onde obter Tabelas CDPOS e CDHDR, procurando a alteração de BSEG-ZLSPR para vazio. Captura Registrado quando os registros da CDPOS indicam a remoção de ZLSPR Tipo de evento explicit | |||
| Documento de pagamento criado | A geração do documento contábil que credita o banco e debita o fornecedor. É encontrado na BKPF com um tipo de documento de pagamento, por exemplo, ZP ou KZ. | ||
| Por que isso importa A realização financeira do pagamento, usada para calcular o Days Payable Outstanding (DPO). Onde obter Tabela BKPF, filtrada pelo tipo de documento (BLART) específico para pagamentos. Captura Registrado quando o documento de pagamento da BKPF é criado Tipo de evento explicit | |||
| Execução dos pagamentos realizada | Representa a execução dos pagamentos, quando as instruções de transferência de dinheiro são geradas. Isso é rastreado pela atualização de status nas tabelas REGUH ou REGUP. | ||
| Por que isso importa O compromisso operacional de pagar, essencial para analisar a eficiência do processo de agrupamento de pagamentos. Onde obter Tabela REGUH, normalmente correlacionada com a data e a identificação da execução. Captura Registrado quando o status da execução dos pagamentos é atualizado Tipo de evento explicit | |||
| Fatura lançada | Representa o registro oficial da obrigação no Razão Geral. Essa atividade é derivada do carimbo de data e hora de criação na tabela BKPF ou da data de entrada na tabela ACDOCA. | ||
| Por que isso importa Este é o principal ponto de início da linha do tempo financeira, estabelecendo a base para as datas de vencimento e a análise de aging. Onde obter Tabela BKPF, usando CPUDT (Data de entrada) e CPUTM (Hora de entrada). Captura Registrado quando o registro da BKPF é criado Tipo de evento explicit | |||
| Pagamento compensado | Marca a reconciliação final, na qual o item em aberto na conta do fornecedor é compensado com o pagamento. É capturado no campo AUGDT (Data de compensação) da tabela BSEG. | ||
| Por que isso importa O estado final do processo, indicando que o ciclo de vida foi concluído e os livros estão equilibrados. Taxas elevadas de compensação manual indicam ineficiências na reconciliação. Onde obter Tabela BSEG, campo AUGDT (Data de compensação). Captura Registrado quando o campo AUGDT é preenchido Tipo de evento explicit | |||
| Desconto financeiro perdido | Um evento calculado que marca a data em que expirou a elegibilidade para um desconto financeiro. É derivado da comparação entre a data-limite do desconto e a data atual ou a data do pagamento. | ||
| Por que isso importa Essencial para que o otimizador de descontos por pagamento antecipado visualize oportunidades financeiras perdidas. Onde obter Calculado: BSEG-ZFBDT + BSEG-ZBD1T (Dias de desconto 1). Captura Derivar comparando a data com a data-limite do desconto Tipo de evento calculated | |||
| Fatura estacionada | Indica que uma fatura foi inserida no SAP, mas ainda não foi lançada no Razão Geral, sendo frequentemente usada para o registro preliminar de dados. Isso é capturado explicitamente na tabela VBKPF ou pela identificação de documentos na BKPF com um código de status estacionado antes da transição para lançado. | ||
| Por que isso importa O estacionamento indica o início da fase de entrada de dados e ajuda a medir o tempo de espera entre o recebimento e a criação da obrigação financeira. Onde obter Tabela VBKPF para dados de cabeçalho de documentos estacionados ou BKPF com status específico do documento (BSTAT = V). Captura Registrado quando a entrada na VBKPF é criada Tipo de evento explicit | |||
| Fatura estornada | Indica que o documento da fatura foi estornado ou cancelado. É capturado verificando o campo STBLG (Documento de estorno) na tabela BKPF. | ||
| Por que isso importa Representa retrabalho e falha no processo, identificando desperdício e possível esforço duplicado. Onde obter Tabela BKPF, campo STBLG não está vazio. Captura Registrado quando o campo STBLG é preenchido Tipo de evento explicit | |||
| Fatura vencida | Um carimbo de data e hora calculado que representa o momento em que a fatura atingiu sua data de vencimento líquido. É derivado da adição dos dias dos termos de pagamento à data-base encontrada na tabela BSEG. | ||
| Por que isso importa Serve como referência para a performance de pagamentos no prazo e para o rastreador de multas por atraso de pagamento. Onde obter Calculado: BSEG-ZFBDT (Data-base) + BSEG-ZBD1T/ZBD2T/ZBD3T (Dias). Captura Derivar comparando a data atual com a data de vencimento líquido Tipo de evento calculated | |||
| Proposta de pagamento criada | Indica que a fatura foi incluída em uma execução de proposta de pagamento (F110), a primeira etapa do programa automatizado de pagamentos. É capturado na tabela REGUH, que armazena os dados de liquidação. | ||
| Por que isso importa Indica que a fatura foi selecionada para pagamento e passou pelas verificações de validação no programa de pagamentos. Onde obter Carimbo de data e hora de criação da tabela REGUH (chaves LAUFD e LAUFI). Captura Registrado quando o registro da REGUH é criado Tipo de evento explicit | |||
| Termos de pagamento alterados | Registra uma atualização nos termos de pagamento de uma fatura em aberto, alterando a data de vencimento ou a elegibilidade para desconto. Isso é rastreado pelos logs de alteração no campo ZTERM da tabela BSEG. | ||
| Por que isso importa Alterações frequentes sugerem erros nos dados mestres ou substituições manuais que afetam a previsão do fluxo de caixa e a conformidade com os termos de pagamento dos fornecedores. Onde obter Tabelas CDPOS e CDHDR, procurando atualizações no campo BSEG-ZTERM. Captura Registrado quando os registros da CDPOS são alterados em ZTERM Tipo de evento explicit | |||
| Variação de preço detectada | Atividade inferida que indica uma divergência entre o preço da fatura e o preço do pedido de compra. Ela é derivada da observação de uma Payment Block Key específica, normalmente 'R' para verificação de fatura, aplicada automaticamente no lançamento. | ||
| Por que isso importa Identifica as causas-raiz do retrabalho manual e apoia a análise da taxa de Three Way Match. Onde obter Inferido do valor 'R' de BSEG-ZLSPR, ou da configuração específica do sistema para bloqueios de preço, no momento do lançamento. Captura Comparar o valor de ZLSPR com 'R' Tipo de evento inferred | |||
| Variação de quantidade detectada | Atividade inferida que indica uma divergência entre a quantidade faturada e a quantidade do recebimento de mercadorias. Ela é derivada da observação de uma Payment Block Key específica, normalmente 'M' para variação de quantidade, aplicada ao item de linha. | ||
| Por que isso importa Essencial para analisar a eficiência da conferência e a qualidade dos dados da cadeia de suprimentos. Onde obter Inferido do valor 'M' de BSEG-ZLSPR, ou da configuração específica do sistema para bloqueios de quantidade. Captura Comparar o valor de ZLSPR com 'M' Tipo de evento inferred | |||
Guias de extração
Etapas
Identifique as visões CDS necessárias: confirme a disponibilidade das visões CDS padrão do SAP S/4HANA. As principais visões necessárias são I_JournalEntry (cabeçalho), I_OperationalAcctgDocItem (itens/equivalente ao BSEG), I_SupplierInvoice (logística), I_PaymentProposalItem (F110) e I_ChangeDocument (para logs).
Configure as permissões do usuário: garanta que o usuário do banco de dados ou o usuário técnico do serviço tenha privilégios SELECT nas visões DDL SQL associadas às entidades CDS. Normalmente, isso é gerenciado pelo SAP HANA Studio ou pelas ABAP Eclipse Development Tools (ADT).
Prepare o ambiente SQL: abra sua interface SQL, como SAP HANA Studio, DBeaver conectado ao HANA ou um conector de Process Mining que aceite SQL. Este método pressupõe acesso SQL direto à camada HANA, onde as visões CDS são expostas como visões.
Defina o escopo: determine o código da empresa (CompanyCode) e o intervalo de anos fiscais para limitar o volume de dados. Isso é essencial para a performance ao consultar a visão de itens de documentos contábeis operacionais.
Implemente a lógica das atividades: copie a consulta SQL fornecida abaixo. Ela usa UNION ALL para combinar 14 blocos de lógica distintos em uma única estrutura de Event Log. Cada bloco tem como alvo uma atividade específica, como Invoice Posted e Payment Cleared.
Trate os documentos de alteração: a consulta inclui seções para alterações nas condições de pagamento e manipulação de bloqueios. Elas dependem da visão I_ChangeDocument. Se essa visão não estiver ativa na sua versão específica do S/4, talvez seja necessário encapsular as tabelas subjacentes (CDHDR/CDPOS) em uma visão CDS personalizada.
Trate os eventos calculados: revise a lógica de Invoice Due e Cash Discount Lost. Esses são eventos calculados, gerados adicionando dias à data-base encontrada na visão de itens operacionais.
Execute a extração: execute a consulta. Para grandes volumes de dados, é altamente recomendável particionar a extração por ano fiscal ou código da empresa para evitar estouros de memória.
Verifique os formatos de data: garanta que a coluna EventTime esteja formatada como YYYY-MM-DD HH:MM:SS. O SAP HANA SQL retorna timestamps que podem exigir conversão, dependendo da aplicação de destino.
Exporte os dados: salve o resultado como arquivo CSV ou Parquet. Garanta que os cabeçalhos correspondam às colunas definidas na instrução SELECT final.
Transforme os dados para upload: se sua ferramenta de Process Mining exigir um formato CSV específico, como uma máscara de data específica, aplique essas transformações em um script de pós-processamento ou no SQL usando funções TO_VARCHAR.
Faça a validação final: carregue uma amostra no ProcessMind e verifique se o Case ID (Invoice Number) agrupa corretamente todas as atividades, do lançamento à compensação.
Configuração
- Filtro de código da empresa: restrinja a consulta a unidades organizacionais específicas (CompanyCode = '1000') para manter o contexto e a performance.
- Intervalo de datas: aplique um filtro em PostingDate ou CreationDate, como os últimos 12 meses, para controlar o volume de dados.
- Tipo de conta: filtre I_OperationalAcctgDocItem por FinancialAccountType = 'K' (fornecedor) para excluir linhas do razão geral e de clientes.
- Ativação das visões CDS: garanta que as visões I_JournalEntry, I_OperationalAcctgDocItem e I_PaymentProposalItem estejam ativas e liberadas para acesso SQL.
- Performance do log de alterações: consultar I_ChangeDocument pode consumir muitos recursos. Limite essas subconsultas por ObjectClass 'BELEG' e por nomes de campos específicos, como ZLSPR e ZTERM.
a Consulta de exemplo sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Etapas
- Confirme que o acesso SQL direto ao schema SAP HANA que contém ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP e as tabelas aplicáveis de documentos de alteração está disponível. Substitua [Your SAP HANA schema] e os detalhes da conexão pelos valores aprovados para o seu sistema.
- Confirme a população de faturas e o período de análise. Defina [Start date] e [End date] no formato YYYYMMDD e configure [Company code filter] como um predicado SQL válido, como BUKRS IN ('1000','2000').
- Valide a versão do SAP e a configuração local para documentos estacionados, campos de status do programa de pagamentos, tipos de documentos de pagamento e armazenamento de documentos de alteração. A consulta usa objetos de origem documentados e mapeamentos conservadores de campos, mas as extensões locais e diferenças entre versões devem ser verificadas antes do uso em produção.
- Execute a consulta no SAP HANA usando um cliente SQL ou serviço de extração aprovado. A consulta cria uma linha de evento para cada atividade extraída explicitamente. O ProcessMind não inferirá atividades ausentes no resultado.
- Revise os dados de origem e ajuste os predicados de configuração marcados para status de documentos estacionados, tipos de documentos de pagamento, status de propostas e execuções de pagamento e classes de objetos de documentos de alteração. Não amplie esses predicados sem reconciliar documentos contábeis duplicados ou não relacionados.
- Valide as junções usando InvoiceNumber, CompanyCode, exercício fiscal, número do documento contábil, número do fornecedor e item quando aplicável. Confirme que os números dos documentos de fatura são representados de forma consistente entre BKPF, BSEG, ACDOCA, REGUH e REGUP no sistema de destino.
- Faça a reconciliação dos eventos calculados. Invoice Due é gerado na data líquida de vencimento calculada, e Cash Discount Lost é gerado no primeiro prazo de desconto aplicável quando nenhum pagamento ocorreu antes desse prazo. Essas são linhas derivadas e devem ser claramente diferenciadas dos eventos baseados em registros de origem.
- Exporte o resultado como um CSV plano UTF-8 ou outro formato tabular compatível com o ProcessMind. Preserve os nomes exatos das colunas InvoiceNumber, Activity, EventTime, SourceSystem e LastDataUpdate. Mantenha uma linha por evento e não agregue atividades por fatura.
- Carregue o registro de eventos no ProcessMind, mapeando InvoiceNumber como identificador do caso, Activity como nome da atividade e EventTime como timestamp do evento. Mapeie as demais colunas como atributos de evento ou de caso, de acordo com a configuração de importação do ProcessMind.
Configuração
- Intervalo de datas: use um período móvel de 3 a 6 meses na extração inicial. Use de forma consistente os predicados de data de lançamento, data de alteração e data do programa de pagamentos e amplie o intervalo ao validar condições de pagamento longas.
- Schema: substitua [Your SAP HANA schema] pelo schema proprietário dos objetos SAP. Confirme se o ambiente expõe objetos dependentes do cliente pelo schema selecionado ou se exige um predicado explícito de cliente.
- Filtro por empresa: configure [Company code filter] para restringir BUKRS aos códigos de empresa necessários. Aplique o mesmo escopo a BKPF, BSEG, ACDOCA, REGUH, REGUP e às fontes de documentos de alteração onde esses campos estiverem disponíveis.
- Filtro de documentos: revise o predicado de tipo de documento de fatura e o predicado de tipo de documento de pagamento. A consulta inclui exemplos comuns, mas os tipos de documento são configuráveis e devem estar alinhados ao sistema de destino.
- Faturas estacionadas: confirme como o status de documento estacionado é representado em VBKPF ou BKPF. A consulta usa um predicado configurável de status estacionado porque a codificação pode variar conforme a versão e a implementação.
- Alterações de pagamento: confirme a classe do objeto, o nome da tabela, os nomes dos campos e a representação dos valores para BSEG-ZLSPR e BSEG-ZTERM. O armazenamento dos documentos de alteração e os nomes dos campos devem ser verificados no sistema de destino.
- Programa de pagamentos: confirme os campos de REGUH e REGUP usados para status da proposta e da execução, data da execução, identificação da execução e vínculo com o documento contábil. A configuração local do programa de pagamentos pode afetar os valores de status disponíveis.
- Performance: restrinja o intervalo de datas e os códigos de empresa, selecione apenas as colunas necessárias e execute os filtros específicos da fonte antes das junções. Para grandes volumes de dados, materialize subconjuntos filtrados das fontes ou use uma Calculation View ou um schema de extração HANA aprovado.
- Autorizações: o acesso necessário inclui autorização de leitura aos objetos do schema SAP HANA relevantes e a quaisquer visões que exponham dados contábeis, do programa de pagamentos e de documentos de alteração. Coordene com as equipes de segurança SAP e governança de dados.
- Pré-requisitos funcionais: as funcionalidades relevantes de Financial Accounting, Contas a Pagar, programa de pagamentos e documentos de alteração devem estar ativas e preenchidas. Se uma tabela de origem não for usada na implementação, configure uma substituição aprovada com base no desenho do sistema.
- Tratamento de timestamps: BKPF e BSEG normalmente fornecem datas e horas em campos separados. A consulta os combina em um timestamp. Confirme o fuso horário do sistema de origem e aplique a conversão necessária antes do upload no ProcessMind.
- Proteção de dados: restrinja os dados de fornecedores e contábeis ao escopo aprovado e aplique as políticas da organização de retenção, mascaramento e acesso.
a Consulta de exemplo sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Pronto para começar?
Transforme seus dados financeiros em insights acionáveis e comece a otimizar seus ciclos de pagamento hoje. Nossa equipe está pronta para apoiar você em cada etapa da sua jornada de Process Mining.
Otimize o processamento de pagamentos de contas a pagar no SAP S/4HANA
Elimine gargalos e reduza seu tempo de ciclo em 30%.
Não é necessário cartão de crédito. Configuração em 5 minutos.