General Journal

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

General Journal

cgw993
 

Hi,

I am new to GNU software in general and am a big supporter of the FSF ideas.
Gnucash looks like it will be very useful.   I have also recently decided to
learn the basics of bookkeeping as is taught in a textbook or by a teacher
instead of as is taught by quickbooks or some other proprietary software.

 

 

Most people I would guess do not have a basic understanding of bookkeeping
principals or the accounting equation.   This is just my opinion but I
believe that you cannot keep books unless you have this basic understanding.
The software makers, to some extent this includes Gnucash, seem to try to
bypass bookkeeping fundamentals and to create their own system in order to
"simplify" the process for people that are not familiar with the basics of
bookkeeping.   I strongly believe this is not a good practice and that this
will cause more failures than successes in helping people to keep their own
books.  But I could be wrong, I did just after all learn some basic things
about bookkeeping recently.

 

 

The very first thing that I was taught to do, and what I assume is taught by
most textbooks, is to become familiar with the concept of the General
Journal.    This is probably the most critical step in the entire
bookkeeping process.   It is during this step that the nature of the
transaction and the amounts involved first enter the bookkeeping system.
It is also at this step that the user can easily verify that the transaction
is balanced.     In order to become familiar with how to use the general
journal, one has to practice with transaction analysis problems.   An
example transaction analysis problem -  

 

You buy $73 of groceries with your checking account -

 

Debit Account - Expense Groceries $73

Credit Account - Checking $73

 

What happens if instead you use a credit card to make the purchase?  What
about if you used cash, spent $80, paid $73 for groceries and tipped $7 to
the person who helped carry the bags to the car?  Understanding how to enter
this into the general journal is critical and in fact all over steps pretty
much take care of themselves after this point.

 

Why in the world accounting software would want to bypass the General
Journal in some way.   Almost all software seems to intentionally do this.
The General Journal is the most important part of the bookkeeping process.
Why would you want to skip this step and go right to the General Ledger?
This is not how students are taught bookkeeping.  Going straight to the
general ledger seems like a guarantee that the books will never be balanced
and that the user will never really understand what money is going where and
how and why.

 

Many people that switch to Gnucash have existing data they would like to set
up.  This can involve dozens of accounts and thousands of transactions.
For example I use excel and would like to instead use Gnucash.    I can save
the spreadsheet as a .csv file, but the problem with Gnucash is that I guess
I can only import one account at a time?   Why not let me specify right in
the spreadsheet the name of the account that transaction goes into?

 

If Gnucash used a general journal as the point of entry into the sytem, it
seems like it would be easier for people to import their data.   Is there a
way around the problem of importing one account at a time?

Thank You

 

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Buddha Buck
Books on basic bookkeeping also discuss "T-Accounts" too, but no one
actually keeps books that way.  There are a lot of things taught in basic
books which are useful and important for understanding the basic concepts
than are actually used.

The idea of the General Journal being the initial entry-point of all
transactions is one of these things.  Even in traditional, manual
double-entry bookkeeping the General Journal was just one of many journals
typically used, in addition to sales journals, cash journals, etc.  Many
actual journals have an implicit assumption that one account will always be
involved in the transaction, and provide places to record the other
account(s) involved (for instance, a "sales journal" might have columns for
sale amount, sales tax, cash, check, credit, so that when the journal is
transferred to the ledgers, the sales column corresponds to the appropriate
income account, the sales tax column corresponds to the appropriate
liability account, the other columns correspond to their respective asset
accounts, etc).  In this setting, the "General Journal" proper is used only
for transactions that can't easily be recorded in more specialized journals.

That said, every DE-accounting package that I have been able to examine (or
write) has, at it's core, the functional equivalent of a General Journal,
in the form of a date-stamped collection of transactions, each of which
must balance debits and credits.  Very few DE-accounting packages use the
General Journal as a main data-entry method.  Why? Because it's
inconvenient, and not how most people think.  Most people think in terms of
specific workflows that look at one main account at a time -- like the
non-general journals mentioned above.  The account registers in GnuCash act
like specialized journals, one for each account.  You see a time-ordered
list of transactions (journal entries) that involve that account.

Note that this is different than what you see in a standard T-account
ledger.  Usually, you don't see the rest of the transaction involved in a
ledger-entry; you just see it's effect in the one ledger (ideally, there'd
be an identifier to be able to look up the rest of the transaction in the
journals, for auditing and error-correcting purposes).  In the GnuCash
registers/journals, you see the other account(s) involved in the
transaction as well.

That said, under Tools->General Ledger, GnuCash provides a General
Journal-style display and entry.  Every entry is displayed like a "split
transaction", even if only two accounts are involved.  Furthermore,
whenever you use the "split" button you effectively get a portion of the
General Journal exposed in the current register (you can use a split entry
to put stuff into any set of accounts, even excluding the account who's
register you are currently using).



On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:

>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
> ideas.
> Gnucash looks like it will be very useful.   I have also recently decided
> to
> learn the basics of bookkeeping as is taught in a textbook or by a teacher
> instead of as is taught by quickbooks or some other proprietary software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic
> understanding.
> The software makers, to some extent this includes Gnucash, seem to try to
> bypass bookkeeping fundamentals and to create their own system in order to
> "simplify" the process for people that are not familiar with the basics of
> bookkeeping.   I strongly believe this is not a good practice and that this
> will cause more failures than successes in helping people to keep their own
> books.  But I could be wrong, I did just after all learn some basic things
> about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is taught
> by
> most textbooks, is to become familiar with the concept of the General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
> transaction
> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?  What
> about if you used cash, spent $80, paid $73 for groceries and tipped $7 to
> the person who helped carry the bags to the car?  Understanding how to
> enter
> this into the general journal is critical and in fact all over steps pretty
> much take care of themselves after this point.
>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to the
> general ledger seems like a guarantee that the books will never be balanced
> and that the user will never really understand what money is going where
> and
> how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like to
> set
> up.  This can involve dozens of accounts and thousands of transactions.
> For example I use excel and would like to instead use Gnucash.    I can
> save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
> guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there a
> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
 

Thanks for sharing.   I should just use the generic term Journal instead of General Journal.  I guess I had assumed GNUcash would have used old school traditional bookkeeping practices because that is how I learned to do bookkeeping and the method I want to stick with.   I don’t want to have to create a matrix where it identifies a traditional bookkeeping term, and then if you follow the row and column, you can identify what the "equivalent" concept is in GNUcash.     I saw this a lot in proprietary software everywhere and it seems like nothing more than a way to control the users and keep them dependent on a unique way of doing something.   In the digital age, I don’t think doing something old school should have to slow a workflow.  I prefer old school, old school is good,  it has proven again and again to me at least that it is always a system you can depend on and others can understand. If everyone uses a different methodology, no one will understand each other and business will be good for proprietary software makers.    If GNUcash does not use a journal as the point of entry, I don’t want to invest the time in learning it.  For one thing, it looks like it is going to be very time consuming just to import my data because of this, which is essentially already in the form of a journal the way it is supposed to me.  All GNUcash needs to do is create or identify the account by looking at my spreadsheet, put the data in that account, then do the same for the other accounts in that transaction as indicated from my journal.  Seems simple.

 

Thank you for your thoughts though as it helped me get up to speed much faster.    If you or anyone knows of another GNU bookkeeping package where I can use a journal as the point of entry and the software uses the traditional terms and methods most people would know from basic bookkeeping.  

 

 

From: Buddha Buck [mailto:[hidden email]]
Sent: Wednesday, August 07, 2013 6:15 PM
To: [hidden email]
Cc: GnuCash Users List
Subject: Re: General Journal

 

Books on basic bookkeeping also discuss "T-Accounts" too, but no one actually keeps books that way.  There are a lot of things taught in basic books which are useful and important for understanding the basic concepts than are actually used.  

 

The idea of the General Journal being the initial entry-point of all transactions is one of these things.  Even in traditional, manual double-entry bookkeeping the General Journal was just one of many journals typically used, in addition to sales journals, cash journals, etc.  Many actual journals have an implicit assumption that one account will always be involved in the transaction, and provide places to record the other account(s) involved (for instance, a "sales journal" might have columns for sale amount, sales tax, cash, check, credit, so that when the journal is transferred to the ledgers, the sales column corresponds to the appropriate income account, the sales tax column corresponds to the appropriate liability account, the other columns correspond to their respective asset accounts, etc).  In this setting, the "General Journal" proper is used only for transactions that can't easily be recorded in more specialized journals.

 

That said, every DE-accounting package that I have been able to examine (or write) has, at it's core, the functional equivalent of a General Journal, in the form of a date-stamped collection of transactions, each of which must balance debits and credits.  Very few DE-accounting packages use the General Journal as a main data-entry method.  Why? Because it's inconvenient, and not how most people think.  Most people think in terms of specific workflows that look at one main account at a time -- like the non-general journals mentioned above.  The account registers in GnuCash act like specialized journals, one for each account.  You see a time-ordered list of transactions (journal entries) that involve that account.

 

Note that this is different than what you see in a standard T-account ledger.  Usually, you don't see the rest of the transaction involved in a ledger-entry; you just see it's effect in the one ledger (ideally, there'd be an identifier to be able to look up the rest of the transaction in the journals, for auditing and error-correcting purposes).  In the GnuCash registers/journals, you see the other account(s) involved in the transaction as well.

 

That said, under Tools->General Ledger, GnuCash provides a General Journal-style display and entry.  Every entry is displayed like a "split transaction", even if only two accounts are involved.  Furthermore, whenever you use the "split" button you effectively get a portion of the General Journal exposed in the current register (you can use a split entry to put stuff into any set of accounts, even excluding the account who's register you are currently using).

 

 

On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:



Hi,

I am new to GNU software in general and am a big supporter of the FSF ideas.
Gnucash looks like it will be very useful.   I have also recently decided to
learn the basics of bookkeeping as is taught in a textbook or by a teacher
instead of as is taught by quickbooks or some other proprietary software.





Most people I would guess do not have a basic understanding of bookkeeping
principals or the accounting equation.   This is just my opinion but I
believe that you cannot keep books unless you have this basic understanding.
The software makers, to some extent this includes Gnucash, seem to try to
bypass bookkeeping fundamentals and to create their own system in order to
"simplify" the process for people that are not familiar with the basics of
bookkeeping.   I strongly believe this is not a good practice and that this
will cause more failures than successes in helping people to keep their own
books.  But I could be wrong, I did just after all learn some basic things
about bookkeeping recently.





The very first thing that I was taught to do, and what I assume is taught by
most textbooks, is to become familiar with the concept of the General
Journal.    This is probably the most critical step in the entire
bookkeeping process.   It is during this step that the nature of the
transaction and the amounts involved first enter the bookkeeping system.
It is also at this step that the user can easily verify that the transaction
is balanced.     In order to become familiar with how to use the general
journal, one has to practice with transaction analysis problems.   An
example transaction analysis problem -



You buy $73 of groceries with your checking account -



Debit Account - Expense Groceries $73

Credit Account - Checking $73



What happens if instead you use a credit card to make the purchase?  What
about if you used cash, spent $80, paid $73 for groceries and tipped $7 to
the person who helped carry the bags to the car?  Understanding how to enter
this into the general journal is critical and in fact all over steps pretty
much take care of themselves after this point.



Why in the world accounting software would want to bypass the General
Journal in some way.   Almost all software seems to intentionally do this.
The General Journal is the most important part of the bookkeeping process.
Why would you want to skip this step and go right to the General Ledger?
This is not how students are taught bookkeeping.  Going straight to the
general ledger seems like a guarantee that the books will never be balanced
and that the user will never really understand what money is going where and
how and why.



Many people that switch to Gnucash have existing data they would like to set
up.  This can involve dozens of accounts and thousands of transactions.
For example I use excel and would like to instead use Gnucash.    I can save
the spreadsheet as a .csv file, but the problem with Gnucash is that I guess
I can only import one account at a time?   Why not let me specify right in
the spreadsheet the name of the account that transaction goes into?



If Gnucash used a general journal as the point of entry into the sytem, it
seems like it would be easier for people to import their data.   Is there a
way around the problem of importing one account at a time?

Thank You



_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

 

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

foxylady337
On 8 Aug 2013, at 03:20, [hidden email] wrote:

>
>
> Thanks for sharing.   I should just use the generic term Journal instead of General Journal.  I guess I had assumed GNUcash would have used old school traditional bookkeeping practices because that is how I learned to do bookkeeping and the method I want to stick with.   I don’t want to have to create a matrix where it identifies a traditional bookkeeping term, and then if you follow the row and column, you can identify what the "equivalent" concept is in GNUcash.     I saw this a lot in proprietary software everywhere and it seems like nothing more than a way to control the users and keep them dependent on a unique way of doing something.   In the digital age, I don’t think doing something old school should have to slow a workflow.  I prefer old school, old school is good,  it has proven again and again to me at least that it is always a system you can depend on and others can understand. If everyone uses a different methodology, no one will understand each other and business will be good for proprietary software makers.    If GNUcash does not use a journal as the point of entry, I don’t want to invest the time in learning it.  For one thing, it looks like it is going to be very time consuming just to import my data because of this, which is essentially already in the form of a journal the way it is supposed to me.  All GNUcash needs to do is create or identify the account by looking at my spreadsheet, put the data in that account, then do the same for the other accounts in that transaction as indicated from my journal.  Seems simple.
>
>
>
> Thank you for your thoughts though as it helped me get up to speed much faster.    If you or anyone knows of another GNU bookkeeping package where I can use a journal as the point of entry and the software uses the traditional terms and methods most people would know from basic bookkeeping.  

As a non-accountant, I started to use a book-keeping program in the 90s without knowing anything about double-entry, because I'd started selling software in a small way, and needed to keep track of invoicing, while also managing my personal budgeting.

I learned by trial and (a lot of) error, and eventually realised that I was going to have to learn about double-entry book-keeping. I bought an "old-school" book, and went through all the paper exercises, until I had sufficient knowledge and experience to stop me making (so many) errors.

If I understand it correctly, what's called the General Ledger in GnuCash (GC)  is identical in function to the General Journal in a paper accounting system, except that it automatically posts the transactions to the appropriate accounts - a process you would have to do methodically by hand in a paper system.

If you're insistent on using the General Journal method in a computerised book-keeping system, it's supported by the General Ledger in GC. The price you pay in doing it this way is that you have to specify at least two accounts for the distribution each time you make an entry. I find it more natural when entering a batch of transactions - for example from the counterfoils in my cheque-book or from a pile of credit card receipts - is to open the relevant source account and make the entries through that. The end result is the same, but the risk of operator error is reduced.

Michael


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one actually keeps books that way.  There are a lot of things taught in basic books which are useful and important for understanding the basic concepts than are actually used.  
>
>
>
> The idea of the General Journal being the initial entry-point of all transactions is one of these things.  Even in traditional, manual double-entry bookkeeping the General Journal was just one of many journals typically used, in addition to sales journals, cash journals, etc.  Many actual journals have an implicit assumption that one account will always be involved in the transaction, and provide places to record the other account(s) involved (for instance, a "sales journal" might have columns for sale amount, sales tax, cash, check, credit, so that when the journal is transferred to the ledgers, the sales column corresponds to the appropriate income account, the sales tax column corresponds to the appropriate liability account, the other columns correspond to their respective asset accounts, etc).  In this setting, the "General Journal" proper is used only for transactions that can't easily be recorded in more specialized journals.
>
>
>
> That said, every DE-accounting package that I have been able to examine (or write) has, at it's core, the functional equivalent of a General Journal, in the form of a date-stamped collection of transactions, each of which must balance debits and credits.  Very few DE-accounting packages use the General Journal as a main data-entry method.  Why? Because it's inconvenient, and not how most people think.  Most people think in terms of specific workflows that look at one main account at a time -- like the non-general journals mentioned above.  The account registers in GnuCash act like specialized journals, one for each account.  You see a time-ordered list of transactions (journal entries) that involve that account.
>
>
>
> Note that this is different than what you see in a standard T-account ledger.  Usually, you don't see the rest of the transaction involved in a ledger-entry; you just see it's effect in the one ledger (ideally, there'd be an identifier to be able to look up the rest of the transaction in the journals, for auditing and error-correcting purposes).  In the GnuCash registers/journals, you see the other account(s) involved in the transaction as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General Journal-style display and entry.  Every entry is displayed like a "split transaction", even if only two accounts are involved.  Furthermore, whenever you use the "split" button you effectively get a portion of the General Journal exposed in the current register (you can use a split entry to put stuff into any set of accounts, even excluding the account who's register you are currently using).
>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF ideas.
> Gnucash looks like it will be very useful.   I have also recently decided to
> learn the basics of bookkeeping as is taught in a textbook or by a teacher
> instead of as is taught by quickbooks or some other proprietary software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic understanding.
> The software makers, to some extent this includes Gnucash, seem to try to
> bypass bookkeeping fundamentals and to create their own system in order to
> "simplify" the process for people that are not familiar with the basics of
> bookkeeping.   I strongly believe this is not a good practice and that this
> will cause more failures than successes in helping people to keep their own
> books.  But I could be wrong, I did just after all learn some basic things
> about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is taught by
> most textbooks, is to become familiar with the concept of the General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the transaction
> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?  What
> about if you used cash, spent $80, paid $73 for groceries and tipped $7 to
> the person who helped carry the bags to the car?  Understanding how to enter
> this into the general journal is critical and in fact all over steps pretty
> much take care of themselves after this point.
>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to the
> general ledger seems like a guarantee that the books will never be balanced
> and that the user will never really understand what money is going where and
> how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like to set
> up.  This can involve dozens of accounts and thousands of transactions.
> For example I use excel and would like to instead use Gnucash.    I can save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there a
> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.


_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Ian Konen
In reply to this post by cgw993
On Wed, Aug 7, 2013 at 10:20 PM, <[hidden email]> wrote:

>
>
> Thanks for sharing.   I should just use the generic term Journal instead
> of General Journal.  I guess I had assumed GNUcash would have used old
> school traditional bookkeeping practices because that is how I learned to
> do bookkeeping and the method I want to stick with.   I don’t want to have
> to create a matrix where it identifies a traditional bookkeeping term, and
> then if you follow the row and column, you can identify what the
> "equivalent" concept is in GNUcash.     I saw this a lot in proprietary
> software everywhere and it seems like nothing more than a way to control
> the users and keep them dependent on a unique way of doing something.   In
> the digital age, I don’t think doing something old school should have to
> slow a workflow.  I prefer old school, old school is good,  it has proven
> again and again to me at least


You're obviously entitled to your opinion, but this seems a little picky.
 It's a computer program...there are options in a computerized system (like
multiple ways of entering transactions that all put the same data into the
system, and the ability to re-sort transactions by date if they're entered
out of order) that are not really an option in a pen and paper system, and
it is silly (my opinion of course) to expect developers to forgo the
advantages of a computerized system to conform to an order of operations
designed for pen and paper.  They're not trying to trap you into their
platform by inventing idiosyncratic accounting methods nobody has ever
heard of.  Perhaps a little more care to use the words journal and ledger
properly would help, but for the most part the concepts of double entry
book keeping have been implemented correctly.  So what if you're looking at
a ledger instead of a journal when you want to enter a transaction?  The
fundamental data are the transactions themselves...and yes, even if entered
from an account register, transactions involve at least two accounts, and
don't unbalance the books (if you choose not to enter the second account
then GnuCash creates and fills an account called "Imbalance", but that's
your choice.  The entry point for the second account is there and easy to
see). That GnuCash assumes one of the accounts will be the one who's
register is being edited saves typing / mouse clicks, and can be overridden
if that is not desired behavior.

I'm not a developer, and I've never seen this stated explicitly, but I
think the basic design idea is that the account registers (and the general
ledger/journal) are meant to offer convenient data entry and user info and
may allow you to do or see things that would not normally be present in a
pen and paper system.  If you need to meet a strict formatting requirement,
that's what reports are better for, and I think it's a little more
reasonable to expect standard reports like "balance sheet" to conform to a
standard format your accountant might be expecting.  Then you print the
report and send it along, but the underlying data is not edited in that
process.


> that it is always a system you can depend on and others can understand. If
> everyone uses a different methodology, no one will understand each other
> and business will be good for proprietary software makers.    If GNUcash
> does not use a journal as the point of entry, I don’t want to invest the
> time in learning it.  For one thing, it looks like it is going to be very
> time consuming just to import my data because of this, which is essentially
> already in the form of a journal the way it is supposed to me.  All GNUcash
> needs to do is create or identify the account by looking at my spreadsheet,
> put the data in that account, then do the same for the other accounts in
> that transaction as indicated from my journal.  Seems simple.
>

The CSV import option is an attempt to match the output format of online
banking data.  It's not a simple problem because there is not a single
agreed upon format, so some user input is required to help parse the
columns and date formats etc, but one thing I'm pretty sure almost every
bank does is format the data like a ledger: info only relevant to one bank
account at a time.  GnuCash's CSV import is not designed to import journal
data because your bank won't give you a CSV account summary formatted like
a journal.  GnuCash does give the option to select the opposing account
during import and makes an attempt to learn to map the transaction data to
your accounts list, but that's an extremely difficult problem when the
available information is usually just a store name and maybe an address.
 If you can convert your spreadsheet (manually or through spreadsheet logic
(perhaps a lookup function) from journal form to ledger form, and you
include the opposing accounts, I'm pretty sure the training algorithm will
learn it very quickly, but if you were only going to do it once to convert
from spreadsheet to GnuCash and then never again, it's probably easier to
just input the data the old school way: eyeballs and fingertips.


>
> Thank you for your thoughts though as it helped me get up to speed much
> faster.    If you or anyone knows of another GNU bookkeeping package where
> I can use a journal as the point of entry and the software uses the
> traditional terms and methods most people would know from basic bookkeeping.
>

I would check Sourceforge for other open source accounting software if you
haven't already, but beyond that I cannot help.


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one
> actually keeps books that way.  There are a lot of things taught in basic
> books which are useful and important for understanding the basic concepts
> than are actually used.
>
>
>
> The idea of the General Journal being the initial entry-point of all
> transactions is one of these things.  Even in traditional, manual
> double-entry bookkeeping the General Journal was just one of many journals
> typically used, in addition to sales journals, cash journals, etc.  Many
> actual journals have an implicit assumption that one account will always be
> involved in the transaction, and provide places to record the other
> account(s) involved (for instance, a "sales journal" might have columns for
> sale amount, sales tax, cash, check, credit, so that when the journal is
> transferred to the ledgers, the sales column corresponds to the appropriate
> income account, the sales tax column corresponds to the appropriate
> liability account, the other columns correspond to their respective asset
> accounts, etc).  In this setting, the "General Journal" proper is used only
> for transactions that can't easily be recorded in more specialized journals.
>
>
>
> That said, every DE-accounting package that I have been able to examine
> (or write) has, at it's core, the functional equivalent of a General
> Journal, in the form of a date-stamped collection of transactions, each of
> which must balance debits and credits.  Very few DE-accounting packages use
> the General Journal as a main data-entry method.  Why? Because it's
> inconvenient, and not how most people think.  Most people think in terms of
> specific workflows that look at one main account at a time -- like the
> non-general journals mentioned above.  The account registers in GnuCash act
> like specialized journals, one for each account.  You see a time-ordered
> list of transactions (journal entries) that involve that account.
>
>
>
> Note that this is different than what you see in a standard T-account
> ledger.  Usually, you don't see the rest of the transaction involved in a
> ledger-entry; you just see it's effect in the one ledger (ideally, there'd
> be an identifier to be able to look up the rest of the transaction in the
> journals, for auditing and error-correcting purposes).  In the GnuCash
> registers/journals, you see the other account(s) involved in the
> transaction as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General
> Journal-style display and entry.  Every entry is displayed like a "split
> transaction", even if only two accounts are involved.  Furthermore,
> whenever you use the "split" button you effectively get a portion of the
> General Journal exposed in the current register (you can use a split entry
> to put stuff into any set of accounts, even excluding the account who's
> register you are currently using).
>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
> ideas.
> Gnucash looks like it will be very useful.   I have also recently decided
> to
> learn the basics of bookkeeping as is taught in a textbook or by a teacher
> instead of as is taught by quickbooks or some other proprietary software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic
> understanding.
> The software makers, to some extent this includes Gnucash, seem to try to
> bypass bookkeeping fundamentals and to create their own system in order to
> "simplify" the process for people that are not familiar with the basics of
> bookkeeping.   I strongly believe this is not a good practice and that this
> will cause more failures than successes in helping people to keep their own
> books.  But I could be wrong, I did just after all learn some basic things
> about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is taught
> by
> most textbooks, is to become familiar with the concept of the General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
> transaction
> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?  What
> about if you used cash, spent $80, paid $73 for groceries and tipped $7 to
> the person who helped carry the bags to the car?  Understanding how to
> enter
> this into the general journal is critical and in fact all over steps pretty
> much take care of themselves after this point.
>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to the
> general ledger seems like a guarantee that the books will never be balanced
> and that the user will never really understand what money is going where
> and
> how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like to
> set
> up.  This can involve dozens of accounts and thousands of transactions.
> For example I use excel and would like to instead use Gnucash.    I can
> save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
> guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there a
> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.




--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen
978-821-6498
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Derek Atkins
In reply to this post by foxylady337
Hi,

Michael Hendry <[hidden email]> writes:

> As a non-accountant, I started to use a book-keeping program in the
> 90s without knowing anything about double-entry, because I'd started
> selling software in a small way, and needed to keep track of
> invoicing, while also managing my personal budgeting.
>
> I learned by trial and (a lot of) error, and eventually realised that
> I was going to have to learn about double-entry book-keeping. I bought
> an "old-school" book, and went through all the paper exercises, until
> I had sufficient knowledge and experience to stop me making (so many)
> errors.
>
> If I understand it correctly, what's called the General Ledger in
> GnuCash (GC) is identical in function to the General Journal in a
> paper accounting system, except that it automatically posts the
> transactions to the appropriate accounts - a process you would have to
> do methodically by hand in a paper system.
>
> If you're insistent on using the General Journal method in a
> computerised book-keeping system, it's supported by the General Ledger
> in GC. The price you pay in doing it this way is that you have to
> specify at least two accounts for the distribution each time you make
> an entry. I find it more natural when entering a batch of transactions
> - for example from the counterfoils in my cheque-book or from a pile
> of credit card receipts - is to open the relevant source account and
> make the entries through that. The end result is the same, but the
> risk of operator error is reduced.

GnuCash enforces double-entry accounting.

GnuCash provides multiple methods of entering transactions, but due to
the power of computers it saves you time because you only have to enter
it once and GnuCash will properly post the transaction everywhere it
needs to be.  You can enter it from the General Ledger (Tools -> General
Ledger) and supply all the debit and credit accounts you wish.  Or you
can enter it from one of the accounts, and also supply the same
information.

Unlike Quicken, GnuCash treats Income and Expense accounts the same as
Asset and Liability accounts.  This means you can enter transactions
from those just as easily as you can enter them from your Bank Account
Register or the GL.  Or even using the Transfer Dialog.

However, to the OP: You're welcome to be beholden to your ink-and-paper
archaic entry methods, but I can assure you that NOWHERE will you find a
computer program (paid or gratis) that will require you to enter your
transactions multiple times like you need to do with pen-and-paper!  The
whole power of using a computer program is "enter once" technologies,
GnuCash included.

Good luck in your quest, and make sure you tell the guardian your actual
favorite color.

> Michael

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by foxylady337

Thanks for your input, I guess I don't see how the journal could be
equivilant to the ledger or why users would buy into that statement. They
are two completely different things.
-----Original Message-----
From: Michael Hendry [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 1:51 AM
To: [hidden email]
Cc: 'Buddha Buck'; 'GnuCash Users List'
Subject: Re: General Journal

On 8 Aug 2013, at 03:20, [hidden email] wrote:

>
>
> Thanks for sharing.   I should just use the generic term Journal instead
of General Journal.  I guess I had assumed GNUcash would have used old
school traditional bookkeeping practices because that is how I learned to do
bookkeeping and the method I want to stick with.   I don't want to have to
create a matrix where it identifies a traditional bookkeeping term, and then
if you follow the row and column, you can identify what the "equivalent"
concept is in GNUcash.     I saw this a lot in proprietary software
everywhere and it seems like nothing more than a way to control the users
and keep them dependent on a unique way of doing something.   In the digital
age, I don't think doing something old school should have to slow a
workflow.  I prefer old school, old school is good,  it has proven again and
again to me at least that it is always a system you can depend on and others
can understand. If everyone uses a different methodology, no one will
understand each other and business will be good for proprietary software
makers.    If GNUcash does not use a journal as the point of entry, I don't
want to invest the time in learning it.  For one thing, it looks like it is
going to be very time consuming just to import my data because of this,
which is essentially already in the form of a journal the way it is supposed
to me.  All GNUcash needs to do is create or identify the account by looking
at my spreadsheet, put the data in that account, then do the same for the
other accounts in that transaction as indicated from my journal.  Seems
simple.
>
>
>
> Thank you for your thoughts though as it helped me get up to speed much
faster.    If you or anyone knows of another GNU bookkeeping package where I
can use a journal as the point of entry and the software uses the
traditional terms and methods most people would know from basic bookkeeping.


As a non-accountant, I started to use a book-keeping program in the 90s
without knowing anything about double-entry, because I'd started selling
software in a small way, and needed to keep track of invoicing, while also
managing my personal budgeting.

I learned by trial and (a lot of) error, and eventually realised that I was
going to have to learn about double-entry book-keeping. I bought an
"old-school" book, and went through all the paper exercises, until I had
sufficient knowledge and experience to stop me making (so many) errors.

If I understand it correctly, what's called the General Ledger in GnuCash
(GC)  is identical in function to the General Journal in a paper accounting
system, except that it automatically posts the transactions to the
appropriate accounts - a process you would have to do methodically by hand
in a paper system.

If you're insistent on using the General Journal method in a computerised
book-keeping system, it's supported by the General Ledger in GC. The price
you pay in doing it this way is that you have to specify at least two
accounts for the distribution each time you make an entry. I find it more
natural when entering a batch of transactions - for example from the
counterfoils in my cheque-book or from a pile of credit card receipts - is
to open the relevant source account and make the entries through that. The
end result is the same, but the risk of operator error is reduced.

Michael


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one
actually keeps books that way.  There are a lot of things taught in basic
books which are useful and important for understanding the basic concepts
than are actually used.  
>
>
>
> The idea of the General Journal being the initial entry-point of all
transactions is one of these things.  Even in traditional, manual
double-entry bookkeeping the General Journal was just one of many journals
typically used, in addition to sales journals, cash journals, etc.  Many
actual journals have an implicit assumption that one account will always be
involved in the transaction, and provide places to record the other
account(s) involved (for instance, a "sales journal" might have columns for
sale amount, sales tax, cash, check, credit, so that when the journal is
transferred to the ledgers, the sales column corresponds to the appropriate
income account, the sales tax column corresponds to the appropriate
liability account, the other columns correspond to their respective asset
accounts, etc).  In this setting, the "General Journal" proper is used only
for transactions that can't easily be recorded in more specialized journals.
>
>
>
> That said, every DE-accounting package that I have been able to examine
(or write) has, at it's core, the functional equivalent of a General
Journal, in the form of a date-stamped collection of transactions, each of
which must balance debits and credits.  Very few DE-accounting packages use
the General Journal as a main data-entry method.  Why? Because it's
inconvenient, and not how most people think.  Most people think in terms of
specific workflows that look at one main account at a time -- like the
non-general journals mentioned above.  The account registers in GnuCash act
like specialized journals, one for each account.  You see a time-ordered
list of transactions (journal entries) that involve that account.
>
>
>
> Note that this is different than what you see in a standard T-account
ledger.  Usually, you don't see the rest of the transaction involved in a
ledger-entry; you just see it's effect in the one ledger (ideally, there'd
be an identifier to be able to look up the rest of the transaction in the
journals, for auditing and error-correcting purposes).  In the GnuCash
registers/journals, you see the other account(s) involved in the transaction
as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General
Journal-style display and entry.  Every entry is displayed like a "split
transaction", even if only two accounts are involved.  Furthermore, whenever
you use the "split" button you effectively get a portion of the General
Journal exposed in the current register (you can use a split entry to put
stuff into any set of accounts, even excluding the account who's register
you are currently using).

>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
ideas.
> Gnucash looks like it will be very useful.   I have also recently decided
to
> learn the basics of bookkeeping as is taught in a textbook or by a
> teacher instead of as is taught by quickbooks or some other proprietary
software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic
understanding.
> The software makers, to some extent this includes Gnucash, seem to try
> to bypass bookkeeping fundamentals and to create their own system in
> order to "simplify" the process for people that are not familiar with the
basics of
> bookkeeping.   I strongly believe this is not a good practice and that
this

> will cause more failures than successes in helping people to keep
> their own books.  But I could be wrong, I did just after all learn
> some basic things about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is
> taught by most textbooks, is to become familiar with the concept of the
General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
transaction

> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?  
> What about if you used cash, spent $80, paid $73 for groceries and
> tipped $7 to the person who helped carry the bags to the car?  
> Understanding how to enter this into the general journal is critical
> and in fact all over steps pretty much take care of themselves after this
point.

>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to
> the general ledger seems like a guarantee that the books will never be
> balanced and that the user will never really understand what money is
> going where and how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like
> to set up.  This can involve dozens of accounts and thousands of
transactions.
> For example I use excel and would like to instead use Gnucash.    I can
save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there
a

> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.


_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by Ian Konen


There is no possible way to get away from the fact that for each download,
no matter what the account, the user user needs to assign the affected
account(s) in the transaction.  If you download a bank statement, and it
shows on the checking account there was paid an amount of $73 to Grocery
Store A, of course the bank statement is not going to provide the other
accounts affected by that transaction.

You would download the bank statement, and go through the items and assign
to each entry in the bank statement, the other account that is affected.
For example

Credit Account Checking $73 - This is from your download
Debit Account Expense Groceries $73 - This is what you have to enter.  No
accounting software will automatically do this for you. You have to tell the
bookkeeping sytem "this charge is an expense and it goes into the grocery
expense account". This is the function of the journal.

If you have lots of charges in the bank statement that are all grocery
charges, you can tell the accounting software "everytime you see Grocery A
in the bank statement, assign this charge to the Expense Account Grocery in
the general journal. "  Some additional logic can be used.  Trying to do
this logic for the user means the user will never understand their own
bookkeeping system.   They may be able to do  taxes, ,maybe, but never will
be able to see situation is with the money at any given moment.

Stating that the journal is equivalent to the ledger makes no sense. This is
how the quickbooks and peachtree message boards sound.    This really means
that and on the 2nd Tuesday of every 3rd moon you do this to achieve that.
They cannot possibly be equivalent.  What GC has done is to create a clone
of some proprietary software that also did it wrong on purpose.   That was
probably the correct choice for GC because they needed to provide something
for people to switch to that was similar to what they were already using,
but that was free software.








-----Original Message-----
From: gnucash-user-bounces+cgw993=[hidden email]
[mailto:gnucash-user-bounces+cgw993=[hidden email]] On Behalf Of Ian
Konen
Sent: Thursday, August 08, 2013 6:48 AM
To: GnuCash Users List
Subject: Re: General Journal

On Wed, Aug 7, 2013 at 10:20 PM, <[hidden email]> wrote:

>
>
> Thanks for sharing.   I should just use the generic term Journal instead
> of General Journal.  I guess I had assumed GNUcash would have used old
> school traditional bookkeeping practices because that is how I learned to
> do bookkeeping and the method I want to stick with.   I don't want to have
> to create a matrix where it identifies a traditional bookkeeping term,
> and then if you follow the row and column, you can identify what the
> "equivalent" concept is in GNUcash.     I saw this a lot in proprietary
> software everywhere and it seems like nothing more than a way to control
> the users and keep them dependent on a unique way of doing something.   In
> the digital age, I don't think doing something old school should have
> to slow a workflow.  I prefer old school, old school is good,  it has
> proven again and again to me at least


You're obviously entitled to your opinion, but this seems a little picky.
 It's a computer program...there are options in a computerized system (like
multiple ways of entering transactions that all put the same data into the
system, and the ability to re-sort transactions by date if they're entered
out of order) that are not really an option in a pen and paper system, and
it is silly (my opinion of course) to expect developers to forgo the
advantages of a computerized system to conform to an order of operations
designed for pen and paper.  They're not trying to trap you into their
platform by inventing idiosyncratic accounting methods nobody has ever heard
of.  Perhaps a little more care to use the words journal and ledger properly
would help, but for the most part the concepts of double entry book keeping
have been implemented correctly.  So what if you're looking at a ledger
instead of a journal when you want to enter a transaction?  The fundamental
data are the transactions themselves...and yes, even if entered from an
account register, transactions involve at least two accounts, and don't
unbalance the books (if you choose not to enter the second account then
GnuCash creates and fills an account called "Imbalance", but that's your
choice.  The entry point for the second account is there and easy to see).
That GnuCash assumes one of the accounts will be the one who's register is
being edited saves typing / mouse clicks, and can be overridden if that is
not desired behavior.

I'm not a developer, and I've never seen this stated explicitly, but I think
the basic design idea is that the account registers (and the general
ledger/journal) are meant to offer convenient data entry and user info and
may allow you to do or see things that would not normally be present in a
pen and paper system.  If you need to meet a strict formatting requirement,
that's what reports are better for, and I think it's a little more
reasonable to expect standard reports like "balance sheet" to conform to a
standard format your accountant might be expecting.  Then you print the
report and send it along, but the underlying data is not edited in that
process.


> that it is always a system you can depend on and others can
> understand. If everyone uses a different methodology, no one will
understand each other
> and business will be good for proprietary software makers.    If GNUcash
> does not use a journal as the point of entry, I don't want to invest
> the time in learning it.  For one thing, it looks like it is going to
> be very time consuming just to import my data because of this, which
> is essentially already in the form of a journal the way it is supposed
> to me.  All GNUcash needs to do is create or identify the account by
> looking at my spreadsheet, put the data in that account, then do the
> same for the other accounts in that transaction as indicated from my
journal.  Seems simple.
>

The CSV import option is an attempt to match the output format of online
banking data.  It's not a simple problem because there is not a single
agreed upon format, so some user input is required to help parse the columns
and date formats etc, but one thing I'm pretty sure almost every bank does
is format the data like a ledger: info only relevant to one bank account at
a time.  GnuCash's CSV import is not designed to import journal data because
your bank won't give you a CSV account summary formatted like a journal.
GnuCash does give the option to select the opposing account during import
and makes an attempt to learn to map the transaction data to your accounts
list, but that's an extremely difficult problem when the available
information is usually just a store name and maybe an address.
 If you can convert your spreadsheet (manually or through spreadsheet logic
(perhaps a lookup function) from journal form to ledger form, and you
include the opposing accounts, I'm pretty sure the training algorithm will
learn it very quickly, but if you were only going to do it once to convert
from spreadsheet to GnuCash and then never again, it's probably easier to
just input the data the old school way: eyeballs and fingertips.


>
> Thank you for your thoughts though as it helped me get up to speed much
> faster.    If you or anyone knows of another GNU bookkeeping package where
> I can use a journal as the point of entry and the software uses the
> traditional terms and methods most people would know from basic
bookkeeping.
>

I would check Sourceforge for other open source accounting software if you
haven't already, but beyond that I cannot help.


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one
> actually keeps books that way.  There are a lot of things taught in
> basic books which are useful and important for understanding the basic
> concepts than are actually used.
>
>
>
> The idea of the General Journal being the initial entry-point of all
> transactions is one of these things.  Even in traditional, manual
> double-entry bookkeeping the General Journal was just one of many
> journals typically used, in addition to sales journals, cash journals,
> etc.  Many actual journals have an implicit assumption that one
> account will always be involved in the transaction, and provide places
> to record the other
> account(s) involved (for instance, a "sales journal" might have
> columns for sale amount, sales tax, cash, check, credit, so that when
> the journal is transferred to the ledgers, the sales column
> corresponds to the appropriate income account, the sales tax column
> corresponds to the appropriate liability account, the other columns
> correspond to their respective asset accounts, etc).  In this setting,
> the "General Journal" proper is used only for transactions that can't
easily be recorded in more specialized journals.

>
>
>
> That said, every DE-accounting package that I have been able to
> examine (or write) has, at it's core, the functional equivalent of a
> General Journal, in the form of a date-stamped collection of
> transactions, each of which must balance debits and credits.  Very few
> DE-accounting packages use the General Journal as a main data-entry
> method.  Why? Because it's inconvenient, and not how most people
> think.  Most people think in terms of specific workflows that look at
> one main account at a time -- like the non-general journals mentioned
> above.  The account registers in GnuCash act like specialized
> journals, one for each account.  You see a time-ordered list of
transactions (journal entries) that involve that account.

>
>
>
> Note that this is different than what you see in a standard T-account
> ledger.  Usually, you don't see the rest of the transaction involved
> in a ledger-entry; you just see it's effect in the one ledger
> (ideally, there'd be an identifier to be able to look up the rest of
> the transaction in the journals, for auditing and error-correcting
> purposes).  In the GnuCash registers/journals, you see the other
> account(s) involved in the transaction as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General
> Journal-style display and entry.  Every entry is displayed like a
> "split transaction", even if only two accounts are involved.  
> Furthermore, whenever you use the "split" button you effectively get a
> portion of the General Journal exposed in the current register (you
> can use a split entry to put stuff into any set of accounts, even
> excluding the account who's register you are currently using).
>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
> ideas.
> Gnucash looks like it will be very useful.   I have also recently decided
> to
> learn the basics of bookkeeping as is taught in a textbook or by a
> teacher instead of as is taught by quickbooks or some other proprietary
software.

>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic
> understanding.
> The software makers, to some extent this includes Gnucash, seem to try
> to bypass bookkeeping fundamentals and to create their own system in
> order to "simplify" the process for people that are not familiar with the
basics of
> bookkeeping.   I strongly believe this is not a good practice and that
this

> will cause more failures than successes in helping people to keep
> their own books.  But I could be wrong, I did just after all learn
> some basic things about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is
> taught by most textbooks, is to become familiar with the concept of
> the General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
> transaction
> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?  
> What about if you used cash, spent $80, paid $73 for groceries and
> tipped $7 to the person who helped carry the bags to the car?  
> Understanding how to enter this into the general journal is critical
> and in fact all over steps pretty much take care of themselves after
> this point.
>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to
> the general ledger seems like a guarantee that the books will never be
> balanced and that the user will never really understand what money is
> going where and how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like
> to set up.  This can involve dozens of accounts and thousands of
> transactions.
> For example I use excel and would like to instead use Gnucash.    I can
> save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
> guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there
a

> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.




--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen
978-821-6498
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by Derek Atkins
Like I said if getting people to use the more ethical free software means
making clones of proprietary software, then I am all for it.  I did not
realize that this would be what GNU was doing or what they had to do.  I
support it, but at the same time I do not have a need for quickbooks version
of bookkeeping because in the long run that is will cost me time and money.
If it works for you, or if you think it works for you, then great.

"archaic" "ink and paper"

-----Original Message-----
From: Derek Atkins [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 7:57 AM
To: Michael Hendry
Cc: [hidden email]; 'GnuCash Users List'
Subject: Re: General Journal

Hi,

Michael Hendry <[hidden email]> writes:

> As a non-accountant, I started to use a book-keeping program in the
> 90s without knowing anything about double-entry, because I'd started
> selling software in a small way, and needed to keep track of
> invoicing, while also managing my personal budgeting.
>
> I learned by trial and (a lot of) error, and eventually realised that
> I was going to have to learn about double-entry book-keeping. I bought
> an "old-school" book, and went through all the paper exercises, until
> I had sufficient knowledge and experience to stop me making (so many)
> errors.
>
> If I understand it correctly, what's called the General Ledger in
> GnuCash (GC) is identical in function to the General Journal in a
> paper accounting system, except that it automatically posts the
> transactions to the appropriate accounts - a process you would have to
> do methodically by hand in a paper system.
>
> If you're insistent on using the General Journal method in a
> computerised book-keeping system, it's supported by the General Ledger
> in GC. The price you pay in doing it this way is that you have to
> specify at least two accounts for the distribution each time you make
> an entry. I find it more natural when entering a batch of transactions
> - for example from the counterfoils in my cheque-book or from a pile
> of credit card receipts - is to open the relevant source account and
> make the entries through that. The end result is the same, but the
> risk of operator error is reduced.

GnuCash enforces double-entry accounting.

GnuCash provides multiple methods of entering transactions, but due to the
power of computers it saves you time because you only have to enter it once
and GnuCash will properly post the transaction everywhere it needs to be.
You can enter it from the General Ledger (Tools -> General
Ledger) and supply all the debit and credit accounts you wish.  Or you can
enter it from one of the accounts, and also supply the same information.

Unlike Quicken, GnuCash treats Income and Expense accounts the same as Asset
and Liability accounts.  This means you can enter transactions from those
just as easily as you can enter them from your Bank Account Register or the
GL.  Or even using the Transfer Dialog.

However, to the OP: You're welcome to be beholden to your ink-and-paper
archaic entry methods, but I can assure you that NOWHERE will you find a
computer program (paid or gratis) that will require you to enter your
transactions multiple times like you need to do with pen-and-paper!  The
whole power of using a computer program is "enter once" technologies,
GnuCash included.

Good luck in your quest, and make sure you tell the guardian your actual
favorite color.

> Michael

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Buddha Buck
In reply to this post by cgw993
You are right, a journal and a ledger are two different things.

GnuCash uses neither term, and does not conflate them.

A "journal", according to dictionary.com, is either a daybook or a book in
which transactions from the daybooks are written to facilitate posting to
the ledgers.  A "daybook" is a book in which the transactions of the day
are written in the order they occurred.

The important thing here is that a journal is an ordered record of
transactions.  It's the transactions that are important, not the book
itself.

GnuCash has transactions, and provides many ways to record them.  It does
not provide direct access to anything called a "Journal", although it
maintains an ordered record of transactions, and does provide a method for
seeing all transactions in a time-ordered manner.

What is a transaction?  It's a dated collection of ledger entries with the
restriction that the sum of debits in the transaction equals the sum of
credits in the transaction.  Fundamentally, a ledger entry is simply a
record of an account, a debit amount, and a credit amount.  Every ledger
entry belongs to a single transaction.  Everything else about a ledger
entry or a transaction is additional data which may help the bookkeeper,
accountant, or business owner maintain the business.

GnuCash calls ledger entries (as defined above) "splits".  It does not
provide direct access to anything called a "Ledger", although it maintains
a collection of splits associated with each transaction, and provides ways
of seeing all transactions which affect a particular account (what one
would traditionally look at a ledger for).

Saying that GnuCash treats journals and ledgers equivalently, or implies
that they are equivalent, is a misunderstanding of what GnuCash does.

GnuCash registers (where most data entry takes place) provide a filtered
view of the ordered transaction list (the internal equivalent to the
General Journal), usually limited to transactions which involve a chosen
account.  Every entry in a register reflects the entire transaction,
especially when expanded as a "split transaction", where all accounts and
the debit/credit amounts are explicitly spelled out.  When the transaction
is not expanded as a split (and only involves two accounts) some of the
account and debit/credit information is implicit, not explicit, but it's
still there.



On Thu, Aug 8, 2013 at 11:37 AM, <[hidden email]> wrote:

>
> Thanks for your input, I guess I don't see how the journal could be
> equivilant to the ledger or why users would buy into that statement. They
> are two completely different things.
> -----Original Message-----
> From: Michael Hendry [mailto:[hidden email]]
> Sent: Thursday, August 08, 2013 1:51 AM
> To: [hidden email]
> Cc: 'Buddha Buck'; 'GnuCash Users List'
> Subject: Re: General Journal
>
> On 8 Aug 2013, at 03:20, [hidden email] wrote:
>
> >
> >
> > Thanks for sharing.   I should just use the generic term Journal instead
> of General Journal.  I guess I had assumed GNUcash would have used old
> school traditional bookkeeping practices because that is how I learned to
> do
> bookkeeping and the method I want to stick with.   I don't want to have to
> create a matrix where it identifies a traditional bookkeeping term, and
> then
> if you follow the row and column, you can identify what the "equivalent"
> concept is in GNUcash.     I saw this a lot in proprietary software
> everywhere and it seems like nothing more than a way to control the users
> and keep them dependent on a unique way of doing something.   In the
> digital
> age, I don't think doing something old school should have to slow a
> workflow.  I prefer old school, old school is good,  it has proven again
> and
> again to me at least that it is always a system you can depend on and
> others
> can understand. If everyone uses a different methodology, no one will
> understand each other and business will be good for proprietary software
> makers.    If GNUcash does not use a journal as the point of entry, I don't
> want to invest the time in learning it.  For one thing, it looks like it is
> going to be very time consuming just to import my data because of this,
> which is essentially already in the form of a journal the way it is
> supposed
> to me.  All GNUcash needs to do is create or identify the account by
> looking
> at my spreadsheet, put the data in that account, then do the same for the
> other accounts in that transaction as indicated from my journal.  Seems
> simple.
> >
> >
> >
> > Thank you for your thoughts though as it helped me get up to speed much
> faster.    If you or anyone knows of another GNU bookkeeping package where
> I
> can use a journal as the point of entry and the software uses the
> traditional terms and methods most people would know from basic
> bookkeeping.
>
>
> As a non-accountant, I started to use a book-keeping program in the 90s
> without knowing anything about double-entry, because I'd started selling
> software in a small way, and needed to keep track of invoicing, while also
> managing my personal budgeting.
>
> I learned by trial and (a lot of) error, and eventually realised that I was
> going to have to learn about double-entry book-keeping. I bought an
> "old-school" book, and went through all the paper exercises, until I had
> sufficient knowledge and experience to stop me making (so many) errors.
>
> If I understand it correctly, what's called the General Ledger in GnuCash
> (GC)  is identical in function to the General Journal in a paper accounting
> system, except that it automatically posts the transactions to the
> appropriate accounts - a process you would have to do methodically by hand
> in a paper system.
>
> If you're insistent on using the General Journal method in a computerised
> book-keeping system, it's supported by the General Ledger in GC. The price
> you pay in doing it this way is that you have to specify at least two
> accounts for the distribution each time you make an entry. I find it more
> natural when entering a batch of transactions - for example from the
> counterfoils in my cheque-book or from a pile of credit card receipts - is
> to open the relevant source account and make the entries through that. The
> end result is the same, but the risk of operator error is reduced.
>
> Michael
>
>
> >
> >
> >
> >
> >
> > From: Buddha Buck [mailto:[hidden email]]
> > Sent: Wednesday, August 07, 2013 6:15 PM
> > To: [hidden email]
> > Cc: GnuCash Users List
> > Subject: Re: General Journal
> >
> >
> >
> > Books on basic bookkeeping also discuss "T-Accounts" too, but no one
> actually keeps books that way.  There are a lot of things taught in basic
> books which are useful and important for understanding the basic concepts
> than are actually used.
> >
> >
> >
> > The idea of the General Journal being the initial entry-point of all
> transactions is one of these things.  Even in traditional, manual
> double-entry bookkeeping the General Journal was just one of many journals
> typically used, in addition to sales journals, cash journals, etc.  Many
> actual journals have an implicit assumption that one account will always be
> involved in the transaction, and provide places to record the other
> account(s) involved (for instance, a "sales journal" might have columns for
> sale amount, sales tax, cash, check, credit, so that when the journal is
> transferred to the ledgers, the sales column corresponds to the appropriate
> income account, the sales tax column corresponds to the appropriate
> liability account, the other columns correspond to their respective asset
> accounts, etc).  In this setting, the "General Journal" proper is used only
> for transactions that can't easily be recorded in more specialized
> journals.
> >
> >
> >
> > That said, every DE-accounting package that I have been able to examine
> (or write) has, at it's core, the functional equivalent of a General
> Journal, in the form of a date-stamped collection of transactions, each of
> which must balance debits and credits.  Very few DE-accounting packages use
> the General Journal as a main data-entry method.  Why? Because it's
> inconvenient, and not how most people think.  Most people think in terms of
> specific workflows that look at one main account at a time -- like the
> non-general journals mentioned above.  The account registers in GnuCash act
> like specialized journals, one for each account.  You see a time-ordered
> list of transactions (journal entries) that involve that account.
> >
> >
> >
> > Note that this is different than what you see in a standard T-account
> ledger.  Usually, you don't see the rest of the transaction involved in a
> ledger-entry; you just see it's effect in the one ledger (ideally, there'd
> be an identifier to be able to look up the rest of the transaction in the
> journals, for auditing and error-correcting purposes).  In the GnuCash
> registers/journals, you see the other account(s) involved in the
> transaction
> as well.
> >
> >
> >
> > That said, under Tools->General Ledger, GnuCash provides a General
> Journal-style display and entry.  Every entry is displayed like a "split
> transaction", even if only two accounts are involved.  Furthermore,
> whenever
> you use the "split" button you effectively get a portion of the General
> Journal exposed in the current register (you can use a split entry to put
> stuff into any set of accounts, even excluding the account who's register
> you are currently using).
> >
> >
> >
> >
> >
> > On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
> >
> >
> >
> > Hi,
> >
> > I am new to GNU software in general and am a big supporter of the FSF
> ideas.
> > Gnucash looks like it will be very useful.   I have also recently decided
> to
> > learn the basics of bookkeeping as is taught in a textbook or by a
> > teacher instead of as is taught by quickbooks or some other proprietary
> software.
> >
> >
> >
> >
> >
> > Most people I would guess do not have a basic understanding of
> bookkeeping
> > principals or the accounting equation.   This is just my opinion but I
> > believe that you cannot keep books unless you have this basic
> understanding.
> > The software makers, to some extent this includes Gnucash, seem to try
> > to bypass bookkeeping fundamentals and to create their own system in
> > order to "simplify" the process for people that are not familiar with the
> basics of
> > bookkeeping.   I strongly believe this is not a good practice and that
> this
> > will cause more failures than successes in helping people to keep
> > their own books.  But I could be wrong, I did just after all learn
> > some basic things about bookkeeping recently.
> >
> >
> >
> >
> >
> > The very first thing that I was taught to do, and what I assume is
> > taught by most textbooks, is to become familiar with the concept of the
> General
> > Journal.    This is probably the most critical step in the entire
> > bookkeeping process.   It is during this step that the nature of the
> > transaction and the amounts involved first enter the bookkeeping system.
> > It is also at this step that the user can easily verify that the
> transaction
> > is balanced.     In order to become familiar with how to use the general
> > journal, one has to practice with transaction analysis problems.   An
> > example transaction analysis problem -
> >
> >
> >
> > You buy $73 of groceries with your checking account -
> >
> >
> >
> > Debit Account - Expense Groceries $73
> >
> > Credit Account - Checking $73
> >
> >
> >
> > What happens if instead you use a credit card to make the purchase?
> > What about if you used cash, spent $80, paid $73 for groceries and
> > tipped $7 to the person who helped carry the bags to the car?
> > Understanding how to enter this into the general journal is critical
> > and in fact all over steps pretty much take care of themselves after this
> point.
> >
> >
> >
> > Why in the world accounting software would want to bypass the General
> > Journal in some way.   Almost all software seems to intentionally do
> this.
> > The General Journal is the most important part of the bookkeeping
> process.
> > Why would you want to skip this step and go right to the General Ledger?
> > This is not how students are taught bookkeeping.  Going straight to
> > the general ledger seems like a guarantee that the books will never be
> > balanced and that the user will never really understand what money is
> > going where and how and why.
> >
> >
> >
> > Many people that switch to Gnucash have existing data they would like
> > to set up.  This can involve dozens of accounts and thousands of
> transactions.
> > For example I use excel and would like to instead use Gnucash.    I can
> save
> > the spreadsheet as a .csv file, but the problem with Gnucash is that I
> guess
> > I can only import one account at a time?   Why not let me specify right
> in
> > the spreadsheet the name of the account that transaction goes into?
> >
> >
> >
> > If Gnucash used a general journal as the point of entry into the sytem,
> it
> > seems like it would be easier for people to import their data.   Is there
> a
> > way around the problem of importing one account at a time?
> >
> > Thank You
> >
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
>
>
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Buddha Buck
In reply to this post by cgw993
On Thu, Aug 8, 2013 at 11:52 AM, <[hidden email]> wrote:

> Stating that the journal is equivalent to the ledger makes no sense. This
> is
> how the quickbooks and peachtree message boards sound.    This really means
> that and on the 2nd Tuesday of every 3rd moon you do this to achieve that.
> They cannot possibly be equivalent.  What GC has done is to create a clone
> of some proprietary software that also did it wrong on purpose.   That was
> probably the correct choice for GC because they needed to provide something
> for people to switch to that was similar to what they were already using,
> but that was free software.
>

When banks offer downloads in Quicken format (or derivatives thereof),
GnuCash (or any other software which wants to import this data from banks)
must use what information is available in that format.

Personally, I do not see GnuCash as similar to Quicken.  If anything, I see
it as similar to Peachtree, or other professional DE-accounting packages
I've used.  Guess what: they didn't use a General Journal as the main
data-entry tool either.  I learned DE-bookkeeping long before Quicken was
released; heck, I wrote DE-bookkeeping software before Quicken was
released.  From the beginning, I knew Quicken got it wrong, in terms of
artificially simplifying the DE process to make it easier for
non-bookkeepers to keep books.  I use GnuCash because GnuCash gets it
right, and is not a Quicken clone.
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by Buddha Buck
From google –

 

 

Functions of the Journal -

 

Identify the purpose for the transaction

Enter the debits and credits for the transaction

Choose what you want to do with the transaction

 

The above functions are not a simple, "do in your head" kind of a thing.  Quickbooks, peachtree and GC seem to imply to the user that yes, do this in your head and post directly to the ledgers.  The consensus among these software users is that if you don’t do this in your head, you are "archaic" and "ink and paper".   No textbook or teacher will ever teach bookkeeping this way.   Its like saying  you have found a faster way to calculate the area of the circle, and if you use the old procedure, the right procedure,  your doing it wrong.   With a computer, there is no speed difference at all by using the standard approach. None.  Yet quickbooks, peachtree and GC absolutly insist that the user not follow standard bookkeeping practice because then I guess the user might get control of their own finances and oh no we cant have that.

 

Whats worse, many people want to learn bookkeeping and they arrive at these message boards for help and spend countless hours learning the wrong thing.  Awful.

 

 

 

 

 

 

 

From: Buddha Buck [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 9:25 AM
To: cgw993
Cc: Michael Hendry; GnuCash Users List
Subject: Re: General Journal

 

You are right, a journal and a ledger are two different things.

 

GnuCash uses neither term, and does not conflate them.

 

A "journal", according to dictionary.com, is either a daybook or a book in which transactions from the daybooks are written to facilitate posting to the ledgers.  A "daybook" is a book in which the transactions of the day are written in the order they occurred.

 

The important thing here is that a journal is an ordered record of transactions.  It's the transactions that are important, not the book itself.

 

GnuCash has transactions, and provides many ways to record them.  It does not provide direct access to anything called a "Journal", although it maintains an ordered record of transactions, and does provide a method for seeing all transactions in a time-ordered manner.

 

What is a transaction?  It's a dated collection of ledger entries with the restriction that the sum of debits in the transaction equals the sum of credits in the transaction.  Fundamentally, a ledger entry is simply a record of an account, a debit amount, and a credit amount.  Every ledger entry belongs to a single transaction.  Everything else about a ledger entry or a transaction is additional data which may help the bookkeeper, accountant, or business owner maintain the business.

 

GnuCash calls ledger entries (as defined above) "splits".  It does not provide direct access to anything called a "Ledger", although it maintains a collection of splits associated with each transaction, and provides ways of seeing all transactions which affect a particular account (what one would traditionally look at a ledger for).

 

Saying that GnuCash treats journals and ledgers equivalently, or implies that they are equivalent, is a misunderstanding of what GnuCash does.

 

GnuCash registers (where most data entry takes place) provide a filtered view of the ordered transaction list (the internal equivalent to the General Journal), usually limited to transactions which involve a chosen account.  Every entry in a register reflects the entire transaction, especially when expanded as a "split transaction", where all accounts and the debit/credit amounts are explicitly spelled out.  When the transaction is not expanded as a split (and only involves two accounts) some of the account and debit/credit information is implicit, not explicit, but it's still there.

 

 

On Thu, Aug 8, 2013 at 11:37 AM, <[hidden email]> wrote:


Thanks for your input, I guess I don't see how the journal could be
equivilant to the ledger or why users would buy into that statement. They
are two completely different things.

-----Original Message-----
From: Michael Hendry [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 1:51 AM
To: [hidden email]
Cc: 'Buddha Buck'; 'GnuCash Users List'
Subject: Re: General Journal

On 8 Aug 2013, at 03:20, [hidden email] wrote:

>
>
> Thanks for sharing.   I should just use the generic term Journal instead
of General Journal.  I guess I had assumed GNUcash would have used old
school traditional bookkeeping practices because that is how I learned to do
bookkeeping and the method I want to stick with.   I don't want to have to
create a matrix where it identifies a traditional bookkeeping term, and then
if you follow the row and column, you can identify what the "equivalent"
concept is in GNUcash.     I saw this a lot in proprietary software
everywhere and it seems like nothing more than a way to control the users
and keep them dependent on a unique way of doing something.   In the digital
age, I don't think doing something old school should have to slow a
workflow.  I prefer old school, old school is good,  it has proven again and
again to me at least that it is always a system you can depend on and others
can understand. If everyone uses a different methodology, no one will
understand each other and business will be good for proprietary software
makers.    If GNUcash does not use a journal as the point of entry, I don't
want to invest the time in learning it.  For one thing, it looks like it is
going to be very time consuming just to import my data because of this,
which is essentially already in the form of a journal the way it is supposed
to me.  All GNUcash needs to do is create or identify the account by looking
at my spreadsheet, put the data in that account, then do the same for the
other accounts in that transaction as indicated from my journal.  Seems
simple.
>
>
>
> Thank you for your thoughts though as it helped me get up to speed much
faster.    If you or anyone knows of another GNU bookkeeping package where I
can use a journal as the point of entry and the software uses the
traditional terms and methods most people would know from basic bookkeeping.


As a non-accountant, I started to use a book-keeping program in the 90s
without knowing anything about double-entry, because I'd started selling
software in a small way, and needed to keep track of invoicing, while also
managing my personal budgeting.

I learned by trial and (a lot of) error, and eventually realised that I was
going to have to learn about double-entry book-keeping. I bought an
"old-school" book, and went through all the paper exercises, until I had
sufficient knowledge and experience to stop me making (so many) errors.

If I understand it correctly, what's called the General Ledger in GnuCash
(GC)  is identical in function to the General Journal in a paper accounting
system, except that it automatically posts the transactions to the
appropriate accounts - a process you would have to do methodically by hand
in a paper system.

If you're insistent on using the General Journal method in a computerised
book-keeping system, it's supported by the General Ledger in GC. The price
you pay in doing it this way is that you have to specify at least two
accounts for the distribution each time you make an entry. I find it more
natural when entering a batch of transactions - for example from the
counterfoils in my cheque-book or from a pile of credit card receipts - is
to open the relevant source account and make the entries through that. The
end result is the same, but the risk of operator error is reduced.

Michael


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one
actually keeps books that way.  There are a lot of things taught in basic
books which are useful and important for understanding the basic concepts
than are actually used.
>
>
>
> The idea of the General Journal being the initial entry-point of all
transactions is one of these things.  Even in traditional, manual
double-entry bookkeeping the General Journal was just one of many journals
typically used, in addition to sales journals, cash journals, etc.  Many
actual journals have an implicit assumption that one account will always be
involved in the transaction, and provide places to record the other
account(s) involved (for instance, a "sales journal" might have columns for
sale amount, sales tax, cash, check, credit, so that when the journal is
transferred to the ledgers, the sales column corresponds to the appropriate
income account, the sales tax column corresponds to the appropriate
liability account, the other columns correspond to their respective asset
accounts, etc).  In this setting, the "General Journal" proper is used only
for transactions that can't easily be recorded in more specialized journals.
>
>
>
> That said, every DE-accounting package that I have been able to examine
(or write) has, at it's core, the functional equivalent of a General
Journal, in the form of a date-stamped collection of transactions, each of
which must balance debits and credits.  Very few DE-accounting packages use
the General Journal as a main data-entry method.  Why? Because it's
inconvenient, and not how most people think.  Most people think in terms of
specific workflows that look at one main account at a time -- like the
non-general journals mentioned above.  The account registers in GnuCash act
like specialized journals, one for each account.  You see a time-ordered
list of transactions (journal entries) that involve that account.
>
>
>
> Note that this is different than what you see in a standard T-account
ledger.  Usually, you don't see the rest of the transaction involved in a
ledger-entry; you just see it's effect in the one ledger (ideally, there'd
be an identifier to be able to look up the rest of the transaction in the
journals, for auditing and error-correcting purposes).  In the GnuCash
registers/journals, you see the other account(s) involved in the transaction
as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General
Journal-style display and entry.  Every entry is displayed like a "split
transaction", even if only two accounts are involved.  Furthermore, whenever
you use the "split" button you effectively get a portion of the General
Journal exposed in the current register (you can use a split entry to put
stuff into any set of accounts, even excluding the account who's register
you are currently using).

>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
ideas.
> Gnucash looks like it will be very useful.   I have also recently decided
to
> learn the basics of bookkeeping as is taught in a textbook or by a
> teacher instead of as is taught by quickbooks or some other proprietary
software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic
understanding.
> The software makers, to some extent this includes Gnucash, seem to try
> to bypass bookkeeping fundamentals and to create their own system in
> order to "simplify" the process for people that are not familiar with the
basics of
> bookkeeping.   I strongly believe this is not a good practice and that
this

> will cause more failures than successes in helping people to keep
> their own books.  But I could be wrong, I did just after all learn
> some basic things about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is
> taught by most textbooks, is to become familiar with the concept of the
General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
transaction

> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?
> What about if you used cash, spent $80, paid $73 for groceries and
> tipped $7 to the person who helped carry the bags to the car?
> Understanding how to enter this into the general journal is critical
> and in fact all over steps pretty much take care of themselves after this
point.

>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to
> the general ledger seems like a guarantee that the books will never be
> balanced and that the user will never really understand what money is
> going where and how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like
> to set up.  This can involve dozens of accounts and thousands of
transactions.
> For example I use excel and would like to instead use Gnucash.    I can
save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there
a

> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.



 

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by Buddha Buck
If by professional software, you mean software that does not follow standard bookkeeping practices and the user has no hope of understanding their own books, then yes Peachtree is proffessional, second only to quickbooks.

 

From: Buddha Buck [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 9:33 AM
To: cgw993
Cc: Ian Konen; GnuCash Users List
Subject: Re: General Journal

 

 

On Thu, Aug 8, 2013 at 11:52 AM, <[hidden email]> wrote:

Stating that the journal is equivalent to the ledger makes no sense. This is
how the quickbooks and peachtree message boards sound.    This really means
that and on the 2nd Tuesday of every 3rd moon you do this to achieve that.
They cannot possibly be equivalent.  What GC has done is to create a clone
of some proprietary software that also did it wrong on purpose.   That was
probably the correct choice for GC because they needed to provide something
for people to switch to that was similar to what they were already using,
but that was free software.

 

When banks offer downloads in Quicken format (or derivatives thereof), GnuCash (or any other software which wants to import this data from banks) must use what information is available in that format.

 

Personally, I do not see GnuCash as similar to Quicken.  If anything, I see it as similar to Peachtree, or other professional DE-accounting packages I've used.  Guess what: they didn't use a General Journal as the main data-entry tool either.  I learned DE-bookkeeping long before Quicken was released; heck, I wrote DE-bookkeeping software before Quicken was released.  From the beginning, I knew Quicken got it wrong, in terms of artificially simplifying the DE process to make it easier for non-bookkeepers to keep books.  I use GnuCash because GnuCash gets it right, and is not a Quicken clone.

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Ian Konen
In reply to this post by cgw993
On Thu, Aug 8, 2013 at 11:52 AM, <[hidden email]> wrote:

>
>
> There is no possible way to get away from the fact that for each download,
> no matter what the account, the user user needs to assign the affected
> account(s) in the transaction.  If you download a bank statement, and it
> shows on the checking account there was paid an amount of $73 to Grocery
> Store A, of course the bank statement is not going to provide the other
> accounts affected by that transaction.
>

Are you still talking about importing CSV data or are you talking about
entering transactions as they come up?  Because if you understand that
GnuCash is not expecting to find a list of other accounts in an imported
CSV file, then why would expect it to be able to figure out your CSV
representation of a journal with separate lines for each credit and debit?
 You understand that in the most general sense, CSV just means comma
separated values: Data that is logically sorted into columns, stored as
ASCII and separated by commas.  That GnuCash is looking for a more specific
format is because the CSV import was implemented for a specific use case:
Bank downloads.  You were not around when the feature was implemented to
tell them about your specific spreadsheet format so the ability to import
your format wasn't included. If you're moving your data from a spreadsheet
to somebody else's specialty software (accounting or otherwise), it is your
job to convert your data to a form the target software can parse.  It's not
a moral imperative; it's just not reasonable to expect the developer to
anticipate every other possible data format and write a generic interpreter.

[snip..discussion about loading bank data I don't disagree with]

the general journal. "  Some additional logic can be used.  Trying to do
> this logic for the user means the user will never understand their own
> bookkeeping system.   They may be able to do  taxes, ,maybe, but never will
> be able to see situation is with the money at any given moment.
>

Still not sure what the complaint is: In the previous post you seemed
annoyed that GnuCash wouldn't create new accounts based on what it finds in
the CSV file.  That is because GnuCash does not expect to find account
names in the file...it expects to find a Bank's summary of information
about each transaction, including the counter-party.  Now you seem to
object to GnuCash making any attempt to parse a recorded transaction and
associate it with appropriate accounts.  Do you really think the 15th time
I debit Expense:Groceries when I see "Piggly Wiggly" I'm still solidifying
my grasp of accounting concepts?  It's a time saving device, not an
educational tool.  I also completely disagree with the idea that doing
things efficiently will cripple the users' ability to learn the basics.
 That's a pretty low opinion of the user base.  Certainly some will decide
they don't care to learn the basics and if they can keep their books
balanced in GnuCash without doing so, more power to 'em.  Those who do
bother to learn about bookkeeping are not going to have a hard time
understanding what the import is trying to do in terms of selecting
accounts for transactions.


>
> Stating that the journal is equivalent to the ledger makes no sense. This
> is
>

I didn't state that.  You seem stuck on the idea that the only way a
transaction should be entered is by typing in cells of an interface
formatted like a proper journal because any other method will screw up the
books.  That is false.  Entering in a journal first is an important step in
a pen and paper system because there is so much manual copying of entries
that duplication and omissions are easy mistakes to make.  GnuCash CANNOT
put transaction information in one place and leave it missing anywhere
else: it's only stored in one memory location internally, and only saved in
one entry in the file.  This may also be different from a spreadsheet
system where the use of a formula only allows automated data flow in one
direction.


> how the quickbooks and peachtree message boards sound.    This really means
> that and on the 2nd Tuesday of every 3rd moon you do this to achieve that.
> They cannot possibly be equivalent.  What GC has done is to create a clone
> of some proprietary software that also did it wrong on purpose.


This is what's bugging me, and I suspect everybody else who's taken the
bait here:  There are plenty of fair criticisms to level..GnuCash is a work
in progress, and in particular the documentation needs work.  Perhaps
figuring out how to use the GnuCash interface to perform a standard
accounting action is harder than it should be, but you sound like you think
there's some grand conspiracy to prevent accounting software from using
proper accounting procedures.  It's a very ungenerous attitude towards any
software, but especially freeware, which doesn't benefit from user lock-in.



>
> -----Original Message-----
> From: gnucash-user-bounces+cgw993=[hidden email]
> [mailto:gnucash-user-bounces+cgw993=[hidden email]] On Behalf Of Ian
> Konen
> Sent: Thursday, August 08, 2013 6:48 AM
> To: GnuCash Users List
> Subject: Re: General Journal
>
> On Wed, Aug 7, 2013 at 10:20 PM, <[hidden email]> wrote:
>
> >
> >
> > Thanks for sharing.   I should just use the generic term Journal instead
> > of General Journal.  I guess I had assumed GNUcash would have used old
> > school traditional bookkeeping practices because that is how I learned to
> > do bookkeeping and the method I want to stick with.   I don't want to
> have
> > to create a matrix where it identifies a traditional bookkeeping term,
> > and then if you follow the row and column, you can identify what the
> > "equivalent" concept is in GNUcash.     I saw this a lot in proprietary
> > software everywhere and it seems like nothing more than a way to control
> > the users and keep them dependent on a unique way of doing something.
> In
> > the digital age, I don't think doing something old school should have
> > to slow a workflow.  I prefer old school, old school is good,  it has
> > proven again and again to me at least
>
>
> You're obviously entitled to your opinion, but this seems a little picky.
>  It's a computer program...there are options in a computerized system (like
> multiple ways of entering transactions that all put the same data into the
> system, and the ability to re-sort transactions by date if they're entered
> out of order) that are not really an option in a pen and paper system, and
> it is silly (my opinion of course) to expect developers to forgo the
> advantages of a computerized system to conform to an order of operations
> designed for pen and paper.  They're not trying to trap you into their
> platform by inventing idiosyncratic accounting methods nobody has ever
> heard
> of.  Perhaps a little more care to use the words journal and ledger
> properly
> would help, but for the most part the concepts of double entry book keeping
> have been implemented correctly.  So what if you're looking at a ledger
> instead of a journal when you want to enter a transaction?  The fundamental
> data are the transactions themselves...and yes, even if entered from an
> account register, transactions involve at least two accounts, and don't
> unbalance the books (if you choose not to enter the second account then
> GnuCash creates and fills an account called "Imbalance", but that's your
> choice.  The entry point for the second account is there and easy to see).
> That GnuCash assumes one of the accounts will be the one who's register is
> being edited saves typing / mouse clicks, and can be overridden if that is
> not desired behavior.
>
> I'm not a developer, and I've never seen this stated explicitly, but I
> think
> the basic design idea is that the account registers (and the general
> ledger/journal) are meant to offer convenient data entry and user info and
> may allow you to do or see things that would not normally be present in a
> pen and paper system.  If you need to meet a strict formatting requirement,
> that's what reports are better for, and I think it's a little more
> reasonable to expect standard reports like "balance sheet" to conform to a
> standard format your accountant might be expecting.  Then you print the
> report and send it along, but the underlying data is not edited in that
> process.
>
>
> > that it is always a system you can depend on and others can
> > understand. If everyone uses a different methodology, no one will
> understand each other
> > and business will be good for proprietary software makers.    If GNUcash
> > does not use a journal as the point of entry, I don't want to invest
> > the time in learning it.  For one thing, it looks like it is going to
> > be very time consuming just to import my data because of this, which
> > is essentially already in the form of a journal the way it is supposed
> > to me.  All GNUcash needs to do is create or identify the account by
> > looking at my spreadsheet, put the data in that account, then do the
> > same for the other accounts in that transaction as indicated from my
> journal.  Seems simple.
> >
>
> The CSV import option is an attempt to match the output format of online
> banking data.  It's not a simple problem because there is not a single
> agreed upon format, so some user input is required to help parse the
> columns
> and date formats etc, but one thing I'm pretty sure almost every bank does
> is format the data like a ledger: info only relevant to one bank account at
> a time.  GnuCash's CSV import is not designed to import journal data
> because
> your bank won't give you a CSV account summary formatted like a journal.
> GnuCash does give the option to select the opposing account during import
> and makes an attempt to learn to map the transaction data to your accounts
> list, but that's an extremely difficult problem when the available
> information is usually just a store name and maybe an address.
>  If you can convert your spreadsheet (manually or through spreadsheet logic
> (perhaps a lookup function) from journal form to ledger form, and you
> include the opposing accounts, I'm pretty sure the training algorithm will
> learn it very quickly, but if you were only going to do it once to convert
> from spreadsheet to GnuCash and then never again, it's probably easier to
> just input the data the old school way: eyeballs and fingertips.
>
>
> >
> > Thank you for your thoughts though as it helped me get up to speed much
> > faster.    If you or anyone knows of another GNU bookkeeping package
> where
> > I can use a journal as the point of entry and the software uses the
> > traditional terms and methods most people would know from basic
> bookkeeping.
> >
>
> I would check Sourceforge for other open source accounting software if you
> haven't already, but beyond that I cannot help.
>
>
> >
> >
> >
> >
> >
> > From: Buddha Buck [mailto:[hidden email]]
> > Sent: Wednesday, August 07, 2013 6:15 PM
> > To: [hidden email]
> > Cc: GnuCash Users List
> > Subject: Re: General Journal
> >
> >
> >
> > Books on basic bookkeeping also discuss "T-Accounts" too, but no one
> > actually keeps books that way.  There are a lot of things taught in
> > basic books which are useful and important for understanding the basic
> > concepts than are actually used.
> >
> >
> >
> > The idea of the General Journal being the initial entry-point of all
> > transactions is one of these things.  Even in traditional, manual
> > double-entry bookkeeping the General Journal was just one of many
> > journals typically used, in addition to sales journals, cash journals,
> > etc.  Many actual journals have an implicit assumption that one
> > account will always be involved in the transaction, and provide places
> > to record the other
> > account(s) involved (for instance, a "sales journal" might have
> > columns for sale amount, sales tax, cash, check, credit, so that when
> > the journal is transferred to the ledgers, the sales column
> > corresponds to the appropriate income account, the sales tax column
> > corresponds to the appropriate liability account, the other columns
> > correspond to their respective asset accounts, etc).  In this setting,
> > the "General Journal" proper is used only for transactions that can't
> easily be recorded in more specialized journals.
> >
> >
> >
> > That said, every DE-accounting package that I have been able to
> > examine (or write) has, at it's core, the functional equivalent of a
> > General Journal, in the form of a date-stamped collection of
> > transactions, each of which must balance debits and credits.  Very few
> > DE-accounting packages use the General Journal as a main data-entry
> > method.  Why? Because it's inconvenient, and not how most people
> > think.  Most people think in terms of specific workflows that look at
> > one main account at a time -- like the non-general journals mentioned
> > above.  The account registers in GnuCash act like specialized
> > journals, one for each account.  You see a time-ordered list of
> transactions (journal entries) that involve that account.
> >
> >
> >
> > Note that this is different than what you see in a standard T-account
> > ledger.  Usually, you don't see the rest of the transaction involved
> > in a ledger-entry; you just see it's effect in the one ledger
> > (ideally, there'd be an identifier to be able to look up the rest of
> > the transaction in the journals, for auditing and error-correcting
> > purposes).  In the GnuCash registers/journals, you see the other
> > account(s) involved in the transaction as well.
> >
> >
> >
> > That said, under Tools->General Ledger, GnuCash provides a General
> > Journal-style display and entry.  Every entry is displayed like a
> > "split transaction", even if only two accounts are involved.
> > Furthermore, whenever you use the "split" button you effectively get a
> > portion of the General Journal exposed in the current register (you
> > can use a split entry to put stuff into any set of accounts, even
> > excluding the account who's register you are currently using).
> >
> >
> >
> >
> >
> > On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
> >
> >
> >
> > Hi,
> >
> > I am new to GNU software in general and am a big supporter of the FSF
> > ideas.
> > Gnucash looks like it will be very useful.   I have also recently decided
> > to
> > learn the basics of bookkeeping as is taught in a textbook or by a
> > teacher instead of as is taught by quickbooks or some other proprietary
> software.
> >
> >
> >
> >
> >
> > Most people I would guess do not have a basic understanding of
> bookkeeping
> > principals or the accounting equation.   This is just my opinion but I
> > believe that you cannot keep books unless you have this basic
> > understanding.
> > The software makers, to some extent this includes Gnucash, seem to try
> > to bypass bookkeeping fundamentals and to create their own system in
> > order to "simplify" the process for people that are not familiar with the
> basics of
> > bookkeeping.   I strongly believe this is not a good practice and that
> this
> > will cause more failures than successes in helping people to keep
> > their own books.  But I could be wrong, I did just after all learn
> > some basic things about bookkeeping recently.
> >
> >
> >
> >
> >
> > The very first thing that I was taught to do, and what I assume is
> > taught by most textbooks, is to become familiar with the concept of
> > the General
> > Journal.    This is probably the most critical step in the entire
> > bookkeeping process.   It is during this step that the nature of the
> > transaction and the amounts involved first enter the bookkeeping system.
> > It is also at this step that the user can easily verify that the
> > transaction
> > is balanced.     In order to become familiar with how to use the general
> > journal, one has to practice with transaction analysis problems.   An
> > example transaction analysis problem -
> >
> >
> >
> > You buy $73 of groceries with your checking account -
> >
> >
> >
> > Debit Account - Expense Groceries $73
> >
> > Credit Account - Checking $73
> >
> >
> >
> > What happens if instead you use a credit card to make the purchase?
> > What about if you used cash, spent $80, paid $73 for groceries and
> > tipped $7 to the person who helped carry the bags to the car?
> > Understanding how to enter this into the general journal is critical
> > and in fact all over steps pretty much take care of themselves after
> > this point.
> >
> >
> >
> > Why in the world accounting software would want to bypass the General
> > Journal in some way.   Almost all software seems to intentionally do
> this.
> > The General Journal is the most important part of the bookkeeping
> process.
> > Why would you want to skip this step and go right to the General Ledger?
> > This is not how students are taught bookkeeping.  Going straight to
> > the general ledger seems like a guarantee that the books will never be
> > balanced and that the user will never really understand what money is
> > going where and how and why.
> >
> >
> >
> > Many people that switch to Gnucash have existing data they would like
> > to set up.  This can involve dozens of accounts and thousands of
> > transactions.
> > For example I use excel and would like to instead use Gnucash.    I can
> > save
> > the spreadsheet as a .csv file, but the problem with Gnucash is that I
> > guess
> > I can only import one account at a time?   Why not let me specify right
> in
> > the spreadsheet the name of the account that transaction goes into?
> >
> >
> >
> > If Gnucash used a general journal as the point of entry into the sytem,
> it
> > seems like it would be easier for people to import their data.   Is there
> a
> > way around the problem of importing one account at a time?
> >
> > Thank You
> >
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
>
>
>
> --
> Ian Konen
> [hidden email]
> www.linkedin.com/in/iankonen
> 978-821-6498
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>


--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen
978-821-6498
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

sunfish62
In reply to this post by cgw993
A couple of points:


First, on which of these functions does Gnucash fail? It seems to me that I can identify from an account register the purpose of a transaction, I can enter all those pesky debits and credits, and I can choose what to do with my transaction (although, to be honest I don't fully understand what the last "function" even means). So Gnucash "works" on those measures.


Second, you've apparently decided that Gnucash is flawed for your needs. Fine. It works for me and others, regardless of whether it's modeled on QuickBooks, PeachTree, envelopes, napkins, or papyrus. Since it doesn't work for you, your best option is to find (or write) your own solution.


Continuing this discussion in its current tenor, however, is not a productive use of anyone's time, and serves no real purpose.

Good luck with your search.

David



________________________________
 From: "[hidden email]" <[hidden email]>
To: 'Buddha Buck' <[hidden email]>
Cc: 'GnuCash Users List' <[hidden email]>
Sent: Thursday, August 8, 2013 9:39 AM
Subject: RE: General Journal
 

From google –

Functions of the Journal -
Identify the purpose for the transaction
Enter the debits and credits for the transaction
Choose what you want to do with the transaction


The above functions are not a simple, "do in your head" kind of a thing.  Quickbooks, peachtree and GC seem to imply to the user that yes, do this in your head and post directly to the ledgers.  The consensus among these software users is that if you don’t do this in your head, you are "archaic" and "ink and paper".   No textbook or teacher will ever teach bookkeeping this way.   Its like saying  you have found a faster way to calculate the area of the circle, and if you use the old procedure, the right procedure,  your doing it wrong.   With a computer, there is no speed difference at all by using the standard approach. None.  Yet quickbooks, peachtree and GC absolutly insist that the user not follow standard bookkeeping practice because then I guess the user might get control of their own finances and oh no we cant have that.



Whats worse, many people want to learn bookkeeping and they arrive at these message boards for help and spend countless hours learning the wrong thing.  Awful.















From: Buddha Buck [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 9:25 AM
To: cgw993
Cc: Michael Hendry; GnuCash Users List
Subject: Re: General Journal



You are right, a journal and a ledger are two different things.



GnuCash uses neither term, and does not conflate them.



A "journal", according to dictionary.com, is either a daybook or a book in which transactions from the daybooks are written to facilitate posting to the ledgers.  A "daybook" is a book in which the transactions of the day are written in the order they occurred.



The important thing here is that a journal is an ordered record of transactions.  It's the transactions that are important, not the book itself.



GnuCash has transactions, and provides many ways to record them.  It does not provide direct access to anything called a "Journal", although it maintains an ordered record of transactions, and does provide a method for seeing all transactions in a time-ordered manner.



What is a transaction?  It's a dated collection of ledger entries with the restriction that the sum of debits in the transaction equals the sum of credits in the transaction.  Fundamentally, a ledger entry is simply a record of an account, a debit amount, and a credit amount.  Every ledger entry belongs to a single transaction.  Everything else about a ledger entry or a transaction is additional data which may help the bookkeeper, accountant, or business owner maintain the business.



GnuCash calls ledger entries (as defined above) "splits".  It does not provide direct access to anything called a "Ledger", although it maintains a collection of splits associated with each transaction, and provides ways of seeing all transactions which affect a particular account (what one would traditionally look at a ledger for).



Saying that GnuCash treats journals and ledgers equivalently, or implies that they are equivalent, is a misunderstanding of what GnuCash does.



GnuCash registers (where most data entry takes place) provide a filtered view of the ordered transaction list (the internal equivalent to the General Journal), usually limited to transactions which involve a chosen account.  Every entry in a register reflects the entire transaction, especially when expanded as a "split transaction", where all accounts and the debit/credit amounts are explicitly spelled out.  When the transaction is not expanded as a split (and only involves two accounts) some of the account and debit/credit information is implicit, not explicit, but it's still there.





On Thu, Aug 8, 2013 at 11:37 AM, <[hidden email]> wrote:


Thanks for your input, I guess I don't see how the journal could be
equivilant to the ledger or why users would buy into that statement. They
are two completely different things.

-----Original Message-----
From: Michael Hendry [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 1:51 AM
To: [hidden email]
Cc: 'Buddha Buck'; 'GnuCash Users List'
Subject: Re: General Journal

On 8 Aug 2013, at 03:20, [hidden email] wrote:

>
>
> Thanks for sharing.   I should just use the generic term Journal instead
of General Journal.  I guess I had assumed GNUcash would have used old
school traditional bookkeeping practices because that is how I learned to do
bookkeeping and the method I want to stick with.   I don't want to have to
create a matrix where it identifies a traditional bookkeeping term, and then
if you follow the row and column, you can identify what the "equivalent"
concept is in GNUcash.     I saw this a lot in proprietary software
everywhere and it seems like nothing more than a way to control the users
and keep them dependent on a unique way of doing something.   In the digital
age, I don't think doing something old school should have to slow a
workflow.  I prefer old school, old school is good,  it has proven again and
again to me at least that it is always a system you can depend on and others
can understand. If everyone uses a different methodology, no one will
understand each other and business will be good for proprietary software
makers.    If GNUcash does not use a journal as the point of entry, I don't
want to invest the time in learning it.  For one thing, it looks like it is
going to be very time consuming just to import my data because of this,
which is essentially already in the form of a journal the way it is supposed
to me.  All GNUcash needs to do is create or identify the account by looking
at my spreadsheet, put the data in that account, then do the same for the
other accounts in that transaction as indicated from my journal.  Seems
simple.
>
>
>
> Thank you for your thoughts though as it helped me get up to speed much
faster.    If you or anyone knows of another GNU bookkeeping package where I
can use a journal as the point of entry and the software uses the
traditional terms and methods most people would know from basic bookkeeping.


As a non-accountant, I started to use a book-keeping program in the 90s
without knowing anything about double-entry, because I'd started selling
software in a small way, and needed to keep track of invoicing, while also
managing my personal budgeting.

I learned by trial and (a lot of) error, and eventually realised that I was
going to have to learn about double-entry book-keeping. I bought an
"old-school" book, and went through all the paper exercises, until I had
sufficient knowledge and experience to stop me making (so many) errors.

If I understand it correctly, what's called the General Ledger in GnuCash
(GC)  is identical in function to the General Journal in a paper accounting
system, except that it automatically posts the transactions to the
appropriate accounts - a process you would have to do methodically by hand
in a paper system.

If you're insistent on using the General Journal method in a computerised
book-keeping system, it's supported by the General Ledger in GC. The price
you pay in doing it this way is that you have to specify at least two
accounts for the distribution each time you make an entry. I find it more
natural when entering a batch of transactions - for example from the
counterfoils in my cheque-book or from a pile of credit card receipts - is
to open the relevant source account and make the entries through that. The
end result is the same, but the risk of operator error is reduced.

Michael


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one
actually keeps books that way.  There are a lot of things taught in basic
books which are useful and important for understanding the basic concepts
than are actually used.
>
>
>
> The idea of the General Journal being the initial entry-point of all
transactions is one of these things.  Even in traditional, manual
double-entry bookkeeping the General Journal was just one of many journals
typically used, in addition to sales journals, cash journals, etc.  Many
actual journals have an implicit assumption that one account will always be
involved in the transaction, and provide places to record the other
account(s) involved (for instance, a "sales journal" might have columns for
sale amount, sales tax, cash, check, credit, so that when the journal is
transferred to the ledgers, the sales column corresponds to the appropriate
income account, the sales tax column corresponds to the appropriate
liability account, the other columns correspond to their respective asset
accounts, etc).  In this setting, the "General Journal" proper is used only
for transactions that can't easily be recorded in more specialized journals.
>
>
>
> That said, every DE-accounting package that I have been able to examine
(or write) has, at it's core, the functional equivalent of a General
Journal, in the form of a date-stamped collection of transactions, each of
which must balance debits and credits.  Very few DE-accounting packages use
the General Journal as a main data-entry method.  Why? Because it's
inconvenient, and not how most people think.  Most people think in terms of
specific workflows that look at one main account at a time -- like the
non-general journals mentioned above.  The account registers in GnuCash act
like specialized journals, one for each account.  You see a time-ordered
list of transactions (journal entries) that involve that account.
>
>
>
> Note that this is different than what you see in a standard T-account
ledger.  Usually, you don't see the rest of the transaction involved in a
ledger-entry; you just see it's effect in the one ledger (ideally, there'd
be an identifier to be able to look up the rest of the transaction in the
journals, for auditing and error-correcting purposes).  In the GnuCash
registers/journals, you see the other account(s) involved in the transaction
as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General
Journal-style display and entry.  Every entry is displayed like a "split
transaction", even if only two accounts are involved.  Furthermore, whenever
you use the "split" button you effectively get a portion of the General
Journal exposed in the current register (you can use a split entry to put
stuff into any set of accounts, even excluding the account who's register
you are currently using).

>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
ideas.
> Gnucash looks like it will be very useful.   I have also recently decided
to
> learn the basics of bookkeeping as is taught in a textbook or by a
> teacher instead of as is taught by quickbooks or some other proprietary
software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.   This is just my opinion but I
> believe that you cannot keep books unless you have this basic
understanding.
> The software makers, to some extent this includes Gnucash, seem to try
> to bypass bookkeeping fundamentals and to create their own system in
> order to "simplify" the process for people that are not familiar with the
basics of
> bookkeeping.   I strongly believe this is not a good practice and that
this

> will cause more failures than successes in helping people to keep
> their own books.  But I could be wrong, I did just after all learn
> some basic things about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is
> taught by most textbooks, is to become familiar with the concept of the
General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.   It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
transaction

> is balanced.     In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.   An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?
> What about if you used cash, spent $80, paid $73 for groceries and
> tipped $7 to the person who helped carry the bags to the car?
> Understanding how to enter this into the general journal is critical
> and in fact all over steps pretty much take care of themselves after this
point.

>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.   Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to
> the general ledger seems like a guarantee that the books will never be
> balanced and that the user will never really understand what money is
> going where and how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like
> to set up.  This can involve dozens of accounts and thousands of
transactions.
> For example I use excel and would like to instead use Gnucash.    I can
save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
guess
> I can only import one account at a time?   Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.   Is there
a

> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.





_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by Ian Konen
I am talking about software simply following standard bookkeeping practice.
The journal is the entry to the bookkeeping system, not the ledgers and
there are major implications for not following that methodology. You
sacrifice all the built in structure of the journal.   Yes, I understand
that there are workarounds.  

What is the motivation for quickbooks or Peachtree for doing it this way?
Well users trained on those methods cannot easily move on to another
software package and are tied to the software. Why is GC also doing it this
way?  I imagine because they had no choice in order to pull users away from
non free software.  How are proprietary software makers responding to more
users using free software, which is a huge threat to their business? By
forcing the use the wonderful "feature" of "Cloud" computing, which
nullifies the GPL licenses which protect you. Cloud computing is your worst
enemy.

 Just because GC creates a journal after you have entered the data into the
ledgers directly, does not mean the journal has served its purpose.   You
always enter the data into the Journal first, otherwise it doesn't serve any
real function.

A journal contains at least 2 accounts.  You have to enter the other account
anyway when you download statements.   This can be done manually, or tools
can be used to make this semi automatic.   GC has no real way of creating
journals for you which is what they they seem to attempt to do  when they do
auto this or that.  

Assuming all statements from banks, credit cards, other financial use their
own format, you the user then have to standardize the format.   This is
relatively easy using good old debits and credits and understanding the
accounting equation.

For example, download the CSV from your bank.  GC should ask for the
appropriate fields, and you tell it.   GC sort does this, but does not use
Debits and Credits, no they  use deposits and withdrawals which is not the
correct terminiology and will cause confusion among the users.  How do you
apply this to a credit card download? You have a 50% chance of getting it
right or you have to figure out what they mean..is deposit a debit or credit
when it comes to credit cards is the very first question I will bet 99% of
users ask themselves.  Problem solved if they just use Debits and Credits as
the fields.

Once that is done, GC has about half of a journal.  You the user then enter
the other account or accounts that the transaction applies to.  You can do
this manually, or you can use tools that GC could have easily provided to
assign every transaction that includes the string term "grocery" to the
grocery expense account, making the process semi automatic.  This technique
might not work if the string grocery was found, but it was a refund, but I
just used that as an example to illustrate the user has to make these
decisions and can go so with the right tools to make it efficient.    Making
it fully automatic is not possible because in order to do so, GC would have
to read your mind.

 When done, you now have a journal.   There is no real decision making for
GC to do, all it has to do now is post the transactions to the ledgers as
entered in the journal. This is all that I wanted to use GC for, but I have
to do a lot of work arounds to accomplish this goal.


-----Original Message-----
From: gnucash-user-bounces+cgw993=[hidden email]
[mailto:gnucash-user-bounces+cgw993=[hidden email]] On Behalf Of Ian
Konen
Sent: Thursday, August 08, 2013 11:15 AM
To: GnuCash Users List
Subject: Re: General Journal

On Thu, Aug 8, 2013 at 11:52 AM, <[hidden email]> wrote:

>
>
> There is no possible way to get away from the fact that for each
> download, no matter what the account, the user user needs to assign
> the affected
> account(s) in the transaction.  If you download a bank statement, and
> it shows on the checking account there was paid an amount of $73 to
> Grocery Store A, of course the bank statement is not going to provide
> the other accounts affected by that transaction.
>

Are you still talking about importing CSV data or are you talking about
entering transactions as they come up?  Because if you understand that
GnuCash is not expecting to find a list of other accounts in an imported CSV
file, then why would expect it to be able to figure out your CSV
representation of a journal with separate lines for each credit and debit?
 You understand that in the most general sense, CSV just means comma
separated values: Data that is logically sorted into columns, stored as
ASCII and separated by commas.  That GnuCash is looking for a more specific
format is because the CSV import was implemented for a specific use case:
Bank downloads.  You were not around when the feature was implemented to
tell them about your specific spreadsheet format so the ability to import
your format wasn't included. If you're moving your data from a spreadsheet
to somebody else's specialty software (accounting or otherwise), it is your
job to convert your data to a form the target software can parse.  It's not
a moral imperative; it's just not reasonable to expect the developer to
anticipate every other possible data format and write a generic interpreter.

[snip..discussion about loading bank data I don't disagree with]

the general journal. "  Some additional logic can be used.  Trying to do
> this logic for the user means the user will never understand their own
> bookkeeping system.   They may be able to do  taxes, ,maybe, but never
will
> be able to see situation is with the money at any given moment.
>

Still not sure what the complaint is: In the previous post you seemed
annoyed that GnuCash wouldn't create new accounts based on what it finds in
the CSV file.  That is because GnuCash does not expect to find account names
in the file...it expects to find a Bank's summary of information about each
transaction, including the counter-party.  Now you seem to object to GnuCash
making any attempt to parse a recorded transaction and associate it with
appropriate accounts.  Do you really think the 15th time I debit
Expense:Groceries when I see "Piggly Wiggly" I'm still solidifying my grasp
of accounting concepts?  It's a time saving device, not an educational tool.
I also completely disagree with the idea that doing things efficiently will
cripple the users' ability to learn the basics.
 That's a pretty low opinion of the user base.  Certainly some will decide
they don't care to learn the basics and if they can keep their books
balanced in GnuCash without doing so, more power to 'em.  Those who do
bother to learn about bookkeeping are not going to have a hard time
understanding what the import is trying to do in terms of selecting accounts
for transactions.


>
> Stating that the journal is equivalent to the ledger makes no sense.
> This is
>

I didn't state that.  You seem stuck on the idea that the only way a
transaction should be entered is by typing in cells of an interface
formatted like a proper journal because any other method will screw up the
books.  That is false.  Entering in a journal first is an important step in
a pen and paper system because there is so much manual copying of entries
that duplication and omissions are easy mistakes to make.  GnuCash CANNOT
put transaction information in one place and leave it missing anywhere
else: it's only stored in one memory location internally, and only saved in
one entry in the file.  This may also be different from a spreadsheet system
where the use of a formula only allows automated data flow in one direction.


> how the quickbooks and peachtree message boards sound.    This really
means
> that and on the 2nd Tuesday of every 3rd moon you do this to achieve that.
> They cannot possibly be equivalent.  What GC has done is to create a
> clone of some proprietary software that also did it wrong on purpose.


This is what's bugging me, and I suspect everybody else who's taken the bait
here:  There are plenty of fair criticisms to level..GnuCash is a work in
progress, and in particular the documentation needs work.  Perhaps figuring
out how to use the GnuCash interface to perform a standard accounting action
is harder than it should be, but you sound like you think there's some grand
conspiracy to prevent accounting software from using proper accounting
procedures.  It's a very ungenerous attitude towards any software, but
especially freeware, which doesn't benefit from user lock-in.



>
> -----Original Message-----
> From: gnucash-user-bounces+cgw993=[hidden email]
> [mailto:gnucash-user-bounces+cgw993=[hidden email]] On Behalf Of
> Ian Konen
> Sent: Thursday, August 08, 2013 6:48 AM
> To: GnuCash Users List
> Subject: Re: General Journal
>
> On Wed, Aug 7, 2013 at 10:20 PM, <[hidden email]> wrote:
>
> >
> >
> > Thanks for sharing.   I should just use the generic term Journal instead
> > of General Journal.  I guess I had assumed GNUcash would have used
> > old school traditional bookkeeping practices because that is how I
learned to
> > do bookkeeping and the method I want to stick with.   I don't want to
> have
> > to create a matrix where it identifies a traditional bookkeeping
> > term, and then if you follow the row and column, you can identify what
the
> > "equivalent" concept is in GNUcash.     I saw this a lot in proprietary
> > software everywhere and it seems like nothing more than a way to
> > control the users and keep them dependent on a unique way of doing
something.

> In
> > the digital age, I don't think doing something old school should
> > have to slow a workflow.  I prefer old school, old school is good,  
> > it has proven again and again to me at least
>
>
> You're obviously entitled to your opinion, but this seems a little picky.
>  It's a computer program...there are options in a computerized system
> (like multiple ways of entering transactions that all put the same
> data into the system, and the ability to re-sort transactions by date
> if they're entered out of order) that are not really an option in a
> pen and paper system, and it is silly (my opinion of course) to expect
> developers to forgo the advantages of a computerized system to conform
> to an order of operations designed for pen and paper.  They're not
> trying to trap you into their platform by inventing idiosyncratic
> accounting methods nobody has ever heard of.  Perhaps a little more
> care to use the words journal and ledger properly would help, but for
> the most part the concepts of double entry book keeping have been
> implemented correctly.  So what if you're looking at a ledger instead
> of a journal when you want to enter a transaction?  The fundamental
> data are the transactions themselves...and yes, even if entered from
> an account register, transactions involve at least two accounts, and
> don't unbalance the books (if you choose not to enter the second
> account then GnuCash creates and fills an account called "Imbalance",
> but that's your choice.  The entry point for the second account is there
and easy to see).

> That GnuCash assumes one of the accounts will be the one who's
> register is being edited saves typing / mouse clicks, and can be
> overridden if that is not desired behavior.
>
> I'm not a developer, and I've never seen this stated explicitly, but I
> think the basic design idea is that the account registers (and the
> general
> ledger/journal) are meant to offer convenient data entry and user info
> and may allow you to do or see things that would not normally be
> present in a pen and paper system.  If you need to meet a strict
> formatting requirement, that's what reports are better for, and I
> think it's a little more reasonable to expect standard reports like
> "balance sheet" to conform to a standard format your accountant might
> be expecting.  Then you print the report and send it along, but the
> underlying data is not edited in that process.
>
>
> > that it is always a system you can depend on and others can
> > understand. If everyone uses a different methodology, no one will
> understand each other
> > and business will be good for proprietary software makers.    If GNUcash
> > does not use a journal as the point of entry, I don't want to invest
> > the time in learning it.  For one thing, it looks like it is going
> > to be very time consuming just to import my data because of this,
> > which is essentially already in the form of a journal the way it is
> > supposed to me.  All GNUcash needs to do is create or identify the
> > account by looking at my spreadsheet, put the data in that account,
> > then do the same for the other accounts in that transaction as
> > indicated from my
> journal.  Seems simple.
> >
>
> The CSV import option is an attempt to match the output format of
> online banking data.  It's not a simple problem because there is not a
> single agreed upon format, so some user input is required to help
> parse the columns and date formats etc, but one thing I'm pretty sure
> almost every bank does is format the data like a ledger: info only
> relevant to one bank account at a time.  GnuCash's CSV import is not
> designed to import journal data because your bank won't give you a CSV
> account summary formatted like a journal.
> GnuCash does give the option to select the opposing account during
> import and makes an attempt to learn to map the transaction data to
> your accounts list, but that's an extremely difficult problem when the
> available information is usually just a store name and maybe an address.
>  If you can convert your spreadsheet (manually or through spreadsheet
> logic (perhaps a lookup function) from journal form to ledger form,
> and you include the opposing accounts, I'm pretty sure the training
> algorithm will learn it very quickly, but if you were only going to do
> it once to convert from spreadsheet to GnuCash and then never again,
> it's probably easier to just input the data the old school way: eyeballs
and fingertips.

>
>
> >
> > Thank you for your thoughts though as it helped me get up to speed much
> > faster.    If you or anyone knows of another GNU bookkeeping package
> where
> > I can use a journal as the point of entry and the software uses the
> > traditional terms and methods most people would know from basic
> bookkeeping.
> >
>
> I would check Sourceforge for other open source accounting software if
> you haven't already, but beyond that I cannot help.
>
>
> >
> >
> >
> >
> >
> > From: Buddha Buck [mailto:[hidden email]]
> > Sent: Wednesday, August 07, 2013 6:15 PM
> > To: [hidden email]
> > Cc: GnuCash Users List
> > Subject: Re: General Journal
> >
> >
> >
> > Books on basic bookkeeping also discuss "T-Accounts" too, but no one
> > actually keeps books that way.  There are a lot of things taught in
> > basic books which are useful and important for understanding the
> > basic concepts than are actually used.
> >
> >
> >
> > The idea of the General Journal being the initial entry-point of all
> > transactions is one of these things.  Even in traditional, manual
> > double-entry bookkeeping the General Journal was just one of many
> > journals typically used, in addition to sales journals, cash
> > journals, etc.  Many actual journals have an implicit assumption
> > that one account will always be involved in the transaction, and
> > provide places to record the other
> > account(s) involved (for instance, a "sales journal" might have
> > columns for sale amount, sales tax, cash, check, credit, so that
> > when the journal is transferred to the ledgers, the sales column
> > corresponds to the appropriate income account, the sales tax column
> > corresponds to the appropriate liability account, the other columns
> > correspond to their respective asset accounts, etc).  In this
> > setting, the "General Journal" proper is used only for transactions
> > that can't
> easily be recorded in more specialized journals.
> >
> >
> >
> > That said, every DE-accounting package that I have been able to
> > examine (or write) has, at it's core, the functional equivalent of a
> > General Journal, in the form of a date-stamped collection of
> > transactions, each of which must balance debits and credits.  Very
> > few DE-accounting packages use the General Journal as a main
> > data-entry method.  Why? Because it's inconvenient, and not how most
> > people think.  Most people think in terms of specific workflows that
> > look at one main account at a time -- like the non-general journals
> > mentioned above.  The account registers in GnuCash act like
> > specialized journals, one for each account.  You see a time-ordered
> > list of
> transactions (journal entries) that involve that account.
> >
> >
> >
> > Note that this is different than what you see in a standard
> > T-account ledger.  Usually, you don't see the rest of the
> > transaction involved in a ledger-entry; you just see it's effect in
> > the one ledger (ideally, there'd be an identifier to be able to look
> > up the rest of the transaction in the journals, for auditing and
> > error-correcting purposes).  In the GnuCash registers/journals, you
> > see the other
> > account(s) involved in the transaction as well.
> >
> >
> >
> > That said, under Tools->General Ledger, GnuCash provides a General
> > Journal-style display and entry.  Every entry is displayed like a
> > "split transaction", even if only two accounts are involved.
> > Furthermore, whenever you use the "split" button you effectively get
> > a portion of the General Journal exposed in the current register
> > (you can use a split entry to put stuff into any set of accounts,
> > even excluding the account who's register you are currently using).
> >
> >
> >
> >
> >
> > On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
> >
> >
> >
> > Hi,
> >
> > I am new to GNU software in general and am a big supporter of the
> > FSF ideas.
> > Gnucash looks like it will be very useful.   I have also recently
decided

> > to
> > learn the basics of bookkeeping as is taught in a textbook or by a
> > teacher instead of as is taught by quickbooks or some other
> > proprietary
> software.
> >
> >
> >
> >
> >
> > Most people I would guess do not have a basic understanding of
> bookkeeping
> > principals or the accounting equation.   This is just my opinion but I
> > believe that you cannot keep books unless you have this basic
> > understanding.
> > The software makers, to some extent this includes Gnucash, seem to
> > try to bypass bookkeeping fundamentals and to create their own
> > system in order to "simplify" the process for people that are not
> > familiar with the
> basics of
> > bookkeeping.   I strongly believe this is not a good practice and that
> this
> > will cause more failures than successes in helping people to keep
> > their own books.  But I could be wrong, I did just after all learn
> > some basic things about bookkeeping recently.
> >
> >
> >
> >
> >
> > The very first thing that I was taught to do, and what I assume is
> > taught by most textbooks, is to become familiar with the concept of
> > the General
> > Journal.    This is probably the most critical step in the entire
> > bookkeeping process.   It is during this step that the nature of the
> > transaction and the amounts involved first enter the bookkeeping system.
> > It is also at this step that the user can easily verify that the
> > transaction
> > is balanced.     In order to become familiar with how to use the general
> > journal, one has to practice with transaction analysis problems.   An
> > example transaction analysis problem -
> >
> >
> >
> > You buy $73 of groceries with your checking account -
> >
> >
> >
> > Debit Account - Expense Groceries $73
> >
> > Credit Account - Checking $73
> >
> >
> >
> > What happens if instead you use a credit card to make the purchase?
> > What about if you used cash, spent $80, paid $73 for groceries and
> > tipped $7 to the person who helped carry the bags to the car?
> > Understanding how to enter this into the general journal is critical
> > and in fact all over steps pretty much take care of themselves after
> > this point.
> >
> >
> >
> > Why in the world accounting software would want to bypass the General
> > Journal in some way.   Almost all software seems to intentionally do
> this.
> > The General Journal is the most important part of the bookkeeping
> process.
> > Why would you want to skip this step and go right to the General Ledger?
> > This is not how students are taught bookkeeping.  Going straight to
> > the general ledger seems like a guarantee that the books will never
> > be balanced and that the user will never really understand what
> > money is going where and how and why.
> >
> >
> >
> > Many people that switch to Gnucash have existing data they would
> > like to set up.  This can involve dozens of accounts and thousands
> > of transactions.
> > For example I use excel and would like to instead use Gnucash.    I can
> > save
> > the spreadsheet as a .csv file, but the problem with Gnucash is that
> > I guess
> > I can only import one account at a time?   Why not let me specify right
> in
> > the spreadsheet the name of the account that transaction goes into?
> >
> >
> >
> > If Gnucash used a general journal as the point of entry into the
> > sytem,
> it
> > seems like it would be easier for people to import their data.   Is
there

> a
> > way around the problem of importing one account at a time?
> >
> > Thank You
> >
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
>
>
>
> --
> Ian Konen
> [hidden email]
> www.linkedin.com/in/iankonen
> 978-821-6498
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>


--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen
978-821-6498
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
In reply to this post by sunfish62
On the import field, they don’t call them debits and credits, they call them deposits and withdrawals unless I missed something.   Does debit = deposit, and credit=withdrawal?  

 

Thanks for speaking for others, deciding what my best option was, and labeling the discussion as not a productive use of anyone's time.   Where would the world be without you to decide things for them?

 

Best of luck to you too.

 

 

From: David T. [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 11:51 AM
To: [hidden email]; 'Buddha Buck'
Cc: 'GnuCash Users List'
Subject: Re: General Journal

 

A couple of points:

 

First, on which of these functions does Gnucash fail? It seems to me that I can identify from an account register the purpose of a transaction, I can enter all those pesky debits and credits, and I can choose what to do with my transaction (although, to be honest I don't fully understand what the last "function" even means). So Gnucash "works" on those measures.

 

Second, you've apparently decided that Gnucash is flawed for your needs. Fine. It works for me and others, regardless of whether it's modeled on QuickBooks, PeachTree, envelopes, napkins, or papyrus. Since it doesn't work for you, your best option is to find (or write) your own solution.

 

Continuing this discussion in its current tenor, however, is not a productive use of anyone's time, and serves no real purpose.

 

Good luck with your search.

 

David

 

  _____  

From: "[hidden email]" <[hidden email]>
To: 'Buddha Buck' <[hidden email]>
Cc: 'GnuCash Users List' <[hidden email]>
Sent: Thursday, August 8, 2013 9:39 AM
Subject: RE: General Journal


From google –

Functions of the Journal -
Identify the purpose for the transaction
Enter the debits and credits for the transaction
Choose what you want to do with the transaction


The above functions are not a simple, "do in your head" kind of a thing.  Quickbooks, peachtree and GC seem to imply to the user that yes, do this in your head and post directly to the ledgers.  The consensus among these software users is that if you don’t do this in your head, you are "archaic" and "ink and paper".  No textbook or teacher will ever teach bookkeeping this way.  Its like saying  you have found a faster way to calculate the area of the circle, and if you use the old procedure, the right procedure,  your doing it wrong.  With a computer, there is no speed difference at all by using the standard approach. None.  Yet quickbooks, peachtree and GC absolutly insist that the user not follow standard bookkeeping practice because then I guess the user might get control of their own finances and oh no we cant have that.



Whats worse, many people want to learn bookkeeping and they arrive at these message boards for help and spend countless hours learning the wrong thing.  Awful.















From: Buddha Buck [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 9:25 AM
To: cgw993
Cc: Michael Hendry; GnuCash Users List
Subject: Re: General Journal



You are right, a journal and a ledger are two different things.



GnuCash uses neither term, and does not conflate them.



A "journal", according to dictionary.com, is either a daybook or a book in which transactions from the daybooks are written to facilitate posting to the ledgers.  A "daybook" is a book in which the transactions of the day are written in the order they occurred.



The important thing here is that a journal is an ordered record of transactions.  It's the transactions that are important, not the book itself.



GnuCash has transactions, and provides many ways to record them.  It does not provide direct access to anything called a "Journal", although it maintains an ordered record of transactions, and does provide a method for seeing all transactions in a time-ordered manner.



What is a transaction?  It's a dated collection of ledger entries with the restriction that the sum of debits in the transaction equals the sum of credits in the transaction.  Fundamentally, a ledger entry is simply a record of an account, a debit amount, and a credit amount.  Every ledger entry belongs to a single transaction.  Everything else about a ledger entry or a transaction is additional data which may help the bookkeeper, accountant, or business owner maintain the business.



GnuCash calls ledger entries (as defined above) "splits".  It does not provide direct access to anything called a "Ledger", although it maintains a collection of splits associated with each transaction, and provides ways of seeing all transactions which affect a particular account (what one would traditionally look at a ledger for).



Saying that GnuCash treats journals and ledgers equivalently, or implies that they are equivalent, is a misunderstanding of what GnuCash does.



GnuCash registers (where most data entry takes place) provide a filtered view of the ordered transaction list (the internal equivalent to the General Journal), usually limited to transactions which involve a chosen account.  Every entry in a register reflects the entire transaction, especially when expanded as a "split transaction", where all accounts and the debit/credit amounts are explicitly spelled out.  When the transaction is not expanded as a split (and only involves two accounts) some of the account and debit/credit information is implicit, not explicit, but it's still there.





On Thu, Aug 8, 2013 at 11:37 AM, <[hidden email]> wrote:


Thanks for your input, I guess I don't see how the journal could be
equivilant to the ledger or why users would buy into that statement. They
are two completely different things.

-----Original Message-----
From: Michael Hendry [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 1:51 AM
To: [hidden email]
Cc: 'Buddha Buck'; 'GnuCash Users List'
Subject: Re: General Journal

On 8 Aug 2013, at 03:20, [hidden email] wrote:

>
>
> Thanks for sharing.  I should just use the generic term Journal instead
of General Journal.  I guess I had assumed GNUcash would have used old
school traditional bookkeeping practices because that is how I learned to do
bookkeeping and the method I want to stick with.  I don't want to have to
create a matrix where it identifies a traditional bookkeeping term, and then
if you follow the row and column, you can identify what the "equivalent"
concept is in GNUcash.    I saw this a lot in proprietary software
everywhere and it seems like nothing more than a way to control the users
and keep them dependent on a unique way of doing something.  In the digital
age, I don't think doing something old school should have to slow a
workflow.  I prefer old school, old school is good,  it has proven again and
again to me at least that it is always a system you can depend on and others
can understand. If everyone uses a different methodology, no one will
understand each other and business will be good for proprietary software
makers.    If GNUcash does not use a journal as the point of entry, I don't
want to invest the time in learning it.  For one thing, it looks like it is
going to be very time consuming just to import my data because of this,
which is essentially already in the form of a journal the way it is supposed
to me.  All GNUcash needs to do is create or identify the account by looking
at my spreadsheet, put the data in that account, then do the same for the
other accounts in that transaction as indicated from my journal.  Seems
simple.
>
>
>
> Thank you for your thoughts though as it helped me get up to speed much
faster.    If you or anyone knows of another GNU bookkeeping package where I
can use a journal as the point of entry and the software uses the
traditional terms and methods most people would know from basic bookkeeping.


As a non-accountant, I started to use a book-keeping program in the 90s
without knowing anything about double-entry, because I'd started selling
software in a small way, and needed to keep track of invoicing, while also
managing my personal budgeting.

I learned by trial and (a lot of) error, and eventually realised that I was
going to have to learn about double-entry book-keeping. I bought an
"old-school" book, and went through all the paper exercises, until I had
sufficient knowledge and experience to stop me making (so many) errors.

If I understand it correctly, what's called the General Ledger in GnuCash
(GC)  is identical in function to the General Journal in a paper accounting
system, except that it automatically posts the transactions to the
appropriate accounts - a process you would have to do methodically by hand
in a paper system.

If you're insistent on using the General Journal method in a computerised
book-keeping system, it's supported by the General Ledger in GC. The price
you pay in doing it this way is that you have to specify at least two
accounts for the distribution each time you make an entry. I find it more
natural when entering a batch of transactions - for example from the
counterfoils in my cheque-book or from a pile of credit card receipts - is
to open the relevant source account and make the entries through that. The
end result is the same, but the risk of operator error is reduced.

Michael


>
>
>
>
>
> From: Buddha Buck [mailto:[hidden email]]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: [hidden email]
> Cc: GnuCash Users List
> Subject: Re: General Journal
>
>
>
> Books on basic bookkeeping also discuss "T-Accounts" too, but no one
actually keeps books that way.  There are a lot of things taught in basic
books which are useful and important for understanding the basic concepts
than are actually used.
>
>
>
> The idea of the General Journal being the initial entry-point of all
transactions is one of these things.  Even in traditional, manual
double-entry bookkeeping the General Journal was just one of many journals
typically used, in addition to sales journals, cash journals, etc.  Many
actual journals have an implicit assumption that one account will always be
involved in the transaction, and provide places to record the other
account(s) involved (for instance, a "sales journal" might have columns for
sale amount, sales tax, cash, check, credit, so that when the journal is
transferred to the ledgers, the sales column corresponds to the appropriate
income account, the sales tax column corresponds to the appropriate
liability account, the other columns correspond to their respective asset
accounts, etc).  In this setting, the "General Journal" proper is used only
for transactions that can't easily be recorded in more specialized journals.
>
>
>
> That said, every DE-accounting package that I have been able to examine
(or write) has, at it's core, the functional equivalent of a General
Journal, in the form of a date-stamped collection of transactions, each of
which must balance debits and credits.  Very few DE-accounting packages use
the General Journal as a main data-entry method.  Why? Because it's
inconvenient, and not how most people think.  Most people think in terms of
specific workflows that look at one main account at a time -- like the
non-general journals mentioned above.  The account registers in GnuCash act
like specialized journals, one for each account.  You see a time-ordered
list of transactions (journal entries) that involve that account.
>
>
>
> Note that this is different than what you see in a standard T-account
ledger.  Usually, you don't see the rest of the transaction involved in a
ledger-entry; you just see it's effect in the one ledger (ideally, there'd
be an identifier to be able to look up the rest of the transaction in the
journals, for auditing and error-correcting purposes).  In the GnuCash
registers/journals, you see the other account(s) involved in the transaction
as well.
>
>
>
> That said, under Tools->General Ledger, GnuCash provides a General
Journal-style display and entry.  Every entry is displayed like a "split
transaction", even if only two accounts are involved.  Furthermore, whenever
you use the "split" button you effectively get a portion of the General
Journal exposed in the current register (you can use a split entry to put
stuff into any set of accounts, even excluding the account who's register
you are currently using).

>
>
>
>
>
> On Wed, Aug 7, 2013 at 7:22 PM, <[hidden email]> wrote:
>
>
>
> Hi,
>
> I am new to GNU software in general and am a big supporter of the FSF
ideas.
> Gnucash looks like it will be very useful.  I have also recently decided
to
> learn the basics of bookkeeping as is taught in a textbook or by a
> teacher instead of as is taught by quickbooks or some other proprietary
software.
>
>
>
>
>
> Most people I would guess do not have a basic understanding of bookkeeping
> principals or the accounting equation.  This is just my opinion but I
> believe that you cannot keep books unless you have this basic
understanding.
> The software makers, to some extent this includes Gnucash, seem to try
> to bypass bookkeeping fundamentals and to create their own system in
> order to "simplify" the process for people that are not familiar with the
basics of
> bookkeeping.  I strongly believe this is not a good practice and that
this

> will cause more failures than successes in helping people to keep
> their own books.  But I could be wrong, I did just after all learn
> some basic things about bookkeeping recently.
>
>
>
>
>
> The very first thing that I was taught to do, and what I assume is
> taught by most textbooks, is to become familiar with the concept of the
General
> Journal.    This is probably the most critical step in the entire
> bookkeeping process.  It is during this step that the nature of the
> transaction and the amounts involved first enter the bookkeeping system.
> It is also at this step that the user can easily verify that the
transaction

> is balanced.    In order to become familiar with how to use the general
> journal, one has to practice with transaction analysis problems.  An
> example transaction analysis problem -
>
>
>
> You buy $73 of groceries with your checking account -
>
>
>
> Debit Account - Expense Groceries $73
>
> Credit Account - Checking $73
>
>
>
> What happens if instead you use a credit card to make the purchase?
> What about if you used cash, spent $80, paid $73 for groceries and
> tipped $7 to the person who helped carry the bags to the car?
> Understanding how to enter this into the general journal is critical
> and in fact all over steps pretty much take care of themselves after this
point.

>
>
>
> Why in the world accounting software would want to bypass the General
> Journal in some way.  Almost all software seems to intentionally do this.
> The General Journal is the most important part of the bookkeeping process.
> Why would you want to skip this step and go right to the General Ledger?
> This is not how students are taught bookkeeping.  Going straight to
> the general ledger seems like a guarantee that the books will never be
> balanced and that the user will never really understand what money is
> going where and how and why.
>
>
>
> Many people that switch to Gnucash have existing data they would like
> to set up.  This can involve dozens of accounts and thousands of
transactions.
> For example I use excel and would like to instead use Gnucash.    I can
save
> the spreadsheet as a .csv file, but the problem with Gnucash is that I
guess
> I can only import one account at a time?  Why not let me specify right in
> the spreadsheet the name of the account that transaction goes into?
>
>
>
> If Gnucash used a general journal as the point of entry into the sytem, it
> seems like it would be easier for people to import their data.  Is there
a

> way around the problem of importing one account at a time?
>
> Thank You
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.





_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Ian Konen
In reply to this post by cgw993
I'm inclined to agree with David T here: this point about how to enter
transactions is getting repetitive and I don't really have anything new to
add.  I'm not going to engage on the merits of cloud computing, that's for
another mailing list.

On Thu, Aug 8, 2013 at 2:55 PM, <[hidden email]> wrote:


> For example, download the CSV from your bank.  GC should ask for the
> appropriate fields, and you tell it.   GC sort does this, but does not use
> Debits and Credits, no they  use deposits and withdrawals which is not the
>

Aha!  This, however, I can offer concrete help:  That is a preference
setting and it can be switched using Edit->Preferences, then in the dialog
Accounts tab -> "Use Formal accounting labels".  Rage at the injustice of
that not being the default setting, but at least you can change it. It is
documented and perhaps makes the point that you might not find GnuCash
quite so morally compromised if you spend a little more time reading the
documentation (and adjusting preferences where it helps...you might also be
interested in the Register Defaults->Default Style setting)

--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen
978-821-6498
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

RE: General Journal

cgw993
I just discovered this thing with GC being modeled after unethical
proprietary software, but I think I understand why it was done, and the most
beautiful thing is, the GPL license guarantees that users will never be
trapped by the software, they can change and modify it at will as an
individual or as a group.  Thanks for listening and your patience.   May I
suggest anyone not familiar with Richard Stallman view some of this videos
online.  I will continue to use Excel and VBA to do bookkeeping for now as I
don't know how to program in any other non proprietary spreadsheet and am
still making the transition to GNU + Linux operating system.  Thanks for the
discussion, take care.

 

 

 

From: Ian Konen [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 12:33 PM
To: [hidden email]
Cc: GnuCash Users List
Subject: Re: General Journal

 

I'm inclined to agree with David T here: this point about how to enter
transactions is getting repetitive and I don't really have anything new to
add.  I'm not going to engage on the merits of cloud computing, that's for
another mailing list.  

 

On Thu, Aug 8, 2013 at 2:55 PM, <[hidden email]> wrote:

 

For example, download the CSV from your bank.  GC should ask for the
appropriate fields, and you tell it.   GC sort does this, but does not use
Debits and Credits, no they  use deposits and withdrawals which is not the

 

Aha!  This, however, I can offer concrete help:  That is a preference
setting and it can be switched using Edit->Preferences, then in the dialog
Accounts tab -> "Use Formal accounting labels".  Rage at the injustice of
that not being the default setting, but at least you can change it. It is
documented and perhaps makes the point that you might not find GnuCash quite
so morally compromised if you spend a little more time reading the
documentation (and adjusting preferences where it helps...you might also be
interested in the Register Defaults->Default Style setting)

 

--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen
978-821-6498

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: General Journal

Dominic Grosleau
In reply to this post by cgw993
Hi,

As a new GnuCash user, I have closely following this thread developing from a basic Q+A format to an all out flame war that I hadn't experienced since my newsgroup days following M$ vs Apple or any of the asm threads ...

Unfortunaately I believe that this thread has reached its usefulness and should be closed.

Yes I agree that Gnucash isn't perfect (like all software) but at least when I exposed my issue a few days ago the devel or users freely and promptly replied back to me with solutions that work.  All I had to do was pick the one I could live with for the time being until it gets readressed in a later version (aka hopefully gnucash will one day default the report headers to the standards found in any accounting books lol ).  In the meantime, I caan take the extra few seconds and add html break codes to remodel the header ... If I don't want to do that I can still move back to any of the free alternatives or proprietary one.  The beauty: gnucash didn't cost me anything besides a 5 mins of email drafting to adress my issue.  Oh and mebe an hour to familiarize myself with the interface.  Don't like it, don't use it.

Onto the DR / CR vs deposit / withdrawal issue at hand... Gnucash has the option to revert the columns to the standard DR / CR if its what you want.  Go in options and click the checkbox and voila!

Let's either keep this discussion PG and constructive or close it and move on to the next user issue..

My 2 cents worth!

Dom
Ontario, Canada
Sent by my Blackberry, I-Pod Touch, Computer, PSP, DS, PDA, Tablet, smoke signal, ESP, Cell Phone, Other device nobody but the manufacturer cares about....

-----Original Message-----
From: [hidden email]
Date: Thu, 8 Aug 2013 20:00:33
To: <[hidden email]>
Cc: <[hidden email]>
Subject: RE: General Journal


I just discovered this thing with GC being modeled after unethical
proprietary software, but I think I understand why it was done, and the most
beautiful thing is, the GPL license guarantees that users will never be
trapped by the software, they can change and modify it at will as an
individual or as a group.  Thanks for listening and your patience.   May I
suggest anyone not familiar with Richard Stallman view some of this videos
online.  I will continue to use Excel and VBA to do bookkeeping for now as I
don't know how to program in any other non proprietary spreadsheet and am
still making the transition to GNU + Linux operating system.  Thanks for the
discussion, take care.

 

 

 

From: Ian Konen [mailto:[hidden email]]
Sent: Thursday, August 08, 2013 12:33 PM
To: [hidden email]
Cc: GnuCash Users List
Subject: Re: General Journal

 

I'm inclined to agree with David T here: this point about how to enter
transactions is getting repetitive and I don't really have anything new to
add.  I'm not going to engage on the merits of cloud computing, that's for
another mailing list. 

 

On Thu, Aug 8, 2013 at 2:55 PM, <[hidden email]> wrote:

 

For example, download the CSV from your bank.  GC should ask for the
appropriate fields, and you tell it.   GC sort does this, but does not use
Debits and Credits, no they  use deposits and withdrawals which is not the

 

Aha!  This, however, I can offer concrete help:  That is a preference
setting and it can be switched using Edit->Preferences, then in the dialog
Accounts tab -> "Use Formal accounting labels".  Rage at the injustice of
that not being the default setting, but at least you can change it. It is
documented and perhaps makes the point that you might not find GnuCash quite
so morally compromised if you spend a little more time reading the
documentation (and adjusting preferences where it helps...you might also be
interested in the Register Defaults->Default Style setting)

 

--
Ian Konen
[hidden email]
www.linkedin.com/in/iankonen <http://www.linkedin.com/in/iankonen>
978-821-6498

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
12