[Gnue] Re: [free-erp-dev] RE: Participation RE: [xbrl-public] XBRL book proposal

[Derek A. Neighbors]

> > 1.   use a simple schema that is completely valid and well-formed XML but
> > additionaly, can be easily converted to and from ASCII to integrate the
> > legacy small business systems.
> <DU> I think this is an important requirement but it is in tension
> with a requirement to not suffer information loss during the
> communication process.  Comunication richness = 1 - information
> loss.  How will you prevent or manage this ?
> </DU>

I am not sure I see the relationship here....  How does good formed XML
and multiFormat ready have to do with information loss?  You would think
the first half if anything would help in keeping data with integrity.

> > 2.   decide what are the natural boundaries of a general ledger.  I have
> > submitted that the scope of a GL must shrink as the number and diversity of
> > A2A integrations to business modules expands exponentially on ASPs and BSPs
> > on the internet, and as B2B transactions span boundaries of companies.  I
> > argued the scope of a rootledger included seven key requirements and little
> > else.
> <DU>  Agree with the need to define the system boundaries of the
> G/L.  Agree that many commercial vendors often have too much in
> their G/L.  Don't agree that your proposal for rootledger adequately
> addresses the needs for a business of more than trivial size.   For
> example I managed an ERP implementation for a furniture
> manufacturing company with a annual T/O of $5.5M US.  Yet they
> had complex requirements for accounting for tax, transaction
> timing, depreciation and currency exchange.  How and where
> would this have been handled in your new world?  I had a
> subsidiary in Brazil that had complex requirements that ACCPAC
> just could not handle in it's G/L - and ACCPACs ledger is more
> comprehensive/rich than your proposal .  I think you have some
> fundamental assumptions that need review.  These are:

This is why most standards fail.  They are either too encompassing or
too vague.  Those that are very complex dont get used.  Those that are
simple get customized to where biz2biz partners can do business, but
customization is needed everytime a new player steps to the table.  EDI
is a perfect example of such silliness.

In GNU Enterprise we plan to make simple GL's etc that can easily be
customized.  Then we can offer several ways to talk to biz/trading
partners through a multitude of standards..  I think this will be the
success of businesses going forward.  As in this day only supporting on
standard is almost death.

> a.  SME business is simple.  I don't find this.  Yes there is a
> correlation of complexity/number of accountant in an org/turn over
> but its not linear.  I have seen billion dollar companies who could
> use Quicken effectively and I have seen $10M T/O family
> businesses who have legitimate highly complex information
> requirements.

Often times small businesses are more complex, because their owners to
be more competitive use more "clever" business practices. :)  Also,
smaller industries are usually less regulated and have fewer accepted
"best practices".

> b.  A breakdown in the hedgemony of total package solutions
> vendors into loosely coupled point vendors in a mix and match
> strategy creates an overwealming requirement to standardize the
> attributes that classify where in an organization a transaction
> occurs (the attributes).  If we assume that a G/L is there to report
> for an organization and that boundaries of this organization are
> different for different consumers of the information (e.g. for the
> board of directors the 'organization' is the consolidated group listed
> on the exchange, for the 'GM' it is the total operational group, for
> the factory manager it is her factory)  then this supposes that all
> businesses/views are essentially consistent in all organizations.
> That is that a not for profit charity will classify things the same way
> as Union Carbide.  The traditional accounting vendors/systems
> accounts approach to this was to have metalabels like
> "Department", "Cost Centre", "Project" - of course these have
> complex mappings inside the company to their real reporting
> entities - often which are never explicitly defined or defined outside
> the ledger itself (in a reporting system or spreadsheet).  It is, infact,
> at this mapping level that the mapping complexity is transferred in
> your schema.  But you make it worse.  Rather than during set up
> match up "factory manufacturing unit" in company/system A  to
> "Production facility" in company/system B, I have to capture this
> implicit knowledge (e.g. that the second segment of the project
> code is actually an employee number in company A) and then do
> the mapping as well.  You see you have not only not solved a
> problem but you have made it worse because you are encouraging
> the loss of explicit labelling by driving people to plug into an
> artificial taxonomy for attributes.  This is just as true if I have
> quicken on one end as SAP.  There will always be a need to map
> from one G/L implementation to another or subsidiary system.
> Don't fight this but embrace it and make it as simple as possible -
> don't force the loss of information in a misguided quest for
> 'plug&play'.
> </DU>

BINGO.  This is the goal of GNU Enterprise.  We are working on data
integration tools that allow for complex mapping between different data
stores and specifications.
 
> > You guys seem to think you can sit in your private meetings and cook up
> > standards we will all happily accept.  You are wrong.   Nobody can even
> > understand your XBRL stuff.  I waste my breath, trying to get my clients and
> > other software developers, to read it.  Everybody turns away, and builds
> > incompatible stuff in python, java, and perl (GNUE, FERMS, SQL-Ledger) and
> > those are only the tip of a very large iceberg.
> <DU> Here you have a good point.  We need to have these system
> talking via a common protocol.  But really this only can solve the
> data interchange problem.  It is the 'standardize' that is the
> problem. You mean standardize at which ISO 7-layer model level?
>  Do you include the Systam, Semantics and Pragmatics in this
> standardization?  If so then we are on a fool's errand.  What you
> describe is a stalinist fantasy.  In this model all organizations
> would have to be structured the same, think the same and reort the
> same.  I think you can standardize only so far up the 7 layers
> (Physical, transport, etc) but you need to MAP the semantics and
> pragmatics bilaterially between applications and organizations to
> get the subte things correct.  Comments please.
> </DU>

I know GNU Enterprise plans to be compatiable to several standards not
internally w/in our system necessarily, but on interchange to systems. 
This is really where the importance is anyhow (IMHO).  

I will simply add this.  Programmers/Developers/Architects are very busy
at tasks at hand.  A lot dont care about the business side, but those
that do dont have the time to read through a 4 page email and respond. 
Ex: this mail has sat in my box for over a week.  Normally, I would have
tossed it, but really want partake in discussions as they are important
to GNU Enterprise.  

I would advise several shorter emails are better than one long email.  I
think you will see a far greater response. 

Derek Neighbors
GNU Enterprise
http://www.gnue.org
address@hidden   
> >
> > Therefore, XBRL's general ledger schema will be a brilliant and ingenious
> > thing, a fiendishly complex thing,  that can support two-way integration
> > between GLs and every paying vendor's business modules.  Accordingly it
> > won't just be about data.  It won't just be about accurate modeling of
> > business process, or anything else in the real world except to the extent
> > they exist within backwards compatibility into client/server designs from
> > the early 1990s.
> <DU>  I share you concern that there is a tendency to go too far
> and talk about distributed agents interoperating across networks
> blah blah blah and creating a white elephant good for Ph.D. thesis
> but not really going to be taken up.  But it is only a concern.  As
> long as the approach is pragmatic then this accurate modelling is a
> very important and valid construct.
> </DU>
> 
> >
> > I'm having great fun with this-- prove me wrong. Publish your work in
> > progress.  Publish your developers' lists.
> <DU> O.k. But you answer my points in detail and prove me wrong
> ;-) </DU>
> 
> >
> 
> > Please inform us of the approaches you are taking, in representing
> > transaction attributes within XBRL's schema for General Ledger. Will they
> > converge with ebXML core components?  Do you anticipate that these
> > attributes will be quite diverse?  Should users companies plan to publish
> > those attributes in registries and repositories where distributed
> > applications can read them?
> <DU> Even if the process is closed, it is vital that the outputs and
> workings are public.   </DU>
> 
> >
> > My understanding is that the whole transaction side of ecommerce has already
> > formed consensus on the principle of registries and repositories, and the
> > only question is whose designs will be adopted. XBRL will not succeed in
> > posting business systems other than as a compliant member of registries and
> > repositories.  In other words, XBRL GL does not fit as a "taxonomy" inside
> > your XBRL financial reporting schema, but rather, as a compliant application
> > of ebXML or Biztalk/UDDI registries and repositories.
> <DU> And while repositories are important I think you have not
> addressed the G/L schema either.  Where is the domain object
> model (the inner representation and semantics).  I DON'T mean flat
> files flying through space being stored on file servers.  I mean
> where is the mapping of Account to Department and the rules on
> how there interact, for example.   Re XBRL G/L there is a need for
> a schema to interconnect LOB  applications and G/Ls  AND to
> have the G/L schema itself.  They are two things.  Of course the
> interconnect schema is influence by what it is interconnecting.
> Thing of languages.  If I want to create a french to german
> translator I need to understand French, German and the tranforms
> from one to the other.</DU>
> >
> > I cannot imagine XBRL workgroup having the horsepower to keep up with
> > current developments on the transaction side of ecommerce.  I see little
> > evidence you recognize that transactions now traverse entity boundaries.
> >   Should accountants be scared that XBRL is betraying them?  No such thing
> > is occuring.  Rather, accountants are in the center of the biggest step
> > forward in digital reporting since internet and EDIFACT.
> > This is not about loyalty to accountants.  It is about loyalty to the 28
> > million small and medium businesses in the US who need low-cost general
> > ledger integration, low cost software, and low cost tax and accounting
> > services.
> <DU> If this is the total requirement then Microwimp is the answer.
>  Cost is only one attribute.  What about quality, flexibility, power of
> expression, relevance to their business.  BTW I have a problem of
> what is a Small and Medium business.  I have hinted at this before.
>  I see  my key concerns being those orgs too bigs for trivial
> solutions like MS/Quicken but who have been poorly serverd by
> large ERP or even mid-tier vendors like Great Plains.  These are
> good packages but they only do 80% of what isrequired and the
> ability to fork out big $$ for customization is not on - hence they
> live in the hell of complex spreadsheets and access databases.
> </DU>
> 
> ---------------------------------------
> Duncan Unwin         'consilio manuque'
> 
> address@hidden
> 
> PO Box 5023
> Kenmore South, 4069
> Australia