X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fhtml%2Fch02s12.html;h=c692831b02dc326a76dea4c6430c2a4764093c6a;hb=0fe866714abb2a0a63653afcded66b89d0ebe69f;hp=72e760d12448d095186838a547479ff301f9f6ba;hpb=6c0c0f2c43fb4cbc31e21cdd09672f11cde96fff;p=kivitendo-erp.git diff --git a/doc/html/ch02s12.html b/doc/html/ch02s12.html index 72e760d12..c692831b0 100644 --- a/doc/html/ch02s12.html +++ b/doc/html/ch02s12.html @@ -1,67 +1,58 @@ - 2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR

2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: - EUR

2.12.1. Einführung

kivitendo besaß bis inklusive Version 2.6.3 einen - Konfigurationsparameter namens eur, der sich in der - Konfigurationsdatei config/lx_office.conf - befand. Somit galt er für alle Mandanten, die in dieser Installation - benutzt wurden.

Mit der nachfolgenden Version wurde der Parameter zum Einen in - die Mandantendatenbank verschoben und dabei auch gleich in drei - Einzelparameter aufgeteilt, mit denen sich das Verhalten genauer - steuern lässt.

2.12.2. Konfigurationsparameter

Es gibt drei Parameter, die die Gewinnermittlungsart, - Versteuerungsart und die Warenbuchungsmethode regeln:

- profit_determination -

Dieser Parameter legt die Berechnungsmethode für die - Gewinnermittlung fest. Er enthält entweder - balance für - Betriebsvermögensvergleich/Bilanzierung oder - income für die - Einnahmen-Überschuss-Rechnung.

- accounting_method -

Dieser Parameter steuert die Buchungs- und - Berechnungsmethoden für die Versteuerungsart. Er enthält - entweder accrual für die Soll-Versteuerung - oder cash für die Ist-Versteuerung.

- inventory_system -

Dieser Parameter legt die Warenbuchungsmethode fest. Er - enthält entweder perpetual für die - Bestandsmethode oder periodic für die - Aufwandsmethode.

Zum Vergleich der Funktionalität bis und nach 2.6.3: - eur = 1 bedeutete Einnahmen-Überschuss-Rechnung, - Ist-Versteuerung und Aufwandsmethode. eur = 0 - bedeutete hingegen Bilanzierung, Soll-Versteuerung und - Bestandsmethode.

Die Konfiguration "eur" unter - [system] in der Konfigurationsdatei - - config/kivitendo.conf wird nun nicht mehr - benötigt und kann entfernt werden. Dies muss manuell geschehen.

2.12.3. Festlegen der Parameter

Beim Anlegen eines neuen Mandanten bzw. einer neuen Datenbank in - der Admininstration können diese Optionen nun unabhängig voneinander - eingestellt werden.

Beim Upgrade bestehender Mandanten wird eur ausgelesen und die - Variablen werden so gesetzt, daß sich an der Funktionalität nichts - ändert.

Die aktuelle Konfiguration wird unter Nummernkreise und - Standardkonten unter dem neuen Punkt "Einstellungen" (read-only) - angezeigt. Unter System - -> Mandantenkonfiguration können - die Einstellungen auch geändert werden. Dabei ist zu beachten, - dass eine Änderung vorhandene Daten so belässt und damit - evtl. die Ergebnisse verfälscht. Dies gilt vor Allem für die - Warenbuchungsmethode (siehe auch - - Bemerkungen zu Bestandsmethode).

2.12.4. Bemerkungen zu Bestandsmethode

Die Bestandsmethode ist eigentlich eine sehr elegante Methode, - funktioniert in kivitendo aber nur unter bestimmten Bedingungen: - Voraussetzung ist, daß auch immer alle Einkaufsrechnungen gepflegt - werden, und man beim Jahreswechsel nicht mit einer leeren Datenbank - anfängt, da bei jedem Verkauf anhand der gesamten Rechnungshistorie - der Einkaufswert der Ware nach dem FIFO-Prinzip aus den - Einkaufsrechnungen berechnet wird.

Die Bestandsmethode kann vom Prinzip her also nur funktioneren, - wenn man mit den Buchungen bei Null anfängt, und man kann auch nicht - im laufenden Betrieb von der Aufwandsmethode zur Bestandsmethode - wechseln.

2.12.5. Bekannte Probleme

Bei bestimmten Berichten kann man derzeit noch inviduell - einstellen, ob man nach Ist- oder Sollversteuerung auswertet, und es - werden im Code Variablen wie $accrual oder $cash gesetzt. Diese - Codestellen wurden noch nicht angepasst, sondern nur die, wo bisher - die Konfigurationsvariable - $::lx_office_conf{system}->{eur} ausgewertet - wurde.

Es fehlen Hilfetext beim Neuanlegen eines Mandanten, was die - Optionen bewirken, z.B. mit zwei Standardfällen.

\ No newline at end of file + 2.12. OpenDocument-Vorlagen

2.12. OpenDocument-Vorlagen

kivitendo unterstützt die Verwendung von Vorlagen im + OpenDocument-Format, wie es OpenOffice.org ab Version 2 erzeugt. + kivitendo kann dabei sowohl neue OpenDocument-Dokumente als auch aus + diesen direkt PDF-Dateien erzeugen. Um die Unterstützung von + OpenDocument-Vorlagen zu aktivieren muss in der Datei + config/kivitendo.conf die Variable + opendocument im Abschnitt + print_templates auf ‘1’ stehen. + Dieses ist die Standardeinstellung.

Weiterhin muss in der Datei + config/kivitendo.conf die Variable + dbcharset im Abschnitt system auf + die Zeichenkodierung gesetzt werden, die auch bei der Speicherung der + Daten in der Datenbank verwendet wird. Diese ist in den meisten Fällen + "UTF-8".

Während die Erzeugung von reinen OpenDocument-Dateien keinerlei + weitere Software benötigt, wird zur Umwandlung dieser Dateien in PDF + OpenOffice.org benötigt. Soll dieses Feature genutzt werden, so muss + neben OpenOffice.org ab Version 2 auch der “X virtual frame buffer” + (xvfb) installiert werden. Bei Debian ist er im Paket “xvfb” enthalten. + Andere Distributionen enthalten ihn in anderen Paketen.

Nach der Installation müssen in der Datei + config/kivitendo.conf zwei weitere Variablen + angepasst werden: openofficeorg_writer muss den + vollständigen Pfad zur OpenOffice.org Writer-Anwendung enthalten. + xvfb muss den Pfad zum “X virtual frame buffer” + enthalten. Beide stehen im Abschnitt + applications.

Zusätzlich gibt es zwei verschiedene Arten, wie kivitendo mit + OpenOffice kommuniziert. Die erste Variante, die benutzt wird, wenn die + Variable $openofficeorg_daemon gesetzt ist, startet + ein OpenOffice, das auch nach der Umwandlung des Dokumentes gestartet + bleibt. Bei weiteren Umwandlungen wird dann diese laufende Instanz + benutzt. Der Vorteil ist, dass die Zeit zur Umwandlung deutlich + reduziert wird, weil nicht für jedes Dokument ein OpenOffice gestartet + werden muss. Der Nachteil ist, dass diese Methode Python und die + Python-UNO-Bindings benötigt, die Bestandteil von OpenOffice 2 + sind.

Ist $openofficeorg_daemon nicht gesetzt, so + wird für jedes Dokument OpenOffice neu gestartet und die Konvertierung + mit Hilfe eines Makros durchgeführt. Dieses Makro muss in der + Dokumentenvorlage enthalten sein und + “Standard.Conversion.ConvertSelfToPDF()” heißen. Die Beispielvorlage + ‘templates/mastertemplates/German/invoice.odt’ + enthält ein solches Makro, das in jeder anderen Dokumentenvorlage + ebenfalls enthalten sein muss.

Als letztes muss herausgefunden werden, welchen Namen + OpenOffice.org Writer dem Verzeichnis mit den Benutzereinstellungen + gibt. Unter Debian ist dies momentan + ~/.openoffice.org2. Sollte der Name bei Ihrer + OpenOffice.org-Installation anders sein, so muss das Verzeichnis + users/.openoffice.org2 entsprechend umbenannt werden. + Ist der Name z.B. einfach nur .openoffice, so wäre + folgender Befehl auszuführen:

+ mv users/.openoffice.org2 + users/.openoffice +

Dieses Verzeichnis, wie auch das komplette + users-Verzeichnis, muss vom Webserver beschreibbar + sein. Dieses wurde bereits erledigt (siehe Manuelle Installation des Programmpaketes), kann aber + erneut überprüft werden, wenn die Konvertierung nach PDF + fehlschlägt.

\ No newline at end of file