Reimbursement system vs A/P module

[Brett Smith]

On 09/08/2016 02:03 PM, Glen Whitney wrote:

> So it seems to me that there are two ways to go:
>
> (1) A core A/P module with two (or more) fairly lightweight "skins"
> over it for "rank & file" submitters vs. "accounting-experienced"
> staff.  (If there's an existing system out there that is usually
> customized with code, it's not inconceivable that a graphical interface
> to customize the system's forms could be built on top of that, for
> example.)
>
> (2) As you put it, a "filing out forms app" that really has no
> accounting knowledge inherent in it, but is simply an information-
> gathering-with-review-by-a-gatekeeper-via-web-forms product, which then
> spits a report out in a standard format, either sufficiently automated
> to spit into the eventual system's programmatic API, or just for quick
> handling by a bookkeeper. From this point of view, the project might be
> just as suited to submitting insurance claims as reimbursement
> requests, even though npoacct is surely not pursuing a system for not-
> for-profit insurance companies ;-).
>
> I really appreciate your taking the time to look at existing open
> source accounting systems (cf. the second snippet I quoted), and
> respect and trust your judgment that none of them are close enough at
> the moment to be a basis for option (1).
>
> In that case, option (2) seems reasonable as a path to get something
> going if there isn't the time or resources or project inclination to
> either make more extensive adaptations to get an existing A/P
> functionality to allow for (1), or to start building what could be a
> new one that would satisfy (1) -- not that I am advocating starting
> from scratch!

I think approach (2) has a few benefits over (1). None of them is a slam
dunk, but taken together they make me prefer it. One is time, yes; I
think we can get (2) working more quickly. But perhaps more importantly,
(1) is likely to have deeper ties to a particular accounting system—or
if it doesn’t, it will take additional time to extricate an A/P module
from one of the existing ones. I think approach (2) will have a little
easier time adapting to different accounting systems, meaning different
organizations can start using it sooner. That seems like a big win to
me, the opportunity to get this deployed at several organizations and
start getting feedback and building interest.

> If it's option (2), then, the question is what might npoacct build on
> to avoid wasting effort creating something de novo in that vein? There
> must be existing form-building apps out there.  It might be heard to
> search for them because they might not nominally have much or anything
> to do with accounting.  If it would be helpful, I'd be happy to be
> another pair of eyes poking around for such things.
>
> On the other hand, I am quite familiar with CiviCRM because MoMath has
> depended on it for years. If npoacct does not mind this stage of the
> project only being usable with a CiviCRM installation, then a CiviCRM
> Extension, parallel with CiviEvent or CiviMailing, seems like a
> perfectly reasonable way to go, and I would be happy to contribute
> effort.

I agree this seems like a promising approach. It’s what I’ve been
spending my time on this week, and I’ve started taking notes about what
I’ve found on the wiki
<http://npoacct.sfconservancy.org/Reimbursements/OnCiviCRM/>, noting
possible implementation ideas and pitfalls.

Right now this is just based on reading some documentation and playing
with a local development install. I’m sure there’s more to cover. If
you, or anyone else with CiviCRM experience, has thoughts about how we
might address some of the issues that are already covered there, or
notes about issues that are likely to come up in the future, adding your
thoughts to that page would be a huge contribution right now.

Thank you,

​
-- 
Brett Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160916/81289ee3/attachment.html>