Template de dados: Pedido ao Recebimento - Processamento de Pedido de Vendas
Seu Template de dados de Order to Cash - Processamento de Pedidos de Venda
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientações de extração do SAP ECC
Pedido à Cobrança - Atributos de Processamento de Pedido de Vendas
| Nome | Descrição | ||
|---|---|---|---|
Pedido de venda SalesOrder | O identificador único do documento de pedido de venda, que serve como case principal para acompanhar todo o processo Order to Cash. | ||
Descrição O Pedido de Venda é o documento central do processo de vendas, representando a solicitação do cliente por produtos ou serviços. Ele reúne todas as informações necessárias para processar essa solicitação do início ao fim. Em Process Mining, esse atributo é usado como o Case ID. Cada número de Pedido de Venda único representa uma instância ponta a ponta do processo. Analisar por Pedido de Venda permite acompanhar todo o ciclo de vida, medir tempos de ciclo e identificar variações para cada pedido do cliente. Por que é importante É a chave essencial para conectar todas as atividades e eventos relacionados, permitindo uma análise ponta a ponta completa da jornada de cada pedido do cliente. Onde obter Encontrado na tabela de cabeçalho do documento de vendas (VBAK) como o campo VBELN. Exemplos 900001234590000123469000012347 | |||
Atividade Activity | O nome de uma etapa de negócio específica ou de um evento ocorrido no processo de pedido de venda. | ||
Descrição Este atributo descreve uma etapa do processo Order to Cash (O2C), como 'Sales Order Created', 'Delivery Created' ou 'Payment Received'. Essas atividades são os blocos usados para reconstruir o fluxo de processo de cada pedido de venda. Analisar a sequência e o tempo dessas atividades é o núcleo do Process Mining. Isso ajuda a visualizar o mapa do processo, identificar gargalos, descobrir variantes e verificar a conformidade frente a um modelo padrão. As atividades normalmente são derivadas da combinação de eventos de criação de documentos, mudanças de status ou códigos de transação específicos registrados no sistema. Por que é importante As atividades são a espinha dorsal do mapa do processo, permitindo visualizar e analisar o fluxo, os desvios e os gargalos. Onde obter Atributo derivado, geralmente criado durante a extração de dados ao mapear códigos de transação do SAP (T-Codes), mudanças de status de documentos (ex.: tabelas VBUK, VBUP) ou logs de alteração (tabelas CDHDR, CDPOS) para nomes de atividades fáceis de entender. Exemplos Pedido de venda criadoEntrega criadaSaída de mercadoriasFatura CriadaPagamento Recebido | |||
Hora de Início StartTime | O timestamp que indica quando uma atividade ou evento começou. | ||
Descrição O Start Time, também conhecido como timestamp do evento, registra a data e a hora exatas em que uma atividade específica ocorreu. Por exemplo, captura quando um pedido de venda foi criado, quando houve a saída de mercadorias ou quando uma fatura foi lançada. Esse timestamp é a base de toda análise temporal em Process Mining. Ele é usado para calcular tempos de ciclo entre atividades, medir a duração total de um case e identificar atrasos ou gargalos. Timestamps precisos são críticos para Dashboards de performance, como os que monitoram entrega no prazo ou lead time de atendimento. Por que é importante Atributo crítico para calcular todas as métricas de performance, como tempos de ciclo e durações, essenciais para identificar gargalos. Onde obter Atributo composto, normalmente obtido pela combinação de um campo de data (ex.: ERDAT) com um campo de hora (ex.: ERZET) em tabelas do SAP como VBAK (Pedido de Venda), LIKP (Entrega) e VBRK (Fatura). Exemplos 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
Sistema de Origem SourceSystem | Identifica o sistema de origem do qual os dados foram extraídos. | ||
Descrição Este atributo informa o sistema de origem, por exemplo, o nome de uma instância específica do SAP ECC ou o número do mandante (client). Ele dá contexto aos dados, especialmente em ambientes com vários sistemas produtivos ou dados de sistemas legados. Nas análises, é usado para filtrar ou segmentar dados pela sua origem. É particularmente útil para comparar processos entre sistemas diferentes ou em projetos de migração, garantindo a integridade e a consistência dos dados. Por que é importante Fornece contexto essencial, especialmente em ambientes com múltiplos sistemas, permitindo comparar processos e garantindo a rastreabilidade dos dados. Onde obter Valor normalmente adicionado durante a extração de dados e, em geral, é estático, representando o SAP System ID (SAPSID) ou o mandante (MANDT). Exemplos ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
Última Atualização de Dados LastDataUpdate | Timestamp que indica quando os dados deste registro foram atualizados pela última vez no sistema de origem. | ||
Descrição Este atributo registra a data e a hora da extração de dados ou atualização mais recente para um evento ou caso. Ele traz transparência sobre a atualidade dos dados analisados. Em dashboards e relatórios, essa informação é crucial para que os usuários entendam a atualidade dos insights. Ajuda a confirmar se a análise reflete o estado mais recente das operações ou se está baseada em dados antigos, alinhando as expectativas dos usuários quanto à recência dos dados. Por que é importante Garante que os usuários saibam quão atualizados estão os dados, algo crítico para decisões rápidas e bem embasadas com base na análise de Process Mining. Onde obter Atributo de metadado preenchido pela ferramenta ou processo de extração no momento da ingestão. Não é armazenado nas tabelas de origem do SAP. Exemplos 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
Bloqueio de entrega DeliveryBlock | Um código que indica se um pedido de venda está bloqueado para entrega, impedindo a criação do documento de entrega. | ||
Descrição O Bloqueio de Entrega é um status aplicado a um pedido de venda (no cabeçalho ou no item) para interromper temporariamente o processo antes da etapa de entrega. Os bloqueios podem ser definidos manualmente por um usuário ou automaticamente pelo sistema por motivos como estouro do limite de crédito ou dados incompletos. Esse atributo é fundamental para o Dashboard 'Análise de Bloqueios e Retrabalho em Pedidos de Venda'. Analisar a frequência, a duração e os motivos dos bloqueios de entrega ajuda a identificar os principais gargalos no atendimento. Reduzir esses bloqueios é chave para melhorar a entrega no prazo e o tempo de ciclo geral. Por que é importante Identifica diretamente gargalos no processo de atendimento. Analisar por que e com que frequência os pedidos são bloqueados é crucial para melhorar a eficiência do fluxo. Onde obter Encontrado na tabela de cabeçalho do documento de vendas (VBAK) como o campo LIFSK. Exemplos 0102Z1 | |||
Motivo da Rejeição RejectionReason | Um código que indica o motivo pelo qual um item do pedido de venda foi rejeitado ou cancelado. | ||
Descrição O Motivo de Rejeição explica por que um pedido de venda ou um item específico não foi atendido. Pode ser cancelamento do cliente, indisponibilidade de produto ou outros motivos de negócio. Esse atributo é essencial para o Dashboard 'Tendências de Cancelamento de Pedidos de Venda'. Ao analisar os motivos de rejeição mais comuns, a empresa identifica as causas raiz de vendas perdidas. Esses insights apoiam melhorias na gestão de estoque, na estratégia de preços ou na comunicação com o cliente para reduzir a taxa de cancelamento de pedidos. Por que é importante Mostra o motivo por trás dos cancelamentos de pedidos, permitindo análise de causa raiz para reduzir perdas de vendas e melhorar a precisão das previsões. Onde obter Encontrado na tabela de itens do documento de vendas (VBAP) como o campo ABGRU. Exemplos 0215Z5 | |||
Número do cliente CustomerNumber | O identificador único do cliente que fez o pedido de venda. | ||
Descrição Este atributo representa o 'Sold-to Party', a conta de cliente principal associada ao pedido de venda. Ele vincula a transação a um cliente específico nos dados mestres. Analisar por número do cliente permite segmentar o processo para entender comportamentos e desempenho por cliente. Ajuda a responder perguntas como quais clientes têm os maiores tempos de ciclo, maiores taxas de retrabalho ou mais alterações de pedido. Isso é crucial para melhorar o relacionamento com o cliente e os níveis de serviço. Por que é importante Permite uma análise centrada no cliente, ajudando a identificar problemas de processo que afetam clientes específicos e a medir o desempenho por cliente. Onde obter Encontrado na tabela de cabeçalho do documento de vendas (VBAK) como o campo KUNNR. Exemplos 100234100567200112 | |||
Número do Material MaterialNumber | O identificador único do produto ou serviço vendido. | ||
Descrição O Número do Material identifica o item específico em uma linha do pedido de venda. Como um único pedido pode conter vários materiais, esse atributo normalmente é analisado no nível do item. Analisar o processo por Número do Material ajuda a revelar problemas específicos de produto. Pode mostrar se determinados produtos estão associados a prazos de atendimento mais longos, taxas mais altas de bloqueio de entrega ou divergências de faturamento mais frequentes. Isso é crucial para que a cadeia de suprimentos e a gestão de produtos otimizem o processo para as diferentes linhas de produto. Por que é importante Permite analisar o processo por produto, revelando quais produtos estão associados a ineficiências como atrasos, bloqueios ou retrabalho. Onde obter Encontrado na tabela de itens do documento de vendas (VBAP) como o campo MATNR. Exemplos FG-1001-ARAW-205BSERV-INSTALL | |||
Organização de vendas SalesOrganization | A unidade organizacional responsável pela venda de produtos ou serviços. | ||
Descrição Uma Organização de Vendas é uma entidade organizacional fundamental no SAP que estrutura a empresa de acordo com suas necessidades de vendas. Ela é responsável por negociar condições comerciais e distribuir bens e serviços. No Process Mining, esse atributo é uma dimensão crítica de análise. Ele permite comparar o desempenho do processo, a eficiência e a conformidade entre diferentes unidades, regiões ou divisões de vendas. Isso ajuda a identificar boas práticas em organizações de alto desempenho e oportunidades de melhoria nas demais. Por que é importante Permite fazer benchmarking organizacional, comparando eficiência do processo e conformidade entre diferentes unidades de negócio ou regiões. Onde obter Encontrado na tabela de cabeçalho do documento de vendas (VBAK) como o campo VKORG. Exemplos 100025003100 | |||
Tempo de ciclo do pedido de venda SalesOrderCycleTime | A duração total desde a criação do pedido de venda até seu encerramento ou pagamento. | ||
Descrição Essa métrica calculada mede o tempo de processamento ponta a ponta de um único pedido de venda. Normalmente é apurada como a diferença entre o timestamp da primeira atividade ('Sales Order Created') e o da última atividade (por exemplo, 'Payment Received' ou 'Order Item Closed'). Essa é a principal medida do dashboard 'Tempo de Ciclo Ponta a Ponta do Pedido de Venda' e do KPI de Tempo de Ciclo de Atendimento do Pedido de Venda. Ela oferece uma visão de alto nível da eficiência do processo e é fundamental para identificar pedidos com maior duração e avaliar a saúde geral do processo. Analisar a distribuição dessa métrica ajuda a definir referências e acompanhar o impacto das iniciativas de melhoria ao longo do tempo. Por que é importante KPI principal para medir velocidade e eficiência do processo, oferecendo uma linha de base crítica para iniciativas de melhoria. Onde obter Esta é uma métrica calculada derivada do Event Log, obtida pela diferença entre o StartTime máximo e o mínimo para um determinado SalesOrder. Exemplos 10 days 4 hours25 dias 11 horas5 dias 2 horas | |||
Utilizador User | O ID de usuário do colaborador que criou ou alterou por último o documento ou executou a atividade. | ||
Descrição Este atributo registra o ID do usuário do SAP responsável por um evento específico no processo. Por exemplo, identifica o atendente de vendas que criou o pedido ou a equipe do armazém que registrou a saída de mercadorias. Analisar o processo por usuário ajuda a entender a distribuição da carga de trabalho, identificar necessidades de treinamento e detectar variações na forma como diferentes usuários executam a mesma tarefa. É essencial para dashboards focados em desempenho dos recursos, conformidade e identificação de intervenções manuais. Por que é importante Gera visibilidade sobre desempenho e carga de trabalho por recurso, ajuda a identificar desvios por usuário e é fundamental para análises de conformidade e automação. Onde obter Encontrado em muitas tabelas de cabeçalho do SAP como o campo 'Criado por' (ERNAM) ou 'Alterado por' (AENAM), por exemplo em VBAK, LIKP e VBRK. Exemplos CBURKEJSMITHRWILLIAMS | |||
Valor Líquido NetAmount | O valor total do pedido de venda, excluindo impostos e descontos no nível do cabeçalho. | ||
Descrição O Valor Líquido representa o valor monetário do pedido de vendas. É um indicador financeiro-chave associado a cada instância do processo. Esse atributo é essencial para o Process Mining orientado por valor. Ele permite priorizar iniciativas de melhoria focando nos pedidos de maior valor. Os analistas podem correlacionar problemas do processo, como atrasos ou retrabalho, com o impacto financeiro, ajudando a construir um caso de negócio mais robusto para a mudança. Por exemplo, é possível analisar se pedidos de alto valor são processados com mais ou menos eficiência do que pedidos de baixo valor. Por que é importante Permite uma análise baseada em valor, ajudando a priorizar esforços de melhoria nos pedidos com maior impacto financeiro para a empresa. Onde obter Encontrado na tabela de cabeçalho do documento de vendas (VBAK) como o campo NETWR. Exemplos 1500.0012550.75850.50 | |||
Condições de expedição ShippingConditions | Define a estratégia geral de expedição para a entrega de mercadorias ao cliente. | ||
Descrição As Condições de expedição determinam como um pedido será enviado, por exemplo, 'Padrão', 'Expresso' ou 'Retirada'. Isso é acordado com o cliente e influencia o planejamento logístico. Esse atributo é usado na análise 'Eficiência e Custo do Método de Envio'. Ao segmentar o processo pelas condições de expedição, é possível avaliar se certos métodos são mais propensos a atrasos ou têm tempos de ciclo mais longos. Esses dados ajudam a otimizar a logística e a gerenciar as expectativas do cliente quanto a prazos de entrega. Por que é importante Permite analisar o desempenho logístico, ajudando a identificar se certas modalidades de envio se correlacionam com atrasos ou maior eficiência. Onde obter Encontrado na tabela de cabeçalho do documento de vendas (VBAK) como o campo VSBED. Exemplos 011020 | |||
Data de entrega confirmada ConfirmedDeliveryDate | Data em que a entrega dos produtos ou serviços foi confirmada ao cliente. | ||
Descrição É a data de entrega prometida ao cliente, baseada na disponibilidade de material e no planejamento. Serve como base para medir a performance de entrega. Esse atributo é a base do dashboard 'On-Time Delivery Performance' e do KPI On-Time Delivery Rate. Ao comparar a Confirmed Delivery Date com a data real de 'Goods Issued', a análise permite verificar se o pedido foi entregue no prazo, adiantado ou atrasado. É uma medida primária de confiabilidade da cadeia de suprimentos e de satisfação do cliente. Por que é importante Referência para medir a performance de entrega no prazo, um KPI crítico para satisfação do cliente e eficiência da cadeia de suprimentos. Onde obter Encontrado na tabela de linhas de programação do documento de vendas (VBEP) como o campo EDATU. Exemplos 2023-05-102023-06-202023-07-01 | |||
É Retrabalho IsRework | Um indicador booleano que sinaliza se um pedido de venda passou por alteração significativa ou retrabalho após a criação inicial. | ||
Descrição Este atributo calculado identifica instâncias do processo que passaram por retrabalho, como uma ou mais atividades 'Sales Order Changed'. A lógica do que caracteriza retrabalho — por exemplo, alteração de preço, quantidade ou data de entrega — é definida na configuração do projeto. Esse atributo é vital para o dashboard 'Retrabalho e Frequência de Alterações em Pedidos de Venda' e para o KPI de Taxa de Retrabalho em Pedido de Venda. Ele simplifica a análise ao permitir filtrar e comparar diretamente pedidos que seguiram um caminho direto, sem intervenção, versus aqueles que exigiram alterações manuais. Isso ajuda a quantificar o impacto do retrabalho nos tempos de ciclo e nos custos. Por que é importante Quantifica diretamente a frequência de retrabalho, permitindo analisar suas causas e seu impacto na eficiência do processo e no tempo de ciclo. Onde obter Este é um atributo calculado derivado do Event Log. A lógica verifica a presença de atividades 'Sales Order Changed' ou de eventos de alteração específicos nas tabelas CDHDR/CDPOS. Exemplos verdadeirofalse | |||
Entrega no Prazo IsOnTimeDelivery | Um indicador booleano que informa se as mercadorias foram expedidas na data confirmada de entrega ou antes. | ||
Descrição Este atributo calculado compara a data real da saída de mercadorias com o 'ConfirmedDeliveryDate' do pedido de venda. Se a saída ocorrer na data confirmada ou antes, o valor é verdadeiro; caso contrário, é falso. Esse atributo simplifica a criação do dashboard 'Desempenho de Entregas no Prazo' e o cálculo do KPI de Taxa de Entrega no Prazo. Ele permite agregar e visualizar o desempenho com facilidade, sem precisar comparar datas a cada análise ou gráfico. É uma medida clara, de leitura rápida, da confiabilidade das entregas. Por que é importante Oferece uma medida clara e simples de desempenho de entrega, facilitando o cálculo do KPI de Taxa de Entrega no Prazo (OTD). Onde obter Este é um atributo calculado. A lógica compara o timestamp da atividade 'Goods Issued' com o valor do atributo 'ConfirmedDeliveryDate'. Exemplos verdadeirofalse | |||
Status da análise de crédito CreditCheckStatus | Indica o status da verificação de crédito do documento de vendas. | ||
Descrição Este atributo mostra o resultado da análise de crédito, automática ou manual, realizada no pedido de venda. Os status mais comuns incluem 'Approved', 'Rejected' ou 'Blocked'. É um atributo-chave para o dashboard 'Tempo de Processamento da Análise de Crédito'. Atrasos ou bloqueios nessa etapa podem impactar significativamente o tempo de ciclo de atendimento do pedido. Analisar esse status ajuda a entender a eficiência da gestão de crédito e seu impacto na velocidade de vendas. Por que é importante Impacta diretamente a velocidade de processamento do pedido. Analisar esse status ajuda a identificar gargalos na gestão de crédito que atrasam o atendimento. Onde obter Encontrado na tabela de status do cabeçalho do documento de vendas (VBUK) ou diretamente em VBAK como o campo de status de crédito (ex.: CMGST). Exemplos ABD | |||
Pedido à Cobrança - Atividades de Processamento de Pedido de Vendas
| Atividade | Descrição | ||
|---|---|---|---|
Fatura Criada | Marca a criação da fatura do cliente (documento de faturamento). É um evento explícito que gera um novo documento no sistema, iniciando a etapa de pagamento do processo. | ||
Por que é importante Marco crucial que inicia a contagem do 'Invoice to Payment Cycle Time'. Atrasos na emissão da fatura impactam diretamente o fluxo de caixa. Onde obter Registrado na tabela VBRK (documento de faturamento: dados de cabeçalho) com base na data de criação (ERDAT). O vínculo com o pedido de venda ou a entrega está na tabela VBFA. Captura Evento baseado na data/hora de criação (ERDAT) na tabela VBRK. Tipo de evento explicit | |||
Item do Pedido Encerrado | Esta atividade marca o encerramento final de um item do pedido de venda, indicando que foi totalmente entregue, faturado e concluído. Isso é inferido pelo status geral do item. | ||
Por que é importante Serve como evento final bem-sucedido do processo. Analisar quando os itens são encerrados ajuda a entender a duração do processo de ponta a ponta e a identificar pedidos que permanecem abertos desnecessariamente. Onde obter Inferido pelo campo de status geral na tabela VBUP (Documento de Vendas: Status do Item) para o item. Quando VBUP-GBSTA é 'C' (Totalmente processado), o item é encerrado. Captura Inferido quando o status do item (VBUP-GBSTA) muda para 'C' (Totalmente processado). Tipo de evento inferred | |||
Pagamento Recebido | Este evento indica que o pagamento do cliente foi recebido e aplicado à fatura, baixando o item em aberto de contas a receber. É um evento contábil, inferido a partir da baixa de um documento financeiro. | ||
Por que é importante Etapa final para converter a venda em caixa. É o ponto de término para medir o 'Invoice to Payment Cycle Time' e o 'Sales Order Fulfillment Cycle Time' geral. Onde obter Inferido pelas informações do documento de compensação na tabela BSEG para o item do cliente. Quando BSEG-AUGBL (Documento de compensação) e BSEG-AUGDT (Data de compensação) estão preenchidos, o pagamento foi recebido. Captura Inferido pelo preenchimento da data de compensação (AUGDT) na tabela BSEG para o item de contas a receber (AR). Tipo de evento inferred | |||
Pedido Confirmado | Esta atividade indica que o pedido de venda passou por todas as verificações iniciais e está confirmado para atendimento. Normalmente, isso é inferido quando o pedido não está mais bloqueado e há quantidades confirmadas nas linhas de programação. | ||
Por que é importante Marco importante que separa a entrada do pedido do atendimento (fulfillment). É o ponto de partida para medir prazos de atendimento e a performance de entrega no prazo. Onde obter Pode ser inferido quando as linhas de programação em VBEP têm quantidade confirmada (BMENG > 0) e o pedido não está bloqueado para entrega (por exemplo, VBUK-LIFSK vazio). Captura Inferido pela confirmação da linha de programação (VBEP-BMENG > 0) e pela remoção de bloqueios no nível do cabeçalho. Tipo de evento inferred | |||
Pedido de venda criado | Marca a criação de um novo documento de pedido de vendas. É um evento explícito, capturado quando o usuário salva um novo pedido, normalmente pela transação VA01 no SAP. | ||
Por que é importante Evento inicial principal do processo Order to Cash (O2C). Analisar seu momento é essencial para medir o tempo de ciclo total e a taxa de entrada de pedidos. Onde obter Registrado na tabela VBAK (dados de cabeçalho do documento de venda) usando a data de criação (ERDAT) e a hora (ERZET). O código da transação é armazenado em VBAK-TCODE. Captura Evento baseado na data/hora de criação (ERDAT, ERZET) na tabela VBAK. Tipo de evento explicit | |||
Saída de mercadorias | Um evento crítico em que a propriedade das mercadorias é transferida e elas saem oficialmente do armazém. Trata-se de um lançamento contábil explícito que cria um documento de material e atualiza o estoque. | ||
Por que é importante Este é o evento de expedição e um marco-chave para medir entrega no prazo e prazos de atendimento. Ele dispara atualizações financeiras e marca o ponto de não retorno no processo de atendimento físico. Onde obter Criação de um documento de material (MKPF/MSEG) com tipo de movimento de saída de mercadorias (ex.: 601), vinculado ao documento de entrega. Captura Criação de um documento de material (MKPF/MSEG) com tipo de movimento de saída de mercadorias, vinculado à entrega. Tipo de evento explicit | |||
Análise de crédito realizada | Indica que a verificação de crédito, automática ou manual, do cliente no pedido de vendas foi concluída. Geralmente é inferido por uma alteração no status geral de crédito do documento. | ||
Por que é importante A verificação de crédito costuma ser um gargalo crítico. Medir o tempo gasto nessa etapa é essencial para a 'Análise do Tempo de Processamento da Verificação de Crédito' e para acelerar o processamento de pedidos. Onde obter Inferido pelos campos de status de crédito na tabela VBUK (Documento de Vendas: Status do Cabeçalho). Uma mudança em VBUK-CMGST de bloqueado para liberado marca essa atividade. Captura Inferido a partir de alterações no campo de status geral de crédito (VBUK-CMGST). Tipo de evento inferred | |||
Bloqueio de entrega aplicado | Representa a aplicação de um bloqueio de entrega ao pedido de venda, impedindo a criação do documento de entrega. Isso pode ser capturado explicitamente nos logs de mudança ou inferido a partir de tabelas de status. | ||
Por que é importante Esta atividade está diretamente relacionada ao KPI 'Taxa de Bloqueio de Pedido de Venda'. Identificar por que e com que frequência os bloqueios são aplicados ajuda a revelar as causas dos atrasos no atendimento. Onde obter Pode ser encontrado nos logs de alteração (CDHDR/CDPOS) para o campo VBAK-LIFSK. Alternativamente, pode ser inferido observando quando o campo VBAK-LIFSK é preenchido. Captura Evento de documentos de alteração para o campo VBAK-LIFSK ou VBAP-LIFSP. Tipo de evento explicit | |||
Comprovante de entrega confirmado | Esta atividade representa a confirmação de que o cliente recebeu a mercadoria. Ela é registrada quando o comprovante de entrega é lançado no sistema, normalmente atualizando o status do documento de entrega. | ||
Por que é importante Este evento fornece a data real da entrega, essencial para medir com precisão a 'On-Time Delivery Rate' em relação à data prometida. Onde obter Inferido quando o status de POD (proof of delivery) em VBUK-PODAT é definido como 'C' (Confirmado). A data de confirmação é armazenada em VLPOD-PODAT. Nem sempre está implementado. Captura Inferido pela atualização do status de POD na entrega (VBUK-PODAT) ou pelo registro na tabela VLPOD. Tipo de evento inferred | |||
Entrega criada | Este evento marca a criação do documento de entrega de saída (outbound delivery), que é a instrução para o armazém iniciar a separação (picking) e a expedição. É um evento explícito capturado a partir do fluxo de documentos. | ||
Por que é importante Primeiro passo do processo de atendimento físico. O tempo entre a confirmação do pedido e a criação da entrega mostra quão rápido o processo logístico é iniciado. Onde obter A criação de um registro na tabela LIKP (Documento SD: Dados de Cabeçalho da Entrega). O vínculo com o pedido de venda é mantido na tabela de fluxo de documentos VBFA. Captura Evento baseado na data/hora de criação na tabela LIKP, vinculado via tabela VBFA. Tipo de evento explicit | |||
Fatura Cancelada | Representa o estorno de um documento de faturamento previamente criado. É uma transação explícita que gera um novo documento de cancelamento para compensar o original. | ||
Por que é importante Monitorar cancelamentos de fatura ajuda a identificar problemas de precificação, divergências de envio ou erros de dados. Isso apoia o KPI 'Invoice Discrepancy Rate'. Onde obter Evento explícito capturado pela criação de um documento de faturamento de cancelamento (VBRK-VBTYP = 'N' ou 'O'). A fatura original é referenciada em VBRK-SFAKN. Captura Criação de um documento de cancelamento em VBRK, referenciando a fatura original. Tipo de evento explicit | |||
Pedido Cancelado | Indica que um pedido de venda foi cancelado antes do atendimento. Normalmente, isso é registrado aplicando um 'motivo de rejeição' a todos os itens relevantes do pedido. | ||
Por que é importante Evento final crítico que sustenta diretamente o KPI 'Order Cancellation Rate'. Entender quando e por que os pedidos são cancelados gera insights sobre problemas no processo de vendas. Onde obter Inferido quando o campo VBAP-ABGRU (Motivo da rejeição) é preenchido para todos os itens ativos em um pedido de vendas. A data da alteração pode ser encontrada em CDHDR/CDPOS. Captura Inferido pelo preenchimento do campo 'Motivo da rejeição' (VBAP-ABGRU) em todos os itens. Tipo de evento inferred | |||
Pedido de venda alterado | Representa uma modificação feita em um pedido de venda existente após sua criação inicial. Essas alterações são registradas nas tabelas de log de mudanças (CDHDR, CDPOS) quando campos como quantidade, preço ou datas são alterados. | ||
Por que é importante Acompanhar as alterações ajuda a identificar retrabalho, instabilidade do processo e problemas de qualidade dos dados. Uma alta frequência de mudanças pode indicar falhas na entrada do pedido e gerar atrasos. Onde obter Obtido nas tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item) para OBJECTCLAS = 'VERKBELEG'. É possível identificar o carimbo de data e hora e o campo alterado. Captura Evento das tabelas de documentos de alteração (CDHDR, CDPOS) para objetos de documento de vendas. Tipo de evento explicit | |||
Separação Concluída | Indica que todos os itens da entrega foram separados fisicamente no armazém. Se o Warehouse Management (WM) estiver em uso, isso pode ser inferido pelo status da ordem de transferência (Transfer Order). | ||
Por que é importante Analisar o tempo de picking ajuda a otimizar as operações de armazém. Atrasos nessa etapa impactam diretamente o prazo de expedição e o ciclo de atendimento. Onde obter Inferido quando o status de separação do item da entrega na tabela LIPS-KOSTA muda para 'C' (totalmente separado). Se o WM estiver ativo, pode ser inferido pela confirmação da Transfer Order (tabelas LTAK/LTAP). Captura Inferido a partir de alteração no status de separação (LIPS-KOSTA) ou pela confirmação da Transfer Order do WM. Tipo de evento inferred | |||
Guias de Extração
Etapas
- Desenvolvimento do programa: Usando a transação SE38 ou SE80, crie um novo programa ABAP executável. Esse programa concentrará toda a lógica de extração.
- Definir a tela de seleção: No programa, crie uma tela de seleção para filtrar os dados. Inclua parâmetros para data de criação do documento de vendas (VBAK-ERDAT), organização de vendas (VBAK-VKORG) e tipo de documento de vendas (VBAK-AUART). Isso torna a extração reutilizável e fácil de manter.
- Declarações de dados: Defina as tabelas internas e estruturas necessárias para armazenar dados de várias tabelas SAP (por exemplo, VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK, BSAD). Defina também a estrutura final de saída do Event Log com os atributos exigidos.
- Selecionar os pedidos de venda base: Escreva a instrução SELECT inicial para buscar cabeçalhos de pedidos de venda (VBAK) e itens (VBAP) conforme os filtros definidos na tela de seleção. Esse será o conjunto principal de casos a serem analisados.
- Extrair o evento de 'Criação': Percorra os registros selecionados de VBAK. Para cada registro, preencha a estrutura do Event Log com a atividade 'Pedido de venda criado', usando VBAK-ERDAT e VBAK-ERZET para o StartTime.
- Extrair eventos do log de mudanças: Selecione registros de CDHDR e CDPOS onde OBJECTCLAS = 'VERKBELEG' para os pedidos selecionados. Analise os resultados para identificar alterações específicas. Por exemplo, uma mudança em VBAK-LIFSK indica 'Bloqueio de entrega aplicado', e uma mudança em VBUK-CMGST indica 'Análise de crédito realizada'. Outras alterações relevantes podem ser registradas como 'Pedido de venda alterado'.
- Extrair dados do fluxo de documentos: Para os pedidos selecionados, consulte a tabela de fluxo de documentos (VBFA). Ela vincula pedidos de venda a documentos subsequentes, como entregas, movimentações de material e faturas. Selecione todos os documentos relacionados para processamento posterior.
- Extrair eventos de entrega e atendimento: Usando os números de entrega obtidos em VBFA, consulte LIKP e LIPS para eventos de 'Entrega criada'. Consulte MKPF e MSEG para documentos de saída de mercadorias (tipo de movimento '601') e capture o evento 'Saída de mercadorias registrada'. Se o Warehouse Management (WM) estiver ativo, consulte LTAK e LTAP para obter o horário de confirmação do último item da ordem de transferência e determinar 'Separação concluída'. Verifique o status do cabeçalho de entrega VBUK-PODAT para 'Comprovante de entrega confirmado'.
- Extrair eventos de faturamento e pagamento: Com os números de fatura de VBFA, consulte VBRK e VBRP para registrar 'Fatura criada' e 'Fatura cancelada' (quando VBRK-FKSTO = 'X'). Para identificar 'Pagamento recebido', relacione a fatura de VBRK ao documento contábil em BKPF e, em seguida, localize o documento de compensação e a data de compensação em BSAD.
- Extrair eventos baseados em status: Use as tabelas de status VBUP (status do item) e VBUK (status do cabeçalho) para inferir eventos de negócio. Por exemplo, um item é considerado 'Item do pedido encerrado' quando VBUP-GBSTA = 'C'. Um pedido é 'Pedido cancelado' quando um 'Motivo de rejeição' (VBAP-ABGRU) é definido para todos os itens relevantes.
- Consolidar e formatar: Una todos os eventos capturados em uma única tabela interna final. Garanta que todos os atributos (SalesOrder, Activity, StartTime, User, etc.) estejam corretamente preenchidos em cada registro de evento. Adicione os carimbos de data e hora de SourceSystem e LastDataUpdate.
- Gerar o arquivo de saída: Use o módulo de função GUI_DOWNLOAD ou o método cl_gui_frontend_services=>gui_download para exportar a tabela interna final para um arquivo CSV na máquina local do usuário. Garanta que o arquivo seja salvo com codificação UTF-8.
Configuração
- Pré-requisitos: Autorizações de desenvolvedor ABAP (por exemplo, acesso à transação SE38) e permissões de leitura para todas as tabelas SAP necessárias, incluindo VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG e BSAD.
- Parâmetros de seleção: O programa deve incluir uma tela de seleção com parâmetros de filtro. Principais parâmetros:
- Intervalo de datas: Intervalo obrigatório da data de criação do pedido de venda (VBAK-ERDAT). Comece com um período recente de 3 a 6 meses para manter o volume de dados administrável.
- Organização de Vendas: Filtre por VBAK-VKORG para focar a análise em unidades de negócio específicas.
- Tipo de Documento de Vendas: Filtre por VBAK-AUART para incluir apenas tipos de pedido relevantes (ex.: pedidos padrão) e excluir outros (ex.: cotações, devoluções).
- Considerações de desempenho: A extração das tabelas de log de alterações (CDHDR, CDPOS) e do fluxo de documentos (VBFA) pode ser muito lenta com grandes volumes de dados. O programa deve ser otimizado para usar campos indexados nas cláusulas WHERE. Para extrações muito grandes, agende a execução como um job em background fora do horário de pico, usando a transação SM36.
- Ativação do log de alterações: Este método depende da funcionalidade de documentos de alteração do SAP. Verifique se o registro de alterações está ativado para elementos de dados-chave (ex.: LIFSK, CMGST, ABGRU). Isso pode ser verificado na transação SCDO para o objeto VERKBELEG.
a Consulta de Exemplo abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM.Etapas
- Pré-requisitos: Garanta que você tenha acesso direto, de somente leitura, ao banco de dados SAP ECC. Você vai precisar de um cliente de banco de dados como DBeaver, SQL Server Management Studio ou Oracle SQL Developer para se conectar e executar consultas.
- Obter o script SQL: Copie a consulta SQL completa fornecida na seção 'query' deste documento.
- Conectar ao banco de dados: Abra seu cliente de banco de dados e estabeleça a conexão com a instância do SAP ECC. Tenha em mãos o endereço do servidor, a porta, o nome do banco de dados e as credenciais de acesso.
- Configurar a consulta: Cole o script SQL em uma nova janela do editor de consultas. Localize a seção de configuração dentro da Common Table Expression (CTE) principal chamada SalesOrders. Substitua os placeholders de data inicial ('{StartDate}'), data final ('{EndDate}'), organizações de vendas ('{SalesOrgs}') e tipos de documento ('{DocTypes}') pelos valores reais da sua análise.
- Executar a consulta: Execute o script SQL configurado. Dependendo do período e do tamanho do seu banco SAP, a consulta pode levar alguns minutos para ser concluída.
- Revisar os resultados: Quando a execução terminar, um conjunto de resultados será exibido. Faça uma verificação rápida para garantir que as colunas esperadas (SalesOrder, Activity, StartTime, etc.) estão presentes e que existem linhas retornadas para várias atividades.
- Exportar os dados: Use a função de exportação do seu cliente de banco de dados para salvar o conjunto de resultados como um arquivo CSV. Dê um nome descritivo, como SAP_O2C_Event_Log.csv.
- Formatar para o ProcessMind: Abra o arquivo CSV em um editor de planilhas. Confira se os cabeçalhos de coluna correspondem exatamente aos atributos exigidos (por exemplo, SalesOrder, Activity, StartTime). Garanta que o formato de data e hora de StartTime e LastDataUpdate esteja consistente e seja compatível com o ProcessMind, como YYYY-MM-DD HH:MI:SS.
- Fazer upload no ProcessMind: Faça o upload do CSV final, já formatado, no seu projeto no ProcessMind para análise.
Configuração
- Intervalo de datas: A consulta usa placeholders ('{StartDate}' e '{EndDate}') para filtrar pedidos de venda pela data de criação (VBAK.ERDAT). Um período típico de análise é de 3 a 6 meses para garantir uma amostra representativa sem sobrecarregar o banco de dados.
- Filtro por Organização de Vendas: Use o placeholder '{SalesOrgs}' para limitar a extração a organizações de vendas específicas (ex.: '1000', '2000'). Isso é essencial para direcionar a análise e melhorar o desempenho da consulta.
- Filtro por Tipo de Documento: Use o placeholder '{DocTypes}' para selecionar tipos específicos de pedidos de venda (ex.: 'OR' para pedido padrão). Isso ajuda a excluir documentos fora do fluxo principal, como entregas sem cobrança ou devoluções.
- Identificador do Sistema de Origem: Um placeholder fixo '{SourceSystemName}' é usado para marcar cada registro com seu sistema de origem. Defina um nome significativo para sua instância do SAP ECC (ex.: SAP_ECC_PRD).
- Compatibilidade com o banco de dados: A função usada para combinar campos de data e hora, [Your DB-specific timestamp function], é um placeholder. Substitua-a pela função correta do seu banco de dados (ex.: TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') para SAP HANA ou CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) para SQL Server).
- Pré-requisitos: Este método exige credenciais de acesso direto ao banco de dados, com permissão de leitura. O usuário do banco precisa ter autorização para acessar todas as tabelas referenciadas na consulta, incluindo VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK e BSAD.
a Consulta de Exemplo sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> '';