Re: [GNC] Scary moment

[R Losey]

As a software engineer with ~40 years, I've learned to remember details...
glad it was helpful.


On Sat, Dec 31, 2022 at 11:51 AM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Not boring. Well detailed, thanks!
>
> It looks like that rules out file-access issues.
>
> Okay, last gasp here:
>
> For safety, I'd make 2 copies for testing.
>
> 1. Update prices via GUI rather than CLI. Check if transactions
> disappear. Exit, reopen, check again. Since you were running the CLI
> update on Linux, perhaps I'd test that first.
>
> 2. On a second copy, do the CLI update again. Check for missing
> transactions. If so, you'd know this is repeatable.
>
> If Both #1 & #2 corrupt data, then the issue is in the price update code.
>
> If just #2, then it is something in gnucash-cli but not the GUI.
>
> As I understand it, gnucash-cli is just a different interface to the
> same code the GUI uses, but since there is not yet clear MVC separation,
> there could be significant differences.
>
> I'm sure someone else is using gnucash-cli for price updates. It is
> curious that no one else has noticed, or is getting, data corruption.
>
> Regards,
> Adrien
>
> On 12/31/22 11:27 AM, R Losey wrote:
> > My data file is stored on a NAS device (with redundant disks). I've been
> > using GnuCash for seven years now, and have always kept it on the NAS and
> > have had no issues like this before.
> >
> > My machines are three separate physical machines (I have an recent iMac,
> a
> > Windows 10 machine, and an older machine that runs Ubuntu). None of these
> > are VMs.
> >
> > I never double-click on a file; I always start the GnuCash GUI and it
> > always loads the last file; I've been doing this for years, and it is the
> > only GnuCash file I have, so I'm absolutely certain that I am using the
> > same file.
> >
> > I've never seen such a thing before, so I'm also very skeptical that the
> > gnucash-cli stock update script would erase register transactions.
> >
> > To recap, here is a timeline {with comments}
> > *Fri*: Did the regular financial data-entry.  After finishing, I realized
> > that I forget to write a couple of checks to charities, so I wrote the
> > checks. {I believe that I also entered this into GnuCash, but it is
> > possible I forgot and would just pick it up next week; this doesn't tally
> > with notes I have in the checkbook and my own memory, but it is certainly
> > possible. If I did enter it at this time, it was on the iMac}
> >
> > later (late Fri or Sat) Ran the gnucash-cli command to update stock
> quotes
> > on Linux - no errors
> >
> > *Mon*: Ran stock quote update {and then felt foolish as I realized the
> > markets were closed Monday.} Discovered that it only fetches current
> data,
> > and should be run daily to get daily quotes.
> >
> > *Tue*: Ran stock quote update (Linux)
> >
> > Wed morning: Thought I'd update the Finance::Quote to 1.54 (I was running
> > 1.52). In case I had problems, I ran an update using 1.52. First update
> > failed because, while I had a C compiler installed (gcc), I did not have
> > make (gmake). Installed make, and the update worked. Ran another stock
> > update command and verified it is using 1.54
> >
> > *Wed afternoon*: Did a preliminary check of where I stand with taxes. Ran
> > my YTD transaction report to get info. Noticed it stopped at the end of
> the
> > previous month. Changed config to end at end of current year. Re-ran
> > report. Started entering in data; noticed that charity checks from Friday
> > were missing. Assumed that I neglected to enter them, so I entered them.
> > Re-ran the report; they are showing up.
> >
> > *Wed evening*: Ran stock update. Modified the gnc-fq-update perl script
> to
> > check for the existence of /usr/bin/make if running on Linux.
> >
> > *Thu night*: ran stock update
> >
> > *Friday morning*. Brought up GnuCash (Windows) to do regular data entry,
> > and noticed that the charity checks are missing again. Wondered if I was
> > somehow on an old data file. Looked at the directory where files are
> > stored; sorted by last modified - no indication of a second file, and the
> > GUI only has my standard file in the MRU list in the "File" Menu. Shut
> down
> > Windows GnuCash; went to iMac, brought up Gnucash - still missing, and
> the
> > automated entry made on the windows machine showed up, so they are
> pointing
> > to the same file. Ran the transaction report, and the data that was there
> > Wed was gone. Troubled, and thought about what could be different.
> Realized
> > that I have been running the stock update program, and decided to not run
> > it. Re-entered the charity checks, used the transaction report to verify
> it
> > was present; double-checked the balance to verify that I hadn't somehow
> > double-entered them. Shut down; back to Windows GnuCash: the checks are
> > there.
> >
> >
> > I've not run the stock update program since Thursday night, and I've not
> > seen anything go missing. I find it hard to be

Re: [GNC] Scary moment

[R Losey]

Your post came though for me, and I answered it.

I only have Perl installed on Linux, so I can only do price updates there.


On Sat, Dec 31, 2022 at 6:57 PM Robert Kesterson 
wrote:

> I don’t know what that content is, but I didn’t knowingly post a binary
> here (which is what that looks like).   Speaking of scary moments…
>
> Anyway what I intended to post was something along the lines of this:
>
> Since the OP mentions using Gnucash both as an application and as a CLI
> utility on multiple machines, is it possible that this is just a case of
> the file being open on more than one machine (or more than one process) at
> once?  If changes were made in one program but another program had the file
> open, it would be fairly easy for the one without the chnages to have
> overwritten the changes made on the other machine (or other process on the
> same machine)?
>
>
> > On Dec 31, 2022, at 3:12 PM, Robert Kesterson 
> wrote:
> >
> >
> TWF5YmUgaXQgaGFzIGJlZW4gYXNrZWQgYWxyZWFkeSwgYnV0IHdpdGggdGhlIGZpbGUgYmVpbmcg.
> ……
> >
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
_
Richard Losey
rlo...@gmail.com
Micah 6:8
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Scary moment

[R Losey]

Well, before, if I ran the GnuCash GUI with it open on another machine, it
tells me that the file is locked. I don't override the lock unless I know
that the machine or GnuCash crashed.  I have caught myself a handful of
times over the last seven years, so it is possible, especially if the
gnucash-cli option doesn't check for the lock file. I'm not sure what would
happen, however, if I did have the file open... with a seven-minute
auto-save, I'd have to really be working hard to run an update before the
autosave kicked in.

On Sat, Dec 31, 2022 at 3:11 PM Robert Kesterson 
wrote:

> Maybe it has been asked already, but with the file being accessed from
> three separate machines, by a gui and by a CLI utility, are you sure it
> wasn’t open on two machine at once?  That would explain everything if one
> machine made the changes, but another machine (which didn’t have the
> changes) saved its copy of the file.
>
> > On Dec 31, 2022, at 11:52 AM, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> >
> > Not boring. Well detailed, thanks!
> >
> > It looks like that rules out file-access issues.
> >
> > Okay, last gasp here:
> >
> > For safety, I'd make 2 copies for testing.
> >
> > 1. Update prices via GUI rather than CLI. Check if transactions
> disappear. Exit, reopen, check again. Since you were running the CLI update
> on Linux, perhaps I'd test that first.
> >
> > 2. On a second copy, do the CLI update again. Check for missing
> transactions. If so, you'd know this is repeatable.
> >
> > If Both #1 & #2 corrupt data, then the issue is in the price update code.
> >
> > If just #2, then it is something in gnucash-cli but not the GUI.
> >
> > As I understand it, gnucash-cli is just a different interface to the
> same code the GUI uses, but since there is not yet clear MVC separation,
> there could be significant differences.
> >
> > I'm sure someone else is using gnucash-cli for price updates. It is
> curious that no one else has noticed, or is getting, data corruption.
> >
> > Regards,
> > Adrien
> >
> >> On 12/31/22 11:27 AM, R Losey wrote:
> >> My data file is stored on a NAS device (with redundant disks). I've been
> >> using GnuCash for seven years now, and have always kept it on the NAS
> and
> >> have had no issues like this before.
> >> My machines are three separate physical machines (I have an recent
> iMac, a
> >> Windows 10 machine, and an older machine that runs Ubuntu). None of
> these
> >> are VMs.
> >> I never double-click on a file; I always start the GnuCash GUI and it
> >> always loads the last file; I've been doing this for years, and it is
> the
> >> only GnuCash file I have, so I'm absolutely certain that I am using the
> >> same file.
> >> I've never seen such a thing before, so I'm also very skeptical that the
> >> gnucash-cli stock update script would erase register transactions.
> >> To recap, here is a timeline {with comments}
> >> *Fri*: Did the regular financial data-entry.  After finishing, I
> realized
> >> that I forget to write a couple of checks to charities, so I wrote the
> >> checks. {I believe that I also entered this into GnuCash, but it is
> >> possible I forgot and would just pick it up next week; this doesn't
> tally
> >> with notes I have in the checkbook and my own memory, but it is
> certainly
> >> possible. If I did enter it at this time, it was on the iMac}
> >> later (late Fri or Sat) Ran the gnucash-cli command to update stock
> quotes
> >> on Linux - no errors
> >> *Mon*: Ran stock quote update {and then felt foolish as I realized the
> >> markets were closed Monday.} Discovered that it only fetches current
> data,
> >> and should be run daily to get daily quotes.
> >> *Tue*: Ran stock quote update (Linux)
> >> Wed morning: Thought I'd update the Finance::Quote to 1.54 (I was
> running
> >> 1.52). In case I had problems, I ran an update using 1.52. First update
> >> failed because, while I had a C compiler installed (gcc), I did not have
> >> make (gmake). Installed make, and the update worked. Ran another stock
> >> update command and verified it is using 1.54
> >> *Wed afternoon*: Did a preliminary check of where I stand with taxes.
> Ran
> >> my YTD transaction report to get info. Noticed it stopped at the end of
> the
> >> previous month. Changed config to end at end of current year. Re-ran
> >> report. Started entering in data; noticed that charity checks from
> Friday
> >> were missing. Assumed that I neglected to enter them, so I entered them.
> >> Re-ran the report; they are showing up.
> >> *Wed evening*: Ran stock update. Modified the gnc-fq-update perl script
> to
> >> check for the existence of /usr/bin/make if running on Linux.
> >> *Thu night*: ran stock update
> >> *Friday morning*. Brought up GnuCash (Windows) to do regular data entry,
> >> and noticed that the charity checks are missing again. Wondered if I was
> >> somehow on an old data file. Looked at the directory where files are
> >> stored; sorted by last modified - no indica

Re: [GNC] Bank account reconciled, will this change screw things up?

[Liz]

On Fri, 30 Dec 2022 23:54:05 +
"Dr. David Kirkby"  wrote:

> I think that I am in a minority here using them. They seem to make
> things more complicated. I just hope that the benefits outweigh the
> complications.
> 
> Dave.

I use them to create invoices and check that I have been paid but not to
pay money out.
Just going back to the data entry error, you typed 'P' and got
'payroll'.
You can make sure that all your accounts have fairly unique first two
letter combinations, so 'Pa' would be Payroll and 'Po' Postage. Then
typing 2 letters should get the correct account, or you may decide to
type three letters as a habit.

Liz 

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] One File, Two Users

[Adrien Monteleone]

On 12/31/22 2:43 PM, Paul Kroitor wrote:

1.  Put the data file in an existing MySQL server in the cloud and allow
the MySQL lockout mechanisms to deal with access conflicts;


No go. At least if you're considering the MySQL backend. GnuCash doesn't 
use it except as a store. It reads the whole thing into RAM just like 
with XML. One day it is hoped to be a true db based app, but that is 
still many moons away.


Therefore, you won't get any lockout benefits from the db format itself. 
(but you should still have GnuCash take out a lockfile when you access 
it from the first machine, just like with XML)


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
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Scary moment

[Adrien Monteleone]

Not sure where you saw that odd string. It didn't appear in your last post.

Binaries would be stripped off anyway.

It must be something with your mail client.

Regards,
Adrien

On 12/31/22 6:56 PM, Robert Kesterson wrote:

I don’t know what that content is, but I didn’t knowingly post a binary here 
(which is what that looks like).   Speaking of scary moments…


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Scary moment

[Robert Kesterson]

I don’t know what that content is, but I didn’t knowingly post a binary here 
(which is what that looks like).   Speaking of scary moments…

Anyway what I intended to post was something along the lines of this:

Since the OP mentions using Gnucash both as an application and as a CLI utility 
on multiple machines, is it possible that this is just a case of the file being 
open on more than one machine (or more than one process) at once?  If changes 
were made in one program but another program had the file open, it would be 
fairly easy for the one without the chnages to have overwritten the changes 
made on the other machine (or other process on the same machine)?


> On Dec 31, 2022, at 3:12 PM, Robert Kesterson  wrote:
> 
> TWF5YmUgaXQgaGFzIGJlZW4gYXNrZWQgYWxyZWFkeSwgYnV0IHdpdGggdGhlIGZpbGUgYmVpbmcg.
>  ……
> 

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] One File, Two Users

[Andreas Hentze]

   Hi Paul,

   I do #2 (using the sqlite file type) successfully. But I use my own
   cloud on a synology NAS disk station (as I want to be sure, that my
   data is mine :-)).
   Therefor I use the sync-client to the local disk and never had a
   Problem with the lockfile.

   Best regards
   Andy

   Gesendet: Samstag, 31. Dezember 2022 um 21:43 Uhr
   Von: "Paul Kroitor" 
   ...
   So I need to find a way to allow two users, in two different cities, to
   access a single set of books, but without an office infrastructure.
   Access
   will be alternating, thus no simultaneous access. Neither user has
   static
   IPs or internet facing servers. So far I have thought of the following
   (unsatisfactory to varying degrees) mechanisms:
   1. Put the data file in an existing MySQL server in the cloud and allow
   the MySQL lockout mechanisms to deal with access conflicts;
   2. Keep an XML file in the cloud and
   a. Use scripts to upload/download and manage lock semaphores (yuck),
   b. Use SMB sharing over the internet (double yuck!); or
   3. Set up a desktop OS in the cloud and allow users to remote desktop
   in.
   None of these are good, but 1) seems better than the others.
   Perhaps there's a way for the app to run in the cloud but the GUIs are
   on
   the remote user machines?
   All ideas welcome, no matter how inane!
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] OFX import date questions

[Phyllis Bruce]

   Hi Simon, the import had the proper transactions but was not matching a
   couple I had manually entered that were outside the default parameters.
I thing I’ve got that sorted now.

   I’m running ver 4.13 of GC in Windows 11.  I upgrade as soon as I know
   one has been distributed.

 On Dec 31, 2022, at 11:54 AM, Simon Roberts
  wrote:

   
   A side thought Phylls, I think your first observation was about some
   transactions that you had imported not showing up?
   If that's the case, what version of GnuCash are you running? I was
   running 3.8, which was the default from the Ubuntu Linux repositories.
   It was indeed failing to import some transactions (because it deemed
   them duplicates, even though they most definitely were not). However,
   after building version 4.13, I no longer see that problem.

   On Sat, Dec 31, 2022 at 6:53 AM Phyllis Bruce <[1]pobruc...@gmail.com>
   wrote:

   Thanks Jean and David,
   My thresholds are prolly set to the defaults.  Another thing I will do
   is filter for "Unreconciled" before I start my reconciliation.  I often
   have some withdrawals that don't occur within two months.  If I know
   they're there, I can change the threshold to look for them.
   Second thought, clearly a preference because we are looking at
   "statements" from the bank.  How might I keep the date issued as part
   of my record?  Where should I enter that since, in the reconciliation
   the date is always changed to date cleared?  Just finished reconciling
   for the month so it will be a while before I can test this.  New year -
   new start

   On Fri, Dec 30, 2022 at 7:25 PM Simon Roberts
   <[2]si...@dancingcloudservices.com> wrote:

 Thank you for the help to this point. I think I've worked out the
 date
 issue (very embarrassing, nothing to do with GC). Now I have a bunch
 more
 questions, but I'll ask them in dedicated threads to minimize
 confusion.
 I did notice that the CSV version of the transaction information
 contains
 two different date columns one called "Posting" and the other
 "Effective",
 but in all my samples so far, they're the same. That had nothing to
 do with
 my stupi^H^H^H^H^H ... er, "problem", but I mention it in case it
 has any
 relevance to anyone looking at this thread years from now. The OFX
 file
 only seems to contain a single date field ("DTPOSTED").
 But yeah, overwhelm induced stupidity on my part, sorry. Next
 question will
 be a bit more real, but many thanks to everyone who was kind enough
 to
 pitch in their ideas.
 On Fri, Dec 30, 2022 at 3:19 PM David Cousens
 <[3]davidcousen...@gmail.com>
 wrote:
 > Simon,
 >
 > The OFX file will be the immediate position in the banks records
 at the
 > time of
 > download. What appears in a statement may be after completion of
 interbank
 > clearances of funds and the dates in the statement may reflect
 when this
 > occurred rather than when the transaction was first received by
 the bank.
 > Clearnce times are generally a lot shorter with electronic
 clearances than
 > they
 > used to be can sometimes be delayed. SInce this is a disagreement
 between
 > OFX
 > records and statement both produced by the bank, they are best
 placed to
 > explain
 > what such discrepancies are and why they occur.
 >
 > David Cousens
 >
 >
 > On Fri, 2022-12-30 at 14:35 -0700, Simon Roberts wrote:
 > > Beginner/refugee from QuickBooks here (more context below if you
 > > care).  I'm working in a scratch file, so I can do stupid things
 while
 > > learning without damaging anything "important".
 > >
 > > I'm working with importing my bank transactions using OFX format
 (though
 > > I've also tinkered with CSV, and am willing to use that if it
 > > solves my problem).
 > >
 > > I imported some transactions using OFX. Several things surprised
 me, but
 > > the one that I think needs resolving first is that the
 transaction dates
 > do
 > > not match the bank statement.
 > >
 > > Earlier I tried the CSV import and saw there were *two* date
 fields
 > > (presumably difference between being received and being acted
 on?
 > >
 > > Can someone tell me what I should do to fix this? Is there a way
 to
 > "tweek"
 > > the OFX import, or do I need to use CSV? Or is this something
 else
 > entirely
 > > that's gone amiss?
 > >
 > > Thanks for any hints,
 > > Cheers,
 > > Simon
 > >
 > > Background in case it's relevant:
 > >
 > > I'm a refugee from Intuit, and very early in my learning
 process.
 > >
 > > I"m not a bookkeeper, I'm a programmer. Conversely, my
 bookkeeper isn't a
 > > software person--she would have continued paying the annual
 ransom t

Re: [GNC] Autofill on import OFX?

[Jean L]

No you don't need to do anything for it to learn, except select the 
account the transaction should be associated with when you import the 
transaction so the matcher can remember that. Of course, that's only if 
you haven't already entered the transaction manually (in which case you 
already selected the accounts involved).


So:
- If your OFX transaction matches an existing transaction you entered 
manually you have nothing to do
- If you're importing an OFX transaction that's "new" (you haven't 
entered it manually) then make sure you select the accounts during the 
import, not afterward. If you select the account afterward the matcher 
does not get a chance to learn the correct association.


J

On 12/31/2022 1:06 PM, Simon Roberts wrote:

Thanks for this Jean, Murugan, that's very helpful (and rather impressive!)

Do I infer that I need to use the " right click on a transaction in the
transaction matching window, you can edit various fields prior to the
transaction being imported" feature so it knows I'm trying to teach it,
rather than editing after the import is complete?

Cheers,
Simon


On Sat, Dec 31, 2022 at 12:15 PM Murugan Muruganandam <
m.muruganan...@hotmail.com> wrote:


Simon

GNUCash learns the transactions matching when you start input, and stores
it for future reference. Same is the case with imported files, you can view
the  import map editor for details.  please note you cannot directly enter
the assocation here, but you can delete any wrong association and allow
GNUCash to relearn.

it takes some time for the system to learn the associations.



Saludos Cordiales


Murugan
--
*From:* gnucash-user  on behalf of Simon Roberts <
si...@dancingcloudservices.com>
*Sent:* Saturday, December 31, 2022 3:20 PM
*To:* Gnucash Users
*Subject:* [GNC] Autofill on import OFX?

Now that I have GC 4.13 and my imported transactions are correctly
recognized and not dumped, I have another question.

If I have a transaction with, for example, a description field of XYZ, and
I start to enter a new transaction with the same description, and then hit
tab, GC auto-fills all the rest of the fields; Transfer, Amount, Memo, etc.
This is great.

However, this behavior doesn't seem to occur with imported transactions.

To be clear, I don't expect (nor want!) it to overwrite transaction
details, but inferring the Transfer field, which is of course not specified
(nor could it be) in the OFX file, would be enormously helpful. Similarly,
copying over the most recent memo field would be good too.

Is there a way to configure this behavior, or does this constitute a
feature request?

Another question, which I think is sufficiently related to be OK to put in
the same message, is that in the system we're migrating away from
(quickbooks--washes mouth with soap and water :) there are "rules" one can
apply. For example, "if the description field of the import contains this
text, then fill out that field with that text". Is there such a mechanism
in GnuCash, and if so, what's it called (so I can read about it in
documentation)?

Thanks for all your ongoing help everyone, it's very reassuring that
there's a community as active and willing to help when making a transition
as critical as this!

Cheers,
Simon

--
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.




___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] One File, Two Users

[Glenn Serre]

Good afternoon Paul,

Inline below...

On Sat, Dec 31, 2022 at 12:44 PM Paul Kroitor  wrote:
[...]
> So I need to find a way to allow two users, in two different cities, to
> access a single set of books, but without an office infrastructure. Access
> will be alternating, thus no simultaneous access. Neither user has static
> IPs or internet facing servers. So far I have thought of the following
> (unsatisfactory to varying degrees) mechanisms:
>
[...]
> Perhaps there's a way for the app to run in the cloud but the GUIs are on
> the remote user machines?
>
[...]

I think you can do this with a linux machine using X and SSH port
forwarding (the -X or -Y option, but see the security warnings in the
man page).
You could probably also use Windows remote desktop.

That said, I have never been particularly happy with remote desktop
usage in recent times, even with fast connections, but it might be
worth a try.   I suspect that developers no longer care much about
minimizing the traffic between the windowing system and the app.

-- Glenn S.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Scary moment

[Robert Kesterson]

Maybe it has been asked already, but with the file being accessed from three 
separate machines, by a gui and by a CLI utility, are you sure it wasn’t open 
on two machine at once?  That would explain everything if one machine made the 
changes, but another machine (which didn’t have the changes) saved its copy of 
the file. 

> On Dec 31, 2022, at 11:52 AM, Adrien Monteleone 
>  wrote:
> 
> Not boring. Well detailed, thanks!
> 
> It looks like that rules out file-access issues.
> 
> Okay, last gasp here:
> 
> For safety, I'd make 2 copies for testing.
> 
> 1. Update prices via GUI rather than CLI. Check if transactions disappear. 
> Exit, reopen, check again. Since you were running the CLI update on Linux, 
> perhaps I'd test that first.
> 
> 2. On a second copy, do the CLI update again. Check for missing transactions. 
> If so, you'd know this is repeatable.
> 
> If Both #1 & #2 corrupt data, then the issue is in the price update code.
> 
> If just #2, then it is something in gnucash-cli but not the GUI.
> 
> As I understand it, gnucash-cli is just a different interface to the same 
> code the GUI uses, but since there is not yet clear MVC separation, there 
> could be significant differences.
> 
> I'm sure someone else is using gnucash-cli for price updates. It is curious 
> that no one else has noticed, or is getting, data corruption.
> 
> Regards,
> Adrien
> 
>> On 12/31/22 11:27 AM, R Losey wrote:
>> My data file is stored on a NAS device (with redundant disks). I've been
>> using GnuCash for seven years now, and have always kept it on the NAS and
>> have had no issues like this before.
>> My machines are three separate physical machines (I have an recent iMac, a
>> Windows 10 machine, and an older machine that runs Ubuntu). None of these
>> are VMs.
>> I never double-click on a file; I always start the GnuCash GUI and it
>> always loads the last file; I've been doing this for years, and it is the
>> only GnuCash file I have, so I'm absolutely certain that I am using the
>> same file.
>> I've never seen such a thing before, so I'm also very skeptical that the
>> gnucash-cli stock update script would erase register transactions.
>> To recap, here is a timeline {with comments}
>> *Fri*: Did the regular financial data-entry.  After finishing, I realized
>> that I forget to write a couple of checks to charities, so I wrote the
>> checks. {I believe that I also entered this into GnuCash, but it is
>> possible I forgot and would just pick it up next week; this doesn't tally
>> with notes I have in the checkbook and my own memory, but it is certainly
>> possible. If I did enter it at this time, it was on the iMac}
>> later (late Fri or Sat) Ran the gnucash-cli command to update stock quotes
>> on Linux - no errors
>> *Mon*: Ran stock quote update {and then felt foolish as I realized the
>> markets were closed Monday.} Discovered that it only fetches current data,
>> and should be run daily to get daily quotes.
>> *Tue*: Ran stock quote update (Linux)
>> Wed morning: Thought I'd update the Finance::Quote to 1.54 (I was running
>> 1.52). In case I had problems, I ran an update using 1.52. First update
>> failed because, while I had a C compiler installed (gcc), I did not have
>> make (gmake). Installed make, and the update worked. Ran another stock
>> update command and verified it is using 1.54
>> *Wed afternoon*: Did a preliminary check of where I stand with taxes. Ran
>> my YTD transaction report to get info. Noticed it stopped at the end of the
>> previous month. Changed config to end at end of current year. Re-ran
>> report. Started entering in data; noticed that charity checks from Friday
>> were missing. Assumed that I neglected to enter them, so I entered them.
>> Re-ran the report; they are showing up.
>> *Wed evening*: Ran stock update. Modified the gnc-fq-update perl script to
>> check for the existence of /usr/bin/make if running on Linux.
>> *Thu night*: ran stock update
>> *Friday morning*. Brought up GnuCash (Windows) to do regular data entry,
>> and noticed that the charity checks are missing again. Wondered if I was
>> somehow on an old data file. Looked at the directory where files are
>> stored; sorted by last modified - no indication of a second file, and the
>> GUI only has my standard file in the MRU list in the "File" Menu. Shut down
>> Windows GnuCash; went to iMac, brought up Gnucash - still missing, and the
>> automated entry made on the windows machine showed up, so they are pointing
>> to the same file. Ran the transaction report, and the data that was there
>> Wed was gone. Troubled, and thought about what could be different. Realized
>> that I have been running the stock update program, and decided to not run
>> it. Re-entered the charity checks, used the transaction report to verify it
>> was present; double-checked the balance to verify that I hadn't somehow
>> double-entered them. Shut down; back to Windows GnuCash: the checks are
>> there.
>> I've not run the stock update pr

Re: [GNC] Autofill on import OFX?

[Simon Roberts]

Thanks for this Jean, Murugan, that's very helpful (and rather impressive!)

Do I infer that I need to use the " right click on a transaction in the
transaction matching window, you can edit various fields prior to the
transaction being imported" feature so it knows I'm trying to teach it,
rather than editing after the import is complete?

Cheers,
Simon


On Sat, Dec 31, 2022 at 12:15 PM Murugan Muruganandam <
m.muruganan...@hotmail.com> wrote:

> Simon
>
> GNUCash learns the transactions matching when you start input, and stores
> it for future reference. Same is the case with imported files, you can view
> the  import map editor for details.  please note you cannot directly enter
> the assocation here, but you can delete any wrong association and allow
> GNUCash to relearn.
>
> it takes some time for the system to learn the associations.
>
>
>
> Saludos Cordiales
>
>
> Murugan
> --
> *From:* gnucash-user  hotmail@gnucash.org> on behalf of Simon Roberts <
> si...@dancingcloudservices.com>
> *Sent:* Saturday, December 31, 2022 3:20 PM
> *To:* Gnucash Users 
> *Subject:* [GNC] Autofill on import OFX?
>
> Now that I have GC 4.13 and my imported transactions are correctly
> recognized and not dumped, I have another question.
>
> If I have a transaction with, for example, a description field of XYZ, and
> I start to enter a new transaction with the same description, and then hit
> tab, GC auto-fills all the rest of the fields; Transfer, Amount, Memo, etc.
> This is great.
>
> However, this behavior doesn't seem to occur with imported transactions.
>
> To be clear, I don't expect (nor want!) it to overwrite transaction
> details, but inferring the Transfer field, which is of course not specified
> (nor could it be) in the OFX file, would be enormously helpful. Similarly,
> copying over the most recent memo field would be good too.
>
> Is there a way to configure this behavior, or does this constitute a
> feature request?
>
> Another question, which I think is sufficiently related to be OK to put in
> the same message, is that in the system we're migrating away from
> (quickbooks--washes mouth with soap and water :) there are "rules" one can
> apply. For example, "if the description field of the import contains this
> text, then fill out that field with that text". Is there such a mechanism
> in GnuCash, and if so, what's it called (so I can read about it in
> documentation)?
>
> Thanks for all your ongoing help everyone, it's very reassuring that
> there's a community as active and willing to help when making a transition
> as critical as this!
>
> Cheers,
> Simon
>
> --
> Simon Roberts
> (303) 249 3613
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Matching error in OFX import

[Simon Roberts]

Good to know, but for 20.04,it gave me 3.8.


On Sat, Dec 31, 2022 at 1:27 PM john  wrote:

>
>
> On Dec 31, 2022, at 8:14 AM, Simon Roberts 
> wrote:
>
> But, I will get back when I'm not using 3.8. It's sad (but clearly nobody
> here is in control of this!) that Ubuntu is packaging such an old version.
>
>
> They're not. You're using Ubuntu 20.04. The current Ubuntu release, 22.10,
> has GnuCash 4.11.
>
> Regards,
> John Ralls
>
>

-- 
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[GNC] One File, Two Users

[Paul Kroitor]

Hi, long time user of GnuCash with various sets of books. Some are currently
run in a quasi-office environment such that users in other cities can VPN
into our LAN and thus open GnuCash books as though they are on a local
server. But this infrastructure is now going away.

 

So I need to find a way to allow two users, in two different cities, to
access a single set of books, but without an office infrastructure. Access
will be alternating, thus no simultaneous access. Neither user has static
IPs or internet facing servers. So far I have thought of the following
(unsatisfactory to varying degrees) mechanisms:

 

1.  Put the data file in an existing MySQL server in the cloud and allow
the MySQL lockout mechanisms to deal with access conflicts;
2.  Keep an XML file in the cloud and

a.  Use scripts to upload/download and manage lock semaphores (yuck),
b.  Use SMB sharing over the internet (double yuck!); or

3.  Set up a desktop OS in the cloud and allow users to remote desktop
in.

 

None of these are good, but 1) seems better than the others.

 

Perhaps there's a way for the app to run in the cloud but the GUIs are on
the remote user machines?

 

All ideas welcome, no matter how inane!

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Matching error in OFX import

[john]

> On Dec 31, 2022, at 8:14 AM, Simon Roberts  
> wrote:
> 
> But, I will get back when I'm not using 3.8. It's sad (but clearly nobody
> here is in control of this!) that Ubuntu is packaging such an old version.

They're not. You're using Ubuntu 20.04. The current Ubuntu release, 22.10, has 
GnuCash 4.11.

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
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] OFX import date questions

[Phyllis Bruce]

Yes, David C- to me, date issued is the date I wrote the check.  By date
cleared, I meant the date on the statement which I assume is the date the
bank cleared the transaction.  I'm also going to take a leap and assume the
OFX and QFX operate the same since the two are on the same line as OFX/QFX
in the import selection panel.  As for keeping the date written, I'll start
using the notes field for that when it's important to me.

I do have a play file but didn't think to use it.  Thanks for the reminder.

On Sat, Dec 31, 2022 at 11:24 AM David Carlson 
wrote:

> Phyllis,
>
> Reconciliation does* not* always change the date to date cleared.  In
> fact, the only date messed with during reconciliation is the reconciliation
> date.  That date is always automatically set to the date used by the
> reconciliation process.  In fact, that date has been the topic of other
> threads in recent months.  The OFX import may or may not change the
> transaction date when the imported transaction date differs from the
> existing matched transaction date depending on whether you choose to use
> the Update feature for that particular transaction.  You may wish to
> re-read the Tutorial regarding how the matching process works.  I am not
> sure even what you mean by 'date issued'  Is that the the date you wrote
> the check?  If I want to keep that date in the record I manually write it
> in the Notes field.
>
> By the way, if you want to test anything in GnuCash, just make a
> disposable and renamed copy of your data file or backup from earlier and
> put it in a folder labelled Test.
>
> On Sat, Dec 31, 2022 at 7:54 AM Phyllis Bruce  wrote:
>
>> Thanks Jean and David,
>> My thresholds are prolly set to the defaults.  Another thing I will do is
>> filter for "Unreconciled" before I start my reconciliation.  I often have
>> some withdrawals that don't occur within two months.  If I know they're
>> there, I can change the threshold to look for them.
>>
>> Second thought, clearly a preference because we are looking at
>> "statements"
>> from the bank.  How might I keep the date issued as part of my record?
>> Where should I enter that since, in the reconciliation the date is always
>> changed to date cleared?  Just finished reconciling for the month so it
>> will be a while before I can test this.  New year - new start
>>
>> On Fri, Dec 30, 2022 at 7:25 PM Simon Roberts <
>> si...@dancingcloudservices.com> wrote:
>>
>> > Thank you for the help to this point. I think I've worked out the date
>> > issue (very embarrassing, nothing to do with GC). Now I have a bunch
>> more
>> > questions, but I'll ask them in dedicated threads to minimize confusion.
>> >
>> > I did notice that the CSV version of the transaction information
>> contains
>> > two different date columns one called "Posting" and the other
>> "Effective",
>> > but in all my samples so far, they're the same. That had nothing to do
>> with
>> > my stupi^H^H^H^H^H ... er, "problem", but I mention it in case it has
>> any
>> > relevance to anyone looking at this thread years from now. The OFX file
>> > only seems to contain a single date field ("DTPOSTED").
>> >
>> > But yeah, overwhelm induced stupidity on my part, sorry. Next question
>> will
>> > be a bit more real, but many thanks to everyone who was kind enough to
>> > pitch in their ideas.
>> >
>> >
>> > On Fri, Dec 30, 2022 at 3:19 PM David Cousens > >
>> > wrote:
>> >
>> > > Simon,
>> > >
>> > > The OFX file will be the immediate position in the banks records at
>> the
>> > > time of
>> > > download. What appears in a statement may be after completion of
>> > interbank
>> > > clearances of funds and the dates in the statement may reflect when
>> this
>> > > occurred rather than when the transaction was first received by the
>> bank.
>> > > Clearnce times are generally a lot shorter with electronic clearances
>> > than
>> > > they
>> > > used to be can sometimes be delayed. SInce this is a disagreement
>> between
>> > > OFX
>> > > records and statement both produced by the bank, they are best placed
>> to
>> > > explain
>> > > what such discrepancies are and why they occur.
>> > >
>> > > David Cousens
>> > >
>> > >
>> > > On Fri, 2022-12-30 at 14:35 -0700, Simon Roberts wrote:
>> > > > Beginner/refugee from QuickBooks here (more context below if you
>> > > > care).  I'm working in a scratch file, so I can do stupid things
>> while
>> > > > learning without damaging anything "important".
>> > > >
>> > > > I'm working with importing my bank transactions using OFX format
>> > (though
>> > > > I've also tinkered with CSV, and am willing to use that if it
>> > > > solves my problem).
>> > > >
>> > > > I imported some transactions using OFX. Several things surprised me,
>> > but
>> > > > the one that I think needs resolving first is that the transaction
>> > dates
>> > > do
>> > > > not match the bank statement.
>> > > >
>> > > > Earlier I tried the CSV import and saw there were *two* date fields
>> > > > (presumably differen

Re: [GNC] Autofill on import OFX?

[Murugan Muruganandam]

Simon

GNUCash learns the transactions matching when you start input, and stores it 
for future reference. Same is the case with imported files, you can view the  
import map editor for details.  please note you cannot directly enter the 
assocation here, but you can delete any wrong association and allow GNUCash to 
relearn.

it takes some time for the system to learn the associations.




Saludos Cordiales


Murugan


From: gnucash-user 
 on behalf of 
Simon Roberts 
Sent: Saturday, December 31, 2022 3:20 PM
To: Gnucash Users 
Subject: [GNC] Autofill on import OFX?

Now that I have GC 4.13 and my imported transactions are correctly
recognized and not dumped, I have another question.

If I have a transaction with, for example, a description field of XYZ, and
I start to enter a new transaction with the same description, and then hit
tab, GC auto-fills all the rest of the fields; Transfer, Amount, Memo, etc.
This is great.

However, this behavior doesn't seem to occur with imported transactions.

To be clear, I don't expect (nor want!) it to overwrite transaction
details, but inferring the Transfer field, which is of course not specified
(nor could it be) in the OFX file, would be enormously helpful. Similarly,
copying over the most recent memo field would be good too.

Is there a way to configure this behavior, or does this constitute a
feature request?

Another question, which I think is sufficiently related to be OK to put in
the same message, is that in the system we're migrating away from
(quickbooks--washes mouth with soap and water :) there are "rules" one can
apply. For example, "if the description field of the import contains this
text, then fill out that field with that text". Is there such a mechanism
in GnuCash, and if so, what's it called (so I can read about it in
documentation)?

Thanks for all your ongoing help everyone, it's very reassuring that
there's a community as active and willing to help when making a transition
as critical as this!

Cheers,
Simon

--
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Autofill on import OFX?

[Jean L]

The transfer will be automatically assigned once you import a few 
transactions. GC is smart in the way it learns from previous imported 
transactions which account a given imported transaction should be 
assigned to. So give it a little time and it'll do the right thing. 
Another thing you may not have noticed: if you right click on a 
transaction in the transaction matching window, you can edit various 
fields prior to the transaction being imported.


There are no "rules", the way you describe them, in GC, as far as I know...

Jean

On 12/31/2022 10:20 AM, Simon Roberts wrote:

Now that I have GC 4.13 and my imported transactions are correctly
recognized and not dumped, I have another question.

If I have a transaction with, for example, a description field of XYZ, and
I start to enter a new transaction with the same description, and then hit
tab, GC auto-fills all the rest of the fields; Transfer, Amount, Memo, etc.
This is great.

However, this behavior doesn't seem to occur with imported transactions.

To be clear, I don't expect (nor want!) it to overwrite transaction
details, but inferring the Transfer field, which is of course not specified
(nor could it be) in the OFX file, would be enormously helpful. Similarly,
copying over the most recent memo field would be good too.

Is there a way to configure this behavior, or does this constitute a
feature request?

Another question, which I think is sufficiently related to be OK to put in
the same message, is that in the system we're migrating away from
(quickbooks--washes mouth with soap and water :) there are "rules" one can
apply. For example, "if the description field of the import contains this
text, then fill out that field with that text". Is there such a mechanism
in GnuCash, and if so, what's it called (so I can read about it in
documentation)?

Thanks for all your ongoing help everyone, it's very reassuring that
there's a community as active and willing to help when making a transition
as critical as this!

Cheers,
Simon


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[GNC] Autofill on import OFX?

[Simon Roberts]

Now that I have GC 4.13 and my imported transactions are correctly
recognized and not dumped, I have another question.

If I have a transaction with, for example, a description field of XYZ, and
I start to enter a new transaction with the same description, and then hit
tab, GC auto-fills all the rest of the fields; Transfer, Amount, Memo, etc.
This is great.

However, this behavior doesn't seem to occur with imported transactions.

To be clear, I don't expect (nor want!) it to overwrite transaction
details, but inferring the Transfer field, which is of course not specified
(nor could it be) in the OFX file, would be enormously helpful. Similarly,
copying over the most recent memo field would be good too.

Is there a way to configure this behavior, or does this constitute a
feature request?

Another question, which I think is sufficiently related to be OK to put in
the same message, is that in the system we're migrating away from
(quickbooks--washes mouth with soap and water :) there are "rules" one can
apply. For example, "if the description field of the import contains this
text, then fill out that field with that text". Is there such a mechanism
in GnuCash, and if so, what's it called (so I can read about it in
documentation)?

Thanks for all your ongoing help everyone, it's very reassuring that
there's a community as active and willing to help when making a transition
as critical as this!

Cheers,
Simon

-- 
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] OFX import date questions

[Simon Roberts]

A side thought Phylls, I think your first observation was about some
transactions that you had imported not showing up?

If that's the case, what version of GnuCash are you running? I was running
3.8, which was the default from the Ubuntu Linux repositories. It was
indeed failing to import some transactions (because it deemed them
duplicates, even though they most definitely were not). However, after
building version 4.13, I no longer see that problem.



On Sat, Dec 31, 2022 at 6:53 AM Phyllis Bruce  wrote:

> Thanks Jean and David,
> My thresholds are prolly set to the defaults.  Another thing I will do is
> filter for "Unreconciled" before I start my reconciliation.  I often have
> some withdrawals that don't occur within two months.  If I know they're
> there, I can change the threshold to look for them.
>
> Second thought, clearly a preference because we are looking at
> "statements" from the bank.  How might I keep the date issued as part of my
> record?  Where should I enter that since, in the reconciliation the date is
> always changed to date cleared?  Just finished reconciling for the month so
> it will be a while before I can test this.  New year - new start
>
> On Fri, Dec 30, 2022 at 7:25 PM Simon Roberts <
> si...@dancingcloudservices.com> wrote:
>
>> Thank you for the help to this point. I think I've worked out the date
>> issue (very embarrassing, nothing to do with GC). Now I have a bunch more
>> questions, but I'll ask them in dedicated threads to minimize confusion.
>>
>> I did notice that the CSV version of the transaction information contains
>> two different date columns one called "Posting" and the other "Effective",
>> but in all my samples so far, they're the same. That had nothing to do
>> with
>> my stupi^H^H^H^H^H ... er, "problem", but I mention it in case it has any
>> relevance to anyone looking at this thread years from now. The OFX file
>> only seems to contain a single date field ("DTPOSTED").
>>
>> But yeah, overwhelm induced stupidity on my part, sorry. Next question
>> will
>> be a bit more real, but many thanks to everyone who was kind enough to
>> pitch in their ideas.
>>
>>
>> On Fri, Dec 30, 2022 at 3:19 PM David Cousens 
>> wrote:
>>
>> > Simon,
>> >
>> > The OFX file will be the immediate position in the banks records at the
>> > time of
>> > download. What appears in a statement may be after completion of
>> interbank
>> > clearances of funds and the dates in the statement may reflect when this
>> > occurred rather than when the transaction was first received by the
>> bank.
>> > Clearnce times are generally a lot shorter with electronic clearances
>> than
>> > they
>> > used to be can sometimes be delayed. SInce this is a disagreement
>> between
>> > OFX
>> > records and statement both produced by the bank, they are best placed to
>> > explain
>> > what such discrepancies are and why they occur.
>> >
>> > David Cousens
>> >
>> >
>> > On Fri, 2022-12-30 at 14:35 -0700, Simon Roberts wrote:
>> > > Beginner/refugee from QuickBooks here (more context below if you
>> > > care).  I'm working in a scratch file, so I can do stupid things while
>> > > learning without damaging anything "important".
>> > >
>> > > I'm working with importing my bank transactions using OFX format
>> (though
>> > > I've also tinkered with CSV, and am willing to use that if it
>> > > solves my problem).
>> > >
>> > > I imported some transactions using OFX. Several things surprised me,
>> but
>> > > the one that I think needs resolving first is that the transaction
>> dates
>> > do
>> > > not match the bank statement.
>> > >
>> > > Earlier I tried the CSV import and saw there were *two* date fields
>> > > (presumably difference between being received and being acted on?
>> > >
>> > > Can someone tell me what I should do to fix this? Is there a way to
>> > "tweek"
>> > > the OFX import, or do I need to use CSV? Or is this something else
>> > entirely
>> > > that's gone amiss?
>> > >
>> > > Thanks for any hints,
>> > > Cheers,
>> > > Simon
>> > >
>> > > Background in case it's relevant:
>> > >
>> > > I'm a refugee from Intuit, and very early in my learning process.
>> > >
>> > > I"m not a bookkeeper, I'm a programmer. Conversely, my bookkeeper
>> isn't a
>> > > software person--she would have continued paying the annual ransom to
>> > > Intuit but I'm sick of their hostage taking. Of course this means I
>> need
>> > to
>> > > do a decent part of the legwork for this transition.
>> > >
>> > > Of course because I'm not a bookkeeper, I don't understand the
>> accounting
>> > > side of this stuff, and likely won't know how to ask/phrase the
>> > questions.
>> > >
>> > > Neither of us are going to be great at searching the documentation
>> since
>> > it
>> > > seems like the terminology is different between GC and QB (and I don't
>> > > really know the terminology anyway)
>> > >
>> > > So, please forgive the idiot question, and if the simple answer to a
>> > > question is RTFM, we're very happy to do 

Re: [GNC] Scary moment

[Adrien Monteleone]

Not boring. Well detailed, thanks!

It looks like that rules out file-access issues.

Okay, last gasp here:

For safety, I'd make 2 copies for testing.

1. Update prices via GUI rather than CLI. Check if transactions 
disappear. Exit, reopen, check again. Since you were running the CLI 
update on Linux, perhaps I'd test that first.


2. On a second copy, do the CLI update again. Check for missing 
transactions. If so, you'd know this is repeatable.


If Both #1 & #2 corrupt data, then the issue is in the price update code.

If just #2, then it is something in gnucash-cli but not the GUI.

As I understand it, gnucash-cli is just a different interface to the 
same code the GUI uses, but since there is not yet clear MVC separation, 
there could be significant differences.


I'm sure someone else is using gnucash-cli for price updates. It is 
curious that no one else has noticed, or is getting, data corruption.


Regards,
Adrien

On 12/31/22 11:27 AM, R Losey wrote:

My data file is stored on a NAS device (with redundant disks). I've been
using GnuCash for seven years now, and have always kept it on the NAS and
have had no issues like this before.

My machines are three separate physical machines (I have an recent iMac, a
Windows 10 machine, and an older machine that runs Ubuntu). None of these
are VMs.

I never double-click on a file; I always start the GnuCash GUI and it
always loads the last file; I've been doing this for years, and it is the
only GnuCash file I have, so I'm absolutely certain that I am using the
same file.

I've never seen such a thing before, so I'm also very skeptical that the
gnucash-cli stock update script would erase register transactions.

To recap, here is a timeline {with comments}
*Fri*: Did the regular financial data-entry.  After finishing, I realized
that I forget to write a couple of checks to charities, so I wrote the
checks. {I believe that I also entered this into GnuCash, but it is
possible I forgot and would just pick it up next week; this doesn't tally
with notes I have in the checkbook and my own memory, but it is certainly
possible. If I did enter it at this time, it was on the iMac}

later (late Fri or Sat) Ran the gnucash-cli command to update stock quotes
on Linux - no errors

*Mon*: Ran stock quote update {and then felt foolish as I realized the
markets were closed Monday.} Discovered that it only fetches current data,
and should be run daily to get daily quotes.

*Tue*: Ran stock quote update (Linux)

Wed morning: Thought I'd update the Finance::Quote to 1.54 (I was running
1.52). In case I had problems, I ran an update using 1.52. First update
failed because, while I had a C compiler installed (gcc), I did not have
make (gmake). Installed make, and the update worked. Ran another stock
update command and verified it is using 1.54

*Wed afternoon*: Did a preliminary check of where I stand with taxes. Ran
my YTD transaction report to get info. Noticed it stopped at the end of the
previous month. Changed config to end at end of current year. Re-ran
report. Started entering in data; noticed that charity checks from Friday
were missing. Assumed that I neglected to enter them, so I entered them.
Re-ran the report; they are showing up.

*Wed evening*: Ran stock update. Modified the gnc-fq-update perl script to
check for the existence of /usr/bin/make if running on Linux.

*Thu night*: ran stock update

*Friday morning*. Brought up GnuCash (Windows) to do regular data entry,
and noticed that the charity checks are missing again. Wondered if I was
somehow on an old data file. Looked at the directory where files are
stored; sorted by last modified - no indication of a second file, and the
GUI only has my standard file in the MRU list in the "File" Menu. Shut down
Windows GnuCash; went to iMac, brought up Gnucash - still missing, and the
automated entry made on the windows machine showed up, so they are pointing
to the same file. Ran the transaction report, and the data that was there
Wed was gone. Troubled, and thought about what could be different. Realized
that I have been running the stock update program, and decided to not run
it. Re-entered the charity checks, used the transaction report to verify it
was present; double-checked the balance to verify that I hadn't somehow
double-entered them. Shut down; back to Windows GnuCash: the checks are
there.


I've not run the stock update program since Thursday night, and I've not
seen anything go missing. I find it hard to believe that it somehow messed
around with the registers. I know that the GUI looks for the existence of
the lock file, so that one gets a warning if the same data file is accessed
at the same time. I don't know if the stock price update script has this
check. If it doesn't, I thought that perhaps I ran an update with Gnucash
up, and it overwrote the data. But that means that it was have to be before
the auto-save kicked in (7 minutes on the Mac), and I'm just not sure that
that was long enough.

I brought 

Re: [GNC] Scary moment

[R Losey]

Yes, I have an iMac (pretty new), a Win10 machine, and an older Linux
machine (Ubuntu 22.04 LTS). The file - the only one I use - is stored on a
NAS disk that all of the machines can access. Nothing has gone wrong with
the disk that I can tell, since I use the NAS for a lot of stuff and there
have been no issues with it.

On Fri, Dec 30, 2022 at 11:50 PM Peter West  wrote:

> How are you accessing your file from the two different operating systems?
> Are you running a Linux VM on your Windows system? If so, are you accessing
> a common disc from both systems, or are you using a network file system to
> access the GnuCash data file?
>
>
> —
> Peter West
> p...@pbw.id.au
> And the angel said to them, “Fear not, for behold, I bring you good news
> of great joy that will be for all the people. For unto you is born this day
> in the city of David a Saviour, who is Christ the Lord. And this will be
> a sign for you: you will find a baby wrapped in swaddling cloths and lying
> in a manger.”
>
> On 31 Dec 2022, at 11:31 am, R Losey  wrote:
>
> Versions are a little confusing Mac was running 4.12 until today; I am
> now on the current version.
>
> I updated the Windows version earlier this week.
>
> Linux GnuCash is older (4.), but I don't run the GUI there -
> usually just the gnucash-cli stock updates, which I updated on Thursday
> from whatever it was.
>
> For now, I'm going to avoid running the gnucash-cli updates... I only
> caught the missing checks because of the tax work I was doing; I'm rather
> scared about what else may have been lost.
>
> Also, I've closed and re-opened GnuCush on both Windows and Mac multiple
> times, and the transactions are there, like I expect (but I haven't run the
> stock price update)
>
>
>
>
> On Fri, Dec 30, 2022 at 7:25 PM Stan Brown 
> wrote:
>
> Are you using the current version? If so, it might be appropriate to
> enter a bug report, mentioning each of the things you have checked for.
>
> Stan Brown
> Tehachapi, CA, USA
> https://BrownMath.com
>
> On 2022-12-30 17:23, R Losey wrote:
>
> Thanks, but I am aware of this. On Wed, after I entered the data, I
> re-ran the report, and verified that the checks now showed up.
>
> On Friday, the checks were missing again.
>
> The only thing I can think of that was different is that I was running
> price updates on Tue, Wed, and Thu via gnucash-cli.
>
>
> On Fri, Dec 30, 2022 at 7:11 PM Stan Brown  > wrote:
>
>Good suggestions, Adrien. I have a fourth thought:
>
>We don't know how Losey was doing the "workup", but if it involved a
>report, and some of the relevant transactions were in accounts
>
> created
>
>after the last time the report was saved, then transactions in those
>accounts would not be picked up automatically. In that case, Losey
>should open the saved report configuration, click Edit » Report
>
> Options,
>
>select all relevant accounts, and save the new configuration.
>
>Stan Brown
>Tehachapi, CA, USA
>https://BrownMath.com 
>
>On 2022-12-30 13:56, Adrien Monteleone wrote:
>
> Another possibility:
>
> The transactions ended up in a different account.
>
> Do a Find from the Accounts tab from all sides of the transaction
>
> and
>
> see if they pop up when you think they are missing.
>
> Also, check the Orphan and Imbalance accounts.
>
> And another possibility:
>
> You have a View Filter on the affected register(s).
>
> The status bar indicates on the far right, if you are using a
>
> filtered
>
> view.
>
> A third:
>
> The dates are way off and aren't where you are looking. This may
>
>or may
>
> not be combined with a filtered view. A Find using accounts,
>
> amounts,
>
> descriptions, et cetera should find them so you can correct the
>
> dates.
>
>
> Regards,
> Adrien
>
> On 12/30/22 10:43 AM, R Losey wrote:
>
> I was doing preliminary tax workup earlier this week,
>
>
>
>
> --
> _
> Richard Losey
> rlo...@gmail.com
> Micah 6:8
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
>
>

-- 
_
Richard Losey
rlo...@gmail.com
Micah 6:8
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Scary moment

[R Losey]

My data file is stored on a NAS device (with redundant disks). I've been
using GnuCash for seven years now, and have always kept it on the NAS and
have had no issues like this before.

My machines are three separate physical machines (I have an recent iMac, a
Windows 10 machine, and an older machine that runs Ubuntu). None of these
are VMs.

I never double-click on a file; I always start the GnuCash GUI and it
always loads the last file; I've been doing this for years, and it is the
only GnuCash file I have, so I'm absolutely certain that I am using the
same file.

I've never seen such a thing before, so I'm also very skeptical that the
gnucash-cli stock update script would erase register transactions.

To recap, here is a timeline {with comments}
*Fri*: Did the regular financial data-entry.  After finishing, I realized
that I forget to write a couple of checks to charities, so I wrote the
checks. {I believe that I also entered this into GnuCash, but it is
possible I forgot and would just pick it up next week; this doesn't tally
with notes I have in the checkbook and my own memory, but it is certainly
possible. If I did enter it at this time, it was on the iMac}

later (late Fri or Sat) Ran the gnucash-cli command to update stock quotes
on Linux - no errors

*Mon*: Ran stock quote update {and then felt foolish as I realized the
markets were closed Monday.} Discovered that it only fetches current data,
and should be run daily to get daily quotes.

*Tue*: Ran stock quote update (Linux)

Wed morning: Thought I'd update the Finance::Quote to 1.54 (I was running
1.52). In case I had problems, I ran an update using 1.52. First update
failed because, while I had a C compiler installed (gcc), I did not have
make (gmake). Installed make, and the update worked. Ran another stock
update command and verified it is using 1.54

*Wed afternoon*: Did a preliminary check of where I stand with taxes. Ran
my YTD transaction report to get info. Noticed it stopped at the end of the
previous month. Changed config to end at end of current year. Re-ran
report. Started entering in data; noticed that charity checks from Friday
were missing. Assumed that I neglected to enter them, so I entered them.
Re-ran the report; they are showing up.

*Wed evening*: Ran stock update. Modified the gnc-fq-update perl script to
check for the existence of /usr/bin/make if running on Linux.

*Thu night*: ran stock update

*Friday morning*. Brought up GnuCash (Windows) to do regular data entry,
and noticed that the charity checks are missing again. Wondered if I was
somehow on an old data file. Looked at the directory where files are
stored; sorted by last modified - no indication of a second file, and the
GUI only has my standard file in the MRU list in the "File" Menu. Shut down
Windows GnuCash; went to iMac, brought up Gnucash - still missing, and the
automated entry made on the windows machine showed up, so they are pointing
to the same file. Ran the transaction report, and the data that was there
Wed was gone. Troubled, and thought about what could be different. Realized
that I have been running the stock update program, and decided to not run
it. Re-entered the charity checks, used the transaction report to verify it
was present; double-checked the balance to verify that I hadn't somehow
double-entered them. Shut down; back to Windows GnuCash: the checks are
there.


I've not run the stock update program since Thursday night, and I've not
seen anything go missing. I find it hard to believe that it somehow messed
around with the registers. I know that the GUI looks for the existence of
the lock file, so that one gets a warning if the same data file is accessed
at the same time. I don't know if the stock price update script has this
check. If it doesn't, I thought that perhaps I ran an update with Gnucash
up, and it overwrote the data. But that means that it was have to be before
the auto-save kicked in (7 minutes on the Mac), and I'm just not sure that
that was long enough.

I brought up the GnuCash GUI on Linux; it is at 4.8 (and, late Fri night, I
verified that the charity checks showed up there as well).

So, there is a long, boring description of stuff.

On Fri, Dec 30, 2022 at 11:31 PM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Where is your data file?
>
> Are you using 3 separate physical machines, or are some of these VMs?
>
> If you've done various finds, reports, and other searches to eliminate
> data-entry error possibilities, and since this has happened more than
> once to the same data, I'm inclined to hazard one more guess:
>
> file-access issues
>
> Are you absolutely certain, when you are in a file showing the
> transactions 'missing' that you are indeed in the *exact* same file as
> when you put them in?
>
> How do you know you are in the same file?
>
> I'm not saying that gnucash-cli does not have a nasty bug, but I'm
> skeptical that a stock price update would be affecting any registers,
> much less non-stock

Re: [GNC] OFX import date questions

[David Carlson]

Phyllis,

Reconciliation does* not* always change the date to date cleared.  In fact,
the only date messed with during reconciliation is the reconciliation
date.  That date is always automatically set to the date used by the
reconciliation process.  In fact, that date has been the topic of other
threads in recent months.  The OFX import may or may not change the
transaction date when the imported transaction date differs from the
existing matched transaction date depending on whether you choose to use
the Update feature for that particular transaction.  You may wish to
re-read the Tutorial regarding how the matching process works.  I am not
sure even what you mean by 'date issued'  Is that the the date you wrote
the check?  If I want to keep that date in the record I manually write it
in the Notes field.

By the way, if you want to test anything in GnuCash, just make a disposable
and renamed copy of your data file or backup from earlier and put it in a
folder labelled Test.

On Sat, Dec 31, 2022 at 7:54 AM Phyllis Bruce  wrote:

> Thanks Jean and David,
> My thresholds are prolly set to the defaults.  Another thing I will do is
> filter for "Unreconciled" before I start my reconciliation.  I often have
> some withdrawals that don't occur within two months.  If I know they're
> there, I can change the threshold to look for them.
>
> Second thought, clearly a preference because we are looking at "statements"
> from the bank.  How might I keep the date issued as part of my record?
> Where should I enter that since, in the reconciliation the date is always
> changed to date cleared?  Just finished reconciling for the month so it
> will be a while before I can test this.  New year - new start
>
> On Fri, Dec 30, 2022 at 7:25 PM Simon Roberts <
> si...@dancingcloudservices.com> wrote:
>
> > Thank you for the help to this point. I think I've worked out the date
> > issue (very embarrassing, nothing to do with GC). Now I have a bunch more
> > questions, but I'll ask them in dedicated threads to minimize confusion.
> >
> > I did notice that the CSV version of the transaction information contains
> > two different date columns one called "Posting" and the other
> "Effective",
> > but in all my samples so far, they're the same. That had nothing to do
> with
> > my stupi^H^H^H^H^H ... er, "problem", but I mention it in case it has any
> > relevance to anyone looking at this thread years from now. The OFX file
> > only seems to contain a single date field ("DTPOSTED").
> >
> > But yeah, overwhelm induced stupidity on my part, sorry. Next question
> will
> > be a bit more real, but many thanks to everyone who was kind enough to
> > pitch in their ideas.
> >
> >
> > On Fri, Dec 30, 2022 at 3:19 PM David Cousens 
> > wrote:
> >
> > > Simon,
> > >
> > > The OFX file will be the immediate position in the banks records at the
> > > time of
> > > download. What appears in a statement may be after completion of
> > interbank
> > > clearances of funds and the dates in the statement may reflect when
> this
> > > occurred rather than when the transaction was first received by the
> bank.
> > > Clearnce times are generally a lot shorter with electronic clearances
> > than
> > > they
> > > used to be can sometimes be delayed. SInce this is a disagreement
> between
> > > OFX
> > > records and statement both produced by the bank, they are best placed
> to
> > > explain
> > > what such discrepancies are and why they occur.
> > >
> > > David Cousens
> > >
> > >
> > > On Fri, 2022-12-30 at 14:35 -0700, Simon Roberts wrote:
> > > > Beginner/refugee from QuickBooks here (more context below if you
> > > > care).  I'm working in a scratch file, so I can do stupid things
> while
> > > > learning without damaging anything "important".
> > > >
> > > > I'm working with importing my bank transactions using OFX format
> > (though
> > > > I've also tinkered with CSV, and am willing to use that if it
> > > > solves my problem).
> > > >
> > > > I imported some transactions using OFX. Several things surprised me,
> > but
> > > > the one that I think needs resolving first is that the transaction
> > dates
> > > do
> > > > not match the bank statement.
> > > >
> > > > Earlier I tried the CSV import and saw there were *two* date fields
> > > > (presumably difference between being received and being acted on?
> > > >
> > > > Can someone tell me what I should do to fix this? Is there a way to
> > > "tweek"
> > > > the OFX import, or do I need to use CSV? Or is this something else
> > > entirely
> > > > that's gone amiss?
> > > >
> > > > Thanks for any hints,
> > > > Cheers,
> > > > Simon
> > > >
> > > > Background in case it's relevant:
> > > >
> > > > I'm a refugee from Intuit, and very early in my learning process.
> > > >
> > > > I"m not a bookkeeper, I'm a programmer. Conversely, my bookkeeper
> > isn't a
> > > > software person--she would have continued paying the annual ransom to
> > > > Intuit but I'm sick of their hostage taking. Of course this me

Re: [GNC] Matching error in OFX import

[Simon Roberts]

I've built 4.13 and the problem seems to have been fixed :)


On Sat, Dec 31, 2022 at 9:14 AM Simon Roberts <
si...@dancingcloudservices.com> wrote:

> Gach, yes, sorry meant to reply all, will pay attention in future,
> hopefully not do that again :(
>
> But FWIW, these transactions have different FITIDs and are in a single
> import from a single file (and do not duplicate anything pre-existing).
> But, I will get back when I'm not using 3.8. It's sad (but clearly nobody
> here is in control of this!) that Ubuntu is packaging such an old version.
>
> On Fri, Dec 30, 2022 at 7:08 PM Jean L  wrote:
>
>> Don't forget to reply to the list.
>>
>> Bear in mind: if you import an OFX file, match its transactions to some
>> of your register transactions, the matched transactions will be silently
>> ignored when you re-import the same OFX. That's by design. So if you match
>> everything then re-import the same OFX, you'll have nothing to match.
>>
>> GC uses the FITID to verify that an OFX transaction was already imported
>> and matched (it compares the FITID value of the transaction in the register
>> to that in the OFX file). When GC imports an OFX transaction, it copies the
>> OFX FITID to the register transaction.
>>
>> But yes, update to a recent version as there were bugs in this mechanism
>> that were recently fixed.
>>
>> J
>> On 12/30/2022 6:03 PM, Simon Roberts wrote:
>>
>> Yes, different FITIDs.
>>
>> I'm now finding that actually silently dumping some of these similar
>> transactions. (But I've also discovered I'm not using the latest
>> version--I'm on 3.8, so I think I should upgrade it and try again.)
>>
>>
>>
>> On Fri, Dec 30, 2022 at 6:57 PM Jean L  wrote:
>>
>>> We might need a bit more info to give a useful answer. But just to be
>>> sure:
>>> - The FITID of the transactions in the OFX file are all different,
>>> right? That's an absolute requirement, not just within a single OFX
>>> file, but from ofx to ofx, the FITID is supposed to identify one and
>>> only 1 transaction. If you re-download the same transaction the FITID is
>>> supposed to be the same as the first time you downloaded it. GC uses
>>> this to know which transactions have already been matched when it looks
>>> at an imported OFX file.
>>>
>>> - Is the problem that you have similar transactions in your register
>>> (that you've entered manually) with the same amount and close dates?
>>> It's not impossible that GC is a bit confused because it finds 2 or more
>>> transactions in your register than seem to match 1 or more transactions
>>> in your OFX. In other words, GC does not have a way to figure out which
>>> OFX transaction should be matched with which transaction in your
>>> register if everything is very similar between them.
>>> I must say I've never run into this issue, so I don't know for a fact
>>> what GC does in that case.
>>>
>>> J
>>>
>>> On 12/30/2022 5:36 PM, Simon Roberts wrote:
>>> > With the same caveat about my being new to this...
>>> >
>>> > My transaction records show regular, very similar, transactions. The
>>> same
>>> > institution, identical amounts, usually close but not identical dates.
>>> >
>>> > The importer's matcher is confused by these similar transactions. It
>>> marks
>>> > them in red and refuses to do anything with them directly. I can unmark
>>> > them, and then get them to import, but there are other fields
>>> (specifically
>>> > there is a field "" in the OFX file that seems like it should
>>> > distinguish them, even if everything else is identical (I'm assuming
>>> FITID
>>> > is "Financial Transaction ID", but I could be wrong since that's just a
>>> > guess!)
>>> >
>>> > In the interest of being clear, these "conflicting" transactions are
>>> in the
>>> > *same* OFX file, it's not trying to match against something already in
>>> > place.
>>> >
>>> > Can I do anything to get this to behave more helpfully?
>>> >
>>> > Cheers,
>>> > Simon
>>> >
>>> ___
>>> gnucash-user mailing list
>>> gnucash-user@gnucash.org
>>> To update your subscription preferences or to unsubscribe:
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> -
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>>>
>>
>>
>> --
>> Simon Roberts
>> (303) 249 3613
>>
>>
>
> --
> Simon Roberts
> (303) 249 3613
>
>

-- 
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Matching error in OFX import

[Simon Roberts]

Gach, yes, sorry meant to reply all, will pay attention in future,
hopefully not do that again :(

But FWIW, these transactions have different FITIDs and are in a single
import from a single file (and do not duplicate anything pre-existing).
But, I will get back when I'm not using 3.8. It's sad (but clearly nobody
here is in control of this!) that Ubuntu is packaging such an old version.

On Fri, Dec 30, 2022 at 7:08 PM Jean L  wrote:

> Don't forget to reply to the list.
>
> Bear in mind: if you import an OFX file, match its transactions to some of
> your register transactions, the matched transactions will be silently
> ignored when you re-import the same OFX. That's by design. So if you match
> everything then re-import the same OFX, you'll have nothing to match.
>
> GC uses the FITID to verify that an OFX transaction was already imported
> and matched (it compares the FITID value of the transaction in the register
> to that in the OFX file). When GC imports an OFX transaction, it copies the
> OFX FITID to the register transaction.
>
> But yes, update to a recent version as there were bugs in this mechanism
> that were recently fixed.
>
> J
> On 12/30/2022 6:03 PM, Simon Roberts wrote:
>
> Yes, different FITIDs.
>
> I'm now finding that actually silently dumping some of these similar
> transactions. (But I've also discovered I'm not using the latest
> version--I'm on 3.8, so I think I should upgrade it and try again.)
>
>
>
> On Fri, Dec 30, 2022 at 6:57 PM Jean L  wrote:
>
>> We might need a bit more info to give a useful answer. But just to be
>> sure:
>> - The FITID of the transactions in the OFX file are all different,
>> right? That's an absolute requirement, not just within a single OFX
>> file, but from ofx to ofx, the FITID is supposed to identify one and
>> only 1 transaction. If you re-download the same transaction the FITID is
>> supposed to be the same as the first time you downloaded it. GC uses
>> this to know which transactions have already been matched when it looks
>> at an imported OFX file.
>>
>> - Is the problem that you have similar transactions in your register
>> (that you've entered manually) with the same amount and close dates?
>> It's not impossible that GC is a bit confused because it finds 2 or more
>> transactions in your register than seem to match 1 or more transactions
>> in your OFX. In other words, GC does not have a way to figure out which
>> OFX transaction should be matched with which transaction in your
>> register if everything is very similar between them.
>> I must say I've never run into this issue, so I don't know for a fact
>> what GC does in that case.
>>
>> J
>>
>> On 12/30/2022 5:36 PM, Simon Roberts wrote:
>> > With the same caveat about my being new to this...
>> >
>> > My transaction records show regular, very similar, transactions. The
>> same
>> > institution, identical amounts, usually close but not identical dates.
>> >
>> > The importer's matcher is confused by these similar transactions. It
>> marks
>> > them in red and refuses to do anything with them directly. I can unmark
>> > them, and then get them to import, but there are other fields
>> (specifically
>> > there is a field "" in the OFX file that seems like it should
>> > distinguish them, even if everything else is identical (I'm assuming
>> FITID
>> > is "Financial Transaction ID", but I could be wrong since that's just a
>> > guess!)
>> >
>> > In the interest of being clear, these "conflicting" transactions are in
>> the
>> > *same* OFX file, it's not trying to match against something already in
>> > place.
>> >
>> > Can I do anything to get this to behave more helpfully?
>> >
>> > Cheers,
>> > Simon
>> >
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>
>
> --
> Simon Roberts
> (303) 249 3613
>
>

-- 
Simon Roberts
(303) 249 3613
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] OFX import date questions

[Phyllis Bruce]

Thanks Jean and David,
My thresholds are prolly set to the defaults.  Another thing I will do is
filter for "Unreconciled" before I start my reconciliation.  I often have
some withdrawals that don't occur within two months.  If I know they're
there, I can change the threshold to look for them.

Second thought, clearly a preference because we are looking at "statements"
from the bank.  How might I keep the date issued as part of my record?
Where should I enter that since, in the reconciliation the date is always
changed to date cleared?  Just finished reconciling for the month so it
will be a while before I can test this.  New year - new start

On Fri, Dec 30, 2022 at 7:25 PM Simon Roberts <
si...@dancingcloudservices.com> wrote:

> Thank you for the help to this point. I think I've worked out the date
> issue (very embarrassing, nothing to do with GC). Now I have a bunch more
> questions, but I'll ask them in dedicated threads to minimize confusion.
>
> I did notice that the CSV version of the transaction information contains
> two different date columns one called "Posting" and the other "Effective",
> but in all my samples so far, they're the same. That had nothing to do with
> my stupi^H^H^H^H^H ... er, "problem", but I mention it in case it has any
> relevance to anyone looking at this thread years from now. The OFX file
> only seems to contain a single date field ("DTPOSTED").
>
> But yeah, overwhelm induced stupidity on my part, sorry. Next question will
> be a bit more real, but many thanks to everyone who was kind enough to
> pitch in their ideas.
>
>
> On Fri, Dec 30, 2022 at 3:19 PM David Cousens 
> wrote:
>
> > Simon,
> >
> > The OFX file will be the immediate position in the banks records at the
> > time of
> > download. What appears in a statement may be after completion of
> interbank
> > clearances of funds and the dates in the statement may reflect when this
> > occurred rather than when the transaction was first received by the bank.
> > Clearnce times are generally a lot shorter with electronic clearances
> than
> > they
> > used to be can sometimes be delayed. SInce this is a disagreement between
> > OFX
> > records and statement both produced by the bank, they are best placed to
> > explain
> > what such discrepancies are and why they occur.
> >
> > David Cousens
> >
> >
> > On Fri, 2022-12-30 at 14:35 -0700, Simon Roberts wrote:
> > > Beginner/refugee from QuickBooks here (more context below if you
> > > care).  I'm working in a scratch file, so I can do stupid things while
> > > learning without damaging anything "important".
> > >
> > > I'm working with importing my bank transactions using OFX format
> (though
> > > I've also tinkered with CSV, and am willing to use that if it
> > > solves my problem).
> > >
> > > I imported some transactions using OFX. Several things surprised me,
> but
> > > the one that I think needs resolving first is that the transaction
> dates
> > do
> > > not match the bank statement.
> > >
> > > Earlier I tried the CSV import and saw there were *two* date fields
> > > (presumably difference between being received and being acted on?
> > >
> > > Can someone tell me what I should do to fix this? Is there a way to
> > "tweek"
> > > the OFX import, or do I need to use CSV? Or is this something else
> > entirely
> > > that's gone amiss?
> > >
> > > Thanks for any hints,
> > > Cheers,
> > > Simon
> > >
> > > Background in case it's relevant:
> > >
> > > I'm a refugee from Intuit, and very early in my learning process.
> > >
> > > I"m not a bookkeeper, I'm a programmer. Conversely, my bookkeeper
> isn't a
> > > software person--she would have continued paying the annual ransom to
> > > Intuit but I'm sick of their hostage taking. Of course this means I
> need
> > to
> > > do a decent part of the legwork for this transition.
> > >
> > > Of course because I'm not a bookkeeper, I don't understand the
> accounting
> > > side of this stuff, and likely won't know how to ask/phrase the
> > questions.
> > >
> > > Neither of us are going to be great at searching the documentation
> since
> > it
> > > seems like the terminology is different between GC and QB (and I don't
> > > really know the terminology anyway)
> > >
> > > So, please forgive the idiot question, and if the simple answer to a
> > > question is RTFM, we're very happy to do so, but likely are asking as
> > we've
> > > failed to find the relevant part of said references.
> > >
> > > Anyway, thanks for your indulgence :)
> > > ___
> > > gnucash-user mailing list
> > > gnucash-user@gnucash.org
> > > To update your subscription preferences or to unsubscribe:
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > > -
> > > Please remember to CC this list on all your replies.
> > > You can do this by using Reply-To-List or Reply-All.
> >
> > ___
> > gnucash-user mailing list
> > gnucash-user@gnucash.org
> > To updat