Forum Stats

  • 3,855,345 Users
  • 2,264,499 Discussions


What could happened if we load data while a consolidation is running?

.Martin. Member Posts: 59
edited Aug 15, 2016 12:30PM in Financial Consolidation

Hi all,

hope that someone can explain what could happened if we load data while a consolidation is running.

Dataload and consolidation were start for the same POV.

We had a data loss in one scenario and year.

Possible tasks for this were a delete data task, perhaps in wrong scenario / year or a dataload task with wrong replace mode or the dataload while running consolidation with the same pov.

I know what happened while delete data and dataload with replace, but i don´t know what happened in the above described case.

Thanks vor every hint in advance. :-)

[HFM Version:]

Sai Kumar Kandunuri.Martin.


  • CBarbieri
    CBarbieri Member Posts: 1,011 Gold Trophy
    edited Aug 2, 2016 9:48AM

    During a consolidation, HFM locks the descendants of the selected parent entity. If users load data, post journals or in some other way attempt to modify the data in the locked entities, the action will be queued until the consolidation is complete and the locks are removed. The user doesn't need to retry the data load/post/etc., they just have to wait and they will see their action complete. HFM is designed to have lots of users concurrently loading data, consolidating, adjusting, reporting, etc., so you don't have to worry about what the system is doing.

    You can also load rules or metadata during a data load or consolidation - you may notice the metadata or rules load will not begin until all currently running data loads and consolidations have completed.

    Data is not lost in a normal activity. If the user loaded data in replace mode, then you should investigate the data load, but HFM on its own will not delete base data. Only a user can do this through their actions, or through rules.

    - Chris

    Sai Kumar Kandunuri.Martin.
  • .Martin.
    .Martin. Member Posts: 59
    edited Aug 2, 2016 6:25PM

    Hi Chris,

    the users said that they did their Tasks correctly.

    Do i have any possibility to analyze with wich mode the data was loaded and in wich Scenario the delete Task was running?

    Unfortunately we did not activate the logging function and in the Task Audit i did not get the detailed Information.

    On last friday there was a delete Task in a test Scenario. There were a lot of changes in metadata so we had to deploy the application on Weekend.

    On last Monday after the deploy there were two data load Tasks in the actual Scenario were we lost data. No one can say when exactly the data failed.

    We could copy the failed data from another Scenario so all data are complete at the Moment. But i have to analyze the reason for the data loss.

    I only administrate the Metadata and rules and don´t have directly Access to the database.


  • KVJ
    KVJ Member Posts: 23
    edited Aug 7, 2016 2:44AM

    Check HFM log on the server if you find any Delete entries. Hope you have turned on the Task Audit now.

  • Jeo123
    Jeo123 Member Posts: 515 Gold Badge
    edited Aug 15, 2016 12:30PM

    For what it's worth, I often find users say that they performed everything correctly up until the point you can prove that they did in fact not perform the task correctly.  Always take "it wasn't my fault" with a grain of salt.

    As for what happens when data is loaded during a conoslidation(since my users do this all the time it seems), you'll wind up with a consolidation that completes, however the data load will happen afterwards, so as a result, you'll still have an impacted hierarchy.  As previously mentioned though, this can't cause a data loss.

    Data load on replace by mistake is the most common cause of data loss in an unlocked/unpublished scenario since users with a data file can easily have the wrong year.  As a simple example, if your data file is being built in excel and contains all 12 periods across a record, dragging the year down can cause the excel auto-increment function to kick in and you can wind up loading a record to the wrong year.

    On a replace, that's effectively a clear for the entire year for that entity with the exception of that one bad record.

    Unfortunately without data audit enabled or a backup, it will be almost impossible to prove that though.

This discussion has been closed.