OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: XFRML, ebXML, and the root ledger


Todd <tboyle@rosehill.net> wrote:
> The XFRML workgroup http://www.xfrml.org is nearing release of its 
> vocabulary for financial reporting.  (I am not associated with XFRML.)
> 
> This is XML for GAAP (Generally Accepted Accounting Principles)
> for financial statements in the U.S. i.e. for statutory reporting
> for publicly listed companies as well as SMEs.  See the website for 
> draft tag sets and demo applications.
> 
> I understand XFRML workgroup are actively considering at this time, 
> the issue of flatness vs. hierarchic structure in their schema.  Any 
> comments on that?

Last month I attended an XFRML presentation by John Woodburn, one of the
leaders of the XFRML effort.  He did not mention "depth of hierarchy" as one
of the major outstanding issues, but the talk was not really pitched toward
XML experts.


> The significance of the XFRML release may be far reaching. For example,
> it will be inevitable that definitions or usage of the vocabulary 
> must be forthcoming from the AICPA in some fashion; in the past
> the definitions of GAAP terminology (although legally binding), were
> copyrighted by FASB and cost hundreds of dollars.  
> 
> Financial data in XFRML format may enable automation of downstream
> processes such as tax returns, and all kinds of boutique financial 
> analyses beyond the financial statements. The need to publish and
> manipulate financial statements in multiple formats (.doc's, .html, 
> edgar, excel, .txt, .ppt and so forth) will certainly be reduced. 
> 
> ASPs and accounting systems that can effectively store transactions 
> in a way that is mapped to XFRML tags, will obviously deliver better
> reports out of the box.

In the Q & A session, John disavowed any near-term goals for the XFRML group
itself beyond those directly linked to financial reporting (and USA
financial reporting at that).  However, he did say that they consciously
aimed for broad applicability, in the hope that their effort would be
influential in other financial DTD/Schema standardization efforts.


> ebXML workgroups should consider the interrelationship between your
> XML Schema for General Ledger and downstream XML such as XFRML that
> emanate from the resulting transactions.  

Again, it sounds like this sort of consideration is exactly what the XFRML
team is hoping would happen.


> I don't claim to have any easy answers but suppose you release, as
> did OAG, an XML spec calling for an Account Code (here are the OAGIS
> elements in JELINE with their content models:)
> 
> GLNOMACCT, BUSNAREA?, COSTCENTER?, DEPARTMENT?, DESCRIPTN?, DIVISION?, 
> ELEMENT*, FUND?, GEOGRAPHY?, GLENTITYD?, ITEM?, PRODCTLINE?, 
> PRODORDER?, PROFITCTR?, PROJACTVTY?, PROJECT?, PROJRESEL*, 
> REASONCODE?, REF*, SALESORDID?, UNIT?, WAREHOUSE?, WORKORDER?
> 
> The notion of an "Account Code" may be obsolete; the Chart of Accounts
> has historically been overloaded with multiple uses. It has often been
> an intricate, denormallized table combining values such as org. structure
> and department, with accounting classifications.  Chart of Accounts
> has served multiple needs including ease of keypunching, internal
> control, reconcilation with external entities, and downstream
> reporting.  No wonder Charts of Accounts are an unmanageable mess.
> 
> Account codes need to be burst out into several different attributes
> representing their real uses. General Ledgers should not have 
> "Charts of Accounts" in future.  Chart of accounts is supposed to
> be the classification choices for the GAAP domain. That's called 
> XFRML, in the U.S. now isn't it?  Do you see what I mean?

I am not an accountant, but I believe I am catching the highlights.
Nonetheless, a little more exposition on the "Chart of Accounts" mess would
be useful.  Especially I would like to see an enumeration of the processes
facilitated in the paper document world, and suggestions for better serving
those processes in the XML world.

[remainder snipped, because I had no comments]


-- Roger Glover 
   Norstan Consulting 
   * E-mail: Roger.Glover@NorstanConsulting.com
   * Office: +1-612-352-5718 
   * FAX:    +1-612-238-5718 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC