Aaron Laws
My feedback
10 results found
-
63 votes
-
142 votes
An error occurred while saving the comment -
232 votes
-
135 votes
An error occurred while saving the comment This can be closed as a duplicate of: https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/2047887-make-it-easier-for-users-to-work-with-alternative
-
308 votes
Concurrent multi-user support has been part of our long-term goals for a while now:
http://wiki.gnucash.org/wiki/Roadmap#Database_and_QOFTime to update the status of this feature request…
Note it still says “long-term”, which currently means several years ahead of us. -
6 votes
An error occurred while saving the comment I believe this is a solved problem (it's *really* common), but maybe I'm missing something. The normal way to handle this is to have all times stored in UTC, and all input and display is done in local time. For example:
I'm in eastern time (normally UTC-5:00). I enter a transaction for 2012-02-14 22:00, and it's stored in the database as 2012-02-15 03:00 (UTC assumed). When I open gnucash in eastern time, this transaction shows up at 2012-02-14 22:00 as expected. If I open it in Israel (UTC+2:00), it shows up as 2012-02-15 05:00. This is because if something happened at 2012-02-15 03:00 EST, it happened at 2012-02-15 05:00 IST (Israeli Standard Time). They're the same time.
Using the timezone of UTC+11:00 for input, storage, and display is misleading. It doesn't match up to any perception of real-world time. Continuing the analogy, say I (in EST) send an e-mail at 2012-02-14 22:00 to a colleague in IST, saying "Happy Valentine's day; I entered the transaction just now.". (Of course, the timestamp on his e-mail says 2012-02-15 05:00 IST.) This will be stored in the gnucash database as 2012-02-14 22:00 (with an assumption of timezone UTC+11:00). My friend later opens the books in IST and sees the transaction as being entered 2012-02-14 22:00. He thinks, "Wait, that doesn't look right; let me check the e-mail", and sees the discrepancy. The other way around is no better (if my Israeli colleague created the transaction, then I later view this transaction in EST).
I didn't vote for this solution. Banking and finance is in general handled in "days" not "minutes", but if we're going to do accounting in minutes (or microseconds or whatever), we should do it reasonably.
-
11 votes
-
8 votes
An error occurred while saving the comment And how should it handle import from file?
-
0 votes
An error occurred while saving the comment It is not possible to post to placeholder accounts (at least in the latest Gnucash, and I assume it has been this way for a long time). To mark an account as placeholder, right click the account in the account tree, click "edit account", check the "Placeholder" checkbox.
-
2 votes
An error occurred while saving the comment The only way I know to do that now is to make those scheduled transactions actually "post" to their future dates. Then, you can simply scroll down to the date at which you're looking.
As a GNU/Linux user, I see this as a user problem, not an application problem. That is, the user is responsible for keeping his software as up-to-date as he likes. In GNU/Linux it is typically done centrally so that you run one command (mine is pacman -Syu) to get every piece of software on the whole system up-to-date nigh-instantly.
I understand some folks are using Microsoft Windows and that operating system doesn't help users with this sort of thing which is unfortunate. Even so, the proposal still seems like a bad one. If Microsoft Windows users need to download a MSI file and run it, maybe something as simple as signing up for an "update" e-mail with a link to the necessary MSI that will update Gnucash should be much simpler than Gnucash trying to update itself. Then you just click, hope the installation file isn't compromised (does Microsoft Windows have a way to ensure this type of security yet?), next, next, next, finish?