Numérotation des objets assistée par index 
Numérotation des objets assistée par index
Lorsqu’une pièce est enregistrée dans l’Analyse du compte de résultat, le système doit rechercher un numéro d’objet de résultat pour la combinaison des valeurs de caractéristiques fournies par cette pièce. Il est extrêmement important que le système puisse procéder à la numérotation le plus rapidement possible, sans quoi le débit de données global risque d’être considérablement ralenti lorsque vous transférez des données externes ou enregistrez des factures groupées (lorsque vous imputez simultanément vers un nombre élevé d’objets de résultat).
Cette rubrique décrit, du point de vue technique, comment le système recherche le numéro d’objet et règle les problèmes éventuels. Ces informations s’appliquent à toutes les versions ultérieures à la version 2.1A.
Structure de données de la table d’objets
Les éléments les plus importants de la table d’objets CE4xxxx sont le numéro d’objet, situé dans la clé de la table, et les caractéristiques du périmètre de résultat, qui constituent la partie données. La table CE4xxxx est structurée comme suit :
Nom de zone |
Clé |
Commentaire |
MANDT |
X |
Mandant |
AKTBO |
X |
Toujours « X » actuellement |
PAOBJNR |
X |
Numéro d’objet de résultat |
PASUBNR |
X |
Toujours « 0001 » actuellement |
KNDNR |
Numéro client | |
ARTNR |
Numéro d’article | |
FKART |
Type d’opération | |
Autres caractéristiques fixes | ||
Caractéristiques définies dans le périmètre de résultat dans le Customizing | ||
Zones techniques supplémentaires | ||
Chaque numéro d’objet représente une combinaison spécifique de valeurs de caractéristiques.
Recherche du numéro d’objet via une sélection dans la table d’objets
Lorsqu’une pièce (telle qu’une facture, une pièce issue de l’imputation de l’ordre ou des données externes) est imputée à l’Analyse du compte de résultat, le système doit définir le numéro d’objet approprié en fonction de la combinaison des valeurs de caractéristiques fournies par la pièce. Pour ce faire, le système procède à une sélection dans la table d’objets à l’aide de toutes les valeurs définies dans la partie données. La sélection ressemble à ceci :
SELECT * FROM CE4xxxx
WHERE AKTBO = "X"
AND KNDNR = ...
AND ARTNR = ...
AND FKART = ...
AND (toutes les autres caractéristiques spécifiées)
Une condition de mandant est également implicitement spécifiée par le système d’exécution ABAP !
Index secondaire standard
La vitesse à laquelle le système trouve les numéros d’objet dans la table d’objets influence fortement les performances générales du système pour le transfert de factures groupées, de données externes ou d’écritures (comme l’imputation de l’ordre, les imputations directes depuis FI) dans les objets de résultat.
L’index primaire (code d’indexation 0) lié à la clé de la table d’objets ne convient pas à la sélection ci-dessus. Par conséquent, SAP tente de prendre en charge cet accès spécial à l’aide d’un index secondaire adapté (code d’indexation 1). Dans le système standard, cet index contient quelques-unes des caractéristiques fixes suivantes situées dans chaque périmètre de résultat :
Requêtes de recherche à l’aide d’index
Un index ne contient une copie que de quelques zones d’une table de base de données. Dans l’index, ces zones sont triées - par opposition aux données de la table elle-même. Le système peut ainsi accéder plus rapidement aux données de l’index. En outre, chaque entrée de l’index « pointe » vers l’enregistrement de données correspondant dans la table.
Si une requête de recherche spécifie des conditions pour des zones comprises dans un index, le système peut traiter une partie de cette requête simplement à l’aide des données de l’index. Par conséquent, certaines entrées de l’index - et les enregistrements de données correspondants - peuvent être écartées sans que le système ne doive lire la table directement.
Le système doit ensuite lire les enregistrements de données de la table qui correspondent aux autres entrées de l’index. Ce n’est qu’alors qu’il peut déterminer si un enregistrement de données répond également au reste de la requête de recherche, c’est-à-dire si cet enregistrement figure dans la liste des occurrences. La lecture des enregistrements de données prend plus de temps que la lecture de l’index.
Par conséquent, il faut définir l’index de sorte que le nombre d’enregistrements de données qui doivent être lus dans la table ne soit pas beaucoup plus élevé que le nombre d’enregistrements qui répondent à la condition de recherche. Ce type d’index est appelé index sélectif puisqu’il exécute la plupart de la sélection de la requête de recherche.
1 : analyse du compte de résultat au niveau client/article
Si vous utilisez les caractéristiques Client et Article au niveau de l’objet, le système transfère automatiquement les factures depuis ADV dans CO-PA avec ce niveau de détail. Ainsi, lorsque le système recherche le numéro d’objet de résultat d’un poste de facture, les valeurs de caractéristiques Client (KNDNR) et Article (ARTNR) sont reprises dans la commande SELECT. Ces deux caractéristiques ont un nombre très élevé de valeurs dans la table d’objets (il s’agit de zones sélectives de la table d’objets). Par conséquent, l’index secondaire MANDT, AKTBO, KNDNR, ARTNR, BUKRS, WERKS, VTWEG est également sélectif et il est possible de définir rapidement le numéro d’objet de résultat.
2 : analyse du compte de résultat à un niveau supérieur
Considérons un système dans lequel les caractéristiques Client et Article ne sont pas des caractéristiques du niveau de l’objet. (voir également la section Données de base
Dans ce cas, les zones KNDNR et ARTNR sont vides dans tous les enregistrements du niveau de l’objet CE4xxxx. Par conséquent, l’index susmentionné n’est pas sélectif. Ainsi, la sélection de recherche du numéro d’objet de résultat se présente comme suit :
SELECT * FROM CE4xxxx
WHERE AKTBO = "X"
AND KNDNR = " "
AND ARTNR = " "
AND FKART = constante
AND (toutes les autres caractéristiques spécifiées)
Le problème réside dans le fait que les zones indépendantes sélectives (dans ce cas, il peut s’agir du groupe de clients et du secteur) sont spécifiées dans la sélection mais n’apparaissent pas dans l’index secondaire utilisé. Par ailleurs, les zones comparativement moins sélectives - MANDT (habituellement une valeur), AKTBO (toujours « X »), KNDNR et ARTNR (toujours vides), BUKRS, WERKS et VTWEG (généralement quelques valeurs uniquement) - sont comprises dans l’index secondaire. Lorsque le système lit cet index (scannage sur l’ensemble de l’index), il doit également lire tous les enregistrements de la table d’objets qui contiennent les valeurs spécifiées pour KNDNR, ARTNR, MANDT, AKTBO, BUKRS, WERKS et VTWEG. Dans le pire des cas, il peut même s’agir de l’ensemble de la table d’objets. Le système lit alors trop d’enregistrements, ce qui ralentit considérablement la requête. Les durées d’exécution des factures s’en ressentent également.
La règle suivante découle de ces exemples :
Règle :
Un index secondaire permet de prendre en charge la numérotation des objets à condition qu’il comprenne les caractéristiques restrictives et sans rapport logique de la table d’objets. Les zones MANDT et AKTBO doivent être les premières zones de l’index secondaire, sans quoi le système de base de données lit plutôt l’index primaire.
3 : index secondaire bien adapté
Si votre système utilise les caractéristiques Client et Article au niveau de l’objet, vous devez utiliser un index qui contient les zones MANDT, AKTBO, KNDNR et ARTNR. Par ailleurs, si vous n’utilisez pas les caractéristiques Client et Article et que le groupe de clients (KDGRP) et le secteur (SPART) sont des caractéristiques indépendantes, il est plus judicieux d’utiliser un index contenant les zones MANDT, AKTBO, KDGRP et SPART. Ainsi, pour créer un index secondaire adapté, vous devez connaître la hiérarchie logique des caractéristiques de votre périmètre de résultat.
Enregistrements dans plusieurs niveaux hiérarchiques
À l’aide de l’index secondaire proposé dans la règle ci-dessus, le système peut définir rapidement le numéro d’objet des factures. Toutefois, l’enregistrement de données issues d’autres opérations dans un niveau hiérarchique différent pose un problème supplémentaire.
3.1 : transfert externe des données pré-budgétées dans un niveau supérieur
Considérons un périmètre de résultat qui dispose des caractéristiques Client et Article au niveau de l’objet, mais pour lequel la pré-budgétisation s’effectue au niveau du groupe de clients (KDGRP) et du secteur (SPART). Dans ce cas également, l’index secondaire indiqué ci-dessus (MANDT, AKTBO, KNDNR, ARTNR) convient au transfert des factures.
Toutefois, lorsque vous créez des pièces pré-budgétées à un niveau supérieur, il est possible que les performances du système s’en ressentent lorsque le système recherche les numéros d’objet. En effet, le système doit lire tous les enregistrements de la table d’objets dans lesquels les zones KNDNR et ARTNR sont vides. S’il existe un nombre élevé d’enregistrements, cela affecte considérablement les performances du système.
3.2 : compte de résultat comptable
Vous serez confronté à un problème similaire si vous travaillez au niveau client/article dans le compte de résultat analytique et que ces caractéristiques ne sont pas utilisées dans le compte de résultat comptable.
Par conséquent, il faut modifier la règle établie ci-dessus. Il ne suffit pas d’inclure les caractéristiques sans rapport logique dans l’index secondaire. Par conséquent :
Règle :
Un index « optimal » pour la prise en charge de la numérotation des objets doit comprendre - après MANDT et AKTBO - toutes les caractéristiques restrictives et sans rapport logique de toutes les sélections de numéro d’objet (y compris celles des niveaux supérieurs).
Notes
4 : index secondaire optimal
Dans l’exemple ci-dessus (données réelles au niveau client/article et pré-budgétisation au niveau groupe de clients/secteur), un index secondaire comprenant MANDT, AKTBO, KNDNR, ARTNR, KDGRP, SPART serait suffisant. Si vous avez également besoin d’objets de résultat à des niveaux supérieurs (par exemple, à cause de la répartition globale des coûts de centres de coûts), vous devez de nouveau compléter cet index.
Il est préférable de compléter un premier index plutôt que de créer des index supplémentaires (par exemple, un index 1 avec MANDT, AKTBO, KNDNR, ARTNR et un index 2 avec MANDT, AKTBO, KDGRP, SPART). Puisque la condition de sélection pour la recherche du numéro de l’objet de résultat est toujours intégralement spécifiée, le système utilise toujours le même index.
SAP recommande fortement de remplacer le modèle d’index secondaire SAP (code d’indexation 001) par un index secondaire optimisé selon vos besoins particuliers.
La transaction ST05 (trace SQL) et le bouton de commande Explain SQL vous permettent de vérifier si l’index secondaire que vous avez créé est réellement utilisé dans la recherche des numéros d’objet. Voir également
La fonction Explain SQL montre la stratégie d’accès de la base de données lorsqu’elle traite une instruction SELECT. Recherchez une instruction OPEN ou REOPEN pour la table CE4xxxx dans la représentation sous forme de liste de la trace SQL. En fonction du temps indiqué dans la liste (normalement nettement inférieur à 100 millièmes de seconde), vous pouvez juger de l’efficacité absolue du chemin d’accès sélectionné.