We are a group of users of Blackbaud products and are not affiliated with Blackbaud. We'd love to have you join our community to help and be helped in getting the most from your Blackbaud software.
Register now to join us to get independant advice on your system, connect with 3rd party consultants to help you maximize your database and have a real alternative to the official Blackbaud website.
Has anyone had any issues with quick letters where you're using HOH processing as well as segmentation with several input/output queries?
We're running a mailing with several segments and the output queries being generated include both the HOH in one segment and the NON-HOH record in another -- and the non-hoh has been eliminated from the quickletter output itself.
Have a case logged with blackbaud and they initial indicated that issues were because we weren't on the latest release. I then went back with additional questions around how HOH & segmentation priority impact each other (ie. non-hoh in a higher level segment than HOH spouse -- which segment would the couple end up in...) and was told
"After testing this issue, it appears the program is functioning as designed. Head-Of-Household processing has no way to recognize, when going through each segment, that the HOH is in a query in another segment not run yet. If a non HOH is in a segment prior to the HOH they will be included in the output query. If the HOH appears in a segment first, the non HOH should not be in the output query."
Doesn't address why the quickletter output is able to eliminate the non-hoh from the overall results...
Anyone had any similar issues -- very worrisome to me as quickletter output does NOT refect the results of the output queries & appeals/packages are being assigned to some non-hoh records that have been excluded from the letter itself...
I am trying to follow your issue and it appears to be one I identified one time earlier.
In quick letters you can have RE add the assigned appeal and I noticed that although th letters being produced was only going to the HOH both records (including the non-HOH) were marked with the appeal code. (which I did not want).
I believe I was on an earlier version and I believe that it was identified as an issue to be resolved and I think it was (my memory is foggy but I hope and assume it is working now)
This must be a similar issue where the record is being marked with the static query code (which is how static queries work in the background) just like they were being marked with the appeal.
I HATE the excuse it is "working as designed" because all that means to me is that they designed it wrong and don't plan on fixing it.
We also have this problem. What we do is include soft credits in our initial query. This way both the spouses are in the same query. When you run quick letters to de-dup the both of them get left in the higher query but are removed from the other queries. When I export, I only export HOH and only one record gets exported.
I guess this only helps if you use the soft credits.