Add : Export to LedgerSMB

* Simple sentences with present tone.
* Reorganize a bit for current priorities.

Reimbursements.mdwn

@@ -0,0 +1,13 @@
+# Payment Request software project
+
+Many non-profit organizations in our space handle payment requests from various parties, like reimbursement requests from employees and volunteers.  Handling these requests can be arduous for both sides: organizations often have nuanced rules for what can be reimbursed when, meaning it's work for requesters to be sure what they should submit, and work for the organization to make sure everything in a request is acceptable.
+
+This software will help organizations set up web forms that walk requesters through the process of filing a payment request.  It will prompt requesters for all the necessary documentation, and automatically validate that submissions meet the organization's payment criteria.  This guidance will help requesters make a submission that can be paid the first time, reducing lengthy reviews and back-and-forth.
+
+Once a request has been accepted, the software will be able export the payment request to the organization's books.  No more time-consuming and error-prone manual data copying.  And since this is a relatively limited interface to the organization's finances, this is a self-contained system we can develop now to get organizations started using NPO Accounting software without committing to a big change in their existing systems.
+
+We've started developing an extension to CiviCRM to add this functionality.  Check out the [Git repository on Conservancy's Kallithea server](https://k.sfconservancy.org/NPO-Accounting/civipay).
+
+If you'd like to dive in, we have [[implementation notes for CiviCRM|Reimbursements/OnCiviCRM]], which provides some technical background for how the extension is built.
+
+To read more about what we're building, including plans for near- and long-term development, see our [[requirements document|Reimbursements/Requirements]].

Reimbursements/OnCiviCRM.mdwn

@@ -0,0 +1,42 @@
+# CiviCRM extension plan
+
+One possibility for building the reimbursement system is to make a CiviCRM extension.
+
+The reimbursement system's early development is focused primarily on helping requestors submit a complete reimbursement request, and helping bookkeepers add those requests to the books quickly.  Actual accounting primarily enters the picture at the end of the process, when the bookkeeper is ready to accept a request into the books.  From this perspective, CiviCRM provides a lot of fuctionality the core system would need:
+
+* Users related to an organization, with different access levels
+* Users outside the organization can log in and submit forms
+* Forms customizable by sysadmins
+* Request tracking, with e-mail updates
+
+A CiviCRM extension will probably be easier for other organizations to adopt as well.  Those that already have CiviCRM installed will already have most of the necessary deployment infrastructure, and probably experience working with other CiviCRM extensions already.
+
+Think of this as a shared notepad: it's a place to discuss implementation ideas and notes.  We might be missing information about specific CiviCRM functionality, and may not be following all the best practices.  If you know something we don't, please feel free to jump in and make suggestions!
+
+## Extending CiviCase
+
+CiviCase seems to provide a useful base to build the reimbursement system from.  A "case" in CiviCRM parlance represents an ongoing interaction with someone outside the organization.  It has expected workflows and timelines, and can end in a few different states.  Actions on cases are recorded, and everyone involved can get e-mail updates about those changes.  All of these map very well to the workflow imagined in the requirements document.
+
+It seems reasonable to implement the whole request for reimbursement as a case.  The question from there is how to add the variable expense information to it.
+
+## How to represent expenses and build forms for them
+
+It's tempting to use Activities to represent expenses.  Activities represent someone doing something; the core information is all relevant to expenses; and they can have custom fields attached to them, representing the additional information required for each type of expense.
+
+But it seems like the mental model for Activities is closer to "things the organization itself does."  The docs say, "If it is important for you to know who at your organisation carried out a task, then record it as an activity."  That rationale doesn't consistently apply to expenses.  Because of that, I wonder if representing expenses as different kinds of Activities would lead to trouble down the line.
+
+It might be safer to introduce a new Expense object type.  Functionally it might act very similarly to Activities, but keeping them separate in the system and UI would prevent trouble if they need to grow in different directions in the future.  In particular, if we could attach custom fields to them, that means a lot of CiviCRM's existing field building functionality would meet our needs.
+
+## Saving files associated with expenses
+
+Out of the box, files that are uploaded to CiviCRM (e.g., attachments) go to the framework's public files directory.  This means that anybody who knows the filename can get the file, even if they're not logged into the system.  This doesn't seem secure enough for files that might include sensitive financial information.
+
+On a new install, at least, you can configure CiviCRM to save file uploads to a different directory by changing Directory Preferences→uploadDir.  It would suit our purposes if this was a non-accessible directory; then our extension could serve the files to people who were authorized to view them.
+
+[CiviCRM recommends making this configuration change](https://civicrm.org/advisory/civi-sa-2014-001-risk-information-disclosure).  Given that, I think we can count on administrators to have done so, and be satisfied with the security on the uploads directory, even though it's out of our hands.
+
+Note that we'll need to be careful to make sure files go to `uploadDir`, and not `imageUploadDir`, where anonymous web access still needs to be allowed.
+
+## Money type
+
+CiviCRM's Money type simply ensures that the input is numeric, with up to two decimal points.  See [this regexp](https://github.com/civicrm/civicrm-core/blob/4.7.12/CRM/Utils/Rule.php#L557).  It does not, out of the box, support specifying a currency.  When forms call for a money input, it will probably be implemented as two inputs: a Currency pulldown (which we can implement and install so administrators don't have to define it themselves), and a Money input for the numeric part.

Reimbursements/Requirements.mdwn

@@ -179,7 +179,9 @@ effort for the first release.
 * Additional exporters
 
   * Export to SQLedger
-
+  
+  * Export to LedgerSMB
+ 
   * [Certainly many more, feel free to add them here]
 
 * Richer lifecycle management
@@ -238,6 +240,19 @@ base system or framework.
     formats to a common format, and then administrators can define how
     questions in their system can be answered based on imported data.
 
+* Automatically prepare payment
+
+  * Print checks with the requestor's name and approved amount
+
+  * Automatically submit wire transfers through standard APIs like HBCI
+
+  [I think this is required functionality for the NPO Accounting Project in
+  the long term, but there are probably other solutions if it's not
+  included directly in this reimbursement system.  I think we'd be willing
+  to use an existing system or framework that didn't have a good way to
+  provide this functionality, as long as there could be another way to build
+  it.]
+
 * Provide iCalendar feeds for request-related tasks
 
   We could implement any combination of the following:

index.mdwn

@@ -7,24 +7,22 @@ NPO Accounting Software Project
 Current Status
 ==============
 
-We're currently planning a Reimbursement and Payment Request system.  We
+We're currently developing a Reimbursement and Payment Request system.  We
 believe this is a relatively standalone component that other organizations
-could start using quickly.  Check out the
-[[requirements document|Reimbursements/Requirements]] and let us know if
-you think anything's missing.  Software development will begin soon.
+could start using quickly.  Check out the [[project page|Reimbursements]].
 
 <a id="howtohelp"></a>
 Contributing to the Project
 ========================
 Conservancy welcomes the help of anyone who is interested in this issue to
-design and develop this software.  You can help us by:
+design and develop this software.
 
-  * Editing this Wiki!
-  * Joining the discussion on [the mailing list for this project](https://lists.sfconservancy.org/mailman/listinfo/npo-accounting)
-  * Joining the discussion on
-    [the IRC channel, #npoacct on irc.freenode.net](irc:irc.freenode.net/npoacct) ([logs](/irclogs/)).
-  * Submit patches and merge requests to [npo-accounting Ledger CLI tutorial](https://gitorious.org/ledger/npo-ledger-cli/).
-  * [Donating money to fund this effort!](https://sfconservancy.org/campaign/)
+  * Contribute to our [CiviCRM extension for payment requests](https://k.sfconservancy.org/NPO-Accounting/civipay).
+  * Edit this Wiki.
+  * Join the [mailing list for this project](https://lists.sfconservancy.org/mailman/listinfo/npo-accounting)
+  * Join the discussion on
+    [our IRC channel, #npoacct on irc.freenode.net](irc:irc.freenode.net/npoacct) ([logs](/irclogs/)).
+  * [Donate money to fund this effort!](https://sfconservancy.org/campaign/)
 
 Work So Far
 ===========

sandbox.mdwn

@@ -37,7 +37,7 @@ Bulleted list
 
 * continuing the list at the top level
 
-Paragraph with `inline code`
+Paragraph with `inline code` which can occur `multiple times`
 
       code block
       it's a block of code

templates/page.tmpl

@@ -103,6 +103,7 @@
 
                 <a href="http://validator.w3.org/check?uri=referer">Valid (X)HTML 5</a><br/>
                 <a href="/about/javascript.html" rel="jslicense">Javascript license information</a>
+                - <a href="https://sfconservancy.org/privacy-policy/">Privacy Policy</a>
             </p>
         </div>
       </footer>