Intégration à SAP

Cette page décrit les étapes d'intégration des charges de travail opérationnelles SAP (SAP ECC et SAP S/4 HANA) dans Cortex Framework Data Foundation. Cortex Framework peut accélérer l'intégration des données SAP à BigQuery à l'aide de modèles de traitement de données prédéfinis avec des pipelines Dataflow jusqu'à BigQuery, tandis que Cloud Composer planifie et surveille ces pipelines Dataflow pour obtenir des insights à partir de vos données opérationnelles SAP.

Le fichier config.json du répertoire Cortex Framework Data Foundation configure les paramètres requis pour transférer des données à partir de n'importe quelle source de données, y compris SAP. Ce fichier contient les paramètres suivants pour les charges de travail SAP opérationnelles:

  "SAP": {
        "deployCDC": true,
        "datasets": {
            "cdc": "",
            "raw": "",
            "reporting": "REPORTING"
        },
        "SQLFlavor": "ecc",
        "mandt": "100"
    }

Le tableau suivant décrit la valeur de chaque paramètre opérationnel SAP:

Paramètre Signification Valeur par défaut Description
SAP.deployCDC Déployer la CDC true Générez des scripts de traitement CDC à exécuter en tant que DAG dans Cloud Composer.
SAP.datasets.raw Ensemble de données de destination brut - Utilisé par le processus CDC, c'est là que l'outil de réplication place les données de SAP. Si vous utilisez des données de test, créez un ensemble de données vide.
SAP.datasets.cdc Ensemble de données traité par la CDC - Ensemble de données qui sert de source pour les vues de création de rapports et de cible pour les DAG des enregistrements traités. Si vous utilisez des données de test, créez un ensemble de données vide.
SAP.datasets.reporting Ensemble de données de rapport SAP "REPORTING" Nom de l'ensemble de données accessible aux utilisateurs finaux pour la création de rapports, où les vues et les tables destinées aux utilisateurs sont déployées.
SAP.SQLFlavor Variante SQL pour le système source "ecc" s4 ou ecc. Pour les données de test, conservez la valeur par défaut (ecc).
SAP.mandt Mandant ou client "100" Mandant ou client par défaut pour SAP. Pour les données de test, conservez la valeur par défaut (100).
SAP.languages Filtre de langue ["E","S"] Codes de langue SAP (SPRAS) à utiliser pour les champs pertinents (tels que les noms).
SAP.currencies Filtre de devise ["USD"] Codes de devise cible SAP (TCURR) pour la conversion de devise.

Bien qu'aucune version minimale de SAP ne soit requise, les modèles ECC ont été développés sur la version la plus ancienne actuellement prise en charge de SAP ECC. Des différences entre les champs de notre système et ceux d'autres systèmes sont à prévoir, quelle que soit la version.

Modèle de données

Cette section décrit les modèles de données SAP (ECC et S/4 HANA) à l'aide de diagrammes des relations entre entités (ERD).

SAP ECC

Schéma des relations entre les entités pour SAP ECC

Figure 2 SAP ECC: diagramme des relations entre entités.

SAP S/4 HANA

Schéma des relations entre les entités pour SAP S/4 HANA

Figure 2 SAP S/4 HANA: diagramme des relations entre entités.

Vues de base

Il s'agit des objets bleus de l'ERD. Il s'agit de vues sur les tables CDC sans autre transformation que certains alias de nom de colonne. Consultez les scripts dans src/SAP/SAP_REPORTING.

Vues de rapports

Il s'agit des objets verts de l'ERD et ils contiennent les attributs dimensionnels pertinents utilisés par les tableaux de rapports. Consultez les scripts dans src/SAP/SAP_REPORTING.

Affichage "Utilitaire" ou BQML

Il s'agit des objets jaunes de l'ERD. Ils contiennent les faits joints et les dimensions, ainsi qu'un type de vue spécifique utilisé pour l'analyse et la création de rapports sur les données. Consultez les scripts sur src/SAP/SAP_REPORTING.

Tags supplémentaires

Les tags de couleur de cet ERD représentent les fonctionnalités suivantes des tableaux de reporting:

Tag Color Description
L Jaune Cette balise fait référence à un élément ou un attribut de données qui spécifie la langue dans laquelle les données sont stockées ou affichées.
S/4 Rouge Cette balise indique que des attributs spécifiques sont spécifiques à SAP S/4 HANA (cet objet peut ne pas se trouver dans SAP ECC).
MANDT Violet Cette balise indique que des attributs spécifiques contiennent le paramètre MANDT (qui représente le client ou l'ID client) pour déterminer à quelle instance de client ou d'entreprise un enregistrement de données spécifique appartient.
EXT Rouge Cette balise indique que des objets spécifiques sont renseignés par des DAG ou des ensembles de données externes. Cela signifie que l'entité ou la table marquée n'est pas stockée directement dans le système SAP lui-même, mais qu'elle peut être extraite et chargée dans SAP à l'aide d'un DAG ou d'un autre mécanisme.
T Violet Cette balise indique que des attributs spécifiques seront automatiquement matérialisés à l'aide du DAG configuré.
S Rouge Cette balise indique que les données d'une entité ou de tables sont influencées ou affectées par plusieurs devises.

Conditions préalables à la réplication SAP

  • Cortex Framework Data Foundation s'attend à ce que les tables SAP soient répliquées avec les mêmes noms et types de champs que ceux créés dans SAP.
  • Tant que les tables sont répliquées avec le même format, les mêmes noms de champs et la même granularité que dans la source, il n'est pas nécessaire d'utiliser un outil de réplication spécifique.
  • Les noms de table doivent être créés en minuscules dans BigQuery.
  • La liste des tables utilisées par les modèles SAP est disponible et configurable dans le CDC cdc_settings.yaml. Si une table n'est pas listée lors du déploiement, les modèles qui en dépendent échouent. D'autres modèles se déploient correctement.
  • Tenez compte des points suivants si vous utilisez BigQuery Connector pour SAP :
  • Si vous ne prévoyez pas de déployer de données de test et si vous prévoyez de générer des scripts DAG CDC lors du déploiement, assurez-vous que le tableau DD03L pour les métadonnées SAP est répliqué à partir de SAP dans le projet source. Ce tableau contient des métadonnées sur les tables, comme la liste des clés, et est nécessaire pour que le générateur CDC et le résolveur de dépendances fonctionnent. Ce tableau vous permet également d'ajouter des tables non couvertes par le modèle pour générer des scripts CDC, comme des tables personnalisées ou des tables Z.

  • Si un nom de table présente de légères différences, il est possible que certaines vues ne parviennent pas à trouver un champ, car les systèmes SAP peuvent présenter de légères variations en raison des versions ou des modules complémentaires, et ajouter des structures dans les tables, ou parce que certains outils de réplication peuvent gérer les caractères spéciaux de manière légèrement différente. Nous vous recommandons d'exécuter le déploiement avec turboMode : false pour détecter la plupart des échecs en une seule tentative. Exemple :

    • Le _ des champs commençant par _ (par exemple, _DATAAGING) est supprimé.
    • Les champs ne peuvent pas commencer par / dans BigQuery.

    Dans ce cas, vous pouvez adapter la vue défaillante pour sélectionner le champ tel qu'il est placé par l'outil de réplication de votre choix.

Répliquer des données brutes à partir de SAP

L'objectif de Data Foundation est d'exposer des données et des modèles d'analyse pour les rapports et les applications. Les modèles consomment les données répliquées à partir d'un système SAP à l'aide d'un outil de réplication privilégié, comme ceux listés dans les guides d'intégration des données pour SAP.

Les données du système SAP (ECC ou S/4 HANA) sont répliquées sous forme brute. Les données sont copiées directement de SAP vers BigQuery sans modification de leur structure. Il s'agit essentiellement d'une image miroir des tables de votre système SAP. BigQuery utilise des noms de table en minuscules pour son modèle de données. Par conséquent, même si vos tables SAP ont des noms en majuscules (comme MANDT), elles sont converties en minuscules (comme mandt) dans BigQuery.

Conditions préalables à la réplication SAP

Tenez compte des conditions préalables suivantes pour les données de réplication SAP avec Cortex Framework Data Foundation :

  • Intégrité des données: Cortex Framework Data Foundation s'attend à ce que les tables SAP soient répliquées avec des noms, des types et des structures de données de champ identiques à ceux de SAP. Tant que les tables sont répliquées avec le même format, les mêmes noms de champs et la même granularité que dans la source, il n'est pas nécessaire d'utiliser un outil de réplication spécifique.
  • Nommer les tables: les noms des tables BigQuery doivent être créés en minuscules.
  • Configuration des tables: la liste des tables utilisées par les modèles SAP est disponible et configurable dans le fichier cdc_settings.yaml de la capture des données modifiées (CDC). Si une table n'est pas listée lors du déploiement, les modèles qui en dépendent échouent, même si les autres modèles non dépendants sont correctement déployés.
  • Considérations spécifiques à BigQuery Connector pour SAP :
  • Réplication des métadonnées: si vous ne déployez pas de données de test et ne générez pas de scripts DAG CDC lors du déploiement, assurez-vous que la table DD03L pour les métadonnées SAP est répliquée à partir de SAP dans le projet source. Ce tableau contient des métadonnées sur les tables, telles que la liste des clés, et est nécessaire pour que le générateur CDC et le résolveur de dépendances fonctionnent. Ce tableau vous permet également d'ajouter des tables non couvertes par le modèle, par exemple des tables personnalisées ou des tables Z, afin que des scripts CDC puissent être générés.

  • Gestion des différences mineures dans le nom des tables: si un nom de table présente de légères différences, certaines vues peuvent ne pas trouver les champs obligatoires, car les systèmes SAP peuvent présenter de légères variations en raison des versions ou des modules complémentaires, ou parce que certains outils de réplication peuvent gérer les caractères spéciaux de manière légèrement différente. Nous vous recommandons d'exécuter le déploiement avec turboMode : false pour détecter la plupart des échecs en une seule tentative. Voici quelques problèmes courants:

    • Le _ des champs commençant par _ (par exemple, _DATAAGING) est supprimé.
    • Les champs ne peuvent pas commencer par / dans BigQuery.

    Dans ce cas, vous pouvez ajuster la vue défaillante pour sélectionner le champ tel qu'il est placé par l'outil de réplication de votre choix.

Traitement de la capture des données modifiées (CDC)

Choisissez l'un des modes de traitement CDC suivants que Cortex Framework propose aux outils de réplication pour charger les enregistrements à partir de SAP:

  • Append-always: insérez chaque modification dans un enregistrement avec un code temporel et un indicateur d'opération (Insérer, Mettre à jour, Supprimer), afin que la dernière version puisse être identifiée.
  • Mettre à jour lors de l'atterrissage (fusion ou mise à jour): créez une version mise à jour d'un enregistrement lors de l'atterrissage dans change data capture processed. Il effectue l'opération CDC dans BigQuery.

Cortex Framework Data Foundation est compatible avec les deux modes, bien que pour l'ajout permanent, il fournisse des modèles de traitement CDC. Certaines fonctionnalités doivent être commentées pour être mises à jour sur la page de destination. Par exemple, OneTouchOrder.sql et toutes ses requêtes dépendantes. Cette fonctionnalité peut être remplacée par des tables telles que CDPOS.

Traitement CDC

Figure 1 Traitement CDC.

Configurer des modèles CDC pour les outils de réplication en mode "append-always"

Nous vous recommandons vivement de configurer cdc_settings.yaml en fonction de vos besoins. Certaines fréquences par défaut peuvent entraîner des coûts inutiles si l'entreprise n'a pas besoin d'un tel niveau de fraîcheur des données. Si vous utilisez un outil qui s'exécute en mode "append-always", Cortex Framework Data Foundation fournit des modèles CDC pour automatiser les mises à jour et créer la dernière version de la vérité ou du jumeau numérique dans l'ensemble de données traité par CDC.

Vous pouvez utiliser la configuration du fichier cdc_settings.yaml si vous devez générer des scripts de traitement CDC. Pour en savoir plus, consultez Configurer le traitement CDC. Pour les données de test, vous pouvez laisser ce fichier par défaut.

Apportez toutes les modifications nécessaires aux modèles de DAG en fonction de votre instance d'Airflow ou de Cloud Composer. Pour en savoir plus, consultez la section Recueillir les paramètres Cloud Composer.

Facultatif: Si vous souhaitez ajouter et traiter des tables individuellement après le déploiement, vous pouvez modifier le fichier cdc_settings.yaml pour ne traiter que les tables dont vous avez besoin et réexécuter le module spécifié en appelant directement src/SAP_CDC/cloudbuild.cdc.yaml.

Configurer le traitement CDC

Lors du déploiement, vous pouvez choisir de fusionner les modifications en temps réel à l'aide d'une vue dans BigQuery ou de planifier une opération de fusion dans Cloud Composer (ou toute autre instance d'Apache Airflow). Cloud Composer peut planifier les scripts pour traiter les opérations de fusion régulièrement. Les données sont mises à jour avec leur dernière version chaque fois que les opérations de fusion sont exécutées. Toutefois, des opérations de fusion plus fréquentes se traduisent par des coûts plus élevés. Personnalisez la fréquence de diffusion en fonction des besoins de votre entreprise. Pour en savoir plus, consultez la section Planification compatible avec Apache Airflow.

L'exemple de script suivant présente un extrait du fichier de configuration:

  data_to_replicate:
    - base_table: adrc
      load_frequency: "@hourly"
    - base_table: adr6
      target_table: adr6_cdc
      load_frequency: "@daily"

Cet exemple de fichier de configuration effectue les opérations suivantes:

  1. Créez une copie de SOURCE_PROJECT_ID.REPLICATED_DATASET.adrc dans TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adrc, si ce dernier n'existe pas.
  2. Créez un script CDC dans le bucket spécifié.
  3. Créez une copie de SOURCE_PROJECT_ID.REPLICATED_DATASET.adr6 dans TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adr6_cdc, si ce dernier n'existe pas.
  4. Créez un script CDC dans le bucket spécifié.

Si vous souhaitez créer des DAG ou des vues d'exécution pour traiter les modifications apportées aux tables qui existent dans SAP et qui ne sont pas listées dans le fichier, ajoutez-les à ce fichier avant le déploiement. Cela fonctionne tant que la table DD03L est répliquée dans l'ensemble de données source et que le schéma de la table personnalisée est présent dans cette table. Par exemple, la configuration suivante crée un script CDC pour la table personnalisée zztable_customer et une vue d'exécution pour analyser les modifications en temps réel pour une autre table personnalisée appelée zzspecial_table:

    - base_table: zztable_customer
      load_frequency: "@daily"
    - base_table: zzspecial_table
      load_frequency: "RUNTIME"

Exemple de modèle généré

Le modèle suivant génère le traitement des modifications. À ce stade, vous pouvez modifier des éléments tels que le nom du champ de code temporel ou des opérations supplémentaires:

  MERGE `${target_table}` T
  USING (
     SELECT *
     FROM `${base_table}`
     WHERE
        recordstamp > (
            SELECT IF(
                MAX(recordstamp) IS NOT NULL,
                MAX(recordstamp),
                TIMESTAMP("1940-12-25 05:30:00+00"))
            FROM `${target_table}` )
  ) S
  ON ${p_key}
  WHEN MATCHED AND S.operation_flag='D' AND S.is_deleted = true THEN
    DELETE
  WHEN NOT MATCHED AND S.operation_flag='I' THEN
    INSERT (${fields})
    VALUES
    (${fields})
  WHEN MATCHED AND S.operation_flag='U' THEN
  UPDATE SET
      ${update_fields}

Si votre entreprise nécessite des insights en temps quasi réel et que l'outil de réplication le permet, l'outil de déploiement accepte l'option RUNTIME. Cela signifie qu'aucun script CDC ne sera généré. À la place, une vue analyse et extrait le dernier enregistrement disponible au moment de l'exécution pour assurer une cohérence immédiate.

Structure des répertoires pour les DAG et les scripts CDC

La structure de bucket Cloud Storage pour les DAG CDC SAP s'attend à ce que les fichiers SQL soient générés en /data/bq_data_replication, comme dans l'exemple suivant. Vous pouvez modifier ce chemin avant le déploiement. Si vous ne disposez pas encore d'un environnement Cloud Composer, vous pouvez en créer un par la suite et déplacer les fichiers dans le bucket DAG.

with airflow.DAG("CDC_BigQuery_${base table}",
                template_searchpath=['/home/airflow/gcs/data/bq_data_replication/'], ##example
                default_args=default_dag_args,
                schedule_interval="${load_frequency}") as dag:
    start_task = DummyOperator(task_id="start")
    copy_records = BigQueryOperator(
      task_id='merge_query_records',
        sql="${query_file}",
        create_disposition='CREATE_IF_NEEDED',
        bigquery_conn_id="sap_cdc_bq", ## example
        use_legacy_sql=False)
    stop_task = DummyOperator (task_id="stop")
    start_task >> copy_records >> stop_task

Les scripts qui traitent les données dans Airflow ou Cloud Composer sont générés intentionnellement séparément des scripts spécifiques à Airflow. Vous pouvez ainsi les porter vers un autre outil de votre choix.

Champs CDC requis pour les opérations MERGE

Spécifiez les paramètres suivants pour la génération automatique de processus par lot CDC:

  • Projet source + ensemble de données:ensemble de données dans lequel les données SAP sont diffusées ou répliquées. Pour que les scripts CDC fonctionnent par défaut, les tables doivent comporter un champ d'horodatage (appelé "recordstamp") et un champ d'opération avec les valeurs suivantes, toutes définies lors de la réplication :
    • I: pour "Insert" (Insérer).
    • U: pour "Update" (Mettre à jour).
    • D: pour "Suppression".
  • Projet cible + ensemble de données pour le traitement CDC: le script généré par défaut génère les tables à partir d'une copie de l'ensemble de données source si elles n'existent pas.
  • Tables répliquées: tables pour lesquelles les scripts doivent être générés
  • Fréquence de traitement: conformément à la notation Cron, fréquence d'exécution des DAG:
  • Bucket Cloud Storage cible dans lequel les fichiers de sortie du CDC sont copiés.
  • Nom de la connexion: nom de la connexion utilisée par Cloud Composer.
  • (Facultatif) Nom de la table cible:disponible si le résultat du traitement CDC reste dans le même ensemble de données que la cible.

Optimisation des performances pour les tables CDC

Pour certains ensembles de données CDC, vous pouvez tirer parti du partitionnement de table et du clustering de table BigQuery, ou des deux. Ce choix dépend des facteurs suivants:

  • Taille et données de la table.
  • Colonnes disponibles dans le tableau.
  • Besoin de données en temps réel avec des vues.
  • Données matérialisées sous forme de tables.

Par défaut, les paramètres de CDC n'appliquent pas de partitionnement ni de clustering de tables. Vous pouvez le configurer en fonction de ce qui vous convient le mieux. Pour créer des tables avec des partitions ou des clusters, mettez à jour le fichier cdc_settings.yaml avec les configurations appropriées. Pour en savoir plus, consultez les pages Partitionnement de table et Paramètres du cluster.

  1. Cette fonctionnalité ne s'applique que lorsqu'un ensemble de données dans cdc_settings.yaml est configuré pour la réplication en tant que table (par exemple, load_frequency = "@daily") et non défini en tant que vue (load_frequency = "RUNTIME").
  2. Une table peut être à la fois une table partitionnée et une table en cluster.

Si vous utilisez un outil de réplication qui autorise les partitions dans l'ensemble de données brut, comme BigQuery Connector pour SAP, nous vous recommandons de définir des partitions basées sur le temps dans les tables brutes. Le type de partition fonctionne mieux s'il correspond à la fréquence des DAG CDC dans la configuration cdc_settings.yaml. Pour en savoir plus, consultez la section Considérations liées à la conception de la modélisation des données SAP dans BigQuery.

Facultatif: Configurer le module d'inventaire SAP

Le module d'inventaire SAP de Cortex Framework inclut des vues InventoryKeyMetrics et InventoryByPlant qui fournissent des insights clés sur votre inventaire. Ces vues sont basées sur des tables d'instantanés mensuelles et hebdomadaires à l'aide de DAG spécialisés. Vous pouvez exécuter les deux en même temps, sans qu'ils ne s'interfèrent.

Pour mettre à jour l'une ou les deux tables d'instantanés, procédez comme suit:

  1. Mettez à jour SlowMovingThreshold.sql et StockCharacteristicsConfig.sql pour définir le seuil de vente lente et les caractéristiques de stock pour différents types de matériaux, en fonction de vos exigences.

  2. Pour le chargement initial ou l'actualisation complète, exécutez des DAG Stock_Monthly_Snapshots_Initial et Stock_Weekly_Snapshots_Initial.

  3. Pour les actualisations ultérieures, planifiez ou exécutez les DAG suivants:

    • Mises à jour mensuelles et hebdomadaires :
      • Stock_Monthly_Snapshots_Periodical_Update
      • Stock_Weekly_Snapshots_periodical_Update
    • Mise à jour quotidienne :
      • Stock_Monthly_Snapshots_Daily_Update
      • Stock_Weekly_Snapshots_Update_Daily

  4. Actualisez les vues intermédiaires StockMonthlySnapshots et StockWeeklySnapshots, suivies des vues InventoryKeyMetrics et InventoryByPlants, respectivement, pour afficher les données actualisées.

Facultatif: Configurer la vue "Textes de l'arborescence des produits"

La vue "Textes de la hiérarchie des produits" aplatit les matériaux et leurs hiérarchies de produits. La table générée peut être utilisée pour fournir au module complémentaire Trends une liste de termes afin de récupérer l'intérêt au fil du temps. Pour configurer cette vue, procédez comme suit:

  1. Ajustez les niveaux de la hiérarchie et la langue dans le fichier prod_hierarchy_texts.sql, sous les repères pour ## CORTEX-CUSTOMER.

  2. Si votre hiérarchie de produits comporte plusieurs niveaux, vous devrez peut-être ajouter une instruction SELECT supplémentaire semblable à l'expression de table commune h1_h2_h3.

    Des personnalisations supplémentaires peuvent s'appliquer en fonction des systèmes sources. Nous vous recommandons d'impliquer les utilisateurs métier ou les analystes dès le début du processus pour les repérer.

Facultatif: Configurer des vues d'aplatissement de hiérarchie

À partir de la version v6.0, Cortex Framework prend en charge l'aplatissement de la hiérarchie en tant que vues de reporting. Il s'agit d'une amélioration majeure par rapport à l'ancien aplatisseur de hiérarchie, car il aplatit désormais l'ensemble de la hiérarchie, optimise mieux S/4 en utilisant des tables spécifiques à S/4 au lieu des anciennes tables ECC, et améliore également considérablement les performances.

Résumé des vues de rapports

Vous trouverez les vues suivantes liées à l'aplatissement de la hiérarchie:

Type de hiérarchie Table contenant uniquement une hiérarchie aplatie Vues pour visualiser une hiérarchie aplatie Logique d'intégration du compte de résultat à l'aide de cette hiérarchie
Version du relevé financier fsv_glaccounts FSVHierarchyFlattened ProfitAndLossOverview
Centre de profit profit_centers ProfitCenterHierarchyFlattened ProfitAndLossOverview_ProfitCenterHierarchy
Centre de coûts cost_centers CostCenterHierarchyFlattened ProfitAndLossOverview_CostCenterHierarchy

Tenez compte des points suivants lorsque vous utilisez des vues d'aplatissement de hiérarchie:

  • Les vues de la hiérarchie aplatie uniquement sont fonctionnellement équivalentes aux tables générées par l'ancienne solution d'aplatissement de la hiérarchie.
  • Les vues d'aperçu ne sont pas déployées par défaut, car elles sont destinées à présenter uniquement la logique d'analyse de données. Vous trouverez leur code source dans le répertoire src/SAP/SAP_REPORTING.

Configurer l'aplatissement de la hiérarchie

En fonction de la hiérarchie avec laquelle vous travaillez, les paramètres d'entrée suivants sont obligatoires:

Type de hiérarchie Paramètre obligatoire Champ source (ECC) Champ source (S4)
Version du relevé financier Plan comptable ktopl nodecls
Nom de la hiérarchie versn hryid
Centre de bénéfices Classe de l'ensemble setclass setclass
Unité organisationnelle: zone de contrôle ou clé supplémentaire pour l'ensemble. subclass subclass
Centre de coûts Classe de l'ensemble setclass setclass
Unité organisationnelle: zone de contrôle ou clé supplémentaire pour l'ensemble. subclass subclass

En cas de doute sur les paramètres exacts, demandez conseil à un consultant SAP en finance ou en contrôle.

Une fois les paramètres collectés, mettez à jour les commentaires ## CORTEX-CUSTOMER dans chacun des répertoires correspondants, en fonction de vos besoins:

Type de hiérarchie Emplacement du code
Version du relevé financier src/SAP/SAP_REPORTING/local_k9/fsv_hierarchy
Centre de profit src/SAP/SAP_REPORTING/local_k9/profitcenter_hierarchy
Centre de coûts src/SAP/SAP_REPORTING/local_k9/costcenter_hierarchy

Le cas échéant, veillez à mettre à jour les commentaires ## CORTEX-CUSTOMER dans les vues de rapports pertinentes du répertoire src/SAP/SAP_REPORTING.

Détails de la solution

Les tables sources suivantes sont utilisées pour aplatir la hiérarchie:

Type de hiérarchie Tables sources (ECC) Tables sources (S4)
Version du relevé financier
  • fagl_011pc
  • fagl_011zc
  • ska1
  • hrrp_node
  • hrrp_directory
  • ska1
Centre de profit
  • setheader
  • setnode
  • setleaf
  • sethanahier0106
Centre de coûts
  • setheader
  • setnode
  • setleaf
  • sethanahier0101

Visualiser les hiérarchies

La solution d'aplatissement de la hiérarchie SAP de Cortex aplatit l'ensemble de la hiérarchie. Si vous souhaitez créer une représentation visuelle de la hiérarchie chargée qui soit comparable à ce que SAP affiche dans l'UI, interrogez l'une des vues permettant de visualiser les hiérarchies aplaties avec la condition IsLeafNode=True.

Migrer depuis l'ancienne solution d'aplatissement de la hiérarchie

Pour migrer depuis l'ancienne solution d'aplatissement de la hiérarchie avant Cortex v6.0, remplacez les tables comme indiqué dans le tableau suivant. Assurez-vous que les noms des champs sont exacts, car certains ont été légèrement modifiés. Par exemple, prctr dans cepc_hier est désormais profitcenter dans la table profit_centers.

Type de hiérarchie Remplacez ce tableau: Avec:
Version du relevé financier ska1_hier fsv_glaccounts
Centre de profit cepc_hier profit_centers
Centre de coûts csks_hier cost_centers

Facultatif: Configurer le module SAP Finance

Le module SAP Finance de Cortex Framework inclut les vues FinancialStatement, BalanceSheet et ProfitAndLoss qui fournissent des insights financiers clés.

Pour mettre à jour ces tables Finance, procédez comme suit:

Pour le chargement initial

  1. Après le déploiement, assurez-vous que votre ensemble de données CDC est correctement renseigné (exécutez les DAG CDC si nécessaire).
  2. Assurez-vous que les vues d'aplatissement de la hiérarchie sont correctement configurées pour les types de hiérarchies que vous utilisez (FSV, centre de coûts et centre de profit).

  3. Exécutez le DAG financial_statement_initial_load.

  4. Si vous les déployez en tant que tables (recommandé), actualisez les éléments suivants dans l'ordre en exécutant les DAG correspondants:

    1. Financial_Statements
    2. BalanceSheets
    3. ProfitAndLoss

Pour l'actualisation périodique

  1. Assurez-vous que les vues d'aplatissement de la hiérarchie sont correctement configurées et à jour pour les types de hiérarchies que vous utilisez (FSV, centre de coûts et centre de profit).

  2. Planifiez ou exécutez le DAG financial_statement_periodical_load.

  3. Si vous les déployez en tant que tables (recommandé), actualisez les éléments suivants dans l'ordre en exécutant les DAG correspondants:

    1. Financial_Statements
    2. BalanceSheets
    3. ProfitAndLoss

Pour visualiser les données de ces tables, consultez les vues "Vue d'ensemble" suivantes:

  • ProfitAndLossOverview.sql si vous utilisez la hiérarchie FSV.
  • ProfitAndLossOverview_CostCenter.sql si vous utilisez la hiérarchie des centres de coûts.
  • ProfitAndLossOverview_ProfitCenter.sql si vous utilisez la hiérarchie des centres de profit.

Étape suivante