Changeset - 49d91f04e597
[Not reviewed]
Brett Smith (brett) - 7 years ago 2016-08-31 15:45:10
brett@sfconservancy.org
Policy validation can wait until after the first release.

The policy validations that would help reduce back and forth most are
the ones that are hard to implement: checking that attachments
actually include the necessary information, checking that per diems
match limits, etc. Building to be able to accommodate these is going
to take time, and we don't need to make all that investment for the
first release.
1 file changed with 64 insertions and 46 deletions:
0 comments (0 inline, 0 general)
Reimbursements/Requirements.mdwn
Show inline comments
...
 
@@ -34,37 +34,31 @@ 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
 
* Currency (We may not need strict validation, but the system must at least
 
  understand that different currencies exist, and be able to validate that a
 
  currency is specified when needed.  Using a plain Number for currency is
 
  not sufficient.)
 
* 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.).
 
Other types like boolean and date would be nice, but I think they could be
 
expressed with the types above.
 

	
 
It is expected that one question about expenses will be the type of expense
 
(e.g., airfare, accommodations, meals, office supplies).  The administrator
 
must be able to define follow-up questions that are asked based on the
 
expense type, to request additional information as required by policy.  For
 
example, Conservancy requires airfare search results to be attached to
 
airfare reimbursement requests.  Requestors should be prompted for this
 
documentation when submitting reimbursements for flights, and not for other
 
expenses.
 

	
 
### Requestor workflow
 

	
 
Requestors can log in and see the status of all their requests.  They can also
 
create a new request, which starts in the In Progress
 
state.
...
 
@@ -72,22 +66,21 @@ 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 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
 
by asking them questions common to all 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.
 
approval, along with optional notes about the request.
 
Once the request is submitted, it moves to the Submitted state.
 
Bookkeepers receive an e-mail notification that the request is ready for
 
review, including the notes written by the requestor.
 

	
 
### Bookkeeper workflow
 

	
 
Bookkeepers can log into the system and see all requests.
 

	
 
When bookkeepers review a Submitted report, they can change the report's
...
 
@@ -144,15 +137,47 @@ would also like to release a first version as early as possible, to start
 
getting feedback from users and generating more development interest.  It's
 
good to keep these in mind when architecting—in particular, we may choose an
 
existing system to use, or framework to build on, based on its ability to
 
support these features.  However, they needn't be a focus of development
 
effort for the first release.
 

	
 
* Administrator-defined policy validations
 

	
 
  Some validations we would like to have:
 

	
 
  * A value from a selection is in a specific subset of values
 

	
 
  * A date is within N days before and/or after today or a date in another answer
 

	
 
  * A currency amount is over or under a limit, with automatic conversion as needed
 

	
 
  * The limit on a currency amount is defined by an outside source - The
 
    main case for this is per diem, where many organizations use rates that
 
    are determined by another party like the US GSA and updated periodically.
 

	
 
  These may need to be compounded.  For example, an administrator may want
 
  to define a policy, "If an employee did not use a preferred airline, and
 
  did not travel internationally, it does not meet policy."
 

	
 
* Flag non-reimburseable expenses based on policy validations
 

	
 
  When the requestor answers questions that are outside the policy
 
  validations, the system should flag the answer and explain how it falls
 
  outside policy.  The requestor should still be able to submit the request,
 
  but they should be prompted to explain why the request should be fulfilled
 
  despite policy problems.
 

	
 
* Ask additional questions based on policy validations
 

	
 
  For example, "If the expense type is office supplies, and the cost is over
 
  $50, prompt for a receipt."
 

	
 
* Allow optional questions
 
  * Along with this, question conditions probably need to
 
    be extended to address the case of "other question isn't answered"
 

	
 
  Along with this, policy validations 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
...
 
@@ -166,29 +191,22 @@ effort for the first release.
 
    requests, and their approval moves the request into the In Progress
 
    state.  Their rejection moves the request to the Rejected sate.
 

	
 
  * 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").
 
* Show currency amounts in the requestor's reimbursement currency
 

	
 
  For example, the requestor can submit a reimbursement with expenses in
 
  USD, EUR, and CHR, but wants 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
0 comments (0 inline, 0 general)