RE: XFRML, ebXML, and the root ledger

["Liv A. Watson" <liv1@wworld.com>]

Hi,

My name is Liv Watson and I serve on the XFRML Steering Committee
representing the Institute of Management Accountants. We are very interested
in working together with all the XML initiatives to ensure success.  We are
also very interested in your feedback as soon as our spec group release
them.  I have cc Walter Hamscher and Zachary  Coffin (XFRML liaison Chairs)
on this   e-mail since they will  be able to answer some of the questions
that you have with regards how we can be working together.  Please keep in
touch and direct any other questions to either Walter, Zachary, or myself
and we will make sure they are answered.  Thanks for your interest, Liv

-----Original Message-----
From: owner-ebxml-core@lists.oasis-open.org
[mailto:owner-ebxml-core@lists.oasis-open.org]On Behalf Of Glover, Roger
Sent: Thursday, March 02, 2000 1:38 PM
To: 'tboyle@rosehill.net'; ebxml-core@lists.oasis-open.org
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