ShalomCloud has five transaction codes, three of which apply to credits. We have PD for payments; FA for Financial Assistance; and AJ for adjustments.
On the debit side, we have OW for general amounts owed, and PL for Pledges. Whether you actually use the term Pledges, or Dues, or Commitments, the idea is the same. PL represents amounts expected from the congregation.
The same arithmetic applies, identically, to both PL and OW. What is the difference, then? Primarily, three cases:
When you do a financial transaction query, instead of picking individual pledge categories, you can use the transaction code “PL” to collect the pledge categories together.
The Pledge/Paid gap graph depends on PL transactions for its numbers.
The Pledges and Paid bar graphs, same thing.
So, given this background, how does this change come into play? When you’re explicitly creating a debit (= receivable), you explicitly choose whether to use OW or PL. However — and here’s the significance of this change — when payments come into the system, whether from the back office screens or from any of the user portals — if there is no debit for those funds, the system creates its own. That system-created debit uses the default OW/PL for the category.
Accordingly, if you now visit Configuration -> Financial Categories, you’ll see a new heading, namely “Trancode on charge.” This is where you’ll select whether ShalomCloud should record an on-the-fly debit as a PL or an OW item. Just go straight down the screen, selecting the radio button PL where it applies. Unmarked categories will default to OW, as they do today.
This is one place where you won’t need a submit button to declare the default transaction code on charge. Clicking the radio button takes effect immediately.
Until now, when you wanted to select people to be notified about a contribution, you had to scroll down the list of all the people in your congregation. And, then, point and click on the one(s) you wanted to notify. Now, you can enter part of a last name. After one second, ShalomCloud reduces the pull-down list to match the name you’ve keyed.
Similarly, for the category of the contribution, you had to point and click. If your categories were fairly small in number, this was not much of a challenge. However, if you have several hundred categories, finding exactly the right one might prove frustrating. Now, you can enter a term, such as “tuition”, into the search box. After one second, ShalomCloud reduces the dynamic pull-down list to match the category you’ve keyed.
By way of explanation — typically, after a pledge drive, or school signups, you’ll record what each family owes. The most direct way to handle those charges, is to book an amount owed per category. For example, $1800 for a pledge, or $500 for religious school. You can include an effective date and/or a due date with each item.
However, we understand that some synagogues prefer, not a lump sum, but to create equal charges over time. Using that $1800 pledge as an example, to bill $200 for nine consecutive months.
Until this change, the only way to create successive monthly (or quarterly) charges was to bill them manually. Now, as you can see in the video below, ShalomCloud handles that automatically. You’ll enter the total amount of the charge, say whether it’s monthly or quarterly, declare a first bill date and a last bill date, and ShalomCloud handles the arithmetic.
One small point — the program handles situations where the total, divided by the number of months, is not an even number of cents.. For example, if you’re making six pledges for a total of $1000, ShalomCloud will create five of $166.67; and then the last one will be $166.65, to come out to the even $1000.
A few points of caution to consider.
Statements will exclude future-dated transactions. So, if you’re running statements on, say, October 5th, and you want to show amounts owed that might be effective-dated October 15th, you’ll need to use a period end date of at least October 15th.
The logged-in member portal will show each of those individual transactions owed. Put another way, showing a single line item for a pledge, would be a cleaner presentation than half a dozen, smaller line items.
Another point — if your intent is to set up recurring payments for the pledge, you’re much better off keeping the amount owed as a single line item. Otherwise, you’ll see a screen like this:
where the top line, a single lump-sum pledge, is clearer to deal with than many small increments.
Nonetheless, if you’re aware of these situations, and consider that incremental billing fits your situation, feel free to use it.
You can now remove items from the Selected Journal Entry screen.
If you’re a QuickBooks Desktop user, you’re likely familiar with the Selected Journal Entry screen. This panel shows the items posted to ShalomCloud since the last push to QBD. From its inception, you could pick and choose which items you wanted to summarize and send.
However, if for some reason you wanted to permanently remove an item from that screen, you had to contact ShalomCloud support. Otherwise, the item would stay on that screen. Now, though, the right edge of the screen has a link to Remove the item. This does not delete the transaction altogether. Instead, it just marks it with a faux batch code.
On the other hand, if you removed an item and want it put back into the SJE screen, there is a way. Namely, you would do a financial transaction query to find the item, edit it, and check a box to remove that faux batch code.
You now have the ability to specify where you’d like the family’s address to appear on the statement. You can be as precise as you’d like, down to 1/72nd of an inch. Thus, you can now configure window envelopes with precision.
Second announcement — if you use the option to include recent payments on the statement, the payment line now includes the transaction description. We’ve always shown the date, the category, the amount, and the source of funds. Now, though, we show the description, if entered within the item.
We now have a convenient, straightforward way to handle those situations where you have a third-party payer. By that, we mean cases where your congregant owes for dues or school, for example, and someone volunteers to pay on their behalf.
To enter the third-party payer, you’d use the same screen as always. There’s simply a new field, roughly in the middle, to select the family who is making that payment.
On the financial transaction query, you’ll see the family name of the payer in the “source of funds” column. Likewise, that information appears on a spreadsheet export.
We’re rolling out a new feature for statements, dubbed “Link to Pay.”
Some background. For some time now, we’ve offered the ability to send statement notifications by email. The statement notification has a link, that enables the congregant to pull down a statement. That statement is exactly what would have appeared if you’d printed it in the office.
Similarly, we offer a member portal. With a user id and password that we generate, any of your members are able to log in, edit family information, pull statements, and conduct financial transactions. Included, too, is a member search.
This new feature, “link to pay,” combines these capabilities. Within the emailed statement notification, you may include a link that automatically logs the person into the respective account. No password needed. In fact, it goes one step further. It sends your congregant directly to the payment page within the member portal.
ShalomCloud now creates automated emails to contributors. Well, not only contributors, but also people paying any kind of commitment. And, also, payments made from the ShalomCloud shopping cart.
Some background: originally, ShalomCloud was strictly a back-office utility. Appropriately, it tracked membership, Yahrzeits, and commitments and payments. Primarily, office personnel recorded those payments, most of which arrived via paper check. Also, ShalomCloud offered, and continues to offer, a way to produce acknowledgement letters.
However, as people have become more and more accustomed to making online payments, ShalomCloud has expanded beyond a back-office program. Accordingly, we offer three different windows for payments. There is a pure payment portal (login not required), a logged-in member portal, and a shopping cart. Again, to keep pace with what perhaps has become an expectation in this digital society, we now generate immediate acknowledgements via email, for each of those three windows into ShalomCloud.
One thing more, not shown in the video. You can designate the sender of those emails. By default, the sender will be [email protected] However, after logging into the system, if you go to Home -> Declare synagogue options, you’ll see a place to declare the “Default email from.” We will need to verify that sender email address, just be aware.
You can now search financial transactions using a wildcard, or key-word, for the category.
Especially for those of you converting from a legacy system, you may find yourself with hundreds of financial categories. Worse, the naming convention may have differed from year to year, especially if the fiscal year was part of the category name. We’ve seen lists such as
18-19 Senior Dues
2018-2019 School tuition
Young couple dues, 2018-19
With that sort chaos in the naming convention, it’s time consuming to try pinpointing several related categories in a sorted list.
With today’s change, you can merely type a keyword or phrase into an area labeled Category wildcard.
When accompanied by fiscal year, this gives you a powerful and quick way to focus on a set of transactions in related categories.
Feel free to enjoy this short (3m 26s) video, demonstrating this ability to search financial transactions using a wildcard in the category.