This means,

"I hereby send you a copy of a transaction I have entered in my software.  Because this entry names you as the buyer, seller, giver or receiver of something with me, I am sending you a copy.  Isn't that nice?  Just in case you find this information useful.  "

This is a piece of content.  Like human speech, the recipient makes of it, whatever they want. 

You can think of this as a copy of an accounting entry.  A accounting system is a collection of real entries (UEENs) involving real exchanges with partners, and fictitious entries (accruals and adjustments which are really reporting artifacts.)

The UEEN can be sent by email (fire-and-forget), or newer, more functional messaging infrastructures.  Use cases include "I'm recording that you owe me money", or "I owe you money", "I'm recording receipt of goods", "I'm recording that I've paid you.", or any other atomic business message.

UEENs accept that smaller companies have "role compression".  The shipper, receiver, biller, etc. is often the same person.  SMEs already know how to do business, especially one-person companies.  SMEs that have one desk, are not interested in workflow or business process suggestions.  SMEs often do not perform sufficient data entry for decomposing their activities into steps. They do however have a BIG need for A) simple semantic standard, and B) reasonably reliable document delivery. These two requirements are sufficient for alignment of most, routine dealings.  That is, getting the payables, receivables and inventory entries into their computer (where the individual will almost always review them manually.) 

	Hi there. I am a bookkeeping entry, no. 36346 in Bob's books. That's a globally unique URI.   I show a positive Amount 400.00 of something. I also show a currency identifier of USD in this case. Thus, you can see I'm adding US$400 to my ledger for some reason, and, you are named as the person ...  You are named as the counterparty -the reciprocal party. That probably means I'm recording this receivable as DUE FROM YOU.  That means, this is a bill. That probably means you might want to record that you owe me money.   If this were a negative number then, you would know, I owe you money. That would mean it is an IOU. (Or, that you owe me less.  When you "pay" me then I will record $400 DUE FROM BANK. and -$400 due from you.) If this were a positive amount of some Product or Service ID instead of money, then, you would know, I think something has come into my possession, and it came from YOU.. thus, you might want to observe your inventory count and your accounts receivable. -This is a digitally signed message. To me, this is a real business event. Now, whatever you want to book in your system is YOUR business. Good bye.

Economic Events in the real world seem to break down into passive events and active events (actions). The doer of an event (active) should notify the counterparty.  The way it should work is, the recipient of an act, upon observing an un-notified act, shall have a claim to a fee for accounting :-)  just kidding... 

The semantics and choreography of today's Enterprise EAI schemas (OAGIS), B2B documents (UBL, UCC) and frameworks (BPML, UMM, BPEL4WS WebServices etc.) are like SGML: expensive and complex. The UEEN is to be atomic and lightweight.  

Here is the principle external usecase between unrelated parties.  You can see this is rather like the receipt you receive at a supermarket.  It is given by one party to the other, whether they request it or not: 

An accountant might say, "The UEEN is a General Ledger schema" since it simply represents an atomic, economic transaction. However, UEEN does not necessarily require double-entry.  UEEN provides a unified format, or information model, which is so simplistic that it doesn't preclude any type of economic event, i.e. passing a money or non-money resource into or out of control of its Owner (Self).   Since the General Ledger of an enterprise is equivalent to a collection of atomic transactions, it might very well be expressed in UEEN format.

The UEEN format may permit the root ledger to view any business application (or other original source of economic events) as a sub-ledger. A "ledger" is just a view or presentation oriented around certain  core elements such as dates, amount of money or quantity of resource, and the identity of trading partner.  

This unified format is also intended to enable the replication or entry of business data from business applications into GLs even if that data is not compliant with traditional, CDEA rules.   

Most GLs continues to insist that business data be in the form of balanced double-entries with correct account codes or other classification mechanism, before it is Posted, as entries in the trial balance.  To use the UEEN as a GL schema does not abandon classic double-entry accounting (CDEA).  However, the UEEN information model accepts, and embraces, a wider scope of information into its view e.g. economic commitments.

1.  Modern GLs should include (permit entry) of Unposted as well as Posted information.  Unposted information is subject to fewer constraints, and may include any valid business information formatted as a GL entry or entries.  "Posted" information however, is fully compliant traditional double entry GL data with account classifications.  For example, an modern GL may have a boolean "IsPosted" flag, to distinguish between real CDEA trial balance and other business reports. 

2.  Modern GLs should include economic commitments within the scope of information management and storage. 

3.  Modern GLs should Require descriptive structure and vocabulary for native transaction attributes associated with transactions and transaction entry rows, when the amounts of transactions are material.  There are a fairly manageable number of independent dimensions that recur in most economic exchanges.  Native attributes of business transactions might include

who - parties and their roles in relationship to a GL transaction (individuals as well as organization units on both sides of the economic exchange)
what - product or service or financial instrument, etc. associated with this monetary amount
when - the point(s) in time the transaction was negotiated, ordered, fulfilled, settled, entered, posted, approved, reversed, audited, etc.
where - location created, executed, posted, delivered, taxable, etc.
why - immediate purpose being duality, the expectation of reciprocal flow,
why - business purpose, budget classification, business segment, accountability, etc. and
how - applications, authority, chain of custody of the information prior to, during and after execution of a transaction

In other words, Modern GLs should require structures for party, product, location, budget, and other dimensional data within the GL.  These dimensions are the foundation for broader use of GL data in management reporting (fact table as data warehouse), as well as the automation of accounting classification.   

4.  Modern GLs should not enforce balanced journal entries (require balanced books) at time of entry of "unposted" transactions.  Acknowledges that single entries to the books are an inherent part of unfinished business processes.  Enforces, however, that a single entry must be accompanied by an identifier to its previous or anticipated, future related entry(ies).  This may include references to contract, party, collaboration instance, or other data sufficient for generating a balancing claim.   (Enforces balanced entries only as part of the  closing of books stage of the value chain.)  The suggested name for this identifier, which associates entry rows into balanced transactions, is "TransactionID".

5.  In principle, Modern GLs should require that each event (entry) be identified to the business collaboration instance, or at least, to the transaction to which they belong.  Historically, an entry was only identified (i.e. associated with) its balancing siblings in a transaction, and the composition of such entries was not normative.  Different accountants could correclty compose quite different sequences of entries to represent the same transaction.  UEEN does not solve this problem.  However, to serve as the information component in external interactions requires that events be associated with their associated or reciprocal movements,  within a collaboration, and this imposes normative requirements.  A possible, suggested name for this identifier which associates the multiple transactions within the same collaboration is "GroupID".

For example, a shipment is an event in REA for which a claim (a receivable) may be materialized at the same moment, to post a balanced accounting entry.  This shipment/receivable event needs an identifier to connect it with a later payment.  In general, all entries in a modern GL may be viewed as within transactions and all transactions as within collaborations.  Thus, the e-business community may find that the GroupID is a requirement, even though in cash-and-carry, there may be no associated transactions since both reciprocal movements occur at the same time.

6. Modern GLs should adopt standard vocabulary for a three tier general ledger meta model (transactionSet, transaction, entry row, account, etc.  This implies a standard vocabulary for resource types, which are equivalent in some regards, to accounts.)   Reasonable people disagree over the need for standardization of terminology or behaviors for these particular elements, since they typically do not occur between reciprocal parties in e-Business.   Notwithstanding, these particular elements are clearly needed in internal integration -- which is among the goals of modern GLs.

7.  Modern GLs should no longer Require the account code or classification be present at time of entry of unposted transactions, i.e., the modern GL contains data at earlier points in the business process than the point at which GAAP classifications are present or in some case possible.

8.  Modern GLs should no longer Require charts of accounts, or account codes at all, even for Posted transactions, if resource types or XBRL classifications are applied sufficiently for financial reporting objectives.

9.  Deletion of data - Many business applications, in widespread use, permit the deletion of data.  Data in systems touching customers or supporting business processes prior to execution of exchanges, often contain information which is tentative, ambiguous, and not correct.  Modern GLs should not impose constraints such as nondeletion upon native business application that find it necessary to allow deletion.  Furthermore, the modern GL may be required to reflect the deletion of data, if it is to be accurately in synch with real applications. 

The CDEA subset of an modern GL does not abandon accounting constraints such as the audit trail and other Invariants, in the 1998 OMG GL specification.    

10.  The notion of a Modern GL implies a flat row structure (NDEA cannot require 2- or 3- tier structure) - The NDEA model must function within a flat single-entry assumption.  NDEA encompasses individual debit or credit entries without any constraint for balancing, or association with dual movements or GroupID, at points in time earlier than any balancing sibling entries, dual movements, etc.   One of the usage scenarios of NDEA is support of business processes at runtime, in which atomic movements need to be recorded which do not share information with any other entry past or future. 

Even when balancing sibling entries are anticipated at a later time, it may be difficult for accountants or software applications to compose a transaction header until those future rows of data in the journal entry are known.

11.  The notion of a modern GL requires accounting entries for quantities without monetary valuation.  Actors in business processes such as fulfillment often generate data about movements of quantities of economic resources, in circumstances where valuations are not present, or available for reasons of security, expediency, system resources, etc.  Many other circumstances exist where monetary valuations of resources are impractical or impossible to determine, such as movements of assemblies prior to job costing, sale of inventory before all of its costs have been booked, etc.  

The goal of these comments is to accommodates all movements of all resources that are material; this goal is no different than the traditional goal of accounting.  It is the goal of the UEEN semantic model and "modern GL" comments, is to serve as a unified event notification whenever a commitment or economic event has occurred in any Individual or SME or Enterprise. 

The intent of these comments is to provide a very general framework for those native business applications to represent their tentative economic commitments and events in tabular UEEN views, facilitating integration, alignment of business state with trading partners, and business intelligence.  It is implementation decision whether a modern GL application maintains logs or audit trail, for deletions of unposted data. 

Here, what do you think of this?

<!-- Uniform Economic Event 
A lightweight container for any transfer (or commitment to transfer) any economic resource.
See notes at bottom. Pronounced wee. -->

<uee>
 <!-- The identities of the economic "Persons" -->
 <!-- (the individuals or organizations owning or controlling the resource.) -->
  <selfId> *****any valid URI goes here, identifying one "owner" receiving or giving something. </selfId>
  <reciprocalPartyId>***any valid URI. The other party to/from whom something is transferred. </reciprocalPartyId>
  <ueeType> 0="memo only", 1 ="commitment" or 2= "transfer" </ueeType>
  <entryId>*****any valid URI goes here, identifying this entry uniquely in the "self" ledger. REQUIRED for idempotency.</entryId> 


  <resourceDetails>
 <!-- What was transferred. Positive amounts denote increases in the assets of the "self" party. -->
  <amount>******any valid decimal number (representing money or quantity of goods/services) </amount>
  <resourceId>***any valid URI identifying the currency, or product or service. e.g. a currency code "USD" or UCC/EAN code. </resourceId>
  <measureId>*****any valid unit of measure, e.g. "25" "gold" "grams" </measureId>
 </resourceDetails>

<eventDetails>
 <!-- "E" in REA. information about the "EconomicEvent" -->
  <eventType>***a valid URI identifying the type of "commitment" or "transfer" within the two person's business context. </eventType>
 <!-- "A" in REA. The identities of the economic Agent(s) i.e. individual or organization. -->
  <actorId>***any valid Identifier of "Self" or its contact or agent or employee or any other party who committed or transferred a resource. </actorId>
  <businessActionId>***any valid Identifier of a verb within a business process, i.e. event that "happened" or was "done".  </businessActionId>
  <businessActionDateTime>***any valid DateTime. This is the execution date of an economic event, i.e., the accounting recognition date.  </businessActionDateTime>
</eventDetails>

<authorEditor>
 <!-- optional. Identities of whoever added, edited, or had custody of the information in this UEE. -->
  <authorEditorId>***any valid Identifier such as self, reciprocal party, employee Id etc. </authorEditorId>
  <addOrEditDateTime>***any valid DateTime </addOrEditDateTime>
  <addOrEditTypeId>***any valid Identifier denoting type of (Recording being very similar to a busiNess process action.). </addOrEditTypeId>
</authorEditor>

<moreXML>***any valid XML meaningful to either party, goes here. 
   <!-- whole or part of an XML business document may go here (OAGIS, UBL, UCC, etc. -->
</moreXML>
<documentId>***any valid Identifier pointing at a full document </documentId>

</uee>

<-- Uniform Economic Event representation
A lightweight container for information entities describing any economic transfer or commitment.

Every element is a URI ( see http://www.ietf.org/rfc/rfc2396.txt  )) EXCEPT: 
- the "amount" (string representation of a decimal), and 
- "dateTime" (win32 time, http://www.xml-x.org/time.html  )

Although software for resolving all types of URIs is hard, using URI's is easy. examples: 
"Bill Clinton", "978236451", or "DUNS:123456789", or "http://codelist.net/productId?21642367"
It is the users' responsibility to ensure URIs are unambiguously readable by recipient.

These information elements describe an "EconomicEvent" object within the REA economic semantics.
http://www.google.com/search?q=McCarthy+REA 
http://www.tieke.fi/sc32wg1/wg1n236.zip 
http://webster.disa.org/cefact-groups/tmg/downloads/BPWG/reference/UMM-N090R10/Chapter%208%20MetamodelR10.zip 

The goal of this schema is to lightweight communication of events over networks, storing events in small 
database systems, and presentation of multiple events as rows in 2-dimensional human readable formats
such as screens, lists, and spreadsheets. This is objective ledger alignment with the other party's ledger.
-->