Re: [GNC] Working with dates in Postgresql DB

[D. via gnucash-user]

Was the problem that he entered variant dates, or that GnuCash reinterpreted 
his Perth transactions to a new date? My point is this: if he entered 
transactions in Perth for the 11th, and then returned to California, and they 
showed the 10th, wouldn't his problem have been solved if GnuCash had stored 
the local date time and then ignored the time zone? 


 Original Message 
From: John Ralls 
Sent: Sat May 02 03:53:01 GMT+05:30 2020
To: David H 
Cc: "D." , "Eric H. Bowen via gnucash-user" 

Subject: Re: [GNC] Working with dates in Postgresql DB

That's exactly what happened a few years ago to a guy from California who did 
some updates while visiting New Zealand.

Regards,
John Ralls


> On May 1, 2020, at 3:16 PM, David H  wrote:
> 
> Might be a problem if you were in Perth on April 11 entering txns and then 
> back in California on April 10 entering further txns using today's date ?  
> i.e. if you travelled to a timezone that was still the previous day ?
> 
> Cheers David H.
> 
> 
> On Sat, 2 May 2020 at 04:35, D. via gnucash-user  
> wrote:
> I understand that a lot of debate and discussion and heartache had gone into 
> this, so I really don't mean to be a pain, but it would seem to me that if I 
> entered April 10, 2020 for a transaction, and GnuCash then stored 2020-04-10 
> HH:MM:SS (where HH:MM:SS represents any arbitrary time), if GnuCash then 
> ignored the time portion from that point forth, then I'd see April 10, 2020 
> no matter how many times I crossed the date line. If I'm in California on 
> April 10, or in Perth on April 11, I'm presumably going to pick "today's" 
> date for my transaction. The two dates would be different, even if the 
> transactions were entered at the exact same time, but I could only see this 
> as a potential problem for a business with offices in both cities. 
> 
> As I said, I don't remember all the details, but I'm sure there were solid 
> reasons for choosing to take transaction dates and store them in UTC, to be 
> converted back to some arbitrary time zone at a later time. It makes my head 
> hurt, though. 
> 
> David
> 
> 
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 23:30:37 GMT+05:30 2020
> To: "D." 
> Cc: finf...@gmail.com, "D. via gnucash-user" 
> Subject: Re: [GNC] Working with dates in Postgresql DB
> 
> David,
> 
> You're not thinking it through: It's about 11:00 on Friday 1 May here in 
> California but it's 03:00 on Saturday 2 May in Western Australia. Chopping 
> off the time doesn't solve anything, a point illustrated by Finfort when he 
> pointed out that just changing the time on the errant dates would put them in 
> the wrong day.
> 
> Regards,
> John Ralls
> 
> 
> 
> 
> > On Apr 30, 2020, at 10:24 PM, D.  wrote:
> > 
> > Thanks for the reply. I do understand the challenges this poses-- both from 
> > the perspective of managing it on a daily basis, and from that of the 
> > difficulty of changing the underlying system. At least, conceptually!
> > 
> > Is there any option to simply ignore the time portion in these timestamps? 
> > It would seem to me that one could focus on that, and simplify the process 
> > piece by piece. Of course, not being a programmer, I'm just a silly voice 
> > in the wilderness.
> > 
> > David
> > 
> > 
> >  Original Message 
> > From: John Ralls 
> > Sent: Fri May 01 10:32:09 GMT+05:30 2020
> > To: "D." 
> > Cc: "finf...@gmail.com" , "D. via gnucash-user" 
> > 
> > Subject: Re: [GNC] Working with dates in Postgresql DB
> > 
> > David,
> > 
> > I don't know why the decision was made to use time, it was taken long 
> > before I joined the project, but it probably has to do with that being the 
> > way computers keep time, in UTC and the accompanying date-time manipulation 
> > functions in the C standard library were readily available. Over the years 
> > various developers have piled more manipulation functions on top of it, or 
> > added other libraries to the side because they made doing something easier, 
> > and splattered it all over the code so that changing the base design would 
> > involve chasing down and reworking all of those disparate functions. As I 
> > said, no one has expressed much enthusiasm for taking it on.
> > 
> > Knowing now that using time instead of date was a poor decision is just 
> > applying 20/20 hindsight to criticize Linas's decision 22 years ago. It 
> > can't change it. I can't say that I would have decided differently.
> > 
> > Regards,
> > John Ralls
> > 
> > 
> >> On Apr 30, 2020, at 8:46 PM, D.  wrote:
> >> 
> >> John,
> >> 
> >> I somewhat remember the discussion back in 2011 about the timestamp, but 
> >> do not recall all the details. Remind me why it is that GnuCash uses 
> >> timestamps in these date fields? All these steps and workarounds that take 
> >> place to present the proper date around the world.
> >> 
> >> Wouldn't it be simpler just to store a bare date?
> >> 
> >> Or just ignore the time portion and 

Re: [GNC] Change account type by editing XML?

[flywire]

The intent of my post was to report you can't reassign transactions between
Asset and Expenses accounts either using the process previously described.
Yes, the account in Asset was created by the import wizard.

It's nothing serious, went back to the previous file and imported again.


On Sat, May 2, 2020 at 3:27 PM David Carlson wrote:

> Please elaborate.  There are several ways to recover if such a mistake is
> noticed immediately.
>
> If you use the XML format:
>
> 1.  You did do a File > Save immediately before the import, right, so you
> could just abandon the import, re-open the data file and import again.
> 2.  If not, you could still abandon the current changes and open a back-up
> file from earlier.
> 3.  You could follow one of the GnuCash procedures outlined earlier in
> this thread to move the account with transactions to a different parent
> account if it is mistakenly imported under the incorrect parent account
> type.
> 4.  Was the account created by the import wizard?  That may change
> options, but the three procedures listed above should still work.  I
> believe GnuCash allows contra accounts as sub-accounts in the
> Asset/Liability types as well as Income/Expense types, but perhaps not
> mixing Asset and Income or Liability and Expense.  Where contra accounts
> are allowed, I think the types can simply be changed in the account edit
> dialog unless there are existing transactions.
>
> If you use a db format it may be a little more difficult depending on your
> back-up procedure.  I am not a db user, so I cannot speak from experience.
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Working with dates in Postgresql DB

[D. via gnucash-user]

First off, flight time between California and Australia is something like 17 
hours (to Hawaii, it's about 11), so if, after all that, you have energy to do 
your accounting in GnuCash, well, you're more of a masochist than I. 

Second, if I were to land on the 10th in California, I personally would enter 
those transactions for the tenth. Wouldn't you? 


 Original Message 
From: David H 
Sent: Sat May 02 03:46:28 GMT+05:30 2020
To: "D." 
Cc: John Ralls , "Eric H. Bowen via gnucash-user" 

Subject: Re: [GNC] Working with dates in Postgresql DB

Might be a problem if you were in Perth on April 11 entering txns and then
back in California on April 10 entering further txns using today's date ?
i.e. if you travelled to a timezone that was still the previous day ?

Cheers David H.


On Sat, 2 May 2020 at 04:35, D. via gnucash-user 
wrote:

> I understand that a lot of debate and discussion and heartache had gone
> into this, so I really don't mean to be a pain, but it would seem to me
> that if I entered April 10, 2020 for a transaction, and GnuCash then stored
> 2020-04-10 HH:MM:SS (where HH:MM:SS represents any arbitrary time), if
> GnuCash then ignored the time portion from that point forth, then I'd see
> April 10, 2020 no matter how many times I crossed the date line. If I'm in
> California on April 10, or in Perth on April 11, I'm presumably going to
> pick "today's" date for my transaction. The two dates would be different,
> even if the transactions were entered at the exact same time, but I could
> only see this as a potential problem for a business with offices in both
> cities.
>
> As I said, I don't remember all the details, but I'm sure there were solid
> reasons for choosing to take transaction dates and store them in UTC, to be
> converted back to some arbitrary time zone at a later time. It makes my
> head hurt, though.
>
> David
>
>
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 23:30:37 GMT+05:30 2020
> To: "D." 
> Cc: finf...@gmail.com, "D. via gnucash-user" 
> Subject: Re: [GNC] Working with dates in Postgresql DB
>
> David,
>
> You're not thinking it through: It's about 11:00 on Friday 1 May here in
> California but it's 03:00 on Saturday 2 May in Western Australia. Chopping
> off the time doesn't solve anything, a point illustrated by Finfort when he
> pointed out that just changing the time on the errant dates would put them
> in the wrong day.
>
> Regards,
> John Ralls
>
>
>
>
> > On Apr 30, 2020, at 10:24 PM, D.  wrote:
> >
> > Thanks for the reply. I do understand the challenges this poses-- both
> from the perspective of managing it on a daily basis, and from that of the
> difficulty of changing the underlying system. At least, conceptually!
> >
> > Is there any option to simply ignore the time portion in these
> timestamps? It would seem to me that one could focus on that, and simplify
> the process piece by piece. Of course, not being a programmer, I'm just a
> silly voice in the wilderness.
> >
> > David
> >
> >
> >  Original Message 
> > From: John Ralls 
> > Sent: Fri May 01 10:32:09 GMT+05:30 2020
> > To: "D." 
> > Cc: "finf...@gmail.com" , "D. via gnucash-user" <
> gnucash-user@gnucash.org>
> > Subject: Re: [GNC] Working with dates in Postgresql DB
> >
> > David,
> >
> > I don't know why the decision was made to use time, it was taken long
> before I joined the project, but it probably has to do with that being the
> way computers keep time, in UTC and the accompanying date-time manipulation
> functions in the C standard library were readily available. Over the years
> various developers have piled more manipulation functions on top of it, or
> added other libraries to the side because they made doing something easier,
> and splattered it all over the code so that changing the base design would
> involve chasing down and reworking all of those disparate functions. As I
> said, no one has expressed much enthusiasm for taking it on.
> >
> > Knowing now that using time instead of date was a poor decision is just
> applying 20/20 hindsight to criticize Linas's decision 22 years ago. It
> can't change it. I can't say that I would have decided differently.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Apr 30, 2020, at 8:46 PM, D.  wrote:
> >>
> >> John,
> >>
> >> I somewhat remember the discussion back in 2011 about the timestamp,
> but do not recall all the details. Remind me why it is that GnuCash uses
> timestamps in these date fields? All these steps and workarounds that take
> place to present the proper date around the world.
> >>
> >> Wouldn't it be simpler just to store a bare date?
> >>
> >> Or just ignore the time portion and drop the conversion between UTC and
> locale time altogether?
> >>
> >> Everyone refers to them as dates ("transaction date" "invoice date"
> "posting date"). The software arbitrarily uses the same time for everything
> in a futile attempt to properly display dates for all timezones (the

[GNC] Change account type by editing XML?

[flywire]

No it's not specific to type A/R and/or A/P accounts.

I clicked the wrong account and accidentally imported an expenses
account into assets. I was expecting I could just delete it and move
it to Expenses:Account but it just moved to Assets. (Import Matcher
pisses me off because the account was specified correctly in the csv.)


On Wed, Apr 29, 2020, 7:56 PM Adrien Monteleone <

adrien.monteleone at lusfiber.net
> wrote:

>* Already reported earlier today, that doesn’t work.
*>>* I suggested it earlier, and then tested it on my own book. Indeed, once
*>* there are transactions in the errant account, it cannot be changed. This
*>* must be something specific to type A/R and/or A/P accounts.
*>>* Regards,
*>* Adrien*
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Working with dates in Postgresql DB

[John Ralls]

That's exactly what happened a few years ago to a guy from California who did 
some updates while visiting New Zealand.

Regards,
John Ralls


> On May 1, 2020, at 3:16 PM, David H  wrote:
> 
> Might be a problem if you were in Perth on April 11 entering txns and then 
> back in California on April 10 entering further txns using today's date ?  
> i.e. if you travelled to a timezone that was still the previous day ?
> 
> Cheers David H.
> 
> 
> On Sat, 2 May 2020 at 04:35, D. via gnucash-user  
> wrote:
> I understand that a lot of debate and discussion and heartache had gone into 
> this, so I really don't mean to be a pain, but it would seem to me that if I 
> entered April 10, 2020 for a transaction, and GnuCash then stored 2020-04-10 
> HH:MM:SS (where HH:MM:SS represents any arbitrary time), if GnuCash then 
> ignored the time portion from that point forth, then I'd see April 10, 2020 
> no matter how many times I crossed the date line. If I'm in California on 
> April 10, or in Perth on April 11, I'm presumably going to pick "today's" 
> date for my transaction. The two dates would be different, even if the 
> transactions were entered at the exact same time, but I could only see this 
> as a potential problem for a business with offices in both cities. 
> 
> As I said, I don't remember all the details, but I'm sure there were solid 
> reasons for choosing to take transaction dates and store them in UTC, to be 
> converted back to some arbitrary time zone at a later time. It makes my head 
> hurt, though. 
> 
> David
> 
> 
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 23:30:37 GMT+05:30 2020
> To: "D." 
> Cc: finf...@gmail.com, "D. via gnucash-user" 
> Subject: Re: [GNC] Working with dates in Postgresql DB
> 
> David,
> 
> You're not thinking it through: It's about 11:00 on Friday 1 May here in 
> California but it's 03:00 on Saturday 2 May in Western Australia. Chopping 
> off the time doesn't solve anything, a point illustrated by Finfort when he 
> pointed out that just changing the time on the errant dates would put them in 
> the wrong day.
> 
> Regards,
> John Ralls
> 
> 
> 
> 
> > On Apr 30, 2020, at 10:24 PM, D.  wrote:
> > 
> > Thanks for the reply. I do understand the challenges this poses-- both from 
> > the perspective of managing it on a daily basis, and from that of the 
> > difficulty of changing the underlying system. At least, conceptually!
> > 
> > Is there any option to simply ignore the time portion in these timestamps? 
> > It would seem to me that one could focus on that, and simplify the process 
> > piece by piece. Of course, not being a programmer, I'm just a silly voice 
> > in the wilderness.
> > 
> > David
> > 
> > 
> >  Original Message 
> > From: John Ralls 
> > Sent: Fri May 01 10:32:09 GMT+05:30 2020
> > To: "D." 
> > Cc: "finf...@gmail.com" , "D. via gnucash-user" 
> > 
> > Subject: Re: [GNC] Working with dates in Postgresql DB
> > 
> > David,
> > 
> > I don't know why the decision was made to use time, it was taken long 
> > before I joined the project, but it probably has to do with that being the 
> > way computers keep time, in UTC and the accompanying date-time manipulation 
> > functions in the C standard library were readily available. Over the years 
> > various developers have piled more manipulation functions on top of it, or 
> > added other libraries to the side because they made doing something easier, 
> > and splattered it all over the code so that changing the base design would 
> > involve chasing down and reworking all of those disparate functions. As I 
> > said, no one has expressed much enthusiasm for taking it on.
> > 
> > Knowing now that using time instead of date was a poor decision is just 
> > applying 20/20 hindsight to criticize Linas's decision 22 years ago. It 
> > can't change it. I can't say that I would have decided differently.
> > 
> > Regards,
> > John Ralls
> > 
> > 
> >> On Apr 30, 2020, at 8:46 PM, D.  wrote:
> >> 
> >> John,
> >> 
> >> I somewhat remember the discussion back in 2011 about the timestamp, but 
> >> do not recall all the details. Remind me why it is that GnuCash uses 
> >> timestamps in these date fields? All these steps and workarounds that take 
> >> place to present the proper date around the world.
> >> 
> >> Wouldn't it be simpler just to store a bare date?
> >> 
> >> Or just ignore the time portion and drop the conversion between UTC and 
> >> locale time altogether?
> >> 
> >> Everyone refers to them as dates ("transaction date" "invoice date" 
> >> "posting date"). The software arbitrarily uses the same time for 
> >> everything in a futile attempt to properly display dates for all timezones 
> >> (the solution in this thread underscores that fact, insofar as you are 
> >> recommending the user to arbitrarily change all other times to the 
> >> "standard").
> >> 
> >> Of what use is it to store the added detail of an arbitrary timestamp in a 
> >> field that 

Re: [GNC] Working with dates in Postgresql DB

[David H]

Might be a problem if you were in Perth on April 11 entering txns and then
back in California on April 10 entering further txns using today's date ?
i.e. if you travelled to a timezone that was still the previous day ?

Cheers David H.


On Sat, 2 May 2020 at 04:35, D. via gnucash-user 
wrote:

> I understand that a lot of debate and discussion and heartache had gone
> into this, so I really don't mean to be a pain, but it would seem to me
> that if I entered April 10, 2020 for a transaction, and GnuCash then stored
> 2020-04-10 HH:MM:SS (where HH:MM:SS represents any arbitrary time), if
> GnuCash then ignored the time portion from that point forth, then I'd see
> April 10, 2020 no matter how many times I crossed the date line. If I'm in
> California on April 10, or in Perth on April 11, I'm presumably going to
> pick "today's" date for my transaction. The two dates would be different,
> even if the transactions were entered at the exact same time, but I could
> only see this as a potential problem for a business with offices in both
> cities.
>
> As I said, I don't remember all the details, but I'm sure there were solid
> reasons for choosing to take transaction dates and store them in UTC, to be
> converted back to some arbitrary time zone at a later time. It makes my
> head hurt, though.
>
> David
>
>
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 23:30:37 GMT+05:30 2020
> To: "D." 
> Cc: finf...@gmail.com, "D. via gnucash-user" 
> Subject: Re: [GNC] Working with dates in Postgresql DB
>
> David,
>
> You're not thinking it through: It's about 11:00 on Friday 1 May here in
> California but it's 03:00 on Saturday 2 May in Western Australia. Chopping
> off the time doesn't solve anything, a point illustrated by Finfort when he
> pointed out that just changing the time on the errant dates would put them
> in the wrong day.
>
> Regards,
> John Ralls
>
>
>
>
> > On Apr 30, 2020, at 10:24 PM, D.  wrote:
> >
> > Thanks for the reply. I do understand the challenges this poses-- both
> from the perspective of managing it on a daily basis, and from that of the
> difficulty of changing the underlying system. At least, conceptually!
> >
> > Is there any option to simply ignore the time portion in these
> timestamps? It would seem to me that one could focus on that, and simplify
> the process piece by piece. Of course, not being a programmer, I'm just a
> silly voice in the wilderness.
> >
> > David
> >
> >
> >  Original Message 
> > From: John Ralls 
> > Sent: Fri May 01 10:32:09 GMT+05:30 2020
> > To: "D." 
> > Cc: "finf...@gmail.com" , "D. via gnucash-user" <
> gnucash-user@gnucash.org>
> > Subject: Re: [GNC] Working with dates in Postgresql DB
> >
> > David,
> >
> > I don't know why the decision was made to use time, it was taken long
> before I joined the project, but it probably has to do with that being the
> way computers keep time, in UTC and the accompanying date-time manipulation
> functions in the C standard library were readily available. Over the years
> various developers have piled more manipulation functions on top of it, or
> added other libraries to the side because they made doing something easier,
> and splattered it all over the code so that changing the base design would
> involve chasing down and reworking all of those disparate functions. As I
> said, no one has expressed much enthusiasm for taking it on.
> >
> > Knowing now that using time instead of date was a poor decision is just
> applying 20/20 hindsight to criticize Linas's decision 22 years ago. It
> can't change it. I can't say that I would have decided differently.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Apr 30, 2020, at 8:46 PM, D.  wrote:
> >>
> >> John,
> >>
> >> I somewhat remember the discussion back in 2011 about the timestamp,
> but do not recall all the details. Remind me why it is that GnuCash uses
> timestamps in these date fields? All these steps and workarounds that take
> place to present the proper date around the world.
> >>
> >> Wouldn't it be simpler just to store a bare date?
> >>
> >> Or just ignore the time portion and drop the conversion between UTC and
> locale time altogether?
> >>
> >> Everyone refers to them as dates ("transaction date" "invoice date"
> "posting date"). The software arbitrarily uses the same time for everything
> in a futile attempt to properly display dates for all timezones (the
> solution in this thread underscores that fact, insofar as you are
> recommending the user to arbitrarily change all other times to the
> "standard").
> >>
> >> Of what use is it to store the added detail of an arbitrary timestamp
> in a field that is treated everywhere as a date? What is gained?
> >>
> >> David T.
> >>
> >>
> >>  Original Message 
> >> From: John Ralls 
> >> Sent: Fri May 01 00:48:57 GMT+05:30 2020
> >> To: "finf...@gmail.com" 
> >> Cc: Gnucash Users 
> >> Subject: Re: [GNC] Working with dates in Postgresql DB
> >>
> >> GnuCash 

Re: [GNC] Working with dates in Postgresql DB

[Finfort]

 
 

 I hope the posted time in DB in transactions and invoices will be the same 
10:59 at least after fixing these two bugs when posting the invoices and set 
offsets through the lots.
 

 
 
 

 
 
>  
> On May 1, 2020 at 21:32,  mailto:sunfis...@yahoo.com)>  wrote:
>  
>  
>  
>  I understand that a lot of debate and discussion and heartache had gone into 
> this, so I really don't mean to be a pain, but it would seem to me that if I 
> entered April 10, 2020 for a transaction, and GnuCash then stored 2020-04-10 
> HH:MM:SS (where HH:MM:SS represents any arbitrary time), if GnuCash then 
> ignored the time portion from that point forth, then I'd see April 10, 2020 
> no matter how many times I crossed the date line. If I'm in California on 
> April 10, or in Perth on April 11, I'm presumably going to pick "today's" 
> date for my transaction. The two dates would be different, even if the 
> transactions were entered at the exact same time, but I could only see this 
> as a potential problem for a business with offices in both cities. As I said, 
> I don't remember all the details, but I'm sure there were solid reasons for 
> choosing to take transaction dates and store them in UTC, to be converted 
> back to some arbitrary time zone at a later time. It makes my head hurt, 
> though. David -
--- Original Message  From: John RallsSent: Fri 
May 01 23:30:37 GMT+05:30 2020 To: "D."Cc: 
finf...@gmail.com, "D. via gnucash-user"Subject: 
Re: [GNC] Working with dates in Postgresql DB David, You're not thinking it 
through: It's about 11:00 on Friday 1 May here in California but it's 03:00 on 
Saturday 2 May in Western Australia. Chopping off the time doesn't solve 
anything, a point illustrated by Finfort when he pointed out that just changing 
the time on the errant dates would put them in the wrong day. Regards, John 
Ralls  >  On Apr 30, 2020, at 10:24 PM, D.wrote:  >   
>  Thanks for the reply. I do understand the challenges this poses-- both from 
the perspective of managing it on a daily basis, and from that of the 
difficulty of changing the underlying system. At least, conceptually!  >   >  
Is there any option to simply ignore the time portion in these timestamps? It 
wou
ld seem to me that one could focus on that, and simplify the process piece by 
piece. Of course, not being a programmer, I'm just a silly voice in the 
wilderness.  >   >  David  >   >   >   Original Message   >  
From: John Ralls >  Sent: Fri May 01 10:32:09 GMT+05:30 
2020  >  To: "D." >  Cc: "finf...@gmail.com"  
, "D. via gnucash-user" >  
Subject: Re: [GNC] Working with dates in Postgresql DB  >   >  David,  >   >  I 
don't know why the decision was made to use time, it was taken long before I 
joined the project, but it probably has to do with that being the way computers 
keep time, in UTC and the accompanying date-time manipulation functions in the 
C standard library were readily available. Over the years various developers 
have piled more manipulation functions on top of it, or added other libraries 
to the side because they made doing something easier, and splattered it a
ll over the code so that changing the base design would involve chasing down 
and reworking all of those disparate functions. As I said, no one has expressed 
much enthusiasm for taking it on.  >   >  Knowing now that using time instead 
of date was a poor decision is just applying 20/20 hindsight to criticize 
Linas's decision 22 years ago. It can't change it. I can't say that I would 
have decided differently.  >   >  Regards,  >  John Ralls  >   >   >>  On Apr 
30, 2020, at 8:46 PM, D.wrote:  >>   >>  John,  >>   
>>  I somewhat remember the discussion back in 2011 about the timestamp, but do 
not recall all the details. Remind me why it is that GnuCash uses timestamps in 
these date fields? All these steps and workarounds that take place to present 
the proper date around the world.  >>   >>  Wouldn't it be simpler just to 
store a bare date?  >>   >>  Or just ignore the time portion and drop the 
conversion between UTC and locale time altogether?  >>   >>  Everyone 
refers to them as dates ("transaction date" "invoice date" "posting date"). The 
software arbitrarily uses the same time for everything in a futile attempt to 
properly display dates for all timezones (the solution in this thread 
underscores that fact, insofar as you are recommending the user to arbitrarily 
change all other times to the "standard").  >>   >>  Of what use is it to store 
the added detail of an arbitrary timestamp in a field that is treated 
everywhere as a date? What is gained?  >>   >>  David T.  >>   >>   >>  
 Original Message   >>  From: John Ralls
 >>  Sent: Fri May 01 00:48:57 GMT+05:30 2020  >>  To: "finf...@gmail.com"  
   >>  Cc: Gnucash Users >>  
Subject: Re: [GNC] Working with dates in Postgresql DB  >>   >>  GnuCash stores 
all dates as UTC but displays them as local, 

Re: [GNC] Working with dates in Postgresql DB

[D. via gnucash-user]

I understand that a lot of debate and discussion and heartache had gone into 
this, so I really don't mean to be a pain, but it would seem to me that if I 
entered April 10, 2020 for a transaction, and GnuCash then stored 2020-04-10 
HH:MM:SS (where HH:MM:SS represents any arbitrary time), if GnuCash then 
ignored the time portion from that point forth, then I'd see April 10, 2020 no 
matter how many times I crossed the date line. If I'm in California on April 
10, or in Perth on April 11, I'm presumably going to pick "today's" date for my 
transaction. The two dates would be different, even if the transactions were 
entered at the exact same time, but I could only see this as a potential 
problem for a business with offices in both cities. 

As I said, I don't remember all the details, but I'm sure there were solid 
reasons for choosing to take transaction dates and store them in UTC, to be 
converted back to some arbitrary time zone at a later time. It makes my head 
hurt, though. 

David


 Original Message 
From: John Ralls 
Sent: Fri May 01 23:30:37 GMT+05:30 2020
To: "D." 
Cc: finf...@gmail.com, "D. via gnucash-user" 
Subject: Re: [GNC] Working with dates in Postgresql DB

David,

You're not thinking it through: It's about 11:00 on Friday 1 May here in 
California but it's 03:00 on Saturday 2 May in Western Australia. Chopping off 
the time doesn't solve anything, a point illustrated by Finfort when he pointed 
out that just changing the time on the errant dates would put them in the wrong 
day.

Regards,
John Ralls




> On Apr 30, 2020, at 10:24 PM, D.  wrote:
> 
> Thanks for the reply. I do understand the challenges this poses-- both from 
> the perspective of managing it on a daily basis, and from that of the 
> difficulty of changing the underlying system. At least, conceptually!
> 
> Is there any option to simply ignore the time portion in these timestamps? It 
> would seem to me that one could focus on that, and simplify the process piece 
> by piece. Of course, not being a programmer, I'm just a silly voice in the 
> wilderness.
> 
> David
> 
> 
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 10:32:09 GMT+05:30 2020
> To: "D." 
> Cc: "finf...@gmail.com" , "D. via gnucash-user" 
> 
> Subject: Re: [GNC] Working with dates in Postgresql DB
> 
> David,
> 
> I don't know why the decision was made to use time, it was taken long before 
> I joined the project, but it probably has to do with that being the way 
> computers keep time, in UTC and the accompanying date-time manipulation 
> functions in the C standard library were readily available. Over the years 
> various developers have piled more manipulation functions on top of it, or 
> added other libraries to the side because they made doing something easier, 
> and splattered it all over the code so that changing the base design would 
> involve chasing down and reworking all of those disparate functions. As I 
> said, no one has expressed much enthusiasm for taking it on.
> 
> Knowing now that using time instead of date was a poor decision is just 
> applying 20/20 hindsight to criticize Linas's decision 22 years ago. It can't 
> change it. I can't say that I would have decided differently.
> 
> Regards,
> John Ralls
> 
> 
>> On Apr 30, 2020, at 8:46 PM, D.  wrote:
>> 
>> John,
>> 
>> I somewhat remember the discussion back in 2011 about the timestamp, but do 
>> not recall all the details. Remind me why it is that GnuCash uses timestamps 
>> in these date fields? All these steps and workarounds that take place to 
>> present the proper date around the world.
>> 
>> Wouldn't it be simpler just to store a bare date?
>> 
>> Or just ignore the time portion and drop the conversion between UTC and 
>> locale time altogether?
>> 
>> Everyone refers to them as dates ("transaction date" "invoice date" "posting 
>> date"). The software arbitrarily uses the same time for everything in a 
>> futile attempt to properly display dates for all timezones (the solution in 
>> this thread underscores that fact, insofar as you are recommending the user 
>> to arbitrarily change all other times to the "standard").
>> 
>> Of what use is it to store the added detail of an arbitrary timestamp in a 
>> field that is treated everywhere as a date? What is gained?
>> 
>> David T.
>> 
>> 
>>  Original Message 
>> From: John Ralls 
>> Sent: Fri May 01 00:48:57 GMT+05:30 2020
>> To: "finf...@gmail.com" 
>> Cc: Gnucash Users 
>> Subject: Re: [GNC] Working with dates in Postgresql DB
>> 
>> GnuCash stores all dates as UTC but displays them as local, applying the 
>> timezone rules for the date, not for today. So in EEST 2020-02-12 22:00:00 
>> displays as 2020-02-13, 2020-06-12 21:00:00 displays as 2020-06-13, but 
>> 2020-02-21 21:00:00 displays as 2020-02-21.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Apr 30, 2020, at 11:42 AM, finf...@gmail.com wrote:
>>> 
>>> It is not just adding one day, it depends on the 

Re: [GNC] Working with dates in Postgresql DB

[John Ralls]

David,

You're not thinking it through: It's about 11:00 on Friday 1 May here in 
California but it's 03:00 on Saturday 2 May in Western Australia. Chopping off 
the time doesn't solve anything, a point illustrated by Finfort when he pointed 
out that just changing the time on the errant dates would put them in the wrong 
day.

Regards,
John Ralls




> On Apr 30, 2020, at 10:24 PM, D.  wrote:
> 
> Thanks for the reply. I do understand the challenges this poses-- both from 
> the perspective of managing it on a daily basis, and from that of the 
> difficulty of changing the underlying system. At least, conceptually!
> 
> Is there any option to simply ignore the time portion in these timestamps? It 
> would seem to me that one could focus on that, and simplify the process piece 
> by piece. Of course, not being a programmer, I'm just a silly voice in the 
> wilderness.
> 
> David
> 
> 
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 10:32:09 GMT+05:30 2020
> To: "D." 
> Cc: "finf...@gmail.com" , "D. via gnucash-user" 
> 
> Subject: Re: [GNC] Working with dates in Postgresql DB
> 
> David,
> 
> I don't know why the decision was made to use time, it was taken long before 
> I joined the project, but it probably has to do with that being the way 
> computers keep time, in UTC and the accompanying date-time manipulation 
> functions in the C standard library were readily available. Over the years 
> various developers have piled more manipulation functions on top of it, or 
> added other libraries to the side because they made doing something easier, 
> and splattered it all over the code so that changing the base design would 
> involve chasing down and reworking all of those disparate functions. As I 
> said, no one has expressed much enthusiasm for taking it on.
> 
> Knowing now that using time instead of date was a poor decision is just 
> applying 20/20 hindsight to criticize Linas's decision 22 years ago. It can't 
> change it. I can't say that I would have decided differently.
> 
> Regards,
> John Ralls
> 
> 
>> On Apr 30, 2020, at 8:46 PM, D.  wrote:
>> 
>> John,
>> 
>> I somewhat remember the discussion back in 2011 about the timestamp, but do 
>> not recall all the details. Remind me why it is that GnuCash uses timestamps 
>> in these date fields? All these steps and workarounds that take place to 
>> present the proper date around the world.
>> 
>> Wouldn't it be simpler just to store a bare date?
>> 
>> Or just ignore the time portion and drop the conversion between UTC and 
>> locale time altogether?
>> 
>> Everyone refers to them as dates ("transaction date" "invoice date" "posting 
>> date"). The software arbitrarily uses the same time for everything in a 
>> futile attempt to properly display dates for all timezones (the solution in 
>> this thread underscores that fact, insofar as you are recommending the user 
>> to arbitrarily change all other times to the "standard").
>> 
>> Of what use is it to store the added detail of an arbitrary timestamp in a 
>> field that is treated everywhere as a date? What is gained?
>> 
>> David T.
>> 
>> 
>>  Original Message 
>> From: John Ralls 
>> Sent: Fri May 01 00:48:57 GMT+05:30 2020
>> To: "finf...@gmail.com" 
>> Cc: Gnucash Users 
>> Subject: Re: [GNC] Working with dates in Postgresql DB
>> 
>> GnuCash stores all dates as UTC but displays them as local, applying the 
>> timezone rules for the date, not for today. So in EEST 2020-02-12 22:00:00 
>> displays as 2020-02-13, 2020-06-12 21:00:00 displays as 2020-06-13, but 
>> 2020-02-21 21:00:00 displays as 2020-02-21.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Apr 30, 2020, at 11:42 AM, finf...@gmail.com wrote:
>>> 
>>> It is not just adding one day, it depends on the time.
>>> 
>>> Looks like time 00:00:00 is the same date, not next.
>>> 
>>> From 21:00:00 is the next date in most cases, but I did not check all 
>>> transactions manually =)
>>> 
>>> How the program converts this wrong dates to the correct ones in its GUI?
>>> 
>>> I believe I have found a correct way to convert all the dates including 
>>> wrong ones to correct dates in Postgresql (pgAdmin 4):
>>> 
>>> 
>>> date(t.post_date AT TIME ZONE 'UTC' AT TIME ZONE 'EEST') AS 
>>> DATE_AT_timezone_EEST
>>> 
>>> EEST is a correct zone in my case. CEST does not work.
>>> 
>>> The transactions.post_date type is timestamp without timezone: 2017-12-31 
>>> 21:00:00
>>> 
>>> t.post_date AT TIME ZONE 'EEST' AS timestamp_AT_timezone_EEST gives 
>>> 2017-12-31 21:00:00+3
>>> 
>>> date(t.post_date AT TIME ZONE 'UTC' AT TIME ZONE 'EEST') AS 
>>> DATE_AT_timezone_EEST gives 2018-01-01
>>> 
>>> Looks strange but works.
>>> 
>>> 2.
>>> 
>>> There are only 3 transactions with 22:00:00 not connected with invoices.
>>> 
>>> There is only 1 transaction with 21:00:00 not connected with invoices.
>>> 
>>> Thinking how to find them...
>>> 
>>> 
>>> 
>>> On 30/04/2020 21:25, John Ralls wrote:
 Hmm, true. Should be 

Re: [GNC] Change account type by editing XML?

[david whiting]

Assuming I have understood correctly, this still doesn't allow me to
change the account type. See attached screenshot of the Edit Account
dialogue after having moved an account to the top level.

David

On Fri, 1 May 2020 at 17:57, Derek Atkins  wrote:
>
> "Stephen M. Butler"  writes:
>
> > On 4/29/20 11:25 AM, david whiting wrote:
> >> Hello,
> >>
> >> When I first set up my accounts (for a local club) I knew very little
> >> about accounting and misinterpreted some information I was given by an
> >> accountant and ended up creating some sub-accounts in Accounts Receivable.
> >> I now know that was not the correct thing to do, and I should have created
> >> these accounts as straight-forward asset accounts.
> >>
> >> Using gnucash I cannot change the account type for these accounts. When I
> >> use ctrl+e on these accounts I only see account type A/Receivable so I
> >> cannot change them through the GUI.
> >
> > When I've had problems changing the account type on an account, I found
> > that changing the parent first opens up the additional account types to
> > be used.
> >
> > Don't know if that will work for A/R (as I don't utilize them).
>
> Indeed, I was going to suggest that you re-parent to make it a top-level
> account, then you can change the type, and then you can re-parent it
> wherever you want in the hierarchy.
>
> -derek
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see 
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.



-- 
David Whiting
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Change account type by editing XML?

[Derek Atkins]

"Stephen M. Butler"  writes:

> On 4/29/20 11:25 AM, david whiting wrote:
>> Hello,
>>
>> When I first set up my accounts (for a local club) I knew very little
>> about accounting and misinterpreted some information I was given by an
>> accountant and ended up creating some sub-accounts in Accounts Receivable.
>> I now know that was not the correct thing to do, and I should have created
>> these accounts as straight-forward asset accounts.
>>
>> Using gnucash I cannot change the account type for these accounts. When I
>> use ctrl+e on these accounts I only see account type A/Receivable so I
>> cannot change them through the GUI.
>
> When I've had problems changing the account type on an account, I found
> that changing the parent first opens up the additional account types to
> be used.
>
> Don't know if that will work for A/R (as I don't utilize them).

Indeed, I was going to suggest that you re-parent to make it a top-level
account, then you can change the type, and then you can re-parent it
wherever you want in the hierarchy.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] AqBanking for Canadian banks

[Derek Atkins]

Nelson  writes:

> Hello everyone.  
>
> Just wondering if anyone was successful in setting up any Canadian banks for
> online banking in GnuCash. Thanks for sharing.

Do they support OFX-DC?

You can check OFXHome for your bank info?

Good Luck,

> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Why do Imported Transactions NEED to be Matched?

[Derek Atkins]

Hi,

flywire  writes:

> Agree that import works in small chunks (as posted previously). Does that
> response cover any way of getting GUIDs on the data?

The GUIDs are 100% internal to GnuCash and unique per user per object
(account, transaction, etc).  There is no way to add GUIDs to imports,
and even if you did it would never make sense because there is no way
your bank or any other entity would know what GUID to use in your
personal gnucash database.

Just a case in point, even if you and I have the same account name,
e.g. Expenses:Groceries, the GUID in my book and the GUID in your book
would be different.

Having said that, there *ARE* ways to map from textual account name to
GUID, and the CSV and QIF importers already do that to some degree.

> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Mortgage repayment schedule : error while inputting million

[Derek Atkins]

Hi,

Sorry for the delayed response (I'm still catching up on old emails).

Murugan  writes:

> i am new to this forum.  i am trying to create a mortgage repayment schedule
> for 2 Million pesos , but the formula is not picking up the value and
> showing a zero.  can you please let me know what i am doing wrong

Can you post a screen shot on what you see?
You DO need to manually enter the mortgage amount; it doesn't pull it
from the liability balance.

> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Customer Chargeback

[Derek Atkins]

Hi,

I don't see any responses to this question; sorry for the delay but I am
catching up on 2 months of email..

Marcell Madar  writes:

> Hi,
>
> I am trying to use the chargeback function in Gnucash. The chargeback
> customer and job are both specified when I create the bill and the
> "Billable" column is checked on all items in the bill. However, I cannot see
> any option to link this Bill to an Invoice that I send to a customer.
>
> Could you please help me how the chargeback option works in GnuCash?

The way it is supposed to work is when you post Vendor Bills with items
marked "Billable", those posted line-items will appear in the Invoice
editor for the customer.  Then you need to *attach* the items to the
invoice by clicking on the first column in the invoice.

Hope this helps.

> Thank you,
> Marcell

> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Restoring "Unable to save to database" error?

[Eric H. Bowen via gnucash-user]

Yes, that's exactly what I did...made a copy of the Gnucash file in
another directory as a backup, then "Save As" over the old file. Worked
like a charm.


Eric H. Bowen
e...@ehbowen.net 
On 5/1/2020 9:48 AM, Derek Atkins wrote:
> Hi Eric,
>
> Sorry to respond to an old message but I didn't see any responses and I
> am currently catching up on ~2 months of email..
>
> "Eric H. Bowen via gnucash-user"  writes:
>
>> I've been getting the "Unable to save to database" error whenever I
>> import and/or save transactions in one of my asset accounts. I haven't
>> lost any transactions, but it appears that the database which
>> automatically matches imported transactions (or attempts to) is
>> corrupted. I'd be perfectly happy to drop the old database and begin
>> again with a new one, as long as I can keep my previously saved
>> transactions, but I haven't yet found a (newbie friendly) way to do
>> this. Any assistance?Eric.
> Assuming you have not solved this, yet -- have you tried to use File ->
> Save As to save it to a new database or an XML file?
>
> That should at least get you going.  Another option is File -> Save As
> to XML, delete your (SQL?) database, and then File -> Save As back to
> the SQL database to get it to rebuild.
>
> Hope this helps,
>
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> -derek
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Restoring "Unable to save to database" error?

[Derek Atkins]

Hi Eric,

Sorry to respond to an old message but I didn't see any responses and I
am currently catching up on ~2 months of email..

"Eric H. Bowen via gnucash-user"  writes:

> I've been getting the "Unable to save to database" error whenever I
> import and/or save transactions in one of my asset accounts. I haven't
> lost any transactions, but it appears that the database which
> automatically matches imported transactions (or attempts to) is
> corrupted. I'd be perfectly happy to drop the old database and begin
> again with a new one, as long as I can keep my previously saved
> transactions, but I haven't yet found a (newbie friendly) way to do
> this. Any assistance?Eric.

Assuming you have not solved this, yet -- have you tried to use File ->
Save As to save it to a new database or an XML file?

That should at least get you going.  Another option is File -> Save As
to XML, delete your (SQL?) database, and then File -> Save As back to
the SQL database to get it to rebuild.

Hope this helps,

> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Find or search all expenses in a certain account

[Derek Atkins]

Hi,

Sorry to respond to an old thread, but I'm catching up on 2 months of
emails while I was heads-down on another project..

Gio Bacareza  writes:

> I'll give it a try. Thanks Adrien
>
> On Tue, Mar 10, 2020 at 11:41 AM Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
>
>> That was the right criteria. I’m not sure why it isn’t working for you.
>>
>> Maybe I missed something, but you noted earlier that you have 10
>> transactions that are transfers and are fixed properly. You want to delete
>> everything else in AccountA.
>>
>> Doing a search for ‘everything else’ seems to be overkill. (especially at
>> this point) Can’t you just do one of the following:

Here's the problem with these approaches.  A register is, by definition,
the result of a search.  Specifically, it is a SPLIT searach where the
initial criteria is "split->account == register_account".

When you do a FIND from within a register, you are, by definition,
limiting your search to the *account splits*.  Transfer accounts are, by
definition, in *other* splits, not the account splits.  The reason is
that you get a search query that looks like:

  Find splits where
  Split->account == register_account AND
  ( ... your stuff ... )

So, in short, you can't do what you want from within a register because
of the way sub-searches are implemented.

The only way to do this search is to start from the CoA and search for
transactions' split-accounts that match both A and B.

Hope this helps,

>> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Invoice Date

[Derek Atkins]

Adrien,

Sorry for the delayed response -- I'm catching up on 2 months of emails
while I was heads-down on other projects.

Adrien Monteleone  writes:

> I forgot to mention, if you didn’t notice the ‘date opened’ field in
> the pop-up, and you are already in the invoice, click the Edit Invoice
> button to change it. The date cannot be changed from the invoice
> viewing screen. (this is a known bug)

Nope, it's a feature -- working as designed.  :)

> Regards,
> Adrien

> 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 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] New User - Unique Transaction Number & Dates

[Derek Atkins]

Hi Stan,

Sorry to respond to an old message, but I'm catching up on ~2 months of
mail when I was heads-down on other projects..

Stan Brown  writes:

> David, you may be thinking of File » Properties » Accounts » Day
> Threshold for Read-Only Transactions (red-line).
>
> I'm not sure why the developers thought it would be a good idea to do
> this as a number of days in the past instead of a date in the past, but
> they did. It means that if you want, say, to prevent yourself from
> accidentally changing something in last year's transactions, or
> accidentally entering a new transaction with last year's date, you have
> to change the red-line every single day that you use GnuCash.

The idea is that you probably never want to enter transactions more than
e.g. 90 days old.  The devs decided this is a more common desire than
"don't enter last year".  If you set a fixed date then you need to
remember to change it all the time, whereas with a days-setting you can
set it and forget it.

If you're someone who enters transactions once a year, then yes, this
might be a bit more problematic.  If you enter transactions once a week,
this makes much more sense.

Hope this explains the reasoning.

Enjoy!

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Reporting transactions

[Ruaraidh Sackville Hamilton]

Yes :)

They differ from other brokerage accounts in regulations on tax and on when
and how you can withdraw funds. e.g. when you use it in retirement as your
pension income, withdrawals from the fund into your normal bank account are
taxed as income at the point of withdrawal (again, from a tax perspective,
paying into a SIPP is a business expense, whereas withdrawing from a SIPP
is a taxable income).

But yes, they are brokerage accounts, to be managed as you say.

On Fri, 1 May 2020 at 12:00, Christopher Lam 
wrote:

> IIUC the SIPP is simply a wrapper around stock-type and cash-type
> investments, so, you'd handle it exactly the same as any Broker and Broker
> investments.
>
> See https://www.gnucash.org/docs/v3/C/gnucash-guide/invest-setup1.html -
> the SIPP wrapper would be the "Brokerage Accounts" asset. You may choose to
> record each stock fluctuation, or (my preference) trust the SIPP statements
> instead.
>
> Annually you'd print a Transaction Report from SIPP account. Or you can
> run a cash flow report, originating from SIPP account and children.
>
> On Fri, 1 May 2020 at 10:26, Ruaraidh Sackville Hamilton <
> ruaraidh...@gmail.com> wrote:
>
>> Yes sure that's one perspective and I agree with it, and that's why I
>> have my SIPP in the same GC file as everything else. I was just noting that
>> the way contributions are reported (i.e. as expenses eligible for tax
>> rebates, not as income that is taxed) seems more in line with a
>> different perspective, that the net worth of a SIPP is independent from
>> personal net worth. Isn't a business's net worth different from personal
>> net worth? Isn't it possible to view it both ways?
>>
>> Ignore me. I'm a novice to GnuCash and naive in economics. I just find it
>> interesting, learning new concepts as part of learning GnuCash.
>>
>> On Fri, 1 May 2020 at 10:41, Christopher Lam 
>> wrote:
>>
>>> I wouldn't classify sipp contributions as expense. You'd be incorrectly
>>> reducing your net worth whenever you contribute to it.
>>>
>>> On Fri, 1 May 2020, 5:23 pm Ruaraidh Sackville Hamilton, <
>>> ruaraidh...@gmail.com> wrote:
>>>
 Ah yes you are right! I didn't think of the case where an employer pays
 directly into a SIPP. In that case it is clearly an income. Not in mine.

 Conceptually, it might be better thought of as a business expense. The
 business is the SIPP and the government encourages investment in the
 business by giving tax rebates on allowable business expenses. Payments
 into the SIPP are reported in the tax report as expenses rather than as
 income. And a SIPP is not like other assets: I can't sell it or trade
 it,
 and there are strict rules limiting when and how much income I can take
 from it in retirement. So maybe we should look at the SIPP as its own
 independent entity, with income to the SIPP being expenses to our other
 assets, just as reported in tax reports.

 But that seems a theoretical discussion, and we have a sort of pragmatic
 solution that works (even though I have to go outside of GnuCash to
 calculate what to put in the tax form)

 Thanks again for enlightening comments!

 On Thu, 30 Apr 2020 at 16:30, D.  wrote:

 > Ah, then yes it's a terminology thing. In my own case, money from my
 > income goes directly into the SIPP as a payroll deduction, so I just
 > transfer from income into the SIPP. It can just as easily go from an
 asset
 > to another asset.
 >
 >
 >  Original Message 
 > From: Ruaraidh Sackville Hamilton 
 > Sent: Thu Apr 30 19:42:46 GMT+05:30 2020
 > To: "D." 
 > Cc: "D. via gnucash-user" 
 > Subject: Re: [GNC] Reporting transactions
 >
 > Sorry David, I didn't mean to imply I prefer the second to the first
 > option. I just thought it easier to show by editing one of your
 versions,
 > and happened to pick the second. I could as easily have picked the
 first.
 >
 > In my reply I replaced your "Income:Me" with "Assets:my bank
 account". The
 > point is that, when the SIPP is in the same GC file as my other
 assets, the
 > transaction is from one asset (the bank account I used to pay into the
 > SIPP) to another asset (my SIPP). It's not from an income account to
 the
 > SIPP, so it can't appear in a report of income.
 >
 > If I keep the SIPP in a separate dedicated GC file, then no problem:
 my
 > contribution appears in the main GC file as an expense against my bank
 > account and as an income in the SIPP GC file. I just wondered if
 there was
 > a way of keeping all assets in one file.
 >
 > Ruaraidh
 >
 > On Thu, 30 Apr 2020 at 14:41, D.  wrote:
 >
 > > ???
 > >
 > > Perhaps this is a terminology thing, but aren't you just
 re-presenting
 > the
 > > second option I gave originally?
 > >
 > > Think of it 

Re: [GNC] Reporting transactions

[Christopher Lam]

IIUC the SIPP is simply a wrapper around stock-type and cash-type
investments, so, you'd handle it exactly the same as any Broker and Broker
investments.

See https://www.gnucash.org/docs/v3/C/gnucash-guide/invest-setup1.html -
the SIPP wrapper would be the "Brokerage Accounts" asset. You may choose to
record each stock fluctuation, or (my preference) trust the SIPP statements
instead.

Annually you'd print a Transaction Report from SIPP account. Or you can run
a cash flow report, originating from SIPP account and children.

On Fri, 1 May 2020 at 10:26, Ruaraidh Sackville Hamilton <
ruaraidh...@gmail.com> wrote:

> Yes sure that's one perspective and I agree with it, and that's why I have
> my SIPP in the same GC file as everything else. I was just noting that the
> way contributions are reported (i.e. as expenses eligible for tax rebates,
> not as income that is taxed) seems more in line with a
> different perspective, that the net worth of a SIPP is independent from
> personal net worth. Isn't a business's net worth different from personal
> net worth? Isn't it possible to view it both ways?
>
> Ignore me. I'm a novice to GnuCash and naive in economics. I just find it
> interesting, learning new concepts as part of learning GnuCash.
>
> On Fri, 1 May 2020 at 10:41, Christopher Lam 
> wrote:
>
>> I wouldn't classify sipp contributions as expense. You'd be incorrectly
>> reducing your net worth whenever you contribute to it.
>>
>> On Fri, 1 May 2020, 5:23 pm Ruaraidh Sackville Hamilton, <
>> ruaraidh...@gmail.com> wrote:
>>
>>> Ah yes you are right! I didn't think of the case where an employer pays
>>> directly into a SIPP. In that case it is clearly an income. Not in mine.
>>>
>>> Conceptually, it might be better thought of as a business expense. The
>>> business is the SIPP and the government encourages investment in the
>>> business by giving tax rebates on allowable business expenses. Payments
>>> into the SIPP are reported in the tax report as expenses rather than as
>>> income. And a SIPP is not like other assets: I can't sell it or trade it,
>>> and there are strict rules limiting when and how much income I can take
>>> from it in retirement. So maybe we should look at the SIPP as its own
>>> independent entity, with income to the SIPP being expenses to our other
>>> assets, just as reported in tax reports.
>>>
>>> But that seems a theoretical discussion, and we have a sort of pragmatic
>>> solution that works (even though I have to go outside of GnuCash to
>>> calculate what to put in the tax form)
>>>
>>> Thanks again for enlightening comments!
>>>
>>> On Thu, 30 Apr 2020 at 16:30, D.  wrote:
>>>
>>> > Ah, then yes it's a terminology thing. In my own case, money from my
>>> > income goes directly into the SIPP as a payroll deduction, so I just
>>> > transfer from income into the SIPP. It can just as easily go from an
>>> asset
>>> > to another asset.
>>> >
>>> >
>>> >  Original Message 
>>> > From: Ruaraidh Sackville Hamilton 
>>> > Sent: Thu Apr 30 19:42:46 GMT+05:30 2020
>>> > To: "D." 
>>> > Cc: "D. via gnucash-user" 
>>> > Subject: Re: [GNC] Reporting transactions
>>> >
>>> > Sorry David, I didn't mean to imply I prefer the second to the first
>>> > option. I just thought it easier to show by editing one of your
>>> versions,
>>> > and happened to pick the second. I could as easily have picked the
>>> first.
>>> >
>>> > In my reply I replaced your "Income:Me" with "Assets:my bank account".
>>> The
>>> > point is that, when the SIPP is in the same GC file as my other
>>> assets, the
>>> > transaction is from one asset (the bank account I used to pay into the
>>> > SIPP) to another asset (my SIPP). It's not from an income account to
>>> the
>>> > SIPP, so it can't appear in a report of income.
>>> >
>>> > If I keep the SIPP in a separate dedicated GC file, then no problem: my
>>> > contribution appears in the main GC file as an expense against my bank
>>> > account and as an income in the SIPP GC file. I just wondered if there
>>> was
>>> > a way of keeping all assets in one file.
>>> >
>>> > Ruaraidh
>>> >
>>> > On Thu, 30 Apr 2020 at 14:41, D.  wrote:
>>> >
>>> > > ???
>>> > >
>>> > > Perhaps this is a terminology thing, but aren't you just
>>> re-presenting
>>> > the
>>> > > second option I gave originally?
>>> > >
>>> > > Think of it another way: there are two sources for the funding of
>>> your
>>> > > SIPP: your contribution, and the government's. How you handle your
>>> own
>>> > > contribution depends on your workflow; the government is giving you
>>> > money,
>>> > > so that's an income account. I offered two methods of recording that
>>> > > two-step; yours is a repetition of my second method.
>>> > >
>>> > > I personally use the first, since the two events are inextricably
>>> linked
>>> > > (the second never happens without the first).
>>> > >
>>> > > Or am I missing something?
>>> > >
>>> > > David
>>> > >
>>> > >
>>> > >  Original Message 
>>> > > 

Re: [GNC] Reporting transactions

[Ruaraidh Sackville Hamilton]

Yes sure that's one perspective and I agree with it, and that's why I have
my SIPP in the same GC file as everything else. I was just noting that the
way contributions are reported (i.e. as expenses eligible for tax rebates,
not as income that is taxed) seems more in line with a
different perspective, that the net worth of a SIPP is independent from
personal net worth. Isn't a business's net worth different from personal
net worth? Isn't it possible to view it both ways?

Ignore me. I'm a novice to GnuCash and naive in economics. I just find it
interesting, learning new concepts as part of learning GnuCash.

On Fri, 1 May 2020 at 10:41, Christopher Lam 
wrote:

> I wouldn't classify sipp contributions as expense. You'd be incorrectly
> reducing your net worth whenever you contribute to it.
>
> On Fri, 1 May 2020, 5:23 pm Ruaraidh Sackville Hamilton, <
> ruaraidh...@gmail.com> wrote:
>
>> Ah yes you are right! I didn't think of the case where an employer pays
>> directly into a SIPP. In that case it is clearly an income. Not in mine.
>>
>> Conceptually, it might be better thought of as a business expense. The
>> business is the SIPP and the government encourages investment in the
>> business by giving tax rebates on allowable business expenses. Payments
>> into the SIPP are reported in the tax report as expenses rather than as
>> income. And a SIPP is not like other assets: I can't sell it or trade it,
>> and there are strict rules limiting when and how much income I can take
>> from it in retirement. So maybe we should look at the SIPP as its own
>> independent entity, with income to the SIPP being expenses to our other
>> assets, just as reported in tax reports.
>>
>> But that seems a theoretical discussion, and we have a sort of pragmatic
>> solution that works (even though I have to go outside of GnuCash to
>> calculate what to put in the tax form)
>>
>> Thanks again for enlightening comments!
>>
>> On Thu, 30 Apr 2020 at 16:30, D.  wrote:
>>
>> > Ah, then yes it's a terminology thing. In my own case, money from my
>> > income goes directly into the SIPP as a payroll deduction, so I just
>> > transfer from income into the SIPP. It can just as easily go from an
>> asset
>> > to another asset.
>> >
>> >
>> >  Original Message 
>> > From: Ruaraidh Sackville Hamilton 
>> > Sent: Thu Apr 30 19:42:46 GMT+05:30 2020
>> > To: "D." 
>> > Cc: "D. via gnucash-user" 
>> > Subject: Re: [GNC] Reporting transactions
>> >
>> > Sorry David, I didn't mean to imply I prefer the second to the first
>> > option. I just thought it easier to show by editing one of your
>> versions,
>> > and happened to pick the second. I could as easily have picked the
>> first.
>> >
>> > In my reply I replaced your "Income:Me" with "Assets:my bank account".
>> The
>> > point is that, when the SIPP is in the same GC file as my other assets,
>> the
>> > transaction is from one asset (the bank account I used to pay into the
>> > SIPP) to another asset (my SIPP). It's not from an income account to the
>> > SIPP, so it can't appear in a report of income.
>> >
>> > If I keep the SIPP in a separate dedicated GC file, then no problem: my
>> > contribution appears in the main GC file as an expense against my bank
>> > account and as an income in the SIPP GC file. I just wondered if there
>> was
>> > a way of keeping all assets in one file.
>> >
>> > Ruaraidh
>> >
>> > On Thu, 30 Apr 2020 at 14:41, D.  wrote:
>> >
>> > > ???
>> > >
>> > > Perhaps this is a terminology thing, but aren't you just re-presenting
>> > the
>> > > second option I gave originally?
>> > >
>> > > Think of it another way: there are two sources for the funding of your
>> > > SIPP: your contribution, and the government's. How you handle your own
>> > > contribution depends on your workflow; the government is giving you
>> > money,
>> > > so that's an income account. I offered two methods of recording that
>> > > two-step; yours is a repetition of my second method.
>> > >
>> > > I personally use the first, since the two events are inextricably
>> linked
>> > > (the second never happens without the first).
>> > >
>> > > Or am I missing something?
>> > >
>> > > David
>> > >
>> > >
>> > >  Original Message 
>> > > From: Ruaraidh Sackville Hamilton 
>> > > Sent: Thu Apr 30 17:20:34 GMT+05:30 2020
>> > > To: "D." 
>> > > Cc: Gnucash Users 
>> > > Subject: Re: [GNC] Reporting transactions
>> > >
>> > > That covers it if the SIPP is in a separate GC file of its own, where
>> my
>> > > contribution is an income (and an expense from my bank account in the
>> > main
>> > > GC file, which I use to fund the contribution).
>> > >
>> > > But if it's all in one GC file we have
>> > >
>> > > 01-01-2020 SIPP Contribution   Assets:SIPP  £100
>> > > My contribution  Assets:my bank account  £100
>> > >
>> > > 01-01-2020 SIPP Govt Contribution   Assets:SIPP  £25
>> > > Government contribution Income:GovContrib £25
>> > >
>> > > Am I wrong?
>> > >
>> > > 

Re: [GNC] Reporting transactions

[Christopher Lam]

I wouldn't classify sipp contributions as expense. You'd be incorrectly
reducing your net worth whenever you contribute to it.

On Fri, 1 May 2020, 5:23 pm Ruaraidh Sackville Hamilton, <
ruaraidh...@gmail.com> wrote:

> Ah yes you are right! I didn't think of the case where an employer pays
> directly into a SIPP. In that case it is clearly an income. Not in mine.
>
> Conceptually, it might be better thought of as a business expense. The
> business is the SIPP and the government encourages investment in the
> business by giving tax rebates on allowable business expenses. Payments
> into the SIPP are reported in the tax report as expenses rather than as
> income. And a SIPP is not like other assets: I can't sell it or trade it,
> and there are strict rules limiting when and how much income I can take
> from it in retirement. So maybe we should look at the SIPP as its own
> independent entity, with income to the SIPP being expenses to our other
> assets, just as reported in tax reports.
>
> But that seems a theoretical discussion, and we have a sort of pragmatic
> solution that works (even though I have to go outside of GnuCash to
> calculate what to put in the tax form)
>
> Thanks again for enlightening comments!
>
> On Thu, 30 Apr 2020 at 16:30, D.  wrote:
>
> > Ah, then yes it's a terminology thing. In my own case, money from my
> > income goes directly into the SIPP as a payroll deduction, so I just
> > transfer from income into the SIPP. It can just as easily go from an
> asset
> > to another asset.
> >
> >
> >  Original Message 
> > From: Ruaraidh Sackville Hamilton 
> > Sent: Thu Apr 30 19:42:46 GMT+05:30 2020
> > To: "D." 
> > Cc: "D. via gnucash-user" 
> > Subject: Re: [GNC] Reporting transactions
> >
> > Sorry David, I didn't mean to imply I prefer the second to the first
> > option. I just thought it easier to show by editing one of your versions,
> > and happened to pick the second. I could as easily have picked the first.
> >
> > In my reply I replaced your "Income:Me" with "Assets:my bank account".
> The
> > point is that, when the SIPP is in the same GC file as my other assets,
> the
> > transaction is from one asset (the bank account I used to pay into the
> > SIPP) to another asset (my SIPP). It's not from an income account to the
> > SIPP, so it can't appear in a report of income.
> >
> > If I keep the SIPP in a separate dedicated GC file, then no problem: my
> > contribution appears in the main GC file as an expense against my bank
> > account and as an income in the SIPP GC file. I just wondered if there
> was
> > a way of keeping all assets in one file.
> >
> > Ruaraidh
> >
> > On Thu, 30 Apr 2020 at 14:41, D.  wrote:
> >
> > > ???
> > >
> > > Perhaps this is a terminology thing, but aren't you just re-presenting
> > the
> > > second option I gave originally?
> > >
> > > Think of it another way: there are two sources for the funding of your
> > > SIPP: your contribution, and the government's. How you handle your own
> > > contribution depends on your workflow; the government is giving you
> > money,
> > > so that's an income account. I offered two methods of recording that
> > > two-step; yours is a repetition of my second method.
> > >
> > > I personally use the first, since the two events are inextricably
> linked
> > > (the second never happens without the first).
> > >
> > > Or am I missing something?
> > >
> > > David
> > >
> > >
> > >  Original Message 
> > > From: Ruaraidh Sackville Hamilton 
> > > Sent: Thu Apr 30 17:20:34 GMT+05:30 2020
> > > To: "D." 
> > > Cc: Gnucash Users 
> > > Subject: Re: [GNC] Reporting transactions
> > >
> > > That covers it if the SIPP is in a separate GC file of its own, where
> my
> > > contribution is an income (and an expense from my bank account in the
> > main
> > > GC file, which I use to fund the contribution).
> > >
> > > But if it's all in one GC file we have
> > >
> > > 01-01-2020 SIPP Contribution   Assets:SIPP  £100
> > > My contribution  Assets:my bank account  £100
> > >
> > > 01-01-2020 SIPP Govt Contribution   Assets:SIPP  £25
> > > Government contribution Income:GovContrib £25
> > >
> > > Am I wrong?
> > >
> > > Ruaraidh
> > >
> > > On Thu, 30 Apr 2020 at 12:33, D.  wrote:
> > >
> > > > Set up an independent income account for the government
> contributions:
> > > >
> > > > Income:GovContrib
> > > >
> > > > Then add either a split to your contribution for the government,
> > > >
> > > > 01-01-2020 SIPP Contribution   Assets:SIPP  £125
> > > > My contribution  Income:Me  £100
> > > > Government contribution Income:GovContrib £25
> > > >
> > > > or a separate transaction,
> > > >
> > > > 01-01-2020 SIPP Contribution   Assets:SIPP  £100
> > > > My contribution  Income:Me  £100
> > > >
> > > > 01-01-2020 SIPP Govt Contribution   Assets:SIPP  £25
> > > > Government contribution Income:GovContrib £25
> > > >
> > > > That should cover it, yes?
> > > >
> > > >
> 

Re: [GNC] Reporting transactions

[Ruaraidh Sackville Hamilton]

Ah yes you are right! I didn't think of the case where an employer pays
directly into a SIPP. In that case it is clearly an income. Not in mine.

Conceptually, it might be better thought of as a business expense. The
business is the SIPP and the government encourages investment in the
business by giving tax rebates on allowable business expenses. Payments
into the SIPP are reported in the tax report as expenses rather than as
income. And a SIPP is not like other assets: I can't sell it or trade it,
and there are strict rules limiting when and how much income I can take
from it in retirement. So maybe we should look at the SIPP as its own
independent entity, with income to the SIPP being expenses to our other
assets, just as reported in tax reports.

But that seems a theoretical discussion, and we have a sort of pragmatic
solution that works (even though I have to go outside of GnuCash to
calculate what to put in the tax form)

Thanks again for enlightening comments!

On Thu, 30 Apr 2020 at 16:30, D.  wrote:

> Ah, then yes it's a terminology thing. In my own case, money from my
> income goes directly into the SIPP as a payroll deduction, so I just
> transfer from income into the SIPP. It can just as easily go from an asset
> to another asset.
>
>
>  Original Message 
> From: Ruaraidh Sackville Hamilton 
> Sent: Thu Apr 30 19:42:46 GMT+05:30 2020
> To: "D." 
> Cc: "D. via gnucash-user" 
> Subject: Re: [GNC] Reporting transactions
>
> Sorry David, I didn't mean to imply I prefer the second to the first
> option. I just thought it easier to show by editing one of your versions,
> and happened to pick the second. I could as easily have picked the first.
>
> In my reply I replaced your "Income:Me" with "Assets:my bank account". The
> point is that, when the SIPP is in the same GC file as my other assets, the
> transaction is from one asset (the bank account I used to pay into the
> SIPP) to another asset (my SIPP). It's not from an income account to the
> SIPP, so it can't appear in a report of income.
>
> If I keep the SIPP in a separate dedicated GC file, then no problem: my
> contribution appears in the main GC file as an expense against my bank
> account and as an income in the SIPP GC file. I just wondered if there was
> a way of keeping all assets in one file.
>
> Ruaraidh
>
> On Thu, 30 Apr 2020 at 14:41, D.  wrote:
>
> > ???
> >
> > Perhaps this is a terminology thing, but aren't you just re-presenting
> the
> > second option I gave originally?
> >
> > Think of it another way: there are two sources for the funding of your
> > SIPP: your contribution, and the government's. How you handle your own
> > contribution depends on your workflow; the government is giving you
> money,
> > so that's an income account. I offered two methods of recording that
> > two-step; yours is a repetition of my second method.
> >
> > I personally use the first, since the two events are inextricably linked
> > (the second never happens without the first).
> >
> > Or am I missing something?
> >
> > David
> >
> >
> >  Original Message 
> > From: Ruaraidh Sackville Hamilton 
> > Sent: Thu Apr 30 17:20:34 GMT+05:30 2020
> > To: "D." 
> > Cc: Gnucash Users 
> > Subject: Re: [GNC] Reporting transactions
> >
> > That covers it if the SIPP is in a separate GC file of its own, where my
> > contribution is an income (and an expense from my bank account in the
> main
> > GC file, which I use to fund the contribution).
> >
> > But if it's all in one GC file we have
> >
> > 01-01-2020 SIPP Contribution   Assets:SIPP  £100
> > My contribution  Assets:my bank account  £100
> >
> > 01-01-2020 SIPP Govt Contribution   Assets:SIPP  £25
> > Government contribution Income:GovContrib £25
> >
> > Am I wrong?
> >
> > Ruaraidh
> >
> > On Thu, 30 Apr 2020 at 12:33, D.  wrote:
> >
> > > Set up an independent income account for the government contributions:
> > >
> > > Income:GovContrib
> > >
> > > Then add either a split to your contribution for the government,
> > >
> > > 01-01-2020 SIPP Contribution   Assets:SIPP  £125
> > > My contribution  Income:Me  £100
> > > Government contribution Income:GovContrib £25
> > >
> > > or a separate transaction,
> > >
> > > 01-01-2020 SIPP Contribution   Assets:SIPP  £100
> > > My contribution  Income:Me  £100
> > >
> > > 01-01-2020 SIPP Govt Contribution   Assets:SIPP  £25
> > > Government contribution Income:GovContrib £25
> > >
> > > That should cover it, yes?
> > >
> > >
> > >
> > >
> > >  Original Message 
> > > From: Ruaraidh 
> > > Sent: Thu Apr 30 15:17:04 GMT+05:30 2020
> > > To: gnucash-user@gnucash.org
> > > Subject: [GNC] Reporting transactions
> > >
> > > I have another question related to UK tax reporting obligations.
> > >
> > > In the UK we can have a type of asset called a SIPP (Self-invested
> > Personal
> > > Pension). You pay money into a SIPP with the idea of building up an
> > income
> > > for your 

Re: [GNC] Superannuation Co-Vid payment

[D. via gnucash-user]

Did you read thre recommendations that David Cousens gave in:

https://lists.gnucash.org/pipermail/gnucash-user/2020-May/090891.html

David T. 


 Original Message 
From: Chris Taylor 
Sent: Fri May 01 11:37:46 GMT+05:30 2020
To: gnucash-user@gnucash.org
Subject: [GNC] Superannuation Co-Vid payment

Hi everyone
Looking for some advice on how to setup a account system
Ok. What I have done is take up the Gov on the Co-Vid superannuation 
payment (withdrawal) of $10,000
What I wish to do is have it show up in bank account AAA that works day 
to day, I will be buying Gold this this money on a weekly basis that 
will come out of account AAA and got to AB company.
But I wish to know when I have transfered the 10,000.
Hope you can see what I want
Thanks for any input
Chris
I'm not asking if you think that what I'm doing is correct or not. That 
is MY decision not yours
I'm just asking the best way to manage it is GNUCASH
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Adding Transactions From Another Program

[david whiting]

I thought it was related to the due identity issues with python 2.7
and python 3.x

On Fri, 1 May 2020 at 06:30, D. via gnucash-user
 wrote:
>
> That somehow seems to be an entirely justified substitution in my case!
>
>
>  Original Message 
> From: John Ralls 
> Sent: Fri May 01 10:34:54 GMT+05:30 2020
> To: "D." 
> Cc: Hal Vaughan , "D. via gnucash-user" 
> 
> Subject: Re: [GNC] Adding Transactions From Another Program
>
> Maybe one supplied by a drug manufacturer. Google tells me that Clozapine is 
> an antipsychotic.
>
> Regards,
> John Ralls
>
>
> > On Apr 30, 2020, at 9:54 PM, D. via gnucash-user  
> > wrote:
> >
> > "clozapine"="compile"
> >
> > Not sure what dictionary my machine is using!
> >
> >
> >  Original Message 
> > From: "D. via gnucash-user" 
> > Sent: Fri May 01 09:21:46 GMT+05:30 2020
> > To: Hal Vaughan 
> > Cc: "D. via gnucash-user" 
> > Subject: Re: [GNC] Adding Transactions From Another Program
> >
> > Hal,
> >
> > John Ralls, the person who manages the Mac end of GnuCash, has pointed out 
> > that Homebrew simply uses the GnuCash dmg for its installation. That dmg 
> > does not include python bindings, so the answer to your question is "No, 
> > Homebrew does not include python. You would need to clozapine GnuCash 
> > yourself."
> >
> > David T.
> >
> >
> >  Original Message 
> > From: Hal Vaughan 
> > Sent: Fri May 01 01:32:14 GMT+05:30 2020
> > To: Gnucash 
> > Subject: Re: [GNC] Adding Transactions From Another Program
> >
> > Actually, this has me looking over what I am and am not still using.
> >
> > Since Mac is still using Python 2.7, but Catalina is coming up and that 
> > includes Python 3.x.  So I’m looking over what I use and what I don’t among 
> > my decades of scripts.
> >
> > Last I looked, pretty much every system like that usurped the originals.  
> > At the time, when I looked them over, it became clear to me why they did 
> > that and it made sense.  But, again, that decision was something like 10 
> > years ago and I haven’t had time or cause to revisit it - until now.
> >
> > Do you know if Homebrew can provide the Python bindings for GC?
> >
> >
> > Hal
> >
> >> On Apr 30, 2020, at 2:27 AM, Adrien Monteleone 
> >>  wrote:
> >>
> >> Have you investigated Homebrew vs. MacPorts?
> >>
> >> Just curious if the Perl issues are the same.
> >>
> >> Regards,
> >> Adrien
> >>
> >>> On Apr 30, 2020 w18d121, at 12:29 AM, Hal Vaughan  wrote:
> >>>
> >>> I’ve checked out the bindings - as I mentioned in my original post, the 
> >>> problem is that using the bindings on a Mac requires MacPorts.  I’ve had 
> >>> issues before, since MacPorts (and other similar systems) usurp some of 
> >>> the normal paths for things like Perl and Python.  I don’t use Perl for 
> >>> coding anymore, but I have Perl scripts I’ve been using for over a decade 
> >>> that do some simple work for me.  I had an important Perl script I was 
> >>> using that used a specific Perl library.  I don’t remember which one it 
> >>> was, but when I added MacPorts and tried to run my script a week later, 
> >>> it crashed.
> >>>
> >>> I had no idea MacPorts, Fink, Homebrew, and similar systems usurped the 
> >>> normal system paths for scripting languages.  When I installed it, and it 
> >>> took over for Perl, it put in a system without all the libraries my 
> >>> scripts used and some of the libraries that were available to me with a 
> >>> standard Perl install (libraries I had installed from CPAN) would not 
> >>> install in the new system.  I had to completely remove MacPorts to get my 
> >>> old scripts to work.
> >>>
> >>> I’d love to use MacPorts, since it makes a lot available to me that I 
> >>> can’t easily add now (unless I start using a Linux VM), but that 
> >>> experience taught me never to trust such a system.
> >>>
> >>> I think it would be a lot easier for me to do this with Python bindings, 
> >>> but I still use older scripts for things I need to do once a month or 
> >>> once a year and I don’t want to risk breaking them again like they broke 
> >>> about a decade ago when I installed MacPorts.
> >>>
> >>>
> >>> Hal
> >>
> >>
> >> ___
> >> gnucash-user mailing list
> >> gnucash-user@gnucash.org
> >> To update your subscription preferences or to unsubscribe:
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >> If you are using Nabble or Gmane, please see 
> >> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> >> -
> >> 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@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see 
> > https://wiki.gnucash.org/wiki/Mailing_Lists 

[GNC] Superannuation Co-Vid payment

[Chris Taylor]

Hi everyone
Looking for some advice on how to setup a account system
Ok. What I have done is take up the Gov on the Co-Vid superannuation 
payment (withdrawal) of $10,000
What I wish to do is have it show up in bank account AAA that works day 
to day, I will be buying Gold this this money on a weekly basis that 
will come out of account AAA and got to AB company.

But I wish to know when I have transfered the 10,000.
Hope you can see what I want
Thanks for any input
Chris
I'm not asking if you think that what I'm doing is correct or not. That 
is MY decision not yours

I'm just asking the best way to manage it is GNUCASH
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.