Hi,
Yawar Amin yawar.a...@gmail.com writes:
This is a little embarrassing but I lost the private SSH key that I used
for SVN access when I switched to a new laptop. I'll generate a new
keypair and ask for access again but hoping that someone can do the docs
patch in the meantime
That's
On 2013-01-13 20:35, Derek Atkins wrote:
[...]
That's too bad...
I'll need your new key, and please don't lose it this time... ;-)
Sending shortly, and not to worry, I'm backing up this time :-)
Thanks
signature.asc
Description: OpenPGP digital signature
close books in the documentation, I
rename the bug and assign it to the documentation team.
Thanks for your work.
I've uploaded a couple of patches to the bug:
1. Add documentation for book closing (gnucash-docs, based on c726f61a).
This adds a section on closing the books.
2. Get GnuCash
2011-01-10 18:09:26 UTC ---
[...]
Because I can not find something like close books in the documentation, I
rename the bug and assign it to the documentation team.
Thanks for your work.
I've uploaded a couple of patches to the bug:
1. Add documentation for book closing (gnucash-docs
Hi John,
On 2013-01-12 16:16, John Ralls wrote:
Yawar,
I'll commit the code if someone else doesn't beat me to it. You can commit
the documentation change yourself.
Regards,
John Ralls
This is a little embarrassing but I lost the private SSH key that I used
for SVN access when I switched
Am Donnerstag, 9. Dezember 2010 schrieb Frank H. Ellenberger:
Am Mittwoch, 8. Dezember 2010 um 20:46:25 schrieb Derek Atkins:
Geert Janssens janssens-ge...@telenet.be writes:
On Tuesday 07 December 2010, John Ralls wrote:
Schema: OK. To make the policy clearer, backwards-incompatible
Am Mittwoch, 8. Dezember 2010 um 20:46:25 schrieb Derek Atkins:
Geert Janssens janssens-ge...@telenet.be writes:
On Tuesday 07 December 2010, John Ralls wrote:
Schema: OK. To make the policy clearer, backwards-incompatible schema
changes in 2.5 require a change to 2.4 to provide a read
On Thursday 09 December 2010, Frank H. Ellenberger wrote:
Am Mittwoch, 8. Dezember 2010 um 20:46:25 schrieb Derek Atkins:
Geert Janssens janssens-ge...@telenet.be writes:
On Tuesday 07 December 2010, John Ralls wrote:
Schema: OK. To make the policy clearer, backwards-incompatible schema
John Ralls jra...@ceridwen.us writes:
[snip]
Schema: OK. To make the policy clearer, backwards-incompatible schema
changes in 2.5 require a change to 2.4 to provide a read facility for
the new schema.
Sure. Note that this doesn't have to happen in 2.4.0. Having it in
2.4.1 or even 2.4.6 is
On Tuesday 07 December 2010, John Ralls wrote:
Schema: OK. To make the policy clearer, backwards-incompatible schema
changes in 2.5 require a change to 2.4 to provide a read facility for the
new schema.
Do we have a wiki page for this kind of policies ? It will get lost when it's
only
Geert Janssens janssens-ge...@telenet.be writes:
On Tuesday 07 December 2010, John Ralls wrote:
Schema: OK. To make the policy clearer, backwards-incompatible schema
changes in 2.5 require a change to 2.4 to provide a read facility for the
new schema.
Do we have a wiki page for this kind
On Dec 6, 2010, at 8:07 AM, Derek Atkins wrote:
Robin Chattopadhyay robinra...@gmail.com writes:
At a minimum:
* Update the database schema (sqlite, postgres, mysql) to add a column to
the transactions table called closing_entry.
* Update the XML schema to add an element called
On Tue, December 7, 2010 12:33 pm, John Ralls wrote:
On Dec 6, 2010, at 8:07 AM, Derek Atkins wrote:
Robin Chattopadhyay robinra...@gmail.com writes:
At a minimum:
* Update the database schema (sqlite, postgres, mysql) to add a column
to
the transactions table called closing_entry.
*
On Dec 7, 2010, at 9:44 AM, Derek Atkins wrote:
On Tue, December 7, 2010 12:33 pm, John Ralls wrote:
On Dec 6, 2010, at 8:07 AM, Derek Atkins wrote:
Robin Chattopadhyay robinra...@gmail.com writes:
At a minimum:
* Update the database schema (sqlite, postgres, mysql) to add a column
to exclude any transactions where
the closing entry flag is set to 'y'.
* Update the Close Books routine to set the closing entry flag to 'y' for
each transaction created by the routine.
This might be a little more challenging, but should be doable.
Possible addition:
* Update the report
to 'y'.
* Update the Close Books routine to set the closing entry flag to 'y' for
each transaction created by the routine.
Possible addition:
* Update the report customization screens to give users an option to exclude
the closing entries from the report.
* The default for the option would
JT Morée more...@yahoo.com writes:
--- On Mon, 2/8/10, Derek Atkins warl...@mit.edu wrote:
If you perform Cash
based accounting then you need to apply your Income and
Expense when the
payment happens, not when you book the invoice/bill.
So in this case
the invoice/bill txn does NOT apply
--- On Mon, 2/8/10, Derek Atkins warl...@mit.edu wrote:
If you perform Cash
based accounting then you need to apply your Income and
Expense when the
payment happens, not when you book the invoice/bill.
So in this case
the invoice/bill txn does NOT apply to the period in which
it is dated.
JT Morée more...@yahoo.com writes:
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
On Mon, Feb 8, 2010 at 8:11 AM, Derek Atkins warl...@mit.edu wrote:
JT Morée more...@yahoo.com writes:
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
z33...@gmail.com writes:
On Mon, Feb 8, 2010 at 8:11 AM, Derek Atkins warl...@mit.edu wrote:
JT Morée more...@yahoo.com writes:
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)
You can disagree all you want, but you're still wrong. ;) The GAAP
method to close the books is to create a fake date (or 'invalid' date)
that sits between the periods. That's what most accountants and
large-scale accounting programs do. You might dislike it, but it's the
way the world works.
Op zaterdag 06-02-2010 om 19:33 uur [tijdzone -0800], schreef JT Morée:
I realize the close books issue has been dealt with for years but I'm
coming up empty on searching for this particular aspect. Please tell
me if there is another way to fix this issue that I'm not seeing. As I
JT Morée wrote:
I realize the close books issue has been dealt with for years but I'm coming up
empty on searching for this particular aspect. Please tell me if there is
another way to fix this issue that I'm not seeing.
As I have mentioned before (more than once) the way around
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
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
I realize the close books issue has been dealt with for years but I'm coming up
empty on searching for this particular aspect. Please tell me if there is
another way to fix this issue that I'm not seeing.
As I understand and experience the 'close books' feature: Close books makes
offsetting
27 matches
Mail list logo