1. Implementing Accounting Hub
  2. Manage Transaction Objects

Manage Transaction Objects

You can assign transaction and reference objects for each accounting event class. Based on the transaction objects, sources are generated and are assigned to the corresponding accounting event classes. These sources are used to create accounting rules.

Subledgers pass information to the application through transaction object tables. The columns in these tables are named after the source codes. Transaction and reference objects hold transaction information that's useful when creating journal entry rules for accounting. The transaction and reference objects are defined for an accounting event class so that source assignments to accounting event class can be generated using these objects. On the Manage Subledger Application Transaction Objects page, you can view all the transaction objects, primary reference objects, and secondary reference objects associated with the selected event class. You can select the objects to view the details of source mappings. The source assignments display the particulars of the source, its assignment level, and source details.

Transaction Objects

Transaction objects refer to the tables or views from which the Create Accounting program takes the source values to create subledger journal entries. Source values, along with accounting event identifiers, are stored in the transaction objects. The Create Accounting program uses this information to create subledger journal entries.

You have several options. You can:

  • Create new tables as the transaction objects and create a program to populate them.

  • Use views of your transaction data as the transaction objects.

  • Use your transaction data tables as the transaction objects.

Types of transaction objects:

  • Header transaction objects: Header transaction objects store one row with untranslated header source values for each accounting event. The primary key of a header transaction object is the event identifier. You need to provide at least one header transaction object for each accounting event class. All the transaction details that are neither translated nor their values vary by transaction line, or distribution should normally be stored in header transaction objects. Such as the Loan Number for a loan or the Contract Number for a contract.

  • Line transaction objects: Line transaction objects are relevant when there are details for the accounting event that vary based upon transaction attributes. For example, a mortgage transaction for loan origination may have multiple amounts, each related to different components of the loan. There may be a loan origination amount, closing cost amounts, and escrow amounts. Each of these amounts could be captured as separate lines, along with an indication of the amount type. Line transaction objects store untranslated line-level source values. There should be one row per distribution, identified by a unique line number. The primary key of a line transaction object is the event identifier and transaction object line number. Transaction details that are neither translated nor their values vary by transaction line or distribution are normally stored in line transaction objects columns, such as the Loan Number for a loan payment.

  • Multi-Language Support (MLS) transaction objects: MLS transaction objects are relevant to applications that support the MLS feature. MLS transaction objects store translated source values. There should be one row per accounting event and language. The primary key of a header MLS transaction object is the event identifier and language. The primary key of a line MLS transaction object is the event identifier, transaction object line number, and language. Transaction details that are translated, and whose values don't vary by transaction line or distribution, are normally stored in header MLS transaction object columns. Examples include Loan Terms for a commercial loan. Implementors can avoid having to store source values in header MLS transaction objects by using value sets and lookup types. Transaction details that are translated, and whose values vary by transaction line or distribution, should normally be stored in the transaction object in columns defined in a line MLS transaction object.

Reference Objects

Reference objects are useful for storing information that's used for creating subledger journal entries. This information may not be directly from the source system or may be used for many entries, thus making it redundant. Use reference objects to share sources' information across applications. For example, store customer attributes, such as the customer class or credit rating in a reference object, and then use it to account for different journal entries in a loan cycle, such as loan origination or interest accrual. Store information, such as bond ratings and terms, and use it to account for entries across the life of bonds, such as interest accruals or bond retirement. Reference objects can either have a direct relationship to transaction objects (primary reference object), or be related to other reference objects (secondary reference object).

Sources

Sources are a key component for setting up accounting rules. Sources represent transaction and reference information from subledger applications or reference systems. Contextual and reference data of transactions that are set up as sources can be used in accounting rules definitions. Oracle Fusion Applications predefines sources for its subledger. When determining what sources should be available for non-Oracle applications, it's helpful to begin the analysis by considering which information from your systems is accounting in nature. Examples of sources that are accounting in nature include general ledger accounts that are entered on transactions, the currency of a transaction, and transaction amounts. Sources that aren't always required for accounting rules include items that are related to the transaction for other purposes than accounting. Examples of information that may not be specifically for accounting, but which may be useful for creating subledger journal entries, are transaction identification number (loan number, customer number, or billing account number), counter party information, and transaction dates. Provide a rich library of sources from your subledger applications for maximum flexibility when creating definitions for subledger journal entries. Predefined sources are provided as part of the initial data of the application.