Your FCCS rule validates successfully. It deploys successfully. The job status says Success. And the target cell is still empty.
One of the first things you should check is whether the problem is related to data block creation.
Why the Calculation Runs but Nothing Gets Stored
Consider this calculation:
"CI_Calculated" = "FCCS_Net Income" + "FCCS_Total Other Comprehensive Income";
The calculation looks simple and logical. But in the Standard FCCS application design, Account is the dense dimension by default, while the other dimensions are sparse. So, when you calculate an Account without first creating or anchoring the calculation at the appropriate sparse intersection, the calculation may run successfully, but there may be no existing data block at the target intersection to store the result.
The Solution: Use a Sparse Member as an Anchor
A common approach is to use a sparse dimension member to provide the calculation context. Data Source and Movement are common candidates. For example:
"FCCS_Other Data" (
"CI_Calculated" =
"FCCS_Managed Data"->"FCCS_Net Income"
+ "FCCS_Managed Data"->"FCCS_Total Other Comprehensive Income";
)
The sparse member acts as the anchor for the calculation.
An even more targeted approach is to anchor the calculation on the source Data Source and use @CALCMODE(BOTTOMUP). With this approach, the target block is created only if the corresponding source data block exists.
The principle is simple: before trying to force Essbase to create blocks, first determine whether the calculation can be anchored to an existing source block.
The Related Mistake: Reaching for Block-Creation Settings Too Quickly
When a calculation does not produce the expected result, it can be tempting to immediately use block-creation settings copied from other Essbase or Planning implementations. That approach should be used carefully in FCCS.
FCCS calculation best practices provide specific approaches for handling block creation, including sparse-member anchors and bottom-up calculation techniques. Automatic block creation can also have a significant performance impact, and Auto-Create Blocks and @CALCMODE(BOTTOMUP) are mutually exclusive.
So, the better approach is to first understand:
- Where the source data exists.
- Whether the target block already exists.
- Which sparse dimension can provide the appropriate calculation context.
- Whether a bottom-up calculation approach is appropriate.
- Whether block creation is genuinely required.
Anchor the calculation properly, and in many cases, you may not need to force block creation at all.
The next time your FCCS rule says Success, but the target cell still returns #MISSING, don't stop at the job status. Ask yourself: does a data block exist at the intersection where the calculation needs to write the result?