185 lines
9 KiB
Markdown
185 lines
9 KiB
Markdown
# Requirements for the Reimbursement and Outgoing Payment Request System
|
|
|
|
## Overview
|
|
|
|
One short-term goal of the Non-Profit Accounting Project is to create a
|
|
system that allows (a) members of an organization, and external parties, to
|
|
submit requests for reimbursement or request for payment (e.g., invoices),
|
|
and (b) the organization's bookkeepers, accountants, and managerial approvers
|
|
to review those requests, add them to the organization's books, and prepare
|
|
payment. The primary motivation for this project is to save time both groups
|
|
spend on handling reimbursement requests and outgoing payments, and reduce
|
|
turnaround time for these requests, and to help members file complete
|
|
requests that are easy for bookkeepers to review and accept.
|
|
|
|
Members of the organization could be employees, members of projects
|
|
represented by the organization, or others doing work to advance the
|
|
organization's mission—anyone who the organization might want to reimburse or
|
|
pay.
|
|
|
|
The system should not make assumptions about specific reimbursement policies
|
|
or invoicing requirements. Instead, it should be possible for a bookkeeper
|
|
or administrator to define follow-up questions and what responses are and are
|
|
not eligible for reimbursement or payment. Early versions may require
|
|
sysadmin-level technical expertise to do this, but ultimately it should be
|
|
doable by a bookkeeper with appropriate privileges.
|
|
|
|
## Requirements for first release
|
|
|
|
### Defining the request form
|
|
|
|
Requests for payment have five states: Pre-Approval, In Progress, Submitted,
|
|
Accepted, and Rejected.
|
|
|
|
Administrators can define questions to ask the requestor about the entire
|
|
request, and about each expense in the request. The system can display
|
|
forms, validate answers, and record answers for questions with the following
|
|
types of answers:
|
|
|
|
* Text
|
|
* Boolean (yes/no)
|
|
* Selection (from a list of values)
|
|
* Number
|
|
* Currency (this is probably a string that's validated to have a numeric part plus an optional currency code)
|
|
* Date
|
|
* File upload
|
|
|
|
For each question, the administrator can define any number of conditions to
|
|
check against the requestor's answer. When a requestor submits an answer that does
|
|
not comply with all of the conditions, the answer is flagged in the interface
|
|
as making the expense non-reimuburseable. The first release must support the
|
|
following conditions:
|
|
|
|
* Boolean: is yes, or is no
|
|
* Selection: the selected value is in a specific subset of values
|
|
* Date: the value is N days before and/or after today or a date in another answer
|
|
|
|
Using these same conditions, the administrator can define questions that are
|
|
conditional on other questions' answers. These questions are only presented
|
|
to the requestors when they submit an answer that meets the specified conditions.
|
|
For illustration purposes, the canonical deployment will have
|
|
relatively few unconditional questions about each expense (type of expense,
|
|
receipt, amount), and then a series of conditional questions based on those
|
|
answers (e.g., follow-up questions specific to airfare expenses,
|
|
accommodations expenses, etc.).
|
|
|
|
### Requestor workflow
|
|
|
|
Requestors can log in and see the status of all their requests. They can also
|
|
create a new request, which starts either the Pre-Approval or the In Progress
|
|
state.
|
|
|
|
When they view a report, it shows the questions and answers about the entire
|
|
report, and a list of associated expenses. Viewing a specific expense
|
|
similarly shows all the questions and answers about it.
|
|
|
|
When a report is in the Pre-Approval state, the requestor is submitting not
|
|
receipts or invoices, but documents regarding potential expenses that have
|
|
not yet been incurred, but for which organization policies require
|
|
preapproval by organizational management ahead of time. The appropriate
|
|
management representatives are duly notified by the system of pending
|
|
Pre-Approval requests, and their approval moves the request into the In
|
|
Progress state. Their rejection moves the request to the Rejected sate.
|
|
|
|
When a report is In Progress state, the requestor can edit any answer in the
|
|
report or an associated expense. They can also add an expense, which begins
|
|
by asking them unconditional questions associated with expenses, and then
|
|
follow-up questions as necessary based on those answers.
|
|
|
|
When an In Progress report has at least one expense associated with it, and
|
|
all questions have been answered, the requestor may submit the request for
|
|
approval. If any of the answers do not meet the administrator's conditions
|
|
for payment, the requestor may still submit the request, and provide an
|
|
explanation for why the request should be paid (e.g., because it was
|
|
approved in advance). Once the request is submitted, it moves to the
|
|
Submitted state.
|
|
|
|
### Bookkeeper workflow
|
|
|
|
Bookkeepers can log into the system and see all requests.
|
|
|
|
When bookkeepers review a Submitted report, they can change the report's
|
|
state, and include a note explaining why the report was moved to that state
|
|
(e.g., moved back to In Progress because a specific receipt was insufficient
|
|
documentation). When they do this, the system sends e-mail to the requestor
|
|
letting them know about the change, including the rationale provided by the
|
|
bookkeeper.
|
|
|
|
The bookkeeper can export any request to the books. The first release of the
|
|
software will simply provide an archive that includes all of the request's
|
|
supporting documentation, plus a `.ledger` file with entries for each
|
|
expense. However, note that when building this feature in the code and UI,
|
|
it should be relatively generic. Exporting should remain abstract enough
|
|
that integration with other accounting systems remains simple and
|
|
straightforward. Note that even the mechanics could be different; for
|
|
example, an SQLedger exporter may add entries to the system directly, rather
|
|
than providing the bookkeeper with a file download.
|
|
|
|
## Requirements potentially for first release
|
|
|
|
These are features that we would like the system to have, and it may make
|
|
sense to make them requirements of the first release depending on how it's
|
|
built.
|
|
|
|
* CiviCRM integration: Many NPOs are already using CiviCRM. CiviCRM
|
|
integration would provide a familiar interface to users, and simplify
|
|
system administration for the organization. It may be possible to build
|
|
the system as a CiviCRM extension. If so, we would get this feature for
|
|
"free."
|
|
|
|
* Usable without JavaScript: For consistent mission advocacy, it's important
|
|
that some organizations not require requestor to use JavaScript. (e.g., Tor
|
|
browsers typically have JavaScript disabled because it can undermine Tor's
|
|
anonymity guarantees.) It should be possible to submit payment
|
|
requests without JavaScript. The interface can be enhanced when JavaScript
|
|
is available.
|
|
|
|
Whether or not we do this in the first release probably depends on what
|
|
framework we decide to build on. If the framework itself requires
|
|
JavaScript out of the box, it may make sense to have the first release go
|
|
with the flow, then work to add JavaScript-free functionality in a later
|
|
release.
|
|
|
|
|
|
## Requirements for later releases
|
|
|
|
These are features that we would ultimately like the system to have, but we
|
|
know aren't necessary for the first version. It's good to keep them in mind
|
|
when architecting, but also to know that they've been considered and aren't
|
|
immediately necessary.
|
|
|
|
* Allow optional questions: With this, question conditions probably need to
|
|
be extended to address the case of "other question isn't answered"
|
|
|
|
* Additional exporters:
|
|
* Export to SQLedger
|
|
* [Certainly many more, feel free to add them here]
|
|
|
|
* Richer lifecycle management: A leader may need to approve a request before
|
|
it's added to the books, like an employee's manager or a program director
|
|
|
|
* Various currency improvements:
|
|
* Automatic currency conversion for validation (e.g., validate that an amount
|
|
in an aribtrary currency is within a limit in USD)
|
|
|
|
* Validate currency amounts from outside data sources: The main case for
|
|
this is per diem, where many organizations use rates that are determined
|
|
by another party (e.g., US GSA) and updated periodically.
|
|
|
|
* Handle totaling the request based on currency (e.g., expenses can are in
|
|
USD, EUR, CHR but the traveler may want payment in INR.) Unclear what
|
|
interface for this would look like, but real-time data about past
|
|
currency rates might be available via an API somewhere, and we can use
|
|
that to have the requestor give us "preferred currency for payment" so
|
|
all changes happen in real time in the interface (even allowing the
|
|
requestor to be able to decide *while filling out the report*: "ugh,
|
|
these exchange rates to INR are horrible; I'll have them pay my USD
|
|
account instead").
|
|
|
|
* Data import: Apps like [Tricky Tripper](http://trickytripper.blogspot.de/)
|
|
let users track expenses for a trip as they go. The system could import
|
|
this data to prepopulate answers to questions about the request and
|
|
expenses in it. Probably there would be an import API that can map
|
|
different import formats to a common format, and then administrators can
|
|
define how questions in their system can be answered based on imported
|
|
data.
|