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), la puissance de cette base de données permet de s’affranchir des tables de totaux et autres index secondaires et par la même des « lourdeurs » du code associé

Ceci 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 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 obligés à de nombreux artifices !

il n’est pas 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 de ne plus avoir ce petit laps de temps d’attente lors de chaque appel de transaction !

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 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 (variable selon le nombre de champs du Coding Block et de COPA Comptable) et dans les dernières version Sap S4HANA mais ne se substitue pas pour autant avec BSEG (table des pièces FI qui avoisine maintenant les 390 champs) mais plutôt principalement aux tables FAGLFLEXA – dans la mesure ou les enregistrements sont par Ledger – et COEP – pour les données réelles – comme nous allons le voir.

Pour autant, ACDOCA n’est pas une simple extension de la table FAGLFLEXA, Sap a été bien plus judicieux pour créer un journal universel sans pour autant « 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

Il est facile d’identifier ce type de flux 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 « 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.

Notez au passage qu’il existe également des cas d’enregistrements dans ACDOCA uniquement lors des reports à nouveau, cela paraît logique dès lors qu’il n’y a plus de véritable table de totaux.

Cette simplification du modèle de donnée s’accompagne de nombreuses simplifications (« Simplification List »)

A titre d’exemple:

• Fusion des comptes généraux avec les natures comptables
• Les clients et fournisseurs sont désormais des Business Partenaires (BP), sauf versions S4HANA Finance
• La nouvelle comptabilité des immobilisation (déjà disponible avec ECC6 EhP7) prend maintenant tout son sens avec S/4HANA et n’est plus optionnelle si vous souhaitez utiliser ce module
• 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 maintenant nécessairement dans Sap Credit Management (FIN-FSCM-CR)

Enfin, il n’est pas envisageable de ne pas évoquer les nombreux efforts réalisés par Sap pour rendre l’interface plus « user friendly », notamment avec Sap Fiori