Version .83  -  15 May 2001

CHANGES IN OBJECT

- yesterday's new object or datatype "actor" is killed, which contained 
two elements: - "contact" of type "code", and -"role" of type "code".

"contact" would have enabled you to point at a person or party in a list, 
which you can still do with the "Code" object.  SO there will be no "contact".
 
"role" would have been another "Code" list of roles but after debating
this in telcons we question whether any GL needs to know the role of
anybody who executed, entered, approved, reviewed, etc.. a transaction.
The Owner will already know these people's authorized roles etc. and if
the Owner at the rootledger location doesn't know those roles and needs
to know them, then the best practice is to establish a broader framework
of internal control outside ArapXML.  If an owner is using a rootledger
fed by ArapXML to implement and enforce policies of internal control such
as verifying whether particular users had sufficient levels of authority
to execute transactions ascribed to them, the Owner has two choices: (1) 
assign to the transaction the highest authority of any of the mulitiple
users encoded in the entry row, even if it is ambiguous which hat they
may have been wearing when their name went into the list of "ledgerUser"s,
or (2) configure the subledger to transmit unambiguosly the role of the
"ledgerUser" on each line of entry by using the "othercodes" element.

The rootledger requirements include maintaining fiscal control over 
dealings executed on multiple different service providers.  It is 
expected that an "entry" will often be executed by, entered by, approved 
or reviewed by, etc. different actors both inside the company and/or 
outsourced business processes or software providers.  

The "ledgerUser" and "partysUser" structures provide accountability and 
audit trail over transactions at a business level.  We tentatively 
conclude "role" will not have sufficient usage to warrant having its own 
attribute in the entry line in a general ledger, and decided that 
simply allowing multiple occurrences of "ledgerUser" and "partysUser"
(increasing the maxoccurs to unbounded) is sufficient.


CHANGES IN ENTRY

- within entry, "ledgerUser" is changed to type "Code" and allows
multiple occurrences.  (The multiple people who were responsible
for the entry are iterated without differentiating what they did. )

- within entry, "partysUser" is changed to type "Code" and allows
multiple occurrences. (same as "ledgerUser".)