Validierungen für Genehmigungsphasen

Systemvalidierungen

Für jede Genehmigungsaktion wird der folgende Validierungsprozess ausgeführt, sofern anwendbar.

Systemvalidierungen für Hochstufungen/Genehmigungen

  • Benutzer ist gültiger Eigentümer mit Schreibzugriff auf die Entity

  • Aktueller Standort der Entity ist dem Benutzer zugewiesen

  • Berechnungsstatus der Entity lautet "OK"/"Keine Daten"/"Systemänderung"

  • Für Anwendungen, in denen "Erweiterte Organisation nach Periode" aktiviert ist, müssen sowohl der Berechnungsstatus als auch der Knotenstatus der Entity "OK"/"Keine Daten"/"Systemänderung" lauten.

Systemvalidierungen für Sperren

Um eine Entity für die aktuelle Periode zu sperren, müssen alle vorherigen Perioden in demselben Jahr der Entity gesperrt werden. Wenn die aktuelle Periode die erste Periode des Jahres ist, muss die vorherige Periode (die letzte Periode des Vorjahres) gesperrt werden.

Genehmigungen in Phasen ohne Phasenabhängigkeiten

Da es keine Phasenabhängigkeiten gibt, wird innerhalb derselben Periode nicht geprüft, ob Phase 1 gesperrt ist, bevor Phase 2 gesperrt werden kann.

Das System prüft nicht, ob Sperren für die vorherigen Perioden vorhanden sind. Bei einer Prüfung der gesperrten Perioden werden alle Phasen der vorherigen Periode gesperrt, um alle Phasen der aktuellen Periode zu sperren.

Beispiel: Um die Periode "March, NY: GroupA" zu sperren, müssen alle vorherigen Perioden für diese Entity und alle Phasen gesperrt sein. Daher müssen die Perioden "Feb, NY: GroupA", "GroupB"," GroupC" und "Jan, NY: GroupA", "GroupB" und "GroupC" gesperrt sein.

Genehmigungen in Phasen mit Phasenabhängigkeiten

Bei Genehmigungen in Phasen mit Abhängigkeiten wird zusätzlich zur Prüfung der vorherigen Periode auch sichergestellt, dass alle vorherigen Phasen in derselben Periode gesperrt sind.

Das System prüft den Berechnungsstatus beim Sperren der einzelnen Phasen. Um die Phase zu sperren, muss die Entity "OK", "SC" oder "NoData" lauten.

Beispiel: Es ist möglich, dass Phase 1 gesperrt wurde, Sie aber später weitere Daten für Phase 2 eingegeben haben, die noch nicht gesperrt ist. Um Phase 2 zu sperren, müssen Sie die Entity konsolidieren, damit der Berechnungsstatus "OK" lautet, bevor Sie Phase 2 sperren können.

Systemvalidierungen für Entsperrungen

Um eine Entity für die aktuelle Periode zu entsperren, müssen alle zukünftigen Perioden (mit Daten) in demselben Jahr der Entity gesperrt werden.

Genehmigungen in Phasen ohne Phasenabhängigkeiten

Da es keine Phasenabhängigkeiten gibt, wird innerhalb derselben Periode nicht geprüft, ob Phase 2 entsperrt ist, bevor Phase 1 entsperrt werden kann.

Das System führt eine Prüfung durch, um sicherzustellen, dass alle Phasen für zukünftige Perioden ohne Daten nicht gesperrt sind, um eine beliebige Phase für die aktuelle Periode zu entsperren.

Beispiel: Um die Periode "March, NY: GroupA" zu entsperren, gesetzt den Fall, dass die letzte Periode mit Daten "May" lautet, müssen alle Phasen in allen zukünftigen Perioden (April und May) entsperrt werden. Die Perioden "April, NY: GroupA", "GroupB", "GroupC" und "May, NY: GroupA", "GroupB" und "GroupC" müssen entsperrt werden.

Genehmigungen in Phasen mit Phasenabhängigkeiten

Bei Genehmigungen in Phasen mit Abhängigkeiten wird zusätzlich zur Prüfung der zukünftigen Periode auch sichergestellt, dass alle nachfolgenden Phasen in derselben Periode nicht gesperrt sind.

Benutzerdefinierte Validierungen

Die Genehmigungsvalidierung in Phasen basiert auf den für die Zellen der einzelnen Phasen definierten Regeln.

Sie können alle Validierungsregeln definieren, die Sie benötigen. Sie können die Regel im Eingabeformular erstellen, oder Sie können die Berechnung mit einem Berechnungsskript durchführen und das Ergebnis anschließend einem Konto zuweisen, welches Sie im Formular als Teil der Validierungsregel referenzieren.

Wenn Sie eine andere Validierungsregel für eine andere Phase verwenden möchten, können Sie das spezifische Validierungskonto bei der Phasendefinition einschließen.

Da die benutzerdefinierte Validierung optional ist, werden Validierungen möglicherweise für einige Phasen nicht benötigt und müssen für andere Phasen erzwungen werden.

Phasenabhängigkeitsvalidierungen

Wenn die Option "Phasenabhängigkeit" für die Genehmigungseinheitenhierarchie ausgewählt ist, werden zusätzliche Validierungsprüfungen ausgeführt, bevor eine bestimmte Genehmigungsaktion zulässig ist. Für die folgenden Genehmigungsaktionen sind zusätzliche Phasenabhängigkeitsprüfungen erforderlich:

  • Starten

  • Ausschließen

  • Hochstufen

  • Ablehnen

  • Eigentümerschaft übernehmen

  • Erneut öffnen

  • Genehmigen

  • Sperren

  • Entsperren

Die Phasenabhängigkeitsprüfung gilt nicht für Dateneingaben, da ein Benutzer erst dann Daten eingeben kann, wenn die Entity gestartet ist.

Bei einer Entitygruppe in einer Genehmigungseinheitenhierarchie werden drei Eigenschaften für die Abhängigkeitsprüfung in Betracht gezogen.

  • Validierung des Genehmigungsstatus (neuer Genehmigungsstatus, nachdem eine Aktion ausgeführt wurde)

    Genehmigungsstatus von Phase N+1 muss kleiner/gleich Phase N sein

  • Validierung des Standorts (neuer Standort, nachdem eine Aktion ausgeführt wurde)

    Standort der Ebene X Entity muss kleiner gleich Ebene X+1 sein

  • Validierung von Eigentümern und Prüfern

    Es gibt keine Abhängigkeitsvalidierung für Eigentümer und Prüfer in demselben Standort. Daher werden der Eigentümer sowie Prüfer 1 und Prüfer 2 desselben Standorts im Hochstufungspfad als gleich betrachtet.

Um die Genehmigungsaktion auszuführen, muss die Abhängigkeitsprüfung für den Genehmigungsstatus und für die Standortvalidierung erfolgreich sein. Wenn einer der Validierungsteile nicht erfolgreich ist, ist auch die Genehmigungsaktion nicht erfolgreich.

Zusätzlich zur Validierungsregel für Genehmigungsaktionen wird eine Validierung durchgeführt, wenn Benutzer Zugriff auf die Daten und Aktionen haben, die sie ausführen können. Informationen hierzu finden Sie unter Datenvalidierungsregeln.