From: Todd Boyle [tboyle@rosehill.net] Sent: Friday, August 04, 2000 12:05 PM To: xbrl-public@egroups.com Subject: RE: [xbrl-public] GL Schema Eric -- thank you for your comments; > Commercial and Industrial US GAAP financial statement specification > [was] delivered on Monday, 7/31. Awesome. I didn't see the announcement on http://www.xbrl.org/ or on this list http://www.egroups.com/group/xbrl-public/ > As I have stated to you before, there is a strong interest within XBRL's > steering committee membership to pursue a GL journal entry standard. > That should not be surprising, given the representation of almost every > major accounting software developer from Peachtree to SAP. To the contrary an open GL standard would be surprising. Historically, there has been no standard data format for exchange of GL entries in SMBs. Undocumented and proprietary data formats are widespread. :-) > Numerous of our members are exploring this, and considering how to > develop the specification to work within their systems and within > the XBRL framework. That is a good thing. Of course little information has been emitted by XBRL.org about the GL spec. I cannot afford the $5,000 membership fee to join XBRL.org. :-( > > By going as far down spectrum as possible, to a flat XML structure, > > we can enable a lot of integrations with accounting software that > > only support flatfiles such as comma delimited... a flat schema > > would enable processing in C or VB etc. without requiring XML parsers. > > You are correct that XSLT and other processing methods can be used to > turn a hierarchic structure into a flat one, and vice versa. An obvious > advantage to a hierarchic schema is the ability to reduce file sizes by > using inheritance to eliminate duplicative information found within a > set of journal entries. Everybody knows that hierarchic schemas reduce file size and eliminate duplicative information. However, we are talking about a schema for transporting GL data in XML, across applications and networks. The decision to use XML itself bloats file sizes by a factor of 10. The XML community says that's not a problem because compression solves it. The internet is building towards speeds that will be thousands of times greater than today, in order to distribute multimedia content. GL data is absolutely trivial. Forget about that issue. The real business cost of a flat schema structure is from potentially higher software development cost associated with the software object that talk to the flat schema. It is more convenient for some developers of business objects when the foreign data is in the same structure as their proprietary structure. For small business software that structure tends to be both flat, and simple. For big systems, it tends to be hierarchic and having many variables. ERP GLs have *thousands* of fields. The Oracle GL manual for release 11 is 500 pages of small print, approximately 1/4 of the volume of the book consists of listings of fields in the tables. The main tables are loaded with denormalized, repeating bands of rows like "PERIOD1_AMOUNT", "PERIOD2_AMOUNT",.. "PERIOD60_AMOUNT" but there are still 6 or 8 levels of hierarchy. I am really looking forward to getting ahold of a Peoplesoft manual. Our county has a brand new $43 million dollar Peoplesoft project that failed and the whole datacenter and software are mothballed--maybe I can get ahold of a manual from them. It is also more convenient for developers when data structures in memory and database are "normalized" or packaged into hierarchies that map to their OO business objects. Show me a guy with a big investment in 1990s business objects, I will show you a guy who does not want flat XML schemas. (Of course these guys are never going to agree with each other, either, since their objects dont map. Too bad their greedy CEOs wouldn't let them talk to each other about standards, during the 1990s. Now they will be predated upon by EAI middleware vendors.) The best reason not to use flat schemas is that the whole semantics of CDEA (classic double-entry accounting) may not adequately resemble the underlying reality they are supposed to represent. This is where all of us are a bunch of jackasses, braying in the morning sun, since there has been no discussion of the nature of the transactions in the first place, or whether the CDEA and A=L+OE is an appropriate descriptive model for the GAAP domain, let alone for interactive commerce. For example, I posted wild and irresponsible comments advocating CDEA over REA, the Resources, Events and Agents model on alt.accounting recently and was corrected by REA wonks: http://www.gldialtone.com/ToddREAPost.htm http://www.gldialtone.com/BobHaugenPost.htm http://www.gldialtone.com/McCarthyPost.htm All of us CPAs are like clerics in the middle ages, arguing how many angels can dance on the head of a pin. Transactions themselves are increasingly going to be generated out of multipart, asynchronous XML messages. Business software has obviously uncoupled from the "GL". What is a GL, anyway? That is the question. Business software has taken all kinds of new forms which provide great commercial advantage. Witness ariba and commerce one, covisint. And nmm.com, aspnews.com. I tried to explore network-centric accounting in my STR whitepaper. I tried to modernize CDEA and AL=OE for the net. But the REA people have already been there and said "tsk tsk". and they're right. But so am I-- my scope is narrower. see below. > There is common information shared between related entries. > That shared information may included some of the most verbose > information that would be found in a transfer > file, such as the description of the reason for the entry. In a > hierarchic structure, that information does not have to be repeated for > each line in a journal entry; it is passed down from parent to child > within a related set of entries. This does not need to be repeated in rootledgerXML files either. It may be transmitted once, in the first row where it applies. For example, certain designated fields such as the Company and TransactionDate will apply to all lines of a journal entry in this specification. Many other fields such as Party will be transmitted only in the row to which it applies, e.g. Party will appear in the accounts receivable and the sales row of a journal entry but not in the rows related to sales tax, cost of goods sold, etc. for that transaction. As they say, XML provides syntax but not semantics. The usage of the elements in any XML schema are always defined by the application, in this case, the STR webledger. I will be glad to discuss changes to the rootledgerXML schema with any application vendors outside of XBRL, if your companies allow you to do that. > As a non-XML-aware product will not understand XML tags (even in a > flattened XML file), I am not sure I understand the benefit you are > trying to express. As MSXML.DLL, the Microsoft parser, ships for free > and is included with IE, I would think that developers using DOM or Sax > with C or VB should provide a superior solution for working with XML > than trying to filter through the XML tags without it. XML parsers are great for some people. I happen to believe that they dont belong on drive C: or even on the company LAN for the forseeable future, because of the complexity and the rate of churn in the standards. XML will sell more new software than anything since the transition to 32-bits, or the transition to the GUI. If you're a small business, and you start down this XML path you will be replacing and updating your parser, your browser, your applications and even your OS. OK that's fine but not when you're FORCED to upgrade a lot of employees desktops and workgroup servers every year just to stay in business. So let's allow the more frugal companies to simply retrofit their literally millions of vb, foxpro, delphi, etc. applications. They can parse XBRL General LEdger with simple string parsers if 1. reasonably limited number of elements, 2. flat or nearly flat structure, and 3. all elements, or at least not a mixture of elements and attributes. There have already been published a number articles with source code for parsing XML data into objects, in AOVB adviser, Component advisor, and internet and other magazines. Obviously this code will scream, compared with XML parsers, especially compared with XSLT which is quite slow. When GL schemas become standardized, validation would be built into these ledger XML parsers. Easy stuff. > In reviewing your DTD, there are some fields/functions that are part of > many mid-range products' general journal function that I would > appreciate your help with identifying or incorporating into your DTD. > Some of these include: > > Auto-creation of reversing entries, including reversing date and amount > Auto-distribution codes, for later allocation based on code > Correcting entries for expanded cash flow statements These are undoubtedly good and valuable fields to some applications. I don't see a problem adding these as additional, optional fields. They don't bother me; in fact there are several excellent sources for ideas for further additional fields such as EDI and OAG. http://www.unece.org/trade/untdid/d99b/trmd/chacco_c.htm http://www.unece.org/trade/untdid/d99b/trmd/entrec_c.htm http://www.unece.org/trade/untdid/d99b/trmd/ledger_c.htm http://www.openapplications.org I'm not trying to be facetious; the problem is identifying what is the PURPOSE of the XBRL General Ledger schema? I don't know what XBRL's purpose is, since you never publish. However the goals of rootledgerXML are stated throughout my website: a rootledger should be designed minimally, to provide those minimum core business purposes which cannot be achieved any other way in an environment of distributed processing. In plain english, small businesses will use multiple BSPs (business svs provdiers) to pay, to bill, to be billed, to purchase, etc. All of this will work splendidly for their intended purposes, but unless all the BSPs on the internet start integrating with each other, SMBs will require a root ledger someplace for these purposes: 1. fiscal control/internal control, 2. cash flow/cash management, 3. consolidated views of accounts receivable and payable, 4. financial statemts/ financ reporting, 5. tax reporting, 6. consolidations and eliminations, and 7. foreign currency translations. Thus a rootledgerXML schema should work to achieve mostly a downstream reporting objective, the statory GAAP domain, and management reporting. This is very close to the purpose of XBRL taxonomies. It is really a trivial afterthought, almost. I am *not* interested in establishing a rich or deep programmatic ledger interface, to control the behaviours of a GL from a remote application. The three items you mention imply behaviors of the GL; ok that's fine, no problem with me. OAGIS has already got a Post_Journal spec which has been designed exactly for that purpose, and implemented for every leading ERP and some midrange systems. In other words, SMBs are not going to create transactions with that level of functionality on any BSP or ASP or 3rd party application anyway. They are going to do those things inside their GL and not thru the XML interface. Similarly, SMBs are NOT going to sit in front of their rootledger and create transactions for submission to their payments or billing or payroll supplier on the internet. It is true, you might do that on NetLedger but the messages will not be rootledgerXML they will be vertical application XMLs. > You have Employee; would this field be used for Vendor if it was > payables related or Customer if it was receivables related? Well honestly I have not worked out any usages of the Emp,Vendor, Cust. etc. fields. Personally I think they are not correct models, anymore than the Account Code. I think the Account code has been obsoleted by XBRL taxonomies. But most GLs have columns for Emp, Vendor,Cust, Account Codes, and Product. You are aware that a flat GL table can be viewed as the fact table within an OLAP hypercube, i.e. a data warehouse? It would be capable of amazing reports, self-joins, etc. just with the existing columns. I endeavored to follow Ralph Kimballs' suggestions for reporting hypercubes, much more than EDI or OAG approaches. Why? Because reporting is the purpose of the system for which the rootledgerXML schema was published. Rootledger is nothing but an XBRL repository plus a couple of things you left out of XBRL, i.e. cash flow etc. Hell I don't know maybe you included sufficient fields for cash flow, in all those thousands of elements. Why would a rootledger be anything other than an XBRL repository? > Is TransactionDateTime the same as desired posting date (as opposed to > EnteredDateTime, when the entry was entered)? Do you suggest another field for EnteredDateTime? Fine with me. I just don't happen to have run across a need for it in my particular experience. My experience is certainly not complete/comprehensive. By the way you are aware that there are MANY datetimes in the problem domain. Here are some OAGIS has enumerated Whew. Then they needed more so they added this: > Likewise, would product be used for invoice numbers or other identifiers > if not inventory related? Invoice Number. Not a bad idea. Well, I provided a field for that, in the rootledgerXML schema, maybe it is insufficient? "Reference source doc. number or index, etc. " > Is one "account" field, without segmentation, suitable? What do you propose? Segment 1, Segment 2, Segment 3 etc? Fine with me. > Posted/unposted status? > Out of balance status? Those seem to be good candidates for adding to the schema. > I know you have seen these entries as part of my prior DTD. Do you feel > these are not necessary? I was embarrassed at getting up to 43 fields and waited for anybody else to comment, basically. You could always use the 5 generic T-codes. > Again, thank you for spending time in trying to progress toward faster, > easier, and cheaper methods of exchanging business reporting > information. This is the goal of XBRL as well. Thank you todd out