With Kscope19 quickly approaching, I wanted to remind you of the presentations from KScope18.  It was a great week and I hope to build on what was discussed next year.  I hope you find these valuable. Read more



To expand on Part 13 of this series, which covers stopping a form from saving when there are validation errors, is identifying the errors by cell and communicating with the user the problems at a cell level.  This does NOT stop at the first error and throw an exception.  This will iterate through all the errors and explain each one at a cell level for the user to correct.  The following example will use similar code and concepts, but will apply validations to each cell by changing the color and setting a tool-tip with the explanation of what the validation error is.

Before we continue, the methods to do this do not make use of the MessageBundle.  I think this is a miss because one bundle can be reused for similar validation, and the current methods assume a single language.  There is a way to use it indirectly.  There is a bug that is causing issues with the method, so we will assume basic functionality and come back to the use of a MessageBundle when the bug is fixed

Throw an Exception (Interrupt Form Save)

The basic inclusion of cell validation is very simple.  As the code iterates and validates the cells, the following will change the background color, add a tool-tip, and invalidate the form and stop it from saving any data to Planning.

def BackErrColor = 16755370 //Red
it.addValidationError(BackErrColor, "error message here",false)

The color can be different for different errors and it completely customizable.  The error message can be anything necessary.

Consolidated Example

The form associated to this rule has the ability to adjust a number by either increasing or decreasing the units by month.

To illustrate this, here is an example of looping through cells and validating two things.

  1. Units can’t ever be adjusted to a negative amount – they can be decreased, but never to a negative value.
  2. Any change to units must be offset to have a full year impact of zero.
def BackErrColor = 16755370 //Red

def CaseTotal = it.crossDimCell('Jan').data + it.crossDimCell('Feb').data + it.crossDimCell('Mar').data + it.crossDimCell('Apr').data + it.crossDimCell('May').data + it.crossDimCell('Jun').data + it.crossDimCell('Jul').data + it.crossDimCell('Aug').data + it.crossDimCell('Sep').data + it.crossDimCell('Oct').data + it.crossDimCell('Nov').data + it.crossDimCell('Dec').data 
operation.grid.dataCellIterator('Working_Inp','Jan','Feb','Mar','Apr','May','Jun','Jul','Aug','Sep','Oct','Nov','Dec').each {
 if(it.data + it.crossDimCell('OEP_Working').data < 0.0)
   def change = it.data + it.crossDimCell('OEP_Working').data
   it.addValidationError(BackErrColor, "Your adjustment forces the new cases to be a negative volume. Increase your adjustment by $change", false)
  if(CaseTotal != 0.0 && it.data != 0.0)
     it.addValidationError(BackErrColor, "Adjustments must not have a full year impact. Currently, the data would change by $CaseTotal.", false)

Enhancement Request

One thing you might notice is the lack of inclusion of the messageBundle object.  I have requested an enhancement, as it only makes sense that it be used here, and they have added it to the enhancement list.  So, look for this be added in the future.  It can be identified internally by the following.


I don’t know why, but Oracle has no way of getting the message based on the local from the messageBundle.  Many of the methods, like getMessage, are not made available to us as developers, that would likely circumvent this issue.


As with the other validation methods, this introduces a huge benefit in both usability and budget accuracy.  Any time data validation can be performed proactively, everybody wins.  There is less of a burden on administrators and users get instant feedback they can easily and quickly fix.



When moving data in PBCS with Data Maps or Smart Pushes, they have limits on how much data can be moved.  The amount of data can be seen in the logs, and look something like this. Read more



One of the fundamental features of a Groovy calculation is the ability to dynamically grab aspects of a grid, and getting the POV is something that is required to dynamically generate an Essbase calculation.  There are times when the entire POV is required, times when only members from specific dimensions are needed, and situations where only the rows and columns of the edited cells are used to construct effective fix statements.  All 3 of these situations will be discussed. Read more


With more and more time dependent related data, grabbing the month from a Smart List is becoming more common.  Associating that with a value in the application is required for a number of calculations, including things like Read more


As you all notice PBCS does not yet offer the possibility to create attribute dimensions. One of the solutions to get around this is to choose to map a smart list to a dimension in the map reporting module. Follow the steps below to configure your mapping.
Read more


I’m currently working with a Planning application that has 2 data types with different dimensionality. This proved to cause some issues when I would try to import data via FDMEE. I would receive a validation error during the import phase for dimension UD4 (Customer dimension) which was valid for Plan Type 2 but not for Plan Type 1 Read more