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