How to lock reported periods in Oracle FCCS

Data accidently being changed for the closed and reported periods is an unfortunate mistake. Luckily, this is quite easy to avoid. In Oracle 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.

lock reported periods in Oracle FCCS

Prohibiting users from entering data in Oracle 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 Oracle 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?

Oracle FCCS runs two checks

When you try to (un)lock an approval unit, basically two checks are done by Oracle 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: Locking-approval-6
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? Discover more about support for Oracle and our EPM support services.

Text: Bert Dotinga

Webinar Support & Life Cycle Management Oracle EPM