MPC Logic Summary

The MPC logic comprises two parts, as follows.

Part 1: Start MPC Preprocessor

Start the MPC Preprocessor:

1. Check MPC_CALC_EXECUTION table for an instance of the preprocessor that is pending for the same MPC rule.
   If one instance is pending and the number of submitted > 0, then skip to Step 10.
2. Update MPC_CALC_EXECUTION table to pending status.
3. Generate a list of all entities in the rule.
   • If no include criteria is selected, select all entities from the entity table.
   • Else, add included entities. If necessary, determine members of LIST entities.
   • Check the entity close date field, if it has a date prior to today, do not include it.
   • Remove excluded entities. If necessary, determine members of LIST entities. 
4.  Determine which entities have not been run since the last rebuild, rule change, or field change (E records in MPC_CALC_EXECUTION_CONTEXT).
5.  Compare the current rule parameters to the rule parameters in the prior run (R records in MPC_CALC_EXECUTION_CONTEXT)
6.  Compare the current field parameters to the field parameters in the prior run (F records in MPC_CALC_EXECUTION_CONTEXT).
7.  Generate a list of all entities that need to be run.
   • If submitted as rebuild, select all entities from Step 3 that are in PERF_SUMMARY for selected dictionary and source.
   • Else if the rule has changed, select all entities from Step 3 that are in PERF_SUMMARY for selected dictionary and source.
   • Else if at least one field has changed, select all entities from Step 3 that are in PERF_SUMMARY for selected dictionary and source.
   • Else, submit entities from Step 4 that are in PERF_SUMMARY for selected dictionary and source and submit any entities that have changed since the last run (update_date > mpc_upd_date or mpc_upd_date = null) for selected dictionary and source.
8.  Submit one MPC engine for each entity identified in Step 7 to the scheduler and MPC_CALC_EXECUTION_DETAILS.
    See "Part 2 Perform for Each MPC" for more details. 
9. Update MPC_CALC_EXECUTION stats.
10. Check the status of each MPC engine every minute until all complete.
11. If all complete successfully then:
    • Update the MPC_CALC_EXECUTION table with the successful status and stats.
    • Update the MPC_CALC_EXECUTION_CONTEXT table.
      If rebuild, rule, or field changed, delete all and insert all successful entities, all rule parameters, and all field parameters. Else insert successful entities from Step 4.
12. If all do not complete successfully:
    Update MPC_CALC_EXECUTION table with the failed status and stats.

Part 2: Perform for Each MPC Engine

In each MPC engine:

1. Lock the entity in ENTITY_COMMIT_CHECK.
2. Determine all PERF_ROLLUP_RETURN_ID values that need to be updated.
3. Interpret SCHEDULE_DEF USER_DATA from MPC preprocessor.
   • Changed and unchanged fields are flagged.
   • If submitted as rebuild or a rule was changed or a field was changed or the entity was added in Part 1, Step 4 set all fields as changed.
   • For changed fields, determine earliest END_EFFECTIVE_DATES of PERF_SUMMARY records in starting frequency.
   • For unchanged fields, determine the dates that have changed PERF_SUMMARY records (update_date > mpc_upd_date or mpc_upd_date = null).
   • Get the entity inception / fiscal year end date. If these are NULL, then set the value in the ITD / FYTD column as NULL
4. Retrieve all data from PERF_SUMMARY and PERF_SEC_RETURNS table for the selected fields.
   
   • Note the dates that are found in Step 3.c and Step 3.d as change dates.
   • Note the LOCKED and PRIMER records.
   • Retrieve and note business dates from the BUSINESS_CALENDAR table.
5. Calculate starting frequency data.
   For each MPC field in each PERF_ROLLUP_RETURN_IDS level:
   •   WTD Columns:
     • If a primer record is found start with that value.
     • Reset date is first date of the week.
     • On Reset date, use current day's value.
     • If not Reset date, prior day is used to calculate current date.
     • If field was changed, update all dates.
     • If field was unchanged, update column until the day prior to the next Reset date.
     • Derived frequency RESULT columns are not updated.
   • MTD Columns:
     • If a primer record is found start with that value.
     • Reset date is first date of the month.
     • On Reset date, use current day's value.
     • If not Reset date, prior day is used to calculate current date.
     • If field was changed, update all dates.
     • If field was unchanged, update column until the day prior to the next Reset date.
     • Derived M frequency RESULT columns are updated.
   • QTD Columns:
     • If a primer record is found start with that value.
     • Reset date is first date of the quarter.
     • On Reset date, use current day's values.
     • If not Reset date, prior day is used to calculate current date.
     • If field was changed, update all dates.
     • \If field was unchanged, update column until the day prior to the next Reset date.
     • Derived M, Q frequency RESULT columns are updated.
   • YTD Columns:
     • If a primer record is found start with that value.
     • Reset date is first date of the year.
     • On Reset date, use current day's values.
     • If not Reset date, prior day is used to calculate current date.
     • If field was changed, update all dates.
     • If field was unchanged, update column until the day prior to the next Reset date.
     • Derived M, Q, Y frequency RESULT columns are updated.
   • FYTD Columns:
     • If a primer record is found start with that value.
     • Reset date is the day and month of the fiscal year end date.
     • On Reset date, use current day's values.
     • If not Reset date, prior day is used to calculate current date.
     • If field was changed, update all dates.
     • If field was unchanged, update column until the day prior to the next Reset date.
     • Derived M, Q frequency RESULT columns are updated.
   • ITD Columns:
     • If a primer record is found start with that value.
     • Reset date is inception date.
     • On Reset date, use current day's values.
     • If not Reset date, prior day is used to calculate current date.
     • If field was changed, update all dates.
     • If field was unchanged, update column for every date after the changed date.
     • Derived M, Q, Y frequency RESULT columns are updated.
       Derived frequency BASE columns are updated for all subsequent dates.

    6. Update the MPC_UPD_DATE for each starting frequency changed.
    7. Update the UPDATE_DATE for each derived frequency changed.
    8. Update the business calendar if necessary.
    9. Unlock the entity in the ENTITY_COMMIT_CHECK table.