Version .85  -  2 June 2001  changes from Version .84

CHANGES IN AGGREGATE ELEMENTS (OBJECTS) aka complex types

- the "Code" class disappears.  Replaced by the "IdType" class to conform 
with ebXML naming and definition of "identifier.type" in Core Components 
Structure.xls v1.04.  

In ebXML a "code" is not a UID.  It is an entity like an EDIFACT segment 
code or data element code.  In ebXML the "identifier" is used for stuff 
like a party, project, DUNS number etc. having discrete separate identity.

- within the "IdType" class, changes in naming were made:

   "code" becomes "idContent"
   "codeListName" becomes "idSchemeName"
   "codeText" becomes "idName"
   "language" is to conform with ebXML "code language code" (ISO 639)
   "parent" is added
   "version" is added
   "codeListUri" becomes "schemaUri" 
   "getRecordUri" becomes "dataUri" 
   "balance" enables expression of monetary total i.e. balance information 
      within dimensions such as account, party receivables, department, etc.
      "balance" is an arapXML:Money object. 
    
- the "Money" object is renamed to become "Amount" to conform with ebXML
naming.

- the "Money" object is expanded to provide a third element, "qualifier". 
This is a string.  This accommodates OAGIS and it enables many diverse 
uses.  The initial allowable values are "actual" and "original" 
i.e. stated in base currency and original or foreign currency.

- the "Account" object is dropped.  The account element becomes an "IdType".

- the "Quantity" object is added, as a container for "quantity" in 
   decimal, and "idContent", "idName", "idSchemeName", and "dataUri". 

   "quantity" is the number of non-monetary units. The identifiers are 
   your facility for representing units of measure used in "quantity". 
   They are the same as in "IdType" object. .. this brings us closer to 
   conformance with ebXML Core Components for "quantity.type".   ebXML 
   suggests that applications use UN/ECE recomm. 20 or X12-355 codes.

- the "Measure" object is added, as a container for "measure" in 
   decimal, "idContent", "idName", "idSchemeName", and "dataUri".

   "measure" is the size, volume, mass, etc. by physical measure. The 
   identifiers are your facility for representing units of measure used 
   in "measure".  They are the same as in "IdType" object. .. this 
   brings us closer to conformance with ebXML Core Components for 
   "quantity.type".   ebXML suggests that applications use UN/ECE 
   recomm. 20 or X12-355 codes.

- the "transactionFiscalType" element is shortened to "fiscalType". 
   This completes our renaming (shortening) of the names of every 
   element on the Transaction level which is not duplicated on the 
   Entry level.  The only elements that occur both on the header and row 
   are ??Id, ??Date, ??Description, ??JournalType, and ??Doc.

CHANGES IN TRANSACTIONSET

CHANGES IN TRANSACTION

CHANGES IN ENTRY

- "originalAmount" element is deleted.  

- "amount" element now allows more than one instance.  (Note above, that 
   the Amount object now supports a "qualifier", such as "actual" and "original".)

- the "blob" element is added, a URI reference to the internet
   or local filesystem, etc. for a graphic or other object.

- "unitsOfMeasure" is killed, to conform with ebXML Quantity and Measures objects.

- "quantity" is renamed "productQuantity" because the new type Quantity contains
    the element "quantity".  We have a naming rule not to repeat any name.
    
- "productMeasure" is added to conform with ebXML "measure" object.  It is a
    necessary distinction that quantity is an independent from measure, e.g. 
    100 units of 12-inch pipe, or 6 reams of A4 paper. If you're going to 
    support product and counts then, you need both quantity and measure. 

CORRECTION IN ENTRY

-  "taxType" element is added.  The type(s) of tax associated with the
    amount in the entry.  This was introduced in version .81 changeLog but 
    was omitted from the XSD in error.  Usually a taxtype attribute of 
    a tax payable; may recur unbounded.

    One or more sales tax or VAT tax codes is very common in 3rd party 
    transactions.  It may be a function of other things in the schema 
    such as party location or implicitly known by company location, but 
    quite often the "taxType" is burned into the row at creation, and/or 
    added or changed later.