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.
Our payment/contribution portal contains an area to designate someone to be notified about a contribution. That has been in place for years. In order to send that acknowledgment letter, the administrator had to pick a name (or names) from a drop-down list. With this enhancement, though, we now offer the ability to search names on contributions, rather than choosing from a pick-list.
Yes, the ability to search names on contributions. The new search box is right above the pick-list. Enter any portion of the last name of the person to be notified; pause one second; and the pick-list will be reduced to only those names that match what was entered.
Here’s a video that shows, first, someone entering a contribution. And, then, the back-office point of view.
This shopping cart tutorial provides instruction on how to set up and use the ShalomCloud shopping cart.
First, a couple of ground rules. If you don’t see the menu options for the cart, we’ll need to set a certain flag. Also, using the shopping cart depends on your organization using the services of our preferred card and ACH provider. The reason will become apparent as you read on — our shopping cart is integrated with the membership and financial aspect of ShalomCloud.
Another ground rule — the shopping cart is appropriate for any fixed-priced items — including zero. In other words, where the visitor chooses an amount to pay, that would go under contributions.
First, setting up the cart. Under the Configuration menu, you’ll see a selection named “Items.” An item has a name, a description, a price, and a quantity available. Also, there is a date after which the item appears for purchase. In other words, before that date, the item won’t appear in the cart. Then, on the flip side, you would archive the item once it is longer for sale. For example, a Shabbat dinner from last Friday.
Finally, there is a field to designate what category to which the funds post.
When someone makes a purchase, then, the system subtracts the quantity purchased from the available count; and posts the monies to the category glued to that item.
To see what people have bought, you’d go to Queries -> Purchases. Here, you can ask for purchases, using any combination of four fields:
Any portion of the family code of the purchaser
Any portion of the item name
Purchased on or after
Purchased on or before.
As with all our queries, you can then download the results.
Last thing — in the video, you’ll see what the cart looks like from the visitor’s perspective. It’s a typical shopping cart paradigm. It has buttons to adjust quantities; to clear the cart; to continue shopping; and, finally, to check out.
When the user completes the purchase, a few things happen:
The purchaser receives an immediate email
Administrators so flagged receive an email about the purchase
If the system recognizes the email or cell phone that the visitor entered, it posts the money to that family.
If the system does not recognize the email or cell phone, it creates the family automatically.
In the video, you’ll see some options when producing the tax letters. For example, you may choose to show payment sources — check number, card last-four-digits, etc.
Another option is whether you want to include all payments, or only those to categories marked as deductible.
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.
