X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fhtml%2Fch02s13.html;h=be06a1f523c6dba3d64c8584fd1271e1e6a3923a;hb=f044d58d95464652f923f0c27d74566f72c1fb47;hp=3b6141deba4fc6f67d7fa2fc7fd00030744eaa2f;hpb=4486e3bc8eb00c37cf8029e663eb94b4b9c5346a;p=kivitendo-erp.git diff --git a/doc/html/ch02s13.html b/doc/html/ch02s13.html index 3b6141deb..be06a1f52 100644 --- a/doc/html/ch02s13.html +++ b/doc/html/ch02s13.html @@ -1,65 +1,189 @@ - 2.13. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR

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

2.13.1. Einführung

kivitendo besaß bis inklusive Version 2.6.3 einen Konfigurationsparameter namens eur, der sich in der - Konfigurationsdatei config/kivitendo.conf (damals noch 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.13.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.13.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.13.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.13.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.13. OpenDocument-Vorlagen

2.13. OpenDocument-Vorlagen

kivitendo unterstützt die Verwendung von Vorlagen im + OpenDocument-Format, wie es LibreOffice oder OpenOffice (ab Version 2) + erzeugen. 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.

Während die Erzeugung von reinen OpenDocument-Dateien keinerlei + weitere Software benötigt, wird zur Umwandlung dieser Dateien in PDF + LibreOffice oder OpenOffice benötigt. Soll dieses Feature genutzt + werden, so muss neben LibreOffice oder OpenOffice 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 im Abschnitt + applications zwei weitere Variablen angepasst + werden:

+ openofficeorg_writer muss den vollständigen + Pfad zu LibreOffice oder OpenOffice enthalten. Dabei dürfen keine + Anführungszeichen eingesetzt werden.

Beispiel für Debian oder Ubuntu:

openofficeorg_writer = /usr/bin/libreoffice

+ xvfb muss den Pfad zum “X virtual frame buffer” + enthalten.

Zusätzlich gibt es zwei verschiedene Arten, wie kivitendo mit + LibreOffice bzw. OpenOffice kommuniziert. Die erste Variante, die + benutzt wird, wenn die Variable $openofficeorg_daemon + gesetzt ist, startet ein LibreOffice oder 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 LibreOffice bzw. OpenOffice gestartet werden muss. Der Nachteil ist, + dass diese Methode Python und die Python-UNO-Bindings benötigt, die + Bestandteil von LibreOffice bzw. OpenOffice sind.

[Anmerkung]Anmerkung

Für die Verbindung zu LibreOffice bzw. OpenOffice wird + normalerweise der Python-Interpreter + /usr/bin/python benutzt. Sollte dies nicht der + richtige sein, so kann man mit zwei Konfigurationsvariablen + entscheiden, welcher Python-Interpreter genutzt wird. Mit der Option + python_uno aus dem Abschnitt + applications wird der Interpreter selber + festgelegt; sie steht standardmäßig auf dem eben erwähnten Wert + /usr/bin/python.

Zusätzlich ist es möglich, Pfade anzugeben, in denen Python + neben seinen normalen Suchpfaden ebenfalls nach Modulen gesucht wird, + z.B. falls sich diese in einem gesonderten LibreOffice- bzw. + OpenOffice-Verzeichnis befinden. Diese zweite Variable heißt + python_uno_path und befindet sich im Abschnitt + environment. Sie ist standardmäßig leer. Werden + hier mehrere Pfade angegeben, so müssen diese durch Doppelpunkte + voneinander getrennt werden. Der Inhalt wird an den Python-Interpreter + über die Umgebungsvariable PYTHONPATH + übergeben.

Ist $openofficeorg_daemon nicht gesetzt, so + wird für jedes Dokument LibreOffice bzw. 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/print/rev-odt/invoice.odt’ enthält ein + solches Makro, das in jeder anderen Dokumentenvorlage ebenfalls + enthalten sein muss.

Als letztes muss herausgefunden werden, welchen Namen OpenOffice + bzw. LibreOffice dem Verzeichnis mit den Benutzereinstellungen gibt. + Unter Debian ist dies momentan ~/.config/libreoffice. + kivitendo verwendet das Verzeichnis + users/.openoffice.org2. Eventuell muss dieses + Verzeichnis umbenannt werden.

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.

2.13.1. OpenDocument (odt) Druckvorlagen mit Makros

OpenDocument Vorlagen können Makros enthalten, welche komplexere + Aufgaben erfüllen.

Der Vorlagensatz "rev-odt" enthält solche Vorlagen mit Schweizer Bank-Einzahlungsscheinen (BESR). + Diese Makros haben die Aufgabe, die in den Einzahlungsscheinen + benötigte Referenznummer und Kodierzeile zu erzeugen. Hier eine kurze + Beschreibung, wie die Makros aufgebaut sind, und was bei ihrer Nutzung + zu beachten ist (in fett sind nötige einmalige + Anpassungen aufgeführt):

2.13.1.1. Bezeichnung der Vorlagen

Rechnung: invoice_besr.odt, Auftrag: + sales_order_besr.odt

2.13.1.2. Vorbereitungen im Adminbereich

Damit beim Erstellen von Rechnungen und Aufträgen neben der + Standardvorlage ohne Einzahlungsschein weitere Vorlagen (z.B. mit + Einzahlungsschein) auswählbar sind, muss für jedes Vorlagen-Suffix + ein Drucker eingerichtet werden:

  • Druckeradministration → Drucker hinzufügen

  • Mandant wählen

  • Druckerbeschreibung → aussagekräftiger Text: wird in der + Auftrags- bzw. Rechnungsmaske als Auswahl angezeigt (z.B. mit + Einzahlungsschein Bank xy)

  • Druckbefehl → beliebiger Text (hat für das Erzeugen von + Aufträgen oder Rechnungen als odt-Datei keine Bedeutung, darf + aber nicht leer sein)

  • Vorlagenkürzel → besr bzw. selbst gewähltes Vorlagensuffix + (muss genau der Zeichenfolge entsprechen, die zwischen + "invoice_" bzw. "sales_order_" und ".odt" steht.)

  • speichern

2.13.1.3. Benutzereinstellungen

Wer den Ausdruck mit Einzahlungsschein als Standardeinstellung + im Rechnungs- bzw. Auftragsformular angezeigt haben möchte, kann + dies persönlich für sich bei den Benutzereinstellungen + konfigurieren:

  • Programm → Benutzereinstellungen → Druckoptionen

  • Standardvorlagenformat → OpenDocument/OASIS

  • Standardausgabekanal → Bildschirm

  • Standarddrucker → gewünschte Druckerbeschreibung auswählen + (z.B. mit Einzahlungsschein Bank xy)

  • Anzahl Kopien → leer

  • speichern

2.13.1.4. Aufbau und nötige Anpassungen der Vorlagen

In der Vorlage sind als Modul "BESR" 4 Makros gespeichert, die + aus dem von kivitendo erzeugten odt-Dokument die korrekte + Referenznummer inklusive Prüfziffer sowie die Kodierzeile in + OCRB-Schrift erzeugen und am richtigen Ort ins Dokument + schreiben.

  • Für den Einzahlungsschein ist die letzte Seite des + Dokuments reserviert

  • Direkt über dem Einzahlungsschein enthält die Vorlage eine + Zeile mit folgenden Angaben (Bank-Konto-Identifikationsnummer und + Postkonto-Nummer der Bank müssen gemäss Angaben der jeweiligen + Bank angepasst werden):

    • DDDREF: 4 Werte zum Bilden der Referenznummer + (jeweils durch einen Leerschlag getrennt):

      • erster Wert: Bank-Konto-Identifikation + (nur Ziffern, maximal 6), muss + angepasst werden.

      • zweiter Wert: <%customernumber%> + (Kundennummer: nur Ziffern, maximal 6)

      • dritter Wert: <%ordnumber%> + (Auftragsnummer bei Auftragsvorlage + sales_oder_besr.odt, sonst 0) maximal 7 Ziffern, + führende Buchstaben werden vom Makro entfernt

      • vierter Wert: <%invnumber%> + (Rechnungsnummer bei Rechnungsvorlage + invoice_besr.odt, sonst 0) maximal 7 Ziffern, + führende Buchstaben werden vom Makro entfernt

      +

    • DDDKONTO: Postkonto-Nummer der + Bank, muss angepasst werden.

    • DDDBETRAG: <%total%> Einzahlungsbetrag oder 0, + falls Einzahlungsschein ohne Betrag

    • DDDEND: muss am Ende der Zeile vorhanden sein

    +

  • + Im Einzahlungsschein selbst müssen + der Name und die Adresse der Bank, die Postkonto-Nummer der + Bank, sowie der eigene Firmenname und die Firmenadresse + angepasst werden. Dabei ist darauf zu achten, dass + sich die Positionen der Postkonto-Nummern der Bank, sowie der + Zeichenfolgen dddfr, DDDREF1, DDDREF2, 609, DDDKODIERZEILE nicht + verschieben.

2.13.1.5. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer + odt-Rechnung (analog bei Auftrag)

Im Fussbereich der Rechnungsmaske muss neben Rechnung, + OpenDocument/OASIS und Bildschirm die im Adminbereich erstellte + Druckerbeschreibung ausgewählt werden, falls diese nicht bereits bei + den Benutzereinstellungen als persönlicher Standard gewählt + wurde.

2.13.1.6. Makroeinstellungen in LibreOffice anpassen

Falls beim Öffnen einer von kivitendo erzeugten odt-Rechnung + die Meldung kommt, dass Makros aus Sicherheitsgründen nicht + ausgeführt werden, so müssen folgende Einstellungen in LibreOffice + angepasst werden:

  • Extras → Optionen → Sicherheit → Makrosicherheit

  • Sicherheitslevel auf "Mittel" einstellen (Diese + Einstellung muss auf jedem Computer durchgeführt werden, mit dem + von kivitendo erzeugte odt-Rechnungen oder Aufträge geöffnet + werden.)

  • Beim Öffnen einer odt-Rechnung oder eines odt-Auftrags bei + der entsprechenden Nachfrage "Makros ausführen" + auswählen.

    + Wichtig: die Makros sind + so eingestellt, dass sie beim Öffnen der Vorlagen selbst nicht + ausgeführt werden. Das heisst für das Ansehen und Bearbeiten der + Vorlagen sind keine speziellen Einstellungen in LibreOffice + nötig.

2.13.2. Schweizer QR-Rechnung mit OpenDocument Vorlagen

2.13.2.1. Übersicht

Mit der Version 3.6.0 unterstützt Kivitendo die Erstellung von + Schweizer QR-Rechnungen gemäss Swiss + Payment Standards, Version 2.2. Implementiert sind hierbei die + Varianten:

  • + QR-IBAN mit + QR-Referenz +

  • + IBAN ohne Referenz +

Der Vorlagensatz "rev-odt" enthält die Vorlage + invoice_qr.odt, welche für die Erstellung von + QR-Rechnungen vorgesehen ist. Damit diese verwendet werden kann muss + wie obenstehend beschrieben ein Drucker hinzugefügt werden (siehe + Abschnitt 2.13.1.2, „Vorbereitungen im Adminbereich“ + ). Alternativ kann die Vorlage umbenannt werden in + invoice.odt.

Die Vorlage invoice_qr.odt kann beliebig + angepasst werden. Zwingend muss diese jedoch das QR-Code Platzhalter + Bild, als eingebettetes Bild, enthalten. Da dieses beim + Ausdrucken/Erzeugen der Rechnung durch das neu generierte QR-Code + Bild ersetzt wird.

2.13.2.2. Einstellungen

2.13.2.2.1. Mandantenkonfiguration

Unter System → Mandantenkonfiguration → + Features. Im Abschnitt Einkauf und + Verkauf, beim Punkt Verkaufsrechnungen mit + Schweizer QR-Rechnung erzeugen, die gewünschte Variante + wählen.

2.13.2.2.2. Konfiguration der Bankkonten

Unter System → Bankkonten muss bei + mindestens einem Bankkonto die Option Nutzung mit + Schweizer QR-Rechnung auf Ja gestellt werden.

[Tipp]Tipp

Für die Variante QR-IBAN mit + QR-Referenz muss dieses Konto unter IBAN eine gültige + QR-IBAN Nummer enthalten. Diese + unterscheidet sich von der regulären IBAN.

Zusätzlich muss eine gültige Bankkonto + Identifikationsnummer angegeben werden + (6-stellig).

Diese werden von der jeweiligen Bank vergeben.

Sind mehrere Konten ausgewählt wird das erste + verwendet.

2.13.2.2.3. Rechnungen ohne Betrag

Für Rechnungen ohne Betrag (z.B. Spenden) kann, in der + jeweiligen Rechnung, die Checkbox QR-Rechnung ohne + Betrag aktiviert werden. Diese Checkbox erscheint nur, + wenn QR-Rechnungen in der Mandantenkonfiguration aktiviert sind + (variante ausgewählt).

Dies wirkt sich lediglich auf den erzeugten QR-Code aus. Die + Vorlage muss separat angepasst und ausgewählt werden.

2.13.2.3. Adressdaten

Die Adressdaten zum Zahlungsempfänger werden aus der + Mandantenkonfiguration entnommen. Unter System → + Mandantenkonfiguration → Verschiedenes, Abschnitt + Firmenname und -adresse. +

Die Adressdaten zum Zahlungspflichtigen stammen aus den + Kundendaten der jeweiligen Rechnung.

Die Adressen müssen inklusive Land angegeben werden. Akzeptiert + werden Ländername oder Ländercode, also z.B. "Schweiz" oder "CH". +

Diese können in der Vorlage mit den jeweiligen Variablen + eingetragen werden. Siehe auch: Abschnitt 3.3, „Dokumentenvorlagen und verfügbare Variablen“ +

Der erzeugte QR-Code verwendet Adress-Typ "K" (Kombinierte + Adressfelder, 2 Zeilen).

2.13.2.4. Referenznummer

Die Referenznummer wird in Kivitendo erzeugt und setzt sich + wiefolgt zusammen:

  • Bankkonto Identifikationsnummer (6-stellig)

  • Kundennummer (6-stellig, mit führenden Nullen + aufgefüllt)

  • Auftragsnummer (7-stellig, mit führenden Nullen + aufgefüllt)

  • Rechnungsnummer (7-stellig, mit führenden Nullen + aufgefüllt)

  • Prüfziffer (1-stellig, berechnet mittels modulo 10, + rekursiv)

Es sind lediglich Ziffern erlaubt. Allfällige Prefixe mit + Buchstaben werden entfernt und fehlende Stellen werden mit führenden + Nullen aufgefüllt.

2.13.2.5. Zusätzliche Variablen für Vorlage

Zusätzlich zu den in der Vorlage standardmässig verfügbaren + Variablen (siehe Abschnitt 3.3, „Dokumentenvorlagen und verfügbare Variablen“), + werden die folgenden Variablen erzeugt:

ref_number_formatted

Referenznummer formatiert mit Leerzeichen, z.B.: 21 00000 + 00003 13947 14300 09017

iban_formatted

IBAN formatiert mit Leerzeichen

amount_formatted

Betrag formatiert mit Tausendertrennzeichen Leerschlag, + z.B.: 1 005.55

\ No newline at end of file