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 a acompanhar
- Orientações para extração de dados do SAP S/4HANA
Atributos de Order-to-Cash, faturamento e emissão de faturas
| Nome | Descrição | ||
|---|---|---|---|
| Número da fatura InvoiceNumber | Identificador exclusivo de um documento de faturamento, usado como identificador principal do caso no processo de emissão de faturas. | ||
| Descrição O número da fatura, chamado de 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, da criação e do lançamento da fatura ao recebimento e à conciliação do pagamento. No Process Mining, este atributo é essencial para correlacionar os casos. Todos os eventos com o mesmo número de fatura são agrupados em uma única instância do processo, permitindo analisar de ponta a ponta o ciclo de vida de cada fatura. Assim, você acompanha os tempos de ciclo, identifica desvios e analisa o percurso de cada fatura. Por que isso importa É o identificador fundamental que reúne todas as atividades de faturamento relacionadas em um único caso e permite analisar o processo de ponta a ponta. Onde encontrar Tabela SAP: VBRK, campo: VBELN Exemplos 900012349000567890009012 | |||
| Horário do evento EventTime | Data e hora exatas em que uma atividade ou um evento ocorreu. | ||
| Descrição O horário do evento fornece a data e a hora de cada atividade e forma a base cronológica do processo. Esse registro é essencial para calcular durações, tempos de ciclo e tempos de espera entre as diferentes etapas do processo de faturamento. Na análise, o horário do evento é usado para ordenar as atividades, calcular indicadores-chave de performance, como o prazo médio de recebimento de vendas e o tempo de ciclo de emissão da fatura, e identificar gargalos relacionados ao tempo. Ele oferece 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 relacionadas ao tempo, como tempos de ciclo e durações. Onde encontrar Extraído de diferentes campos de data e hora, conforme a atividade, como data e horário 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 | Nome da atividade de negócio ou do evento ocorrido no processo de faturamento, como “Fatura emitida” ou “Pagamento recebido”. | ||
| Descrição O nome da atividade descreve uma etapa ou um marco específico no ciclo de vida do faturamento. Essas atividades são derivadas de diferentes pontos de dados no SAP, como códigos de transação, alterações no status de documentos ou registros específicos de log, para formar um fluxo sequencial do processo. Analisar a sequência e a frequência dessas atividades é a base do Process Mining. Isso ajuda a visualizar o mapa do processo, descobrir variantes comuns e raras, identificar gargalos entre etapas e medir a frequência de atividades que não agregam valor, como retrabalho ou cancelamentos. Por que isso importa Este atributo define as etapas do processo e permite visualizar mapas de processo e analisar o fluxo, as variações e os gargalos. Onde encontrar 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 emitidaFatura lançada na contabilidadePagamento do cliente recebidoFatura cancelada | |||
| Data da fatura InvoiceDate | Data oficial em que a fatura foi emitida para o cliente. | ||
| Descrição A data da fatura, também chamada de data de faturamento no SAP, serve de referência inicial para muitos cálculos financeiros. É a partir dela que são determinadas as condições de pagamento, as datas de vencimento e a idade do valor a receber. Este é um atributo essencial no nível do caso para a análise financeira. Ele serve de referência para calcular o KPI de prazo médio de recebimento de vendas (DSO) e gerar relatórios de envelhecimento de faturas em aberto, ferramentas importantes para gerenciar o fluxo de caixa e as cobranças. Por que isso importa É a principal data de referência para cálculos financeiros e o ponto de partida para o DSO, as datas de vencimento e a análise de envelhecimento das faturas. Onde encontrar Tabela SAP: VBRK, campo: FKDAT Exemplos 2023-03-202023-04-012023-05-18 | |||
| Data de vencimento do pagamento PaymentDueDate | Data até a qual se espera que o cliente pague 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 antes que a fatura fique em atraso. Este atributo é essencial para monitorar a eficácia das cobranças e prever o fluxo de caixa. Ele é usado diretamente no cálculo do KPI de taxa de pagamentos em dia e na segmentação de faturas em relatórios de envelhecimento. Analisar as diferenças entre a data de vencimento e a data efetiva do pagamento ajuda a avaliar a eficácia de diferentes condições de pagamento. Por que isso importa Define o prazo para o pagamento do cliente e é essencial para calcular a taxa de pagamentos em dia e gerenciar as contas a receber. Onde encontrar Esta data não é armazenada diretamente. Ela é calculada com base na data da fatura (VBRK-FKDAT) e na chave das 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 | |||
| Hora de término EndTime | Data e hora exatas em que uma atividade ou evento foi concluído. | ||
| Descrição A hora de término indica quando uma atividade foi concluída. Em Process Mining, ela costuma ser inferida a partir da hora de início da atividade seguinte no caso. Também pode vir diretamente do sistema, se ele registrar eventos de início e de término. Esse atributo é essencial para calcular o tempo de processamento de cada atividade. Subtraindo a hora de início da hora 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 aprovação de faturas. Por que isso importa Permite calcular a duração exata, ou tempo de processamento, de cada atividade, algo fundamental para a análise de gargalos. Onde encontrar Esse atributo é derivado para Process Mining. Em geral, é calculado usando a hora de início 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 de usuário UserName | ID do usuário que executou a atividade. | ||
| Descrição Este atributo registra 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. Analisar os dados por nome de 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, pois mostra quem executou atividades críticas e ajuda a entender as diferenças na forma como cada pessoa realiza o mesmo processo. Por que isso importa Ele conecta as atividades do processo a usuários específicos e permite analisar a carga de trabalho, a performance e a conformidade por pessoa ou equipe. Onde encontrar Para eventos de criação, o dado está em VBRK-ERNAM. Para alterações posteriores, ele pode ser encontrado em tabelas de histórico de alterações, como CDHDR-USERNAME, ou em logs de Workflow. Exemplos CBURNSHSIMPSONLLEONARD | |||
| Nome do cliente CustomerName | Nome do cliente para quem a fatura foi emitida. | ||
| Descrição Este atributo identifica a razão social do cliente faturado. O dado vem dos dados mestres centrais de clientes no SAP. Analisar o processo por cliente ajuda a identificar padrões específicos de cada conta. Por exemplo, você pode descobrir quais clientes pagam com atraso com frequência, quais contestam mais faturas ou para quais o processo de faturamento é menos eficiente. Isso permite gerenciar o relacionamento com cada cliente de forma direcionada e adaptar as estratégias de cobrança. Por que isso importa Ele permite analisar o processo sob a perspectiva do cliente e identificar comportamentos de pagamento, frequência de contestações e ineficiências para contas específicas. Onde encontrar 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 SpringfieldMercadinho Kwik-E-MartCyberdyne Systems | |||
| Região Region | Região geográfica do cliente. | ||
| Descrição O atributo Região indica a área geográfica, como um estado ou uma província, associada ao endereço do cliente. Normalmente, esse dado faz parte do registro mestre do cliente. Este atributo é essencial para o Dashboard de performance regional do faturamento. Ele permite comparar métricas importantes, como tempos de ciclo, taxas de erro e DSO, entre diferentes regiões. Essa comparação pode revelar 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, identificar disparidades regionais e padronizar os processos. Onde encontrar 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 | Valor líquido total da fatura. | ||
| Descrição Este atributo representa o valor monetário total dos produtos ou serviços faturados, sem incluir 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 outra forma ou sofrem mais atrasos. Também serve de base para relatórios financeiros e para calcular o valor total das contas a receber em aberto. Por que isso importa Ele quantifica o valor financeiro de cada fatura e permite fazer análises por valor, priorizar cobranças e avaliar o impacto financeiro. Onde encontrar Tabela SAP: VBRK, campo: NETWR Exemplos 1500.0025000.50125.75 | |||
| Código da empresa CompanyCode | Unidade organizacional em que a transação financeira é registrada. | ||
| Descrição O código da empresa é uma entidade organizacional fundamental no SAP Financials. Ele representa uma empresa legalmente independente para a qual são elaboradas demonstrações financeiras. Cada documento de faturamento é associado a um código de empresa específico. Analisar os dados por código da empresa é essencial em organizações com várias empresas. Isso permite comparar a performance dos processos, métricas financeiras como DSO e conformidade entre diferentes entidades legais. Também oferece um filtro organizacional de alto nível para todos os Dashboards de processos. Por que isso importa Permite segmentar a análise dos processos por entidade legal, comparar a performance e consolidar os dados financeiros em toda a organização. Onde encontrar 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 concedido para pagar. | ||
| Descrição As condições de pagamento são regras predefinidas acordadas com o cliente que determinam quando uma fatura deve ser paga. Alguns exemplos são '30 dias' (pagamento em até 30 dias) e '2/10, 30 dias' (desconto de 2% para pagamentos em até 10 dias; caso contrário, o pagamento vence em 30 dias). Analisar os dados por condição de pagamento ajuda a avaliar a eficácia de cada uma. Ao relacionar as diferentes condições com o tempo efetivamente levado para receber o pagamento, a empresa pode identificar quais incentivam pagamentos mais rápidos e ajustá-las para melhorar o fluxo de caixa. Por que isso importa Define o cronograma de pagamento acordado e permite analisar quais condições são mais eficazes para garantir que os clientes paguem em dia. Onde encontrar Tabela SAP: VBRK, campo: ZTERM Exemplos Z030Z060ZB60 | |||
| Moeda Currency | Código da moeda do valor da fatura. | ||
| Descrição Este atributo especifica a moeda em que os valores das faturas são expressos, como USD, EUR ou JPY. Ele fornece o contexto necessário para interpretar todos os valores monetários. Em uma organização global, a moeda é essencial para análises e relatórios financeiros corretos. Ela permite agregar os dados financeiros adequadamente, 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 necessário para interpretar todos os valores monetários e garantir análises e relatórios financeiros precisos, especialmente em operações multinacionais. Onde encontrar Tabela SAP: VBRK, campo: WAERK Exemplos USDEURGBP | |||
| Motivo da contestação CustomerDisputeReason | Motivo informado pelo cliente para contestar uma fatura. | ||
| Descrição Quando um cliente contesta uma fatura, o motivo geralmente é registrado. Pode ser um erro de preço, uma quantidade incorreta ou um produto danificado. Essas informações podem estar no módulo SAP Dispute Management ou em observações de texto. Analisar os motivos das contestações é fundamental para o KPI de taxa de erros de faturamento e para a análise desses erros. Isso 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 Explica por que as faturas estão sendo contestadas e revela diretamente as causas raiz dos erros de faturamento e da insatisfação dos clientes. Onde encontrar Se o SAP Dispute Management estiver em uso, essas informações podem ser encontradas em tabelas como UDM_DISPUTE. Caso contrário, podem ser obtidas a partir de códigos de motivo em documentos relacionados ou de campos de texto. Exemplos Preço incorretoDivergência na quantidadeProduto recebido danificado | |||
| Motivo da nota de crédito CreditMemoReason | Código que indica o motivo da emissão de uma nota de crédito. | ||
| Descrição Quando uma fatura está incorreta e precisa ser creditada, geralmente se atribui um motivo ao documento de nota de crédito. Isso permite categorizar de forma estruturada as causas dos erros de faturamento. Esse atributo contribui diretamente para o KPI de taxa de erros de faturamento. Ao agrupar e analisar os motivos das notas de crédito, a empresa pode identificar os erros mais comuns, como falhas de preço ou devoluções de produtos. Essa análise orienta melhorias no processo para reduzir a necessidade de ajustes financeiros e retrabalho. Por que isso importa Categoriza os motivos da emissão de créditos, ajudando a identificar as causas mais frequentes dos erros de faturamento e a orientar melhorias de qualidade. Onde encontrar Tabela SAP: VBRK, campo: AUGRU (motivo do pedido). Esse campo é usado em solicitações de nota de crédito ou 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 | Identificador do pedido de venda original que deu origem à fatura. | ||
| Descrição O número do pedido de venda vincula o documento de faturamento às atividades de vendas anteriores. Um único pedido de venda pode gerar uma ou mais faturas, e esse vínculo mostra o fluxo completo de documentos. Esse atributo é essencial para uma análise realmente completa do processo de Order-to-Cash. Ele permite ampliar a visão do processo para as etapas anteriores, relacionando problemas de faturamento às possíveis causas raiz na criação ou no atendimento do pedido de venda. Por exemplo, ajuda a calcular o tempo total do ciclo de geração da fatura, a partir do atendimento do pedido. Por que isso importa Vincula a fatura ao pedido de venda original e permite analisar o processo de Order-to-Cash de ponta a ponta, indo além do faturamento. Onde encontrar Tabela SAP: VBRP (dados de itens do documento de faturamento), campo: AUBEL Exemplos 100001231000045610000789 | |||
| Pagamento em dia IsPaidOnTime | Indicador booleano que informa se a fatura foi paga até a data de vencimento. | ||
| Descrição Esse atributo calculado compara a data efetiva do pagamento com a data de vencimento prevista. O resultado é 'verdadeiro' quando o pagamento é feito em dia e 'falso' quando é feito com atraso. Esse indicador simplifica o cálculo e a visualização do KPI de taxa de pagamentos em dia. Ele facilita a filtragem e a segmentação para analisar as características das faturas pagas com atraso em comparação com as pagas em dia. Assim, é possível identificar padrões relacionados a clientes, regiões ou condições de pagamento específicas que levam a atrasos. Por que isso importa Facilita a medição da performance ao indicar claramente se cada fatura foi paga em dia ou com atraso, contribuindo diretamente para o KPI de taxa de pagamentos em dia. Onde encontrar Este é um campo calculado. A lógica compara a data e hora da atividade 'Pagamento recebido do cliente' com o valor do atributo 'Data de vencimento do pagamento'. Exemplos truefalse | |||
| Sistema de origem SourceSystem | Identifica o sistema de origem específico do qual os dados foram extraídos. | ||
| Descrição Este atributo especifica a origem dos dados, o que é 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 mandante. Na análise, ajuda a diferenciar processos e performance entre sistemas ou entidades organizacionais. Também garante a linhagem dos dados e fornece contexto, especialmente quando dados de várias fontes são combinados para criar uma visão abrangente do processo. Por que isso importa Ele fornece contexto essencial sobre a origem dos dados, garantindo clareza em ambientes com vários sistemas e apoiando a governança de dados. Onde encontrar Geralmente, é um valor estático definido durante a extração de dados, que combina o ID do sistema (SY-SYSID) e o mandante (SY-MANDT). Exemplos S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Status do pagamento PaymentStatus | Status atual do pagamento da fatura, como em aberto, paga ou vencida. | ||
| Descrição O status do pagamento mostra em que etapa do ciclo de cobrança está uma fatura. No SAP, ele não corresponde a um único campo: é determinado pela verificação do status de compensação do documento contábil correspondente. Esse atributo é essencial para o Dashboard de envelhecimento de faturas em aberto. Ele permite segmentar todas as faturas em aberto por status e tempo de vencimento, ajudando a equipe de cobrança a priorizar o trabalho. Acompanhar as mudanças de status também permite monitorar o próprio processo de cobrança. Por que isso importa Mostra de forma clara e rápida o status da cobrança de cada fatura, informação essencial para gerenciar contas a receber e priorizar as ações de cobrança. Onde encontrar Determinado pela 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 abertoPagaVencidaParcialmente paga | |||
| Tipo de documento de faturamento BillingDocumentType | 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 importante que categoriza as transações do processo de faturamento. Ele controla como o documento é processado, incluindo a faixa 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, você pode criar uma visão separada para notas de crédito e entender os motivos e o fluxo do processo de ajustes financeiros. Também pode analisar faturas padrão separadamente dos cancelamentos para ter uma visão mais clara do processo principal de faturamento. Por que isso importa Classifica as transações e permite analisar fluxos específicos de documentos, como faturas padrão, notas de crédito ou cancelamentos. Onde encontrar Tabela SAP: VBRK, campo: FKART Exemplos F2G2S1L2 | |||
| Última atualização dos dados LastDataUpdate | Data e hora da última extração ou atualização dos dados deste evento. | ||
| Descrição Este 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 quanto os dados analisados estão atualizados. Essa informação é usada para validar a atualidade da análise e gerenciar as programações de atualização dos dados. Assim, as partes interessadas sabem se os dados estão atualizados ao tomar decisões com base nos Dashboards e insights de Process Mining. Por que isso importa Ele indica o quanto os dados estão atualizados, algo essencial para confiar na análise e entender sua relevância para a situação atual das operações. Onde encontrar Esta data e hora são geradas e registradas em cada linha durante o processo de extração e carregamento de dados (ETL). Exemplos 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
Atividades de Order-to-Cash, faturamento e emissão de faturas
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura emitida | Esta atividade marca a criação do documento de faturamento no sistema. É um evento explícito, registrado quando uma pessoa executa uma transação como VF01 ou quando um job em segundo plano cria a fatura, gerando um novo registro 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 de ciclo de emissão da fatura e identificar atrasos no início do processo. Onde encontrar Registrado na tabela VBRK do SAP S/4HANA (documento de faturamento: dados de cabeçalho) no momento da criação. A data de criação (VBRK-ERDAT) e o horário (VBRK-ERZET) registram a data e a hora do evento. Coleta O evento é capturado a partir da data e hora de criação do registro do documento de faturamento na tabela VBRK. Tipo de evento explicit | |||
| Fatura encerrada | Esta atividade indica o estado final de uma fatura paga com sucesso. Funcionalmente, equivale a “Recebimento aplicado/conciliado” e indica que o processo dessa fatura foi concluído. | ||
| Por que isso importa É o principal evento de encerramento do caminho ideal. Medir o tempo de ciclo total até este ponto oferece uma visão completa do ciclo de vida do faturamento e da emissão de faturas, de ponta a ponta. Onde encontrar Inferido a partir do status do item do 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. Coleta Inferido pelo preenchimento da data de compensação (AUGDT) na tabela BSEG/ACDOCA para o item da fatura. Tipo de evento inferred | |||
| Fatura lançada na contabilidade | Representa o lançamento bem-sucedido do documento de faturamento no módulo de contabilidade financeira. Este é um marco importante: a fatura passa a ser um título oficial a receber e gera lançamentos no razão geral. | ||
| Por que isso importa Esta atividade confirma que a fatura é um documento financeiro oficial. O tempo entre a emissão e o lançamento é um indicador-chave de performance que mostra a eficiência do processamento interno. Onde encontrar 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. Coleta 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 do cliente recebido | Esta atividade marca o lançamento de um pagamento recebido de um cliente no sistema financeiro. Nesse momento, o pagamento ainda pode não estar associado a uma fatura específica, mas o recebimento já foi registrado. | ||
| Por que isso importa Um marco essencial para calcular o prazo médio de recebimento de vendas (DSO). Indica que o dinheiro foi recebido, mesmo que a conciliação ainda esteja pendente. Onde encontrar Capturado a partir da data de lançamento (BKPF-BUDAT) do documento de pagamento do cliente, geralmente do tipo 'DZ' na tabela BKPF. Coleta O evento se baseia na criação do documento de pagamento em BKPF/BSEG. Tipo de evento explicit | |||
| Recebimento aplicado/conciliado | Representa o momento em que o pagamento recebido do cliente é associado à fatura em aberto e usado para baixá-la no razão auxiliar de contas a receber. Do ponto de vista financeiro, esta atividade conclui a transação. | ||
| Por que isso importa Mede a eficiência do processo de aplicação dos recebimentos. Atrasos nesta etapa podem distorcer a situação real das contas dos clientes e gerar trabalho desnecessário para as equipes de cobrança. Onde encontrar Este evento é capturado pela data de compensação (BSEG-AUGDT) no item do documento contábil da fatura original. Essa data é preenchida quando um documento de compensação baixa o item. Coleta Capturado a partir do campo de data de compensação (AUGDT) na tabela BSEG/ACDOCA para o item da fatura. Tipo de evento explicit | |||
| Aviso de cobrança enviado | Representa o envio de um lembrete de pagamento ou aviso de cobrança ao cliente por 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 encontrar 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. Coleta 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 | |||
| Contestação do cliente aberta | Esta atividade ocorre quando um cliente contesta uma fatura e a contestação é registrada formalmente no sistema. Para isso, é necessário usar o módulo SAP Dispute Management. | ||
| Por que isso importa Destaca problemas de precisão no faturamento, qualidade do produto ou prestação de serviços que causam atrasos nos pagamentos. Analisar os motivos das contestações pode ajudar a resolver as causas raiz e aumentar a satisfação dos clientes. Onde encontrar Registrado quando um caso de contestação é criado nas tabelas do Dispute Management (por exemplo, UDM_CASE) e vinculado ao item do documento contábil. Coleta Capturado a partir da data e hora de criação do registro do caso de contestação vinculado à fatura. Tipo de evento explicit | |||
| Data de vencimento do pagamento atingida | 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: ele é derivado dos dados da fatura. | ||
| Por que isso importa Este evento fornece uma referência essencial para medir o desempenho dos pagamentos em dia e analisar o comportamento de pagamento dos clientes. Ele ajuda a diferenciar pagamentos feitos no prazo daqueles feitos com atraso. Onde encontrar Calculado com base na data-base de pagamento (BSEG-ZFBDT) e nas condições de pagamento armazenadas no item do cliente no documento contábil. Coleta Derivado da soma dos dias previstos nas condições de pagamento à data-base de pagamento registrada no item do documento contábil (BSEG). Tipo de evento calculated | |||
| Fatura cancelada | Ocorre quando uma fatura já criada é cancelada, geralmente com a criação de um documento de cancelamento correspondente. Isso reverte 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 importantes nas etapas anteriores, como o lançamento do pedido de venda ou a configuração do faturamento. Onde encontrar Capturado quando um documento de faturamento de cancelamento é criado (por exemplo, do tipo 'S1'). Esse novo documento na VBRK faz referência ao número da fatura original no campo VBRK-SFAKN. Coleta O evento é capturado a partir da data de criação, na VBRK, do documento de cancelamento que faz referência à fatura original. Tipo de evento explicit | |||
| Fatura enviada ao cliente | Esta atividade marca o envio da fatura ao cliente, por exemplo, por impressão, e-mail ou EDI. A forma de captura depende da configuração de gerenciamento de saída no SAP. | ||
| Por que isso importa É quando começa oficialmente a contagem do prazo de pagamento para o cliente. Atrasos no envio da fatura afetam diretamente o prazo médio de recebimento de vendas (DSO) e o fluxo de caixa. Onde encontrar Pode ser registrado explicitamente nas tabelas de controle de saída, como NAST para métodos mais antigos ou seu equivalente no S/4HANA. Se não houver registro explícito, geralmente se infere que o envio ocorreu ao mesmo tempo que o “Lançamento da fatura na contabilidade”. Coleta Verifique os logs de processamento nas tabelas de gerenciamento de saída para encontrar a data e a hora associadas 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 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 na qualidade dos dados ou na gestão de crédito. Onde encontrar 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' (documento de faturamento bloqueado para encaminhamento à FI) indica um bloqueio. Coleta Inferido pela verificação do valor do campo de status de lançamento (VBRK-RFBSK) logo após a emissão da fatura. Tipo de evento inferred | |||
| Nota de crédito criada | Esta atividade representa a criação de uma nota de crédito, emitida para corrigir uma cobrança excessiva ou conceder crédito por mercadorias devolvidas. Muitas vezes, ela está vinculada a uma fatura original. | ||
| Por que isso importa Destaca problemas que levam a ajustes financeiros após o faturamento. Analisar as notas de crédito pode revelar erros de preço, problemas com produtos ou outras causas raiz de perda de receita. Onde encontrar Criado explicitamente como um novo documento de faturamento na VBRK, com um tipo específico para notas de crédito (por exemplo, 'G2'). Muitas vezes, faz referência ao pedido de venda ou à fatura original. Coleta 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 no faturamento identificado | Evento calculado que identifica um ciclo de retrabalho: uma fatura é cancelada e, em seguida, outra é emitida para o mesmo pedido de venda. Não corresponde a uma única transação, mas a um padrão de eventos. | ||
| Por que isso importa Contribui diretamente para o KPI de taxa de retrabalho no faturamento, quantificando as ocorrências de correção. Isso ajuda a identificar ineficiências e medir o custo da baixa qualidade no processo de faturamento. Onde encontrar Este padrão é calculado pela identificação de um evento “Fatura cancelada” seguido de um novo evento “Fatura emitida”, ambos vinculados ao mesmo documento de origem, como um número de pedido de venda. Coleta Derivado da detecção de uma sequência de “Fatura cancelada” e “Fatura emitida” para a mesma referência de pedido de venda. Tipo de evento calculated | |||
Guias de extração
Etapas
- Pré-requisitos: Tenha uma conta de usuário no SAP S/4HANA com as autorizações necessárias para consultar as views do Core Data Services (CDS). Você precisa, especificamente, 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: Entre 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 plugin SAP Analysis for Microsoft Excel. Neste guia, vamos considerar o uso de um cliente SQL padrão.
- Identifique os parâmetros do sistema: Antes de executar a consulta, identifique os códigos de empresa específicos e o período relevante para a análise. Para começar, recomendamos limitar o escopo, por exemplo, aos 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, disponível na seção 'query' deste documento, para o cliente SQL escolhido.
- Personalize os valores de exemplo: Altere os valores de exemplo na consulta. Substitua
'YYYY-MM-DD'pelas datas de início e fim desejadas. Substitua'XXXX'pelo(s) código(s) de empresa desejado(s). Talvez também seja necessário ajustar o valor de exemplo dos tipos de documento de nota de crédito, como'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 os resultados. O conjunto retornado deve ser uma tabela simples, em que cada linha representa uma atividade do processo de faturamento. Esse é seu Event Log.
- Transformação dos dados (se necessário): A consulta foi criada para gerar um Event Log em um formato organizado. Mesmo assim, confira se o formato do timestamp é compatível com sua ferramenta de Process Mining. A consulta usa
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpara converter os valores para um timestamp UTC padrão, amplamente compatível. - Exporte o Event Log: Exporte todo o conjunto de resultados do cliente SQL para um arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres.
- Carregue os dados no ProcessMind: Carregue o arquivo CSV gerado na plataforma ProcessMind e mapeie as colunas do arquivo, como InvoiceNumber, ActivityName e EventTime, para os campos correspondentes na ferramenta.
Configuração
- Período: Defina as datas de início e fim na cláusula
WHEREda expressão de tabela comum (CTE) inicial. Para a análise inicial, recomendamos um período de 3 a 6 meses, equilibrando o volume de dados e a performance. O filtro usaBillingDocumentDate. - Código da empresa: Filtre por um ou mais valores de
CompanyCodepara limitar a extração às entidades legais relevantes. Esse filtro é essencial para controlar o escopo dos dados. - Tipos de documento: A consulta identifica notas de crédito com base em
BillingDocumentType. Configure o valor de exemplo, por exemplo,('G2', 'CR'), com os tipos de documento usados para notas de crédito na sua organização. - Pré-requisitos: É obrigatório ter acesso às CDS Views subjacentes. Para isso, a equipe de segurança do SAP precisa atribuir funções e autorizações específicas. Além disso, atividades como 'Customer Dispute Opened' ou 'Payment Reminder Issued' exigem que os respectivos módulos SAP, SAP Dispute Management e SAP Financials Dunning, estejam em uso no 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 dos horários de pico ou aplicar filtros mais restritivos para limitar a extração inicial.
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 esquema SAP HANA que contém as tabelas de faturamento e as tabelas financeiras relacionadas. Solicite ao responsável pelo sistema o nome do esquema, os detalhes de conexão, o período autorizado, o escopo dos códigos de empresa, os tipos de documento de faturamento e os filtros de cliente ou região. Substitua apenas os valores de conexão e os filtros de exemplo na consulta.
- Confirme as fontes de dados relevantes do SAP S/4HANA e o mapeamento dos campos no sistema de destino. A consulta usa VBRK e VBRP para os dados de faturamento e requer fontes configuradas para contabilidade, gerenciamento de saídas, gerenciamento de disputas, cobrança, pagamentos recebidos, compensação e relações entre documentos. Substitua os valores de exemplo entre colchetes para fontes e campos somente depois de validá-los no dicionário de dados do sistema.
- Configure o período de extração com um timestamp inicial inclusivo e um timestamp final exclusivo. Para a execução inicial, recomendamos um período de três a seis meses. Limite a extração por código de empresa e, quando apropriado, por tipo de faturamento para controlar o volume e evitar misturar processos de faturamento diferentes.
- Execute a consulta com um usuário de banco de dados HANA somente de leitura. A consulta cria uma linha de evento para cada atividade extraída explicitamente. Ela não depende do ProcessMind para inferir eventos. Atividades calculadas, incluindo Payment Due Date Reached e Billing Rework Identified, são geradas pela lógica SQL e retornadas como linhas.
- Valide o esquema 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 dos eventos e as relações entre eles. Compare as linhas de Invoice Generated com os dados de criação do cabeçalho de faturamento, as linhas de Invoice Posted To Accounting com o status de lançamento contábil, as linhas de 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 que dependem de valores de exemplo antes de usar a consulta em produção.
- Normalize os resultados para o ProcessMind. Mantenha uma linha por evento, use um tipo de timestamp e um fuso horário consistentes, preserve InvoiceNumber como texto para manter os zeros à esquerda e garanta que os valores de ActivityName correspondam exatamente aos nomes de atividade exigidos. Ordene por InvoiceNumber e EventTime e use uma ordenação secundária determinística se vários eventos tiverem o mesmo timestamp.
- Exporte os resultados 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, carregue o arquivo pelo processo de importação configurado do ProcessMind e confira a contagem final 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. Mantenha o valor como texto, pois os números de documentos SAP podem começar com zeros.
- 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, disputas, cobrança, pagamentos, compensação e fluxo de documentos precisam ser configuradas de acordo com a versão implantada do SAP S/4HANA e os módulos habilitados. Substitua as referências de fonte entre colchetes por objetos e campos validados.
- Eventos calculados: Payment Due Date Reached é derivado dos dados de condições de pagamento e vencimento. Billing Rework Identified é derivado de padrões de cancelamento e geração posterior de faturas. Esses eventos são linhas geradas por SQL, não registros transacionais nativos.
- Performance: Aplique filtros de data, código de empresa, tipo de faturamento e número de documento em cada consulta às fontes. Selecione apenas as colunas necessárias, evite junções sem restrições com tabelas contábeis grandes, processe o período em lotes mensais ou semanais e use os planos de execução do banco de dados para identificar junções custosas.
- Extração incremental: Use um marco estável baseado nos timestamps de criação ou lançamento da fonte. Reprocesse um pequeno período de sobreposição para capturar registros de saída, pagamento, disputa e compensação que chegarem com atraso. Depois, remova duplicatas 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 esquema HANA. Confirme se a política de segurança da organização permite acesso direto ao banco de dados e se 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 disputas, cobrança, pagamentos recebidos e compensação só estarão disponíveis se esses recursos estiverem configurados e em uso no sistema. Se módulos ou registros de origem estiverem ausentes, as atividades correspondentes também estarão ausentes, sem inferência de eventos.
- Fuso horário: Padronize os timestamps de acordo com o fuso horário exigido pelo ProcessMind. Documente se os timestamps de origem estão em UTC, no horário local do sistema ou em outro fuso horário configurado.
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 agilizar a preparação dos dados e começar a otimizar seu processo de Order to Cash - faturamento e emissão de notas fiscais. Transforme hoje os dados do SAP S/4H4ANA em insights acionáveis.
Otimize o faturamento de Order to Cash e acelere o fluxo de caixa em 30%
Elimine ineficiências e reduza em 30% o tempo do ciclo de faturamento a partir de hoje.
Não é necessário informar cartão de crédito. Comece em poucos minutos.