Seu Template de dados para pedido ao recebimento: processamento de pedidos de venda
Seu Template de dados para pedido ao recebimento: processamento de pedidos de venda
- Atributos recomendados para coleta
- Principais atividades para acompanhar
- Orientações para extração no SAP ECC
Atributos do processo de pedido ao recebimento: processamento de pedidos de venda
| Nome | Descrição | ||
|---|---|---|---|
| Pedido de venda SalesOrder | Identificador exclusivo do documento do pedido de venda, usado como caso principal para acompanhar todo o processo de pedido ao recebimento. | ||
| Descrição O pedido de venda é o documento central do processo de vendas e representa a solicitação de mercadorias ou serviços feita pelo cliente. Ele reúne todas as informações necessárias para atender essa solicitação do início ao fim. Em Process Mining, este atributo é usado como ID do caso. Cada número exclusivo de pedido de venda representa uma instância do processo de ponta a ponta. Analisar os processos por pedido de venda permite acompanhar todo o ciclo de vida, medir os tempos de ciclo e identificar variações em cada pedido de cliente. Por que isso importa É a chave essencial para relacionar todas as atividades e eventos associados, permitindo analisar de ponta a ponta a jornada de cada pedido de cliente. Onde encontrar Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo VBELN. Exemplos 900001234590000123469000012347 | |||
| Atividade Activity | 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 etapa do processo de pedido ao recebimento, como 'Pedido de venda criado', 'Entrega criada' ou 'Pagamento recebido'. Essas atividades são os elementos usados para reconstruir o fluxo do processo de cada pedido de venda. Analisar a sequência e o momento dessas atividades é a base 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. Em geral, as atividades 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 são a base do mapa do processo e permitem visualizar e analisar o fluxo, os desvios e os gargalos. Onde encontrar Este é um atributo derivado, geralmente gerado durante a extração de dados. Para isso, códigos de transação SAP (T-Codes), alterações de status de documentos (por exemplo, nas tabelas VBUK e VBUP) ou registros de alteração (tabelas CDHDR e CDPOS) são associados a nomes de atividades mais claros. Exemplos Pedido de venda criadoEntrega criadaSaída de mercadorias registradaFatura criadaPagamento recebido | |||
| Hora de início StartTime | Data e hora que indicam quando uma atividade ou evento começou. | ||
| Descrição A hora de início, também chamada de data e hora do evento, registra a data e a hora exatas em que uma atividade ocorreu. Por exemplo, indica quando um pedido de venda foi criado, quando as mercadorias tiveram a saída lançada ou quando uma fatura foi lançada. Esse dado é fundamental para todas as análises temporais em 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. Datas e horas precisas são essenciais para os Dashboards de análise de performance, como os que acompanham entregas no prazo ou prazos de atendimento. Por que isso importa Este atributo é essencial para calcular métricas de performance, como tempos de ciclo e durações, que ajudam a identificar gargalos. Onde encontrar Este é um atributo composto, geralmente 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 mandante. Ele dá contexto aos 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 de acordo com a 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 manter clara a linhagem dos dados. Onde encontrar Este valor geralmente é adicionado durante a extração de dados e costuma ser um valor estático que representa o ID do sistema SAP (SAPSID) ou o mandante (MANDT). Exemplos ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam 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 evento ou caso. Assim, você sabe se os dados analisados estão atualizados. Em Dashboards e relatórios, essa informação é essencial para entender a atualidade dos insights. Ela ajuda a confirmar se a análise reflete o estado mais recente das operações ou se usa dados antigos, alinhando as expectativas sobre quando os dados foram atualizados. Por que isso importa Ajuda os usuários a saber se os dados estão atualizados, algo essencial para tomar decisões fundamentadas e no momento certo com base na análise de Process Mining. Onde encontrar Este é um atributo de metadados preenchido pela ferramenta ou pelo processo de extração de dados no momento da ingestão. Ele não fica armazenado nas tabelas SAP de origem. Exemplos 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| Bloqueio de entrega DeliveryBlock | 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 no pedido de venda, no nível do cabeçalho ou do item, para interromper temporariamente o processo antes da etapa de entrega. Um usuário pode definir o bloqueio manualmente, ou o sistema pode aplicá-lo automaticamente por motivos como limite de crédito excedido ou dados incompletos. Este atributo é essencial 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 é fundamental para melhorar as entregas 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 encontrar Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo LIFSK. Exemplos 0102Z1 | |||
| Motivo da rejeição RejectionReason | Código que indica por que um item do pedido de venda foi rejeitado ou cancelado. | ||
| Descrição O motivo da rejeição explica por que um pedido de venda ou um item específico não foi atendido. Isso pode ocorrer por cancelamento do cliente, indisponibilidade do produto ou outros motivos comerciais. Este 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 os clientes para reduzir a taxa de cancelamento de pedidos. Por que isso importa Explica por que os pedidos são cancelados e permite fazer uma análise de causa raiz para reduzir as vendas perdidas e melhorar a precisão das previsões. Onde encontrar Encontrado na tabela de dados do item do documento de vendas (VBAP), no campo ABGRU. Exemplos 0215Z5 | |||
| Número do cliente CustomerNumber | Identificador exclusivo do cliente que fez o pedido de venda. | ||
| Descrição Este atributo representa o cliente principal associado ao pedido de venda, identificado como 'Sold-to Party'. Ele relaciona a transação a um cliente específico nos dados mestres. Analisar os dados por número do cliente permite segmentar o processo e entender o comportamento e a performance de cada cliente. Isso ajuda a responder perguntas como: quais clientes têm os maiores tempos de ciclo, mais retrabalho ou mais alterações nos pedidos? Essa análise é essencial para melhorar o relacionamento com os clientes e o nível de serviço. Por que isso importa Permite analisar o processo com foco no cliente, identificar problemas que afetam clientes específicos e medir a performance de cada um. Onde encontrar Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo KUNNR. Exemplos 100234100567200112 | |||
| Número do material MaterialNumber | 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 pedido pode incluir vários materiais, este atributo costuma ser analisado no nível do item. Analisar o processo por número do material ajuda a identificar problemas específicos de cada produto. Isso pode revelar se determinados produtos estão associados a prazos de atendimento mais longos, mais bloqueios de entrega ou divergências frequentes nas faturas. Essa análise é essencial para que as equipes de cadeia de suprimentos e gestão de produtos otimizem o processo para cada linha de produtos. Por que isso importa Permite analisar os processos por produto e identificar quais estão associados a ineficiências, como atrasos, bloqueios ou retrabalho. Onde encontrar 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 | Unidade organizacional responsável pela venda de produtos ou serviços. | ||
| Descrição A organização de vendas é uma entidade organizacional importante no SAP, que estrutura a empresa de acordo com suas necessidades comerciais. Ela é responsável por negociar as condições de venda e distribuir mercadorias e serviços. Em Process Mining, este atributo é uma dimensão importante para a análise. Ele permite comparar a performance, a eficiência e a conformidade dos processos entre diferentes unidades de vendas, regiões ou divisões. Assim, você pode identificar boas práticas nas unidades com melhor performance e oportunidades de melhoria nas demais. Por que isso importa Permite comparar a eficiência e a conformidade dos processos entre diferentes unidades de negócio ou regiões. Onde encontrar Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo VKORG. Exemplos 100025003100 | |||
| Usuário User | ID do usuário que criou ou alterou o documento pela última vez ou realizou a atividade. | ||
| Descrição Este atributo registra o ID do usuário SAP responsável por um evento específico do processo. Por exemplo, identifica o atendente de vendas que criou o pedido ou a equipe do depósito que lançou a saída das mercadorias. Analisar o processo por usuário ajuda a entender a distribuição da carga de trabalho, identificar necessidades de treinamento e detectar diferenças na forma como cada pessoa executa a mesma tarefa. É essencial para Dashboards que acompanham a performance dos recursos, a conformidade e as intervenções manuais. Por que isso importa Dá visibilidade à performance e à carga de trabalho dos recursos, ajuda a identificar desvios do processo associados a usuários específicos e é importante para análises de conformidade e automação. Onde encontrar Encontrado em várias tabelas de cabeçalho SAP nos campos 'Criado por' (ERNAM) ou 'Alterado por' (AENAM), como VBAK, LIKP e VBRK. Exemplos CBURKEJSMITHRWILLIAMS | |||
| Valor líquido NetAmount | Valor total do pedido de venda, sem impostos nem descontos no nível do cabeçalho. | ||
| Descrição O valor líquido representa o valor monetário do pedido de venda. É uma métrica financeira importante associada a cada instância do processo. Este atributo é essencial para o Process Mining baseado em valor. Ele permite priorizar iniciativas de melhoria com foco nos pedidos de maior valor. Os analistas podem relacionar problemas do processo, como atrasos ou retrabalho, ao impacto financeiro e, assim, embasar melhor a necessidade de mudança. Por exemplo, é possível analisar se pedidos de alto valor são processados com mais ou menos eficiência do que os de baixo valor. Por que isso importa Permite analisar os processos com base no valor e priorizar melhorias nos pedidos com maior impacto financeiro para a empresa. Onde encontrar Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo NETWR. Exemplos 1500.0012550.75850.50 | |||
| Condições de envio ShippingConditions | Define a estratégia geral de envio das mercadorias ao cliente. | ||
| Descrição As condições de envio determinam como um pedido será enviado, por exemplo, por modalidade 'Padrão', 'Expressa' ou 'Retirada'. Elas são acordadas com o cliente e influenciam o planejamento logístico. Este atributo é usado na análise de eficiência e custos dos métodos de envio. Ao segmentar o processo por condição de envio, as empresas podem verificar 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 alinhar as expectativas dos clientes sobre os prazos de entrega. Por que isso importa Permite analisar a performance logística e identificar se determinados métodos de envio estão associados a atrasos ou a maior eficiência. Onde encontrar Encontrado na tabela de dados do cabeçalho do documento de vendas (VBAK), no campo VSBED. Exemplos 011020 | |||
| Data de entrega confirmada ConfirmedDeliveryDate | Data em que a entrega das mercadorias ou dos serviços foi confirmada ao cliente. | ||
| Descrição Esta é a data de entrega acordada com o cliente, definida com base na disponibilidade de materiais e no planejamento. Ela serve de referência para medir a performance das entregas. Este 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 das mercadorias, a análise determina se o pedido foi entregue no prazo, antes ou depois. Essa é uma das principais medidas de confiabilidade da cadeia de suprimentos e de satisfação do cliente. Por que isso importa É a referência para medir a performance das entregas no prazo, um KPI importante para a satisfação do cliente e a eficiência da cadeia de suprimentos. Onde encontrar Encontrado na tabela de linhas de programação do documento de vendas (VBEP), no campo EDATU. Exemplos 2023-05-102023-06-202023-07-01 | |||
| É retrabalho IsRework | Indicador booleano que informa se um pedido de venda passou por uma alteração significativa ou por retrabalho após sua criação. | ||
| Descrição Este atributo calculado identifica as instâncias do processo que passaram por retrabalho, como aquelas com uma ou mais atividades de alteração do pedido de venda. A lógica que define o retrabalho, por exemplo, uma alteração de preço, quantidade ou data de entrega, é estabelecida durante a configuração do projeto. Este 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 desses pedidos. Ele simplifica a análise ao permitir filtrar e comparar diretamente os pedidos que seguiram um fluxo sem interrupções com aqueles que exigiram alterações manuais. Assim, você pode quantificar o impacto do retrabalho nos tempos de ciclo e nos custos. Por que isso importa Quantifica diretamente a frequência do retrabalho e permite analisar suas causas e seu impacto na eficiência geral do processo e no tempo de ciclo. Onde encontrar Este atributo é calculado a partir do Event Log. A lógica verifica se há atividades de alteração do pedido de venda ou eventos de alteração específicos nas tabelas CDHDR/CDPOS. Exemplos truefalse | |||
| Entrega no prazo IsOnTimeDelivery | Indicador booleano que informa se as mercadorias foram enviadas até a data de entrega confirmada. | ||
| Descrição Este atributo calculado compara a data real de saída das mercadorias com a data de entrega confirmada do pedido de venda. Se a saída ocorreu até a data confirmada, o valor é verdadeiro; caso contrário, é falso. Este 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 facilita a agregação e a visualização da performance, sem exigir comparações de datas em cada análise ou gráfico. Assim, você tem uma medida clara e imediata da confiabilidade das entregas. Por que isso importa Oferece uma medida clara e simples da performance das entregas e facilita o cálculo do KPI geral de taxa de entrega no prazo. Onde encontrar Este atributo é calculado comparando a data e hora da atividade de saída das mercadorias com o valor do atributo de data de entrega confirmada. 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 para um pedido de venda. Os status mais comuns incluem 'Aprovado', 'Rejeitado' ou 'Bloqueado'. Este atributo é importante para o Dashboard de análise do tempo de processamento da verificação de crédito. Atrasos ou bloqueios nessa etapa podem aumentar significativamente o tempo de ciclo total 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 de processamento dos pedidos. Analisar este status ajuda a identificar gargalos na gestão de crédito que atrasam o atendimento. Onde encontrar Encontrado na tabela de status do cabeçalho do documento de vendas (VBUK) ou diretamente em VBAK, no campo de status de crédito (por exemplo, CMGST). Exemplos ABD | |||
Atividades do processo de pedido ao recebimento: processamento de pedidos de venda
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura criada | Marca a criação da fatura do cliente ou do documento de faturamento. Este evento explícito gera um novo documento no sistema e dá início à etapa de pagamento do processo. | ||
| Por que isso importa Este marco importante inicia a contagem do tempo de ciclo entre a emissão da fatura e o pagamento. Atrasos no faturamento afetam diretamente o fluxo de caixa. Onde encontrar Registrado na tabela VBRK (documento de faturamento: dados do cabeçalho) com base na data de criação (ERDAT). A relação com o pedido de venda ou a entrega está na tabela VBFA. Coleta Evento baseado no registro da data e hora de criação (ERDAT) na tabela VBRK. Tipo de evento explicit | |||
| Item do pedido encerrado | Esta atividade marca o encerramento definitivo de um item do pedido de venda, indicando que ele foi entregue e faturado por completo e está concluído. Isso é inferido pelo status geral do item. | ||
| Por que isso importa Marca o 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 continuam abertos sem necessidade. Onde encontrar Inferido pelo campo de status geral da tabela VBUP (documento de vendas: status do item). Quando VBUP-GBSTA é 'C' (Processado completamente), o item está encerrado. Coleta Inferido pela mudança 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. É um evento contábil, inferido pela baixa de um documento financeiro. | ||
| Por que isso importa Esta é a etapa final para receber o valor da venda. Ela marca o fim do período usado para medir o tempo de ciclo entre a emissão da fatura e o pagamento e o tempo de ciclo total do atendimento do pedido de venda. Onde encontrar Inferido pelas informações do documento de compensação na tabela BSEG para o item de linha do cliente. Quando BSEG-AUGBL (documento de compensação) e BSEG-AUGDT (data de compensação) estão preenchidos, o pagamento foi recebido. Coleta Inferido pelo preenchimento da data de compensação (AUGDT) na tabela BSEG para o item de linha 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 atendimento. Normalmente, ela é inferida quando o pedido não está mais bloqueado e tem quantidades confirmadas nas linhas de programação. | ||
| Por que isso importa Este é um marco importante que separa a entrada do pedido do atendimento. É o ponto de partida para medir os prazos de atravessamento do atendimento e a performance de entrega no prazo. Onde encontrar 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, quando VBUK-LIFSK está vazio). Coleta 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 | |||
| Pedido de venda criado | Indica a criação de um novo documento de pedido de venda. Esse evento explícito é registrado quando um usuário salva um novo pedido, normalmente pela transação VA01 no SAP. | ||
| Por que isso importa Este é o principal evento de início do processo Order to Cash. Analisar quando ele ocorre é essencial para medir o tempo de ciclo total e o volume de entrada de pedidos. Onde encontrar Registrado na tabela VBAK (dados do cabeçalho do documento de venda), usando a data de criação (ERDAT) e a hora (ERZET). O código da transação fica armazenado em VBAK-TCODE. Coleta Evento baseado no timestamp de criação (ERDAT, ERZET) na tabela VBAK. Tipo de evento explicit | |||
| Saída de mercadorias registrada | Evento crítico em que a propriedade dos produtos é transferida e eles deixam oficialmente o armazém. É um lançamento financeiro explícito que cria um documento de material e atualiza o estoque. | ||
| Por que isso importa Este é o evento de envio e um marco importante para medir as entregas no prazo e os prazos de atravessamento do atendimento. Ele aciona atualizações financeiras e marca um ponto sem retorno no processo de atendimento físico. Onde encontrar 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. Coleta 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 | |||
| Análise de crédito realizada | Indica a conclusão da análise de crédito automática ou manual do cliente associado ao pedido de venda. Normalmente, esse evento é inferido a partir de uma mudança no status geral de crédito do documento. | ||
| Por que isso importa A análise de crédito costuma ser um gargalo crítico. Medir o tempo dessa etapa é essencial para a 'Análise do tempo de processamento da análise de crédito' e para acelerar o processamento dos pedidos. Onde encontrar Inferido a partir dos campos de status de crédito na tabela VBUK (status do cabeçalho do documento de venda). A mudança de VBUK-CMGST de bloqueado para liberado marca esta atividade. Coleta Inferido a partir de alterações no campo de status geral de crédito (VBUK-CMGST). Tipo de evento inferred | |||
| Bloqueio de entrega definido | Representa a ação de aplicar um bloqueio de entrega ao pedido de venda, impedindo a criação de um documento de entrega. Esse evento pode ser registrado explicitamente nos logs de alteração ou inferido a partir das tabelas de status. | ||
| Por que isso importa Esta atividade está diretamente relacionada ao KPI 'Taxa de bloqueio de pedidos de venda'. Identificar por que e com que frequência os bloqueios são definidos ajuda a encontrar as causas dos atrasos no atendimento. Onde encontrar Pode ser encontrado nos logs de alteração (CDHDR/CDPOS) do campo VBAK-LIFSK. Outra opção é inferir o evento observando quando o campo VBAK-LIFSK é preenchido. Coleta Evento obtido nos documentos de alteração do 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 informa a data real da entrega, essencial para calcular com precisão a taxa de entrega no prazo em relação à data prometida. Onde encontrar Inferido quando o status do comprovante de entrega (VBUK-PODAT) é definido como 'C' (Confirmado). A data da confirmação fica armazenada em VLPOD-PODAT. Essa implementação não está presente em todos os sistemas. Coleta Inferido pela atualização do status do comprovante de entrega (VBUK-PODAT) ou por um registro na tabela VLPOD. Tipo de evento inferred | |||
| Entrega criada | Este evento marca a criação do documento de entrega de saída, que instrui o armazém a iniciar as atividades de separação e envio. É um evento explícito registrado no fluxo de documentos. | ||
| Por que isso importa Esta é a primeira etapa do atendimento físico do pedido. 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 encontrar Criação de um registro na tabela LIKP (dados do cabeçalho do documento de entrega). A ligação com o pedido de venda é mantida na tabela de fluxo de documentos VBFA. Coleta Evento baseado no timestamp de criação na tabela LIKP, vinculado por meio da tabela VBFA. Tipo de evento explicit | |||
| Fatura cancelada | Representa o estorno de um documento de faturamento criado anteriormente. Essa transação explícita 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ço, divergências no envio ou erros nos dados. Isso contribui para o KPI de taxa de divergência de faturas. Onde encontrar Evento explícito registrado pela criação de um documento de faturamento de cancelamento (VBRK-VBTYP = 'N' ou 'O'). A fatura original é referenciada em VBRK-SFAKN. Coleta Criação de um documento de cancelamento em VBRK, com referência à fatura original. Tipo de evento explicit | |||
| Pedido cancelado | Indica que um pedido de venda foi cancelado antes do atendimento. Em geral, isso é registrado quando um motivo de rejeição é aplicado a todos os itens relevantes do pedido. | ||
| Por que isso importa Este é um ponto final crítico de falha, que contribui diretamente para o KPI de taxa de cancelamento de pedidos. Entender quando e por que os pedidos são cancelados revela problemas no processo de vendas. Onde encontrar Inferido quando o campo VBAP-ABGRU (motivo da rejeição) está preenchido para todos os itens ativos de um pedido de venda. A data da alteração pode ser consultada em CDHDR/CDPOS. Coleta Inferido pelo preenchimento do campo de motivo da rejeição (VBAP-ABGRU) em todos os itens. Tipo de evento inferred | |||
| Pedido de venda alterado | Representa uma alteração feita em um pedido de venda existente após sua criação inicial. Essas mudanças 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 frequência alta de mudanças pode indicar falhas na entrada inicial do pedido e causar atrasos. Onde encontrar Obtido nas tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item), para OBJECTCLAS = 'VERKBELEG'. É possível identificar o timestamp e o campo alterado. Coleta Evento obtido nas tabelas de documentos de alteração (CDHDR, CDPOS) para objetos de documentos de venda. 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, o evento pode ser inferido pelo status da ordem de transferência. | ||
| 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 cronograma de envio e o ciclo de atendimento. Onde encontrar Inferido quando o status de separação do item de entrega na tabela LIPS-KOSTA muda para 'C' (separação concluída). Se o WM estiver ativo, o evento pode ser inferido pela confirmação da ordem de transferência (tabelas LTAK/LTAP). Coleta Inferido a partir da mudança no status de separação (LIPS-KOSTA) ou da confirmação da ordem de transferência do WM. Tipo de evento inferred | |||
Guias de extração
Etapas
- Desenvolva o programa: Use a transação SE38 ou SE80 para criar um novo programa ABAP executável. Nele ficará toda a lógica de extração.
- Defina a tela de seleção: Crie no programa uma tela para filtrar os dados. Inclua parâmetros para a data de criação do documento de vendas (VBAK-ERDAT), a organização de vendas (VBAK-VKORG) e o tipo de documento de vendas (VBAK-AUART). Assim, a extração poderá ser reutilizada e gerenciada com facilidade.
- Declare os dados: Defina as tabelas internas e estruturas necessárias para armazenar dados de várias tabelas SAP, como VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK e BSAD. Defina também a estrutura final do Event Log, de acordo com os atributos necessários.
- Selecione os pedidos de venda iniciais: Escreva a instrução SELECT inicial para recuperar os cabeçalhos (VBAK) e os itens (VBAP) dos pedidos de venda com base nos parâmetros informados na tela de seleção. Esse será o conjunto de dados de casos a analisar.
- Extraia 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 como StartTime.
- Extraia os eventos do log de alterações: Selecione em CDHDR e CDPOS os registros em que OBJECTCLAS seja 'VERKBELEG' para os pedidos de venda selecionados. Percorra os resultados para identificar alterações em campos específicos. Por exemplo, uma alteração em VBAK-LIFSK indica 'Bloqueio de entrega definido', e uma alteração em VBUK-CMGST indica 'Análise de crédito realizada'. Outras alterações relevantes podem ser registradas como 'Pedido de venda alterado'.
- Extraia os dados do fluxo de documentos: Consulte a tabela de fluxo de documentos (VBFA) para os pedidos de venda selecionados. Ela relaciona os pedidos a documentos subsequentes, como entregas, movimentos de mercadorias e faturas. Selecione todos os documentos relacionados para processamento posterior.
- Extraia os eventos de entrega e atendimento: Use os números dos documentos de entrega da VBFA para consultar LIKP e LIPS e identificar eventos de 'Entrega criada'. Consulte MKPF e MSEG para encontrar documentos de saída de mercadorias (tipo de movimento '601') e registrar o evento 'Mercadorias expedidas'. 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 quando a 'Separação foi concluída'. Verifique o status do cabeçalho da entrega VBUK-PODAT para identificar a 'Confirmação de entrega recebida'.
- Extraia os eventos de faturamento e pagamento: Use os números dos documentos de faturamento da VBFA para consultar VBRK e VBRP e identificar os eventos 'Fatura criada' e 'Fatura cancelada' (quando VBRK-FKSTO = 'X'). Para encontrar o evento 'Pagamento recebido', relacione a fatura da VBRK ao documento contábil na BKPF e, em seguida, localize o documento e a data de compensação na BSAD.
- Extraia eventos com base no 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 é igual a 'C'. Um pedido é considerado 'Pedido cancelado' quando o 'Motivo da rejeição' (VBAP-ABGRU) está definido para todos os itens relevantes.
- Consolide e formate os dados: Combine todos os eventos capturados em uma única tabela interna final. Confira se todos os atributos (SalesOrder, Activity, StartTime, User etc.) estão preenchidos corretamente em cada registro de evento. Adicione os dados de SourceSystem e LastDataUpdate.
- Gere 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. Salve o arquivo com codificação UTF-8.
Configuração
- Pré-requisitos: Autorizações de desenvolvedor ABAP, como acesso à transação SE38, e permissão 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 com parâmetros de filtro. Os principais são:
- Intervalo de datas: 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 em um tamanho gerenciável.
- 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 os demais, como cotações e devoluções.
- Considerações de performance: A extração de grandes volumes de dados das tabelas de log de alterações (CDHDR, CDPOS) e de fluxo de documentos (VBFA) pode ser muito lenta. Otimize o programa para usar campos de índice nas cláusulas WHERE. Para extrações muito grandes, programe a execução em segundo plano durante horários de menor movimento 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 os principais elementos de dados, como LIFSK, CMGST e ABGRU. Você pode conferir isso na transação SCDO para o objeto VERKBELEG.
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: Confirme se você tem acesso direto, 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 se conectar e executar consultas.
- Obtenha o script SQL: Copie a consulta SQL completa fornecida na seção 'consulta' deste documento.
- Conecte-se ao banco de dados: Abra o cliente de banco de dados e conecte-se à 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 acesso apropriadas.
- Configure 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 de exemplo 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.
- Execute a consulta: Execute o script SQL configurado. Dependendo do intervalo de datas e do tamanho do banco de dados SAP, a consulta pode levar alguns minutos.
- Confira os resultados: Quando a consulta terminar, será exibido um conjunto de resultados. Verifique rapidamente se ele contém as colunas esperadas (SalesOrder, Activity, StartTime etc.) e se há linhas para diferentes atividades.
- Exporte os dados: Use a função de exportação do cliente de banco de dados para salvar o resultado em um arquivo CSV. Escolha um nome descritivo, como SAP_O2C_Event_Log.csv.
- Formate os dados para o ProcessMind: Abra o arquivo CSV em um editor de planilhas. Confira se os cabeçalhos das colunas correspondem exatamente aos atributos necessários, como SalesOrder, Activity e StartTime. Verifique se o formato de data e hora de StartTime e LastDataUpdate é consistente e compatível com o ProcessMind, por exemplo, YYYY-MM-DD HH:MI:SS.
- Carregue os dados no ProcessMind: Carregue o arquivo CSV final, já formatado, no seu projeto do ProcessMind para análise.
Configuração
- Intervalo de datas: A consulta usa os valores de exemplo ('{StartDate}' e '{EndDate}') para filtrar pedidos de venda pela data de criação (VBAK.ERDAT). Um período de análise típico é de 3 a 6 meses de dados, o que permite obter uma amostra representativa sem sobrecarregar o banco de dados.
- Filtro de organização de vendas: Use o valor '{SalesOrgs}' para limitar a extração a organizações de vendas específicas, como '1000' e '2000'. Isso é essencial para concentrar a análise e melhorar a performance da consulta.
- Filtro de tipo de documento: Use o valor '{DocTypes}' para selecionar tipos específicos de pedido de venda, como 'OR' para pedido padrão. Assim, você pode excluir do fluxo principal do processo documentos irrelevantes, como entregas gratuitas ou devoluções.
- Identificador do sistema de origem: O valor fixo '{SourceSystemName}' identifica o sistema de origem de cada registro. Defina um nome significativo para sua instância do SAP ECC, como 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], é apenas um exemplo. Substitua-a pela função correta para o seu banco de dados, como TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') no SAP HANA ou CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) no SQL Server.
- Pré-requisitos: Este método exige credenciais de acesso direto ao banco de dados, somente para leitura. O usuário do banco precisa ter autorização para acessar todas as tabelas mencionadas na consulta, incluindo VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK e BSAD.
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?
Use este Template de dados para aproveitar todo o potencial do processo de pedido ao recebimento no processamento de pedidos de venda. Comece hoje a aumentar a eficiência e acelerar o fluxo de caixa.
Otimize hoje o processamento de pedidos de venda no processo de pedido ao recebimento
Elimine gargalos, reduza o tempo de ciclo em 30% e acelere o fluxo de caixa.
Não é necessário informar o cartão de crédito. Configure tudo em poucos minutos.