[GNC] Gnucash 3.9 Flathub stucks
Gnucash 3.9 Flathub stucks for about 5 minutes on Ubuntu 18.04, 19.10 when starting. After that shows it’s logo,boots and works normally. Sometimes it freezes all the system when starting and all you can do is only cold restart. Does anybody have the same problem? ___ 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] Gnucash 3.9 Flathub stucks
Thank you, but what is the command to start it? Just "gnucash" does not work... > > On Apr 7, 2020 at 19:36, (mailto:adrien.montele...@lusfiber.net)> wrote: > > > > Not sure about Flatpak specifics, but I would start it from the command line > and see if there is any output that lends some clues. Regards, Adrien > On > Apr 7, 2020 w15d98, at 6:28 AM, Finfortwrote: > > > > > > Gnucash 3.9 Flathub stucks for about 5 minutes on Ubuntu 18.04, > 19.10 when starting. After that shows it’s logo, boots and works normally. > > > Sometimes it freezes all the system when starting and all you can do is > only cold restart. > > > > Does anybody have the same problem? > ___ 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] Gnucash 3.9 Flathub stucks
Thank you Adrien. Maybe it is better to build it myself from the last source? > > On Apr 7, 2020 at 21:38, (mailto:adrien.montele...@lusfiber.net)> wrote: > > > > That’s why I mentioned ’flatpak specifics’. Search for 'how to launch a > flatpak app from the command line'. Sorry, I don’t use them so I don’t know > the syntax right-off. Regards, Adrien > On Apr 7, 2020 w15d98, at 1:26 PM, > Finfortwrote: > > Thank you, but what is the > command to start it? > Just "gnucash" does not work... > > >> On Apr > 7, 2020 at 19:36,wrote: >> >> Not sure about > Flatpak specifics, but I would start it from the command line and see if > there is any output that lends some clues. >> >> Regards, >> Adrien >> > >> > On Apr 7, 2020 w15d98, at 6:28 AM, Finfort > wrote: >> > >> > >> > >> > >> > Gnucash 3.9 Flathub > stucks for about 5 minutes on Ubuntu 18.04, 19.10 when starting. After that > shows it’s logo, boots and works normally. >> > >> > Sometimes it > freezes all the system when starting and all you can do is only cold restart. > >> > >> > >> > >> > Does anybody have the same problem? > ___ 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] cMakeError.log errors - building Gnucash 3.10
Ofx lib is installed by instructions, anyway...
>
> On Apr 12, 2020 at 19:40, mailto:jra...@ceridwen.us)> wrote:
>
>
>
> > On Apr 12, 2020, at 4:25 AM, finf...@gmail.com wrote: > > I have
> these errors in cMakeError.log after cmake: > > Can anybody explain how
> to fix that? > > > > Performing C++ SOURCE FILE
> Test HAVE_OFX_BUG_39 failed with the following output: > Change Dir:
> /home/dfg/Applications/build-gnucash-3.10/CMakeFiles/CMakeTmp > > Run
> Build Command:"/usr/bin/ninja" "cmTC_5918e" > [1/2] Building CXX object
> CMakeFiles/cmTC_5918e.dir/src.cxx.o > [2/2] Linking CXX executable
> cmTC_5918e > FAILED: cmTC_5918e > : && /usr/bin/c++ -DHAVE_OFX_BUG_39
> CMakeFiles/cmTC_5918e.dir/src.cxx.o -o cmTC_5918e -lofx && : >
> /usr/bin/ld: CMakeFiles/cmTC_5918e.dir/src.cxx.o: in function `main': >
> src.cxx:(.text+0xb5): undefined reference to
> `ofxdate_to_time_t(std::__cxx11::basic_string,
> std::allocator >)' > collect2: error: ld returned 1 exit status >
> ninja: build stopped: subcommand failed. > > Return value: 1 > Source
> file was: > > #include > #include > #include
>> extern time_t ofxdate_to_time_t(const std::string ofxdate); >
> > int main(int argc, char** argv) > { > const std::string timestr =
> "2016031900"; > struct tm ts; > ts.tm_year = 116; > ts.tm_mon = 2;
> > ts.tm_mday = 19; > #ifdef _WIN32 > putenv("TZ=PST-8PDT-7,M 4.1.0/0,M
> 10.6.0/0"); > #else > setenv("TZ", "PST 08P DT 07 M 4.1.0, M 10.6.0", 1);
> > #endif > time_t t = ofxdate_to_time_t(timestr); > if (t ==
> mktime(&ts)) > exit(1); > exit(0); > } > > Determining if the
> pthread_create exist failed with the following output: > Change Dir:
> /home/dfg/Applications/build-gnucash-3.10/CMakeFiles/CMakeTmp > > Run
> Build Command:"/usr/bin/ninja" "cmTC_2d065" > [1/2] Building C object
> CMakeFiles/cmTC_2d065.dir/CheckSymbolExists.c.o > [2/2] Linking C
> executable cmTC_2d065 > FAILED: cmTC_2d065 > : && /usr/bin/cc
> -Wno-error=deprecated-declarations -std=gnu11 -Wno-error=parentheses -Werror
> -Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wmissing-prototypes
> -Wmissing-declarations -Wno-unused
> CMakeFiles/cmTC_2d065.dir/CheckSymbolExists.c.o -o cmTC_2d065 && : >
> /usr/bin/ld: CMakeFiles/cmTC_2d065.dir/CheckSymbolExists.c.o: in function
> `main': > CheckSymbolExists.c:(.text+0x1f): undefined reference to
> `pthread_create' > collect2: error: ld returned 1 exit status > ninja:
> build stopped: subcommand failed. > > File
> /home/dfg/Applications/build-gnucash-3.10/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
> > /* */ > #include > > int main(int argc, char** argv)
> > { > (void)argv; > #ifndef pthread_create > return
> ((int*)(&pthread_create))[argc]; > #else > (void)argc; > return 0; >
> #endif > } > > Determining if compiler accepts -pthread failed with the
> following output: > Change Dir:
> /home/dfg/Applications/build-gnucash-3.10/CMakeFiles/CMakeTmp > > Run
> Build Command:"/usr/bin/ninja" "cmTC_12d58" > [1/2] Building C object
> CMakeFiles/cmTC_12d58.dir/CheckForPthreads.c.o > FAILED:
> CMakeFiles/cmTC_12d58.dir/CheckForPthreads.c.o > /usr/bin/cc
> -Wno-error=deprecated-declarations -std=gnu11 -Wno-error=parentheses -Werror
> -Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wmissing-prototypes
> -Wmissing-declarations -Wno-unused -o
> CMakeFiles/cmTC_12d58.dir/CheckForPthreads.c.o -c
> /usr/share/cmake-3.13/Modules/CheckForPthreads.c >
> /usr/share/cmake-3.13/Modules/CheckForPthreads.c:3:7: error: no previous
> prototype for ‘start_routine’ [-Werror=missing-prototypes] > 3 | void*
> start_routine(void* args) > | ^ > cc1: all warnings being
> treated as errors > ninja: build stopped: subcommand failed. > > >
> Determining if the function pthread_create exists in the pthreads failed with
> the following output: > Change Dir:
> /home/dfg/Applications/build-gnucash-3.10/CMakeFiles/CMakeTmp > > Run
> Build Command:"/usr/bin/ninja" "cmTC_59318" > [1/2] Building C object
> CMakeFiles/cmTC_59318.dir/CheckFunctionExists.c.o > [2/2] Linking C
> executable cmTC_59318 > FAILED: cmTC_59318 > : && /usr/bin/cc
> -Wno-error=deprecated-declarations -std=gnu11 -Wno-error=parentheses -Werror
> -Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wmissing-prototypes
> -Wmissing-declarations -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create
> CMakeFiles/cmTC_59318.dir/CheckFunctionExists.c.o -o cmTC_59318 -lpthreads
> && : > /usr/bin/ld: cannot find -lpthreads > collect2: error: ld
> returned 1 exit status > ninja: build stopped: subcommand failed. > The
> linker can't find libofx, pthreads.h, and libpthreads, respectively. That
> means either that you've tried to
Re: [GNC] Working with dates in Postgresql DB
Hi John! You are here finally! Waiting for you all the day :) All my data I have entered inside Gnucash 3.7,Ubuntu. No imports! Scheduled are ok! Just simple invoices inside the program! The SQL type conversions inside Postgres give better results with 22:00 but 21:00 show the same date again even in April - summer time where is for example 2018-06-04 21:00:00+03. 22:00+02 is 00:00 of the next day, 21:00+03 (summer time) is 00:00 of the next day but conversion does not work... So, maybe you could try this SQL to check your records and revise the procedure which posts the data to DB? Thank you, Dimon. > > On Apr 29, 2020 at 19:50, mailto:jra...@ceridwen.us)> wrote: > > > > > On Apr 29, 2020, at 2:18 AM, finf...@gmail.com wrote: > > Dear John, > > > Thank you for your response. > > > I have collected some > statistics from my DB. > > My DB has 1724 records - transactions. > > > This is my SQL query, it is pretty simple and shows all the combinations of > times in posted_date timestamps in transactions table, number of repetitions > for that time value, min enter_date, max enter_date: > > SELECT > > t.post_date::TIME as "POST TIME", > COUNT(t.post_date::TIME) as "REPS", > > min(t.enter_date) as "MIN ENTER DATE", > max(t.enter_date) as "MAX ENTER > DATE" > FROM transactions t > GROUP BY t.post_date::TIME > ORDER BY > t.post_date::TIME > > Here are the results: > > > > POST > TIME REPS MIN ENTER DATE MAX ENTER DATE > > "00:00:00" 18 "2020-01-26 > 18:07:14" "2020-01-28 19:11:07" > "10:59:00" 1177 "2019-12-23 17:55:29" > "2020-04-23 11:24:24" > "21:00:00" 251 "2020-01-08 17:43:54" "2020-04-23 > 10:36:33" > "22:00 :00" 256 "2020-01-08 17:06:59" "2020-04-23 11:24:08" > "23:00:00" 22 "2020-01-27 19:16:04" "2020-01-28 19:39:49" > > > > I live in Cyprus, here is UTC +2 and summer time UTC +3, as I know. > > I started to study Gnucash in December 2019 and have entered my data of 2016-2020. > > I never changed my place and time zone in the period of working with Gnucash. > > > 1. Most of the records have time in date_posted 10:59:00 for all the period of data entering. > > 2. Only 2 days of entering have the results of 00:00:00 - 18 records. > > 3. Only 2 days of entering have the results of 23:00:00 - 22 records. > > 4. 21:00:00 and 22:00:00 - 500+ records - 30% of transactions for all the period of data entering. > > > Can you please explain that? > > Why I have so many different time stamps? When and why the system decides to write time different from 10:59:00? > > I understand that the system writes real ENTERING date and time and it is reas onable to use the time zone somehow. > > When I POST the document with exact date in it I suppose to see this POST DATE the same wherever in Cyprus or UK or USA. But entering the same date I can have 5 different results. How it works and what is the reason - I have no idea... > > Maybe you can give some examples and the algorithm to convert these dates? Where else I have to convert dates? As those are all posted dates you've found a bug or two as posted date should always have a 10:59:00 timestamp. The 21:00 and 22:00 times are clearly midnight local, and which one is used *should* be determined by whether DST is in effect for the posted date in your locale. It seems that 40 transactions somehow used UK time instead of Cypress time. Did you enter all of the transactions from the GnuCash UI or did you import some of them? If you imported some is there any way to tell which were imported (and from where and by what method), perhaps by the accounts their splits are in or because you still have some of the import files? Were any of them created by scheduled transactions? Regards, John Ralls > > ___ 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?
It is a good idea to automatically split (in settings options) all the accounts receivable and accounts payable by customers and vendors having separate accounts for the reports usable by the owner and auditors! > > On Apr 29, 2020 at 21:28, mailto:d...@davidwhiting.me.uk)> > 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. I've compared the XML structure of one of these accounts with > another simple asset account and they are the same except for the > , i.e.: RECEIVABLE versus > ASSET I've tried editing this (on a copy) and simply > changing RECEIVABLE to ASSET seems to work when I re-open the file. Once this > is done I used gnucash to move the account to the correct place in the > accounts hierarchy and all seemed well. Before I do this to all instances in my working file are there any potential adverse consequences that doing this could cause that I am not aware of? Thanks. David -- 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. > > ___ 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
I also unzipped GNUCASH file to check the date format and values inside - it is the same timestamp as in Postgres > > On Apr 30, 2020 at 19:44, mailto:finf...@gmail.com)> wrote: > > > > Hi John, The result is: 22:00:00 253 00:00:00 18 21:00:00 250 23:00:00 22 So > wrong dates are only when I use invoices. On 29/04/2020 23:56, John Ralls > wrote: > Please remember to copy the list on all replies. > > I take it > that that means that you do in fact use the business invoice features. Let's > see if that's the source of the problem. Run this query: > > select > t.post_date::TIME count(t.post_date::TIME) from transactions as t inner join > invoices as i on i.post_txn = t.guid group by t.post_date::TIME; > > > Regards, > John Ralls > > >> On Apr 29, 2020, at 1:41 PM, Finfort > wrote: >> >> But the program use business features > like entering invoices or bills. >> And we have this mess. >> How we can > manage that? >> >> >> >>> On Apr 29, 2020 at 23:23, > wrote: >>> >>> Dimon, >>> >>> I'm in Silicon Valley, so 10 hours > behind you. >>> >>> By "simple invoices" do you mean that some of the > transactions are created using business invoices? >>> >>> My book goes back to 1993 and entry_dates begin in 2001. We changed the transaction time from local midnight in early 2011 so `select distinct time(post_date) from transactions;` returns >>> 10:59:00 >>> 07:00:00 >>> >>> If I say instead `select distinct time(post_date) from transactions where post_date > '2011-01-01';` I just get 10:59:00. >>> >>> But I don't use the business features, so if that's the problem my book won't show it. >>> >>> Regards, >>> John Ralls >>> >>>> On Apr 29, 2020, at 10:13 AM, Finfortwrote: >>>> >>>> Hi John! >>>> You are here finally! >>>> Waiting for you all the day :) >>>> >>>> All my data I have entered inside Gnucash 3.7, Ubuntu. No imports! Scheduled are ok! >>>> Just simple invoices inside the program! >>>> The SQL type conversions inside Postgres give better results with 22:00 but 21:00 show the same date again even in April - summer time wher e is for example 2018-06-04 21:00:00+03. >>>> 22:00+02 is 00:00 of the next day, 21:00+03 (summer time) is 00:00 of the next day but conversion does not work... >>>> So, maybe you could try this SQL to check your records and revise the procedure which posts the data to DB? >>>> >>>> Thank you, >>>> Dimon. >>>> >>>> >>>> >>>> >>>> >>>>> On Apr 29, 2020 at 19:50, wrote: >>>>> >>>>>> On Apr 29, 2020, at 2:18 AM, finf...@gmail.com wrote: >>>>>> >>>>>> Dear John, >>>>>> >>>>>> Thank you for your response. >>>>>> >>>>>> >>>>>> I have collected some statistics from my DB. >>>>>> >>>>>> My DB has 1724 records - transactions. >>>>>> >>>>>> This is my SQL query, it is pretty simple and shows all the combinations of times in posted_date timestamps in transactions table, number of repetitions for that time value, min enter_date, max enter_date: >>>>>> >>>>>> SELECT >>>>>> t.post_date::TIME as "POST TIME", >>>>>> COUNT(t.post_ date::TIME) as "REPS", >>>>>> min(t.enter_date) as "MIN ENTER DATE", >>>>>> max(t.enter_date) as "MAX ENTER DATE" >>>>>> FROM transactions t >>>>>> GROUP BY t.post_date::TIME >>>>>> ORDER BY t.post_date::TIME >>>>>> >>>>>> Here are the results: >>>>>> >>>>>> >>>>>> >>>>>> POST TIME REPS MIN ENTER DATE MAX ENTER DATE >>>>>> >>>>>> "00:00:00" 18 "2020-01-26 18:07:14" "2020-01-28 19:11:07" >>>>>> "10:59:00" 1177 "2019-12-23 17:55:29" "2020-04-23 11:24:24" >>>>>&g
Re: [GNC] Working with dates in Postgresql DB
Also I tried to unpost and post again. No changes. > > On Apr 30, 2020 at 19:44, mailto:finf...@gmail.com)> wrote: > > > > Hi John, The result is: 22:00:00 253 00:00:00 18 21:00:00 250 23:00:00 22 So > wrong dates are only when I use invoices. On 29/04/2020 23:56, John Ralls > wrote: > Please remember to copy the list on all replies. > > I take it > that that means that you do in fact use the business invoice features. Let's > see if that's the source of the problem. Run this query: > > select > t.post_date::TIME count(t.post_date::TIME) from transactions as t inner join > invoices as i on i.post_txn = t.guid group by t.post_date::TIME; > > > Regards, > John Ralls > > >> On Apr 29, 2020, at 1:41 PM, Finfort > wrote: >> >> But the program use business features > like entering invoices or bills. >> And we have this mess. >> How we can > manage that? >> >> >> >>> On Apr 29, 2020 at 23:23, > wrote: >>> >>> Dimon, >>> >>> I'm in Silicon Valley, so 10 hours > behind you. >>> >>> By "simple invoices" do you mean that some of the > transactions are created using business invoices? >>> >>> My book goes back to 1993 and entry_dates begin in 2001. We changed the transaction time from local midnight in early 2011 so `select distinct time(post_date) from transactions;` returns >>> 10:59:00 >>> 07:00:00 >>> >>> If I say instead `select distinct time(post_date) from transactions where post_date > '2011-01-01';` I just get 10:59:00. >>> >>> But I don't use the business features, so if that's the problem my book won't show it. >>> >>> Regards, >>> John Ralls >>> >>>> On Apr 29, 2020, at 10:13 AM, Finfortwrote: >>>> >>>> Hi John! >>>> You are here finally! >>>> Waiting for you all the day :) >>>> >>>> All my data I have entered inside Gnucash 3.7, Ubuntu. No imports! Scheduled are ok! >>>> Just simple invoices inside the program! >>>> The SQL type conversions inside Postgres give better results with 22:00 but 21:00 show the same date again even in April - summer time wher e is for example 2018-06-04 21:00:00+03. >>>> 22:00+02 is 00:00 of the next day, 21:00+03 (summer time) is 00:00 of the next day but conversion does not work... >>>> So, maybe you could try this SQL to check your records and revise the procedure which posts the data to DB? >>>> >>>> Thank you, >>>> Dimon. >>>> >>>> >>>> >>>> >>>> >>>>> On Apr 29, 2020 at 19:50, wrote: >>>>> >>>>>> On Apr 29, 2020, at 2:18 AM, finf...@gmail.com wrote: >>>>>> >>>>>> Dear John, >>>>>> >>>>>> Thank you for your response. >>>>>> >>>>>> >>>>>> I have collected some statistics from my DB. >>>>>> >>>>>> My DB has 1724 records - transactions. >>>>>> >>>>>> This is my SQL query, it is pretty simple and shows all the combinations of times in posted_date timestamps in transactions table, number of repetitions for that time value, min enter_date, max enter_date: >>>>>> >>>>>> SELECT >>>>>> t.post_date::TIME as "POST TIME", >>>>>> COUNT(t.post_ date::TIME) as "REPS", >>>>>> min(t.enter_date) as "MIN ENTER DATE", >>>>>> max(t.enter_date) as "MAX ENTER DATE" >>>>>> FROM transactions t >>>>>> GROUP BY t.post_date::TIME >>>>>> ORDER BY t.post_date::TIME >>>>>> >>>>>> Here are the results: >>>>>> >>>>>> >>>>>> >>>>>> POST TIME REPS MIN ENTER DATE MAX ENTER DATE >>>>>> >>>>>> "00:00:00" 18 "2020-01-26 18:07:14" "2020-01-28 19:11:07" >>>>>> "10:59:00" 1177 "2019-12-23 17:55:29" "2020-04-23 11:24:24" >>>>>> "21:00:00" 251 "2020-01-08 17:43:54" &q
Re: [GNC] Working with dates in Postgresql DB
How can I help? I can send you my gnucash file if it helps to find all the bugs. And how can I change now my wrong dates in transactions? > > On Apr 30, 2020 at 20:41, mailto:jra...@ceridwen.us)> wrote: > > > > Yeah, it's definitely a bug. I easily found the wrong code and I'll fix it > for 3.903 and 3.11. The query actually accounts for only 543 of the 547 wrong > times, so there's another error somewhere else. Regards, John Ralls > On > Apr 30, 2020, at 10:27 AM, Finfortwrote: > > Also > I tried to unpost and post again. No changes. > > > >> On Apr 30, > 2020 at 19:44,wrote: >> >> Hi John, >> >> The result is: > >> >> 22:00:00 253 >> >> 00:00:00 18 >> >> 21:00:00 250 >> >> > 23:00:00 22 >> >> So wrong dates are only when I use invoices. >> >> > >> >> On 29/04/2020 23:56, John Ralls wrote: >> > Please remember to > copy the list on all replies. >> > >> > I take it that that means > that you do in fact use the business invoice features. Let's see if that's > the source of the problem. Run this query: >> > >> > select > t.post_date::TIME count(t.post_date::TIME) from transactions as t inner join > invoices as i on i.post_txn = t.guid group by t.post_date::TIME; >> > >> > Regards, >> > John Ralls >> > >> > >> >> On Apr 29, 2020, at 1:41 PM, Finfortwrote: >> >> >> >> But the program use business features like entering invoices or bills. >> >> And we have this mess. >> >> How we can manage that? >> >> >> >> >> >> >> >>> On Apr 29, 2020 at 23:23,wrote: >> >>> >> >>> Dimon, >> >>> >> >>> I'm in Silicon Valley, so 10 hours behind you. >> >>> >> >>> By "simple invoices" do you mean that some of the transactions are created using business invoices? >> >>> >> >>> My book goes back to 1993 and entry_dates begin in 2001. We changed the transaction time from local midnight in early 2011 so `select distinct time(post_date) from transactions;` returns >> >>> 10:59:00 >> >>> 07:00:00 >> >>> >> >>> If I say instead `select distinct time(post_date) from transaction s where post_date > '2011-01-01';` I just get 10:59:00. >> >>> >> >>> But I don't use the business features, so if that's the problem my book won't show it. >> >>> >> >>> Regards, >> >>> John Ralls >> >>> >> >>>> On Apr 29, 2020, at 10:13 AM, Finfortwrote: >> >>>> >> >>>> Hi John! >> >>>> You are here finally! >> >>>> Waiting for you all the day :) >> >>>> >> >>>> All my data I have entered inside Gnucash 3.7, Ubuntu. No imports! Scheduled are ok! >> >>>> Just simple invoices inside the program! >> >>>> The SQL type conversions inside Postgres give better results with 22:00 but 21:00 show the same date again even in April - summer time where is for example 2018-06-04 21:00:00+03. >> >>>> 22:00+02 is 00:00 of the next day, 21:00+03 (summer time) is 00:00 of the next day but conversion does not work... >> >>>> So, maybe you could try this SQL to check your records and revise the procedure which posts the data to DB? >> >>>> >> >>>> Thank you, >> >>>> Dimon. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> On Apr 29, 2020 at 19:50,wrote: >> >>>>> >> >>>>>> On Apr 29, 2020, at 2:18 AM, finf...@gmail.com wrote: >> >>>>>> >> >>>>>> Dear John, >> >>>>>> >> >>>>>> Thank you for your response. >> >>>>>> >> >>>>>> >> >>>>>> I have collected some statistics from my DB. >
Re: [GNC] Working with dates in Postgresql DB
If post_date is 2017-12-31 22:00 or 23:00, it means (sometimes?) the real date is 2018-01-01. At least in cases where I manually checked the invoices. Setting all times to 10:59:00 will give wrong dates in the program. Now they are displayed correctly in the program somehow... > > On Apr 30, 2020 at 20:59, mailto:jra...@ceridwen.us)> wrote: > > > > I don't think that's necessary. To fix the wrong times just do an update > query, something like update transactions set post_date::TIME = 10:59:00 > where post_date::TIME != 10:59:00; I don't know Postgresql's date-time > functions well enough to know if that syntax works, you might have to adjust > it a bit. You might create a table with a DATETIME column and put a couple of > rows in it to test against while you tweak. Make sure that GnuCash isn't > connected to the database when you run that. Regards, John Ralls > On Apr > 30, 2020, at 10:45 AM, Finfortwrote: > > How can I > help? > > I can send you my gnucash file if it helps to find all the > bugs. > > And how can I change now my wrong dates in transactions? > > >> On Apr 30, 2020 at 20:41,wrote: >> >> Yeah, it's > definitely a bug. I easily found the wrong code and I'll fix it for 3.903 and > 3.11. >> >> The query actually accounts for only 543 of the 547 wrong > times, so there's anot her error somewhere else. >> >> Regards, >> John Ralls >> >> >> > On Apr 30, 2020, at 10:27 AM, Finfortwrote: >> > >> > Also I tried to unpost and post again. No changes. >> > >> > >> > >> >> On Apr 30, 2020 at 19:44,wrote: >> >> >> >> Hi John, >> >> >> >> The result is: >> >> >> >> 22:00:00 253 >> >> >> >> 00:00:00 18 >> >> >> >> 21:00:00 250 >> >> >> >> 23:00:00 22 >> >> >> >> So wrong dates are only when I use invoices. >> >> >> >> >> >> >> >> On 29/04/2020 23:56, John Ralls wrote: >> >> > Please remember to copy the list on all replies. >> >> > >> >> > I take it that that means that you do in fact use the business invoice features. Let's see if that's the source of the problem. Run this query: >> >> > >> >> > select t.post_date::TIME count(t.post_date::TIME) from transactions as t inner join invoices as i o n i.post_txn = t.guid group by t.post_date::TIME; >> >> > >> >> > Regards, >> >> > John Ralls >> >> > >> >> > >> >> >> On Apr 29, 2020, at 1:41 PM, Finfortwrote: >> >> >> >> >> >> But the program use business features like entering invoices or bills. >> >> >> And we have this mess. >> >> >> How we can manage that? >> >> >> >> >> >> >> >> >> >> >> >>> On Apr 29, 2020 at 23:23,wrote: >> >> >>> >> >> >>> Dimon, >> >> >>> >> >> >>> I'm in Silicon Valley, so 10 hours behind you. >> >> >>> >> >> >>> By "simple invoices" do you mean that some of the transactions are created using business invoices? >> >> >>> >> >> >>> My book goes back to 1993 and entry_dates begin in 2001. We changed the transaction time from local midnight in early 2011 so `select distinct time(post_date) from transactions;` returns >> >> >>> 10:59 :00 >> >> >>> 07:00:00 >> >> >>> >> >> >>> If I say instead `select distinct time(post_date) from transactions where post_date > '2011-01-01';` I just get 10:59:00. >> >> >>> >> >> >>> But I don't use the business features, so if that's the problem my book won't show it. >> >> >>> >> >> >>> Regards, >> >> >>> John Ralls >> >> >>> >> >> >&g
Re: [GNC] Working with dates in Postgresql DB
John, I have found lost 4 transactions, they are from invoices but not connected with invoices. Found using your SQL with left outer join and ordering by invoices.date_posted. They have Null in invoices columns. They have vendor names In transactions.description... Found! All of them are transactions with splits “Lot link”, “offset between documents: Bill... Credit note ”! > > On Apr 30, 2020 at 22:19, mailto:jra...@ceridwen.us)> wrote: > > > > 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 always, since > you're in a time zone east of the prime meridian. So you also want to > increment the day on those. I think it would be safest to do it in two > queries, the first one being >> >> update transactions post_date = > post_date + interval '1 day' where post_date::TIME != '10:59:00'; >> >> > and the second to update the time as before. >> >> Regards, >> John > Ralls >> >> >>> On Apr 30, 2020, at 11:07 AM, Finfort > wrote: >>> >>> If post_date is 2017-12-31 22:00 or > 23:00, it means (sometimes?) the real date is 2018-01-01. At least in cases > where I manually checked the invoices. >>> Setting all times to 10:59:00 > will give wrong dates in the program. >>> Now they are displayed correctly > in the program somehow... >>> >>> >>> >>>> On Apr 30, 2020 at 20:59, > wrote: >>>> >>>> I don't think that's necessary. >>>> > >>>> To fix the wrong times just do an update query, something like >>>> > >>>> update transactions set post_date::TIME = 10:59:00 where > post_date::TIME != 10:59:00; >>>> >>>> I don't know Postgresql's > date-time functions well enough to know if that syntax works, you might have > to adjust it a bit. You might create a table with a DATETIME column and put a > couple of rows in it to test against while you tweak. Make sure that GnuCash > isn't connected to the database when you run that. >>>> >>>> Regards, > >>>> John Ralls >>>> >>>> >>>>> On Apr 30, 2020, at 10:45 AM, Finfort > wrote: >>>>> How can I help? >>>>> I can send you my > gnucash file if it helps to find all the bugs. >>>>> And how can I change > now my wrong dates in transactions? >>>>> >>>>>> On Apr 30, 2020 at > 20:41,wrote: >>>>>> Yeah, it's definitely a bug. I easily > found the wrong code and I'll fix it for 3.903 and 3.11. >>>>>> The query > actually accounts for only 543 of the 547 wrong times, so there's another > error somewhere else. >>>>>> Regards, >>>>
Re: [GNC] Working with dates in Postgresql DB
Sorry, I have used a wrong example with 2017-12-31 21:00:00, should be 22:00:00+02 - not summer time. My SQL conversion of that gives 2018-01-01 Like 22:00 + 2 hours = next day. Cyprus and British territories here have the same time. > > On Apr 30, 2020 at 23:07, mailto:g...@2realms.com)> wrote: > > > > Curious about this. So is the goal to show all times in UTC on invoices > along with local time? I tend to default most things to UTC (including local > time on computers) and just display in some local time if necessary. If GMT > is available as a time zone, I use that (GMT is a timezone; UTC is not). Last > time I checked, GMT does not change for DST (but some locales might try to > use GMT with DST), and displays the same as UTC. Time zones like Tehran's > also differ by 30 minutes, not 60, from adjacent time zones. I think DST is > silly, but a fourth of the planet does not, so their call in their countries. > Cyprus *might* be a special case, but probably not. My assumption is that the > entire Island is in the same time zone, but I don't know what you would get > if you pinged a time server in Akrotiri or Dhekelia (British Overseas > Territories), which seems to be GMT +3 (during DST). Moscow, Ankara, Sudan, > Hungary, and quite a few others are not EEST, but rather UTC +3/GMT +3, which > results in the same time. Postgres does have a somewhat confusing way of handling timestamp (timestamp without timezone) versus timestamptz (timestamp with time zone): https://dba.stackexchange.com/questions/2796/how-do-i-get-the-current-unix-timestamp-from-postgresql That applies when doing conversions to and from unix time; not sure if it affects the situation here. Gordon On Thu, Apr 30, 2020 at 2:19 PM John Ralls wrote: > > 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 d ate 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 always, since you're in a time zone east of the prime meridian. So you also want to increment the day on those. I think it would be safest to do it in two queries, the first one being > >> > >> update transactions post_date = post_date + interval '1 day' where post_date::TIME != '10:59:00'; > >> > >> and the second to update the time as before. > >> > >> Regards, > >> John Ralls > >> > >> > >>> On Apr 30, 2020, at 11:07 AM, Finfortwrote: > >>> > >>> If post_date is 2017-12-31 22:00 or 23:00, it means (sometimes?) the real date is 2018-01-01. At least in cases where I manually checked the invoices. > >>> Setting all times to 10:59:00 will give wrong dates in the program. > >>> Now they are displayed correctly in the program some how... > >>> > >>> > >>> > >
Re: [GNC] Working with dates in Postgresql DB
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 timest
Re: [GNC] XML vs SQL data integrity question
I use Ubuntu with Postgresql, saving sometimes to XML. Had a lot of troubles in Windows with XML. > > On May 7, 2020 at 19:21, mailto:rollenwi...@fastmail.net)> > wrote: > > > > Sounds like you have a couple of issues happening there. I have no > experience with Windows, but I've used the postgres backend in linux for many > years without issue. I also periodically save to the XML format as a backup. > -Greg On Thu, 2020-05-07 at 00:07 -0500, Jeff wrote: > This has probably > been discussed here before but; I'm going ask > anyway. > Which do most > people find more reliable with GNC, SQL or the default > XML? And are there > any features I would lose other than the > rollback > ability with SQL? > > > I'm getting tired of having to track down account and report issues > > every time Windoze 10 hiccups. I use the default XML, > uncompressed. > > One set of books has been corrupted several times, I'm assuming when > > Windoze just simply kills the GNC program out of the blue. I have > another > set of books for a business that so far, knock on wood, the > only problem > is sometimes various buttons have to be selected > multiple > times to > work then all of the windows open in GNC blur while > processing > then go back to normal display. > > My computers are all networked and dual boot Windoze and Ubuntu, so > I > would need SQL on both sides if I switch over. I'm leaning towards > PostgreSQL (pro's, con's? Suggestions?). > ___ 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] Wrong running balances in reports
But this is wrong and should be recalculated when changing sort order, isn't it? > > On May 27, 2020 at 17:39, mailto:de...@ihtfp.com)> wrote: > > > > Hi, "finf...@gmail.com"writes: > Appears in reports > when you sorting by date and you have 2 > transactions of the same date. > > > Needs recalculation of running balance. > > Example of General > Ledger report: > > VAT Output Dr Cr Running Balance > > 31/12/19 O.. > LTD €25,080.00-€212,124.82 > > 31/12/19 R.. GMBH €2,926.00-€187,044.82 > > (should be 215050.82) > > Total For VAT Output €28,006.00 > > In > this example rows should stay vice versa, like in the editable form > to > have correct running balance. > > So the form has recalculation of > running balance, the report does not have. If you change the sort-order in > the register you will also notice the balance is "off" -- the balance is > computed based on the default sort order and displayed in whatever view you > have. In other words, the balance is ONLY valid in the default sort order, > not any other sort order. This is true in reports as well as the register. > > 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.
[GNC] Fwd: Wrong running balances in reports
Begin forwarded message: > > From: Finfort mailto:finf...@gmail.com)> > Date: May 28, 2020 at 09:13 > To: David Carlson (mailto:david.carlson@gmail.com)> > Subject: Re: [GNC] Wrong running balances in reports > > > > > > If it is out of sequence - it shows wrong values after some transactions, > including the end of the day (in my example). > > Who needs running balance like that? > > > > > > > > > > > On May 28, 2020 at 02:51, > (mailto:david.carlson@gmail.com)> wrote: > > > > > > > > > > I forgot the other point I intended to make. > > > > > > > > GnuCash does not necessarily calculate intra-day balances correctly.It > > is only correct at the end of the day.Gnucash may sort same day > > transactions differently than you or I want it to. > > > > > > > > > > On Wed, May 27, 2020 at 6:44 PM David Carlson > (mailto:david.carlson@gmail.com)> wrote: > > > > > > > > > > > IIRC, in some views the running total is not shown at all when it is not > > > in sort order.In other views it is shown out of sequence, but it is > > > correct if theview including the running totals is re-sorted to the > > > 'correct' sequence.Thus it is not actually wrong, it is just out of > > > sequence. > > > > > > > > > > > > That is my opinion. > > > > > > > > > > > > On Wed, May 27, 2020 at 3:33 PM Finfort > > (mailto:finf...@gmail.com)> wrote: > > > > > > > > > > > > > > > > > > > But this is wrong and should be recalculated when changing sort > > > > order, isn't it? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On May 27, 2020 at 17:39, > > > (mailto:de...@ihtfp.com)>wrote: > > > > > > > > > > > > > > > > > > > >Hi, "finf...@gmail.com (mailto:finf...@gmail.com)" > > > > mailto:finf...@gmail.com)>writes: > > > > > Appears in reports when you sorting by date and you have 2 > > > > > transactions of the same date. > >Needs recalculation of > > > > running balance. > >Example of General Ledger report: > > > > > >VAT Output Dr Cr Running Balance > >31/12/19 > > > > O.. LTD €25,080.00-€212,124.82 > >31/12/19 R.. GMBH > > > > €2,926.00-€187,044.82 >(should be 215050.82) > > > > > > Total For VAT Output €28,006.00 > >In this example rows > > > > should stay vice versa, like in the editable form >to have > > > > correct running balance. > >So the form has recalculation > > > > of running balance, the report does not have. If you change the > > > > sort-order in the register you will also notice the balance is "off" -- > > > > the balance is computed based on the default sort order and displayed > > > > in whatever view you have. In other words, the balance is ONLY valid in > > > > the default sort order, not any other sort order. This is true in > > > > reports as well as the register. >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 (mailto:de...@ihtfp.com) www.ihtfp.com > > > > (http://www.ihtfp.com) Computer and Internet Security Consultant > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > gnucash-user mailing list > > > > gnucash-user@gnucash.org (mailto: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 Carlson > > > > > > > -- > > > > > > David Carlson > > ___ 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] Fwd: Wrong running balances in reports
Yes I understand. And I have to open this in something like Excel and recalculate it. What is the problem to do this in GNC after changing of sort order? > > On May 28, 2020 at 10:28, (mailto:david.carlson@gmail.com)> wrote: > > > > Your example had two transactions for the same day.If they are not sorted > in the default sort order, the end-of-day running balance is not the last > balance displayed. > > > > On Thu, May 28, 2020 at 1:16 AM Finfort (mailto:finf...@gmail.com)> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Begin forwarded message: > > > > > > > > > > From:Finfort mailto:finf...@gmail.com) > > (mailto:finf...@gmail.com)> > > > Date:May 28, 2020 at 09:13 > > > To:David Carlson > (mailto:david.carlson@gmail.com) (mailto:david.carlson@gmail.com)> > > > Subject: Re: [GNC] Wrong running balances in reports > > > > > > > > > > > > > > > > > >If it is out of sequence - it shows wrong values after some > > transactions, including the end of the day (in my example). > > > > > > Who needs running balance like that? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On May 28, 2020 at 02:51, > (mailto:david.carlson@gmail.com)>wrote: > > > > > > > > > > > > > > > > > > > > I forgot the other point I intended to make. > > > > > > > > > > > > > > > > GnuCash does not necessarily calculate intra-day balances > > correctly.It is only correct at the end of the day.Gnucash > > may sort same day transactions differently than you or I want it to. > > > > > > > > > > > > > > > > > > > > On Wed, May 27, 2020 at 6:44 PM David Carlson > > mailto:david.carlson@gmail.com) > > (mailto:david.carlson@gmail.com)>wrote: > > > > > > > > > > > > > > > > > > > IIRC, in some views the running total is not shown at all when > > it is not in sort order.In other views it is shown out of sequence, > > but it is correct if theview including the running totals is > > re-sorted to the 'correct' sequence.Thus it is not actually wrong, > > it is just out of sequence. > > > > > > > > > > > > > > > > > > > > That is my opinion. > > > > > > > > > > > > > > > > > > > > On Wed, May 27, 2020 at 3:33 PM Finfort > (mailto:finf...@gmail.com) (mailto:finf...@gmail.com)>wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But this is wrong and should be recalculated when > > changing sort order, isn't it? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >On May 27, 2020 at 17:39,> Atkins (mailto:de...@ihtfp.com)>wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi, "finf...@gmail.com > > (mailto:finf...@gmail.com) (mailto:finf...@gmail.com)" > > mailto:finf...@gmail.com) (mailto:finf...@gmail.com)> > > writ
Re: [GNC] Tax tables changing
I say yes, reset the tax tables and I choose the tax table with new name but it shows me the same old tax table name. Is it correct??? > > On Jun 21, 2020 at 20:13, (mailto:adrien.montele...@lusfiber.net)> wrote: > > > > The current terminology is: “Reset Tax Tables to current values?” “Yes, > reset the Tax Tables” “No, keep them as they are” Regards, Adrien > On Jun > 20, 2020 w25d172, at 7:59 AM, Derek Atkinswrote: > > > Hi, > > On Sat, June 20, 2020 6:55 am, finf...@gmail.com wrote: >> I > have renamed some of taxtables and see the same old names in my bills >> > and invoices. >> >> I also see a lot of records with the same taxtable > names in Postgresql >> table "taxtables". >> >> Could some body explain > the logics of this table? What is "parent" in it? > > If you search the > archives I'm sure you'll find I've gone through this in > excruciating > detail in the past. > > In short, Tax Tables get frozen when an invoice > is posted. And future > changes to the Tax Tables introduce a Copy-on-Write > semantic. > > The reasoning is that if you post an invoice in 2018 with a > 2% tax and > then in 2019 that tax changes to 3%, if in 2020 you need to > revisit that > 2018 invoice you want it to display with 2% tax, not 3% tax. > So to solve > this problem the tax tables are frozen on posting. When you > unpost an > invoice with tax-table associations it asks you whether you > want to keep > the taxes or "unfreeze" them (I forget the terminology). > I.e., if you > unposted that 2018 invoice and told it to unfreeze, then it > would change > those taxes from 2% to 3% and the values would change when > you re-posted > the invoice. Sometimes this may be what you want (e.g. to > correct an > error in the tax table), but sometimes it may NOT be what you > want (e.g. > to correct a typing error). > > The "parent" is a pointer > from the frozen tax table to the non-frozen one. > So when the 2018 invoice > is posted, it freezes and when you change it in > 2019 you get a > parent/child relationship between them. > > Hope this helps! > ___ 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.
[GNC] Vendor report beta errors
Debit and Credit totals are wrong - when filtering by period of time it shows these totals for all the period. ___ 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.
[GNC] Invoice/bill post crash
When editing a new invoice and adding the quantity 1.00 and the price 33000.00 I see 1 and 33,00 but the totals are correct. After that and pressing Post the program crashes. Reinstating and installing on another PC does not help. Windows 10 last updated. Gnucash 3.7+ ___ 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.
