At right is a conceptual map of an arapXML instance document. In other words, a transaction batch. The three main elements are displayed (GLTransactionSet, GLTransaction and GLEntry).  These are business requirements in the accounting domain, which are fairly universal and not subject to much conceptual dispute.  Deep consensus exists that accounting data consists of related pairs or sets of debit and credit entries, that they are called transactions, and that general ledger consists of sets of transactions.

GLTransactionSet, GLTransaction and GLEntry have been submitted to the EWG, and to the XBRL consortium as suggested naming for the core components for  general ledger data.  

The names of the required elements within each of the three main levels are also business requirements.  For example, entry contains an amount.  This is a required element within each entry. Within the three main levels there are a small number of other required elements.  These are business requirements, which are not subject to  being omitted or dropped from a general ledger. 

The three main elements at right, and the required elements such as date and amount, are business requirements which are essential to the methodology and science of double entry accounting.  Whether the ebXML, XBRL, or EWG adopt these particular names is irrelevant to the arapXML schema.  When they finally publish their GL, these elements will be present in some fashion.

Within the three main levels however, there are a larger number of optional elements, such as description strings, product and party codes, etc.  These elements are coming from the broader domain of business requirements outside the double entry accounting domain.  They are not applicable to all users, and their inclusion and naming are open for debate.

These optional elements, and all of the complex types defined in the arapXML schema, are equivalent to data elements or aggregates in the ebXML registry (catalog of core components).

It is the objective of arapXML to conform with ebXML core components for each of these optional elements and complex types.  The technical design of these objects is in the technical domain, i.e. software domain.

Post your comments: Discussion