General Journal
cgw993 at aol.com
cgw993 at aol.com
Thu Aug 8 11:52:59 EDT 2013
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=aol.com at gnucash.org
[mailto:gnucash-user-bounces+cgw993=aol.com at gnucash.org] 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, <cgw993 at aol.com> 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:blaisepascal at gmail.com]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: cgw993 at aol.com
> 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, <cgw993 at aol.com> 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
> gnucash-user at gnucash.org
> 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
> gnucash-user at gnucash.org
> 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
iankonen at gmail.com
www.linkedin.com/in/iankonen
978-821-6498
_______________________________________________
gnucash-user mailing list
gnucash-user at gnucash.org
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.
More information about the gnucash-user
mailing list