Data Copy using DataGridBuilder in Groovy!

 

 

In this blog, we will see how to perform an intercompany data translation with ease,  

 

This rule ensures intercompany data is clean, aligned, and instantly processed when users save a form. It applies standard naming and business logic automatically—no manual cleanup needed. Data flows straight into the target  cube or POV, reducing cycle time and reconciliation effort. It improves auditability and consistency across entities, accounts, and products. The result? Faster closes, fewer errors, and more trust in your numbers

Benefits of This Rule?

1.  Smart Data Transformation: Automates the cleanup of messy or inconsistent member names. No need to rely on manual fixes or assume users always get it right.
2.  Accurate Intercompany Processing: Ensures intercompany data is grouped and processed correctly critical in financial systems.
3.  Reliable Save Operations: Only runs when there's something worth saving. It won't crash or run on an empty form.
4.  Better Data Integrity: Ensures the data written to the cube follows expected patterns and naming standards, reducing errors and rework.
5.  Repeatable & Scalable: This logic can be reused across entities, products, and accounts. One rule to rule them all.

 

 The Rule’s job is to:

 

1. Ensure a form has been saved (aka, there’s a grid of data to work with).
2. Group changes made to the form by the "Intercompany" dimension.
3. Transform the data (adjust dimension members if needed).
4. Load the transformed data into a specific cube or POV.

 

Think of it like having a spreadsheet where users can enter some financial data. When they click "Save", this rule springs into action behind the scenes, cleaning up the data, fixing naming conventions, organizing it, and stuffing it into the right place in the cube. Pretty cool, right?

Here it does check for the data Grid, and then access the provided cube. In this case its Fin_Pln. Then retrieve all the dimensions of the cube. 

    

Retrieves all the dimensions and their members part of the POV. Also gets the dimensions that are not part of the POV. 

Gets the edited icp members and for each icp member a POV is created and a data grid builder is created.  

 For each edited icp member a column is added and rows are added which are part of the data form. 

Then the transformation happens as per the icp logic for the dimensions members that needs transformation. Here its for product, detail & account dimension members. 

Finally the data is saved to the grid and the log is printed to the job console for debugging and audit. 

Conclusion:

 

  if (!operation.hasGrid()): Checks if there’s a saved form with data. If not, it throws an error and stops everything. No data? No party.

  operation.getGrid() and getCube('PCM_CLC'): These lines grab the saved form data (the "grid") and the cube we're working with. Think of it like opening the right Excel tab and grabbing the spreadsheet.

  Gathering the POV and Dimensions: It figures out which dimensions are fixed in the form’s POV (like headers) and which ones are in rows or columns. Why? Because the rule needs to know where to inject the data.

  Grouping Edited Cells by Intercompany: This part organizes all the changes the user made by the "Intercompany" member, which helps the rule act smartly and efficiently by handling one intercompany value at a time.

  Data Transformation: Here’s where the rule earns its keep. It modifies:

• Account names (e.g., "0010" becomes "0010_icp"),
• Product names ("Product_NA" becomes something clearer),
• And Detail entries to standardize them.

  Building the Data Grid: For each Intercompany group, the script builds a grid with all the needed POV values and transformed row values, then writes it back to the cube. It's like taking cleaned data from one tab and pasting it neatly into another with perfect formatting.

 

Customize it as needed and try it out as per your application,

 

Happy days on the Cloud!!!