>Hi,
>
>I'm working with a small independent school to get our records set up in
>ebase. I've been playing around with ebase: entering some data by hand
>and importing some names, setting up Affiliations, Issues, and Action
>Prefs to fit our activities, trying out queries based on these, etc. I
>think I'm getting a pretty good idea of how to set things up so that we
>can get back out the information we want.
>
>I'm having some trouble with the "Payments" area, however; it doesn't
>seem to fit our organization very well:
>
>1) Our income comes from Tuition, Grants, and Contributions, primarily,
>with some income from Events and Sales. "Dues" doesn't apply at all.
>
>2) While I can add an accounting code for Tuition, if I set "Payment
>For" to Tuition, I won't see the payment on the payments screen (unless
>I modify the layout).
That's correct. The three columns in the View Payments screen
correspond to the three values in the drop-down list connected to the
Payment For field.
>3) Tuition payments are really different from "Giving" -- in general, if
>I'm reporting on giving, I'd like to exclude tuition payments. But it
>appears they get lumped in with the rest, even if they're marked as
>"nondeductible". Short of customization, is there any other way to
>handle this?
Tuition is definitely different from giving. Looks like payment for
services, which I would categorize as Events/Purchases. Payments
posted as Events/Purchases don't get accumulated into Member Level or
$YTD.
>4) It might be nice to use "pledges" to record tuition agreements, which
>would help us find parents whose tuition payments are overdue. Any
>thoughts on whether this would be an appropriate use of pledges?
It's possible, but ebase is set up to post pledges only to
Contribution or Dues.
>5) Finally, it would be nice to be able to base the "member level" on
>the contributions, not dues. But I understand that member level is
>coded within ebase to be calculated based on the Dues payments only, and
>I'm hesitant to muck with the logic here.
That's actually pretty simple, assuming you have FileMaker. Change
the definition of the field Sum:MemberLevel from Dues::Level to
Contribution::Level. Using the relationship Contribution assures that
only payments coded for Contribution will be considered when
calculating the level.
>It seems like it might be best simply to
>
>a) create our own summary field to accumulate contributions and assign a
>"donor level" based on this field, and
That's another way to accomplish the Donor Level item, and one that
is less likely to cause confusion later on.
>b) separate the tuition into a custom table or custom fields, rather
>than including it with the other contributions we get.
I'd use the Events/Purchase coding in Payment For. Ebase isn't an
accounting program, so invoicing and distribution of the income would
be best handled by your accounting software. In fact, there's an
argument that tuition payments are sufficiently different that they
would best be handled outside ebase entirely.
>
>Any thoughts or comments from other schools, or suggestions from more
>experienced users?
>
>
>
>-- Nellie Pennington
>[EMAIL PROTECTED]
>for Open Fields School
>
>------------------
>Reminder to each recipient: To change your list account preferences, go to
>http://email.sparklist.com/scripts/lyris.pl?enter=support and enter
>the email address you used to subscribe to the ebase support list::
>[EMAIL PROTECTED]
>
>To unsubscribe send a blank email to [EMAIL PROTECTED]
>---------------------------------------------------------------------
> ebase - Relationship Management for Nonprofits, http://www.ebase.org
>---------------------------------------------------------------------
--
Dave Shaw Northwest Classics, Inc
tel: 206-954-7526 fax: 206-625-1338
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
