Mission 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. The ArapXML schema is designed to transport general ledger rows, in summary or detail format, as necessary. ArapXML is the solution for integration such as the blue-colored connections below (touching the General Ledger).
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 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. In some cases, the Owner will archive (replicate) full details of his business dealings that exist on his BSPs. In other cases, only summary journal entries will be posted in the master GL, and in other cases the general ledger will be only a view --a temporary data repository only for ad hoc reporting. In any of these cases arapXML is an appropriate schema. ArapXML virtualizes business transactions into a fact table of a data warehouse, or flat rows suitable for use in spreadsheets.
Please see the requirments document for further discussion, or review the draft General Ledger interface components or ARAP submission 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). The GL is that system which maintains a particular
information model based on the accounting equation. The accounting
equation is the foundation of all financial reporting: Assets =Liabilities +Owners Equity, hereinafter called ALOE. This is actually an ideology or belief, that the total of assets minus liabilities forms a residual number that is significant. Ideology or not, it is universally mandatory in all public financial statements,
corporate income tax filings, and certainly, 99% of owners require it as well. Owners require decomposition of account balances into their history, and an index for "sideways" inspection of whatever else was gotten or surrendered in connection with the exchange. If you're going to have those two entries, you'll find it is inevitable that you'll have the synthetic, balancing entry or abandon ALOE. Necessity for GL integration When multiple business applications exist, the necessity for integration into a combined view is not new. Historically, the transactions of a business flow into its GL. Newer architectures provide ALOE views of native data without replicating detail from business applications to any GL. There are always economic gains from automating these flows of information to the GL. Thousands of custom GL integration projects have been performed the past 30 years, and continue to be performed. arapXML enables the representation of any transaction based on classic double-entry accounting. It is designed for individuals and companies who use software or services from multiple vendors to conduct business. Necessity for standardization of GL integration All of the custom GL integrations in the past, have been done by connecting the particular application with a particular GL. If you are a developer, it is more economical to perform one mapping (Application to Application) than two mappings (Application to Standards to Application). Besides cost, mapping two applications against a common GL standard cannot improve your interface; instead, it can reduce performance and it can introduce the dreaded "impedance mismatches". 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. Let's say, 1000 substantially important applications. Now, it is quite clear most companies are not about to abandon their financials package, GLs, accounting software, etc. nor are those vendors planning to drop dead. There are at least 100 very substantial GLs in the world. The N-squared problem is that 1000 connections to each of 100 GLs = 100,000 individual integration projects (mappings). This is extremely wasteful of valuable development resources. OAGI has a whitepaper explaining the economics of the N-squared problem. Exchanging transactions such as payments, purchases and sales among multiple systems, and over the Internet, requires common vocabulary and protocols. Many good schemas exist for Purchases and Sales-- B2B schemas. EDI is another language for B2B messaging. ArapXML defines a common model for general ledger and A/R, and A/P integration. This is application to application (A2A) integration-- this is integration of the business modules of the same owner, the same company. Standardization around a General Ledger schema is a necessary condition for the success of e-commerce among SMEs on the internet. The lack of a standard GL schema is a critical problem for SMEs, today. A2A integration is thus, a necessary condition to the success of all e-commerce on the internet, and the viability of B2B commerce itself. SMEs (Small/Med. Enterprises) will use service providers ("web applications") to buy, sell, and pay. It is not feasible for SMEs to maintain the security and the applications on their site, to conduct real money transactions. Windows PCs are notoriously insecure. When real money is at stake, intruders will come and steal it. Continuing this reasoning: SMEs will use more than one provider. Some of their banks, customers and suppliers will control this decision. SMEs themselves, will choose multiple providers. They may operate web storefronts. Some of them will be locked into vertical applications. Some of them will reject any monolithic lock-in provider no matter how good. They will need to pull together their dealings into a single view. A coherent scope and boundaries for the GL: Owners strongly require a summarized, consolidated view of transactions for at least five things: 1. financial reporting/ GAAP financial
statements, Whenever income or expenses are executed in more than one system (e.g. LANs or the Internet), these needs arise, and a solution of some sort is required. ArapXML is designed for these minimum requirements. The five requirements above are the primary scope of arapXML. In some circumstances, GL integration cannot succeed without achieving a summarized, consolidated view for these purposes: 6. fiscal control and oversight over
multiple applications, A general ledger is not a portal play. This is about providing choice of components to small business, by enabling interoperability. This is about removing roadblocks. Before any element goes into ArapXML, the question is asked, "Is this element really necessary, to enable the owner of the company to use more than one web service or business service provider?" ArapXML engages both GL providers and providers of business applications in pursuit of a standard GL schema. General Ledger views Business applications maintain data in countless, diverse formats, optimized to meet the requirements of users. Every type of business transaction can be transformed into classic GL format. These transformations are trivially easy if finer details are neglected. When necessary, ArapXML enables finer details such as product quantities, delivery addresses of goods, or employees' ID numbers to be maintained with transactions in General Ledger tables. The leading ERP systems maintain data in GL formats having many thousands of fields. The benefits of transforming B2B documents such as invoices, payments, orders, ship notices, etc. into any unified format are very great because the transactions can be understood in consolidated views. ArapXML offers one schema, certainly not the only schema, as the unified format. Developers should adopt GL rows as the unified view, because GL data becomes highly portable. Well-established methods already exist, for consolidating and aggregating with other data from diverse applications. GLs excel as platforms for reporting, for tax and AR/AP. Solutions have been worked out which resolve many difficult legal and operational problems, in classic GL format. The human factor is considerable-- skills are available from millions of workers, called accountants. All businesses maintain accounting systems. There is a double-entry GL in every business. There are no single-entry accounting software left in the marketplace. Even Quicken is a double-entry schema in the back end. A GL is a fact table within a classic star schema. The merits of stars, snowflakes, dimensional modeling in data warehouses are discussed by Kimball and many other authors. 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. See "About arapXML" for further info about what we're doing. |
Who needs arapXML? Business applications which support many general ledgers. General ledgers which support many business applications. Local applications connecting with a web app Users having 2 or more web apps Companies with branch or subsidiary general ledgers WAP/device needing lightweight XML format Developer porting data between GLs Payments or collections services transmitting transactions Banks P2P networks anybody implementing micropayments anybody doing consolidations
|
