Thread: 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
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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@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&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 > > 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&twocents@openknowledge.org > Read the _Wall Street Performer Protocol_: > http://www.openknowledge.org/writing/open-source/scb/ > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > >
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
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 > Any hints would be appreciated. > > Dave > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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. > > > > 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 > > > Any hints would be appreciated. > > > > Dave > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > >
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
Credits are positive, debits are negative. I have never seen an accounting package that did not follow this basic rule. 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. > > Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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.