Der Typ bestimmt als Pflichtfeld statisch per Einfachauswahl den Nummerntyp der Attribute, deren Werte aufsummiert werden sollen.

Der Parameter Zielebene definiert über einen positiven oder negativen ganzzahligen Index die Hierarchieebene, für die Teilsummen berechnet werden sollen:

• Wert > 0: absolute Ebene; Anzahl der Stufen unterhalb der Kopfebene

• Wert < 0: relative Ebene; Anzahl der Stufen oberhalb der "tiefsten" Ebene (je Positionstyp)

• Wert = 0: "Kopfebene" des Bezugsobjekts (s. Hinweis unten)

Der Parameter Quellebene definiert definiert über einen positiven oder negativen ganzzahligen Index die Hierarchieebene, in der nach Einzelwerten für den Nummerntyp gesucht werden soll:

• Wert > 0: absolute Ebene; Anzahl der Stufen unterhalb der Kopfebene

• Wert < 0: relative Ebene; Anzahl der Stufen oberhalb der "tiefsten Ebene" (je Positionstyp)

• Wert = 0: "tiefste Ebene" (je Positionstyp)

Die Anzahl Dezimalstellen definiert ob und ggf. wie beim Aufsummieren gerundet wird:

• Wert = 0: keine Rundung

• Wert > 0: Anzahl der Nachkommastellen für die Rundung der Einzelwerte vor dem Summieren.

Relevante Positionstypen für die Berechnung können per Mehrfachauswahl qualifiziert werden.

►HINWEIS◄ In Lobster Data Platform / Orchestration begründet jeder Positionstyp eine eigenständige Positionshierarchie, so dass die Teilsummen immer nur Einzelwerte für denselben Positionstyp zusammenfassen. Sind mehrere Positionstypen als relevant ausgewählt, dann wird das gesamte Berechnungsverfahren der Ereignisbehandlung sequenziell für jeden relevanten Positionstyp wiederholt. Daher sind folgende Aspekte zu berücksichtigen:

• Sofern die Quellebene und/oder die Zielebene relativ zur "tiefsten Ebene" der Positionshierarchie definiert ist, wird die "tiefste Ebene" für jeden Positionstyp individuell ermittelt. Die Aggregation betrifft dann je Positionstyp individuelle Ebenen.

• Verweist die Zielebene relativ oder absolut auf die Kopfebene des Bezugsobjekts, dann verwendet jeder verarbeitete Positionstyp auf dieser Ebene dasselbe numerische Attribut für den ausgewählten Nummerntyp als Zielposition. Dieses wird immer wieder überschrieben und zeigt im Ergebnis nur die Teilsumme für den zuletzt verarbeiteten Positionstyp. Das ist in der Regel nicht erwünscht. Eine Gesamtsumme über unterschiedliche Positionstypen auf Kopfebene kann mit der Ereignisaktion auf diesem Weg nicht berechnet werden.

Innerhalb einer Ereignisbehandlung, die bei jedem "Speichern" eines Antrags, also über die Ereignisse "Erstellen" und "Ändern" (s. Allgemein (Ereignisse)) mit einer entsprechenden Typprüfung, ausgelöst wird, muss die Ereignisaktion Summiere numerisches Attribut zu diesem Zweck drei Mal konfiguriert werden.

• Jeder Schritt der Aggregation bezieht sich auf den Typ (Nummerntyp) "Kosten" (COSTS).
  
  

• Die Zielebene variiert, wobei die positiven Ganzzahlen als absolute Angabe der Zielebene interpretiert werden:
  
  

  • Der erste Schritt summiert die gerundeten "Kosten" aus der Ebene 3 in der unmittelbar übergeordneten Positionsebene (2).
    
    

  • Der zweite Schritt summiert die gerundeten "Kosten" aus der Ebene 3 in der obersten Positionsebene (1).
    
    

  • Der dritte Schritt summiert die gerundeten "Kosten" aus der Ebene 3 als Gesamtsumme im Kopf des Antrags.
    
    

• Die Quellebene ist immer die Ebene 3, mit den zu addierenden Einzelwerten.
  
  

• Für die Anzahl Dezimalstellen ist ebenfalls einheitlich der Wert 1 eingestellt.
  
  

• Unter Positionstypen ist einheitlich der verwendete Positionstyp "Service" (SERVICE) ausgewählt.

►ANMERKUNG◄ Die Berechnungsergebnisse werden von der Ereignisaktion in der jeweiligen Zielebene als Wert des "Kosten"-Attributs eingetragen, das dabei wie üblich auch neu angelegt wird, falls es noch nicht in den volatilen Daten des Bezugsobjekts existiert.

Das Beispiel rechts zeigt die Berechnungsergebnisse für einen konkreten Investitionsantrag mit sieben mit Kosten versehenen Positionen auf der Ebene 3.

Da die Eingabefelder für "Kosten" in den Ebenen 1 und 2 drei Dezimalstellen des berechneten Wert anzeigen, ist dort die Rundung auf eine Dezimale ablesbar.

►ANMERKUNG◄ Anhand der Werte im konkreten Beispiel zeigt sich der besondere Einfluss der Rundung der Einzelwerte vor dem Aufsummieren innerhalb der Position SER2.1:

• Die Einzelposten in den Unterpositionen werden beim Runden mit einer Dezimale aufgerundet (von 18,858 zu 18,9 T€ und 12,567 zu 12,6 T€), was für SER2.1 eine Teilsumme von 31,5 T€ ergibt.
  
  

• Ein Aufsummieren ohne Rundung ergäbe eine Teilsumme von 31,425 T€, was bei Rundung auf eine Dezimale nach der Addition 31,4 T€ ergäbe. Diese Bewertung der aggregierten Position könnte man angesichts der Einzelwerte als angemessener betrachten als den mit der Rundung der Einzelwerte ermittelten Wert von 31,5 T€. Allerdings ergäbe sich im Beispiel dann eine Differenz zwischen der Addition der ausgewiesenen Zwischenergebnisse für SER2.1 (in Höhe von 31,4 T€) und
  SER2.2 (in Höhe von 16,1 T€), die eine Summe von 47,5 T€ ergibt, und dem durch Rundung nach dem Aufsummieren aller Einzelwerte ermittelten Wert für die Position SER2 (in Höhe von 47,6 T€).
  
  

• Die Rundung vor der Addition stellt also sicher, dass das Aufsummieren über mehrere Stufen ein konsistentes Zahlenwerk ergibt. Und zwar unabhängig davon, ob das Aufsummieren durchgängig stufenweise erfolgt oder - wie im Beispiel - auch teilweise über mehrere Stufen hinweg.

►ANMERKUNG◄ Über die Buttons "1", "2" und "3" im Kopfbereich der für das Beispiel erstellten Erfassungsmaske kann der Detaillierungsgrad der Darstellung ausgewählt werden.

Im Screenshot rechts wurden per Klick auf den Button "2" die Unterpositionsebene 3 ausgeblendet, so dass nur noch die aggregierten Zahlen (deaktiviert) zu sehen sind.