wow, having a sub ledger of unearned income so that i can book work to
specific sub account for each customer and have it aggregated in the
general unearned account sounds like just the right solution.
What do you think, Dieter? it takes care of my worry about having too
many unearned accounts - one per customer - i like it.
On Tue, 2002-06-25 at 13:00, Ho-Sheng Hsiao wrote:
> 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
--
elizabeth ziph
734.761.4689
www.linuxbox.nu
-------------------------------------------------------
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
