Re: Non-profit/Campus Management Expansion for LedgerSMB?

["Chris Nighswonger" <..hidden..>]

On 10/18/07, Chris Travers <..hidden..> wrote:
> I am going to reply to both here.
>
> On 10/17/07, Chris Nighswonger <..hidden..> wrote:
> > General:
> >    Fund/Non-Profit Accounting (There are some stirrings on this I think...)
>
> Something that would really help would be a few scenarios of
> transactions and how they map to designations and accounts.

I'll try to get the accountant into this discussion.

>
>
> >    Facilities Management
> In this as in most areas, the key is going to be understanding the
> problem.  I would suggest that in each of these areas you may want to

...elaborate.... (I assume :-)


>
> >
> > The financials will need to be IASB/FASB compliant.
>
> Note that we do our best.   The codebase still has few areas where it
> allows some businesses to cheat.  We are working on closing these.
>
> > As well as SOX,
> > etc. Any medical records of any real detail contained in the School
> > Management module would require some level of HIPPA compliance.
>
>HIPPA is something I am more familiar with but is largely
> beyond the scope of LSMB.

I suspect that this is a combination of code/administration like the
ssl issue we hashed out in another thread. However, such a module
should provide the ability to secure such data at the necessary level
or at *least* be flexible enough to adapt. In my understanding the IT
side of HIPPA is largely securing the data itself and access control
to the data on a need-to-know basis. Again, the level of compliance
will be dictated by the *type* of medical data to be stored.

>
> > And I
> > believe that there are several "acts" of law other countries that
> > might be of interest to those using these modules in them.
> >
> > After some email discussion with Chris Travers, it appears that the
> > 1.3 code base (once stable) will be the place to start development on
> > some of these things.
>
> Agreed.
> >
> > I realize that there are some other oss apps out there that do
> > crm/membership/donations stuff (ie civicrm) but we would like a
> > unified solution rather than a patchwork of various solutions.
>
> I am not sure I 100% agree with this assessment.  I am going to share
> my experience and why I think that ideally you want a set of different
> applications which are effectively sharing the same data.
>
> When I worked at Microsoft, there was a time when we were using as
> many as 4 CRM suites on a daily basis.  The problem wasn't that people
> didn't want a unified solution.  The problem was that they did, and so
> every time one department needed something not in the unified
> solution, they had to get another tool
>

Understood and agreed with as an issue with larger business types. I
do not perceive this type of issue in our situation. However, I can
see how this would be an issue in a context where departments are more
numerous and less adept to cooperate with this sort of thing.
(Microsoft uncooperative??? :-P)

> I think that basically you have two options going forward.
> 1)  You could look for other programs that do most of what you want
> them to do

I have looked at CiviCRM. My concern is MySQL. If we are going to run
a patch work of apps, a common db would be nice.

Until this post, I was unaware of Koha. Took a cursory look at it and
was impressed.

>and port them to use the common LSMB framework (CiviCRM,
> Koha, some EMR solutions, etc).

I assume this could be done with some custom code, sp's, and triggers.
(ie. transaction in one app triggers sp/code which manipulates data in
another apps db/table(s) etc....)

With membership/donations/library/academic records/etc. we really need
to achieve a SPOE for common data such as members/entities, etc. Users
will scream if they have to do double entry...

>
> 2)  You could build up add-ons in a modular and modetely coupled way--
> each being a new client application to the LSMB database.

If #1 is the most straight forward approach, it wins in my opinion. No
need to reinvent the wheel. Although as an admin, I am partial to a
common db rather than db's of different flavors. Its more to keep up
with from a maintenance/security prospective.

>
> In both cases the result is very close to the same.  However, I dont
> think you necessarily want to either end up in a situation where you
> have lots of applications which barely talk to eachother, or where one
> application does it all.
>
> >
> > I would like to hear what others want/need or would like to say
> > concerning these items both from the user and development standpoint.
>
> If it would help, I will throw the idea at another school and see if
> we can get something going here.  One area I could see helping would
> be fundraising auctions.

It would be nice to here another school's thoughts/input.

Chris

-- 
Chris Nighswonger
Network & Systems Director
Foundations Bible College & Seminary
www.foundations.edu
www.fbcradio.org