I recently noticed you can now do e-Receipts in web view - which would be a huge improvement over our current database view e-Receipt process, which is very slow and frequently crashes. However, there are three areas that are thus far insufficiently developed, preventing us from being able to switch to the web view feature yet.

The first area is filtering. Currently, the ability to select the gifts to receipt is extremely limited. You can select Filters, where you only get three criteria to choose from: Gift Date, Gift Amount, and Fund. Or, you can manually select gifts displayed in the list. For us, this could theoretically work if only we had more options in the filters, such as Batch Number, Payment Method, or even the ability to use a Query (which is how we do it in database view currently, using the <ask> operator on Batch Number). On the other hand, the ability to manually select gifts seems promising at first, as there are a number of useful fields displayed in the list - including Batch Number. However, there is no way to sort the listed gifts; even clicking on the column headings doesn't change the sort order. Theoretically, even if we could just click on the Batch Number column heading, that would be enough for us to go and find the gifts we need to receipt. But as it is currently set up, this area is just far too limited and there's no way for us to reliably find the hundreds of gifts we need to e-Receipt.

The second area is the handling of the email addresses to use for each Constituent. As we all know, email address handling can be complicated, and people over time change emails, or sometimes have multiple addresses they want you to use for different situations. We have invested a lot of time in database view managing these complex issues, and as a result we have an intricate system of Email Types that have historically supported our handling of eReceipts. In database view, the eReceipts parameter gives you great options for email type handling. We have a priority system where first it checks for a type we created called "Email receipt"; then if that's absent, it moves on to Email 1, Email 2, etc. This is very logical, and the database view parameter allows you to do all this. Well... the web view feature has no options whatsoever for handling Email Types. From my testing of the feature, what I have learned is that it looks up the table of Emails listed on the Constituent's Bio 1 tab, and it simply grabs the email listed in the first ROW of that table. I don't know about other orgs, but for us, since we are longtime RE users, these tables can get crowded. Given the usefulness of the Email Type table feature, we have not prioritized paying attention to the literal row order in the email table; in fact, given the way data entry naturally happens, it makes sense that the older or less-likely-to-be-preferred email addresses are likely to occur at the top of the table. So, if you're going to have all these features like a "Primary" checkbox and Email Types, why would you ignore them and default to something that's likely to be the oldest (thus, outdated) record?

The final area is the email template. Specifically, the available merge fields are very limited. There are only three categories of field to select: Constituent, Gift, and My Organization.

The Constituent category only has three options: First Name, Last Name, and "selected name format". The latter refers to a setting you have to set elsewhere in the options, which forces you to choose one type of Addressee/Salutation for all receipts. The problem here is, what if I want the Constituent's Addressee at the very top of the receipt (full formal name, for IRS tax deductible receipt purposes), then I want their Informal Salutation down in the body where we greet them ("Hi Sara, thanks for your gift...") And what about Nickname? What about the Constituent's address? I believe the IRS likes to see address, too. This doesn't meet our needs for Constituent Info.

Then there's the gift info, and this is where we get some major problems. I would not consider our needs to be overly complicated. But our donors DO need to see the split gift info so they know how their gift was credited. Now, there is a field called "Fund", but this option exports only a list of the Fund Descriptions, without the breakdown of the amounts for each fund. Strangely, the only way to get the list to include the Amount for each Fund is to select the merge field "Transaction details". BUT, this field spits out a long list of all sorts of info - and, very problematically for us, the first piece of info shown in that list is what web view likes to call the "Gift Type". I say this because, as old-school RE users will know, web view has oddly dismantled the actual database view Gift Type table. In our case, what ends up happening here is ALL our gifts end up being labeled as "One-Time Gift" by this field - even the recurring ones! Because we don't have BBMS or use Recurring Gift types due to their complexity, we enter our recurring gifts in similar fashion to one-time gifts. Of course it would be incredibly confusing for our recurring donors to receive an email stating that their gift was "One-time" when in fact it was not. So, what we're left with is an unworkable situation. If only you could get the Fund split amount details as its own field instead of needing the full "Transaction details", we could clear this piece.

Finally, the My Organization stuff is not really relevant because it's stable information, so why wouldn't you just type that info hard coded into the message body? Well, that's what I've done anyway.

Again, it's very encouraging to see that Blackbaud has continued to develop more features in the web view - but in the case of email receipts, it seems like again something very basic was released without sufficient testing or consideration as to what organizations actually need to do with those receipts. Once the filtering and the available merge fields are further developed, I'm sure this will be a useful feature.