AdminJohn Ralls
(Developer, GnuCash)
My feedback
17 results found
-
4 votes
An error occurred while saving the comment -
1 vote
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
1. Turn your code into a PR or attach it to a bug request. Patches on the mailing list tend to get lost. Derek's suggestion that the change could be limited to a single file was I think about personal use. To actually make this a feature I'd prefer that it be a preference item similar to the Action/Number switch, but in this case it would be a regular preference since it's just display.
2. Interesting idea, but your presentation is a bit unclear: You begin with having a color associated with each account, not too hard; then a color associated with each account type, which is a little harder if you mean the types that already exist, like STOCK and BANK and a lot harder if you mean to have user-assignable account types--let's call them groups to distinguish from the hard-coded types--and UI to manage them.
3. Huh? Only the transaction being edited has a blank line and in that case it probably is needed. Removing it won't save much screen real estate and having to use the menu or a shortcut every time one wants to add a split would be pretty annoying.
4. Another interesting idea, but since one can examine a "split transacion" easily enough with a click or two I'm not sure it would be much of an enhancement.
5. Use a variable in your scheduled transaction template and the since-last-run dialog will ask you for an amount to plug in when the transaction fires. A transaction must have an amount in order to post; if you don't know the amount you're not ready to post it.
6. Splits are orderless. The set of splits is a description of a state, not a sequence. Making them ordered in the display would require adding a hidden order field to the schema and code to set the field while the transaction is being edited and to read it when the transaction is displayed in split mode.
7. No, overloading accounts to create tags would be a poor design, a violation of the single-responsibility rule.
8. The main use-case for this would be to link capital gain transactions to their corresponding sell transactions, and the Lots facility does that though not in a way that's visible to the user and there's no way to do the same thing manually. IMO a split transaction is a better way to represent a transfer from a reserve account to a current account and then spend the money. It will already appear as two entries in the current account because of the two splits.
-
12 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
What exactly are you asking for? Reports? Exports? Imports?
I imagine by "they force you to use SBR", you mean that some Dutch governmental agency requires that some financial entities must file reports formatted in SBR, a derivative of XBRL. If that's right, what sort of entities and what reports?
-
6 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Aaron,
Time, not timezone. All transactions were timestamped at midnight local time to signify the day. If you changed timezone to the east the date changed. This proposal, implemented in 2.6.14, changes the *time*, not the *time zone*, to 11:00 UTC so that for most timezones the date would stay the same. 2.6.15 will change it to 10:59 UTC because in New Zealand Summer Time 11:00 UTC is midnight the next day. Oops.
As you say, the time resolution for accounting is days, not minutes. The original developers of GnuCash decided to store dates as timespecs (resolution in nanoseconds!) anyway, and we've been dealing with trying to work around that poor decision almost ever since.
AdminJohn Ralls
(Developer, GnuCash)
shared this idea
·
-
266 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
There is an API in C with bindings in Scheme and Python.
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Patches welcome, as the saying goes. None of the regular developers has this as a priority AFAIK.
-
1 vote
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
A filter function would be both easier to implement and more natural in the GUI IMO.
-
15 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Would the simple addition of such an option really satisfy the requirement? Or is the requirement really that the program must impose controls to ensure that the books can't be altered without creating journal entries?
As for preventing a debit balance in a trust account, can you elaborate on what that means and how it would be implemented?
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
This has been discussed at length on gnucash-users; the belief that you can rely on electronic records for an audit trail is a fantasy. Storage is either in XML or SQL, and both are easily edited outside of GnuCash, so any controls that GnuCash imposes can be defeated without much effort.
That aside, GnuCash's target market is homes and sole proprietorships, and our goal is to make the program easy for those users, not to supply a corporate-grade system.
Finally, while GnuCash doesn't have the ability to make all editing impossible, version 2.6 does provide an option to prevent editing transactions more than n days old, where n is configured in File>Properties on the Accounts tab: Set "Day Threshold for Read-Only Transactions (red line) to something other than 0.
-
4 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Nice thought, but Adwaita is a Gtk3 CSS theme and GnuCash uses Gtk2. Unfortunately I've never found Gtk2 theme engine that was sufficiently stable on OS X to distribute, but you're free to install one yourself if you like.
-
6 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Abhinav Pandey: What report?
Domingo Bernardo: This isn't the right place to ask for help. Please subscribe to the user mailing list, gnucash-user@gnucash.org, at https://lists.gnucash.org/mailman/listinfo/gnucash-user. -
6 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Hmm. It's present on my system, running in the US locale, but the tax stuff is locale sensitive. What locale are you using?
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
OK.
Have you tried using the "Tax Report Only -- No TXF Export" category for everything?
I don't use the tax report; I tried it out a few years ago and decided that the Income statement report worked better for me -- but I have my CoA set up in such a way that taxable and non-taxable income are separate as are deductible and non-deductible expenses.
If the Tax Report Only tax category doesn't do what you need, I suggest that you subscribe to gnucash-user@gnucash.org and pose the question there. There are a lot of experienced users, many of whom aren't in the US, but all of whom must pay taxes. I'm sure they'll have some more suggestions for you.
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
That's interesting. AFAIK we've only ever had US and German tax reports, and neither has changed appreciably since they were introduced aside from being updated annually to reflect changes in tax law in those two countries.
What version of GnuCash had this more universal tax report?
-
5 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Why can't you just name the SX meaningfully?
-
34 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
For those users who see an improvement when the locale is set to UTF-8 or C, see https://bugzilla.gnome.org/show_bug.cgi?id=736189.
Also consider just setting a UTF-8 locale instead of an ISO8859 one. -
3 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Version 2.6 permits you to attach a link to an external document to transactions. This is more flexible than allowing newlines in the memo fields, especially if you're interested in graphical elements like barcodes. Might that meet your needs?
-
357 votes
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Yes, we'll be able to support smaller fractions than 10E-6 in 2.8. That's what I'm working on now.
Duh, of course there are countries besides the US. But AFAIK none of them have issued rules about how to account for "virtual currency" transactions. Accounting is about rules, not arithmetic: The arithmetic is easy.
If you live in the USA, you *must* account for your bitcoin (or any other "virtual currency" that you use) in the way already supported by GnuCash. If you live anywhere else, you probably *should* account for them the same way, simply because that's what's least likely to get you in trouble, until your country's tax and accounting authorities get around to publishing their own rules. I do expect that more of them will do so in the next two years, and I predict that most OECD countries will follow the US lead.
I don't at present know all of the things that will have to change in GnuCash to support treating currencies and commodities the same. The relevant code is scattered about the UI as well as the engine, and the major focus of this development cycle to fix that and get a properly layered database-driven application that will make it feasible to change the basic rules in the future.
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
> Currencies should not only be defined by ISO. US Gov said Bitcoin is a currencies already.
Utterly incorrect and likely to get you in trouble. See question 1 in
http://www.irs.gov/pub/irs-drop/n-14-21.pdf?utm_source=3.31.2014+Tax+Alert&utm_campaign=3.31.14+Tax+Alert&utm_medium=emailBitcoin and all similar "convertible virtual currencies" are properties, like stocks or bonds. For US federal tax purposes at least GnuCash's current treatment of Bitcoin is correct.
-
11 votesAdminJohn Ralls
(Developer, GnuCash)
shared this idea
·
-
1 vote
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
Why are Tools:Close Book and Preferences:Accounting Period not sufficient?
-
1 vote
An error occurred while saving the comment AdminJohn Ralls
(Developer, GnuCash)
commented
What's the difference between your proposed "pending" status and the existing "cleared" status? ISTM that if the bank agrees with you then the transaction has cleared; that's independent of whether you find out from doing an import or looking at the "transactions" page on the bank's website, or some other way.
There's already a cleared balance column available on the Accounts page, so unless there's a real difference between "pending" and "cleared" this is already covered.
Do you mean an account template for churches and other non-profits? If so,
what accounts would go in that category and why would they be different from any other business?