gnue/docbook/GNUeModuleGuide/chapters introduct...

[Neil Tiffin]

CVSROOT:        /home/cvs
Module name:    gnue
Changes by:     Neil Tiffin <address@hidden>    01/08/26 10:25:51

Modified files:
        docbook/GNUeModuleGuide/chapters: introduction.sgml 

Log message:
        Revise section for current definitions of Money and Quanitity.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/docbook/GNUeModuleGuide/chapters/introduction.sgml.diff?cvsroot=OldCVS&tr1=1.5&tr2=1.6&r1=text&r2=text

Patches:
Index: gnue/docbook/GNUeModuleGuide/chapters/introduction.sgml
diff -u gnue/docbook/GNUeModuleGuide/chapters/introduction.sgml:1.5 
gnue/docbook/GNUeModuleGuide/chapters/introduction.sgml:1.6
--- gnue/docbook/GNUeModuleGuide/chapters/introduction.sgml:1.5 Sat Mar 31 
15:39:40 2001
+++ gnue/docbook/GNUeModuleGuide/chapters/introduction.sgml     Sun Aug 26 
10:25:51 2001
@@ -758,58 +758,33 @@
 have the business layer see ``virtual auto increment fields'', so
 a module writer doesn't have to know about this at all. (I wonder,
 why I write this here, anyway).
-
       </para>
     </sect3>
     <sect3>
       <title>Money</title>
       <para>
-Amounts of money will not be stored as decimal(9,2) because there
-are some countries (e.g. in the middle east) where there are 3 digits
-after the decimal point. I would suggest to use a signed 64-bit-integer, unless
-the database does not support that. In that case, decimal(18,0) would
-possibly be appropriate for every currency of the world.
-In either case amounts of money would be expressed in the smallest unit,
-e.g. in US-Cent, in British Pence, in German Pfennig and so on.
-</para>
-<para>
-There would of course be a currency table in which per currency is
-defined how many digits are after the decimal point, and how calculated
-amounts in that currency are to be rounded (e.g. in Switzerland amounts
-are rounded by 0.05!).
-</para>
-<para>
-Be sure to document clearly whether an amount of money is in local
-currency or in foreign currency. For each column with foreign currency
-amounts, there should be a column specifying the according currency
-in the same table.
+Money is now defined as a base object in the currency module.  It
+is defined as a 64 bit integer with an implied decimal point.  So if
+the integer value was = 1234567 and the implied decimal point was 3,
+the actual amount of money representated will be 1234.567.  Also a
+currency must also be defined for any money objects.
       </para>
     </sect3>
     <sect3>
       <title>Quantity</title>
       <para>
-The quantity of different goods and services is measured in different
-units, so columns storing quantities must be flexible enough to be able
-to deal with every practically used unit.
-</para>
-<para>
-I would recommend decimal(12,3).
-</para>
-<para>
-For each quantity field, it should be stated clearly in which unit this
-quantity is measured (by naming the column which specifies the according
-unit).
-</para>
-<para>
-Non-decimal fractions of units (e.g. hours/minutes) should be avoided
-where possible.
+Quantity is now defined as a base object in the unit module. Like
+currency, a quantity is defined with a 64 bit integer, an implied
+decimal point and a unit of measure.  If the unit of measure is
+"each" then "each must be defined in the unit object of the unit
+module.
       </para>
     </sect3>
     <sect3>
       <title>Codes</title>
       <para>
 Codes (that means the user-visible key to auxiliary tables) will be
-char(8) consistently, which will enable the user to make the codes
+char<8> consistently, which will enable the user to make the codes
 meaningful and easy to remember.
       </para>
     </sect3>