SAP DRC et la facturation électronique en France : le concept d'autorisations dont vous avez vraiment besoin

À partir du 1er septembre 2026, toute entreprise assujettie à la TVA établie en France doit pouvoir recevoir des factures électroniques structurées via une plateforme agréée. Les grandes entreprises et les ETI doivent également en émettre. Les PME et micro-entreprises ont jusqu'au 1er septembre 2027 pour l'émission. L'e-reporting, c'est-à-dire les données de transaction pour les ventes B2C et internationales ainsi que les données de paiement, suit le même calendrier.

L'essentiel de l'effort de mise en œuvre revient aux équipes fiscales et fonctionnelles : choisir une Plateforme Agréée, mapper les formats, tester l'annuaire. La sécurité arrive généralement en fin de course, reçoit une date de go-live, et s'entend demander de « juste construire le rôle ».

Ce rôle est plus intéressant qu'il n'y paraît. SAP Document and Reporting Compliance (DRC) est livré avec un ensemble d'objets d'autorisation que presque personne ne restreint correctement, et deux d'entre eux sont déjà des niveaux organisationnels en standard. Si vous construisez le rôle France de la manière paresseuse, vous donnez à un comptable fournisseurs français la visibilité sur tous les documents électroniques de toutes les sociétés du système, Italie, Espagne, Pologne et tout ce que DRC fait tourner par ailleurs.

Voici à quoi ressemble réellement cette empreinte.

Ce que l'utilisateur manipule

DRC repose sur une transaction classique et trois applications Fiori.

La transaction est EDOC_COCKPIT, le cockpit eDocument. C'est l'outil de travail : afficher les documents électroniques, les soumettre, créer ceux dont la génération a échoué, suivre les statuts et effectuer les actions de suivi.

Côté Fiori, trois applications, et elles ne sont pas interchangeables :

ID Fiori	Application	Objet sémantique et action	Composant UI5
F4306	Manage Electronic Documents	`ElectronicDocument-documentComplianceCockpit`	`glo.log.dccockpits1`
F5218	Manage Document and Reporting Compliance	`GlobalCompliance-overview`	`gs.gco.dashboard.s1`
F1515	Run Statutory Reports	`ReportingTask-run`	`gs.fin.runstatutoryreports.s1`

F4306 est l'équivalent Fiori de EDOC_COCKPIT. F5218 est le tableau de bord de conformité, une vue d'ensemble transverse aux pays et aux processus. F1515 est le runtime de reporting statutaire, c'est-à-dire le volet e-reporting plutôt que le volet facturation électronique.

Derrière ces tuiles se trouvent les services OData à mettre dans le menu du rôle :

EDOC_DCC_SRV (le cockpit lui-même)
SRF_REPORTING_TASK (reporting statutaire)
CV_ATTACHMENT_SRV (pièces jointes)
CA_OC_OUTPUT_REQUEST_SRV (output management)
CA_FM_FEATURE_TOGGLE_STATUS_SRV

Si vous êtes sur S/4HANA avec Fiori, maintenir SU24 sur EDOC_COCKPIT seul ne suffit pas. La proposition doit porter sur l'application IAM ou sur le service OData, sinon les autorisations de tuile sortent fausses et vous passez la semaine du go-live à courir après des 403 qui ressemblent à des erreurs applicatives.

Les trois dimensions de restriction

DRC offre trois façons indépendantes de découper les accès. Comprendre laquelle fait quoi évite beaucoup de discussions inutiles par la suite.

1. Le processus : EDO_PROC

L'objet d'autorisation EDO_PROC comporte deux champs :

EDO_PROC, le processus eDocument
EDO_PRSTEP, l'étape du processus

C'est dans le processus que se joue la séparation française. Les factures clients sortantes, les factures fournisseurs entrantes et les flux d'e-reporting sont des processus distincts avec des valeurs distinctes. Cela recoupe presque parfaitement l'organisation des équipes finance : la comptabilité clients facture, la comptabilité fournisseurs reçoit, la fiscalité déclare. Un facturier n'a aucune raison de resoumettre une facture fournisseur à la plateforme, et réciproquement.

EDO_PRSTEP est le découpage fin. Il contrôle sur quelle étape du cycle de vie du processus l'utilisateur peut agir. C'est le champ qui sépare « peut consulter le document » de « peut l'envoyer à la plateforme » et de « peut l'annuler ». Presque tous les rôles que je rencontre sur le terrain le laissent à l'astérisque, ce qui signifie que quiconque peut ouvrir le cockpit peut exécuter toutes les actions supportées par le processus.

2. La sensibilité ou le regroupement : EDO_ORG

EDO_ORG comporte trois champs :

EDO_ORG, le critère organisationnel
EDO_ORGVAL, la valeur de ce critère
EDO_PROC, le processus, à nouveau

C'est la dimension extensible. Vous définissez en customizing ce que signifie le critère organisationnel, puis vous restreignez sur ses valeurs. Organisation commerciale, division, catégorie de document, classe de sensibilité de facture, ce que le métier a besoin de ségréguer. La localisation indienne en a sa propre variante avec EDOIN_ORG1, où des unités organisationnelles regroupent des divisions et sont rattachées à des sociétés dans une vue de Customizing avant que PFCG ne propose les valeurs.

Deux points sur EDO_ORG qui prennent les équipes en défaut. D'abord, les valeurs doivent exister en customizing avant que PFCG ne les affiche, ce qui en fait une dépendance vis-à-vis du flux fonctionnel et non quelque chose que la sécurité peut livrer seule. Ensuite, EDO_PROC apparaît aussi à l'intérieur de cet objet : la restriction par processus est donc contrôlée deux fois, via EDO_PROC et via EDO_ORG.

3. La société : EDO_BUK

EDO_BUK porte un seul champ, BUKRS, et c'est le niveau organisationnel société standard. Rien d'exotique, mais c'est lui qui empêche votre rôle français d'afficher le trafic SdI italien.

À ses côtés, F_SRF_RNTM gouverne le runtime de reporting statutaire avec ACTVT, COUNTRY et SRF_REPCAT (catégorie de rapport). COUNTRY est un niveau organisationnel. Pour un rôle France, il doit valoir FR et rien d'autre.

Le point que presque tout le monde manque

EDO_PROC et EDO_ORG sont livrés comme niveaux organisationnels. Sur S/4HANA 2023, ils apparaissent dans PFCG sous la forme $EDO_PROC et $EDO_ORG sans aucune conversion.

Je veux être direct sur l'enjeu, parce que j'ai eu cette conversation plus d'une fois : si vous partez du principe qu'il s'agit de champs d'autorisation ordinaires, vous planifiez une conversion PFCG_ORGFIELD_CREATE. C'est une modification indépendante du mandant qui affecte tous les rôles du système, elle exige une analyse d'impact, un gel de PFCG, une régénération de masse et un enregistrement de changement. C'est un chantier réellement perturbateur. Et sur une release actuelle, il est totalement inutile, parce que SAP l'a déjà fait.

Vérifiez AGR_1252 pour vos rôles DRC existants, ou ouvrez simplement un rôle dans PFCG et regardez le bouton niveaux organisationnels. Si $EDO_PROC et $EDO_ORG y figurent, passez la conversion et allez directement à la dérivation de rôles.

Ce qui amène au deuxième point que l'on manque. Être un niveau organisationnel ne signifie pas que la valeur est restreinte. Dans tous les rôles DRC que j'ai revus, les rôles dérivés portent une société et un pays corrects, puis $EDO_PROC et $EDO_ORG restent à l'astérisque parce que personne ne les a renseignés. L'infrastructure de dérivation est là, sous la main. Elle n'a simplement pas été utilisée.

La connectivité : les objets que personne ne trace

La France fonctionne via des plateformes agréées plutôt qu'un portail public unique, et SAP s'y connecte en OAuth 2.0. Cela fait entrer en jeu un objet qui n'appartient pas au vocabulaire de la plupart des concepteurs de rôles.

S_OA2C_USE contrôle l'utilisation d'un client OAuth 2.0. L'utilisateur final a besoin de :

OA2C_PROF = GCO_ECOM_OAUTH_PROFILE, le profil client qui atteint l'API du prestataire
ACTVT = 16, pour la demande de jeton

Gardez OA2C_PROF figé sur le profil précis. Jamais d'astérisque, et n'intégrez jamais cet objet dans un rôle Basis ou fourre-tout. Le nom du profil est la seule restriction réellement offerte par l'objet : si vous l'élargissez, vous avez de fait supprimé le contrôle.

Une question doit être tranchée avant de décider dans quel rôle cela atterrit. Le jeton est-il demandé dans le contexte de l'utilisateur en dialogue, ou sous l'utilisateur technique qui exécute EDOC_BACKGROUND ? La réponse est souvent les deux, et c'est l'utilisateur de fond que l'on oublie. Tracez-le avec STAUTHTRACE dans un bac à sable plutôt que de le déduire par le raisonnement.

Tenez la configuration du client OAuth à l'écart des utilisateurs qui soumettent. Quelqu'un qui peut à la fois reconfigurer le client OAuth et soumettre des documents peut rediriger votre trafic de factures ailleurs.

S_SERVICE apparaît également avec SRV_TYPE = HT et une liste de noms de services hachés. Ces hachages sont propres au paysage, générés par la maintenance SU24 sur votre propre système : ne les recopiez donc ni depuis un modèle ni depuis un article de blog. Générez-les depuis votre propre SU24.

Trois éléments qui complètent le rôle

Un rôle DRC France complet compte une quarantaine d'objets. La plupart viennent de la proposition SU24 et ne demandent aucune réflexion. Trois groupes en demandent.

Les objets financiers de navigation (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK et consorts) sont contrôlés lorsque l'utilisateur passe du cockpit au document de facturation ou au document comptable source. Omettez-les et le cockpit fonctionne à moitié, ce qui génère en première semaine une vague de tickets qui ressemblent à des problèmes DRC sans en être.

EDOIN_ORG1 est la localisation indienne, et il arrive dans un rôle France par la proposition SU24. Retirez-le plutôt que de le laisser à l'astérisque.

Et n'oubliez pas AIF. Les factures rejetées atterrissent dans l'Application Interface Framework, pas seulement dans le cockpit. Celui qui les corrige a besoin d'autorisations /AIF/ cadrées sur le namespace et les interfaces concernés. C'est une seconde console, avec sa propre conception, généralement découverte au premier batch en échec.

Séparation des tâches

Le modèle français retransmet les statuts de cycle de vie des factures à l'administration. Cela change le profil de risque des actions du cockpit, car supprimer ou altérer un statut n'est plus seulement une question de contrôle interne. Cela affecte les données déclarées.

Quatre conflits à ajouter à votre ruleset avant le go-live :

Créer une facture client (VF01) combiné aux actions du cockpit qui annulent, ignorent ou complètent manuellement un eDocument. Quelqu'un peut facturer puis empêcher la plateforme de le voir.
Comptabiliser une facture fournisseur (MIRO) combiné à la définition du statut de cycle de vie entrant. Accepter ou refuser une facture au nom de l'entreprise est une décision métier, pas une décision technique.
Maintenir le customizing DRC en production combiné à la soumission.
Maintenir la configuration du client OAuth combiné à la soumission.

Aucun de ces conflits ne figure dans un ruleset standard, parce que les rulesets standard sont antérieurs à la réforme. Il faut les écrire. Si vous faites tourner votre analyse dans SAP GRC Access Control, cela veut dire des fonctions et des risques personnalisés ; si vous la faites tourner dans notre propre outil, MTC Skopos, cela veut dire étendre le fichier de ruleset. Dans les deux cas, c'est un travail manuel que quelqu'un doit prendre en charge avant septembre.

Un modèle de rôles qui tient

Trois rôles maîtres, séparés par processus, parce qu'ils ont des menus différents, des cibles de navigation différentes et des propriétaires différents :

Sortant, factures clients, porté par la comptabilité clients et la facturation
Entrant, factures fournisseurs et réponses de cycle de vie, porté par la comptabilité fournisseurs
E-reporting, données de transaction et de paiement, porté par la fiscalité ou la trésorerie

Puis dérivez sur la société et le pays, avec $EDO_PROC fixé par le rôle maître et $EDO_ORG portant le regroupement demandé par le métier. Séparez l'affichage de l'action à l'intérieur de chaque rôle maître via EDO_PRSTEP plutôt qu'en construisant une dimension de dérivation supplémentaire. La classification de sensibilité concerne généralement qui peut agir, pas qui peut voir, et répondre honnêtement à cette question vous épargne beaucoup de rôles dérivés.

Le volet données de paiement de l'e-reporting est celui qui saute du cadrage. Il n'est ni comptabilité clients ni comptabilité fournisseurs, il suit le même calendrier de septembre, et il lui faut un propriétaire.

Si vous lisez ceci en août 2026

Le temps est court, et une conversion en niveau organisationnel n'est pas un changement de deux semaines si vos rôles sont déjà productifs. La bonne nouvelle, encore une fois, est que sur une release actuelle vous n'en avez presque certainement pas besoin.

Ce dont vous avez besoin, c'est d'ouvrir vos rôles DRC existants et de vérifier ce que valent réellement $EDO_PROC et $EDO_ORG. Si la réponse est l'astérisque, vous avez un go-live France où chaque utilisateur disposant du cockpit peut voir et agir sur tous les documents électroniques du paysage. C'est un constat d'audit en gestation, et la vérification prend quinze minutes.

La liste courte, dans l'ordre de rentabilité :

Ouvrez AGR_1252 pour vos rôles DRC et confirmez que $EDO_PROC et $EDO_ORG sont des niveaux organisationnels avec de vraies valeurs, pas des astérisques.
Confirmez que EDO_BUK et F_SRF_RNTM-COUNTRY sont dérivés par pays, pour que le rôle France ne puisse pas lire le trafic italien ou espagnol.
Trouvez tous les rôles portant S_OA2C_USE et vérifiez que OA2C_PROF est figé, y compris pour l'utilisateur de fond derrière EDOC_BACKGROUND.
Tracez le cockpit de bout en bout dans un bac à sable avec STAUTHTRACE, navigation vers les documents de facturation et comptables incluse.
Écrivez les quatre règles SoD ci-dessus et passez-les sur les rôles que vous vous apprêtez à livrer.

Comment MTC intervient

Nous concevons et revoyons les concepts d'autorisations SAP pour des paysages SAP réglementés et multi-pays, depuis Genève, y compris le périmètre DRC de la réforme française : restriction par processus et par société, modèles de rôles dérivés, exposition OAuth et interfaces, alignement SU24 pour Fiori, et les règles SoD que le contenu standard ne porte pas. Sur les programmes de grande taille, nous intervenons aux côtés de cabinets internationaux de premier plan en audit, risque et conseil technologique, le résultat sécurité restant porté par une équipe senior basée en Suisse.

Questions fréquentes

Quels objets d'autorisation SAP DRC utilise-t-il ?

Les objets centraux de SAP Document and Reporting Compliance sont EDO_PROC (processus eDocument et étape de processus), EDO_ORG (un critère organisationnel extensible, sa valeur et le processus), EDO_BUK (société) et F_SRF_RNTM (runtime de reporting statutaire, avec activité, pays et catégorie de rapport). S'y ajoutent les objets de connectivité S_OA2C_USE pour le client OAuth 2.0 et S_SERVICE pour les services Fiori/OData, ainsi que les objets financiers de navigation (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK) contrôlés lorsque l'utilisateur passe du cockpit eDocument au document source. Un rôle France complet compte typiquement une quarantaine d'objets.

Faut-il PFCG_ORGFIELD_CREATE pour faire de EDO_PROC et EDO_ORG des niveaux organisationnels ?

Sur les releases S/4HANA actuelles, non. EDO_PROC et EDO_ORG sont livrés comme niveaux organisationnels et apparaissent dans PFCG sous la forme $EDO_PROC et $EDO_ORG, sans conversion. Lancer PFCG_ORGFIELD_CREATE est une modification indépendante du mandant qui affecte tous les rôles du système et impose une analyse d'impact, un gel de PFCG et une régénération de masse : il vaut donc la peine de vérifier AGR_1252 ou le bouton niveaux organisationnels sur un rôle DRC existant avant de planifier ce chantier. Être un niveau organisationnel ne signifie pas que la valeur est restreinte : dans la plupart des paysages, les rôles dérivés portent une société et un pays corrects pendant que $EDO_PROC et $EDO_ORG restent à l'astérisque.

Quel est le calendrier de la facturation électronique en France ?

À partir du 1er septembre 2026, toute entreprise assujettie à la TVA établie en France doit pouvoir recevoir des factures électroniques structurées via une plateforme agréée, et les grandes entreprises ainsi que les ETI doivent également en émettre. Les PME et micro-entreprises ont jusqu'au 1er septembre 2027 pour l'émission. L'e-reporting (données de transaction B2C et internationales, plus les données de paiement) suit le même calendrier.

Quelles applications Fiori couvrent Document and Reporting Compliance ?

Trois applications, non interchangeables : F4306 Manage Electronic Documents (l'équivalent Fiori de la transaction EDOC_COCKPIT), F5218 Manage Document and Reporting Compliance (le tableau de bord de conformité multi-pays) et F1515 Run Statutory Reports (le runtime de reporting statutaire, où vit l'e-reporting). Derrière ces tuiles se trouvent les services OData EDOC_DCC_SRV, SRF_REPORTING_TASK, CV_ATTACHMENT_SRV, CA_OC_OUTPUT_REQUEST_SRV et CA_FM_FEATURE_TOGGLE_STATUS_SRV, qui doivent figurer dans le menu du rôle.

Quels conflits SoD faut-il ajouter pour la facturation électronique française ?

Les rulesets standard sont antérieurs à la réforme : quatre conflits doivent généralement être écrits à la main : créer une facture client (VF01) combiné aux actions du cockpit qui annulent, ignorent ou complètent manuellement un eDocument ; comptabiliser une facture fournisseur (MIRO) combiné à la définition du statut de cycle de vie entrant ; maintenir le customizing DRC en production combiné à la soumission ; et maintenir la configuration du client OAuth combiné à la soumission. Ils comptent parce que le modèle français retransmet les statuts de cycle de vie des factures à l'administration : supprimer ou altérer un statut affecte donc les données déclarées.