With the ShalomCloud form builder, you can declare certain questions as auto-bill. This means that, depending on what the user selects, ShalomCloud creates an amount owed. Example — membership type, like this:
Family membership $2000
Single membership $1000
Senior couple $1200
What has been happening on occasion, is that either both adults in a household respond to the form — or the same person responds a second time. The result would be double-billing. Two family memberships, in the above example, for a total of $4000.
Now, with this safety check, when someone accesses a form, the system checks whether anybody in the household has already submitted the form. The system provides the name of that person, and the date of the previous form submission.
One caveat — this is just a warning. That is, it does allow the 2nd person to continue with the form. Why? At this juncture, we are leery of stopping those cases where, perhaps, someone didn’t fill out the form completely, and just wants a do-over. Depending on how this plays out, we can consider preventing the subsequent submission.
Also — we have not yet applied this logic to school registrations. Most assuredly, it needs to be there, but we opted to put this portion of the enhancement into production.
We’ve expanded on the already-available, but not widely publicized, ability for ShalomCloud to manage the process of assigning honors. This pertains primarily to the High Holidays, but could be used for any set of honors.
There a detailed tutorial available, which may serve better than this text description. Nonetheless, here goes. With this feature, you can
Nominate people to carry out various honors.
Track the status — accepted in person, accepted virtually, declined — whatever terminology you’re accustomed to using.
When assigning honors, ask for a specific last name, or by anyone who has not already been assigned an honor.
Obtain a spreadsheet, with contact information, of who has not received an honor.
And on the query side,
Obtain a list of honors for which there is no assigned person.
Ask for those who have been offered an honor, but who have not yet responded.
From that list, send formatted emails, with the specifics about the respective honor.
Obtain a list of those who have accepted an honor, and email a formatted reminder, replete with details about the honor.
We have two new small enhancements regarding the “Turnaround Document” — so-called because, when you send it to your congregation, they it turn it back in, with additions and corrections. We’ve had this capability for three years (https://blog.shalomcloud.com/2020/03/18/the-turnaround-document-2/), but it’s worth going over again.
First of all — if you’re not familiar with this term in ShalomCloud, perhaps it’s best to view the tutorial. That will cover what it is, what purpose it serves, and how to send it to your congregation. Basically, it’s a document that can either be sent via postal mail, one per family, or by email. It displays every piece of non-financial data in ShalomCloud on behalf of that family, with a place to write in additions and corrections.
The two new aspects of the turnaround document are:
Including the three emergency contact fields — a name, phone number, and email address.
A place to put a free-form message, after the individual members of the household, and before the Yahrzeits observed by anyone in the household.
Until now, the items in the shopping cart consisted of the name of the item, a description, and a price. (By the way, that price could be zero, or could be user-determined). All well and good. But — what if you needed to collect some additional information from the “buyer”?
For a class, the names of the attendees
Same thing for a community Seder
If you’re selling Hamantaschen, who will be picking up the order?
If you have asked for that additional information, when someone places that item into the cart, the program will provide a place for the response.
In turn, the purchase queries include the question-answer pair.
Last item of note — the email to the “buyer.” Thinking that, more often than not, those emails will appear on a cell phone, we’ve formatted the response to appear vertically.
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.
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.
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.