The Applications Accounting Definitions (AAD) Loader enables users to import and export application accounting definitions and journal entry setups between the file system and database instances. The AAD Loader also supports concurrent development and version control of the application accounting definitions.
In this chapter, seeded application accounting definitions refer to the ones created by Oracle implementers and shipped to customers. User-defined application accounting definitions refer to the ones created by implementers at the customer installation.
The AAD Loader satisfies the following version control requirements:
Ensures version consistency for all the journal entry setups assigned to an application accounting definition
Maintains consistency between user application accounting definitions and Oracle application accounting definitions for all shared journal entry steps
Restores previous versions of application accounting definitions
All application accounting definitions, mapping sets, account derivation rules, and supporting references are stamped with a version number. The version history is recorded in the database. The AAD Loader records whether a version change is a result of leapfrogging. When an application accounting definition is updated based on a version earlier than its latest version, the result is defined as a leapfrog version. Leapfrogging is commonly used when implementers fix bugs on earlier versions. The version control mechanism ensures consistency of the application accounting definitions and journal entry setups during the import and export processes.
In the example described in the leapfrogging figure and table below, the latest version of AAD ONE in development is version 2. A customer using AAD ONE Version 1 realizes that the property Side should be Debit rather than Credit for Journal Line Type Invoice Receivables. However, the customer does not want all the changes in version 2, namely the Transfer to GL property equals Detail and the added Condition property. The fix is made to version 1 and delivered to the customer as version 3. An updated version of AAD ONE Version 1 leapfrogs over the current AAD ONE Version 2 to become AAD ONE Version 3. The current version in development is now AAD ONE Version 3.
Leapfrogging Example
The table below describes the leapfrogging example.
AAD One Version 1 (Old) | AAD One Version 2 (Current) | AAD One Version 3 (Updated) |
---|---|---|
Journal Line Type: Invoice Receivables Side = Credit Transfer to GL = Summary |
Journal Line Type: Invoice Receivables Side = Debit Transfer to GL = Detail Condition = Transaction Type Name = Invoice |
Journal Line Type: Invoice Receivables Side = Debit Transfer to GL = Summary |
See:
This section includes the following parts:
All application accounting definitions and journal entry setups for an application are delivered or imported using a single data file. The file includes only application accounting definitions and journal entry setups of an application. Other seed data, such as sources and event entities, classes, and types are delivered through regular seed data mechanisms.
Application accounting definitions are imported using the Import Application Accounting Definitions concurrent program. This program imports the application accounting definitions from a data file to the Accounting Methods Builder (AMB) context specified in the SLA: Accounting Methods Builder Context profile option and produces a report of the results.
See: SLA: Accounting Methods Builder Context, Oracle Subledger Accounting Implementation Guide
When running the Import Application Accounting Definitions concurrent program, users specify whether to run the merge analysis, merge, or overwrite processes.
The table below describes the parameters for the Import Application Accounting Definitions program.
Parameter | Description |
---|---|
Accounting Methods Builder Context | AMB context for the application accounting definitions to be imported; defaulted from the SLA: Accounting Methods Builder Context profile option; required. |
Source File Pathname | Full path name, including the .ldt file name, of the data file containing the application accounting definitions to be imported; required Path name example: /home/jdoe/out/APAAD.ldt: Note: At least one of the three source path names must be entered. |
Merge Analysis | Determines whether merge analysis is performed to the imported application accounting definitions. Default is Yes. |
Batch Name | User-entered merge analysis report name. |
Import Option | Enabled and defaults to Merge if the Merge Analysis option is set to No. you cannot change the value. Indicates that the application accounting definitions from the data file are merged to the database. |
Validate | Enabled and required only if the Merge Analysis parameter is set to No; determines whether the Validate Application Accounting Definitions concurrent program should be submitted to validate all the imported application accounting definitions. Default is Yes. |
Purge Application Accounting Definition Setup | Specify if you want the Application Accounting Definition setups to be purged. The default value is No. If you specify Yes, then the next two parameters, Destination Directory Path and Purge Application Accounting Definition History are enabled. |
Destination Directory Path | Specify the destination directory path where the backup file is created. This option is enabled only if the Purge Application Accounting Definition Setup is set to Yes. |
Purge Application Accounting Definition History | Specify if you want the Application Accounting Definition history to be purged. The default value is No. This option is enabled only if the Purge Application Accounting Definition Setup is set to Yes. |
Note: The three options, Purge Application Accounting Definition Setup, Destination Directory Path, and Purge Application Accounting Definition History are relevant only for non-oracle subledgers. The Purge Application Accounting Definition Setup is not available for Oracle Subledger users.
When the Import Application Accounting Definitions program is completed successfully, a report highlighting all the imported application accounting definitions and their versions as well as all the errors that occurred during the import process is produced.
The decision to merge application accounting definitions and journal entry setups results in the copying of the specified application accounting definitions and journal entry setups from the file system to the database.
The table below describes the relationship between the type of user and the actions they can take with certain application accounting definitions. For example, an Oracle developer can merge and overwrite Oracle application accounting definitions while a customer can overwrite but cannot merge seeded application accounting definitions.
User Type | Seeded Application Accounting Definition | User-defined Application Accounting Definition |
---|---|---|
Oracle Developer | Merge Overwrite | Not Available |
Customer | Overwrite | Merge, Overwrite |
When merging seeded application accounting definitions from the file system to the database in a customer environment, a seeded application accounting definition is deleted from the database if it does not exist in the file system.
Users merge application accounting definitions by submitting the Import Application Accounting Definitions concurrent program with the Merge option.
Note: When importing application accounting definitions using the Merge option, the AAD Loader merges the relationships between the subledger accounting methods and application accounting definitions that do not contain application accounting definition assignments for the application.
See: Merge Validations
When merging application accounting definitions from the file system to the database, the versions of the application accounting definitions are validated. Merge is allowed if the original version of the application accounting definition to be merged is higher than the current version in the database.
If the version of a mapping set, account derivation rule, or supporting reference in the data file is lower than that in the database, it is not merged into the database. The higher version is retained.
When completed successfully, the Import Application Accounting Definitions program produces a report highlighting all the merged application accounting definitions, mapping sets, account derivation rules, and supporting references setups as well as all the errors that occurred during the merge process.
Users overwrite application accounting definitions by submitting the Import Application Accounting Definitions program with the Overwrite option.
See: Import Application Accounting Definitions Program Description
The overwrite program copies all the application accounting definitions from the file system to the database. The previous copies of application accounting definitions in the database are replaced.
Note: The Force Overwrite parameter in the Import Application Accounting Definitions program must be set to Yes in order to overwrite all application accounting definitions and journal entry setups regardless of their version number in the database.
When completed successfully, the Import Application Accounting Definitions program produces a report highlighting all the overwritten application accounting definitions, mapping sets, account derivation rules, and supporting references setups as well as all the errors that occurred during the overwrite process.
The Export Application Accounting Definitions program exports all application accounting definitions of an application from a database to the file system and produces a report of the results. All application accounting definitions and journal entry setups for an application are exported to the same data file. When the application accounting definitions are exported, a new version is stamped on the application accounting definitions, mapping sets, account derivation rules, and supporting references referenced by exported application accounting definitions.
The table below describes the parameters for the Export Application Accounting Definitions program.
Parameter | Description |
---|---|
Account Method Builder Context | AMB context for the application accounting definitions to be imported; defaulted from the SLA Accounting Methods Builder Context profile option; required |
Destination File Path | Full path name, including the .ldt file name, of the file system where the application accounting definitions are to be exported; required Path name example: /home/jdoe/out/APAAD.ldt Note: At least one of the three destination file path names must be entered. |
Destination File Pathname for Base Application | Valid file path name for the base application |
Destination File Pathname for Budgetary Control | Valid path name for the federal budgetary control |
Versioning Mode | Indicates whether the exported application accounting definitions are a result of leapfrogging. Select Standard if the AAD to be exported is based on the latest version; select Leapfrog if the AAD to be exported is not based on the latest version; or select Supersede if the AAD to be exported is not based on the latest version and is not a leapfrog. Default is Standard. |
User Version | User-assigned version; optional |
Export Comment | User-entered export comments; optional |
All application accounting definitions that belong to the same owner, Oracle or User, and share any journal entry setups are considered part of the same application accounting definition group. All application accounting definitions in the same group are exported with the same version number.
If any application accounting definition in a group is modified, all the application accounting definitions within the group are exported with a new version number. The new version number is the application accounting definition in the group with the highest version number plus one.
The following validations apply to mappings sets, account derivation rules, and supporting references upon export:
If mapping sets, account derivation rules, or supporting references are modified, they are exported with the highest version of the mapping set or account derivation rule in the history table plus one.
If mapping sets, account derivation rules, or supporting references are not modified, they are exported with the same version number.
If any of the unmodified mapping sets or supporting references result from a forced overwrite, they are exported with a new version number based on the highest version of the mapping set in the history table plus one.
When completed successfully, the Export Application Accounting Definitions program produces a report highlighting all the exported application accounting definitions as well as all the errors that occurred during the export process.
The AAD Loader does not support the direct migration of application accounting definitions from one instance to another. Instead, the migration of application accounting definitions is supported by the following operations:
Application accounting definitions are exported from the source instance into a data file.
Application accounting definitions are imported from the data file to the destination instance with the option to overwrite all application accounting definitions from the staging area to the working area of an AMB context.
Users can create multiple AMB contexts to support multiple implementers working concurrently.
This section includes the following parts:
Implementers use the AAD Loader to import and export application accounting definitions between the data file and the database instances.
In the example shown in the figure below, a single Implementer imports a data file into the AMB context and completely overwrites the application accounting definitions in the database with the application accounting definitions from the imported data file. The application accounting definitions are then exported into a new data file.
Development by a Single Implementer Example
Concurrent development is possible because the AMB enables implementers to simultaneously work on the same application accounting definitions in different AMB contexts. Data files with updated versions of application accounting definitions are then imported and merged into specified AMB contexts to load the updated application accounting definitions into the database.
In the example shown in the figure below, multiple implementers import a data file into their respective AMB contexts and merge the application accounting definitions in their context with the application accounting definitions from the imported data file. Implementer A completes the work and exports the updated application accounting definitions into a new data file. Implementer B imports the data file and merges the updated application accounting definitions into context B. The merged application accounting definitions are then exported along with changes made by Implementer B into a new data file.
Concurrent Development Example
The AAD Loader facilitates development of customer-specific application accounting definitions at the customer site by providing the same import, export, and merge utilities available to Oracle implementers.
In the example shown in the figure below, a patch with seeded application accounting definitions is applied at the customer site. The latest versions of all the application accounting definitions currently in use by the customer are imported into the working area of a default AMB context before applying the patch. The data file from the patch is imported and a merge analysis is run highlighting the impact of the new seeded application accounting definitions before merging the application accounting definitions. The merged application accounting definitions are then exported along with changes made by the implementer into a new data file.
Development by a Single Implementer at a Customer Site Example
The AAD Loader offers the same concurrent development at the customer site.
In the example shown in the figure below, multiple implementers at the customer site import a data file into their respective AMB contexts and merge the application accounting definitions in their working areas with the application accounting definitions from the imported data file. Implementer A completes the work and exports the updated application accounting definitions into a new data file. Implementer B imports the data file and merges the updated application accounting definitions into the working area in context B. The merge application accounting definitions are then exported along with changes made by Implementer B into a new data file.
Concurrent Development at a Customer Site Example