Planning

Get Involved. Join the Conversation.

Topic

    Scott Rose
    ePBCS - Workforce - Process Loaded Data does not carry...
    Topic posted October 12, 2019 by Scott RoseGreen Ribbon: 100+ Points, tagged Calc Manager, EPBCS, Financial Planning, PBCS, Planning, Workforce 
    79 Views, 4 Comments
    Title:
    ePBCS - Workforce - Process Loaded Data does not carry properties forward for forecast.
    Summary:
    When Loading Forecast or Budget Data and running Load Process Details / Calculate Existing Employee Compensation = No Salary or Compensation Shows
    Content:

    We are seeing and issue in ePBCS where we load FY19 Forecast or FY20 Plan and we run the 1X copy rates to months, Load Process Details and Calculate Existing Empoyees Compensation and no Salary, Compensation or any of the properties carries forward into the future months.

    Not sure if related but we did restore the following scripts recently and didn't see any custom code in them...

    • OWP_Add Requisition_GT
    • OWP_Add Requisition_T
    • OWP_Assign Compensation_T

    Have been told this could be a create block issue so I tested one individual and submitted to the calculated workforce fields, we ran process details and calculate existing employees compensation and corporate bonus did calc out in future months (Nice!) but the salary did not calculate in salary basis and the properties did not carry into future months. 

    Details Attached.

     

    Comment

     

    • Mark Rinaldi

      Are you loading the Default Assignments are part of your data load?  If not, you should change the Process Loaded Data Rule (not Template) to include the Synchronize Defualts Template instead of the Synchronize Component Definition Template.  Moreover, you should be using Data Management with the Incremental Load File Adapter to load all data for performance gains. This process uses Groovy-based rules to only calculate data for the intersections that have data.  There are 2 rules to use with this process that align with my earlier comment:  one assumes your data load has the Default Assignments (Synch Component Definition) and the other will define those for you (Synch Defaults).

      My guess is, you haven't run the Synchronize Defaults rule.

    • Mark Rinaldi

      Also, the 1X rule, really only needed to be once per Scenario/Version combination.  You still shouldn't need to run this rule for an existing application at this point. 

    • Mark Rinaldi

      Regarding my note to substitute the Synch Defaults Template in place of the Synch Component Definition Template, refer to the second to last bullet point in this chapter of the documentation (read the whole chapter), Performance Considerations with Workforce Rules.

      Also, please refer to the Loading and Calculating Incremental Workforce Data chapter, which was introduced in February of this year (19.02).  Even if you only load data once per cycle, using this process should still provide performance gains based on the Groovy rule dynamically generating the FIX statement for the intersections with data rather than you running the Process Loaded Data (PLD) Rule for the world (e.g. All entities, all employees, all jobs, etc.).  This is a clear use case where Groovy rules are significantly more efficient than pure Essbase rules.  We also have an Overview Video on YouTube for this topic. At about the 50-second mark, we discuss the 2 rules to use.

       

    • Scott Rose

      We were able to resolve - the Load Process Details calc is apparantly tied to the PlanStartYr Varaible, we are running a FY19 forecast and a FY20 plan (Budget) so when we updated the PlanStartYr to FY20 we were unable to load existing employees to FY19 which did not have a Jan Start date.  See more Information below and response from Oracle Support.

      If we update our PlanStartYr variable from FY20 to FY19 the data loads as expected for our Open Positions.  We are running a FY20 Plan (a next year annual budget) so one would expect this variable to be FY20.  The PlanStartYr variable appears be in the dimensionality of compensation members and not in the calc script, odd they would have a plan start year variable in the coding which forecast uses.