Votre modèle de données Purchase to Pay - Traitement des factures

L’attribut Activité représente une étape ou une action précise du flux de travail de traitement des factures. Ces activités sont dérivées de différents événements système, tels que la création d’un document, les changements d’état, les approbations ou les actions des utilisateurs enregistrées dans les journaux de modifications SAP.

L’analyse des activités constitue le cœur du Process Mining. Elle permet de visualiser les cartes de processus, d’identifier les goulots d’étranglement, par exemple les longues attentes après « Facture envoyée pour approbation », les boucles de reprise, comme les cycles répétés « Blocage de paiement défini » et « Blocage de paiement levé », ainsi que les écarts de conformité. La séquence et la fréquence des activités révèlent le flux réel du processus, tel qu’il existe.

Il définit les étapes de la carte de processus et permet de visualiser les flux de processus, de découvrir les goulots d'étranglement et d'identifier les reprises.

Cet attribut est généralement dérivé de plusieurs sources, notamment des codes de transaction (SY-TCODE), des champs de statut dans des tables telles que RBKP, par exemple RBSTAT, ainsi que des événements de modification issus des tables CDHDR et CDPOS.

Event Time enregistre le moment exact où une activité métier a été exécutée et consignée dans le système source. Cet horodatage constitue la base chronologique du processus : il ordonne toutes les activités de chaque facture pour former une séquence cohérente.

Dans l'analyse, Event Time est indispensable au calcul de toutes les métriques fondées sur la durée, notamment les temps de cycle, les temps d'attente et les temps de traitement entre les activités. Il alimente des Dashboards tels que « Invoice End-to-End Cycle Time » et « Payment Block Resolution Duration » en fournissant les données nécessaires pour mesurer le temps écoulé entre deux points quelconques du processus. Des horodatages précis sont essentiels pour identifier les retards et les goulots d'étranglement qui affectent les performances.

Cet horodatage est indispensable pour ordonner correctement les événements et calculer toutes les métriques de performance, notamment les temps de cycle et la durée des goulots d'étranglement.

Il est généralement obtenu en combinant la date de modification (UDATE) et l'heure de modification (UTIME) de la table d'en-tête des documents de modification, CDHDR. Pour certains événements de création, il peut correspondre à la date et à l'heure de création issues de tables telles que RBKP (ERNAM, ERZET).

Le numéro de facture sert d'identifiant unique du cas pour le parcours de traitement de la facture. Chaque numéro correspond à une seule facture reçue d'un fournisseur, ce qui permet de suivre toutes les activités associées, de la capture des données au paiement final, dans le cadre d'une même instance de processus.

Dans une analyse de process mining, cet attribut est fondamental pour reconstituer le cycle de vie complet de chaque facture. Il permet de relier les différents événements enregistrés dans SAP, tels que le préenregistrement, la comptabilisation, le blocage et le lettrage, au sein d'une séquence chronologique. Vous obtenez ainsi une vision claire du traitement de chaque facture, de sa durée et des écarts par rapport au processus standard.

Il s'agit de la clé primaire qui relie tous les événements associés à une même facture. Elle constitue donc le fondement indispensable de l'analyse des processus et de l'exploration des variantes.

Il s'agit généralement du numéro de document de la table SAP RBKP, champ BELNR, souvent concaténé avec le code société (BUKRS) et l'exercice fiscal (GJAHR) pour garantir une unicité absolue.

La Payment Due Date est calculée à partir de la date de référence de la facture et des conditions de paiement convenues. Elle représente la date limite de paiement à respecter pour éviter un retard, d'éventuelles pénalités ou une dégradation de la relation avec le fournisseur.

Cet attribut est essentiel pour des KPI de performance et de conformité tels que « On-Time Payment Rate » et « Cash Discount Opportunity Loss ». En comparant la date réelle de paiement (Clearing Date) à la Payment Due Date, l'analyse peut déterminer automatiquement si le paiement a été effectué à temps, en avance ou en retard. Il constitue un élément fondamental du Dashboard Payment Terms Adherence.

Elle sert de référence pour mesurer la performance des paiements effectués à temps et identifier les possibilités de bénéficier de remises pour paiement anticipé.

Cette date est souvent calculée. La date de référence du paiement (ZFBDT) figure dans la table BSEG. La logique de calcul de l'échéance dépend également des conditions de paiement (BSEG-ZTERM).

La Posting Date est une date clé du processus comptable. Elle détermine la période fiscale au cours de laquelle la charge liée à la facture est comptabilisée dans le grand livre. Elle est généralement définie par le comptable fournisseurs lors du traitement de la facture.

Dans l'analyse des processus, l'activité « Invoice Posted », marquée par cette date, constitue une étape importante. La durée entre la réception de la facture et la Posting Date représente une composante essentielle du temps de cycle global. Cette date est également fondamentale pour le reporting financier et l'analyse du débit, par exemple pour suivre le volume de factures comptabilisées par semaine ou par mois.

Elle marque une étape importante du processus, détermine la période financière de la transaction et constitue un élément clé du calcul du temps de cycle.

Il s'agit du champ « Posting Date » (BUDAT) de la table d'en-tête des documents de facture, RBKP.

La Clearing Date marque la dernière étape du cycle de vie de la facture : le paiement. Il s'agit de la date à laquelle le poste de facture ouvert est lettré par un document de paiement dans le système. Elle représente le moment réel de l'exécution du paiement.

Cet attribut constitue le point final de nombreux KPI importants, notamment « Average Invoice Cycle Time » et « On-Time Payment Rate ». Il est comparé à la Payment Due Date pour mesurer la performance des paiements. Pour l'analyse des remises, il est comparé à la période de remise afin de vérifier si le paiement a été effectué à temps pour en bénéficier.

Elle marque l'achèvement du processus et sert de base au calcul du temps de cycle total, du taux de paiements effectués à temps et de la réalisation des remises pour paiement anticipé.

Pour les postes lettrés, il s'agit du champ « Clearing Date » (AUGDT) de la table des postes fournisseurs lettrés, BSAK.

Invoice Amount représente la valeur totale de la facture soumise par le fournisseur. Il s'agit d'une métrique financière essentielle pour chaque cas de facture.

Dans le Process Mining, cet attribut est indispensable à l'analyse par valeur. Il permet de filtrer et de segmenter le processus selon le montant de la facture, qui est souvent corrélé à la complexité du processus et aux exigences d'approbation. Par exemple, les factures d'un montant élevé peuvent suivre un parcours d'approbation différent et plus strict. Cet attribut est également utilisé dans les analyses de conformité, notamment pour vérifier que les factures d'un montant élevé ne contournent pas les étapes d'approbation requises.

Il permet une analyse fondée sur la valeur, aide à prioriser les factures d'un montant élevé et à comprendre l'incidence du montant de la facture sur le flux du processus et la conformité.

Il s'agit du champ « Gross invoice amount » (RMWWR) de la table d'en-tête des documents de facture, RBKP.

Lorsqu'une facture présente un écart ou nécessite un examen complémentaire, un blocage de paiement est appliqué. Le code Payment Block Reason précise la raison du blocage, par exemple un écart de quantité, un écart de prix ou un blocage manuel.

Cet attribut est essentiel au Dashboard « Payment Block Resolution Duration ». L'analyse de la fréquence et de la durée des blocages par motif aide à identifier les causes profondes des retards de paiement. Par exemple, si « Price Discrepancy » est le motif le plus fréquent des blocages prolongés, cela peut révéler un problème dans les données de référence ou dans le processus de commande d'achat qui doit être corrigé.

Il explique les raisons des retards de facture, permet d'analyser les causes profondes des blocages de paiement et aide à prioriser les efforts d'amélioration du processus.

Le motif du blocage de paiement peut être trouvé au niveau du poste dans la table RSEG (champ SPGRS) ou dans la table des documents comptables BSEG (champ ZLSPR).

L'attribut User Name identifie précisément la personne responsable de l'exécution d'une activité donnée dans le processus. Il s'agit généralement du nom d'utilisateur SAP enregistré avec la transaction ou l'événement de modification.

Cet attribut est essentiel pour analyser les performances et la charge de travail au niveau d'un utilisateur ou d'une équipe. Il permet de répondre à des questions telles que « Qui sont les approbateurs les plus rapides ? » ou « Quels utilisateurs génèrent le plus de reprises ? ». Il est utilisé dans les Dashboards pour analyser la répartition de la charge, identifier les besoins de formation et comprendre les écarts de performance entre les collaborateurs.

Il permet d'analyser les performances et la charge de travail par personne ou par équipe, afin d'identifier les meilleurs contributeurs, les besoins de formation et les déséquilibres de Ressources.

Il s'agit du champ « Changed By » (USERNAME) de la table d'en-tête des documents de modification, CDHDR. Pour les événements de création, il peut correspondre au champ « Entered by » (ERNAM) de tables telles que RBKP.

Le Purchase Order Number relie une facture au document d'achat d'origine. Il est fondamental pour le rapprochement à trois niveaux (PO, réception des marchandises, facture) et pour analyser l'efficacité du processus de traitement des factures associées à une PO.

Cet attribut est essentiel pour des Dashboards tels que « Invoice-PO Matching Discrepancy Rate ». Il permet de distinguer les factures associées à une PO des factures sans PO, qui suivent souvent des parcours et présentent des niveaux de complexité très différents. L'analyse des problèmes liés à certaines PO peut contribuer à diagnostiquer les difficultés en amont du processus d'achat.

Il relie la facture au processus d'achat, permet d'analyser les factures avec ou sans PO et d'identifier les écarts de rapprochement.

Cette information se trouve généralement au niveau du poste. Le « Purchase Order Number » (EBELN) figure dans la table des postes de facture, RSEG. Il peut être nécessaire de l'agréger au niveau de l'en-tête.

Le Vendor Number est la clé des données de référence qui identifie le fournisseur. Il relie la transaction de facture à un partenaire commercial précis et permet ainsi d'analyser le processus selon les caractéristiques du fournisseur.

L'analyse du processus par Vendor Number peut révéler des informations importantes sur les relations avec les fournisseurs et leurs performances. Elle peut notamment montrer quels fournisseurs soumettent régulièrement des factures problématiques entraînant des blocages de paiement ou des écarts, ou quelles factures fournisseurs sont traitées le plus efficacement. Ces informations sont utiles à la gestion des fournisseurs et aux initiatives d'achats stratégiques.

Il permet une analyse propre à chaque fournisseur et aide à identifier les tendances, les problèmes ou les gains d'efficacité associés à certains fournisseurs.

Il s'agit du champ « Invoicing Party » (LIFNR) de la table d'en-tête des documents de facture, RBKP.

Le Company Code est une unité organisationnelle fondamentale de SAP Financials qui représente une entité juridique indépendante. Toutes les transactions financières, y compris les factures, sont comptabilisées dans un code société précis.

Cet attribut permet de segmenter l'analyse du processus par entité juridique. Il est essentiel pour comparer les performances, la conformité et l'efficacité du processus entre différentes sociétés d'un même groupe. Les Dashboards peuvent être filtrés par Company Code afin de fournir une vue des KPI de traitement des factures propre à chaque société.

Il permet de comparer les processus et d'évaluer les performances entre différentes entités juridiques d'une même organisation.

Il s'agit du champ « Company Code » (BUKRS) de la table d'en-tête des documents de facture, RBKP.

Le General Ledger (G/L) Account est le compte de destination du plan comptable sur lequel l'impact financier de la facture est enregistré. Il s'agit d'une donnée essentielle pour le reporting financier et la gestion des coûts.

Dans le Process Mining, l'analyse du compte du grand livre ajoute une dimension financière au flux du processus. Le Dashboard « General Ledger Account Usage Analysis » peut révéler des tendances de dépenses, identifier d'éventuelles erreurs d'imputation des factures et vérifier que les coûts sont affectés aux bons services ou projets. Il contribue à relier l'exécution du processus à son impact financier.

Il ajoute une dimension financière au processus et permet d'analyser l'affectation des coûts, les tendances de dépenses et les erreurs potentielles d'imputation des factures.

Cette information se trouve au niveau du poste. Le « G/L Account Number » (HKONT) figure dans la table des postes de facture RSEG pour les factures avec PO, ou dans BSEG pour les factures FI directes.

Les Payment Terms définissent les règles relatives à la date de paiement d'une facture et aux éventuelles remises pour paiement anticipé. Elles peuvent par exemple prévoir « Net 30 days » ou « 2% 10, Net 30 », ce qui signifie qu'une remise de 2 % est accordée en cas de paiement sous 10 jours, tandis que le montant total est dû sous 30 jours.

Cet attribut constitue la base du Dashboard « Cash Discount Opportunity Loss » et du KPI « Cash Discount Capture Rate ». L'analyse utilise les conditions de paiement conjointement avec les dates de comptabilisation et de paiement pour déterminer si une remise était disponible et si elle a effectivement été obtenue. Il est également essentiel au Dashboard Payment Terms Adherence.

Il est essentiel pour analyser les taux d'obtention des remises pour paiement anticipé et comprendre l'incidence financière des retards de traitement.

Il s'agit du champ « Terms of Payment Key » (ZTERM) de la table d'en-tête des documents de facture, RBKP.

Cet attribut enregistre la date et l'heure de l'extraction ou de la mise à jour la plus récente des données. Il s'applique à l'ensemble du jeu de données, et non à des événements individuels, et indique clairement son niveau d'actualité.

Il s'agit d'un attribut de métadonnées essentiel pour les utilisateurs de Dashboards et les analystes. Il les aide à comprendre la période couverte par l'analyse et à s'assurer que leurs décisions reposent sur des informations à jour. Il est généralement affiché de manière visible sur les Dashboards afin d'indiquer la date de fraîcheur des données.

Il informe les utilisateurs du niveau d'actualité des données et garantit que les analyses et les décisions reposent sur des informations à jour.

Cette valeur est générée et injectée dans le jeu de données par l'outil d'extraction des données ou l'outil ETL au moment de l'actualisation.

L'attribut Currency précise la devise dans laquelle le montant de la facture est exprimé, par exemple USD, EUR ou JPY.

Cet attribut fournit le contexte nécessaire à l'interprétation de Invoice Amount. Il permet d'interpréter et d'agréger correctement les données financières, en particulier dans les organisations internationales qui utilisent plusieurs devises. L'analyse peut être filtrée par devise afin de comparer l'efficacité du traitement ou les problèmes rencontrés dans différentes zones monétaires. Pour obtenir des agrégations financières pertinentes, les montants peuvent devoir être convertis dans une devise de reporting unique.

Il fournit le contexte nécessaire à l'interprétation de tout montant financier et permet un filtrage et une analyse par devise fiables.

Il s'agit du champ « Currency Key » (WAERS) de la table d'en-tête des documents de facture, RBKP.

Il s'agit d'un attribut booléen calculé en comparant la « Clearing Date » (date réelle du paiement) à la « Payment Due Date ». Si la date de lettrage est postérieure à la date d'échéance, l'indicateur est vrai ; sinon, il est faux. Il fournit une mesure simple et directe de la performance des paiements effectués à temps pour chaque facture.

Cet attribut simplifie l'analyse et la visualisation dans les Dashboards. Il permet de filtrer et d'agréger facilement les données afin de calculer le KPI « On-Time Payment Rate ». Les utilisateurs peuvent rapidement comparer les flux de processus des factures en retard à ceux des factures payées à temps et mettre en évidence les schémas de processus susceptibles d'entraîner des retards de paiement.

Il simplifie l'analyse de la performance des paiements effectués à temps et permet de comparer facilement les processus des factures payées à temps et ceux des factures en retard.

Cet attribut n'existe pas dans SAP. Il est calculé lors de la transformation des données à l'aide de la formule : ClearingDate > PaymentDueDate.

L'attribut End Time marque l'achèvement d'une activité donnée. Dans SAP, de nombreux événements sont consignés comme des instants uniques : End Time est alors identique à Start Time. Pour les activités dont la durée est mesurable, comme une étape d'approbation traitée activement, il peut toutefois représenter la fin de cette activité.

Dans l'analyse des processus, un End Time distinct permet de mesurer le temps de traitement de l'activité séparément du temps d'attente qui la précède. Il devient ainsi possible de distinguer le temps nécessaire à l'exécution d'une activité du temps pendant lequel un cas attend son démarrage, ce qui apporte une meilleure compréhension de l'efficacité des Ressources.

Il permet de calculer le temps de traitement d'une activité, de le distinguer du temps d'attente entre les activités et d'améliorer l'analyse des goulots d'étranglement.

Il s’agit souvent de la même valeur que l’Heure de début, dérivée de CDHDR-UDATE et CDHDR-UTIME. Dans certains cas, elle peut être extraite des journaux du flux de travail qui enregistrent explicitement le début et la fin d’une tâche.

Lorsqu'un approbateur rejette une facture, il indique idéalement le motif du rejet. Celui-ci peut prendre la forme d'un code standardisé ou d'un commentaire en texte libre signalant, par exemple, un « Incorrect PO number », une « Duplicate Invoice » ou un « Amount incorrect ».

Ces données sont essentielles au Dashboard « Invoice Rejection Reasons & Trends ». L'analyse de la fréquence des différents motifs de rejet permet à l'entreprise d'identifier les problèmes récurrents et de mettre en place des mesures correctives. Par exemple, si « Incorrect PO number » revient fréquemment, cela peut indiquer la nécessité d'améliorer la communication avec les fournisseurs ou de former les collaborateurs chargés de la saisie. Cette analyse est essentielle pour réduire les reprises.

Il fournit la cause profonde des rejets et permet de cibler les améliorations du processus afin de réduire les reprises et d'augmenter le taux de traitement correct dès la première fois.

Ces informations ne sont souvent pas stockées dans un champ standard unique. Elles peuvent figurer dans les journaux du conteneur du flux de travail, dans les champs de texte long associés au document ou dans des champs spécifiques d’une solution de flux de travail personnalisée.

Il s'agit d'un attribut booléen calculé à partir des conditions de paiement et de la date réelle du paiement. Il prend la valeur vrai si les « Payment Terms » prévoyaient une remise pour paiement anticipé et si la « Clearing Date » était postérieure à l'expiration de la période de remise. Il mesure directement la perte financière due aux inefficacités du processus.

Cet attribut constitue la base du Dashboard « Cash Discount Opportunity Loss ». Il permet de quantifier facilement l'impact financier des retards de traitement. En filtrant les cas pour lesquels cet indicateur est vrai, les analystes peuvent examiner les variantes de processus et les goulots d'étranglement qui entraînent le plus souvent la perte de remises, et ainsi étayer la nécessité d'améliorer le processus.

Quantifie directement la perte financière liée aux retards du processus et constitue un argument convaincant en faveur de l’optimisation du flux de travail de traitement des factures.

Cet attribut n'existe pas dans SAP. Il est calculé lors de la transformation des données en interprétant « PaymentTerms » et en comparant « ClearingDate » à la date d'échéance de la remise.

L'attribut Source System indique l'origine des données d'événement, par exemple le nom d'une instance SAP ECC donnée. Il est particulièrement important dans les environnements qui utilisent plusieurs systèmes ERP ou dans lesquels les données proviennent de sources différentes.

Dans l'analyse, cet attribut permet de distinguer les processus et les performances entre différents systèmes, régions ou unités opérationnelles pouvant fonctionner sur des instances distinctes. Il garantit une traçabilité claire des données et permet d'appliquer des filtres et des analyses propres à chaque système.

Il fournit un contexte essentiel dans les environnements multisystèmes, en permettant une séparation appropriée des données et une analyse des performances propre à chaque système.

Il s'agit généralement d'une valeur statique ajoutée lors de l'extraction des données. Elle représente l'identifiant du système SAP (TADIR-SRCSYSTEM) ou un identifiant attribué manuellement à l'instance SAP concernée.

Le Document Type sert à catégoriser les différents types de transactions métier dans SAP. Pour le traitement des factures, les types courants comprennent « RE » pour les factures standard et « KG » pour les notes de crédit fournisseur. Le type de document contrôle certains aspects de la comptabilisation, notamment la plage de numéros utilisée.

Dans l'analyse, cet attribut permet de filtrer le processus sur certains types de transactions. Par exemple, le traitement d'une note de crédit peut être très différent de celui d'une facture standard. La séparation de ces flux à l'aide du Document Type fournit une vue du processus plus précise et plus pertinente.

Il permet de séparer et d'analyser différentes transactions métier, telles que les factures et les notes de crédit, qui suivent des processus distincts.

Il s'agit du champ « Document Type » (BLART) de la table d'en-tête des documents de facture, RBKP.