update docs

Policies & Guidelines/Accounting.md

@@ -1 +1,22 @@
+# Accounting
+
+## Accounting Standards
+
+The German legally binding accounting regulations must be followed (i.e. Abgabenordnung AO, Umsatysteuergesetz UStG).
+
+### Account System
+
+The account system follows SKR 03 (Standardkontenrahmen).
+
+New real accounts, cost centers and cost objects can only be created by the head of finance, head of controlling or head of accounting. Additionally, automated workflows may also generate real accounts, cost centers and cost objects. Examples for such automated workflows can be updates to the account system, creation of new departments etc.
+
+### Depreciation
+
+Amortization periods are based on the standard depreciation amortization periods provided by the Bundesfinanzministerium.
+
+## Reporting Standards
+
+
+
+2022-01-01 - Version 1.0
 

Policies & Guidelines/Code of Conduct.md

@@ -1,4 +1,4 @@
-# Contributor Covenant Code of Conduct
+# Code of Conduct
 
 ## Our Pledge
 

Policies & Guidelines/Confidentiality Policy.md

@@ -50,4 +50,4 @@ This policy is binding even after separation.
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Policies & Guidelines/Conflict of Interest Policy.md

@@ -34,4 +34,4 @@ Disrespecting this policy possibly leads to a warning and potnetially excluding
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Policies & Guidelines/General Definitions & Standards.md

@@ -0,0 +1,70 @@
+# General Definitions & Standards
+
+## Key words to indicate requirement levels
+
+### Copyright Notice
+
+Copyright © The Internet Society (1997). All Rights Reserved.
+
+### Abstract
+
+In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
+
+    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+Note that the force of these words is modified by the requirement level of the document in which they are used.
+
+1.  MUST
+
+This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
+
+2.  MUST NOT
+
+This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
+
+3.  SHOULD
+
+This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
+
+4.  SHOULD NOT
+
+This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
+
+5.  MAY
+
+This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
+
+6.  Guidance in the use of these Imperatives
+
+Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
+
+7.  Security Considerations
+
+These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification.
+
+8.  Acknowledgments
+
+The definitions of these terms are an amalgam of definitions taken from a number of RFCs. In addition, suggestions have been incorporated from a number of people including Robert Ullmann, Thomas Narten, Neal McBurnett, and Robert Elz.
+
+**Author's Address**
+Scott Bradner
+Harvard University
+1350 Mass. Ave.
+Cambridge
+MA 02138
+Phone:   - +1 617 495 3864
+Email:   sob@harvard.edu
+
+### Full Copyright Statement
+
+Copyright © The Internet Society (1997). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+## Date Time Format
+
+The date time format in all documents must follow the [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) standardization: `YYYY-MM-DD` or `YYYY-MM-DD HH:MM:SS` (sometimes written as `YYYY-MM-DD h:i:s`). 

Policies & Guidelines/IT/Backup and Data Recovery.md

@@ -0,0 +1,8 @@
+# Backup and Data Recovery
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Change Management.md

@@ -0,0 +1,8 @@
+# Change Management
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Database Guidelines.md

@@ -0,0 +1,8 @@
+# Database Guidelines
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Development and Maintenance.md

@@ -0,0 +1,8 @@
+# Development and Maintenance
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/General Employee Guideline.md

@@ -0,0 +1,8 @@
+# General Employee Guideline
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Jobs.md

@@ -0,0 +1,8 @@
+# Jobs
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Operations Guidelines.md

@@ -0,0 +1,8 @@
+# Operations Guidelines
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Password Guideline.md

@@ -0,0 +1,8 @@
+# Password Guideline
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/IT/Software Guidelines.md

@@ -0,0 +1,8 @@
+# Software Guideline
+
+
+
+
+
+2022-01-01 - Version 1.0
+

Policies & Guidelines/Organization Activity Policy.md

@@ -12,4 +12,4 @@ Extremely few or insignificant contributions may lead to the exclusion from the
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Policies & Guidelines/Organization Guidelines.md

@@ -22,4 +22,4 @@ Disrespecting this policy possibly leads to a warning and potnetially excluding
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Processes/01_Development.md

@@ -10,9 +10,9 @@ Every organization member and contributor to the organization must follow the [c
 
 ## Becoming a contributor
 
-For public repositories you can immediately start by creating forks and pull requests. For private repositories which are necessary to setup the complete developer environment, feel free to request access. Please not that we may not immediately give you access to private repositories and instead will give you smaller tasks regarding public repositories. Please contact spl1nes.com@googlemail.com for more details.
+For public repositories you can immediately start by creating forks and pull requests. For private repositories which are necessary to setup the complete developer environment, feel free to request access. Please not that we may not immediately give you access to private repositories and instead will give you smaller tasks regarding public repositories. Please contact spl1nes.com@googlemail.com for more details. (R1)
 
-For all contributions our [Contributor License Agreement ("CLA")](https://github.com/Karaka-Management/Organization-Guide/blob/develop/legal/individual contributor license agreement.md) comes into effect.
+For all contributions our [Contributor License Agreement ("CLA")](https://github.com/Karaka-Management/Organization-Guide/blob/develop/legal/individual contributor license agreement.md) comes into effect. (R2)
 
 ## Code changes
 
@@ -24,9 +24,9 @@ Developers  are encouraged to pick open tasks with high priorities according to
 
 Open tasks can be found in the project overview: [PROJECT.md](https://github.com/Karaka-Management/Organization-Guide/blob/master/Project/PROJECT.md)
 
-Tasks  currently in development are prefixed in the priority column with an  asterisk `*` and a name tag in the task description of the developer who is working on the task.
+Tasks currently in development are prefixed in the priority column with an  asterisk `*` and a name tag in the task description of the developer who is working on the task.
 
-The open  tasks are reviewed once a month by a senior developer. The senior developer updates the project overview if necessary and requests  feedback regarding development status of important tasks under development. During this process important tasks may also get directly assigned to developers. This review is performed on a  judgmental bases of the senior basis.
+The open tasks are reviewed once a month by a senior developer. The senior developer updates the project overview if necessary and requests feedback regarding development status of important tasks under development. During this process important tasks may also get directly assigned to developers. This review is performed on a  judgmental bases of the senior basis.
 
 ### Quality
 
@@ -34,7 +34,7 @@ The open  tasks are reviewed once a month by a senior developer. The senior deve
 
 Code changes must follow the [style guidelines](https://github.com/Karaka-Management/Developer-Guide/tree/develop/standards). Additionally, the automatic code style inspection tools must return no errors, failures or warnings. Developers should test their changes with inspection tools and configurations mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) in advance before submitting them for review.
 
-In rare  cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be changes in the programming language, special  cases which cannot, are difficult or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review.
+In rare  cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be changes in the programming language, special  cases which cannot, are difficult or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review. (R3)
 
 Automated checks which are run during the review process:
 
@@ -58,7 +58,7 @@ npx jasmine-node ./
 ./cOMS/tests/test.sh
 ```
 
-Additional inspections which are run but might be ignored during the review depending on the use case are mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) as other checks.
+Additional inspections which are run but might be ignored during the review depending on the use case are mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) as other checks. (R4)
 
 #### Code review
 
@@ -66,11 +66,11 @@ In addition to the automatic code review performed by the various inspection too
 
 In case a code change request is not approved the reviewer states the reason for the decision, this may include some tips and requests which will allow the contributor to make improvements so that the code change may get approved.
 
-If the code reviewer only finds minor issues with the proposed code change the reviewer may make small changes to the proposed code change and inform the contributor to speed up the implementation process. Code reviewers are encouraged to do this with new contributors to avoid long iteration processes and to not discourage new developers. However, communication is key and severe issues with code change requests or if the contributor already made multiple code change requests in the past the reviewer should not implement the improvements by himself and rather decline the code change requests with his reasoning.
+If the code reviewer only finds minor issues with the proposed code change the reviewer may make small changes to the proposed code change and inform the contributor to speed up the implementation process. Code reviewers are encouraged to do this with new contributors to avoid long iteration processes and to not discourage new developers. However, communication is key and severe issues with code change requests or if the contributor already made multiple code change requests in the past the reviewer should not implement the improvements by himself and rather decline the code change requests with his reasoning. (R3+R4)
 
 #### Demo
 
-Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically.
+Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically. (R4)
 
 ### Release flow
 
@@ -91,4 +91,4 @@ The senior developer who performs the code review merges the change request into
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Processes/01_Development_Flowchart.md

@@ -1,2 +1,23 @@
 # Development Flowchart
 
+```mermaid
+graph TD;
+    SETUP_DEV_ENV([Seup Dev Environment])-->HAS_ACCESS{Has code access?};
+    HAS_ACCESS-- YES -->FORK[Fork or Pull];
+    HAS_ACCESS-- NO -->REQUEST_ACCESS[Request access via mail];
+    FORK-->NEW_BRANCH[Create new branch];
+    REQUEST_ACCESS-->FORK;
+    NEW_BRANCH-->CHANGE[Make changes];
+    CHANGE-->TEST_CHANGE[Test changes locally];
+    TEST_CHANGE-->IS_SUCCESSFUL{Is successful?};
+    IS_SUCCESSFUL-- YES -->PULL_REQUEST[Pull request];
+    IS_SUCCESSFUL-- NO -->FIX[Fix];
+    FIX-->TEST_CHANGE;
+    PULL_REQUEST-->AUTOMATIC_CHECKS[Automatic system checks]
+    AUTOMATIC_CHECKS-->MANUAL_CHECKS[Manual checks]
+    MANUAL_CHECKS-->IS_ACCEPTED{Is accepted?};
+    IS_ACCEPTED-- YES -->MERGE([Merge]);
+    IS_ACCEPTED-- NO -->FIX;
+    FIX-->TEST_CHANGE;
+```
+

Processes/01_Development_Risk Control Matrix.md

@@ -0,0 +1,9 @@
+# Development Risk Control Matrix
+
+| No.  | R                 | Category                       | Risk Event                                                   | L    | C    | O                 | Mitigation Type              | Mitigation Strategy                                          | L*   | C*   | Changes | Comments                                                     | ES   | EY   |
+| ---- | ----------------- | ------------------------------ | ------------------------------------------------------------ | ---- | ---- | ----------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- |
+| 1    | CTO               | Operational Risk (Development) | Unauthorized source code and development asset access.       | 1    | 1    | Many times a day  | Preventing (System & Manual) | Only authorized people gain access to confidential source code and development assets. | 1    | 1    |         | Not all source code and development assets are considered confidential and may be publicly accessible. The confidential aspects are determined by the CTO. | yes  | yes  |
+| 2    | CTO               | Operational Risk (Development) | Undefined terms of intellectual property for code contributions. | 1    | 3    | Many times a day  | Preventing (Manual)          | The terms of intellectual property for all contributions are well defined. | 1    | 1    |         |                                                              | yes  | yes  |
+| 3    | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5    | 1    | Many times a day  | Preventing (System & Manual) | Code styles are automatically tested with code style checkers. | 2    | 1    |         | Not all code style options can be reasonably checked and defined. In some cases it's also possible to have false positive code style violations for edge cases. Manual checks during the code review by the responsible person may lead to additional code style changes or ignoring some code style "violations" if deemed reasonable. | yes  | yes  |
+| 4    | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal.         | 5    | 4    | Many times  a day | Preventing (System & Manual) | Static code analysis tools and written tests for automatic tests. Additionally, manual tests can be performed in a demo environment with self generated dummy data. | 2    | 1    |         |                                                              |      |      |
+

Processes/02_Purchase.md

@@ -1,13 +1,56 @@
 # Purchase
 
-| No.  | Process step | Risks/Things to consider | Checks/Risk mitigation | R    | O    |
+## Inquiry / Offer
-| ---- | ------------ | ------------------------ | ---------------------- | ---- | ---- |
-|      |              |                          |                        |      |      |
-|      |              |                          |                        |      |      |
-|      |              |                          |                        |      |      |
 
-Abbreviations:
+Before purchasing employees must perform some research depending on the type and purchase amount. Generally, employees should always compare prices and also different vendors. For purchases above 1,000 EUR for single unit prices or above 50,000 EUR for total invoice expenses employees must always compare prices, argue why they choose a certain product and vendor and provide evidences of such research. Sometimes it can be applicable to not only compare different vendors but also different product types. This research may require to already request offers from potential suppliers and perform negotiations. Please use the **Vendor Comparison Form**. (R1)
 
-* R: Responsible
+## Offer approval
-* O: Occurrence
 
+The approval of offers must be performed according to the below mentioned approval table. The approval is done by signature on the offer with date. (R2)
+
+### Approval table
+
+| Amount                    | Approval by                                      |
+| ------------------------- | ------------------------------------------------ |
+| 0 - 250.00 EUR            | Direct superior (can also be head of department) |
+| 250.01 - 1,000.00 EUR     | Head of department                               |
+| 1,000.01 - 100,000.00 EUR | Head of department + Head of Finance             |
+| > 100,000.00 EUR          | Head of department + Head of Finance + CEO       |
+
+*It's possible to skip stages in the approval table. This means a higher instance may approve a purchase without a signature from an employee in a previous step of the approval process.*
+
+## Purchasing
+
+The purchasing department creates an order in the IT system referring to the offer if available and forwards this order to the supplier. 
+
+For small orders below 1,000 EUR which are done at online shops or direct purchases in local shops no order in the IT system must be made. The reason for this is to increase efficiency for minor invoices. For purchases in local shops it's also not necessary that the purchase department itself does the purchasing but another department may do them.
+
+All documents related to the purchasing process (i.e. offers, negotiation documentation, order confirmations, invoices etc.) must be stored in the IT system and referred to the respective purchase.
+
+## Supplier invoice validation
+
+The invoice from the supplier must be stored in the IT system where it must be validated by the system. The system validates the following aspects:
+
+* Valid and correct VAT ID
+* VAT amounts and percentages mentioned on the invoice
+* Supplier rating for invoices above 1,000 EUR.
+  * Ratings above 300, C or similar must be approved by the head of purchasing in the IT system
+* Invoice amount is equals to the order amount (if available)
+* Individual prices (if available in the order)
+* Individual items on the invoice (if available in the order)
+
+In case of differences the head of the department the order was performed for and the head of purchasing in the IT system must approve the differences.
+
+All invoices must be approved by the purchase employee handling the invoice. (R3)
+
+## Accounting
+
+### Booking
+
+The it system generates a booking suggestion for the invoice. This suggestion is based on automatic invoice recognition and manually trained system behavior (see accounting process for more details). The accountant booking the invoice can adjust the booking suggestion. Reasons for this can be a new business case, the booking suggestion must be split between multiple accounts, cost centers or cost objects which didn't get recognized or defined during the purchasing step.
+
+The IT system generates a monthly booking list with all invoices and their booking. The head of finance has to perform random checks on this list and approve the list in the IT system.
+
+### Payment
+
+The accountant starts the payment process by telling the IT system to genrate a list of all payment suggestions according to the invoice payment terms. The system automatically calculates cash back and forex differences. The accountant may add or remove invoices from the suggestion. Both the accountant and the head of finance sign off on the payments in the IT system.

Processes/02_Purchase_Flowchart.md

@@ -0,0 +1,39 @@
+# Purchase Flowchart
+
+```mermaid
+graph TD;
+    INQUIRY([Inquiry by employee])-->OFFER[Offer from supplier];
+    OFFER-->APPROVAL[[Approval]];
+    APPROVAL-->APPROVED{Is approved?};
+    APPROVED-- Yes -->ORDER[Order by purchase department];
+    ORDER-->INVOICE[Invoice from supplier];
+    INVOICE-->CHECK_INVOICE{Is valid?};
+    CHECK_INVOICE--Yes-->FORWARD_TO_ACCOUNTING[Forward to accounting];
+    CHECK_INVOICE--No-->FORWARD_TO_RESPONSIBLE[Forward to head of purchase and responsible head of];
+    FORWARD_TO_RESPONSIBLE-->CHECK_INVOICE_2{Is valid?};
+    CHECK_INVOICE_2--Yes-->FORWARD_TO_ACCOUNTING;
+    CHECK_INVOICE_2--No-->CLARIFY[Clarify with supplier];
+    FORWARD_TO_ACCOUNTING-->BOOKING[Booking invoice];
+    BOOKING-->PAYING[Pay invoice];
+```
+
+## Approval Flowchart
+
+```mermaid
+graph TD;
+	APPROVAL[[Approval]]--Below 250-->APPROVAL_BY_SUPERIOR[Approval by supperior]
+	APPROVAL_BY_SUPERIOR-->STAGE_1{Is approved?}
+	STAGE_1--Yes-->ORDER[Order by purchase department]
+	APPROVAL--Above 250-->APPROVAL_BY_HEAD_OF[Approval by head of department]
+	APPROVAL_BY_HEAD_OF-->STAGE_2{Is approved?}
+	STAGE_2--Yes-->IS_ABOVE_2{Is above 1,000?}
+	IS_ABOVE_2--Yes-->APPROVAL_BY_HEAD_OF_FINANCE[Approval by head of finance]
+	IS_ABOVE_2--No-->ORDER
+	APPROVAL_BY_HEAD_OF_FINANCE-->STAGE_3{Is approved?}
+	STAGE_3--Yes-->IS_ABOVE_3{Is above 100,000?}
+	IS_ABOVE_3--Yes-->APPROVAL_BY_CEO[Approval by CEO]
+	IS_ABOVE_3--No-->ORDER
+	APPROVAL_BY_CEO-->STAGE_4{Is approved?}
+	STAGE_4--Yes-->ORDER
+```
+

Processes/02_Purchase_Risk Control Matrix.md

@@ -0,0 +1,8 @@
+# Purchase Risk Control Matrix
+
+| No.  | R                           | Category                    | Risk Event                                                   | L    | C    | O                | Mitigation Type              | Mitigation Strategy                                          | L*   | C*   | Changes | Comments | ES   | EY   |
+| ---- | --------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- |
+| 1    | Employee                    | Operational Risk (Purchase) | Purchasing not the optimal product due to no market research. *"Optimal" includes product/service quality, vendor reliability, price, ...* | 1    | 1    | Many times a day | Preventing (Manual)          | Compare products and vendors                                 | 1    | 1    |         |          | yes  | yes  |
+| 2    | See purchase approval table | Operational Risk (Purchase) | Unauthorized purchase (budget risks, fraud, compliance, ...) | 1    | 1    | Many times a day | Preventing (Manual)          | Authorize purchases according to the purchase approval table. This functions as control and separation of responsibilities. | 1    | 1    |         |          | yes  | yes  |
+| 3    | Purchase + Employee         | Operational Risk (Purchase) | Invalid invoice contents (formal or other mistakes)          | 1    | 1    | Many times a day | Preventing (Manual & System) | Automatic system checks and manual checks.                   | 1    | 1    |         |          | yes  | yes  |
+

Processes/06_Finance.md

@@ -1,13 +1,8 @@
-# Inventory
+# Finance
 
-| No.  | Process step | Risks/Things to consider | Checks/Risk mitigation | R    | O    |
+## Inventory
-| ---- | ------------ | ------------------------ | ---------------------- | ---- | ---- |
-|      |              |                          |                        |      |      |
-|      |              |                          |                        |      |      |
-|      |              |                          |                        |      |      |
 
-Abbreviations:
+### Assets
 
-* R: Responsible
+### Merchandise
-* O: Occurrence
 

Processes/COSO/CLC.md

@@ -43,4 +43,4 @@
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Processes/COSO/ITGC.md

@@ -108,4 +108,4 @@
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Processes/COSO/Risk Management/Risk Management.md

@@ -155,5 +155,5 @@ The Risk Management System needs to be reviewed on a regular basis in terms of e
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0
 

Processes/COSO/Risk Management/Risk Register.md

@@ -27,5 +27,5 @@ The risk register is a central repository to describe and track risks as well as
 
 
 
-2022.01.01
+2022-01-01
 

Processes/HR/Colleague Evaluation Form.md

@@ -0,0 +1,17 @@
+# Colleague Evaluation Form
+
+
+| No.  | Colleague Evaluation  | Very Confident | Fairly Confident | Not Very Confident | Not At All Confident | Notes |
+| ---- | ----------------------------- | ---------------| ---------------- | ------------------ | -------------------- | ----- |
+| 2    | My colleagues a broad and deep knowledge overy my work field. | [ ] | [ ]  | [ ]  | [ ]  |   |
+| 3    | My colleagues also considering my job/department when doing their work. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 4    | My colleagues are flexible. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 5    | My colleagues are motivated. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 6    | My colleagues are good at communication. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 7    | My colleagues share information with me accordingly. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 8    | My colleagues are team players. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 10   | My colleagues complete assigned work effectively and on time. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 12   | My colleagues are resilient. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 13   | My colleagues show initiative. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+| 14   | My colleagues work autonomously. | [ ]  | [ ]  | [ ]  | [ ]  |   |
+

Processes/HR/Colleague Evaluation.md

@@ -1,14 +0,0 @@
-
-| No.  | Collegue Evaluation           | Very Confident | Fairly Confident | Not Very Confident | Not At All Confident | Notes |
-| ---- | ----------------------------- | ---------------| ---------------- | ------------------ | -------------------- | ----- |
-| 2    | My colleques a broad and deep knowledge overy my work field. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 3    | My colleques also considering my job/department when doing their work. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 4    | My colleques are flexible. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 5    | My colleques are motivated. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 6    | My colleques are good at communication. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 7    | My colleques share information with me accordingly. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 8    | My colleques are team players. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 10   | My colleques complete assigned work effectively and on time. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 12   | My colleques are resilient. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 13   | My colleques show initiative. | [ ]  | [ ]  | [ ]  | [ ]  |   |
-| 14   | My colleques work autonomusly. | [ ]  | [ ]  | [ ]  | [ ]  |   |

Processes/HR/Company Evaluation Form.md

@@ -0,0 +1,2 @@
+# Company Evaluation Form
+

Processes/HR/Company Evaluation.md

@@ -1 +0,0 @@
-

Processes/HR/Employee Evaluation Form.md

@@ -0,0 +1 @@
+# Employee Evaluation Form

Processes/HR/Employee Evaluation.md

@@ -1 +0,0 @@
-

Processes/HR/Individual Contributor License Agreement.md

@@ -50,4 +50,4 @@ This agreement constitutes the entire agreement and supersedes all prior or cont
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Processes/HR/Self-Evaluation Form.md

@@ -1,4 +1,4 @@
-# HR Self-Evaluation Form
+# Self-Evaluation Form
 
 Name:
 

Processes/Organigram.md

@@ -1,7 +1,21 @@
 ```mermaid
 graph TD;
-    A---B;
+    MANAGEMENT[Management]---DEVELOPMENT[Development];
-    A---C;
+    MANAGEMENT[Management]---SUPPORT_SERVICE[Support & Service];
-    B---D;
+    MANAGEMENT[Management]---IT[IT];
-    C---D;
+    MANAGEMENT[Management]---QM[Quality Management];
+    MANAGEMENT[Management]---PURCHASE[Purchase];
+    MANAGEMENT[Management]---FINANCE[Finance];
+    MANAGEMENT[Management]---HR[HR];
+    MANAGEMENT[Management]---SALES[Sales];
+    MANAGEMENT[Management]---MARKETING[Marketing];
+    DEVELOPMENT---CTO[CTO]
+    SUPPORT_SERVICE---CTO
+    IT---CTO
+    FINANCE---CFO[CFO]
+    PURCHASE---CFO
+    HR---CFO
+    SALES---CSO[CSO]
+    MARKETING---CSO
 ```
+

Processes/Purchase/Vendor Comparison Form.md

@@ -0,0 +1,20 @@
+# Vendor Comparison Form
+
+| Type                | Vendor 1 | Vendor 2 | Vendor 3 |
+| ------------------- | -------- | -------- | -------- |
+| Vendor name         |          |          |          |
+| Product description |          |          |          |
+| Total net expenses  |          |          |          |
+| Pros                |          |          |          |
+| Cons                |          |          |          |
+
+Date: YYYY-MM-DD
+
+Employee: {YOUR_NAME}
+
+Signature:
+
+
+
+2021-01-01 - Version 1.0
+

Processes/Support/Maintenance Checklist.md

@@ -149,4 +149,4 @@ Supervised by (customer):
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0

Processes/Support/Ticket Template.md

@@ -1,6 +1,6 @@
 # Ticket
 
-**Date/Time:** 2022.01.01 -  11:00
+**Date/Time:** 2022-01-01 -  11:00
 
 **Customer:** 123456 - Test customer
 
@@ -26,9 +26,9 @@
 
 
 
-**Closed at:** 2022.01.01 - 13:30
+**Closed at:** 2022-01-01 - 13:30
 
 
 
-2022.01.01 - Version 1.0
+2022-01-01 - Version 1.0
 

Project/PROJECT.md

@@ -13,13 +13,13 @@ Last update of this file: 2022.05.01
 
 ## Latest changelog
 
-### May 2022
+### June 2022
 
 #### New
 
 ##### Application
 
-* 
+* Implement table sorting
 
 ##### Framework
 
@@ -412,6 +412,8 @@ Todos/tasks which are not important enough to be part of the milestones (or don'
 | low      | Kanban                     | The kanban board currently assumes up to 4 columns, however there should be a layout which allows more than 4 columns. Don't use flexbox but min-width and max-width combined with a horizontal scrollable board content |
 | low | Media | Allow to index a local file if it is not in the database (e.g. button with text "Add to Application"). Un-indexed files cannot be changed/moved/deleted. |
 | low      | DataMapperAbstract         | Implement data binding                                       |
+| low | DataMapperFactory | Handle column search/filter for columns which are not 1 to 1 members (e.g. columns are manipulated or the result of multiple data values). One solution could be to pass callbacks for such columns. |
+| low | DataMapperFactory | Consider to only allow search in fields which have `autocomplete => true` defined |
 | low      | Email                      | Find a way to localize some hard coded email content. Pass localization array? Manually overwrite email body if a hard coded/default message should be returned (maybe by checking for a flag/status code)? |
 | low      | DataMapper / ModelFactory  | Some models may require special initialization. For such cases a model factory should be implemented and used by the data mapper. One solution could be to create a default `ModelFactory` which behaves as the current DataMapper functions which set/update the model members. This factory could be extended in case custom behavior becomes necessary. In the Mapper you would just have to define a `const FACTORY` constant which references the factory to use (instead of the default one). Since there hasn't been a situation where this was necessary it will not be implemented until we actually need this (it would additional overhead which maybe never becomes necessary) |
 | low      | Editor             | Create special markdown content (calendar, chart, task, news, comment, media, ...) |