UML class diagram

Transaction
Object Interface	GLIE
trans_id voucher_ref voucher_date act_trans_date period_id	GL. Transaction Identifier. Text GL. Transaction Document. DetailsDoc. Number. Text GL. Transaction Document. DetailsDoc. Date Time Author Editor. DetailsAuthor Editor. Action. Date Time, where action="posted" GL. Period. Text
Entry
Object Interface	GLIE
trans_id entry_id entry_date entry_type acc_id orig_amount amount cr_dr description voucher_ref	GL. Transaction Identifier. Text GL. Entry Identifier. Text Author Editor. DetailsAuthor Editor. Action. Date Time, where action="posted" GL. Source Journal. Identifier GL Account. DetailsGL Account. Identifier GL. Original. Amount GL. Amount GL. Debit Credit. CodeCode. Content GL. Description. Text GL. Entry Document. DetailsDoc. Number. Text
Account
Object Interface	GLIE
acc_id description is_control balance	GL Account. DetailsGL Account. Identifier GL Account. DetailsGL Account. Name GL Account. DetailsGL Account .Type. Text, where Text="control" GL Account. DetailsGL Account. Balance. Amount

Selected portions of OMG GL Facility, pages 9 - 18

These are the key assumptions provisioned for the environmental objects containing and managing the GL Facility.

• The GL Facility assumes that GL client authentication for the security policy domain has occurred prior to access to GL Facility interfaces. Please see "Service Dependencies and Relationships" (Appendix A) for more information.
  
• The GL Facility assumes that access controls will be applied according to system domain policies prior to and during GL client sessions. For example, the passing of clear-text parameters in operation invocations will be protected from unauthorised access or disclosure.
  
• The only interface provided to GL clients prior to GL session establishment is the GL Arbitrator interface. The environment shall not disclose other GL interfaces to GL clients. That is the responsibility of the GL Arbitrator interface. For example, only the GL Arbitrator interface shall be advertised in the Trader Service and Name Service. Other GL interfaces are provided by the GL Profile interface, subsequent to GL client session establishment.

This section details key assumptions regarding the responsibilities of GL Facility implementations, as well as detailing various invariants for General Ledgers, GL Accounts, GL Transactions and GL Entries.

• The GL Facility maintains state for each client session. For example, each GL client session concerns only one known General Ledger and that General Ledger's established Chart of Accounts.
  
• There is a one-to-one mapping between each General Ledger and each Chart of Accounts in each GL Facility instance. This "single set of books" constraint is conformant with International Accounting Standards. However, a GL Facility is not responsible for enforcing this constraint in federation with other GL Facility installations.
  
• Operations performed during each GL client session are constrained by session-specific GL policies. Please see GL FacilityLifecycle for administrative operations.
  
• Implementations shall make available at least one Chart of Accounts to GL clients so that an initial GL client session may be established in situations where no General Ledgers exist. This chart may either be empty or may be a default chart. Implementations with zero General Ledgers are prohibited.

• The specified names of General Ledgers to be constrained and managed by the GL Facility must be unique. The duplication of General Ledger names is prohibited. The naming of specific General Ledgers is usually carried out by privileged GL Facility administrators.

• The decision to remove a specific General Ledger, GL Account, GL Transaction or GL Entry from the GL Facility is set by organisational and environment specific policies.
  
• The currently selected General Ledger’s reporting currency is determined by organisational policy. A reporting currency is the nominated currency used by a reporting enterprise and is used in the presentation of general purpose financial statements. The reporting enterprise is an enterprise or other organisational entity, for which there are users who rely on general purpose financial statements as their major source of information about the enterprise. A single General Ledger constrained by a GL Facility implementation may support only a single reporting currency.
  
• Individual GL Transactions and GL Entries must be "date stamped" in order to comply with Generally Accepted Accounting Principles (GAAP). However, these date stamps can have very different meanings and therefore impact. For example, GL Transactions and GL Entries have an "actual date" which represents a "physical" or "actual" calendar date. However, this date is not necessarily the same date as the "logical" accounting date or "entry date" also associated with a GL Entry. It is assumed that GL Facility implementations will support the GL Retrieval (and other) GL interface operations based on either or both of the date semantics associated with GL Transactions and GL Entries.

• GL Account references constrained by a specific General Ledger’s Chart of Accounts must be unique. The duplication of GL Account references is prohibited.
  
• The decision to remove a specific GL Account from a specific General Ledger constrained and managed by the GL Facility is set by organisational and environment specific policies. The specific GL Account must exist and cannot be in use. GL Accounts which are in use cannot be removed. A GL Account is in use when there are associated GL Transactions and/or GL Entries in the specified General Ledger or the balance of the account is non-zero.
  
• GL Accounts must be created with an account balance which is equal to zero. The monetary amount represented by the balance of a single GL Account that has no associated GL Transactions and/or GL Entries can only ever be equal to zero. A newly created GL Account must be created first, prior to the posting of any GL Transactions and GL Entries to be associated with a specified GL Account. The creation of new GL Accounts with a non-zero balance is prohibited.
  
• GL Account references may not be modified in any way. The only way to modify a GL Account reference is by removing it before it is in use. A specified GL Account cannot be modified if it is in use. The modification of GL Account references is prohibited.

• GL Transaction references must be unique. The duplication of GL Transaction references is prohibited.

• GL Transaction references may not be removed or modified in any way. The modification and removal of GL Transaction references is prohibited.
  
• The sum of all GL Entry debits and credits constrained by any GL Transaction must be equal (i.e. "balanced"). GL Transactions which are unbalanced are prohibited. If the debit and credit accounts of the GL Entries constrained by a single GL Transaction are the same, implementations will ensure that the debit takes place before the credit in the audit trail.
  
• GL Transaction references may be ignored by implementations which automatically allocate these references at the server.
  
• The GL Transaction BookKeeping::post_transaction_list() operation return values must match the corresponding TransactionIdList for implementations which allocate GL Transaction references at the client.

• A single GL Entry constrained by a single GL Transaction and posted to a specific General Ledger constrained by the GL Facility has an identifier which must be unique. This identifier represents the "audit trail" number of each GL entry.
  
• GL Entries may not be removed or modified in any way. A GL Entry which has been posted to any General Ledger constrained and managed by an instance of the GL Facility cannot be removed or modified. The modification and/or removal of GL Entries is prohibited.
  
• A single GL Entry constrained by a single GL Transaction and posted to a specific General Ledger has an identifier which specifies whether the GL Entry was a debit or credit. A single GL Entry can only be a debit or credit.
  
• A single GL Entry constrained by a single GL Transaction and posted to a specific General Ledger constrained and managed by an instance of the GL Facility has an identifier which specifies the precise nature of that GL Entry. Implementations claiming conformance with this specification shall provide each GL Entry a type with a unique GL Entry type code which semantically differentiates between the various types of GL related financial accounting transactions for example; "Journal Debit" or "Journal Debit",.
  
• A single GL Entry constrained by a single GL Transaction and posted to a specific General Ledger constrained and managed by the GL Facility, shall record details of the amount (debited or credited) in a foreign currency, as well as in the nominated reporting currency for a specific General Ledger.

Forward declarations are included for all of the interfaces defined in the GL Facility.

interface Arbitrator; // establish GL client session
interface Profile; // GL Facility metadata
interface BookKeeping; // GL data entry
interface Retrieval; // GL data acquisition
interface LedgerLifecycle; // GL lifecycle management
interface Integrity; // GL data integrity checks
interface FacilityLifecycle; // GL Facility lifecycle management

The FdGeneralLedger module defines several data types for GL accounting information. Among these are a number of sequence types, which follow the naming convention <T>List where <T> is the type of the sequence elements. All string types used in the module are wstrings.

GL Facility - Basic Data Type Definitions

typedef FbcCurrency::Money Money; // imported from the OMG Currency 
// specification, module FbcCurrency
typedef sequence<wstring> wstringList; // sequence of type wstring
typedef sequence<boolean> booleanList; // sequence of type boolean 

typedef wstring CurrencyMnemonic; // a reference to a single currency

typedef wstring TransactionId; // a single GL Transaction reference
typedef sequence<TransactionId> TransactionIdList;

typedef wstring EntryId; // audit trail number for a GL Entry 
typedef sequence<EntryId> EntryIdList;

typedef wstring AccountId; // a single GL Account reference
typedef sequence<AccountId> AccountIdList;

typedef wstring EntryType; // a single GL Entry type
typedef sequence<EntryType> EntryTypeInfoList;

typedef wstring PeriodId; // a reference to a user defined period

typedef unsigned short ChartKind;
const ChartKind EMPTY_CHART = 1;
const ChartKind DEFAULT_CHART = 2;
const ChartKind EXISTING_CHART = 3;

An instance of the GL Facility constrains and manages one or more General Ledgers, each of which requires a single Chart of Accounts (schema) to be established before proper operation can be assured. The data type ChartKind specifies the different kinds of Chart of Accounts schemata for the initialisation of a new General Ledger which is to be constrained and managed by an instance of the GL Facility. Please refer to the GL Facility’s FacilityLifecycle interface operation create_ledger_chart_of_accounts()for specific information.

Each General Ledger has an identifying name and a single Chart of GL Accounts schema. A new General Ledger may be initialised without first specifying the Chart of Accounts. That is, the new General Ledger is created but has zero GL Accounts defined. This schema type is represented by the EMPTY_CHART member of the ChartKind data type.

A single Chart of GL Accounts schema (associated with a single General Ledger) may be required to be conformant with specific accounting practices and/or regulations in a particular locale or country, for example. This schema type is represented by the DEFAULT_CHART member of the ChartKind data type. Governments and other regulatory bodies of the vast majority of countries in the world have specific minimum requirements regarding a General Ledger’s Chart of Accounts schema.

A new General Ledger may be based on an existing Chart of Accounts in another General Ledger managed by the GL Facility. This schema type is represented by the EXISTING_CHART member of the ChartKind data type. The new Chart of Accounts may subsequently be revised by using the administrative operations provided by the GL FacilityLifecycle interface.

enum DebitOrCredit { DEBIT, CREDIT };

The data type DebitOrCredit specifies whether a single GL Entry is a debit or a credit. A single GL Entry can only be either a debit or a credit.

Struct Date { CBO::DTime setting;

boolean is_set; };

 

The data type Date is used for all date operations. However, the CBO::DTime does not allow for "not set" date values which are frequently needed for many date oriented operations. The boolean is_set is added to provide a workaround for many frequently encountered situations that require a blank date, such as the retrieval of information from legacy systems, for example.

struct DateRange { Date start_date; Date end_date; };

The data type DateRange specifies date ranges for the purpose of supporting general purpose retrieval operations on GL accounting information such as GL Transactions and GL Entries, for example. The DateRange data type is inclusive of both a start_date and end_date.

GL Facility - Account Information

The GL Facility is responsible for one or more General Ledgers. A single, specific General Ledger must constrain and manage a single collection of GL Accounts, also known as a "Chart of Accounts".

Subsequently, GL Transactions and their associated GL Entries may be further associated with one or more GL Accounts (specified in the currently selected General Ledger’s Chart of Accounts schema) by "posting" (i.e. recording) GL Transactions concerning at least two (or more) GL Accounts contained in the General Ledger’s Chart of Accounts schema. Please see the various GL LedgerLifecycle interface operations for specific information about General Ledger administrative operations as well as the GL Profile::BookKeeping interface operations for more information about posting GL Transactions.

struct AccountInfo { AccountId acc_id;

wstring acc_description;

};

typedef sequence<AccountInfo> AccountInfoList;

The data type AccountInfo comprises a single GL Account reference which is unique to a specific General Ledger, as well as a user defined GL Account name which may be used to describe the nature or purpose for which a particular GL Account will be used. For example, salaries, bank current account, etc. The data type AccountInfoList is a collection type for the data type AccountInfo.

struct Account {

AccountInfo acc_info;

boolean is_control_account;

Money balance;

};

typedef sequence<Account> AccountList;

The data type Account specifies summary information describing a single GL Account. The data type AccountList is a collection type for GL Accounts.

• The acc_info member of the data type AccountInfo specifies a unique GL Account reference and name describing the name or purpose of this particular GL Account (for example, salaries, bank current account etc).
  
• If a GL Account has been specified as a "Control Account", the member is_control_account will always return TRUE. A GL Control Account accumulates a monetary value of related subsidiary GL Accounts over time. Some examples of GL Control Account designations could be: Debtor's Control Account, Creditor's Control Account, Inventory, Buildings and Equipment.
  
• The GL Account member balance is a state value representing an accumulated monetary value as recorded in the currently selected General Ledger, to date. The GL Account balance represents a monetary amount in the currently selected General Ledger’s reporting currency.

struct TransactionInfo {

TransactionId trans_id;

wstring voucher_ref;

Date voucher_date;

Date act_trans_date;

PeriodId period_id;

};

typedef sequence <TransactionInfo> TransactionInfoList;

The data type TransactionInfo specifies summary information about a single, specific GL Transaction. The data type TransactionInfoList is a collection type for multiple TransactionInfo data types

• The member trans_id specifies a unique GL Transaction reference for a single, specific GL Transaction.
  
• The member voucher_ref refers to any external (e.g. physical) documentation which may be related to (or associated with) a single GL Transaction such as a cheque, purchase order or invoice number, for example. Many National statutory regulations require that each GL Transaction in the accounting books must correspond to a "real" business transaction (usually represented by a paper voucher) and that it must also be easy to trace a specific GL Entry in the books to a corresponding voucher. This information may also be required for internal auditing purposes.
  
• The member voucher_date refers to the date of the "real" business transaction that caused the GL Transaction to be created and posted to the General Ledger, for example; a date on some external documentation (e.g. voucher) that a GL Transaction is to be (or was) associated with. Please see the TransactionInfo member voucher_ref as mentioned previously.
  
• The member act_trans_date refers to the "physical" or actual calendar date that the GL Transaction was (or is to be) posted to the currently selected General Ledger, and may be used for general purpose GL Transaction retrieval.
  
• The member period_id refers to an implementation defined accounting period for the logical posting of this GL Transaction. The data type PeriodId is of type wstring.

Generally, financial accounting is done within "accounting periods". An accounting period is defined as a period of time (of arbitrary length), whose only constraint is that a given accounting period is shorter than a full financial year. This applies not only to General Ledger accounting, but also to other often related accounting functions such as Accounts Receivable and Accounts Payable, for example. The set up of accounting periods is typically performed only once a year and is the subject of organisational policy. This submission makes no prescriptive statements about the rules that may be applied when using accounting periods.

As of this writing, both Period Management as well as Closing and Reconciliation Facilities are being considered as potential candidates for future OMG FDTF RFPs.

Each GL Transaction is composed of at least two (or more) GL Entries. Every GL Entry in the GL Facility corresponds to either a debit or a credit. Each GL Entry contains the details of an amount (debited or credited) in a foreign currency, as well that same amount in the nominated reporting currency of a specific General Ledger. In combination with the historical exchange rate information provided by an instance of the OMG Currency Facility, this provides sufficient information to generate multi-currency general purpose financial statements, should this be required.

struct Entry {

TransactionId trans_id;

EntryId entry_id;

Date entry_date;

EntryType entry_type;

AccountId acc_id;

Money orig_amount

Money amount;

DebitOrCredit dr_cr;

wstring description;

wstring voucher_ref;

};

typedef sequence<Entry> EntryList;

The data type EntryList specifies a collection type for multiple GL Entries. The data type Entry specifies information about a single GL Entry.

• The member trans_id specifies the parent GL Transaction that a single GL Entry is associated with and is synonymous with the TransactionId data type of the TransactionInfo data type mentioned previously.
  
• The member entry_id specifies the "audit trail" number of a GL Entry, while the members entry_date and data type entry_type (respectively) specify the "logical" date that a GL Entry was (or is to be) posted and the GL Entry type identifying the type of a single GL Entry.
  
• The member acc_id specifies the GL Account associated with a single GL Entry.
  
• The member orig_amount specifies the original amount of money of a foreign currency business transaction. A "foreign currency" is defined as a currency other than the reporting currency of an enterprise. Please see Profile::get_ledger_currency() for more information.
  
• The member Amount specifies the monetary amount of a GL Entry in a General Ledger’s reporting currency, while the member dr_cr indicates whether the GL Account involved was (or is to be) debited or credited.
  
• The GL Entry members description and voucher_ref hold user defined annotation which describes the GL Entry and a voucher reference to any relevant documentation associated with the GL Entry.

The data type EntryTypeInfo refers to a single, specific GL Entry type and an associated high level description such as "Journal Debit" or "Journal Credit", for example. The data type EntryTypeInfoList is a collection type of EntryTypeInfo.

• The member type refers to a single GL Entry type which represents the type of financial accounting transaction associated with a single, specific GL Entry.

The member description refers to a high level, human-readable description such as "Journal Credit" or "Journal Debit", for example.

copyright notice:

Used with the permission of the Object Management Group. For information on joining the OMG or additional information, please contact OMG headquarters by phone at +1-781-444 0404, by fax at +1-781-444 0320, or by email at info@omg.org. The OMG provides current information and services for distributed enterprise computing on the World Wide Web at www.omg.org and www.corba.org. Information about OMG Japan can be found at www.omgj.org.

The Object Management Group is an international non-profit standards organization that promotes a full-lifecycle approach to enterprise integration. OMG's standards cover application design and implementation.

CORBA®, The Information Brokerage®, CORBA Academy®, IIOP® and the Object Management Group logo® are registered trademarks of the Object Management Group. OMG(tm), Object Management Group(tm), the CORBA Logo(tm), "The Middleware That's Everywhere(tm)" , the CORBA Academy logo(tm), XMI(tm), MOF(tm), CWM(tm), OMG Interface Definition Language(tm), IDL(tm), CORBAservices(tm), CORBAfacilities(tm), CORBAmed(tm), CORBAnet(tm), UML(tm), the UML Cube Logo, "We're Known By The Companies We Connect(tm)", Model Driven Architecture(tm), MDA(tm), OMG Model Driven Architecture(tm), OMG MDA(tm), "The Architecture of Choice for a Changing World(tm)", and Unified Modeling Language(tm) are trademarks of the Object Management Group.