Web-based Problem/Project tracking system ...

The Hermit Hacker wrote:

Keystone not withstanding (we didn't like it much), can anyone recommend a
good tracking system that runs with a PgSQL backend, and, at minimum

Hi Marc,

Have you checked out the software development manager? It's part of the openACS
distribution. You can see it in action here:

http://openacs.org/sdm/open-bafs.tcl?package_id=2

Chris

--
Use e-gold? Send me two cents:
http://2cw.org/257121&twocents@openknowledge.org
Read the _Wall Street Performer Protocol_:
http://www.openknowledge.org/writing/open-source/scb/

Have to agree, didn't like Keystone much myself. I am interested too.

The acs system looks interesting... but is running on AolServer.. this kind
of interferes with what I currently have .... any others?

I do know that the there is some work being done on a java based one called
scarab. scarab.tigris.org. It doesn't look like it has gotten too far though
;(

Dave
----- Original Message -----
From: "The Hermit Hacker" <scrappy@hub.org>
To: <freebsd-questions@freebsd.org>
Cc: <pgsql-general@postgresql.org>
Sent: Saturday, May 05, 2001 2:03 PM
Subject: [GENERAL] Web-based Problem/Project tracking system ...

Keystone not withstanding (we didn't like it much), can anyone recommend a
good tracking system that runs with a PgSQL backend, and, at minimum,
would provide the ability for a client to have a login id/pass that they
can login to add/comment on/close and view their own tickets, while our
help desk personel would be able to view everything?

It has to be reasonably intuitive on the front-end side ... don't want to
have to spend hours upon hours just answering questions about how to use
the thing :)

Thanks ...

Marc G. Fournier ICQ#7615664 IRC Nick:

Scrappy

Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:

scrappy@{freebsd|postgresql}.org

Dave Cramer wrote:

Have to agree, didn't like Keystone much myself. I am interested too.

The acs system looks interesting... but is running on AolServer.. this kind
of interferes with what I currently have .... any others?

You can run the ACS with Apache, if that's the issue. You will need
mod_aolserver, which provides access to the AOLserver API.

Chris

--
Use e-gold? Send me two cents:
http://2cw.org/257121&amp;twocents@openknowledge.org
Read the _Wall Street Performer Protocol_:
http://www.openknowledge.org/writing/open-source/scb/

Oh, cool... that is something then...
Thanks I will give it a spin..

Dave
----- Original Message -----
From: "Chris Rasch" <crasch@openknowledge.org>
To: <pgsql-general@postgresql.org>
Sent: Saturday, May 05, 2001 5:17 PM
Subject: Re: [GENERAL] Web-based Problem/Project tracking system ...

Dave Cramer wrote:

Have to agree, didn't like Keystone much myself. I am interested too.

The acs system looks interesting... but is running on AolServer.. this

kind

Hi all,

Can anyone out there with more experience than me give me some hints as to
how to do accounting tables in a db. The problem I am wrestling with is how
to represent credits, and debits.
One way is to identify credits and debits with a transactiontype, and keep
all of the numbers positive which models the way accountants do it. This
makes things liking calculating the balance difficult with a sql statement.

Any hints would be appreciated.

Dave

Credits are positive, debits are negative. I have never seen an accounting
package that did not follow this basic rule.

Dave Cramer wrote:

On Sat, May 05, 2001 at 07:09:13PM -0400, some SMTP stream spewed forth:

Hi all,

Can anyone out there with more experience than me give me some hints as to
how to do accounting tables in a db. The problem I am wrestling with is how
to represent credits, and debits.
One way is to identify credits and debits with a transactiontype, and keep
all of the numbers positive which models the way accountants do it. This
makes things liking calculating the balance difficult with a sql statement.

Keep in mind that what is in the database and what the user sees do not
have to be the same...
You could store the values in the database as positive or negative
convert them to all positives (with a determined "transaction type")
accordingly for display.

gh

Ya, thought of that. I generally prefer to keep my data model consistent. It
has some merit though, thanks

--dc--
----- Original Message -----
From: "GH" <grasshacker@over-yonder.net>
To: "Dave Cramer" <Dave@micro-automation.net>
Cc: <pgsql-general@postgresql.org>
Sent: Saturday, May 05, 2001 7:48 PM
Subject: Re: [GENERAL] Accounting Schema

On Sat, May 05, 2001 at 07:09:13PM -0400, some SMTP stream spewed forth:

Hi all,

Can anyone out there with more experience than me give me some hints as

to

how to do accounting tables in a db. The problem I am wrestling with is

how

to represent credits, and debits.
One way is to identify credits and debits with a transactiontype, and

keep

all of the numbers positive which models the way accountants do it. This
makes things liking calculating the balance difficult with a sql

statement.

Hallo!

Ya, thought of that. I generally prefer to keep my data model consistent. It
has some merit though, thanks

Keep all amounts positive, cumulate income and outcome, and to calculate
profit/loss subtract the smaller number from the bigger one.
So You will avoid negative numbers (You will only have to put the result
in the proper column: profit/loss)

LUdwig

Dave Cramer wrote:

Hi all,

Can anyone out there with more experience than me give me some hints as to
how to do accounting tables in a db. The problem I am wrestling with is how
to represent credits, and debits.
One way is to identify credits and debits with a transactiontype, and keep
all of the numbers positive which models the way accountants do it. This
makes things liking calculating the balance difficult with a sql statement.

Any hints would be appreciated.

In accounting systems I have written I seem to be evolving towards a schema along
these lines:

AccountGroup ( <pk>AccountGroupCode</pk>, Description )
ChartOfAccount ( <pk>AccountCode</pk>, <fk>AccountGroupCode</fk>, Name )
AcctgEntityType ( <pk>AcctgEntityTypeCode</pk>, Description )
AcctgEntity ( <pk>AcctgEntityCode</pk>, <fk>AcctgEntityTypeCode</fk>, Description )
AccountTransaction ( <fk>AcctgEntityCode</fk>, <fk>AccountCode</fk>, Description,
Amount , Date, <fk>FinancialPeriodCode</fk> )

From there I denormalise substantially, holding balance records which are the sum of
the AccountTransaction records for FinancialPeriods (maintained by a trigger). I
hold budget / revised budget figures on those records as well. All of this also
gets summarised (again by triggers) to maintain a "current balance" which is the sum
of all transactions, ever (and budgets etc).

The denormalisation really helps reporting because most reports want figures at the
end of some financial period, usually the one just prior to the current one. This
means that taking the "current balance" and subtracting any balances for months
after the end of the period we're looking for is (heuristically) the quickest way to
get a balance as at the end of any period. The accounting systems I have
constructed in this way typically hold around fourteen years of data now, so that
heuristic really does apply in most real-world cases. I could hold a cumulative
balance for each period, rather than just a total transactions for the period, but
it is much more work to maintain the consistency of data in that sort of form, and
accounting systems need to be provably giving the correct answers.

As for the amounts: NUMBER would seem the best type to represent them, although
INT8 could also be a nice way. The decision would largely rest on the handling of
multiple currencies. In my experience Credits are universally recognised as nasty
things which we don't want to have too many of, and should be portrayed in as
negative a manner as possible.... :-)

Feel free to enquire further by private e-mail if you are interested in more
details.

Regards,
Andrew.
--
_____________________________________________________________________
Andrew McMillan, e-mail: Andrew@catalyst.net.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64(21)635-694, Fax: +64(4)499-5596, Office: +64(4)499-2267xtn709

Ian Harding wrote:

Credits are positive, debits are negative. I have never seen an accounting
package that did not follow this basic rule.

It's the other way round. To help remember:

debit = "He owes" and represents an asset or an expense
credit = "He trusts [to be repaid] for" and represents a liability or a
receipt.

Since debits are assets, they are naturally represented by positive sign.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Dearly beloved, avenge not yourselves, but rather give
place unto wrath. For it is written, Vengeance is
mine; I will repay, saith the Lord. Therefore if thine
enemy hunger, feed him; if he thirst, give him drink;
for in so doing thou shalt heap coals of fire on his
head. Be not overcome of evil, but overcome evil with
good." Romans 12:19-21

The Hermit Hacker <scrappy@hub.org> writes:

Keystone not withstanding (we didn't like it much), can anyone recommend a
good tracking system that runs with a PgSQL backend, and, at minimum,
would provide the ability for a client to have a login id/pass that they
can login to add/comment on/close and view their own tickets, while our
help desk personel would be able to view everything?

Bugzilla is rather nice - while I don't know if a postgresql specific
backend exists, there are multiple ones (at least Oracle, MySQL), so
if it isn't already there, it shouldn't be too hard to add.

--
Trond Eivind Glomsr�d
Red Hat, Inc.