Kuali Financials uses batch processing to post transactions into the Labor Ledger and General Ledger, to create capitalization, indirect cost recovery, cost share and various other types of entries. There are also batch processes that update the Capital Assets module when capital purchases or transactions occur, extractions from the Financial System into Payment module, depreciation, year end and several other processes. Batch typically runs Sunday through Thursday.
Jobs are scheduled or unscheduled. A scheduled job is a job that will be executed once all of its dependencies have been satisfied. An unscheduled job must be manually invoked using the batch schedule screen. Note, when manually running an unscheduled job, job dependencies are not considered. Caution should be exercised that all necessary data that are normally added by the prerequisite jobs are set up to ensure a successful job run. All scheduled jobs have an unscheduled counterpart to facilitate testing or to run jobs outside the normal batch cycle. Year end jobs are primarily unscheduled and need to be run manually.
How to run batch jobs is described in the How to Run Batches article.
Batch File (Logs and System Reports)
The batch process generates files, logs and reports that summarize activity and postings. Refer to the Batch File - Logs, Reports and Files article for additional information.
Some batch jobs rely on files to be uploaded to specific directories which can dropped directly or by using a file upload process in the system. Refer to File Uploads article for additional information.
Correction Process (General Ledger and Labor Ledger)
Each ledger has an online correction process in the event that a transaction is demerged. The transactions are placed in a file that can be opened with the Correction Process documents. Providing an audit trail of changes made to the system. Files can also be downloaded, uploaded or deleted using the following documents:
- Step: conceptually, a stage in a process (i.e. job).
- Job: a series of steps that runs sequentially (and not in parallel). However, depending on how jobs are set up, jobs may run in parallel.
- Dependency: a job may rely on another job's execution before running. For example, there may be a job "A" that creates database tables, and another job "B" that writes data into those tables. Job "B" is said to be have a dependency (or be dependent upon) job "A". Therefore, job B (the dependent) should be run after job A (the dependee). A job may be dependent upon multiple jobs; in which case, all dependee jobs must run before the dependent job may run.
- Hard dependency: a dependency that specifies that the dependent job may run only after the dependee job has run successfully.
- Soft dependency: a dependency that specifies that the dependent job may run only after the dependee job has run (successfully or not).