working on cash discount abstraction (XR and reading is still missing)

doc/development_documentation.md

@@ -1,5 +1,5 @@
 
-## General approach
+## Typical process
 
 1. build
 
@@ -29,6 +29,18 @@ If you do a pull request, please do a feature branch, e.g. if you are working on
 Most of mustang is a library, adding (autmated junit) test cases is often not only the most sustainable but also the fastest way to see if new/changed functionality works. If something is changed so that old test cases break on purpose please do not just remove them but take the time to fix the test cases
 
 
+## Typical workflow
+
+If e.g. new elements or attributes are added, they are often added
+* in the object so that a developer can use them
+* in the interface so that a old fashioned developer could use them as well
+* in the pullprovider so that it actually finds it's way into the XML
+* in at least one test, after the test has been run this should at least once be 
+* validated. If that works one can start implementing the 
+* reading part (along with tests), then it needs to be
+* documented e.g. on the homepage and 
+* communicated, at the very least by mentioning it in the history.md
+
 ## Architecture
 
 Mustang contains a library to read/write e-invoices,