Siehe Einführung und Glossar.

Analog der Kreditpunktebuchhaltung für den Leistungsausweis sollen die Kreditpunkte für die SGR ebenfalls in einem buchungsbasierten System verwaltet werden können.

• Die Kreditpunktebuchhaltungen für den Leistungsausweis und für die SGR sind strikte voneinander getrennt.
• In jede Kreditpunktebuchhaltung wird separat gebucht. Es gibt keine "systemübergreifenden" Buchungssätze.
• Bei Geschäftsprozessen resp. Arbeitsschritten, welche Aktionen mit Kreditpunkten aus beiden Kontexten involvieren, wird doppelt gebucht: Einmal in die Leistungsausweis-Buchhaltung, einmal in die SGR-Buchhaltung.
• Die beiden Systeme sind komplett unabhängig voneinander. Buchungen in die Leisungsausweis-Buchhaltung haben niemals einen Einfluss auf die SGR-Buchhaltung und den darauf basierenden Komponenten (SGR-Snapshots, Reports etc.) und umgekehrt.

• Abgebildet in daylight als "Kreditpunktebuchungen Eingeschrieben" (verwaltet in Entität PersonCreditPoints).
• Das Buchungsregister kann im Navigator unter "Anlässe und Artikel" => "Kreditpunktebuchungen Eingeschrieben" aufgerufen werden.

Im Gegensatz zu Evento, wo die Kreditpunkte für die SGR erst zum Stichtag evaluiert werden, sollen in daylight die Buchungen laufend vorgenommen werden. Dies kann zum Zeitpunkt des Arbeitsschrittes geschehen, welcher für die Buchung "verantwortlich" ist oder aber zu jedem beliebigen Zeitpunkt bis zum Stichtag.

Folgende Prozesse im Kontext von Lerneinheiten sind buchungsrelevant und müssen fortlaufend nachgeführt werden können:

• Anmeldung
• Abmeldung
• Ummeldung
• Löschen von Anmeldungen

• Ergänzend zur manuellen Buchung von SGR-relevanten Kreditpunkten sollen Buchungsgeneratoren dort zum Einsatz kommen, wo viele, gleichartige Buchungen nach einer klar definierbaren Logik generiert werden müssen.
• Von Generatoren erstellten Buchungen sind nachträglich durch den Benutzer editierbar/löschbar.
• Die Fixierung erfolgt der Buchungen erfolgt manuell durch den Benutzer (siehe nächster Abschnitt).
• Die Generatoren sind möglichst "intelligent" zu implementieren. So ist es z.B. vorteilhaft, wenn sie im gleichen Kontext mehrmals ausgeführt werden können. Dies ermöglicht ein iteratives Bereinigen von Daten und/oder ein zeitlich versetztes Ausführen.

Für die PHSZ wird 1 Generator implementiert. Spezifikation: https://daylightsoftware.atlassian.net/wiki/x/LN4a

• Kreditpunktebuchungen können durch den Benutzer fixiert werden.
• Fixierte Buchungen sind "read only" und können im UI nicht mehr editiert oder gelöscht werden.
• Fixierte Buchungen werden auch von Buchungsgeneratoren nicht mehr verändert.
• Fixierte Buchungen können "unfixiert" und erneut bearbeitet werden. Dies erfordert jedoch ein Spezialrecht.
• Es ist möglich, Buchungen in der Masse zu fixieren.

Kreditpunktebuchungen besitzen die daylight-Standardfelder "Erstellt", "Erstellt von", "Zuletzt geändert", "Zuletzt geändert von".

Benötigen wir eine Änderungshistorie? Soll das Mutationsjournal für diese Entität aktiviert werden?

Kreditpunktebuchungen können storniert werden. Es kann ein Grund für die Stornierung angegeben werden (Freitext).

Fixierte Buchungen aus abgeschlossenen Abrechnungsperioden sollten nicht mehr storniert werden können!

Noch nicht umgesetzt.

• Verwaltung von Abrechnungsperioden (Stichtagen) in Form von Stammdaten.
• Einer Kreditpunktebuchung muss eine Abrechnungsperiode zugewiesen werden können (zwingend).
• Abrechnungsperioden können fixiert werden. Für fixierte Abrechnungsperioden können keine Buchungen mehr erstellt werden.
• Die FHV-Abrechnung und der hierfür notwendige SGR-Snapshot findet 2 mal pro Jahr zu fixen Terminen statt, nämlich am 15.04. und am 15.10. für die Kreditpunkteabrechnung. Die Pro-Kopf-Abrechnung findet jeweils einen Monat später statt am 15.05. und am 15.11.
• Bei jedem dieser Snapshots, also 2-mal im Jahr, muss den Kantonen die sog. Kantonsliste und die jeweiligen Rechnungsbeilagen gemeinsam mit der Rechnung geschickt werden; für die Neustudierenden werden ausserdem noch zusätzliche Dokumente incl. Personalienblatt mitgeliefert
• Die jährliche Meldung der Studierenden an BFS müssen wir im Oktober machen, dies ist aber eine reine statistische Datenerhebung (= Studierendenstatistik) und hat eigentlich nichts mit der FHV-Abrechnung zu tun (…ausser dass hier die immatrikulierten Studis gemeldet werden)

• Tabelle für Abrechnungsperioden implementiert: "FHV SGR Abrechnungsperiode".
• Folgende Stammdatensätze erfasst: "FHV SGR 2018-10", "FHV SGR 2019-04", "FHV SGR 2019-10"

Die Buchungen einer fixierten Abrechnungsperioden können nicht mehr verändert werden.

• Verwaltung von Abrechnungslimiten in Form von Stammdaten.
• Einer Kreditpunktebuchung muss eine Abrechnungslimite zugewiesen werden können (zwingend).

• Buchungen für an der Heimschule eingeschriebene und somit abrechnungswirksame Kreditpunkte.
• Müssen als solche erkennbar sein in der Buchhaltung.
• Einzelbuchungen müssen, wann immer möglich, mit der Anmeldung auf die Lerneinheit, welcher die Kredits zugeordnet sind, verbunden werden (optional). Referenzierte Anmeldungen sollten nicht mehr gelöscht werden können.

• Feld Typ: Wert "Standard".
• Feld "Anmeldung" für Zuweisung der Anmeldung auf die Lerneinheit, welcher die Kredits zugeordnet sind.

• Einzelbuchungen müssen, wann immer möglich, mit der Anmeldung auf die Lerneinheit, welcher die Kredits zugeordnet sind, verbunden werden (optional). Referenzierte Anmeldungen sollten nicht mehr gelöscht werden können.

• Feld "Anmeldung" für Zuweisung der Anmeldung auf die Lerneinheit, welcher die Kredits zugeordnet sind. Der Fremdschlüssel wurde trotzdem auf der Buchung implementiert und nicht auf der Anmeldung (aufgrund von Designüberlegungen und Abwärtskompatibilität).

• Alternativ soll es soll es möglich, Sammelbuchungen für eingeschriebene Kreditpunkte zu erfassen. Beispiel: Total aller eingeschriebene Kredits im FS 2019 für Studi X, Kanton Y und Abrechnungslimite Z für Abrechnungsperiode "Apr. 2019".
• Die Id der Buchung wird auf allen dazugehörenden Anmeldungen hinterlegt,

• Zwischenentität "Kreditpunktebuchungsreferenz", mit welcher mehrere Anmeldungen der gleichen Buchung zugewiesen werden können.

• Abrechnungswirksame Auf-/Abrundungsbuchungen.
• Müssen als solche erkennbar sein in der Buchhaltung.

• Feld Typ: Wert "Differenzbuchung".

• Abrechnungsunwirksame Buchungen, z.B. die ECTS von Übernahmeverträgen, welche bereits von der Vorgängerschule abgerechnet wurden.
• Müssen als solche erkennbar sein in der Buchhaltung.
• Folgende Subtypen müssen unterscheidbar sein: "Korrektur", "Interner Wechsel", "Extern mitgebracht".

• Feld Typ: Wert "Korrekturbuchung".
  
• Die Subtypen sind im Feld Kategorie abgebildet. Folgende Werte können für Buchungen vom Typ "Korrekturbuchung" gesetzt werden: "Standard", "Interner Wechsel", "Extern mitgebracht".

• Die für die Kantonslisten und Ertragsrechnung aufbereiteten Daten sollen in Form von Schulgeldrechnungs-Snapshots persistent abgespeichert werden.
• Konsequente Trennung von Datenaufbereitungslogik und Formatierung-/Darstellungslogik für die Kantonslisten- und Ertragsrechnungsdokumente.
• Die Datenstruktur wird für die Berichte Kantonsliste und Ertragsrechnung optimiert.

Die Erstellung der Kantonslisten und die Ertragsrechnung erfordert Stammdaten. Diese Stammdaten sind persistent zu speichern und mittels einer grafischen Oberfläche den Benutzern zur Verwaltung zugänglich zu machen.

• Die persistente Speicherung von SGR-spezifischen Stammdaten ist möglich pro Schule, pro Region, pro Studiengang und pro Region/Studiengang-Kombination.
• Folgende Stammdaten-Felder werden bereit gestellt: Vereinbarung, Verrechnungspauschale, KontoSoll, KontoHaben und Ktr.

• Ein SGR-Snapshot kann aus daylight heraus für ein spezifisches Stichdatum erstellt werden.
• Die Datenbasis eines SGR-Snapshots sind die Buchungen der SGR-Kreditpunktebuchhaltung mit gleichem Stichdatum (resp. Abrechungsperiode).
• Der Algorithmus der Snapshot-Generierung sucht sich für eine Region/Studiengang-Kombination den jeweils „spezifischsten“ Stammdatensatz heraus.

• In einem Log wird festgehalten, ob und wann SGR-Snapshots erfolgreich durchgeführt worden sind ebenso wieviele Studierenden-Datensätze verarbeitet worden sind.
• Der Inhalt des Logs kann aus daylight betrachtet werden (Bericht)

Existierende SGR-Snapshots eines bestimmten Stichdatums können vor Überschreiben (durch das Erstellen eines neuen SGR-Snapshots) und vor Veränderungen geschützt werden. Damit wird sichergestellt, dass an die Kantone gemeldete SGR-Daten durch den Benutzer nicht mehr verändert werden können.

Brauchen wir das? Wurde (vermutlich) so gar nie umgesetzt in Evento...

• SGR-Snapshots können miteinander verglichen und die Differenzen in einer Änderungsliste (Bericht) dargestellt werden.
• Es können sowohl Snapshot-Versionen des gleichen Stichdatums als auch Snapshots unterschiedlicher Stichtage miteinander verglichen werden.
• Dies ermöglicht eine gezielte Datenkontrolle, d.h. die SGR-Snapshotdaten müssen nicht zum wiederholten Mal gesamthaft kontrolliert werden.

• ECTS-Summenkontrolle zwischen errechnete PersonenCredits mit Summen auf Kanton/StJg-Ebene Ist in Studiliste drinn.
• Quercheck aktuelle Berechnung der Credits pro Person und Abrechnungslimite mit Vorgängerdaten im SGR-Snapshot (letzter gespeicherter Stichtag) Ist in Studiliste drinn.
• 01_Auf Abrechnung fehlende Personen: Aufgrund STjg-anm und SN => Im April manuell
  

SGR-Kantonsliste
(alias Kantonsrechnung Studierende)

Die am letzten Stichtag (Okt. 2018) den Kantonen gemeldeten Kreditpunkte-Saldi. Diese gelten pro Student, Kanton und Abrechnungslimite.

Diese Saldi sind die neuen "ECTS bisher" für den Stichtag Apr. 2019.

Pro Student, Kanton und Abrechnungslimite müssen folgende Buchungen für SGR-Kreditpunktebuchhaltung und für die Abrechnungsperiode "10.2018" erstellt werden:

• Korrekturbuchung "Extern mitgebracht": Summe aller Buchungen aus Tabelle PersonCreditsMitgebracht
• Korrekturbuchung "Intern": Summe aller Buchungen aus Tabelle PersonCreditsMitgebracht
• Sammelbuchung: EctsTotal des letzten SGR Snapshots (Tab tblCstPHZ_3160_SGR_Snapshot_Stud) - Betrag Korrekturbuchung "Extern mitgebracht"- Betrag Korrekturbuchung "Intern".

Tabelle PersonCredits.

Der letzte Stichtag (Okt. 2018) wird als Abrechnungsperiode erfasst und die Saldi werden als Sammelbuchungen (Korrekturbuchungen, mit entspr. Subtyp) darauf gebucht.

WICHTIG: Die Anmeldungen (der migrierten Anlässe und weitere) müssen mit den Sammelbuchungen verknüpft werden.

Tabelle PersonCredits.

Buchungen für die aktuelle Abrechnungsperiode werden generiert mittels Anmeldungs-Kreditpunktegenerator.

Bewegungsdaten müssen vorgängig aufbereitet werden (Bsc und Ma).

Aufrundungsbuchungen für Exmatrikulierte, Abrundungsbuchungen

Es gibt keine Buchungen für diese Abrechnungsperiode.

Tabelle PersonCredits.

Werden in Zukunft manuell als Kreditpunktebuchungen erfasst.

Startbuchungen aus Übernahmeverträgen (bei Neu-Immatrikulierten)

Tabelle PersonCredits.

Werden in Zukunft manuell als Kreditpunktebuchungen erfasst.