Sur la plupart des projets de facturation électronique, ce sont les équipes fiscales et fonctionnelles qui portent l'essentiel du travail : choix de la Plateforme Agréée, correspondance des formats, tests de l'annuaire. La sécurité intervient tard, avec une date de mise en production déjà fixée et une demande du type « il faut juste créer le rôle ».

Le rôle mérite un peu plus d'attention. Les objets DRC sont rarement bien restreints, et un rôle France construit à partir de la proposition SU24 avec des astérisques partout donne accès aux documents électroniques de l'Italie, de l'Espagne, de la Pologne et de tout autre pays que DRC gère dans le même système. Voici les objets concernés et la manière dont nous les découpons.

Transaction et applications

DRC comprend une transaction classique et trois applications Fiori.

EDOC_COCKPIT, le cockpit eDocument, est l'écran de travail principal : affichage des documents électroniques, soumission, création de ceux dont la génération a échoué, suivi des statuts et actions de suivi.

Les trois applications Fiori ont chacune leur usage :

ID FioriApplicationObjet sémantique et actionComposant UI5
F4306Manage Electronic DocumentsElectronicDocument-documentComplianceCockpitglo.log.dccockpits1
F5218Manage Document and Reporting ComplianceGlobalCompliance-overviewgs.gco.dashboard.s1
F1515Run Statutory ReportsReportingTask-rungs.fin.runstatutoryreports.s1

F4306 est la version Fiori de EDOC_COCKPIT. F5218 est le tableau de bord de conformité, avec une vue par pays et par processus. F1515 sert à exécuter les déclarations légales, donc au volet e-reporting plutôt qu'à la facturation électronique.

Le menu du rôle doit aussi contenir les services OData suivants :

  • EDOC_DCC_SRV (le cockpit)
  • SRF_REPORTING_TASK (déclarations légales)
  • CV_ATTACHMENT_SRV (pièces jointes)
  • CA_OC_OUTPUT_REQUEST_SRV (gestion des sorties)
  • CA_FM_FEATURE_TOGGLE_STATUS_SRV

Sur S/4HANA avec Fiori, maintenir SU24 uniquement pour EDOC_COCKPIT ne suffit pas. La proposition doit être faite sur l'application IAM ou sur le service OData. Sinon, les autorisations des tuiles sont fausses et la semaine de mise en production se passe à analyser des erreurs 403 qui ressemblent à des erreurs applicatives.

Trois axes de restriction

DRC offre trois axes de restriction indépendants. Mieux vaut savoir dès le départ lequel sert à quoi.

1. Le processus : EDO_PROC

L'objet d'autorisation EDO_PROC a deux champs :

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

La séparation pour la France se fait au niveau du processus. Les factures clients sortantes, les factures fournisseurs entrantes et les flux d'e-reporting sont des processus distincts, avec des valeurs distinctes. Cela correspond à l'organisation habituelle de la finance : la comptabilité clients facture, la comptabilité fournisseurs reçoit, la fiscalité déclare. Un collaborateur de la facturation n'a pas à resoumettre une facture fournisseur à la plateforme, et inversement.

EDO_PRSTEP détermine à quelle étape du cycle de vie l'utilisateur peut intervenir. C'est ce champ qui distingue la consultation d'un document de son envoi à la plateforme ou de son annulation. Dans la plupart des rôles que nous auditons, il est à l'astérisque : toute personne qui ouvre le cockpit peut alors exécuter toutes les actions du processus.

2. Sensibilité ou regroupement : EDO_ORG

EDO_ORG a trois champs :

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

Cet axe est extensible. On définit en customizing ce que représente le critère organisationnel (organisation commerciale, division, catégorie de document, classe de sensibilité de facture, ou tout autre découpage voulu par le métier), puis on restreint sur ses valeurs. La localisation indienne a sa propre variante, EDOIN_ORG1 : 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 remarques pratiques. Les valeurs doivent exister en customizing pour que PFCG les affiche : la sécurité dépend donc ici de l'équipe fonctionnelle et ne peut pas livrer seule. Et comme EDO_PROC est aussi un champ de cet objet, la restriction par processus est contrôlée deux fois, dans EDO_PROC et dans EDO_ORG.

3. La société : EDO_BUK

EDO_BUK a un seul champ, BUKRS, le niveau organisationnel société standard. C'est lui qui empêche le rôle France d'afficher les flux SdI italiens.

À côté, F_SRF_RNTM contrôle l'exécution des déclarations légales avec ACTVT, COUNTRY et SRF_REPCAT (catégorie de rapport). COUNTRY est un niveau organisationnel ; dans un rôle France, il vaut FR et rien d'autre.

EDO_PROC et EDO_ORG sont déjà des niveaux organisationnels

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 conversion.

La question revient sur plusieurs projets. Si l'équipe les prend pour des champs d'autorisation ordinaires, elle planifie une conversion avec PFCG_ORGFIELD_CREATE : une modification indépendante du mandant qui touche tous les rôles du système, avec analyse d'impact, gel de PFCG, régénération de masse et demande de changement. C'est un chantier lourd, et sur une version actuelle SAP l'a déjà fait.

Consultez AGR_1252 pour vos rôles DRC existants, ou ouvrez un rôle dans PFCG et cliquez sur le bouton des niveaux organisationnels. Si $EDO_PROC et $EDO_ORG y figurent, laissez tomber la conversion et passez directement à la dérivation des rôles.

Encore faut-il les renseigner. Dans les rôles DRC que nous avons revus, les rôles dérivés ont une société et un pays corrects, mais $EDO_PROC et $EDO_ORG restent à l'astérisque parce que personne ne les a remplis.

Objets de connectivité

En France, les échanges passent par des plateformes agréées et non par un portail public unique, et SAP s'y connecte en OAuth 2.0. Cela fait intervenir un objet que la plupart des concepteurs de rôles connaissent peu.

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 appelle l'API du prestataire
  • ACTVT = 16, pour la demande de jeton

Limitez OA2C_PROF à ce profil. Pas d'astérisque, et pas question de placer cet objet dans un rôle Basis générique ou un rôle fourre-tout. Le nom du profil est la seule restriction possible sur cet objet : si on l'élargit, il n'y a plus rien à contrôler.

Avant de choisir le rôle qui le portera, il faut savoir si le jeton est demandé dans le contexte de l'utilisateur de dialogue ou par l'utilisateur technique qui exécute EDOC_BACKGROUND. Souvent, c'est les deux, et l'utilisateur technique est celui qu'on oublie. Faites une trace STAUTHTRACE sur un système de test plutôt que de le déduire.

Séparez la configuration du client OAuth des utilisateurs qui soumettent les documents. Quelqu'un qui peut à la fois reconfigurer le client OAuth et soumettre peut envoyer les factures ailleurs.

S_SERVICE apparaît également, avec SRV_TYPE = HT et une liste de noms de services hachés. Ces valeurs sont générées par la maintenance SU24 de votre propre système : générez-les chez vous, ne les recopiez pas d'un modèle ou d'un article.

Les autres objets du rôle

Un rôle DRC France complet compte une quarantaine d'objets. La plupart viennent de la proposition SU24 et ne posent pas de question particulière. Trois groupes demandent de l'attention.

Les objets financiers de navigation (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK et autres) sont contrôlés quand l'utilisateur passe du cockpit au document de facturation ou au document comptable d'origine. S'ils manquent, le cockpit ne fonctionne qu'en partie, et la première semaine amène des tickets qui ressemblent à des problèmes DRC alors qu'ils n'en sont pas.

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

AIF : les factures rejetées arrivent aussi dans l'Application Interface Framework, pas seulement dans le cockpit. La personne qui les corrige a besoin d'autorisations /AIF/ limitées à l'espace de noms et aux interfaces concernés. C'est une seconde console avec sa propre conception, que l'on découvre en général au premier traitement en erreur.

Séparation des tâches

Dans le modèle français, les statuts de cycle de vie des factures sont transmis à l'administration. Supprimer ou modifier un statut change donc les données déclarées, et pas seulement une donnée interne : les actions du cockpit présentent un risque plus élevé que dans un processus purement interne.

Quatre conflits à ajouter au jeu de règles avant la mise en production :

  1. Création de facture client (VF01) avec les actions du cockpit qui annulent, ignorent ou terminent manuellement un eDocument. La même personne peut facturer puis empêcher la facture d'arriver sur la plateforme.
  2. Saisie de facture fournisseur (MIRO) avec la mise à jour du statut de cycle de vie entrant. Accepter ou refuser une facture au nom de l'entreprise relève d'une décision métier.
  3. Customizing DRC en production avec la soumission.
  4. Configuration du client OAuth avec la soumission.

Les jeux de règles standard sont antérieurs à la réforme et n'en contiennent aucun. Dans SAP GRC Access Control, il faut les créer comme fonctions et risques spécifiques ; dans notre outil, MTC Skopos, on les ajoute au fichier de règles. Dans les deux cas, quelqu'un doit s'en charger avant septembre.

Modèle de rôles

Nous partons de trois rôles maîtres, séparés par processus, car chacun a son propre menu, ses propres documents de navigation et son propre responsable :

  • Sortant (factures clients), sous la responsabilité de la comptabilité clients et de la facturation
  • Entrant (factures fournisseurs et réponses de cycle de vie), sous la responsabilité de la comptabilité fournisseurs
  • E-reporting (données de transaction et de paiement), sous la responsabilité de la fiscalité ou de la trésorerie

On dérive ensuite par société et par pays, avec $EDO_PROC fixé dans le rôle maître et $EDO_ORG contenant le regroupement demandé par le métier. Dans chaque rôle maître, séparez affichage et action avec EDO_PRSTEP plutôt qu'en ajoutant un axe de dérivation. Les besoins de confidentialité portent le plus souvent sur qui peut agir, et non sur qui peut voir ; trancher cette question tôt évite de multiplier les rôles dérivés.

Le volet données de paiement de l'e-reporting est souvent oublié lors du cadrage. Il ne relève ni de la comptabilité clients ni de la comptabilité fournisseurs, il a la même échéance de septembre, et il lui faut un responsable.

Si vous lisez ceci en août 2026

Le temps manque, et une conversion de niveaux organisationnels sur des rôles déjà en production prend plus de deux semaines. Sur une version actuelle, vous n'en aurez très probablement pas besoin.

Il faut en revanche vérifier les valeurs de $EDO_PROC et $EDO_ORG dans vos rôles DRC existants. S'ils sont à l'astérisque, chaque utilisateur du cockpit peut voir et traiter tous les documents électroniques du système, ce qu'un auditeur relèvera. La vérification prend un quart d'heure.

Par ordre de priorité :

  1. Ouvrez AGR_1252 pour vos rôles DRC et vérifiez que $EDO_PROC et $EDO_ORG sont des niveaux organisationnels avec de vraies valeurs, pas des astérisques.
  2. Vérifiez que EDO_BUK et F_SRF_RNTM-COUNTRY sont dérivés par pays, pour que le rôle France ne puisse pas lire les flux italiens ou espagnols.
  3. Listez tous les rôles contenant S_OA2C_USE et vérifiez que OA2C_PROF est restreint, y compris pour l'utilisateur technique derrière EDOC_BACKGROUND.
  4. Tracez le cockpit de bout en bout avec STAUTHTRACE sur un système de test, navigation vers les documents de facturation et comptables comprise.
  5. Écrivez les quatre règles SoD ci-dessus et appliquez-les aux rôles que vous allez livrer.

Comment MTC intervient

Depuis Genève, nous concevons et revoyons les concepts d'autorisations SAP de systèmes réglementés et multi-pays. Pour la réforme française, cela couvre :

  • la restriction par processus et par société dans DRC
  • les modèles de rôles dérivés
  • l'exposition OAuth et des interfaces
  • l'alignement SU24 pour Fiori
  • les règles SoD absentes du contenu standard

Sur les programmes de grande taille, nous intervenons aux côtés de cabinets internationaux de premier plan en audit, risque et conseil technologique, avec une équipe senior basée en Suisse responsable du volet sécurité.

À lire également

Questions fréquentes

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

Les objets centraux sont EDO_PROC (processus eDocument et étape de processus), EDO_ORG (critère organisationnel extensible, sa valeur et le processus), EDO_BUK (société) et F_SRF_RNTM (exécution des déclarations légales : activité, pays, catégorie de rapport). S'y ajoutent S_OA2C_USE pour le client OAuth 2.0, S_SERVICE pour les services Fiori/OData, et les objets financiers (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK) contrôlés quand l'utilisateur passe du cockpit eDocument au document source. Un rôle France complet compte une quarantaine d'objets.

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

Pas sur les versions actuelles de S/4HANA. EDO_PROC et EDO_ORG sont livrés comme niveaux organisationnels et apparaissent dans PFCG sous la forme $EDO_PROC et $EDO_ORG. PFCG_ORGFIELD_CREATE est une modification indépendante du mandant qui touche tous les rôles et demande une analyse d'impact, un gel de PFCG et une régénération de masse : vérifiez d'abord AGR_1252 ou le bouton des niveaux organisationnels sur un rôle DRC existant. Un niveau organisationnel n'est pas pour autant restreint : la plupart des rôles dérivés que nous voyons ont une société et un pays renseignés, mais $EDO_PROC et $EDO_ORG à l'astérisque.

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

Dès le 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 aussi 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, données de paiement) suit le même calendrier.

Quelles applications Fiori couvrent Document and Reporting Compliance ?

Trois applications, chacune avec un rôle différent : F4306 Manage Electronic Documents (équivalent Fiori de EDOC_COCKPIT), F5218 Manage Document and Reporting Compliance (tableau de bord de conformité multi-pays) et F1515 Run Statutory Reports (exécution des déclarations légales, utilisée pour l'e-reporting). Le menu du rôle doit aussi contenir les services OData EDOC_DCC_SRV, SRF_REPORTING_TASK, CV_ATTACHMENT_SRV, CA_OC_OUTPUT_REQUEST_SRV et CA_FM_FEATURE_TOGGLE_STATUS_SRV.

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

Les jeux de règles standard sont antérieurs à la réforme. Quatre conflits sont donc à écrire soi-même : création de facture client (VF01) avec les actions du cockpit qui annulent, ignorent ou terminent manuellement un eDocument ; saisie de facture fournisseur (MIRO) avec la mise à jour du statut de cycle de vie entrant ; customizing DRC en production avec la soumission ; configuration du client OAuth avec la soumission. Le modèle français transmet les statuts de cycle de vie des factures à l'administration : supprimer ou modifier un statut change donc les données déclarées.