Introduction
Les solutions RapidViews ont pour objectif de proposer un véritable accélérateur de déploiement de vos projets décisionnels SAP HANA mais également de les gérer et de les maintenir. Les RapidViews sont composés de datamarts virtuels ou comptoirs de données, de rapports prédéfinis et de tables de fait/dimension (Vues HANA), c’est le socle de la solution. Ils sont disponibles sur les modules de l’ERP SAP FI-CO, SD, MM et PP.
Nous estimons que la solution RapidViews couvre en moyenne 70% des besoin BI du client une fois installée. Pour couvrir les 30% de besoins restants et ainsi satisfaire l’ensemble des demandes additionnelles des clients, nous proposons de les accompagner dans la réalisation des développements.
Pour cela nous utilisons une méthode qui se décompose en plusieurs étapes :
- Dans un premier temps nous travaillons en collaboration directe avec le client pour comprendre son besoin. Cette étape aboutit grâce à un outil inclus dans les RapidViews à la génération de spécifications techniques.
- En même temps, grâce à ce même outil, nous déterminons la liste des demandes qui sont déjà couvertes par les RapidViews et celles qui devront être ajoutées au modèle.
- Enfin, une fois les développements sous HANA Studio, et le reporting achevé nous procédons à la recette des données.
Use Case :
Réalisation d’une vue RapidViews pour l’analyse financière des postes non soldés des comptes clients/fournisseurs en compensation :
Pour illustrer notre fonctionnement, nous allons présenter le travail réalisé chez l’un de nos clients dans le cadre d’un déploiement BI sur la comptabilité générale (Module FI-CO).
Besoin du client
Notre client souhaite reproduire dans ses outils de reporting le flux de compensation des comptes clients qui concerne des pièces comptables non soldées (enregistrées ou préenregistrées). Dans notre cas les clients compensent les postes fournisseurs/clients dans les paiements émis en fournissant des extraits de comptes retraçant ces compensations.
Présentation des RapidViews FI-CO utilisés :
Commençons par présenter les RapidViews utilisés du module FICO.
Nous avons utilisé les deux vues suivantes des RapidViews :
- La vue de la Balance client(F_CUSTOMERS_ITEMS_DV)
- La vue de la Balance fournisseur(F_SUPPLIER_ITEMS_DV)
Inscrivez-vous à la newsletter Rapid Views !
Soyez notifiés de nos derniers articles de blog, de nos prochains webinars et nos actualités !
Résumé des spécifications
Les RapidViews possèdent en standard les vues dont nous avons besoin pour répondre au besoin « Analyse globale des postes non soldés ». En effet les vues de balance fournisseurs et de balance client ont été installées chez le client clés en main.
On remarque cependant que ces vues sont indépendantes, or l’intérêt d’une vue « Analyse globale des postes non soldés » est de remonter les données des deux vues citées précédemment au sein d’une seule et même vue, et de compléter les éléments manquants à partir des tables SAP, calculs d’indicateurs et des règles métiers propres à notre client.
L’objectif de ce développement spécifique est donc de créer une vue « Analyse globale des postes non soldés » que nous appellerons F_PARKED_ITEMS_DV. Cette vue réalisera l’union entre la balance client, la balance fournisseur et les pièces comptables préenregistrées, et inclura aussi les règles métiers propres à notre client.
La vue F_PARKED_ITEMS_DV fera partie de la couche des vues supérieures aux RapidViews :
La solution mise en place consiste à déterminer les comptes en compensation des clients/fournisseurs liés à une pièce comptables enregistrée ou préenregistrée en utilisant les vues F_CUSTOMERS_ITEMS_DV et F_SUPPLIER_ITEMS_DV.
La solution technique est la suivante :
- Les deux jointures « getCustomerPeer » et « getVendorPeer » récupèrent les pièces comptables enregistrées liées à des comptes en compensation
- La première jointure est réalisée entre la vue F_CUSTOMERS_ITEMS_DV et la table KNA1 (Fiche Client) sur les champs « Mandant » et « N° de client » afin de récupérer les comptes des fournisseurs liés à des comptes de clients.
- La deuxième jointure est réalisable entre la vue F_SUPPLIER_ITEMS_DV et la table LFA1 (Fiche Fournisseur) sur les champs « Mandant » et « N° de fournisseur » afin de récupérer les comptes des clients liés à des comptes de fournisseurs.
- L’union « Compensation » récupère les attributs des comptes client/fournisseur en compensation issus de ces deux jointures.
- Le filtre dans la « Projection_3 » permet de conserver uniquement les comptes clients liés à des comptes fournisseurs.
- La jointure « getItemCategory » entre « la projection_3 » et BKPF (En-tête de la pièce comptable) nous permet de récupérer le statut de la pièce comptable (Enregistrée/Préenregistrée)
- La récupération des pièces comptable préenregistrées liés à des comptes client/ fournisseurs en compensation se fait dans la jointure « Join_2 » comme le montre le schéma ci-dessous :
- Union entre les pièces préenregistrées liées à des fournisseurs et les pièces préenregistrées liées à des clients « getParkedPeers ».
- Jointure entre les en-têtes et les postes des pièces préenregistrées « getParkedItems ».
- Une jointure entre « getParkedPeers » et « getParkedItems » afin de récupérer toutes les pièces préenregistrées liées à des comptes clients et/ou des comptes fournisseurs.
Ci-dessous la version finale de la vue F_PARKED_ITEMS :
Nous retrouvons les éléments suivants :
- Une union entre les pièces comptables enregistrées des comptes clients/fournisseurs en compensation avec les pièces comptables préenregistrées liées à des comptes clients/fournisseurs en compensation
- La colonne calculés « IndicatorIsParked » : Flague les postes préenregistrés à P et les postes standards à S
Une fois la nouvelle vue de fait terminée, elle peut être utilisée dans un datamart avec toutes les dimensions nécessaires à l’analyse souhaitée.
Conclusion
La vue « Analyse générale des comptes non soldés » est une vue réalisée pour répondre à un besoin spécifique sur la comptabilité des comptes clients en compensation. Elle permet d’identifier les pièces comptables non soldées (enregistrées ou préenregistrées) liées à des comptes en compensation.
Dans ce cas pratique, nous avons ajouté des tables SAP non présentes dans les RapidViews Standard, créé des champs calculés additionnels et réalisé des jointures / unions entre plusieurs vues des RapidViews.
Les développements additionnels peuvent varier selon les besoins des clients :
- Ajouter des tables ou champs SAP spécifiques (Ex : tables Z_…)
- Mettre en place des règles de gestion spécifiques au client
- Créer des calculs de nouveaux indicateurs
- Ajouter des données externes
- …
Ce cas pratique montre comment les RapidViews peuvent être utilisés et adaptés afin de répondre à un besoin d’analyse des données SAP dans le monde HANA.
Les RapidViews avec notre fondation et nos outils et méthodologies nous ont permis de répondre très rapidement à la demande de notre client.