Votre modèle de données Purchase to Pay - Requisition
Votre modèle de données Purchase to Pay - Requisition
- Attributs recommandés pour une analyse détaillée
- Activités clés à suivre pour découvrir le processus
- Conseils pour extraire les données de SAP S/4HANA
Attributs de Purchase to Pay - Requisition
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Date et heure précises auxquelles une activité s’est produite. | ||
| Description L’heure de l’événement est l’horodatage qui indique quand une activité a eu lieu. Ces données sont essentielles pour ordonner chronologiquement les événements d’un cas et servent de base à tous les calculs de durée et de performance en Process Mining. Par exemple, l’écart entre les événements « Demande d’achat soumise » et « Demande d’achat approuvée » détermine le temps de cycle d’approbation. Des horodatages précis sont indispensables pour analyser la performance du processus, repérer les retards et vérifier le respect des accords de niveau de service. Cet attribut permet de créer des Dashboards qui visualisent les temps de cycle, repèrent les demandes bloquées et comparent les résultats sur différentes périodes. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner les événements, calculer les temps de cycle et analyser la performance du processus ainsi que ses goulots d’étranglement. Où trouver ces données Les horodatages proviennent généralement des en-têtes des documents de modification (CDHDR-UDATE, CDHDR-UTIME) ou des journaux d’événements du flux de travail. Exemples 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Identifiant de la demande d’achat PurchaseRequisitionId | Identifiant unique d’un document de demande d’achat. | ||
| Description L’identifiant de la demande d’achat est la clé primaire qui distingue chaque demande de biens ou de services dans SAP S/4HANA. Il sert d’identifiant central du cas et relie toutes les activités et modifications associées à une demande, de sa création à son état final, qu’elle soit approuvée, rejetée ou convertie en commande d’achat. En Process Mining, cet attribut est indispensable pour reconstituer le cycle de vie complet de chaque demande. En regroupant tous les événements associés sous un même identifiant de demande d’achat, les analystes peuvent mesurer précisément les temps de cycle, suivre les changements de statut et étudier les différents parcours d’approbation. Pourquoi est-ce important ? Cet identifiant de cas essentiel relie toutes les étapes du processus associées et donne une vue complète et cohérente du cycle de vie de la demande. Où trouver ces données Il s’agit du numéro de demande d’achat, dans la table EBAN, champ BANFN. Exemples 100178901001789110017892 | |||
| Nom de l’activité ActivityName | Nom de l’activité métier qui s’est produite à une étape précise du processus de demande d’achat. | ||
| Description Le nom de l’activité désigne un événement ou une tâche précise du cycle de vie d’une demande d’achat. Ces activités sont tirées des journaux du système, notamment des documents de modification et de l’historique des flux de travail. Elles correspondent à des étapes importantes telles que « Demande d’achat créée », « Étape d’approbation commencée » ou « Commande d’achat créée ». L’analyse de ces activités permet de visualiser le flux du processus, de repérer les goulots d’étranglement et de mesurer le temps passé à chaque étape. Comprendre l’ordre et la fréquence d’activités telles que « Demande d’achat modifiée » ou « Demande d’achat rejetée » aide à repérer les inefficacités et les pistes d’amélioration. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il forme la structure de la cartographie du processus et permet d’analyser son déroulement, ses variantes et ses goulots d’étranglement. Où trouver ces données Cet attribut est calculé à partir des données, généralement en interprétant les informations des tables de documents de modification (CDHDR, CDPOS) et des journaux de flux de travail (par exemple, SWWLOGHIST). Exemples Demande d’achat crééeÉtape d’approbation terminéeDemande d’achat approuvéeCommande d’achat créée | |||
| Identifiant de l’approbateur ApproverId | Identifiant de l’utilisateur qui a approuvé ou rejeté une demande à une étape du processus. | ||
| Description L’identifiant de l’approbateur désigne précisément l’utilisateur qui a réalisé une activité d’approbation ou de rejet. À la différence de l’identifiant utilisateur général, il concerne uniquement les personnes qui prennent les décisions dans le flux de travail d’approbation. Il est essentiel de recueillir cette information pour analyser le processus en détail. Cet attribut permet d’étudier les comportements en matière d’approbation, par exemple de repérer les responsables dont les délais d’approbation sont longs ou qui rejettent souvent des demandes. Il est indispensable aux Dashboards consacrés aux temps de cycle des étapes d’approbation et à l’analyse des goulots d’étranglement du flux de travail, car il aide à identifier les personnes ou les rôles à l’origine des retards. Pourquoi est-ce important ? Identifie précisément la personne qui prend une décision à une étape d’approbation et permet d’analyser les temps de cycle et les goulots d’étranglement par personne ou par rôle. Où trouver ces données Ces informations sont généralement extraites de tables SAP Business Workflow telles que SWW_WI2OBJ et SWWLOGHIST, qui relient les éléments de travail à l’utilisateur qui les a terminés. Exemples MJOHNSONCWILLIAMSLBLACK | |||
| Identifiant utilisateur UserId | Identifiant de l’utilisateur qui a créé la demande ou réalisé une activité précise. | ||
| Description L’identifiant utilisateur désigne l’employé ou l’utilisateur système responsable d’un événement donné du cycle de vie de la demande. Il peut s’agir de la personne qui a créé la demande, du responsable qui l’a approuvée ou de l’agent qui l’a modifiée. Pour les étapes automatisées, il peut s’agir d’un identifiant système ou de traitement par lots. L’analyse par identifiant utilisateur permet d’étudier les comportements individuels, la répartition de la charge de travail et la performance. Elle aide à repérer les besoins de formation, à reconnaître les personnes les plus performantes et à garantir la répartition des responsabilités dans le processus. Associée aux données de référence des utilisateurs, elle permet aussi d’analyser la performance des services. Pourquoi est-ce important ? Permet d’analyser la performance des utilisateurs, la répartition de la charge de travail et le respect du processus. Cet attribut aide à repérer les besoins de formation et les goulots d’étranglement liés aux ressources. Où trouver ces données Pour le créateur, l’identifiant figure dans EBAN-ERNAM. Pour les modifications ultérieures, il figure dans CDHDR-USERNAME. Pour les approbations, il se trouve dans les journaux du flux de travail. Exemples JSMITHRROEWF-BATCH | |||
| Montant de la demande d’achat RequisitionAmount | Valeur monétaire totale de la demande d’achat. | ||
| Description Le montant de la demande correspond au coût total estimé des biens ou des services demandés. Il détermine souvent la complexité et la durée du flux de travail d’approbation : les demandes d’un montant élevé nécessitent généralement davantage de niveaux d’approbation. L’analyse de cet attribut permet de segmenter le processus par valeur. Elle peut répondre à des questions telles que « Les demandes d’un montant élevé prennent-elles plus de temps à approuver ? » ou « Quel est le montant des demandes souvent rejetées ? ». C’est un axe essentiel pour comprendre les conséquences financières des inefficacités du processus. Pourquoi est-ce important ? Permet de segmenter le processus selon son incidence financière, souvent liée à la complexité de l’approbation et au temps de cycle. Cet attribut est essentiel à l’analyse du processus par valeur. Où trouver ces données La valeur totale figure dans la table EBAN, champ GFWERT. La valeur au niveau du poste se trouve dans EBAN-PREIS. Exemples 1500.0075000.50250.75 | |||
| Service Department | Service ou centre de coûts auquel les dépenses de la demande sont imputées. | ||
| Description L’attribut du service, souvent représenté par le centre de coûts dans SAP, désigne l’unité opérationnelle responsable de l’achat demandé. Il s’agit d’une information financière et organisationnelle essentielle, affectée au niveau du poste de la demande. En Process Mining, cet attribut est indispensable à l’analyse de la performance des services. Il permet de créer des Dashboards comparant des indicateurs clés, tels que le temps de cycle, la fréquence des modifications et le taux de rejet, entre différents services. Ces comparaisons aident à repérer les bonnes pratiques à reprendre ailleurs, ainsi que les services qui pourraient avoir besoin de formation ou d’assistance supplémentaires. Pourquoi est-ce important ? Permet de comparer la performance des unités opérationnelles et de repérer les écarts de temps de cycle ou de taux de rejet, afin de dégager des pratiques efficaces et des pistes d’amélioration. Où trouver ces données Il s’agit du centre de coûts, généralement présent dans la table d’imputation comptable EBKN, champ KOSTL. Exemples FIN-1001IT-2005MKT-3010 | |||
| Statut de la demande d’achat RequisitionStatus | Statut actuel de traitement ou d’approbation de la demande d’achat. | ||
| Description Le statut de la demande indique son état actuel dans le cycle de vie. Dans SAP, il est souvent représenté par l’indicateur de validation, qui précise si la demande est bloquée, en cours d’approbation, partiellement approuvée ou entièrement approuvée. Ce statut évolue au fil du flux de travail. Le suivi du statut dans le temps est essentiel pour comprendre le déroulement du processus. Il permet de repérer les demandes bloquées et de mesurer la durée du blocage. L’analyse des transitions entre les statuts donne une vue détaillée du processus d’approbation et de ses variantes. Pourquoi est-ce important ? Indique l’état actuel d’une demande, un élément essentiel pour suivre son avancement, repérer les goulots d’étranglement et analyser le déroulement du processus. Où trouver ces données Le statut de validation est souvent déterminé par l’indicateur de validation, dans la table EBAN, champ FRGZU. Exemples B1S | |||
| Type de demande d’achat RequisitionType | Code qui classe la demande d’achat, par exemple pour des articles standard, des services ou des dépenses d’investissement. | ||
| Description Le type de demande d’achat, également appelé type de document dans SAP, est un champ de configuration qui catégorise les demandes d’achat. Selon le type, le flux de travail d’approbation et les paramètres des champs peuvent varier. Les types correspondent également à des besoins métier différents, comme des articles de stock standard, des services externes ou l’achat d’immobilisations. L’analyse du processus par type de demande permet de comprendre comment les différentes demandes sont traitées. Elle sert à comparer la performance, les temps de cycle et les parcours d’approbation entre catégories, afin de déterminer si certains types de demande sont traités plus efficacement et d’adapter les améliorations du processus. Pourquoi est-ce important ? Catégorise les demandes pour permettre des comparaisons et déterminer si les types de demande suivent des parcours différents ou présentent des goulots d’étranglement et des temps de cycle distincts. Où trouver ces données Il s’agit du champ de type de document, dans la table EBAN, champ BSART. Exemples NBFORV | |||
| Automatisée IsAutomated | Indicateur précisant si une activité a été réalisée par un utilisateur système plutôt que par une personne. | ||
| Description L’attribut « Is Automated » est un indicateur booléen qui vaut vrai lorsqu’une activité a été exécutée par un système ou un utilisateur de traitement par lots, comme « WF-BATCH » pour les actions de flux de travail. Il permet de distinguer les étapes manuelles des étapes automatisées du processus. Cet attribut est essentiel pour mesurer le degré d’automatisation du processus de demande d’achat et calculer l’indicateur « Taux d’approbation automatisée ». En filtrant les étapes automatisées ou manuelles, les analystes peuvent comparer leur efficacité et repérer les possibilités d’automatisation supplémentaires afin de réduire les durées de traitement et les interventions manuelles. Pourquoi est-ce important ? Distingue les activités réalisées par des personnes de celles exécutées par un système, ce qui permet de mesurer le taux d’automatisation et de repérer les tâches manuelles susceptibles d’être automatisées. Où trouver ces données Il s’agit d’un attribut calculé, généralement à partir d’une règle qui vérifie si l’identifiant utilisateur associé à un événement appartient à une liste d’utilisateurs système ou de traitement par lots connus. Exemples truefalse | |||
| Correspond à une reprise IsRework | Indique si une activité correspond à une reprise, par exemple une modification effectuée après l’envoi de la demande. | ||
| Description « Is Rework » est un indicateur booléen calculé qui repère les activités correspondant à un travail répétitif ou sans valeur ajoutée. Dans ce processus, l’activité « Demande d’achat modifiée » après l’envoi de la demande pour approbation en est un exemple courant : elle oblige à recommencer le processus d’approbation. Cet attribut est essentiel pour quantifier les reprises dans le processus et mesurer leur incidence sur le temps de cycle global. Le Dashboard sur les modifications de demandes d’achat et le taux de reprises s’appuie sur cet indicateur pour mettre en évidence les inefficacités du processus. Réduire les reprises est souvent un objectif prioritaire des démarches d’amélioration, car cela permet de gagner du temps et de limiter les efforts nécessaires. Pourquoi est-ce important ? Repère les activités qui entraînent des efforts inutiles ou répétés. Vous pouvez ainsi mesurer directement les reprises et leur incidence sur l’efficacité du processus. Où trouver ces données Il s’agit d’un attribut calculé. En règle générale, la logique signale comme reprise toute activité « Demande d’achat modifiée » survenant après la première activité « Demande d’achat envoyée pour approbation ». Exemples truefalse | |||
| Date souhaitée RequiredByDate | Date à laquelle le demandeur a besoin des biens ou des services demandés. | ||
| Description La date souhaitée, appelée date de livraison dans SAP, indique à quel moment les biens ou les services du poste de demande sont nécessaires. Le demandeur définit cette date, qui sert d’objectif pour l’ensemble du processus d’achat. Cet attribut est essentiel au calcul de l’indicateur « Taux de demandes traitées dans les délais ». En comparant la date souhaitée à la date d’approbation finale ou de création de la commande, l’organisation peut mesurer sa capacité à respecter ses niveaux de service internes et à répondre aux besoins métier. L’analyse des demandes qui dépassent cette date peut révéler des retards systémiques dans le processus d’achat. Pourquoi est-ce important ? Définit la date cible de traitement d’une demande et permet de mesurer le respect des délais et des niveaux de service internes. Où trouver ces données Il s’agit de la date de livraison, au niveau du poste dans la table EBAN, champ LFDAT. Exemples 2023-11-152023-12-012024-01-20 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
| Description Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données depuis le système source. Ces métadonnées sont essentielles pour connaître leur fraîcheur. Les analystes et les utilisateurs métier s’appuient sur cet horodatage pour vérifier que les données du processus reflètent bien l’état le plus récent des opérations. Pour analyser un processus, il est fondamental de savoir si les données sont à jour afin de prendre des décisions éclairées. Cet attribut permet de définir les attentes des utilisateurs et de s’assurer que les conclusions reposent sur des données suffisamment récentes pour l’analyse concernée. Pourquoi est-ce important ? Indique si les données sont à jour, un élément essentiel pour se fier à l’analyse et prendre des décisions métier au bon moment. Où trouver ces données Cet horodatage est généré et ajouté pendant le processus d’extraction, de transformation et de chargement des données (ETL). Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Code de devise du montant de la demande. | ||
| Description Cet attribut indique la devise du montant de la demande, par exemple USD, EUR ou JPY. Il apporte le contexte nécessaire à l’interprétation du montant, notamment dans les organisations internationales qui utilisent plusieurs devises. Pour obtenir des analyses et des rapports financiers précis, il est indispensable de tenir compte de la devise. Avant d’agréger ou de comparer les montants des demandes, il convient de les convertir dans une devise commune. Cet attribut est nécessaire à ces conversions. Pourquoi est-ce important ? Apporte le contexte nécessaire à l’interprétation du montant de la demande et permet d’effectuer des analyses et des comparaisons financières précises dans un environnement multidevise. Où trouver ces données Cet attribut figure dans la table EBAN, champ WAERS. Exemples USDEURGBP | |||
| Heure de fin EndTime | Date et heure précises auxquelles une activité donnée a été terminée. | ||
| Description EndTime est l’horodatage qui indique quand une activité s’est terminée. De nombreux événements générés par le système sont instantanés, auquel cas StartTime et EndTime sont identiques. En revanche, les tâches humaines, comme les approbations, peuvent avoir des heures de début et de fin distinctes. Cet horodatage marque la fin du travail. La présence d’un champ EndTime distinct permet de mesurer plus précisément le temps de traitement actif et le temps d’attente. Associé à StartTime, il sert à calculer la métrique ProcessingTime. Ces informations détaillées améliorent l’analyse de l’utilisation des ressources et de l’efficacité des tâches manuelles. Pourquoi est-ce important ? Indique la fin d’une activité, ce qui permet de calculer le temps de traitement actif et d’examiner plus précisément la durée des tâches. Où trouver ces données Cette information provient des journaux du flux de travail, qui peuvent enregistrer la création d’un élément de travail (StartTime) et sa date de fin (EndTime). Exemples 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Motif du rejet RejectionReason | Motif indiqué lors du rejet d’une demande d’achat. | ||
| Description Le motif du rejet explique pourquoi un approbateur a rejeté une demande d’achat. Il peut s’agir d’un dépassement de budget, d’informations incorrectes, du non-respect des règles ou d’une demande en double. Cette information aide à comprendre les échecs du processus. L’analyse des motifs de rejet permet d’en repérer les causes profondes et de mieux comprendre les reprises. Par exemple, si le motif « Centre de coûts incorrect » revient souvent, il peut être nécessaire de mieux former les utilisateurs ou de renforcer les contrôles du système. Cet attribut est au cœur du Dashboard d’analyse des rejets de demandes d’achat et contribue à cibler les améliorations du processus. Pourquoi est-ce important ? Indique la cause des échecs du processus et permet de cibler les améliorations pour réduire les reprises et augmenter le taux de demandes correctes dès la première soumission. Où trouver ces données Il ne s’agit souvent pas d’un champ standard. L’information peut être enregistrée dans des éléments du conteneur du flux de travail, dans un texte long associé à la demande ou dans des champs personnalisés. Exemples Dépassement de budgetFournisseur incorrectDemande en double | |||
| Niveau d’urgence UrgencyLevel | Classe le degré d’urgence de la demande d’achat, qui peut influer sur sa priorité de traitement. | ||
| Description Le niveau d’urgence indique la priorité de la demande d’achat. Même s’il n’existe pas de champ standard dédié, certaines organisations utilisent, par exemple, le numéro de suivi des besoins pour enregistrer cette information. Les demandeurs peuvent ainsi signaler les besoins critiques qui nécessitent un traitement accéléré. L’analyse de l’incidence de l’urgence permet de vérifier si le processus accorde effectivement la priorité aux demandes critiques. Le Dashboard d’analyse de l’incidence du niveau d’urgence utilise cet attribut pour comparer les temps de cycle et les taux d’approbation des demandes urgentes et standard. Vous pouvez ainsi déterminer si le traitement prioritaire fonctionne comme prévu. Pourquoi est-ce important ? Permet d’analyser les écarts de performance du processus pour les demandes prioritaires et de vérifier si les demandes urgentes sont effectivement traitées plus rapidement. Où trouver ces données Il n’existe pas de champ d’urgence standard. Certaines entreprises utilisent le numéro de suivi des besoins (EBAN-BEDAR) à cette fin. Il peut également s’agir d’un champ personnalisé. Exemples ÉlevéMoyenFaible | |||
| Nom de l’étape d’approbation ApprovalStepName | Nom ou description précise d’une étape d’approbation du flux de travail. | ||
| Description Le nom de l’étape d’approbation décrit clairement une phase donnée du flux de travail d’approbation, par exemple « Approbation du responsable » ou « Approbation du vice-président des finances ». Il est plus explicite qu’une activité générique telle que « Étape d’approbation terminée ». Cet attribut est essentiel aux Dashboards d’analyse du temps de cycle des étapes d’approbation et d’analyse des goulots d’étranglement du flux de travail. Il permet d’examiner le processus d’approbation en détail, de repérer précisément les étapes qui entraînent les retards les plus importants et celles où le travail s’accumule. Ces informations sont nécessaires pour cibler les améliorations de la chaîne d’approbation. Pourquoi est-ce important ? Fournit des informations détaillées sur les étapes d’approbation et permet de repérer précisément les goulots d’étranglement dans le flux de travail d’approbation à plusieurs niveaux. Où trouver ces données Cette information provient de la description de la tâche du flux de travail. Vous pouvez la récupérer en reliant le journal du flux de travail aux tables de définition des tâches, comme T528T. Exemples Approbation du responsableApprobation du directeurApprobation du vice-président des finances | |||
| Numéro de commande d’achat PurchaseOrderNumber | Numéro de la commande d’achat créée à partir de la demande. | ||
| Description Le numéro de commande d’achat identifie le document d’achat officiel créé à partir d’une demande approuvée. La création d’une commande constitue souvent l’aboutissement du processus de demande : celle-ci est alors convertie en commande officielle auprès d’un fournisseur. Cet attribut est essentiel pour mesurer l’indicateur de délai entre la demande et la commande d’achat, ainsi que le taux de conversion global. Il relie le processus de demande au processus d’achat en aval et permet d’analyser l’ensemble du cycle Purchase-to-Pay, de bout en bout. Pourquoi est-ce important ? Relie la demande au document d’achat qui en découle et permet de mesurer le taux de conversion et le délai entre la demande et la commande. Où trouver ces données Cet attribut figure dans la table EBAN, champ EBELN, une fois qu’une commande d’achat a été créée à partir du poste de demande. Exemples 450001789045000178914500017892 | |||
| Système source SourceSystem | Identifie l’instance SAP S/4HANA dont proviennent les données extraites. | ||
| Description L’attribut du système source indique le système d’origine où les données du processus ont été générées. Dans les organisations qui utilisent plusieurs instances SAP, par exemple des systèmes distincts pour le développement, l’assurance qualité et la production, ou pour différentes régions, ce champ fournit un contexte essentiel à la gouvernance des données. Il permet de distinguer les données provenant de sources différentes, évite les agrégations incorrectes et rend possible une analyse propre à chaque système. Cet attribut est obligatoire pour assurer la traçabilité de l’origine et du parcours des données du processus. Pourquoi est-ce important ? Fournit un contexte essentiel sur l’origine des données et leur gouvernance, notamment dans les environnements comportant plusieurs systèmes, et garantit leur traçabilité. Où trouver ces données Il s’agit généralement de l’identifiant du système SAP (SID), récupérable à partir des variables système ou des tables de configuration. Exemples S4PECCS4H_PROD_01 | |||
Activités de Purchase to Pay - Requisition
| Activité | Description | ||
|---|---|---|---|
| Commande d’achat créée | Indique qu’une commande d’achat a été générée à partir du poste de demande. Cet événement explicite du système relie la demande à un document d’achat ultérieur. | ||
| Pourquoi est-ce important ? Cette étape importante marque une issue favorable du processus de demande. Le délai entre l’approbation de la demande et la création de la commande d’achat est un indicateur essentiel de l’efficacité des achats. Où trouver ces données L’événement est enregistré explicitement à la création d’un poste de commande d’achat. Le lien figure dans la table EKPO (poste de commande d’achat), qui contient le numéro de la demande d’origine (BANFN) et le numéro de poste (BNFPO). Données à recueillir Reliez la table EKPO à EBAN à l’aide du numéro de demande et du numéro de poste. La date de création du poste de commande marque l’événement. Type d’événement explicit | |||
| Demande d’achat approuvée | Indique l’approbation complète et définitive de la demande d’achat, qui peut alors être convertie en commande d’achat. Cette étape est déduite lorsque le statut général de validation atteint son état final d’approbation. | ||
| Pourquoi est-ce important ? Cette étape marque une réussite importante et constitue un point de fin courant pour l’analyse du temps de cycle. Elle confirme que la demande a passé tous les contrôles et que le service des achats peut la traiter. Où trouver ces données Cet événement est déduit d’un changement de statut dans la table EBAN, notamment lorsque l’indicateur général de validation (FRGZU) ou le statut de traitement (PROCSTAT) prend la valeur finale « Approved ». Données à recueillir Repérez l’horodatage auquel le dernier code de validation est appliqué ou le statut général de la demande passe à « Approved ». Type d’événement inferred | |||
| Demande d’achat clôturée | Indique que le poste de demande est considéré comme entièrement traité et qu’aucune autre commande d’achat ne peut en être issue. Ce statut est généralement défini automatiquement lorsque la totalité de la quantité a été commandée. | ||
| Pourquoi est-ce important ? Cette activité marque la fin réussie du cycle de vie du poste de demande. Elle confirme que le besoin a été entièrement converti en commande d’achat. Où trouver ces données Cet événement est déduit de la table EBAN. Il se produit lorsque l’indicateur « Closed » (EBAKZ) est renseigné, généralement lorsque la quantité commandée correspond à la quantité demandée. Données à recueillir À partir des documents de modification, repérez l’événement où l’indicateur « Closed » (EBAKZ) est renseigné dans la table EBAN. Type d’événement inferred | |||
| Demande d’achat créée | Indique la création initiale du document de demande d’achat dans le système. Cet événement est enregistré explicitement lorsqu’un utilisateur enregistre une nouvelle demande pour la première fois, avec son horodatage de création. | ||
| Pourquoi est-ce important ? Cette activité constitue le point de départ de l’analyse du cycle de vie de la demande. Elle est indispensable pour mesurer le temps de cycle de bout en bout, depuis l’identification du besoin initial jusqu’à l’approbation finale ou à la conversion en commande d’achat. Où trouver ces données Il s’agit d’un événement explicite extrait de la table EBAN, à partir des champs de date de création (ERDAT) et d’heure de création (ERZEIT) pour le numéro de demande d’achat concerné (BANFN). Données à recueillir Utilisez les champs d’horodatage de création (ERDAT, ERZEIT) de la table EBAN pour chaque demande (BANFN). Type d’événement explicit | |||
| Demande d’achat rejetée | Indique le rejet définitif de la demande d’achat par un approbateur, qui met fin au processus. Cet événement est enregistré par une mise à jour de statut indiquant le rejet. | ||
| Pourquoi est-ce important ? Cette activité constitue un point d’échec définitif. L’analyse de la fréquence et des motifs de rejet, ainsi que des étapes où ils surviennent, permet de repérer les problèmes liés au respect des règles, au budget ou à la qualité des demandes. Où trouver ces données Cet événement est déduit d’un changement de statut dans la table EBAN. Le statut de traitement (PROCSTAT) ou un indicateur de validation prend une valeur qui signifie explicitement « Rejected ». Données à recueillir À partir des documents de modification, repérez l’horodatage auquel le statut général dans EBAN passe à « Rejected ». Type d’événement inferred | |||
| Étape d’approbation terminée | Cet événement se produit lorsqu’un approbateur approuve une demande et termine ainsi une étape du flux de travail d’approbation à plusieurs niveaux. Il est déduit d’une modification du statut de validation de la demande. | ||
| Pourquoi est-ce important ? Cette activité permet d’analyser en détail le flux de travail d’approbation et de mesurer le temps consacré à chaque étape. Elle aide à repérer les approbateurs efficaces et les goulots d’étranglement du processus. Où trouver ces données Cet événement est déduit des documents de modification (CDHDR/CDPOS) de la table EBAN. Pour un code donné, le passage du statut de validation du champ concerné (par exemple, FRGZU) de non validé à validé indique que l’événement a eu lieu. Données à recueillir Suivez les modifications des champs de statut de validation dans EBAN pour chaque code défini dans la stratégie. Type d’événement inferred | |||
| Approbation réinitialisée | Indique la réinitialisation de l’ensemble du flux de travail d’approbation, souvent à la suite d’une modification importante de la demande. L’approbation doit alors reprendre depuis le premier niveau. | ||
| Pourquoi est-ce important ? Cette activité met en évidence des reprises importantes qui allongent considérablement le temps de cycle. En identifier les causes est essentiel pour simplifier le processus et réduire les retards. Où trouver ces données Cet événement est déduit des documents de modification (CDHDR/CDPOS) de la table EBAN. Il est détecté lorsque les champs de statut de validation (tels que FRGKZ ou FRGZU) sont effacés après avoir été partiellement ou entièrement renseignés. Données à recueillir Dans les journaux de modification, recherchez le passage d’un statut de validation accordée à un statut de validation non accordée. Type d’événement inferred | |||
| Demande d’achat modifiée | Cet événement se produit lorsqu’un utilisateur modifie un champ important de la demande après sa création, par exemple la quantité, le prix ou le matériel. La modification est enregistrée explicitement dans le système de documents de modification de SAP. | ||
| Pourquoi est-ce important ? Le suivi des modifications est essentiel pour repérer les boucles de reprise et mesurer leur effet sur les temps de cycle. Des modifications fréquentes peuvent signaler des problèmes de qualité des données ou une évolution des besoins, autant de pistes d’amélioration du processus. Où trouver ces données Les modifications apportées à la table EBAN sont enregistrées explicitement dans les tables SAP des documents de modification (CDHDR et CDPOS). Chaque changement d’un champ suivi génère une entrée. Données à recueillir Extrayez les événements de modification de CDHDR/CDPOS lorsque la classe d’objet est BANF, pour les demandes d’achat. Type d’événement explicit | |||
| Demande d’achat retirée | Cet événement se produit lorsque le demandeur initial annule ou supprime la demande avant son traitement complet. Il s’agit généralement d’une action explicite qui active un indicateur de suppression sur le poste de demande. | ||
| Pourquoi est-ce important ? Le suivi des retraits permet de mieux comprendre les variations de la demande et les motifs d’annulation. Le retrait met fin au cycle de vie de la demande et empêche tout traitement ultérieur. Où trouver ces données Cet événement est enregistré explicitement lorsque le champ d’indicateur de suppression (LOEKZ) de la table EBAN est renseigné pour un poste de demande. La modification est consignée dans CDHDR/CDPOS. Données à recueillir Repérez l’événement où l’indicateur de suppression (LOEKZ) de la table EBAN prend la valeur « L ». Type d’événement explicit | |||
| Demande d’achat soumise à approbation | Indique le moment où le demandeur soumet officiellement la demande, ce qui déclenche le flux de travail d’approbation. Cet événement est généralement déduit de la détermination de la stratégie de validation de la demande et du passage de son statut à « In Approval ». | ||
| Pourquoi est-ce important ? Cette étape importante marque le début du calcul des indicateurs de temps de cycle d’approbation. L’analyse du délai entre la création et la soumission peut révéler des retards dans la préparation de la demande. Où trouver ces données Cet événement est déduit des documents de modification (CDHDR/CDPOS) de la table EBAN, notamment lorsque les champs de stratégie de validation (par exemple, FRGST) sont renseignés ou que le statut général (PROCSTAT) indique que la demande est en cours d’approbation. Données à recueillir Repérez la première entrée des documents de modification qui indique le début du flux de travail d’approbation ou le passage au statut « In Approval ». Type d’événement inferred | |||
| Étape d’approbation commencée | Indique qu’une demande attend l’intervention d’un approbateur ou d’un groupe d’approbation précis. Cet événement est déduit du statut de la demande, qui signale l’attente d’un code de validation particulier. | ||
| Pourquoi est-ce important ? Cette activité est essentielle pour repérer les goulots d’étranglement dans la chaîne d’approbation. L’analyse de la durée de cet état permet de détecter les demandes bloquées et les approbateurs surchargés. Où trouver ces données Cet événement est déduit des champs de statut de validation de la table EBAN (par exemple, FRGZU) et de la configuration de la stratégie de validation. Il commence lorsqu’un code de validation précis devient le prochain à traiter. Données à recueillir Déterminez à quel moment une demande passe à l’état d’attente d’approbation pour un code de validation précis, à partir des journaux du flux de travail ou des champs de statut. Type d’événement inferred | |||
| Source d’approvisionnement affectée | Indique qu’un acheteur affecte un fournisseur, un contrat ou une fiche info à un poste de demande approuvé. Cette étape prépare la création de la commande d’achat. | ||
| Pourquoi est-ce important ? Cette activité fait le lien entre l’approbation et la commande. Mesurer le délai d’affectation d’une source permet de repérer les retards liés à la charge de travail des acheteurs et à l’efficacité du processus d’approvisionnement. Où trouver ces données Cet événement est déduit du renseignement de champs liés à la source d’approvisionnement dans la table EBAN, tels que le fournisseur fixe (LIFNR), la fiche info (INFNR) ou le contrat (KONNR). Données à recueillir Suivez, à l’aide des documents de modification, le renseignement de champs tels que LIFNR, INFNR ou KONNR dans la table EBAN. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Prérequis : vérifiez que vous disposez d’un utilisateur doté des autorisations nécessaires pour accéder aux vues CDS requises dans SAP S/4HANA. Il faut généralement des autorisations sur des objets tels que S_TABU_NAM et l’accès à des outils d’affichage des données.
- Déterminez la méthode d’accès au système : choisissez comment vous vous connecterez à la base de données SAP S/4HANA pour exécuter les requêtes SQL. Parmi les outils courants figurent SAP HANA Studio, l’IDE Eclipse avec ADT (ABAP Development Tools) ou des clients SQL tiers comme DBeaver, qui peuvent se connecter au moyen du client de base de données SAP HANA.
- Examinez la requête SQL : familiarisez-vous avec le script SQL fourni. Il utilise des expressions de table communes (CTE) pour recueillir les données de différentes activités, puis les regroupe afin de constituer un journal d’événements unifié.
- Remplacez les espaces réservés : repérez les espaces réservés dans la requête et remplacez-les. Vous devez définir la période d’extraction au format
[YYYY-MM-DD]et préciser les codes société concernés ([Your Company Code]). - Exécutez la requête : lancez la requête SQL complète et personnalisée sur la base de données SAP S/4HANA. Selon le volume de données et la période choisie, son exécution peut prendre un certain temps.
- Effectuez une première vérification des données : une fois la requête terminée, examinez les premières lignes du résultat. Vérifiez que toutes les colonnes, notamment PurchaseRequisitionId, ActivityName et EventTime, sont renseignées comme prévu et que les formats sont corrects.
- Vérifiez les transformations de données : la requête fournie produit des données dans un format adapté au Process Mining. Les fonctions
CASTetCONCATassurent la cohérence des types de données. Aucune transformation importante ne devrait être nécessaire après l’exécution. - Exportez le journal d’événements : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que l’encodage est défini sur UTF-8 afin d’éviter les problèmes de caractères.
- Préparez l’importation : avant d’importer le fichier dans un outil de Process Mining, vérifiez que le CSV comporte les en-têtes attendus (
PurchaseRequisitionId,ActivityName,EventTime, etc.) et que le format de date et d’heure deEventTimeest cohérent et pris en charge par la plateforme cible. - Importez les données dans ProcessMind : importez le fichier CSV final dans votre projet ProcessMind. Configurez le projet en associant
PurchaseRequisitionIdà l’ID de cas,ActivityNameà l’activité etEventTimeà l’horodatage.
Configuration
- Vues CDS principales : l’extraction utilise principalement
I_PurchaseRequisitionAPI01pour les données essentielles des demandes d’achat,I_ChangeDocumentetI_ChangeDocumentItempour le suivi des modifications et des mises à jour de statut, ainsi queI_PurchaseOrderItemAPI01pour établir le lien avec les commandes d’achat. - Autorisations : l’utilisateur qui exécute la requête doit disposer d’un accès en lecture aux vues CDS mentionnées ci-dessus. Consultez l’équipe de sécurité SAP pour connaître les rôles et autorisations nécessaires.
- Filtrage par période : il est essentiel de filtrer les données selon la date de création des demandes d’achat (
CreationDate) afin de limiter le volume extrait. Pour une première analyse, il est recommandé de sélectionner une période de 3 à 6 mois. - Filtrage organisationnel : filtrez les données par
CompanyCodepour analyser la bonne entité. Vous pouvez également filtrer parPurchaseRequisitionTypeafin de cibler certains processus d’achat, par exemple les achats de biens standard ou de services. - Configuration des documents de modification : la capture d’activités telles que « Demande d’achat modifiée » et des différentes étapes d’approbation dépend de l’activation de la journalisation des modifications pour les champs concernés dans votre système SAP. Si ces événements sont absents, vérifiez la configuration du système pour la table EBAN.
- Performances : dans les très grands systèmes qui comptent des millions de demandes d’achat, l’exécution de cette requête sur une longue période peut nuire aux performances. Envisagez de la lancer en dehors des heures de pointe ou dans un environnement hors production contenant des données récemment actualisées.
Exemple de requête 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' Étapes
- Vérifiez que vous disposez d’un accès direct en lecture au schéma SAP HANA contenant EBAN et EBKN. Repérez également les objets de documents de modification et d’achat utilisés dans votre système pour les modifications de demandes, le traitement des approbations, l’affectation des sources, les références aux commandes d’achat et la clôture. Comme ces objets et champs varient selon la version et la configuration, remplacez chaque espace réservé entre crochets dans la requête par l’objet ou le champ correspondant dans votre système.
- Dans SAP GUI, utilisez la transaction SE16H ou un outil d’administration de base de données approuvé pour examiner EBAN et EBKN, vérifier les champs clés des demandes d’achat et confirmer la disponibilité des champs de date, d’heure, d’utilisateur, de statut, de suppression, d’approbation, d’imputation et de référence aux documents d’achat. Utilisez SE11 ou le dictionnaire de données SAP pour vérifier les définitions des champs. Ne divulguez pas de données de production pendant les tests.
- Repérez la source de documents de modification configurée pour les changements apportés aux demandes d’achat et aux approbations. La requête attend une source de modifications normalisée nommée [Your requisition change document source], avec des champs pour le numéro de demande, le numéro de poste, le champ modifié, l’ancienne valeur, la nouvelle valeur, la date et l’heure de modification ainsi que l’utilisateur. Avant l’exécution, associez cette source aux tables de documents de modification SAP ou à la vue CDS correspondante dans votre système.
- Repérez la source de flux de travail ou d’approbation configurée pour l’envoi, la réinitialisation de l’approbation, le début et la fin des étapes d’approbation, l’approbation finale et le rejet. La requête attend [Your requisition approval event source], avec une ligne par changement de statut ou d’approbation et des champs pour le numéro de demande, le numéro de poste, le type d’événement, le code d’approbation ou le groupe d’approbation, l’approbateur, la date et l’heure de l’événement ainsi que le statut. Associez cette source aux données persistantes d’approbation ou de flux de travail utilisées par votre configuration S/4HANA.
- Repérez les sources d’affectation des sources, de références aux commandes d’achat et de clôture. La requête attend [Your requisition source assignment source], [Your requisition purchase order reference source] et [Your requisition closure source]. Associez ces espaces réservés aux tables ou vues approuvées de votre système. La création d’une commande d’achat doit être représentée par une référence explicite entre le poste de commande et le poste de demande, et non déduite d’une activité d’achat sans lien direct.
- Définissez la période d’extraction à l’aide de [Start date] et [End date]. Une période de trois à six mois est recommandée pour la première exécution. N’élargissez cette période qu’après avoir vérifié les performances de la base de données et le volume d’événements. La requête filtre les dates de création et d’événement tout en conservant l’identifiant de la demande comme identifiant de cas.
- Exécutez la requête dans un client SQL approuvé et connecté à SAP HANA. Ne remplacez que les paramètres de connexion situés hors de la requête, les paramètres de date, les filtres propres à l’entreprise et les espaces réservés de source et de champ explicitement documentés. Conservez exactement les noms des colonnes de sortie : PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount et RequisitionStatus.
- Vérifiez les événements en double, la précision des horodatages, la gestion des fuseaux horaires et le niveau de détail, par poste ou par document. La requête produit des identifiants de cas au niveau du document et conserve le contexte des postes dans les données internes. Si plusieurs postes génèrent la même activité au même horodatage, conservez des lignes distinctes, sauf si la conception de votre projet ProcessMind exige explicitement leur déduplication.
- Vérifiez que chaque activité requise apparaît comme valeur de ActivityName, que EventTime est renseigné et chronologiquement plausible, et que l’identifiant de cas requis n’est pas nul. Comparez les volumes avec les rapports SAP ou les extractions opérationnelles approuvées pour la même période.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Incluez une ligne d’en-tête, conservez des horodatages compatibles avec la norme ISO, représentez les valeurs nulles par des champs vides, puis importez le fichier en utilisant PurchaseRequisitionId comme identifiant de cas, ActivityName comme colonne d’activité et EventTime comme colonne d’horodatage.
Configuration
- Identifiant de cas : utilisez le numéro de document de demande d’achat d’EBAN, représenté par PurchaseRequisitionId. Si le processus est défini au niveau du poste, utilisez plutôt une clé composite documentée, par exemple le numéro de demande et le numéro de poste, et appliquez-la à chaque événement.
- Source principale : EBAN fournit les données des postes de demande d’achat. EBKN fournit les imputations et les informations complémentaires sur le service ou le centre de coûts. Avant l’exécution, vérifiez les noms exacts et les types de données des champs dans le dictionnaire de données SAP.
- Sources d’événements : la requête utilise volontairement des espaces réservés professionnels pour les sources de modifications, d’approbation, d’affectation des sources, de références aux commandes d’achat et de clôture. Ces sources dépendent de la version de S/4HANA, de la conception du flux de travail, de la procédure d’approbation, des fonctions métier activées et des extensions propres au client.
- Période : commencez par trois à six mois. Dans la mesure du possible, définissez une période limitée sur des champs de date indexés ou permettant l’élagage des partitions. Pour les chargements incrémentiels, faites se chevaucher suffisamment les périodes d’extraction afin de capturer les modifications reçues tardivement, puis dédupliquez les données à l’aide du cas, de l’activité, de l’horodatage, du poste et de la clé de l’événement source.
- Filtres métier : configurez [Company code filter], [Document type filter], [Purchasing group filter] et [Plant filter] uniquement si ces champs sont disponibles et que leur signification métier est confirmée. Évitez de filtrer selon le statut si vous souhaitez capturer l’ensemble du cycle de vie.
- Correspondance des statuts : configurez les valeurs correspondant aux statuts « En cours d’approbation », « Approuvé définitivement », « Rejeté », « Réinitialisé », « Code d’approbation en attente » et « Clôturé » en fonction de la stratégie d’approbation ou de la configuration du flux de travail du système cible. Ne supposez pas qu’un même code de statut s’applique à tous les clients SAP.
- Correspondance des modifications : incluez les changements portant sur la quantité, le prix, le matériau, la date de livraison, l’imputation et les autres champs que votre processus considère comme essentiels. La requête contient des conditions explicites pour les champs clés indiqués et exige que la source fournisse le nom du champ modifié.
- Gestion des horodatages : combinez la date et l’heure de l’événement dans le fuseau horaire de la base de données, puis documentez toute conversion en UTC. Si une source ne contient qu’une date, utilisez minuit uniquement en l’absence d’un horodatage plus précis et consignez cette limite.
- Performances : limitez l’extraction initiale par période et par périmètre métier, sélectionnez uniquement les colonnes nécessaires, évitez les jointures sans restriction avec les historiques volumineux de modifications ou de flux de travail, et examinez le plan d’exécution HANA. Si les extractions doivent être répétées, matérialisez ou préparez les sources d’événements normalisées dans une zone intermédiaire.
- Autorisations et prérequis : obtenez un accès en lecture à EBAN, EBKN, aux sources configurées de modifications et de flux de travail, aux données d’affectation des sources, aux références aux commandes d’achat et aux données de clôture. Vérifiez que l’accès direct à la base de données est approuvé, que les fonctions d’achat et de flux de travail concernées sont actives et que les licences de base de données SAP HANA ou les outils d’administration nécessaires sont disponibles.
- Sécurité : appliquez le principe du moindre privilège, protégez les identifiants des utilisateurs et des approbateurs, et respectez les règles de l’organisation concernant l’extraction des informations d’achat et financières.
Exemple de requête 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; Prêt à commencer ?
Utilisez ce modèle pour préparer vos données en toute confiance et tirer le meilleur parti du Process Mining pour votre processus Purchase to Pay - Requisition. Commencez dès aujourd’hui à améliorer son efficacité !
Réduisez les retards des demandes d’achat P2P : optimisez votre flux de travail dès maintenant !
Optimisez vos processus, réduisez les délais et diminuez le temps de cycle de 30 %.
Aucune carte bancaire requise. Configuration en 5 minutes.