> Just a couple of thoughts from left field-
> 1. Is there a chance that you could convince your client not to enter
> identical information in Quickbooks? I strive to insist that a system
> be designed to avoid duplicate entries, including exportable
> duplication. Ebase can summarize all donations for a day, week or month
> to match deposits to the bank that need to be entered in Quickbooks. Is
> there a sound reason for entering the details in Quickbooks?
I think it is clear that one wants to pick ebase for tracking the names and
address and probably all the membership stuff. QB does not need to know the
details of any of that. On the otherhand, if you sell things, as we do,
ebase does not track inventory and QB does. So each program has its
strengths and those should be exploited without trying to make both programs
track everything.
> 2. If details must be entered in Quickbooks, perhaps it would be easier
> to enter first in Quickbooks and export to ebase via an Excel
> spreadsheet.
>
This would be the hardest to implement because QB knows nothing about
generating new member numbers or even if the person is already a member
unless you do extensive exporting and try to keep two name/address lists in
sync. We have member discounts for purchases for instance.
If I were going to do the job I would drive the process from the ebase end
or better still from an ebase aware web application.
For some of us there is a third program involved in the processing. We
accept credit cards for purchases, memberships and donations. This goes
though a program called ICVerify to actually do the transaction with the
bank that settles the credit card accounts. It can import yet another copy
of the raw data in its format and process batches. Again an argument for
driving the whole process from ebase or a third program.
Then there is a fourth program, in our case ecOrder, which receives orders
placed from the web. Those orders need to be checked by a person (or maybe a
program) because they get all kinds of things wrong, e.g. ordering at member
prices when they are not members.
There are existing programs that integrate all of this stuff but they cost
10s of thousands of dollars. Ultimately the V2 ebase would like to get into
this massive integration business.
The integration of any/all of these pieces will not be a simple 2 week job.
I think it is best tackled in the context of V2.
------------------
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
---------------------------------------------------------------------
