Seu Template de dados de Order to Cash: processamento de pedidos de venda
Seu Template de dados de Order to Cash: processamento de pedidos de venda
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração no SAP ECC
Atributos do processamento de pedidos de venda de Order to Cash
| Nome | Descrição | ||
|---|---|---|---|
| Pedido de venda SalesOrder | O identificador exclusivo de um documento de pedido de venda, que funciona como o caso principal para acompanhar todo o processo de Order-to-Cash. | ||
| Descrição O pedido de venda é o documento central do processo de vendas e representa a solicitação de mercadorias ou serviços feita por um cliente. Ele contém todas as informações necessárias para processar a solicitação do cliente do início ao fim. No Process Mining, esse atributo é usado como o Case ID. Cada número exclusivo de pedido de venda representa uma instância de processo de ponta a ponta. Analisar os processos por pedido de venda permite acompanhar todo o ciclo de vida, medir tempos de ciclo e identificar variações em cada pedido individual do cliente. Por que isso importa É a chave essencial para vincular todas as atividades e eventos relacionados, permitindo uma análise completa, de ponta a ponta, da jornada de cada pedido do cliente. Onde obter Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo VBELN. Exemplos 900001234590000123469000012347 | |||
| Atividade Activity | O nome de uma etapa ou evento específico do negócio que ocorreu no processo do pedido de venda. | ||
| Descrição Este atributo descreve uma única etapa do processo de Order-to-Cash, como 'Pedido de venda criado', 'Entrega criada' ou 'Pagamento recebido'. Essas atividades são os blocos básicos usados para reconstruir o fluxo do processo de cada pedido de venda. Analisar a sequência e o momento dessas atividades é o núcleo do Process Mining. Isso ajuda a visualizar o mapa do processo, identificar gargalos, descobrir variantes do processo e verificar a conformidade com um modelo padrão. As atividades normalmente são derivadas de uma combinação de eventos de criação de documentos, alterações de status ou códigos de transação específicos registrados no sistema. Por que isso importa As atividades formam a base do mapa do processo, permitindo visualizar e analisar o fluxo, os desvios e os gargalos do processo. Onde obter Este é um atributo derivado, normalmente gerado durante a extração de dados ao mapear códigos de transação SAP (T-Codes), alterações de status de documentos (por exemplo, das tabelas VBUK e VBUP) ou logs de documentos de alteração (tabelas CDHDR e CDPOS) para nomes de atividades fáceis de entender. Exemplos Sales Order criadoEntrega criadaSaída de mercadoriasFatura criadaPagamento recebido | |||
| Hora de início StartTime | O carimbo de data e hora que indica quando uma atividade ou evento começou. | ||
| Descrição A hora de início, também conhecida como carimbo de data e hora do evento, registra a data e a hora exatas em que uma atividade específica ocorreu. Por exemplo, ela registra quando um pedido de venda foi criado, quando as mercadorias foram lançadas ou quando uma fatura foi contabilizada. Esse carimbo de data e hora é fundamental para todas as análises baseadas em tempo no Process Mining. Ele é usado para calcular os tempos de ciclo entre atividades, medir a duração total de um caso e identificar atrasos ou gargalos. Carimbos de data e hora precisos são essenciais para os Dashboards de análise de performance, como os que monitoram a entrega no prazo ou os prazos de atendimento. Por que isso importa Este é um atributo crítico para calcular todas as métricas de performance, como tempos de ciclo e durações, essenciais para identificar gargalos. Onde obter Este é um atributo composto, normalmente derivado da combinação de um campo de data (por exemplo, ERDAT) e um campo de hora (por exemplo, ERZET) de várias tabelas 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 especifica o sistema de origem, por exemplo, o nome de uma instância específica do SAP ECC ou o número do cliente. Ele fornece contexto para os dados, especialmente em ambientes com vários sistemas de produção ou dados de sistemas legados. Na análise, ele é usado para filtrar ou segmentar os dados com base na origem. Isso é especialmente útil para comparar processos entre sistemas diferentes ou durante projetos de migração, garantindo a integridade e a consistência dos dados. Por que isso importa Fornece contexto essencial, especialmente em ambientes com vários sistemas, permitindo comparar processos e garantir a clareza da linhagem dos dados. Onde obter Esse valor normalmente é adicionado durante o processo de extração de dados e costuma ser um valor estático que representa o ID do sistema SAP (SAPSID) ou o cliente (MANDT). Exemplos ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Última atualização dos dados LastDataUpdate | Carimbo de data e hora que indica quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Este atributo registra a data e a hora da extração ou atualização mais recente dos dados de um determinado evento ou caso. Ele fornece transparência sobre a atualidade dos dados analisados. Em Dashboards e relatórios, essas informações são essenciais para que os usuários entendam a atualidade dos insights. Elas ajudam a confirmar se a análise reflete o estado mais recente das operações ou se é baseada em dados antigos, gerenciando as expectativas dos usuários sobre a recência dos dados. Por que isso importa Garante que os usuários estejam cientes da atualidade dos dados, algo crítico para tomar decisões oportunas e bem fundamentadas com base na análise de Process Mining. Onde obter Este é um atributo de metadados preenchido pela ferramenta ou pelo processo de extração de dados no momento da ingestão. Ele não é armazenado nas tabelas SAP de origem. 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 de um documento de entrega. | ||
| Descrição O bloqueio de entrega é um status definido em um pedido de venda, no nível do cabeçalho ou do 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 devido a motivos como falha no limite de crédito ou dados incompletos. Esse atributo é crítico para o Dashboard de '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 processo de atendimento. Reduzir esses bloqueios é essencial para melhorar a entrega no prazo e o tempo de ciclo geral. Por que isso importa Identifica diretamente os gargalos no processo de atendimento. Analisar por que e com que frequência os pedidos são bloqueados é essencial para melhorar a eficiência do fluxo. Onde obter Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no 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 da rejeição fornece contexto sobre por que um pedido de venda ou uma linha específica não foi atendido. Isso pode ocorrer devido ao cancelamento pelo cliente, à indisponibilidade do produto ou a outros motivos comerciais. Esse atributo é essencial para o Dashboard de 'Tendências de cancelamento de pedidos de venda'. Ao analisar os motivos de rejeição mais comuns, a empresa pode identificar as causas-raiz das vendas perdidas. Esse insight pode orientar 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 isso importa Explica o motivo por trás dos cancelamentos de pedidos, permitindo analisar as causas-raiz para reduzir vendas perdidas e melhorar a precisão das previsões. Onde obter Encontrado na tabela de dados do item do documento de vendas (VBAP), no campo ABGRU. Exemplos 0215Z5 | |||
| Número do cliente CustomerNumber | O identificador exclusivo do cliente que realizou o pedido de venda. | ||
| Descrição Este atributo representa o 'Cliente comprador', a conta principal do cliente 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 a performance específicos de cada cliente. Isso ajuda a responder perguntas como quais clientes têm os maiores tempos de ciclo, as maiores taxas de retrabalho ou as alterações de pedido mais frequentes. Esse recurso é essencial para melhorar a gestão do relacionamento com o cliente e os níveis de serviço. Por que isso importa Permite uma análise centrada no cliente, ajudando a identificar problemas de processo que afetam clientes específicos e a medir a performance de cada cliente. Onde obter Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo KUNNR. Exemplos 100234100567200112 | |||
| Número do material MaterialNumber | O identificador exclusivo de um 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 cada produto. Isso pode mostrar se determinados produtos estão associados a prazos de atendimento mais longos, maiores taxas de bloqueio de entrega ou divergências de faturas mais frequentes. Esse recurso é essencial para a gestão da cadeia de suprimentos e de produtos, permitindo otimizar o processo para diferentes linhas de produtos. Por que isso importa 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 dados do item do documento de vendas (VBAP), no 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 importante no SAP que estrutura a empresa de acordo com suas necessidades de vendas. Ela é responsável por negociar condições de venda e distribuir mercadorias e serviços. No Process Mining, esse atributo é uma dimensão crítica para a análise. Ele permite comparar a performance, a eficiência e a conformidade do processo entre diferentes unidades de vendas, regiões ou divisões. Isso ajuda a identificar boas práticas em organizações de alta performance e áreas de melhoria nas demais. Por que isso importa Permite fazer benchmarking organizacional, comparando a eficiência e a conformidade dos processos entre diferentes unidades de negócio ou regiões. Onde obter Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo VKORG. Exemplos 100025003100 | |||
| Usuário User | O ID do usuário do funcionário que criou ou alterou o documento pela última vez ou executou a atividade. | ||
| Descrição Este atributo registra o ID do usuário SAP responsável por um determinado evento no processo. Por exemplo, ele identifica o vendedor que criou o pedido ou o funcionário do armazém que lançou 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. Ele é essencial para Dashboards focados na performance dos recursos, na conformidade e na identificação de intervenções manuais. Por que isso importa Fornece visibilidade sobre a performance e a carga de trabalho dos recursos, ajuda a identificar desvios específicos de cada usuário e é fundamental para análises de conformidade e automação. Onde obter Encontrado em várias tabelas de cabeçalho 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 venda. Ele é uma métrica financeira importante associada a cada instância do processo. Esse atributo é essencial para o Process Mining baseado em valor. Ele permite priorizar iniciativas de melhoria de processos, concentrando-se em pedidos de alto valor. Os analistas podem correlacionar problemas de processo, como atrasos ou retrabalho, com o impacto financeiro, ajudando a construir um caso de negócio mais sólido para a mudança. Por exemplo, ele pode ser usado para analisar se pedidos de alto valor são processados com mais ou menos eficiência do que pedidos de baixo valor. Por que isso importa Permite uma análise baseada em valor, ajudando a priorizar esforços de melhoria nos pedidos que têm o maior impacto financeiro para a empresa. Onde obter Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo NETWR. Exemplos 1500.0012550.75850.50 | |||
| Condições de expedição ShippingConditions | Define a estratégia geral de expedição das 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 de 'Eficiência e custo do método de expedição'. Ao segmentar o processo por condições de expedição, as empresas podem analisar se determinados métodos estão mais sujeitos a atrasos ou têm tempos de ciclo mais longos. Esses dados ajudam a otimizar a logística e a gerenciar as expectativas dos clientes em relação aos prazos de entrega. Por que isso importa Permite analisar a performance logística, ajudando a determinar se determinados métodos de expedição estão relacionados a atrasos ou a uma maior eficiência. Onde obter Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo VSBED. Exemplos 011020 | |||
| Data de entrega confirmada ConfirmedDeliveryDate | A data em que a entrega das mercadorias ou dos serviços foi confirmada ao cliente. | ||
| Descrição Esta é a data de entrega comprometida com o cliente, com base na disponibilidade de materiais e no planejamento. Ela serve como referência para medir a performance da entrega. Esse atributo é a base do Dashboard de 'Performance de entrega no prazo' e do KPI de Taxa de entrega no prazo. Ao comparar a data de entrega confirmada com a data real de 'Saída de mercadorias', a análise pode determinar se um pedido foi entregue no prazo, antes ou depois do prazo. Essa é uma medida essencial da confiabilidade da cadeia de suprimentos e da satisfação do cliente. Por que isso importa É a referência para medir a performance de entrega no prazo, um KPI crítico para a satisfação do cliente e a eficiência da cadeia de suprimentos. Onde obter Encontrado na tabela de linhas de programação do documento de vendas (VBEP), no campo EDATU. Exemplos 2023-05-102023-06-202023-07-01 | |||
| É entrega no prazo IsOnTimeDelivery | Um indicador booleano que informa se as mercadorias foram expedidas na data de entrega confirmada ou antes dela. | ||
| Descrição Este atributo calculado compara a data real da saída de mercadorias com a 'ConfirmedDeliveryDate' de um pedido de venda. Se a data da saída de mercadorias for igual ou anterior à data confirmada, o valor será verdadeiro; caso contrário, será falso. Esse atributo simplifica a criação do Dashboard de 'Performance de entrega no prazo' e o cálculo do KPI de Taxa de entrega no prazo. Ele permite agregar e visualizar a performance com facilidade, sem precisar comparar datas dinamicamente em cada análise ou gráfico. Assim, oferece uma medida clara e imediata da confiabilidade das entregas. Por que isso importa Fornece uma medida clara e simples da performance de entrega, facilitando o cálculo do KPI geral de Taxa de entrega no prazo. Onde obter Este é um atributo calculado. A lógica compara o carimbo de data e hora da atividade de 'Saída de mercadorias' com o valor do atributo 'ConfirmedDeliveryDate'. Exemplos truefalse | |||
| É retrabalho IsRework | Um indicador booleano que informa se um pedido de venda passou por uma alteração significativa ou atividade de retrabalho após sua criação inicial. | ||
| Descrição Este atributo calculado identifica instâncias de processo que passaram por retrabalho, como uma ou mais atividades de 'Pedido de venda alterado'. A lógica específica que define o retrabalho, por exemplo, uma alteração de preço, quantidade ou data de entrega, é definida durante a configuração do projeto. Esse atributo é essencial para o Dashboard de 'Retrabalho e frequência de alterações em pedidos de venda' e para o KPI de Taxa de retrabalho em pedidos de venda. Ele simplifica a análise ao permitir filtrar e comparar diretamente os pedidos que seguiram um fluxo contínuo com aqueles que exigiram alterações manuais. Isso ajuda a quantificar o impacto do retrabalho nos tempos de ciclo e nos custos. Por que isso importa Quantifica diretamente a frequência do retrabalho, permitindo analisar suas causas e seu impacto na eficiência geral e no tempo de ciclo do processo. Onde obter Este é um atributo calculado derivado do Event Log. A lógica verifica a presença de atividades de 'Pedido de venda alterado' ou de eventos de alteração específicos das tabelas CDHDR/CDPOS. Exemplos truefalse | |||
| Status da verificação 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 verificação de crédito automática ou manual realizada em um pedido de venda. Os status comuns incluem 'Aprovado', 'Rejeitado' ou 'Bloqueado'. Esse é um atributo importante para o Dashboard de 'Análise do tempo de processamento da verificação de crédito'. Atrasos ou bloqueios na etapa de verificação de crédito podem afetar significativamente o tempo de ciclo geral do atendimento do pedido. Analisar esse status ajuda a entender a eficiência do processo de gestão de crédito e seu impacto na velocidade das vendas. Por que isso importa Afeta diretamente a velocidade do processamento dos pedidos. Analisar esse status ajuda a identificar gargalos na gestão de crédito que atrasam o atendimento dos pedidos. Onde obter Encontrado na tabela de status do cabeçalho do documento de vendas (VBUK) ou diretamente na VBAK, como o campo de status de crédito (por exemplo, CMGST). Exemplos ABD | |||
Atividades do processamento de pedidos de venda de Order to Cash
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura criada | Marca a criação da fatura do cliente ou do documento de faturamento. Este é um evento explícito que gera um novo documento no sistema e inicia a etapa de pagamento do processo. | ||
| Por que isso importa Este é um marco crucial que inicia a contagem do 'Tempo de ciclo da fatura ao pagamento'. Atrasos no faturamento afetam diretamente o fluxo de caixa. Onde obter Registrado na tabela VBRK (Documento de faturamento: dados do 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 no registro do carimbo de data e 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 ele foi totalmente entregue, faturado e considerado concluído. Isso é inferido a partir do status geral do item. | ||
| Por que isso importa Funciona como o evento de encerramento 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 sem necessidade. Onde obter Inferido a partir do campo de status geral da tabela VBUP (Documento de vendas: status do item) para o item. Quando VBUP-GBSTA é 'C' (Processado completamente), o item é encerrado. Captura Inferido a partir da alteração do status do item (VBUP-GBSTA) para 'C' (Processado completamente). 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. Trata-se de um evento contábil, inferido a partir da baixa de um documento financeiro. | ||
| Por que isso importa Esta é a etapa final para transformar a venda em caixa. Ela marca o ponto final para medir o 'Tempo de ciclo da fatura ao pagamento' e o 'Tempo de ciclo geral do atendimento do pedido de venda'. Onde obter Inferido a partir das informações do documento de compensação na tabela BSEG para o item de cliente. Quando BSEG-AUGBL (Documento de compensação) e BSEG-AUGDT (Data de compensação) estão preenchidos, o pagamento foi recebido. Captura Inferido a partir do preenchimento da data de compensação (AUGDT) na tabela BSEG para o item de contas a receber. Tipo de evento inferred | |||
| Pedido confirmado | Esta atividade indica que o pedido de venda passou por todas as verificações iniciais e foi confirmado para fulfillment. Normalmente, ela é inferida quando o pedido não está mais bloqueado e tem quantidades confirmadas em suas linhas de programação. | ||
| Por que isso importa Este é um marco importante que separa a entrada do pedido do fulfillment. É o ponto de partida para medir os prazos de fulfillment e a performance de entregas no prazo. Onde obter Pode ser inferido quando as linhas de programação em VBEP têm uma quantidade confirmada (BMENG > 0) e o pedido não está bloqueado para entrega (por exemplo, VBUK-LIFSK está vazio). Captura Inferido a partir da confirmação da linha de programação (VBEP-BMENG > 0) e da remoção dos bloqueios no nível do cabeçalho. Tipo de evento inferred | |||
| Saída de mercadorias | Um evento crítico em que a propriedade das mercadorias é transferida e elas deixam oficialmente o armazém. Trata-se de um lançamento financeiro explícito que cria um documento de material e atualiza o estoque. | ||
| Por que isso importa Este é o evento de 'expedição' e um marco importante para medir a entrega no prazo e os prazos de atendimento. Ele aciona atualizações financeiras e representa um ponto sem retorno no processo físico de atendimento. Onde obter Criação de um documento de material (MKPF/MSEG) com um tipo de movimento de saída de mercadorias (por exemplo, 601), vinculado ao documento de entrega. Captura Criação de um documento de material (MKPF/MSEG) com um tipo de movimento de saída de mercadorias, vinculado à entrega. Tipo de evento explicit | |||
| Sales Order criado | Marca a criação de um novo documento de pedido de venda. Este é um evento explícito, capturado quando um usuário salva um novo pedido, normalmente por meio da transação VA01 no SAP. | ||
| Por que isso importa Este é o principal evento de início do processo Order-to-Cash. Analisar seu momento é essencial para medir o tempo total do ciclo e as taxas de entrada de pedidos. Onde obter Registrado na tabela VBAK (dados do cabeçalho do documento de vendas), usando a data de criação (ERDAT) e o horário (ERZET). O código da transação é armazenado em VBAK-TCODE. Captura Evento baseado no timestamp de criação (ERDAT, ERZET) na tabela VBAK. Tipo de evento explicit | |||
| Bloqueio de entrega definido | Representa uma ação em que um bloqueio de entrega é aplicado ao pedido de venda, impedindo a criação de um documento de entrega. Isso pode ser capturado explicitamente nos logs de alterações ou inferido a partir das tabelas de status. | ||
| Por que isso importa Esta atividade está diretamente relacionada ao KPI 'Sales Order Blockage Rate'. Identificar por que e com que frequência os bloqueios são definidos ajuda a descobrir as causas dos atrasos no fulfillment. Onde obter Pode ser encontrado nos logs de alterações (CDHDR/CDPOS) para o campo VBAK-LIFSK. Como alternativa, pode ser inferido observando quando o campo VBAK-LIFSK é preenchido. Captura Evento proveniente 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 as mercadorias. Ela é registrada quando o comprovante de entrega é lançado no sistema, geralmente atualizando o status do documento de entrega. | ||
| Por que isso importa Este evento fornece a data real da entrega, essencial para medir com precisão a 'Taxa de entrega no prazo' em relação à data prometida. Onde obter Inferido a partir da definição do status do comprovante de entrega (VBUK-PODAT) como 'C' (Confirmado). A data da confirmação é armazenada em VLPOD-PODAT. Isso nem sempre é implementado. Captura Inferido a partir da atualização do status do POD na entrega (VBUK-PODAT) ou de uma entrada na tabela VLPOD. Tipo de evento inferred | |||
| Entrega criada | Este evento marca a criação do documento de entrega de saída, que é a instrução para o armazém iniciar as atividades de separação e expedição. É um evento explícito capturado no fluxo de documentos. | ||
| Por que isso importa Este é o primeiro passo do processo físico de fulfillment. O tempo entre a confirmação do pedido e a criação da entrega indica a rapidez com que o processo logístico é iniciado. Onde obter A criação de um registro na tabela LIKP (dados do cabeçalho da entrega do documento SD). O vínculo com o pedido de venda é mantido na tabela de fluxo de documentos VBFA. Captura Evento baseado no timestamp de criação na tabela LIKP, vinculado por meio da tabela VBFA. Tipo de evento explicit | |||
| Fatura cancelada | Representa a reversão de um documento de faturamento criado anteriormente. Trata-se de uma transação explícita que cria um novo documento de cancelamento para compensar o original. | ||
| Por que isso importa Acompanhar os cancelamentos de faturas ajuda a identificar problemas de preços, divergências na expedição ou erros nos dados. Isso dá suporte ao KPI 'Taxa de divergência de faturas'. Onde obter Um 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 da rejeição' a todos os itens relevantes do pedido. | ||
| Por que isso importa Este é um ponto final crítico de falha que dá suporte direto ao KPI 'Taxa de cancelamento de pedidos'. Entender quando e por que os pedidos são cancelados fornece insights sobre problemas no processo de vendas. Onde obter Inferido a partir do preenchimento do campo VBAP-ABGRU (Motivo da rejeição) para todos os itens ativos de um pedido de venda. 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 | |||
| Sales Order alterado | Representa uma modificação feita em um pedido de venda existente após sua criação inicial. Essas alterações são registradas em tabelas específicas de log de alterações (CDHDR, CDPOS) quando campos como quantidade, preço ou datas são modificados. | ||
| Por que isso importa Acompanhar as alterações ajuda a identificar retrabalho, instabilidade do processo e problemas de qualidade dos dados. Uma alta frequência de alterações pode indicar problemas no processo inicial de entrada do pedido, levando a atrasos. Onde obter Obtido nas tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item) para OBJECTCLAS = 'VERKBELEG'. O timestamp e o campo alterado podem ser identificados. Captura Evento proveniente das tabelas de documentos de alteração (CDHDR, CDPOS) para objetos de documentos de vendas. Tipo de evento explicit | |||
| Separação concluída | Indica que todos os itens da entrega foram fisicamente separados no armazém. Se o Warehouse Management (WM) estiver sendo usado, isso pode ser inferido pelo status da Transfer Order. | ||
| Por que isso importa Analisar o tempo de separação ajuda a otimizar as operações do armazém. Atrasos nessa etapa afetam diretamente o prazo geral de expedição e o ciclo de atendimento. Onde obter Inferido a partir da alteração do status de separação do item da entrega na tabela LIPS-KOSTA para 'C' (separação completa). Se o WM estiver ativo, pode ser inferido pela confirmação da Transfer Order (tabelas LTAK/LTAP). Captura Inferido a partir da alteração do status de separação (LIPS-KOSTA) ou da confirmação da Transfer Order do WM. Tipo de evento inferred | |||
| Verificação de crédito realizada | Indica a conclusão da verificação de crédito automática ou manual do cliente no pedido de venda. Normalmente, isso é inferido a partir de uma alteração no status geral de crédito do documento. | ||
| Por que isso importa A verificação de crédito costuma ser um gargalo crítico. Medir o tempo gasto nessa etapa é essencial para a 'Credit Check Processing Time Analysis' e para acelerar o processamento dos pedidos. Onde obter Inferido a partir dos campos de status de crédito na tabela VBUK (documento de vendas: status do cabeçalho). Uma alteração em VBUK-CMGST de bloqueado para liberado marca esta atividade. Captura Inferido a partir das alterações no campo de status geral de crédito (VBUK-CMGST). 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 conterá 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 gerenciar.
- Declarações de dados: defina as tabelas internas e as estruturas necessárias para armazenar os dados das várias tabelas SAP, como VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK e BSAD. Defina também a estrutura do resultado final do Event Log, de acordo com os atributos necessários.
- Selecionar os pedidos de venda-base: escreva a instrução SELECT inicial para recuperar os cabeçalhos dos pedidos de venda (VBAK) e os itens (VBAP) com base nas entradas da tela de seleção do usuário. Esse será o conjunto de dados principal dos casos a serem analisados.
- Extrair o evento 'Criação': percorra os registros VBAK selecionados. Para cada registro, preencha a estrutura do Event Log com a atividade 'Sales Order Created', usando VBAK-ERDAT e VBAK-ERZET para StartTime.
- Extrair eventos do log de alterações: selecione registros de CDHDR e CDPOS em que OBJECTCLAS seja 'VERKBELEG' para os pedidos de venda selecionados. Percorra os resultados para identificar alterações específicas nos campos. Por exemplo, uma alteração em VBAK-LIFSK indica 'Delivery Block Set', e uma alteração em VBUK-CMGST indica 'Credit Check Performed'. Qualquer outra alteração relevante pode ser registrada como 'Sales Order Changed'.
- Extrair dados do fluxo de documentos: para os pedidos de venda selecionados, consulte a tabela de fluxo de documentos (VBFA). Essa tabela vincula pedidos de venda a documentos subsequentes, como entregas, movimentos de mercadorias e faturas. Selecione todos os documentos relacionados para processamento posterior.
- Extrair eventos de entrega e atendimento: usando os números de documento de entrega da VBFA, consulte LIKP e LIPS para eventos 'Delivery Created'. Consulte MKPF e MSEG para documentos de saída de mercadorias, com tipo de movimento '601', a fim de capturar o evento 'Goods Issued'. Se o Warehouse Management estiver ativo, consulte LTAK e LTAP para encontrar o horário de confirmação do último item da ordem de transferência e determinar 'Picking Completed'. Verifique o status do cabeçalho da entrega VBUK-PODAT para 'Proof of Delivery Confirmed'.
- Extrair eventos de faturamento e pagamento: usando os números de documento de faturamento da VBFA, consulte VBRK e VBRP para capturar os eventos 'Invoice Created' e 'Invoice Cancelled' (quando VBRK-FKSTO = 'X'). Para encontrar 'Payment Received', vincule a fatura da VBRK ao documento contábil na BKPF e, em seguida, encontre o documento de compensação e a data de compensação na 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 'Order Item Closed' quando VBUP-GBSTA é igual a 'C'. Um pedido é 'Order Cancelled' quando um 'Reason for Rejection' (VBAP-ABGRU) é definido para todos os itens relevantes.
- Consolidar e formatar: combine todos os eventos capturados em uma única tabela interna final. Garanta que todos os atributos (SalesOrder, Activity, StartTime, User etc.) estejam preenchidos corretamente para cada registro de evento. Adicione os timestamps 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 no computador local do usuário. Garanta que o arquivo seja salvo com codificação UTF-8.
Configuração
- Pré-requisitos: autorizações de desenvolvedor ABAP, como 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 filtragem. Os principais parâmetros são:
- Intervalo de datas: um intervalo obrigatório para a criação de pedidos de venda (VBAK-ERDAT). Comece com um período recente de 3 a 6 meses para manter o conjunto de dados sob controle.
- Organização de vendas: filtre por VBAK-VKORG para concentrar a análise em unidades de negócio específicas.
- Tipo de documento de vendas: filtre por VBAK-AUART para incluir apenas os tipos de pedido relevantes, como pedidos padrão, e excluir outros, como cotações e devoluções.
- Considerações de performance: a extração das tabelas de log de alterações (CDHDR, CDPOS) e do fluxo de documentos (VBFA) pode ser muito lenta em grandes volumes de dados. O programa deve ser otimizado para usar campos de índice nas cláusulas WHERE. Para extrações muito grandes, programe o programa para ser executado como 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á habilitado para os principais elementos de dados, como LIFSK, CMGST e ABGRU. Isso pode ser verificado pela 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 e somente para leitura ao banco de dados subjacente do SAP ECC. Você precisará de uma ferramenta cliente de banco de dados, como DBeaver, SQL Server Management Studio ou Oracle SQL Developer, para conectar-se e executar consultas.
- Obter o script SQL: copie a consulta SQL completa fornecida na seção 'query' deste documento.
- Conectar-se ao banco de dados: abra o cliente de banco de dados e estabeleça uma conexão com a instância do banco de dados SAP ECC. Você precisará do endereço do servidor, da porta, do nome do banco de dados e das credenciais de login apropriadas.
- 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 valores placeholder da data inicial ('{StartDate}'), da data final ('{EndDate}'), das organizações de vendas ('{SalesOrgs}') e dos tipos de documento ('{DocTypes}') pelos valores reais da sua análise.
- Executar a consulta: execute o script SQL configurado. Dependendo do intervalo de datas e do tamanho do seu banco de dados SAP, a consulta pode levar vários minutos.
- Revisar os resultados: quando a consulta terminar, um conjunto de resultados será exibido. Faça uma verificação rápida dos dados para garantir que ele contenha as colunas esperadas (SalesOrder, Activity, StartTime etc.) e que haja 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ê ao arquivo um nome descritivo, como SAP_O2C_Event_Log.csv.
- Formatar para o ProcessMind: abra o arquivo CSV em um editor de planilhas. Verifique se os cabeçalhos das colunas correspondem exatamente aos atributos exigidos, como SalesOrder, Activity e StartTime. Garanta que o formato de data e hora de StartTime e LastDataUpdate seja consistente e compatível com o ProcessMind, como YYYY-MM-DD HH:MI:SS.
- Carregar no ProcessMind: carregue o arquivo CSV final e formatado no seu projeto do ProcessMind para análise.
Configuração
- Intervalo de datas: a query usa valores de exemplo ('{StartDate}' e '{EndDate}') para filtrar os pedidos de venda com base na data de criação (VBAK.ERDAT). Um período típico de análise é de 3 a 6 meses de dados, garantindo uma amostra representativa sem sobrecarregar o banco de dados.
- Filtro de organização de vendas: use o valor de exemplo '{SalesOrgs}' para limitar a extração a organizações de vendas específicas, como '1000' e '2000'. Isso é fundamental para concentrar a análise e melhorar a performance da query.
- Filtro de tipo de documento: use o valor de exemplo '{DocTypes}' para selecionar tipos específicos de pedidos de venda, como 'OR' para pedido padrão. Isso ajuda a excluir documentos irrelevantes, como entregas gratuitas ou devoluções, do fluxo principal do processo.
- Identificador do sistema de origem: o valor de exemplo codificado '{SourceSystemName}' é usado para identificar o sistema de origem de cada registro. Ele deve ser definido com um nome significativo para sua instância do SAP ECC, como SAP_ECC_PRD.
- Compatibilidade do banco de dados: a função usada para combinar campos de data e hora, [Your DB-specific timestamp function], é um valor de exemplo. Você precisa substituí-la pela função correta para seu banco de dados específico, como 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 banco de dados diretas e somente leitura. O usuário do banco de dados deve ter autorização para acessar todas as tabelas referenciadas na query, 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 <> ''; Pronto para começar?
Desbloqueie todo o potencial do seu processo de Order to Cash: processamento de pedidos de venda usando este Template de dados. Comece hoje sua jornada rumo a uma eficiência otimizada e a um fluxo de caixa mais rápido.
Otimize hoje o processamento de vendas de Order to Cash
Elimine gargalos, reduza o tempo de ciclo em 30% e aumente o fluxo de caixa rapidamente.
Não é necessário cartão de crédito. Configure em poucos minutos.