ACCOUNTS Recurring Transactions Testing

Hello ACCOUNTS beta testers. We have a significant new feature available in the beta test version at http://www.software4nonprofits.com/accounts/pretest.htm, and it would be great if you could test it!

The feature is recurring transactions, which some users have been asking for, for quite a while. As you will recall, we did a survey about it a while ago, and the results were that every option we asked about for how recurring transactions could be set up was needed by at least some users. As a result, there are a lot of options, and a lot of complexity to the programming to make them all work properly!

You can very safely test recurring transactions by memorizing some transactions (if you don’t already have them memorized), and making them recurring in the new Maintenance -> Recurring Transactions menu option’s window. If you set them up for immediate recurrence, when you exit ACCOUNTS and start it up again, any that are due to recur will be shown to you, and automatically inserted (or prompted for, if you chose that option). If you were doing that just for testing, just go into the register window for the account the transactions were inserted into, and delete them! And you can go back to the Recurring Transactions window to remove the recurrence if you set it up only for testing.

As always, we would greatly appreciate any feedback you have on the new features, including comments on the Help text associated with them. And as usual with significant new features, there will be a bonus of an extra 3 month’s support and upgrades renewal for the first user to find each real bug in our programming! (Of course, Kwame and I have tested things extensively, so we are hoping there are no remaining bugs!)

You can give feedback by commenting on this blog post, or just by emailing us directly. MANY THANKS!

New Software4Nonprofits Website

Hello ACCOUNTS beta testers and advisors. (If you also get the DONATION blog posts, please forgive this duplication!)

We have been working on updating our website to look good on any device, especially mobile devices like phones and tablets. It should have an appropriately adjusted display for those devices, so it’s not just squished pages as it is now. On your computer, it should look very much the same as before.

While we have been able to test the pages on a couple of different phones and tablets, obviously that testing is still limited. So we would like to invite you to please take a look at the draft version, which starts at www.software4nonprofits.com/NEW (the caps on “NEW” are required!) . If you can, look at it with both a regular web browser on your computer, and any devices you have. Please report any problems in the display and navigation of specific pages to us, so that we can fix them.

When reporting display and navigation problems, please include:

• the device and the screen size (if known),
• the problem web page,
• and the description of the problem.

If you see any typos or anything that appears to be bad writing or factual errors, we’d also love to hear about that! (Those things probably haven’t changed from the current live website.)

Please enjoy the new experience of our website on your mobile devices. As soon as we have a reasonable number of replies, we will upload this draft to be the new official site for DONATION and ACCOUNTS at the main web address.

Thank you.

Payroll Samples for the U.S.A.

Hello ACCOUNTS advisors. This is specifically for any of you in the U.S.A. who have payrolls.

If you look in the Index of the program’s Help, there is a page “Payroll Samples”, with screen shots of Write Cheques (Write Checks for you Americans!) windows for Canada. That includes both a transaction for paying payroll cheques with appropriate deductions, and the monthly submission to the Canada Revenue Agency (equivalent to the IRS) to submit those deducted payroll taxes to them.

Could any of you please send us either screen shots or just written out samples of similar transactions for the U.S.A., so I can add them to that page? I just don’t know what exactly the right accounts would be named for your country, so I need a bit of help to get the details right.

Probably email would be best for replies about this – info@software4nonprofits.com as always.

Thank you.

ACCOUNTS New Version Testing

Hello again ACCOUNTS beta testers. I have uploaded a new beta test version, 1.36 Beta2. We would greatly appreciate it if as many of you as possible could test it out. As usual, you get it from:

http://www.software4nonprofits.com/accounts/pretest.htm

There are a lot of small improvements in it, including:

• Major speedup in loading Register windows with lots of transactions in them
• Email Sending Configuration working better with Gmail addresses
• several other small feature improvements and bug fixes, all of which are listed on that pretest.htm page, and the Revision History in the program’s Help.

However, the biggest change from our perspective (which you should really not see at all) is a significant re-organization of the program’s code so that a lot of pieces of it can be shared with our DONATION program (used for tracking donors and donations and issuing charitable receipts). If we have done this correctly, you won’t see a single difference from it, but if we missed something, some features could fail to work.

Of course, both Kwame and I have carefully tested pretty much every feature in the program, but we know from experience that the more different people test things, the more likely problems are to be caught, because someone else will just try something in a slightly different way than we thought of trying it.

As always, if you encounter any problems report them to us ASAP and we will fix them and get a fix back to you ASAP as well.

Thank you very much in advance.

New Video on Bank Deposits

Hello again ACCOUNTS advisors. I wanted to let you know that over the last couple of weeks, we have updated and re-recorded all of the introductory and training videos for our DONATION program on the Demos and Samples page on its website, at www.software4nonprofits.com/demos.htm. We haven’t yet done that for the ACCOUNTS videos, because they are less out of date than the DONATION ones were.

The videos for both programs are also now hosted on YouTube, and can be found there by searching. One great side effect of that is that previously, the videos didn’t work on most phones or tablets – now they do. The ACCOUNTS videos are on its Demos and Samples page, at www.software4nonprofits.com/accounts/demos.htm.

There’s also a new video posted on both the DONATION and ACCOUNTS Demos and Samples pages, on configuring and creating bank deposits in DONATION, and exporting them to ACCOUNTS or Intuit QuickBooks.

We’d be most interested in hearing what you think of the new and revised videos.

Thank you.

One Account Details with Balances Reports

Hello ACCOUNTS advisors. A user is questioning the presence of the Starting Balance and Ending Balance figures included in Reports -> Details -> One Account Details and Balances and One Account Details and Running Balances, when you run them for income and expense accounts.

The problem is that those balances are the totals of all transactions over all years that you have been using the program, which makes a lot of sense (as being the current “balance”) for balance sheet accounts (assets, liabilities, and funds) but makes very little sense for income statement accounts (income and expenses).

The question is what exactly is the right fix, when running those reports for income statement accounts. (There will be no change for balance sheet accounts!)

One option (“Option 1”) is to just eliminate those lines for the balances entirely, when running for income statement accounts. For the Running Balances report, it would just start at $0. For the regular Balances report, it would just give a total for the selected time period at the bottom, instead of an ending balance.

Another option I considered (“Option 2”) is to have the opening balance be included, but it would just be the total in that account since the beginning of your fiscal year that includes the starting date for the report. (So if the start date was the start of a fiscal year, it would always be $0.) And the ending balance would be that starting balance plus the sum of all transactions for the dates included in the report. That makes some sense, but starts to make less sense if you run that report over a time period that includes parts of 2 or more fiscal years.

Which of these two options do you prefer?

The other problem of removing balances from these reports is that the reports’ names are then somewhat inaccurate, when run for income statement accounts, since the names say “with Balances” but we may have removed those balances! Any thoughts? Of course the report description in the Help, and in the Report Browser, could explain those differences.

Thank you in advance for your feedback.

ACCOUNTS non-numeric reference #s

Hello again ACCOUNTS advisors. I’m finally addressing an issue that someone brought up some months back, which is about entering reference numbers (also known as transaction numbers) for transactions that aren’t composed solely of digits, for instance “A1234”, for non-cheque transactions.

Currently the Register window allows such reference/transaction numbers, but warns you that if the transaction is a cheque, this will be a problem. (That message also states “you seem to be entering a cheque” regardless of what transaction type you entered, which seems clearly incorrect.)

In the Write Cheques window, however, although you can change the transaction type, only numeric reference/transaction numbers are allowed to be entered and saved. That needs to be fixed, so that other types of transactions that have non-numeric reference numbers can also be entered on that window.

So far so good. The problem comes in what do about the warning messages. I think it’s clear that if the entered transaction type is definitely for a cheque, and the transaction number is non-numeric, there should be a warning and confirmation question as there is now on the Register window. The transaction types that I’m clear indicate it’s a cheque are CHECK, CHEQUE, CHK, and CHQ. Any others? (I’m wondering about French and Spanish versions. Google Translate says the French is chèque and Spanish is cheque, so that’s pretty simple!)

Perhaps if the transaction type includes “CH” anywhere, or is empty, the warning should say something like “It appears that this might be a cheque …”.

And if the transaction type is anything else that doesn’t include “CH”, there would never be a warning about non-numeric reference/transaction numbers.

Make sense? Any other thoughts? Thanks.

ACCOUNTS Cloud Storage Technical Details

For those of you who have subscribed to the ACCOUNTS blog but not the DONATION blog, we just posted a blog for DONATION that also applies to you. It’s about the technical details of our proposed “cloud storage feature”, that we are doing rather than creating a true web-based version. If you are interested, you can read it and comment on it at:

https://donationusers.wordpress.com/2015/03/24/cloud-storage-details/

Thank you.

Fund Balances and Asset Accounts

Hello ACCOUNTS program advisors. I’m having a discussion with a new user, who is switching to ACCOUNTS from the program Aplos. Aplos does one thing that ACCOUNTS does not do, which is track which amounts in each asset account (like a bank account or investment account) belongs to each fund. The user is having trouble seeing how he can do without that feature, seeing as how ACCOUNTS does not do that at all.

To be clear, this is a situation where the user does not have separate bank accounts for each fund. I know some of you may do that, but as I have discussed with some of you before, I see no real need for that.

My view is that in ACCOUNTS, you know two relevant things: how much total is in each asset account, and what each fund’s current (implicit) balance is. As you may recall, what we call the implicit balance is what shows up as the current fund balance on a Balance Sheet, or Fund Income Statement.

The user is concerned about having an expense that needs to come from a fund, that might exceed the amount of money in that fund in his bank account, even though there is enough in an investment amount to cover it. However, the bank account total is sufficient for the expense.

My argument is, it just doesn’t matter. In my not so humble opinion, there are only two questions to be asked (relevant to the accounting, at least) about an upcoming approved expense that will be from a specific fund. First, is there enough in that fund’s balance. Second, is there enough cash on hand in the bank.

If there’s not enough in the fund balance, you either can’t spend the money, or you put the fund into a negative balance, or you get approval for an inter-fund transfer (which may not require actually moving any money around in bank accounts, unless you keep separate bank accounts for each fund) to cover it.

If there’s not enough in the cash on hand in the bank, you need to cash in some investments (or wait for them to come due so their funds are available), get that money into the bank, and then you will have enough.

But I just can’t see how any questions of which funds’ income made up the current bank and investment account balances needs to come into this (or any other) question.

Can any of you think of anything I’m missing here, or alternatively back me up from your experience? Thank you in advance for any comments.

Rules for Incrementing Cheque Numbers

Hello ACCOUNTS advisors. We have a somewhat subtle design question we’d like opinions on.

It’s about how, when you use Write Cheques, the “next” cheque number is supposed to appear in the Cheque # field as the default. The same should happen when you are in the Number field in a Register window, and press the “+” key.

Our original design for how that worked was that it found the highest cheque number you had used in that bank account in the last 13 months (plus in any post-dated cheques) and showed a number one higher than that. However, a major problem was discovered with that, for organizations that get new cheques numbered back starting at 1 after they pass (say) 999. In that case, it would keep trying to prompt you to use cheque number 1,000, which you don’t have.

So in version 1.14b, released in February 2013, we changed how it comes up with that next cheque number. The new rule was that it would use a number one higher than the number of the latest-dated cheque in that bank account in the last 13 months (including any post-dated cheques).

That worked well for most users, until recently when a user had written a post-dated cheque number 874 for quite a while in the future, then wrote a number of cheques with current dates and of course higher cheque numbers after that. While all of then had numbers higher than 874, the program would always suggest number 875, because it was the latest-dated cheque in that bank account (although it was in the future).

So, what is the right solution? One thought would be to ignore post-dated cheques when looking for the latest-dated cheque. But that will end up prompting you for the same cheque number (874 in that case) when you go to write the very next cheque after that post-dated one, because it would only see 873 in the past. Of course, once you had entered an 875, everything would be OK again.

So, here’s a possible solution, partly suggested by the user who’s having this problem. Have a configuration field, probably in Maintenance -> Main Options, labelled something like “When suggesting the next cheque number, ignore previous numbers higher than: ____”. And set the rule back to the old way: always suggest the number one higher than the highest cheque number in that bank account in the last 13 months (or in the future), as long as it’s not higher than that configured number, if it has been filled in.

This resolves the problem that we made the change in version 1.14b to fix, because if you have wrapped your cheque numbers around from 999 to 1, you just set that configuration number to some reasonable number like 500, and it will not suggest any higher numbers.

And it resolves the problem that the current user is having, because he won’t set that value, and it will prompt for a number higher than any number (past or post-dated) he has used yet.

There’s one remaining problem that I can see – what happens if you set that configuration to 500, and then reach cheque # 500 again? My thought is that if you manually enter cheque # 500 (or any higher number) when that configuration value is set, the program gives you a message about that, and tells you to clear that configured value so as not to have further problems. That should be safe, because the program only looks back 13 months to figure out the correct next number to use, and it’s hard to imaging that any of the previous run of cheques that were numbered 500 or higher would be within the last 13 months, if it wrapped around at 999. (At least, not for the sizes of organizations that are likely to adopt ACCOUNTS.)

One other tiny thought relates to what would be acceptable values for that configuration setting. If someone entered 1, because they didn’t understand the setting, the program would then always suggest number 1! So I think there should be a minimum value, which the user would be warned if they tried to set the configuration lower than. Perhaps 100?

Any thoughts? Anything we may have missed? Thank you in advance for your comments!