1. Administering Financial Consolidation and Close
  2. Managing the Approval Process
  3. Managing Approval Phases
  4. Validations for Approval Phases

Validations for Approval Phases

System Validations

For each approval action, the following validation process will be performed where applicable.

System Validations for Promotion / Approval

  • User is valid Owner with Write access to Entity

  • Current location of Entity is with assigned User

  • Calc Status of Entity is OK / No Data / System Changed

System Validations for Locking

In order to lock an entity for the current period, all prior periods within the same year of the entity must be locked. If the current period is the first period of the year, the prior period (which would be the last period of prior year) must be locked.

Phased Approval with No Phase Dependency

Since there is no dependency on phase, within the same period, the system does not check if Phase 1 is locked before Phase 2 can be locked.

The system does check for prior period locking. For lock period check, all of the phases for the Prior period are locked in order to lock any phase for the current period.

For example, in order to lock March, NY: GroupA, all prior periods for this entity and all of the phases must be locked. Therefore, Feb, NY: GroupA, GroupB, GroupC, and Jan, NY: GroupA, GroupB, GroupC must be locked.

Phased Approval with Phase Dependency

For Phased Approval with Dependency, in addition to the prior period check, the system also checks to ensure that all previous phases within the same period are locked.

The system checks Calculation Status when locking each phase. In order to lock the phase, then entity must be OK or SC or NoData.

For example, it is possible that Phase 1 was locked, but later you entered more data for Phase 2 which is not yet locked. In order to lock Phase 2, you must consolidate the entity so that Calculation Status is OK before you can lock Phase 2.

System Validations for Unlocking

In order to unlock an entity for the current period, all future periods (with data) within the same year of the entity must be unlocked.

Phased Approval with No Phase Dependency

Since there is no dependency on phase, within the same period, the system does not check if Phase 2 is unlocked before Phase 1 can be unlocked.

The system checks to ensure that all phases for future periods with data are not locked in order to unlock any phase for the current period.

For example, in order to unlock March, NY: GroupA, assuming that the last period with data is May, then all phases in all future periods (April and May) must be unlocked. April, NY: GroupA, GroupB, GroupC and May, NY: GroupA, GroupB, GroupC must be unlocked.

Phased Approval with Phase Dependency

For Phased Approval with Phase Dependency, in addition to the future period check, the system checks to ensure that all subsequent phases within the same period are not locked.

User-Defined Validations

Phased approval validation is based on the rules defined for the cells within each phase.

You can define any validation rules that you need.. You can create the rule in the data form, or you can use calc script to do the calculation, and then assign the result to an account which you reference in the form as part of your validation rule.

If you want a different validation rule for a different phase, you can include the specific validation account as part of the phase definition.

Since custom validation is optional, you may not need validation for some phases and enforce it for other phases.

Phase Dependency Validations

If Phase Dependency option is selected for the Aapproval Unit Hierarchy, there are additional validation checks before a specific approval action is allowed. The following approval actions require additional phase dependency check:

  • Start

  • Exclude

  • Promote

  • Reject

  • Take Ownership

  • Reopen

  • Approve

  • Lock

  • Unlock

The phase dependency check does not apply to data entry as a user cannot start entering data until the entity is started.

An Entity Group within an Approval Unit Hierarchy has three properties that are considered for the dependency check.

  • Approval Status validation (new approval status after action is performed)

    Approval status of Phase N+1 must be equal or lower than Phase N

  • Location validation (new location after action is performed)

    Location of the Level X Entity must be equal or lower than Level X+1

  • Owner and Reviewers validation

    There is no dependency validation for owner and reviewer within the same location. Therefore, owner and Reviewer1 and Reviewer 2 of the same location within the promotional path are considered the same.

To perform the approval action, one must pass the dependency check for both approval status and location validation. If any part of the validation fails, the approval action will fail.

In addition to the validation rule for approval actions, the system validates when users can have access to the data and the actions they can perform. See Data Validation Rules.