Reimbursement system vs A/P module

[Glen Whitney]

Dear Brett,
   Wow, I appreciate your in-depth consideration and response on this
topic.  For brevity I will only clip three key bits from your note, and
follow with my thoughts.

On Thu, 2016-09-08 at 16:18 +0000, npo-accounting-
request at sfconservancy.org wrote:
> Everything I’ve done and read makes me think that
> building interfaces that adapt to the user’s experience level, at a
> very
> fundamental level, is a fundamentally hard problem. I won’t speak for
> others on the list, but I know I myself am not the kind of UI/UX
> expert
> who’s in a position to break new ground on that.

...

> So I went to evaluate some of the systems out there. ... I spent some
> good time with ADempiere and
> LedgerSMB, and a little with FrontAccounting.

...

> I’m
> seriously looking at whether it makes sense to build this as a
> CiviCRM
> extension.

As you can probably tell, my remarks were motivated primarily by the
thought that the project would be best served by avoiding creating a
reimbursement system (possibly rolling its own) and later separately
needing an A/P system (possibly again rolling its own!) when the
essential operation provided by both has a vast overlap.  But I agree
with your first snip, the optimal interface for different users is
quite different.  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!

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.  (Note there is already at least one Civi extension billed as
"integration with an accounting system"!, namely Xero -- which is a
proprietary system AFAICT.)  So let us all know what conclusions you
reach.  It could be quite usable with no accounting system integration
at all, the end product simply being a page an admin can go and see all
of the approved reimbursement requests, or paid ones, or finalized
(receipt acknowledged ones), etc.

Finally, let me throw out one other oddball possibility for the basis
of this "type (2)" reimbursement system: bug-tracking systems.  There
are numerous open source ones available, they have an at least
superficially similar workflows -- an item (bug or reimbursement
request) is created, various conditions must be met, it can/must be
assigned back and forth to various people in a collaborativefashion.
Most bug trackers are web-based and some are extensively configurable,
and they have triggers for set actions to occur when a "bug" (here
reimbursement request) reaches a certain status.  Just brainstorming,
let me know if it would be helpful for me to poke around to see if any
seem especially close/adptable to being suitable.

    Best regards, Glen