[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ERP Standards
Re: ERP Standards
Mon, 25 Feb 2002 00:33:41 -0500
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
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
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
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
- 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"))
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/>
- RE:ERP Standards, Ke Deng, 2002/02/24
- Re: ERP Standards,
- RE: ERP standards, Coffin, Zachary P, 2002/02/24
- Re: ERP standards, Stanley A. Klein, 2002/02/25
- RE: ERP standards, Todd Boyle, 2002/02/25