### Defining the request form

Requests for payment have four states: In Progress, Submitted,

Accepted, and Rejected.

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)

* 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

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

For illustration purposes, the common deployment is expected to 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.).

create a new request, which starts in 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.

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

approval.  If any of the answers do not meet the administrator's conditions

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 a bookkeeper reviews 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

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

  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

  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