@@ -92,25 +92,25 @@ 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
documentation). When they do this, the system sends email 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.