RE: Playing Accountant

[Todd Boyle]

> It is given that money is the common factor in business transactions, 
> thus the only practical unit of measure that can produce financial data 
> that can be compared.  Now of course you have different monetary units 
> (currencies) etc, but you can convert to make comparisions.
> 
> Here is the question.  We treat a dollar (or monetary unit) as a 
> 'standard of measure'.  However this seems like a bad thing to do.

Hmmmm...  I don't think so... 

> However, I can not say 1 dollar = 1 dollar and 1 franc = 1 franc. In 60 
> years 1 dollar = 1 dollar and 1 franc = 1 franc.
> 
> This of course is due to the voliatle nature of purchasing power. 

Well... it is due to variability in exchange rates.  Purchasing power
can be quite volatile while exchange rates remain stable.  If the 
purchasing power of all the currencies changes in the same way, 
their exchange rate might remain stable.

> Things like inflation and other factors adjust the relevance of the 
> measurement. Now it appears that accountants accept the fact that there 
> is a moving target and tend to deal with it off hand.

No, inflation does not reduce the relevance of money or the 
usefulness of business systems; if anything, the rate of inflation
or currency volatility increases the need for featureful accounting 
and reporting systems.
 
> So my question is should we allow a way to account for such factors in 
> our reporting etc??  Kind of a monetary unit restatement?  For what its 
> worth I'm not an accountant, but would like to hear opinions.

If the data itself is stored with date and currency then users can
restate and manipulate as needed.  For example, translation of financial 
statements from foreign currencies to the functional currency is a
whole set of rules that are routinely practiced in US and international
GAAP.  Let me know if you want those rules--they are fairly essential
in designing multicurrency accounting software because rules are different
for rates applicable to balance sheet and income statement amounts, etc.
As with consolidation, the legal rules impose dependencies on software
design.

GnuE software should consider the software models for monetary amounts
that are used by OMG and other standards bodies you think are relevant.
The OMG's amount is a combination of a numeric value and a currency code,
including but not limited to one of the ISO 4217 currency codes.
http://www.omg.org/cgi-bin/doc?formal/98-12-02

OAG also binds the currency with a numeric amount in a single object.
<!ELEMENT AMOUNT (VALUE, NUMOFDEC, SIGN, CURRENCY, DRCR)>
<!ATTLIST AMOUNT
        qualifier %SEG_AMOUNT_QUALIFIERS; #REQUIRED
        type %SEG_AMOUNT_TYPES; #IMPLIED
        index CDATA #IMPLIED
>
<!ENTITY % AMOUNT.ACTUAL "AMOUNT">
<!ENTITY % AMOUNT.ACTUAL.F "AMOUNT">
<!ENTITY % AMOUNT.ACTUAL.T "AMOUNT">
<!ENTITY % AMOUNT.AVAILABLE.F "AMOUNT">
<!ENTITY % AMOUNT.AVAILABLE.T "AMOUNT">
<!ENTITY % AMOUNT.APPRVORD.F "AMOUNT">
<!ENTITY % AMOUNT.APPRVORD.T "AMOUNT">
<!ENTITY % AMOUNT.BUDGET "AMOUNT">
and so forth.  Fortyfive qualifiers. 

XML Schema does not define a monetary datatype but the XML Schema
part 0 examples include this:
http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT

Deriving a Complex Type from a Simple Type  
 <xsd:element name="internationalPrice">
  <xsd:complexType>
   <xsd:simpleContent>
    <xsd:extension base="xsd:number">
     <xsd:attribute name="currency" type="xsd:string" />
    </xsd:extension>
   </xsd:simpleContent>
  </xsd:complexType>
 </xsd:element>

Money is the root element in every transaction.  Individuals and
businesses go through enormously complex value decisions, evaluating
the utility of every product and service, boiling them down to a
money amount.

Everything else in business systems is debatable but once you
agree with a third party on any monetary transaction, let's book it:

------PARTY A's BOOKS----     common   -----PARTY B's BOOKS -------
<bla>                                                         <bla>
<yada><yada>                                            <yada><bla>
<bla><bla><bla>                                     <bla><bla><bla>
<bla><bla><hare><hare>                        <bla><heebie><jeebie>
<bla><bla><bla><bla><bla>                 <bla><bla><bla><bla><bla>
<bla><bla><bla><bla><bla><bla><money><bla><bla><bla><bla><bla><bla>
<bla><hare><hare><bla><bla>             <bla><yada><yada><bla><bla>
<yada><yada><bla><bla>                     <hubba><hubba><bla><bla>
<whoopie><bla><bla>                                 <bla><bla><bla>
<bla><bla>                                               <bla><bla>
<bla>                                                         <bla>

You're solving the wrong problem by trying to disambiguate all the
bla bla's or make both parties agree on the blah blahs.  It is 
intrinsic to commerce that the perception of the goods and services
is subjective and unequal.  Forcing them to be equal, or even forcing
the particular attributes quantities and Units of Measure, is the 
beginning of a logical process which results in value destruction i.e.
loss of sales.  THe minute you say, here is a widget thats NEW and
it is higher priced becaue it has objectively a different color or
weight, BLAMMO there is no more way to differentiate in the market.
Just as soon as that product appears in the UNSPSC Barcode list and
starts trading on auction sites as a commodity, suppliers will create 
a different product that it 1/4 ounce different weight to prevent 
tracking and competition in the product,

So, what I'm saying is, YES build in robust multicurrency foundations
and know that multiple currencies exist (including currencies outside
ISO 4217, and including quantities of commodities).  And NO, don't
worry about the fact that value of the currency changes against 
the value of goods, nor against the value of other currencies.

BTW in Brazil if you're interested in real software solutions enabling
businesses to operate dealing with huge rates of inflation, they
have worked out solutions.  The US would be unable to function, the
country would be devastated--but Brazil, it's business as usual with
their software infrastructures.

tODD
http://WWW.GLdialtone.com/endredundancy.htm
http://WWW.GLdialtone.com/str.htm