On 19 Nov 1999 17:32:39 EST, the world broke into rejoicing as
Derek Atkins <[EMAIL PROTECTED]> suggested that a handling of
loan payments might be a good idea...
Your suggestion has led me think a bit further, and I am quite
sure that the "mortgage problem" is essentially the same as as
the "depreciation problem."
--> You have a set of transactions that need to be scheduled;
--> They involve a calculation that is based on such things as:
a) Time elapsed since the start of the contract,
b) Balance in the account
Rob Browning suggested that it might be good to have a way of
somehow handling calculations done in Guile; I think I have some
suggestions for architecture. Either better still, or scarier
still, my "strawman" proposal has not, to the best of my
knowledge, been implemented in any system.
General idea: Add in the ability for transactions to have the
following properties:
a) Scheduled to take place multiple times.
Sensible criteria would be things like:
- The 15th and last day of each month,
- The second Tuesday of each month,
- Every 9 days,
and such
b) Have amounts based on a set of "calculation" fields whereby the
values of the splits may be based on a formula calculation.
c) The Really Powerful part is to have the ability to have a method
of bringing account balances into the formula calculation.
The Scheme way of doing this would be something like:
(define (past-balance account days-ago)
;;; code to calculate the balance as at some past date
)
The *critical* point is that the value "days-ago" must be a
positive value; in order to avoid an equivalent to the spreadsheet
notion of cycles, the (past-balance a d) function can solely look
back at *PAST* balances.
That way, calculations may be done unambiguously, moving forward
through time, with no "time loops" where you do a calculation today
based on a prediction of what the account balance will be next month.
Indeed, (past-balance a d) can't look at *today,* because the balance
will be dependant on transaction ordering during today, and would
be susceptible to "time loops."
A "friendly" public interface should probably be made to look just like
the sorts of calculations that spreadsheets permit, with some way of
getting at user-defined Guile functions if need be.
A Canadian CCA depreciation calculation in account "Computers" might
thus look like:
=@if(@year()=1999,0.5,1)*0.3*@past-balance("Computers",1)
This breaks out thusly:
--> If the year is 1999, then the depreciation rate is 15%, otherwise
it's 30%.
--> Multiply that rate by the balance that was sitting in "Computers"
yesterday.
This would be adapted to handling a loan thusly:
Loan payment on a $20000 loan, involves three split pieces:
a) Checking account - fixed payment amount each month...
-1500.00
b) Interest, being paid at 1% per month:
=0.01*@past-balance("Loan",1)
c) Amount by which loan gets paid down:
=1500-(0.01*@past-balance("Loan",1))
It would be convenient to have a "balance-the-transaction" function,
balance_txn() that would implicitly take on the difference required
to balance debits and credits to 0, thus:
=@balance_txn()
This could also be readily used to schedule budgeted incomes and expenses
that are to be scheduled on a periodic basis; complex calculations would
likely not be needed...
It would be quite appropriate to have a way of getting user-defined
formulae coming from the Guile side of the world so that if it proved
necessary to construct some complex formula to manage oddball depreciation
schedules, that could, too, be made easier.
This mandates four rather major changes:
a) Transactions need to become "first class objects," with the ability
to attach to them a schedule on which they are to be repeated.
At present, transactions are not a "thing" in and of themselves; they
are implied by a joining of splits and accounts.
Note that there will be three kinds of transactions:
i) "Actual" transactions, where the amount and date is permanently
nailed down,
ii) "Template" transactions, which is essentially a "rule" for
generating transactions, and
iii) "Virtual" transactions, the ones that have been generated by
"template" transactions.
Once a "virtual" transaction gets marked for reconcilation, it is
"nailed down" because we've verified amount and possibly other bits,
and it is no longer free to float around in value.
b) Splits need to have a field whereby a (text? somewhat compiled?)
formula is attached to them.
c) By virtue of a) and b), the structures are no longer forcibly of
fixed size. And there needs to be a way of saving this increasingly
dynamic set of stuff out to disk. Methinks a move towards something
like XML starts to look more and more sensible...
d) The "engine" needs to run through time and generate the "virtual"
transactions, their amounts, and the balances of the accounts. Rather
complex, particularly with a need for attention to temporal concerns.
(Time "loops" may be forbidden, but there's still a need to run through
time in order to calculate all the thinge that might happen in all the
accounts...)
This is a *rather* wild scheme. I don't know of any accounting system
that has ever done this. It is probably too dynamic to cope with a huge
enterprise.
BUT. It's probably the right way to put a calculation engine into
GnuCash, and it's definitely more powerful than what anyone else has
realistically contemplated...
--
Be careful when a loop exits to the same place from side and bottom.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
