I have just uploaded a new version, which you can test if you have a few minutes.

Most of the changes were motivated by something I learned at a conference for MicroISVs (tiny Independent Software Vendors, like me) that I attended a couple of weeks back in Las Vegas. One thing I took special note of was a suggestion that the first 5 minutes of use of your software has to “sing”. That made me think about the fact that there are too many windows to fill out the first time you use the program (or create a new database for a new organization), and I was actually able to remove two of them!

Here is the complete list of changes in this beta test version, 3.43 Beta1:

• The Find Donor window now allows you to also find by email address, as well as the previous fields it allowed.
• On the main window when you are entering or editing donations, and on the One Date Batch Entry window, the drop-down list for the donation Category now has an additional entry “<Add New>”. Selecting that entry brings up the Maintenance -> Donation Categories window, already set up to add a new category. If you add one and close the window, that new one becomes the category for the current donation row.
• On the main window when you are entering or editing donors, the drop-down lists for the donor Category 1 and Category 2 fields now each have an additional entry “<Add New>”. Selecting that entry brings up the Maintenance -> Donor Category 1 or Donor Category 2 window, already set up to add a new category. If you add one and close the window, that new one becomes the corresponding category for the current donor.
• Changed the Maintenance -> Organization Info window, so that when it is automatically shown to you the first time you initialize the information for a new organization, you can fill in a new Receipt Style For field, which could previously only be edited on the Maintenance -> Receipt Options window. This means that you don’t have to visit that Receipt Options window during your initialization for the organization. (On subsequent visits to the Organization Info window, the Receipt Style For field can be viewed but not edited – you still edit it with the Receipt Options window.)
• Removed the automatic display of the Maintenance -> Donation Categories window that was automatically shown to you the first time you initialized the information for a new organization.
• Fixed a bug in the Database -> Import -> Donors window, where if you get an error about not being able to import Category1 or Category2 fields because you haven’t set up any of those those values, you can’t try the import again without first exiting the program. (If you do try it again, you get an error message about not being able to open certain files.)

As usual, you can download and install the upgrade to this beta test version from http://www.software4nonprofits.com/pretest.htm. And if you do have a bit of time to test any of that, please let me know any testing results, positive or negative, by adding a Comment to this post, or by email.

If you want to test anything about that first-time experience, you can do so by creating and switching to a new database with the Database -> Switch Databases window. (Click Help in that window if you don’t know what to do.)

Thank you.

I have been considering for some time whether it would make any sense for me to create a fairly simple bookkeeping program. It’s not at all clear that it does make sense, given how many programs are out there, but I do keep getting asked about this by my users. There are also some things that I know existing standard programs (like QuickBooks) do relatively poorly, lilke fund accounting, that I think I could do better.

So what I’m planning is to send a link to a web-based survey to all registered users of DONATION, asking them (or whoever does the overall bookkeeping for their organization) to tell me what they are currently using, whether they would consider switching, and what features would be required for them to switch. (If they say they wouldn’t consider switching, they don’t have to fill out the rest of the survey.)

Before I launch this survey, though, I would really appreciate some feedback on the current draft. You can see a printout of it in this PDF file:

www.software4nonprofits.com/files/BookkeepingSoftwareSurvey.pdf

What I’m interest in is your comments on things like:

• Do the questions, and the options for the answers to those questions, make sense?
• Any suggestions for improving the wording?
• Am I missing asking about anything important?
• Am I asking about anything that I don’t need to ask about?

One thing I should make you aware of is that in the question about optional features, where I ask the survey respondents to tell me how important each one is, there are features there that I absolutely will not do. In particular, payroll calculations – they are just way too complicated, with too many variations by country and I believe even in some cases by state or province. So, if a large percentage of users said that payroll calculations were a required feature, I would almost certainly not create such a program. I’m also quite unlikely to be willing to include handling investment accounts, accounts receivable, or accounts payable.

My feeling is that I should not mention this in the survey, so as not to bias the responses. Any thoughts?

Many thanks in advance for any comments you have. Obviously, if I’m going to launch this survey to my now over 4,500 registered users, I want it to be as clear as possible before doing so!

In terms of fiscal years, what I implemented was configuring your fiscal year (if it’s different from the calendar year) in Maintenance -> Organization Info, a new Reports -> Fiscal Year submenu with 7 reports on it, and fiscal year selection options in Reports -> Custom Reports. Things I did not do are support fiscal year-based pledging, or mail merge letters based on fiscal year donation amounts.

One great side-effect of some changes to the database structure that I made to support fiscal year reporting, is I was able to fix a long-standing weakness of the multi-year reports, under Reports -> Donor -> Donation Info. Previously, if there was a donor present in last year’s database, but absent from this year’s (e.g. because you deleted them), that donor was omitted from the report, and thus the dollar totals for the previous year could be incorrect. This new version fixes that for all of those reports, including the Last 4 Years report.

One important bug fix was to mail-merged letters or receipts. It turned out that with some longer letters, or a letter added before the mail-merge receipt, sometimes the page breaks between donors’ letters or receipts were disappearing when you printed, so each one didn’t start on its own page. Turns out that was a bug in Internet Explorer (which is actually what is underlying my mail merge editor), that I was already using one work-around for, but that work-around didn’t always work. So I’ve put in another work-around, which I think will be more reliable to make sure that the page breaks always work.

There are also a bunch of other smaller improvements, changes and bug fixes. All are listed on the page:

www.software4nonprofits.com/pretest.htm

from which you can download this DONATION version 3.42 Beta1 for testing. As always, I will greatly appreciate any testing that you can do, and hearing back with either or both of positive or negative test results.

You can reply as a Comment to this blog post, or by email, as usual. Many thanks in advance.

I have been thinking about to what extent (if at all) I should add handling of fiscal years different from the calendar year into DONATION. I have always resisted this (and may still resist it!) because of my “Keep It Simple” philosophy for the program, not wanting to add too many complicating features that only a small minority of the users will want.

There are actually two different issues here, the first of which I definitely do not want to accommodate. That is for countries (such as England and Australia, as I understand it) where the receipting year is not the calendar year, e.g. you claim on your taxes the donations made between (say) April 1 of one year and March 31 of the next year, and so in theory receipts should also cover that period. I have just told users in those countries to handle that by issuing two receipts per year – one covering January 1 to March 31, and one covering April 1 to December 31. Handling this any other way would be an enormous complication that I just don’t want to get into, given that my major market is the U.S.A. and Canada, both of which have a tax receipting year that is the same as the calendar year.

The current offering for organizations in Canada and the U.S.A. with a fiscal year different from the calendar year is just a couple of reports, run through the Database -> SQL Select menu option, explained in a Support Forum post at http://forums.software4nonprofits.com/cgi-bin/fdsforum/gforum.cgi?post=2. One gives total donations by donor, within one fiscal year, and the other gives individual donation details, within one fiscal year. Both need to be hand edited to put in your specific years you are reporting on, and fiscal year start and end dates.

If I was to really build something into the program to handle fiscal years, some or all of the following changes would be needed:

• Add a settable option (perhaps in Maintenance -> Main Window Options, though it doesn’t really affect the main window) for showing fiscal year options in the program, and specifying your fiscal year end’s month and day.
• Add two or more fiscal year reports, based on those settings. I think they would start with ones like the two mentioned above, and perhaps also include one that gives donation totals by donation category, for the fiscal year, for use in reconciling with an accounting program’s data. (These might be in a new Reports -> Fiscal Year sub-menu.)
• Add an option in Reports -> Custom Reports for reporting on one fiscal year. (See below for complexities about this, and the fiscal reports mentioned in the previous point, however.)
• Possibly add two keywords for use in Database -> SQL Select (similar to the existing DONATION_FROM_DATE and DONATION_TO_DATE, which cause the report to prompt the user for a range of dates) that cause it to select the donations in the current fiscal year.
• Possibly add options for the mail-merge letters, particularly the Total Donations information ones, to select a fiscal year to include in that letter, rather than all or part of the current calendar year.
• Possibly add an option to have the Annual Pledge be considered to be for a fiscal year. (But if so, how or when does this get changed, when you pass the fiscal year end in the current calendar year?)

One thing that complicates all of this is the way I have chosen to store donor data, with a copy of each donor record being made for each calendar year. The advantage of this is that you can get rid of donors that are no longer with your organization / donating to your organization. The disadvantage is that currently, multi-year reports (such as Reports -> Donor -> Donation Info -> Sort by Amount) do not always accurately show all of the previous year’s donors, and thus don’t always have an accurate previous year total. (This happens when donors in the previous year have been deleted from, or never copied to, the current year. It can be fixed with the Database -> Copy Missing Donors menu option.)

This problem with reports is arguably not too terrible for the current multi-year reports (because presumably you are most interested in the current year, and looking back to see how much your current year donors gave in past years). However, it is really bad for fiscal year reports, that cover part of this year and part of last year, because they really cannot be considered to be accurate if they are missing some of last year’s donors that have been deleted in the current year! I would really have to build in a check for that being a potential problem, and prompt the user to use Copy Missing Donors to fix it before running those reports. (The check is this: are there any donors present in last year’s list of donors, who had donations last year, who are not present in this year’s list of donors.)

Another big problem with built-in fiscal year reports is the question of which fiscal year you are reporting on. Suppose your fiscal year end is May 30. If you are running fiscal year reports in June or later, how is the program supposed to know whether you want to report on the fiscal year that is just over, or the new one that has started? Would it have to prompt and ask the user, each time? Or only do that in the part of the calendar year that is after the fiscal year end?

I should note that when you are after your fiscal year end, currently you can already run correct reports for the current fiscal year, because you just select one of many available reports that prompt for a range of dates, and select from your fiscal year start up to the current date (or the calendar year end, whichever you prefer).

Also, there is an awkward (but accurate) way to get fiscal year reports now. Again, suppose your fiscal year end is May 30, and it’s currently June 2012, so you want a report on fiscal 2012 (June 1, 2011 to May 30, 2012.) Run a report in the 2012 year covering the 2^nd part of the 2012 fiscal year (January 1 to May 30, 2012). Switch back to 2011 with Maintenance -> Change Year -> Previous Year, and run a report for the 1^st part of the 2012 fiscal year (April 1 to December 31, 2011). Paste them together, and add up any totals, to get a complete fiscal year report. Of course, it may not be sorted appropriately! (You could export both to Excel, copy the data from one at the bottom of the data from the other, and re-sort them in Excel, if you wished.)

Another question I am asking myself is, if I were to add all of these features, would they be completely invisible until you make the setting in the Maintenance option that selects to use fiscal years and specifies your fiscal year end? Or would they be visible, but either inactive (greyed out), or active but give an error message explaining that if you want to use them, you need to make the appropriate Maintenance setting?

I would as usual appreciate any comments or thoughts you have on this, either as a Comment on the blog post, or by an email reply. Particularly for those of you who aren’t regular blog readers, to whom I have emailed a link to this blog posting because you asked me about fiscal year issues in the past – which of those features are “must haves”, and which just “nice to haves”? (Since some of you who asked me about fiscal year handling purchased the program despite the almost non-existing fiscal year support, I suppose I can conclude that none of them are “must haves”, but please tell me if that is incorrect!)

The improvements in that version include some final cleanup and fixes to the new Internet backup feature (which I’ve already separately sent emails about, to those of you who informed me they were testing it). But also the following:

• The Database -> Import  Donors window now allows you to also import the Donor Category 1 and Category 2 fields, which previously could not be imported.
• For users with @earthlink.net email addresses, who are using the first window of Maintenance -> Email Sending Configuration and basing it just on their email address, rather than the settings in an existing email program, DONATION was suggesting the wrong SMTP server (smtp.earthlink.net). That has now been corrected to use smtpauth.earthlink.net.
• Fixed a problem where you got a techie error message if you tried to add a 2nd donation or donor category with the same name as an existing one, in the Maintenance -> Donation Categories menu option or the Maintenance -> Donor Category 1 or Donor Category 2 menu option. Now you get a nicer error message.
• Added a check for adding a 2nd Paid By value with the same name, in the Maintenance -> Donation Paid By Values menu option.
• Fixed a bug in the Database -> Import -> Donations menu option, where Donation Categories containing single quotes (or apostrophes) cannot be imported.

As usual, any comments on these changes, or testing results, will be greatly appreciated. I plan to release this as an official version on the DOWNLOAD page on the website on the weekend, and start sending all users emails about it next week.

Thank you.

There are also a number of other nice new features, and bug fixes, in this version. One that will stand out is that all File Open or File Save dialog boxes are now new-style dialog boxes, and they all have Help buttons that give help on whatever feature they are part of.

Full details of all of the changes are on the www.software4nonprofits.com/pretest.htm page, from where you can download this beta test version and try it out.

I would greatly appreciate any testing you can do on this new version, and Comments back to this blog post (or private emails if you prefer) with your testing results, positive or negative. That includes, if you have the time and interest, commenting on the Help topics describing the new Internet Backup features.

By the way, you will notice that for this beta test version, you have to download the appropriate full installation file, for the Standalone, Lite, Network Server, or Network Client version. For technical reasons (having to do with putting up with a larger download for this version 3.41, to prevent larger update downloads in all future versions) there is no smaller update version available.

Thank you all in advance for whatever testing you can do, and comments you have, which will help make sure this version is as good as possible for all users.

They are now ready to be tested, as part of version 3.40 Beta1, which you can update to at http://www.software4nonprofits.com/pretest.htm. As usual, I will greatly appreciate any testing you can do, and your comments (positive or negative) on the changes.

A full summary of the changes is on that Pretest download page, below the download link. In brief though, it includes renaming the backup files to include the date, plus a sequence number if you make more than one backup per day; warning the user clearly if they are restoring an older backup on top of a newer database; giving an option to retain only the last “N” backups in any one backup directory; and a few other small changes.

I have not done anything yet about my backup to the cloud idea, discussed in the other blog post from last week, because I have not yet found a suitable cloud storage service in Canada, to satisfy privacy concerns for Canadian users.

Thank you!

Unfortunately, I thought of something else significant after making that post, which I’d also like to ask you about.

I considered this some time ago, and rejected it in favour of the email backups option I added, but I’m again considering adding an option to backup to “the cloud”, i.e. remote Internet-based storage. It might be on my own web server, or I might use a service like Amazon’s S3 (Simple Storage Service).

The idea would be that as an option, following every regular backup, an encrypted version of your backup would also be sent to the online storage. Obviously this would slow things down, depending on your Internet speed and the size of your database backups, but it would give an additional enormous level of security for your backups.

One big concern would be distinguishing everyone’s backups from everyone else’s. My thought is that the first time you went to use an online backup, a special guaranteed unique ID would be generated for you, and stored in your database. That key would be used to identify your backups online. It would also be transmitted to me (the first time) so that if you somehow lose everything on your computer and all local backups you have made, you can request the key from me, re-enter it into a new copy of the program, and then retrieve that online backup.

There are a couple of options for how the encryption could work. Obviously, it would have to be based on an encryption key.

One option is to just have you provide the key, and also store it in your database for re-use each time you do an online backup (or restore). That’s like how the current email backups work – you provide the key, and if you forget it, you are completely out of luck. It would be the same with this. (I would not suggest that you send me the key – I should have no access to your data.)

Another option would be for me to have a secret way of generating the key from your unique ID, and just use that generated encryption key.

Both methods are succeptible to cracking (though with significant difficulty!). If someone knew your unique ID, they could enter it into a copy of DONATION, and get back your encrypted database. At that point, with the first option (you provided the key), standard methods could be used to guess obviously bad keys (like “password”!) which some percentage of users always use. With the second option (I create the key in a secret way from your unique ID), a very skillful programmer might be able to reverse engineer my program to determine what my secret way was.

And of course, anyone with access to your current database could also get access to your backups stored online. But that doesn’t seem like a big concern, since they already have access to your current database!

There are also privacy concerns in terms of national legislation like the US Patriot Act, which as I understand it gives the US government the right to inspect any data that is stored in the USA, and to demand any required encryption keys from the data’s owner. Apparently there is somewhat similar legislation here in Canada, and Canadian privacy legislation may forbid the storage of such information in the USA. One option with Amazon’s storage is to store the data in their facility in Ireland. I’m guessing that could cause slightly longer transmission times, but might address this issue. Or perhaps users just aren’t that concerned – generally the IRS in the USA or the CRA in Canada would have the right to audit you, including seeing any donation information, anyways!

My web server is in Vancouver, so storing the data there (or in some Canadian cloud storage provider) would at least eliminate the Patriot Act concerns.

Because there is a cost to online data storage (though it’s quite minimal!) I don’t see retaining unlimited numbers of backups from each user online. Perhaps the last 3?

Any thoughts about all of these points, and the general idea? Many thanks!

I’ve had three or four users relatively recently report missing data within the current year, like “I’m missing all of June and July’s donations, but the ones after that are there”.

Given that there is no feature in DONATION that could possibly mass delete donations like that, the only possibility I can imagine for a situation like that is that at some point in August say, they accidentally (or on purpose, but not understanding what they were doing) restored a database backup from the end of May, didn’t realize that lost them their June and July data, and then just continued data entry from there.

So, I’m working on ideas for some changes to make this less likely.

The first has to do with backups. Currently if your database is the default one, DONATION4.DB, the default backup name you are offered is DONATION4.DB.GBK. You can change that (as long as you leave the ending of “.DB.GBK”), but I’m sure most people don’t.

My idea is to change the default backup filename to be based on the current date, e.g. DONATION2011-12-07.DB.GBK for today’s backup (on December 7, 2011). It could still be changed if desired.

There are two advantages to this. The first is that it will be obvious how old a backup is, that a user is trying to restore (as long as they figure out the YYYY-MM-DD date format, I guess!). The second is that unless the user does something about it, they will have a bunch of backups stored, from all different dates, and each backup will not overwrite the previous one that was stored in the same location.

However, that last point is also a potential disadvantage, as those multiple backups could start filling up whatever storage they were storing it in, e.g. their hard drive or a USB memory key. However, for most users a backup is at most a few megabytes, so it would really take a long time for this to be an issue given the large size of today’s storage.

One option would be to do what some other programs do, and have an option to keep only the last N backups, where they specify the number N (like, last 10 backups). But personally, I think you never know how old a backup you might need. So I’m not sure whether this is a good idea or not.

There could also be an option (on the same window as the one for changing the Backup Reminder Frequency) to go back to the old naming convention, leaving the date part out of the backup filename. But I’m not sure that’s a good idea, as the advantages of the new naming are significant, and the users can always erase the date part from the filename each time they do a backup, if they feel strongly about it.

If I added one or both of the options mentioned above to the Backup/Restore -> Backup Reminder Frequency window, I’d probably rename that menu option to Backup/Restore -> Backup Options.

Now, on to restores. What I’m thinking is that when you go to restore a backup, the program will first open up that backup and find the latest donation date in it. It will compare that to the latest donation date in your current database, and if the backup’s data is older than your current data, it will give a message about it, including stating what each of those two dates is. If the backup data is at least one month older, the message could also say something like “You are about to restore data that is N months older than your current data.” And then of course ask whether they really want to do the restore.

Any thoughts about these changes, and the possible options mentioned above (let them go back to the old backup naming without the date part, and let them specify a maximum number of backups to store in the same location)? As usual, you can Comment on this post to give me your thoughts, or just email a reply. Thank you in advance!

I have found four products or services that I feel could be useful to at least some of my users, or someone else within your organizations, and am working towards an email to all users in the USA to recommend these products. (I’m restricting it to users in the USA, at this point, because two of the services only work there.)

The products and services are:

• CauseVox, at www.causevox.com, an affordable online fundraising platform with social-network-like features available. (USA only for now.)
• PerfectTablePlan, at www.perfecttableplan.com, a simple and affordable Windows program for doing table planning for any form of seated event with tables, such as formal fundraising dinners.
• PayrollCentral USA, at http://www.payrollcentralusa.com, an affordable and very easy to use online payroll processing system. (USA only.)
• NetMinistry, www.netministry.com, a relatively inexpensive service for designing and hosting an attractive website, with a content management system that you can use to maintain the site yourself, for churches or other organizations.

The last three of these are already listed on the Links page on the Software4Nonprofits website.

I would appreciate your comments, about the products themselves, and about the appropriateness of doing something like this. I would not intend to email users about companion products in this way more than once a year.

One final question relates to the fact that in all of the cases, I will be receiving some form of commission for sales that come from my users. This forms another revenue stream for my business. However, I would not be recommending any of these products and services if I had not checked them out thoroughly, including checking references, and did not feel they would be of good use to at least some of my users. At least two of the products/services will also be offered with some discount to my users. (N.B. I am still waiting to receive and check references for NetMinistry, and I know the author of PerfectTablePlan so do not feel a need for references.)

One very specific question I have though, is an ethical one. I’m not clear whether or not I should mention in the email to my users that offers these products that I will be receiving commissions on the sales made to my users. I sort of think I should, but am not 100% clear on this point. Any opinions?

As always, thank you in advance for any comments you post, or email replies.