<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1">Hi, <br>
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. <br>
<br>
"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)". <br>
.... 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.<br>
<br>
"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 <br>
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, <br>
and cost center; you need to create a valid (proposed) journal
entry; you need payee information; and you need to attach
documentation". <br>
.... agree that this is a fundamental requirement ... in all
systems not just 'npoacct'.<br>
<br>
"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 <br>
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."<br>
..... agree <br>
<br>
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 </font><font
size="-1"><font size="-1">"ultimate npoacct"</font> 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 </font><font size="-1"><font size="-1">an
"ultimate npoacct" should require the writing of yet another A/P
system.<br>
<br>
</font>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:<br>
.. create a Role that allows only a few windows or forms to be
displayed to the user/claimant in a browser.<br>
.. 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'.<br>
.. optionally create a Purchase Order for the expenses anticipated
for some proposed activity and accrue the costs. <br>
.. allow the user to create a reimbursement request for expenses
due to only to himself/herself.<br>
.. allow the user to attach images supporting reimbursement
claims.<br>
.. allow/force the user to select fund, account, cost center (etc)
and then submit.<br>
.. 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.<br>
.. 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)<br>
.. all stages of the creation and processing will be logged and
date/time stamped.<br>
<br>
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 </font><font size="-1"><font size="-1"> during the
early reviews </font>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. <br>
<br>
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".<br>
<br>
Before I get flamed, can I point out that I strongly support the
idea of the </font><font size="-1"><font size="-1"><font
size="-1">"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. <br>
</font></font><br>
regards<br>
Steven</font><br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 27/08/2016 10:00 PM,
<a class="moz-txt-link-abbreviated" href="mailto:npo-accounting-request@sfconservancy.org">npo-accounting-request@sfconservancy.org</a> wrote:<br>
</div>
<blockquote
cite="mid:mailman.3.1472299201.17412.npo-accounting@sfconservancy.org"
type="cite">
<pre wrap="">Send npo-accounting mailing list submissions to
<a class="moz-txt-link-abbreviated" href="mailto:npo-accounting@sfconservancy.org">npo-accounting@sfconservancy.org</a>
To subscribe or unsubscribe via the World Wide Web, visit
<a class="moz-txt-link-freetext" href="http://lists.sfconservancy.org/mailman/listinfo/npo-accounting">http://lists.sfconservancy.org/mailman/listinfo/npo-accounting</a>
or, via email, send a message with subject or body 'help' to
<a class="moz-txt-link-abbreviated" href="mailto:npo-accounting-request@sfconservancy.org">npo-accounting-request@sfconservancy.org</a>
You can reach the person managing the list at
<a class="moz-txt-link-abbreviated" href="mailto:npo-accounting-owner@sfconservancy.org">npo-accounting-owner@sfconservancy.org</a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:dave@lab6.com"><dave@lab6.com></a>
To: Frederico Guth <a class="moz-txt-link-rfc2396E" href="mailto:fredguth@fredguth.com"><fredguth@fredguth.com></a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:npo-accounting@sfconservancy.org">"npo-accounting@sfconservancy.org"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:npo-accounting@sfconservancy.org"><npo-accounting@sfconservancy.org></a>
Subject: Re: Revitalization of npoacct project; Brett Smith will take
over as project lead
Message-ID:
<a class="moz-txt-link-rfc2396E" href="mailto:CAEozd0yENG2weNFz02eEPnBaLmjAWURUWVh9iUQfmV8sv6idRA@mail.gmail.com"><CAEozd0yENG2weNFz02eEPnBaLmjAWURUWVh9iUQfmV8sv6idRA@mail.gmail.com></a>
Content-Type: text/plain; charset="utf-8"
On 26 August 2016 at 09:28, Frederico Guth <a class="moz-txt-link-rfc2396E" href="mailto:fredguth@fredguth.com"><fredguth@fredguth.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">
Hoodie is good
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a class="moz-txt-link-rfc2396E" href="http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160826/89bbb2f7/attachment-0001.html"><http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20160826/89bbb2f7/attachment-0001.html></a>
------------------------------
Message: 2
Date: Fri, 26 Aug 2016 13:22:53 -0700
From: Glen Whitney <a class="moz-txt-link-rfc2396E" href="mailto:gwhitney@post.harvard.edu"><gwhitney@post.harvard.edu></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:npo-accounting@sfconservancy.org">npo-accounting@sfconservancy.org</a>
Subject: Scope of this phase of npoacct
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:57C0A51D.6020109@post.harvard.edu"><57C0A51D.6020109@post.harvard.edu></a>
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
<a class="moz-txt-link-freetext" href="http://momath.org">http://momath.org</a>
<a class="moz-txt-link-abbreviated" href="mailto:brett@sfconservancy.org">brett@sfconservancy.org</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
------------------------------
Subject: Digest Footer
_______________________________________________
npo-accounting mailing list <a class="moz-txt-link-rfc2396E" href="mailto:npo-accounting@sfconservancy.org"><npo-accounting@sfconservancy.org></a>
List URL: <a class="moz-txt-link-freetext" href="http://lists.sfconservancy.org/mailman/listinfo/npo-accounting">http://lists.sfconservancy.org/mailman/listinfo/npo-accounting</a>
Wiki URL: <a class="moz-txt-link-freetext" href="http://npoacct.sfconservancy.org/">http://npoacct.sfconservancy.org/</a>
------------------------------
End of npo-accounting Digest, Vol 15, Issue 8
*********************************************
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title></title>
<div class="moz-forward-container">
<div class="moz-signature">
<table border="0" cellpadding="0" cellspacing="0" width="420">
<tbody>
<tr>
<td align="left" valign="top"><img
src="cid:part1.E760B698.1F41F068@adaxa.com"
height="52" width="135"></td>
</tr>
<tr>
<td align="left" valign="top">
<table border="0" cellpadding="0" cellspacing="5"
width="100%">
<tbody>
<tr>
<td align="left" valign="top" width="17%">
<table border="0" cellpadding="0"
cellspacing="0" width="100%">
<tbody>
<tr>
<td align="left" valign="top"><img
src="cid:part2.118DD135.40204437@adaxa.com"
height="96" width="82"></td>
</tr>
</tbody>
</table>
</td>
<td align="left" valign="top" width="83%">
<table border="0" cellpadding="0"
cellspacing="0" width="100%">
<tbody>
<tr>
<td style="font-family:
Arial,Helvetica,sans-serif; font-size:
16px; color: rgb(0, 0, 0);
font-weight: bold; padding-left: 5px;"
align="left" valign="top" width="78%">Steven
Sackett<br>
<span style="font-family:
tahoma,Verdana,Arial,Helvetica,sans-serif;
font-size: 11px; color: rgb(0, 0,
0); font-weight: normal;
padding-left: 0px;">Chief Financial
Officer<br>
</span></td>
<td align="left" valign="top"
width="22%"> </td>
</tr>
</tbody>
</table>
<table style="width: 100%;" border="0"
cellpadding="0" cellspacing="5">
<tbody>
<tr>
<td style="border-right: 1px solid
rgb(204, 204, 204); vertical-align:
middle; text-align: left; font-family:
tahoma,Verdana,Arial,Helvetica,sans-serif; font-size: 11px; color:
rgb(0, 0, 0); font-weight: normal;
width: 45%;">au : 1 300 990 120<br>
nz : 0 800 232 922<br>
tel: 613 9510 4788<br>
mob: 0 402 077 911 </td>
<td style="font-family:
Verdana,Arial,Helvetica,sans-serif;
font-size: 11px; color: rgb(0, 0, 0);
font-weight: normal; padding-left:
5px;" height="30" align="left"
valign="top" width="65%">e: <a
moz-do-not-send="true"
style="font-family:
tahoma,Verdana,Arial,Helvetica,sans-serif;
font-size: 11px; color: rgb(0, 0,
0); font-weight: normal;"
href="mailto:ssackett@adaxa.com">ssackett@adaxa.com</a><br>
w: <a moz-do-not-send="true"
style="font-family:
tahoma,Verdana,Arial,Helvetica,sans-serif;
font-size: 11px; color: rgb(0, 0,
0); font-weight: normal;
text-decoration: none;"
href="http://www.adaxa.com"
target="_blank">www.adaxa.com</a>
<table height="26" border="0"
cellpadding="0" cellspacing="0"
width="65%">
<tbody>
<tr>
<td align="left" valign="bottom"
width="22%"><img
src="cid:part5.96DD7C31.D99F8F60@adaxa.com"
height="20" width="20"></td>
<td valign="bottom" width="58%"><span
style="font-family:
tahoma,Verdana,Arial,Helvetica,sans-serif;
font-size: 11px; color:
rgb(0, 0, 0); font-weight:
normal; padding-left: 0px;">steven1001</span></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td colspan="2" style="border-top: 1px solid rgb(204,
204, 204); font-family:
tahoma,Verdana,Arial,Helvetica,sans-serif; font-size:
11px; color: rgb(0, 0, 0); font-weight: normal;
padding-top: 5px;" align="left" valign="top">Adaxa
helps your business management software needs with a
fully integrated enterprise grade suite of pure open
source solutions. </td>
</tr>
</tbody>
</table>
</div>
<br>
</div>
<br>
</div>
</body>
</html>