Reimbursement system vs A/P module

[Brett Smith]

Glen,

Sorry for sitting on this e-mail. It’s actually given me a lot to chew
on, and drove me to even take a look at some of the A/P interfaces of
current systems. More thoughts inline.

On 09/01/2016 06:01 AM, Glen Whitney wrote:

> I don't see either of the paragraphs below as undermining that point of
> view; rather they reinforce it.  Indeed, I think one of the great
> potential benefits of npoacct is to provide a low-cost, easy-to-begin-
> with system for small NFPs, who may well not have significant
> accounting expertise in-house.  Hence the ability for an A/P component
> to present itself without accounting jargon (but perhaps with technical
> terminology accessible for experts) is a terrific plus.

I agree with all of this, but I do want to be careful about that
parenthetical. 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.

> As for the second paragraph, if I understand the roadmap, it is to
> develop npoacct as a collection of interoperating modules, so that it
> can be approached piecemeal.

I agree that’s the current thinking, and right now I’m not aware of any
reason we wouldn’t do it that way, but I don’t think we necessarily have
a hard commitment to that approach. If other considerations like a
choice of framework made it difficult, it’s something we might consider
trading off for other benefits.

It also depends a little bit on your definition of “module.” The first
release of the reimbursement system is expected to talk to ledgers
through export functionality. If it continues to work that way, even as
we build out the rest of the NPO Accounting software, is it still a
“module?” I can understand different people answering that differently,
and I don’t think it matters too much as long as we’re on the same page
about functionality.

>   So the idea that A/P qua Reimbursements
> can operate independently from the eventual General Ledger module seems
> to me completely consistent with such an architecture, and reinforce
> the idea that a Reimbursement module now be conceived as suitable to be
> the eventual A/P module.  Moreover it seems to imply conversely that
> A/P components of existing systems, such as the one Steven described,
> should be candidates for  (the foundation of) this Reimbursement
> module, if they can be extracted as an independent
> module/service/library -- as has been stated before as a likely path
> for the npoacct project, to take an existing system or systems and
> reconstrue them as a library or toolkit.

I agree with all this. So I went to evaluate some of the systems out there.

I know it’s been a while since the project’s earlier evaluation of
accounting systems, and given what I’ve said about priorities for the
first release, the emphasis is a little different than the core
accounting functionality that had center stage there. So I started from
Wikipedia’s list of FOSS accounting software
<https://en.wikipedia.org/wiki/Comparison_of_accounting_software#Free_and_open_source_software>.

The reimbursement system needs to let requestors file requests through
the web, so anything that requires a dedicated client was out.
Long-term, I think it’s important for the health of the project that all
our components be at least GPL-compatible, so that ruled out a couple
more too.

From there, I went through some of the more popular options. As much as
possible, I tried to go through demos, to get a high level picture as
quickly as possible. I spent some good time with ADempiere and
LedgerSMB, and a little with FrontAccounting. I think there are a couple
of features that we’ve identified as really core for the reimbursement
system that would be difficult for all of them to support, which makes
me think they’re not especially suitable for the job we have in mind.

The first is that all program customization tends to be done through
code. One of the ways we want the reimbursement system to save us time
is by asking requestors the right questions about what they’re filing,
to help them as much as possible to submit a complete report. Because of
that, it’s important to be able to adapt the form, as either
reimbursement policies change, or we find out that current forms aren’t
giving users the right guidance. Requiring code changes to be able to do
this is more overhead than we really want, especially since collecting
information not anticipated by the system might require database schema
changes.

The second is that the systems don’t really seem to have much of a
concept of collaborating to build a purchase order. For most businesses,
I think this makes perfect sense: usually you’re sending purchase orders
outside your organization, and you can’t expect those parties to log
into your own systems to ask for corrections or changes. But that’s the
core of the workflow for the reimbursement system. For some of the
systems, it’s not clear that you can edit a purchase order at all after
it’s finalized. Even when it is, it doesn’t provide the same tight
feedback loop we’d like, where a requestor can see comments from the
organization that say, “We can’t accept your request because of these
reasons; please correct them and resubmit.”

If I’m mistaken in these evaluations, I’m happy to be corrected. They’re
large systems, and I’d have no trouble believing there might be a
particular angle I missed. But that’s what I’ve found so far, and
without at least some indication that the system can provide the core
functionality without too much revision, I can only justify spending so
much time on further evaluation.

I think this is all very understandable given that the reimbursement
system we want to build has a very different emphasis from accounting
software generally. Part of the reason we decided to prioritize it is
exactly /because/ the core of the software is not accounting: it’s
useful to accounting departments, and needs to talk to an organization’s
general ledger, but the core functionality is really more about filling
out forms than bookkeeping. It’s something we can make progress on
without getting into larger accounting issues.

I share the impulse to build on what’s already there. Given that, I’m
seriously looking at whether it makes sense to build this as a CiviCRM
extension. CiviCRM already has a lot of the building blocks that we
expect the system to have: forms defined by system administrators
through the interface rather than code; and multiple parties having
different views into that form by their role. And CiviCRM integration is
a feature that we’ve already heard other NPOs say would be valuable, so
we have a reason to build on top of it that’s unfortunately not there
for the accounting systems. In the best case, the extension might be
able to simply define the workflow and help build common forms; but even
if the reality isn’t that rosy, it’s at least clearer that the core
CiviCRM building blocks suit what we’re trying to build.

I’m going to be digging into that more over the next couple of days, and
I’ll follow up with what I find. But that’s the current direction I’m
exploring.

​
-- 
Brett Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160908/6180e0e3/attachment-0001.html>