If you take advantage of the integration between ShalomCloud and QuickBooks Online, you may take a keen interest in this post.
First of all, if you’re not familiar with class codes, you may find this article from Intuit to be instructive.
With that background in hand, know that our connection to QBO now supports designating a class code for each financial category.
Here’s a video that demonstrates the use of class codes. This short illustration shows both the ShalomCloud posting, and how it’s reflected in QuickBooks Online.
ShalomCloud now has the ability to send statements, for specific categories that you select.
Until now, every statement was all-in. That is, it showed everything owed per family. Thus, you could not produce a statement for religious-school only, or cemetery-only.
Now, you can select one or more categories to appear.
To see a short (3m 7s) video of this feature in action, please follow this link.
We have two unrelated, and relatively minor, enhancements.
First — on the trend report. For those of you unfamiliar with the trend report, it’s a running total across the last six years, of charges and credits per family. You choose which categories you’d like to see on the report. What have we enhanced? The trend report consists of one line per family unit. Formerly, each line started with the family code. Now, you’ll see both the family code and the formal name.
Trend report snippet
(By the way, all names are fictitious.)
The second enhancement resides in Queries -> Financial Transactions. Here, the very first filtering criterion, Fiscal year, had been limited to one fiscal year only. Most of the time, you can select the data you want by filtering on a range of effective dates. However, there are times when activity might occur before your next fiscal year starts, yet you want to attribute that pledge or payment to the forthcoming fiscal year.
In those cases, you may well want to select a range of fiscal years, instead of entering a range of dates. That is now possible:
Until now, the ShalomCloud shopping cart contained strictly fixed-price items. Shabbat dinners, Lulav and Etrog sets, classes (whether free or not) are some examples.
However, sometimes you’ll have a set of prices for an event, perhaps with various sponsorship levels. Aha, but if anyone wanted to register for the event, but remit something above, or between, the fixed sponsorship levels, you couldn’t do that with the shopping cart. Instead, you’d have to use the donation button.
With this announcement, you can designate shopping cart items that have a “fill-in-the-blank” price.
By the way, your existing shopping cart items are unaffected. By default, they are fixed-price.
With tax season just around the corner, you may be interested in one new tax letter option.
Previously, when you produced tax letters, you had the option to include what we call “source of funds.” Meaning the check number, or last four digits of the card, or some bank account info. You could also omit that column, and simply show the date, the category, and the amount.
If you’d like to view a basic tax letter tutorial, please visit this link.
What’s new? One new choice — instead of the source of funds, you can now choose to show the transaction description — typically phrases such as “in memory of” or “in honor of.”
By the way, this option holds, whether you print and mail the tax letters, or choose to send them via a personalized link in emails.
This is a tutorial on the subject of credit on file. Credits on file are funds that you’re holding to be applied later.
There are two main ways that these funds originate: One way is typically toward the end of a calendar year. Somebody might send in a check, typically for tax purposes. Their intent is to instruct you in months to come, where to apply those funds; perhaps after the next pledge campaign, for example.
More frequently, though, is the case where you’ll have recurring payments. Toward the end of the recurring payment cycle, the respective charges are completely paid. In that case, the system places the extra funds into the category that we’ve dubbed Credit on File.
The question then is what do you do with that? How do you go about applying it? And we’ll run through a simple illustration in the accompanying video, using the fictitious Davis family.
We’ll see that they do owe some modest sums for dues. And if we skip all the way to the bottom, we’ll find that they have some credits on file left over from recurring payments over-payment.
To “draw” on the credit on file, we simply put an amount into the category that we wish to pay; and then, instead of a check, card, or bank account, we key that amount next to the credit on file balance.
ShalomCloud has for years been able to print labels. That is true both for individuals and for family units. However, until now, the labels were strictly mailing labels. That is, the program always printed the mailing address onto the label.
With this change, you now have the choice of printing name-only labels — excluding addresses. For family units, that name can be the formal name (“President George Washington and Mrs. Martha Washington”), or the informal name (“George and Martha”), or the informal label (“George and Martha Washington”). For individuals, it’s the title, the first name, and the last name.
A few possible uses for name-only labels: seating for a community Seder; badges for social events; badges for religious school, to name a few.
Here’s a short video showing the two places from which you can produce name-only labels.
You now have the ability to point a link or button to a specific item in the shopping cart.
ShalomCloud has offered a shopping cartfor some time now. That enables simple event registration, and the purchase of fixed-priced items. That could be classes, high holiday tickets, Hamantaschen, Siddurim–really anything with a price, including zero.
However, we’ve received feedback about the desire to point to a specific item in the cart, instead of showing all available items. That’s what this change provides.
Here’s how it works — when you’re configuring your items in the cart, you’ll see here and there a “Show” link. By selecting that link, you’ll see a new field, labeled Direct link. By using a button or link — on your web site, or in an email blast, for example–and directing people to that direct link, only that one item will show in the shopping cart.
For an extra layer of security, you may now take advantage of our one-time password capability.
One-time password? What’s that? Until now, logging into ShalomCloud was a matter of entering an email address and a password. That is still the default.
However, if you enter the synagogue options panel, you’ll see three choices: To not use OTP, or to require OTP for all, or to have OTP be an individual option.
If you opt to require OTP, everyone logging into ShalomCloud will see a second login screen. At the same time, the system will send that user a numeric code, to the logon email; and, if there is a cell phone in the user’s profile, the system will also send the code via text message.
If you make the second factor an option for your synagogue, then you’ll use a checkbox for each individual who prefers to log on via both email/password, and the six-digit number sent via email and/or cell.
Please follow this video to see how to put this capability into action.
Process Flags
Some possible future enhancements:
Offering a preference between cell phone and email, to receive the code. For now, since cell phone is a new field in the user record, we’ll send to the email always, and the cell phone if it’s there.
Offering authentication via a phone app, such as Google Authenticator or Twilio Authy. This would mean scanning a bar code with your phone, and then using the phone app to retrieve the login code. This is considered a more secure way to implement MFA (Multi-Factor Authentication), but more complex.
