[Anne Marie]

Hi

I've created an Idea based on BB KB 218331 - Unable to Automatically leave the Gift Constituent Code Field Blank - when adding gifts.

Right now RE automatically assigns the Primary Constituent Code to every gift (located on misc. tab in gift record).

I would like the freedom to "turn that off" so that the field is left blank. In other words, users could choose whether they want the constituency code on a gift left blank, or defaulted to the Primary constituent code on Bio 2.

Vote if you'd like. I've added myself to the list - Ha! We all know what THAT means...........

Thanks

[DrewAllen]

I vote NO!!! Absolutely not! (One of the flaws with the Ideas section is that you cannot actually vote "No.")

First, what does it mean to have a blank gift constituency? If it has a specific meaning, you are betting off supplying a code that relays that meaning so that it is clear to other people.

Second, it should not be a user option. If you want to make it a configuration option, that would make it (only slightly) better. I would still vote against it.

What do you hope to gain by implementing this feature? It won't save you time, because it's already an automatic process. It won't save you much space, because it's only takes one more byte per record.

On the other hand, you lose a lot! The gift constituency gives you a much finer level of control than the bio constituency. If you allow blank constituencies, you run into problems with reports. You don't know whether they were intentionally left blank or whether you should go back and try to fill them in at reporting time.

If you really, really want this, I would suggest the following options.

When adding gifts on constituents with multiple current constituencies:

• Use the hierarchy on the constituent.
• Use the hierarchy on the table.
• Prompt the user to choose the correct code.

I'd like to see more of the reasoning behind implementing this before voting on it.

Drew

[Melissa Siobhan]

I completely agree with Drew - NO WAY! As I have been discussing in several other threads on constituent codes sometimes in some reports the only way you can accurately report on giving by constituent codes is to use the one on the gift.

If you are using constituent codes properly and your primary constituent code is a true reflection of the code the constituent had at the time they made the gift - what is the harm in adding it to the gift. It is going there automatically so there is no extra work. Should you choose not to use it that is completely your perogative but I would not want it to ever be shut off on my database by a user or even by myself accidentally.

If you are not using constituent codes as they are intended to be used by RE I sure do hope that BB does not change the functionality of the database to cater to "off-label" use of constituent codes.

[RezaIslam]

I'd like the opportunity to address "whats the harm" in adding GFCons to the gift. We do not use Gift constitunecy Codes at all, that we is we do not report off it. Although we do use the Constituency Codes on the Bio2. With 1.5 million constituents, one of the problems we have is that there are many "inactive" consCodes, but there are issues around marking them as such. Here's why: When using the batch process to auto-generate gift rows (from 8K to 20K gifts), if the Recurring Gift has a constituency code (which is inactive) then the gift row appears as an exeption. This essentially means that we cannot collect our regular gift from the donors bank...Immediate financial loss.

A tedious work around is that, I use a SQL stored procedure to construct an RE Gift update Import File, which basically wipes out the "GFCons" values. This is long-winded and it's unfortunate the software does not presently allow/consider clients that may use Bio2ConsCodes but not use GiftConsCodes....

To summarise, I would welcome the flexibity to turn this costly feature off!

thanks -
Reza Islam | Senior Database Analyst
The Children's Society | Edward Rudolf House | Margery Street | London | WC1X 0JL

[Melody Penner]

Hmmmm??? Why are we getting some blank gift constituent codes? We do report on gift constituency and once in a while there are blank gift constituencies. We implemented a regular check for this prior to running reports. In config it is not an option to turn the check box on (or off) to make this a required field. Are we missing something that our gifts are not defaulting to the primary constituent code? I just checked and we have 5 pay-cash gifts that do not have a gift constituency.

[DrewAllen]

Quote:

Originally Posted by RezaIslam

I'd like the opportunity to address "whats the harm" in adding GFCons to the gift. We do not use Gift constitunecy Codes at all, that we is we do not report off it. Although we do use the Constituency Codes on the Bio2. With 1.5 million constituents, one of the problems we have is that there are many "inactive" consCodes, but there are issues around marking them as such. Here's why: When using the batch process to auto-generate gift rows (from 8K to 20K gifts), if the Recurring Gift has a constituency code (which is inactive) then the gift row appears as an exeption. This essentially means that we cannot collect our regular gift from the donors bank...Immediate financial loss.

I assume that you mean that the codes are marked "Inactive" in the code table rather than that the code on the constituent has an end date. Without knowing the details, it seems strange that you would have primary constituency codes that are inactive. The constituent codes represent the relationship the constituent has with your organization. If they have a current relationship with your institution, they should have an active constituent code as their primary. (Yes you may want to use inactive codes for historical purposes, but these should not be the primary codes.)

Again, without knowing the details, it looks like you are using your bio2 cons codes incorrectly, and that is where the problem lies. I don't think that it's a compelling argument to change the way gift cons codes are handled, because it breaks when someone uses bio2 cons codes incorrectly.

Drew

[RezaIslam]

Quote:

Originally Posted by DrewAllen

I assume that you mean that the codes are marked "Inactive" in the code table rather than that the code on the constituent has an end date. Without knowing the details, it seems strange that you would have primary constituency codes that are inactive. The constituent codes represent the relationship the constituent has with your organization. If they have a current relationship with your institution, they should have an active constituent code as their primary. (Yes you may want to use inactive codes for historical purposes, but these should not be the primary codes.)

Again, without knowing the details, it looks like you are using your bio2 cons codes incorrectly, and that is where the problem lies. I don't think that it's a compelling argument to change the way gift cons codes are handled, because it breaks when someone uses bio2 cons codes incorrectly.

Drew

Because we're a 125 year old charity, there are numerous "constituent codes" on the database. Not all the constituent codes are relevant today (but we know what they all mean!). Marking them as inactive through the code table is really what we should be doing because users continue to apply these old codes. But as mentioned earlier, marking them inactive has repercussions...

I dont believe we're using constituent codes incorrectly. although not quite sure how you make the distinction of what's primary... here's an example, "Covenantor" is a ConsCode that no longer became relevant, i.e. we stopped recruiting Covenantors since 1999, no such role! Would be great to mark this "inactive" to stop our userbase from using this, but we cannot, for the reasons I gave earlier. Also what happens if we have two codes that are equally 'primary', why should only 1 be marked against the Gift? I'm sure there's an answer for this question, but it would seem to be impractical for us , and possibly misleading to users to report off the Gift ConsCode. We use a datawarehouse similar to TIE which essentially derives a lot of the methods in which a constituent may be supporting us. For example, "adhoc giver" would be taken from Gifts, "major donor potential" would be taken from monetary value and possibly their geo data.... etc.

I wouldnt suggest BB change the system altogether so that it no longer adds a ConsCode by default, but just the option would be beneficial to us, and possibly others...

[Melissa Siobhan]

I agree with Drew on this one. If that code is no longer the primary cons code for that individual it should be changed in Bio 2 (an any active recurring gifts/pledges) so that whatever is their real current cons code at the time they donate is always is on properly put the gift. Not keeping your Bio2 codes or active pledge/recurring gift gift codes up to date is not a reason to ask BB to chage the software.

The reason that you can only put one code is so you can properly report on giving by cons code based on actual gift dates not just date ranges. I just posted this week about using constituent codes properly. It mentions why sometimes you can ONLY report properly using the code on the gift and the Bio2 will not do.

date ranges for constituent codes: effective?

[RezaIslam]

Quote:

Originally Posted by Melissa Siobhan

I agree with Drew on this one. If that code is no longer the primary cons code for that individual it should be changed in Bio 2 (an any active recurring gifts/pledges) so that whatever is their real current cons code at the time they donate is always is on properly put the gift. Not keeping your Bio2 codes or active pledge/recurring gift gift codes up to date is not a reason to ask BB to chage the software.

The reason that you can only put one code is so you can properly report on giving by cons code based on actual gift dates not just date ranges. I just posted this week about using constituent codes properly. It mentions why sometimes you can ONLY report properly using the code on the gift and the Bio2 will not do.

date ranges for constituent codes: effective?

Hi there Melissa,

There is nothing in the definition of Constituent Codes that mention it needs to be used in conjunction with Gifts. It clearly mentions "it should define why the constituent is on your database". This is exactly how we are using it. The primary Constituent Code is taken automatically to the Gift. This is questionnable in that, it does not use date logic to accept the earliest date from, rather it takes the one that appears at the top using a sequencing system stored in SQL! I think you misunderstood my point about keeping it up to date, I would love to, but the batch process is affected by "keeping it up to date". Regardless of this, we have no business need to even use the Gift Constituency Codes. The reason for this is that our reporting is done externally... (I appreciate not all RE users do).

Anyway, lets take a step back & think logically. In the 1960's there was a Constituency Code called "Local Campaigner", and a Mrs Smith has a start date of 1962 to 1968. In 1969 a new Recurring Gift would have been created for Mrs Smith. In the 1970's "Local Campaigner" has evolved over time, and really no longer exists. So ideally I'd like to mark this as inactive through the codes table. Consequence is when attempting to generate payments using Batch it appears as an exception and cannot collect our regular gift (thus lose money). In NOT doing so, means that our userbase continues to use this Constituency Code on the Bio2 which affects data quality! Work around is: before making the code inactive, clear it off the Recurring Gift.... OR run scheduled script to produce Gift Update file to wipe off every week!

Why arent we using the GFConsCode? Whilst it may take only 1 minute to add/maintain/use the GFConsCode, moving forward the total time would be unthinkable (we have 9.7 milion gifts, avg 80K a month)...My underlying message is that we should not be driven to work a certain way by a generally flexible system like RE. BB suggested this idea, not me, I only welcome it with both my arms :-)

Many thanks for your comments!

Reza Islam, Senior DB Analyst
The Childrens Society.

[DrewAllen]

Quote:

Originally Posted by RezaIslam

Because we're a 125 year old charity, there are numerous "constituent codes" on the database. Not all the constituent codes are relevant today (but we know what they all mean!). Marking them as inactive through the code table is really what we should be doing because users continue to apply these old codes. But as mentioned earlier, marking them inactive has repercussions...

If they're not relevant today, they should not be a primary constituent code.

Quote:

I dont believe we're using constituent codes incorrectly. although not quite sure how you make the distinction of what's primary... here's an example, "Covenantor" is a ConsCode that no longer became relevant, i.e. we stopped recruiting Covenantors since 1999, no such role! Would be great to mark this "inactive" to stop our userbase from using this, but we cannot, for the reasons I gave earlier.

If there is no such role as a Covenantor and hasn't been since 1999, why do you still have people listed on your database as current Covenantors? If the program was phased out, then anyone marked with that code should have an end date on that code corresponding to the end of the program. They should also have been assigned some new constituent code that matches their current relationship to your organization.

Quote:

Originally Posted by RezaIslam

Anyway, lets take a step back & think logically. In the 1960's there was a Constituency Code called "Local Campaigner", and a Mrs Smith has a start date of 1962 to 1968. In 1969 a new Recurring Gift would have been created for Mrs Smith. In the 1970's "Local Campaigner" has evolved over time, and really no longer exists. So ideally I'd like to mark this as inactive through the codes table.

Here again, she should have been assigned a new constituent code that matches her current relationship to your organization. The recurring gift should have been created/updated with her new constituent code.

You're trying to treat historical codes as if they were current codes rather than updating your constituents to reflect their current relationships with your institution. That is what I meant when I said that you were using your constituent codes incorrectly.

Drew

[wionm]

Here's my scenario/question...

We have gifts that either qualify as annual campaign, events, or what can be referred to as product sales (i.e. custom ties). All of which can fall under the same fund. My folks like to see giving broken down by constituency however they also want event and product sales broken out seperately.

I produce monthly financial status reports on fiscal year giving to date using a Statistical Report using Gift Constituency codes. When entering event and product related gifts I remove the gift constituency code so these are not included in the statistical report. I would most likely use another report to do this however as I said before, these event and product related gifts can fall under the same fund as an annual campaign gift. To get the event and product totals, I pull various other reports and do some manual totalling.

I've been using RE for over 7 years however I'm somewhat new to this organization so instead of using Batch to enter gifts, I enter them manually. It's the usual story of coming to an organization who doesn't have a policies and procedures handbook, so I find manual entry helps me to learn more about the constituents and how the organization has been using the database until the information can be organized and duplicates removed. Now I'm ready to increase entry speed and am building batches. If I leave the gift constituency field blank in the batch, the field propagates once it's committed. This is the reason I came to the forum today.

Does anyone have any suggestions? After reading the above posts, I thought of giving event donors an additional constitutency code of maybe "Event Donor" and using that for the gift constituency code however would like to get some feedback.

Thanks,
Michelle
Magee-Womens Foundation

[Melissa Siobhan]

How are you using campaigns and appeals? Typically this is where you can code gifts by method of solicitation and overall general category.

You can on your report exclude event appeals or an event campaign or product sales appeals/campaign. You can then include only those on another report.

In my opinion these would not have anything to do with constituency code. These would be who he gift is from - not how the gift came in.