1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>GnuCash Project Goals</title>
<meta name="description" content= "The Linux GnuCash project
aims at creating a world-class personal finance package.
Goals include ease-of use, double entry, OFX support,
charts, and reports, and multi-user support.">
<meta name="keywords" content= "linux, OFX, accounting, finance,
financial, ledger, double entry, GPL, gnu">
</head>
<body bgcolor="#d6dacb" fgcolor="#000000">
<div align=center><a href="http://www.gnucash.org/" target="_top">
<img border=0 width=470 height=62 alt="GnuCash Personal Finance Manager"
src="GnuCash_Long.jpg"></a><br>
</div>
<h1>GnuCash Project Goals</h1>
<p>
The people behind <a href="http://www.gnucash.org">GnuCash</a>
aim to create a world-class GPL'ed Open Source Personal
Financial Application for GNU/Linux and other Unix's. This page
reviews some of the technical issues and development status
surrounding this project. It is a kind of an <b>FAQ</b> for
developers and contributors, providing status, and suggesting
directions and technologies for deploying new features. If you
simply want to get a better idea of what <a href=
"http://www.gnucash.org">GnuCash</a> is and what it does, visit its
<a href="http://www.gnucash.org">home page</a>. The home page
contains screen shots, news items, and mailing list
archives.
</p>
<p>
There are currently several different versions of GnuCash.
We've adopted the kernel numbering scheme: even minor release
numbers (1.4.x, 1.6.x) are considered to mark stable releases,
while odd numbers (1.5.x, 1.7.x) mark development releases.
</p>
<ul>
<li>The current stable, production release is gnucash-1.6.0 and
is based on the <a href= "http://www.gnome.org">Gnome</a> /
<a href= "http://www.gtk.org">GTK</a> libraries.
</li>
<li>The 1.7.x releases focus on adding new features and
improving existing functionality.
</li>
</ul>
<p>
The latest version is available only via CVS. Occasionally,
some of the more stable CVS versions are given a version number,
and packaged as a precompiled deb or RPM install package. Naive or
beginning users should probably stick to version gnucash-1.6.0.
More adventurous users can try one of the 1.7.x releases, However,
keep in mind that they are in a state of constant change and will
often be unstable.
</p>
<p>This document is divided into several sections.</p>
<ol>
<li><a href="#arch">Architectural Goals</a></li>
<li><a href="#reqs">Requirements</a></li>
<li><a href="#size">Sizings</a></li>
<li><a href="#feats">Features</a></li>
</ol>
<hr>
<!--===================================================-->
<a name="arch">
<h1>Architectural Goals</h1>
</a>
There are some over-reaching design principles and philosophies
that we intend to maintain. Some of these concepts and terms
are introduced in this section.
<h2>Separation of GUI and Data</h2>
First, we must maintain a clean separation between the data
structures and the GUI that manipulates them, along the lines
of the <b>Model-View-Controller</b> paradigm.
<ul>
<li>Lists of accounts and the transactions in them can be
thought of as a representation of financial data, a
<b>Model</b>.
</li>
<li>The GUI that adds, modifies and deletes these should be
thought of as a manipulator of the data, a <b>Controller</b>.
Thus, the Motif or Gnome GUI's are merely two possible
manipulators of the data; others, based on <i>e.g.</i>
web/cgi-bin, Qt/KDE, emacs, Java applets or Java servlets
ought to be possible.</li>
<li>The <b>View</b> of the data is a subset or slice of the
data described by the Model. The View may consist of only the
transactions for the month of May, or only the account totals
for certain accounts. The View is used in part to generate
the reports and graphs, but it is also that which the
Controller interacts with. Views are generated by queries to
the data store.</li>
</ul>
<p>
GnuCash also needs to deal with multiple distributed data
sources: stock quotations from the net or transaction
confirmations from online banks and brokerage houses, or from
more mundane sources, such as file imports, or merger of data
from several users. Amongst these terms, the concept of a
global Model-View is dated, and somewhat inappropriate. Rather,
we need to be concerned about how data is represented in the
local address space of the GUI, how the GUI manipulates it, how
data is brought in and merged from external sources, and how
that data is again output, whether to a file or a local or
remote database.</p>
<p>
Thus, the <b>View</b> essentially represents a local data
cache of the data that is immediately present and being
displayed, reported, and manipulated. The <b>Model</b> is the
abstraction of that data that the GUI (the controller) can act
on.</p>
<h2>The Financial Engine</h2>
In GnuCash, the Model is implemented via the <b>Engine</b> API,
and the View is the data that is currently in the <b>
Engine</b>. Thus, the Engine is a set of programming API's that
the GUI (or a script, or even a clever command-line-addict) can
use to manipulate the data.
<p>
Currently, the Engine provides basic accounting structures
These include: </p>
<ul>
<li><b>Transactions</b>, which consist of a set of 'splits'
or journal entries (JE's) whose values sum to zero.
The transaction includes several date fields, a description,
and a common-currency field, and a universal unique id
(uuid/guid). It also provides hooks to store arbitrary data
associated with the transaction (using a URL-based key-value tree).
</li>
<li><b>Journal Entries</b> (internally referred to as
'splits') which an amount and the account on which it is drawn.
Splits also store reconcile status, dates, a memo field,
and also a key-value based hook for arbitrary data.
</li>
<li><b>Accounts</b>, which include a nme, a type, a description
field, and the type of commodity they store. Principlally,
the account consists of a list of journal entries.</li>
<li><b>Chart of Accounts</b>, which is a hierarchical tree of
accounts.</li>
</ul>
The Engine has a basic two-phase commit model, and a
query mechanism for finding the data needed for reports and
views. The goal of the two-phase commit and query model is
allow the creation of multi-user server based backends, such
as an SQL backend, and RPC client-server backend, or an
XML-based HTTP/web backend. This design seems to work
for the above-named backends.
<p>The Engine currently handles only a basic set of data
sources:</p>
<ul>
<li>It can import and merge in QIF's (actually, this function
has been moved into the GUI, and is no longer part of the
engine);
</li>
<li>It can read and write its own XML byte stream;
This ability has been used to provide a multi-user
client-server demo (which is currently broken).
</li>
<li>It can use a Postgres SQL database as a datastore, thereby
enabling multi-user and auditing functions.
</li>
<li>It can talk, via RPC, to a gnucash server. (This code is
'alpha' and incomplete/broken).
</li>
<li>It can get stock quotes from the net (actually, this
function is provided by a separate module, the Finance::Quote
perl module.)
</li>
</ul>
<p>
However, since the Engine is meant to be the interface
between the GUI and the financial data, it is really intended
to be able to do much more.
In particular, it should be possible to create a peer-to-peer
network model, where gnucash peers can synchronize data between
themselves. The engine should also be expandable to handle other
sources of data, such as OFX/IFX, the Open Trading Protocol, or
the OMG CORBA General Ledger submission. In particular, it
should be possible to use GnuCash not only to view data from
these sources, but also to manipulate it and send it back.
</p>
<h2>Modularity, Extensibility and Customization</h2>
<p>The above structure should lead us to view GnuCash not so
much as a tightly integrated application, but rather as a loose
confederation of component objects, libraries and interfaces.
This has a number of advantages for both the deeloper and the
user. For the developer, it allows parts to evolve semi-independently
of one-another, and to be used in other, non-gnucash projects.
For the user, a good extensibility allows the use of
<a href="#arrangements">arrangements</a>: a way of broadly
customizing the appearence and behaviour of gnucash, and then
allowing users to very easily share these customizations with
one another. Such arrangements might be collections of canned
reports, e.g. for business or home user. Or they might be
the menu contents: one menu arrangement is for gbeginners, another
for 'power users', a third for business owners. Th goal is that
broad areas should be not only customizable, but it should be
possible, even easy, to trade these customizations between users.
</p>
<p>
In order to facilitate the gluing together of these parts, as
well as simplify the questions of customizability, change and
rapid development, GnuCash makes use of the
<a href= "http://www.swiss.ai.mit.edu/projects/scheme/index.html">
Scheme</a> extension language (as implemented in the FSF
<a href="http://www.gnu.org/software/guile/guile.html">Guile</a>
interpreter), to glue the pieces together. (Note that the
engine interface is also available with
<a href="http://www.perl.org">Perl</a> interfaces, thanks to a
<a href="http://starship.skyport.net/crew/beazley/swig.html">SWIG</a>
wrapper.
</p>
<h2>A Web Browser for Financial Data</h2>
<p>More and more finacial data is moving onto the web.
People shop on-line. They pay bills on-line. There are
even some promising e-wallet systems (such as
<a href="http://www.webfunds.org">WebFunds</a>). For GnuCash
to be relevent in this on-line world, it must be able to interact
with these systems. There are several steps that can be taken
along this path. First, it must be possible to simply and
transparently import financial data off the web. Click on a QIF
file, mime-type "application/x-qif"? Gnucash sucks it in without
burping. But, in a more distant future, can GnuCash originate
transactions? It should be able to!
</p>
<p>
GnuCash can be and should be "The Sophisticated Financial Web Browser".
All GnuCash reports and the help system are HTML-based. In fact,
GnuCash has a built-in web browser that can view ordinary web sites.
Interactive gnucash components such as the bar and pie charts, or
the graphs and reports, can all be served up by a remote web server,
as well as locally through the GnuCash application. This allows
GnuCash to blur the line between web browser and financial application,
and offer the best of both worlds.
</p>
<p>
Why is this a good thing? One can always have a pure web-based
accounting solution (such as SQL-Ledger) that uses ordinary web
browsers to view the financial data. But there are problems:
dynamically-generated html and cgi-bins aren't as pretty or easy
to use, or as fast, responsive or sophisticated, as what you can
do with a custom client. That is, GnuCash can be more interactive,
easier to user, slicker and more professional looking in style
and presentation than a plain-old dynamic website. Financial
ASP's simply cannot currently offer the kind of utility, flexibility,
responsiveness and integration that GnuCash can offer.
</p>
<p>
In theory, the 'Java revolution' was supposed to provide this
function, with downloadable Java applets providing the 'fancier-
than-plain-html' interface. But a Java applet that is this
sophisticated would also be large and slow to download:
it offers no inherent advantages over native code. Another
problem with Java is the inherent propreitary fragmentation:
no two Java applets are alike: every site has thier own; there
is no standardization.
</p>
<p>
In order to solve the 'no gui standardization between websites'
problem, there are a number of businesses that have arisen to
provide "financial aggregation". You sign up with these sites,
and let them get all of your credit-card, bank and investment info,
and they can provide a unified interface for your bank statements,
with graphs and reports (all for a monthly fee). The existance of
these services highlights a problem: the inability to aggregate
the same data on the users desktop, in a simple, coherent fashion.
Let us posit that GnuCash, with the right on-line interfaces,
would be a natural for this. For the paranoid,
this has the added advantage that no one business has access to
all of your financial records.
</p>
<p>
To put it another way, GnuCash can provide a centralized, trusted
store for financial data that no other application can provide.
The convenience
factor: if you have trading accounts at e*trade and charles schwab,
then GnuCash can be the central place where you can oversee
<b>all</b> of your investments. The trust factor:
maybe you can trust your web bank. Maybe you can trust your web
stock account. But can you trust a single web entity with *all*
of your financial data? Someone who won't treat you as 'just
another consumer' and sell your 'consumer profile' to anyone who
cares to stalk (ahem, target) your financial activity (ahem,
purchasing) patterns? Didn't think so. Of course, you
*could* use some proprietary financial software. Assuming, of course,
that you trust it not to have any built-in covert channels:
nothing that might send back the make and model of your CPU and
the last ten transactions 'home to mommy' for 'diagnostic purposes'.
Because open source software, such as GnuCash, can be audited
it can be trusted in ways that no proprietary software can be.
In an increasingly net-connected world, the ability to build
trust through audits will be increasingly important.
</p>
<h2>Looking Into the Future</h2>
Things like support for OFX, and small-business features are
hopefully in the near term future of gnucash. Lets take a look
at some more far-out possibilities.
</p>
<dl>
<dt><b>E-Wallet</b></dt>
<dd>An e-wallet, just like a real wallet, stores cash. You
can use that cash to pay freinds or businesses. Just
like a real wallet, an e-wallet should not charge you
monthly fees. It should provide you with some measure
of anonymity and privacy. An e-wallet should also do
something no ordinary wallet can do: show you a monthly
report of expenditures. GnuCash should get e-wallet
features. </dd>
<dt><b>Authentication, Authorization and Access Control</b></dt>
<dd>How does an on-line merchant know that you are who you say
you are? How can you use GnuCash to authorize a bill payment?
Sooner or later, smart-cards will provide the sort of
authentication and access control that is only groped for
with PGP/GPG, keyrings, x.509 certificates, and Microsoft
Passport/Hailstorm. Of all the electronic things in the
electronic world where access control and authentication
are important, real money is the most so.
</dd>
<dt><b>Bill Presentment, Bill Pay</b></dt>
<dd>These magic keywords just mean that a merchant wants to
send you a bill, and wants you to go to thier website to
pay that bill (they want your eyeballs). Of course, for
the user, it would be more convenient to have the bill
show up on the desktop, inside of gnucash, and get authenticated
and paid out from the desktop (by gnucash), as you would
do with all of your other bills.
</dl>
<hr>
<!--===================================================-->
<a name="reqs">
<h1>Requirements</h1>
</a>
Lets take a look at who the current and potential future users
of GnuCash are, and how they might use it. The classes:
<ul>
<li>Basic Household Accounting/Budgeting</li>
<li>Personal Stock Portfolio Management</li>
<li>Personal On-line Trading (Day-Trading)</li>
<li>On-line shopping and bill-pay</li>
<li>Small Business Users</li>
</ul>
These different applications may use some of the same
financial terminology, and hopefully might share a fair
bit of code, but have quite different goals and requirements.
<h3>Basic Household Accounting and Budgeting</h3>
<p>Important properties of a personal finance system
include:</p>
<ul>
<li>Approachable and usable by occasional users
who are not knowledgeable about accounting.</li>
<li>Ease of use and simplicity is critical.</li>
<li>A reasonable selection of reports, graphs, charts, and
tools for personal finance, such as mortgage
calculations.</li>
<li>Budgeting support needs to be targeted at <em>naive</em>
users.</li>
<li>Interfaces to on-line banking, shopping, stock
systems. Bank and credit-card statements should
arrive 'automatically' and always be up-to-date.</li>
</ul>
<h3>Personal Portfolio Management</h3>
<ul>
<li>Support for management of stock portfolios that may
involve considerable sophistication, since individuals
commonly have retirement plans that hold mutual funds,
stocks, options, bonds, and the like.</li>
<li>Reporting infrastructure needs to simplify handling of
tax issues (long-term vs. short-term capital gains/losses,
cost-basis FIFO accounting, simplfied cost-basis
spinoff/merger handling). Need on-line updates of
prices, simple portfolio overview, ability to link
to websites for additional research.
<li>Integration with on-line trading systems. This could
save time typing.
<li>Basic Audit features. There's a problem with blindly
allowing on-line data (prices, transactions) to enter
GnuCash. It may not be clear where it came from,
and even if the source is beleived to be 'reputable',
there still may be factual errors in the data. Thus,
there must be a way of audting newly-arrived (or even old)
on-line data, and mark it as 'reconciled', i.e.
manually reviewed and checked for accuracy. That is,
incoming on-line data must be auditable, and audit
trails should mark the history of on-line data import.
</ul>
<h3>Small Business Needs</h3>
<ul>
<li>With a business system, it is likely that there will be
users who use it eight hours a day, which puts the emphasis
on <em>efficiency</em> of user interface rather than on its
approachability to naive users.</li>
<li>Business systems require network support, and the ability
to support multiple simultaneous users.</li>
<li>Some business users may want access to the system from an
MS Windows 95/98/NT box. For these folks, a web-based
interface could be just handy. Web interfaces are also nice
a for ASP type deployment.</li>
<li>
Small businesses do not often have sophisticated investment
portfolios; they instead need support for additional
sophistication in such areas as:
<ul>
<li>Customer and Vendor Lists; Invoicing</li>
<li>Payroll (Batch processed and individual)</li>
<li>Inventory Control & Asset Management</li>
<li>Amortization Schedules, Depreciation</li>
<li>Shipping and Receiving</li>
<li>Accounts Receivable, Accounts Payable (A/R, A/P)</li>
<li>Credit Card Processing</li>
</ul>
</li>
<li>Support for calculations associated with accrual
accounting.</li>
<li>Ambitions for the future might include interfaces to
online shopping carts, credit card clearing interfaces, and
ERP systems.</li>
</ul>
<h3>Reconciling Those Needs</h3>
<p>A seemingly contradictory factor is that the kinds of
sophistication that are required vary considerably.
Consider:</p>
<ul>
<li>A home user does not generally require most of the
sophistication of accrual accounting that is
required by business enterprises. Thus, home users don't need
<em>much</em> of the sophistication of an Accounts Receivable
or Payable system, or the <em>bizarre</em> depreciation
policies that crop up in Asset Management systems.<br>
<br>
</li>
<li>
On the other hand, home users are in increasing need of
surprisingly sophisticated financial tools for managing
stock portfolios, including:
<ul>
<li>Mutual funds</li>
<li>Retirement savings plans, with such identifiers as
401(k), IRA, Roth IRA, RRSP, or Insurance Annuities</li>
<li>Corporate stock purchase plans</li>
<li>Corporate option plans</li>
</ul>
</li>
</ul>
Another set of contradictory requirements has to do with the
back-end, and interfacing to other systems:
<ul>
<li>Home users need a simple-to-install, simple-to-maintain
system. This essentially rules out the use of SQL for the
storage medium/back-end for home users. (That is, the current
state of the art for SQL on Linux does not offer any simple,
fool-proof management for data).</li>
<li>By contrast, non-SQL systems for business use are almost
unimaginable. SQL provides a high degree of data integrity
and storage robustness, and also simplifies tremendously the
import and export of data. Powerful SQL tools exist that can
work magic in the hands of a good DB admin.</li>
</ul>
<p>It may be that these will require <em>completely</em>
different systems, and that GnuCash cannot be "all things to
all people." This remains to be seen.</p>
<hr>
<!--===================================================-->
<a name="size">
<h1>Sizings</h1>
</a>
This section attempts to guess how hard it would be to
implement certain features.
<h2>Personal Financial Application</h2>
Below are listed the technical work items needed to implement
the features that home users might hope to have. They are
listed in approximate order of priority.
<p>The right hand column shows a sizing guesstimate. pm ==
person-months. These sizings are meant to show 'effort needed
to complete', rather than 'total effort required'. Thus,
half-finished items have smaller sizings.</p>
<ul>
<li><b>Done</b> The work item is essentially completed</li>
<li><b>Small</b> 0 to 4 pm</li>
<li><b>Medium</b> 3 to 12 pm</li>
<li><b>Large</b> More than 12 pm</li>
</ul>
<table border="1" summary= "Personal Finance Functionality Requirements">
<tr>
<th>Feature</th>
<th>Sizing</th>
<th>Responsible</th>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td><a href="#i18n">Internationalization</a></td>
<td>Done</td>
<td>-</td>
</tr>
<tr>
<td><a href="#reports">Reports</a></td>
<td>Medium</td>
<td>Stimming/Gribble</td>
</tr>
<tr>
<td><a href="#graphs">Graphs</a></td>
<td>Medium</td>
<td>Guppi/Gribble</td>
</tr>
<tr>
<td><a href="#query">Transaction Query</a></td>
<td>Small</td>
<td>Linas/LewisMoss</td>
</tr>
<tr>
<td><a href="#ledger">Simplified Ledger</a></td>
<td>Done</td>
<td>-</td>
</tr>
<tr>
<td><a href="#glitz">Themes, Icons, Glitz</a></td>
<td>Small</td>
<td>Various</td>
</tr>
<tr>
<td><a href="#misc">Miscellaneous Small Tasks</a></td>
<td>Done</td>
<td>Various</td>
</tr>
<tr>
<td><a href="#alerts">Alerts, Recurring & Scheduled Transactions</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#budget">Budgeting</a></td>
<td>Medium</td>
<td>Dave</td>
</tr>
<tr>
<td><a href="#classes">Classes/'Action' Field</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#book">Books, Accounting Periods</a></td>
<td>Small</td>
<td>Linas</td>
</tr>
<tr>
<td><a href="#check">Check Printing</a></td>
<td>Small</td>
<td>Grib</td>
</tr>
<tr>
<td><a href="#wizards">Wizards</a></td>
<td>Small</td>
<td>Dave, Bill-qif</td>
</tr>
<tr>
<td><a href="#arrangements">Arrangements</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#userpref">User Preferences/Session Mgmt.</a></td>
<td>Done</td>
<td>?</td>
</tr>
<tr>
<td><a href="#quickim">Quicken(TM) QIF Import</a></td>
<td>Small</td>
<td>Gribble</td>
</tr>
<tr>
<td><a href="#iifim">IIF Import</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#quickex">IIF Export</a></td>
<td>Small</td>
<td>Grib</td>
</tr>
<tr>
<td><a href="#currency">Multiple Currencies</a></td>
<td>Medium</td>
<td>Rethink Requirements-Linas</td>
</tr>
<tr>
<td><a href="#architecture">Architecture Review</a></td>
<td>Small</td>
<td>RLB, Dave</td>
</tr>
<tr>
<td><a href="#testing">Automated Test Suite</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#quote">Stock Quotes, Price Quotes</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#install">Install</a></td>
<td>Small ?</td>
<td>?</td>
</tr>
<tr>
<td><a href="#double">Forced Double Entry</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#401K">401K etc.</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#searchdocs">Searchable Documentation</a></td>
<td>Done</td>
<td>grib</td>
</tr>
<tr>
<td><a href="#reconcile">Reconcile Auditing</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#note">Annotate with Investment News</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#loan">Loan and Mortgage Calculators</a></td>
<td>Small</td>
<td>Dave</td>
</tr>
<tr>
<td><a href="#overdraft">Overdraft Alerts</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#tech">Technical Stock Analysis</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#sink">Depreciation, Sinking Funds</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#ofx">OFX, Online Banking, Trading,
Bill-pay</a></td>
<td>Large</td>
<td>Dave</td>
</tr>
<tr>
<td><a href="#tab">Tab-delimited ASCII export</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#tax">Tax Preparation</a></td>
<td>Large</td>
<td>?</td>
</tr>
<tr>
<td><a href="#palm">Sync with Palm Pilot
organizers</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#emerg">Emergency Records Organizer</a></td>
<td>Small</td>
<td>?</td>
</tr>
</table>
<h2>Small Business Features</h2>
Features that small/medium businesses expect.
<table border="1" summary=
"Business Functionality Requirements">
<tr>
<th>Feature</th>
<th>Sizing</th>
<th>Responsible</th>
</tr>
<tr>
<td>
</td>
</tr>
<tr>
<td><a href="#engine">Enriched Engine, Financial
Objects</a></td>
<td>Large</td>
<td>?</td>
</tr>
<tr>
<td><a href="#sql">SQL I/O</a></td>
<td>Done</td>
<td>Linas</td>
</tr>
<tr>
<td><a href="#multiuser">Multi-User Support</a></td>
<td>Small</td>
<td>Linas</td>
</tr>
<tr>
<td><a href="#addressbook">Address Book</a></td>
<td>Small</td>
<td>?</td>
</tr>
<tr>
<td><a href="#arap">A/R, A/P Accounts Payable,
Receivable</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#payroll">Payroll</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#invoice">Invoicing</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#estimate">Job Costing</a></td>
<td>Medium</td>
<td>?</td>
</tr>
<tr>
<td><a href="#expense">Expense Accounts</a></td>
<td>Large</td>
<td>?</td>
</tr>
</table>
<hr>
<!--===================================================-->
<a name="feats">
<h1>Features and Functions</h1>
</a>
This section reviews the current status of various features.
Some of these are 'in process', some are 'almost done', some
are 'completely done'. This section thus provides status on
both where we've been, and where we're going.
<dl>
<dt><a name="i18n"><b>Internationalization</b></a></dt>
<dd>
All menus, markup and help-text should be
internationalized, so that GnuCash may be usable in any
country. This would include the printing of currency values
in the local country conventions.
<p><b>Current status:</b>
Essentially Done (?)
<ul>
<li>All GUI messages currently use GNU <tt>gettext()</tt>
for the message catalogs. Translations exist for English,
British, French, Swedish, German, Japanese.</li>
<li>Help pages available only in English and French.</li>
<li>Monetary and string handling done through glibc. The
latest glibc (2.2.3) is needed to get the correct
functions.</li>
<li>Yannick Le Ny <y-le-ny@ifrance.com> traduction
en francais</li>
<li>Most GUI input elements use the gtk text widget, and
thus use the XIM input method in Asian locales. This
allows <i>e.g.</i> Kanji, Katakana support. However, the
register does <em>not</em> use XIM, and thus doesn't
currently support the Asian languages. This needs
fixing. (This may be done already??)</li>
</ul>
</p>
</dd>
<dt><a name="reports"><b>Reports</b></a></dt>
<dd>
A variety of reports, including Net Worth, Balance Sheets,
and Profit and Loss statements. These should be printable:
that is, exportable as HTML as well as print-ready
postscript. These should be easy to customize. Ideally,
even novice users should be able to create custom reports.
<p>The Report Generator should be a separate but "dockable"
subsystem of the whole. That is, it should be possible to
run the report generator in a stand-alone, read-only
fashion without having to start up the main application. It
should be possible to run reports nightly from a
command-line and/or cron job.
The GUI should remember what reports were run last time, and
these should be re-run/redisplayed whenever the report generator
is used.
</p>
<p>One difficult aspect of reporting is designing a
configurable interface, so that people can build custom
reports. The <a href="xacc-reports.html#NEWREP">New
Reporting Infrastructure</a> is seeking to build this up
using Guile. Note there are several flavours of customization:
<ul>
<li>Allow user to specify a custom logo (e.g. company
logo/address) on every page
(generically, having a header and footer for every page).
<li>Allowing user to modify report title/subtitle on the fly
(and possibly add notes at the top or bottom of the report,
e.g. to explain line items).
<li>Allow user to use the <a href="#query">transaction query</a>
interface to pick the set of transactions that will make up
the report.
<li>Memorize the report that was asked for, give that report
a name, and in the future, allow that same exact report
to be re-run. Allow user to edit this report properties
at a later date. Note that the basic idea is similar to
that of <a href="#query">memorized queries, discussed below.</a>
</ul>
Note that the customization info should be stored in a
<a href="#arrangements">Arrangements File (see below)</a>.
</p>
<p>Generated reports should be exportable to other gnome
systems (probably using bonobo).
Reports should also be exportable to
the Gnumeric spreadsheet (probably by writing out gnumeric
file format). Export of CSV (comma separated values) and
tab-delimited formats (for other spreadsheet import) would
be good. Tables & etc. should be exportable to AbiWord,
StarOffice, other word processors. (formats: docbook sgml?
would then make convert to richtext, TeX easy.)
Export should be as wysiwyg as possible.
</p>
<p>Must be possible to e-mail reports (for example,
invoices) to users. Suggest an evolution addressbok
/mailer bonobo plugin.
</p>
<p>
Relationship to budgeting not clear ...
</p>
<p>Stock portfolio tools should include a Cost Averaging
report, Market Index report, Stock Option values,
Estimation of capital gains tax liabilities.</p>
<p>Reports should be printable to printer (postscript/
Adobe Acrobat).
<p>
<b>Status:</b>
<ul>
<li>A general reporting infrastructure was implemented in
Perl, in the form of html-embedded perl (ePerl). However,
this reporting mechanism was abandoned in part because
ongoing build and install problems related to ePerl and
swig. Also, since ePerl didn't participate in the
interpreter even loop, the report generator had to run
as a separate process, reading data via pipes. This was
uglier than some folks liked.</li>
<li>A general reporting infrastructure has been <a href=
"xacc-reports.html#NEWREP">implemented in Scheme</a>.
Currently, there are a variety of reports for Profit/Loss,
Balance Sheet, and portfolio valuation; none are
particularly sophisticated.</li>
<li>Done: Reports are displayed with the gtk-html widget.
This widget provides postscript printing and Acrobat
output.
</li>
<li>There is currently no way (no longer any way??) to
generate reports from the command line ...</li>
<li>While many reports have been implemented, there is
no master list of what we should have. We should have ....
</li>
<li>The following technologies were rejected/unused mostly
because they were too complex, didn't hang together technologies:
<a href= "http://www.oasis-open.org/cover/">SGML</a> and <a href=
"http://www.oasis-open.org/cover/xml.html">Extensible
Markup Language - XML.</a> In the long run, these are
preferable to HTML, since <a href=
"http://www.jclark.com/dsssl/">DSSSL</a> tools such as <a
href="http://www.jclark.com/jade/">Jade (James DSSSL
Engine)</a> can be used to convert to RTF, Postscript, etc.
Add to this the consideration that XML is the basis for the
<a href="http://www.w3.org/DOM/">Document Object Model</a>,
which is being integrated into many web-based applications,
and we can see that XML is an increasingly significant
format as we look to the future.
</li>
</ul>
</p>
</dd>
<dt><a name="graphs"><b>Graphs</b></a></dt>
<dd>
<p>Provide support for graphs, charts, etc., such as:
Asset allocation pie chart, portfolio value vs. cost,
ROI. Graphs should be printable to printer.
Graph generation should be fully integrated with reporting,
both for data collection via queries, and for displayed
output.
</p>
<p>
<b>Status:</b>
<ul>
<li>Different graphing packages were evaluated,
<a href="http://www.gnome.org/guppi/">GUPPI</a>.
Guppi was chosen. Considered & rejected were
plotutils, gnumeric graphing code (Miguel says
they'll replace gnumeric code with guppi.)
Miguel's/Gnumeric requirements were:
interactive plot editing -- each segment attributes
totally settable/controllable -- drag/move callbacks
when segments are click-dragged.
</li>
<li>Basic pie charts and bar charts are used in GnuCash
reports. There are problems: dates along the bottom
of a bar-chart are not well-spaced/autoscaled.
The over look is a bit klunky.
</ul>
</p>
</dd>
<dt><a name="query"><b>Transaction Query</b></a></dt>
<dd>
Allow user to build (complex) queries to locate a
set of transactions that match some criteria: e.g.
a date range, or a matching payee, description, amount,
etc. Once a user has created a complex query, it
must be possible to memorize it (i.e. give it a name,
and store it for future reuse).
<p>
<b>Status:</b></p>
<ul>
<li>The query engine has been implemented (as of 1.4.0,
grib)
</li>
<li>The GUI for creating queries has been implemented
(as of 1.4.0, grib)
</li>
<li>The queries are handled by the Postgres SQL backend.
(as of 1.6.0, linas)
</li>
<li>Queries can be turned into XML and back, for file
storage or network transmission. This used to work
for XML version 1 but was broken in version 2.
</li>
<li>The ability to memorize queries has <b>not</b>
been implemented and awaits further action (needed
for reports, above).
</li>
</ul>
</dd>
<dt><a name="ledger"><b>Simplified Ledger</b></a></dt>
<dd>
Ledger should look clean, work easily.
<p>
<b>Status:</b></p>
Essentially done.
<ul>
<li>Multi-line ledger confusion fixed by using correct
left-right journal display style.
Fixed in 1.6.0, Peticolas, Champaigne.
</li>
<li>
Stocks and Mutual funds are handled by placing them each in
their own account. Each account can be viewed individually.
If all of the stock accounts are children of a master
trading account, then the trading account can be viewed and
modified in a General Ledger window.
Layout problems fixed in 1.6.0.
</li>
<li>
How to most simply allow the user to enter loads and fees?
Through multi-line transactions. Seems to work well in
1.6.0.
</li>
</ul>
</dd>
<dt><a name="glitz"><b>Themes, Icons, Glitz</b></a></dt>
<dd>
A variety of finer touches need work:
<ul>
<li>
<p><b>Hint-of-the-Day</b>. A collection of a some
50-100 hints-of-the-day: short (2-4 sentence)
hints/tips on how to use gnucash. Every time the user
starts gnucash, an new hint shows up ...
<b>Status:</b> Hint infrastructure complete (RGMerkel,
version 1.4.0). Need to add
hints (only a dozen are currently available).
</p>
</li>
<li>
<p><b>Themes</b>. Some theme testing required. The
effect of themes on the register window needs to be
reviewed. Some themes look flaky in the main account
window, might be a gtk bug ???</p>
</li>
<li>
<p><b>Household Assets/House Inventory</b>
Add wizard to walk user through a set of questions
about household inventory & help user value them.
(do you own a house? appraised value? mortgage?
do you own jewelry? appraised value? etc.)
In particular, show how appreciation
and depreciation should be treated.
See the section <a href="#arrangments">Arrangements</a> for
a discussion of the customization issues.
</p>
</li>
<li>
<p><b>More account types</b> Introduce more
'fundamental' account types: (amortized) Loan,
Mortgage, ESOP, House, Line of Credit.</p>
</li>
<li>
<p><b>Register View</b> Allow user to view only
non-reconciled transactions ...</p>
</li>
<li>
<p><b>Configurable main-window Status Bar</b> Bottom of
main window currently shows total asset, and total
income-expense (profits). Make this configurable, so
that user can show arbitrary sums of arbitrary
accounts.
This is mostly solved by having the MDI interface
have reports, and the use of multi-paning. But the
default display for gnucash should be changed to
show a very small (1-4 line) networth and P&L report,
and maybe a cash-flow report.
See the section <a href="#arrangements">Arrangements</a> for
a discussion of the customization issues.
</p>
</li>
<li>
<p><b>Dockable Registers/ aka "Browser Mode"</b>.
Currently, when each new register opens, it opens in a
new window. An alternate style would be to 'dock' the
register window in a bigger frame, and just have
'backward/forward' buttons to navigate through
different registers (the way that a browser navigates
web pages.) This of course would be a user
preference. Possiblity for doing this exists with MDI.
Maybe we shouldn't bother doing this ?? </p>
</li>
<li>
<p><b>Context sensitive help</b>. When users
create new accounts, need to suggest stuff if the user
typed something unexpected ... (<em>e.g.</em>
non-alphanumeric input) ...</p>
</li>
<li>
<p><b>Folder Tabs</b> Currently, Income/Expense
accounts can be shown or hidden by selecting from a
menu. It would be nice to be able to examine different
account types (Asset, Liability, Income, Expense,
Payables, Receivables, Inventory) by selecting a tab
folder. This is maybe a bs. request that shoudn't
be implemented.</p>
</li>
</ul>
The following have been completed, but possibly not fully
documented:
<ul>
<li>
<p><b>Pop-up Calendar</b> All date fields should pop up
a calendar widget; selected date should get entered in
field. (peticolas, version 1.4 ??)</p>
</li>
<li>
<p><b>Pop-up Calculator</b> All price/amount fields
should pop up a calculator widget; output of calculator
gets entered in field. Instead of a popup calculator,
this was implemented by allowing all fields to take
algebraic expressions (plus, minus, times, divide).
(rlb ?? version 1.6.0)
</p>
</li>
<li>
<p><b>Button Bar</b> A user-configurable button-bar.
Solved in version 1.6.0 with tabs, not buttons, via
gnome MDI (gribble, version 1.6.0)
See also the section <a href="#arrangements">Arrangements</a>
for a discussion of the customization issues.
</p>
</li>
<li>
<p><b>Currency Exchange Table</b>
Keep a currency exchange-rate table. This is now
automatically handled via the 'price database'
(rlbrowning, version 1.6.0)
(the finance::quote perl module handles currency
exchange rate fetches)
</p>
</li>
<li>
<p><b>Currency Selection Pop-up</b> Currency field
should get replaced by menu of long-hand currency
names, three-letter ISO 4217 abbreviations, and symbols.
User should be able to hand-enter non-IS4217 currencies.
<b>Status:</b>
Done in 1.4.0
</p>
</p>
</li>
<li>
<p><b>Cut-n-paste</b> Cut-n-paste of whole transactions
in the register window... <b>Status:</b> Done. (by Dave
Peticolas, in 1.4.0)</p>
</li>
<li>
<p><b>Auto-completion</b> Quick-fill should also
auto-complete amount, memo fields.
<b>Status:</b>
Done in 1.4.0, Dave Peticolas
</p>
</li>
<li>
<p><b>Autoincrement</b> Check numbers should
auto-increment. Hit + key in check number field
(same keystroke as in quicken).
<b>Status:</b>
Done in 1.4.0, Dave Peticolas
</p>
</li>
<li>
<p><b>Navigation</b> Menu navigation using the keyboard
should be possible. Hit the Alt-F to get file menu,
hit Alt-FS to save.
Similarly, tab-key navigation in the register
should be possible.
<b>Status:</b>
Done (in 1.3.x ?, Dave & all, partly inherited via gtk
widget set.).
</p>
</li>
<li>
<p><b>Fly-Over Help</b> When the user pauses the mouse
over a button, "fly-over" pop-up help windows should
appear.
<b>Status:</b>
Done (in 1.3.x, inherited via gnome/gtk widget set).
</p>
</li>
<li>
<p><b>Grayed-out Form Help</b> Create grayed out
entries in the ledger, titled "Memo", "Description",
etc, helping users understand what should be typed into
each field. <b>Status:</b> Done (by Dave?), as of version
1.3.2(?)</p>
</li>
<li>
<p><b>Key Bindings for Editing Text Fields</b>. The input fields
use the gtk text widget, which provides key bindings that
are similar to the Netscape/emacs key bindings.
This allows <em>e.g.</em> emacs-style ctrl-a,
ctrl-k to do the right thing.
<b>Status:</b>
Done (in 1.3.x, inherited via
gnome/gtk text widget).</p>
</li>
</ul>
</dd>
<dt><a name="misc"><b>Miscellaneous Small Projects</b></a></dt>
<dd>
A variety of small internal projects. All have been
completed as of 1.6.0
<ul>
<li>
<p><b>File Format</b>. Rework to use text file format. Will be
XML-based.
<b>Status:</b> RLB, LewisMoss. Version 1.6.0 Done.
</p>
</li>
<li>
<p><b>Reconcile Window</b>.
Auto-pay credit card when reconciling credit card
accounts (Done, Dave).
Auto-add bank fee when reconciling bank accounts.
(Not done?, Dave).
</p>
</li>
<li>
<p><b>Print Register Window</b>. Output register window to
printer.
<b>Status:</b> Done: there is a register report which
is printable, there is botton on register. Done in 1.6.0
</p>
</li>
<li>
<p><b># of decimal places in prices (penny stock)</b>.
Part of the big numeric overhaul. Done, Gribble, others,
version 1.6.0
</p>
</li>
<li>
<p><b>gtkhtml</b>. Move to gtkhtml from gtk-xmhtml.
Done in 1.5, Grib.
</p>
</li>
<li>
<p><b>print</b>. Print reports, etc. Done in 1.5, Grib.
This came 'for free' with gtkhtml.
</p>
</li>
<li>
<p><b>key-val pairs</b>. Add generic key-slot mechanism
into accounts, transactions, journal-entries. Done in
1.5.0, Grib.
</p>
</li>
<li>
<p><b>guid in fileio</b>. No longer relevant with new file
format. Dave.
</p>
</li>
</ul>
</dd>
<dt><a name="book"><b>Books, Accounting Periods</b></a></dt>
<dd>
Ability to close the book at end of the fiscal year. This
consists of several steps:
<ul>
<li>Permanently lock some transactions as non-editable.
This should be straight-forward by using the <tt>
reconciled</tt> field to indicate a <tt>locked</tt>
value, and not allowing the GUI to edit locked
records.
</li>
<li>Transfer the Income minus Expense for the book period
to an equity account, so that each new period starts with
zero income/expense balances.
</li>
<li>A mechanism to purge really old transactions from the
database.
</li>
<li>Extensions to querying and reporting infrastructure ...
The query changes might be painful ...
</li>
<li>
A user should be allowed to 'delete' an account <em>
only</em> if it has no transactions in the currently
open book.
Of course, it's not deleted from the old books.
From this last, we conclude that every chart of
accounts should have a beginning and ending date (that
match the book period), and the file format needs to
support multiple charts ...
</li>
<li>Memorized Transactions ... Currently, transaction
auto-completion works by auto-completing with the last
'similar' transaction. This ability will get trashed
when books for the old year get closed, because there
won't be 'similar' transactions.
</li>
</ul>
<p><b>Status:</b>
<ul>
<li>A mini-design Doc exists in <tt>src/engine/extensions.txt</tt>
A far more extensive, four-part proposal is ??? somewhere
in the mailing list archives (by Linas Vepstas, circa Feb-May
2001)
</li>
</ul>
</p>
</dd>
<dt><a name="check"><b>Check Printing</b></a></dt>
<dd>
Create a check-printing ability. Include MICR (Magnetic Ink,
Computer Readable) check printing abilities.
<a href="http://dir.yahoo.com/business_and_economy/shopping_and_services/financial_services/banking/checks/">
Yahoo Check Printing</a> provides a list of vendors & printers.
<p>
Print vendor/client/payee address on the check (so that check
can be mailed with window envelopes.) This requires gnucash
to integrate with addressbook.
<p><b>Status:</b>
<ul>
<li>More check formats need to be supported.
<li>Done, except for address part, in version 1.4.0.
(gribble)
</li>
<li>Need a sample check/sample transaction to print out
so that user can test printer.
<li>MICR Fonts are available & brought to mailing list.
</ul>
</p>
</dd>
<dt><a name="wizards"><b>Wizards</b></a></dt>
<dd>
Create a set of wizards to walk through some of the more
complex tasks, such as new user setup, account creation,
QIF import, budget prep, obscure functional corners.
<p>
Wizards are great, but lets not thow away the denser GUI's.
For 8-hour-a-day users, the wizards can be irritating.
A single, dense screen can be more efficient and nicer.
So when adding wizards, don't dump GUI's !! (instead,
make them 'advanced' features).
<p>
<b>Status:</b>
The following not done:
<ul>
<li><b>Account Creation</b>
The account creation panel is somewhat busy. Maybe
could use a wizard?
</li>
<li><b>Budget Setup</b>
Setting up a budget.
</li>
<li><b>Obscure Corners</b>
Various obscure corners of the application may be
non-intuitive, and need wizard help. e.g. stock splits?
e.g. using foreign currency on a business trip?
</li>
</ul>
<b>Completed:</b>
<ul>
<li>
<b>New User Setup</b> Provide
a default Chart of Accounts, which will mostly consist
of a default set of 'Categories' (Income/Expense
Accounts). These are categories such as "Automobile
Expense", "Bank Interest Income", and "Employment
Income". The user should be able to select a default
set of accounts, and have those created
automatically. Profiles: home-owner vs. renter
non-for-profit (some non-profits are very very simple,
just a club). Done in version 1.6.0, C. Champagne,
J LewisMoss
</li>
<li><b>QIF Import</b>
QIF Import is just complicated enough that it needs
a wizard walk-through of the steps. Grib,
version 1.6.0, Done.
</li>
</ul>
<p></p>
<dt><a name="arrangements"><b>Arrangments</b></a></dt>
<dd>
An "application arrangement" is the defining look-n-feel of an application.
The idea is similar to, but not the same as 'skins'/'themes'. Its similar
to, but not the same as allowing a user to set 'preferences'. Its similar
to, but not the same as, allowing a user to generate customized financial
reports. In the context of GnuCash, a 'arrangement' should be a file
(that can be traded by users, uploaded and shared) that controls important
aspects of how the application is configured.
<p>
In particular, the GnuCash Arrangement should include the following:
<ul>
<li>A list of sample/initial accounts. These might be tailored for a
home user (groceries, gas, electric), an apartment dweller
(rent, laundry), or different kinds of business users.
Because these sample accounts appear in the Arrangement file,
it becomes easy to create & distribute customized arrangements.
<li>A list of pre-defined reports and graphs. The kind that you'd find
for a home user might be different than for a person managing a stock
portfolio, which is in turn different from what a business might need.
The Arrangement File should include install-specific customizations, such
as the report headers, footers, etc.
<li>Hint of the day. The types of 'hint of the day' would be different
for new users, than it would be for advanced users. Thus, different
arrangements would have different catalogues of 'hint of the day'.
<li>Menu Contents & Navigation. New users might be presented with a simple set
of menu contents. 'Power Users' might be presented with deep, nested
sets of menus, with oodles of features.
<li>Register Layout. The layout of the register might be customized for
different countries: e.g. in Germany, a different type of electronic
banking seems to require the display of account numbers in separate
columns in the register.
</ul>
A good arrangement infrastructure will not only allow gnucash to be configured
for different application domains, but also will allow users to fine-tune
thier own prefered arrangement. It can also simplify the code base:
instead of having two products, a home-user application, and a small-business
application, each with a different code base and #defines and what not, instead,
we have one code base, and different arrangments for each.
However, most importantly, the arrangments should be easy to share between users.
They should be such that users are encouraged to trade and use arrangments,
and to create new ones that suit thier needs.
</p>
<p>
The idea for arrangements was inspired by
Adam Curry's commentary on
<a href="http://adamcurry.editthispage.com/stories/storyReader$161">
radio formats and Napster</a>.
</p>
<p>
<b>Status:</b>
Not started. Individually, all these cusomizable things exist
here and there in gnucash, but they cannot be shared between
users: a gnucash user cannot mail her favorite 'arrangement'
to her freind.
</p>
<dt><a name="userpref"><b>User Preferences, Session Management</b></a></dt>
<dd>
A dialog system and file format for manipulating user
preferences. Preferences include things like default
currency, register layout and colors, etc.
<p>What are some of the competitive preference-handling
technologies? Lets get some URL's here ... Following the
Unix tradition, there is no global preferences registry.
Note that session management and preferences are related
things ... sort-of. Right now, we don't treat them as such
...</p>
<p><b>Status:</b></p>
Done, more or less, version 1.6.0.
<ul>
<li>Works real good; lots of preferences in the GUI.
Implemented in home-grown scheme. (version 1.4.0,
rlb)</li>
<li>These are saved in the '.gnucash/config.auto' file.
The current file format is raw scheme code, rather
delicate to tweak by hand ...</li>
<li>Session management mostly works, but doesn't use the
sawmill/gnome/X ICCCM system. GnuCash remembers MDI
based reports, restart reopens in same state. Sizes
and shapes and positions are remembered.
Done in version 1.6.0
</li>
<li>Independently of session management, the register
windows should remember how big they were last time they
were popped up, and they should pop up the same size, again.
The app should remember these sizes from invocation to
invocation. Done in version 1.6.0, but seems a bit buggy.
</li>
</ul>
<br>
<br>
</dd>
<dt><a name="architecture"><b>Architecture Review</b></a></dt>
<dd>
The application is wired together partly with C, partly
with Scheme. The architecture of the wiring and how scheme
is fit in needs to be reviewed, with a general overview
created so that additional extensions may be added in a
straightforward manner.
<p>The overall architecture is envisioned thus:
All code, including the transaction engine, the file I/O
routines, the menus, and the ledger, will be abstracted
into compact modules that can function independently of
each other. At the highest level, there will be a
infrastructure with extension language interfaces that will
"wire together" the various modules.</p>
<p>Such "wiring together" will consist of a dispatch
infrastructure that will allow arbitrary menu entries to be
hooked to arbitrary modules. The configuration for menu
entries, and their associated callbacks, will be specified
in an extension-language configuration file. At the final
stages, it is <em>highly</em> desirable to be able to, in
some manner, import new modules <em>without</em> requiring
that the application itself be recompiled and relinked.</p>
<p><b>Status:</b></p>
<ul>
<li>
Scheme/Guile is the central extension language. Guile
interfaces auto-generated using g-wrap.
</li>
<li>
Optional interfaces to the data engine (for, e.g.
perl) can be generated using
<a href= "http://starship.skyport.net/crew/beazley/swig.html">
SWIG</a>.
</li>
<li>
Dave to collate & edit architecture documents.
RLB to provide diagrams.
</li>
</ul>
<br>
<br>
</dd>
<dt><a name="alerts"><b>Recurring Transactions, Calendar Alerts,
Scheduled Transactions</b></a></dt>
<dd>
(1)Add support for automatic, recurring transactions, <em>
e.g.</em> mortgage payments, fixed-interest bonds, regular
salary checks, regular gas/phone/electric bills, <em>
etc.</em>
<p>(2) Recurring bills, salary income, etc. are simpler to
handle, since they don't have interest rates, balloons,
etc. They do/will have multiple splits (<em>e.g.</em>
payroll gross, fica, futa, income taxes, payroll net).</p>
<p>(3)Provide list of upcoming & recently paid
bills/scheduled payments/scheduled deposits for the next
1,2,3,6,12 months. Historical view shows payments crossed
out (!?)</p>
<p>(4)Loans & mortgages are one of the more complicated
recurring transactions. Typically, there might be a years
worth of smaller payments, then a long string of larger
payments, followed by a balloon.
</p>
<p>(5)Provide a calendar-display of upcoming & past
scheduled payments. Clicking on a calendar day should raise
up editable list of transactions. Calendaring should
include generic red-lettering of important dates: taxes
due, insurance renewal dates, domain registration renewal
dates, ISP contract expiration date :-). These may or may
not be associated with transactions. Memo's should be
possible. Pop-ups should happen when dates get close.
Technology: best bet is the Ximian Evolution Calander
component.</p>
<p><b>Design Notes:</b> Most alerts & data storage
should be driven out of the engine. This will enable
multi-user, distributed use. <b>Note:</b> alerts should be
piggy-backed on a general alert infrastructure within the
engine, viz, registered callbacks when balances change, so
that windows can be redrawn. Not clear on if/how calendar
events might be server-ified. (On the other hand, a good
calendar should be server-ified, and thus viewable by
secretaries, co-workers, etc.)</p>
<p>More complex financial instruments may need a
guile-based extension mechanism to compute values ....
simple interest/mortgage calculators should be done in C in
the engine ... (<em>e.g.</em> depreciation schedules ...
under us tax law, a variety of different schedules are
allowed ... )</p>
<p>May need interfaces to email for emailed alerts.</p>
<p>Plot forecast graphs based on scheduled income &
payments ... is this tied into budgeting ????</p>
<p><b>Status:</b></p>
<ul>
<li>Need to create design doc, need to implement engine
pieces, need to hunt down gnome-calendaring bonobo.</li>
<li>Preliminary work started.
</ul>
<br>
<br>
</dd>
<dt><a name="budget"><b>Budgeting</b></a></dt>
<dd>
Ability to create a budget (<em>i.e.</em> - estimates of
future expenditures). Reconcile actual expenditures against
future expenditures. Create simple, step-by-step 'financial
plan' budgeting GUI's:
<ul>
<li>Home purchase planner</li>
<li>Retirement planner</li>
<li>College tuition planner</li>
<li>Debt reduction planner</li>
<li>Scrimp-n-Save planner</li>
<li>Special purchase planner (big ticket items)</li>
</ul>
Create a summary budget/track-record budget report that a
professional financial planner/advisor could use.
<p>Note that the above 'step-by-step' budgeters will have a
very very different GUI than what the budgeting system
required for a small-business might look like.</p>
<p>Note that the utility of budgets is greatly enhanced by using
them with '<a href="#classes">classes</a>'.
<p><b>Status:</b></p>
<ul>
<li>A design doc has been submitted by Bob Drzyzgula.
Take a look at <tt>./src/budget.txt</tt> in the source
directory.</li>
<li>Bryan Larsen has begun work .. it's scheme based ...
Dave Peticolas has some GUI roughed out ...</li>
</ul>
<br>
<br>
</dd>
<dt><a name="classes"><b>Classes</b></a></dt>
<dd>
Ability to mark certain journal entries as belonging to
a 'class', so that expenses (or income) can be categorized
in more than one way. For example, the expense of a trip
might include food, travel and lodging, and thus be spread over
three different expense accounts. None-the-less, we want all
of these entries to be marked as being in the same class.
(Alternate names: 'job costing' is the report that's generated,
'cost center', 'cost pool', 'pooling')
Note that classes can be particularly useful when used with
budgets: viz. I set aside $10K in the budget for some activity,
then deduct the actual costs. Note that it should be possible
to roll the remainder over to somehere else (!)
<p>
Confusion: isn't this what the 'action' field is supposed to do?
The 'action' field is under-utilized.
<p>
This requires the following:
<ul>
<li>Ability to report by class/action
<li>Ability to query by class/action.
</ul>
</p>
<br>
<br>
</dd>
<dt><a name="testing"><b>Automated Test Suite</b></a></dt>
<dd>
Build automated test suite, including:
<ul>
<li>File IO consistency check. Done, 1.6.0, LewisMoss
<li>Currency math correctness. Done ?? Grib.
</ul>
<br>
<br>
</dd>
<dt><a name="quickim"><b>Quicken(TM) Import</b></a></dt>
<dd>
Ability to import Quicken QIF files. Both MSMoney and
Quicken use QIF files to export data. Need both wholsesale
data import, and incremental (staged) merge.
<p><b>Status:</b></p>
<ul>
<li>
Quicken import is implemented and mostly works.
(Bill Gribble, Done, in version 1.4.0)
</li>
<li>
Need a QIF Import wizard (there are several non-intuitive
steps that need to be performed during import.
A dialogue wizard seems like the best idea to carry
through this process. (grib, done in 1.6.0)
</li>
<li>
Work needs to be done for recurring transactions, etc.
</li>
<li>
QIF processing, as used for on-line banking, is <em>
in prototype form</em> (for 1.6.1 ??)
Note that since banks use QIF, the <em>correct</em>
way to updated 'cleared' reconcile state is through
QIF on-line import.
On one side, we have existing recorded transactions;
on the other, the latest bank statement, in QIF
format.
</p>
</li>
</ul>
<br>
<br>
</dd>
<dt><a name="iifim"><b>IIF Import</b></a></dt>
<dd>
Ability to import IIF (Intuiut Interchange Format, used by Quickbooks)
files, quickbooks, some upsacle accounting packages use this format.
<p><b>Status:</b></p>
<ul>
<li>
Sample files checked into sample directory.
No formal documentation known.
</li>
</ul>
<br>
<br>
</dd>
<dt><a name="quickex"><b>IIF Export</b></a></dt>
<dd>
Ability to export Intuit IIF files.
The IIF format is more rational than the QIF format,
and other 'real' accounting apps support IIF.
Several design alternatives are apparent:
<ul>
<li>
A special 'report' that writes out qif could be
created.
This would use the 'reports' infrastructure to
generate QIF's.
</li>
<li>It is fairly easy to traverse the data in the engine
to write out qif files. This is not hard. Just do it.
</li>
</ul>
<br>
<br>
<p><b>Status:</b> not started</p>
</dd>
<dt><a name="quote"><b>Stock Quotes, Price Quotes</b></a></dt>
<dd>
Add ability to obtain stock, mutual fund, and currency trading
data from news agencies, web pages.
Add ability to download historical prices as well.
(<em>e.g.</em> get 5-year history of mutual fund
performance vs. DJIA).
<p>Right now, stock prices are stored in a separate, simple pricedb.
</p>
<ul>
<li>Prices need to have several different status states.
One state is 'critical/audited', i.e. reviewed by a human,
and important for understanding a historical transaction.
Less mportant may simply be 'audited': i.e. reviewed by a
human, but not a critical price. Lowest level: 'live data'
something that was gotten off the net, may be wrong, may
be right, who knows, who cares.
</li>
<li>Add to this the idea that we should probably store other
'technical' stock data, such as share volume, high/low/close,
daily volatility, etc.
</li>
<li>Need access to historical quotes, for graphing charting
of historic portfolio perfformance.
</li>
</ul>
<p><b>Status:</b></p>
<ul>
<li>
<a href="http://sourceforge.net/project/?group_id=4232">
Finance::Quote.pm</a> is now a separate development project at
SourceForge. Its a perl module.
It can obtain stock quotes from Yahoo
(NYSE), Yahoo-Europe, Fidelity Investments, T.Rowe Price,
TIAA-CREF, others. Also handles currency exchange rates.
</li>
<li>A scheme wrapper allows prices to be
fetched from GUI. Done, version 1.6.0, rlbrowning.</li>
<li>
Commandline-flag replaces script file <tt>gnc-prices</tt>
perl script). Suitable for use with cron jobs.
(version 1.6.0)
</li>
<li>A separate, historical-quote module can be found at the
<a href="http://sourceforge.net/project/?group_id=2403">QuoteHist</a>
sourceforge site. It might be a good idea to fold this
together with the Quote.pm module !?
</li>
</ul>
<br>
<br>
</dd>
<dt><a name="install"><b>Install</b></a></dt>
<dd>
Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux,
etc. Possibly use a 'configure'-like way of dealing with
install inconsistencies.
<p></p>
</dd>
<dt><a name="currency"><b>Multiple Currencies</b></a></dt>
<dd>
Need to support multiple currencies.
Work is needed in the GUI. The engine currently supports
multiple currencies by treating them as securities, thus
allowing currency trading. The currency-trading register
needs a complete overhaul as it is obtuse and
unintuitive. Weird stuff is in weird columns.
</p>
<p>
A simplified way of dealing with one-shot currency
exchanges needs to be implemented, essentially just a
simple calculator pop-up. This might be handy for the
occasional business traveler or tourist with some minor
currency trades.
</p>
<p>
Implement the 'correct' way of handling this when user
is working in multiple currencies on a regular basis.
</p>
<p>
<a href="http://www.cloanto.com/specs/seriff.html">SERIFF</a>
Simple Exchange Rate Information File Format. Completely
*.ini-centric in layout and design, but otherwise seemingly
quite complete.
</p>
<p>
<b>Status:</b>
<ul>
<li>Need to rethink whether the one-shot exchanges
should in fact be recorded full-fledged in the engine.
Also: Euro support is currently hacked in: the EURO is treated as
a 'special' currency. Virtually all the Euro code can be fully
generalized (and should be).
<li>New split architecture should store quantity and value, and
never the price. This will simplify currency movements
between accounts, without requiring/forcing the use of a
currency trading account. (this also solves problems with
rounding that occur when a price is explicitly specified.)
Grib & dave are working this for next release.
</ul>
</p>
</dd>
<dt><a name="double"><b>Forced Double-Entry</b></a></dt>
<dd>
The system supports double-entry: every transaction
indicates a pair of accounts: one is debited, and one is
credited.
<p>Double-entry is a powerful way of ensuring the integrity
of of the financial data. Currently, while double-entry is
supported, its use is not enforced: the user <em>can</em>
create dangling transactions, where only one account is
indicated.</p>
<p>Although this is acceptable for home use (arguably
desirable, since it allows the casual user the simplicity
they desire), it is not acceptable for business use. (The
counterargument is that casual users that aren't
accountants need all the help at getting things right that
they can get.)</p>
<p>It must be possible to enforce double entry, so that a
transaction cannot be completed until two accounts have
been specified.</p>
<p><b>Restricted Double</b> Note that sometimes, the words
'single-entry' have a an alternate meaning: they can mean
'a double entry account which can only be credited, or
debited, but not both'. We need to implement this.</p>
<p><b>Current status:</b>
<ul>
<li>April 1998 -- The engine has a couple of flags in it
that control double-entry behavior: it can be made lax or
strict, however, they are compiled in, and there is no
way to change them from the GUI.</li>
<li>Dec 1998 -- Scrubber functions implemented to crawl
through data, and find all unbalanced or orphaned
transactions.</li>
<li>May 2000 -- Default will be changed to double-entry
always. It will not be possible to disable this and move
to single-entry.</li>
</ul>
</p>
</dd>
<dt><a name="401K"><b>401(k), Retirement Savings Plans</b></a></dt>
<dd>
401K, 403, IRA, Roth IRA, SEP, Keogh ...
Retirement Savings Plans often do not put a high
priority on tracking costs, as the tax implication is that
amounts are taxable upon withdrawal, meaning that there is
little necessity to track capital gains. (huh??)
<p>
</p>
</dd>
<dt><a name="note"><b>Annotate with News Stories</b></a></dt>
<dd>
Download, save, annotate investment news and research.
Provide a way of storing news stories with accounts, and
possibly annotating individual transactions in the same
way.
<p></p>
</dd>
<dt><a name="searchdocs"><b>Searchable Documentation</b></a></dt>
<dd>Need to add a 'meta keyword' tag to the documentation
pages, this will help the search engine (<em>e.g.</em>
<a href="http://www.htdig.org/">htdig</a>) better categorize the
help. <a href="http://www.senga.org/mifluz/html/">Mifluz</a>
might be more embeddable ... I am told that htdig-API is in
good solid condition for this, but undocumented.
<p>
<b>Status:</b>
Done, using a simple keyword search, homegrown. The only
problem is it doesn't support compound expressions.
</p>
</dd>
<dt><a name="reconcile"><b>Reconcile Auditing</b></a></dt>
<dd>When a collection of transactions get processed through the
reconcile dialogue, user needs to be able to add a note to this,
i.e. this set of JE's will be treated as a group. The note
(and date) can be later called up as a part of an audit
procedure. The act of reconciliation is treated as a
historical event that needs to be logged.
<p></p>
</dd>
<dt><a name="loan"><b>Loan and Mortgage Calculators</b></a></dt>
<dd>
Provide a variety of simple GUI utilities to allow user to
calculate the future value of loans, mortgage payments,
interest payments, etc.
<p> Consider the following dialogue layout:</p>
<pre>
loan amount $_____________ currency _________ (pull-down menu)
Remaining balance $___________
Payment amount $___________
balloon payment $_____________
other payment $________ (e.g. escrow, tax)
Payment frequency (weekly/monthly/bimonthly/quarterly/yearly)
loan start date mm/dd/yy length -----(weeks/months/years/payments)
loan time left (number of days/weeks/months, rounded)
number of payments left
interest rate %__________________
payee ____________
pay-from account __________________
next due date mm/dd/yy
</pre>
Note that in the above, not all fields are independent:
some can be calculated from others. The <tt>other
payment</tt> should bring up a mini-register, allowing user
to add any number of splits.<br>
<br>
<p><b>Status:</b></p>
<ul>
<li>There is an implementation of the calculation routines by
Terry Boldt in the development branch. There is an initial
GUI implementation of the calculator by Dave.
</li>
</ul>
<br>
<br>
</dd>
<dt><a name="overdraft"><b>Overdraft Alerts</b></a></dt>
<dd>
Overdraft alerts are pop-ups that pop up whenever the user
enters a transaction that would move an account below some
minimum balance, or above some max balance (for a bank
account) or an expense/spending limit is reached (on an
expense account). A similar but different alert can be
implemented for price highs & lows. Note that these
alerts do <em>not</em> require any sort of calendaring or
recurring transaction support.
<p>Design requirements: implement multiple (not just two)
alerts for any account type. Alert should consist of</p>
<ul>
<li>value point or price point</li>
<li>movement direction</li>
<li>'is active' boolean flag (<em>i.e.</em> Should be
possible to 'turn off alert' without deleting it)</li>
<li>memo text</li>
</ul>
<p><b>Status:</b>
<ul>
<li>Not Started.</li>
</ul>
</p>
</dd>
<dt><a name="tech"><b>Technical Stock Analysis</b></a></dt>
<dd>Provide technical stock analysis graphs, <em>e.g.</em>
volume, 90 moving avg, beta, etc. See gstalker for example of
how to do it ...
<p></p>
</dd>
<dt><a name="sink"><b>Asset Depreciation, Sinking Funds,
Amortization Schedules</b></a></dt>
<dd>Need to
support different depreciation schedules (see IRS books for
that). Asset depreciation is complex; there are many
different depreciation schedules, and these vary from
country to country, and change when new tax laws are
implemented. It might be hard for free software to provide
a no-cost subscription to updated depreciation modules.
<p></p>
</dd>
<dt><a name="ofx"><b>OFX support</b></a></dt>
<dd>
Provide the SGML DTD parsers to handle the OFX reports that
many banking institutions are providing, or will soon be
providing, to retail customers. See below for OFX
references.
<p>OFX is an open spec from Microsoft, Intuit, and
Checkfree, and which will be supported by Integrion. The
OFX DTD's are included in the 1.1 distributions. See <a
href="http://www.ofx.net">OFX Home Page</a> for
details.</p>
<p>There are two ways to build an OFX parser. One way is to
build a compile-time DTD parser that treats the DTD as if
it were an IDL, and generates C language stubs for a
parser. This approach was attempted and abandoned because
it leads to fragile C code and a very large binary.</p>
<ul>
<li>The parser is fragile because minor DTD
non-compliances are hard to parse, handle and recover
from.</li>
<li>The parser is huge because the DTD results in
hundreds of (C++) objects being generated.</li>
</ul>
The other method would be to perform run-time DTD parsing.
This is attractive particularly because it is a more
commonly-used approach; there are a variety of XML tools
available that provide this function.
<p>Run-time parsing may be slower, but on the OFX client
side, this should not be a bottleneck.</p>
<p><b>Status:</b></p>
<ul>
<li>A compile-time parser was developed and
abandoned.</li>
</ul>
<p>Note that the organizations developing OFX are looking
to use XML as their "formats of the future;" this may
encourage the use of one of the many XML parsers available
for UNIX.</p>
</dd>
<dt><b>Other on-line support</b></dt>
<dd>
<pre>
>> the German T-Online
>> homebanking system BTX.
>>
>> I Germany we have a very popular online homebanking system,
>> based on the T-Online BTX (Datex-J) system. All of the
>> commercial homebanking software packages like MS-Money or
>> Quicken work with that online system. With that system,
>> you can retrieve account data from your bank, and also
>> send your transfers.
>>
>> I am using since more than 2 years a GPL software written
>> by a former colleague of mine, Niek Busscher, to work with
>> the T-Online homebanking system. That software package with
>> the name ZKA4BTX is very unknown, since Niek published it only
>> by email.
>>
>> Some words to the features of ZKA4BTX :
>>
>> - Completely written in Tcl
>> - Uses Xcept as a BTX browser
>> - Retrieve account data from multiple banks
>> - Send transfers, using TAN
>> - Export retrieved account data to CBB, Xfinans and QIF files
>> - Export retrieved account data to CBB, Xfinans and QIF files
>>
>> With a simple click to an icon on my desktop, ZKA4BTX logs into
>> T-Online, gets all my account datas from several banks, and writes
>> (adds) it to my CBB, Xfinans or GnuCash (QIF) files.
>>
>> Another very important thing is that I can do all my transfers
>> offline, editing a transfer sheet, and ZKA4BTX sends these
>> transfers in one step to my bank.
>
>One thing we could do in the short-medium term is have gnucash
>launch ZKA4BTX to get the data, export it to QIF, and then load
>it in, all through one command.
</pre>
</dd>
<dt><a name="tab"><b>Tab-delimited ASCII file format</b></a></dt>
<dd>
People <em>like</em> to be able to read file contents in
ASCII; there are many Unix tools for manipulating ASCII. An
ASCII equivalent of the current file format should be easy
to develop ... just substitute the writes with <tt>
printf()</tt>s.
<p>The tab-delimited format should be compatible with that
of <tt>/rdb</tt>, aka <a href=
"ftp://ftp.rand.org/pub/RDB-hobbs/">RAND/Hobbs /rdb</a> or
<a href=
"ftp://ftp.linux.it/pub/database/RDB/nosql-0.8.tar.gz">
NoSQL.</a> (NoSQL is available as part of the <a href=
"http://www.debian.org">Debian GNU/Linux</a> distribution,
for instance.)</p>
<p>The <tt>/rdb</tt> format is thus:</p>
<pre>
field-name tab fieldname tab fieldname \n
------------------------------------------ \n
value tab value tab value \n
value tab value tab value \n
etc ...
</pre>
<p>It is a very simple, very basic flat table format. The
use of <tt>/rdb</tt> with GnuCash should try to match with
SQL schemas as much as possible in order to minimize I/O
complexity and incompatibility.</p>
</dd>
<dt><a name="tax"><b>Tax Preparation</b></a></dt>
<dd>
Gotta prepare those taxes.
W-2, W-3, 941, 940 Processing.
<ul>
<li>
TurboTax --
categorize items according to different tax
schedules
</li>
<li>VAT -- Value Added Tax. Varies from country to country.
</li>
<li>Estimate income taxes.
Estimate itemized deductions, find potential
deductions, categorize them</li>
</ul>
<p></p>
</dd>
<dt><a name="palm"><b>Sync with Palm Pilot organizers</b></a></dt>
<dd>There are Quicken-workalikes that run on the
PalmComputing platform; it would be good to inter-operate
with this. See
<a href="ftp://ryeham.ee.ryerson.ca/pub/PalmOS/">PalmLink</a>
and <a href="http://www.orbits.com/Palm/">Palm & Linux</a>.
<p></p>
</dd>
<dt><a name="emerg"><b>Emergency Records Organizer</b></a></dt>
<dd>Put together a single-page report showing critical info
about accounts, etc.
<p></p>
</dd>
<dt><a name="logging"><b>Logging, Crash Recovery</b></a></dt>
<dd>
Logging serves two purposes: (1) return the system to the state
it was in on some earlier date. (2) recover from a crash.
Probably need two distinct mechanisms to support this. The
mechanisms are (A) backup copies. These can be compactly handled
via RCS (actually, deltax) for storage. (B) Logging. Write
out to disk each & every change made.
</p>
<p><b>Status:</b>
<ul>
<li>Crude transaction logging/auditing in place; should
be suitable for error/crash recovery but has not been
"tried by fire."</li>
<li>Backup files automatically created and
time-stamped.</li>
</ul>
</p>
</dd>
<dt><a name="engine"><b>Enriched Engine, Financial Objects</b></a></dt>
<dd>
The current system makes a distinction between the data
(account, transaction) and they GUI that displays it. The
data is embedded within and controlled by the "Engine",
which is a set of routines to access accounts,
transactions, etc. The engine serves as a kind of a dynamic
cache between the permanent data repository (file, sql db)
and the GUI.
<p>The current engine is rather simple: it provides support
for accounts, account hierarchies and transactions
consisting of multiple entries.</p>
<p>Many of the features described elsewhere will require
that the engine have a far richer, more sophisticated data
model, including such things as:</p>
<ul>
<li>Linking to "Address Info" ( <em>e.g.</em> names,
addresses)</li>
<li>Transaction identifiers</li>
<li>Part numbers, SKU IDs</li>
<li>Interest rates</li>
<li>Budget policy</li>
</ul>
<p>Note: it makes no sense at this point to make the engine
API much richer than what the GUI can currently
support.</p>
<ul>
<li><b>Locks</b> When splits are implemented, and the
parent transaction has been marked as cleared/reconciled,
the record
should be locked, so that further modifications to the
amount can't be performed (or at least, a warning is
generated to prevent accidental garbaging up of old
transactions).</li>
</ul>
<p><b>Current Status:</b></p>
<ul>
<li>
<tt>BeginEdit()/RollbackEdit()/CommitEdit()</tt>
routines mostly in place,
these "Transaction processing constructs" should
simplify creation of an SQL back end, or some other
more sophisticated transactional server.
</li>
<li>Multiple currency support is present but still pretty
"raw."</li>
<li>Query engine has been broadly extended (Bill Gribble).
Documentation for Query Engine??</li>
</ul>
<p></p>
</dd>
<dt><a name="sql"><b>SQL I/O</b></a></dt>
<dd>
A module is necessary to allow data to be fetched from an
SQL database, and for that database to be updated.
There has been <em>much</em> discussion about this on
mailing lists both for GnuCash and
<a href="http://www.menet.umn.edu/~curt/cbb/">CBB.</a>
Major points have included:
<br>
<br>
<ul>
<li>The use of a database allows only that data which
is actually <em>in use</em> to be loaded into
memory. This permits managing larger sets of
transactions more efficiently.
</li>
<br><br>
<li>It also allows data to be pushed out to the DBMS
<em>immediately after entry,</em> rather than waiting
for the user to "save the books."
</li>
<br><br>
<li>Using a client/server SQL database might make it easier
to turn GnuCash into a multi-user system.
</li>
<br><br>
<li>By using a well-known DBMS, outside programs are
provided a well-defined way of getting at, and
perhaps even modifying, GnuCash data.
(Actually, this is not true: GnuCash already provides
a uniform, well-documented, preferred data access API.
As long as this
API is used, there is some guarantee that data is stored
in a self-consistent fashion. Not using the GnuCash
programming interfaces risks corrupting the data.
Direct access to the data is dangerous and discouraged.
Furthermore, The API is guaranteed to be backwards
compatible with a variety of data storage formats.
Due to enhancements, the actual form of the data stored in
a flat file, or in the SQL database, may change without
warning.)
</li>
<br><br>
<li>
Those SQL databases available on Linux tend to involve
considerable <em>administrative</em> overhead in terms
of getting them set up.
This may be a minor cost to a business enterprise
that routinely hires Database Administrators.
It is <em>not</em> acceptable to require this of
naive users that may find "simple" things like
<pre>
% su -
Password:
# cd /tmp
# rpm -i gnucash-4.1.3.i386.rpm
# exit
</pre>
to be challenging.
</li>
<br><br>
<li>
It might be useful to use an embedded database engine
like unto <a href="http://www.sleepycat.com/">Sleepycat
DB</a>,
<a href="ftp://koobera.math/uic.edu/www.cdb.html">cdb</a>,
or something like
<a href="http://www.opengroup.org/public/prods/dmm4.htm">
ISAM</a> (Note CQL++ supports ISAM access methods), or
even an embedded SQL engine such as
<a href="http://www.ispras.ru/~knizhnik/gigabase.html">
GigaBASE</a>.
The reasons to do so include ... ???
</li>
<br><br>
<li>
GnuCash presently uses a document-oriented model, where
the <em>entire</em> set of books are loaded in, and
dumped out, all at one fell swoop.
GnuCash needs to be modified to access the database
in a transactional manner. This is at least partly
implemented with the <tt>Begin()/End()</tt> constructs
in the engine.
<p>
Some transactional thoughts: entire SQL
tables/databases do not need to be locked while the
user is editing a transaction via the GUI.
Instead, an optimistic approach, similar to that
employed by CVS (concurrent version system, a mechanism
for storing versions of source code) could be used: if
the edits conflict with changes made by others, edits
are be rejected en-masse, allowing the user to merge
and correct their changes.
Important note: updating SQL does <em>not</em>
require locks to be held for extended periods of
time!
</p>
</li>
<li>
The SQL engine chosen should be fully transactional,
passing the 'ACID' test (Atomicity, Consistency,
Isolation, Durability).
Note that
<a href="http://openacs.org/why-not-mysql.html">MySQL
does not satisfy the 'ACID' criteria</a>.
</li>
</ul>
<p>
<b>Status:</b>
Done, more or less, gnucash version 1.6.0, Linas Vepstas.
Theres still a laundry list of things that need to be
cleaned up, see the README file in src/engine/sql/README.
</p>
</dd>
<dt><a name="multiuser"><b>Multi-user Support</b></a></dt>
<dd>
Multi-user support should be added with either an SQL
backend to the engine, and/or through CORBA interfaces to
the engine.
Another possibility is to create a web application
server, and have users do much/most of I/O via a web
interface, possibly using the register object as a browser
plugin.
The following industrial-strength features are
needed:
<br><br>
<ul>
<li>transaction-oriented queuing of updates</li>
<li>event subscription channel for updates</li>
<li>user authentication</li>
<li>user authorization</li>
<li>non-repudiability (needed only for peer-to-peer??)</li>
<li>encryption of network connections</li>
</ul>
<p>
<b>Status:</b> Partly done. (gnucash 1.6.0, Linas)
The postgres backend fully
supports multiple simltaneous users. This includes
events for automatic updates of all GUI displays.
However, the GUI support is rough, no GUI dialog
for user/password.
</p>
</dd>
<dt><a name="addressbook"><b>Address Book</b></a></dt>
<dd>
Provide support for client/vendor/customer address books,
including street addres, eamil, phone. Also: to-do lists,
a mini-contact manager (when is last time this person
was paid? what did they say on phone the last time we
sent them a check? Is there a dispute?)
<p>
Propose: use Ximian Evolution contact manager/to-do lists.
</p>
</dd>
<dt><a name="arap"><b>Accounts Payable, Receivable</b></a></dt>
<dd>Add features to track sales receipts and other pending
sources of income, as well as owed sums.
<ul>
<li>Need new account type 'ar' and 'ap'. When this account type is
selected, the register display, etc. is slightly different, as below:
<li>Add field to register called 'date due'. The date could be
entered as 'date of transaction +30days'. etc. The account
could have a default: entries always default to +30 or +45 days
or whatever.
<li>Create a report to match 'date due' to current date, and report
overdue balances ...
<li>Create Account aging report: show (average) age of
amount-due/amount-owed.
<li>Create a projected cash flow report: showing projected
future payments based on date due.
<li>Somehow, automatically match invoices to payments.
When an invoice has been paid off, then there should be a
view mode where the invoice and its payment is no longer shown
(i.e. so that only outstanding, unpaid entires are shown ...)
<li>create report showing everything but the a/p:
Here's an example. I buy a chair for a friend, and three
days later he pays me back. What I've been doing is ...
<pre>
> 1/12/01 Credit -$100
> A/R +$100
> 1/15/01 Cash +$100
> A/R -$100
</pre>
To make it less painful to read and understand, the
report should look like:
<pre>
> 1/12/01 Credit -$100
> 1/15/01 Cash +$100
</pre>
i.e. there would be a new kind of 'transaction report' that
would pair up transactions in this way, showing things
'as if' the A/R didn't exist, and 'as if' a transaction
was spread over a bunch of days.
</ul>
<p></p>
</dd>
<dt><a name="payroll"><b>Payroll</b></a></dt>
<dd>
Payroll introduces a <em>sizable</em> amount of complexity
in terms of the need to comply with constantly-changing
government regulations in whatever country one is in.
While the GnuCash "engine" might remain free,
maintenance of payroll functionality would require
"subscribing" to an update scheme; it might be troublesome
to try to provide such a "subscription" free of charge.
<p></p>
</dd>
<dt><a name="invoice"><b>Invoicing</b></a></dt>
<dd>Invoicing. Note that invoicing and order entry are
closely related.
Several components:
<ul>
<li>Record an invoice. Assign it a serial number. Be able
to reprint/report based on invoice serial number.
<li>Invoice associates customer name to set of transactions.
Need to deal with PIM issue. I.e. need to integrate
with high-function PIM or CRM interface.
<li>Allow historical browsing of invoices customer by customer.
<li>To visually design an invoice, need to have a
mini-word-processor/simple drawing plug-in. Is
Abisource/Abiword a candidate? Probably needs bonobo...
</ul>
</dd>
<dt><a name="order"><b>Order Entry</b></a></dt>
<dd>
Mini-GUI allowing users to type in orders.
<ul>
<li>Should interface to parts/inventory database to confirm
item availability, (maybe recommend additional production)?
inventory should be updated after order placement.
<li>Automatically update accounts receivable.
<li>Allow order revision/update (esp. as partial orders are shipped).
<li>Orders can be invoiced when entered (simple invoicing), or
placed on account (double invoicing).
<li>Allow back-orders to be printed customer-by-customer, or by
product/item.
<li>Allow printing of packing slip.
</ul>
<p></p>
</dd>
<dt><a name="estimate"><b>Job Costing</b></a></dt>
<dd>Ability to prepare and track estimates.
<ul>
<li>Allow estimate/bid to be converted to a firm order & get invoiced.
</ul>
<p></p>
</dd>
<dt><a name="expense"><b>Expense Accounts</b></a></dt>
<dd>Expense Account Automation, including air, car, hotel,
dining. Receipts, reservations, cancellations.
<p></p>
</dd>
</dl>
<h1>References</h1>
All software and technical standard references have been moved to
<a href="http://www.gnucash.org/links.php3">
http://www.gnucash.org/links.php3</a>
<hr>
Draft version 0.51 -- June 2001
Linas Vepstas
<a href="mailto:linas@linas.org">linas@linas.org</a>
<br>
</body>
</html>
|
