Memos on Transactions

Hello again ACCOUNTS advisors. Long time no communicate!

Someone has raised a question about memos on transactions. He was concerned when memos he entered on transactions (such as say a direct purchase entered on a bank account register window) didn’t show up with the counter account’s details for that transactions in a report such as Reports -> Details -> Transactions by Account.

The reason for this is that memos are attached to splits lines in transactions, not the transaction itself. Each transaction includes at least two splits (a debit and a credit, technically). With a purchase entered on a bank account’s register window, the memo you enter on the register window itself gets associated with the split line for the bank account (the credit), but no memo gets associated with the expense account you enter (the debit). You can fix that, by opening up the splits window and entering a memo there, but obviously that is extra effort.

The reason I designed it this way is that I think expecially for complex transactions with multiple splits, you might want a different memo on each split line, to better explain that particular line. (Plus, other programs seemed to do it that way too.)

The user who brought this to my attention has made a suggestion, which I’m considering, and want your opinions on. The suggestion is that when you enter what is apparently an overall memo for the transaction (because it is the one entered directly on the register window, or on a special purpose data entry window like Write Cheques, Enter Deposits etc.), but you don’t enter other memos for the counter account(s) / splits, that memo should get automatically copied to the other splits lines of the transaction.

I see this happening at the point that you choose to save any such transaction. If this change was made, there would also be one-time fixup of your existing data done by the new version of the program, to make it be like that. I.e. when the first split line in a transaction (which is the one you entered on the register window etc.) has a memo, copy that memo to any other splits lines in the  same transaction that are current empty.

Your thoughts? Any drawbacks? Thanks.

Indenting of Amounts in ACCOUNTS Reports

Hello again ACCOUNTS advisors.

I’ve had a user complain that she didn’t at all like the way the dollar amounts are indented in reports such as the Income Statement or Balance Sheet, to show the sub-account levels. She would have preferred all of the amounts to line up perfectly vertically. (She was fine with the indenting of the account names.)

I designed it with the indenting because I think it better allows you to see what adds up to what – everything that adds up to the same total below it is lined up, but things that add up to subtotals are indented to the left a bit.

Please let me know if you have any significant preference one way or the other for the two designs – amounts indented by sub-account level, or completely lined up. Or, if you feel it would be important to provide an option to the users to have it either of the two ways.

Thanks!

Building Fund and Mortage Payments

Hello again ACCOUNTS advisors.

I had a question from a user in a church yesterday, which has a Building Fund, and a mortage on their church building. As usual, the mortgage payments are made up of a principal component (which reduces the long-term liability account balance for the mortgage) and an interest expense component.

She was hoping that the principal component would reduce her Building Fund balance, but of course it doesn’t, because in my design only income and expense accounts can be linked to fund accounts. (The interest component would of course reduce the Building Fund balance, because its account would be linked to the Building Fund account.)

In some ways I can see what she is thinking. If $1,000 has been donated to the Building Fund, to help pay the mortage payments, and an $1,000 mortgage payment is then made (perhaps composed of $100 principal and $900 interest), one might indeed expect the Building Fund balance to be reduced by that $1,000, since the money was spent.

Does anyone have any bright thoughts on either how to explain why this is not appropriate, or how to make it happen in terms of what the splits on the transaction could be? I’m afraid that I don’t.

Thanks.

ACCOUNTS drop-down lists of accounts

Hello again ACCOUNTS advisors and beta testers.

There’s something about the design that I’ve been wondering about, that I’d like your opinions on.

In drop-down lists of accounts, such as in the register windows, the Write Cheques window etc., the account names are indented according to whether they are top-level accounts, sub-accounts or sub-sub-accounts. However, no parent accounts are shown, because it’s only accounts that have no sub-accounts themselves that can have transactions posted against them, and thus only those accounts are shown in the drop-down.

This could be considered to be misleading, because if you (say) have a top-level account (call it A) that has no sub-accounts, and the next account in the drop-down list is a sub-account (call it B) of a different top-level account that isn’t shown (call it C), the indenting makes it look like that sub-account B is a sub-account of A, rather than of C that isn’t shown.

So, I’m wondering whether I should stop indenting account names in drop-down lists, unless there’s a case where all accounts are being shown in that drop-down list, not just ones that you can post transactions to. (I’m not sure there is such a case in the program so far.)

Opinions? As always, you can reply to this post online, or just email me your thoughts. Thank you.

ACCOUNTS version 1.04 testing – Memorized Transactions

Hello again ACCOUNTS beta testers and advisors.

I am preparing to release version 1.04 of ACCOUNTS, which has a number of fixes and improvements. The most relevant changes since version 1.02c (the last announced release) are:

  • Added Memorized Transactions capabilites in the register windows, through right-click menu options. You can memorize everything except bills and bill payments entered with the special features for Enter Bills and Pay Bills, and your Opening Balances transaction.
  • Added the Database -> Delete All Transactions menu option (for optional use after initial testing).
  • Added Reports -> Details -> Transactions by Payee / Description.
  • Added right-click menu options in the register for Edit Bill and Edit Bill Payment.
  • Added a “Name for Cheques” field in the Vendor details, which is what gets printed on cheques if it is present and different from the Vendor’s Name field.
  • Journal Entries and Opening Balances transactions displayed on a register window are now basically non-editable, except with the right-click menu options are Ctrl+E.

If those of you with a bit of time and the interest could try this version out and let me know what you think (positive or negative!) about the changes and your testing experience, it would be greatly appreciated, and hopefully ensure that the official version I will release to all users will be as bug-free and well-designed as possible.

You can get this beta test version, as usual, from http://www.software4nonprofits.com/accounts/pretest.htm.

Thank you.

ACCOUNTS register changes questions

Hello again ACCOUNTS advisors.

Some of you may have already noticed that in the just-released version 1.02c of ACCOUNTS, I made a change to the right-click menu option “View as Journal Entry” in the register windows. If the transaction you are right-clicking over is actually a journal entry, it changes to “Edit Journal Entry”, and if the transaction is your Opening Balances transaction (entered via Actions -> Opening Balances) it changes to “Edit Opening Balances”. In both cases, if you pick that menu option you get to actually edit and save changes, not just view a non-journal entry transaction as if it were one.

I think that change is obviously good. My first question after that, then, is whether with this now made available, both journal entries and opening balances transactions should become non-editable in the register. To me, that makes a fair bit of sense, because many of them won’t be editable in effect anyways, because they may include both fund accounts and non-fund accounts, and you cannot save changes to any transaction like that in the register. (The Number field would be left editable, as with Bill and Bill Payment transactions in the register, because for technical reasons if there is no editable field at all in a row, you can’t click into it or even right-click in it to pop up the menu!)

I think that I should also add an additional right-click menu option “Edit Bill” when you right-click on a register transaction that is a Bill, or “Edit Bill Payment” for a bill payment. (This would save having to go and find those transactions in the Bill List or Bill Payment List windows, if an edit was required.) Do you agree?

The final question, which I am less clear on, is whether for transactions that appear to be cheques, deposits, or credit card charges (in a register for a Credit Card account), I should add a right-click menu option for “Edit as Cheque”, “Edit as Deposit”, or “Edit as Credit Card Charge”. It makes sense at first look, but on the other hand, there is really nothing gained by doing that – all of the same fields are available for editing those types of transactions in either the register, or the register splits window, and with basically the same field names. And it’s not as if the presentation is in any way significantly different (as when editing a journal entry or opening balances transaction, where you change to viewing things as Debits and Credits). So, do you think I should add “Edit as Cheque” etc.?

Thanks for your thoughts on this.

Important ACCOUNTS Reports Update

Hello again ACCOUNTS beta testers and advisors.

A few days ago, a user testing ACCOUNTS helped me discover that many of the reports had subtle but rather unfortunate problems They could display extra lines with names of accounts (but no dollar figures) that did not belong on them. And they could fail to display header lines for parent accounts of sub-accounts (or sub-sub-accounts) that were displayed with dollar figures, when those headers should have been displayed.

This applies to the Income Statement, Income Statement Yr/Yr Comparison, Balance Sheet, Budget Comparison, Fund Income Statement and Trial Balance reports. I feel terrible that these errors were not found in the testing process. (The good news is that all accounts with actual dollar figures that were there were correct, and all of them that ought to be there were there, and the totals were all correct!)

There were also a couple of other minor issues with the Trial Balance reports – $0 could sometimes be displayed in a Credit column when there was a real value in the Debit column, or vice versa. And some funds that had no direct transactions (or transactions on linked income or expense accounts) could appear with $0 balances, when this report is supposed to omit any accounts that have no data whatsoever.

This is all fixed now (in version 1.02 Beta2), and I will release it and announce it by email as an official version to everyone who has registered ACCOUNTS tomorrow or Tuesday. If those of you with a bit of time you could check it out first, to make sure nobody sees anything that still isn’t fixed properly, that would be greatly appreciated. You get it from http://www.software4nonprofits.com/accounts/pretest.htm.

The other significant changes are following from the two recent posts on account selection, and other user’s further suggestions:

  • Changed some of the behaviour of most fields for selecting an account (unless there are usually only a few options, like in the top part of the Write Cheques, Enter Deposits, Credit Card Charges or Enter Bills windows). First, the fields now drop down their lists automatically, as soon as you Tab or click into them. Second, if you press a letter, it immediately goes to the first account that starts with that letter (as it did before) but it also re-sorts the list in alphabetical order, to make it easier to see and select other accounts that start with that letter. If you press Backspace after that, or Tab out of the field, the list is returned to chart of accounts order.
  • In the Enter Deposits window, when the Account drop-down is first displayed for an Account field that current has no value in it, the list is scrolled to show the first Income account for you.
  • In the Write Cheques, Credit Card Charges and Enter Bills windows, when the Account drop-down is first displayed for an Account field that current has no value in it, the list is scrolled to show the first Expense account for you.

Thank you in advance for any testing results you can share with me!

Account Selection, Take 2

OK, I am trying something different, that simplifies selection by name. The change is only in the register window so far, but I want to know what you all think of it, to see whether I should keep the change (and if so, make the same change pretty much everywhere you can select an account).

This is the change:

In register windows, when you move into the field for the account (in the register itself, not the register splits window), the drop-down immediately drops down. And if you press a letter key, for the first letter of an account name, it immediately re-sorts the list alphabetically, so that you see accounts in order that start with that letter, making it easier to select them if the first match wasn’t the one you wanted. (If you don’t press a letter key, the accounts are still in chart of accounts order.)

If you have time and interest, please try this out from http://www.software4nonprofits.com/accounts/pretest.htm, and let me know what you think. (And if you don’t have time, but have a comment on the idea, that’s OK too!)

Thanks!

Account selection by Number

I have had a request from a potential user to be able to select accounts for transactions by typing the account number, rather than selecting from the drop-down list, or pressing first letters of the account name until it comes up (the two current options).

The problem with this is that it changes the account selection fields from ones you cannot type in, to ones you can type in. If you are going to be able to type in them, it only makes sense to change it to an “autocomplete” type field, like the Payee / Description fields, where you start typing an entry and matches come up. That would have to work whether you start typing a number, or start typing an account name.

There are a couple of problems I see with this, that I’d like your input on.

The first is that it could actually make the selection of some accounts by name much harder. Think about if you had three accounts named “General Fund”, “General Fund Income”, and “General Fund Expense” (or, obviously, anything other sets of accounts whose names all start similarly). As you started typing say “Gen”, “General Fund” would pop up. To get to one of the other two, you would have to click to the end of that field, or press the End key, and then continue typing. (Or, if you don’t figure that out, you’d have to type the whole common part, before you could start distinguishing it!) That’s confusing and slow.

The other problem is that suddenly validation is needed on the account entry, because you can type in something that’s not on the list. One option would be to ask whether the user wants to add that new account name (or number!), but there’s already a mechanism for that (the <Add New> entry on the list), so I’m not really inclined to add a 2nd way. So that means there has to be a message as they leave the field, saying something to the effect of “Sorry, that account isn’t on the list, please enter or select something that’s on the list”.

Now, one option is to stick with the current method (no typing, only first letters) for users who want to select accounts by name (which I think will be a large majority of users!) and switch to the autocomplete method for those who want to do entry by number. There would have to be an option added to Maintenance -> Main Options to control that switch. But I’m not crazy about the idea of their being two rather different data entry methods available for the same fields.

Thoughts? Thanks.

Comments on draft ACCOUNTS announcement?

Hello again ACCOUNTS advisors.

I have drafted an email announcement of the official release of version 1.00 of ACCOUNTS, to be sent out tomorrow morning (Thursday November 1st). It is at http://www.software4nonprofits.com/AccountsReleaseDraft.htm.

If you have any suggestions for improvements to this draft, they would be most welcome. It’s a tricky balance between too much and too little detail.

Many thanks!