the trigger. I am sure that this type of change
> (moving accounts) will not be a common thing once the COA has been set up
> and in use for a while.
>
> HTH.
> Michael
>
>> Date: Mon, 10 Nov 2008 05:24:03 +0100
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
gt; From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> Subject: Re: [GENERAL] Chart of Accounts> CC:
> pgsql-general@postgresql.org> > Hi James,> > There is some my publications
> about SART AML System based on banking> General Ledger (OLAP Data Warehouse
> and Chart
Hi James,
There is some my publications about SART AML System based on banking
General Ledger (OLAP Data Warehouse and Chart of Accounts as dimension
with 60 000+ items) - may be helpful.
http://www.analyticsql.org/documentation.html
http://www.analyticsql.org/files/AITM-MoneyLaundering.pdf
Rega
Sorry for the silence. Have been away on official duty. Please see inline:
--- On Mon, 13/10/08, justin <[EMAIL PROTECTED]> wrote:
>
>
> Create Table general_ledger_transactions(
> transaction_id serial not null
> coad_id integer,
> accounting_period integer,
> debit nu
James Hitz wrote:
As I said earlier, I am quite green with PGSQL, so please bear with me when I ask
"Stupid" questions...
--- On Mon, 13/10/08, justin <[EMAIL PROTECTED]> wrote:
I just redid the accounting side of an application we have
access to
source code, so been here and done this.
As I said earlier, I am quite green with PGSQL, so please bear with me when I
ask "Stupid" questions...
--- On Mon, 13/10/08, justin <[EMAIL PROTECTED]> wrote:
> I just redid the accounting side of an application we have
> access to
> source code, so been here and done this.
>
> If i was not
On Tue, Oct 14, 2008 at 3:50 PM, Isak Hansen <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 13, 2008 at 2:57 AM, justin <[EMAIL PROTECTED]> wrote:
>> [...] Also you want to split out the debit and credits instead of
>> using one column. Example one column accounting table to track values
>> entered how
On Tue, Oct 14, 2008 at 5:07 PM, justin <[EMAIL PROTECTED]> wrote:
> because a credit account is a liability account aka a negative account so
> credit a credit account causes it to go UP not down.
As you say, "a negative account". Our liability accounts go further
down when credited. I work with
Isak Hansen wrote:
On Mon, Oct 13, 2008 at 2:57 AM, justin <[EMAIL PROTECTED]> wrote:
[...] Also you want to split out the debit and credits instead of
using one column. Example one column accounting table to track values
entered how do you handle Crediting a Credit Account Type. is it a n
because a credit account is a liability account aka a negative account
so credit a credit account causes it to go UP not down. Look a your
bank statement it says Credit you $500 when you make a deposit its a
debit to you a credit to the bank in a credit account as its a liability
to the bank.
On Mon, Oct 13, 2008 at 2:57 AM, justin <[EMAIL PROTECTED]> wrote:
> [...] Also you want to split out the debit and credits instead of
> using one column. Example one column accounting table to track values
> entered how do you handle Crediting a Credit Account Type. is it a negative
> or positi
TECTED]
Cc: pgsql-general@postgresql.org
Date: Sun, 12 Oct 2008 20:57:59 -0400
Subject: Re: [GENERAL] Chart of Accounts
You are making this far to complicated.
I just redid the accounting side of an application we have access to
source code, so been here and done this.
If i was not for th
Craig Bennett wrote:
If you want to take a particular system out to extra digits, it's
probably good to record the rounding error as a separate component of
the transaction (that is, if you want everything to balance out
perfectly).
I think you have two different problems here. On the one
If you want to take a particular system out to extra digits, it's
probably good to record the rounding error as a separate component of
the transaction (that is, if you want everything to balance out
perfectly).
I think you have two different problems here. On the one hand you have
rounding
On Mon, Oct 13, 2008 at 6:33 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> justin <[EMAIL PROTECTED]> writes:
>
>> special note do not use only 2 decimal points in the accounting tables. If
>> your application uses 10 decimal places somewhere then every table in the
>> database that has decimals
Gregory Stark wrote:
justin <[EMAIL PROTECTED]> writes:
special note do not use only 2 decimal points in the accounting tables. If
your application uses 10 decimal places somewhere then every table in the
database that has decimals needs to have the same precision. Nothing is more
annoyi
justin <[EMAIL PROTECTED]> writes:
> special note do not use only 2 decimal points in the accounting tables. If
> your application uses 10 decimal places somewhere then every table in the
> database that has decimals needs to have the same precision. Nothing is more
> annoying where a transactio
You are making this far to complicated.
I just redid the accounting side of an application we have access to
source code, so been here and done this.
If i was not for the rest of the application i would have completely
redone the accounting table layout something like this
3 Accounting Tabl
Dear All,
I have just started experimenting with PGSQL, with a view to migrate from the
SQL server I use currently. I am trying to implement an "intelligent" Chart of
Accounts for an accounting program. The following is long-winded but please
bear with me:
I have a table coa (chart of accoun
19 matches
Mail list logo
