Thank you, for being flameless. My ears are all yours to listen to the explanation...
I actually didn’t tell the whole story ... I did software development for good chuck of my early career in the computer field (worked with through MIL-STD-2167/A when it was de-facto). I am concurring that DATA is in a file of "program data" that gets read in when the "program" starts and that the "change accounting period" function changes this data. I am not sure I concur that to get it to take effect the program has to be shut down and start again manually. During the input phase of the change, upon confirmation "click" a call to start again just that portion of the program is doable, IMHO. It may require implementing a different sub-routine or sub-function if the existing one is not sufficient to do so. I personally write init routines to take a parameter that has value of "COLD", "WORM", "HOT" or nothing (which would default to "COLD") and then branch & execute appropriately. If it is in files of "program data" and is not peek-only then it is likely to be poked and so that poking at any time should be accounted for in "program". I am thinking of examples like say you have to install device driver in an OS, have to update routines in Voyager 1 or 2, modify systems during Apollo 13 mission, fighter pilot needing to input new coordinates, etc. While GNC may not be at the same "critical" level as those examples, we shouldn't nonetheless not have sight of it. I definitely see that you have employed very fail-safe workflow -- for that I commend you for it and my hats offs to you... -----Original Message----- From: Michael or Penny Novack <stepbystepf...@comcast.net> Sent: Monday, December 18, 2023 8:54 PM To: Kalpesh Patel <kalpesh.pa...@usa.net> Cc: gnucash-user@gnucash.org Subject: Re: [GNC] Accounting Period Change issue On 12/18/2023 3:11 PM, Kalpesh Patel wrote: > Hmmm! > > For 1) see the attached jpg. It describes the situation that no one wants to > be in (fyi - I am current practitioner in IT/Systems/Engineering/Software > world) ... it's a defect; not a bug. > > For 2), if I am spending energy to change it deliberately then I want to see > updated values; why else would I be making that change? Definitely not to > have a self-exploding time bomb for the future. It is a refresh/redraw issue > and is not an error in calculation issue, as it does eventually displays > correct values. > > I get feeling that I am going to get flamed... No, not flamed, explained. So you have enough experience in the IT world to understand that this is a "refresh" issue. That the DATA (that defines current accounting period) is going to be in a file of "program data" that gets read in when the program starts and that the "change accounting period" function changes this data. To get it to take effect the program has to start again. If you don't want to "leave a time bomb for the future", want to "see it now", just do a save, close, (re)open immediately after making the change to accounting period. If you don't want to interrupt your work flow (say entering a stack of transactions), the change will appear the NEXT TIME you open gnucash (not far in the future). Not having it automatic gives you the choice. Personally I like all saves to be explicit, known points in my workflow. I am rarely entering transactions "real time" or in date order so want to know exactly where I was in the work flow each save. Michael D Novack PS -- that "not in real time" means I would be using explicit dates for reports, etc. and not things like "current accounting period" which are relative to real time. _______________________________________________ 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.
