Seu Template de dados de Order to Cash - Faturamento e emissão de faturas
Seu Template de dados de Order to Cash - Faturamento e emissão de faturas
- Atributos recomendados para coleta
- Principais atividades para acompanhar
- Orientações para extração no SAP S/4HANA
Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento
| Nome | Descrição | ||
|---|---|---|---|
| Número da Fatura InvoiceNumber | O identificador exclusivo de um documento de faturamento, que funciona como o identificador principal do caso no processo de emissão de faturas. | ||
| Descrição O Número da Fatura, conhecido como Número do Documento de Faturamento no SAP, identifica exclusivamente cada transação de faturamento. Ele funciona como a chave central que conecta todas as atividades relacionadas, desde a criação e o lançamento da fatura até o recebimento e a reconciliação do pagamento. No Process Mining, esse atributo é essencial para a correlação de casos. Todos os eventos que compartilham o mesmo Número da Fatura são agrupados em uma única instância do processo, permitindo uma análise completa, de ponta a ponta, do ciclo de vida de cada fatura. Isso permite acompanhar tempos de ciclo, identificar desvios e analisar a jornada de cada fatura. Por que isso importa É 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 | |||
| Horário do Evento EventTime | O registro preciso de data e hora que indica quando uma atividade ou evento ocorreu. | ||
| Descrição O Horário do Evento fornece a data e a hora de cada atividade, formando a base cronológica do processo. Esse registro de data e hora é essencial para calcular durações, tempos de ciclo e tempos de espera entre diferentes etapas do processo de faturamento. Na análise, o Horário do Evento é usado para ordenar as atividades em sequência, calcular indicadores-chave de performance, como Dias de Vendas Pendentes e Tempo de Ciclo de Geração da Fatura, e identificar gargalos relacionados ao tempo. Ele permite uma visão dinâmica do processo, mostrando como a performance muda ao longo do tempo e quanto dura cada etapa do ciclo de faturamento. Por que isso importa Ele fornece a sequência cronológica dos eventos, essencial para calcular todas as métricas baseadas em 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), registros de data e hora de alterações (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 | |||
| Nome da Atividade ActivityName | O nome da atividade ou do evento de negócio ocorrido no processo de faturamento, como 'Fatura Gerada' ou 'Pagamento Recebido'. | ||
| Descrição O Nome da Atividade descreve uma etapa ou marco específico no ciclo de vida do faturamento. Essas atividades são derivadas de vários pontos de dados no SAP, como códigos de transação, alterações de status de documentos ou entradas específicas de log, para criar um fluxo sequencial do processo. A análise da sequência e da frequência dessas atividades é o núcleo do Process Mining. Ela ajuda a visualizar o mapa do processo, descobrir variantes comuns e raras, identificar gargalos entre as etapas e medir a frequência de atividades que não agregam valor, como retrabalho ou cancelamentos. Por que isso importa Esse atributo define as etapas do processo, permitindo visualizar mapas de processo e analisar o fluxo, as variações e os gargalos do processo. Onde obter Derivado de várias fontes, incluindo códigos de transação (SY-TCODE), status de documentos de alteração (tabelas CDHDR/CDPOS) ou logs de Workflow de negócio (por exemplo, SWW_WI2OBJ). Exemplos Fatura geradaFatura lançada na contabilidadePagamento do cliente recebidoFatura Cancelada | |||
| Data da Fatura InvoiceDate | A data oficial em que a fatura foi emitida para o cliente. | ||
| Descrição A Data da Fatura, também conhecida como data de faturamento no SAP, serve como ponto de partida para muitos cálculos financeiros. É a data a partir da qual são determinados as condições de pagamento, os vencimentos e o tempo em aberto do recebível. Essa data é um atributo essencial no nível do caso para a análise financeira. Ela é a base para calcular o KPI de Dias de Vendas Pendentes (DSO) e criar relatórios de aging de faturas em aberto, ferramentas essenciais para gerenciar o fluxo de caixa e as cobranças. Por que isso importa É a principal data para os cálculos financeiros, funcionando como ponto de partida para o DSO, as datas de vencimento e a análise de aging das faturas. Onde obter Tabela SAP: VBRK, Campo: FKDAT Exemplos 2023-03-202023-04-012023-05-18 | |||
| Data de Vencimento do Pagamento PaymentDueDate | A data até a qual o cliente deve pagar a fatura. | ||
| Descrição A Data de Vencimento do Pagamento é calculada com base na data da fatura e nas condições de pagamento acordadas. Ela representa o prazo para receber o pagamento sem que a fatura fique em atraso. Esse atributo é essencial para monitorar a eficácia das cobranças e fazer previsões de fluxo de caixa. Ele é usado diretamente no cálculo do KPI de Taxa de Pagamento no Prazo e para segmentar faturas em relatórios de aging. A análise dos desvios entre a data de vencimento e a data real de pagamento ajuda a avaliar a eficácia de diferentes condições de pagamento. Por que isso importa Ele define o prazo para o pagamento do cliente, sendo essencial para calcular as taxas de pagamento no prazo e gerenciar as contas a receber. Onde obter Essa data não é armazenada diretamente, mas calculada com base na Data da Fatura (VBRK-FKDAT) e na chave de Condições de Pagamento (VBRK-ZTERM), usando as funções padrão de determinação de datas do SAP. Exemplos 2023-04-192023-05-012023-06-17 | |||
| Horário de Término EndTime | O registro preciso de data e hora que indica quando uma atividade ou evento foi concluído. | ||
| Descrição O Horário de Término marca a conclusão de uma atividade. No Process Mining, ele costuma ser inferido como o Horário de Início da atividade seguinte no caso ou pode ser obtido diretamente quando o sistema registra os eventos de início e término. Esse atributo é essencial para calcular o Tempo de Processamento de atividades individuais. Subtraindo o Horário de Início do Horário de Término, é possível medir a duração de cada etapa, o que é fundamental para a análise de gargalos, como a identificação de atrasos na etapa de aprovação da fatura. Por que isso importa Ele permite calcular a duração exata, ou tempo de processamento, de cada atividade, sendo fundamental para a análise de gargalos. Onde obter Esse é um atributo derivado para Process Mining. Normalmente, ele é calculado como o StartTime do próximo evento na sequência do caso. Em alguns cenários, tabelas específicas podem registrar os horários de conclusão. Exemplos 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Nome do Cliente CustomerName | O nome do cliente para quem a fatura foi emitida. | ||
| Descrição Esse atributo identifica a razão social do cliente faturado. Ele é obtido a partir dos dados mestres centrais de clientes no SAP. A análise do processo por cliente permite identificar padrões específicos de determinadas contas. Por exemplo, ela pode revelar quais clientes pagam atrasado com frequência, quais abrem mais disputas ou para quais o processo de faturamento é menos eficiente. Isso permite uma gestão direcionada do relacionamento com o cliente e estratégias de cobrança personalizadas. Por que isso importa Ele permite uma análise centrada no cliente, ajudando a identificar comportamentos de pagamento, frequência de disputas e ineficiências do processo em contas específicas. Onde obter Obtido da tabela de dados mestres de clientes KNA1 (Campo: NAME1), vinculada pelo ID do Pagador no cabeçalho da fatura (VBRK-KUNRG). Exemplos Usina de energia de SpringfieldKwik-E-MartCyberdyne Systems | |||
| Nome do Usuário UserName | O ID do usuário do funcionário que executou a atividade. | ||
| Descrição Esse atributo captura o ID do usuário SAP responsável por um evento específico, como criar uma fatura, lançar um documento ou compensar um pagamento. Ele conecta as etapas do processo às pessoas ou equipes que as executam. A análise por Nome do Usuário ajuda a identificar pessoas com alta performance, necessidades de treinamento ou desequilíbrios na distribuição da carga de trabalho. Também é essencial para a análise de conformidade, mostrando quem executou atividades críticas, e para entender variações na forma como diferentes usuários executam o mesmo processo. Por que isso importa Ele conecta as atividades do processo a usuários específicos, permitindo analisar carga de trabalho, performance e conformidade no nível individual ou da equipe. Onde obter Para eventos de criação, esse dado está em VBRK-ERNAM. Para alterações posteriores, ele é encontrado em tabelas de histórico de alterações, como CDHDR-USERNAME, ou em 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, como estado ou província, associada ao endereço do cliente. Normalmente, esses dados fazem parte do registro mestre do cliente. Esse atributo é fundamental para o Dashboard de Performance de Faturamento Regional. Ele permite comparar métricas importantes, como tempos de ciclo, taxas de erro e DSO, entre diferentes regiões. Essa comparação pode destacar diferenças regionais na execução do processo, na conformidade ou na eficiência, abrindo caminho para melhorias direcionadas e para a padronização das melhores práticas. Por que isso importa Ele permite comparar a performance do faturamento entre diferentes áreas geográficas, ajudando a identificar disparidades regionais e padronizar processos. Onde obter Obtido da tabela de dados mestres de clientes KNA1 (Campo: REGIO), vinculada pelo 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 Esse atributo representa o valor monetário total dos produtos ou serviços faturados, excluindo impostos. É um dado financeiro fundamental para cada caso de fatura. O Valor da Fatura é usado em várias análises. Ele permite segmentar o processo por valor, por exemplo, para verificar se faturas de alto valor são processadas de forma diferente ou sofrem mais atrasos. Também é a base para relatórios financeiros e para calcular o valor total dos recebíveis em aberto. Por que isso importa Ele quantifica o valor financeiro de cada fatura, permitindo análises baseadas em valor, priorização de cobranças e avaliação do impacto financeiro. Onde obter Tabela SAP: VBRK, Campo: NETWR Exemplos 1500.0025000.50125.75 | |||
| Código da Empresa CompanyCode | A unidade organizacional na qual a transação financeira é registrada. | ||
| Descrição O Código da Empresa é uma entidade organizacional fundamental no SAP Financials, representando uma empresa legalmente independente para a qual são elaboradas demonstrações financeiras. Cada documento de faturamento é atribuído a um código de empresa específico. A análise por Código da Empresa é essencial em organizações com várias empresas para comparar a performance do processo, métricas financeiras como DSO e conformidade entre diferentes entidades legais. Ele fornece um filtro organizacional de alto nível para todos os Dashboards do processo. Por que isso importa Ele permite segmentar a análise do processo por entidade legal, possibilitando comparar a performance e consolidar as informações financeiras 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 o pagamento. | ||
| Descrição As Condições de Pagamento são condições predefinidas acordadas com um cliente que determinam quando o pagamento de uma fatura vence. Os exemplos incluem 'Líquido 30' (pagamento devido em 30 dias) ou '2/10 Líquido 30' (desconto de 2% se pago em 10 dias; caso contrário, vencimento em 30 dias). A análise por condições de pagamento ajuda a avaliar sua eficácia. Ao relacionar diferentes condições de pagamento ao tempo real necessário para receber o pagamento, a empresa pode determinar quais condições são mais eficazes para incentivar pagamentos rápidos e otimizar suas condições para melhorar o fluxo de caixa. Por que isso importa Ele 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 informa se a fatura foi paga na data de vencimento ou antes dela. | ||
| Descrição Esse é um atributo calculado que compara a data real de pagamento com a data de vencimento programada. O resultado é 'true' se o pagamento foi feito no prazo e 'false' se foi feito com atraso. Esse indicador simplifica o cálculo e a visualização do KPI de Taxa de Pagamento no Prazo. Ele permite filtrar e segmentar facilmente as faturas para analisar as características das que são pagas com atraso em comparação com as que são pagas no prazo. Isso pode ajudar a revelar padrões relacionados a clientes, regiões ou condições de pagamento específicas que levam a atrasos. Por que isso importa Ele simplifica a medição da performance ao indicar claramente se cada fatura foi paga 'no prazo' ou 'com atraso', dando suporte direto ao KPI de Taxa de Pagamento no Prazo. Onde obter Esse é um campo calculado. A lógica compara o registro de data e hora da atividade 'Pagamento do Cliente Recebido' com o valor do atributo 'PaymentDueDate'. Exemplos truefalse | |||
| Moeda Currency | O código da moeda do valor da fatura. | ||
| Descrição Esse atributo especifica a moeda em que os valores das faturas são denominados, como USD, EUR ou JPY. Ele fornece o contexto necessário para todos os valores monetários. Em uma organização global, a moeda é essencial para análises e relatórios financeiros corretos. Ela permite agregar adequadamente os dados financeiros, convertendo todos os valores para uma moeda comum de relatório, e comparar a performance do faturamento entre regiões com moedas locais diferentes. Por que isso importa Ele fornece o contexto essencial para todos os valores monetários, garantindo análises e relatórios financeiros precisos, especialmente em operações multinacionais. Onde obter Tabela SAP: VBRK, Campo: WAERK Exemplos USDEURGBP | |||
| Motivo da Disputa CustomerDisputeReason | O motivo informado por um cliente para contestar uma fatura. | ||
| Descrição Quando um cliente contesta uma fatura, o motivo da disputa costuma ser registrado. Isso pode ocorrer devido a erros de preço, quantidades incorretas ou mercadorias danificadas. Essas informações podem ser armazenadas no módulo SAP Dispute Management ou como observações de texto. A análise dos motivos das disputas é fundamental para o KPI de Taxa de Erro de Faturamento e para a análise de erros associada. Ela ajuda a identificar as causas-raiz das imprecisões no faturamento, permitindo que a empresa corrija problemas sistêmicos nos processos anteriores, melhore a qualidade das faturas e aumente a satisfação dos clientes. Por que isso importa Ele explica por que as faturas estão sendo contestadas, oferecendo um insight direto sobre as causas-raiz dos erros de faturamento e da insatisfação dos clientes. Onde obter Se o SAP Dispute Management for usado, essas informações podem ser encontradas em tabelas como UDM_DISPUTE. Caso contrário, podem ser derivadas de códigos de motivo em documentos relacionados ou de campos de texto. Exemplos Preço incorretoDivergência de quantidadeMercadoria danificada recebida | |||
| Motivo da Nota de Crédito CreditMemoReason | O código de motivo que indica por que uma nota de crédito foi emitida. | ||
| Descrição Quando uma fatura está incorreta e precisa receber um crédito, normalmente é atribuído um motivo ao documento da nota de crédito. Isso oferece uma forma estruturada de categorizar as fontes dos erros de faturamento. Esse atributo dá suporte direto ao KPI de Taxa de Erro de Faturamento. Ao consolidar e analisar os motivos das notas de crédito, a empresa pode identificar os tipos de erro mais comuns, como erros de preço ou devoluções de produtos. Essa análise orienta melhorias no processo para reduzir a necessidade de correções financeiras e retrabalho. Por que isso importa Ele categoriza os motivos para a emissão de créditos, ajudando a localizar as fontes mais frequentes de erros de faturamento e impulsionando melhorias de qualidade. Onde obter Tabela SAP: VBRK, Campo: AUGRU (Motivo do Pedido). Esse campo é usado em solicitações de nota de crédito/débito que depois são faturadas. Exemplos 001 - Diferença de preço002 - Baixa qualidade005 - Devolução do cliente | |||
| Número do Pedido de Venda SalesOrderNumber | O identificador do pedido de venda original que deu origem à fatura. | ||
| Descrição O Número do Pedido de Venda conecta o documento de faturamento às atividades de vendas anteriores. Um único pedido de venda pode resultar em uma ou mais faturas, e esse vínculo fornece o fluxo completo de documentos. Esse atributo é fundamental para uma análise verdadeira de Order-to-Cash de ponta a ponta. Ele permite estender a visão do processo para as etapas anteriores, conectando problemas de faturamento às possíveis causas-raiz nas fases de criação ou atendimento do pedido de venda. Por exemplo, ajuda a calcular o Tempo de Ciclo de Geração da Fatura desde o atendimento do pedido. Por que isso importa Ele conecta 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 do Item do Documento de Faturamento), Campo: AUBEL Exemplos 100001231000045610000789 | |||
| Sistema de Origem SourceSystem | Identifica o sistema de origem específico do qual os dados foram extraídos. | ||
| Descrição Esse atributo especifica a origem dos dados, sendo especialmente útil em ambientes com várias instâncias SAP ou outros sistemas integrados. Normalmente, inclui o ID do sistema e o número do cliente. Na análise, ele ajuda a diferenciar processos e performance entre diferentes sistemas ou entidades organizacionais. Garante a linhagem dos dados e fornece contexto, especialmente quando dados de várias fontes são combinados para oferecer uma visão holística do processo. Por que isso importa Ele fornece um contexto essencial sobre a origem dos dados, garantindo clareza em ambientes com vários sistemas e dando suporte à governança de dados. Onde obter Normalmente, esse é um valor estático definido durante a extração dos dados, geralmente combinando o ID do sistema (SY-SYSID) e o cliente (SY-MANDT). Exemplos S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Status do Pagamento PaymentStatus | O status atual do pagamento da fatura, como Em Aberto, Paga ou Em Atraso. | ||
| Descrição O Status do Pagamento oferece uma visão instantânea da posição da fatura no ciclo de vida das cobranças. Esse não é um campo único no SAP, mas é derivado da verificação do status de compensação do documento contábil correspondente. Esse atributo é essencial para o Dashboard de Aging de Faturas em Aberto. Ele permite segmentar todas as faturas em aberto por status e idade, ajudando a equipe de cobrança a priorizar seus esforços com eficiência. Acompanhar as transições entre os status também é uma forma de monitorar o próprio processo de cobrança. Por que isso importa Ele oferece uma visão clara e imediata do status de cobrança de uma fatura, essencial 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 em aberto) e BSAD (itens compensados). Exemplos Em abertoPagoEm atrasoParcialmente pago | |||
| 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 no processo de faturamento. Ele controla como o documento é processado, incluindo seu intervalo de numeração e as regras de lançamento contábil. Esse atributo permite filtrar o processo para analisar tipos específicos de transação. Por exemplo, é possível criar uma visão de processo separada apenas para notas de crédito, entender os motivos e o fluxo do processo de correções financeiras ou analisar faturas padrão separadamente dos cancelamentos para obter uma visão mais clara do processo principal de faturamento. Por que isso importa Ele classifica as transações, permitindo uma análise direcionada de fluxos específicos de documentos, como faturas padrão, notas de crédito ou cancelamentos. Onde obter Tabela SAP: VBRK, Campo: FKART Exemplos F2G2S1L2 | |||
| Última Atualização dos Dados LastDataUpdate | O registro de data e hora que indica quando os dados desse evento foram extraídos ou atualizados pela última vez. | ||
| Descrição Esse atributo registra a data e a hora da última extração de dados do sistema de origem. É um campo de metadados essencial para entender o nível de atualização dos dados analisados. Essas informações são usadas para validar a atualidade da análise e gerenciar os cronogramas de atualização dos dados. Elas garantem que as partes interessadas saibam o quão recentes são os dados ao tomar decisões com base nos Dashboards e insights de Process Mining. Por que isso importa Ele indica o nível de atualização dos dados, essencial para confiar na análise e entender sua relevância para a situação atual das operações. Onde obter Esse registro de data e hora é gerado e gravado em cada registro durante o processo de extração e carregamento de dados (ETL). Exemplos 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura Fechada | Essa atividade representa o estado final de uma fatura paga com sucesso. Funcionalmente, é igual a 'Pagamento Aplicado/Reconciliado' e indica que o processo dessa fatura foi concluído. | ||
| Por que isso importa Funciona como o principal evento final do 'caminho feliz' do processo. Medir o tempo total do ciclo até esse ponto oferece uma visão completa do ciclo de vida de faturamento e emissão de faturas, de ponta a ponta. Onde obter Inferido a partir do status do item do cliente no documento contábil. Um item é fechado 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 de linha da fatura. Tipo de evento inferred | |||
| Fatura gerada | Esta atividade marca a criação do documento de faturamento no sistema. É um evento explícito capturado quando um usuário executa uma transação como VF01 ou quando um job em segundo plano cria a fatura, resultando em uma nova entrada na tabela de cabeçalho do documento de faturamento. | ||
| Por que isso importa Este é o principal evento de início do processo de faturamento. Analisar o tempo entre o atendimento do pedido e esta atividade é essencial para medir o tempo do ciclo de geração de faturas e identificar atrasos iniciais no processo. Onde obter Registrado na tabela VBRK do SAP S/4HANA (Billing Document: Header Data) no momento da criação. A data de criação (VBRK-ERDAT) e o horário (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 de contabilidade financeira. Este é um marco crítico em que a fatura se torna oficialmente um item de contas a receber, gerando lançamentos no razão contábil. | ||
| Por que isso importa Esta atividade confirma que a fatura é um documento financeiro legal. O tempo entre a geração e o lançamento é um indicador-chave de performance que evidencia a eficiência do processamento interno. Onde obter Este evento é capturado quando o documento contábil correspondente é criado. O documento de faturamento (VBRK-VBELN) é vinculado ao documento contábil (BKPF-BELNR) por meio de 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 vinculada ao documento de faturamento. Tipo de evento explicit | |||
| Pagamento Aplicado/Reconciliado | Representa o momento em que o pagamento recebido do cliente é associado e usado para compensar o item da fatura em aberto no subledger de contas a receber. Essa atividade conclui a transação do ponto de vista financeiro. | ||
| Por que isso importa Mede a eficiência do processo de aplicação de pagamentos. Atrasos nessa etapa podem distorcer a situação real das contas dos clientes e gerar trabalho desnecessário para as equipes de cobrança. Onde obter Esse evento é capturado pela data de compensação (BSEG-AUGDT) no item de linha do documento contábil da fatura original. Essa data é preenchida quando um documento de compensação compensa o item. Captura Capturado a partir do campo de data de compensação (AUGDT) na tabela BSEG/ACDOCA para o item de linha da fatura. Tipo de evento explicit | |||
| Pagamento do cliente recebido | Esta atividade marca o lançamento de um pagamento recebido de um cliente no sistema financeiro. Nesta etapa, o pagamento ainda pode não ter sido aplicado a uma fatura específica, mas os recursos já foram registrados. | ||
| Por que isso importa Um marco essencial para calcular o Days Sales Outstanding (DSO). Indica que o dinheiro foi recebido, mesmo que a reconciliação ainda esteja pendente. Onde obter Capturado a partir da data de lançamento (BKPF-BUDAT) do documento de pagamento do cliente (normalmente, tipo de documento 'DZ' na tabela BKPF). Captura O evento é baseado na criação do documento de pagamento em BKPF/BSEG. Tipo de evento explicit | |||
| Contestação do cliente aberta | Esta atividade ocorre quando um cliente abre uma disputa sobre uma fatura, que é então registrada formalmente no sistema. Isso exige o uso do módulo SAP Dispute Management. | ||
| Por que isso importa Destaca problemas de precisão do faturamento, qualidade do produto ou prestação de serviços que levam a atrasos nos pagamentos. Analisar os motivos das disputas pode ajudar a tratar as causas-raiz e melhorar a satisfação dos clientes. Onde obter Registrado quando um caso de disputa é criado nas tabelas do Dispute Management, como UDM_CASE, vinculado ao item do documento contábil. Captura Capturado a partir do timestamp de criação do registro do caso de disputa vinculado à fatura. Tipo de evento explicit | |||
| Data de vencimento do pagamento atingida | Um evento calculado que representa a data em que o pagamento da fatura vence oficialmente, de acordo com as condições de pagamento acordadas. Não é um evento transacional, mas é derivado dos dados da fatura. | ||
| Por que isso importa Oferece uma base essencial para medir a performance dos pagamentos no prazo e analisar o comportamento de pagamento dos clientes. Ajuda a diferenciar pagamentos pontuais de pagamentos em atraso. Onde obter Calculado com base na data de referência do pagamento (BSEG-ZFBDT) e nas condições de pagamento armazenadas no item de cliente do documento contábil. Captura Derivado da adição dos dias das condições de pagamento à data de referência encontrada no item do documento contábil (BSEG). Tipo de evento calculated | |||
| Fatura Cancelada | Ocorre quando uma fatura criada anteriormente é cancelada, o que normalmente envolve a criação de um documento de cancelamento correspondente. Isso reverte efetivamente a fatura original e seu impacto contábil. | ||
| Por que isso importa Indica retrabalho, correções ou erros de faturamento. Uma frequência alta de cancelamentos aponta para problemas significativos nas etapas anteriores, como o lançamento do pedido de venda ou a configuração do faturamento. Onde obter Capturado quando um documento de faturamento de cancelamento é criado (por exemplo, tipo de documento 'S1'). Esse novo documento em VBRK fará referência ao número da fatura original no campo VBRK-SFAKN. Captura O evento é capturado a partir da data de criação do documento de cancelamento em VBRK que faz referência à fatura original. Tipo de evento explicit | |||
| Fatura enviada ao cliente | Esta atividade marca o momento em que a fatura foi enviada ao cliente, por exemplo, por impressão, e-mail ou EDI. O mecanismo de captura depende da configuração de gerenciamento de saídas no SAP. | ||
| Por que isso importa O início oficial da contagem do prazo de pagamento sob a perspectiva do cliente. Atrasos no envio da fatura afetam diretamente o Days Sales Outstanding (DSO) e o fluxo de caixa. Onde obter Pode ser registrado explicitamente nas tabelas de controle de saída, como NAST nos métodos antigos ou no equivalente do S/4HANA. Se não houver um registro explícito, geralmente considera-se que ocorre ao mesmo tempo que 'Invoice Posted To Accounting'. Captura Verifique os logs de processamento nas tabelas de gerenciamento de saídas para encontrar um timestamp associado ao tipo de saída da fatura. Tipo de evento explicit | |||
| Lançamento da fatura bloqueado | Este evento ocorre quando uma fatura é criada, mas bloqueada automaticamente para lançamento na contabilidade financeira por vários motivos, como verificações de crédito ou inconsistências nos dados. Esse status é inferido a partir do campo de status de lançamento do documento de faturamento. | ||
| Por que isso importa Identifica gargalos em que as faturas são criadas, mas não são liberadas imediatamente para a área financeira, atrasando todo o ciclo de recebimento. É um indicador importante de problemas de qualidade dos dados ou de gestão de crédito. Onde obter Inferido a partir do campo de status de lançamento na tabela de cabeçalho do documento de faturamento (VBRK-RFBSK). Um status como 'A' (Billing document blocked for forwarding to FI) indica um bloqueio. Captura Inferido pela verificação do 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 emitido | Representa o envio de um lembrete de pagamento ou aviso de cobrança ao cliente referente a uma fatura vencida. É um evento explícito gerado pelo procedimento automatizado de cobrança. | ||
| Por que isso importa Permite analisar a eficácia do processo de cobrança. Ajuda a determinar se os lembretes aceleram os pagamentos e quais níveis de cobrança têm maior impacto. Onde obter Registrado nas tabelas de histórico de cobrança (MAHNV, MHND) quando a execução de cobrança (transação F150) é realizada para o item em aberto da fatura. Captura Capturado a partir da data de execução do aviso de cobrança registrada nas tabelas de histórico de cobrança. Tipo de evento explicit | |||
| Nota de Crédito Criada | Essa atividade representa a criação de uma nota de crédito, emitida para um cliente para corrigir uma cobrança indevida ou conceder um crédito por mercadorias devolvidas. Ela costuma estar vinculada a uma fatura original. | ||
| Por que isso importa Evidencia problemas que resultam em ajustes financeiros após o faturamento. A análise das notas de crédito pode revelar erros de preço, problemas com produtos ou outras causas-raiz de perda de receita. Onde obter Criado explicitamente como um novo documento de faturamento (em VBRK), com um tipo específico de faturamento para notas de crédito (por exemplo, 'G2'). Ele costuma fazer referência ao pedido de venda ou à fatura original. Captura Capturado a partir da criação de um documento de faturamento em 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 em que uma fatura foi cancelada e, depois, uma nova fatura 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 isso importa Dá suporte direto ao KPI de Taxa de Retrabalho de Faturamento ao quantificar ocorrências de correção. Isso ajuda a localizar ineficiências e medir o custo da baixa qualidade no processo de faturamento. Onde obter Esse padrão é calculado identificando um evento de 'Fatura Cancelada' seguido por um novo evento de 'Fatura Gerada', ambos relacionados ao mesmo documento de origem, como um número de pedido de venda. Captura Derivado da detecção de uma sequência de 'Fatura Cancelada' e 'Fatura Gerada' para a mesma referência de pedido de venda. Tipo de evento calculated | |||
Guias de extração
Etapas
- Pré-requisitos: confirme que você tem uma conta de usuário no SAP S/4HANA com as autorizações necessárias para consultar CDS Views (Core Data Services). Especificamente, você precisa de acesso de leitura a Views como I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase e I_DunningHistory.
- Acesse a ferramenta de extração de dados: faça login no seu sistema SAP S/4HANA. Você pode usar várias ferramentas para executar consultas SQL em CDS Views, como o SAP HANA Studio, o DBeaver conectado pelo cliente SAP HANA ou o plug-in SAP Analysis for Microsoft Excel. Neste guia, vamos considerar um cliente SQL padrão.
- Identifique os parâmetros do sistema: antes de executar a consulta, identifique os Company Codes específicos e o período relevante para sua análise. Recomendamos começar com um escopo limitado, por exemplo, os dados dos últimos 3 a 6 meses, para manter o tempo de execução da consulta sob controle.
- Prepare a consulta SQL: copie a consulta SQL completa fornecida na seção 'query' deste documento para o cliente SQL escolhido.
- Personalize os placeholders: altere os valores dos placeholders na consulta. Substitua
'YYYY-MM-DD'pelas datas inicial e final desejadas. Substitua'XXXX'pelo(s) Company Code(s) desejado(s). Talvez você também precise ajustar o placeholder dos tipos de documento de credit memo, por exemplo,'G2', de acordo com a configuração do seu sistema. - Execute a consulta: execute a consulta SQL modificada no banco de dados do SAP S/4HANA. O tempo de execução varia conforme o volume de dados no período selecionado.
- Revise os resultados: quando a consulta terminar, revise a saída. O conjunto de resultados deve ser uma tabela simples em que cada linha representa uma única atividade do processo de faturamento. Esse é o seu Event Log.
- Transformação dos dados, se necessário: a consulta foi criada para produzir um Event Log limpo. Ainda assim, verifique o formato dos timestamps para garantir a compatibilidade com sua ferramenta de Process Mining. A consulta usa
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpara converter os valores em um timestamp UTC padrão, que deve ser amplamente compatível. - Exporte o Event Log: exporte o conjunto completo de resultados do seu cliente SQL para um arquivo CSV. Garanta que o arquivo esteja codificado em UTF-8 para evitar problemas com caracteres.
- Faça o upload no ProcessMind: envie o arquivo CSV gerado para a plataforma ProcessMind, mapeando colunas como InvoiceNumber, ActivityName e EventTime para os campos correspondentes na ferramenta.
Configuração
- Período: defina as datas inicial e final na cláusula
WHEREda Common Table Expression (CTE) inicial. Recomendamos um período de 3 a 6 meses para a análise inicial, equilibrando o volume de dados e a performance. O filtro é aplicado aBillingDocumentDate. - Company Code: filtre por um ou mais valores de
CompanyCodepara restringir a extração às entidades jurídicas relevantes. Esse é um filtro essencial para controlar o escopo dos dados. - Tipos de documento: a consulta inclui uma lógica para identificar credit memos com base em
BillingDocumentType. Você deve configurar o placeholder, por exemplo,('G2', 'CR'), com os tipos de documento específicos usados para credit memos na sua organização. - Pré-requisitos: o acesso às CDS Views subjacentes é obrigatório. Isso exige 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 Dispute Management e SAP Financials Dunning precisam estar ativos e em uso no seu sistema.
- Performance: a consulta usa várias junções e uniões. Para conjuntos de dados muito grandes, como vários anos de dados, considere executá-la fora do horário de pico ou aplicar filtros mais restritivos para limitar a extração 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
- Confirme se há acesso direto de leitura ao schema SAP HANA que contém as tabelas de faturamento e as tabelas financeiras relacionadas. Obtenha do responsável pelo sistema o nome do schema, os dados de conexão, o período autorizado, o escopo de Company Code, os tipos de documento de faturamento e quaisquer filtros de cliente ou região. Substitua apenas os placeholders de conexão e filtros na consulta.
- Confirme as fontes de dados relevantes do SAP S/4HANA e seus mapeamentos de campos no sistema de destino. A consulta usa VBRK e VBRP para dados de faturamento e exige fontes configuradas para contabilidade, gerenciamento de saídas, gerenciamento de contestações, cobrança, pagamentos recebidos, compensação e relações entre documentos. Substitua os placeholders de fonte e campo entre colchetes somente depois de validá-los no dicionário de dados do sistema.
- Configure o período de extração usando timestamps inicial inclusivo e final exclusivo. Recomendamos um período de três a seis meses para a execução inicial. Restrinja a extração por Company Code e, quando apropriado, por tipo de faturamento para controlar o volume e evitar a mistura de processos de faturamento não relacionados.
- Execute a consulta com um usuário de banco de dados HANA somente leitura. A consulta cria uma linha de evento para cada atividade extraída explicitamente. Ela não depende do ProcessMind para inferir eventos. As atividades calculadas, incluindo Payment Due Date Reached e Billing Rework Identified, são geradas pela lógica SQL e retornadas como linhas.
- Valide o schema retornado. O Event Log deve conter InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region e EndTime. Confirme que InvoiceNumber, ActivityName e EventTime estão preenchidos em todas as linhas.
- Valide a semântica e as relações dos eventos. Compare as linhas Invoice Generated com os dados de criação do cabeçalho de faturamento, as linhas Invoice Posted To Accounting com o status de lançamento contábil, as linhas Invoice Sent To Customer com os registros de saída, as linhas de pagamento com os documentos contábeis e as linhas de compensação com os itens de fatura compensados. Revise todas as seções dependentes de placeholders antes de usar em produção.
- Normalize o resultado para o ProcessMind. Mantenha uma linha por evento, use um tipo de timestamp e fuso horário consistentes, preserve InvoiceNumber como texto para manter zeros à esquerda e garanta que os valores de ActivityName correspondam exatamente aos nomes de atividade exigidos. Ordene por InvoiceNumber e EventTime, usando uma ordenação secundária determinística quando vários eventos tiverem o mesmo timestamp.
- Exporte o resultado como CSV UTF-8 ou em outro formato tabular compatível com o ProcessMind. Mapeie InvoiceNumber como identificador do caso, ActivityName como coluna de atividade e EventTime como timestamp do evento. Inclua os atributos recomendados quando disponíveis, envie o arquivo pelo processo de importação configurado do ProcessMind e faça uma verificação final da quantidade de linhas e atividades.
Configuração
- Período: comece com três a seis meses. Use um timestamp inicial inclusivo e um timestamp final exclusivo para evitar eventos duplicados entre execuções incrementais.
- Identificador do caso: use InvoiceNumber do cabeçalho do documento de faturamento. Preserve-o como texto, pois os números de documento SAP podem conter zeros à esquerda.
- Atividades obrigatórias: a extração deve retornar linhas explícitas para Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created e Billing Rework Identified.
- Filtros: aplique filtros de Company Code, tipo de documento de faturamento, organização de vendas, cliente, região e data somente depois de confirmar os campos correspondentes e o escopo de negócio no sistema de destino. Não presuma que todos os tipos de documento de faturamento seguem o mesmo processo contábil ou de saída.
- Configuração das fontes: VBRK e VBRP são as principais fontes de faturamento. As fontes de contabilidade, saída, contestação, cobrança, pagamento, compensação e fluxo de documentos devem ser configuradas com base na versão implantada do SAP S/4HANA e nos módulos habilitados. Substitua as referências de fonte entre colchetes por objetos e campos validados.
- Eventos calculados: Payment Due Date Reached é derivado das condições de pagamento e dos dados de vencimento. Billing Rework Identified é derivado de padrões de cancelamento e geração posterior de faturas. Esses são eventos gerados por SQL, não registros transacionais nativos.
- Performance: aplique filtros de data, Company Code, tipo de faturamento e número de documento em cada consulta de fonte. Selecione apenas as colunas necessárias, evite junções irrestritas com tabelas contábeis grandes, processe o período em lotes mensais ou semanais e use planos de execução do banco de dados para identificar junções dispendiosas.
- Extração incremental: use um watermark estável baseado nos timestamps de criação ou lançamento da fonte. Reprocesse uma pequena janela de sobreposição para capturar registros de saída, pagamento, contestação e compensação que chegarem depois e, em seguida, elimine duplicidades usando InvoiceNumber, ActivityName e EventTime, além da chave do documento de origem relevante.
- Autorizações: o usuário de extração precisa de autorização de leitura para os objetos e campos selecionados do schema HANA. Confirme que o acesso direto ao banco de dados é permitido pela política de segurança da organização e que os requisitos de tratamento de dados pessoais ou de clientes estão sendo atendidos.
- Pré-requisitos funcionais: os dados de gerenciamento de saídas, integração contábil, gerenciamento de contestações, cobrança, pagamentos recebidos e compensação só estarão disponíveis quando esses recursos estiverem configurados e em uso no sistema. Módulos ou registros de origem ausentes resultam em atividades ausentes, não em eventos inferidos.
- Fuso horário: padronize os timestamps para o fuso horário exigido pelo ProcessMind. Documente se os timestamps de origem estão armazenados em UTC, no horário local do sistema ou em outro fuso horário configurado.
a Consulta de exemplo sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName;Pronto para começar?
Use este Template para acelerar a preparação dos seus dados e começar a otimizar seu processo de Order to Cash - Faturamento e emissão de faturas. Comece hoje a transformar seus dados do SAP S/4H4ANA em insights práticos.
Otimize o faturamento de Order to Cash para acelerar o fluxo de caixa em 30%
Elimine ineficiências e reduza hoje em 30% o tempo do seu ciclo de faturamento.
Não é necessário cartão de crédito. Comece em poucos minutos.