Seu Template de dados para o processo de requisição de compra a pagamento
Seu Template de dados para o processo de requisição de compra a pagamento
- Atributos recomendados para uma análise detalhada
- Atividades principais para acompanhar na descoberta do processo
- Orientações para extrair dados do SAP S/4HANA
Atributos do processo de requisição de compra a pagamento
| Nome | Descrição | ||
|---|---|---|---|
| Data e hora do evento EventTime | A data e a hora exatas em que uma atividade específica ocorreu. | ||
| Descrição A data e a hora do evento registram quando uma atividade ocorreu. Esses dados são essenciais para ordenar cronologicamente os eventos de um caso e servem de base para todos os cálculos de duração e performance em 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. Registrar a data e a hora com precisão é essencial 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 mostram os tempos de ciclo, acompanham requisições paradas e comparam a performance em diferentes períodos. Por que isso importa Esses dados de data e hora são essenciais para ordenar eventos, calcular tempos de ciclo e analisar a performance do processo e os gargalos. Onde encontrar As datas e horas geralmente vêm dos cabeçalhos dos documentos de alteração (CDHDR-UDATE, CDHDR-UTIME) ou dos registros de eventos do fluxo de trabalho. Exemplos 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID da requisição de compra PurchaseRequisitionId | 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, conectando todas as atividades e alterações relacionadas a uma requisição específica, desde a criação até o estado final, como aprovação, rejeição ou conversão em pedido de compra. Em 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, analistas podem medir com precisão os tempos de ciclo, acompanhar mudanças de status e analisar os diferentes caminhos que uma requisição pode percorrer durante a aprovação. Por que isso importa Este é o identificador essencial do caso, que conecta todas as etapas relacionadas do processo e permite ter uma visão completa e coerente do ciclo de vida da requisição. Onde encontrar Este atributo corresponde ao número da requisição de compra, encontrado na tabela EBAN, campo BANFN. Exemplos 100178901001789110017892 | |||
| Nome da atividade ActivityName | 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 uma 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 do fluxo de trabalho, 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. Por que isso importa Define as etapas do processo, forma a base do mapa de processos e permite analisar o fluxo, as variações e os gargalos. Onde encontrar Este é um atributo derivado, geralmente construído pela interpretação de dados das tabelas de documentos de alteração (CDHDR, CDPOS) e dos registros do fluxo de trabalho (por exemplo, SWWLOGHIST). Exemplos Requisição criadaEtapa de aprovação concluídaRequisição aprovadaPedido de compra criado | |||
| Departamento Department | Departamento ou centro de custo ao qual os custos da requisição são atribuídos. | ||
| Descrição O atributo Departamento, muitas vezes representado pelo centro de custo no SAP, identifica a unidade de negócio responsável pela compra solicitada. É uma informação financeira e organizacional importante, atribuída no nível do item da requisição. Em Process Mining, esse atributo é essencial para analisar a performance por departamento. Ele permite criar Dashboards que comparam métricas importantes, como tempo de ciclo, taxa de alterações e taxa de rejeição entre departamentos. Assim, é possível identificar departamentos com boas práticas que podem ser adotadas em outras áreas, além daqueles que talvez precisem de mais treinamento ou suporte ao processo. Por que isso importa Permite comparar a performance entre unidades de negócio e identificar diferenças nos tempos de ciclo ou nas taxas de rejeição, destacando boas práticas e oportunidades de melhoria. Onde encontrar Este é o centro de custo, geralmente encontrado na tabela de atribuição de contas EBKN, campo KOSTL. Exemplos FIN-1001IT-2005MKT-3010 | |||
| ID da pessoa aprovadora ApproverId | Identificador da pessoa que realizou uma etapa de aprovação ou rejeição. | ||
| Descrição O ID da pessoa aprovadora identifica especificamente quem concluiu uma atividade de aprovação ou rejeição. Diferentemente do ID geral do usuário, ele se concentra nas pessoas responsáveis pelas decisões no fluxo de trabalho de aprovação. Registrar essa informação é essencial para analisar o processo de aprovação em detalhes. Este atributo permite analisar o comportamento nas aprovações, como identificar lideranças que demoram para aprovar ou rejeitam requisições com frequência. É fundamental para Dashboards que acompanham os tempos de ciclo das etapas de aprovação e analisam gargalos no fluxo de trabalho, ajudando a localizar pessoas ou funções específicas que podem estar causando atrasos. Por que isso importa Identifica quem tomou a decisão em uma etapa de aprovação e permite analisar detalhadamente os tempos de ciclo e os gargalos por pessoa ou função. Onde encontrar Em geral, essas informações são extraídas de tabelas do SAP Business Workflow, como SWW_WI2OBJ e SWWLOGHIST, que associam itens de trabalho à pessoa que os concluiu. Exemplos MJOHNSONCWILLIAMSLBLACK | |||
| ID do usuário UserId | Identificador da pessoa que criou a requisição ou realizou uma atividade específica. | ||
| Descrição O ID do usuário identifica a pessoa colaboradora ou o 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, a liderança que a aprovou ou quem fez uma alteração. Em etapas automatizadas, pode ser o ID de um usuário do sistema ou de processamento em lote. Analisar os dados por ID do usuário ajuda a entender comportamentos individuais, a distribuição da carga de trabalho e a performance. Isso é importante para identificar necessidades de treinamento, reconhecer pessoas com alto desempenho e garantir a responsabilização no processo. Quando combinado com os dados mestres de usuários, também permite analisar a performance por departamento. 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 encontrar O criador consta em EBAN-ERNAM. Para alterações posteriores, consulte CDHDR-USERNAME. Para aprovações, consulte os registros do fluxo de trabalho. Exemplos JSMITHRROEWF-BATCH | |||
| Status da requisição RequisitionStatus | Status atual de processamento ou aprovação da requisição de compra. | ||
| Descrição O status da requisição indica o estado atual dela em seu ciclo de vida. No SAP, esse status costuma ser representado pelo indicador de liberação, que mostra se a requisição está bloqueada, em aprovação, parcialmente aprovada ou totalmente aprovada. O status muda conforme a requisição avança no fluxo de trabalho. Acompanhar o status ao longo do tempo é fundamental para entender o fluxo do processo. Isso ajuda a identificar onde as requisições ficam paradas e por quanto tempo. Analisar as transições entre status permite entender em detalhes o processo de aprovação e suas variações. Por que isso importa Indica o estado atual de uma requisição, informação essencial para acompanhar o andamento, identificar gargalos e analisar o fluxo do processo. Onde encontrar O status de liberação costuma ser determinado pelo indicador de liberação, encontrado na tabela EBAN, campo FRGZU. Exemplos B1S | |||
| Tipo de requisição RequisitionType | 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 chamado de tipo de documento no SAP, é um campo de configuração importante que categoriza as requisições de compra. Tipos diferentes podem acionar fluxos de trabalho de aprovação distintos, ter configurações de campos diferentes e atender a finalidades de negócio específicas, como itens de estoque padrão, serviços externos ou compra de ativos. Ao analisar o processo por tipo de requisição, as organizações podem entender como diferentes solicitações são tratadas. Isso permite comparar a performance, os tempos de ciclo e os 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 e entender se diferentes tipos de solicitação têm fluxos, gargalos ou tempos de ciclo distintos. Onde encontrar Este é o campo Tipo de documento, encontrado na tabela EBAN, campo BSART. Exemplos NBFORV | |||
| Valor da requisição RequisitionAmount | 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 fluxo de trabalho de aprovação, já que requisições de maior valor geralmente exigem mais níveis de aprovação. Analisar esse atributo permite segmentar o processo por valor. Isso ajuda a responder perguntas como: 'Requisições de alto valor demoram mais para ser aprovadas?' ou 'Qual é o valor das requisições rejeitadas com frequência?'. É 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, que muitas vezes está relacionado à complexidade da aprovação e ao tempo de ciclo. É essencial para analisar o processo com base no valor. Onde encontrar O valor total pode ser encontrado na tabela EBAN, campo GFWERT. O valor por item está em EBAN-PREIS. Exemplos 1500.0075000.50250.75 | |||
| Automatizada IsAutomated | Indicador que informa 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 recebe o valor verdadeiro quando uma atividade é executada por um usuário de sistema ou de processamento em lote, como 'WF-BATCH' em ações de Workflow. Isso ajuda a diferenciar 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 'Taxa de aprovações automatizadas'. Ao filtrar as etapas manuais ou automatizadas, os analistas podem comparar a eficiência e identificar oportunidades para ampliar a automação, reduzindo o tempo de processamento e o trabalho manual. Por que isso importa Diferencia as atividades realizadas por pessoas daquelas executadas por sistemas, o que é essencial para medir os níveis de automação e identificar oportunidades de automatizar tarefas manuais. Onde encontrar É um atributo derivado, geralmente calculado por uma regra que verifica se o User ID de um evento pertence a uma lista de usuários de sistema ou de processamento em lote. Exemplos truefalse | |||
| Data necessária RequiredByDate | Data em que a pessoa solicitante precisa receber os bens ou serviços solicitados. | ||
| Descrição A data necessária, chamada de data de entrega no SAP, especifica quando os bens ou serviços do item da requisição serão necessários. Essa data é definida pela pessoa solicitante e serve como meta para todo o processo de compras. Este atributo é essencial para calcular o KPI 'Taxa de conclusão de requisições 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 pode medir sua capacidade de atender aos níveis de serviço internos e às 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 prevista para concluir uma solicitação e permite medir as entregas no prazo e o cumprimento dos níveis de serviço internos. Onde encontrar Esta é a data de entrega, encontrada no nível do item na tabela EBAN, campo LFDAT. Exemplos 2023-11-152023-12-012024-01-20 | |||
| É retrabalho IsRework | 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 repetitivo ou sem valor agregado. Um exemplo comum nesse processo é a atividade 'Requisition Amended' após o envio da requisição para aprovação, o que faz o processo de aprovação recomeçar. Esse atributo é fundamental para quantificar o retrabalho no processo e seu impacto no tempo de ciclo geral. O Dashboard de alterações e taxa de retrabalho de requisições usa esse indicador para destacar ineficiências. Reduzir o retrabalho costuma ser um dos principais objetivos das iniciativas de melhoria de processos, pois isso economiza tempo e esforço. Por que isso importa Sinaliza atividades que representam esforço desperdiçado ou repetido, permitindo medir diretamente o retrabalho e seu impacto na eficiência do processo. Onde encontrar Este é um atributo calculado. Em geral, a regra sinaliza como retrabalho qualquer atividade 'Requisition Amended' que ocorra depois da primeira atividade 'Requisition Submitted For Approval'. Exemplos truefalse | |||
| Horário de término EndTime | Data e hora exatas em que uma atividade específica foi concluída. | ||
| Descrição EndTime registra a data e a hora em que uma atividade foi concluída. Muitos eventos gerados pelo sistema são instantâneos, ou seja, StartTime e EndTime são iguais. Já tarefas humanas, como aprovações, podem ter horários distintos de início e término. EndTime marca a conclusão do trabalho. O registro separado de EndTime permite medir com mais precisão o tempo de processamento ativo e o tempo de espera. Em conjunto com StartTime, ele é usado para calcular a métrica ProcessingTime. Esse nível de detalhe melhora 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 analisar a duração das tarefas com mais detalhes. Onde encontrar Esse dado vem de logs do fluxo de trabalho que podem registrar quando um item de trabalho foi criado (StartTime) e concluído (EndTime). Exemplos 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Moeda Currency | Código da moeda do valor da requisição. | ||
| Descrição Este atributo especifica a moeda em que o valor da requisição é expresso, por exemplo, USD, EUR ou JPY. Ele dá o contexto necessário ao atributo Valor da requisição, especialmente em organizações multinacionais que operam com várias moedas. Para fazer 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, garantindo resultados relevantes. Este atributo é necessário para realizar essas conversões. Por que isso importa Fornece o contexto necessário para o valor da requisição e permite análises e comparações financeiras precisas em ambientes com várias moedas. Onde encontrar Este campo está na tabela EBAN, campo WAERS. Exemplos USDEURGBP | |||
| Motivo da rejeição RejectionReason | Motivo informado para a rejeição de uma requisição de compra. | ||
| Descrição O motivo da rejeição explica por que uma pessoa aprovadora decidiu rejeitar uma requisição de compra. Entre os motivos possíveis estão estouro do orçamento, informações incorretas, descumprimento de políticas ou duplicidade de outra solicitação. Essa informação é essencial para entender o contexto das falhas no processo. Analisar os motivos de rejeição ajuda a identificar as causas raiz das ineficiências e do retrabalho. Por exemplo, se 'Centro de custo incorreto' for um motivo frequente, isso pode indicar a necessidade de oferecer mais treinamento às pessoas usuárias ou validar melhor os dados no sistema. Este atributo é essencial para o Dashboard de análise de rejeições de requisições e para direcionar melhorias no processo. Por que isso importa Revela as causas raiz das falhas no processo e permite direcionar melhorias para reduzir o retrabalho e aumentar a taxa de requisições corretas na primeira tentativa. Onde encontrar Muitas vezes, não há um campo padrão para essa informação. Ela pode estar registrada em elementos do contêiner do fluxo de trabalho, em textos longos associados à requisição ou em campos personalizados. Exemplos Orçamento excedidoFornecedor incorretoSolicitação duplicada | |||
| Nível de urgência UrgencyLevel | 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 Requirement Tracking Number para registrar essa informação. Assim, quem solicita pode sinalizar necessidades críticas que talvez exijam um processamento mais rápido. Analisar o impacto da urgência é importante para avaliar se o processo prioriza as solicitações críticas de forma eficaz. O Dashboard de análise do impacto do nível de urgência usa esse atributo para comparar o tempo de ciclo e as taxas de aprovação de requisições urgentes e padrão. Com isso, você pode verificar se o tratamento prioritário está funcionando como esperado. Por que isso importa Permite analisar como a performance do processo varia para solicitações prioritárias e ajuda a confirmar se os itens urgentes estão sendo processados mais rapidamente. Onde encontrar Não há um campo padrão para urgência. Algumas empresas usam o Requirement Tracking Number (EBAN-BEDAR) para esse fim. Também pode ser um campo personalizado. Exemplos AltaMédiaBaixa | |||
| Nome da etapa de aprovação ApprovalStepName | Nome ou descrição específica de uma etapa de aprovação no fluxo de trabalho. | ||
| Descrição O nome da etapa de aprovação oferece uma descrição clara de uma fase específica do fluxo de trabalho de aprovação, como 'Aprovação do gerente' ou 'Aprovação do vice-presidente de Finanças'. É mais informativo do que uma atividade genérica como 'Etapa de aprovação concluída'. Esse atributo é essencial para os Dashboards de tempo de ciclo das etapas de aprovação e de análise de gargalos do fluxo de trabalho. Ele permite examinar o processo de aprovação em detalhes e identificar exatamente quais etapas causam os maiores atrasos e onde o trabalho se acumula. Esse nível de detalhe é necessário para direcionar ações e simplificar a cadeia de aprovação. Por que isso importa Detalha as etapas de aprovação e permite identificar com precisão os gargalos no fluxo de trabalho de aprovação com vários níveis. Onde encontrar Essa informação vem da descrição da tarefa do fluxo de trabalho, que pode ser consultada vinculando o log do fluxo de trabalho a tabelas de definição de tarefas, como T528T. Exemplos Aprovação do gerenteAprovação do diretorAprovação do vice-presidente de Finanças | |||
| Número do pedido de compra PurchaseOrderNumber | Número do pedido de compra criado a partir da requisição. | ||
| Descrição O número do pedido de compra identifica o documento oficial de compras criado a partir de uma requisição aprovada. A criação do pedido costuma ser o resultado final bem-sucedido da requisição, indicando que a solicitação foi convertida em um pedido formal com um fornecedor. Este atributo é essencial para medir o KPI de tempo entre a requisição e o pedido de compra, além da taxa geral de conversão. Ele conecta o processo de requisição ao processo de compras subsequente, permitindo uma visão mais ampla, de ponta a ponta, de todo o ciclo de Purchase to Pay. Por que isso importa Conecta a requisição ao documento de compras subsequente e permite medir a taxa de conversão e o tempo entre a requisição e o pedido de compra. Onde encontrar 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 em que os dados do processo foram gerados. Em organizações com várias instâncias do SAP, como sistemas distintos para desenvolvimento, garantia da qualidade e produção, ou sistemas separados por região, esse campo é essencial para a governança e o contexto dos dados. Ele permite distinguir dados de diferentes origens, evitando agregações incorretas e viabilizando análises específicas por sistema. É um atributo obrigatório para manter a linhagem dos dados e garantir a rastreabilidade das informações 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, e garante sua rastreabilidade. Onde encontrar Geralmente, corresponde ao ID do sistema SAP (SID), que pode ser obtido em variáveis do sistema ou tabelas de configuração. Exemplos S4PECCS4H_PROD_01 | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Este atributo registra a data e a hora da extração ou atualização mais recente dos dados do sistema de origem. É um metadado essencial para entender o quanto os dados analisados estão atualizados. Analistas e profissionais de negócio usam essa informação para saber se os dados do processo refletem o estado mais recente das operações. Em qualquer análise de processo, saber se os dados estão atualizados é fundamental para tomar decisões fundamentadas. Este atributo ajuda a alinhar as expectativas de quem usa os dados e garante que as conclusões se baseiem em informações tão recentes quanto a análise exige. Por que isso importa Indica o quanto os dados estão atualizados, algo essencial para confiar na análise e tomar decisões de negócio no momento certo. Onde encontrar Esses dados de data e hora são gerados e adicionados durante o processo de extração, transformação e carregamento (ETL). Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Atividades do processo de requisição de compra a pagamento
| Atividade | Descrição | ||
|---|---|---|---|
| Etapa de aprovação concluída | Ocorre quando uma pessoa aprovadora toma uma decisão favorável sobre uma requisição, concluindo uma etapa do fluxo de trabalho de aprovação em vários níveis. Esse evento é inferido a partir de uma mudança no status de liberação da requisição. | ||
| Por que isso importa Esta atividade permite analisar detalhadamente o fluxo de trabalho de aprovação e medir o tempo gasto em cada etapa. Ela ajuda a identificar pessoas aprovadoras eficientes e gargalos no processo. Onde encontrar Inferido a partir dos documentos de alteração (CDHDR/CDPOS) da tabela EBAN. Uma mudança no status do código de liberação (por exemplo, no campo FRGZU), de não liberado para liberado para um código específico, indica esse evento. Coleta Acompanhe as mudanças 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 foi criado um pedido de compra vinculado ao item da requisição. Este é um evento explícito do sistema que conecta a requisição ao documento de compras gerado em seguida. | ||
| Por que isso importa Este é 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 essencial para medir a eficiência de compras. Onde encontrar Registrado explicitamente quando um item do pedido de compra é criado. O vínculo fica 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). Coleta Associe a tabela EKPO à EBAN pelo número da requisição e do item. 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, que passa a poder ser convertida em pedido de compra. Esse marco é inferido quando o status geral de liberação chega ao estado final de aprovação. | ||
| Por que isso importa Este é um marco importante 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 equipe de compras. Onde encontrar 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 o valor final 'Aprovado'. Coleta Identifique a data e a 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 é registrado explicitamente quando alguém salva uma nova requisição pela primeira vez, incluindo a data e a hora da criação. | ||
| Por que isso importa Esta atividade é o principal ponto de partida para analisar o ciclo de vida da requisição. Ela é essencial para medir o tempo de ciclo de ponta a ponta, desde a identificação da necessidade até a aprovação final ou a conversão em pedido de compra. Onde encontrar Este é um evento explícito, registrado na tabela EBAN com 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). Coleta Use os campos de data e hora de 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 outros pedidos de compra a partir dele. Em geral, esse status é definido automaticamente quando a quantidade total é pedida. | ||
| Por que isso importa Esta 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 compra. Onde encontrar Inferido a partir da tabela EBAN. O evento ocorre quando o indicador 'Encerrado' (EBAKZ) é definido, geralmente quando a quantidade pedida nos pedidos de compra é igual à quantidade da requisição. Coleta Identifique, por meio dos documentos de alteração, o evento em que o indicador 'Encerrado' (EBAKZ) é definido na tabela EBAN. Tipo de evento inferred | |||
| Requisição rejeitada | Representa a rejeição final da requisição de compra por uma pessoa aprovadora, interrompendo o processo. O evento é registrado por uma atualização específica de status que indica a rejeição. | ||
| Por que isso importa Esta atividade marca um desfecho crítico de falha. Analisar a frequência e os motivos das rejeições, além das etapas em que ocorrem, ajuda a identificar problemas de conformidade com políticas, orçamento ou qualidade das solicitações. Onde encontrar 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'. Coleta Identifique, por meio dos documentos de alteração, a data e a hora em que o status geral da EBAN é atualizado para 'Rejeitado'. Tipo de evento inferred | |||
| Aprovação reiniciada | Representa um evento em que todo o fluxo de trabalho de aprovação é reiniciado, muitas vezes devido a uma alteração significativa na requisição. Com isso, o processo de aprovação recomeça no primeiro nível. | ||
| Por que isso importa Esta atividade evidencia um retrabalho significativo, com forte impacto no tempo de ciclo. Identificar as causas dos reinícios da aprovação é essencial para simplificar o processo e reduzir atrasos. Onde encontrar Inferido a partir dos documentos de alteração (CDHDR/CDPOS) da tabela EBAN. O evento é detectado quando os campos de status de liberação, como FRGKZ ou FRGZU, são apagados após terem sido preenchidos parcial ou totalmente. Coleta Nos registros de alteração, procure uma mudança no status de liberação, de liberado para não liberado. Tipo de evento inferred | |||
| Etapa de aprovação iniciada | Indica que uma requisição aguarda a ação de uma pessoa aprovadora específica ou de um grupo de aprovação. Esse evento é inferido quando o status da requisição indica que ela está aguardando um código de liberação específico. | ||
| Por que isso importa Esta atividade é essencial para localizar gargalos na cadeia de aprovação. Analisar por quanto tempo a requisição permanece nesse estado ajuda a identificar solicitações paradas e pessoas aprovadoras sobrecarregadas. Onde encontrar Inferido a partir dos campos de status de liberação da tabela EBAN (por exemplo, FRGZU) e da configuração da estratégia de liberação correspondente. O evento começa quando um código de liberação específico passa a ser o próximo a ser processado. Coleta Determine quando uma requisição entra em um estado no qual aguarda a aprovação de um código de liberação específico, com base nos registros do fluxo de trabalho ou nos campos de status. Tipo de evento inferred | |||
| Fonte de suprimento atribuída | Representa a ação de uma pessoa compradora que atribui um fornecedor, contrato ou registro info específico a um item de requisição aprovado. Esta é uma etapa importante para preparar a requisição para a criação do pedido de compra. | ||
| Por que isso importa Esta atividade conecta a aprovação ao pedido. Medir o tempo necessário para atribuir uma fonte ajuda a identificar atrasos na carga de trabalho de compras e na eficiência do processo de seleção de fornecedores. Onde encontrar Inferido quando um valor é inserido nos campos relacionados à fonte de suprimento na tabela EBAN, como fornecedor fixo (LIFNR), registro info (INFNR) ou contrato (KONNR). Coleta Acompanhe o preenchimento de campos como LIFNR, INFNR ou KONNR na tabela EBAN por meio dos documentos de alteração. Tipo de evento inferred | |||
| Requisição alterada | Ocorre quando alguém altera um campo importante da requisição após sua criação, 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 as alterações é essencial para identificar ciclos de retrabalho e seu impacto no tempo de ciclo. Alterações frequentes podem indicar problemas na qualidade dos dados ou mudanças nos requisitos, áreas importantes para melhorar o processo. Onde encontrar Registrado explicitamente nas tabelas de documentos de alteração do SAP (CDHDR e CDPOS) para mudanças na tabela EBAN. Cada alteração em um campo monitorado gera uma entrada. Coleta Extraia os eventos de alteração de CDHDR/CDPOS em que a classe do objeto seja BANF, referente às requisições de compra. Tipo de evento explicit | |||
| Requisição enviada para aprovação | Representa o momento em que a pessoa solicitante envia formalmente a requisição, iniciando o fluxo de trabalho de aprovação. Em geral, esse evento é inferido quando a estratégia de liberação da requisição é definida e o status muda para 'Em aprovação'. | ||
| Por que isso importa Este é um marco importante que inicia a contagem do tempo de ciclo de aprovação nos KPIs. Analisar o intervalo entre a criação e o envio pode revelar atrasos na etapa de preparação da requisição. Onde encontrar Inferido a partir dos documentos de alteração (CDHDR/CDPOS) da tabela EBAN, especificamente quando os campos da estratégia de liberação (por exemplo, FRGST) são preenchidos ou o status geral (PROCSTAT) muda para indicar que a requisição está em aprovação. Coleta Identifique a primeira entrada nos documentos de alteração que indique o início do fluxo de trabalho de aprovação ou uma mudança de status para 'Em aprovação'. Tipo de evento inferred | |||
| Requisição retirada | Ocorre quando a pessoa que fez a solicitação cancela ou exclui a requisição antes do processamento completo. Em geral, essa ação explícita define um indicador de exclusão no item da requisição. | ||
| Por que isso importa Acompanhar as retiradas ajuda a entender as variações na demanda e os motivos dos cancelamentos. Esse é um estado final da requisição, que impede o processamento posterior. Onde encontrar Registrado explicitamente quando o campo do indicador de exclusão (LOEKZ) na tabela EBAN é definido para um item da requisição. A alteração fica registrada em CDHDR/CDPOS. Coleta 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 se você tem um usuário com as autorizações necessárias no SAP S/4HANA para acessar as CDS Views exigidas. Isso normalmente inclui permissões para objetos como S_TABU_NAM e acesso a ferramentas de visualização de dados.
- Identifique como acessar o sistema: Defina como você vai se conectar ao banco de dados SAP S/4HANA para executar consultas SQL. Entre as ferramentas comuns estão SAP HANA Studio, o Eclipse IDE com ADT (ABAP Development Tools) e clientes SQL de terceiros, como DBeaver, que podem se conectar usando o 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 combiná-los em um Event Log unificado.
- Personalize os marcadores: Localize e substitua os marcadores na consulta. Defina o período de extração no formato
[YYYY-MM-DD]e informe os códigos de empresa relevantes ([Your Company Code]) da sua organização. - Execute a consulta: Rode a consulta SQL completa e personalizada no banco de dados SAP S/4HANA. O tempo de execução pode variar conforme o volume de dados e o período selecionado.
- Faça uma revisão inicial dos dados: Quando a consulta terminar, confira as primeiras linhas do resultado. Verifique se todas as colunas, como PurchaseRequisitionId, ActivityName e EventTime, foram preenchidas como esperado e se os formatos dos dados estão corretos.
- Considere as transformações de dados: A consulta fornecida gera dados em um formato pronto para Process Mining. As funções
CASTeCONCATgarantem a consistência dos tipos de dados. Em geral, não é necessário fazer grandes transformações após a execução. - Exporte o Event Log: Exporte todo o conjunto de resultados do cliente SQL para um arquivo CSV. Defina a codificação do arquivo como UTF-8 para evitar problemas com caracteres.
- Prepare o arquivo para carregamento: Antes de carregar os dados em uma ferramenta de Process Mining, confira 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. - Carregue os dados no ProcessMind: Carregue o arquivo CSV final no seu projeto do ProcessMind. Configure o projeto mapeando
PurchaseRequisitionIdcomo ID do caso,ActivityNamecomo atividade eEventTimecomo data e hora.
Configuração
- CDS Views principais: A extração usa principalmente
I_PurchaseRequisitionAPI01para os dados centrais das requisições,I_ChangeDocumenteI_ChangeDocumentItempara acompanhar alterações e atualizações de status, eI_PurchaseOrderItemAPI01para vincular os dados aos pedidos de compra. - Autorização: O usuário que executar a consulta precisa ter acesso de leitura às CDS Views mencionadas. Consulte a equipe de segurança SAP para obter as funções e autorizações necessárias.
- Filtro por período: É essencial aplicar um filtro de período à data de criação da requisição (
CreationDate) para limitar o volume de dados. Para a análise inicial, recomendamos usar dados de 3 a 6 meses. - Filtro organizacional: Filtre os dados por
CompanyCodepara analisar 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 dos documentos de alteração: A captura de atividades como 'Requisition Amended' e de diferentes etapas de aprovação depende do registro de alterações estar ativo para os campos relevantes no sistema SAP. Se esses eventos não aparecerem, verifique a configuração da tabela EBAN.
- Performance: Em sistemas muito grandes, com milhões de requisições, executar essa consulta para um período extenso pode afetar a performance do sistema. Considere executá-la fora do horário de pico ou em um ambiente de não produção com dados atualizados recentemente.
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 esquema do 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 fonte, 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 marcador entre colchetes na consulta pelo objeto ou campo correspondente do seu sistema.
- No SAP GUI, use a transação SE16H ou uma ferramenta de administração de banco de dados aprovada para inspecionar EBAN e EBKN, verificar os campos-chave da requisição e confirmar quais campos de data, hora, usuário, status, exclusão, liberação, imputação e referência a documentos de compras estão disponíveis. Use 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 fonte de documentos de alteração configurada para mudanças nas requisições e nas aprovações. A consulta espera uma fonte de alterações 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. Antes de executar a consulta, mapeie essa fonte para as tabelas de documentos de alteração ou a CDS View relevante no seu sistema.
- Identifique a fonte de Workflow ou liberação configurada para envio, redefinição de aprovação, início e conclusão de etapas de aprovação, aprovação final e rejeição. A consulta espera [Your requisition approval event source], com uma linha por mudança 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 fonte para os dados persistidos de liberação ou Workflow usados na configuração do seu S/4HANA.
- Identifique as fontes de atribuição de fonte, referência a pedidos 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 marcadores para tabelas ou views aprovadas no 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 de atividades de compras sem relação direta.
- Defina o período de extração usando [Start date] e [End date]. Recomendamos um período de três a seis meses para a 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 ID do caso.
- Execute a consulta em um cliente SQL aprovado e conectado ao SAP HANA. Substitua apenas os detalhes de conexão externos à consulta, os parâmetros de data, os filtros específicos da empresa e os marcadores de fonte e campo documentados explicitamente. Mantenha exatamente os nomes das colunas de saída: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount e RequisitionStatus.
- Revise os eventos duplicados, a precisão das datas e horas, o fuso horário e o nível de detalhe por item ou por documento. A consulta gera IDs de caso no nível do documento e inclui internamente o contexto do item. Se vários itens gerarem a mesma atividade e data e hora, mantenha linhas separadas, a menos que o modelo do ProcessMind exija explicitamente a remoção de duplicatas.
- Valide se todas as atividades necessárias aparecem como valores de ActivityName, se EventTime está preenchido e segue uma sequência cronológica plausível e se o ID do caso obrigatório não está nulo. Compare as contagens com relatórios SAP ou extrações operacionais aprovadas para o mesmo período.
- Exporte o resultado como arquivo CSV em UTF-8 ou em outro formato tabular compatível com o ProcessMind. Inclua uma linha de cabeçalho, mantenha datas e horas compatíveis com o padrão ISO, represente valores nulos como campos vazios e carregue o arquivo usando PurchaseRequisitionId como ID do caso, ActivityName como coluna de atividade e EventTime como coluna de data e hora.
Configuração
- Identificador do caso: Use o número do documento de requisição de compra de EBAN, representado por 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 fornece os dados dos itens da requisição. EBKN fornece dados de imputação e informações complementares sobre departamento ou centro de custo. Antes de executar a consulta, confirme os nomes e tipos de dados exatos dos campos no dicionário de dados SAP.
- Fontes de eventos: A consulta usa marcadores profissionais para as fontes de alterações, aprovação, atribuição de fonte, referência a pedidos de compra e encerramento. Essas fontes variam conforme a versão do S/4HANA, o desenho do Workflow, o procedimento de liberação, as funções de negócio ativadas e as extensões do cliente.
- Período: Comece com três a seis meses. Sempre que possível, limite o período usando campos de data indexados ou que permitam eliminar partições. Para cargas incrementais, sobreponha os períodos de extração o suficiente para capturar alterações recebidas com atraso e, em seguida, remova duplicatas usando o caso, a atividade, a data e hora, o item e a 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 para o negócio tiver sido confirmado. Evite filtrar por status quando o objetivo for capturar todo o ciclo de vida.
- Mapeamento de status: Configure os valores para Em aprovação, aprovado final, rejeitado, redefinido, código de liberação pendente e encerrado conforme 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 ambientes SAP.
- Mapeamento de alterações: Inclua alterações de quantidade, preço, material, data de entrega, imputação e outros campos definidos como essenciais para o processo. A consulta inclui condições explícitas para os campos essenciais listados e exige que a fonte disponibilize o nome do campo alterado.
- Tratamento de data e hora: Combine a data e a hora do evento usando o fuso horário do banco de dados e documente qualquer conversão para UTC. Se uma fonte armazenar apenas a data, use meia-noite somente quando não houver uma data e hora mais precisa e registre essa limitação.
- Performance: Restrinja a extração inicial por período e escopo de negócio, selecione apenas as colunas necessárias, evite junções sem restrições com históricos extensos de alterações ou Workflow e revise o plano de execução do HANA. Se precisar repetir a extração, materialize ou prepare as fontes de eventos normalizadas em uma área de staging.
- Autorizações e pré-requisitos: Obtenha autorização de leitura para EBAN, EBKN, as fontes configuradas de alterações e Workflow, os dados de atribuição de fonte, as referências a 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 do banco de dados SAP HANA ou as ferramentas de administração necessárias 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.
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 segurança e aproveitar todo o potencial do Process Mining no processo de requisição de compra a pagamento. Comece hoje a melhorar a eficiência.
Acabe com os atrasos nas requisições: otimize seu fluxo de trabalho agora!
Simplifique os processos, reduza os prazos e diminua o tempo de ciclo em 30%.
Não é necessário informar cartão de crédito. A configuração leva 5 minutos.