Il y a un peu plus d’une dizaine d’années, l’apparition du New Ledger représentait une avancée majeure dans le modèle de données financier Sap

• Simplification de l’architecture des modules financiers (notamment fusion de la comptabilité des centres de profit dans la comptabilité générale)
• Introduction d’une véritable gestion multi-normes (IFRS , Local GAAP…) via l’utilisation de Ledgers au sein même du module FI-GL
• Accélération des processus de clôture (rapprochement FI-CO & ventilation analytique bilancielle en temps réel, reporting sectoriel natif…)
• Reporting multi-axes dans la comptabilité générale (notamment via l’apparition de la table FAGLFLEXT, bien plus riche et flexible que son ancètre GLT0)

 

Bien que déjà exceptionnelle, cette avancée paraît aujourd’hui toute relative au regard du pas de géant accompli par Sap avec S4HANA

 

Dans un premier temps, la puissance des bases de données Sap HANA a permis une refonte drastique du modèle de donnée des modules financiers.

Sans entrer dans les détails techniques (modèle de stockage « In-memory », basé en colonnes, « massively parallel processing ») ou encore aborder son potentiel OLTP + OLAP, la puissance de cette base de données permet de s’affranchir des tables de totaux et autres index secondaires (BSIK, BSAK,…) et par la même occasion des « lourdeurs » du code associé

Ne sous-estimez pas cette avancée, cela constitue un tournant sans précédent dans l’histoire même des systèmes d’informations:

Enfin débarrassé de ces agrégats et index secondaires hérités d’une ère ou les serveurs ne pouvaient gérer suffisamment de mémoire vive et de processeurs pour calculer les totaux à la volée et nous obliger à de nombreux artifices !

 

 

Il n’est jamais simple de fournir des chiffres précis  en matière de gain de performance tant les paramètres sont nombreux mais dans la pratique, la réactivité du système est impressionnante.

Quel plaisir au quotidien de ne plus avoir ce petit laps de temps d’attente (contribuant insidieusement au « syndrome du stress informatique ») au niveau transactionnel ! sans parler du temps d’exécution des programmes

Ce gain de performance hors norme est bien entendu lié à l’adoption de la base de données HANA dont les données courantes sont stockées en RAM (aucune comparaison déjà à ce stade avec le temps de réponse des disques durs traditionnels) mais également au modèle de données hyper épuré de S4HANA qui est capable (merci Hana) de s’exonérer des processus particulièrement consommateurs en ressources et en temps de mise à jour des tables de totalisations.

 

Dans un deuxième temps, Sap a décuplé le potentiel du New Ledger via l’introduction du « Journal Universel », en d’autres termes, une table (« ACDOCA » pour les données réelles) regroupant les principales caractéristiques FI-CO, permettant une simplification majeure du reporting (« one single source of truth ») mais également de reléguer au passé les problématiques de rapprochement FI-CO et FI-AA

La table ACDOCA comprend près de 370 champs dans les dernières versions Sap S4HANA (variable selon le nombre de champs ajoutés au Coding Block et à CO-PA Comptable) mais ne se substitue aucunement à BSEG (table des pièces FI qui avoisine maintenant les 390 champs)

En effet, elle se positionne  plutôt au niveau des tables FAGLFLEXA – dans la mesure ou les enregistrements sont gérés par Ledger – tout en condensant les données réelles issues de CO-OM, CO-PA Comptable,  Material Ledger ainsi que de la comptabilité des immobilisations

 

 

Pour autant, ACDOCA n’est pas une simple extension de la table FAGLFLEXA, Sap a été bien plus judicieux en créant un journal universel sans « polluer » le référentiel comptable (BSEG en quelque sorte) avec les flux purement analytiques :

Ainsi, lors de la comptabilisation d’un flux purement analytique, un document FI est désormais comptabilisé avec un enregistrement d’en-tête (BKPF), des enregistrements dans le journal universel (ACDOCA) mais absolument rien dans BSEG et c’est bien là que réside toute la quintessence du Journal Universel

Ce type de flux est aisément identifiable lors de la consultation d’une pièce FI:

• Type de pièce en principe dédié (« CO » le plus souvent)
• Statut de pièce « U » (« Pièce standardisée »)
• Pas de vue de saisie (uniquement vue du grand livre)

 

 

 

Ce nouveau véritable « genre » de pièce FI (enregistrements dans BKPF et ACDOCA sans enregistrement dans BSEG) est également utilisé par d’autres mécanismes tels que la réévaluation en devises étrangères ou encore par les cycles de répartitions GL.

Notez au passage qu’il existe également des cas d’enregistrements uniquement dans ACDOCA lors des reports à nouveau, cela paraît logique dès lors qu’il n’y a plus de véritable table de totaux (remplacées par des vues pour des raisons de compatibilité)

 

Cette nouvelle architecture s’accompagne de nombreuses améliorations / simplifications (« Simplification List »)

Impossible ici d’être exhaustif, à  titre d’exemple, pour les modules financiers:

• Introduction d’un nouveau type de Ledger dans FI (Extension Ledger) permettant de gérer (via OD manuelles uniquement) quelques ajustements à des fins diverses (ajustement de normes, préparation à la consolidation, reporting fiscal, reporting interne) sans qu’il soit nécessaire de répliquer les données du Ledger de référence
• Fusion des comptes généraux avec les natures comptables (FS00)
• Les clients et fournisseurs sont désormais des Business Partenaires (BP), sauf versions « S4HANA Finance »
• les comptes bancaires sont maintenant des données de base  afin de bénéficier de nouvelles fonctionnalités sous S4 (Workflow d’ouverture de compte par exemple) et doivent être gérés via Fiori ou à défaut NWBC
• La nouvelle comptabilité des immobilisations (déjà disponible depuis ECC6 EhP7) prend maintenant tout son sens avec S/4HANA et n’est plus optionnelle si vous souhaitez utiliser ce module
• CO-PA Comptable se rapproche en partie de CO-PA analytique – en terme de fonctionnalité – et est intégré au Journal Universel, ce qui le rend bien plus intéressant qu’au paravant
• Material Ledger devient également un passage obligé (sauf pour les versions « S4HANA Finance ») afin de bénéficier du reporting multi-devises dans la gestion de stock
• La gestion du crédit client s’effectue désormais nécessairement dans Sap Credit Management (FIN-FSCM-CR) afin de bénéficier de fonctionnalités plus avancées (intégration de données d’agences de crédit, calcul de scoring et plafond de crédit, gestion de dépendances dans les événements liés au crédit…)

 

 

 

Enfin, il est inenvisageable de ne pas évoquer les nombreux efforts réalisés par Sap pour rendre l’interface plus « user friendly», notamment avec Sap Fiori, que l’on pourrait qualifier ainsi: « Web based »,  « Cross platforms/devices », « Cross applications », « Role based », « Tansactional/ Analytical / Factsheet ».

 

 

Marc Samama

Consultant S/4HANA