On Tue, Jun 25, 2002 at 11:26:54AM -0400, Elizabeth Ziph wrote:
> Thanks for the follow up Paul. You are right about both cases. but what
> i need to do to keep the records straight, is recognize that part of
> the income is unearned and to track it by customer as Dieter kindly
> explained, by expanding the chart of accounts so that i have an
> unearned income liability for each contract. (means expanding the chart
> of accounts) It can be rough if the number of these contracts grows.
> I wonder how the lawyers do it since they do it all the time?
I don't know about lawyers. My accounting instructor is going through
the material on subsidary ledgers right now. Probably, in the
paper-and-pencil accounting systems, you would have subsidary ledgers
that keep track of individual customers for unearned income, and make
a summary entry in the general ledger. Looking back, SQL-ledger is
sort of programmed like that, you just don't access it like that. (AR,
AP, and GL occupy seperate tables, and the transaction report
automatically peices the three together).
I guess Paul's workaround works until someone writes a module for
unearned income. I'm actually keeping track of my own retainers for
computer stuff the way Paul described (roughly). I don't have many of
them, so it works well.
What I *am* concerned about is writing a module against a version
series, only to have the architecture change on me. The 1.8.x series
is so much cooler and better than the 1.6.x, and I'm seeing those
hooks for customized modules. Still. I would very much like to see a
repository of user-contributed modules patching against the main
software.
Yeah, and something in Form.pm that generates POST or GET data for
common stuff like $form->{path}, $form->{password}, $form->{script},
$form->{id} ... writing out those URLs by hand are so prevalent, there
should be a standardized function. Hell. Off the top of my head (and
therefore NOT optimized, and not debugged):
sub _get_vars {
my $result;
for my $ref (keys %{ $form->{session_vars} }) {
$result .= "$ref=" . $form->{session_vars}{$ref};
}
$result;
}
sub _post_vars {
my $result;
for my $ref (keys %{ $form->{session_vars} }) {
$result .= "<input name=$ref type=hidden value=" .
$form->{session_vars}{$ref}
}
$result;
}
sub register_var {
$var = shift;
$form->{session_vars}{$var} = $form->{"$var"};
}
And somewhere in initialization
map { $form->register_var($_) } qw(login path password);
The advantage (besides easier time on writing new modules) is being
able to write session-handling code later on when the code gets
waay to unwieldy to rely on passing info through GET or POST. Not to
mention cutting down on bandwith when accessing the program from a
dial-up extranet.
-Qaexl-
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
