X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fdokumentation.xml;h=8b05300c34959826bdbf5bc32e0bc154ef482f6b;hb=83f6467be32b682914ec0b6e5d11619a6df2ead0;hp=35c2c735c22f9162495ae8fb52b6a9b50dd38b7b;hpb=ac9129294850cbe9f04119b3cbcf2a475ad8f4ba;p=kivitendo-erp.git diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml index 35c2c735c..8b05300c3 100644 --- a/doc/dokumentation.xml +++ b/doc/dokumentation.xml @@ -2,7 +2,7 @@ - kivitendo 3.4.1: Installation, Konfiguration, Entwicklung + kivitendo 3.5.0: Installation, Konfiguration, Entwicklung Aktuelle Hinweise @@ -214,6 +214,10 @@ File::Copy::Recursive + + File::MimeInfo + + GD @@ -299,6 +303,10 @@ Text::Iconv + + Text::Unidecode + + URI @@ -311,6 +319,8 @@ YAML + Seit Version größer v3.5.0 sind die folgenden Pakete hinzugekommen: + Text::Unidecode Seit Version v3.4.0 sind die folgenden Pakete hinzugekommen: Algorithm::CheckDigitsPBKDF2::Tiny @@ -364,7 +374,7 @@ libtext-iconv-perl liburi-perl libxml-writer-perl libyaml-perl \ libimage-info-perl libgd-gd2-perl libapache2-mod-fcgid \ libfile-copy-recursive-perl postgresql libalgorithm-checkdigits-perl \ - libcrypt-pbkdf2-perl git libcgi-pm-perl + libcrypt-pbkdf2-perl git libcgi-pm-perl libtext-unidecode-perl Für das Paket HTML::Restrict gibt es kein Debian-Paket, dies @@ -418,6 +428,27 @@ cpan HTML::Restrict cpan Rose::Db::Object + + Andere Pakete installieren + + Seit Version v3.4.0 wird für den Bankimport optional das Paket + 'aqbanking-tools' benötigt. + + Debian und Ubuntu: apt install aqbanking-tools + + + OpenSuSE: zypper install aqbanking-tools + + Seit Version v3.4.1 wird generell zum Feststellen der + Seitenanzahl von PDF_Dokumenten 'pdfinfo' benötigt was im Paket + 'poppler-utils' enthalten ist. + + Debian und Ubuntu: apt install poppler-utils + + + OpenSuSE: zypper install poppler-tools + + Wir empfehlen eine Installation mittels des Versionsmanagager git. Hierfür muss ein git-Client installiert sein. Damit ist man sehr viel flexibler für zukünftige Upgrades. Installations-Anleitung (bitte - die Pfade anpassen) bspw. wie folgt: cd /usr/local/src/ + die Pfade anpassen) bspw. wie folgt: cd /var/www/ git clone https://github.com/kivitendo/kivitendo-erp.git cd kivitendo-erp/ git checkout `git tag -l | egrep -ve "(beta|rc)" | tail -1` + Erläuterung: Der Befehl wechselt zur letzten Stable-Version (git tag -l listet + alle Tags auf, das egrep schmeisst alle Einträge mit beta oder rc raus und + das tail gibt davon den obersten Treffer zurück). + Sehr sinnvoll ist es, direkt im Anschluss einen eigenen Branch zu erzeugen, um bspw. seine eigenen Druckvorlagen-Anpassungen damit zu verwalten. Hierfür reicht ein simples git checkout -b meine_eigenen_änderungen nach dem letzten Kommando (weiterführende Informationen getting - started with git). + url="http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html"> + Git Magic). + + + Ein beispielhafter Workflow für Druckvorlagen-Anpassungen von 3.4.1 nach 3.5: + +$ git clone https://github.com/kivitendo/kivitendo-erp.git +$ cd kivitendo-erp/ +$ git checkout release-3.4.1 # das ist der aktuelle release, den wir wollen +$ git add templates/fullhouse # das sind unsere druckvorlagen inkl. produktbilder +$ git commit -m "juhu tolle ändernungen" +[meine_aenderungen 1d89e41] juhu tolle ändernungen + 4 files changed, 380 insertions(+) + create mode 100644 templates/fullhouse/img/webdav/tesla.png + create mode 100644 templates/fullhouse/mahnung.tex + create mode 100644 templates/fullhouse/zahlungserinnerung_zwei.tex + create mode 100644 templates/fullhouse/zahlungserinnerung_zwei_invoice.tex + +# 5 Jahre später ... + +$ git fetch +$ git rebase --onto release-3.5.0 release-3.4.1 meine_aenderungen +Zunächst wird der Branch zurückgespult, um Ihre Änderungen +darauf neu anzuwenden ... +Wende an: juhu tolle ändernungen +$ service apache2 restart + @@ -818,8 +878,7 @@ Alias /kivitendo-erp/ /var/www/kivitendo-erp/ </Directory> <Directory /var/www/kivitendo-erp/users> - Order Deny,Allow - Deny from All + Require all granted </Directory> Ersetzen Sie dabei die Pfade durch diejenigen, in die Sie vorher @@ -1039,7 +1098,9 @@ Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/Foreneintrag - (Stand Sept. 2015) + (Stand Sept. 2015) und einen aktuellen (Stand Mai 2017) + + SSL-Konfigurations-Generator. @@ -1060,6 +1121,13 @@ Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/ + Da der Taskserver als Perlscript läuft, wird Arbeitsspeicher, + der einmal benötigt wurde, nicht mehr an das Betriebssystem zurückgegeben, + solange der Taskserver läuft. Dies kann dazu führen, dass ein länger + laufender Taskserver mit der Zeit immer mehr Arbeitsspeicher für sich + beansprucht. Es ist deshalb sinnvoll, dass der Taskserver in regelmässigen + Abständen neu gestartet wird. + Verfügbare und notwendige Konfigurationsoptionen @@ -1123,7 +1191,7 @@ Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/ - SystemV-basierende Systeme (z.B. Debian, ältere OpenSUSE, + <title>SystemV-basierende Systeme (z.B. ältere Debian, ältere OpenSUSE, ältere Fedora) Kopieren Sie die Datei @@ -1138,7 +1206,6 @@ Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/Debian-basierende Systeme: update-rc.d kivitendo-task-server defaults -# Nur bei Debian Squeeze und neuer: insserv kivitendo-task-server @@ -1172,7 +1239,7 @@ insserv kivitendo-task-server systemd-basierende Systeme (z.B. neure openSUSE, neuere - Fedora, neuere Ubuntu und Debians) + Fedora, neuere Ubuntu und neuere Debians) Kopieren Sie die Datei scripts/boot/systemd/kivitendo-task-server.service nach /etc/systemd/system/. Passen Sie in der kopierten Datei den Pfad zum Task-Server an (Zeilen @@ -2167,8 +2234,33 @@ systemctl enable kivitendo-task-server.service und nicht nur Teile davon, da dies sonst oft zu einer odt-Datei führt, die vom Parser nicht korrekt gelesen werden kann. + Mahnungen können unter folgenden Einschränkungen mit den odt-Vorlagen + im Vorlagensatz rev-odt erzeugt werden: + + + + als Druckoption steht nur 'PDF(OpenDocument/OASIS)' zur + Verfügung, das heisst, die Mahnungen werden als PDF-Datei ausgegeben. + + + + + für jede Rechnung muss eine eigene Mahnung erzeugt werden + (auch wenn bei einzelnen KundInnen mehrere überfällige Rechnungen + vorhanden sind). + + + + Mehrere Mahnungen für eine Kundin / einen Kunden werden zu einer + PDF-Datei zusammengefasst + + Die Vorlagen zahlungserinnerung.odt sowie mahnung.odt sind für das + Erstellen einer Zahlungserinnerung bzw. Mahnung selbst vorgesehen, die + Vorlage mahnung_invoice.odt für das Erstellen einer Rechnung über die + verrechneten Mahngebühren und Verzugszinsen. + Zur Zeit gibt es in kivitendo noch keine Möglichkeit, - odt-Vorlagen bei Mahnungen, Briefen und Pflichtenheften einzusetzen. + odt-Vorlagen bei Briefen und Pflichtenheften einzusetzen. Entsprechende Vorlagen sind deshalb nicht vorhanden. Fehlermeldungen, Anregungen und Wünsche bitte senden an: @@ -2590,6 +2682,53 @@ systemctl enable kivitendo-task-server.service + + Nomenklatur + + + Datum bei Buchungen + + Seit der Version 3.5 werden für Buchungen in kivitendo einheitlich + folgende Bezeichnungen verwendet: + + + + (en: , + code: ) + + bezeichnet das Datum, an dem die Buchung in kivitendo erfasst wurde. + + + + + (en: , + code: ) + + bezeichnet das buchhaltungstechnisch für eine Buchung relevante + Datum + + Das bei Verkaufs- und + Einkaufsrechnungen entspricht dem Buchungsdatum. Das heisst, in + Berichten wie dem Buchungsjournal, in denen eine Spalte + angezeigt werden kann, erscheint hier + im Fall von Rechnungen das Rechnungsdatum. + + + + Bezieht sich ein verbuchter Beleg auf einen Zeitpunkt, der nicht mit + dem Buchungsdatum übereinstimmt, so kann dieses Datum momentan in kivitendo + nur unter Bemerkungen erfasst werden. + + Möglicherweise wird für solche Fälle in einer späteren Version von + kivitendo ein dritter Datumswert für Buchungen erstellt. (Beispiel: + Einkaufsbeleg stammt aus einem früheren Jahr, das bereits + buchhaltungstechnisch abgeschlossen wurde, und muss deshalb später + verbucht werden.) + + + + + Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR @@ -2983,7 +3122,7 @@ systemctl enable kivitendo-task-server.service Achtung: Werden Verkaufsbelege in anderen Währungen als der Standardwährung erstellt, so muss in - kivitendo 3.4.1 die Genauigkeit 0.01 verwendet werden. + kivitendo ab Version 3.4.1 die Genauigkeit 0.01 verwendet werden. Das heisst, Firmen in der Schweiz, die teilweise Verkaufsrechnungen in Euro oder anderen Währungen erstellen wollen, müssen beim Erstellen der Datenbank als Genauigkeit 0.01 wählen und können zur Zeit die @@ -6200,16 +6339,24 @@ Beschreibung: <%description%> Schweizer Kontenpläne - Seit der Version 3.4.1 stehen in kivitendo 2 Kontenpläne für + Seit der Version 3.5 stehen in kivitendo 3 Kontenpläne für den Einsatz in der Schweiz zur Verfügung, einer für Firmen und - Organisationen, die nicht mehrwertsteuerpflichtig sind, und einer - für Firmen, die mehrwertsteuerpflichtig sind. + Organisationen, die nicht mehrwertsteuerpflichtig sind, einer + für Firmen, die mehrwertsteuerpflichtig sind und einer speziell + für Vereine. Die Kontenpläne orientieren sich am in der Schweiz üblicherweise verwendeten KMU-Kontenrahmen und sind mit der Revision des Schweizerischen Obligationenrechts (OR) vom 1.1.2013 kompatibel, insbesondere Art.957a Abs.2. + Beim Vereinskontenplan sind standardmässig nur die Konten 1100 + (Debitoren CHF) und 1101 (Debitoren EUR) als Buchungskonten im Verkauf + sowie die Konten 2000 (Kreditoren CHF) und 2001 (Kreditoren EUR) als + Buchungskonten im Einkauf vorgesehen. Weitere Konten können bei Bedarf + in den Konto-Detaileinstellungen als Einkaufs- oder Verkaufskonten + konfiguriert werden. + Die Möglichkeit, Saldosteuersätze zu verwenden ist in der aktuellen Version von kivitendo noch nicht integriert. @@ -6221,22 +6368,26 @@ Beschreibung: <%description%> So werden bei Kreditorenbuchungen keine Vorsteuern verbucht. + Bezugssteuern für aus dem Ausland bezogene Dienstleistungen müssen + manuell verbucht werden. + Wünsche für Anpassungen an den Schweizer Kontenplänen sowie Vorschläge für weitere (z.B. branchenspezifische) Kontenpläne bitte an empfang@revamp-it.ch senden. - + + Artikelklassifizierung Übersicht - Die Klassifizierung von Artikeln dient einer weiteren Gliederung + Die Klassifizierung von Artikeln dient einer weiteren Gliederung, um zum Beispiel den Einkauf vom Verkauf zu trennen, gekennzeichnet durch eine Beschreibung (z.B. "Einkauf") und ein Kürzel (z.B. "E"). Für jede Klassifizierung besteht eine Beschreibung und eine Abkürzung die normalerweise aus einem Zeichen besteht, kann aber auf mehrere - Zeichen erweitert werden, falls zur Unterscheidung notwendig, sinnvoll + Zeichen erweitert werden, falls zur Unterscheidung notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen. @@ -6264,15 +6415,15 @@ Beschreibung: <%description%> - keine - (diese wird bei einer Aktualisierung für alle - existierenden Artikel genommen, gültig für Verkauf und + existierenden Artikel verwendet und ist gültig für Verkauf und Einkauf) Es können weitere Klassifizierungen angelegt werden. So kann es - z.B. für separat auszuweisende Artikel folgened Klassen geben: + z.B. für separat auszuweisende Artikel folgende Klassen geben: - + Lieferung (Logistik, Transport) mit Kürzel L @@ -6280,7 +6431,7 @@ Beschreibung: <%description%> Material (Verpackungsmaterial) mit Kürzel M - + @@ -6302,38 +6453,261 @@ Beschreibung: <%description%> separat ausweisen - hierzu gibt es zur Dokumentengenerierung - (LaTeX) zusätzliche Variable + (LaTeX) eine zusätzliche Variable - Beim separat ausweisen stehen im LaTeX die Variable <%non_separate_subtotal%> zur Verfügung, - die alle nicht separat auszuweisenden Artikelkosten saldiert, sowie - pro separat auszuweisenden Klassifizierungen die Variable <%separate_X_subtotal%> wobei X das - Kürzel der Klassifizierung ist. + Für das Attribut "separat ausweisen" stehen in den LaTeX-Vorlagen + die Variable <%non_separate_subtotal%> + zur Verfügung, die alle nicht separat auszuweisenden + Artikelkosten saldiert, sowie pro separat auszuweisenden + Klassifizierungen die Variable< + %separate_X_subtotal%>, wobei X das Kürzel der + Klassifizierung ist. Im obigen Beispiel wäre das für Lieferkosten <%separate_L_subtotal%> und für - Verpackungsmaterial <%separate_M_subtotal%> . + Verpackungsmaterial + <%separate_M_subtotal%>. Zwei-Zeichen Abkürzung - Der Typ des Artikel und die Klassifizierung werden durch zwei + Der Typ des Artikels und die Klassifizierung werden durch zwei Buchstaben dargestellt. Der erste Buchstabe ist eine Lokalisierung des - Typs des Artikel ('P','A','S') , deutch 'W', 'E', und 'D' für Ware - Erzeugnis oder Dienstleistung, ggf. weitere Typen. + Artikel-Typs ('P','A','S'), deutsch 'W', 'E', und 'D' für Ware + Erzeugnis oder Dienstleistung und ggf. weiterer Typen. - Der zweite (und ggf. auch ein dritter Buchstabe, falls nötig) + Der zweite Buchstabe (und ggf. auch ein dritter, falls nötig) entspricht der lokalisierten Abkürzung der Klassifizierung. Diese Abkürzung wird überall beim Auflisten von Artikeln zur Erleichterung mit dargestellt. + + + Dateiverwaltung (Mini-DMS) + + + Übersicht + Parallel zum alten WebDAV gibt es ein Datei-Management-System, das Dateien + verschiedenen Typs verwaltet. Dies können + + + aus ERP-Daten per LaTeX Template erzeugte PDF-Dokumente, + + + zu bestimmten ERP-Daten gehörende Anhangdateien unterschiedlichen Formats, + + + per Scanner eingelesene PDF-Dateien, + + + per E-Mail empfangene Dateianhänge unterschiedlichen Formats, + + + sowie speziel für Artikel hochgeladene Bilder sein. + + + + Übersicht + + + + + + + + + + Struktur + + Über eine vom Speichermedium unabhängige Zwischenschicht werden die Dateien und ihre Versionen in der Datenbank verwaltet. Darunter können verschiedene Implementierungen (Backends) gleichzeitig existieren: + + + + Dateisystem + + + WebDAV + + + Schnittstelle zu externen Dokumenten-Management-Systemen + + + andere Datenbank + + + etc ... + + + Es gibt unterschiedliche Typen von Dateien. Jedem Typ läßt sich in der + Mandantenkonfiguration ein bestimmtes Backend zuordnen. + + + + "document": Das sind entweder generierte, eingescannte oder hochgeladene PDF-Dateien, + die zu bestimmten ERP-Daten (ERP-Objekte, wie z.B. Rechnung, Lieferschein) gehören. + + + "attachment": zusätzlich hochgeladene Dokumente, die an bestimmte ERP-Objekte angehängt werden, + z.B. technische Zeichnungen, Aufmaße. Diese können auch für Artikel, + Lieferanten und Kunden hinterlegt sein. + + + "image": Bilder für Artikel. Diese können auch verkleinert in einer Vorschau (Thumbnail) + angezeigt werden. + + + Zusätzlich werden in der Datenbank zu den Dateien neben der Zuordnung zu ERP-Objekten, Dateityp + Dateinamen und Backend, in dem die Datei gespeichert ist, auch die Quelle der Datei notiert: + + + + "created": vom System erzeugte Dokumente" + + + "uploaded": hochgeladene Dokumente + + + "email": vom Mail-System empfangene Dateien + + + "scanner[1]": von einem oder mehreren Scannern erzeugte Dateien. Existieren mehrere Scanner, + so sind diese durch unterschiedliche Quellennamen zu definieren. + + + Je nach Dateityp sind nur bestimmte Quellen zulässig. So gibt es für "attachment" und "image" nur + die Quelle "uploaded". Für "document" gibt es auf jeden Fall die Quelle "created". + Die Quellen "scanner" und "email" müssen derzeit in der Datenbank konfiguriert werden + (siehe ). + + + + Anwendung + Die Daten werden bei den ERP-Objekten als extra Reiter dargestellt. + Eine Verkaufsrechnung z.B. hat die + Reiter "Dokumente" und "Dateianhänge". + + Reiter "Dateianhänge" + + + + + + + Bei den Dateianhängen wird immer nur die aktuelle Version einer Datei angezeigt. + Wird eine Datei mit gleichem Namen hochgeladen, so wird eine neue Version der Datei erstellt. + Vorher wird der Anwender durch einen Dialog gefragt, ob er eine neue Version anlegen will oder + ob er die Datei umbenennen will, falls es eine neue Datei sein soll. + + Reiter "Dateianhänge" + + + + + + + Es können mehrere Dateien gleichzeitig hochgeladen werden, + solange in Summe die maximale Größe nicht überschritten wird + (siehe ). + + Reiter "Dokumente" + + + + + + + Sind keine weiteren Quellen für Dokumente konfiguriert, so gibt es nur "erzeugte Dokumente". + Es werden alle Versionen der generierten Datei angezeigt. Für Verkaufsrechnungen kommen keine + anderen Quellen zur Geltung. Werden entsprechend der + zusätzliche Quellen konfiguriert, so sind diese z.B. bei + Einkaufsrechnungen sichtbar: + + Reiter "Dokumente" + + + + + + + Statt des Löschens wird hier die Datei zurück zur Quelle verschoben. Somit kann die Datei anschließend + an ein anderes ERP-Objekt angehängt werden. + Derzeit sind "Titel" und "Beschreibung" noch nicht genutzt. Sie sind bisher nur bei Bildern relevant. + + + + Konfigurierung + + Mandantenkonfiguration + + Reiter "Features" + Unter dem Reiter Features im Abschnitt Dateimanagement ist + neben dem "alten" WebDAV das Dateimangement generell zu- und abschaltbar, sowie die Zuordnung der + Dateitypen zu Backends. Die Löschbarkeit von Dateien, sowie die maximale Uploadgröße sind Backend-unabhängig + + Mandantenkonfig Reiter "Features" + + + + + + + Die einzelnen Backends sind einzeln einschaltbar. Spezifische Backend-Konfigurierungen sind hier + noch ergänzbar. + + + Reiter "Allgemeine Dokumentenanhänge" + Unter dem Reiter Allgemeine Dokumentenanhänge + kann für alle ERP-Dokumente ( Angebote, Aufträge, Lieferscheine, Rechnungen im Verkauf und Einkauf ) + allgemeingültige Anhänge hochgeladen werden. + + Mandantenkonfig Reiter "Allgemeine Dokumentenanhänge" + + + + + + + Diese Anhänge werden beim Generieren von PDF-Dateien an die ERP-Dokumente angehängt, + z.B. AGBs oder aktuelle Angebote. Es werden in dem Fall die Daten kopiert, sodass an den ERP-Dokumenten immer + die Anhänge zum Generierungszeitpunkt eingebettet sind. + + + + + Datenbank-Konfigurierung + Die zusätzlichen Quellen für "email" oder ein oder mehrere Scanner sind derzeit vom Administrator + direkt in der Datenbanktabelle "user_preferences" einzurichten. Die "value" ist im JSON-Format + mit den jeweiligen Werten des Verzeichnisses und der Beschreibung der Quelle. + + id | login | namespace | version | key | value +----+-----------+--------------+---------+----------+--------------------------- + 1 | #default# | file_sources | 0.00000 | scanner1 | + {"dir":"/var/tmp/scanner1","desc":"Scanner Einkauf"} + 2 | #default# | file_sources | 0.00000 | scanner2 | + {"dir":"/var/tmp/scanner2","desc":"Scanner Verkauf"} + 3 | #default# | file_sources | 0.00000 | emails | + {"dir":"/var/tmp/emails","desc":"Empfangene Mails" } + + Es ist daran gedacht, statt dem Default-Eintrag später für bestimmte Benutzer ('login') bestimmte Quellen zuzulassen. + Dies wird nach Bedarf implementiert. + + + kivitendo-Konfigurationsdatei + Dort ist im Abschnitt [paths] der relative oder absolute Pfad zum Dokumentenwurzelverzeichnis einzutragen. + Dieser muss für den Webserver schreib- und lesbar sein, jedoch nicht ausführbar. + +[paths] +document_path = /var/local/kivi_documents + + Unter diesem Wurzelverzeichnis wird pro Mandant automatisch ein Unterverzeichnis mit der ID des Mandanten angelegt. + + + @@ -7603,6 +7977,16 @@ $self->{more_texts} = { perl-URI-Find; openSUSE: perl-URI-Find) + + + Sys::CPU (Debian-Panetname: libsys-cpu-perl; Fedora und openSUSE: nicht + vorhanden) + + + + Thread::Pool::Simple (Debian-Panetname: libthread-pool-simple-perl; Fedora und + openSUSE: nicht vorhanden) + Weitere Voraussetzung ist, dass die Testsuite ihre eigene @@ -7782,7 +8166,7 @@ Support::TestSetup::login(); sein. Dieser wird für die Datenbankverbindung benötigt. Wir keine vollständig initialisierte Umgebung benötigt, so - kann die letzte Zeile Support::TestSetup::login(); + kann die letzte Zeile Support::TestSetup::login(); weggelassen werden, was die Ausführungszeit des Scripts leicht verringert.