Re: ERP Standards

[cbbrowne]

On Sun, 24 Feb 2002 22:08:20 +0800, the world broke into rejoicing as
"Ke Deng" <address@hidden>  said:
> I agree with Todd in many aspects of what he said.I think if there's
> no suitable standards for GNUe,we could create our own standards
> referencing some existing ones.

Todd has evidently "struck a nerve;" his position certainly sat at one
pretty extreme end of opinionation, and he seems to be engaging some
"bashing" that's not totally fair.

I somewhat agree with the result, though from a quite different
perspective.

XBRL is all about _reporting_ standards.  It doesn't say what fields
there ought to be in particular accounting transactions; it instead
speaks to how the summary report at the end of the year should get
reported.  

Summarize the data, building a tree, and then do some mapping whereby
you walk that tree, generating XML elements with suitable attributes,
and you might get an XBRL document.  

There's certainly some merit in having some code and tables that could
be used to do that "walk."

But that says between zero and nothing about what fields ought to be
on the screen when entering payroll information about employees.  It
is NOT something that would reasonably have any significant impact on
the architecture of parts of GnuE other than some "financial
reporting" module.

What COULD, CONCEIVABLY, be of some value in influencing GnuE
direction would be stuff along the lines of successor schemes to EDI,
allowing quasi-standardized ways of exchanging data with business
partners.

For instance:

 - It would be nice to pull in transaction data from banks, and
   get as many ID links hooked in as possible to your own data so as
   to know what transactions have gone through the bank.  

   For instance, if you've got 4875 cheques going through each month,
   getting 4853 of them automagically matched against what you issued
   and thus marked as "cleared" so that there are only a couple dozen
   to look at manually is a BIG savings of effort.

 - It sure would be nice if you could take purchase orders sent to you
   by email by customers and automagically transform these into
   "draft" sales orders.

   Similar is true for other documents that get sent back and forth.
   If an incoming electronic form can get transformed automagically to
   generate whatever document you generate as a response to it, that
   would sure be useful.

None of the standards mentioned are much more than elliptically
related to these sorts of "EDI" functionality.

Well, that's not _completely_ fair; the OMG specs for G/L
functionality could be _slightly_ related; it provides an interface
that could be treated as a quasi-generic way of communicating with a
General Ledger.  Similarly, the "ARAP" provides a quasi-generic way of
communicating with some subledgers.

However, there's no way that such communication would take place
_directly_; a customer's data would have to get transformed fairly
substantially before committing it into your own accounting systems.

Which will be true of _ANY_ interchange scheme; it's an inherent
shortcoming to the beast.
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
Rules  of  the  Evil Overlord  #80.  "If  my  weakest troops  fail  to
eliminate a  hero, I will send  out my best troops  instead of wasting
time with progressively stronger ones  as he gets closer and closer to
my fortress." <http://www.eviloverlord.com/>