Pour créer votre entreprise, il est nécessaire de modéliser les allocations en créant les données de base suivantes :
- Interface d'allocation
- L'interface d'allocation contient la liste des compteurs et des paramètres disponibles pour chaque allocation.
- Classes d'événements d'allocation
- Cette classe décrit les données qui peuvent être envoyées d'une dépense aux allocations d'un contrat et inversement.
- Logique d'allocation
- La logique d'allocation décrit la logique de calcul exécutée lorsqu'un événement d'allocation est traité, lorsqu'une allocation est activée, lorsqu'elle expire, etc. Il associe également ces logiques à des classes d'événements d'allocation, tout comme les taux d'utilisation des frais font référence à une certaine classe d'éléments de tarification pour laquelle ils sont sensibles.
- Plans d'allocation
- Les plans d'allocation forment le plan de construction d'une allocation. Ils font généralement référence à une ou plusieurs logiques d'allocation. La combinaison de ces logiques d'allocation définit le comportement de l'allocation lorsqu'elle est créée en fonction du plan d'allocation.
Dans les paragraphes suivants, nous passerons en revue chacun de ces types d'objet et examinerons son objectif, la manière dont il est défini, ainsi que les options et les flexibilités qu'il fournit.
Classe d'événements d'allocation
La classe d'événements d'allocation est une structure stockée dans le catalogue qui est similaire à une classe d'éléments de tarification. Il représente le format des messages qui peuvent être envoyés d'une dépense à un ensemble d'allocations. Un tel message est appelé "Événement d'allocation". La classe d'événements d'allocation est composée d'un nom unique, d'une description facultative et d'un ensemble de champs dans lesquels le message peut contenir des informations. Chaque zone est affectée à l'un des trois types de données suivants :
- Chaîne
- Numéro
- Date
L'image suivante montre la définition d'une classe d'événements d'allocation.
Normalement, ces zones sont utilisées pour déclarer une consommation de service à l'allocation qui doit être décomptée par rapport au solde.
Une différence importante entre les éléments de tarification et les événements d'allocation réside dans le fait que les valeurs de zone d'un événement d'allocation sont modifiables par l'allocation qui les traite. Lorsque la zone CONSUMED_AMOUNT contient le montant en numéraire de l'utilisation de service qui doit être décompté par les allocations, l'allocation ne peut décompter qu'une partie de ce montant consommé et laisser le reliquat à décompter par les allocations suivantes. Pour indiquer le montant restant à décompter, il peut mettre à jour la valeur de la zone "CONSUMED_AMOUNT" avec le montant qu'il n'a pas pu imputer avec son propre solde. L'événement d'allocation reporte ensuite la valeur modifiée à l'allocation suivante, qui peut à son tour lire la valeur, régler ce qu'elle peut et modifier la valeur du champ si nécessaire jusqu'à ce que la valeur du champ atteigne 0 ou qu'aucune autre allocation ne soit disponible pour traiter une utilisation ultérieure. Lorsqu'aucune autre allocation n'est disponible pour traiter l'événement, le message est renvoyé aux frais d'appel, qui a accès à toutes les valeurs de zone mises à jour.
Comme vous l'avez peut-être remarqué, la classe d'événements d'allocation ne contient pas de propriétés par défaut. Elles ne sont pas nécessaires car les événements d'allocation sont envoyés par les dépenses. À ce stade du processus de notation, le contrat et les frais ont déjà été identifiés.
Vous pouvez créer des classes d'événements d'allocation dans Core Tool en sélectionnant Fichier→Nouveau→Classe d'événements d'allocation.
Les événements d'allocation peuvent être envoyés à l'aide du composant d'opérateur appelé Expéditeur d'événement d'allocation. Dans la composante, vous devez sélectionner la classe d'événements d'allocation que vous voulez utiliser pour le message. Dans l'onglet Définition du composant, vous devez ensuite mapper les propriétés de votre contexte d'évaluation aux propriétés définies dans la classe d'événements d'allocation. Pour chaque propriété de la classe d'événements d'allocation, vous pouvez définir le nom d'une propriété qui contiendra la valeur mise à jour après le traitement de l'événement d'allocation. Dans l'exemple ci-dessous, la zone d'événement d'allocation CONSUMED_AMOUNT est fournie avec la valeur du montant de base des frais tandis que la zone REMAINING_AMOUNT contient tout montant qui n'a pas été décompté par les allocations.
Logique d'allocation
Dans SAP Convergent Charging, la logique d'allocation est un objet réutilisable qui appartient aux données de base d'un catalogue. Ils sont composés d'un nom unique, d'une description et similaires aux charges, peuvent contenir des paramètres et des compteurs transitoires ou persistants.
Les logiques de calcul sont définies comme des arborescences. Comme pour les planifications des prix des frais, les arborescences de la logique d'allocation peuvent être divisées en trois parties logiques :
- Niveau de déclenchement
Le composant déclencheur est la racine de chaque arborescence. Ici, le type d'événement déclencheur est défini, qui peut être basé sur un événement, récurrent ou ponctuel.
- Niveau algorithmique
À ce niveau, les logiques de calcul sont localisées. Plusieurs composants logiques sont combinés pour former une logique de calcul exécutée dans l'allocation. Chaque composante logique est affectée à l'une des deux catégories (les séparateurs ne sont pas pris en charge ici !):
- Comparateurs
- Opérateurs
- Niveau de fonction
Les fonctions sont les feuilles de votre logique d'arborescence de calcul. Un composant de fonction définit si un événement d'utilisation est autorisé à passer ou non (où ce dernier crée un message d'erreur) et si un élément imputé est censé être généré pour un événement d'allocation de passage. Lors du transfert d'un événement d'allocation, l'allocation laisse l'événement passer à l'allocation suivante après l'avoir traitée comme défini jusqu'à présent par la logique d'arborescence.
Niveau de déclenchement
Chaque logique d'arborescence commence par un "déclencheur" (similaire à un composant de "taux" dans les frais). Il existe trois types de déclencheurs différents disponibles pour les logiques d'allocation :
- Déclencheur basé sur les événements
- Déclencheur récurrent
- Déclencheur d'un tir
- Déclencheur basé sur les événements
Le déclencheur basé sur un événement permet le traitement des événements d'allocation d'une classe d'événements d'allocation donnée. La seule option attendue pour ce composant est une référence à une classe d'événements d'allocation existante. Le déclencheur basé sur un événement est exécuté uniquement lorsqu'il reçoit un événement d'allocation de ce type. La logique d'arborescence sous un composant de déclencheur basé sur un événement a accès à toutes les valeurs de propriété définies dans la classe d'événements d'allocation référencée.
- Déclencheur récurrent
Le déclencheur récurrent est similaire au tarif récurrent dans la planification des prix d'un frais. Sa configuration définit un modèle récurrent. La logique d'arborescence sous le déclencheur récurrent est exécutée selon ce modèle. La manière dont la configuration d'un modèle récurrent suit les mêmes règles et structures que la configuration des tarifs récurrents dans les planifications des prix. La configuration de déclencheurs récurrents ne prend cependant pas en charge la proratisation.
- Déclencheur d'un tir
Les déclencheurs en une seule fois permettent l'exécution de la logique de l'arborescence à la création, l'activation ou l'expiration d'une allocation. De cette façon, le solde des allocations peut être créé, des messages sur l'état de préparation des allocations peuvent être envoyés ou les soldes restants peuvent être épuisés et signalés à SAP Convergent Invoicing pour être comptabilisés comme produit.
Niveau algorithmique
La partie centrale d'une logique d'arborescence définit la logique de calcul. Vous pouvez combiner librement des composants de comparateur et d'opérateur pour implémenter une logique qui répond à vos besoins. Par exemple, une telle logique peut être de comparer le solde dans l'allocation et, s'il reste du solde, d'en déduire autant que nécessaire, ou éventuellement de régler l'utilisation déclarée dans l'événement d'allocation. Une fois l'opération terminée, la propriété d'événement d'allocation est mise à jour avec le solde restant à imputer.
Les composants d'opérateur et de comparateur les plus importants qui peuvent être utilisés ont déjà été introduits dans le cours. Cependant, les allocations prennent en charge un ensemble de composants spéciaux qui sont disponibles uniquement dans le contexte de la logique d'allocation. Ces composants sont les suivants :
- Émetteur de l'événement d'allocation
- Mise à jour de l'événement d'allocation
- Introducteur de propriété d'allocation
- Mise à jour de la période de validité de l'allocation
- Émetteur de l'événement d'allocation
L'expéditeur de l'événement d'allocation a déjà été introduit lors du traitement des classes d'événements d'allocation. Bien que les événements d'allocation soient généralement envoyés par des dépenses, ils peuvent également être envoyés par des allocations.
- Mise à jour de l'événement d'allocation
Le composant de mise à jour de l'événement d'allocation peut être utilisé pour mettre à jour la valeur du champ de l'événement d'allocation qui est traité. Dans l'exemple donné ci-dessous, le composant de mise à jour d'événement d'allocation est utilisé pour définir la valeur de zone de la propriété d'événement d'allocation CONSUMED_AMOUNT sur 0 et définir la valeur de zone de la propriété d'événement d'allocation PROCESSED sur TRUE. Les propriétés d'événement d'allocation restantes sont mappées sur leurs valeurs réelles, afin qu'elles restent inchangées.
Le composant de mise à jour de l'événement d'allocation est disponible uniquement en tant que sous-composants des déclencheurs basés sur les événements.
- Introducteur de propriété d'allocation
Le composant introducteur de propriété d'allocation vous permet de sélectionner un certain groupe d'allocations en fonction d'un ensemble de critères de sélection, puis d'appliquer des évaluations mathématiques de base à ces allocations et à leurs propriétés.
Prenons un exemple :
Le département des ventes de l'entreprise O2C vendant le service de sélection cloud a une idée : tous les clients avec des contrats associés à un solde d'allocation total d'au moins 100,- € valable pendant au moins un mois de plus doivent recevoir un message les informant des dernières offres de service pour favoriser l'utilisation du service. Cela signifie que pour chaque contrat, l'allocation avec une validité d'au moins quatre semaines supplémentaires doit être sélectionnée et les soldes de toutes les allocations correspondantes doivent être additionnés. C'est ce qu'un composant introducteur de propriété d'allocation peut effectuer en une seule étape d'arborescence.
La configuration du composant nécessite trois étapes :
- Définissez le périmètre de sélection.
- Définissez les critères de sélection.
- Définissez les calculs à effectuer.
La première étape consiste à définir le périmètre à partir duquel les allocations doivent être sélectionnées. Les options sont les suivantes :
- Toutes les indemnités du contrat donné.
- Toutes les allocations du contrat donné et toutes les allocations de son contrat parent.
- Seules les allocations partagées avec un ID de partage spécifique.
Nous n'avons pas encore traité les allocations partagées, alors ne vous confondez pas avec la troisième option.
Lorsque vous avez sélectionné le périmètre, vous pouvez (mais vous n'avez pas besoin) de fournir un ensemble de critères de sélection pour sélectionner uniquement un sous-ensemble d'allocations correspondant à certaines conditions. Selon le type de données de la propriété utilisée comme critère de sélection, différents opérateurs sont disponibles :
Opérateurs
Type de données Opérateurs disponibles Date Est égal à
Avant
Avant ou égal à
Après
Après ou égal à
Numéro Est égal à
Supérieur à
Supérieur ou égal à
Inférieur à
Inférieur ou égal à
Différent de
Chaîne Est égal à
Commence par
Se termine par
Contient
Par défaut, le composant compte le nombre d'allocations dans l'ensemble de résultats sélectionné. Vous devez définir un nom de propriété dans lequel le composant stocke ce nombre.
En outre, vous pouvez définir un ensemble d'opérations mathématiques à exécuter sur les propriétés des allocations dans l'ensemble de résultats. Les opérations prises en charge dépendent du type de données de la propriété :
Types de données
Type de données Opérateurs disponibles Date Le plus grand
Le plus bas
Numéro Le plus grand
Le plus bas
Total
À l'aide de ces opérateurs, vous pouvez, par exemple, sélectionner une propriété numérique "BALANCE" et laisser l'élément calculer la somme de cette propriété dans toutes les allocations de l'ensemble de résultats.
Notez cependant que les propriétés utilisées comme critères de sélection et comme propriétés générées doivent faire partie de l'interface d'allocation, ce qui peut être un inconvénient important. Comme l'interface d'allocation n'était pas encore couverte, gardez ce fait à l'esprit.
- Mise à jour de la période de validité de l'allocation
La mise à jour de la période de validité de l'allocation vous permet de modifier la date de début de validité et/ou la date de fin de validité d'une allocation. La date qui peut être modifiée dépend de l'état de l'allocation et du composant de déclenchement dans lequel se trouve le composant de mise à jour. Le tableau suivant indique quels composants et configurations de déclencheur autorisent quelles modifications.
Combinaison entre composant déclencheur, configuration et modification autorisée
Composant déclencheur Date de début de validité Date de fin de validité Déclencheur basé sur un événement Mise à jour impossible Modifiable Déclencheur récurrent Mise à jour impossible Modifiable Déclencheur unique (création) Modifiable Mise à jour impossible Déclencheur unique (activation) Mise à jour impossible Modifiable Déclencheur unique (expiration) Mise à jour impossible Mise à jour impossible Il peut s'agir, par exemple, d'une société qui associe une certaine validité à un solde d'allocation acheté. Les opérations de rechargement sur les soldes existants et valides prolongent la validité de ces soldes, ce qui incite à acheter plus d'équilibre. La prolongation de la période de validité peut même augmenter en fonction du montant avec lequel les allocations sont rechargées.
Niveau de fonction
Comme indiqué, le dernier composant de chaque arbre de logique d'allocation est une fonction. Les fonctions servent exactement deux objectifs :
- Ils indiquent si l'événement d'allocation traité jusqu'à présent est transféré à l'allocation suivante (le cas échéant) ou si un message d'erreur est généré à la place, car la logique d'allocation a atteint un statut erroné.
- Ils indiquent si un élément imputé est créé par la logique d'allocation en fonction des sorties de calcul qui ont été exécutées jusqu'à présent.
À cette fin, les fonctions suivantes sont disponibles dans les logiques d'allocation :
- Autoriser
- Aucun accès
- Autoriser
La fonction Autoriser permet de transmettre l'événement d'allocation à l'allocation suivante, le cas échéant, ou de le renvoyer aux frais d'appel.
La seule option qu'il fournit est de décider si un élément imputé doit être créé (la case Générer élément imputé est cochée) ou non (case décochée).
- Aucun accès
La fonction Aucun accès a la même fonction que dans les frais : elle interrompt le processus de valorisation, annule toutes les mises à jour du compteur effectuées jusqu'à présent pendant le processus et renvoie un message d'erreur avec un ensemble de noms de propriétés de contexte d'évaluation et leurs valeurs d'exécution actuelles qui peuvent être sélectionnées par l'utilisateur au moment de la conception.
