sql-ledger-users — SQL-Ledger users

[SQL-Ledger-users] Asset Depreciation

[Mark L. <ma...@kn...>]

Hi there; I'm currently using SQL Ledger as a very basic invoice
generator, and it is excellent.  However, the accounting dept. at
my "real" job has asked about a way to do asset depreciation - is
this a feature in SQL Ledger currently?  If not, how much pain
would be involved in adding it?  We have the tax tables and know
how to calculate it, if integrating it into the database isn't
too agonizing, this might work.

Thanks,
Mark

Re: [SQL-Ledger-users] Q. on the TO-DO list. (Payroll update)

[Roderick A. A. <raa...@ti...>]

On Thu, 10 May 2001, Wayne wrote:

> Hi  Steve,
> I was going to hold off on offering some suggestion
> until I understand what is going on in the code, but
> if anyone is going to develope the payroll I would
> suggest that we look at the data model a little further.
> The suggertion I'm going to make is not my own. If
> folks like to purchase the book "The Data Model
> Resource Book"  ISBN 0-471-15364-8

There are several others that address the same issues including "Data
Model Patterns : Conventions of Thought", and the whole Case Method
series.  Data design can be a very touchy issue so I tend to avoid it.
It is very tough being a Programmer and a Database Designer at the same
time.  And the people we design for sometimes either can't get over the
hurdle of data normalization or just like their 3x5 cards, file folders,
and napkin notes.

> you can see where I'm coming from.
> This book has good data model for  a business.
> One enity that is present is a "Party", a party is
> a person or and organization. One then associates
> a relationship to a "Party". This will help to reduce
> data redundancy. For example, if I have an employee
> that happens to be a vendor, then the party is in
> my DB only once , as a person, and I only have to
> establish the relationship this enity has. That
> relationship would be "employee" and  "vendor".
> I know I'm leaving alot of description out, but
> I think if people purchase the book it would give
> the group a good model to follow.

I'll have to look into this one.  I have theoretical books but having a
nuts and bolts will be nice.

> Later.
> Wayne
> P.S. I should also point out that I'm learning Perl
> to convert the system to Python. I hope that
> doesn't offend anyone.

Doesn't offend but I'd suggest you learn Perl then decide if you'd be
gaining anything by going to Python.


Rod
-- 

Re: [SQL-Ledger-users] Q. on the TO-DO list. (Payroll update)

[<li...@li...>]

On Thu, May 10, 2001 at 03:23:21PM -0400, Wayne was heard to remark:
> Hi  Steve,
> This book has good data model for  a business.
> One enity that is present is a "Party", a party is
> a person or and organization. One then associates
> a relationship to a "Party". This will help to reduce
> data redundancy. For example, if I have an employee
> that happens to be a vendor, then the party is in
> my DB only once , as a person, and I only have to
> establish the relationship this enity has. That

Bad example.

If you have employees who also act as vendors to you, 
you are putting yourself into a conflict of interest.
If you're the sole owner, hey, that's up to you, but
if you work for a larger company, that's grounds for 
getting yourself and your employee fired.   If the 
employee is paying you kickbacks, I think that may 
even be a felony under rico.

--linas

-- 
Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/

Re: [SQL-Ledger-users] Q. on the TO-DO list. (Payroll update)

[Wayne <inf...@pi...>]

Hi  Steve,
I was going to hold off on offering some suggestion
until I understand what is going on in the code, but
if anyone is going to develope the payroll I would
suggest that we look at the data model a little further.
The suggertion I'm going to make is not my own. If
folks like to purchase the book "The Data Model
Resource Book"  ISBN 0-471-15364-8
you can see where I'm coming from.
This book has good data model for  a business.
One enity that is present is a "Party", a party is
a person or and organization. One then associates
a relationship to a "Party". This will help to reduce
data redundancy. For example, if I have an employee
that happens to be a vendor, then the party is in
my DB only once , as a person, and I only have to
establish the relationship this enity has. That
relationship would be "employee" and  "vendor".
I know I'm leaving alot of description out, but
I think if people purchase the book it would give
the group a good model to follow.
Later.
Wayne
P.S. I should also point out that I'm learning Perl
to convert the system to Python. I hope that
doesn't offend anyone.


Steve Doerr wrote:

> Hi Wayne/everybody.
>
> Wayne wrote:
>
> > Hello,
> > I see on the TO-DO list that  Steve has started
> > a payroll system and Roderick has started  aging
> > reports. Are these avaiable to view?
> > Thanks.
> > Wayne.
>
> I started a payroll system and there isn't anything that can be loaded
> or used yet.  If anyone wants to help or has any input on it, please let
> me know and I'll send you what I have.  I've got an employee package and
> a few of the sql tables started.
>
> Here's what I have planned - it's a three part system and it just
> follows existing forms and modules.
>
> 1.  An entry form and perl module to set up an employee's information
> (i.e. name, address, pay rate, withholdings/deductions).  This is going
> to write each employee's info to the database, which will be called and
> applied to their pay period data when you enter and run payroll.  I've
> got a separate table for deductions/withholdings that will have a two
> part id, one associates them with an employee id and one numbers them.
> It should be able to hold an infinite number and types of deductions for
> employees in any country (that's the goal).
>
> 2.  An entry form and perl module to enter each employee's data for the
> pay period (hours worked, vacation taken, sick time taken, etc.).
> You'll also be able to run and post the pay period data here.
>
> 3. Reports.
>
> That's a brief overview of payroll.
> Steve

RE: [SQL-Ledger-users] Perl Error: Can't locate DBI.pm

[Hugo P. <hp...@te...>]

From the sources sql-ledger page

REQUIREMENTS:
    Webserver (Apache, ...)
    Perl 5.xxx, depends on DBD and DBI
    SQL Server, must support transactions (PostgreSQL 7.03+, ...)

---->     DBI module
                         http://search.cpan.org/search?module=DBI
---->     DBD driver (DBD-Pg, ....) For the PostgreSQL driver click here
                        http://search.cpan.org/search?dist=DBD-Pg




-----Mensaje original-----
De: Jaco van Staden <ja...@cy...>
Para: sql...@li...
<sql...@li...>; gl...@li...
<gl...@li...>
Fecha: Thursday, May 10, 2001 4:16 AM
Asunto: [SQL-Ledger-users] Perl Error: Can't locate DBI.pm


>Hi
>
>I cannot execute perl .cgi files for SQL-Ledger. I get an internal
>server error with the following message in the ../httpd/error.log file:
>
>Can't locate DBI.pm in @INC (@INC contains:
>/usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0
>/usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0
>/usr/lib/perl5/site_perl .) at /var/www/html/sql-ledger/admin/setup.cgi
>line 33.
>BEGIN failed--compilation aborted at
>/var/www/html/sql-ledger/admin/setup.cgi line 33.
>[Thu May 10 09:18:05 2001] [error] [client 10.0.0.5] Premature end of
>script headers: /var/www/html/sql-ledger/admin/setup.cgi
>
>
>I have installed the following files:
>
>postgresql-7.1-1.i386.rpm
>postgresql-libs-7.1-1.i386.rpm
>postgresql-contrib-7.1-1.i386.rpm
>postgresql-perl-7.1-1.i386.rpm
>postgresql-devel-7.1-1.i386.rpm
>postgresql-server-7.1-1.i386.rpm
>
>I assume all the required files to acces the database are in these
>packages.
>
>Regards
>
>--
>Jaco van Staden
>Cyber Seal Information Systems Development
>Tel: +27 12 998 5674, Fax: +27 12 998 0249,
>Cell: +27 82 927 5513, http://www.cyberseal.co.za
>
>
>

[SQL-Ledger-users] Perl Error: Can't locate DBI.pm

[Jaco v. S. <ja...@cy...>]

Hi 

I cannot execute perl .cgi files for SQL-Ledger. I get an internal
server error with the following message in the ../httpd/error.log file:

Can't locate DBI.pm in @INC (@INC contains:
/usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl .) at /var/www/html/sql-ledger/admin/setup.cgi
line 33.
BEGIN failed--compilation aborted at
/var/www/html/sql-ledger/admin/setup.cgi line 33.
[Thu May 10 09:18:05 2001] [error] [client 10.0.0.5] Premature end of
script headers: /var/www/html/sql-ledger/admin/setup.cgi  


I have installed the following files:

postgresql-7.1-1.i386.rpm 
postgresql-libs-7.1-1.i386.rpm
postgresql-contrib-7.1-1.i386.rpm
postgresql-perl-7.1-1.i386.rpm
postgresql-devel-7.1-1.i386.rpm 
postgresql-server-7.1-1.i386.rpm 

I assume all the required files to acces the database are in these
packages.

Regards

-- 
Jaco van Staden
Cyber Seal Information Systems Development
Tel: +27 12 998 5674, Fax: +27 12 998 0249,
Cell: +27 82 927 5513, http://www.cyberseal.co.za

Re: [SQL-Ledger-users] Q. on the TO-DO list. (Payroll update)

[Steve D. <sd...@sw...>]

Hi Wayne/everybody.

Wayne wrote:

> Hello,
> I see on the TO-DO list that  Steve has started
> a payroll system and Roderick has started  aging
> reports. Are these avaiable to view?
> Thanks.
> Wayne.

I started a payroll system and there isn't anything that can be loaded
or used yet.  If anyone wants to help or has any input on it, please let
me know and I'll send you what I have.  I've got an employee package and
a few of the sql tables started.

Here's what I have planned - it's a three part system and it just
follows existing forms and modules.

1.  An entry form and perl module to set up an employee's information
(i.e. name, address, pay rate, withholdings/deductions).  This is going
to write each employee's info to the database, which will be called and
applied to their pay period data when you enter and run payroll.  I've
got a separate table for deductions/withholdings that will have a two
part id, one associates them with an employee id and one numbers them.
It should be able to hold an infinite number and types of deductions for
employees in any country (that's the goal).

2.  An entry form and perl module to enter each employee's data for the
pay period (hours worked, vacation taken, sick time taken, etc.).
You'll also be able to run and post the pay period data here.

3. Reports.

That's a brief overview of payroll.
Steve

[SQL-Ledger-users] PHP version of sql-ledger

[Caffeinate T. W. <moc...@ya...>]

has anyone made any effort porting sql-ledger to PHP?

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: [SQL-Ledger-users] Q. on the TO-DO list.

[Roderick A. A. <raa...@ti...>]

On Wed, 9 May 2001, Wayne wrote:

> Hello,
> I see on the TO-DO list that  Steve has started
> a payroll system and Roderick has started  aging
> reports. Are these avaiable to view?

Funny you should mention this I just (re)found the notes I had buried
under some other stuff.  I'll be working on it this week and next.


Rod
-- 
                 Remove the word 'try' from your vocabulary ... 
                     Don't try.  Do it or don't do it ...
                                Steers try!

                                                            Don Aslett

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[John O. <jo...@ca...>]

My name is John and I am an accountant. (sounds like Alcoholics Anonymous)

Ron is correct in that older text based accounting packages used, reversing
of incorrect entries, instead of amending them, however, there are about
three or four commercially available packages, which seamlessly amend these
erroneous ones, and replace them with the correct one. It helps the
readability of a transaction listing, not to have to manually stroke off
contra entries.
What the better ones do, is to take a copy of the entry being chanegd and
dump it into another file to allow the year end auditors to see the
transactions which were changed, by whom and when. This makes two reports
available, one for the user, and one for the auditors.


John Osborne


----- Original Message -----
From: Ron Pero <rp...@bo...>
To: <sql...@li...>
Sent: Monday, May 07, 2001 1:33 AM
Subject: Re: [SQL-Ledger-users] OT: Web-based Checking Software


> I could be wrong about this -- I'm not an accountant and do not use
> accounting software much -- but is it not an important principle that once
> you make an entry in a computerized accounting system, you do not allow it
> to be changed. If you want to cancel a previous entry, that cancellation
is
> a new entry that just reverses the previous entry. And if you made a
> mistake in a previous entry, you do not go back and change that entry, but
> instead you create new entries that make the correction. If this is true,
> then there is no consideration of changing an old entry and then
> recalculating the balance. The balance will always be up-to-date.
>
> Ron
>
>  At 04:17 PM 05/05/01 -0500, you wrote:
> >  Linas,
> >  Rather than keep a running total on a per-transaction basis, why not
> >keep a daily balance.  Then if you change a transaction 2 months ago,
> >you've got to apply one change to 60 entries and the change is always
> >the same (+/- X).  A single query can do that lickity-split.
> >  Then when you display, you calculate the running total from the
> >starting balance of the first day displayed, allowing you to process
> >(hopefully) very few transactions.  Alternately the running total could
> >be based on some arbitrary number of transactions (say the balance every
> >hundredth transaction to avoid problems with high-volumes of
> >transactions (e.g. a video store or a fast-food resteraunt that does
> >1000+ transactions/day).
> >  Just a thought
> >
> >Linas Vepstas wrote:
> >>
> >[...]
> >> Well, its 'almost' usable, except for one interesting technical problem
> >> I'd like to tell you about.  GnuCash likes to display accounts in a
> >> 'checkbook register style': that means that there is a running balance
> >> displayed in one of the columns (far right column).
> >>
> >> Say one has a millions transactions in the database. Clearly its insane
> >> to fetch all of them to compute a running balance.  We could store a
> >> running balance with each transaction, but this has a nasty update
> >> semantic: changing one transaction would require updates to hundreds
> >> or thousands of others that occur at a later date.  We talked about
> >> storing 'balance checkpoints' to solve that problem.  But this
> >> introduces another problem: I would need to query a contiguous set of
> >> transactions between checkpoints.  At this point, the sql queries start
> >> getting complex, there's a lot of traffic to the database, and yuck,
> >> so we left it to ferment a bit more.    If you are willing to ignore
> >> the running balance column, then I think the multi-user mode is not far
> >> off.  (there's some minor misc stuff that needs to be brushed up, I
> >> forget what).
> >>
> >[...]
> >
> >--
> >--------------------------------------------------------
> >Donald L. Greer, Jr                  dg...@Au...
> >System Administrator                 Voice: 512-835-8005
> >AustinTX.COM                    http://www.AustinTX.COM/
> >  All opinions are my own.  Flame me directly.
> >
> >"I don't necessarily believe software should be free...
> >but if you pay for it, it should work!" -- Me
> >
>
>

[SQL-Ledger-users] Q. on the TO-DO list.

[Wayne <inf...@pi...>]

Hello,
I see on the TO-DO list that  Steve has started
a payroll system and Roderick has started  aging
reports. Are these avaiable to view?
Thanks.
Wayne.

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

On Sun, May 06, 2001 at 08:33:34PM -0400, Ron Pero was heard to remark:
> I could be wrong about this -- I'm not an accountant and do not use
> accounting software much -- but is it not an important principle that once
> you make an entry in a computerized accounting system, you do not allow it
> to be changed. If you want to cancel a previous entry, that cancellation is
> a new entry that just reverses the previous entry. And if you made a
> mistake in a previous entry, you do not go back and change that entry, but
> instead you create new entries that make the correction. If this is true,
> then there is no consideration of changing an old entry and then
> recalculating the balance. The balance will always be up-to-date.

Gnucash is designed for the home user.  Thus, this proceedure is a bit
too compilcated; instead or paradigm is edit, and at some later date,
(after reconciliation/book close) freeze.  Certainly, after the books
are closed, one *must* do as you describe.

(Its easy to log such changes.  The hard part is to figure out how to
handle it elegantly in the user interface.  Even pro's want to
distinguish between a 'real' transaction, and a train of typos.
Visual and mental clutter leads to even more mistakes ...)

We've talked about having this kind of journalling, but this seems to be
a low priority for our user base.

--linas

[SQL-Ledger-users] Re: GLUG: Cannot install perl-DBD-Pg.

[Daniel S. <da...@ob...>]

Recently (Today) Jaco van Staden typed:

> error: failed dependencies:
>         libpq.so.1 is needed by perl-DBD-Pg-0.91-1
>
> I have already installed:
>
> perl-5.6.0-9
> perl-DBI-1.14-8
> postgresql-server-7.0.2-17
> postgresql-7.0.2-17
> postgresql-devel-7.0.2-17

I think there's a postgres-perl-x.x.x.rpm or a
perl-postgres-x.x.x.rpm...

-- 
Daniel Shaw                                       Obsidian Systems
Technical Support                                        Cape Town
083-296-8406                                        (021) 448-9265
da...@ob...                    http://www.obsidian.co.za/
--
                                       "Put your message in a modem
                                      And throw it in the Cyber Sea"
                                                             - Rush

[SQL-Ledger-users] Cannot install perl-DBD-Pg.

[Jaco v. S. <ja...@cy...>]

Hi

When I do: rpm -i perl-DBD-Pg-0.91-1.i386.rpm I get the following error:

error: failed dependencies:
        libpq.so.1 is needed by perl-DBD-Pg-0.91-1  

I have already installed:

perl-5.6.0-9 
perl-DBI-1.14-8 
postgresql-server-7.0.2-17 
postgresql-7.0.2-17
postgresql-devel-7.0.2-17 

Regards
 
-- 
Jaco van Staden
Cyber Seal Information Systems Development
Tel: +27 12 998 5674, Fax: +27 12 998 0249,
Cell: +27 82 927 5513, http://www.cyberseal.co.za

Re: [SQL-Ledger-users] Re: SQL update statement

[John C. L. N. <nj...@nt...>]

John O'Gorman wrote:
> 
> To selectively update rows: (I have made up column and table names)
> 
> UPDATE tx
>         SET (balance )= (SELECT expr from .... WHERE )
> WHERE txdate between today - 7 and today
> 
> Note the 'today' is appropriate for Informix. There will be an
> equivalent in PostgreSQL.

now() or CURRENT_DATE variable, I think....;-)


-- 
     /) John Clark Naldoza y Lopez                           (\
    / )    Software Design Engineer II                       ( \
  _( (_    _  Web-Application Development                    _) )_
 (((\ \>  /_>    Cable Modem Network Management System <_\  </ /)))
 (\\\\ \_/ /         NEC Telecom Software Phils., Inc.  \ \_/ ////)
  \       /                                              \       /
   \    _/  phone: (+63 32) 233-9142 loc. 3112            \_    /
   /   /  cellphone: (+63 919) 399-4742                     \   \
  /   / email: nj...@nt...                        \   \

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Terry C. <te...@wo...>]

Ron Pero wrote:
> 
> I could be wrong about this -- I'm not an accountant and do not use
> accounting software much -- but is it not an important principle that once
> you make an entry in a computerized accounting system, you do not allow it
> to be changed. If you want to cancel a previous entry, that cancellation is
> a new entry that just reverses the previous entry.

That is the way that it is done in the commercial programs that I am
forced to use.

Consider the case of sales, where there is a double entry.

Debit  Income from sale
Credit   Bank Account or Accounts Receivable
Debit  Cost of Goods Sold
Credit   Asset account for stock


--
   Terry Collins {:-)}}} Ph(02) 4627 2186 Fax(02) 4628 7861  
   email: te...@wo...  www: http://www.woa.com.au  
   WOA Computer Services <lan/wan, linux/unix, novell>

 "People without trees are like fish without clean water"

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Ron P. <rp...@bo...>]

I could be wrong about this -- I'm not an accountant and do not use
accounting software much -- but is it not an important principle that once
you make an entry in a computerized accounting system, you do not allow it
to be changed. If you want to cancel a previous entry, that cancellation is
a new entry that just reverses the previous entry. And if you made a
mistake in a previous entry, you do not go back and change that entry, but
instead you create new entries that make the correction. If this is true,
then there is no consideration of changing an old entry and then
recalculating the balance. The balance will always be up-to-date.

Ron

 At 04:17 PM 05/05/01 -0500, you wrote:
>  Linas,
>  Rather than keep a running total on a per-transaction basis, why not
>keep a daily balance.  Then if you change a transaction 2 months ago,
>you've got to apply one change to 60 entries and the change is always
>the same (+/- X).  A single query can do that lickity-split.
>  Then when you display, you calculate the running total from the
>starting balance of the first day displayed, allowing you to process
>(hopefully) very few transactions.  Alternately the running total could
>be based on some arbitrary number of transactions (say the balance every
>hundredth transaction to avoid problems with high-volumes of
>transactions (e.g. a video store or a fast-food resteraunt that does
>1000+ transactions/day).
>  Just a thought
>
>Linas Vepstas wrote:
>> 
>[...] 
>> Well, its 'almost' usable, except for one interesting technical problem
>> I'd like to tell you about.  GnuCash likes to display accounts in a
>> 'checkbook register style': that means that there is a running balance
>> displayed in one of the columns (far right column).
>> 
>> Say one has a millions transactions in the database. Clearly its insane
>> to fetch all of them to compute a running balance.  We could store a
>> running balance with each transaction, but this has a nasty update
>> semantic: changing one transaction would require updates to hundreds
>> or thousands of others that occur at a later date.  We talked about
>> storing 'balance checkpoints' to solve that problem.  But this
>> introduces another problem: I would need to query a contiguous set of
>> transactions between checkpoints.  At this point, the sql queries start
>> getting complex, there's a lot of traffic to the database, and yuck,
>> so we left it to ferment a bit more.    If you are willing to ignore
>> the running balance column, then I think the multi-user mode is not far
>> off.  (there's some minor misc stuff that needs to be brushed up, I
>> forget what).
>> 
>[...]
>
>-- 
>--------------------------------------------------------
>Donald L. Greer, Jr                  dg...@Au...
>System Administrator                 Voice: 512-835-8005
>AustinTX.COM                    http://www.AustinTX.COM/
>  All opinions are my own.  Flame me directly.
>
>"I don't necessarily believe software should be free...
>but if you pay for it, it should work!" -- Me
>

[SQL-Ledger-users] Re: SQL update statement

[John O'G. <ogo...@ho...>]

To selectively update rows: (I have made up column and table names)

UPDATE tx
	SET (balance )= (SELECT expr from .... WHERE )
WHERE txdate between today - 7 and today

Note the 'today' is appropriate for Informix. There will be an
equivalent in PostgreSQL.

To iterate through rows keeping a running balance, you will need
to open a cursor and use a FOREACH statement.

John O'Gorman

>From: li...@li... (Linas Vepstas)
>Reply-To: sql...@li...
>To: "Donald L Greer Jr." <dg...@au...>
>CC: sql...@li..., li...@li..., 
>gnu...@gn...
>Subject: Re: [SQL-Ledger-users] OT: Web-based Checking Software
>Date: Sat, 5 May 2001 23:17:14 -0500
>
>
>Hi Don,
>Good to hear from you, been a long time ...
>
>On Sat, May 05, 2001 at 04:17:40PM -0500, Donald L Greer Jr. was heard to 
>remark:
> >   Linas,
> >   Rather than keep a running total on a per-transaction basis, why not
> > keep a daily balance.  Then if you change a transaction 2 months ago,
> > you've got to apply one change to 60 entries and the change is always
> > the same (+/- X).
>
>right.  This is what I called a 'balance checkpoint' in the original
>note. (could be daily, could be every N transactions, whatever).
>
> > A single query can do that lickity-split.
>
>Umm. How good are you at sql?  I can't say that I know how to
>select 60 rows, add a value to a field, and update those rows,
>in a single sql statement.   Have I just not mastered the finer points
>of sql?  Can you sketch out that statement?
>
> >   Then when you display, you calculate the running total from the
> > starting balance of the first day displayed, allowing you to process
> > (hopefully) very few transactions.  Alternately the running total could
> > be based on some arbitrary number of transactions (say the balance every
> > hundredth transaction to avoid problems with high-volumes of
> > transactions (e.g. a video store or a fast-food resteraunt that does
> > 1000+ transactions/day).
> >   Just a thought
>
>The problem with what you describe is this:
>Say I want to display all transactions since noon, but the last
>balance checkpoint was midnight.  Thus, I have to query all transactions
>since midnight, compute the running blance, and display only those
>since noon.   It requires a little extra work, but its doable.
>
>Now imagine I want to show all transactions whose memo field starts
>with the letter A...
>
>see what the problem is? first I get all with letter A.  Then I need to
>figure out what checkpoint lies before the earliest transaction, get
>that, and then get all transactions since then, then compute the running
>balance ...  Ugh.
>
>Not too hard to explain, but rather tedious to code up.    Just tedious
>enough that I haven't done it ...
>
>--linas
>
>
> >
> > Linas Vepstas wrote:
> > >
> > [...]
> > > Well, its 'almost' usable, except for one interesting technical 
>problem
> > > I'd like to tell you about.  GnuCash likes to display accounts in a
> > > 'checkbook register style': that means that there is a running balance
> > > displayed in one of the columns (far right column).
> > >
> > > Say one has a millions transactions in the database. Clearly its 
>insane
> > > to fetch all of them to compute a running balance.  We could store a
> > > running balance with each transaction, but this has a nasty update
> > > semantic: changing one transaction would require updates to hundreds
> > > or thousands of others that occur at a later date.  We talked about
> > > storing 'balance checkpoints' to solve that problem.  But this
> > > introduces another problem: I would need to query a contiguous set of
> > > transactions between checkpoints.  At this point, the sql queries 
>start
> > > getting complex, there's a lot of traffic to the database, and yuck,
> > > so we left it to ferment a bit more.    If you are willing to ignore
> > > the running balance column, then I think the multi-user mode is not 
>far
> > > off.  (there's some minor misc stuff that needs to be brushed up, I
> > > forget what).
> > >
> > [...]
> >
> > --
> > --------------------------------------------------------
> > Donald L. Greer, Jr                  dg...@Au...
> > System Administrator                 Voice: 512-835-8005
> > AustinTX.COM                    http://www.AustinTX.COM/
> >   All opinions are my own.  Flame me directly.
> >
> > "I don't necessarily believe software should be free...
> > but if you pay for it, it should work!" -- Me
>
>--
>Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [SQL-Ledger-users] Boa "port"

[Andrew S. <an...@me...>]

I made a patch file and I was looking it over to make sure there
weren't too many ugly hacks in it, when it occured to me that you
might want just a tar ball or something.  Because I am using Debian,
there are various changes that are debian-isms, like the main home
httpd directory being /var/www instead of /home/httpd and like
that.  I don't know if you want all that or not.  Let me know
whether you want a tarball or just a patch file.

a

Dieter Simader wrote:
> 
> Version 1.2.10 is the last stable release.
> 
> Send me a copy of your mods and I'll post it as 1.2.11.
> 
> To send emails from different accounts subsribe to the list with all the
> email addresses you use and then disable delivery for the accounts you do
> not want to receive emails. This way you can post with any of your email
> addresses and receive a copy of the email in your favourite email box.
> 
> Dieter Simader    http://www.sql-ledger.org   (780) 472-8161
> DWS Systems Inc.     Accounting Software       Fax: 478-5281
> =========== On a clear disk you can seek forever ===========
> 
> On Fri, 4 May 2001, Andrew Sharp wrote:
> 
> > I made the necessary mods to sql-ledger to use it with boa instead
> > of apache.  And *boy*, it is a lot faster.  At least faster than it
> > was on my pobre 200MHz powerpc 604e dual processor.  I thought I
> > would ask if anyone else is interested in those mods.  The version
> > is 1.2, I think.  Is that version still relevant?  Actually I sent
> > an email some time ago about this, but apparently the list processor
> > is quite finicky about accepting emails only when the return address
> > is the same as a subscriber to the list.  Since I use several
> > different email addresses, sometimes I send emails and fail to
> > notice right away that it didn't get sent to the list.  If you're
> > not familiar, boa is a single threaded web server that is quite fast
> > compared to apache, but has a very short feature list, by
> > comparison.
> >
> > a
> >
> >

Re: [SQL-Ledger-users] Another Perl Accounting Package, PGSQL List

[Maria G. F. <mg...@ma...>]

I'll be very interested in this application too as a user

Greetings!


----- Original Message -----
From: "Ron Pero" <rp...@bo...>
To: <sql...@li...>
Sent: Friday, May 04, 2001 12:17 PM
Subject: [SQL-Ledger-users] Another Perl Accounting Package, PGSQL List


> Date: Fri, 04 May 2001 07:57:43 +0200
> From: Robert <ro...@ro...>
> X-Mailer: Mozilla 4.76 [en] (Win98; U)
> X-Accept-Language: en
> To: pgs...@po...
> CC: Ludwig Meyerhoff <lu...@an...>
> Subject: Re: Invoices
> Sender: pgs...@po...
>
> Ludwig Meyerhoff wrote:
> >
> > Maybe this is a bit off-topic, as this problem is more a "design"-one,
but
> > I wanted to write a web-application write invoices more easy.
> > ...
>
>   Hi,
>
>   I write the same application for the same reasons - we're three
> partners and we all want to be able to create invoices and also see what
> others create. A rather experimental version runs at
> http://www.eucto.cz/ login as 'admin_jaskot', no password, you need
> IE5+. It's in Czech, but you just go to 'Faktury' (Invoices), 'Nova
> faktura' (New Invoice), 'Ulozit' (Save) and 'Tisk' (Print). The
> application has grown a bit since I started and now it's slowly becoming
> complete web-based accounting package. When I finish new version (in
> maybe three weeks), it should do receivable, payable, cash, bank, should
> print fine and should have basic support for multiple users and multiple
> companies. Then I clean it up, add a bunch of gettext's to prepare an
> English version and start to think really hard about releasing the
> source. It's based on PostgreSQL/Apache/Perl (currently mod_perl &
> HTML::Embperl) and it (almost) works with recent Mozilla builds. I
> expect to get paid as a consultant by accounting companies that would
> offer this as a web service to their clients and/or for running this
> service for them.
>
>   So, here's the preliminary inquiry: anybody interested in such a thing
> as a user or as a developer?
>
>   - Robert
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>

[SQL-Ledger-users] How to use the links feature

[Glenn R. <gl...@co...>]

Hi,

I operate a couple of small businesses and out of all the open
source accounting software I could find sql-ledger seems to be the
one that will suit my needs the best.

However I need to be able to include GST on all AR and AP
transactions but I can't figure out how the accounts need to be
set up to do this. I guess it's got something to do with the links
feature, but I don't really understand how it works and the link
accounts setup page doesn't indicate what relationships are being
set up.

Specifically what I need to do is to have the GST component of all
expenses and income to be shown on all customer and vendor
invoices and put into into separate accounts for expenses and
income. The GST to pay to the tax dept is then worked out by (GST
on income - GST on expenses).

Could someone please help me with an explanation of how links work
and maybe a  simple example of how to set it up for my GST
situation?

Thanks in advance
g (in New Zealand)

-- 
Glenn Ramsey
gl...@co...

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

Hi Don,
Good to hear from you, been a long time ...

On Sat, May 05, 2001 at 04:17:40PM -0500, Donald L Greer Jr. was heard to remark:
>   Linas,
>   Rather than keep a running total on a per-transaction basis, why not
> keep a daily balance.  Then if you change a transaction 2 months ago,
> you've got to apply one change to 60 entries and the change is always
> the same (+/- X).  

right.  This is what I called a 'balance checkpoint' in the original
note. (could be daily, could be every N transactions, whatever).

> A single query can do that lickity-split.

Umm. How good are you at sql?  I can't say that I know how to 
select 60 rows, add a value to a field, and update those rows,
in a single sql statement.   Have I just not mastered the finer points
of sql?  Can you sketch out that statement?

>   Then when you display, you calculate the running total from the
> starting balance of the first day displayed, allowing you to process
> (hopefully) very few transactions.  Alternately the running total could
> be based on some arbitrary number of transactions (say the balance every
> hundredth transaction to avoid problems with high-volumes of
> transactions (e.g. a video store or a fast-food resteraunt that does
> 1000+ transactions/day).
>   Just a thought

The problem with what you describe is this:
Say I want to display all transactions since noon, but the last
balance checkpoint was midnight.  Thus, I have to query all transactions
since midnight, compute the running blance, and display only those
since noon.   It requires a little extra work, but its doable.

Now imagine I want to show all transactions whose memo field starts
with the letter A...

see what the problem is? first I get all with letter A.  Then I need to
figure out what checkpoint lies before the earliest transaction, get
that, and then get all transactions since then, then compute the running
balance ...  Ugh.

Not too hard to explain, but rather tedious to code up.    Just tedious
enough that I haven't done it ...

--linas


> 
> Linas Vepstas wrote:
> > 
> [...] 
> > Well, its 'almost' usable, except for one interesting technical problem
> > I'd like to tell you about.  GnuCash likes to display accounts in a
> > 'checkbook register style': that means that there is a running balance
> > displayed in one of the columns (far right column).
> > 
> > Say one has a millions transactions in the database. Clearly its insane
> > to fetch all of them to compute a running balance.  We could store a
> > running balance with each transaction, but this has a nasty update
> > semantic: changing one transaction would require updates to hundreds
> > or thousands of others that occur at a later date.  We talked about
> > storing 'balance checkpoints' to solve that problem.  But this
> > introduces another problem: I would need to query a contiguous set of
> > transactions between checkpoints.  At this point, the sql queries start
> > getting complex, there's a lot of traffic to the database, and yuck,
> > so we left it to ferment a bit more.    If you are willing to ignore
> > the running balance column, then I think the multi-user mode is not far
> > off.  (there's some minor misc stuff that needs to be brushed up, I
> > forget what).
> > 
> [...]
> 
> -- 
> --------------------------------------------------------
> Donald L. Greer, Jr                  dg...@Au...
> System Administrator                 Voice: 512-835-8005
> AustinTX.COM                    http://www.AustinTX.COM/
>   All opinions are my own.  Flame me directly.
> 
> "I don't necessarily believe software should be free...
> but if you pay for it, it should work!" -- Me

-- 
Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Donald L G. Jr. <dg...@au...>]

  Linas,
  Rather than keep a running total on a per-transaction basis, why not
keep a daily balance.  Then if you change a transaction 2 months ago,
you've got to apply one change to 60 entries and the change is always
the same (+/- X).  A single query can do that lickity-split.
  Then when you display, you calculate the running total from the
starting balance of the first day displayed, allowing you to process
(hopefully) very few transactions.  Alternately the running total could
be based on some arbitrary number of transactions (say the balance every
hundredth transaction to avoid problems with high-volumes of
transactions (e.g. a video store or a fast-food resteraunt that does
1000+ transactions/day).
  Just a thought

Linas Vepstas wrote:
> 
[...] 
> Well, its 'almost' usable, except for one interesting technical problem
> I'd like to tell you about.  GnuCash likes to display accounts in a
> 'checkbook register style': that means that there is a running balance
> displayed in one of the columns (far right column).
> 
> Say one has a millions transactions in the database. Clearly its insane
> to fetch all of them to compute a running balance.  We could store a
> running balance with each transaction, but this has a nasty update
> semantic: changing one transaction would require updates to hundreds
> or thousands of others that occur at a later date.  We talked about
> storing 'balance checkpoints' to solve that problem.  But this
> introduces another problem: I would need to query a contiguous set of
> transactions between checkpoints.  At this point, the sql queries start
> getting complex, there's a lot of traffic to the database, and yuck,
> so we left it to ferment a bit more.    If you are willing to ignore
> the running balance column, then I think the multi-user mode is not far
> off.  (there's some minor misc stuff that needs to be brushed up, I
> forget what).
> 
[...]

-- 
--------------------------------------------------------
Donald L. Greer, Jr                  dg...@Au...
System Administrator                 Voice: 512-835-8005
AustinTX.COM                    http://www.AustinTX.COM/
  All opinions are my own.  Flame me directly.

"I don't necessarily believe software should be free...
but if you pay for it, it should work!" -- Me

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Roderick A. A. <raa...@ti...>]

On Fri, 4 May 2001, Designer wrote:

> "Roderick A. Anderson" wrote:
> 
> Try CBB, or Check Book Balancer. However, it only a personal finance
> module, but it is written inter Perl and TK......

I have used CBB and liked it a lot.  But ... I'd really like a
server/browser version that I could tie into SQL-Ledger.


Rod
-- 

Re: [SQL-Ledger-users] Boa "port"

[Metin O. <me...@tu...>]

Dear a,

Yes, it would be great to try out your work on boa server.  I was thinking
about faster response times myself for some other perl apps too.

m :)

At 06:47 PM 5/4/01 -0700, you wrote:
>I made the necessary mods to sql-ledger to use it with boa instead
>of apache.  And *boy*, it is a lot faster.  At least faster than it
>was on my pobre 200MHz powerpc 604e dual processor.  I thought I
>would ask if anyone else is interested in those mods.  The version
>is 1.2, I think.  Is that version still relevant?  Actually I sent
>an email some time ago about this, but apparently the list processor
>is quite finicky about accepting emails only when the return address
>is the same as a subscriber to the list.  Since I use several
>different email addresses, sometimes I send emails and fail to
>notice right away that it didn't get sent to the list.  If you're
>not familiar, boa is a single threaded web server that is quite fast
>compared to apache, but has a very short feature list, by
>comparison.
>
>a