[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: What do people really expect from ebXML? - Is CC really asetofLegos?
Strongly agree with Philip. > -----Original Message----- > From: Philip Goatly [mailto:email@example.com] > Sent: Tuesday, May 01, 2001 12:58 AM > > Hi Folks, > > I believe that a consideration of what data is essential in all > transactions i.e what cannot be left out in any transaction( as > defined as a > transaction in business terms) allows one to model a top down structure. > Since these pieces of data are 'essential' then they must always be > processed. It follows therefore that when one starts with this scenario, > with the 'top level data' and the 'top level processes' the data and > processes are intrisically bound together. The top levels can then be > expanded to more detail. I think there are six data aggregates in every binary transaction. 1. amount -- a currency/value pair 2. date/time -- ISO 8601 date/time formats 3. two party identifiers -- DUNS or other globally available party codes 4. what we exchange -- A text string or a complete document or contract 5. due date / when do we settle -- ISO 8601 date/time formats 6. how do we settle -- codes such as EDIFACT payment codes and terms, bank/settlement provider, IFX/OFX information, etc. I'm not optimistic that the world will agree on the last two. But the first four are pretty darn obvious. Party Ids are not always disclosed therefore, aliases sometimes apply. "sold to the guy with the yellow shirt"... but Parties are not null. This model excludes interactions that are not economic exchange events, such as exchange of catalogs. Thus, the model is tautological, and trivial. It defines a transaction as any exchange between two parties that has amount, date, and something bought/sold... then enumerates the data elements as amount, date, party ids... whoopie. Todd
Powered by eList eXpress LLC