npo-accounting Digest, Vol 15, Issue 8

ssackett at adaxa.com ssackett at adaxa.com
Mon Aug 29 05:28:33 UTC 2016


Hi,
Glen Whitney's comments raised issues that have puzzled me since the 
commencement of this project. None of the following is a criticism of 
what Glen wrote.

"At its core, a reimbursement request is essentially just (one type of) 
an Accounts Payable (A/P) journal entry (or probably more accurately a 
proposed A/P journal entry that needs to be reviewed/approved by some 
other agent before being added to the ledger)".
.... agree, so there is entry of an A/P document, an authorization 
process and also a responsibility hierarchy that the system needs to 
understand as well.

"So I just wanted to put my two cents in that the current module should 
be developed with the possibility/desire in mind that it can be or grow 
into the full A/P
module for the "ultimate npoacct". I don't see anything much 
particularly "extra" about reimbursement requests as opposed to other 
A/P entries on the one hand, or anything much needed for general A/P 
entries that is irrelevant to reimbursement requests. In both settings, 
you need (at some point) to classify the expense as to fund, account,
and cost center; you need to create a valid (proposed) journal entry; 
you need payee information; and you need to attach documentation".
.... agree that this is a fundamental requirement ... in all systems not 
just 'npoacct'.

"Ultimately, a sufficiently easy-to-use reimbursement request module 
with robust validation of the request and facile means to perform the 
classification would create journal entries requiring no bookkeeper 
modification, only approval by an authorized reviewer, prior to entry in 
the ledger. Moreover, I don't see any roadblock to that same module
being appropriate for an actual bookkeeper (who has authorization to add 
journal entries without review) to enter invoices, contractual payments, 
and other such A/P entries."
..... agree

In my view it is likely that many existing open-source ERPs will already 
provide all the above capabilities and more.  It is equally likely that 
anything specifically developed to meet an "ultimate npoacct" 
requirement risks having a limited breadth of capabilities and that 
extra requirements will keep emerging and then have to 
retrofitted/added.  There will quickly be a requirement for an 
event/visit expenses budget and an accrual of any unexpended portion for 
instance. I thought open source was intended to allow the re-use and 
improvement of existing code so I am really struggling with the idea 
that an "ultimate npoacct" should require the writing of yet another A/P 
system.

For example, the open-source ERP I deal with will let you do the 
following with a relatively small amount of configuration and no code 
changes:
.. create a Role that allows only a few windows or forms to be displayed 
to the user/claimant in a browser.
.. create a cut-down vendor invoice window in the browser that is simple 
to use with many fields filled in with default values and optionally 
'undisplayed'.
.. optionally create a Purchase Order for the expenses anticipated for 
some proposed activity and accrue the costs.
.. allow the user to create a reimbursement request for expenses due to 
only to himself/herself.
.. allow the user to attach images supporting reimbursement claims.
.. allow/force the user to select fund, account, cost center (etc) and 
then submit.
.. an email will be sent to whoever is authorized to make the approval 
and it will also appear in the authorizer's 'workflows pending approval' 
task in their menu.
.. the approver clicks ok and the document is completed and put in the 
payment queue and decrements the accrual made for the activity (if any)
.. all stages of the creation and processing will be logged and 
date/time stamped.

I have not stated which open source ERP this is because the point I wish 
to make is that there are probably a number of existing open source ERPs 
which will do all this stuff (and more) but which were dismissed during 
the early reviews as unsuitable, or too big/complex, or (validly) as not 
quite real open source.  Of course, as soon as you get into real-world 
situations a lot of complexity that has already been addressed by ERP's 
that have been under development for many years will come back to haunt 
the developers of the new project.

In nearly every system selection process I have been involved with in 12 
years of running an open source ERP business there has been a detailed 
user requirements document and an attempt to compare these specific 
requirements with candidate system's capabilities. My recollection is 
that there was no such process for this project, just a quick review of 
easily available information.  I have always been puzzled why a detailed 
functional requirements process seems not been followed for the proposed 
npo-accounting system .. perhaps a case of "if you don't know where you 
are going then it does not matter which road you take".

Before I get flamed, can I point out that I strongly support the idea of 
the "ultimate npoacct" being available to the many not-for-profits doing 
many valuable things within their respective communities, I am just 
disappointed at the slow (and clearly what I see as flawed) process of 
getting there.

regards
Steven



On 27/08/2016 10:00 PM, npo-accounting-request at sfconservancy.org wrote:
> Send npo-accounting mailing list submissions to
> 	npo-accounting at sfconservancy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.sfconservancy.org/mailman/listinfo/npo-accounting
> or, via email, send a message with subject or body 'help' to
> 	npo-accounting-request at sfconservancy.org
>
> You can reach the person managing the list at
> 	npo-accounting-owner at sfconservancy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of npo-accounting digest..."
>
>
> Today's Topics:
>
>     1. Re: Revitalization of npoacct project; Brett Smith will take
>        over as project lead (Dave Crossland)
>     2. Scope of this phase of npoacct (Glen Whitney)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 26 Aug 2016 09:40:09 -0700
> From: Dave Crossland <dave at lab6.com>
> To: Frederico Guth <fredguth at fredguth.com>
> Cc: "npo-accounting at sfconservancy.org"
> 	<npo-accounting at sfconservancy.org>
> Subject: Re: Revitalization of npoacct project; Brett Smith will take
> 	over as project lead
> Message-ID:
> 	<CAEozd0yENG2weNFz02eEPnBaLmjAWURUWVh9iUQfmV8sv6idRA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 26 August 2016 at 09:28, Frederico Guth <fredguth at fredguth.com> wrote:
>
>>   We happen to be developing another app using JS and PouchDB, being able
>> to create mobile and desktop (Electron) apps in javascript that work
>> offline and can be synched only when there is internet connection.
>
> Hoodie is good
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160826/89bbb2f7/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 26 Aug 2016 13:22:53 -0700
> From: Glen Whitney <gwhitney at post.harvard.edu>
> To: npo-accounting at sfconservancy.org
> Subject: Scope of this phase of npoacct
> Message-ID: <57C0A51D.6020109 at post.harvard.edu>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Just another thought about how the current focus of npoacct might
> possibly fit into the larger eventual project, to add to Daniel P's
> excellent comments about the overall workflow of which reimbursement
> requesting is one step:
>
> At its core, a reimbursement request is essentially just (one type of)
> an Accounts Payable (A/P) journal entry (or probably more accurately a
> proposed A/P journal entry that needs to be reviewed/approved by some
> other agent before being added to the ledger). So I just wanted to put
> my two cents in that the current module should be developed with the
> possibility/desire in mind that it can be or grow into the full A/P
> module for the "ultimate npoacct". I don't see anything much
> particularly "extra" about reimbursement requests as opposed to other
> A/P entries on the one hand, or anything much needed for general A/P
> entries that is irrelevant to reimbursement requests. In both settings,
> you need (at some point) to classify the expense as to fund, account,
> and cost center; you need to create a valid (proposed) journal entry;
> you need payee information; and you need to attach documentation.
> Ultimately, a sufficiently easy-to-use reimbursement request module with
> robust validation of the request and facile means to perform the
> classification would create journal entries requiring no bookkeeper
> modification, only approval by an authorized reviewer, prior to entry in
> the ledger. Moreover, I don't see any roadblock to that same module
> being appropriate for an actual bookkeeper (who has authorization to add
> journal entries without review) to enter invoices, contractual payments,
> and other such A/P entries.
>
> Hope this perspective is helpful,  Glen
> ---
> Glen Whitney
> Treasurer, National Museum of Mathematics
> http://momath.org
>
>
> brett at sfconservancy.org wrote:
>> You asked about the scope of this work in another e-mail. For version 1,
>> I think our top priority is the submission process. The goal of the
>> system should be to reduce the amount of back-and-forth required for
>> people to submit reimbursement requests that have all the necessary
>> documentation. This saves time for both submitters and bookkeepers, and
>> it’s relatively self-contained. Once that’s done, though, I agree it
>> makes sense to look at some of the other areas you named, letting
>> organizations track the request through other stages of the lifecycle.
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> npo-accounting mailing list <npo-accounting at sfconservancy.org>
> List URL: http://lists.sfconservancy.org/mailman/listinfo/npo-accounting
> Wiki URL: http://npoacct.sfconservancy.org/
>
>
> ------------------------------
>
> End of npo-accounting Digest, Vol 15, Issue 8
> *********************************************

-- 

	
Steven Sackett
Chief Financial Officer
	

au : 1 300 990 120
nz : 0 800  232 922
tel:  613 9510 4788
mob: 0 402 077 911 	e: ssackett at adaxa.com <mailto:ssackett at adaxa.com>
w: www.adaxa.com <http://www.adaxa.com>
	steven1001

Adaxa helps your business management software needs with a fully 
integrated enterprise grade suite of pure open source solutions.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160829/9a83e363/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 21289 bytes
Desc: not available
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160829/9a83e363/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 23437 bytes
Desc: not available
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160829/9a83e363/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12583 bytes
Desc: not available
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160829/9a83e363/attachment-0005.jpe>


More information about the npo-accounting mailing list