This one has tripped me up as well. In the business world, there often
is either January 1st which is a non-business day to put the
transactions on. The "fake day" is also another option.
There are implications past just the ones indicated in an earlier post
-- most accounts are impacted, as are budgets, if they include
book-close transactions.
Thinking about this a little, I believe that a future solution may take
the form of a flag that identifies certain transactions as book-close
transactions, then let the reports decide how to deal with them. I agree
that use of a "fake date" doesn't make sense in the current era of
computation.
On 2/7/10 8:31 AM, JT Morée wrote:
"calendar" allowed for the special date "year end". In other
words, we could insert a date in between two (real) calendar
dates that fell after the first but before the second. Think
of it as a December 32 or a Jan 0
Not an easy problem for GnuCash (no way of knowing what the
user's "fiscal year" might be)
Michael D Novack, FLMI
I am not an accountant but I disagree that the best solution is to
create a fake date or reserve a real date.
I realize my post was long but in short I believe the best solution is
to have the reports be smarter. It's not difficult (almost done in
fact) and it avoids the fiscal year problem you mention.
JT
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
