[September 24, 2001] Several accounting firms are collaborating on the design of UML models and XML notation for ArapXML, formulated in response to an OMG RFP issued earlier in 2001. ArapXML "is a pure document format for representing General Ledger data as simply, completely, and efficiently as possible. It contains no security features, method calls, etc. It is equally usable with Java, linux, or COM, or scripting languages. ArapXML enables exchange of transactions based on classic double-entry accounting. It is designed for individuals and companies who use software or services from multiple vendors to conduct business. ArapXML is based on UML models. It consists almost entirely of a subset, or synonyms, of ebXML core component vocabulary. It is interoperable with established e-commerce vocabularies such as EDI. ArapXML applies an objective approach to determine the integration needs of small business and individuals as well as large companies, by reference to accounting history, accounting patterns, and existing software. ArapXML aggregates receivables and payables from multiple systems or BSPs, whenever the decision is made to manage and settle them at a single place. This activity can be performed by the owner using an existing local application, as well as a web-based GL or payments and settlements provider. The ArapXML schema is not biased in favor of web-based accounting ASPs or BSPs. It exports as well as imports." An ArapXML UML model corresponding to the OMG's Account Receivable - Account Payable AR/AP Facility RFP is being prepared by members of the consortium.
Problem statement: "There are thousands of good, functional applications available on the internet. The Internet is the operating system and web apps are the programs. When the owner has two or more business applications, the total cash, payables, receivables, and tax reporting requires consolidating into a general ledger someplace. The alternative to component architecture is the monolithic system from a single vendor. ArapXML supports the component vision in a small way, by providing a document format for general ledger transactions... Now that we have the internet, the N-squared problem arises because of the number of applications which must communicate with each other. Any healthy scenario having widespread use of the internet by SMEs implies a large number of specialized, vertical applications from multiple providers... The purpose and scope of a 'General Ledger' most commonly includes financial reporting, tax reporting, and maintaining external balances (cash, and payables and receivables or control over the subledgers that maintain them). arapXML enables exchange of transactions based on classic double-entry accounting. It is designed for individuals and companies who use software or services from multiple vendors to conduct business."
ArapXML project methodology: "The Project includes research, discussion, documenting use cases and requirements, and finally, publishing XML and UML specifications. The research stage relies upon existing GL schemas and formats as evidence of the requirements of earlier developers, and the markets they served. The methodology is to consider each element in each of the various formats, its meaning and usage, and its placement, whether in header or row of transactions. Elements peculiar to one format are dropped. Elements common to all formats are retained. The current scope of research includes examining the existing XML formats for PO, invoice and billing to ensure that arapXML supports the most often required information or structures for payment terms, party, product, bank, etc. The future scope of research also includes (1) schema for ledger definition, (2) schema for chart of accounts, (3) schema for empirical reputation metrics, and (4) business process schema or choreography solution..." [from the web site 'Research' document 2001-09]
From the data dictionary introduction: "ArapXML is an XML document format for representing general ledger and accounts payable and receivable records. For the elements dictionary it is essential that the reader understand some of the complex types used in arapXML instances. The most important of these is the IdType. This is derived from 'identification.type' in ebXML Core Components Structure and Naming convention v1.04. ArapXML uses this core component type to represent DUNS numbers, EAN and UN/SPSC ids, and Ids of UDDI businessEntity's, etc. The objective is to achieve practical usage of these IDs in a business system, and the means to resolve IDs into their meanings by querying these list providers..."
Consortium: As of August 2001, the arapXML Consortium was in startup mode. The founding members [NetAccount AS, SINTEF, GLdialtone.com, EverydayOffice] invited individuals, companies, and web application hosts to participate. Participation from both the accounting and software and web technology domains was solicited.
Account Receivable - Account Payable AR/AP Facility. Request For Proposal. OMG Document: finance/01-04-04. The AR/AP Facility Draft RFP - Version 1.1. Issued April 27, 2001. 37 pages. "The Account Receivable/Account Payable (AR/AP) Facility defines the interfaces, and their semantics, that are required to enable interoperability between AR/AP systems and general ledgers, sales and purchasing systems, and other distributed objects and applications for accounting purposes... Proposals are solicited for the definition of interfaces for a universal, AR/AP ledger which meets two top-level, conceptual requirements: (1) External integration [which] address the requirements and expectations for AR, AP and cash ledgers in an Internet environment, in which the transaction creation, management and settlement cycle is increasingly automated and interconnected with third parties and intermediaries; (2) Internal integration with other applications within the enterprise... The entries within any external balance have common properties: these properties are universal and inherent. The universal attributes of an external transaction entry in the subject's books may include the following list: [1] identity of the party (e.g., customer or supplier) [2] amount of money, [3] date and time the transaction was concluded or executed, [4] description of what was exchanged (e.g., string, document, document reference or XML message), [5] due date (expectations regarding date of settlement), and [6] settlement method (expectation regarding bank, settlement agent or method). This RFP includes within its scope, support for common XML vocabulary for representing an AR/AP transaction, and transporting it among widely disparate systems... Proposals shall discuss in detail the semantics for any use of XML and its relationship to the CORBA standards in this specification... The exchange of transactions with third parties normally takes place within within a business process framework such as Rosettanet PIPs, ebXML business process schemas, or TMWG UMM. Submissions shall describe their relationship to such frameworks... Submissions may provide models which support multiple namespaces or agencies' party ID lists, e.g. DUNS numbers, industry syntax such as telephone billing numbers, etc. Submissions may support frameworks such as UDDI whitepages, ebXML addressing, or W3C namespaces or URNs as solutions for global Party Id schemes.... For purposes of this RFP, an AR/AP system is defined as that basic view or information system for maintaining, managing, paying or collecting debts, or discovery and resolving differences in amount with respect to external parties, during or after the execution of a transaction..."
See the diagram of the AR/AP Cloud and accompanying argumentation: "... It is logically unnecessary, and very inefficient, to send all of our transactions through banks. Individuals and small businesses could easily bill each other by creating receivables and payables, and allow a competitive market of settlement providers to net and offset our mutual balances on the internet. This can be purely an information process: not requiring anybody to trust any customer or supplier more than they already trust today by extending credit, not requiring anybody to maintain or exchange any actual money, become a 'deposit-taking institution' or fiduciary, etc. and not requiring that you trust any settlement agent with anything other than to maintain confidentiality. This can be accomplished purely as a matter of contractual netting, i.e., you agree to give up your receivables in exchange for having a bunch of your bills paid in the same total amount, and to maintain the difference that's left over in either direction, when it's over..."
References:
- ArapXML web site
- ArapXML mission statement
- About ArapXML and the consortium
- ArapXML specifications list
- "General Ledger Information Entities (GLIEs) Library - Requirements." Working Draft 31-January-2002. Version URL: http://www.arapxml.net/requirements31jan2002.htm. Edited by Todd Boyle and Morten Jacobsen. [cache]
- ArapXML XML Schema. Version 0.87. By Todd Boyle. [cache]
- ArapXML elements dictionary Version 087, August 20, 2001 [or later]
- ArapXML use cases - "illustrate how General Ledger interfaces improve interoperability and achieve the five objectives in the mission statement.."
- ArapXML research
- Introduction to ArapXML [PPT]
- Critical Success Factors for net accounting hosts
- Account Receivable - Account Payable AR/AP Facility. OMG Request For Proposal. April 27, 2001. [cache]
- Contact: info@arapXML.org
