Creating a donations database

[Todd]

I'm creating a database to track donations to a charitable organization. Frequently multiple donations are made by the same individuals. What I need to show is an ongoing history of donations made by the same parties. Is there a simpler solution than a relationship file/portal? What I'd like for the user to see is the following: I'll have them do a find on a first and last name and if the donor already exists, the file information will be produced. If not, the data will be enetered. Each first and last name is linked to a unique id.(this part is already built) The organization needs to see how many donations each individual has made and that is what I want displayed on the donor page. Is a relationship file viewed through a portal the only way to do this or are there other options? I've had some problems in the past with relationship files dropping information, which would be disastrous in this case. Thanks.

[Lee Smith]

Hi Todd,

Before you re-invent the wheel, I remember that there is a FREE database solution available for Non-profits. Not sure where, but check at

www.fmfiles.com

and

http://www.filemaker.com/

HTH

Lee

[Todd]

Checked the site, thanks, but I'm not crazy about the interface. Question remains.

[Lee Smith]

Hey, it's Free, You could pay someone a lot of money to create what you need, and still hate the interface.

The interface (a real broad subject) can be changed. Take what works, what you like, etc. and change what doesn't work, like, etc.

[color:"blue"] It isn't locked is it?

Lee

[Todd]

I could only download the screen shots for the 2 files I found. They also seem way beyond what the client needs, which is relatively simple, I'm just seeing if there's another way to give them history without using a portal.

[Fitch]

There's one at http://www.ebase.org/ but it may be overkill for your needs.

To answer your question, Todd, there are basically two ways to look at a list: in a list layout or through a portal. Assuming that you have structured this with one file for donors and another for payments, I would think that a portal would generally be a better method, since anything linked to that ID would show in the portal, it couldn't be omitted as it could in a list. It just depends on what you want to do.

A fairly easy way might be just to change your payment entry flow slightly, so you search for the client first, and if not found it takes you to an entry screen.

However, to do it as you described, set up an entry screen with all global fields. Then when the user hits the "Process" or "Enter" button, do a Find. If Status (CurrentFoundCount) = 0 you create a donor record and enter the payment. If Status (CurrentFoundCount) = 1 you create a payment for that donor. If Status (CurrentFoundCount) > 1 you go to a list layout so the user can click a name, then it enters the payment.

As for "relationship files dropping information," I'll take your word for it. But in my experience, something like that doesn't just "happen." It's usually a case of PEBKAC: Problem Exists Between Keyboard And Chair.

[Todd]

Thanks, that's the road I was going down. One question though: why use a global field? Isn't that field used to show a consistent value across all records? When we're looking up name values (first and last and a perfect match), won't it be most efficient to use text fields? I suppose the unique id/donor number field should be a global field, however.

[Todd]

actually, scratch that last bit, I was confused. The id should definitely NOT be Global, as it's unique. Do you mean the "search for..." fields should be global?

[-Queue-]

Using globals will allow you to have the information entered for the donor, validated if desired, so you can search for it and act upon the results as desired, without having to create a new record that you might not end up using afterward.

[-Queue-]

You are correct that the ID should not be global. The idea is to use the global field to search for the existing id. You could also use a relationship from the global to the id to check whether or not it already exists or how many related records exist for it. The 'find' portion isn't even necessary.

[Todd]

Hmmm. I think the "find" is definitely necessary, because we are trying to make sure that each time a person makes a donation we are not entering name and address if it already exists in the database. The User or the donor will have no idea what the ID number is, that is just being used to lock the address file with the donation files so we can produce histories and reports. Am I missing something here? A Global File is transparent, so how does that help me locate information? I've only ever used them to hold logos and numbers and such that were to be seen across an entire file. How do you use the globals to locate information when they can't be used for a "find"?

[Fitch]

Todd, the idea is to NOT create a new donor record if one already exists. One way to do that is to do a search BEFORE you try to create a new payment. Hmmm... rereading your original post, I guess that's what you were going to do. So you don't have to use globals to do the find after all. I think maybe I misread your original question, I was thinking you wanted to go to a screen where you could enter a payment and THEN see if there was already a matching donor record. This is a common practice, by the way, to prevent records from being created and left in an unfinished state, for example.

The way it works is this :

First of all, don't allow users to create records with the New command. Use a button that takes the user to a data entry screen. On this screen, show global fields for name first and last. Then script a Find like this:

Enter Find mode

Set field (name first, gName first)

Set field (name last, gName last)

Perform Find

etc.

The way to do that instead with a relationship is make a relation with two calculated fields. On the left is:

(gName first & gName last)

On the right is:

(name first & name last)

You could then show any matching names in a portal, or you could show an alert or whatever. So you get the effect of a Find without doing a Find.

[Todd]

You seem to favor using global fields over the find function. Here's what I wish to do, and tell me what makes more sense: The User can not enter a donation without first doing a find on the name. So the steps are this: the first screen needs to be a "find donor" screen with seperate first and last name fields. If there is a perfect match on those fields with a name already in the database, then the user is taken to a screen on which to enter the donation. If there is no match, then they will be taken to a screen on which to perform the data entry for a new donor and subsequently the donation. If there is a multiple match, then they will be taken to a screen showing the multiples and they will choose which one they wish to use.

You seem to favor using global fields for this instead of using the "find" function. As I've never used the global fields for something like this(or much of anything), tell me what the benefit is. I've always found the find function to be most efficient, but maybe I'm missing something here.

Thanks

[Fitch]

I just thought you might like to know how the global technique worked, either through a Find script or a relationship. You sounded kind of dubious that it was even possible.

However, doing a Find as you described is fine. I don't particularly favor one method over another -- there's no one method that's right for every situation.