Unfortunately the code implementing this feature eventually never made it into the official releases. So I’m reopening this feature request.
As cstim's update message indicated this was implemented in the "new" register code. Unfortunately this "new" register code got disabled right before release 2.6 as it turned out to be way to buggy and under performing. That code hasn't been updated since due to lack of time.
So indeed this feature is currently not implemented in any official gnucash release.
Thank you all for the feedback.
The csv importer is currently being improved on the development branch. Several of the missing parts mentioned here are already being addressed, such as:
- ability to select transfer account
- ability to import files exported from gnucash
- remember account mappings for a future import
Just to remind you: the current CSV importer had one very specific goal: import bank statements in CSV format.
In that scenario, all the information a bank statement typically has, is a date, a transaction number, a description and an amount. All this can be mapped in the CSV importer. There typically is no information on transfer accounts, so the importer needs you to specify this. And the from account is implied: it's the bank account you're importing from. Some csv files have this info in a column (the own account number) and so the importer allows you to map that implied account via a column.
The future csv importer extends on this. It can still be used as above to import bank statements with the limited info they provide. But is has also been made more generic and will allow to select both a from account and a transfer account. You will have to teach gnucash which account descriptions in the csv file map to which accounts. But gnucash will remember these for future imports.
The names in the csv file don't have to match exactly with the names in gnucash because of this. The only caveat would be there is a one to one mapping. So if you have an account in your csv file "Charge" and map it to "Expenses:Bank:Charge", you can't have a future csv file in which "Charge" would mean "Expenses:Car:Charge". In that case you will need to adjust the mapping manually on each import.
It will also allow to handle multi-split transactions. You normally don't have such transactions in a bank statement, but you could when importing from other applications.
In addition, if you repeatedly have to do imports from csv files that always are structured the same way, you can save your importer configuration for the next import.
As for when to expect this: the changes are implemented for gnucash 3.0. They were way to invasive to do on a bugfix release in the 2.6 series.
@Devan to clarify: the hint to unlimited tagging refers to the future ability to define a filter based on the contents of a transaction's description, notes or memo field. So you could enter "tag" strings in either of these three fields and create a report to select only transactions matching one or more of these strings. It's rudimentary but should help you reach your goal.
As for when: the developers are currently in the process of stabilizing the code in preparation of the 3.0 release. It's tentatively targeted for end of March of this year. If there are blocking issues by that time we may delay some more.
Thank you for your request. It's a variation of the currently most popular request to add categories or tags allowing to filter on something other than accounts only.
On the other hand I also think you are using accounts the wrong way. Accounts shouldn't be named after the shop you're buying from but after the type of goods you are buying. You can use the Shop's name in the description or notes field instead.
So the accounts in your example would be
Then when you want to report all payments to ABC market, you can search from the account hierarchy on "Description" (or "Notes") "Contains" "ABC Market". And from the search ledger you can open an Account report if you like to print your results.
Would that suffice for your needs ?
@Anonymous: A windows 64bit PC can run the 32bit version of Windows perfectly fine. It's fancy to have 64bit versions of applications (and gnucash will be available as 64bit eventually) but other than that there's no benefit at all.
The project is still actively being developed, albeit by a small group of volunteers. I am one of them and spend most of my free time on improving gnucash.
There is unfortunately not the much development bandwidth available so we have to set priorities. One of the most requested features is multi-user access. The developers have picked this up and most of the current effort is geared to realizing this. It's a major undertaking though because it means the basic design ideas on which the code was built are no longer valid, so almost everything has to be reconsidered and adapted. Still we have decided to bit this apple and do the redesign as that would give us a better basis to continue working on and hopefully make it easier as well to get many of the other highly requested ideas realized more rapidly.
So while you may not see immediate changes, rest assured we are listening and the ideas here are taken into account when making important decisions.
Concurrent multi-user support has been part of our long-term goals for a while now:
Time to update the status of this feature request…
Note it still says “long-term”, which currently means several years ahead of us.
As a gnucash developer I can tell you multi-user support is still a real design goal for gnucash and one all active developers would love to reach as soon as possible.
The necessary core rewrite however takes much more time than anticipated and contrary to what some suggest in the comments here hasn't attracted loads of extra interested developers. It's essentially hard work and currently done by less than a handful of volunteers. So if you are interested in contributing you're most welcome to let us know via irc or gnucash-devel and we'll work out what you can do. Note we're currently close to starting our beta-release cycle for gnucash 2.8. It will take us the next couple of months of our time to stabilize this big release so core refactoring will only be resumed after that.
If someone provides code patches with the necessary changes, they would be included yes. It will need someone with knowledge of the Indian specific tax rules to provide these patches though.
Thank you for your suggestion and offer for help.
However as far as I can see gnucash is already translated in Spanish and the translation is rather up to date according to the translation project's statistics:
So what exactly would you like to see translated in Spanish and are you offering help with ?
For those who unlike mary haven't figured it out yet, here is how you can currently do this:
- Open Tools->General Journal
- Select View->Filter By...
- Set the appropriate date range and click ok
- Then select Report->Account Report
The link to that image is not working. Perhaps this one serves as well:
I have merged these two ideas into one because in code they are essentially the same thing. Implementing quotes for customers is about the same code as implementing purchase orders for vendors.
There are a few similar feature requests, which I'm considering for merging together with this one:
Thank you for your feature request. However unless the interface to this bank is publicly available AND there's a swiss developer with access to such bank account, this isn't going to happen. This is not a matter of ill will, but rather lack of sufficient information to be able to even consider this.
I have moved this request to the GnuCash Android forum as it is a request for the mobile app.
I'm sorry but I don't understand what you are requesting. Can you explain your request in more detail ? Thank you.
Google Translate's transcript of this request:
"The creation of a cost center would be very interesting, because it could be created a cost center to a given project.
Upon launch of the transactions in the account that the categories may not expanded type RECIPE (sub retracted accounts) and expenditure (sub retracted accounts)"
Please make your requests in English in the future. The gnucash developers don't speak Portuguese. Also please make only one suggestion per feature request. This request has two unrelated ones.
I'm still having trouble trying to understand what you want exactly.
Perhaps you are really talking about the fact that gnucash automatically reopens the file you have used last time and don't want this ? Would you rather gnucash asks you which file to open on startup instead ?
Thank you for your suggestion, but I'm afraid I don't understand your request. Can you describe in more detail what you are missing ?
In particular the term "Main Window" as opposed to "not open the account directly" is not clear to me.
I'm not using these fields either. When I don't need them I simply put a dash in the mandatory fields (only Name and the first Address line are mandadory). That's not much wasted time so you could consider this as a workaround.
There are currently technical limitations in gnucash that make it difficult to implement a lookup for vendors when printing checks. Additionally vendors would not be sufficient. Employee vouchers and Customer credit notes may also be paid by checks, so lookups for those would be useful as well.
While not exactly what you are requesting, gnucash 2.6.12 will have the ability to print checks from the Process Payment window for Customers, Vendors and Employees. If these people/companies have addresses specified, these will be used for printing on the check.
In addition, if you didn't print a check when you processed a customer/vendor/employee payment, you can still print a check from the transaction that was generated from that payment. Again gnucash will figure out the address from the partner information associated with that payment.
This new functionality does require the use of the business features. If you are not, there is no address information available.
Would this be sufficient to close your request ?