Scheduled transactions desire a template register. This is a register
which will contain _template_ Splits/Transactions which can be
_instantiated_ to actual transactions, perhaps with user input, at the
appropriate time.
It is expected that the scheduled transaction editor will contain a
general ledger, allowing the user to create transactions between the
appropriate accounts. As the General Ledger cannot be used to create
stock transactions, a separate register will need to be created for
that purpose.
[ Within the UI, I expect that the lower-half of the
scheduled-transaction editor will be a notebook with two tabs: one for
the general ledger, and one for a Portfolio ledger. To get around one
of the most annoying problems with using notebooks to conserve screen
real-estate, the tabs for the pages will include the number of
transactions in the ledger for that page, allowing the user to easily
get an idea of what's going on. ]
The user wants to create a template that can be modified into the
transaction with little/no intervention at that time. However, some
fields are disallowed by definition. I've been thinking that these
columns will just not show up in the template version, but maybe the
better thing is that they do [for consistency with their normal mental
model of the ledger], but they are visibly and otherwise disabled... ?
Template transactions should still reference the accounts which the
Splits [will] belong to, but some other fields are handled differently
or not handled at all; the ledger/register behavior differences are
really based on the type of cell:
. date_cell
. goes away, as this is encoded in the frequency of recurrence
. num_cell
. It may be cool if this was "auto_increment" or "next available",
but I don't think we can implement that...
. {desc,notes,actn}_cell
. stay as-is, and are copied to the instantiated transaction.
. recn_cell
. By definition, a transaction in the future cannot be known as
reconciled... of course, the instantiated version will have this
cell, but I don't think it's part of the template transaction
[unless I can be convinced otherwise].
. {mxfrm,xfrm}_cell
. As per conversations with you, this data shouldn't go into the
Splits they way it normally would. The idea is that an engine
invariant is "An Account gotten from a Split is valid, and the
Account will contain that Split", which won't be true for these
Splits. So, handling of these fields will be modified to place
the account [GUID] in the kvp-data for the Split.
. {cred,debt}_cell
. The amount of the template transaction...
. May be known [fixed, recurring payments]
. May not be known
. Maybe: derivable via simple formula.
. Probably: User input is required at instantiation time
[read-as: a formula with one variable to query from the user].
. In any case, it's not a numeric value.
. Handling probably places both types of values in the kvp-data, as
well. . {baln,sharbaln,tsharbaln}_cell
. By definition, unknowable...
. {tcred,tdebt}_cell
. If the Splits are all numeric, this is the same.
. If the Splits contain formulas, then this gets weird...
. shrs_cell
. Like debt/cred, it may be the case that the number of shares are
either fixed, or derivable from the price at the time of
instantiation... however, in that case, the amount put toward the
purchase of shares may be variable/based on user input. I'm not
exactly sure what to do here, other than to say that -- like
{debt,cred}_cell -- it should be in the kvp-data, and be either a
number or a formula.
. tshrs_cell
. Same problem as the {tcred,tdebt}_cell.
. pric_cell
. Likely, this looked-up at the time of instantiation... so this
field goes away.
My proposal is to subclass the MultiLedger/SplitLedger/splitreg
components in the following way:
. ADD xaccLedgerDisplayTemplateGeneralLedger(...)
. This will create a GeneralLedger, and place it in "template" mode.
. This may require an extra argument to xaccLedgerDisplayInternal.
. ADD xaccLedgerDisplayTemplatePortfolioLedger(...)
. ditto
[ In "template mode", the following 'view'
function pointers will be replaced: ]
. REPLACE xaccSRGetEntryHandler
. This will return the data for the cell type in the appropriate way
described above [i.e., for [m]xfrm_cells, this will get the
account GUID from the kvp-data].
. Otherwise, hand off the the supercla... er...
xaccSRGetEntryHandler. :)
. REPLACE xaccSRConfirmHandler
. A more lenient version which doesn't check for the reconcile flag
[which is all this does, right now].
. I haven't thought about it enough to determine if the template
ledger wants it own confirmation policy, but this will become
apparent soon enough.
. REPLACE xaccSRSaveRegEntry
. This is the other half of the fun. :) This will save those
aforementioned cell contents into the correct place.
. Otherwise, hand off to xaccSRSaveRegEntry.
[ And the following changes to the register/ will need to be made: ]
. MODIFY splitreg.c
. cell_sample_strings
. changed in the template case iff used for cell-width
determination.
. configLayout
. null-cell filling remains the same
. most registers change based on the template option, but it may
be just disabling the cells/column.
. mallocCursors
. number of columns changes based on template option [unless the
columns can be disabled in some way].
. xaccInitSplitRegister
. cell descriptions probably change
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
