transaction date

Thu Mar 13 22:38:12 EDT 2008

There's only one visible date column, the Post Date.  There are a
few invisible dates on transactions and Splits.  There's the
Entered Date (T) that's assigned to the actual date/time that
you create the transaction, and there's the Reconciled Date (S)
which is assigned to the closing date when you reconcile a split.
There are no other dates available to you.

GnuCash does not support what you want to do.  You have to choose a date for
the transaction and live with that one date, even though your two
bank accounts differ.

-derek

Quoting Yogesh Agrawal <agrawaly at gmail.com>:

> I have a suggestion, and I got this one by looking at one of the credit card
> statement.
>
> where you will see two date,  transaction date and posting date, at least if
> I have an
> option to add a another date column in my account page, it will help.
>
> I tried to search the mail-archive but I couldn't find how to add new
> columns on the account page.
>
>
> On Thu, Mar 13, 2008 at 7:26 AM, Andrew Sackville-West <
> andrew at swclan.homelinux.org> wrote:
>
>> On Thu, Mar 13, 2008 at 06:41:06AM -0500, Mike or Penny Novack wrote:
>> >
>> >>
>> >> The short version is that there is nothing incorrect about having the
>> >> dates not match perfectly on both ends of a transaction. You record
>> >> your transactions on the day you initiate them. Other parties involved
>> >> in the transaction record them on the day they process them. These
>> >> dates don't match and that's okay.
>> >>
>> >    That wasn't this situation. Of course the dates on your books need
>> > not match the dates on some other entity's books. But here the
>> > transaction was between two accounts in the same set of books. Note that
>> > for legal purposes the real date (when going between parties) may not be
>> > the date that either end has recorded. Unless a contract between the
>> > parties specifies otherwise, might be the date when "constructive
>> > delivery" occurred --- thus if that were critical, might be obtaining a
>> > mailing receipt from the post office (again -- the usual disclaimer.)
>> >
>> >    The person asking the question didn't say WHY it was important that
>> > the book dates matched what the banks had. From personal experience, let
>> > me say that it can be*.
>>
>> I don't disagree that there are times when it's a problem. I was
>> merely trying to point out that it is perfectly common for dates to
>> not match.
>>
>> This is just an artifact of our banking systems and it's something we
>> have to either live with or work around. We are mostly insulated from
>> this situation when the txn is essentially between two sets of books
>> (e.g. mine and my vendor's). It only becomes glaringly obvious to us
>> when the txn is between two accounts in the same set of books but
>> between two different entities in the real world.
>>
>> Most people seem unbothered by this when they are dealing with a check
>> written and mailed but for some reason can't tolerate it when it's a
>> wire transfer between two of their own accounts. It is an interesting
>> phenomenon...
>>
>> >
>> >> If for some reason you need to keep specific track of the dates
>> >[...] then
>> >> do as Mike suggested and use an interim account ("Funds in
>> >> Transit"). Note [...] THe money out of one account will not directly
>> point to
>> >> the other account in which it is deposited.
>> >>
>> >>
>> >    There is a "description field" available on both transaction (to and
>> > from "funds in transit") which can be used to for that purpose (when
>> > going into "transit", record ultimate destination and when leaving
>> > "transit" record where from).
>>
>> I'm fully aware of the description field ;)... But the direct
>> connection (all splits in one txn and only pointing to final
>> destinations) is lost. It's a level of indirection. It's perfectly
>> valid and I use it all the time, (for reasons other than the "float"
>> between banks), but it's still a disconnect.
>>
>>
>> >
>> > Michael
>> >
>> > * I am also "treasurer" of a second entity but in this case one that
>> > does not have it's own existence as a 510(c)3 independent from national.
>> > I have to submit quarterly reports plus the bank statements for our
>> > local group to the national treasurer. If the transit interval spanned
>> > the closing days of a quarter a discrepancy between books and bank
>> > statements would be glaring and depending on the personality of the
>> > national treasurer I might have a lot of explaining/exception report
>> > filing to do (the previous office holder in that post was most
>> > unreasonable).
>>
>> <shudder>
>>
>> A
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>>
>> iD8DBQFH2TmqaIeIEqwil4YRAkmVAJ92ZIGbrJVUrhzx/wVO+AckNfG61gCgoGVY
>> Q85RxDWtYMsbHwt/vgTVBFc=
>> =y0Mg
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> "Being rich is having money; being wealthy is having time"- Margaret Bonnano
>
> Text : 15103257640 at mobile.mycingular.com
>
> Blogs
> ---------------------------------------------------------
> Tech: http://yagrawal.blogspot.com
> Financial: http://agrawaly.blogspot.com
> _______________________________________________
> 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.
>

-- 
       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
       warlord at MIT.EDU                        PGP key available