Seu Data Template Purchase to Pay - Requisition
Seu Data Template Purchase to Pay - Requisition
- Atributos recomendados para coletar em uma análise detalhada
- Atividades principais para acompanhar na descoberta do processo
- Orientações para extrair dados do SAP S/4HANA
Procure to Pay - Atributos da requisição
| Nome | Descrição | ||
|---|---|---|---|
| Hora do evento EventTime | A data e a hora exatas em que uma atividade específica ocorreu. | ||
| Descrição A Hora do evento é o carimbo de data e hora que registra quando uma atividade ocorreu. Esses dados são essenciais para ordenar cronologicamente os eventos dentro de um caso e servem de base para todos os cálculos de duração e performance no Process Mining. Por exemplo, a diferença entre os eventos "Requisição enviada" e "Requisição aprovada" determina o tempo de ciclo da aprovação. Carimbos de data e hora precisos são essenciais para analisar a performance do processo, identificar atrasos e monitorar o cumprimento dos acordos de nível de serviço. Esse atributo permite criar Dashboards que visualizam tempos de ciclo, acompanham requisições paradas e comparam a performance em diferentes períodos. Por que isso importa Esse carimbo de data e hora é essencial para ordenar eventos, calcular tempos de ciclo e analisar a performance e os gargalos do processo. Onde obter Os carimbos de data e hora normalmente vêm dos cabeçalhos dos documentos de alteração (CDHDR-UDATE, CDHDR-UTIME) ou dos registros de eventos do Workflow. Exemplos 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID da requisição de compra PurchaseRequisitionId | O identificador exclusivo de um documento de requisição de compra. | ||
| Descrição O ID da requisição de compra é a chave primária que identifica exclusivamente cada solicitação de bens ou serviços no SAP S/4HANA. Ele funciona como o identificador central do caso, vinculando todas as atividades e alterações relacionadas a uma requisição específica, desde sua criação até seu estado final, como aprovação, rejeição ou conversão em um pedido de compra. No Process Mining, esse atributo é fundamental para reconstruir o ciclo de vida completo de cada requisição. Ao agrupar todos os eventos relacionados sob um único ID da requisição de compra, os analistas conseguem medir com precisão os tempos de ciclo, acompanhar mudanças de status e analisar os diferentes caminhos que uma requisição pode seguir no processo de aprovação. Por que isso importa Esse é o identificador essencial do caso que conecta todas as etapas relacionadas do processo, permitindo uma visão completa e coerente do ciclo de vida da requisição. Onde obter Esse atributo é o número da requisição de compra, encontrado na tabela EBAN, campo BANFN. Exemplos 100178901001789110017892 | |||
| Nome da atividade ActivityName | O nome da atividade de negócio que ocorreu em um ponto específico do processo de requisição. | ||
| Descrição O Nome da atividade descreve um evento ou tarefa específica que ocorreu durante o ciclo de vida de uma requisição de compra. Essas atividades são derivadas de registros do sistema, como documentos de alteração e históricos de Workflow, e representam marcos importantes do processo, como "Requisição criada", "Etapa de aprovação iniciada" ou "Pedido de compra criado". Analisar essas atividades permite visualizar o fluxo do processo, identificar gargalos e medir o tempo gasto em diferentes etapas. Entender a sequência e a frequência de atividades como "Requisição alterada" ou "Requisição rejeitada" é essencial para identificar ineficiências e oportunidades de melhoria no processo. Por que isso importa Ele define as etapas do processo, formando a base do mapa de processos e permitindo analisar o fluxo, as variações e os gargalos do processo. Onde obter Esse é um atributo derivado, normalmente construído pela interpretação de dados das tabelas de documentos de alteração (CDHDR, CDPOS) e dos registros de Workflow, como SWWLOGHIST. Exemplos Requisição criadaEtapa de aprovação concluídaRequisição aprovadaPedido de compra criado | |||
| Departamento Department | O departamento ou centro de custo ao qual os custos da requisição são atribuídos. | ||
| Descrição O atributo Departamento, geralmente representado pelo Centro de custo no SAP, identifica a unidade de negócio responsável pela compra solicitada. Ele é uma informação financeira e organizacional importante, atribuída no nível do item da requisição. No Process Mining, esse atributo é essencial para analisar a performance por departamento. Ele permite criar Dashboards que comparam métricas importantes, como tempo de ciclo, taxas de alteração e taxas de rejeição entre diferentes departamentos. Isso ajuda a identificar departamentos de alto desempenho, cujas práticas podem ser adotadas em outras áreas, além de departamentos que podem precisar de treinamento adicional ou suporte ao processo. Por que isso importa Permite comparar a performance entre unidades de negócio, destacando variações nos tempos de ciclo ou nas taxas de rejeição para identificar boas práticas e oportunidades de melhoria. Onde obter Esse é o Centro de custo, normalmente encontrado na tabela de atribuição contábil EBKN, campo KOSTL. Exemplos FIN-1001IT-2005MKT-3010 | |||
| ID do aprovador ApproverId | O identificador do usuário que realizou uma etapa de aprovação ou rejeição. | ||
| Descrição O ID do aprovador identifica especificamente o usuário que concluiu uma atividade de aprovação ou rejeição. Ele é diferente do ID do usuário geral, pois se concentra exclusivamente nos responsáveis pelas decisões dentro do Workflow de aprovação. Capturar essas informações é essencial para analisar o processo de aprovação em detalhes. Esse atributo permite analisar o comportamento nas aprovações, como identificar gerentes com tempos de aprovação longos ou que rejeitam requisições com frequência. Ele é fundamental para Dashboards focados nos tempos de ciclo das etapas de aprovação e na análise de gargalos do Workflow, ajudando a identificar pessoas ou funções específicas que podem estar causando atrasos. Por que isso importa Identifica o responsável específico pela decisão em uma etapa de aprovação, permitindo analisar detalhadamente os tempos de ciclo e os gargalos da aprovação por pessoa ou função. Onde obter Essas informações normalmente são extraídas de tabelas do SAP Business Workflow, como SWW_WI2OBJ e SWWLOGHIST, que vinculam itens de trabalho ao usuário que os concluiu. Exemplos MJOHNSONCWILLIAMSLBLACK | |||
| ID do usuário UserId | O identificador do usuário que criou a requisição ou realizou uma atividade específica. | ||
| Descrição O ID do usuário identifica o funcionário ou usuário do sistema responsável por um evento específico no ciclo de vida da requisição. Pode ser a pessoa que criou a requisição, o gerente que a aprovou ou o agente que a alterou. Em etapas automatizadas, pode ser o ID de um usuário do sistema ou de processamento em lote. Analisar por ID do usuário ajuda a entender comportamentos específicos, a distribuição da carga de trabalho e a performance. Esse atributo é importante para identificar necessidades de treinamento, reconhecer profissionais de alto desempenho e garantir a responsabilização no processo. Ele também apoia a análise da performance por departamento quando combinado com os dados mestres dos usuários. Por que isso importa Permite analisar a performance dos usuários, a distribuição da carga de trabalho e a conformidade do processo. É essencial para identificar oportunidades de treinamento e gargalos de recursos. Onde obter Encontrado em EBAN-ERNAM para o criador. Para alterações posteriores, está em CDHDR-USERNAME. Para aprovações, está nos registros do Workflow. Exemplos JSMITHRROEWF-BATCH | |||
| Status da requisição RequisitionStatus | O status atual de processamento ou aprovação da requisição de compra. | ||
| Descrição O Status da requisição indica o estado atual da requisição em seu ciclo de vida. No SAP, ele costuma ser representado pelo Indicador de liberação, que mostra se uma requisição está bloqueada, em aprovação, parcialmente aprovada ou totalmente aprovada. Esse status muda conforme a requisição avança pelo Workflow. Acompanhar o status ao longo do tempo é fundamental para entender o fluxo do processo. Isso ajuda a identificar onde as requisições estão parando e por quanto tempo. Analisar as transições entre status permite obter uma visão detalhada do processo de aprovação e de suas variações. Por que isso importa Indica o estado atual de uma requisição, essencial para acompanhar o progresso, identificar gargalos e analisar o fluxo do processo. Onde obter O status de liberação geralmente é determinado pelo Indicador de liberação, encontrado na tabela EBAN, campo FRGZU. Exemplos B1S | |||
| Tipo de requisição RequisitionType | Um código que classifica a requisição de compra, por exemplo, para itens padrão, serviços ou despesas de capital. | ||
| Descrição O Tipo de requisição, também conhecido como Tipo de documento no SAP, é um campo de configuração importante que categoriza as requisições de compra. Tipos diferentes podem acionar Workflows de aprovação distintos, ter configurações de campos diferentes e ser usados para finalidades de negócio diferentes, como itens padrão de estoque, serviços externos ou compras de ativos. Ao analisar o processo por Tipo de requisição, as organizações conseguem entender como diferentes tipos de solicitação são tratados. Isso permite comparar performance, tempos de ciclo e caminhos de aprovação entre categorias, revelando se determinados tipos de requisição são mais ou menos eficientes e ajudando a direcionar melhorias no processo. Por que isso importa Categoriza as requisições para permitir análises comparativas, ajudando a entender se diferentes tipos de solicitação têm fluxos, gargalos ou tempos de ciclo distintos. Onde obter Esse é o campo Tipo de documento, encontrado na tabela EBAN, campo BSART. Exemplos NBFORV | |||
| Valor da requisição RequisitionAmount | O valor monetário total da requisição de compra. | ||
| Descrição O Valor da requisição representa o custo total estimado dos bens ou serviços solicitados. Esse valor costuma ser um fator importante para determinar a complexidade e a duração do Workflow de aprovação, já que requisições de maior valor normalmente exigem mais níveis de aprovação. Analisar esse atributo permite segmentar o processo por valor. Ele ajuda a responder perguntas como: "Requisições de alto valor demoram mais para ser aprovadas?" ou "Qual é o valor das requisições que são rejeitadas com frequência?". Essa é uma dimensão essencial para entender o impacto financeiro das ineficiências do processo. Por que isso importa Ajuda a segmentar o processo pelo impacto financeiro, geralmente correlacionado à complexidade da aprovação e ao tempo de ciclo. É essencial para a análise do processo com base em valor. Onde obter O valor total pode ser encontrado na tabela EBAN, campo GFWERT. O valor no nível do item está em EBAN-PREIS. Exemplos 1500.0075000.50250.75 | |||
| Data necessária RequiredByDate | A data até a qual o solicitante precisa dos bens ou serviços solicitados. | ||
| Descrição A Data necessária, ou Data de entrega no SAP, especifica quando os bens ou serviços do item da requisição são necessários. Essa data é definida pelo solicitante e serve como meta para todo o processo de compras. Esse atributo é essencial para calcular o KPI de Taxa de conclusão da requisição no prazo. Ao comparar a Data necessária com a data da aprovação final ou da criação do pedido de compra, a organização consegue medir sua capacidade de cumprir os níveis de serviço internos e as necessidades do negócio. Analisar as requisições que não cumprem essa data pode revelar atrasos sistêmicos no processo de compras. Por que isso importa Define a data-alvo de conclusão de uma solicitação, permitindo medir as entregas no prazo e o cumprimento dos níveis de serviço internos. Onde obter Essa é a Data de entrega, encontrada no nível do item na tabela EBAN, campo LFDAT. Exemplos 2023-11-152023-12-012024-01-20 | |||
| É automatizado IsAutomated | Um indicador que mostra se uma atividade foi realizada por um usuário do sistema, e não por uma pessoa. | ||
| Descrição O atributo Is Automated é um indicador booleano que assume o valor verdadeiro quando uma atividade é executada por um sistema ou usuário de lote, como 'WF-BATCH' para ações de Workflow. Isso ajuda a distinguir as etapas manuais das automatizadas no processo. Esse atributo é essencial para medir o nível de automação do processo de requisição e calcular o KPI 'Automated Approval Rate'. Ao filtrar etapas automatizadas ou manuais, os analistas podem comparar a eficiência e identificar oportunidades de ampliar a automação, reduzindo o tempo de processamento e o esforço manual. Por que isso importa Distingue atividades executadas por pessoas daquelas conduzidas por sistemas, algo essencial para medir as taxas de automação e identificar oportunidades de automatizar tarefas manuais. Onde obter Este é um atributo derivado, normalmente baseado em uma regra que verifica se o User ID de um evento pertence a uma lista de usuários de sistema ou de lote conhecidos. Exemplos truefalse | |||
| É retrabalho IsRework | Um indicador que mostra se uma atividade representa retrabalho, como uma alteração feita após o envio. | ||
| Descrição Is Rework é um indicador booleano calculado que identifica atividades que representam trabalho sem valor agregado ou repetitivo. Um exemplo comum nesse processo é a atividade 'Requisition Amended' ocorrer depois que a requisição já foi enviada para aprovação, fazendo com que o processo de aprovação seja reiniciado. Esse atributo é essencial para quantificar o retrabalho no processo e seu impacto no tempo de ciclo geral. O Dashboard Requisition Amendment and Rework Rate usa esse indicador para destacar ineficiências do processo. Reduzir o retrabalho costuma ser um dos principais objetivos das iniciativas de melhoria de processos, pois isso se traduz diretamente em economia de tempo e esforço. Por que isso importa Sinaliza atividades que representam esforço desperdiçado ou repetição, permitindo medir diretamente o retrabalho e seu impacto na eficiência do processo. Onde obter Este é um atributo calculado. Normalmente, a lógica sinaliza qualquer atividade 'Requisition Amended' que ocorra depois da primeira atividade 'Requisition Submitted For Approval' como retrabalho. Exemplos truefalse | |||
| Hora de término EndTime | A data e a hora exatas em que uma atividade específica foi concluída. | ||
| Descrição EndTime é o timestamp que registra quando uma atividade foi concluída. Embora muitos eventos gerados pelo sistema sejam instantâneos, o que significa que StartTime é igual a EndTime, tarefas humanas, como aprovações, podem ter início e fim distintos. Esse timestamp marca a conclusão do trabalho. Ter um EndTime separado permite medir com mais precisão o tempo de processamento ativo em comparação com o tempo de espera ocioso. Ele é usado em conjunto com StartTime para calcular a métrica ProcessingTime. Esse nível de detalhe aprimora a análise da utilização de recursos e da eficiência das tarefas manuais. Por que isso importa Marca a conclusão de uma atividade, permitindo calcular o tempo de processamento ativo e oferecendo uma visão mais detalhada da duração da tarefa. Onde obter É derivado de logs do Workflow que podem registrar tanto quando um item de trabalho foi criado (StartTime) quanto quando foi concluído (EndTime). Exemplos 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Moeda Currency | O código da moeda do valor da requisição. | ||
| Descrição Esse atributo especifica a moeda em que o valor da requisição é denominado, por exemplo, USD, EUR ou JPY. Ele fornece o contexto necessário para o atributo Valor da requisição, especialmente em organizações multinacionais que operam com várias moedas. Para realizar análises e relatórios financeiros precisos, é essencial considerar a moeda. Ao agregar ou comparar valores de requisições, todos os valores devem ser convertidos para uma moeda comum para garantir resultados relevantes. Esse atributo é pré-requisito para essas conversões. Por que isso importa Fornece o contexto essencial para o Valor da requisição, permitindo análises e comparações financeiras precisas em ambientes com várias moedas. Onde obter Esse dado é encontrado na tabela EBAN, campo WAERS. Exemplos USDEURGBP | |||
| Motivo da rejeição RejectionReason | O motivo informado quando uma requisição de compra é rejeitada. | ||
| Descrição O Motivo da rejeição explica por que um aprovador decidiu rejeitar uma requisição de compra. Os motivos podem incluir estouro do orçamento, informações incorretas, não conformidade com a política ou duplicidade de outra solicitação. Essas informações fornecem um contexto essencial para entender as falhas do processo. Analisar os motivos das rejeições ajuda a identificar as causas-raiz das ineficiências e do retrabalho. Por exemplo, se "Centro de custo incorreto" for um motivo frequente, isso indica a necessidade de melhorar o treinamento dos usuários ou a validação do sistema. Esse atributo é fundamental para o Dashboard de Análise de rejeições de requisições e para direcionar melhorias no processo. Por que isso importa Fornece a causa-raiz das falhas do processo, permitindo melhorias direcionadas para reduzir o retrabalho e aumentar a taxa de requisições corretas na primeira tentativa. Onde obter Esse geralmente não é um campo padrão. Ele pode ser capturado em elementos do contêiner do Workflow, textos longos associados à requisição ou campos personalizados. Exemplos Excede o orçamentoFornecedor incorretoSolicitação duplicada | |||
| Nível de urgência UrgencyLevel | Uma classificação da urgência da requisição, que pode influenciar sua prioridade de processamento. | ||
| Descrição O Nível de urgência indica a prioridade da solicitação de compra. Embora não exista um campo padrão específico para isso, algumas organizações usam campos como o Requirement Tracking Number para registrar essa informação. Assim, os solicitantes podem sinalizar necessidades críticas que exigem processamento acelerado. Analisar o impacto da urgência é importante para avaliar se o processo prioriza as solicitações críticas de forma eficaz. O Dashboard Urgency Level Impact Analysis usa esse atributo para comparar tempos de ciclo e taxas de aprovação entre requisições urgentes e padrão, ajudando a determinar se o tratamento prioritário está funcionando como esperado. Por que isso importa Permite analisar como a performance do processo varia em solicitações de alta prioridade, ajudando a validar se os itens urgentes estão realmente sendo acelerados. Onde obter Não existe um campo padrão de urgência. Algumas empresas usam o Requirement Tracking Number (EBAN-BEDAR) para essa finalidade. Também pode ser um campo personalizado. Exemplos AltaMédiaBaixa | |||
| Nome da etapa de aprovação ApprovalStepName | O nome ou a descrição específica de uma etapa de aprovação no Workflow. | ||
| Descrição O Nome da etapa de aprovação fornece uma descrição compreensível de uma etapa específica do Workflow de aprovação, como 'Manager Approval' ou 'VP Finance Approval'. Ele é mais descritivo do que uma atividade genérica 'Approval Step Completed'. Esse atributo é essencial para os Dashboards Approval Step Cycle Time e Workflow Bottleneck Analysis. Ele permite uma visão detalhada do processo de aprovação, tornando possível identificar exatamente quais etapas estão causando os maiores atrasos e onde o trabalho está se acumulando. Esse nível de detalhe é necessário para direcionar intervenções e simplificar a cadeia de aprovação. Por que isso importa Fornece detalhes granulares sobre as etapas de aprovação, permitindo identificar com precisão os gargalos no Workflow de aprovação multinível. Onde obter Essa informação é derivada da descrição da tarefa do Workflow, que pode ser encontrada vinculando o log do Workflow a tabelas de definição de tarefas, como T528T. Exemplos Aprovação do gerenteAprovação do diretorAprovação do VP de Finanças | |||
| Número do pedido de compra PurchaseOrderNumber | O número do pedido de compra criado a partir da requisição. | ||
| Descrição O Número do pedido de compra é o identificador do documento oficial de compras criado a partir de uma requisição aprovada. A criação de um pedido de compra costuma ser o resultado final e bem-sucedido de uma requisição, indicando que a solicitação foi convertida em um pedido formal com um fornecedor. Esse atributo é essencial para medir o KPI de tempo de ciclo entre requisição e pedido de compra e a taxa geral de conversão. Ele conecta o processo de requisição ao processo de compras subsequente, permitindo uma visão mais ampla e de ponta a ponta de todo o ciclo Purchase-to-Pay. Por que isso importa Vincula a requisição ao documento de compras subsequente, permitindo medir a taxa de conversão de requisição em pedido de compra e o tempo de ciclo. Onde obter Encontrado na tabela EBAN, campo EBELN, depois que um pedido de compra é criado a partir do item da requisição. Exemplos 450001789045000178914500017892 | |||
| Sistema de origem SourceSystem | Identifica a instância específica do SAP S/4HANA da qual os dados foram extraídos. | ||
| Descrição O atributo Sistema de origem indica o sistema de origem em que os dados do processo foram gerados. Em organizações com várias instâncias SAP, como sistemas diferentes para desenvolvimento, garantia de qualidade e produção, ou sistemas separados por região, esse campo é essencial para a governança e o contexto dos dados. Ele garante que os dados de diferentes fontes possam ser distinguidos, evitando agregações incorretas e permitindo análises específicas por sistema. É um atributo obrigatório para manter a linhagem dos dados e garantir a rastreabilidade dos dados do processo. Por que isso importa Fornece contexto essencial sobre a origem e a governança dos dados, especialmente em ambientes com vários sistemas, garantindo a rastreabilidade dos dados. Onde obter Normalmente, esse é o ID do sistema SAP (SID), que pode ser obtido de variáveis do sistema ou tabelas de configuração. Exemplos S4PECCS4H_PROD_01 | |||
| Última atualização dos dados LastDataUpdate | O carimbo de data e hora que indica quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Esse atributo registra a data e a hora da extração ou atualização mais recente dos dados a partir do sistema de origem. Ele é um metadado essencial para entender o nível de atualização dos dados analisados. Analistas e usuários de negócio dependem desse carimbo de data e hora para saber se os dados do processo refletem o estado mais atual das operações. Em qualquer análise de processo, saber quão atuais são os dados é fundamental para tomar decisões informadas. Esse atributo ajuda a alinhar as expectativas dos usuários e garante que as conclusões sejam baseadas em dados tão atualizados quanto a análise exige. Por que isso importa Indica o nível de atualização dos dados, essencial para confiar na análise e tomar decisões de negócio no momento certo. Onde obter Esse carimbo de data e hora é gerado e adicionado durante o processo de extração, transformação e carregamento (ETL) dos dados. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Procure to Pay - Atividades da requisição
| Atividade | Descrição | ||
|---|---|---|---|
| Etapa de aprovação concluída | Ocorre quando um aprovador toma uma decisão favorável sobre uma requisição, concluindo uma etapa do Workflow de aprovação em vários níveis. Isso é inferido a partir de uma mudança no status de liberação da requisição. | ||
| Por que isso importa Essa atividade permite uma análise detalhada do Workflow de aprovação, medindo o tempo gasto em cada etapa individual. Ela ajuda a identificar aprovadores eficientes e gargalos no processo. Onde obter Inferido a partir dos documentos de alteração (CDHDR/CDPOS) da tabela EBAN. Uma mudança no status do código de liberação, como no campo FRGZU, de não liberado para liberado para um código específico indica esse evento. Captura Acompanhe as alterações nos campos de status de liberação da EBAN para cada código de liberação definido na estratégia. Tipo de evento inferred | |||
| Pedido de compra criado | Indica que um pedido de compra foi gerado com referência ao item da requisição. Esse é um evento explícito do sistema que vincula a requisição a um documento de compras subsequente. | ||
| Por que isso importa Esse é um marco importante e um resultado bem-sucedido do processo de requisição. O tempo entre a aprovação da requisição e a criação do pedido de compra é um KPI crítico para medir a eficiência de compras. Onde obter Registrado explicitamente quando um item de pedido de compra é criado. O vínculo é armazenado na tabela EKPO (item do pedido de compra), que contém o número da requisição de origem (BANFN) e o número do item (BNFPO). Captura Relacione a tabela EKPO novamente à EBAN pelo número e pelo item da requisição. A data de criação do item do pedido de compra marca o evento. Tipo de evento explicit | |||
| Requisição aprovada | Marca a aprovação final e completa da requisição de compra, tornando-a elegível para conversão em um pedido de compra. Esse marco é inferido quando o status geral de liberação alcança seu estado final de aprovação. | ||
| Por que isso importa Esse é um marco crítico de sucesso e um ponto final comum para a análise do tempo de ciclo. Ele indica que a requisição passou por todas as verificações e está pronta para ser processada pela área de compras. Onde obter Inferido a partir de uma mudança de status na tabela EBAN, especificamente quando o indicador geral de liberação (FRGZU) ou o status de processamento (PROCSTAT) é atualizado para um valor final de "Aprovado". Captura Identifique o carimbo de data e hora em que o código de liberação final é aplicado ou o status geral da requisição muda para "Aprovado". Tipo de evento inferred | |||
| Requisição criada | Marca a criação inicial do documento de requisição de compra no sistema. Esse evento é capturado explicitamente quando um usuário salva uma nova requisição pela primeira vez, registrando o carimbo de data e hora da criação. | ||
| Por que isso importa Essa atividade funciona como o principal ponto de início da análise do ciclo de vida da requisição. Ela é essencial para medir o tempo de ciclo de ponta a ponta, desde a identificação da necessidade inicial até a aprovação final ou conversão em um pedido de compra. Onde obter Esse é um evento explícito capturado da tabela EBAN, usando os campos de data de criação (ERDAT) e hora de criação (ERZEIT) para o número específico da requisição de compra (BANFN). Captura Use os campos de carimbo de data e hora da criação (ERDAT, ERZEIT) da tabela EBAN para cada requisição (BANFN). Tipo de evento explicit | |||
| Requisição encerrada | Indica que o item da requisição foi totalmente processado e que não é possível criar mais pedidos de compra a partir dele. Esse status normalmente é definido automaticamente quando a quantidade total é pedida. | ||
| Por que isso importa Essa atividade representa a conclusão final e bem-sucedida do ciclo de vida do item da requisição. Ela confirma que a necessidade do negócio foi totalmente convertida em um pedido de compras. Onde obter Inferido a partir da tabela EBAN. Isso ocorre quando o indicador "Encerrado" (EBAKZ) é definido, normalmente quando a quantidade pedida nos pedidos de compra é igual à quantidade da requisição. Captura Identifique o evento em que o indicador "Encerrado" (EBAKZ) é definido na tabela EBAN por meio dos documentos de alteração. Tipo de evento inferred | |||
| Requisição rejeitada | Representa a rejeição final da requisição de compra por um aprovador, interrompendo o processo. Isso é capturado por uma atualização de status específica que indica a rejeição. | ||
| Por que isso importa Essa atividade é um ponto final crítico de falha. Analisar a frequência e os motivos das rejeições, além dos pontos do processo em que elas ocorrem, ajuda a identificar problemas de conformidade com políticas, orçamento ou qualidade da solicitação. Onde obter Inferido a partir de uma mudança de status na tabela EBAN. O status de processamento (PROCSTAT) ou um indicador de liberação recebe um valor que significa explicitamente "Rejeitado". Captura Identifique o carimbo de data e hora em que o status geral na EBAN é atualizado para o estado "Rejeitado" por meio dos documentos de alteração. Tipo de evento inferred | |||
| Etapa de aprovação iniciada | Indica que uma requisição está aguardando uma ação de um aprovador específico ou de um grupo de aprovação. Isso é inferido quando o status da requisição indica que ela está pendente de um código de liberação específico. | ||
| Por que isso importa Essa atividade é essencial para identificar gargalos na cadeia de aprovação. Analisar a duração desse estado ajuda a identificar requisições paradas e aprovadores sobrecarregados. Onde obter Inferido a partir dos campos de status de liberação da tabela EBAN, como FRGZU, e da configuração subjacente da estratégia de liberação. O evento começa quando um código de liberação específico se torna o próximo a ser processado. Captura Determine quando uma requisição entra em um estado no qual um código de liberação específico está pendente de aprovação, com base nos registros do Workflow ou nos campos de status. Tipo de evento inferred | |||
| Fonte de suprimento atribuída | Representa a ação de um comprador que atribui um fornecedor, contrato ou registro info específico a um item de requisição aprovado. Essa é uma etapa importante para preparar a requisição para a criação de um pedido de compra. | ||
| Por que isso importa Essa atividade conecta a aprovação ao pedido. Medir o tempo necessário para atribuir uma fonte ajuda a identificar atrasos na carga de trabalho do comprador e na eficiência do sourcing. Onde obter Inferido a partir da inserção de um valor nos campos relacionados à fonte de suprimento da tabela EBAN, como fornecedor fixo (LIFNR), registro info (INFNR) ou contrato (KONNR). Captura Acompanhe o preenchimento de campos como LIFNR, INFNR ou KONNR na tabela EBAN por meio dos documentos de alteração. Tipo de evento inferred | |||
| Redefinição da aprovação | Representa um evento em que todo o Workflow de aprovação é redefinido, geralmente devido a uma alteração significativa na requisição. Isso faz com que o processo de aprovação recomece no primeiro nível. | ||
| Por que isso importa Essa atividade destaca um retrabalho significativo que impacta fortemente o tempo de ciclo. Identificar as causas das redefinições de aprovação é essencial para simplificar o processo e reduzir atrasos. Onde obter Inferido a partir dos documentos de alteração (CDHDR/CDPOS) da tabela EBAN. Esse evento é detectado quando os campos de status de liberação, como FRGKZ ou FRGZU, são limpos depois de terem sido definidos parcial ou totalmente. Captura Procure, nos registros de alteração, uma mudança no status de liberação de um estado liberado para um estado não liberado. Tipo de evento inferred | |||
| Requisição alterada | Ocorre quando um usuário modifica um campo importante da requisição após sua criação inicial, como quantidade, preço ou material. Essa ação é registrada explicitamente no sistema de documentos de alteração do SAP. | ||
| Por que isso importa Acompanhar alterações é essencial para identificar ciclos de retrabalho e seu impacto nos tempos de ciclo. Uma alta frequência de alterações sugere problemas na qualidade dos dados ou mudanças nos requisitos, áreas importantes para a melhoria do processo. Onde obter Registrado explicitamente nas tabelas de documentos de alteração do SAP (CDHDR e CDPOS) para mudanças feitas na tabela EBAN. Cada alteração em um campo monitorado cria uma entrada. Captura Extraia eventos de alteração de CDHDR/CDPOS em que a classe do objeto seja BANF para requisições de compra. Tipo de evento explicit | |||
| Requisição enviada para aprovação | Representa o momento em que o solicitante envia formalmente a requisição, acionando o Workflow de aprovação. Normalmente, isso é inferido quando a estratégia de liberação da requisição é determinada e o status muda para "Em aprovação". | ||
| Por que isso importa Esse é um marco crítico que inicia a contagem dos KPIs de tempo de ciclo da aprovação. Analisar o tempo entre a criação e o envio pode revelar atrasos na fase de preparação da requisição. Onde obter Inferido a partir dos documentos de alteração (CDHDR/CDPOS) da tabela EBAN, especificamente quando os campos da estratégia de liberação, como FRGST, são preenchidos ou quando o status geral (PROCSTAT) muda para refletir um estado de aprovação em andamento. Captura Identifique a primeira entrada de documento de alteração que indique o início do Workflow de aprovação ou uma mudança de status para "Em aprovação". Tipo de evento inferred | |||
| Requisição retirada | Ocorre quando o solicitante original cancela ou exclui a requisição antes que ela seja totalmente processada. Normalmente, essa é uma ação explícita que define um indicador de exclusão no item da requisição. | ||
| Por que isso importa Acompanhar retiradas ajuda a entender a volatilidade da demanda e os motivos dos cancelamentos. Isso representa um estado terminal da requisição, impedindo o processamento posterior. Onde obter Capturado explicitamente quando o campo do indicador de exclusão (LOEKZ) na tabela EBAN é definido para um item de requisição. A alteração é registrada em CDHDR/CDPOS. Captura Identifique o evento em que o indicador de exclusão (LOEKZ) da tabela EBAN é definido como "L". Tipo de evento explicit | |||
Guias de extração
Etapas
- Pré-requisitos: confirme que você tem um usuário com as autorizações adequadas no SAP S/4HANA para acessar as CDS views necessárias. Normalmente, isso inclui permissões para objetos como S_TABU_NAM e acesso a ferramentas de visualização de dados.
- Identifique o método de acesso ao sistema: determine como você se conectará ao banco de dados SAP S/4HANA para executar consultas SQL. As ferramentas comuns incluem SAP HANA Studio, o Eclipse IDE com ADT (ABAP Development Tools) ou clientes SQL de terceiros, como o DBeaver, que podem se conectar por meio do cliente de banco de dados SAP HANA.
- Revise a consulta SQL: familiarize-se com o script SQL fornecido. Ele usa Common Table Expressions (CTEs) para reunir dados de diferentes atividades e uni-los em um Event Log unificado.
- Personalize os placeholders: localize e substitua os placeholders na consulta. Você precisará definir o intervalo de datas (formato
[YYYY-MM-DD]) do período de extração e especificar os códigos de empresa relevantes ([Your Company Code]) da sua organização. - Execute a consulta: execute a consulta SQL completa e personalizada no banco de dados SAP S/4HANA. Dependendo do volume de dados e do intervalo de datas selecionado, a execução pode levar algum tempo.
- Faça uma revisão inicial dos dados: quando a consulta for concluída, revise as primeiras linhas do resultado. Verifique se todas as colunas, como PurchaseRequisitionId, ActivityName e EventTime, foram preenchidas conforme esperado e se os formatos dos dados estão corretos.
- Trate a transformação dos dados: a consulta fornecida foi criada para gerar dados em um formato pronto para Process Mining. As funções
CASTeCONCATgarantem a consistência dos tipos de dados. Não deve ser necessária nenhuma transformação significativa após a execução. - Exporte o Event Log: exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Verifique se a codificação do arquivo está definida como UTF-8 para evitar problemas com caracteres.
- Prepare o upload: antes de fazer o upload para uma ferramenta de Process Mining, verifique se o arquivo CSV tem os cabeçalhos corretos (
PurchaseRequisitionId,ActivityName,EventTimeetc.) e se o formato de data e hora deEventTimeé consistente e compatível com a plataforma de destino. - Faça o upload no ProcessMind: faça o upload do arquivo CSV final para o seu projeto no ProcessMind. Configure o projeto mapeando
PurchaseRequisitionIdcomo Case ID,ActivityNamecomo Activity eEventTimecomo Timestamp.
Configuração
- CDS Views principais: a extração usa principalmente
I_PurchaseRequisitionAPI01para os dados principais da requisição,I_ChangeDocumenteI_ChangeDocumentItempara acompanhar alterações e atualizações de status, eI_PurchaseOrderItemAPI01para vincular as requisições aos pedidos de compra. - Autorização: o usuário que executará a extração precisa ter acesso de leitura às CDS views mencionadas. Consulte sua equipe de segurança SAP para obter as funções e autorizações necessárias.
- Filtragem por intervalo de datas: é essencial aplicar um filtro de intervalo de datas à data de criação da requisição (
CreationDate) para limitar o volume de dados. Recomenda-se usar de 3 a 6 meses de dados na análise inicial. - Filtragem organizacional: filtre os dados por
CompanyCodepara garantir que você está analisando o processo da entidade empresarial correta. Você também pode filtrar porPurchaseRequisitionTypepara se concentrar em processos de compras específicos, como materiais padrão ou serviços. - Configuração de documentos de alteração: a captura de atividades como 'Requisition Amended' e das diferentes etapas de aprovação depende de o registro de documentos de alteração estar ativo para os campos relevantes no seu sistema SAP. Se esses eventos estiverem ausentes, verifique a configuração do sistema para a tabela EBAN.
- Performance: em sistemas muito grandes, com milhões de requisições, executar essa consulta por um período longo pode afetar a performance do sistema. Considere executá-la fora do horário de pico ou em um ambiente que não seja de produção, com dados atualizados recentemente.
a Consulta de exemplo sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Etapas
- Confirme se há acesso direto de leitura ao schema SAP HANA que contém EBAN e EBKN. Identifique também os objetos de documentos de alteração e de compras usados no seu sistema para alterações de requisições, processamento de liberação, atribuição de origem, referências a pedidos de compra e encerramento. Como esses objetos e campos podem variar conforme a versão e a configuração, substitua cada placeholder entre colchetes na consulta pelo objeto ou campo correspondente do seu sistema.
- No SAP GUI, use a transação SE16H ou uma ferramenta aprovada de administração de banco de dados para inspecionar EBAN e EBKN, verificar os campos-chave da requisição e confirmar os campos disponíveis de data, hora, usuário, status, exclusão, liberação, atribuição contábil e referência a documentos de compras. Use a SE11 ou o dicionário de dados SAP para verificar as definições dos campos. Não exponha dados de produção durante os testes.
- Identifique a origem configurada dos documentos de alteração para alterações de requisições e mudanças de aprovação. A consulta espera uma origem de alteração normalizada chamada [Your requisition change document source], com campos para número da requisição, número do item, campo alterado, valor anterior, novo valor, data da alteração, hora da alteração e usuário. Mapeie essa origem para as tabelas de documentos de alteração SAP ou para a CDS view relevante do seu sistema antes da execução.
- Identifique a origem configurada do Workflow ou da liberação para envio, redefinição da aprovação, início da etapa de aprovação, conclusão da etapa de aprovação, aprovação final e rejeição. A consulta espera [Your requisition approval event source], com uma linha por transição de status ou liberação e campos para número da requisição, número do item, tipo de evento, código de liberação ou grupo de aprovação, aprovador, data do evento, hora do evento e status. Mapeie essa origem para a persistência de liberação ou Workflow usada pela sua configuração do S/4HANA.
- Identifique as origens de atribuição de origem, referência ao pedido de compra e encerramento. A consulta espera [Your requisition source assignment source], [Your requisition purchase order reference source] e [Your requisition closure source]. Mapeie esses placeholders para tabelas ou views aprovadas do seu sistema. A criação do pedido de compra deve ser representada por uma referência explícita do item do pedido ao item da requisição, e não inferida a partir de uma atividade de compras sem relação direta.
- Defina a janela de extração usando [Start date] e [End date]. Recomenda-se uma janela de três a seis meses na execução inicial. Use um período maior somente depois de validar a performance do banco de dados e o volume de eventos. A consulta filtra as datas de criação e dos eventos, mantendo o identificador da requisição como identificador do caso.
- Execute a consulta em um cliente SQL aprovado e conectado ao SAP HANA. Substitua apenas os detalhes de conexão fora da consulta, os parâmetros de data, os filtros específicos da empresa e os placeholders de origem e campo documentados explicitamente. Preserve exatamente os nomes das colunas de saída: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount e RequisitionStatus.
- Revise eventos duplicados, precisão dos timestamps, tratamento de fuso horário e granularidade no nível do item ou do documento. A consulta gera identificadores de caso no nível do documento e inclui o contexto do item internamente. Se vários itens gerarem a mesma atividade e o mesmo timestamp, mantenha linhas separadas, a menos que o design do seu ProcessMind exija explicitamente a deduplicação.
- Valide se todas as atividades necessárias aparecem como valores de ActivityName, se EventTime está preenchido e é cronologicamente plausível e se o identificador de caso obrigatório não é nulo. Compare as contagens com relatórios SAP ou extrações operacionais aprovadas para o mesmo intervalo de datas.
- Exporte o resultado como CSV UTF-8 ou outro formato tabular compatível com o ProcessMind. Inclua uma linha de cabeçalho, preserve timestamps compatíveis com ISO, mantenha valores nulos como campos vazios e faça o upload do arquivo usando PurchaseRequisitionId como identificador do caso, ActivityName como coluna da atividade e EventTime como coluna do timestamp.
Configuração
- Identificador do caso: use o número do documento da requisição de compra de EBAN, representado como PurchaseRequisitionId. Se o processo estiver configurado no nível do item, use uma chave composta documentada, como o número da requisição e o número do item, e aplique a mesma chave a todos os eventos.
- Fonte principal: EBAN é usada para os dados dos itens da requisição. EBKN é usada para atribuição contábil e enriquecimento com departamento ou centro de custo. Confirme os nomes e tipos de dados exatos dos campos no dicionário de dados SAP antes da execução.
- Origens dos eventos: a consulta usa deliberadamente placeholders profissionais para as origens de alteração, aprovação, atribuição de origem, referência ao pedido de compra e encerramento, pois essas origens dependem da versão do S/4HANA, do design do Workflow, do procedimento de liberação, das funções de negócio ativadas e das extensões do cliente.
- Intervalo de datas: comece com três a seis meses. Sempre que possível, use um intervalo limitado em campos de data indexados ou que permitam eliminação de partições. Para cargas incrementais, sobreponha as janelas de extração o suficiente para capturar alterações que chegam com atraso e depois deduplicate usando a combinação de caso, atividade, timestamp, item e chave do evento de origem.
- Filtros de negócio: configure [Company code filter], [Document type filter], [Purchasing group filter] e [Plant filter] somente quando esses campos estiverem disponíveis e seu significado de negócio estiver confirmado. Evite filtrar por status quando o objetivo for capturar todo o ciclo de vida.
- Mapeamento de status: configure os valores de In Approval, final approved, rejected, reset, pending release code e closed de acordo com a estratégia de liberação ou a configuração do Workflow no sistema de destino. Não presuma que um código de status seja universal em todos os clientes SAP.
- Mapeamento de alterações: inclua alterações de quantidade, preço, material, data de entrega, atribuição contábil e outros campos que o seu processo definir como campos-chave. A consulta inclui predicados explícitos para os campos-chave listados e exige que a origem exponha o nome do campo alterado.
- Tratamento de timestamps: combine a data e a hora do evento no fuso horário do banco de dados e documente qualquer conversão para UTC. Se uma origem armazenar apenas a data, use meia-noite somente quando não existir um timestamp mais preciso e registre essa limitação.
- Performance: restrinja a extração inicial por data e escopo de negócio, selecione apenas as colunas necessárias, evite joins irrestritos com históricos grandes de alterações ou Workflow e revise o plano de execução do HANA. Materialize ou prepare as origens de eventos normalizadas se a extração precisar ser repetida.
- Autorizações e pré-requisitos: obtenha autorização de leitura para EBAN, EBKN, as origens configuradas de alteração e Workflow, os dados de atribuição de origem, os dados de referência de pedidos de compra e os dados de encerramento. Confirme se o acesso direto ao banco de dados foi aprovado, se as funcionalidades relevantes de compras e Workflow estão ativas e se a licença necessária do banco de dados SAP HANA ou as ferramentas de administração estão disponíveis.
- Segurança: aplique o princípio do menor privilégio, proteja os identificadores de usuários e aprovadores e siga as regras da organização para extrair informações de compras e financeiras.
a Consulta de exemplo sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Pronto para começar?
Use este Template para preparar seus dados com confiança e aproveitar todo o potencial do Process Mining no seu processo Purchase to Pay - Requisition. Comece a otimizar sua eficiência hoje mesmo!
Acabe com os atrasos nas requisições P2P: otimize seu Workflow agora!
Simplifique os processos, reduza os prazos e diminua o tempo de ciclo em 30%.
Não é necessário cartão de crédito. A configuração leva 5 minutos.