Étude des données archivées 

L'archivage des données dans mySAP CRM est similaire à celui effectué dans SAP R/3. Dans les deux cas, des documents créés dans une application et contenant toutes les données relatives à un événement commercial concret sont archivés à l’aide d’objets d'archivage. Toutefois, CRM n’utilise pas le terme document mais celui plus général d’objet de gestion ou, comme dans la gestion de l'opération CRM, le terme opération commerciale. Pour comprendre l'archivage de données CRM, vous devez avoir une représentation précise de la relation entre un objet d'archivage et les données à archiver. Les informations de base ci-après vous permettent de mieux comprendre l'archivage de données CRM.

Relation entre le type d’opération, le type d'opération commerciale et l'objet d'archivage

Une opération commerciale (CRM) se compose de différentes données stockées dans des tables de base de données distinctes. Durant l'archivage, le système utilise les définitions de données sauvegardées dans l'objet d'archivage pour retrouver toutes les données inhérentes à une opération commerciale particulière et les enregistrer, si nécessaire, dans les archives. Ceci préserve l’intégrité de l'opération commerciale archivée et permet de l’afficher ultérieurement sans problème.

Type d’opération et type d'opération commerciale

Une opération commerciale CRM (commande client, visite, ordre de service, etc.) est décrite par un type d'opération exactement (voir le diagramme). Le type d'opération définit la structure de l'opération commerciale et notamment les tables impliquées, qui ont également leur importance dans l'archivage des données. En outre, le type d'opération régit le traitement de l'opération commerciale et détermine les attributs de pilotage (c'est-à-dire le schéma de texte, le schéma partenaire, le schéma de statut et le profil structurel). En d'autres termes, le type d'opération définit les propriétés et les caractéristiques d'une opération commerciale, ainsi que les valeurs par défaut et la manière dont celles-ci sont traitées. Une opération commerciale est toujours créée en faisant référence à un type d'opération.

À un type d’opération sont affectés un ou plusieurs types d'opération commerciale (contrat, vente ou service par exemple). Le type d'opération commerciale détermine le contexte commercial dans lequel le type d'opération peut être utilisé (dans le cadre d’un service, d’une vente, ou d’une activité par exemple). Créés dans le Business Object Repository (BOR), les types d'opération commerciale sont par conséquent également désignés sous le nom d'objets BOR. Vous pouvez définir le type d'opération commerciale au niveau de l’en-tête ou du poste d'opération commerciale. Le type d’opération commerciale indiqué dans l'en-tête peut lui-même se décomposer en type d'opération commerciale principal et type secondaire. Le type d'opération commerciale principal de l’en-tête peut contenir de 0 à n types secondaires.

Le type d'opération commerciale est prédéfini par le système, tandis que le type d'opération est paramétrable par l’utilisateur dans le Customizing. Le concept d'opération commerciale permet donc de créer des postes résultant de contextes commerciaux différents dans une même opération. Par exemple, vous pouvez vendre des produits mais également saisir des postes de réclamation ou de retour dans la même opération.

Sets et extensions

Les données réelles d'une opération commerciale sont stockées dans des tables qui font partie de « sets » et « d’extensions ». Il n’existe pas de tables particulières pour les types d'opération commerciale. Ces derniers jouent seulement un rôle logique dans la structure d'une opération commerciale. Les sets et les extensions, qui ne représentent pas des objets BOR, ne sont pas définis dans le Business Object Repository. En termes techniques, les sets et les extensions sont implémentés comme un progiciel intégrant plusieurs groupes de fonctions. Dans ce progiciel, l'archivage des données est représenté par son propre groupe de fonctions.

·        Extension : vient en complément d’une opération commerciale ; elle contient des informations supplémentaires sur l'opération commerciale et la décrit plus précisément du point de vue de la gestion d'entreprise. L’extension peut exister pour l’opération elle-même, au niveau de l’en-tête, ou pour le poste d’opération commerciale. On peut citer comme exemple les extensions CUSTOMER_H (extension d’en-tête pour compléter les données client) et FINPROD_I (extension de poste pour les données financières).

·        Set : représente également un complément de l’opération commerciale.   Il peut exister pour l’opération (niveau en-tête), pour le poste d'opération commerciale ou pour les deux. Un set permet de sauvegarder les données qui s’appliquent aussi bien à l’opération qu’aux postes. Les informations d'expédition, l'entité organisationnelle et les données partenaire sont des exemples de set. Les sets, qui peuvent être employés plusieurs fois, évitent les données redondantes.

Pour plus d'informations sur ce thème, voir le modèle de données des opérations commerciales CRM, modèle disponible sous /modelage ® Documentation dans le SAP Service Marketplace.

Rôle de l'objet d'archivage

Comment ces concepts se traduisent-ils en termes d’archivage des données ? À chaque objet d'archivage sont affectées n types principaux d’en-tête d’opération commerciale. L’affectation de ces types d'opération commerciale à l'objet d'archivage a lieu dans la transaction DA_CONTROL. De cette façon, lorsque vous archivez une opération commerciale, toutes les entrées de table qui appartiennent à un type d'opération commerciale principal de niveau en-tête (entrées sauvegardées dans les sets et extensions du type en question) et toutes les entrées de table qui sont affectées à des types d’opération commerciale de niveau poste ou en-tête d'opération (entrées également sauvegardées dans les sets et extensions du type en question), sont copiées dans les archives. Le diagramme suivant illustre les relations décrites ci-dessus :

Le diagramme montre qu'une opération commerciale englobe, au niveau en-tête, un type d'opération commerciale principal et un ou plusieurs types d'opération commerciale secondaires (facultatif).  Le type d'opération commerciale principal au niveau en-tête peut s’accompagner d’un ou de plusieurs types d'opération commerciale au niveau du poste. Les types d'opération commerciale de poste et d'en-tête peuvent à leur tour faire partie d’un ou de plusieurs sets ou extensions. Le nombre de sets et d’extensions autorisé est défini dans le Customizing. Un type d'opération ne doit pas obligatoirement utiliser tous les sets et extensions autorisés. Les chiffres indiqués dans le diagramme décrivent les relations entre les différents objets.

Exemple

Les types d'opération commerciale Opération de vente CRM (BUS2000115) et Contact CRM (BUS2000126) sont affectés au type d'opération Commande client standard (voir diagramme ci-après).   Opération de vente CRM représente le type principal. Les types d’opération commerciale de niveau poste Poste de vente CRM (BUS2000131) et Poste de livraison d'échange CRM (BUS2000165) sont affectés à ce type d'opération commerciale principal.

Les types d'opération commerciale utilisent les sets et extensions suivants (extrait) :

Type d’opération	Set ou extension
BUS2000115	BILLING, CUMULAT_H, CUSTOMER_H, PARTNER, TEXTS
BUS2000126	ACTIVITY_H, APPOINTMENT, CUSTOMER_H
BUS2000131	APO_I, TEXTS
BUS2000165	PARNTER, TEXTS

Les niveaux en-tête et poste comportent toujours l'ensemble supérieur des sets et des extensions ; de cette façon, les sets et extensions ne sont copiés qu’une fois par le programme d'écriture même s'ils sont utilisés à plusieurs reprises. Les commandes client sont archivées via l’objet d’archivage CRM_SALDOC. Le diagramme ci-dessous illustre l'exemple fourni précédemment :

Voir aussi :

Pièces jointes et liens d’un flux de documents