Struktur einer Gebühr beschreiben

Als Preismanager ist es Ihre Aufgabe, eine Gebühr für die monatliche Vergütung für die Subskription für den Cloud Selection Service zu entwerfen.

Eine Gebühr stellt Kosten und ein Abrechnungsmuster dar, das mit einem oder mehreren Kundenservices verknüpft ist. Die Kosten werden in einem Berechnungsalgorithmus beschrieben und im Schema zur Preisberechnung in der Gebühr konfiguriert, während das Schema zur Kontenermittlung im Schema zur Kontenermittlung beschrieben wird. Die Gebühr ist das Objekt, das eine Ausgabetransaktion (als „bepreiste Position" bezeichnet) anlegt, die einem Kunden in Rechnung gestellt wird. Jede Gebühr kann maximal eine bepreiste Position anlegen.

Eine Gebühr:

• Berechnet einen Betrag, der mit keiner, einer oder mehreren Klassen zu bepreisender Positionen verknüpft werden kann.
• Enthält eine eindeutige Preisfindungslogik, die in einer Baumstruktur namens „Preisplan" beschrieben wird.
• Enthält auch einen dedizierten Satz von Charging-Regeln als strukturierter Baum „Schema zur Kontenermittlung".
• Generiert einen Betrag, der verwendet werden muss, um einen Kunden oder Partner entweder zu belasten oder zu entlasten.
• Legt keine bepreiste Position oder eine bepreiste Position an.
• Kann entweder vom Typ „Master" oder „Dependent" sein.

Eine Gebühr berechnet einen Betrag, der mit keiner, einer oder mehreren Klassen zu bepreisender Positionen verknüpft sein kann, und diese Gebühr enthält eine eindeutige Preisfindungslogik, die in einer Baumstruktur beschrieben wird, die als "Schema zur Preisberechnung" bezeichnet wird. Darüber hinaus enthält die Gebühr auch einen dedizierten Satz von Charging-Regeln, die als baumstrukturiertes „Schema zur Kontenermittlung" dargestellt werden. Außerdem generiert es einen Betrag, der verwendet werden muss, um einen Kunden oder Partner entweder zu be- oder zu entlasten, während es entweder keine bepreiste Position oder eine bepreiste Position anlegt. Schließlich kann eine Gebühr entweder als „Hauptgebühr" oder als „abhängige" Gebühr klassifiziert werden.

Ein Charging-Geschäftsszenario besteht aus zwei Phasen:

1. Rating-Prozess (auch dynamische Preisfindung genannt)
2. Charging-Prozess (Ermittlung des Rechnungsempfängers)

Wenn ein Endkunde beispielsweise einen nutzungsbasierten Service zur Monetarisierung in Anspruch nimmt, berechnet der Rating-Prozess dynamisch einen bepreisten Betrag, während der Charging-Prozess festlegt, welches Konto mit dem Betrag belastet wird.

Mit einer Gebühr können Sie dieses Charging-Geschäftsszenario über einen Entscheidungsbaum konfigurieren, der aus zwei Teilen besteht:

• Das Schema zur Preisberechnung, das die Schritte festlegt, die SAP Convergent Charging ausführen muss, um den zu belastenden Betrag zu ermitteln. Bei Bedarf können auch zusätzliche Informationen ermittelt werden.
• Das Schema zur Kontenermittlung enthält alle Schritte, die von SAP Convergent Charging ausgeführt werden müssen, um das externe Konto zu ermitteln, auf das der Betrag belastet wird.

Im rechten Bildbereich verfügt die Gebühr über eine Reihe von Registerkarten, die Zugriff auf mehrere Konfigurationseinstellungen gewähren. Beginnen Sie zuerst mit der Registerkarte „Definition".

Auf der Registerkarte Definition muss jede Gebühr einer von zwei Arten zugeordnet werden:

• Master
• Abhängig

Lassen Sie uns herausfinden, was diese Typen definieren.

Bei der Abrechnung von Services kann die dem Kunden in Rechnung gestellte Gebühr aus mehreren Komponenten bestehen. In SAP Convergent Charging wird jede Komponente in der Regel durch eine separate Gebühr berechnet:

Symbol	Erklärung
	Eine Grundgebühr für jede einzelne Servicenutzung
	Eine zeitbasierte Gebühr, die auf der Dauer der Nutzung basiert
	Ein Zuschlag, der für bestimmte bereitgestellte Prämienfunktionen angewendet wird.
	Ein Rabatt, der basierend auf bestimmten Umständen angewendet wird

Wenn SAP Convergent Charging eine zu bepreisende Position verarbeitet, muss es genau eine Gebühr identifizieren, die zuerst zur Verarbeitung der zu bepreisenden Position verwendet wird. Diese Gebühren werden als Hauptgebühren bezeichnet. In den oben genannten Beispielen könnte diese Gebühr für die Grundgebühr für jede Servicenutzung verantwortlich sein. Beim Anruf kann es sich um eine Verbindungsgebühr handeln, die berechnet wird, wenn eine Verbindung zu der angerufenen Person hergestellt wird.

Wenn diese Hauptgebühr mit ihren Berechnungen durchgeführt wird und zusätzliche Gebühren berechnet werden müssen, kann die zu bepreisende Position anschließend an zusätzliche Gebühren übergeben werden. Diese zusätzlichen Gebühren werden als abhängige Gebühren bezeichnet. Im obigen Beispiel könnte eine solche abhängige Gebühr die zeitabhängigen Gebühren für den Anruf berechnen.

Manchmal müssen Rabatte auf Gebühren angewendet werden. Häufig werden diese Gebühren als Prozentsatz aus einer Grundgebühr berechnet.

Im obigen Beispiel könnte ein Rabatt von 10 % auf die zeitabhängige Gebühr für das Telefonat gewährt werden. Der von den vorherigen Kosten berechnete Betrag wird immer an die abhängigen Kosten übergeben, sodass er dort für weitere Berechnungen verwendet werden kann.

Abhängigkeiten können in schneeflockenartigen Strukturen organisiert werden. Es gelten folgende Regeln:

• Eine abhängige Gebühr muss mit genau einer Gebühr verknüpft sein, von der sie abhängt.
• Abhängig davon können keine, eine oder mehrere Kosten auf eine Hauptgebühr oder eine abhängige Gebühr verweisen.
• Abhängigkeitsbeziehungen können kaskadiert werden. Es kann viele Abhängigkeitsebenen geben.

Lassen Sie uns zusammenfassen: Sie müssen Ihre Kosten auf den Typ Master setzen, wenn es die erste in der Gebührenzeile ist, die die zu bepreisenden Positionen verarbeitet. Wenn Ihre Kosten als eine der Folgekosten geplant sind, die von einer anderen Gebühr abhängen, die zuerst ihre Aufgabe ausführt, muss Ihre Gebühr der Art Abhängig zugeordnet werden. Es ist so einfach wie das. Beachten Sie, dass diese Einstellung nicht mehr geändert werden kann, sobald Ihre Kosten in der Datenbank gesichert wurden.

Wenn Sie eine Gebühr mit ihrer Berechnungslogik einrichten, können zwei Dinge passieren:

1. Sie planen, eine Gebühr für alle Währungen anzulegen, die Sie in abrechnen. In diesem Fall muss Ihre Gebühr in der Lage sein, mit jeder Währung umzugehen, die Sie darauf werfen.
2. Bei Ihrer Gebühr handelt es sich sicherlich um Gebühren, die nur mit einer bestimmten Währung verbunden sind.

SAP Convergent Charging ermöglicht die Zuordnung einer „festen Währung" zu einer Gebühr. Wenn Sie jedoch mehr Flexibilität benötigen, können Sie die Gebühr so einstellen, dass "Mehrfachwährung" unterstützt wird. Im letzteren Fall wird automatisch ein Parameter namens „Währung" für Sie angelegt. Sie können diesen Parameter dann verwenden, um die Gebührenwährung später festzulegen.

In SAP Convergent Charging ist die Wiederverwendung von Komponenten der Schlüssel zu einem Sounddesign. Sie möchten dieselbe Logik nicht wiederholt mit vielen Redundanzen erstellen. Dies würde den Wartungs- und Entwicklungsaufwand erhöhen und in der Folge die Kosten erhöhen. Um Ihre Gebührenlogiken flexibel zu halten, wurde das Konzept der Parameter eingeführt.

Ein Parameter dient als Platzhalter für einen Wert und ist für einen der drei Datentypen „Zahl", „Zeichenfolge" oder „Datum" vorgesehen. Er wird zu einem späteren Zeitpunkt mit einem Wert bereitgestellt, der von der Gebühr gelesen, aber nicht geändert werden kann. Darüber hinaus hat der Parameter eine Sichtbarkeitseinstellung, die sicherstellt, dass seine Sichtbarkeit nur auf die Logik des Schemas zur Preisberechnung beschränkt ist und nicht auf andere Objekte wie das Tarifschema erkennbar ist. Die primäre Funktion eines Parameters besteht darin, die Logik des Schemas zur Preisberechnung konfigurierbar zu machen und so die Flexibilität der Gebühren zu verbessern.

Die Werte für diese Parameter können zu späteren Zeitpunkten definiert werden. Dies kann der Fall sein, wenn die Gebühr in einem Tarifschema verwendet wird (später in diesem Kurs behandelt) oder wenn der Provider-Vertrag angelegt wird. Der Schlüsselaspekt besteht darin, dass für verschiedene Verträge oder verschiedene Tarifschemas der Gebührenparameter mit einem anderen Wert bereitgestellt werden kann. Auf diese Weise können Sie Ihre Kosten konfigurieren. Die Logik des Schemas zur Preisberechnung kann den Parameterwert lesen (aber nicht schreiben) und entsprechend handeln.

In der oben gezeigten Gebühr wurde der Parameter „SLA" eingeführt, um die Auswahl einer bestimmten Service-Level-Vereinbarung zu ermöglichen. Das Schema zur Preisberechnung der Gebühr kann dann diesen SLA-Parameterwert verwenden, um den korrekten Preis zu ermitteln, der für die Servicenutzung innerhalb des ausgewählten Service-Levels berechnet werden soll.

Den Parametern muss eine Sichtbarkeitseinstellung zugeordnet werden. Diese Einstellung kann entweder „Intern" oder „Extern" sein. Sie steuert, ob der Parameter von anderen Objekten wie dem Tarifschema (das später in diesem Kurs behandelt wird) oder nur vom Gebührenpreisschema „gesehen" werden kann.

Zähler sind da, um – vielleicht haben Sie es erraten – Dinge zu zählen. Preisberechnungsregeln enthalten häufig Schwellenwerte, Preisstufen oder ähnliche Komplexitäten. Wenn Ihre Logik Sie dazu zwingt, Mengen über einen bestimmten Zeitraum zu verfolgen, können Zähler verwendet werden.

Sehen wir uns eine Zählerdefinition an.

Zähler:

• Platzhalter für Werte, die sich zur Laufzeit ändern können.
• sind immer vom Typ Zahl.
• Habe einen Namen.
• Sie haben einen Wert, mit dem sie initialisiert werden.
• Kommen Sie in zwei Varianten: „Persistent" und „Transient".

Betrachten wir zunächst den Unterschied zwischen persistenten und transienten Zählern.

Transiente Zähler speichern ihre Werte nicht in der Datenbank von SAP Convergent Charging. Ihre Werte gehen verloren, wenn SAP Convergent Charging heruntergefahren und erneut gestartet wird. Sie gehen auch zwischen der Verarbeitung zweier separater zu bepreisender Positionen verloren, was noch wichtiger ist. In der Regel werden transiente Zähler verwendet, um Mengen innerhalb sogenannter Rating-Sitzungen zu verfolgen. Die sitzungsbasierte Bewertung wird in diesem Kurs nicht behandelt. Stellen Sie sich Sitzungen als Servicenutzung vor, die sich im Laufe der Zeit fortsetzt und für die Sie die Kosten berechnen möchten, wenn der Verbrauch stattfindet und fortgesetzt wird.

Oft kann die Nutzung einer Dienstleistung erst dann in Rechnung gestellt werden, wenn der Serviceverbrauch beendet ist und somit die Eigenschaften des Verbrauchs eindeutig sind. Wenn Sie den Service kontinuierlich in Rechnung stellen möchten, stellt dies eine Reihe von Herausforderungen dar.

Die obige Abbildung zeigt einen transienten Zähler innerhalb einer Ladung. Beachten Sie jedoch, dass der angezeigte Zähler als Beispiel zu einem der Übungsobjekte hinzugefügt wurde. Dies ist dort nicht sinnvoll, da in diesem Kurs keine sessionbasierte Bewertung behandelt wird.

Persistente Zähler speichern ihre Werte in der Datenbank von SAP Convergent Charging. Sie sind der häufigste Typ, der in Geschäftsszenarios verwendet wird, in denen die Servicenutzung periodisch gesammelt und abgerechnet wird.

Persistente Zähler sind aus Laufzeitsicht teuer. Jedes Mal, wenn der Zähler geschrieben wird, müssen die Daten an die Datenbank übergeben werden. Der Charging-Prozess muss warten, bis die Datenbank den Vorgang bestätigt, bevor die Gebühr mit der zu bepreisenden Nettoposition umgehen kann. Dies kann sich erheblich auf die Rating-Performance auswirken. Daher sollten Zähler mit Vorsicht und nur in Fällen verwendet werden, in denen sie erforderlich sind. Die folgende Grafik veranschaulicht die Performance-Auswirkungen, die Zähler auf den Rating-Durchsatz haben können.

Beim Einrichten von Zählern innerhalb eines Ansatzes hängt die zu erledigende Lokation von seiner Art ab. Während persistente Zähler eine eigene Registerkarte auf der Wurzelebene des Gebührenbaums haben, werden transiente Zähler eingerichtet, indem das Schema zur Preisberechnung in der Baumstruktur der Gebühr ausgewählt wird.

Wenn Sie in SAP Convergent Charging neue Katalogobjekte wie Gebühren, Tabellen, Makros usw. anlegen, benötigt das System eine Weile, um alle Systemkomponenten über diese neuen Objekte zu informieren. Ein Verteilungsmechanismus stellt sicher, dass von Zeit zu Zeit alle Komponenten eine Aktualisierung aller Objekte erhalten. Solange dieser Prozess nicht gestartet und erfolgreich abgeschlossen wurde, steht nicht allen Bewertern ein neuer Ansatz oder eine neue Tabelle zur Verfügung. Dies kann zu Fehlermeldungen führen, wenn die neuen Objekte von anderen neuen Objekten verwendet werden sollen.

Da Sie wahrscheinlich nicht warten möchten, bis der Verteilungsprozess abgeschlossen ist, können Sie den Prozess manuell anstoßen. Auf diese Weise können Sie sicherstellen, dass alle Objekte allen Systemkomponenten bekannt sind, bevor Sie Ihre neuen Objekte testen. Andernfalls erhalten Sie möglicherweise eine Fehlermeldung, da das Anlegen eines neuen Vertrags mit einer bestimmten Zuordnungstabelle fehlschlägt, wenn die Tabelle den beteiligten Ratern noch nicht bekannt ist. Machen Sie sich keine Sorgen, dass einige der genannten Begriffe Ihnen noch nicht bekannt sind. Dies wird im Verlauf des Kurses erläutert.

Um den Verteilungsmechanismus aus dem Core Tool heraus auszulösen, wählen Sie Werkzeuge→Rating-Instanzen aktualisieren.

Das System fordert Sie zur Bestätigung auf. Wenn Sie "Ja" wählen, erhalten Sie eine Meldung, die besagt, dass alle Bewertungsinstanzen aktualisiert wurden. Anschließend können Sie sicher davon ausgehen, dass Ihre neuen Objekte allen Systemkomponenten bekannt sind.