[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Todd's EDIFACT ENTREC message for General Ledger
Todd Boyle took us through a little of the EDIFACT ENTREC Accounting Entries Message, showing "The total possible message layouts is Quadrillions of possible formats for each of the 6 billion people on earth." This, when you consider all the possible arrangements of segments, composites, elements and codes. Todd concludes "The fundamental problem of EDI and ebXML is that you think you can have a continuous, elastic vocabulary and grammar." Dear Todd: After all these months of harpooning the poor ENTREC and hours calculating the possible instances of ENTREC, I would've thought it possible to build a MIG (message implementation guide) of the message which would suit your purpose. There's even more combinations of English (or Dutch or French or German) words to form sentences, and we not only manage to learn to construct useful ones by the age of 4, but also to distinguish the nonsense from the sensible. The same should be true of EDIFACT messages built up from its constituent components. How many date-time constructs are useful in accounting? You tell me - I'm no accountant. But I'd venture a guess that only a few of the possibilities of the DTM segment would make any sense. Actual date instances, Quarters, years, etc., perhaps? Right off the bat, I bet you can rule out anything that specifies an hour, minute or second!! How many different types of parties are relevant to a General Ledger? You tell me again - I'm no accountant, I repeat. But I bet the NAD can identify them for the most part. Tell you what: give us a couple examples of real ledgers, and we can examine the ENTREC (why not the LEDGER?) and see if we can build a MIG that accommodates your samples. I would have thought a MIG would be available considering that someone, somewhere, had in mind what they wanted to do before they created the UNSM (UN/EDIFACT standard message), i.e., the raw skeleton that appears in the EDIFACT directory at http://www.unece.org/trade/untdid/d01a/trmd/entrec_c.htm. But in any case, examining a real-life problem like yours would be more instructive to all of us than an imaginary one like Death registration for ferreting out core components. Do they really do death registration like that described in the Core Components Discovery and Analysis Spec anywhere in the world? Any undertakers here? No?? At least we have an accountant - a CPA, no less - so let's start solving your problem. And I really don't think xCBL has solved the problem, either - if it's really a problem at all. xCBL has "a continuous, elastic vocabulary and grammar" also - witness the bloated code lists that I've already brought to your attention. William J. Kammerer FORESIGHT Corp. 4950 Blazer Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "accelerating time-to-trade"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC