Description de la structure d'un frais

En tant que responsable de la tarification, vous devez définir des frais mensuels pour la tarification de l'abonnement au Service de sélection Cloud.

Les frais représentent un coût et un modèle de facturation liés à un ou plusieurs services client. Le coût est décrit dans un algorithme de calcul et configuré dans le plan tarifaire dans les frais, tandis que le modèle de recharge est décrit dans le plan de recharge. Les frais sont l'objet qui crée une transaction de sortie (appelée « élément imputé ») qui est facturée à un client. Tous les frais peuvent créer un élément imputé au maximum.

Frais :

• Calcule un montant qui peut être lié à aucune, une ou plusieurs classes d'éléments de tarification.
• Contient une logique de détermination du prix unique décrite dans une arborescence appelée « planification des prix ».
• Contient également un ensemble dédié de règles de recharge sous forme d'arborescence structurée "plan de recharge".
• Génère un montant qui doit être utilisé pour débiter ou créditer un client ou un partenaire.
• Ne crée aucun élément imputé ou un seul élément imputé.
• Il peut s'agir de frais de type "maître" ou "dépendant".

Les frais calculent un montant qui peut être lié à aucune, une ou plusieurs classes d'éléments de tarification et ces frais contiennent une logique de détermination du prix unique décrite dans une arborescence appelée "planification des prix". En outre, la charge contient également un ensemble dédié de règles de recharge représentées sous la forme d'un "plan de recharge" structuré en arborescence. Il génère également un montant qui doit être utilisé pour débiter ou créditer un client ou un partenaire, tandis qu'il ne crée aucun élément imputé ou un seul élément imputé. Enfin, une charge peut être classée comme une charge de type "maître" ou "dépendante".

Un scénario de gestion d'imputation se compose de deux étapes :

1. Processus d'évaluation (détermination dynamique du prix)
2. Processus d'imputation (détermination du destinataire de la facture)

Par exemple, lorsqu'un client final utilise un service basé sur l'utilisation pour monétiser, le processus de tarification calcule dynamiquement un montant évalué tandis que le processus d'imputation définit le compte qui sera facturé avec le montant.

Les frais vous permettent de configurer ce scénario de gestion d'imputation via un arbre de décision composé de deux parties :

• La planification des prix qui indique les étapes à exécuter par SAP Convergent Charging pour déterminer le montant à facturer. Des informations supplémentaires peuvent également être déterminées si nécessaire.
• Le plan de recharge contient toutes les étapes à exécuter par SAP Convergent Charging pour déterminer le compte externe auquel le montant est facturé.

À droite de l'écran, les frais comportent un ensemble d'onglets qui donnent accès à plusieurs options de configuration. Commençons d'abord par l'onglet Définition.

Dans l'onglet Définition, chaque dépense doit être affectée à l'un des deux types suivants :

• Principal
• Personne à charge

Voyons ce que ces types définissent.

Lors de la facturation des services, les frais facturés au client peuvent être constitués de plusieurs composants. Dans SAP Convergent Charging, chaque composant est généralement calculé par des frais distincts :

Icône	Explication
	Une redevance de base associée à chaque utilisation de service individuelle
	Frais basés sur le temps basés sur la durée de l'utilisation
	Une majoration appliquée pour certaines fonctions de prime fournies
	Escompte appliqué en fonction de certaines circonstances

Lorsque SAP Convergent Charging traite un élément de tarification, il doit identifier exactement un frais, qui est utilisé pour traiter l'élément de tarification en premier. Ces charges sont appelées « charges principales ». Dans les exemples ci-dessus, ces frais peuvent être responsables des frais de base associés à chaque utilisation de service. Lors d'un appel téléphonique, il peut s'agir de frais de connexion, qui sont facturés lorsqu'une connexion est établie à la personne qui a été appelée.

Si ces frais principaux sont effectués avec leurs calculs et que des frais supplémentaires doivent être calculés, l'élément de tarification peut ensuite être transféré à des frais supplémentaires. Ces frais supplémentaires sont appelés « frais dépendants ». Dans l'exemple ci-dessus, ces frais dépendants pourraient calculer les frais basés sur le temps pour l'appel.

Parfois, des escomptes doivent être appliqués aux frais. Ces frais sont souvent calculés sous forme de pourcentage à partir de frais de base.

Dans l'exemple ci-dessus, une remise de 10 % pourrait être accordée aux frais basés sur le temps pour l'appel téléphonique. Le montant calculé par les frais précédents est toujours transféré aux frais dépendants afin qu'ils puissent y être utilisés pour d'autres calculs.

Les dépendances peuvent être organisées dans des structures semblables à des flocons de neige. Les règles suivantes s'appliquent :

• Des frais dépendants doivent être liés à exactement un frais dont ils dépendent.
• Les frais principaux ou dépendants peuvent être référencés par aucun, un ou plusieurs frais en fonction de ceux-ci.
• Les relations de dépendance peuvent être transportées en cascade. Il peut y avoir de nombreux niveaux de dépendances.

Récapitulons : vous devez définir vos frais sur le type Principal lorsqu'il s'agit du premier de la ligne de frais pour traiter les éléments de tarification. Lorsque vos frais sont planifiés pour être l'un des frais ultérieurs, ce qui dépend du fait qu'un autre frais effectue son travail en premier, vos frais doivent être affectés au type Dépendant. C'est aussi simple que cela. Notez que cette option ne peut pas être modifiée une fois que vos frais sont sauvegardés dans la base de données.

Lorsque vous configurez des frais avec leur logique de calcul, deux choses peuvent se produire :

1. Vous prévoyez de créer des frais uniques pour toutes les devises dans lesquelles vous facturez. Dans ce cas, votre charge doit être en mesure de traiter n'importe quelle devise que vous lui jetez.
2. Vos frais seront certainement liés à des frais associés à une seule devise spécifique.

SAP Convergent Charging permet d'affecter une « devise fixe » à des frais. Cependant, si vous avez besoin de plus de flexibilité, vous pouvez définir les frais pour prendre en charge "Plusieurs devises". Dans ce dernier cas, un paramètre appelé "devise" sera créé automatiquement pour vous. Vous pouvez ensuite utiliser ce paramètre pour définir ultérieurement la devise des frais.

Dans SAP Convergent Charging, la réutilisation des composants est la clé d'une conception sonore. Vous ne voulez pas créer la même logique avec beaucoup de redondances à plusieurs reprises. Cela augmenterait les efforts de maintenance et de développement et, par la suite, augmenterait les coûts. Pour que vos logiques de frais restent flexibles, le concept de paramètres a été introduit.

Un paramètre sert de caractère générique pour une valeur et est désigné pour l'un des trois types de données : nombre, chaîne ou date. Il sera fourni avec une valeur à un stade ultérieur, une valeur qui peut être lue par la charge mais qui ne peut pas être modifiée par elle. En outre, le paramètre a une option de visibilité qui garantit que sa visibilité est limitée uniquement à la logique du plan tarifaire et qu'il n'est pas discernable pour d'autres objets tels que le plan de charges. La fonction principale d'un paramètre est de permettre à la logique de planification des prix d'être configurable, ce qui améliore la flexibilité des frais.

Les valeurs de ces paramètres peuvent être définies ultérieurement. Cela peut être lorsque les frais sont utilisés dans un plan de charges (couvert ultérieurement dans ce cours) ou lorsque le contrat de fournisseur est créé. L'aspect clé est que pour différents contrats ou plans de charges, le paramètre de frais peut être fourni avec une valeur différente. Cela permet de configurer votre identifiant d'instance. La logique de planification des prix peut lire (mais pas écrire) la valeur du paramètre et agir en conséquence.

Dans les frais indiqués ci-dessus, un paramètre "SLA" a été introduit pour permettre la sélection d'un accord sur le niveau de service spécifique. La planification des prix des frais peut ensuite utiliser cette valeur de paramètre SLA pour déterminer le prix correct à facturer pour l'utilisation du service dans le niveau de service sélectionné.

Une option de visibilité doit être affectée aux paramètres. Cette option peut être "Interne" ou "Externe". Il détermine si le paramètre peut être "vu" par d'autres objets tels que le plan de charges (couvert ultérieurement dans ce cours) ou uniquement par le plan de prix des frais.

Les compteurs sont là pour – vous l’avez peut-être deviné – compter les choses. Les règles de calcul du prix contiennent souvent des seuils, des tranches de prix ou des complexités similaires. Lorsque votre logique vous oblige à suivre les quantités sur une période donnée, des compteurs peuvent être utilisés.

Examinons une définition de compteurs.

Compteurs :

• Il s'agit de caractères génériques pour les valeurs qui peuvent changer au moment de l'exécution.
• Sont toujours de type nombre.
• Avoir un nom.
• Avoir une valeur avec laquelle ils sont initialisés.
• Venez en deux saveurs : « Persistant » et « Transient ».

Examinons d'abord la différence entre les compteurs persistants et transitoires.

Les compteurs transitoires ne stockent pas leurs valeurs dans la base de données de SAP Convergent Charging. Leurs valeurs seront perdues lorsque SAP Convergent Charging sera arrêté et relancé. Elles sont également perdues entre le traitement de deux éléments de tarification distincts, ce qui est encore plus important. En règle générale, les compteurs transitoires sont utilisés pour suivre les quantités dans des « sessions d'évaluation ». L'évaluation basée sur la session n'est pas abordée dans ce cours. Considérez les sessions comme une utilisation de service, qui se poursuit au fil du temps, pour lesquelles vous souhaitez facturer au fur et à mesure que la consommation se produit et se poursuit.

Souvent, l'utilisation d'un service ne peut être facturée qu'une fois la consommation du service terminée et les propriétés de la consommation sont donc claires. Lorsque vous souhaitez facturer au fur et à mesure que le service est continuellement consommé, cela entraîne un ensemble de défis.

La figure ci-dessus montre un compteur transitoire dans une charge. Notez cependant que le compteur affiché a été ajouté à l'un des objets de l'exercice à titre d'exemple. Cela n’a aucun sens dans ce cours, car aucune notation basée sur la session n’est traitée dans ce cours.

Les compteurs persistants stockent leurs valeurs dans la base de données de SAP Convergent Charging. Il s'agit du type le plus courant à utiliser dans les scénarios de gestion où l'utilisation du service est collectée et facturée périodiquement.

Les compteurs persistants sont coûteux du point de vue de l'exécution. Chaque fois que le compteur est écrit, les données doivent être transmises à la base de données. Le processus de recharge doit attendre que la base de données confirme l'opération pour que la charge puisse traiter l'élément de tarification net. Cela peut avoir un impact significatif sur la performance de l'évaluation. Par conséquent, les compteurs doivent être utilisés avec précaution et uniquement dans les cas où ils sont nécessaires. Le graphique suivant illustre l'impact que les compteurs d'impact sur la performance peuvent avoir sur le débit de notation.

Lors de la configuration de compteurs dans un identifiant d'instance, l'emplacement à faire dépend de son type. Alors que les compteurs persistants ont leur propre onglet au niveau racine de l'arborescence des frais, les compteurs transitoires sont configurés en sélectionnant la planification des prix dans l'arborescence des frais.

Lorsque vous créez de nouveaux objets de catalogue dans SAP Convergent Charging comme des frais, des tables, des macros, etc., le système prend un certain temps pour informer toutes les composantes du système de ces nouveaux objets. Un mécanisme de répartition permet de s'assurer que, de temps à autre, tous les composants reçoivent une mise à jour de tous les objets. Tant que ce processus n'est pas lancé et terminé avec succès, un nouvel identifiant d'instance ou une nouvelle table ne sera pas disponible pour tous les évaluateurs. Cela peut entraîner des messages d'erreur lorsque les nouveaux objets doivent être utilisés par d'autres nouveaux objets.

Comme vous ne voulez probablement pas attendre la fin du processus de répartition, il est possible de déclencher le processus manuellement. De cette façon, vous pouvez vous assurer que tous les objets sont bien connus par tous les composants du système avant de tester vos nouveaux objets. Sinon, vous risquez de recevoir un message d'erreur car la création d'un nouveau contrat à l'aide d'une table de mappage donnée échouera si la table n'est pas encore connue des évaluateurs concernés. Ne vous inquiétez pas que certains des termes mentionnés ne vous soient pas encore connus. Ceci est expliqué dans le cours.

Pour déclencher le mécanisme de répartition à partir de Core Tool, sélectionnez Outils→Rafraîchir instances d'évaluation.

Le système vous demandera une confirmation. Sélectionnez « Oui » et vous recevrez un message indiquant que toutes les instances d’évaluation ont été actualisées. Après cela, vous pouvez supposer en toute sécurité que vos nouveaux objets sont connus par tous les composants du système.