Enhanced Data Integration with Fusion Financials Cloud: It’s new & it works

The October 2016 PBCS update saw the release of the “Enhanced Data Integration with Fusion Financials Cloud”. After the previous Fusion integration process turned out to be nothing more than a flat file load, I was sceptical of this new “Enhanced” version. I’m pleased to report that this time it truly is seamless!

The Oracle documentation is pretty good so instead of spouting out the step by step process, I’ll explain some things I picked up on during the process:

Obstacle #1: The Oracle documentation

“The Initialize process brings over the Fusion General Ledger data into the Oracle Enterprise Performance Management Cloud system as ASO Essbase cubes. Each ASO Essbase target application represents a chart of accounts definition from the source Fusion General Ledger instance.”

At this point, I’m thinking that initialising this connection is going to create ASO plan types in my PBCS application, I couldn’t figure out why this would be necessary or how, if that was the case, I was going to be able to load from Fusion into my BSO plan. Turns out that this isn’t the case at all and all it’s referring to is the setup of the Fusion cube in Data Management. Phew!

This is what you’ll see in Setup > Target Application in Data Management after initialising the Source System:

Obstacle #2: Import Format source dimensions
The next thing that stumped me was that when I went to create my Import format (source Fusion, target PBCS) I had all my PBCS dimensions in the drop down for source dimensions as well as my Fusion dimensions. Bug?

Before creating the import format, click Refresh Members in the Target Application. This will fix the issue and show you only the Fusion dimensions in the drop down.

Obstacle #3: Period Mappings

For a standard data file upload into PBCS, the period keys are irrelevant, so I never take much notice of them. For the Fusion upload, the period keys need to be set correctly. For example, if your Years in PBCS are financial years spanning Apr-Mar i.e. FY17 is Apr 2016- Mar 2017, then your Apr-17 mapping needs to have the dates from 2016. See below  

Alternatively, you could set up your own Source Mappings and choose Period Mapping type “Explicit” in your Data Load rule.
Your turn: Please comment if you can enlighten me as to how these months are ordered…

Obstacle #4: Duplicate member names in Fusion

If Fusion has duplicate members, you might need to set Use Qualified Member Name to ‘Yes’ when creating your source filters to prevent the import from failing,

Obstacle #5: Drill through

Once the URL is set and the Drill through option is set to Yes, drilling back into Fusion (Yes, all the way back into Fusion!) works well, I can drill through to see the transactions that were loaded into PBCS and then I can go one step further and drill back into Fusion itself.

I have found this usually doesn’t work first time, I get so far as the login screen before being faced with:

Noooo!

But all hope is not lost, if I go back to my drill through screen above, and click “Drill through to Source” again, Fusion opens and I can see the transaction and the journals that make it up. Hurray!

Writing the Budget back to Fusion

Writing back to Fusion is a very similar process to loading the Actuals to PBCS, except of course your import format will have the source and target swapped over and you’ll have to redefine all your Mappings with the Target set to Fusion.

You will need to enter the Budget Type, Budget name in the Data Load Rule > Target Options and specify the Functional Currency in your Location.

I have to say, adapters to other source systems can’t come soon enough, it has huge time saving implications for clients who no longer need to fuss around generating flat files and has opened up doors for comparing Actuals and Budgets with greater ease.

All we need now is for Data Management to be able to automatically update metadata. Here’s to hoping…

Anything else you've picked up on? 
Comments & Questions always welcome.