Seu Template de Dados de Faturamento e Cobrança
Seu Template de Dados de Faturamento e Cobrança
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientações de extração para o SAP S/4HANA
Atributos de Faturamento e Cobrança (O2C)
| Nome | Descrição | ||
|---|---|---|---|
| Número da fatura InvoiceNumber | O identificador único de um documento de faturamento, servindo como o case identifier principal do processo. | ||
| Descrição O Número da Fatura (Documento de Faturamento no SAP) identifica cada transação de forma única. Ele é a chave central que vincula todas as atividades, da criação ao recebimento. No Process Mining, este atributo é o case identifier. Todos os eventos com o mesmo número são agrupados em uma única instância, permitindo a análise completa do ciclo de vida, rastreio de tempos e identificação de desvios. Por que é importante É o identificador fundamental que conecta todas as atividades de faturamento relacionadas em um único caso, tornando possível a análise do processo de ponta a ponta. Onde obter Tabela SAP: VBRK, Campo: VBELN Exemplos 900012349000567890009012 | |||
| Nome da Atividade ActivityName | O nome da atividade ou evento ocorrido no processo de faturamento, como 'Fatura Gerada' ou 'Pagamento Recebido'. | ||
| Descrição O Nome da Atividade descreve uma etapa ou marco no ciclo de faturamento. Essas atividades vêm de dados do SAP, como códigos de transação ou mudanças de status, para criar um fluxo sequencial. Analisar a sequência e frequência dessas atividades é a base do Process Mining. Isso ajuda a visualizar o mapa do processo, descobrir variantes, identificar gargalos e medir atividades que não agregam valor, como retrabalho ou cancelamentos. Por que é importante Este atributo define as etapas do processo, permitindo a visualização de mapas, análise de fluxo, variações e gargalos. Onde obter Derivado de várias fontes, incluindo códigos de transação (SY-TCODE), status de documentos de modificação (tabelas CDHDR/CDPOS) ou logs de workflow de negócios (ex: SWW_WI2OBJ). Exemplos Fatura geradaFatura Lançada na ContabilidadePagamento do cliente recebidoFatura Cancelada | |||
| Tempo do Evento EventTime | O timestamp preciso que indica quando uma atividade ou evento ocorreu. | ||
| Descrição O Event Time fornece a data e a hora de cada atividade, formando a espinha dorsal cronológica do processo. Esse timestamp é crucial para calcular durações, tempos de ciclo e tempos de espera entre as diferentes etapas do faturamento. Na análise, o Event Time é usado para ordenar as atividades sequencialmente, calcular KPIs como DSO e Tempo do Ciclo de Geração de Faturas, além de identificar gargalos temporais. Ele permite uma visão dinâmica do processo, mostrando como o desempenho muda ao longo do tempo e quanto tempo leva cada estágio do ciclo de faturamento. Por que é importante Fornece a sequência cronológica dos eventos, essencial para o cálculo de todas as métricas baseadas no tempo, como tempos de ciclo e durações. Onde obter Extraído de vários campos de data e hora dependendo da atividade, como data e hora de criação (VBRK-ERDAT, VBRK-ERZET), timestamps de modificação (CDHDR-UDATE, CDHDR-UTIME) ou data de lançamento (BKPF-BUDAT). Exemplos 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Data da Fatura InvoiceDate | A data oficial em que a fatura foi emitida para o cliente. | ||
| Descrição A Data da Fatura (ou data de faturamento no SAP) é o ponto de partida para cálculos financeiros. É a partir dela que se definem condições de pagamento, vencimentos e o aging do contas a receber. Esta data é a base para calcular o KPI de DSO e relatórios de aging, ferramentas essenciais para gerir o fluxo de caixa e cobranças. Por que é importante É a data principal para cálculos financeiros, servindo como ponto de partida para DSO, datas de vencimento e análise de aging de faturas. Onde obter Tabela SAP: VBRK, Campo: FKDAT Exemplos 2023-03-202023-04-012023-05-18 | |||
| Data de Vencimento do Pagamento PaymentDueDate | A data limite para o cliente efetuar o pagamento da fatura. | ||
| Descrição A Data de Vencimento é calculada com base na data da fatura e nos termos acordados. É o prazo limite para o recebimento sem que a fatura fique em atraso. Este atributo é vital para monitorar a eficácia da cobrança e prever o fluxo de caixa. É usado no KPI de Pagamento em Dia (On-Time Payment) e em relatórios de aging. Por que é importante Define o prazo limite para o pagamento do cliente, sendo crucial para o cálculo das taxas de pagamento em dia e para a gestão de contas a receber. Onde obter Esta data não é armazenada diretamente, mas calculada com base na Data da Fatura (VBRK-FKDAT) e na chave de Condição de Pagamento (VBRK-ZTERM). Exemplos 2023-04-192023-05-012023-06-17 | |||
| End Time EndTime | O timestamp preciso que indica quando uma atividade ou evento foi concluído. | ||
| Descrição O End Time marca a conclusão de uma atividade. No Process Mining, ele é vital para calcular o Processing Time. Ao subtrair o Start Time do End Time, medimos a duração de cada etapa, o que é crucial para identificar gargalos, como atrasos na fase de aprovação de faturas. Por que é importante Permite o cálculo da duração exata (tempo de processamento) de cada atividade, o que é fundamental para a análise de gargalos. Onde obter Atributo derivado para Process Mining. Geralmente calculado como o StartTime do próximo evento na sequência. Algumas tabelas podem registrar horários de conclusão específicos. Exemplos 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Nome do Cliente CustomerName | O nome do cliente para o qual a fatura foi emitida. | ||
| Descrição Este atributo identifica a razão social do cliente faturado, extraída dos dados mestres no SAP. Analisar por cliente revela padrões específicos: quais sempre pagam com atraso ou geram mais disputas. Isso permite uma gestão de cobrança personalizada e estratégias de relacionamento mais eficazes. Por que é importante Permite uma análise centrada no cliente, ajudando a identificar comportamentos de pagamento, frequência de disputas e ineficiências de processo para contas específicas. Onde obter Extraído da tabela de dados mestres de clientes KNA1 (Campo: NAME1), vinculado via ID do Pagador no cabeçalho da fatura (VBRK-KUNRG). Exemplos Springfield Power PlantKwik-E-MartCyberdyne Systems | |||
| Nome do Utilizador UserName | O ID de usuário do funcionário que executou a atividade. | ||
| Descrição Este atributo captura o ID de usuário SAP responsável por um evento. Ele vincula as etapas do processo às pessoas ou equipes. Analisar por Usuário ajuda a identificar altas performances, necessidades de treinamento ou desequilíbrios na carga de trabalho. Também é vital para conformidade, mostrando quem realizou atividades críticas. Por que é importante Vincula as atividades do processo a usuários específicos, permitindo a análise de carga de trabalho, desempenho e conformidade em nível individual ou de equipe. Onde obter Para eventos de criação, o dado está em VBRK-ERNAM. Para mudanças subsequentes, encontra-se nas tabelas de histórico de modificações, como CDHDR-USERNAME, ou nos logs de workflow. Exemplos CBURNSHSIMPSONLLEONARD | |||
| Região Region | A região geográfica do cliente. | ||
| Descrição O atributo Região indica a área geográfica do cliente. Esses dados geralmente vêm do mestre de clientes. Este atributo é fundamental para o dashboard de Performance de Faturamento Regional. Ele permite fazer o benchmarking de métricas como tempo de ciclo e DSO entre regiões, revelando diferenças de eficiência e ajudando a padronizar as melhores práticas. Por que é importante Permite comparar o desempenho do faturamento em diferentes áreas geográficas, ajudando a identificar disparidades regionais e padronizar processos. Onde obter Extraído da tabela de dados mestres de clientes KNA1 (Campo: REGIO), vinculado via ID do Pagador no cabeçalho da fatura (VBRK-KUNRG). Exemplos CANYTXBA | |||
| Valor da Fatura InvoiceAmount | O valor líquido total da fatura. | ||
| Descrição Representa o valor total dos bens ou serviços faturados, sem impostos. É um dado financeiro básico para cada caso. O valor da fatura permite segmentar o processo por importância, verificando se faturas de alto valor sofrem mais atrasos. Também é a base para o faturamento e cálculo do contas a receber. Por que é importante Quantifica o valor financeiro de cada fatura, permitindo análises baseadas em valor, priorização de cobranças e avaliação de impacto financeiro. Onde obter Tabela SAP: VBRK, Campo: NETWR Exemplos 1500.0025000.50125.75 | |||
| Código da Empresa CompanyCode | A unidade organizacional onde a transação financeira é registrada. | ||
| Descrição A Empresa (Company Code) é a unidade organizacional básica no SAP Financials, representando uma entidade legal independente. Cada documento de faturamento é atribuído a uma empresa. Analisar por Empresa é essencial para comparar performance, métricas como o DSO e conformidade entre diferentes entidades legais em um grupo. Por que é importante Permite que a análise do processo seja segmentada por entidade legal, possibilitando a comparação de desempenho e a consolidação financeira em toda a organização. Onde obter Tabela SAP: VBRK, Campo: BUKRS Exemplos 10002000US01 | |||
| Condições de Pagamento PaymentTerms | O código que define as condições de pagamento, como o prazo permitido para quitação. | ||
| Descrição As Condições de Pagamento (Payment Terms) são regras acordadas com o cliente que definem o vencimento de uma fatura. Exemplos comuns incluem 'Net 30' (pagamento em 30 dias) ou '2/10 Net 30' (2% de desconto se pago em 10 dias). Analisar essas condições ajuda a avaliar sua eficácia. Ao correlacionar diferentes prazos com o tempo real de recebimento, sua empresa pode identificar quais termos incentivam pagamentos rápidos e otimizá-los para melhorar o fluxo de caixa. Por que é importante Define o cronograma de pagamento acordado, permitindo analisar quais condições são mais eficazes para garantir o pagamento pontual dos clientes. Onde obter Tabela SAP: VBRK, Campo: ZTERM Exemplos Z030Z060ZB60 | |||
| É pago no prazo IsPaidOnTime | Um indicador booleano que sinaliza se a fatura foi paga até a data de vencimento ou antes. | ||
| Descrição Atributo calculado que compara a data real com o vencimento. Resulta em 'true' se pago em dia e 'false' se atrasado. Esta flag simplifica o KPI de Taxa de Pagamento em Dia (On-Time Payment). Permite filtrar e analisar faturas atrasadas, ajudando a encontrar padrões em clientes, regiões ou condições de pagamento que causam inadimplência. Por que é importante Simplifica a medição de desempenho ao sinalizar claramente cada fatura como 'no prazo' ou 'em atraso', suportando diretamente o KPI de Taxa de Pagamento em Dia. Onde obter Campo calculado. A lógica compara o timestamp de 'Pagamento Recebido' com o valor do atributo 'PaymentDueDate'. Exemplos verdadeirofalse | |||
| Moeda Currency | O código da moeda para o valor da fatura. | ||
| Descrição Especifica a moeda da fatura (USD, BRL, EUR, etc.), fornecendo contexto aos valores. Em organizações globais, a moeda é essencial para análises financeiras corretas. Ela permite consolidar dados convertendo valores para uma moeda comum de relatório e comparar a performance entre regiões. Por que é importante Fornece contexto essencial para todos os valores monetários, garantindo análises financeiras e relatórios precisos, especialmente em operações multinacionais. Onde obter Tabela SAP: VBRK, Campo: WAERK Exemplos USDEURGBP | |||
| Motivo da Disputa CustomerDisputeReason | O motivo fornecido pelo cliente para contestar uma fatura. | ||
| Descrição Quando um cliente contesta uma fatura, o motivo é registrado (erros de preço, quantidade incorreta, etc.). Essas informações ficam no SAP Dispute Management ou em notas de texto. Analisar esses motivos é a base para o KPI de Taxa de Erro de Faturamento. Isso ajuda a identificar causas raiz, corrigir falhas em processos anteriores, melhorar a qualidade das faturas e aumentar a satisfação do cliente. Por que é importante Explica por que as faturas estão sendo contestadas, fornecendo insights diretos sobre as causas raiz dos erros de faturamento e da insatisfação do cliente. Onde obter Se o SAP Dispute Management estiver em uso, essa informação pode ser encontrada em tabelas como a UDM_DISPUTE. Caso contrário, pode ser derivada de códigos de motivo em documentos relacionados ou campos de texto. Exemplos Preço IncorretoDivergência de QuantidadeMercadoria Danificada Recebida | |||
| Motivo da Nota de Crédito CreditMemoReason | O código do motivo pelo qual uma nota de crédito foi emitida. | ||
| Descrição Quando uma fatura está incorreta e exige crédito, atribui-se um motivo à nota de crédito. Isso ajuda a categorizar a origem dos erros. Este atributo alimenta o KPI de Taxa de Erro de Faturamento. Ao analisar os motivos das notas de crédito, a empresa identifica erros comuns, como falhas de preço ou devoluções, impulsionando melhorias que reduzem a necessidade de correções financeiras e retrabalho. Por que é importante Categoriza os motivos de emissão de crédito, ajudando a identificar as fontes mais frequentes de erros de faturamento e impulsionando melhorias de qualidade. Onde obter Tabela SAP: VBRK, Campo: AUGRU (Motivo da Ordem). Usado em solicitações de notas de crédito/débito que são faturadas. Exemplos 001 - Diferença de Preço002 - Baixa Qualidade005 - Devolução de Cliente | |||
| Número do pedido de venda SalesOrderNumber | O identificador da ordem de venda original que gerou a fatura. | ||
| Descrição O Número da Ordem de Venda vincula a fatura às atividades de vendas anteriores. Uma única ordem pode gerar várias faturas, e este link fornece o fluxo completo. Este atributo é crítico para uma análise real de ponta a ponta. Ele conecta problemas de faturamento com suas causas raiz na criação do pedido, ajudando a calcular o tempo total desde o atendimento do pedido até a geração da fatura. Por que é importante Vincula a fatura ao pedido de venda original, permitindo uma visão mais ampla e de ponta a ponta do processo de Order-to-Cash além do faturamento. Onde obter Tabela SAP: VBRP (Dados de Item de Faturamento), Campo: AUBEL Exemplos 100001231000045610000789 | |||
| Sistema de Origem SourceSystem | Identifica o sistema de origem específico de onde os dados foram extraídos. | ||
| Descrição Especifica a origem dos dados, útil em ambientes com várias instâncias SAP. Geralmente inclui o ID do sistema e o mandante. Ajuda a diferenciar a performance entre sistemas, garantindo a linhagem dos dados e contexto quando informações de múltiplas fontes são combinadas. Por que é importante Fornece um contexto crucial sobre a origem dos dados, garantindo clareza em ambientes de múltiplos sistemas e apoiando a governança de dados. Onde obter Geralmente um valor estático definido na extração, combinando o ID do sistema (SY-SYSID) e o mandante (SY-MANDT). Exemplos S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Status do Pagamento PaymentStatus | O status atual do pagamento da fatura (Aberto, Pago ou Vencido). | ||
| Descrição O Status de Pagamento fornece um instantâneo de onde a fatura está no ciclo de vida da cobrança. Não é um campo único no SAP, mas derivado da verificação do status de compensação do documento contábil correspondente. Este atributo é essencial para o dashboard de Aging de Faturas Pendentes. Ele permite segmentar todas as faturas abertas por status e vencimento, ajudando a equipe de cobrança a priorizar esforços. Rastrear as transições entre status também é uma forma de monitorar o próprio processo de cobrança. Por que é importante Oferece uma visão clara e rápida do status de cobrança de uma fatura, o que é vital para gerenciar recebíveis e priorizar os esforços de cobrança. Onde obter Derivado da verificação do status de compensação do documento contábil (VBRK-BELNR) em tabelas financeiras como BSID (itens abertos) e BSAD (itens compensados). Exemplos AbertoPagoVencidoPago Parcialmente | |||
| Tempo de Processamento ProcessingTime | A duração de uma atividade, calculada do início ao fim. | ||
| Descrição O Processing Time mede o tempo gasto trabalhando ativamente em uma tarefa, ignorando o tempo de espera entre elas. É calculado pela diferença entre o End Time e o Start Time de uma atividade. Essa métrica é fundamental para a análise de performance. Ela é usada em dashboards como o de Análise de Gargalos na Aprovação de Faturas para quantificar a duração de etapas específicas. Tempos altos podem indicar ineficiências ou necessidade de automação. Por que é importante Mede a duração ativa das etapas do processo, ajudando a identificar atividades ineficientes que são fortes candidatas à otimização ou automação. Onde obter Métrica calculada, derivada da subtração de 'StartTime' do 'EndTime' durante o processo de transformação de dados. Exemplos PT30MPT5MPT1H15M | |||
| Tipo de Documento de Faturamento BillingDocumentType | Um código que classifica o documento de faturamento, como fatura, nota de crédito ou cancelamento. | ||
| Descrição O Tipo de Documento de Faturamento é um campo essencial que categoriza as transações. Ele controla como o documento é processado, incluindo intervalos de numeração e regras contábeis. Este atributo permite filtrar o processo para analisar transações específicas. Por exemplo, você pode criar uma visão só para notas de crédito para entender correções financeiras, ou analisar faturas padrão separadamente de cancelamentos. Por que é importante Classifica as transações, permitindo uma análise focada em fluxos de documentos específicos, como faturas padrão, notas de crédito ou cancelamentos. Onde obter Tabela SAP: VBRK, Campo: FKART Exemplos F2G2S1L2 | |||
| Última Atualização de Dados LastDataUpdate | O timestamp indicando quando os dados deste evento foram extraídos ou atualizados pela última vez. | ||
| Descrição Grava a data e hora da última extração do sistema de origem. É um metadado crítico para entender quão atuais são os dados analisados. Essa informação serve para validar a análise e gerenciar cronogramas de atualização, garantindo que as decisões sejam tomadas com base em dados recentes. Por que é importante Indica o quão recentes são os dados, o que é vital para confiar na análise e entender sua relevância para o estado atual das operações. Onde obter Timestamp gerado e atribuído a cada registro durante o processo de extração e carga (ETL). Exemplos 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
Atividades de Faturamento e Cobrança (O2C)
| Atividade | Descrição | ||
|---|---|---|---|
| Caixa Aplicado/Conciliado | Representa o momento em que o pagamento recebido é conciliado e usado para compensar o item em aberto no contas a receber. Esta atividade encerra a transação financeiramente. | ||
| Por que é importante Mede a eficiência do processo de aplicação de caixa. Atrasos aqui podem distorcer o estado real das contas dos clientes e criar trabalho desnecessário para as equipes de cobrança. Onde obter Capturado pela data de compensação (BSEG-AUGDT) no item do documento contábil da fatura. Esta data é preenchida quando um documento de compensação quita o item. Captura Capturado do campo de data de compensação (AUGDT) na tabela BSEG/ACDOCA para o item da fatura. Tipo de evento explicit | |||
| Fatura Encerrada | Significa o estado final de uma fatura paga. É funcionalmente o mesmo que 'Pagamento Conciliado' e indica que o processo desta fatura foi concluído. | ||
| Por que é importante Serve como o principal evento final do 'caminho feliz' (happy path). Medir o tempo de ciclo até aqui oferece uma visão completa do ciclo de vida de faturamento ponta a ponta. Onde obter Inferido a partir do status do item de cliente no documento contábil. Um item é encerrado ou 'compensado' quando os campos de data de compensação (BSEG-AUGDT) e documento de compensação (BSEG-AUGBL) estão preenchidos. Captura Inferido a partir do preenchimento da data de compensação (AUGDT) na tabela BSEG/ACDOCA para o item da fatura. Tipo de evento inferred | |||
| Fatura gerada | Esta atividade marca a criação do documento de faturamento no sistema. É capturada quando um usuário executa a transação VF01 ou via job em background, gerando uma nova entrada na tabela de cabeçalho. | ||
| Por que é importante O evento inicial do processo de faturamento. Analisar o tempo desde o atendimento do pedido até aqui é vital para medir o Ciclo de Geração de Faturas e identificar atrasos iniciais. Onde obter Registrado na tabela SAP S/4HANA VBRK (Documento de Faturamento: Cabeçalho) na criação. A data (VBRK-ERDAT) e hora (VBRK-ERZET) servem como timestamp. Captura O evento é capturado a partir do timestamp de criação do registro do documento de faturamento na tabela VBRK. Tipo de evento explicit | |||
| Fatura Lançada na Contabilidade | Representa o lançamento bem-sucedido do documento de faturamento no módulo contábil. É o marco onde a fatura se torna oficialmente um item de contas a receber no livro razão. | ||
| Por que é importante Esta atividade confirma a fatura como um documento contábil legal. O tempo entre geração e lançamento é um KPI chave que reflete a eficiência do processamento interno. Onde obter Capturado quando o documento contábil é criado. A fatura (VBRK-VBELN) é vinculada ao documento contábil via VBRK-BELNR, e a data de lançamento é BKPF-BUDAT. Captura Capturado a partir da data de lançamento (BUDAT) do documento contábil na tabela BKPF vinculado ao documento de faturamento. Tipo de evento explicit | |||
| Pagamento do cliente recebido | Esta atividade marca o lançamento de um pagamento recebido no sistema financeiro. O valor pode ainda não ter sido compensado em uma fatura específica, mas os fundos já foram registrados. | ||
| Por que é importante Um marco crucial para calcular o Days Sales Outstanding (DSO). Significa que o valor foi recebido, mesmo que a conciliação ainda esteja pendente. Onde obter Capturado a partir da data de lançamento (BKPF-BUDAT) do documento de pagamento do cliente (geralmente tipo de documento 'DZ' na tabela BKPF). Captura O evento baseia-se na criação do documento de pagamento na BKPF/BSEG. Tipo de evento explicit | |||
| Disputa de Cliente Aberta | Ocorre quando um cliente contesta uma fatura e isso é registrado formalmente. Exige o uso do módulo SAP Dispute Management. | ||
| Por que é importante Destaca problemas na precisão do faturamento, qualidade do produto ou entrega de serviços que levam a atrasos no pagamento. Analisar os motivos das disputas ajuda a tratar as causas raiz e melhorar a satisfação do cliente. Onde obter Registrado na criação de um caso de disputa nas tabelas de Dispute Management (ex: UDM_CASE), vinculado ao item do documento contábil. Captura Capturado a partir do timestamp de criação do registro de caso de disputa vinculado à fatura. Tipo de evento explicit | |||
| Fatura Cancelada | Ocorre quando uma fatura criada anteriormente é cancelada, o que geralmente envolve a criação de um documento de cancelamento correspondente. Isso estorna a fatura original e seu impacto contábil. | ||
| Por que é importante Indica retrabalho, correções ou erros de faturamento. Uma alta frequência de cancelamentos aponta para problemas significativos nas etapas anteriores, como na entrada do pedido ou na configuração do faturamento. Onde obter Capturado quando um documento de faturamento de cancelamento é criado (ex: tipo de documento 'S1'). Este novo documento na VBRK referenciará o número da fatura original no campo VBRK-SFAKN. Captura O evento é capturado a partir da data de criação do documento de cancelamento na VBRK que referencia a fatura original. Tipo de evento explicit | |||
| Fatura enviada ao cliente | Esta atividade marca quando a fatura foi enviada ao cliente (impressão, e-mail ou EDI). O mecanismo de captura depende da configuração de output management no SAP. | ||
| Por que é importante O início oficial do prazo de pagamento para o cliente. Atrasos no envio da fatura impactam diretamente o DSO e o fluxo de caixa. Onde obter Pode ser registrado explicitamente nas tabelas de controle de saída (como a NAST para métodos mais antigos ou seu equivalente no S/4HANA). Se não for registrado, geralmente infere-se que ocorre ao mesmo tempo que 'Invoice Posted To Accounting'. Captura Verifique os logs de processamento nas tabelas de gerenciamento de saída para um timestamp associado ao tipo de saída da fatura. Tipo de evento explicit | |||
| Lançamento de Fatura Bloqueado | Ocorre se uma fatura é criada mas fica bloqueada para lançamento contábil por motivos como verificações de crédito ou inconsistências. Status inferido do campo de status de faturamento. | ||
| Por que é importante Identifica gargalos onde as faturas são criadas, mas não liberadas imediatamente para o financeiro, atrasando todo o ciclo de recebimento. É um indicador-chave de problemas na qualidade dos dados ou na gestão de crédito. Onde obter Inferido do campo de status de lançamento na tabela de cabeçalho do documento de faturamento (VBRK-RFBSK). Um status como 'A' indica que o documento está bloqueado para envio ao financeiro (FI). Captura Inferido ao verificar o valor do campo de status de lançamento (VBRK-RFBSK) imediatamente após a geração da fatura. Tipo de evento inferred | |||
| Lembrete de Pagamento Enviado | Representa o envio de um lembrete de pagamento ou aviso de cobrança (dunning) para uma fatura vencida. É um evento gerado pelo procedimento automático de cobrança. | ||
| Por que é importante Permite analisar a eficácia do processo de cobrança (dunning). Ajuda a determinar se os lembretes aceleram os pagamentos e quais níveis de cobrança são mais impactantes. Onde obter Registrado nas tabelas de histórico de dunning (MAHNV, MHND) quando a execução de cobrança (Transação F150) ocorre para o item em aberto. Captura Capturado a partir da data de execução do aviso de cobrança registrado nas tabelas de histórico de dunning. Tipo de evento explicit | |||
| Nota de Crédito Criada | Representa a criação de uma nota de crédito para corrigir cobranças a maior ou devoluções de mercadorias. Geralmente está vinculada a uma fatura original. | ||
| Por que é importante Destaca problemas que resultam em ajustes financeiros após o faturamento. Analisar as notas de crédito pode revelar erros de preço, problemas no produto ou outras causas raiz de perda de receita. Onde obter Criado explicitamente como um novo documento de faturamento (na VBRK) com um tipo de faturamento específico para notas de crédito (ex: 'G2'). Frequentemente referencia o pedido de venda ou fatura original. Captura Capturado a partir da criação de um documento de faturamento na VBRK com um tipo de faturamento de nota de crédito. Tipo de evento explicit | |||
| Retrabalho de Faturamento Identificado | Um evento calculado que identifica um loop de retrabalho onde uma fatura foi cancelada e uma nova foi gerada para o mesmo pedido de venda. Não se trata de uma única transação, mas de um padrão de eventos. | ||
| Por que é importante Suporta diretamente o KPI de Taxa de Retrabalho de Faturamento ao quantificar instâncias de correção. Isso ajuda a identificar ineficiências e medir o custo da baixa qualidade no processo. Onde obter Padrão calculado ao identificar um evento de 'Fatura Cancelada' seguido por uma nova 'Fatura Gerada', ambos vinculados ao mesmo documento de origem (ex: ordem de venda). Captura Derivado da detecção de uma sequência de 'Invoice Cancelled' e 'Invoice Generated' para a mesma referência de pedido de venda. Tipo de evento calculated | |||
| Vencimento da Fatura Atingido | Um evento calculado que representa a data em que o pagamento da fatura deve ocorrer oficialmente, de acordo com as condições acordadas. Não é um evento transacional, mas derivado dos dados da fatura. | ||
| Por que é importante Fornece a base crítica para medir a performance de pagamentos em dia e analisar o comportamento do cliente, distinguindo o que foi pago no prazo do que está vencido. Onde obter Calculado com base na data base de pagamento (BSEG-ZFBDT) e nas condições de pagamento armazenadas no item da conta do cliente do documento contábil. Captura Derivado da soma dos dias da condição de pagamento à data base de pagamento encontrada no item do documento contábil (BSEG). Tipo de evento calculated | |||
Guias de Extração
Etapas
- Pré-requisitos: Certifique-se de ter uma conta de usuário no SAP S/4HANA com as autorizações necessárias para consultar as Core Data Services (CDS) views. Especificamente, você precisa de acesso de leitura para views como I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase e I_DunningHistory.
- Acessar Ferramenta de Extração: Faça o login no seu sistema SAP S/4HANA. Você pode usar várias ferramentas para executar queries SQL contra CDS views, como SAP HANA Studio, DBeaver conectado via SAP HANA client ou o plugin SAP Analysis for Microsoft Excel. Para este guia, assumiremos um cliente SQL padrão.
- Identificar Parâmetros do Sistema: Antes de executar a query, identifique os Company Codes específicos e o intervalo de datas relevante para sua análise. Recomendamos começar com um escopo limitado, como os últimos 3 a 6 meses, para garantir tempos de execução gerenciáveis.
- Preparar a Query SQL: Copie a query SQL completa fornecida na seção 'query' deste documento para o seu cliente SQL.
- Personalizar Marcadores: Modifique os valores dos marcadores na query. Substitua
'YYYY-MM-DD'pelas datas de início e fim desejadas. Substitua'XXXX'pelo(s) seu(s) Company Code(s) de destino. Você também pode precisar ajustar o marcador para tipos de documento de nota de crédito, por exemplo,'G2', com base na configuração do seu sistema. - Executar a Query: Execute a query SQL modificada no banco de dados SAP S/4HANA. O tempo de execução variará dependendo do volume de dados no intervalo selecionado.
- Revisar os Resultados: Assim que a query terminar, revise a saída. O conjunto de resultados deve ser uma tabela plana onde cada linha representa uma única atividade no processo de faturamento. Este é o seu log de eventos.
- Transformação de Dados (se necessário): A query foi projetada para produzir um formato de log de eventos limpo. No entanto, verifique o formato do timestamp para garantir que seja compatível com sua ferramenta de Process Mining. A query usa
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpara converter para um timestamp UTC padrão, que deve ser amplamente compatível. - Exportar o Log de Eventos: Exporte o resultado completo do seu cliente SQL para um arquivo CSV. Certifique-se de que o arquivo esteja codificado em UTF-8 para evitar problemas de caracteres.
- Upload para o ProcessMind: Faça o upload do arquivo CSV gerado na plataforma ProcessMind, mapeando as colunas do arquivo (como InvoiceNumber, ActivityName e EventTime) para os campos correspondentes na ferramenta.
Configuração
- Intervalo de Datas: Defina as datas de início e fim na cláusula
WHEREda Common Table Expression (CTE) inicial. Recomendamos um intervalo de 3 a 6 meses para a análise inicial para equilibrar o volume de dados e a performance. O filtro é aplicado no campoBillingDocumentDate. - Código da Empresa (Company Code): Filtre por um ou mais valores de
CompanyCodepara restringir a extração às entidades legais relevantes. Este é um filtro essencial para gerenciar o escopo dos dados. - Tipos de Documento: A query inclui a lógica para identificar notas de crédito baseada no
BillingDocumentType. Você deve configurar o marcador, por exemplo,('G2', 'CR'), com os tipos de documentos específicos usados para notas de crédito na sua organização. - Pré-requisitos: O acesso às CDS views subjacentes é obrigatório. Isso requer funções e autorizações específicas atribuídas pela sua equipe de segurança SAP. Além disso, para atividades como 'Customer Dispute Opened' ou 'Payment Reminder Issued', os respectivos módulos SAP (SAP Dispute Management e SAP Financials Dunning) devem estar ativos no seu sistema.
- Performance: A query utiliza diversos joins e unions. Para conjuntos de dados muito grandes (como vários anos de informação), considere executá-la fora do horário de pico ou aplicar filtros mais restritivos para limitar a carga inicial.
a Consulta de Exemplo sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;Etapas
- Pré-requisitos: Certifique-se de ter uma conta de usuário no SAP S/4HANA com as autorizações necessárias para consultar as Core Data Services (CDS) views. Especificamente, você precisa de acesso de leitura para views como I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase e I_DunningHistory.
- Acessar Ferramenta de Extração: Faça o login no seu sistema SAP S/4HANA. Você pode usar várias ferramentas para executar queries SQL contra CDS views, como SAP HANA Studio, DBeaver conectado via SAP HANA client ou o plugin SAP Analysis for Microsoft Excel. Para este guia, assumiremos um cliente SQL padrão.
- Identificar Parâmetros do Sistema: Antes de executar a query, identifique os Company Codes específicos e o intervalo de datas relevante para sua análise. Recomendamos começar com um escopo limitado, como os últimos 3 a 6 meses, para garantir tempos de execução gerenciáveis.
- Preparar a Query SQL: Copie a query SQL completa fornecida na seção 'query' deste documento para o seu cliente SQL.
- Personalizar Marcadores: Modifique os valores dos marcadores na query. Substitua
'YYYY-MM-DD'pelas datas de início e fim desejadas. Substitua'XXXX'pelo(s) seu(s) Company Code(s) de destino. Você também pode precisar ajustar o marcador para tipos de documento de nota de crédito, por exemplo,'G2', com base na configuração do seu sistema. - Executar a Query: Execute a query SQL modificada no banco de dados SAP S/4HANA. O tempo de execução variará dependendo do volume de dados no intervalo selecionado.
- Revisar os Resultados: Assim que a query terminar, revise a saída. O conjunto de resultados deve ser uma tabela plana onde cada linha representa uma única atividade no processo de faturamento. Este é o seu log de eventos.
- Transformação de Dados (se necessário): A query foi projetada para produzir um formato de log de eventos limpo. No entanto, verifique o formato do timestamp para garantir que seja compatível com sua ferramenta de Process Mining. A query usa
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpara converter para um timestamp UTC padrão, que deve ser amplamente compatível. - Exportar o Log de Eventos: Exporte o resultado completo do seu cliente SQL para um arquivo CSV. Certifique-se de que o arquivo esteja codificado em UTF-8 para evitar problemas de caracteres.
- Upload para o ProcessMind: Faça o upload do arquivo CSV gerado na plataforma ProcessMind, mapeando as colunas do arquivo (como InvoiceNumber, ActivityName e EventTime) para os campos correspondentes na ferramenta.
Configuração
- Intervalo de Datas: Defina as datas de início e fim na cláusula
WHEREda Common Table Expression (CTE) inicial. Recomendamos um intervalo de 3 a 6 meses para a análise inicial para equilibrar o volume de dados e a performance. O filtro é aplicado no campoBillingDocumentDate. - Código da Empresa (Company Code): Filtre por um ou mais valores de
CompanyCodepara restringir a extração às entidades legais relevantes. Este é um filtro essencial para gerenciar o escopo dos dados. - Tipos de Documento: A query inclui a lógica para identificar notas de crédito baseada no
BillingDocumentType. Você deve configurar o marcador, por exemplo,('G2', 'CR'), com os tipos de documentos específicos usados para notas de crédito na sua organização. - Pré-requisitos: O acesso às CDS views subjacentes é obrigatório. Isso requer funções e autorizações específicas atribuídas pela sua equipe de segurança SAP. Além disso, para atividades como 'Customer Dispute Opened' ou 'Payment Reminder Issued', os respectivos módulos SAP (SAP Dispute Management e SAP Financials Dunning) devem estar ativos no seu sistema.
- Performance: A query utiliza diversos joins e unions. Para conjuntos de dados muito grandes (como vários anos de informação), considere executá-la fora do horário de pico ou aplicar filtros mais restritivos para limitar a carga inicial.
a Consulta de Exemplo sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;