How to Use FDMEE Data Sync to Copy HFM Actuals to Planning

Okay, first off, when it comes to the data synchronization feature in FDMEE, we’re not a fan of the name.  Being techies, when we hear “synchronization” we think true two-way synchronization. That is, data is compared between two systems and reconciled with the latest changes in System A copied to System B and the updates in System B replicated in System A. That’s not how this works. You use this new FDMEE functionality to copy data from one EPM application to another EPM application. Consider it a one-way sync. So, the name might be a little misleading but this is still one killer feature.  In fact, we think it’s the most significant new feature introduced in FDMEE Release 11.1.2.4.  Why, you ask? Many of our clients have multi-product EPM environments with both HFM and Planning. And one of the most common monthly tasks is to copy Actuals from HFM to Planning for variance reporting.  FDMEE Data Synchronization, more commonly known as “Data Sync”, makes this really easy. Data Synchronization isn’t a component with its own a menu item. Instead, Oracle has baked this functionality into the import format and data load rule components. Here’s a rundown of how to set up. Step 1 – Create your import format. The import format is used to instruct FDM how to interpret the incoming data from HFM.  For the source application, pick your HFM application.  For the target application, select your Planning application.  From there, map the dimensions accordingly. View Image Step 2 – Assign your import format to a new location. Next, create a new location to associate with your new import format....

Part 6 – Legacy FDM to FDMEE: Where to Start

As you can see from the previous posts in this series, there are some complexities when going from FDM Classic to FDMEE.   If your company ever did a conversion from Hyperion Enterprise (HE) to Hyperion Financial Management (HFM), conceptually, it’s a similar effort.  Both HE and HFM are used for reporting and consolidations but are distinctive tools. When considering your upgrade project, we recommend engaging a consulting team with the following qualifications: Referenceable experience with Legacy FDM to FDMEE upgrade projects A solution architect with deep FDM Classic and FDMEE expertise A documented audit and migration process A consulting partner team with proficiency using the FDM Migration Utility You and your consulting organization will collaborate to determine the most effective method for upgrading your FDM Classic applications. The Utility can deliver a tremendous advantage when upgrading a large volume of FDM artifacts. A complete rebuild also has its advantageous. Depending on your Classic apps, a rebuild can be the faster, more direct way to FDMEE. If you do use the Utility, don’t overlook the opportunity to perform some spring cleaning. Also, we suggest introducing some simple enhancements to get your FDM end users more excited about making the leap to FDMEE. Blog Series: Choose the Best Way to Migrate FDM Classic to...

Part 5 – Rebuild vs. Migration Utility: Pros and Cons

Since the release of the FDM Migration Utility in September 2015, we’ve worked on several FDM Classic to FDMEE upgrade projects. We’ve elected to use the Utility for a handful of those implementations. Why? Rebuild Experience Oracle debuted FDMEE Release 11.1.2.3.0 in Spring 2013. The FDM Migration Utility was delivered more than 2 years later. During this time, you can say, we’ve become pretty good at rebuilding FDM Classic artifacts in FDMEE. We know the success factors for FDMEE upgrade projects. We’ve developed our own methods and home-grown utilities to accelerate the rebuild process. Most importantly, we know the benefits of rebuilding FDM in FDMEE from the ground up. There’s additional justification for manually re-creating all FDM content from scratch. Spring Cleaning and Simple Application Enhancements Remember the last time you moved from one place to another?  Maybe it was a local move to a bigger place or maybe you moved to a different state for a new job.  Either way, one of the major tasks when moving is determining what stays and what goes.  If an item is useful – it gets packed.  If it isn’t, it gets purged.  Think of your upgrade from FDM Classic to FDMEE in the same way. Most Legacy FDM applications can benefit from some spring cleaning.  Spending the time to examine your existing FDM Classic application(s) and associated processes can yield some worthwhile benefits. The main objectives of the application evaluation phase of your project is: Purge Outdated Content – Minimize application clutter by omitting outdated artifacts. Enhance Existing Integration Processes – Look for opportunities where FDMEE can offer a more efficient or effective way...

Part 4 – FDM to FDMEE: Artifacts and Migration Options

The FDM Migration Guide contains several FDM Artifacts and their Equivalents tables.  The tables display a listing of the main FDM Classic artifacts and their counterparts in FDMEE.  The tables also indicates if the Utility can convert each particular artifact to FDMEE. The information tables are a quick and easy way to understand old world to new world components and the migration options for each Legacy FDM component that you currently use. Right away, you can see the Migration Utility cannot migrate some artifacts, such as scripts, report objects, and security (User Maintenance and Object Maintenance) to FDMEE.  Here’s a listing of some of the artifacts you will have to rebuild from scratch in FDMEE. Scripts Reports Security Batch Processing Task Flows For most upgrade projects, the most time-consuming effort is re-developing scripts for FDMEE.  FDMEE uses Jython as its primary scripting language.  For more information on re-writing scripts for FDMEE, see Your Top 6 FDMEE Scripting Questions, Answered. Next: Part 5 – Rebuild vs. Migration Utility: Pros and Cons Blog Series: Choose the Best Way to Migrate FDM Classic to...

Part 3 – Does the Migration Utility Turn Classic to EE with a Push of a Button?

So, you’re probably wondering, Will the FDM Migration Utility convert one of our FDM Classic applications into a FDMEE application with a push of a button?   Spoiler alert: No. Not really. While FDMEE replicates most of the functionality found in Legacy FDM, it is not feature-by-feature rewrite of FDM Classic. Import formats, locations, mappings, and the guided workflow – the most utilized features are there.  However, some equivalent features slightly differ (e.g. batch processing), some objects are altogether new to the FDM world (for example, data load rules), and a few, seldom used FDM Classic features don’t exist in FDMEE (e.g., Financial Controls). Also, FDM Classic was built using Visual Basic for Microsoft Windows.  FDMEE is built on the Oracle Fusion Middleware platform. Same But Different Keep in mind, saying FDMEE is the successor to FDM Classic is little like saying your new 2016 BMW 6 Series is the successor to your 1996 Honda Prelude. Sure, both cars are sedans and both can exceed 100 Mph, but there are differences.  Your Prelude has a turn-knob stereo, pop-up headlights, 190 horsepower and has an outdated paper map in the glove compartment. Your 2016 BMW, on the other hand, has a Bluetooth stereo, LED headlights, over 400 horsepower, and an in-dash Navigation system. You get it.  Both cars accomplish the same goal – getting you from point A to point B – but the features aren’t exactly the same. And, let’s face it, you’d rather take out your date in the latest BMW vs. the old-school Prelude with your Hootie & the Blowfish CD. Given the differences, t’s reasonable to expect that a conversion utility can’t transform...