Seu Template de dados para compras, do pedido ao pagamento
Seu Template de dados para compras, do pedido ao pagamento
- Atributos recomendados para uma análise detalhada
- Principais atividades a acompanhar no processo
- Instruções passo a passo para extrair os dados
Atributos de compras, do pedido ao pagamento
| Nome | Descrição | ||
|---|---|---|---|
| Atividade ActivityName | Nome do evento ou da etapa de negócio que ocorreu no processo do pedido de compra. | ||
| Descrição Este atributo descreve uma ação específica ou uma alteração de status no ciclo de vida do pedido de compra, como 'Pedido de compra criado', 'Pedido de compra aprovado' ou 'Entrada de mercadorias lançada'. A sequência dessas atividades forma o fluxo do processo. Analisar a sequência e a frequência das atividades é a base do Process Mining. Isso ajuda a descobrir como o processo realmente acontece, compará-lo com o modelo planejado, identificar gargalos, como longas esperas após 'Fatura recebida', e quantificar o retrabalho, como atividades repetidas de 'Pedido de compra alterado'. Por que isso importa Define as etapas do processo e permite visualizar e analisar o fluxo de ponta a ponta, as variantes e os gargalos. Onde encontrar Em geral, é obtido de uma combinação de tabelas e campos, como campos de status em EKKO/EKPO ou logs de documentos de alteração em CDHDR/CDPOS, para representar marcos importantes do negócio. Exemplos Pedido de compra criadoPedido de compra aprovadoEntrada de mercadorias lançadaFatura recebida | |||
| Data e hora do evento EventTime | Data e hora que indicam quando a atividade ocorreu. | ||
| Descrição Este atributo registra a data e a hora exatas de cada atividade do processo. É fundamental para todas as análises temporais em Process Mining. A data e a hora do evento são usadas para ordenar as atividades cronologicamente e montar o fluxo do processo. Também são a base para calcular métricas de duração, como tempos de ciclo entre atividades, tempos de espera e tempos de processamento, essenciais para analisar a performance e identificar gargalos. Por que isso importa Essas informações de data e hora são essenciais para ordenar os eventos corretamente e calcular todas as métricas de performance, incluindo tempos de ciclo, tempos de atravessamento e tempos de espera. Onde encontrar Campos de data e hora associados a atividades específicas, como Data de criação (EKKO-AEDAT para alterações) ou Data de lançamento (MKPF-BUDAT para entradas de mercadorias). Muitas vezes, é necessário combinar dados de várias tabelas. Exemplos 2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-05-01T09:15:00Z | |||
| Pedido de compra PurchaseOrderNumber | Identificador exclusivo do pedido de compra (PO), usado como ID do caso principal para acompanhar o ciclo de compras. | ||
| Descrição O número do pedido de compra é o identificador central que conecta todas as atividades relacionadas, desde a criação inicial até o recebimento final das mercadorias e a conclusão. Ele funciona como identificador do caso na análise de Process Mining. Na análise, agrupar os eventos por esse número permite reconstruir a trajetória de cada pedido de compra. Isso é essencial para calcular tempos de ciclo, analisar variantes do processo e identificar gargalos ou desvios específicos de cada pedido. Por que isso importa É a chave essencial para conectar todos os eventos de compras em um único processo de ponta a ponta e permitir uma análise detalhada do ciclo de vida de cada pedido de compra. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo EBELN. Exemplos 450001712345000171244500017125 | |||
| Sistema de origem SourceSystem | Identifica o sistema de origem de onde os dados foram extraídos. | ||
| Descrição Este atributo especifica o sistema de origem dos dados dos eventos, por exemplo, 'SAP S/4HANA Production' ou 'SAP ECC'. Em ambientes com vários sistemas, este campo é essencial para rastrear a linhagem dos dados, solucionar problemas e garantir que os dados de diferentes fontes sejam interpretados corretamente. Ele ajuda a entender o contexto dos dados e pode ser usado para filtrar análises por ambiente de sistema. Por que isso importa Fornece contexto essencial sobre a origem dos dados, fundamental para a governança, a validação e a análise em ambientes com vários sistemas. Onde encontrar Em geral, é um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) para identificar a origem do conjunto de dados. Exemplos S4H_PROD_100ECC_EU_200S4H_US_300 | |||
| Última atualização dos dados LastDataUpdate | Data e hora da última atualização ou extração dos dados do sistema de origem. | ||
| Descrição Este atributo indica o nível de atualização dos dados analisados. Ele mostra a data e a hora da extração mais recente de dados do SAP S/4HANA. Saber quando os dados foram atualizados pela última vez é essencial para entender a atualidade da análise. Isso ajuda a interpretar os resultados corretamente, sabendo se você está consultando informações em tempo real ou um retrato de um momento específico, o que afeta a relevância das ações tomadas com base na análise. Por que isso importa Informa aos usuários se os dados estão atualizados, ajudando a entender o contexto e a relevância dos resultados da análise. Onde encontrar Este é um registro de data e hora de metadados, adicionado durante o processo de extração, transformação e carregamento (ETL). Exemplos 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Data de entrega solicitada RequestedDeliveryDate | Data em que a empresa solicitou ao fornecedor a entrega dos bens ou serviços. | ||
| Descrição Este atributo especifica a data de entrega prevista no pedido de compra. Ela serve de referência para medir a performance de entrega do fornecedor. No Process Mining, essa data é comparada com a data real de recebimento das mercadorias (data e hora de 'Entrada de mercadorias lançada') para calcular o KPI 'Índice de entregas do fornecedor no prazo'. Analisar os desvios em relação a essa data ajuda a avaliar a confiabilidade do fornecedor e a gerenciar os riscos da cadeia de suprimentos. Por que isso importa Serve de referência para medir a performance de entrega do fornecedor no prazo, um KPI essencial para a gestão da cadeia de suprimentos e o planejamento operacional. Onde encontrar Este dado está na tabela de linhas de programação EKET, no campo EINDT. Exemplos 2023-06-012023-06-152023-07-01 | |||
| ID do fornecedor VendorId | Identificador exclusivo do fornecedor que fornece os bens ou serviços. | ||
| Descrição O ID do fornecedor é um dado mestre essencial que vincula um pedido de compra a um fornecedor específico. Ele é usado em todo o processo de compras para comunicação, entrega e pagamento. No Process Mining, este atributo permite segmentar a análise de performance por fornecedor. É essencial para Dashboards como 'Performance do tempo de atravessamento do fornecedor' e 'Índice de devolução de mercadorias por fornecedor', que ajudam a identificar os fornecedores mais confiáveis e aqueles que podem estar causando atrasos ou problemas de qualidade. Por que isso importa Permite analisar o processo sob a perspectiva dos fornecedores, avaliar a performance, identificar fornecedores com resultados melhores ou piores e otimizar a cadeia de suprimentos. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo LIFNR. Exemplos 100023100045100088 | |||
| Requisição de compra PurchaseRequisitionNumber | Identificador da solicitação de compra (PR) que deu origem ao pedido de compra. | ||
| Descrição Este atributo vincula o pedido de compra à solicitação que lhe deu origem. Nem todos os pedidos têm uma solicitação de compra, pois podem ser criados diretamente. Esse vínculo é essencial para analisar o processo de compras de ponta a ponta, desde a solicitação inicial. Ele permite acompanhar KPIs como 'Tempo de aprovação da solicitação de compra' e é fundamental para identificar gastos fora dos canais aprovados, quando pedidos são criados sem uma solicitação prévia aprovada. Por que isso importa Vincula o pedido à solicitação inicial, permitindo analisar o processo de ponta a ponta e identificar gastos fora de conformidade realizados por canais não aprovados. Onde encontrar Este atributo está na tabela EKPO do SAP S/4HANA, no nível do item do pedido de compra, no campo BANFN. Exemplos 1001005110010052 | |||
| Tipo de documento do pedido de compra DocumentType | Classificação que diferencia os tipos de pedidos de compra, como pedidos padrão, pedidos de serviços ou pedidos de transferência de estoque. | ||
| Descrição O tipo de documento é um elemento importante da configuração do SAP que controla o fluxo do processo, a faixa de numeração e os campos de um pedido de compra. Ele permite adaptar o processo de compras a diferentes cenários. Analisar o processo por tipo de documento é essencial para entender as variações. Por exemplo, o processo de um pedido padrão de mercadorias pode ser bem diferente do processo de um pedido de serviços ou de transferência de estoque. Este atributo permite filtrar e comparar esses fluxos distintos para encontrar oportunidades específicas de melhoria. Por que isso importa Categoriza os pedidos de compra, permitindo comparar diferentes processos de compras e entender as variações nos fluxos e nos tempos de ciclo. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo BSART. Exemplos NBFOUB | |||
| Usuário UserName | Identificador do usuário que realizou uma atividade específica. | ||
| Descrição Este atributo registra o ID do usuário SAP responsável por criar, alterar ou aprovar um documento. Ele permite rastrear as ações realizadas no sistema. Analisar os dados por usuário ajuda a identificar necessidades de treinamento, distribuição de carga de trabalho e performance individual. Por exemplo, você pode verificar se determinados usuários estão associados com frequência a longos tempos de aprovação ou a alterações recorrentes após a aprovação, o que pode orientar a gestão de recursos e as iniciativas de melhoria do processo. Por que isso importa Permite atribuir responsabilidades e analisar a performance individual ou da equipe, ajudando a identificar oportunidades de treinamento ou limitações de recursos. Onde encontrar Estas informações aparecem em campos como ERNAM (Criado por) na EKKO ou no campo de usuário das tabelas de documentos de alteração (CDHDR-USERNAME). Exemplos CB9980000012JSMITHRROE | |||
| Valor líquido total TotalNetAmount | Valor total do pedido de compra, sem impostos nem custos de frete. | ||
| Descrição Este atributo representa o valor monetário líquido do pedido de compra. É um dado financeiro importante que indica o porte da transação de compras. Este valor é essencial para análises financeiras, como categorizar pedidos por valor (alto ou baixo) e verificar se os caminhos do processo são diferentes. Ele também pode ajudar a priorizar análises, com foco em pedidos de alto valor, que podem envolver mais riscos financeiros ou ter maior impacto nos negócios. Por que isso importa Permite fazer análises financeiras, segmentar pedidos de compra por valor e priorizar melhorias do processo nas áreas com maiores gastos. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo NETWR. Exemplos 1500.0025000.50125.75 | |||
| Categoria do item ItemCategory | Classifica um item do pedido de compra, por exemplo, como padrão, consignação, subcontratação ou serviço. | ||
| Descrição A categoria do item determina como a compra de um material ou serviço específico é controlada e processada. Ela influencia etapas posteriores, como o recebimento de mercadorias e a verificação da fatura. Este atributo é importante para analisar variantes do processo conforme o que está sendo comprado. Por exemplo, o processo de um item de serviço, que exige uma folha de registro de serviços, é bem diferente do processo de um item padrão de estoque. Analisar os dados por categoria de item ajuda a explicar essas diferenças e direcionar melhorias no processo. Por que isso importa Explica as variações do processo distinguindo diferentes tipos de aquisição, como bens, serviços ou subcontratação. Onde encontrar Este atributo está na tabela EKPO do SAP S/4HANA, no campo PSTYP. Exemplos 093 | |||
| Centro Plant | Instalação ou local operacional onde os bens são entregues ou os serviços são prestados. | ||
| Descrição No SAP, um centro é um local físico onde os bens são produzidos ou armazenados, ou onde os serviços são prestados. Ele é um elemento importante para logística e planejamento. Segmentar a análise do processo por centro pode revelar variações regionais ou específicas de cada unidade nas compras. Por exemplo, é possível identificar centros com prazos de entrega mais longos ou mais devoluções de mercadorias, o que pode indicar problemas locais de logística ou controle de qualidade. Por que isso importa Permite analisar o processo por localização e destacar diferenças de performance entre unidades operacionais, centros ou armazéns. Onde encontrar Este atributo está na tabela EKPO do SAP S/4HANA, no campo WERKS. Exemplos 10101710DE01 | |||
| É compra fora do processo IsMaverickSpend | Indicador calculado que mostra se um pedido de compra foi criado sem uma requisição de compra aprovada anteriormente. | ||
| Descrição Este indicador booleano é calculado durante o processamento dos dados. Ele recebe o valor 'true' quando o pedido de compra não tem uma requisição de compra associada ou quando sua criação ignora o fluxo de trabalho padrão de aprovação. Esse atributo dá suporte direto ao Dashboard 'Identificação de compras fora do processo' e aos KPIs relacionados. Ele ajuda a quantificar compras em desacordo com as políticas, permitindo que a empresa direcione ações a departamentos ou grupos de usuários específicos para reforçar as políticas e os controles de compras. Por que isso importa Identifica diretamente compras em desacordo com as políticas, ajudando a quantificar desvios do processo e a aplicar controles financeiros e políticas de compras. Onde encontrar Campo calculado com base na ausência de um valor em 'PurchaseRequisitionNumber' para tipos específicos de documento ou na análise da sequência de eventos. Exemplos truefalse | |||
| É retrabalho IsRework | Indicador calculado que mostra se o pedido de compra passou por retrabalho, como uma alteração após a aprovação ou uma devolução de mercadorias. | ||
| Descrição Este atributo booleano é calculado pela análise da sequência de atividades de cada pedido de compra. Ele recebe o valor 'true' quando ocorre um evento 'Pedido de compra alterado' após um evento 'Pedido de compra aprovado' ou quando há um evento 'Mercadorias devolvidas'. Esse indicador simplifica o cálculo do KPI 'Taxa de processamento direto'. Ele facilita a filtragem e a visualização de todos os pedidos de compra que exigiram intervenção manual ou correção, ajudando a quantificar o custo e a frequência do retrabalho. Por que isso importa Ajuda a quantificar a ineficiência do processo ao sinalizar casos com retrabalho, algo essencial para calcular as taxas de processamento direto e identificar as causas raiz dos desvios. Onde encontrar Campo calculado com base na sequência de atividades. A lógica verifica se um evento 'Pedido de compra alterado' ocorre após uma aprovação ou se existe um evento 'Mercadorias devolvidas'. Exemplos truefalse | |||
| Empresa CompanyCode | Identificador da entidade legal ou empresa para a qual o pedido de compra é criado. | ||
| Descrição A empresa representa uma unidade contábil independente dentro de uma organização. Todas as transações financeiras relacionadas a um pedido de compra são lançadas em uma empresa específica. Esse atributo organizacional fundamental permite filtrar e comparar processos de compras entre diferentes entidades legais. A análise por empresa pode revelar inconsistências na execução do processo, diferenças de eficiência ou variações nos níveis de conformidade dentro da organização. Por que isso importa Permite segmentar a análise do processo por entidade legal, facilitando a comparação de performance e conformidade entre diferentes áreas da empresa. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo BUKRS. Exemplos 101017102000 | |||
| Entrega pontual do fornecedor SupplierOnTimeDelivery | Indicador calculado que mostra se o recebimento de mercadorias foi lançado na data solicitada para entrega ou antes dela. | ||
| Descrição Este atributo booleano é calculado comparando a data e hora do evento 'Recebimento de mercadorias lançado' com a 'Data solicitada para entrega'. Se o recebimento ocorrer na data solicitada ou antes dela, o atributo recebe o valor 'true'. Esse atributo dá suporte direto ao KPI 'Taxa de entregas pontuais do fornecedor'. Ele simplifica a análise ao permitir filtrar facilmente entregas pontuais ou atrasadas, algo essencial para Dashboards de performance de fornecedores e avaliações de fornecedores. Por que isso importa Mede diretamente a confiabilidade do fornecedor, servindo de base para o KPI de entregas pontuais e permitindo uma gestão eficaz da performance dos fornecedores. Onde encontrar Calculado comparando a data e hora do evento 'Recebimento de mercadorias lançado' com o atributo 'RequestedDeliveryDate'. Exemplos truefalse | |||
| Grupo de compras PurchasingGroup | Grupo específico de compradores responsável por determinadas atividades de compras. | ||
| Descrição Um grupo de compras é formado por um ou mais compradores responsáveis por atividades, materiais ou fornecedores específicos. Esse grupo é o principal contato dos fornecedores. Esse atributo permite analisar a carga de trabalho e a performance com mais detalhes do que a organização de compras. Ele pode ajudar a identificar equipes sobrecarregadas, medir a eficiência de diferentes grupos de compradores e entender quais grupos estão mais sujeitos a desvios do processo, como compras fora dos contratos. Por que isso importa Oferece uma visão detalhada da performance dos grupos de compradores, permitindo analisar a carga de trabalho, a eficiência e a adesão ao processo no nível da equipe. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo EKGRP. Exemplos 001002N00 | |||
| Número do material MaterialNumber | Identificador do material ou bem específico que está sendo adquirido. | ||
| Descrição O número do material é um código exclusivo atribuído a cada registro mestre de material no SAP. Ele é usado em todas as transações relacionadas ao material, incluindo compras, gestão de estoque e vendas. A análise por número ou grupo de materiais permite avaliar as compras por categoria. Ela pode ajudar a identificar se os processos de aquisição de determinados tipos de materiais são menos eficientes, têm prazos de entrega mais longos ou estão mais sujeitos a devoluções, gerando insights para a gestão de categorias. Por que isso importa Permite analisar as compras por categoria e identificar problemas no processo ou na performance de fornecedores relacionados a produtos ou materiais específicos. Onde encontrar Este atributo está na tabela EKPO do SAP S/4HANA, no campo MATNR. Exemplos RM100-100FG210SERV-CONSULT | |||
| Organização de compras PurchasingOrganization | Unidade organizacional responsável por adquirir materiais e serviços e negociar com fornecedores. | ||
| Descrição A organização de compras é uma unidade organizacional essencial para as aquisições. Ela pode ser estruturada nos níveis corporativo, empresarial ou de centro e responde por todas as atividades de compras. Analisar o processo por organização de compras ajuda a avaliar a eficiência e a performance de diferentes equipes ou regiões. A análise pode destacar diferenças nas negociações com fornecedores, na conformidade do processo ou nos atrasos de aprovação entre unidades organizacionais. Por que isso importa Permite comparar a performance entre diferentes departamentos ou regiões de compras, ajudando a identificar boas práticas e oportunidades de melhoria. Onde encontrar Este atributo está na tabela EKKO do SAP S/4HANA, no campo EKORG. Exemplos 10101710US01 | |||
Atividades de compras, do pedido ao pagamento
| Atividade | Descrição | ||
|---|---|---|---|
| Entrada de mercadorias lançada | Representa o recebimento físico de mercadorias do fornecedor e o respectivo registro no sistema. É uma transação explícita que atualiza o histórico do pedido de compra. | ||
| Por que isso importa Este é um marco importante: encerra o tempo de atravessamento do fornecedor e dá início ao processo interno de verificação da fatura. É essencial para acompanhar os índices de entrega no prazo. Onde encontrar Registrado como documento de material nas tabelas MKPF (cabeçalho) e MSEG (item), e vinculado ao histórico do pedido de compra na tabela EKBE com um tipo de movimento específico, por exemplo, 101. Coleta Data de lançamento (BUDAT) do cabeçalho do documento de material (MKPF), vinculado por meio da EKBE. Tipo de evento explicit | |||
| Fatura recebida | Representa o registro da fatura do fornecedor no sistema SAP, vinculando-a ao pedido de compra correspondente. É um lançamento financeiro explícito que cria um documento contábil. | ||
| Por que isso importa Este é um marco importante que conecta o processo de compras ao processo de contas a pagar. Ele permite analisar o tempo entre o recebimento das mercadorias e o processamento da fatura. Onde encontrar Um documento contábil é criado na tabela BKPF (cabeçalho), e seus itens de linha ficam na BSEG ou no diário universal ACDOCA. O documento é vinculado ao pedido de compra na tabela RSEG. Coleta Data de entrada do documento (CPUDT) na tabela de cabeçalho do documento contábil BKPF. Tipo de evento explicit | |||
| Pedido de compra aprovado | Indica que o pedido de compra recebeu todas as aprovações internas necessárias e está autorizado para ser enviado ao fornecedor. O evento é inferido a partir de uma alteração de status na estratégia de liberação do pedido. | ||
| Por que isso importa Este é um marco importante para medir a eficiência das aprovações e o retrabalho após a aprovação. Analisar o tempo entre a criação e a aprovação do pedido destaca atrasos no processo interno. Onde encontrar Inferido do indicador de liberação (FRGKE) na tabela EKKO. A data e a hora são determinadas pelo histórico de alterações (CDHDR/CDPOS), que mostra quando esse campo foi atualizado para o status de liberado. Coleta Inferido dos registros de alterações do campo do indicador de liberação (FRGKE) na tabela EKKO. Tipo de evento inferred | |||
| Pedido de compra concluído | Esta atividade indica que um item do pedido de compra foi encerrado do ponto de vista logístico. Ela é inferida quando os indicadores 'Entrega concluída' e 'Fatura final' estão definidos. | ||
| Por que isso importa Este é o ponto final da análise do ciclo de vida do pedido de compra. Medir o tempo até esse evento fornece o tempo de ciclo de ponta a ponta das operações de compras. Onde encontrar Inferido dos indicadores de status na tabela de itens do pedido de compra EKPO. O evento ocorre quando os indicadores 'Entrega concluída' (ELIKZ) e 'Fatura final' (EREKZ) estão ambos definidos como verdadeiros. Coleta Inferido dos registros de alterações quando os campos ELIKZ e EREKZ da EKPO estão marcados como concluídos. Tipo de evento inferred | |||
| Pedido de compra criado | Marca a criação do documento oficial do pedido de compra, que pode ser criado com ou sem referência a uma solicitação de compra. É um evento explícito, capturado quando o pedido é salvo pela primeira vez no sistema. | ||
| Por que isso importa Esta atividade pode servir como ponto de partida alternativo para o processo, especialmente na análise de compras fora dos canais aprovados. É um evento fundamental para acompanhar o tempo total de processamento do pedido de compra. Onde encontrar Registrado na tabela de cabeçalho do pedido de compra EKKO. A data de criação (AEDAT) e a hora do documento são armazenadas diretamente nessa tabela. Coleta Data e hora de criação (AEDAT) do documento de pedido de compra na tabela EKKO. Tipo de evento explicit | |||
| Solicitação de compra aprovada | Representa a aprovação formal de uma solicitação de compra por um gerente ou aprovador designado. Em geral, o evento é inferido a partir de uma alteração de status no documento da solicitação, indicando que ela está pronta para ser convertida em pedido de compra. | ||
| Por que isso importa Este é um marco importante para acompanhar os tempos de ciclo de aprovação e identificar gargalos. Atrasos nessa etapa afetam diretamente a rapidez com que um pedido de compra pode ser criado e enviado ao fornecedor. Onde encontrar Inferido dos campos de status de liberação da tabela EBAN, por exemplo, FRGZU, indicador de liberação. A data e a hora são obtidas dos documentos de alteração (CDHDR/CDPOS), que registram quando o status de liberação final foi definido. Coleta Inferido dos registros de alterações (CDHDR/CDPOS) dos campos de status de liberação na tabela EBAN. Tipo de evento inferred | |||
| Solicitação de compra criada | Esta atividade registra a solicitação formal de bens ou serviços e dá início ao processo de compras. O evento é capturado explicitamente quando um usuário salva um novo documento de solicitação de compra, por exemplo, usando a transação ME51N. | ||
| Por que isso importa Este é o principal ponto de partida do ciclo de vida de muitos pedidos de compra. Analisar o tempo entre esse evento e a criação do pedido ajuda a identificar atrasos no fornecimento e no processamento interno. Onde encontrar Registrado na tabela EBAN (solicitação de compra). A data e a hora de criação do evento podem ser encontradas nas tabelas de histórico de alterações CDHDR e CDPOS do objeto EBAN. Coleta Evento registrado quando um documento é criado na tabela EBAN. Tipo de evento explicit | |||
| Confirmação de serviço registrada | Esta atividade registra a confirmação de que um serviço especificado em um pedido de compra foi executado. O evento é capturado explicitamente pela criação de uma folha de registro de serviços. | ||
| Por que isso importa Nas compras de serviços, esta atividade equivale ao recebimento de mercadorias. É essencial para acompanhar os prazos de entrega dos serviços e permitir pagamentos pontuais aos fornecedores. Onde encontrar Registrado pela criação de uma folha de registro de serviços, com dados armazenados nas tabelas ESSR (cabeçalho) e ESLL (itens). A data de criação serve como data e hora do evento. Coleta Data de criação do documento da folha de registro de serviços na tabela ESSR. Tipo de evento explicit | |||
| Fatura paga | Marca a liquidação final da fatura do fornecedor por meio de uma execução de pagamento ou de um pagamento manual. É uma transação financeira explícita que cria um documento de compensação. | ||
| Por que isso importa Embora tecnicamente faça parte do processo de pagamento, incluir esta atividade oferece uma visão completa do ciclo de compras, do pedido ao pagamento. Ela é fundamental para analisar as condições e a performance dos pagamentos. Onde encontrar O pagamento é registrado como documento de compensação em BKPF/ACDOCA. A data de compensação (AUGDT) do item da fatura na tabela BSEG ou ACDOCA indica o evento de pagamento. Coleta Data de compensação (AUGDT) do documento da fatura, encontrada em BSEG ou ACDOCA. Tipo de evento explicit | |||
| Mercadorias devolvidas | Indica que mercadorias recebidas anteriormente foram devolvidas ao fornecedor, geralmente por problemas de qualidade, danos ou envio incorreto. O evento é registrado como um movimento explícito de estorno de mercadorias. | ||
| Por que isso importa Esta atividade evidencia retrabalho e possíveis problemas de qualidade do fornecedor ou de precisão do pedido. Muitas devoluções de um fornecedor ou material específico sinalizam um problema. Onde encontrar Registrado como documento de material com um tipo específico de movimento de devolução, por exemplo, 122. O evento é registrado em MKPF/MSEG e vinculado ao pedido de compra no histórico da tabela EKBE. Coleta Data de lançamento do documento de material com um tipo de movimento de devolução na EKBE. Tipo de evento explicit | |||
| Pedido de compra alterado | Esta atividade indica que o pedido de compra foi alterado após sua criação, por exemplo, na quantidade, no preço ou na data de entrega. O evento é registrado explicitamente nos logs de alterações do sistema. | ||
| Por que isso importa Acompanhar as alterações, especialmente após a aprovação, é essencial para identificar ineficiências no processo, retrabalho e possíveis problemas de conformidade. Alterações frequentes podem indicar especificações iniciais inadequadas. Onde encontrar Registrado nas tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item) dos objetos de pedido de compra (EINKBELEG). Cada alteração gera uma entrada detalhada no log. Coleta Evento registrado quando há alterações em campos importantes das tabelas EKKO ou EKPO, documentadas em CDHDR/CDPOS. Tipo de evento explicit | |||
| Pedido de compra enviado ao fornecedor | Representa o momento em que o pedido de compra é enviado ao fornecedor, por exemplo, via EDI, e-mail ou impressão. Esse evento costuma ser capturado nos registros de gestão de saídas do sistema. | ||
| Por que isso importa Esta atividade marca o início efetivo do tempo de atravessamento do fornecedor. Ela é essencial para medir com precisão a performance do fornecedor a partir do momento em que ele recebe o pedido. Onde encontrar Capturado na tabela de controle de saídas NAST, que registra as mensagens enviadas para um documento de compras. Você pode usar a data e a hora do tipo de saída correspondente, por exemplo, EDI ou e-mail. Coleta Data e hora da primeira mensagem de saída enviada com sucesso para o pedido de compra na tabela NAST. Tipo de evento inferred | |||
| Pedido de compra excluído | Representa o cancelamento ou a exclusão lógica de um item do pedido de compra ou do documento inteiro. O evento é registrado quando um usuário define um indicador de exclusão no documento. | ||
| Por que isso importa Esta atividade é um ponto final alternativo do processo, indicando falha ou cancelamento. Analisar os motivos da exclusão de pedidos de compra pode revelar problemas no planejamento da demanda ou na definição dos requisitos. Onde encontrar Capturado pelo indicador de exclusão (LOEKZ) nas tabelas de cabeçalho (EKKO) ou de itens (EKPO) do pedido de compra. A data e a hora são obtidas dos documentos de alteração (CDHDR/CDPOS). Coleta Data e hora dos documentos de alteração (CDHDR/CDPOS) em que o indicador de exclusão (LOEKZ) foi definido. Tipo de evento explicit | |||
Guias de extração
Etapas
- Pré-requisitos e acesso: Verifique se você tem um usuário com as autorizações necessárias para consultar as CDS Views (Core Data Services) no sistema SAP S/4HANA. O acesso pode ser feito pelo SAP HANA Studio, pelo ABAP Development Tools (ADT) para Eclipse ou por uma ferramenta de extração de dados de terceiros que aceite conexões SQL com o banco de dados SAP HANA.
- Identifique os dados de conexão do sistema: Obtenha os parâmetros necessários para se conectar ao sistema SAP S/4HANA, incluindo host, número da instância e credenciais de autenticação.
- Conecte-se ao banco de dados: Use o cliente SQL de sua preferência para se conectar ao banco de dados SAP S/4HANA onde estão as CDS Views.
- Prepare a consulta SQL: Copie para o editor SQL a consulta completa fornecida na seção de consultas deste documento. Ela foi criada para extrair todas as atividades e os atributos necessários.
- Defina os parâmetros de filtragem: Localize os valores de exemplo na consulta. Substitua _start_date e _end_date pelo período desejado para a análise, por exemplo, '20230101' e '20231231'. Altere o filtro poh.CompanyCode para incluir os códigos de empresa que você quer analisar.
- Execute a consulta: Rode a consulta SQL modificada no banco de dados S/4HANA. A execução pode levar algum tempo, dependendo do volume de dados e do período especificado.
- Revise os resultados preliminares: Quando a consulta terminar, faça uma verificação rápida dos resultados no cliente SQL. Confira se há diferentes atividades, se os registros de data e hora foram preenchidos corretamente e se o ID do caso (PurchaseOrderNumber) está consistente.
- Exporte os dados: Exporte todo o conjunto de resultados da ferramenta SQL para um arquivo CSV (valores separados por vírgula). Use a codificação UTF-8 para evitar problemas com caracteres.
- Prepare os dados para carregamento: Antes de carregar os dados no ProcessMind, abra o arquivo CSV e confira se os cabeçalhos das colunas correspondem exatamente aos atributos definidos nos requisitos de dados (PurchaseOrderNumber, ActivityName, EventTime etc.). Ajuste os nomes das colunas se a ferramenta de exportação tiver alterado algum deles.
- Carregue os dados no ProcessMind: Carregue o arquivo CSV finalizado no seu projeto do ProcessMind. Durante a importação, mapeie as colunas do arquivo para os campos correspondentes de ID do caso, atividade e registro de data e hora.
Configuração
- Principais CDS Views utilizadas: A lógica de extração usa um conjunto de CDS Views padrão com dados semanticamente ricos. As principais são:
- I_PurchaseOrderItemAPI01: dados essenciais dos itens de pedidos de compra.
- I_PurchaseRequisitionItemAPI01: detalhes das requisições de compra.
- I_MaterialDocumentItem: movimentações de mercadorias, como recebimentos e devoluções.
- I_ServiceEntrySheetAPI01: eventos de confirmação de serviços.
- I_SupplierInvoiceAPI01: informações de faturas de fornecedores.
- I_OperationalAcctgDocItem: associação entre faturas e documentos financeiros para acompanhar pagamentos.
- I_ChangeDocument: alterações feitas nos pedidos de compra.
- Filtro por período: É essencial aplicar um filtro de período para controlar a performance e o volume de dados. A consulta usa os valores de exemplo _start_date e _end_date na data de criação do pedido de compra (PurchaseOrderDate). Para começar, recomendamos um período de 3 a 6 meses.
- Filtro organizacional: A consulta deve sempre usar o filtro CompanyCode para limitar a extração às unidades de negócio relevantes. Para refinar ainda mais os resultados, você pode adicionar filtros de PurchaseOrderType ou PurchasingOrganization à expressão de tabela comum PO_base.
- Pré-requisitos: O usuário que executar a consulta precisa de autorização SELECT em todas as CDS Views listadas acima. Em geral, o acesso a essas views é concedido por meio de funções específicas de negócios ou análise no S/4HANA. Sem as permissões adequadas, a consulta falhará.
Consulta de exemplo sql
WITH PO_base AS (
SELECT
poh.PurchaseOrder AS PurchaseOrderNumber,
poi.PurchaseOrderItem AS PurchaseOrderItem,
poh.CompanyCode,
poh.PurchaseOrderType AS DocumentType,
poh.Supplier AS VendorId,
poh.PurchaseOrderDate,
poi.PurchaseRequisition AS PurchaseRequisitionNumber,
poi.NetPriceAmount * poi.OrderQuantity AS TotalNetAmount, -- Note: This is item-level net amount
poh.CreationDate AS POCreationDate,
poh.CreationTime AS POCreationTime,
poh.LastChangeDateTime AS POLastChangeDateTime,
poi.IsDeleted,
poi.DeliveryIsCompleted,
poi.FinalInvoiceIsExpected,
poi.GoodsReceiptIsExpected,
poi.LastGoodsReceiptDate,
poi.LastInvoiceReceiptDate
FROM I_PurchaseOrderAPI01 poh
JOIN I_PurchaseOrderItemAPI01 poi
ON poh.PurchaseOrder = poi.PurchaseOrder
WHERE
poh.PurchaseOrderDate BETWEEN '_start_date' AND '_end_date' -- Placeholder: e.g., '20230101' and '20230630'
AND poh.CompanyCode IN ('[YourCompanyCode]') -- Placeholder: e.g., '1010'
)
-- 1. Purchase Requisition Created
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(CONCAT(pr.CreationDate, 'T', pr.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem, -- Placeholder
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
pr.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate, -- Available in PR, add if needed
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(CONCAT(pr.PurReqnReleaseDate, 'T', '000000') AS TIMESTAMP) AS EventTime, -- Time is not available in this view
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
WHERE
pr.PurReqnReleaseDate IS NOT NULL
UNION ALL
-- 3. Purchase Order Created
SELECT
po.PurchaseOrderNumber,
'Purchase Order Created' AS ActivityName,
CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
poh.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
UNION ALL
-- 4. Purchase Order Approved
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Approved' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Assuming ReleaseDate reflects final approval
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 5. Purchase Order Sent to Vendor
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Sent to Vendor' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Using ReleaseDate as a proxy for sending time
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 6. Purchase Order Changed
SELECT DISTINCT
ch.OBJECTID AS PurchaseOrderNumber,
'Purchase Order Changed' AS ActivityName,
CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
ch.UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ChangeDocument ch
JOIN PO_base po ON ch.OBJECTID = po.PurchaseOrderNumber
WHERE
ch.ObjectClassName = 'EINKBELEG' -- Object Class for Purchase Documents
AND CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) > CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP)
UNION ALL
-- 7. Goods Receipt Posted
SELECT
po.PurchaseOrderNumber,
'Goods Receipt Posted' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '101'
UNION ALL
-- 8. Services Confirmation Entered
SELECT
po.PurchaseOrderNumber,
'Services Confirmation Entered' AS ActivityName,
CAST(se.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
se.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ServiceEntrySheetAPI01 se
JOIN PO_base po
ON se.PurchaseOrder = po.PurchaseOrderNumber AND se.PurchaseOrderItem = po.PurchaseOrderItem
UNION ALL
-- 9. Goods Returned
SELECT
po.PurchaseOrderNumber,
'Goods Returned' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '122'
UNION ALL
-- 10. Invoice Received
SELECT
po.PurchaseOrderNumber,
'Invoice Received' AS ActivityName,
CAST(inv.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
inv.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
inv.DebitCreditCode = 'H' -- 'H' for Credit (Supplier Invoice)
UNION ALL
-- 11. Invoice Paid
SELECT
po.PurchaseOrderNumber,
'Invoice Paid' AS ActivityName,
CAST(doc.ClearingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
doc.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN I_OperationalAcctgDocItem doc
ON inv.AccountingDocument = doc.AccountingDocument
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
doc.IsCleared = 'X' AND doc.ClearingDate IS NOT NULL
UNION ALL
-- 12. Purchase Order Completed
SELECT
po.PurchaseOrderNumber,
'Purchase Order Completed' AS ActivityName,
CAST(GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
'SYSTEM' AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.DeliveryIsCompleted = 'X'
AND (po.FinalInvoiceIsExpected = 'X' OR po.GoodsReceiptIsExpected = '') -- Logic for completion
AND GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) IS NOT NULL
UNION ALL
-- 13. Purchase Order Deleted
SELECT
po.PurchaseOrderNumber,
'Purchase Order Deleted' AS ActivityName,
CAST(po.POLastChangeDateTime AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- User who set the flag is in change docs
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.IsDeleted = 'X' Etapas
- Confirme se há acesso SQL direto ao esquema SAP HANA que contém EKKO e EKPO e obtenha as autorizações de leitura necessárias. Substitua os valores de exemplo de esquema e conexão pelos valores configurados para o seu sistema.
- Defina o período de extração usando [Start timestamp] e [End timestamp]. Para a carga inicial, recomendamos um período de três a seis meses. Aplique filtros de código de empresa e tipo de documento somente quando forem necessários para o escopo dos relatórios.
- Identifique os pedidos de compra em EKKO e EKPO e mantenha o número do pedido, fornecedor, tipo de documento, código da empresa, data de criação, hora de criação e atributos no nível do item. Some os valores líquidos de EKPO para calcular TotalNetAmount no nível do pedido de compra.
- Extraia os eventos de criação e aprovação de requisições de compra de EBAN. Use o número da requisição e a referência do item disponível em EKPO para associar as requisições aos pedidos de compra. Como os indicadores e registros de data e hora de aprovação variam conforme a configuração da versão, configure as expressões de status e registro de data e hora de acordo com a estratégia de liberação ativa do SAP em [Configure based on your system].
- Extraia os eventos de criação, aprovação, alteração, exclusão e conclusão de pedidos de compra. Para a criação, use a data e a hora de criação de EKKO. A aprovação, a alteração e a exclusão exigem fontes de histórico de liberação ou de alterações. Configure as expressões das fontes correspondentes usando [Your table name] e [Your column name] quando o histórico relevante não estiver disponível no esquema selecionado.
- Extraia os eventos de comunicação com fornecedores, recebimento de mercadorias, confirmação de serviços, devolução de mercadorias, recebimento de faturas e pagamento de faturas das fontes aplicáveis de saída, documentos de materiais, entrada de serviços, faturas, contabilidade e compensação. A consulta inclui valores de exemplo explícitos para objetos específicos do sistema, pois EKKO e EKPO, por si só, não representam essas fontes.
- Normalize todos os eventos de origem para que tenham a mesma estrutura de Event Log. Cada linha deve conter PurchaseOrderNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate, VendorId, UserName, TotalNetAmount, PurchaseRequisitionNumber, RequestedDeliveryDate e DocumentType. Mantenha as ocorrências múltiplas de uma atividade quando a fonte contiver vários eventos válidos.
- Valide os registros de data e hora, remova apenas linhas de origem exatamente duplicadas e não infira atividades sem um registro de origem. O ProcessMind lê o Event Log como está. Portanto, cada atividade exibida na visualização do processo precisa estar presente em uma linha explícita.
- Exporte os resultados como arquivo delimitado ou conjunto de resultados do banco de dados, com uma linha de cabeçalho e nomes de coluna estáveis. Use um formato de registro de data e hora compatível com a configuração de carregamento do ProcessMind, mantenha PurchaseOrderNumber como texto e carregue todo o Event Log pela conexão de dados configurada no ProcessMind.
Configuração
- Objetos de origem: EKKO e EKPO são as fontes confirmadas para cabeçalhos e itens de pedidos de compra. Configure os objetos adicionais para requisições, status de liberação, histórico de alterações, saída, movimentações de mercadorias, folhas de entrada de serviços, faturas, pagamentos e compensação de acordo com a versão do SAP S/4HANA e o modelo de dados ativo.
- Identificador do caso: Use PurchaseOrderNumber como identificador do caso. Associe os eventos no nível do item ao número do pedido de compra e mantenha as referências dos itens em uma coluna adicional específica da fonte, se necessário.
- Período: Comece com três a seis meses. Para cargas históricas, processe períodos menores e reconcilie os limites sobrepostos para evitar omissões.
- Filtros: Configure os filtros de código da empresa, tipo de documento, VendorId, organização de compras, grupo de compras e data do evento de acordo com o escopo necessário. Os filtros de código da empresa e tipo de documento devem usar valores válidos no sistema de destino.
- Semântica dos eventos: A criação e a exclusão podem ser registradas explicitamente quando os campos ou logs relevantes estiverem disponíveis. Aprovação e conclusão são eventos baseados em status e exigem registros de data e hora configurados. Não crie linhas apenas com base no status atual, sem um registro de data e hora do evento que possa ser comprovado.
- Performance: Aplique filtros de data dos eventos e escopo organizacional o quanto antes, some os dados de EKPO antes de associá-los às fontes de eventos sempre que possível e execute cargas históricas grandes em períodos menores. Garanta que as estatísticas do banco de dados estejam adequadas e evite associações sem restrições entre fontes de itens, contabilidade e histórico de alterações.
- Registro de data e hora da atualização: Defina LastDataUpdate como o registro de data e hora da execução da extração para todas as linhas de cada execução.
- Pré-requisitos: São necessários conectividade com SAP HANA, autorização de leitura para todos os objetos de origem configurados, acesso aos dados relevantes de compras, gestão de estoque, aquisição de serviços, verificação de faturas e contas a pagar, além de uma conexão do ProcessMind capaz de importar o arquivo ou conjunto de resultados selecionado.
- Configuração específica do sistema: Substitua todos os valores de exemplo entre colchetes na consulta por uma tabela, view, coluna ou expressão aprovada no sistema SAP S/4HANA de destino. Não exponha credenciais na consulta nem na configuração da extração.
Consulta de exemplo sql
WITH
params AS (
SELECT
CAST('[Start timestamp]' AS TIMESTAMP) AS start_ts,
CAST('[End timestamp]' AS TIMESTAMP) AS end_ts,
CAST(CURRENT_TIMESTAMP AS TIMESTAMP) AS last_data_update,
CAST('[Source system]' AS NVARCHAR(100)) AS source_system
FROM DUMMY
),
po_base AS (
SELECT
h.MANDT,
h.EBELN AS PurchaseOrderNumber,
h.LIFNR AS VendorId,
h.BSART AS DocumentType,
h.BUKRS AS CompanyCode,
CAST(h.AEDAT AS DATE) AS POChangedDate,
CAST(h.AEDAT AS TIMESTAMP) AS POChangedTimestamp,
CAST(h.ERNAM AS NVARCHAR(100)) AS POCreatedBy,
CAST(h.BEDAT AS DATE) AS PODate,
CAST(h.EBELN AS NVARCHAR(20)) AS PurchaseOrderKey,
CAST(SUM(COALESCE(i.NETWR, 0)) AS DECIMAL(23, 2)) AS TotalNetAmount,
CAST(MIN(i.BEDNR) AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
CAST(MIN(i.EINDT) AS DATE) AS RequestedDeliveryDate
FROM EKKO h
INNER JOIN EKPO i
ON i.MANDT = h.MANDT
AND i.EBELN = h.EBELN
WHERE h.AEDAT >= (SELECT start_ts FROM params)
AND h.AEDAT < (SELECT end_ts FROM params)
AND h.BUKRS IN ([Company Code filter])
AND h.BSART IN ([Document Type filter])
GROUP BY
h.MANDT,
h.EBELN,
h.LIFNR,
h.BSART,
h.BUKRS,
h.AEDAT,
h.ERNAM,
h.BEDAT
),
po_items AS (
SELECT
i.MANDT,
i.EBELN AS PurchaseOrderNumber,
i.EBELP,
i.BANFN AS PurchaseRequisitionNumber,
i.BEDNR,
i.EINDT AS RequestedDeliveryDate
FROM EKPO i
),
events AS (
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(r.[Purchase requisition creation timestamp] AS TIMESTAMP) AS EventTime,
s.source_system AS SourceSystem,
s.last_data_update AS LastDataUpdate,
p.VendorId,
CAST(r.[Purchase requisition created by] AS NVARCHAR(100)) AS UserName,
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition source table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition creation timestamp] >= s.start_ts
AND r.[Purchase requisition creation timestamp] < s.end_ts
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(r.[Purchase requisition approval timestamp] AS TIMESTAMP) AS EventTime,
s.source_system,
s.last_data_update,
p.VendorId,
CAST(r.[Purchase requisition approver] AS NVARCHAR(100)),
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)),
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition approval history table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition approval timestamp] >= s.start_ts
AND r.[Purchase requisition approval timestamp] < s.end_ts
AND r.[Approval status] = '[Approved status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Created',
CAST(p.PODate AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
p.POCreatedBy,
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
CROSS JOIN params s
WHERE p.PODate >= CAST(s.start_ts AS DATE)
AND p.PODate < CAST(s.end_ts AS DATE)
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Approved',
CAST(a.[Purchase order approval timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(a.[Approver] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order release history table or view] a
ON a.[Client] = p.MANDT
AND a.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE a.[Purchase order approval timestamp] >= s.start_ts
AND a.[Purchase order approval timestamp] < s.end_ts
AND a.[Release status] = '[Approved release status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Sent to Vendor',
CAST(o.[Output timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(o.[Output user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order output source table or view] o
ON o.[Client] = p.MANDT
AND o.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE o.[Output timestamp] >= s.start_ts
AND o.[Output timestamp] < s.end_ts
AND o.[Output status] = '[Successfully processed output status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Changed',
CAST(c.[Change timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(c.[Changed by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order change history table or view] c
ON c.[Client] = p.MANDT
AND c.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE c.[Change timestamp] >= s.start_ts
AND c.[Change timestamp] < s.end_ts
AND c.[Change indicator] = '[Changed indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Receipt Posted',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods receipt movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Services Confirmation Entered',
CAST(v.[Service entry timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(v.[Entered by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your service entry sheet source table or view] v
ON v.[Client] = p.MANDT
AND v.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE v.[Service entry timestamp] >= s.start_ts
AND v.[Service entry timestamp] < s.end_ts
AND v.[Service entry status] = '[Accepted service entry status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Returned',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods return movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Received',
CAST(i.[Invoice posting timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Invoice posting timestamp] >= s.start_ts
AND i.[Invoice posting timestamp] < s.end_ts
AND i.[Invoice status] = '[Posted invoice status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Paid',
CAST(i.[Clearing timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Cleared by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice clearing source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Clearing timestamp] >= s.start_ts
AND i.[Clearing timestamp] < s.end_ts
AND i.[Clearing status] = '[Cleared status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Completed',
CAST(x.[Completion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(x.[Completion user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order item status source table or view] x
ON x.[Client] = p.MANDT
AND x.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE x.[Completion timestamp] >= s.start_ts
AND x.[Completion timestamp] < s.end_ts
AND x.[Delivery completed indicator] = '[Set indicator value]'
AND x.[Final invoice indicator] = '[Set indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Deleted',
CAST(d.[Deletion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(d.[Deleted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order deletion history table or view] d
ON d.[Client] = p.MANDT
AND d.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE d.[Deletion timestamp] >= s.start_ts
AND d.[Deletion timestamp] < s.end_ts
AND d.[Deletion indicator] = '[Set deletion indicator value]'
)
SELECT
PurchaseOrderNumber,
ActivityName,
EventTime,
SourceSystem,
LastDataUpdate,
VendorId,
UserName,
TotalNetAmount,
PurchaseRequisitionNumber,
RequestedDeliveryDate,
DocumentType
FROM events
WHERE PurchaseOrderNumber IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY PurchaseOrderNumber, EventTime, ActivityName; Etapas
- Especificação e design: Defina a estrutura final do arquivo de Event Log, incluindo todos os atributos obrigatórios e recomendados. Documente as tabelas SAP específicas, como EKKO, EKPO, EKBE, CDHDR, CDPOS e BKPF, que serão usadas como fonte de dados para cada uma das 13 atividades obrigatórias.
- Criação do programa: Na SAP GUI, acesse o Editor ABAP pela transação SE38 ou SE80. Crie um novo programa executável, por exemplo, Z_PM_PO_EXTRACT.
- Definição da tela de seleção: Programe a tela de seleção do relatório para que os usuários possam filtrar os dados que querem extrair. Inclua parâmetros para o período de criação do pedido de compra (P_AEDAT), o código da empresa (P_BUKRS) e o tipo de documento de compras (P_BSART).
- Declarações de dados: Defina as tabelas internas e as estruturas de dados necessárias para o programa. Isso inclui uma tabela interna para o Event Log final, de acordo com a estrutura definida na etapa de especificação.
- Implementação da lógica de seleção de dados: Escreva a lógica ABAP principal para selecionar os dados de cada uma das 13 atividades. Isso envolve uma série de instruções SELECT nas tabelas SAP relevantes, com associações quando necessário. Para eventos baseados em alterações, leia as tabelas de log de alterações CDHDR e CDPOS.
- Transformação e mapeamento dos dados: Para cada registro recuperado, mapeie os campos das tabelas SAP para as colunas correspondentes da tabela interna do Event Log final. Defina ActivityName de acordo com o evento processado, por exemplo, 'Pedido de compra criado'. Converta os campos de data e hora para um formato de registro de data e hora consistente em EventTime.
- Consolidação dos dados dos eventos: Depois de processar os 13 tipos de atividade, reúna todos os dados em uma única tabela interna unificada. Essa tabela representa o Event Log completo dos pedidos de compra selecionados.
- Implementação da saída para arquivo: Adicione uma função para gravar a tabela interna final em um arquivo. Recomendamos usar o método cl_gui_frontend_services=>gui_download para que os usuários salvem o arquivo como CSV no computador local, ou OPEN DATASET para salvá-lo no servidor de aplicações SAP e processá-lo em segundo plano.
- Criação de código de transação (opcional): Para facilitar o acesso ao programa pelos usuários de negócios, use a transação SE93 para criar um código de transação personalizado, por exemplo, ZPM_PO_EXTRACT, que execute o programa ABAP.
- Agendamento de execução em segundo plano: Para grandes volumes de dados ou extrações automatizadas, use a transação SM36 para agendar a execução do programa em segundo plano. O arquivo de saída será gravado no caminho do servidor de aplicações especificado na lógica do programa.
Configuração
- Critérios de seleção: O programa deve incluir parâmetros de seleção para filtrar os dados com eficiência. Os principais filtros são:
- Período: Um período obrigatório para a data de criação do pedido de compra (EKKO-AEDAT). Recomendamos começar com um intervalo de 3 a 6 meses para controlar o volume de dados e a performance do relatório.
- Código da empresa (BUKRS): Essencial para organizações com várias entidades legais, pois limita o escopo da extração.
- Tipo de documento de compras (BSART): Permite filtrar tipos específicos de pedidos de compra, como pedido padrão, contrato-quadro ou pedido de transferência de estoque, para direcionar a análise.
- Leitura do log de alterações: A extração de atividades como 'Pedido de compra aprovado' ou 'Pedido de compra alterado' depende da leitura das tabelas de log de alterações do SAP (CDHDR, CDPOS), o que pode consumir muitos recursos. Otimize a lógica ABAP para selecionar apenas as classes de objeto necessárias (EINKBELEG, BANF) e as combinações de tabela e campo relevantes.
- Autorizações: O usuário ou a conta técnica que executar este relatório precisa de amplas autorizações de leitura para tabelas de vários módulos SAP, incluindo Materials Management (MM), Financial Accounting (FI) e tabelas de todo o sistema. Isso inclui tabelas como EKKO, EKPO, EBAN, EKBE, BKPF, BSAK, RBKP, NAST, CDHDR e CDPOS.
- Execução em segundo plano: Para extrações que abrangem mais de alguns meses de dados ou são executadas em um sistema com alto volume de transações, execute sempre o programa em segundo plano para evitar que o tempo limite encerre o processo interativo.
Consulta de exemplo abap
REPORT z_pm_po_extract.
" ====================================================================
" SELECTION SCREEN
" ====================================================================
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
SELECT-OPTIONS: s_aedat FOR sy-datum OBLIGATORY.
SELECT-OPTIONS: s_bukrs FOR ekko-bukrs.
SELECT-OPTIONS: s_bsart FOR ekko-bsart.
PARAMETERS: p_sysid TYPE string DEFAULT '[Your SAP System ID]'.
SELECTION-SCREEN END OF BLOCK b1.
" ====================================================================
" DATA DECLARATIONS
" ====================================================================
TYPES: BEGIN OF ty_event_log,
purchaseordernumber TYPE ebeln,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
vendorid TYPE lifnr,
username TYPE ernam,
totalnetamount TYPE netwr,
purchaserequisitionnumber TYPE banfn,
requesteddeliverydate TYPE eedat,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lt_ekko TYPE TABLE OF ekko,
lt_ekpo TYPE TABLE OF ekpo.
" ====================================================================
" START OF SELECTION
" ====================================================================
START-OF-SELECTION.
" Get current timestamp for LastDataUpdate
GET TIME STAMP FIELD ls_event_log-lastdataupdate.
ls_event_log-sourcesystem = p_sysid.
" --- Initial Data Selection: Purchase Orders in Scope ---
SELECT * FROM ekko INTO TABLE lt_ekko
WHERE aedat IN s_aedat
AND bukrs IN s_bukrs
AND bsart IN s_bsart.
IF lt_ekko IS INITIAL.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'S' DISPLAY LIKE 'E'.
RETURN.
ENDIF.
SELECT * FROM ekpo INTO TABLE lt_ekpo
FOR ALL ENTRIES IN lt_ekko
WHERE ebeln = lt_ekko-ebeln.
" --- 1. Purchase Requisition Created ---
SELECT ban.banfn, ban.erdat, ban.erzet, ban.ernam,
ekpo.ebeln, ekpo.netwr, ekpo.eindt, ekpo.bsart, ekpo.lifnr, ekko.bukrs
FROM eban AS ban
INNER JOIN ekpo AS ekpo ON ban.banfn = ekpo.banfn AND ban.bnfpo = ekpo.bnfpo
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created INTO DATA(ls_pr_created).
ls_event_log-purchaseordernumber = ls_pr_created-ebeln.
ls_event_log-activityname = 'Purchase Requisition Created'.
CONVERT DATE ls_pr_created-erdat TIME ls_pr_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_pr_created-lifnr.
ls_event_log-username = ls_pr_created-ernam.
ls_event_log-totalnetamount = ls_pr_created-netwr.
ls_event_log-purchaserequisitionnumber = ls_pr_created-banfn.
ls_event_log-requesteddeliverydate = ls_pr_created-eindt.
ls_event_log-documenttype = ls_pr_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 2. Purchase Requisition Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = ekpo.banfn
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE h.objectclas = 'BANF'
AND p.tabname = 'EBAN'
AND p.fname = 'FRGZU'
AND p.value_new = 'X' "Configure based on your system release indicator for 'Approved'
AND ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_approved).
LOOP AT lt_pr_approved INTO DATA(ls_pr_approved).
SELECT SINGLE ebeln FROM ekpo INTO ls_event_log-purchaseordernumber WHERE banfn = ls_pr_approved-objectid.
ls_event_log-activityname = 'Purchase Requisition Approved'.
CONVERT DATE ls_pr_approved-udate TIME ls_pr_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_pr_approved-username.
" Other attributes can be populated with another SELECT if needed.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 3. Purchase Order Created ---
LOOP AT lt_ekko INTO DATA(ls_ekko_created).
ls_event_log-purchaseordernumber = ls_ekko_created-ebeln.
ls_event_log-activityname = 'Purchase Order Created'.
CONVERT DATE ls_ekko_created-aedat TIME ls_ekko_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_ekko_created-lifnr.
ls_event_log-username = ls_ekko_created-ernam.
ls_event_log-totalnetamount = ls_ekko_created-rlwrt.
ls_event_log-purchaserequisitionnumber = ''. "Can be enriched later if needed
ls_event_log-requesteddeliverydate = ''. "Can be enriched from EKPO
ls_event_log-documenttype = ls_ekko_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 4. Purchase Order Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKKO'
AND p.fname = 'FRGKE'
AND p.value_new = 'R' "R for Released
AND h.objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_approved).
LOOP AT lt_po_approved INTO DATA(ls_po_approved).
ls_event_log-purchaseordernumber = ls_po_approved-objectid.
ls_event_log-activityname = 'Purchase Order Approved'.
CONVERT DATE ls_po_approved-udate TIME ls_po_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_approved-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 5. Purchase Order Sent to Vendor ---
SELECT n.objky, n.vstat, n.datvr, n.uhrvr, e.ernam
FROM nast AS n
INNER JOIN ekko AS e ON n.objky = e.ebeln
WHERE n.kappl = 'EF' "Application for Purchasing
AND n.kschl = '[Your PO Output Type]' "e.g. NEU
AND n.vstat = '1' "Successfully processed
AND n.objky IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_sent).
LOOP AT lt_po_sent INTO DATA(ls_po_sent).
ls_event_log-purchaseordernumber = ls_po_sent-objky.
ls_event_log-activityname = 'Purchase Order Sent to Vendor'.
CONVERT DATE ls_po_sent-datvr TIME ls_po_sent-uhrvr INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_sent-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 6. Purchase Order Changed ---
SELECT objectid, udate, utime, username FROM cdhdr
WHERE objectclas = 'EINKBELEG'
AND tcode IN ('ME22', 'ME22N')
AND objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_changed).
LOOP AT lt_po_changed INTO DATA(ls_po_changed).
ls_event_log-purchaseordernumber = ls_po_changed-objectid.
ls_event_log-activityname = 'Purchase Order Changed'.
CONVERT DATE ls_po_changed-udate TIME ls_po_changed-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_changed-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 7. Goods Receipt Posted & 9. Goods Returned ---
SELECT e.ebeln, m.budat, m.cpudt, m.cputm, m.usnam, b.shkzg, b.bwart
FROM mkpf AS m
INNER JOIN mseg AS s ON m.mblnr = s.mblnr AND m.mjahr = s.mjahr
INNER JOIN t156 AS t ON s.bwart = t.bwart
INNER JOIN ekbe AS e ON s.ebeln = e.ebeln AND s.ebelp = e.ebelp AND s.mblnr = e.belnr AND s.mjahr = e.gjahr
WHERE e.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND e.bwart IN ('101', '102', '122', '123') "GR, GR Reversal, Return
INTO TABLE @DATA(lt_goods_mvmt).
LOOP AT lt_goods_mvmt INTO DATA(ls_goods_mvmt).
ls_event_log-purchaseordernumber = ls_goods_mvmt-ebeln.
IF ls_goods_mvmt-bwart = '101'.
ls_event_log-activityname = 'Goods Receipt Posted'.
ELSE.
ls_event_log-activityname = 'Goods Returned'.
ENDIF.
CONVERT DATE ls_goods_mvmt-cpudt TIME ls_goods_mvmt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_goods_mvmt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 8. Services Confirmation Entered ---
SELECT h.erdat, h.erzeit, h.ernam, l.ebeln
FROM essr AS h
INNER JOIN esll AS l ON h.lblni = l.lblni
WHERE l.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_services).
LOOP AT lt_services INTO DATA(ls_services).
ls_event_log-purchaseordernumber = ls_services-ebeln.
ls_event_log-activityname = 'Services Confirmation Entered'.
CONVERT DATE ls_services-erdat TIME ls_services-erzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_services-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 10. Invoice Received ---
SELECT r.ebeln, r.cpudt, r.cputm, r.usnam
FROM rbkp AS r
WHERE r.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_invoice_rcvd).
LOOP AT lt_invoice_rcvd INTO DATA(ls_invoice_rcvd).
ls_event_log-purchaseordernumber = ls_invoice_rcvd-ebeln.
ls_event_log-activityname = 'Invoice Received'.
CONVERT DATE ls_invoice_rcvd-cpudt TIME ls_invoice_rcvd-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_rcvd-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 11. Invoice Paid ---
SELECT b.ebeln, s.augdt, s.augbl, b.usnam
FROM rbkp AS b
INNER JOIN bseg AS e ON b.belnr = e.belnr AND b.gjahr = e.gjahr
INNER JOIN bsak AS s ON e.bukrs = s.bukrs AND e.belnr = s.belnr AND e.gjahr = s.gjahr AND e.buzei = s.buzei
WHERE b.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND s.augdt IS NOT NULL
INTO TABLE @DATA(lt_invoice_paid).
LOOP AT lt_invoice_paid INTO DATA(ls_invoice_paid).
ls_event_log-purchaseordernumber = ls_invoice_paid-ebeln.
ls_event_log-activityname = 'Invoice Paid'.
CONVERT DATE ls_invoice_paid-augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_paid-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 12. Purchase Order Completed & 13. Purchase Order Deleted (via Change Docs) ---
SELECT h.objectid, h.udate, h.utime, h.username, p.fname
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = |{ ekpo.ebeln }{ ekpo.ebelp }|
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKPO'
AND p.fname IN ('ELIKZ', 'EREKZ', 'LOEKZ')
AND p.value_new = 'X'
AND ekpo.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_status_change).
LOOP AT lt_po_status_change INTO DATA(ls_po_status_change).
ls_event_log-purchaseordernumber = substring( val = ls_po_status_change-objectid, off = 0, len = 10 ).
CASE ls_po_status_change-fname.
WHEN 'LOEKZ'.
ls_event_log-activityname = 'Purchase Order Deleted'.
WHEN 'ELIKZ' OR 'EREKZ'.
"This logic may need refinement to check if both are now set.
ls_event_log-activityname = 'Purchase Order Completed'.
ENDCASE.
CONVERT DATE ls_po_status_change-udate TIME ls_po_status_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_status_change-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- Final Output to CSV ---
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lt_event_log. Pronto para começar?
Este Template oferece uma base sólida para você começar sua jornada com Process Mining. Use os dados do SAP S/4HANA para encontrar oportunidades de eficiência e transformar seu processo de compras ao pagamento hoje mesmo.
Otimize seus pedidos de compra no processo de compras ao pagamento e reduza o tempo de ciclo
Elimine ineficiências e reduza em 30% o tempo de ciclo dos pedidos de compra no processo de compras ao pagamento.
Não é necessário informar cartão de crédito. Configure tudo em poucos minutos.