Subject: RE: Getting Back to Basics - How to describe Dates and Times andEvents?
Kammerer said, > We always pay lip-service to UN/EDIFACT, so why not look at how it > describes events? In UN/EDIFACT, Events are described with the DTM > (DATE/TIME/PERIOD) Segment, which basically gives the event or function, > and the Date, Time or DateTime when the event occurs. You can see the > DTM at http://www.unece.org/trade/untdid/d01a/trsd/trsddtm.htm. D.E. > 2005 (Date or time or period function code qualifier) has a huge list of > every possible event known to mankind in the area of trade and commerce. Thanks Bill. There are around 700 datetime qualifiers in 2005. OAGIS uses datetime segments like EDIFACT and manages to get by with 67 qualifiers. This question http://groups.yahoo.com/group/oagis-users/message/85 got some very good followup explanations of datetime segments in OAGIS: http://groups.yahoo.com/group/oagis-users/message/86 http://groups.yahoo.com/group/oagis-users/message/87 On Wednesday I came to my senses and proposed to my employer to DROP all of our specifically-named date and accounting period elements from our General Ledger schema, that I posted sunday, and substitute the following model. (sequence) <transactionDate> <qualifier>subset-Of-Edi-2005-qualifiers</qualifier> optional <date>yyyy-mm-dd</date> <time>hh:mm:ss</date> optional <timezone>zz</timezone> optional <transactionDate> GL entries would have 1 or more transactionDate's, with these qualifiers. - transaction (execution i.e. GAAP accounting recognition) - posting (date posted to the ledger) - entry (date entered to the ledger) - accountingPeriod - paymentDueDate - clearedTheBank - modified ...and more, supporting transitions in negotiationState, etc. This provides a pressure relief valve for particular needs, without hampering small business *at all.* It supports everything we need to support for the smallest applications, just fine. FOr example, Minimal sample GL transaction <ledger> <ledgerName>125 Mainstreet</ledgerName> <Transaction> <transactionId>2352</transactionId> <transactionDate><execution><date>2001-04-01 </date></execution></transactionDate> <entry> <entryId>2352001</entryId> <accountCode>Cash</accountCode> <amount><value>234.50</value></amount> </entry> <entry> <entryId>2352002</entryId> <accountCode>Accts Receivable</accountCode> <amount><value>-234.50</value></amount> <party><codeValue>069874936</codeValue> <codeList>DUNS</codeList></party> </entry> </Transaction> </ledger> I can still parse these with coded loops to churn out flat ASCII etc. That is something I am still stubbornly insisting on. Because I will probably be the guy who has to write some of the gol darned adapters for Peachtree and other little apps. The idea is, why buy a biztalk server, or load an XML parser, if you only need a point solution? You can convert from an XML to ASCII and back, with a 15k COM object. And it doesn't need upgrades every 3 months. I'm still not convinced to support multiple 8601 datetime formats, or the xsd:datetime strings, or the EDIFACT 2379 datetime format codes http://www.unece.org/trade/untdid/d99b/tred/tred2379.htm Let somebody else advance those. It's not my karma. I differentiate these formatting issues from business vocabulary which adds to the descriptive power of the model. I welcome any XML, DTD or XSD snippets representing DateTime, and thank John McClure for posting his slices from DCN. Does anybody have some XML or XSD code representing ebXML date time??? Or, the EDIFACT DTM? Do you think we're on the right track? TOdd
Powered by eList eXpress LLC