Ansicht
Dokumentation

CL_HRPIQ00COHORTS_GENERAL - Klasse mit statischen Methoden für Kohorten

CL_HRPIQ00COHORTS_GENERAL - Klasse mit statischen Methoden für Kohorten

Vendor Master (General Section)   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Die Klasse CL_HRPIQ00COHORTS_GENERAL enthält die beiden zentralen Schnittstellen (Interfaces) zum Backend des Kohorten-Builders:

Über diese Interfaces steuert das System alle zentralen Funktionen des Kohorten-Builders, auch unabhängig von der Transaktion PIQCOH00.

Beziehungen

Die Klasse stellt Verbindungen zu Instanzen folgender Klassen her:

  • CL_HRPIQ00COHORT_MAIN
  • CL_HRPIQ00COHORT_A519
  • CL_HRPIQ00COHORT_STUD
  • CL_HRPIQ00COHORT_CONX
  • CL_HRPIQ00COHORT_OBIT
  • CL_HRPIQ00COHORT_OBJC
  • CL_HRPIQ00COHORT_ITEM

Alle Methoden und Attribute der oben genannten Klassen dürfen nicht von kundeneigenen Funktionen direkt aufgerufen werden, sondern nur über die Interfaces der Klasse CL_HRPIQ00COHORT_GENERAL. Ansonsten können Datenschiefstände die Folge sein.

Beispiel

Hinweise

Beachten Sie bei der Verwendung der Kohortenschnittstelle, dass Kohorten die folgenden Eigenschaften besitzen:

  • Kohorten haben immer einen oder mehrere Kontexte. Kontexte legen fest, für welche Anwendungen eine bestimmte Kohorte vorgesehen ist.
  • Kohorten haben folgende Attribute:
  • Kapazität

  • Kategorie

  • Organisatorische Einheit

  • Studiengang

  • Studiengangsart

  • Angebotsperioden

  • Kohorten besitzen Kontextobjekte. Die Kontextobjekte sind kontextabhängig. Die Customizingtabellen T7PIQCOH_CTXOBJ und T7PIQCOH_CTXITEM definieren, für welche Kontexte welche Kontextobjekttypen möglich sind.
  • Jeder Kohorte kann eine Menge von Studenten zugeordnet sein. Diese Menge ist im allgemeinen kontextunabhängig. Eine Ausnahme bilden so genannte geerbte Studenten (siehe nachfolgende Erläuterung).
  • Kohorten können Teilkohorten besitzen. Alle Studenten einer Teilkohorte gehören auch zu der übergeordneten Kohorte, welche Hauptkohorte genannt wird, sofern Haupt- und Teilkohorte für denselben Kontext vorliegen. Studenten, die einer Kohorte nur dadurch zugeordnet sind, dass sie zu einer ihrer Teilkohorten gehören, sind geerbte Studenten. Eine Hauptkohorte kann über die geerbten Studenten hinaus zusätzliche Studenten besitzen.
  • Eine Kohorte vererbt auch die Kontextobjekte eines Kontextes an ihre Teilkohorten, d.h. alle Kontextobjekte einer Hauptkohorte gehören auch zu allen ihren Teilkohorten. Jede Teilkohorte kann darüber hinaus eigene spezifische Kontextobjekte besitzen. (Im Unterschied zur Vererbung von Studenten von der Teilkohorte auf die Hauptkohorte vollzieht sich die Vererbung von Kontextobjekten gerade umgekehrt von der Hauptkohorte auf die Teilkohorten.)
  • Zu einer Kohorte können sowohl mehrere Teil- als auch mehrere Hauptkohorten gehören.
  • Mehr als 66 Kohortenebenen sind innerhalb einer Hierarchie nicht möglich.
  • Die Vererbung von Studenten und Kontextobjekten zwischen den Hierarchieebenen werden nur zur Laufzeit vorgenommen. Auf der Datenbank und in den Infotypen sind die Vererbungen nicht zu erkennen. Deshalb dürfen Veränderungen an der Zusammensetzung von Kohorten nur über die Transaktion PIQCOH00 oder über die Schnittstellen der Klasse CL_HRPIQ00COHORTS_GENERAL vorgenommen werden.
    Beachten Sie, dass alle anderen Änderungen von Kohortendaten unweigerlich zu Datenschiefständen führen.
  • Dem Kohorten-Builder liegt ein besonderes Zeitkonzept zugrunde. Dieses Zeitkonzept verlangt stets die Angabe eines Stichtags, wenn Kohorten bearbeitet werden. Alle Änderungen, die an einer Kohorte vorgenommen werden, gelten generell vom Stichtag an bis zum Ende der Kohortengültigkeit. Beachten Sie insbesondere folgende Hinweise:
  • Wenn Sie einen Stichtag in der Vergangenheit wählen und zu diesem Stichtag die Kohorte ändern, kann eine Überschreibung vorhandener aktueller Daten die Folge sein.

  • Ähnliches gilt, wenn Sie einen Stichtag in der Zukunft wählen. Dann besteht die Gefahr, dass ein anderer berechtigter Benutzer diese für die Zukunft gültigen Daten durch Änderung der Kohortendaten zum aktuellen Stichtag wieder überschreibt.

  • Bei konsequenter Nutzung des aktuellen Tagesdatums als Stichtag bestehen diese Gefahren nicht.

Weiterführende Informationen






ROGBILLS - Synchronize billing plans   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 6074 Date: 20240329 Time: 164857     sap01-206 ( 93 ms )