We think that, by developing our FCCS consolidation template we will find so many matches with ESSBASE functionalities. And so, we try to report here.
Let’s talk about metadata development in FCCS: here we can use the IMPORT METADATA function, so we build a TXT file with the dimensions we want to import into the FCCS application; we will have a record header with the name of dimensions and the properties we want to upload: we can explicit as many properties as we need for each dimension; FCCS will set as “default” the missing properties in the TXT file. We manage the load option and field separator as in the Essbase Administration Console (EAS) when we manage the RULE FILE to import dimensions and property dimension from a TXT file or from a staging table into our DB. We manage the CLEAR MEMBER option, then we validate and import.
For data upload we build a TXT file made of our Periodic or YTD data values; we have the period, we have the measure with the amount, we have the Point of View for the data import and then we have the cube to be loaded. We set up the location from which to import the file, we set up a delimiter , an import mode, an accumulation type and a date format. This is very similar to the Essbase Data Load Rules, to load thousand of data records from a TXT file or from a database.
Always with reference to what we do in Essbase, both metadata and data management in FCCS includes these process steps:
- TXT model and creation, also from an excel file;
- First import and TXT validation (the same of Data Rule run in EAS);
- Adoption of the TXT as a template for the go live to import files with same format.
For more info email email@example.com
We have started developing our FCCS application for statutory consolidation.
We start from the multi-year experience in the implementation of ORACLE HFM and ESSBASE applications.
Learn more about FCCS features and functionalities: email firstname.lastname@example.org
We are just talking about pre-configured dimensions and hierarchies, but in FCCS Movement dimension was designed to facilitate the creation of Cash Flow Statement: Movement dimension members are appropriately grouped by Cash Flow sections: Operating Activities, Investing Activities, and Financing Activities. In addition, the FCCS_CashFlow hierarchy lays out the Cash Flow Statement design where more details and appropriate adjustments could be added. Each member of the FCCS_Movement hierarchy needs to be shared with FCCS_CashFlow. Also, movement members need to be assigned to the account dimension as in HFM with the Custom Top Member attribute.
Oracle Hyperion Financial Management (HFM) on premise application is based on 12 dimensions: Scenario; Year; Period; View; Entity; Value; Account; Intercompany partner; Custom1; Custom2; Custom3; Custom4. We can use more than 12 dimensions if we make applications with more than 4 Custom dimensions.
Oracle Financial Consolidation and Close Cloud Service (FCCS) starts with 13 dimensions: Scenario; Year; Period; View; Consolidation; Datasource; Currency; Entity; Account; Movement; Intercompany partner; Custom1; Custom2.
FCCS “Consolidation” dimension recalls the old HFM “Value” dimension which means how data go up from my local currency balances to the contribution to a Consolidation Node. FCCS “Datasource” dimension recalls the old HFM “Nature” dimension: we can upload data manually or from TXT or from FdmEE, we can make adjustments in Local or consolidation currency, Fccs performs intercompany eliminations during consolidation process: all these different “nature” of data entry and manual / automatic journals are mapped into the “DATASOURCE” FCCS dimension. FCCS “Movement” dimension recalls the old HFM “Flows” dimension: this shows for istance the info about a fixed asset Opening Balance, an Acquisition, a Disposal and all the movements useful to the Note to Financial Statements.