Historic Reload from Perm Tables
With the answers to the previous questions in hand and presuming that this is not a complete historic reload, follow these steps to perform a historic reload from the perm tables:
Note: If a situation arises that requires a complete historic reload from the ERP of the perm and fact tables, contact QAD customer support. Check back for later releases of this reload guide that may provide more details.
1 Set the DAILY_START job to On Hold.
2 Set the JOB_CHAINING_ENABLED parameter to N.
3 Run the SET_CONNECTION_<datasource1> job from the Scheduler.
4 If this is the Inventory module, go to Step
13.
If this is a single source system, go to Step
6.
If this is a multi-source system, go to Step
5.
5 Run the following jobs, in sequence, kicking off each after the prior has completed. The reason for this step is to populate certain load tables the module loads need, without trying to guess which ones are populated correctly. This is only applicable if this is a multi-source system because if one source has populated a load table and a different source is being run for the modules, the data does not get loaded correctly. Specific examples of these are load_si_mstr and load_en_mstr, which OM, PO, and INV references, as well as possibly others.
a PREPROCESS_COMMON_TRUNCATE
b PREPROCESS_<submodule_symbol>_TRUNCATE
c PREPROCESS_COMMON_LOADS
d PREPROCESS_COMMON_DAILYONLY_LOADS
e PREPROCESS_<submodule_symbol>_LOADS
f DAILY_COMMON_PROCESS_CHAINED
g DAILY_COMMON_PERM_CHAINED
6 Run HIST_<submodule>_PERM_EXTRACT
7 If only one fact table is loaded, then go to step
8. If all the fact tables are reloaded, run HIST_<module>_<submodule>_PROCESS_CHAINED. Go to Step
9.
8 If only one fact table is reloaded, such as fact_om_order_history, make a clone of the existing HIST_<module>_<submodule>_PROCESS_CHAINED job. To do this, follow these steps:
a Right-click on the job name and choosing Insert Copy of Job.
b Click Scheduled at the top of the screen to refresh the job list. Look for the new cloned job that has the same name as the job copied from but with a number extension as part of the name.
c Edit the job name, replacing the number extension to something like _ONE_TIME_RELOAD. For instance, the job might be named HIST_OM_PROCESS_ORD_HIST_ONETIME_RELOAD.
d Edit the Task list of the job. In the example of only needing to reload fact_om_order_history, remove all the tasks that are not relevant to the loading of that table, such as the stage and fact table for fact_om_booking, fact_om_shipping, fact_om_invoice. Make sure to leave jobs in the stage_om_order_hist_revalue that are tied to the fact_om_order_history table. If it is not clear which tasks should be removed, it might be easiest to remove the non-relevant fact tables from the list so that the historic reload is not trying to repopulate them unnecessarily.
e Run the newly created one time job.
9 Assuming all facts should be loaded, then run the HIST_<module>_<submodule>_PROCESS_CHAINED job.
10 Repeat steps
3-
9 for all data sources.
11 Run the POSTPROCESS_<module>_<submodule>_<xxx>_SUMMARY to populate the snapshot and performance tables.
12 Set the DAILY_START parameter back to the regularly scheduled time.
13 For the Inventory modules, set the Parameter INV_PROCESS_DAYS to 50000. Let the Daily run normally. This can cause the run to take much longer than normal. Once the daily run has completed, set the INV_PROCESS_DAYS parameter back to some much lower number like 5 or 10.
Warning This methodology ensures that the Inventory module takes longer than normal for a few days until it passes the reset INV_PROCESS_DAYS parameter again.