Data accidently being changed for the closed and reported periods is an unfortunate mistake. Luckily, this is quite easy to avoid. In FCCS, owners can lock precisely those entities they want to keep unchanged. However, locking can give a validation message. A few easy steps to successfully lock periods.
Prohibiting users from entering data in FCCS can be done by locking the entity through the so called ‘Approval unit’. This stops the data from being (accidently) changed for the closed & reported periods. When locking the data, you have the choice to run validations before you can successfully lock the entity or entities.
Frequent error message
When you’re using the standard validations(form) in FCCS for locking approval units, it can be confusing if the locking is not successful. For example, you might see the message ‘failed: invalid data’. Why are you getting this message, and how do you avoid it?
FCCS runs two checks
When you try to (un)lock an approval unit, basically two checks are done by FCCS;
- 1. Is the data status ‘Impacted’? In other words, did you forget to consolidate the entity/entities after the last data change?
- 2. Is the approval status of the prior- or next period valid?
These checks might need some more explanation. What happens when we’re trying to lock a base entity?
When trying to change the status to ‘locked’, we receive the following message:
If you click the link (red encircled above), you will see a validation screen:
From here, you can go to the underlying validation form, see below. In this case, period November is ‘impacted’, and the prior period October is ‘unlocked’. This means we have to lock October first, then run the consolidation for November before we can successfully lock November itself.
Colors in validation form
So, what do the blue, yellow and red colors mean in the validation form? I found that Oracle’s documentation is at least very limited, so let’s shed some light on the coloring and interpretation.
- Locked, cannot be Unlocked as the next period is ’Locked’.
- Solution: Unlock the periods starting from the last locked period (September in this case).
Blank (FY18 Sep)
- Locked, can be unlocked as the next period is unlocked.
Blank (FY18 Oct)
- Unlocked, can be locked, because prior period is locked and calculation status <> ‘Impacted’.
- Impacted, cannot be locked as calculation status = Impacted.
- Solution: Run consolidation.
- Unlocked, cannot be locked as prior period is ‘unlocked.
- Solution: Lock prior periods first (and consolidate if impacted).
Run the validation separately
Hint: Instead of trying to lock the entity directly, you can also run the validation separately by clicking the button:
You’ll find this button next to the refresh button in the first screenshot.
You will see the status of the Approval unit changing, in this case to ‘no additional approval required’. This means the Approval unit is valid and can be locked:
Why locking periods is so important
With these steps, locking the closed and reported periods is quite easy to achieve. It will help you manage the quality of the data and ensure that previously reported figures are not changed by mistake. In short, it will improve the reliability of your reporting.
Do you also want to improve the reliability of your financial reports in other ways? I like to talk about it further, please contact me via firstname.lastname@example.org.
Text: Bert Dotinga