From: Moritz Bunkus Date: Thu, 15 Nov 2012 16:02:45 +0000 (+0100) Subject: Kapitel zur Installations-Übersicht ergänzt X-Git-Tag: release-3.0.0beta2~12^2~6 X-Git-Url: http://wagnertech.de/git?a=commitdiff_plain;h=c8a19933e3a4b3b0174078b70f7ea9faac56d94e;p=kivitendo-erp.git Kapitel zur Installations-Übersicht ergänzt --- diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml index 47e995cc5..76a569c76 100644 --- a/doc/dokumentation.xml +++ b/doc/dokumentation.xml @@ -20,6 +20,44 @@ Installation und Grundkonfiguration + + Übersicht + + + Die Installation von kivitendo umfasst mehrere Schritte. Die folgende Liste kann sowohl für Neulinge als auch für alte Hasen als + Übersicht und Stichpunktliste zum Abhaken dienen, um eine Version mit minimalen Features möglichst schnell zum Laufen zu kriegen. + + + + Voraussetzungen überprüfen: kivitendo benötigt gewisse Ressourcen und benutzt weitere + Programme. Das Kapitel "" erläutert diese. Auch die Liste der benötigten Perl-Module + befindet sich hier. + + Installation von kivitendo: Diese umfasst die "" sowie grundlegende Einstellungen, die der "" erläutert. + + Konfiguration externer Programme: hierzu gehören die Datenbank ("") und der Webserver (""). + + Benutzerinformationen speichern können: man benötigt mindestens eine Datenbank, in der + Informationen zur Authentifizierung sowie die Nutzdaten gespeichert werden. Wie man das als Administrator macht, verrät "". + + Benutzer, Gruppen und Datenbanken anlegen: wie dies alles zusammenspielt erläutert "". + + Los geht's: alles soweit erledigt? Dann kann es losgehen: "" + + + + Alle weiteren Unterkapitel in diesem Kapitel sind ebenfalls wichtig und dienen sollten vor einer ernsthaften Inbetriebnahme gelesen + werden. + + + Benötigte Software und Pakete diff --git a/doc/html/ch02.html b/doc/html/ch02.html index ada32016c..5a87c8823 100644 --- a/doc/html/ch02.html +++ b/doc/html/ch02.html @@ -1,87 +1,18 @@ - Kapitel 2. Installation und Grundkonfiguration
Kapitel 2. Installation und Grundkonfiguration
Zurück   Weiter

Kapitel 2. Installation und Grundkonfiguration

2.1. Benötigte Software und Pakete

2.1.1. Betriebssystem

kivitendo ist für Linux konzipiert, und sollte auf jedem - unixoiden Betriebssystem zum Laufen zu kriegen sein. Getestet ist - diese Version im speziellen auf Debian und Ubuntu, grundsätzlich wurde - bei der Auswahl der Pakete aber darauf Rücksicht genommen, dass es - ohne große Probleme auf den derzeit aktuellen verbreiteten - Distributionen läuft.

Mitte 2012 sind das folgende Systeme, von denen bekannt ist, - dass kivitendo auf ihnen läuft:

  • Debian

    • 6.0 Squeeze (hier muss allerdings das Modul FCGI in der Version >= 0.72 compiled werden)

    • 7.0 Wheezy

  • Ubuntu 10.04 LTS Lucid Lynx bis 12.10 Oneiric Ocelot

  • openSUSE 11.2 und 11.3

  • SuSE Linux Enterprice Server 11

  • Fedora 13 bis 16

2.1.2. Pakete

Zum Betrieb von kivitendo werden zwingend ein Webserver (meist - Apache) und ein Datenbankserver (PostgreSQL, mindestens v8.2) - benötigt.

Zusätzlich benötigt kivitendo die folgenden Perl-Pakete, die - nicht Bestandteil einer Standard-Perl-Installation sind:

  • - parent (nur bei Perl vor 5.10.1)

  • - Archive::Zip -

  • - Config::Std -

  • - DateTime -

  • - DBI -

  • - DBD::Pg -

  • - Email::Address -

  • - Email::MIME -

  • - JSON -

  • - List::MoreUtils -

  • - Net::SMTP::SSL (optional, bei E-Mail-Versand über SSL; siehe Abschnitt "E-Mail-Versand über einen SMTP-Server")

  • - Net::SSLGlue (optional, bei E-Mail-Versand über TLS; siehe Abschnitt "E-Mail-Versand über einen SMTP-Server")

  • - Params::Validate -

  • - PDF::API2 -

  • - Rose::Object -

  • - Rose::DB -

  • - Rose::DB::Object -

  • - Template -

  • - Text::CSV_XS -

  • - Text::Iconv -

  • - URI -

  • - XML::Writer -

  • - YAML -

Seit v2.7.0 sind die folgenden Pakete hinzugekommen: Email::MIME, Net::SMTP::SSL, - Net::SSLGlue.

Gegenüber Version 2.6.0 sind zu dieser Liste 2 Pakete - hinzugekommen, URI und - XML::Writer sind notwendig. Ohne startet kivitendo - nicht.

Gegenüber Version 2.6.1 sind parent, - DateTime, Rose::Object, - Rose::DB und Rose::DB::Object - neu hinzugekommen. IO::Wrap wurde entfernt.

Gegenüber Version 2.6.3 ist JSON neu - hinzugekommen.

- Email::Address und - List::MoreUtils sind schon länger feste - Abhängigkeiten, wurden aber bisher mit kivitendo mitgeliefert. Beide - sind auch in 2.6.1 weiterhin mit ausgeliefert, wurden in einer - zukünftigen Version aber aus dem Paket entfernt werden. Es wird - empfohlen diese Module zusammen mit den anderen als Bibliotheken zu - installieren.

Die zu installierenden Pakete können in den verschiedenen - Distributionen unterschiedlich heißen.

Für Debian oder Ubuntu benötigen Sie diese Pakete:

apt-get install apache2 postgresql libarchive-zip-perl \
-  libdatetime-perl libdbi-perl libdbd-pg-perl libpg-perl \
-  libemail-address-perl libemail-mime-perl liblist-moreutils-perl libpdf-api2-perl \
-  librose-object-perl librose-db-perl librose-db-object-perl \
-  libtemplate-perl libtext-csv-xs-perl libtext-iconv-perl liburi-perl \
-  libxml-writer-perl libyaml-perl libconfig-std-perl \
-  libparams-validate-perl libjson-perl libclass-accessor-perl \
-  libnet-sslglue-perl libnet-smtp-ssl-perl

Für Fedora Core benötigen Sie diese Pakete:

yum install httpd postgresql-server perl-parent perl-DateTime \
-  perl-DBI perl-DBD-Pg perl-Email-Address perl-Email-MIME perl-List-MoreUtils \
-  perl-PDF-API2 perl-Rose-Object perl-Rose-DB perl-Rose-DB-Object \
-  perl-Template-Toolkit perl-Text-CSV_XS perl-Text-Iconv perl-URI \
-  perl-XML-Writer perl-YAML perl-Net-SSLGlue perl-Net-SMTP-SSL

Für OpenSuSE benötigen Sie diese Pakete:

zypper install apache2 postgresql-server perl-Archive-Zip \
-  perl-DateTime perl-DBI perl-DBD-Pg perl-Email-MIME perl-MailTools perl-List-MoreUtils \
-  perl-PDF-API2 perl-Template-Toolkit perl-Text-CSV_XS perl-Text-Iconv \
-  perl-URI perl-XML-Writer perl-YAML perl-Net-SSLGlue perl-Net-SMTP-SSL

kivitendo enthält ein Script, mit dem überprüft werden kann, ob - alle benötigten Perl-Module installiert sind. Der Aufruf lautet wie - folgt:

./scripts/installation_check.pl
Zurück   Weiter
Kapitel 1. Aktuelle Hinweise Zum Anfang 2.2. Manuelle Installation des Programmpaketes
\ No newline at end of file + Kapitel 2. Installation und Grundkonfiguration
Kapitel 2. Installation und Grundkonfiguration
Zurück   Weiter

Kapitel 2. Installation und Grundkonfiguration

2.1. Übersicht

+ Die Installation von kivitendo umfasst mehrere Schritte. Die folgende Liste kann sowohl für Neulinge als auch für alte Hasen als + Übersicht und Stichpunktliste zum Abhaken dienen, um eine Version mit minimalen Features möglichst schnell zum Laufen zu kriegen. +

  1. + Voraussetzungen überprüfen: kivitendo benötigt gewisse Ressourcen und benutzt weitere + Programme. Das Kapitel "Abschnitt 2.2, „Benötigte Software und Pakete“" erläutert diese. Auch die Liste der benötigten Perl-Module + befindet sich hier.

  2. + Installation von kivitendo: Diese umfasst die "Manuelle Installation des Programmpaketes" sowie grundlegende Einstellungen, die der "Abschnitt 2.4, „kivitendo-Konfigurationsdatei“" erläutert.

  3. + Konfiguration externer Programme: hierzu gehören die Datenbank ("Abschnitt 2.5, „Anpassung der PostgreSQL-Konfiguration“") und der Webserver ("Abschnitt 2.6, „Webserver-Konfiguration“").

  4. + Benutzerinformationen speichern können: man benötigt mindestens eine Datenbank, in der + Informationen zur Authentifizierung sowie die Nutzdaten gespeichert werden. Wie man das als Administrator macht, verrät "Abschnitt 2.8, „Benutzerauthentifizierung und Administratorpasswort“".

  5. + Benutzer, Gruppen und Datenbanken anlegen: wie dies alles zusammenspielt erläutert "Abschnitt 2.9, „Benutzer- und Gruppenverwaltung“".

  6. + Los geht's: alles soweit erledigt? Dann kann es losgehen: "Abschnitt 2.16, „kivitendo ERP verwenden“"

+ Alle weiteren Unterkapitel in diesem Kapitel sind ebenfalls wichtig und dienen sollten vor einer ernsthaften Inbetriebnahme gelesen + werden. +

Zurück   Weiter
Kapitel 1. Aktuelle Hinweise Zum Anfang 2.2. Benötigte Software und Pakete
\ No newline at end of file diff --git a/doc/html/ch02s02.html b/doc/html/ch02s02.html index 668c4bfe9..05d1c0ad2 100644 --- a/doc/html/ch02s02.html +++ b/doc/html/ch02s02.html @@ -1,15 +1,87 @@ - 2.2. Manuelle Installation des Programmpaketes
2.2. Manuelle Installation des Programmpaketes
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.2. Manuelle Installation des Programmpaketes

Die kivitendo ERP Installationsdatei (kivitendo-erp-2.6.3.tgz) wird - im Dokumentenverzeichnis des Webservers (z.B. - /var/www/html/, - /srv/www/htdocs oder - /var/www/) entpackt:

cd /var/www
-tar xvzf kivitendo-erp-2.6.3.tgz

Wechseln Sie in das entpackte Verzeichnis:

cd kivitendo-erp

Alternativ können Sie auch einen Alias in der - Webserverkonfiguration benutzen, um auf das tatsächliche - Installationsverzeichnis zu verweisen.

Die Verzeichnisse users, spool und webdav müssen für den Benutzer - beschreibbar sein, unter dem der Webserver läuft. Die restlichen Dateien müssen für diesen Benutzer lesbar sein. Die Benutzer- und - Gruppennamen sind bei verschiedenen Distributionen unterschiedlich (z.B. bei Debian/Ubuntu www-data, bei Fedora - core apache oder bei OpenSuSE wwwrun).

Der folgende Befehl ändert den Besitzer für die oben genannten - Verzeichnisse auf einem Debian/Ubuntu-System:

chown -R www-data users spool webdav

Weiterhin muss der Webserver-Benutzer in den Verzeichnissen templates und users - Unterverzeichnisse für jeden neuen Benutzer anlegen dürfen, der in kivitendo angelegt wird:

chown www-data templates users
Zurück Nach oben Weiter
Kapitel 2. Installation und Grundkonfiguration Zum Anfang 2.3. kivitendo-Konfigurationsdatei
\ No newline at end of file + 2.2. Benötigte Software und Pakete
2.2. Benötigte Software und Pakete
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.2. Benötigte Software und Pakete

2.2.1. Betriebssystem

kivitendo ist für Linux konzipiert, und sollte auf jedem + unixoiden Betriebssystem zum Laufen zu kriegen sein. Getestet ist + diese Version im speziellen auf Debian und Ubuntu, grundsätzlich wurde + bei der Auswahl der Pakete aber darauf Rücksicht genommen, dass es + ohne große Probleme auf den derzeit aktuellen verbreiteten + Distributionen läuft.

Mitte 2012 sind das folgende Systeme, von denen bekannt ist, + dass kivitendo auf ihnen läuft:

  • Debian

    • 6.0 Squeeze (hier muss allerdings das Modul FCGI in der Version >= 0.72 compiled werden)

    • 7.0 Wheezy

  • Ubuntu 10.04 LTS Lucid Lynx bis 12.10 Oneiric Ocelot

  • openSUSE 11.2 und 11.3

  • SuSE Linux Enterprice Server 11

  • Fedora 13 bis 16

2.2.2. Pakete

Zum Betrieb von kivitendo werden zwingend ein Webserver (meist + Apache) und ein Datenbankserver (PostgreSQL, mindestens v8.2) + benötigt.

Zusätzlich benötigt kivitendo die folgenden Perl-Pakete, die + nicht Bestandteil einer Standard-Perl-Installation sind:

  • + parent (nur bei Perl vor 5.10.1)

  • + Archive::Zip +

  • + Config::Std +

  • + DateTime +

  • + DBI +

  • + DBD::Pg +

  • + Email::Address +

  • + Email::MIME +

  • + JSON +

  • + List::MoreUtils +

  • + Net::SMTP::SSL (optional, bei E-Mail-Versand über SSL; siehe Abschnitt "E-Mail-Versand über einen SMTP-Server")

  • + Net::SSLGlue (optional, bei E-Mail-Versand über TLS; siehe Abschnitt "E-Mail-Versand über einen SMTP-Server")

  • + Params::Validate +

  • + PDF::API2 +

  • + Rose::Object +

  • + Rose::DB +

  • + Rose::DB::Object +

  • + Template +

  • + Text::CSV_XS +

  • + Text::Iconv +

  • + URI +

  • + XML::Writer +

  • + YAML +

Seit v2.7.0 sind die folgenden Pakete hinzugekommen: Email::MIME, Net::SMTP::SSL, + Net::SSLGlue.

Gegenüber Version 2.6.0 sind zu dieser Liste 2 Pakete + hinzugekommen, URI und + XML::Writer sind notwendig. Ohne startet kivitendo + nicht.

Gegenüber Version 2.6.1 sind parent, + DateTime, Rose::Object, + Rose::DB und Rose::DB::Object + neu hinzugekommen. IO::Wrap wurde entfernt.

Gegenüber Version 2.6.3 ist JSON neu + hinzugekommen.

+ Email::Address und + List::MoreUtils sind schon länger feste + Abhängigkeiten, wurden aber bisher mit kivitendo mitgeliefert. Beide + sind auch in 2.6.1 weiterhin mit ausgeliefert, wurden in einer + zukünftigen Version aber aus dem Paket entfernt werden. Es wird + empfohlen diese Module zusammen mit den anderen als Bibliotheken zu + installieren.

Die zu installierenden Pakete können in den verschiedenen + Distributionen unterschiedlich heißen.

Für Debian oder Ubuntu benötigen Sie diese Pakete:

apt-get install apache2 postgresql libarchive-zip-perl \
+  libdatetime-perl libdbi-perl libdbd-pg-perl libpg-perl \
+  libemail-address-perl libemail-mime-perl liblist-moreutils-perl libpdf-api2-perl \
+  librose-object-perl librose-db-perl librose-db-object-perl \
+  libtemplate-perl libtext-csv-xs-perl libtext-iconv-perl liburi-perl \
+  libxml-writer-perl libyaml-perl libconfig-std-perl \
+  libparams-validate-perl libjson-perl libclass-accessor-perl \
+  libnet-sslglue-perl libnet-smtp-ssl-perl

Für Fedora Core benötigen Sie diese Pakete:

yum install httpd postgresql-server perl-parent perl-DateTime \
+  perl-DBI perl-DBD-Pg perl-Email-Address perl-Email-MIME perl-List-MoreUtils \
+  perl-PDF-API2 perl-Rose-Object perl-Rose-DB perl-Rose-DB-Object \
+  perl-Template-Toolkit perl-Text-CSV_XS perl-Text-Iconv perl-URI \
+  perl-XML-Writer perl-YAML perl-Net-SSLGlue perl-Net-SMTP-SSL

Für OpenSuSE benötigen Sie diese Pakete:

zypper install apache2 postgresql-server perl-Archive-Zip \
+  perl-DateTime perl-DBI perl-DBD-Pg perl-Email-MIME perl-MailTools perl-List-MoreUtils \
+  perl-PDF-API2 perl-Template-Toolkit perl-Text-CSV_XS perl-Text-Iconv \
+  perl-URI perl-XML-Writer perl-YAML perl-Net-SSLGlue perl-Net-SMTP-SSL

kivitendo enthält ein Script, mit dem überprüft werden kann, ob + alle benötigten Perl-Module installiert sind. Der Aufruf lautet wie + folgt:

./scripts/installation_check.pl
Zurück Nach oben Weiter
Kapitel 2. Installation und Grundkonfiguration Zum Anfang 2.3. Manuelle Installation des Programmpaketes
\ No newline at end of file diff --git a/doc/html/ch02s03.html b/doc/html/ch02s03.html index 248e638cd..bb2c61dbb 100644 --- a/doc/html/ch02s03.html +++ b/doc/html/ch02s03.html @@ -1,75 +1,15 @@ - 2.3. kivitendo-Konfigurationsdatei
2.3. kivitendo-Konfigurationsdatei
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.3. kivitendo-Konfigurationsdatei

2.3.1. Einführung

In kivitendo gibt es nur noch eine Konfigurationsdatei, - die benötigt wird: config/kivitendo.conf (kurz: - "die Hauptkonfigurationsdatei"). Diese muss bei der Erstinstallation - von kivitendo bzw. der Migration von älteren Versionen angelegt - werden.

Als Vorlage dient die Datei - config/kivitendo.conf.default (kurz: "die - Default-Datei"):

$ cp config/kivitendo.conf.default config/kivitendo.conf

Die Default-Datei wird immer zuerst eingelesen. Werte, die in - der Hauptkonfigurationsdatei stehen, überschreiben die Werte aus der - Default-Datei. Die Hauptkonfigurationsdatei muss also nur die - Abschnitte und Werte enthalten, die von denen der Default-Datei - abweichen.

[Anmerkung]Anmerkung

- Vor der Umbenennung in kivitendo hieß diese Datei noch config/lx_office.conf. Aus Gründen der Kompatibilität - wird diese Datei eingelesen, sofern die Datei config/kivitendo.conf nicht existiert. -

Diese Hauptkonfigurationsdatei ist dann eine - installationsspezifische Datei, d.h. sie enthält bspw. lokale - Passwörter und wird auch nicht im Versionsmanagement (git) - verwaltet.

Die Konfiguration ist ferner serverabhängig, d.h. für alle - Mandaten, bzw. Datenbanken gleich.

2.3.2. Abschnitte und Parameter

Die Konfigurationsdatei besteht aus mehreren Teilen, die - entsprechend kommentiert sind:

Die üblicherweise wichtigsten Parameter, die am Anfang - einzustellen oder zu kontrollieren sind, sind:

[authentication]
-admin_password = geheim
-
-[authentication/database]
-host     = localhost
-port     = 5432
-db       = kivitendo_auth
-user     = postgres
-password =
-
-[system]
-dbcharset = UTF-8

Nutzt man wiederkehrende Rechnungen, kann man unter - [periodic_invoices] den Login eines Benutzers - angeben, der nach Erstellung der Rechnungen eine entsprechende E-Mail - mit Informationen über die erstellten Rechnungen bekommt.

Nutzt man den Taskserver für wiederkehrende Rechnungen, - muss unter [task_server] ein Login eines Benutzers - angegeben werden, mit dem sich der Taskserver an kivitendo bei der - Datenbank anmeldet, die dem Benutzer zugewiesen ist.

Für Entwickler finden sich unter [debug] - wichtige Funktionen, um die Fehlersuche zu erleichtern.

2.3.3. Versionen vor 2.6.3

In älteren kivitendo Versionen gab es im Verzeichnis - config die Dateien - authentication.pl und - lx-erp.conf, die jeweils Perl-Dateien waren. Es - gab auch die Möglichkeit, eine lokale Version der Konfigurationsdatei - zu erstellen (lx-erp-local.conf). Dies ist ab - 2.6.3 nicht mehr möglich, aber auch nicht mehr nötig.

Beim Update von einer kivitendo-Version vor 2.6.3 auf 2.6.3 oder - jünger müssen die Einstellungen aus den alten Konfigurationsdateien - manuell übertragen und die alten Konfigurationsdateien anschließend - gelöscht oder verschoben werden. Ansonsten zeigt kivitendo eine - entsprechende Fehlermeldung an.

Zurück Nach oben Weiter
2.2. Manuelle Installation des Programmpaketes Zum Anfang 2.4. Anpassung der PostgreSQL-Konfiguration
\ No newline at end of file + 2.3. Manuelle Installation des Programmpaketes
2.3. Manuelle Installation des Programmpaketes
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.3. Manuelle Installation des Programmpaketes

Die kivitendo ERP Installationsdatei (kivitendo-erp-2.6.3.tgz) wird + im Dokumentenverzeichnis des Webservers (z.B. + /var/www/html/, + /srv/www/htdocs oder + /var/www/) entpackt:

cd /var/www
+tar xvzf kivitendo-erp-2.6.3.tgz

Wechseln Sie in das entpackte Verzeichnis:

cd kivitendo-erp

Alternativ können Sie auch einen Alias in der + Webserverkonfiguration benutzen, um auf das tatsächliche + Installationsverzeichnis zu verweisen.

Die Verzeichnisse users, spool und webdav müssen für den Benutzer + beschreibbar sein, unter dem der Webserver läuft. Die restlichen Dateien müssen für diesen Benutzer lesbar sein. Die Benutzer- und + Gruppennamen sind bei verschiedenen Distributionen unterschiedlich (z.B. bei Debian/Ubuntu www-data, bei Fedora + core apache oder bei OpenSuSE wwwrun).

Der folgende Befehl ändert den Besitzer für die oben genannten + Verzeichnisse auf einem Debian/Ubuntu-System:

chown -R www-data users spool webdav

Weiterhin muss der Webserver-Benutzer in den Verzeichnissen templates und users + Unterverzeichnisse für jeden neuen Benutzer anlegen dürfen, der in kivitendo angelegt wird:

chown www-data templates users
Zurück Nach oben Weiter
2.2. Benötigte Software und Pakete Zum Anfang 2.4. kivitendo-Konfigurationsdatei
\ No newline at end of file diff --git a/doc/html/ch02s04.html b/doc/html/ch02s04.html index 1d656ee99..f41349201 100644 --- a/doc/html/ch02s04.html +++ b/doc/html/ch02s04.html @@ -1,50 +1,75 @@ - 2.4. Anpassung der PostgreSQL-Konfiguration
2.4. Anpassung der PostgreSQL-Konfiguration
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.4. Anpassung der PostgreSQL-Konfiguration

PostgreSQL muss auf verschiedene Weisen angepasst werden.

2.4.1. Zeichensätze/die Verwendung von UTF-8

Bei aktuellen Serverinstallationen braucht man hier meist nicht - eingreifen

Dieses kann überprüft werden: ist das Encoding der Datenbank - “template1” “UTF8”, so braucht man nichts weiteres diesbezüglich - unternehmen. Zum Testen: + 2.4. kivitendo-Konfigurationsdatei

2.4. kivitendo-Konfigurationsdatei
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.4. kivitendo-Konfigurationsdatei

2.4.1. Einführung

In kivitendo gibt es nur noch eine Konfigurationsdatei, + die benötigt wird: config/kivitendo.conf (kurz: + "die Hauptkonfigurationsdatei"). Diese muss bei der Erstinstallation + von kivitendo bzw. der Migration von älteren Versionen angelegt + werden.

Als Vorlage dient die Datei + config/kivitendo.conf.default (kurz: "die + Default-Datei"):

$ cp config/kivitendo.conf.default config/kivitendo.conf

Die Default-Datei wird immer zuerst eingelesen. Werte, die in + der Hauptkonfigurationsdatei stehen, überschreiben die Werte aus der + Default-Datei. Die Hauptkonfigurationsdatei muss also nur die + Abschnitte und Werte enthalten, die von denen der Default-Datei + abweichen.

[Anmerkung]Anmerkung

+ Vor der Umbenennung in kivitendo hieß diese Datei noch config/lx_office.conf. Aus Gründen der Kompatibilität + wird diese Datei eingelesen, sofern die Datei config/kivitendo.conf nicht existiert. +

Diese Hauptkonfigurationsdatei ist dann eine + installationsspezifische Datei, d.h. sie enthält bspw. lokale + Passwörter und wird auch nicht im Versionsmanagement (git) + verwaltet.

Die Konfiguration ist ferner serverabhängig, d.h. für alle + Mandaten, bzw. Datenbanken gleich.

2.4.2. Abschnitte und Parameter

Die Konfigurationsdatei besteht aus mehreren Teilen, die + entsprechend kommentiert sind:

Die üblicherweise wichtigsten Parameter, die am Anfang + einzustellen oder zu kontrollieren sind, sind:

[authentication]
+admin_password = geheim
 
-        
su postgres
-echo '\l' | psql
-exit 

+[authentication/database]
+host     = localhost
+port     = 5432
+db       = kivitendo_auth
+user     = postgres
+password =
 
-        Andernfalls ist es notwendig, einen neuen Datenbankcluster mit
-        UTF-8-Encoding anzulegen und diesen zu verwenden. Unter Debian und
-        Ubuntu kann dies z.B. für PostgreSQL 8.2 mit dem folgenden Befehl
-        getan werden:
pg_createcluster --locale=de_DE.UTF-8 --encoding=UTF-8 8.2 clustername
Die Datenbankversionsnummer muss an die tatsächlich verwendete
-        Versionsnummer angepasst werden.
Unter anderen Distributionen gibt es ähnliche Methoden.
Wurde PostgreSQL nicht mit UTF-8 als Encoding initialisiert und
-        ist ein Neuanlegen eines weiteren Clusters nicht möglich, so kann
-        kivitendo mit ISO-8859-15 als Encoding betrieben werden.
Das Encoding einer Datenbank kann in psql mit
-        \l geprüft werden.

2.4.2. Änderungen an Konfigurationsdateien

In der Datei postgresql.conf, die je nach - Distribution in verschiedenen Verzeichnissen liegen kann (z.B. - /var/lib/pgsql/data/ oder - /etc/postgresql/, muss sichergestellt werden, - dass TCP/IP-Verbindungen aktiviert sind. Das Verhalten wird über den - Parameter listen_address gesteuert. Laufen - PostgreSQL und kivitendo auf demselben Rechner, so kann dort der Wert - localhost verwendet werden. Andernfalls müssen - Datenbankverbindungen auch von anderen Rechnern aus zugelassen werden, - was mit dem Wert * geschieht.

In der Datei pg_hba.conf, die im gleichen - Verzeichnis wie die postgresql.conf zu finden - sein sollte, müssen die Berichtigungen für den Zugriff geändert - werden. Hier gibt es mehrere Möglichkeiten. sinnvoll ist es nur die - nögiten Verbindungen immer zuzulassen, für eine lokal laufenden - Datenbank zum Beispiel:

local all kivitendo password
-host all kivitendo 127.0.0.1 255.255.255.255 password

2.4.3. Erweiterung für servergespeicherte Prozeduren

In der Datenbank template1 muss die - Unterstützung für servergespeicherte Prozeduren eingerichet werden. - Melden Sie sich dafür als Benutzer “postgres” an der Datenbank an: - 

su - postgres
-psql template1

- - führen Sie die folgenden Kommandos aus:

create language 'plpgsql';
-\q

2.4.4. Datenbankbenutzer anlegen

Wenn Sie nicht den Datenbanksuperuser “postgres” zum Zugriff - benutzen wollen, so sollten Sie bei PostgreSQL einen neuen Benutzer - anlegen. Ein Beispiel, wie Sie einen neuen Benutzer anlegen - können:

Die Frage, ob der neue User Superuser sein soll, können Sie mit nein - beantworten, genauso ist die Berechtigung neue User (Roles) zu - generieren nicht nötig.

su - postgres
-createuser -d -P kivitendo
-exit

Wenn Sie später einen Datenbankzugriff konfigurieren, verändern - Sie den evtl. voreingestellten Benutzer “postgres” auf “kivitendo” bzw. - den hier gewählten Benutzernamen.

Zurück Nach oben Weiter
2.3. kivitendo-Konfigurationsdatei Zum Anfang 2.5. Webserver-Konfiguration
\ No newline at end of file +[system] +dbcharset = UTF-8

Nutzt man wiederkehrende Rechnungen, kann man unter + [periodic_invoices] den Login eines Benutzers + angeben, der nach Erstellung der Rechnungen eine entsprechende E-Mail + mit Informationen über die erstellten Rechnungen bekommt.

Nutzt man den Taskserver für wiederkehrende Rechnungen, + muss unter [task_server] ein Login eines Benutzers + angegeben werden, mit dem sich der Taskserver an kivitendo bei der + Datenbank anmeldet, die dem Benutzer zugewiesen ist.

Für Entwickler finden sich unter [debug] + wichtige Funktionen, um die Fehlersuche zu erleichtern.

2.4.3. Versionen vor 2.6.3

In älteren kivitendo Versionen gab es im Verzeichnis + config die Dateien + authentication.pl und + lx-erp.conf, die jeweils Perl-Dateien waren. Es + gab auch die Möglichkeit, eine lokale Version der Konfigurationsdatei + zu erstellen (lx-erp-local.conf). Dies ist ab + 2.6.3 nicht mehr möglich, aber auch nicht mehr nötig.

Beim Update von einer kivitendo-Version vor 2.6.3 auf 2.6.3 oder + jünger müssen die Einstellungen aus den alten Konfigurationsdateien + manuell übertragen und die alten Konfigurationsdateien anschließend + gelöscht oder verschoben werden. Ansonsten zeigt kivitendo eine + entsprechende Fehlermeldung an.

Zurück Nach oben Weiter
2.3. Manuelle Installation des Programmpaketes Zum Anfang 2.5. Anpassung der PostgreSQL-Konfiguration
\ No newline at end of file diff --git a/doc/html/ch02s05.html b/doc/html/ch02s05.html index 76b1e0f57..582067def 100644 --- a/doc/html/ch02s05.html +++ b/doc/html/ch02s05.html @@ -1,103 +1,50 @@ - 2.5. Webserver-Konfiguration
2.5. Webserver-Konfiguration
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.5. Webserver-Konfiguration

2.5.1. Grundkonfiguration mittels CGI

[Anmerkung]Anmerkung

Für einen deutlichen Performanceschub sorgt die Ausführung - mittels FastCGI/FCGI. Die Einrichtung wird ausführlich im Abschnitt - Konfiguration für FastCGI/FCGI beschrieben.

Der Zugriff auf das Programmverzeichnis muss in der Apache - Webserverkonfigurationsdatei httpd.conf eingestellt - werden. Fügen Sie den folgenden Abschnitt dieser Datei oder einer - anderen Datei hinzu, die beim Starten des Webservers eingelesen - wird:

AddHandler cgi-script .pl
-Alias /kivitendo-erp/ /var/www/kiviteno-erp/
+   2.5. Anpassung der PostgreSQL-Konfiguration
2.5. Anpassung der PostgreSQL-Konfiguration
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter
2.5. Anpassung der PostgreSQL-Konfiguration
PostgreSQL muss auf verschiedene Weisen angepasst werden.
2.5.1. Zeichensätze/die Verwendung von UTF-8
Bei aktuellen Serverinstallationen braucht man hier meist nicht
+	eingreifen
Dieses kann überprüft werden: ist das Encoding der Datenbank
+	“template1” “UTF8”, so braucht man nichts weiteres diesbezüglich
+	unternehmen. Zum Testen:
 
-<Directory /var/www/kivitendo-erp>
- Options ExecCGI Includes FollowSymlinks
-</Directory>
+        
su postgres
+echo '\l' | psql
+exit 

 
-<Directory /var/www/kivitendo-erp/users>
- Order Deny,Allow
- Deny from All
-</Directory>

Ersetzen Sie dabei die Pfade durch diejenigen, in die Sie vorher - das kivitendo-Archiv entpacket haben.

[Anmerkung]Anmerkung

Vor den einzelnen Optionen muss bei einigen Distributionen ein - Plus ‘+’ gesetzt werden.

Auf einigen Webservern werden manchmal die Grafiken und - Style-Sheets nicht ausgeliefert. In solchen Fällen hat es oft - geholfen, die folgende Option in die Konfiguration aufzunehmen:

EnableSendfile Off

2.5.2. Konfiguration für FastCGI/FCGI

2.5.2.1. Was ist FastCGI?

Direkt aus Wikipedia - kopiert:

- [ FastCGI ist ein Standard für die Einbindung - externer Software zur Generierung dynamischer Webseiten in einem - Webserver. FastCGI ist vergleichbar zum Common Gateway Interface - (CGI), wurde jedoch entwickelt, um dessen Performance-Probleme zu - umgehen. ] -

2.5.2.2. Warum FastCGI?

Perl Programme (wie kivitendo eines ist) werden nicht statisch - kompiliert. Stattdessen werden die Quelldateien bei jedem Start - übersetzt, was bei kurzen Laufzeiten einen Großteil der Laufzeit - ausmacht. Während SQL Ledger einen Großteil der Funktionalität in - einzelne Module kapselt, um immer nur einen kleinen Teil laden zu - müssen, ist die Funktionalität von kivitendo soweit gewachsen, dass - immer mehr Module auf den Rest des Programms zugreifen. Zusätzlich - benutzen wir umfangreiche Bibliotheken um Funktionaltät nicht selber - entwickeln zu müssen, die zusätzliche Ladezeit kosten. All dies - führt dazu dass ein kivitendo Aufruf der Kernmasken mittlerweile - deutlich länger dauert als früher, und dass davon 90% für das Laden - der Module verwendet wird.

Mit FastCGI werden nun die Module einmal geladen, und danach - wird nur die eigentliche Programmlogik ausgeführt.

2.5.2.3. Getestete Kombinationen aus Webservern und Plugin

Folgende Kombinationen sind getestet:

  • Apache 2.2.11 (Ubuntu) und mod_fcgid.

  • Apache 2.2.11 (Ubuntu) und mod_fastcgi.

Dabei wird mod_fcgid empfohlen, weil mod_fastcgi seit geraumer - Zeit nicht mehr weiter entwickelt wird. Im Folgenden wird auf - mod_fastcgi nicht mehr explizit eingegangen.

Als Perl Backend wird das Modul FCGI.pm - verwendet.

[Warnung]Warnung

FCGI-Versionen ab 0.69 und bis zu 0.71 inklusive sind extrem strict in der Behandlung von Unicode, und verweigern - bestimmte Eingaben von kivitendo. Falls es Probleme mit Umlauten in Ihrere Installation gibt, muss zwingend Version 0.68 oder - aber Version 0.72 und neuer eingesetzt werden.

Mit CPAN lässt sie sich die Vorgängerversion wie folgt - installieren:

force install M/MS/MSTROUT/FCGI-0.68.tar.gz

2.5.2.4. Konfiguration des Webservers

Bevor Sie versuchen, eine kivitendo Installation unter FCGI - laufen zu lassen, empfliehlt es sich die Installation ersteinmal - unter CGI aufzusetzen. FCGI macht es nicht einfach Fehler zu - debuggen die beim ersten aufsetzen auftreten können. Sollte die - Installation schon funktionieren, lesen Sie weiter.

Zuerst muss das FastCGI-Modul aktiviert werden. Dies kann - unter Debian/Ubuntu z.B. mit folgendem Befehl geschehen:

a2enmod fcgid

Die Konfiguration für die Verwendung von kivitendo mit FastCGI - erfolgt durch Anpassung der vorhandenen Alias- - und Directory-Direktiven. Dabei wird zwischen - dem Installationspfad von kivitendo im Dateisystem - ("/path/to/kivitendo-erp") und der URL - unterschieden, unter der kivitendo im Webbrowser erreichbar ist - ("/url/for/kivitendo-erp").

Folgender Konfigurationsschnipsel funktioniert mit - mod_fastcgi:

AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fcgi
-Alias       /url/for/kivitendo-erp/          /path/to/kivitendo-erp/
+        Andernfalls ist es notwendig, einen neuen Datenbankcluster mit
+        UTF-8-Encoding anzulegen und diesen zu verwenden. Unter Debian und
+        Ubuntu kann dies z.B. für PostgreSQL 8.2 mit dem folgenden Befehl
+        getan werden:
pg_createcluster --locale=de_DE.UTF-8 --encoding=UTF-8 8.2 clustername
Die Datenbankversionsnummer muss an die tatsächlich verwendete
+        Versionsnummer angepasst werden.
Unter anderen Distributionen gibt es ähnliche Methoden.
Wurde PostgreSQL nicht mit UTF-8 als Encoding initialisiert und
+        ist ein Neuanlegen eines weiteren Clusters nicht möglich, so kann
+        kivitendo mit ISO-8859-15 als Encoding betrieben werden.
Das Encoding einer Datenbank kann in psql mit
+        \l geprüft werden.

2.5.2. Änderungen an Konfigurationsdateien

In der Datei postgresql.conf, die je nach + Distribution in verschiedenen Verzeichnissen liegen kann (z.B. + /var/lib/pgsql/data/ oder + /etc/postgresql/, muss sichergestellt werden, + dass TCP/IP-Verbindungen aktiviert sind. Das Verhalten wird über den + Parameter listen_address gesteuert. Laufen + PostgreSQL und kivitendo auf demselben Rechner, so kann dort der Wert + localhost verwendet werden. Andernfalls müssen + Datenbankverbindungen auch von anderen Rechnern aus zugelassen werden, + was mit dem Wert * geschieht.

In der Datei pg_hba.conf, die im gleichen + Verzeichnis wie die postgresql.conf zu finden + sein sollte, müssen die Berichtigungen für den Zugriff geändert + werden. Hier gibt es mehrere Möglichkeiten. sinnvoll ist es nur die + nögiten Verbindungen immer zuzulassen, für eine lokal laufenden + Datenbank zum Beispiel:

local all kivitendo password
+host all kivitendo 127.0.0.1 255.255.255.255 password

2.5.3. Erweiterung für servergespeicherte Prozeduren

In der Datenbank template1 muss die + Unterstützung für servergespeicherte Prozeduren eingerichet werden. + Melden Sie sich dafür als Benutzer “postgres” an der Datenbank an: + 

su - postgres
+psql template1

-<Directory /path/to/kivitendo-erp> - AllowOverride All - Options ExecCGI Includes FollowSymlinks - Order Allow,Deny - Allow from All -</Directory> - -<DirectoryMatch /path/to/kivitendo-erp/users> - Order Deny,Allow - Deny from All -</DirectoryMatch>

Seit mod_fcgid-Version 2.6.3 gelten sehr kleine Grenzen für - die maximale Größe eines Requests. Diese sollte wie folgt - hochgesetzt werden:

FcgidMaxRequestLen 10485760

Das ganze sollte dann so aussehen:

AddHandler fcgid-script .fpl
-AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fpl
-Alias       /url/for/kivitendo-erp/          /path/to/kivitendo-erp/
-FcgidMaxRequestLen 10485760
-
-<Directory /path/to/kivitendo-erp>
-  AllowOverride All
-  Options ExecCGI Includes FollowSymlinks
-  Order Allow,Deny
-  Allow from All
-</Directory>
-
-<DirectoryMatch /path/to/kivitendo-erp/users>
-  Order Deny,Allow
-  Deny from All
-</DirectoryMatch>

Hierdurch wird nur ein zentraler Dispatcher gestartet. Alle - Zugriffe auf die einzelnen Scripte werden auf diesen umgeleitet. - Dadurch, dass zur Laufzeit öfter mal Scripte neu geladen werden, - gibt es hier kleine Performance-Einbußen.

Es ist möglich, die gleiche kivitendo Version parallel unter - CGI und FastCGI zu betreiben. Dafür bleiben die Directorydirektiven - wie oben beschrieben, die URLs werden aber umgeleitet:

# Zugriff über CGI
-Alias       /url/for/kivitendo-erp                /path/to/kivitendo-erp
-
-# Zugriff mit mod_fcgid:
-AliasMatch ^/url/for/kivitendo-erp-fcgid/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fpl
-Alias       /url/for/kivitendo-erp-fcgid/          /path/to/kivitendo-erp/

Dann ist unter /url/for/kivitendo-erp/ - die normale Version erreichbar, und unter - /url/for/kivitendo-erp-fcgid/ die - FastCGI-Version.

Zurück Nach oben Weiter
2.4. Anpassung der PostgreSQL-Konfiguration Zum Anfang 2.6. Der Task-Server
\ No newline at end of file + führen Sie die folgenden Kommandos aus:

create language 'plpgsql';
+\q

2.5.4. Datenbankbenutzer anlegen

Wenn Sie nicht den Datenbanksuperuser “postgres” zum Zugriff + benutzen wollen, so sollten Sie bei PostgreSQL einen neuen Benutzer + anlegen. Ein Beispiel, wie Sie einen neuen Benutzer anlegen + können:

Die Frage, ob der neue User Superuser sein soll, können Sie mit nein + beantworten, genauso ist die Berechtigung neue User (Roles) zu + generieren nicht nötig.

su - postgres
+createuser -d -P kivitendo
+exit

Wenn Sie später einen Datenbankzugriff konfigurieren, verändern + Sie den evtl. voreingestellten Benutzer “postgres” auf “kivitendo” bzw. + den hier gewählten Benutzernamen.

Zurück Nach oben Weiter
2.4. kivitendo-Konfigurationsdatei Zum Anfang 2.6. Webserver-Konfiguration
\ No newline at end of file diff --git a/doc/html/ch02s06.html b/doc/html/ch02s06.html index 8708cfc40..8364c5c06 100644 --- a/doc/html/ch02s06.html +++ b/doc/html/ch02s06.html @@ -1,68 +1,103 @@ - 2.6. Der Task-Server
2.6. Der Task-Server
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.6. Der Task-Server

Der Task-Server ist ein Prozess, der im Hintergrund läuft, in - regelmäßigen Abständen nach abzuarbeitenden Aufgaben sucht und diese zu - festgelegten Zeitpunkten abarbeitet (ähnlich wie Cron). Dieser Prozess - wird bisher nur für die Erzeugung der wiederkehrenden Rechnungen - benutzt, wird aber in Zukunft deutlich mehr Aufgaben übertragen - bekommen.

2.6.1. Verfügbare und notwendige Konfigurationsoptionen

Die Konfiguration erfolgt über den Abschnitt - [task_server] in der Datei - config/kivitendo.conf. Die dort verfügbaren - Optionen sind:

- login -

gültiger kivitendo-Benutzername, der benutzt wird, um die - zu verwendende Datenbankverbindung auszulesen. Der Benutzer muss - in der Administration angelegt werden. Diese Option muss - angegeben werden.

- run_as -

Wird der Server vom Systembenutzer root - gestartet, so wechselt er auf den mit run_as - angegebenen Systembenutzer. Der Systembenutzer muss dieselben - Lese- und Schreibrechte haben, wie auch der Webserverbenutzer - (siehe see Manuelle Installation des Programmpaketes). Daher - ist es sinnvoll, hier denselben Systembenutzer einzutragen, - unter dem auch der Webserver läuft.

- debug -

Schaltet Debug-Informationen an und aus.

2.6.2. Automatisches Starten des Task-Servers beim Booten

Der Task-Server verhält sich von seinen Optionen her wie ein - reguläres SystemV-kompatibles Boot-Script. Außerdem wechselt er beim - Starten automatisch in das kivitendo-Installationsverzeichnis.

Deshalb ist es möglich, ihn durch Setzen eines symbolischen - Links aus einem der Runlevel-Verzeichnisse heraus in den Boot-Prozess - einzubinden. Da das bei neueren Linux-Distributionen aber nicht - zwangsläufig funktioniert, werden auch Start-Scripte mitgeliefert, die - anstelle eines symbolischen Links verwendet werden können.

2.6.2.1. SystemV-basierende Systeme (z.B. Debian, OpenSuSE, Fedora - Core)

Kopieren Sie die Datei - scripts/boot/system-v/kivitendo-server - nach /etc/init.d/kivitendo-server. Passen - Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile - DAEMON=....). Binden Sie das Script in den - Boot-Prozess ein. Dies ist distributionsabhängig:

  • Debian-basierende Systeme:

    update-rc.d kivitendo-task-server defaults
-# Nur bei Debian Squeeze und neuer:
-insserv kivitendo-task-server

  • OpenSuSE und Fedora Core:

    chkconfig --add kivitendo-task-server

Danach kann der Task-Server mit dem folgenden Befehl gestartet - werden: /etc/init.d/kivitendo-task-server - start -

2.6.2.2. Upstart-basierende Systeme (z.B. Ubuntu)

Kopieren Sie die Datei - scripts/boot/upstart/kivitendo-task-server.conf - nach /etc/init/kivitendo-task-server.conf. - Passen Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile - exec ....).

Danach kann der Task-Server mit dem folgenden Befehl gestartet - werden: service kivitendo-task-server - start -

2.6.3. Wie der Task-Server gestartet und beendet wird

Der Task-Server wird wie folgt kontrolliert:

./scripts/task_server.pl Befehl

- Befehl ist dabei eine der folgenden - Optionen:

  • - start startet eine neue Instanz des - Task-Servers. Die Prozess-ID wird innerhalb des - users-Verzeichnisses abgelegt.

  • - stop beendet einen laufenden - Task-Server.

  • - restart beendet und startet ihn - neu.

  • - status berichtet, ob der Task-Server - läuft.

Der Task-Server wechselt beim Starten automatisch in das - kivitendo-Installationsverzeichnis.

Dieselben Optionen können auch für die SystemV-basierenden - Runlevel-Scripte benutzt werden (siehe oben).

2.6.4. Task-Server mit mehreren Mandanten

Beim Task-Server wird der Login-Name des Benutzers, unter dem der - Task-Server laufen soll, in die Konfigurationsdatei geschrieben. Hat - man mehrere Mandanten muß man auch mehrere Konfigurationsdateien - anlegen.

Die Konfigurationsdatei ist eine Kopie der Datei kivitendo.conf, - wo in der Kategorie [task_server] der gewünschte "login" steht.

Der alternative Task-Server wird dann mit folgendem Befehl - gestartet:

./scripts/task_server.pl -c config/DATEINAME.conf
Zurück Nach oben Weiter
2.5. Webserver-Konfiguration Zum Anfang 2.7. Benutzerauthentifizierung und Administratorpasswort
\ No newline at end of file + 2.6. Webserver-Konfiguration
2.6. Webserver-Konfiguration
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.6. Webserver-Konfiguration

2.6.1. Grundkonfiguration mittels CGI

[Anmerkung]Anmerkung

Für einen deutlichen Performanceschub sorgt die Ausführung + mittels FastCGI/FCGI. Die Einrichtung wird ausführlich im Abschnitt + Konfiguration für FastCGI/FCGI beschrieben.

Der Zugriff auf das Programmverzeichnis muss in der Apache + Webserverkonfigurationsdatei httpd.conf eingestellt + werden. Fügen Sie den folgenden Abschnitt dieser Datei oder einer + anderen Datei hinzu, die beim Starten des Webservers eingelesen + wird:

AddHandler cgi-script .pl
+Alias /kivitendo-erp/ /var/www/kiviteno-erp/
+
+<Directory /var/www/kivitendo-erp>
+ Options ExecCGI Includes FollowSymlinks
+</Directory>
+
+<Directory /var/www/kivitendo-erp/users>
+ Order Deny,Allow
+ Deny from All
+</Directory>

Ersetzen Sie dabei die Pfade durch diejenigen, in die Sie vorher + das kivitendo-Archiv entpacket haben.

[Anmerkung]Anmerkung

Vor den einzelnen Optionen muss bei einigen Distributionen ein + Plus ‘+’ gesetzt werden.

Auf einigen Webservern werden manchmal die Grafiken und + Style-Sheets nicht ausgeliefert. In solchen Fällen hat es oft + geholfen, die folgende Option in die Konfiguration aufzunehmen:

EnableSendfile Off

2.6.2. Konfiguration für FastCGI/FCGI

2.6.2.1. Was ist FastCGI?

Direkt aus Wikipedia + kopiert:

+ [ FastCGI ist ein Standard für die Einbindung + externer Software zur Generierung dynamischer Webseiten in einem + Webserver. FastCGI ist vergleichbar zum Common Gateway Interface + (CGI), wurde jedoch entwickelt, um dessen Performance-Probleme zu + umgehen. ] +

2.6.2.2. Warum FastCGI?

Perl Programme (wie kivitendo eines ist) werden nicht statisch + kompiliert. Stattdessen werden die Quelldateien bei jedem Start + übersetzt, was bei kurzen Laufzeiten einen Großteil der Laufzeit + ausmacht. Während SQL Ledger einen Großteil der Funktionalität in + einzelne Module kapselt, um immer nur einen kleinen Teil laden zu + müssen, ist die Funktionalität von kivitendo soweit gewachsen, dass + immer mehr Module auf den Rest des Programms zugreifen. Zusätzlich + benutzen wir umfangreiche Bibliotheken um Funktionaltät nicht selber + entwickeln zu müssen, die zusätzliche Ladezeit kosten. All dies + führt dazu dass ein kivitendo Aufruf der Kernmasken mittlerweile + deutlich länger dauert als früher, und dass davon 90% für das Laden + der Module verwendet wird.

Mit FastCGI werden nun die Module einmal geladen, und danach + wird nur die eigentliche Programmlogik ausgeführt.

2.6.2.3. Getestete Kombinationen aus Webservern und Plugin

Folgende Kombinationen sind getestet:

  • Apache 2.2.11 (Ubuntu) und mod_fcgid.

  • Apache 2.2.11 (Ubuntu) und mod_fastcgi.

Dabei wird mod_fcgid empfohlen, weil mod_fastcgi seit geraumer + Zeit nicht mehr weiter entwickelt wird. Im Folgenden wird auf + mod_fastcgi nicht mehr explizit eingegangen.

Als Perl Backend wird das Modul FCGI.pm + verwendet.

[Warnung]Warnung

FCGI-Versionen ab 0.69 und bis zu 0.71 inklusive sind extrem strict in der Behandlung von Unicode, und verweigern + bestimmte Eingaben von kivitendo. Falls es Probleme mit Umlauten in Ihrere Installation gibt, muss zwingend Version 0.68 oder + aber Version 0.72 und neuer eingesetzt werden.

Mit CPAN lässt sie sich die Vorgängerversion wie folgt + installieren:

force install M/MS/MSTROUT/FCGI-0.68.tar.gz

2.6.2.4. Konfiguration des Webservers

Bevor Sie versuchen, eine kivitendo Installation unter FCGI + laufen zu lassen, empfliehlt es sich die Installation ersteinmal + unter CGI aufzusetzen. FCGI macht es nicht einfach Fehler zu + debuggen die beim ersten aufsetzen auftreten können. Sollte die + Installation schon funktionieren, lesen Sie weiter.

Zuerst muss das FastCGI-Modul aktiviert werden. Dies kann + unter Debian/Ubuntu z.B. mit folgendem Befehl geschehen:

a2enmod fcgid

Die Konfiguration für die Verwendung von kivitendo mit FastCGI + erfolgt durch Anpassung der vorhandenen Alias- + und Directory-Direktiven. Dabei wird zwischen + dem Installationspfad von kivitendo im Dateisystem + ("/path/to/kivitendo-erp") und der URL + unterschieden, unter der kivitendo im Webbrowser erreichbar ist + ("/url/for/kivitendo-erp").

Folgender Konfigurationsschnipsel funktioniert mit + mod_fastcgi:

AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fcgi
+Alias       /url/for/kivitendo-erp/          /path/to/kivitendo-erp/
+
+<Directory /path/to/kivitendo-erp>
+  AllowOverride All
+  Options ExecCGI Includes FollowSymlinks
+  Order Allow,Deny
+  Allow from All
+</Directory>
+
+<DirectoryMatch /path/to/kivitendo-erp/users>
+  Order Deny,Allow
+  Deny from All
+</DirectoryMatch>

Seit mod_fcgid-Version 2.6.3 gelten sehr kleine Grenzen für + die maximale Größe eines Requests. Diese sollte wie folgt + hochgesetzt werden:

FcgidMaxRequestLen 10485760

Das ganze sollte dann so aussehen:

AddHandler fcgid-script .fpl
+AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fpl
+Alias       /url/for/kivitendo-erp/          /path/to/kivitendo-erp/
+FcgidMaxRequestLen 10485760
+
+<Directory /path/to/kivitendo-erp>
+  AllowOverride All
+  Options ExecCGI Includes FollowSymlinks
+  Order Allow,Deny
+  Allow from All
+</Directory>
+
+<DirectoryMatch /path/to/kivitendo-erp/users>
+  Order Deny,Allow
+  Deny from All
+</DirectoryMatch>

Hierdurch wird nur ein zentraler Dispatcher gestartet. Alle + Zugriffe auf die einzelnen Scripte werden auf diesen umgeleitet. + Dadurch, dass zur Laufzeit öfter mal Scripte neu geladen werden, + gibt es hier kleine Performance-Einbußen.

Es ist möglich, die gleiche kivitendo Version parallel unter + CGI und FastCGI zu betreiben. Dafür bleiben die Directorydirektiven + wie oben beschrieben, die URLs werden aber umgeleitet:

# Zugriff über CGI
+Alias       /url/for/kivitendo-erp                /path/to/kivitendo-erp
+
+# Zugriff mit mod_fcgid:
+AliasMatch ^/url/for/kivitendo-erp-fcgid/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fpl
+Alias       /url/for/kivitendo-erp-fcgid/          /path/to/kivitendo-erp/

Dann ist unter /url/for/kivitendo-erp/ + die normale Version erreichbar, und unter + /url/for/kivitendo-erp-fcgid/ die + FastCGI-Version.

Zurück Nach oben Weiter
2.5. Anpassung der PostgreSQL-Konfiguration Zum Anfang 2.7. Der Task-Server
\ No newline at end of file diff --git a/doc/html/ch02s07.html b/doc/html/ch02s07.html index 03430ca92..cce20a2a7 100644 --- a/doc/html/ch02s07.html +++ b/doc/html/ch02s07.html @@ -1,98 +1,68 @@ - 2.7. Benutzerauthentifizierung und Administratorpasswort
2.7. Benutzerauthentifizierung und Administratorpasswort
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.7. Benutzerauthentifizierung und Administratorpasswort

Informationen über die Einrichtung der Benutzerauthentifizierung, - über die Verwaltung von Gruppen und weitere Einstellungen

2.7.1. Grundlagen zur Benutzerauthentifizierung

kivitendo verwaltet die Benutzerinformationen in einer - Datenbank, die im folgenden “Authentifizierungsdatenbank” genannt - wird. Für jeden Benutzer kann dort eine eigene Datenbank für die - eigentlichen Finanzdaten hinterlegt sein. Diese beiden Datenbanken - können, müssen aber nicht unterschiedlich sein.

Im einfachsten Fall gibt es für kivitendo nur eine einzige - Datenbank, in der sowohl die Benutzerinformationen als auch die Daten - abgelegt werden.

Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter - entweder gegen die Authentifizierungsdatenbank oder gegen einen - LDAP-Server überprüft werden.

Welche Art der Passwortüberprüfung kivitendo benutzt und wie - kivitendo die Authentifizierungsdatenbank erreichen kann, wird in der - Konfigurationsdatei config/kivitendo.conf - festgelegt. Diese muss bei der Installation und bei einem Upgrade von - einer Version vor v2.6.0 angelegt werden. Eine - Beispielkonfigurationsdatei - config/kivitendo.conf.default existiert, die als - Vorlage benutzt werden kann.

2.7.2. Administratorpasswort

Das Passwort, das zum Zugriff auf das Aministrationsinterface - benutzt wird, wird ebenfalls in dieser Datei gespeichert. Es kann auch - nur dort und nicht mehr im Administrationsinterface selber geändert - werden. Der Parameter dazu heißt admin_password im - Abschnitt [authentication].

2.7.3. Authentifizierungsdatenbank

Die Verbindung zur Authentifizierungsdatenbank wird mit den - Parametern in [authentication/database] - konfiguriert. Hier sind die folgenden Parameter anzugeben:

- host -

Der Rechnername oder die IP-Adresse des - Datenbankservers

- port -

Die Portnummer des Datenbankservers, meist 5432

- db -

Der Name der Authentifizierungsdatenbank

- user -

Der Benutzername, mit dem sich kivitendo beim - Datenbankserver anmeldet (z.B. - "postgres")

- password -

Das Passwort für den Datenbankbenutzer

Die Datenbank muss noch nicht existieren. kivitendo kann sie - automatisch anlegen (mehr dazu siehe unten).

2.7.4. Passwortüberprüfung

kivitendo unterstützt Passwortüberprüfung auf zwei Arten: gegen - die Authentifizierungsdatenbank und gegen einen externen LDAP- oder - Active-Directory-Server. Welche davon benutzt wird, regelt der - Parameter module im Abschnitt - [authentication].

Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank - gespeichert werden, so muss der Parameter module - den Wert DB enthalten. In diesem Fall können sowohl - der Administrator als auch die Benutzer selber ihre Psaswörter in - kivitendo ändern.

Soll hingegen ein externer LDAP- oder Active-Directory-Server - benutzt werden, so muss der Parameter module auf - LDAP gesetzt werden. In diesem Fall müssen - zusätzliche Informationen über den LDAP-Server im Abschnitt - [authentication/ldap] angegeben werden:

- host -

Der Rechnername oder die IP-Adresse des LDAP- oder - Active-Directory-Servers. Diese Angabe ist zwingend - erforderlich.

- port -

Die Portnummer des LDAP-Servers; meist 389.

- tls -

Wenn Verbindungsverschlüsselung gewünscht ist, so diesen - Wert auf ‘1’ setzen, andernfalls auf - ‘0’ belassen

- attribute -

Das LDAP-Attribut, in dem der Benutzername steht, den der - Benutzer eingegeben hat. Für Active-Directory-Server ist dies - meist ‘sAMAccountName’, für andere - LDAP-Server hingegen ‘uid’. Diese Angabe ist - zwingend erforderlich.

- base_dn -

Der Abschnitt des LDAP-Baumes, der durchsucht werden soll. - Diese Angabe ist zwingend erforderlich.

- filter -

Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort - <%login%>, so wird dieses durch den vom - Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird - der LDAP-Baum nach einem Element durchsucht, bei dem das oben - angegebene Attribut mit dem Benutzernamen identisch ist.

- bind_dn und - bind_password -

Wenn der LDAP-Server eine Anmeldung erfordert, bevor er - durchsucht werden kann (z.B. ist dies bei - Active-Directory-Servern der Fall), so kann diese hier angegeben - werden. Für Active-Directory-Server kann als - ‘bind_dn’ entweder eine komplette LDAP-DN wie - z.B. ‘cn=Martin - Mustermann,cn=Users,dc=firmendomain’ auch nur der - volle Name des Benutzers eingegeben werden; in diesem Beispiel - also ‘Martin Mustermann’.

2.7.5. Name des Session-Cookies

Sollen auf einem Server mehrere kivitendo-Installationen - aufgesetzt werden, so müssen die Namen der Session-Cookies für alle - Installationen unterschiedlich sein. Der Name des Cookies wird mit dem - Parameter cookie_name im Abschnitt - [authentication]gesetzt.

Diese Angabe ist optional, wenn nur eine Installation auf dem - Server existiert.

2.7.6. Anlegen der Authentifizierungsdatenbank

Nachdem alle Einstellungen in - config/kivitendo.conf vorgenommen wurden, muss - kivitendo die Authentifizierungsdatenbank anlegen. Dieses geschieht - automatisch, wenn Sie sich im Administrationsmodul anmelden, das unter - der folgenden URL erreichbar sein sollte:

- http://localhost/kivitendo-erp/admin.pl -

Zurück Nach oben Weiter
2.6. Der Task-Server Zum Anfang 2.8. Benutzer- und Gruppenverwaltung
\ No newline at end of file + 2.7. Der Task-Server
2.7. Der Task-Server
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.7. Der Task-Server

Der Task-Server ist ein Prozess, der im Hintergrund läuft, in + regelmäßigen Abständen nach abzuarbeitenden Aufgaben sucht und diese zu + festgelegten Zeitpunkten abarbeitet (ähnlich wie Cron). Dieser Prozess + wird bisher nur für die Erzeugung der wiederkehrenden Rechnungen + benutzt, wird aber in Zukunft deutlich mehr Aufgaben übertragen + bekommen.

2.7.1. Verfügbare und notwendige Konfigurationsoptionen

Die Konfiguration erfolgt über den Abschnitt + [task_server] in der Datei + config/kivitendo.conf. Die dort verfügbaren + Optionen sind:

+ login +

gültiger kivitendo-Benutzername, der benutzt wird, um die + zu verwendende Datenbankverbindung auszulesen. Der Benutzer muss + in der Administration angelegt werden. Diese Option muss + angegeben werden.

+ run_as +

Wird der Server vom Systembenutzer root + gestartet, so wechselt er auf den mit run_as + angegebenen Systembenutzer. Der Systembenutzer muss dieselben + Lese- und Schreibrechte haben, wie auch der Webserverbenutzer + (siehe see Manuelle Installation des Programmpaketes). Daher + ist es sinnvoll, hier denselben Systembenutzer einzutragen, + unter dem auch der Webserver läuft.

+ debug +

Schaltet Debug-Informationen an und aus.

2.7.2. Automatisches Starten des Task-Servers beim Booten

Der Task-Server verhält sich von seinen Optionen her wie ein + reguläres SystemV-kompatibles Boot-Script. Außerdem wechselt er beim + Starten automatisch in das kivitendo-Installationsverzeichnis.

Deshalb ist es möglich, ihn durch Setzen eines symbolischen + Links aus einem der Runlevel-Verzeichnisse heraus in den Boot-Prozess + einzubinden. Da das bei neueren Linux-Distributionen aber nicht + zwangsläufig funktioniert, werden auch Start-Scripte mitgeliefert, die + anstelle eines symbolischen Links verwendet werden können.

2.7.2.1. SystemV-basierende Systeme (z.B. Debian, OpenSuSE, Fedora + Core)

Kopieren Sie die Datei + scripts/boot/system-v/kivitendo-server + nach /etc/init.d/kivitendo-server. Passen + Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile + DAEMON=....). Binden Sie das Script in den + Boot-Prozess ein. Dies ist distributionsabhängig:

  • Debian-basierende Systeme:

    update-rc.d kivitendo-task-server defaults
+# Nur bei Debian Squeeze und neuer:
+insserv kivitendo-task-server

  • OpenSuSE und Fedora Core:

    chkconfig --add kivitendo-task-server

Danach kann der Task-Server mit dem folgenden Befehl gestartet + werden: /etc/init.d/kivitendo-task-server + start +

2.7.2.2. Upstart-basierende Systeme (z.B. Ubuntu)

Kopieren Sie die Datei + scripts/boot/upstart/kivitendo-task-server.conf + nach /etc/init/kivitendo-task-server.conf. + Passen Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile + exec ....).

Danach kann der Task-Server mit dem folgenden Befehl gestartet + werden: service kivitendo-task-server + start +

2.7.3. Wie der Task-Server gestartet und beendet wird

Der Task-Server wird wie folgt kontrolliert:

./scripts/task_server.pl Befehl

+ Befehl ist dabei eine der folgenden + Optionen:

  • + start startet eine neue Instanz des + Task-Servers. Die Prozess-ID wird innerhalb des + users-Verzeichnisses abgelegt.

  • + stop beendet einen laufenden + Task-Server.

  • + restart beendet und startet ihn + neu.

  • + status berichtet, ob der Task-Server + läuft.

Der Task-Server wechselt beim Starten automatisch in das + kivitendo-Installationsverzeichnis.

Dieselben Optionen können auch für die SystemV-basierenden + Runlevel-Scripte benutzt werden (siehe oben).

2.7.4. Task-Server mit mehreren Mandanten

Beim Task-Server wird der Login-Name des Benutzers, unter dem der + Task-Server laufen soll, in die Konfigurationsdatei geschrieben. Hat + man mehrere Mandanten muß man auch mehrere Konfigurationsdateien + anlegen.

Die Konfigurationsdatei ist eine Kopie der Datei kivitendo.conf, + wo in der Kategorie [task_server] der gewünschte "login" steht.

Der alternative Task-Server wird dann mit folgendem Befehl + gestartet:

./scripts/task_server.pl -c config/DATEINAME.conf
Zurück Nach oben Weiter
2.6. Webserver-Konfiguration Zum Anfang 2.8. Benutzerauthentifizierung und Administratorpasswort
\ No newline at end of file diff --git a/doc/html/ch02s08.html b/doc/html/ch02s08.html index 2810a6c0e..ff5493f04 100644 --- a/doc/html/ch02s08.html +++ b/doc/html/ch02s08.html @@ -1,73 +1,98 @@ - 2.8. Benutzer- und Gruppenverwaltung
2.8. Benutzer- und Gruppenverwaltung
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.8. Benutzer- und Gruppenverwaltung

Nach der Installation müssen Benutzer, Gruppen und Datenbanken - angelegt werden. Dieses geschieht im Administrationsmenü, das Sie unter - folgender URL finden:

- http://localhost/kivitendo-erp/admin.pl -

Verwenden Sie zur Anmeldung das Password, dass Sie in der Datei - config/kivitendo.conf eingetragen haben.

2.8.1. Zusammenhänge

kivitendo verwendet eine Datenbank zum Speichern all seiner - Informationen wie Kundendaten, Artikel, Angebote, Rechnungen etc. Um - mit kivitendo arbeiten zu können, muss eine Person einen - Benutzeraccount haben. Jedem Benutzeraccount wiederum wird genau eine - Datenbank zugewiesen, mit der dieser Benutzer arbeiten kann. Es ist - möglich und normal, dass mehreren Benutzern die selbe Datenbank - zugewiesen wird, sodass sie alle mit den selben Daten arbeiten - können.

Die Basisdaten der Benutzer, die in der Administration - eingegeben werden können, werden in einer zweiten Datenbank - gespeichert, der bereits erwähnten Authentifizierungsdatenbank. Diese - ist also den Produktivdaten enthaltenden Datenbanken vorgeschaltet. - Pro kivitendo-Installation gibt es nur eine - Authentifizierungsdatenbank, aber beliebig viele Datenbanken mit - Firmendaten.

kivitendo kann seinen Benutzern Zugriff auf bestimmte - Funktionsbereiche erlauben oder verbieten. Wird der Zugriff nicht - gestattet, so werden der entsprechenden Menüpunkte auch nicht - angezeigt. Diese Rechte werden ebenfalls in der - Authentifizierungsdatenbank gespeichert.

Um Rechte verteilen zu können, verwendet kivitendo ein - Gruppen-Prinzip. Einer Gruppe kann der Zugriff auf bestimmte Bereiche - erlaubt werden. Ein Benutzer wiederum kann Mitglied in einer oder - mehrerer Gruppen sein. Der Benutzer hat Zugriff auf alle diejenigen - Funktionen, die mindestens einer Gruppe erlaubt sind, in der der - Benutzer Mitglied ist.

Die allgemeine Reihenfolge, in der Datenbanken, Gruppen und - Benutzer angelegt werden sollten, lautet:

  1. Datenbank anlegen

  2. Gruppen anlegen

  3. Benutzer anlegen

  4. Benutzer den Gruppen zuordnen

2.8.2. Datenbanken anlegen

Zuerst muss eine Datenbank angelegt werden. Verwenden Sie für - den Datenbankzugriff den vorhin angelegten Benutzer (in unseren - Beispielen ist dies ‘kivitendo’).

Wenn Sie für die kivitendo-Installation nicht Unicode (UTF-8) sondern den europäischen Schriftsatz ISO-8859-15 benutzen - wollen, so müssen Sie vor dem Anlegen der Datenbank in der Datei config/kivitendo.conf die Variable - dbcharset im Abschnitt system auf den Wert ‘ISO-8859-15’ setzen.

Bitte beachten Sie, dass alle Datenbanken den selben Zeichensatz - verwenden müssen, da diese Einstellungen momentan global in kivitendo - vorgenommen wird und nicht nach Datenbank unterschieden werden kann. - Auch die Authentifizierungsdatenbank muss mit diesem Zeichensatz - angelegt worden sein.

2.8.3. Gruppen anlegen

Eine Gruppe wird in der Gruppenverwaltung angelegt. Ihr muss ein - Name gegeben werden, eine Beschreibung ist hingegen optional. Nach dem - Anlegen können Sie die verschiedenen Bereiche wählen, auf die - Mitglieder dieser Gruppe Zugriff haben sollen.

Benutzergruppen sind unabhängig von Datenbanken, da sie in der - Authentifizierungsdatenbank gespeichert werden. Sie gelten für alle - Datenbanken, die in dieser Installation verwaltet werden.

2.8.4. Benutzer anlegen

Beim Anlegen von Benutzern werden für viele Parameter - Standardeinstellungen vorgenommen, die den Gepflogenheiten des - deutschen Raumes entsprechen.

Zwingend anzugeben sind der Loginname sowie die komplette - Datenbankkonfiguration. Wenn die Passwortauthentifizierung über die - Datenbank eingestellt ist, so kann hier auch das Benutzerpasswort - gesetzt bzw. geändert werden. Ist hingegen die LDAP-Authentifizierung - aktiv, so ist das Passwort-Feld deaktiviert.

In der Datenbankkonfiguration müssen die Zugriffsdaten einer der - eben angelegten Datenbanken eingetragen werden.

2.8.5. Gruppenmitgliedschaften verwalten

Nach dem Anlegen von Benutzern und Gruppen müssen Benutzer den - Gruppen zugewiesen werden. Dazu gibt es zwei Möglichkeiten:

  1. In der Gruppenverwaltung wählt man eine Gruppe aus. Im - folgenden Dialog kann man dann einzeln die Benutzer der Gruppe - hinzufügen.

  2. In der Gruppenverwaltung wählt man das Tool zur Verwaltung - der Gruppenmitgliedschaft. Hier wird eine Matrix angezeigt, die - alle im System angelegten Gruppen und Benutzer enthält. Durch - Setzen der Häkchen wird der Benutzer in der ausgewählten Zeile der - Gruppe in der ausgewählten Spalte hinzugefügt.

2.8.6. Migration alter Installationen

Wenn kivitendo 2.6.3 über eine ältere Version installiert wird, - in der die Benutzerdaten noch im Dateisystem im Verzeichnis - users verwaltet wurden, so bietet kivitendo die - Möglichkeit, diese Benutzerdaten automatisch in die - Authentifizierungsdatenbank zu übernehmen. Dies geschieht, wenn man - sich nach dem Update der Installation das erste Mal im - Administrationsbereich anmeldet. Findet kivitendo die Datei - users/members, so wird der Migrationsprozess - gestartet.

Der Migrationsprozess ist nahezu vollautomatisch. Alle - Benutzerdaten können übernommen werden. Nach den Benutzerdaten bietet - kivitendo noch die Möglichkeit an, dass automatisch eine - Benutzergruppe angelegt wird. Dieser Gruppe wird Zugriff auf alle - Funktionen von kivitendo gewährt. Alle migrierten Benutzern werden - Mitglied in dieser Gruppe. Damit wird das Verhalten von kivitendo bis - Version 2.4.3 inklusive wiederhergestellt, und die Benutzer können - sich sofort wieder anmelden und mit dem System arbeiten.

Zurück Nach oben Weiter
2.7. Benutzerauthentifizierung und Administratorpasswort Zum Anfang 2.9. E-Mail-Versand aus kivitendo heraus
\ No newline at end of file + 2.8. Benutzerauthentifizierung und Administratorpasswort
2.8. Benutzerauthentifizierung und Administratorpasswort
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.8. Benutzerauthentifizierung und Administratorpasswort

Informationen über die Einrichtung der Benutzerauthentifizierung, + über die Verwaltung von Gruppen und weitere Einstellungen

2.8.1. Grundlagen zur Benutzerauthentifizierung

kivitendo verwaltet die Benutzerinformationen in einer + Datenbank, die im folgenden “Authentifizierungsdatenbank” genannt + wird. Für jeden Benutzer kann dort eine eigene Datenbank für die + eigentlichen Finanzdaten hinterlegt sein. Diese beiden Datenbanken + können, müssen aber nicht unterschiedlich sein.

Im einfachsten Fall gibt es für kivitendo nur eine einzige + Datenbank, in der sowohl die Benutzerinformationen als auch die Daten + abgelegt werden.

Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter + entweder gegen die Authentifizierungsdatenbank oder gegen einen + LDAP-Server überprüft werden.

Welche Art der Passwortüberprüfung kivitendo benutzt und wie + kivitendo die Authentifizierungsdatenbank erreichen kann, wird in der + Konfigurationsdatei config/kivitendo.conf + festgelegt. Diese muss bei der Installation und bei einem Upgrade von + einer Version vor v2.6.0 angelegt werden. Eine + Beispielkonfigurationsdatei + config/kivitendo.conf.default existiert, die als + Vorlage benutzt werden kann.

2.8.2. Administratorpasswort

Das Passwort, das zum Zugriff auf das Aministrationsinterface + benutzt wird, wird ebenfalls in dieser Datei gespeichert. Es kann auch + nur dort und nicht mehr im Administrationsinterface selber geändert + werden. Der Parameter dazu heißt admin_password im + Abschnitt [authentication].

2.8.3. Authentifizierungsdatenbank

Die Verbindung zur Authentifizierungsdatenbank wird mit den + Parametern in [authentication/database] + konfiguriert. Hier sind die folgenden Parameter anzugeben:

+ host +

Der Rechnername oder die IP-Adresse des + Datenbankservers

+ port +

Die Portnummer des Datenbankservers, meist 5432

+ db +

Der Name der Authentifizierungsdatenbank

+ user +

Der Benutzername, mit dem sich kivitendo beim + Datenbankserver anmeldet (z.B. + "postgres")

+ password +

Das Passwort für den Datenbankbenutzer

Die Datenbank muss noch nicht existieren. kivitendo kann sie + automatisch anlegen (mehr dazu siehe unten).

2.8.4. Passwortüberprüfung

kivitendo unterstützt Passwortüberprüfung auf zwei Arten: gegen + die Authentifizierungsdatenbank und gegen einen externen LDAP- oder + Active-Directory-Server. Welche davon benutzt wird, regelt der + Parameter module im Abschnitt + [authentication].

Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank + gespeichert werden, so muss der Parameter module + den Wert DB enthalten. In diesem Fall können sowohl + der Administrator als auch die Benutzer selber ihre Psaswörter in + kivitendo ändern.

Soll hingegen ein externer LDAP- oder Active-Directory-Server + benutzt werden, so muss der Parameter module auf + LDAP gesetzt werden. In diesem Fall müssen + zusätzliche Informationen über den LDAP-Server im Abschnitt + [authentication/ldap] angegeben werden:

+ host +

Der Rechnername oder die IP-Adresse des LDAP- oder + Active-Directory-Servers. Diese Angabe ist zwingend + erforderlich.

+ port +

Die Portnummer des LDAP-Servers; meist 389.

+ tls +

Wenn Verbindungsverschlüsselung gewünscht ist, so diesen + Wert auf ‘1’ setzen, andernfalls auf + ‘0’ belassen

+ attribute +

Das LDAP-Attribut, in dem der Benutzername steht, den der + Benutzer eingegeben hat. Für Active-Directory-Server ist dies + meist ‘sAMAccountName’, für andere + LDAP-Server hingegen ‘uid’. Diese Angabe ist + zwingend erforderlich.

+ base_dn +

Der Abschnitt des LDAP-Baumes, der durchsucht werden soll. + Diese Angabe ist zwingend erforderlich.

+ filter +

Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort + <%login%>, so wird dieses durch den vom + Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird + der LDAP-Baum nach einem Element durchsucht, bei dem das oben + angegebene Attribut mit dem Benutzernamen identisch ist.

+ bind_dn und + bind_password +

Wenn der LDAP-Server eine Anmeldung erfordert, bevor er + durchsucht werden kann (z.B. ist dies bei + Active-Directory-Servern der Fall), so kann diese hier angegeben + werden. Für Active-Directory-Server kann als + ‘bind_dn’ entweder eine komplette LDAP-DN wie + z.B. ‘cn=Martin + Mustermann,cn=Users,dc=firmendomain’ auch nur der + volle Name des Benutzers eingegeben werden; in diesem Beispiel + also ‘Martin Mustermann’.

2.8.5. Name des Session-Cookies

Sollen auf einem Server mehrere kivitendo-Installationen + aufgesetzt werden, so müssen die Namen der Session-Cookies für alle + Installationen unterschiedlich sein. Der Name des Cookies wird mit dem + Parameter cookie_name im Abschnitt + [authentication]gesetzt.

Diese Angabe ist optional, wenn nur eine Installation auf dem + Server existiert.

2.8.6. Anlegen der Authentifizierungsdatenbank

Nachdem alle Einstellungen in + config/kivitendo.conf vorgenommen wurden, muss + kivitendo die Authentifizierungsdatenbank anlegen. Dieses geschieht + automatisch, wenn Sie sich im Administrationsmodul anmelden, das unter + der folgenden URL erreichbar sein sollte:

+ http://localhost/kivitendo-erp/admin.pl +

Zurück Nach oben Weiter
2.7. Der Task-Server Zum Anfang 2.9. Benutzer- und Gruppenverwaltung
\ No newline at end of file diff --git a/doc/html/ch02s09.html b/doc/html/ch02s09.html index acfb79539..09b3a6df0 100644 --- a/doc/html/ch02s09.html +++ b/doc/html/ch02s09.html @@ -1,36 +1,73 @@ - 2.9. E-Mail-Versand aus kivitendo heraus
2.9. E-Mail-Versand aus kivitendo heraus
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.9. E-Mail-Versand aus kivitendo heraus

kivitendo kann direkt aus dem Programm heraus E-Mails versenden, z.B. um ein Angebot direkt an einen Kunden zu - verschicken. Damit dies funktioniert, muss eingestellt werden, über welchen Server die E-Mails verschickt werden sollen. kivitendo - unterstützt dabei zwei Mechanismen: Versand über einen lokalen E-Mail-Server (z.B. mit Postfix™ oder - Exim™, was auch die standardmäßig aktive Methode ist) sowie Versand über einen SMTP-Server (z.B. der des - eigenen Internet-Providers).

Welche Methode und welcher Server verwendet werden, wird über die Konfigurationsdatei config/kivitendo.conf - festgelegt. Dort befinden sich alle Einstellungen zu diesem Thema im Abschnitt '[mail_delivery]'.

2.9.1. Versand über lokalen E-Mail-Server

Diese Methode bietet sich an, wenn auf dem Server, auf dem kivitendo läuft, bereits ein funktionsfähiger E-Mail-Server wie - z.B. Postfix™, Exim™ oder Sendmail™ läuft.

Um diese Methode auszuwählen, muss der Konfigurationsparameter 'method = sendmail' gesetzt sein. Dies ist - gleichzeitig der Standardwert, falls er nicht verändert wird.

Um zu kontrollieren, wie das Programm zum Einliefern gestartet wird, dient der Parameter 'sendmail = - ...'. Der Standardwert verweist auf das Programm /usr/bin/sendmail, das bei allen oben genannten - E-Mail-Serverprodukten für diesen Zweck funktionieren sollte.

Die Konfiguration des E-Mail-Servers selber würde den Rahmen dieses sprengen. Hierfür sei auf die Dokumentation des - E-Mail-Servers verwiesen.

2.9.2. Versand über einen SMTP-Server

Diese Methode bietet sich an, wenn kein lokaler E-Mail-Server vorhanden oder zwar einer vorhanden, dieser aber nicht - konfiguriert ist.

Um diese Methode auszuwählen, muss der Konfigurationsparameter 'method = smtp' gesetzt sein. Die folgenden - Parameter dienen dabei der weiteren Konfiguration:

- hostname -

Name oder IP-Adresse des SMTP-Servers. Standardwert: 'localhost'

- port -

Portnummer. Der Standardwert hängt von der verwendeten Verschlüsselungsmethode ab. Gilt 'security = - none' oder 'security = tls', so ist 25 die Standardportnummer. Für 'security = - ssl' ist 465 die Portnummer. Muss normalerweise nicht geändert werden.

- security -

Wahl der zu verwendenden Verschlüsselung der Verbindung mit dem Server. Standardwert ist - 'none', wodurch keine Verschlüsselung verwendet wird. Mit 'tls' wird TLS-Verschlüsselung - eingeschaltet, und mit 'ssl' wird Verschlüsselung via SSL eingeschaltet. Achtung: Für - 'tls' und 'ssl' werden zusätzliche Perl-Module benötigt (siehe unten).

- login und password -

Falls der E-Mail-Server eine Authentifizierung verlangt, so können mit diesen zwei Parametern der Benutzername - und das Passwort angegeben werden. Wird Authentifizierung verwendet, so sollte aus Sicherheitsgründen auch eine Form von - Verschlüsselung aktiviert werden.

Wird Verschlüsselung über TLS oder SSL aktiviert, so werden zusätzliche Perl-Module benötigt. Diese sind:

  • TLS-Verschlüsselung: Modul Net::SSLGlue (Debian-Paketname - libnet-sslglue-perl, Fedora Core: perl-Net-SSLGlue, openSuSE: - perl-Net-SSLGlue -

  • SSL-Verschlüsselung: Modul Net::SMTP::SSL (Debian-Paketname - libnet-smtp-ssl-perl, Fedora Core: perl-Net-SMTP-SSL, openSuSE: - perl-Net-SMTP-SSL -

Zurück Nach oben Weiter
2.8. Benutzer- und Gruppenverwaltung Zum Anfang 2.10. Drucken mit kivitendo
\ No newline at end of file + 2.9. Benutzer- und Gruppenverwaltung
2.9. Benutzer- und Gruppenverwaltung
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.9. Benutzer- und Gruppenverwaltung

Nach der Installation müssen Benutzer, Gruppen und Datenbanken + angelegt werden. Dieses geschieht im Administrationsmenü, das Sie unter + folgender URL finden:

+ http://localhost/kivitendo-erp/admin.pl +

Verwenden Sie zur Anmeldung das Password, dass Sie in der Datei + config/kivitendo.conf eingetragen haben.

2.9.1. Zusammenhänge

kivitendo verwendet eine Datenbank zum Speichern all seiner + Informationen wie Kundendaten, Artikel, Angebote, Rechnungen etc. Um + mit kivitendo arbeiten zu können, muss eine Person einen + Benutzeraccount haben. Jedem Benutzeraccount wiederum wird genau eine + Datenbank zugewiesen, mit der dieser Benutzer arbeiten kann. Es ist + möglich und normal, dass mehreren Benutzern die selbe Datenbank + zugewiesen wird, sodass sie alle mit den selben Daten arbeiten + können.

Die Basisdaten der Benutzer, die in der Administration + eingegeben werden können, werden in einer zweiten Datenbank + gespeichert, der bereits erwähnten Authentifizierungsdatenbank. Diese + ist also den Produktivdaten enthaltenden Datenbanken vorgeschaltet. + Pro kivitendo-Installation gibt es nur eine + Authentifizierungsdatenbank, aber beliebig viele Datenbanken mit + Firmendaten.

kivitendo kann seinen Benutzern Zugriff auf bestimmte + Funktionsbereiche erlauben oder verbieten. Wird der Zugriff nicht + gestattet, so werden der entsprechenden Menüpunkte auch nicht + angezeigt. Diese Rechte werden ebenfalls in der + Authentifizierungsdatenbank gespeichert.

Um Rechte verteilen zu können, verwendet kivitendo ein + Gruppen-Prinzip. Einer Gruppe kann der Zugriff auf bestimmte Bereiche + erlaubt werden. Ein Benutzer wiederum kann Mitglied in einer oder + mehrerer Gruppen sein. Der Benutzer hat Zugriff auf alle diejenigen + Funktionen, die mindestens einer Gruppe erlaubt sind, in der der + Benutzer Mitglied ist.

Die allgemeine Reihenfolge, in der Datenbanken, Gruppen und + Benutzer angelegt werden sollten, lautet:

  1. Datenbank anlegen

  2. Gruppen anlegen

  3. Benutzer anlegen

  4. Benutzer den Gruppen zuordnen

2.9.2. Datenbanken anlegen

Zuerst muss eine Datenbank angelegt werden. Verwenden Sie für + den Datenbankzugriff den vorhin angelegten Benutzer (in unseren + Beispielen ist dies ‘kivitendo’).

Wenn Sie für die kivitendo-Installation nicht Unicode (UTF-8) sondern den europäischen Schriftsatz ISO-8859-15 benutzen + wollen, so müssen Sie vor dem Anlegen der Datenbank in der Datei config/kivitendo.conf die Variable + dbcharset im Abschnitt system auf den Wert ‘ISO-8859-15’ setzen.

Bitte beachten Sie, dass alle Datenbanken den selben Zeichensatz + verwenden müssen, da diese Einstellungen momentan global in kivitendo + vorgenommen wird und nicht nach Datenbank unterschieden werden kann. + Auch die Authentifizierungsdatenbank muss mit diesem Zeichensatz + angelegt worden sein.

2.9.3. Gruppen anlegen

Eine Gruppe wird in der Gruppenverwaltung angelegt. Ihr muss ein + Name gegeben werden, eine Beschreibung ist hingegen optional. Nach dem + Anlegen können Sie die verschiedenen Bereiche wählen, auf die + Mitglieder dieser Gruppe Zugriff haben sollen.

Benutzergruppen sind unabhängig von Datenbanken, da sie in der + Authentifizierungsdatenbank gespeichert werden. Sie gelten für alle + Datenbanken, die in dieser Installation verwaltet werden.

2.9.4. Benutzer anlegen

Beim Anlegen von Benutzern werden für viele Parameter + Standardeinstellungen vorgenommen, die den Gepflogenheiten des + deutschen Raumes entsprechen.

Zwingend anzugeben sind der Loginname sowie die komplette + Datenbankkonfiguration. Wenn die Passwortauthentifizierung über die + Datenbank eingestellt ist, so kann hier auch das Benutzerpasswort + gesetzt bzw. geändert werden. Ist hingegen die LDAP-Authentifizierung + aktiv, so ist das Passwort-Feld deaktiviert.

In der Datenbankkonfiguration müssen die Zugriffsdaten einer der + eben angelegten Datenbanken eingetragen werden.

2.9.5. Gruppenmitgliedschaften verwalten

Nach dem Anlegen von Benutzern und Gruppen müssen Benutzer den + Gruppen zugewiesen werden. Dazu gibt es zwei Möglichkeiten:

  1. In der Gruppenverwaltung wählt man eine Gruppe aus. Im + folgenden Dialog kann man dann einzeln die Benutzer der Gruppe + hinzufügen.

  2. In der Gruppenverwaltung wählt man das Tool zur Verwaltung + der Gruppenmitgliedschaft. Hier wird eine Matrix angezeigt, die + alle im System angelegten Gruppen und Benutzer enthält. Durch + Setzen der Häkchen wird der Benutzer in der ausgewählten Zeile der + Gruppe in der ausgewählten Spalte hinzugefügt.

2.9.6. Migration alter Installationen

Wenn kivitendo 2.6.3 über eine ältere Version installiert wird, + in der die Benutzerdaten noch im Dateisystem im Verzeichnis + users verwaltet wurden, so bietet kivitendo die + Möglichkeit, diese Benutzerdaten automatisch in die + Authentifizierungsdatenbank zu übernehmen. Dies geschieht, wenn man + sich nach dem Update der Installation das erste Mal im + Administrationsbereich anmeldet. Findet kivitendo die Datei + users/members, so wird der Migrationsprozess + gestartet.

Der Migrationsprozess ist nahezu vollautomatisch. Alle + Benutzerdaten können übernommen werden. Nach den Benutzerdaten bietet + kivitendo noch die Möglichkeit an, dass automatisch eine + Benutzergruppe angelegt wird. Dieser Gruppe wird Zugriff auf alle + Funktionen von kivitendo gewährt. Alle migrierten Benutzern werden + Mitglied in dieser Gruppe. Damit wird das Verhalten von kivitendo bis + Version 2.4.3 inklusive wiederhergestellt, und die Benutzer können + sich sofort wieder anmelden und mit dem System arbeiten.

Zurück Nach oben Weiter
2.8. Benutzerauthentifizierung und Administratorpasswort Zum Anfang 2.10. E-Mail-Versand aus kivitendo heraus
\ No newline at end of file diff --git a/doc/html/ch02s10.html b/doc/html/ch02s10.html index a83033615..e78a3d507 100644 --- a/doc/html/ch02s10.html +++ b/doc/html/ch02s10.html @@ -1,101 +1,36 @@ - 2.10. Drucken mit kivitendo
2.10. Drucken mit kivitendo
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.10. Drucken mit kivitendo

Das Drucksystem von kivitendo benutzt von Haus aus LaTeX-Vorlagen. Um drucken zu können, braucht der Server ein geeignetes - LaTeX System. Am einfachsten ist dazu eine texlive Installation. Unter Debianoiden Betriebssystemen installiert man - die Pakete mit:

- 

aptitude install texlive-base-bin texlive-latex-recommended texlive-fonts-recommended \
-  texlive-latex-extra texlive-lang-german texlive-generic-extra

-

TODO: RPM-Pakete.

kivitendo bringt drei alternative Vorlagensätze mit:

  • Standard

  • f-tex

  • RB

2.10.1. Vorlagenverzeichnis anlegen

Im Administrationsbereich lässt sich bei einem Benutzer/Mandanten einer dieser Vorlagensätze als Basis für die zu - druckenden Dokumente auswählen. Rufen Sie dazu die Benutzerverwaltung auf.

Wählen Sie dort einen Benutzer aus oder legen Sie einen neuen an. In der Benutzerbearbeiten-Maske müssen Sie zwei Dinge - angeben:

  1. - Name: Der Verzeichnisname für den neuen Vorlagensatz. Dieser kann im Rahmen der üblichen - Bedingungen für Verzeichnisnamen frei gewählt werden.

  2. - Vorlagen auswählen: Wählen Sie hier den Vorlagensatz aus, der kopiert werden soll - (Standard, f-tex oder RB.)

Der gleiche Vorlagensatz kann, wenn er mal angelegt ist, bei mehreren Benutzern verwendet werden.

Die Abhängigkeiten kann man prüfen mit:

/scripts/installation_check.pl -l

2.10.2. Standard

Der Standard-Vorlagensatz von Kivitendo. Wie unter http://demo.kivitendo.org zu - sehen.

2.10.3. f-tex

Ein Vorlagensatz, der in wenigen Minuten alle Dokumente zur Verfügung stellt.

2.10.3.1. Feature-Übersicht

  • Keine Redundanz. Es wird ein- und dieselbe LaTeX-Vorlage für alle briefartigen Dokumente verwendet. Also - Angebot, Rechnung, Performarechnung, Lieferschein, aber eben nicht für Paketaufkleber etc..

  • Leichte Anpassung an das Firmen-Layout durch verwendung eines Hintergrund-PDF. Dieses kann leicht mit dem - eigenen Lieblingsprogramm erstellt werden (Openoffice, Inkscape, Gimp, Adobe*)

  • Hintergrund-PDF umschaltbar auf "nur erste Seite" (Standard) oder "alle Seiten" (Option - "bgPdfFirstPageOnly" in Datei letter.lco)

  • Hintergrund-PDF für Ausdruck auf bereits bedrucktem Briefpapier abschaltbar. Es wird dann nur bei per E-Mail - versendeten Dokumenten eingebunden (Option "bgPdfEmailOnly" in Datei - letter.lco).

  • Nutzung der Layout-Funktionen von LaTeX für Seitenumbruch, Wiederholung von Kopfzeilen, Zwischensummen - etc. (danke an Kai-Martin Knaak für die Vorarbeit)

  • Anzeige des Empfängerlandes im Adressfeld nur, wenn es vom Land des eigenen Unternehmens abweicht (also die - Rechnung das Land verlässt).

  • Multisprachfähig leicht um weitere Sprachen zu erweitern, alle Übersetzungen in der Datei - translatinos.tex.

  • Auflistung von Bruttopreisen für Endverbraucher.

2.10.3.2. Die Installation

  • Vorlagenverzeichnis mit Option f-tex anlegen, siehe: Vorlagenverzeichnis anlegen. Das - Vorlagensystem funktioniert jetzt schon, hat allerdings noch einen Beispiel-Briefkopf.

  • Erstelle eine pdf-Hintergrund Datei und verlinke sie nach ./letter_head.pdf.

  • Editiere den Bereich "settings" in der datei letter.lco.

oder etwas Detaillierter:

- Es wird eine Datei sample.lco erstellt und diese nach letter.lco verlinkt. Eigentlich - ist dies die Datei die für die Firmenspezifischen Anpassungen gedacht ist. Da die Einstiegshürde in LaTeX nicht ganz niedrig - ist, wird in dieser Datei auf ein Hintergrundpdf verwiesen. Ich empfehle über dieses PDF die persönlichen Layoutanpassungen - vorzunehmen und sample.lco unverändert zu lassen. Die die Anpassung über eine - *.lco-Datei die letztlich auf letter.lco verlinkt ist ist aber auch möglich. -

- Es wird eine Datei sample_head.pdf mit ausgeliefert, diese wird nach letter_head.pdf - verlinkt. Damit gibt es schon mal eine Funktionsfähige Vorlage. Schau Dir nach Abschluss der Installation die Datei - sample_haed.pdf an und erstelle ein entsprechendes PDF passend zum Briefkopf Deiner Firma, diese dann im - Template Verzeichniss ablegen und statt sample_head.pdf nach letter_head.pdf - verlinken. -

- letzlich muss letter_head.pdf auf das passende Hintergrund-PDF verweisen, welches gewünschten Briefkopf - enthält. Bei Updates oder nach erneutem -

- Es wird eine Datei mydata.tex.example ausgeliefert, die nach mytdata.tex verlinkt - ist. Bei verwendetem Hintergrund-PDF wird nur der Eintrag für das Land verwendet. Die Datei muss also nicht angefasst - werden. Die Anderen Werte sind für das Modul 'lp' (Label Print in erp - zur Zeit nicht im öffentlichen Zweig). -

- Alle Anpassungen zum Briefkopf, Fusszeilen, Firmenlogos, etc. sollten über die Hintergrund-PDF-Datei oder die - *.lco-Datei erfolgen. -

2.10.3.3. f-tex Funktionsübersicht

- Das Konzept von kivitendo sieht vor, für jedes Dokument (Auftragsbestätigung, Lieferschein, Rechnung, etc.) eine LaTeX-Vorlage - vorzuhalten, dies ist sehr Wartungsunfreundlich. Auch das Einlesen einer einheitlichen Quelle für den Briefkopf bringt nur - bedingte Vorteile, da hier leicht die Pflege der Artikel-Tabellen aus dem Ruder läuft. Bei dem vorliegenden Ansatz wird für alle - briefartigen Dokumente mit Artikel-Tabellen eine einheitliche LaTeX-Vorlage verwendet, welche über Codeweichen die - Besonderheiten der jeweiligen Dokumente Berücksichtigt. -

  • Tabellen mit oder ohne Preis

  • Sprache der Tabellenüberschriften etc.

  • Anpassung der Bezugs-Zeile (z.B. Rechnungsnummer versus Angebotsnummer)

  • Darstellung von Brutto oder Netto-Preisen in der Auflistung (Endverbraucher versus Gewerblicher - Kunde)

Nachteil:

- LaTeX hat ohnehin eine sehr steile Lehrnkurve. Die Datei letter.tex ist sehr komplex und verstärkt damit - diesen Effekt noch einmal erheblich. Wer LaTeX-Erfahrung hat, oder geübt ist Scriptsparachen nachzuvollziehen kann natürlich - auch innerhalb der Tabellendarstellung gut persönliche Anpassungen vornehmen. Aber man kann sich hier bei Veränderungen sehr - schnell häftig in den Fuss schiessen. -

Wer nicht so tief in die Materie einsteigen will oder leicht zu frustrieren ist, sollte sein Hintergrund PDF auf Basis der - mitglieferten Datei sample_head.pdf erstellen, und sich an der Form der dargestellten Tabellen wie sie - ausgeliefert werden, erfreuen. -

Kleiner Tipp: Nicht zu viel auf einmal wollen, lieber kleine kontinuierliche Schritte gehen.

2.10.3.4. Bruttopreise für Endverbraucher

Der auszuweisende Bruttopreis wird innerhalb der LaTeX-Umgebung berechnet. Es gibt zwar ein Feld, um bei Aufträgen "alle - Preise Brutto" auszuwählen, aber:

  • hierfür müssen die Preise auch in Brutto in der Datenbank stehen (ja - das lässt sich über die Preisgruppen und die - Zuordung einer Default-Preisgruppe handhaben)

  • man darf beim Anlegen des Vorgangs nicht vergessen Dieses Häkchen zu setzen. (das ist in der Praxis wenn man sowohl - Endverbraucher- wie Gewerbekunden beliefert der eigentliche Knackpunkt)

- Es gibt mit f-tex eine weitere Alternative. Die Information ob Brutto oder Nettorechnung wird mit den Zahlarten - verknüpft. Zahlarten bei denen Rechnungen, Angebote, etc, in Brutto ausgegeben werden sollen, enden mit "_E" (für - Endverbraucher). Falls identische Zahlarten für Gewerbekunden und Endverbraucher vorhanden sind, legt man diese einfach doppelt - an (einmal mit der Namensendung "_E"). Gewinn:

  • Die Entscheidung, ob Netopreise ausgewiesen werden, ist nicht mehr fix mit einer Preisliste Verbunden.

  • Die Default-Zahlart kann im Kundendatensatz hinterlegt werden, und man muss nicht mehr daran denken, "alle Preise - Netto" auszuwählen.

  • Die Entscheidung, ob Netto- oder Bruttopreise ausgewiesen werden, kann direkt beim Drucken reviediert werden, - ohne dass sich der Auftragswert ändert.

2.10.3.5. Lieferadressen

In Lieferscheinen kommen shipto*-Variablen im Adressfeld zum Einsatz. Wenn die - shipto*-Variable leer ist, wird die entsprechende Adressvariable eingesetzt. Wenn also die Lieferadresse in - Straße, Hausnummer und Ort abweicht, müssen auch nur diese Felder in der Lieferadresse ausgefüllt werden. Für den Firmenname wird - der Wert der Hauptadresse angezeigt. -

2.10.4. RB

Vollständiger Dokumentensatz mit alternativem Design

2.10.5. Allgemeine Hinweise zu LaTeX Vorlagen

In den allermeisten Installationen sollte drucken jetzt schon - funktionieren. Sollte ein Fehler auftreten wirft TeX sehr lange - Fehlerbeschreibungen, der eigentliche Fehler ist immer die erste Zeite - die mit einem Ausrufezeichen anfängt. Häufig auftretende Fehler sind zum - Beispiel:

  • ! LaTeX Error: File `eurosym.sty' not found. Die entsprechende - LaTeX-Bibliothek wurde nicht gefunden. Das tritt vor allem bei - Vorlagen aus der Community auf. Installieren Sie die entsprechenden - Pakete.

  • ! Package inputenc Error: Unicode char \u8:... set up for - use with LaTeX. Dieser Fehler tritt auf, wenn sie versuchen mit - einer Standardinstallation exotische utf8 Zeichen zu drucken. - TeXLive unterstützt von Haus nur romanische Schriften und muss mit - diversen Tricks dazu gebracht werden andere Zeichen zu akzeptieren. - Adere TeX Systeme wie XeTeX schaffen hier Abhilfe.

Wird garkein Fehler angezeigt sondern nur der Name des Templates, - heißt das normalerweise, dass das LaTeX Binary nicht gefunden wurde. - Prüfen Sie den Namen in der Konfiguration (Standard: - pdflatex), und stellen Sie sicher, dass pdflatex - (oder das von Ihnen verwendete System) vom Webserver ausgeführt werden - darf.

Wenn sich das Problem nicht auf Grund der ausgabe im Webbrowser verifizieren lässt:

  • editiere [kivitendo-home]/config/kivitendo.conf und ändere "keep_tmp_files" auf 1

    - 

    keep_temp_files = 1;

    -

  • bei fastcgi oder mod_perl den Webserver neu Starten

  • Nochmal einen Druckversuch im Webfrontend auslösen

  • wechsele in das users Verzeichnis von kivitendo

    - 

    cd [kivitendo-home]/users

    -

  • LaTeX Suchpfad anpassen:

    - 

    export TEXINPUTS=".:[kivitendo-home]/templates/[aktuelles_template_verzeichniss]:"

    -

  • Finde herraus welche Datei kivitendo beim letzten Durchlauf erstellt hat

    - 

    ls -lahtr ./1*.tex

    -

    Es sollte die letzte Datei ganz unten sein

  • für besseren Hinweis auf Fehler texdatei nochmals übersetzen

    - 

    pdflatex ./1*.tex

    -

    in der *.tex datei nach dem Fehler suchen.

Zurück Nach oben Weiter
2.9. E-Mail-Versand aus kivitendo heraus Zum Anfang 2.11. OpenDocument-Vorlagen
\ No newline at end of file + 2.10. E-Mail-Versand aus kivitendo heraus
2.10. E-Mail-Versand aus kivitendo heraus
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.10. E-Mail-Versand aus kivitendo heraus

kivitendo kann direkt aus dem Programm heraus E-Mails versenden, z.B. um ein Angebot direkt an einen Kunden zu + verschicken. Damit dies funktioniert, muss eingestellt werden, über welchen Server die E-Mails verschickt werden sollen. kivitendo + unterstützt dabei zwei Mechanismen: Versand über einen lokalen E-Mail-Server (z.B. mit Postfix™ oder + Exim™, was auch die standardmäßig aktive Methode ist) sowie Versand über einen SMTP-Server (z.B. der des + eigenen Internet-Providers).

Welche Methode und welcher Server verwendet werden, wird über die Konfigurationsdatei config/kivitendo.conf + festgelegt. Dort befinden sich alle Einstellungen zu diesem Thema im Abschnitt '[mail_delivery]'.

2.10.1. Versand über lokalen E-Mail-Server

Diese Methode bietet sich an, wenn auf dem Server, auf dem kivitendo läuft, bereits ein funktionsfähiger E-Mail-Server wie + z.B. Postfix™, Exim™ oder Sendmail™ läuft.

Um diese Methode auszuwählen, muss der Konfigurationsparameter 'method = sendmail' gesetzt sein. Dies ist + gleichzeitig der Standardwert, falls er nicht verändert wird.

Um zu kontrollieren, wie das Programm zum Einliefern gestartet wird, dient der Parameter 'sendmail = + ...'. Der Standardwert verweist auf das Programm /usr/bin/sendmail, das bei allen oben genannten + E-Mail-Serverprodukten für diesen Zweck funktionieren sollte.

Die Konfiguration des E-Mail-Servers selber würde den Rahmen dieses sprengen. Hierfür sei auf die Dokumentation des + E-Mail-Servers verwiesen.

2.10.2. Versand über einen SMTP-Server

Diese Methode bietet sich an, wenn kein lokaler E-Mail-Server vorhanden oder zwar einer vorhanden, dieser aber nicht + konfiguriert ist.

Um diese Methode auszuwählen, muss der Konfigurationsparameter 'method = smtp' gesetzt sein. Die folgenden + Parameter dienen dabei der weiteren Konfiguration:

+ hostname +

Name oder IP-Adresse des SMTP-Servers. Standardwert: 'localhost'

+ port +

Portnummer. Der Standardwert hängt von der verwendeten Verschlüsselungsmethode ab. Gilt 'security = + none' oder 'security = tls', so ist 25 die Standardportnummer. Für 'security = + ssl' ist 465 die Portnummer. Muss normalerweise nicht geändert werden.

+ security +

Wahl der zu verwendenden Verschlüsselung der Verbindung mit dem Server. Standardwert ist + 'none', wodurch keine Verschlüsselung verwendet wird. Mit 'tls' wird TLS-Verschlüsselung + eingeschaltet, und mit 'ssl' wird Verschlüsselung via SSL eingeschaltet. Achtung: Für + 'tls' und 'ssl' werden zusätzliche Perl-Module benötigt (siehe unten).

+ login und password +

Falls der E-Mail-Server eine Authentifizierung verlangt, so können mit diesen zwei Parametern der Benutzername + und das Passwort angegeben werden. Wird Authentifizierung verwendet, so sollte aus Sicherheitsgründen auch eine Form von + Verschlüsselung aktiviert werden.

Wird Verschlüsselung über TLS oder SSL aktiviert, so werden zusätzliche Perl-Module benötigt. Diese sind:

  • TLS-Verschlüsselung: Modul Net::SSLGlue (Debian-Paketname + libnet-sslglue-perl, Fedora Core: perl-Net-SSLGlue, openSuSE: + perl-Net-SSLGlue +

  • SSL-Verschlüsselung: Modul Net::SMTP::SSL (Debian-Paketname + libnet-smtp-ssl-perl, Fedora Core: perl-Net-SMTP-SSL, openSuSE: + perl-Net-SMTP-SSL +

Zurück Nach oben Weiter
2.9. Benutzer- und Gruppenverwaltung Zum Anfang 2.11. Drucken mit kivitendo
\ No newline at end of file diff --git a/doc/html/ch02s11.html b/doc/html/ch02s11.html index 94228a0f8..78df092b1 100644 --- a/doc/html/ch02s11.html +++ b/doc/html/ch02s11.html @@ -1,58 +1,101 @@ - 2.11. OpenDocument-Vorlagen
2.11. OpenDocument-Vorlagen
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.11. 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.

Zurück Nach oben Weiter
2.10. Drucken mit kivitendo Zum Anfang 2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: - EUR
\ No newline at end of file + 2.11. Drucken mit kivitendo
2.11. Drucken mit kivitendo
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.11. Drucken mit kivitendo

Das Drucksystem von kivitendo benutzt von Haus aus LaTeX-Vorlagen. Um drucken zu können, braucht der Server ein geeignetes + LaTeX System. Am einfachsten ist dazu eine texlive Installation. Unter Debianoiden Betriebssystemen installiert man + die Pakete mit:

+ 

aptitude install texlive-base-bin texlive-latex-recommended texlive-fonts-recommended \
+  texlive-latex-extra texlive-lang-german texlive-generic-extra

+

TODO: RPM-Pakete.

kivitendo bringt drei alternative Vorlagensätze mit:

  • Standard

  • f-tex

  • RB

2.11.1. Vorlagenverzeichnis anlegen

Im Administrationsbereich lässt sich bei einem Benutzer/Mandanten einer dieser Vorlagensätze als Basis für die zu + druckenden Dokumente auswählen. Rufen Sie dazu die Benutzerverwaltung auf.

Wählen Sie dort einen Benutzer aus oder legen Sie einen neuen an. In der Benutzerbearbeiten-Maske müssen Sie zwei Dinge + angeben:

  1. + Name: Der Verzeichnisname für den neuen Vorlagensatz. Dieser kann im Rahmen der üblichen + Bedingungen für Verzeichnisnamen frei gewählt werden.

  2. + Vorlagen auswählen: Wählen Sie hier den Vorlagensatz aus, der kopiert werden soll + (Standard, f-tex oder RB.)

Der gleiche Vorlagensatz kann, wenn er mal angelegt ist, bei mehreren Benutzern verwendet werden.

Die Abhängigkeiten kann man prüfen mit:

/scripts/installation_check.pl -l

2.11.2. Standard

Der Standard-Vorlagensatz von Kivitendo. Wie unter http://demo.kivitendo.org zu + sehen.

2.11.3. f-tex

Ein Vorlagensatz, der in wenigen Minuten alle Dokumente zur Verfügung stellt.

2.11.3.1. Feature-Übersicht

  • Keine Redundanz. Es wird ein- und dieselbe LaTeX-Vorlage für alle briefartigen Dokumente verwendet. Also + Angebot, Rechnung, Performarechnung, Lieferschein, aber eben nicht für Paketaufkleber etc..

  • Leichte Anpassung an das Firmen-Layout durch verwendung eines Hintergrund-PDF. Dieses kann leicht mit dem + eigenen Lieblingsprogramm erstellt werden (Openoffice, Inkscape, Gimp, Adobe*)

  • Hintergrund-PDF umschaltbar auf "nur erste Seite" (Standard) oder "alle Seiten" (Option + "bgPdfFirstPageOnly" in Datei letter.lco)

  • Hintergrund-PDF für Ausdruck auf bereits bedrucktem Briefpapier abschaltbar. Es wird dann nur bei per E-Mail + versendeten Dokumenten eingebunden (Option "bgPdfEmailOnly" in Datei + letter.lco).

  • Nutzung der Layout-Funktionen von LaTeX für Seitenumbruch, Wiederholung von Kopfzeilen, Zwischensummen + etc. (danke an Kai-Martin Knaak für die Vorarbeit)

  • Anzeige des Empfängerlandes im Adressfeld nur, wenn es vom Land des eigenen Unternehmens abweicht (also die + Rechnung das Land verlässt).

  • Multisprachfähig leicht um weitere Sprachen zu erweitern, alle Übersetzungen in der Datei + translatinos.tex.

  • Auflistung von Bruttopreisen für Endverbraucher.

2.11.3.2. Die Installation

  • Vorlagenverzeichnis mit Option f-tex anlegen, siehe: Vorlagenverzeichnis anlegen. Das + Vorlagensystem funktioniert jetzt schon, hat allerdings noch einen Beispiel-Briefkopf.

  • Erstelle eine pdf-Hintergrund Datei und verlinke sie nach ./letter_head.pdf.

  • Editiere den Bereich "settings" in der datei letter.lco.

oder etwas Detaillierter:

+ Es wird eine Datei sample.lco erstellt und diese nach letter.lco verlinkt. Eigentlich + ist dies die Datei die für die Firmenspezifischen Anpassungen gedacht ist. Da die Einstiegshürde in LaTeX nicht ganz niedrig + ist, wird in dieser Datei auf ein Hintergrundpdf verwiesen. Ich empfehle über dieses PDF die persönlichen Layoutanpassungen + vorzunehmen und sample.lco unverändert zu lassen. Die die Anpassung über eine + *.lco-Datei die letztlich auf letter.lco verlinkt ist ist aber auch möglich. +

+ Es wird eine Datei sample_head.pdf mit ausgeliefert, diese wird nach letter_head.pdf + verlinkt. Damit gibt es schon mal eine Funktionsfähige Vorlage. Schau Dir nach Abschluss der Installation die Datei + sample_haed.pdf an und erstelle ein entsprechendes PDF passend zum Briefkopf Deiner Firma, diese dann im + Template Verzeichniss ablegen und statt sample_head.pdf nach letter_head.pdf + verlinken. +

+ letzlich muss letter_head.pdf auf das passende Hintergrund-PDF verweisen, welches gewünschten Briefkopf + enthält. Bei Updates oder nach erneutem +

+ Es wird eine Datei mydata.tex.example ausgeliefert, die nach mytdata.tex verlinkt + ist. Bei verwendetem Hintergrund-PDF wird nur der Eintrag für das Land verwendet. Die Datei muss also nicht angefasst + werden. Die Anderen Werte sind für das Modul 'lp' (Label Print in erp - zur Zeit nicht im öffentlichen Zweig). +

+ Alle Anpassungen zum Briefkopf, Fusszeilen, Firmenlogos, etc. sollten über die Hintergrund-PDF-Datei oder die + *.lco-Datei erfolgen. +

2.11.3.3. f-tex Funktionsübersicht

+ Das Konzept von kivitendo sieht vor, für jedes Dokument (Auftragsbestätigung, Lieferschein, Rechnung, etc.) eine LaTeX-Vorlage + vorzuhalten, dies ist sehr Wartungsunfreundlich. Auch das Einlesen einer einheitlichen Quelle für den Briefkopf bringt nur + bedingte Vorteile, da hier leicht die Pflege der Artikel-Tabellen aus dem Ruder läuft. Bei dem vorliegenden Ansatz wird für alle + briefartigen Dokumente mit Artikel-Tabellen eine einheitliche LaTeX-Vorlage verwendet, welche über Codeweichen die + Besonderheiten der jeweiligen Dokumente Berücksichtigt. +

  • Tabellen mit oder ohne Preis

  • Sprache der Tabellenüberschriften etc.

  • Anpassung der Bezugs-Zeile (z.B. Rechnungsnummer versus Angebotsnummer)

  • Darstellung von Brutto oder Netto-Preisen in der Auflistung (Endverbraucher versus Gewerblicher + Kunde)

Nachteil:

+ LaTeX hat ohnehin eine sehr steile Lehrnkurve. Die Datei letter.tex ist sehr komplex und verstärkt damit + diesen Effekt noch einmal erheblich. Wer LaTeX-Erfahrung hat, oder geübt ist Scriptsparachen nachzuvollziehen kann natürlich + auch innerhalb der Tabellendarstellung gut persönliche Anpassungen vornehmen. Aber man kann sich hier bei Veränderungen sehr + schnell häftig in den Fuss schiessen. +

Wer nicht so tief in die Materie einsteigen will oder leicht zu frustrieren ist, sollte sein Hintergrund PDF auf Basis der + mitglieferten Datei sample_head.pdf erstellen, und sich an der Form der dargestellten Tabellen wie sie + ausgeliefert werden, erfreuen. +

Kleiner Tipp: Nicht zu viel auf einmal wollen, lieber kleine kontinuierliche Schritte gehen.

2.11.3.4. Bruttopreise für Endverbraucher

Der auszuweisende Bruttopreis wird innerhalb der LaTeX-Umgebung berechnet. Es gibt zwar ein Feld, um bei Aufträgen "alle + Preise Brutto" auszuwählen, aber:

  • hierfür müssen die Preise auch in Brutto in der Datenbank stehen (ja - das lässt sich über die Preisgruppen und die + Zuordung einer Default-Preisgruppe handhaben)

  • man darf beim Anlegen des Vorgangs nicht vergessen Dieses Häkchen zu setzen. (das ist in der Praxis wenn man sowohl + Endverbraucher- wie Gewerbekunden beliefert der eigentliche Knackpunkt)

+ Es gibt mit f-tex eine weitere Alternative. Die Information ob Brutto oder Nettorechnung wird mit den Zahlarten + verknüpft. Zahlarten bei denen Rechnungen, Angebote, etc, in Brutto ausgegeben werden sollen, enden mit "_E" (für + Endverbraucher). Falls identische Zahlarten für Gewerbekunden und Endverbraucher vorhanden sind, legt man diese einfach doppelt + an (einmal mit der Namensendung "_E"). Gewinn:

  • Die Entscheidung, ob Netopreise ausgewiesen werden, ist nicht mehr fix mit einer Preisliste Verbunden.

  • Die Default-Zahlart kann im Kundendatensatz hinterlegt werden, und man muss nicht mehr daran denken, "alle Preise + Netto" auszuwählen.

  • Die Entscheidung, ob Netto- oder Bruttopreise ausgewiesen werden, kann direkt beim Drucken reviediert werden, + ohne dass sich der Auftragswert ändert.

2.11.3.5. Lieferadressen

In Lieferscheinen kommen shipto*-Variablen im Adressfeld zum Einsatz. Wenn die + shipto*-Variable leer ist, wird die entsprechende Adressvariable eingesetzt. Wenn also die Lieferadresse in + Straße, Hausnummer und Ort abweicht, müssen auch nur diese Felder in der Lieferadresse ausgefüllt werden. Für den Firmenname wird + der Wert der Hauptadresse angezeigt. +

2.11.4. RB

Vollständiger Dokumentensatz mit alternativem Design

2.11.5. Allgemeine Hinweise zu LaTeX Vorlagen

In den allermeisten Installationen sollte drucken jetzt schon + funktionieren. Sollte ein Fehler auftreten wirft TeX sehr lange + Fehlerbeschreibungen, der eigentliche Fehler ist immer die erste Zeite + die mit einem Ausrufezeichen anfängt. Häufig auftretende Fehler sind zum + Beispiel:

  • ! LaTeX Error: File `eurosym.sty' not found. Die entsprechende + LaTeX-Bibliothek wurde nicht gefunden. Das tritt vor allem bei + Vorlagen aus der Community auf. Installieren Sie die entsprechenden + Pakete.

  • ! Package inputenc Error: Unicode char \u8:... set up for + use with LaTeX. Dieser Fehler tritt auf, wenn sie versuchen mit + einer Standardinstallation exotische utf8 Zeichen zu drucken. + TeXLive unterstützt von Haus nur romanische Schriften und muss mit + diversen Tricks dazu gebracht werden andere Zeichen zu akzeptieren. + Adere TeX Systeme wie XeTeX schaffen hier Abhilfe.

Wird garkein Fehler angezeigt sondern nur der Name des Templates, + heißt das normalerweise, dass das LaTeX Binary nicht gefunden wurde. + Prüfen Sie den Namen in der Konfiguration (Standard: + pdflatex), und stellen Sie sicher, dass pdflatex + (oder das von Ihnen verwendete System) vom Webserver ausgeführt werden + darf.

Wenn sich das Problem nicht auf Grund der ausgabe im Webbrowser verifizieren lässt:

  • editiere [kivitendo-home]/config/kivitendo.conf und ändere "keep_tmp_files" auf 1

    + 

    keep_temp_files = 1;

    +

  • bei fastcgi oder mod_perl den Webserver neu Starten

  • Nochmal einen Druckversuch im Webfrontend auslösen

  • wechsele in das users Verzeichnis von kivitendo

    + 

    cd [kivitendo-home]/users

    +

  • LaTeX Suchpfad anpassen:

    + 

    export TEXINPUTS=".:[kivitendo-home]/templates/[aktuelles_template_verzeichniss]:"

    +

  • Finde herraus welche Datei kivitendo beim letzten Durchlauf erstellt hat

    + 

    ls -lahtr ./1*.tex

    +

    Es sollte die letzte Datei ganz unten sein

  • für besseren Hinweis auf Fehler texdatei nochmals übersetzen

    + 

    pdflatex ./1*.tex

    +

    in der *.tex datei nach dem Fehler suchen.

Zurück Nach oben Weiter
2.10. E-Mail-Versand aus kivitendo heraus Zum Anfang 2.12. OpenDocument-Vorlagen
\ No newline at end of file diff --git a/doc/html/ch02s12.html b/doc/html/ch02s12.html index a78ea4aa7..ab27592cf 100644 --- a/doc/html/ch02s12.html +++ b/doc/html/ch02s12.html @@ -1,65 +1,58 @@ - 2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR
2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: - EUR
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

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/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.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.

Zurück Nach oben Weiter
2.11. OpenDocument-Vorlagen Zum Anfang 2.13. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
\ No newline at end of file + 2.12. OpenDocument-Vorlagen
2.12. OpenDocument-Vorlagen
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

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.

Zurück Nach oben Weiter
2.11. Drucken mit kivitendo Zum Anfang 2.13. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: + EUR
\ No newline at end of file diff --git a/doc/html/ch02s13.html b/doc/html/ch02s13.html index dda1d399d..3b6141deb 100644 --- a/doc/html/ch02s13.html +++ b/doc/html/ch02s13.html @@ -1,36 +1,65 @@ - 2.13. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.13. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.13. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb

2.13.1. Einführung

Die Umsatzsteuerumstellung auf 19% für SKR04 für die - Steuerschlüssel "EU ohne USt-ID Nummer" ist erst 2010 erfolgt. - kivitendo beinhaltet ein Upgradeskript, das das Konto 3804 automatisch - erstellt und die Steuereinstellungen korrekt einstellt. Hat der - Benutzer aber schon selber das Konto 3804 angelegt, oder gab es schon - Buchungen im Zeitraum nach dem 01.01.2007 auf das Konto 3803, wird das - Upgradeskript vorsichtshalber nicht ausgeführt, da der Benutzer sich - vielleicht schon selbst geholfen hat und mit seinen Änderungen - zufrieden ist. Die korrekten Einstellungen kann man aber auch per Hand - ausführen. Nachfolgend werden die entsprechenden Schritte anhand von - Screenshots dargestellt.

Für den Fall, daß Buchungen mit der Steuerschlüssel "EU ohne - USt.-IdNr." nach dem 01.01.2007 erfolgt sind, ist davon auszugehen, - dass diese mit dem alten Umsatzsteuersatz von 16% gebucht worden sind, - und diese Buchungen sollten entsprechend kontrolliert werden.

2.13.2. Konto 3804 manuell anlegen

Die folgenden Schritte sind notwendig, um das Konto manuell - anzulegen und zu konfigurieren. Zuerst wird in - System -> - Kontenübersicht -> Konto - erfassen das Konto angelegt.

- Als Zweites muss Steuergruppe 13 für Konto 3803 angepasst werden. Dazu unter System -> - Steuern -> Bearbeiten den Eintrag mit Steuerschlüssel 13 auswählen und ihn - wie im folgenden Screenshot angezeigt anpassen. -

- Als Drittes wird ein neuer Eintrag mit Steuerschlüssel 13 für Konto 3804 (19%) angelegt. Dazu unter System -> - Steuern -> Erfassen auswählen und die Werte aus dem Screenshot übernehmen. -

- Als Nächstes sind alle Konten anzupassen, die als Steuerautomatikkonto die 3803 haben, sodass sie ab dem 1.1.2007 auch - Steuerautomatik auf 3804 bekommen. Dies betrifft in der Standardkonfiguration die Konten 4315 und 4726. Als Beispiel für 4315 - müssen Sie dazu unter System -> Kontenübersicht -> Konten - anzeigen das Konto 4315 anklicken und die Einstellungen wie im Screenshot gezeigt vornehmen. -

- Als Letztes sollte die Steuerliste unter System -> Steuern -> - Bearbeiten kontrolliert werden. Zum Vergleich der Screenshot. -

Zurück Nach oben Weiter
2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: - EUR Zum Anfang 2.14. Einstellungen pro Mandant
\ No newline at end of file + 2.13. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR
2.13. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: + EUR
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

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.

Zurück Nach oben Weiter
2.12. OpenDocument-Vorlagen Zum Anfang 2.14. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
\ No newline at end of file diff --git a/doc/html/ch02s14.html b/doc/html/ch02s14.html index cfcfe9111..4b29a6f11 100644 --- a/doc/html/ch02s14.html +++ b/doc/html/ch02s14.html @@ -1,20 +1,36 @@ - 2.14. Einstellungen pro Mandant
2.14. Einstellungen pro Mandant
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.14. Einstellungen pro Mandant

Einige Einstellungen können von einem Benutzer mit dem - Recht "Administration - (Für die Verwaltung der aktuellen Instanz aus einem Userlogin heraus)" - gemacht werden. Diese Einstellungen sind dann für die aktuellen - Mandanten-Datenbank gültig. Die Einstellungen sind - unter System - -> Mandantenkonfiguration erreichbar.

Bitte beachten Sie die Hinweise zu den einzelnen - Einstellungen. Einige Einstellungen sollten nicht ohne Weiteres - im laufenden Betrieb geändert werden (siehe - auch Bemerkungen zu - Bestandsmethode).

Die Einstellungen show_bestbefore - und payments_changeable aus dem - Abschnitt features und die Einstellungen im - Abschnitt datev_check (sofern schon vorhanden) - der kivitendo-Konfigurationsdatei - werden bei einem Datenbankupdate einer älteren Version automatisch - übernommen. Diese Einträge können danach aus der Konfigurationsdatei - entfernt werden.

Zurück Nach oben Weiter
2.13. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb Zum Anfang 2.15. kivitendo ERP verwenden
\ No newline at end of file + 2.14. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.14. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.14. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb

2.14.1. Einführung

Die Umsatzsteuerumstellung auf 19% für SKR04 für die + Steuerschlüssel "EU ohne USt-ID Nummer" ist erst 2010 erfolgt. + kivitendo beinhaltet ein Upgradeskript, das das Konto 3804 automatisch + erstellt und die Steuereinstellungen korrekt einstellt. Hat der + Benutzer aber schon selber das Konto 3804 angelegt, oder gab es schon + Buchungen im Zeitraum nach dem 01.01.2007 auf das Konto 3803, wird das + Upgradeskript vorsichtshalber nicht ausgeführt, da der Benutzer sich + vielleicht schon selbst geholfen hat und mit seinen Änderungen + zufrieden ist. Die korrekten Einstellungen kann man aber auch per Hand + ausführen. Nachfolgend werden die entsprechenden Schritte anhand von + Screenshots dargestellt.

Für den Fall, daß Buchungen mit der Steuerschlüssel "EU ohne + USt.-IdNr." nach dem 01.01.2007 erfolgt sind, ist davon auszugehen, + dass diese mit dem alten Umsatzsteuersatz von 16% gebucht worden sind, + und diese Buchungen sollten entsprechend kontrolliert werden.

2.14.2. Konto 3804 manuell anlegen

Die folgenden Schritte sind notwendig, um das Konto manuell + anzulegen und zu konfigurieren. Zuerst wird in + System -> + Kontenübersicht -> Konto + erfassen das Konto angelegt.

+ Als Zweites muss Steuergruppe 13 für Konto 3803 angepasst werden. Dazu unter System -> + Steuern -> Bearbeiten den Eintrag mit Steuerschlüssel 13 auswählen und ihn + wie im folgenden Screenshot angezeigt anpassen. +

+ Als Drittes wird ein neuer Eintrag mit Steuerschlüssel 13 für Konto 3804 (19%) angelegt. Dazu unter System -> + Steuern -> Erfassen auswählen und die Werte aus dem Screenshot übernehmen. +

+ Als Nächstes sind alle Konten anzupassen, die als Steuerautomatikkonto die 3803 haben, sodass sie ab dem 1.1.2007 auch + Steuerautomatik auf 3804 bekommen. Dies betrifft in der Standardkonfiguration die Konten 4315 und 4726. Als Beispiel für 4315 + müssen Sie dazu unter System -> Kontenübersicht -> Konten + anzeigen das Konto 4315 anklicken und die Einstellungen wie im Screenshot gezeigt vornehmen. +

+ Als Letztes sollte die Steuerliste unter System -> Steuern -> + Bearbeiten kontrolliert werden. Zum Vergleich der Screenshot. +

Zurück Nach oben Weiter
2.13. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: + EUR Zum Anfang 2.15. Einstellungen pro Mandant
\ No newline at end of file diff --git a/doc/html/ch02s15.html b/doc/html/ch02s15.html index bc16a0722..c5be10066 100644 --- a/doc/html/ch02s15.html +++ b/doc/html/ch02s15.html @@ -1,8 +1,20 @@ - 2.15. kivitendo ERP verwenden
2.15. kivitendo ERP verwenden
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.15. kivitendo ERP verwenden

Nach erfolgreicher Installation ist der Loginbildschirm unter - folgender URL erreichbar:

- http://localhost/kivitendo-erp/login.pl -

Die Administrationsseite erreichen Sie unter:

- http://localhost/kivitendo-erp/admin.pl -

Zurück Nach oben Weiter
2.14. Einstellungen pro Mandant Zum Anfang Kapitel 3. Features und Funktionen
\ No newline at end of file + 2.15. Einstellungen pro Mandant
2.15. Einstellungen pro Mandant
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.15. Einstellungen pro Mandant

Einige Einstellungen können von einem Benutzer mit dem + Recht "Administration + (Für die Verwaltung der aktuellen Instanz aus einem Userlogin heraus)" + gemacht werden. Diese Einstellungen sind dann für die aktuellen + Mandanten-Datenbank gültig. Die Einstellungen sind + unter System + -> Mandantenkonfiguration erreichbar.

Bitte beachten Sie die Hinweise zu den einzelnen + Einstellungen. Einige Einstellungen sollten nicht ohne Weiteres + im laufenden Betrieb geändert werden (siehe + auch Bemerkungen zu + Bestandsmethode).

Die Einstellungen show_bestbefore + und payments_changeable aus dem + Abschnitt features und die Einstellungen im + Abschnitt datev_check (sofern schon vorhanden) + der kivitendo-Konfigurationsdatei + werden bei einem Datenbankupdate einer älteren Version automatisch + übernommen. Diese Einträge können danach aus der Konfigurationsdatei + entfernt werden.

Zurück Nach oben Weiter
2.14. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb Zum Anfang 2.16. kivitendo ERP verwenden
\ No newline at end of file diff --git a/doc/html/ch02s16.html b/doc/html/ch02s16.html new file mode 100644 index 000000000..15b71bba1 --- /dev/null +++ b/doc/html/ch02s16.html @@ -0,0 +1,8 @@ + + + 2.16. kivitendo ERP verwenden
2.16. kivitendo ERP verwenden
Zurück Kapitel 2. Installation und Grundkonfiguration Weiter

2.16. kivitendo ERP verwenden

Nach erfolgreicher Installation ist der Loginbildschirm unter + folgender URL erreichbar:

+ http://localhost/kivitendo-erp/login.pl +

Die Administrationsseite erreichen Sie unter:

+ http://localhost/kivitendo-erp/admin.pl +

Zurück Nach oben Weiter
2.15. Einstellungen pro Mandant Zum Anfang Kapitel 3. Features und Funktionen
\ No newline at end of file diff --git a/doc/html/ch03.html b/doc/html/ch03.html index 94be1a2f6..0d33263b7 100644 --- a/doc/html/ch03.html +++ b/doc/html/ch03.html @@ -1,6 +1,6 @@ - Kapitel 3. Features und Funktionen
Kapitel 3. Features und Funktionen
Zurück   Weiter

Kapitel 3. Features und Funktionen

3.1. Wiederkehrende Rechnungen

3.1.1. Einführung

Wiederkehrende Rechnungen werden als normale Aufträge definiert + Kapitel 3. Features und Funktionen

Kapitel 3. Features und Funktionen
Zurück   Weiter

Kapitel 3. Features und Funktionen

3.1. Wiederkehrende Rechnungen

3.1.1. Einführung

Wiederkehrende Rechnungen werden als normale Aufträge definiert und konfiguriert, mit allen dazugehörigen Kunden- und Artikelangaben. Die konfigurierten Aufträge werden später automatisch in Rechnungen umgewandelt, so als ob man den Workflow benutzen würde, und auch die @@ -35,7 +35,7 @@ automatisch nach hinten geschoben wird.

Drucken

Sind Drucker konfiguriert, so kann man sich die erstellten Rechnungen auch gleich ausdrucken lassen.

Nach Erstellung der Rechnungen kann eine E-Mail mit Informationen zu den erstellten Rechnungen verschickt werden. - Konfiguriert wird dies in der Konfigurationsdatei + Konfiguriert wird dies in der Konfigurationsdatei config/kivitendo.conf im Abschnitt [periodic_invoices].

3.1.3. Auflisten

Unter Verkauf->Berichte->Aufträge finden sich zwei neue @@ -43,7 +43,7 @@ Rechnungen inaktiv", mit denen man sich einen Überglick über die wiederkehrenden Rechnungen verschaffen kann.

3.1.4. Erzeugung der eigentlichen Rechnungen

Die zeitliche und periodische Überprüfung, ob eine wiederkehrende Rechnung automatisch erstellt werden soll, geschieht - durch den Taskserver, einen + durch den Taskserver, einen externen Dienst, der automatisch beim Start des Servers gestartet werden sollte.

3.1.5. Erste Rechnung für aktuellen Monat erstellen

Will man im laufenden Monat eine monatlich wiederkehrende Rechnung inkl. des laufenden Monats starten, stellt man das Startdatum @@ -51,4 +51,4 @@ den neu konfigurieren Auftrag erkennt und daraus eine Rechnung generiert hat. Alternativ setzt man das Startdatum auf den Monatsersten des Folgemonats und erstellt die erste Rechnung direkt - manuell über den Workflow.

Zurück   Weiter
2.15. kivitendo ERP verwenden Zum Anfang 3.2. Dokumentenvorlagen und verfügbare Variablen
\ No newline at end of file + manuell über den Workflow.

Zurück   Weiter
2.16. kivitendo ERP verwenden Zum Anfang 3.2. Dokumentenvorlagen und verfügbare Variablen
\ No newline at end of file diff --git a/doc/html/ch03s02.html b/doc/html/ch03s02.html index e8b2f81d1..488f30be2 100644 --- a/doc/html/ch03s02.html +++ b/doc/html/ch03s02.html @@ -556,7 +556,7 @@ invdate

Rechnungsdatum

invnumber -

Rechnungsnummer

3.2.10. Variablen in anderen Vorlagen

3.2.10.1. Einführung

Die Variablen in anderen Vorlagen sind ähnlich wie in der +

Rechnungsnummer

3.2.10. Variablen in anderen Vorlagen

3.2.10.1. Einführung

Die Variablen in anderen Vorlagen sind ähnlich wie in der Rechnung. Allerdings heißen die Variablen, die mit inv beginnen, jetzt anders. Bei den Angeboten fangen sie mit quo für "quotation" an: diff --git a/doc/html/ch04.html b/doc/html/ch04.html index 6f4616f0d..999c63ec5 100644 --- a/doc/html/ch04.html +++ b/doc/html/ch04.html @@ -1,6 +1,6 @@ - Kapitel 4. Entwicklerdokumentation

Kapitel 4. Entwicklerdokumentation
Zurück   Weiter

Kapitel 4. Entwicklerdokumentation

4.1. Globale Variablen

4.1.1. Wie sehen globale Variablen in Perl aus?

Globale Variablen liegen in einem speziellen namespace namens + Kapitel 4. Entwicklerdokumentation

Kapitel 4. Entwicklerdokumentation
Zurück   Weiter

Kapitel 4. Entwicklerdokumentation

4.1. Globale Variablen

4.1.1. Wie sehen globale Variablen in Perl aus?

Globale Variablen liegen in einem speziellen namespace namens "main", der von überall erreichbar ist. Darüber hinaus sind bareword globs global und die meisten speziellen Variablen sind... speziell.

Daraus ergeben sich folgende Formen:

@@ -25,7 +25,7 @@ $PACKAGE::form.

local $form

Alle Änderungen an $form werden am Ende - des scopes zurückgesetzt

4.1.2. Warum sind globale Variablen ein Problem?

Das erste Problem ist FCGI™.

+ des scopes zurückgesetzt

4.1.2. Warum sind globale Variablen ein Problem?

Das erste Problem ist FCGI™.

SQL-Ledger™ hat fast alles im globalen namespace abgelegt, und erwartet, dass es da auch wiederzufinden ist. Unter FCGI™ müssen diese Sachen aber wieder @@ -39,7 +39,7 @@ dies hat, seit der Einführung, u.a. schon so manche langwierige Bug-Suche verkürzt. Da globale Variablen aber implizit mit Package angegeben werden, werden die nicht geprüft, und somit kann sich - schnell ein Tippfehler einschleichen.

4.1.3. Kanonische globale Variablen

Um dieses Problem im Griff zu halten gibt es einige wenige + schnell ein Tippfehler einschleichen.

4.1.3. Kanonische globale Variablen

Um dieses Problem im Griff zu halten gibt es einige wenige globale Variablen, die kanonisch sind, d.h. sie haben bestimmte vorgegebenen Eigenschaften, und alles andere sollte anderweitig umhergereicht werden.

Diese Variablen sind im Moment die folgenden neun:

  • @@ -62,7 +62,7 @@ $::request

Damit diese nicht erneut als Müllhalde missbraucht werden, im Folgenden eine kurze Erläuterung der bestimmten vorgegebenen - Eigenschaften (Konventionen):

4.1.3.1. $::form

  • Ist ein Objekt der Klasse + Eigenschaften (Konventionen):

    4.1.3.1. $::form

    • Ist ein Objekt der Klasse "Form"

    • Wird nach jedem Request gelöscht

    • Muss auch in Tests und Konsolenscripts vorhanden sein.

    • Enthält am Anfang eines Requests die Requestparameter vom User

    • Kann zwar intern über Requestgrenzen ein Datenbankhandle @@ -110,7 +110,7 @@ push @{ $form->{TEMPLATE_ARRAYS}{number} }, $form->{"partnumber_$i"}; push @{ $form->{TEMPLATE_ARRAYS}{description} }, $form->{"description_$i"}; # ... -}

    4.1.3.2. %::myconfig

    • Das einzige Hash unter den globalen Variablen

    • Wird spätestens benötigt wenn auf die Datenbank +}

    4.1.3.2. %::myconfig

    • Das einzige Hash unter den globalen Variablen

    • Wird spätestens benötigt wenn auf die Datenbank zugegriffen wird

    • Wird bei jedem Request neu erstellt.

    • Enthält die Userdaten des aktuellen Logins

    • Sollte nicht ohne Filterung irgendwo gedumpt werden oder extern serialisiert werden, weil da auch der Datenbankzugriff für diesen user drinsteht.

    • Enthält unter anderem Listenbegrenzung vclimit, @@ -122,10 +122,10 @@ überwiegend die Daten, die sich unter Programm -> Einstellungen befinden, bzw. die Informationen über den Benutzer die über die - Administrator-Schnittstelle (admin.pl) eingegeben wurden.

    4.1.3.3. $::locale

    • Objekt der Klasse "Locale"

    • Wird pro Request erstellt

    • Muss auch für Tests und Scripte immer verfügbar + Administrator-Schnittstelle (admin.pl) eingegeben wurden.

    4.1.3.3. $::locale

    • Objekt der Klasse "Locale"

    • Wird pro Request erstellt

    • Muss auch für Tests und Scripte immer verfügbar sein.

    • Cached intern über Requestgrenzen hinweg benutzte Locales

    Lokalisierung für den aktuellen User. Alle Übersetzungen, - Zahlen- und Datumsformatierungen laufen über dieses Objekt.

    4.1.3.4. $::lxdebug

    • Objekt der Klasse "LXDebug"

    • Wird global gecached

    • Muss immer verfügbar sein, in nahezu allen + Zahlen- und Datumsformatierungen laufen über dieses Objekt.

    4.1.3.4. $::lxdebug

    • Objekt der Klasse "LXDebug"

    • Wird global gecached

    • Muss immer verfügbar sein, in nahezu allen Funktionen

    $::lxdebug stellt Debuggingfunktionen bereit, wie "enter_sub" und @@ -135,12 +135,12 @@ "message" und "dump" mit denen man flott Informationen ins Log (tmp/kivitendo-debug.log) packen kann.

    Beispielsweise so:

    $main::lxdebug->message(0, 'Meine Konfig:' . Dumper (%::myconfig));
-$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});

    4.1.3.5. $::auth

    • Objekt der Klasse "SL::Auth"

    • Wird global gecached

    • Hat eine permanente DB Verbindung zur Authdatenbank

    • Wird nach jedem Request resettet.

    +$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});

    4.1.3.5. $::auth

    • Objekt der Klasse "SL::Auth"

    • Wird global gecached

    • Hat eine permanente DB Verbindung zur Authdatenbank

    • Wird nach jedem Request resettet.

    $::auth stellt Funktionen bereit um die Rechte des aktuellen Users abzufragen. Obwohl diese Informationen vom aktuellen User abhängen wird das Objekt aus Geschwindigkeitsgründen nur einmal angelegt und dann nach jedem - Request kurz resettet.

    4.1.3.6. $::lx_office_conf

    • Objekt der Klasse + Request kurz resettet.

    4.1.3.6. $::lx_office_conf

    • Objekt der Klasse "SL::LxOfficeConf"

    • Global gecached

    • Repräsentation der config/kivitendo.conf[.default]-Dateien

    Globale Konfiguration. Configdateien werden zum Start gelesen und danach nicht mehr angefasst. Es ist derzeit nicht geplant, dass @@ -150,16 +150,16 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{ file = /tmp/kivitendo-debug.log

    ist der Key file im Programm als $::lx_office_conf->{debug}{file} erreichbar.

    [Warnung]Warnung

    Zugriff auf die Konfiguration erfolgt im Moment über - Hashkeys, sind also nicht gegen Tippfehler abgesichert.

    4.1.3.7. $::instance_conf

    • Objekt der Klasse + Hashkeys, sind also nicht gegen Tippfehler abgesichert.

    4.1.3.7. $::instance_conf

    • Objekt der Klasse "SL::InstanceConfiguration"

    • wird pro Request neu erstellt

    Funktioniert wie $::lx_office_conf, speichert aber Daten die von der Instanz abhängig sind. Eine Instanz ist hier eine Mandantendatenbank. Beispielsweise überprüft 

    $::instance_conf->get_inventory_system eq 'perpetual'

    - ob die berüchtigte Bestandsmethode zur Anwendung kommt.

    4.1.3.8. $::dispatcher

    • Objekt der Klasse + ob die berüchtigte Bestandsmethode zur Anwendung kommt.

    4.1.3.8. $::dispatcher

    • Objekt der Klasse "SL::Dispatcher"

    • wird pro Serverprozess erstellt.

    • enthält Informationen über die technische Verbindung zum Server

    Der dritte Punkt ist auch der einzige Grund warum das Objekt global gespeichert wird. Wird vermutlich irgendwann in einem anderen - Objekt untergebracht.

    4.1.3.9. $::request

    • Hashref (evtl später Objekt)

    • Wird pro Request neu initialisiert.

    • Keine Unterstruktur garantiert.

    + Objekt untergebracht.

    4.1.3.9. $::request

    • Hashref (evtl später Objekt)

    • Wird pro Request neu initialisiert.

    • Keine Unterstruktur garantiert.

    $::request ist ein generischer Platz um Daten "für den aktuellen Request" abzulegen. Sollte nicht für action at a distance benutzt werden, sondern um lokales memoizing zu @@ -172,20 +172,20 @@ file = /tmp/kivitendo-debug.log

    ist der Key file$::request

  • Muss ich von anderen Teilen des Programms lesend drauf zugreifen? Dann $::request, aber Zugriff über - Wrappermethode

4.1.4. Ehemalige globale Variablen

Die folgenden Variablen waren einmal im Programm, und wurden - entfernt.

4.1.4.1. $::cgi

  • war nötig, weil cookie Methoden nicht als + Wrappermethode

4.1.4. Ehemalige globale Variablen

Die folgenden Variablen waren einmal im Programm, und wurden + entfernt.

4.1.4.1. $::cgi

  • war nötig, weil cookie Methoden nicht als Klassenfunktionen funktionieren

  • Aufruf als Klasse erzeugt Dummyobjekt was im Klassennamespace gehalten wird und über Requestgrenzen leaked

  • liegt jetzt unter $::request->{cgi} -

4.1.4.2. $::all_units

  • war nötig, weil einige Funktionen in Schleifen zum Teil +

4.1.4.2. $::all_units

  • war nötig, weil einige Funktionen in Schleifen zum Teil ein paar hundert mal pro Request eine Liste der Einheiten brauchen, und de als Parameter durch einen Riesenstack von Funktionen geschleift werden müssten.

  • Liegt jetzt unter $::request->{cache}{all_units}

  • Wird nur in AM->retrieve_all_units() gesetzt oder - gelesen.

4.1.4.3. %::called_subs

  • wurde benutzt um callsub deep recursions + gelesen.

4.1.4.3. %::called_subs

  • wurde benutzt um callsub deep recursions abzufangen.

  • Wurde entfernt, weil callsub nur einen Bruchteil der möglichen Rekursioenen darstellt, und da nie welche auftreten.

  • komplette recursion protection wurde entfernt.

Zurück   Weiter
3.3. Excel-Vorlagen Zum Anfang 4.2. Entwicklung unter FastCGI
\ No newline at end of file diff --git a/doc/html/index.html b/doc/html/index.html index 9b8060127..96717ff56 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -1,9 +1,9 @@ - kivitendo: Installation, Konfiguration, Entwicklung
kivitendo: Installation, Konfiguration, Entwicklung
   Weiter

kivitendo: Installation, Konfiguration, Entwicklung

Inhaltsverzeichnis

1. Aktuelle Hinweise
2. Installation und Grundkonfiguration
2.1. Benötigte Software und Pakete
2.1.1. Betriebssystem
2.1.2. Pakete
2.2. Manuelle Installation des Programmpaketes
2.3. kivitendo-Konfigurationsdatei
2.3.1. Einführung
2.3.2. Abschnitte und Parameter
2.3.3. Versionen vor 2.6.3
2.4. Anpassung der PostgreSQL-Konfiguration
2.4.1. Zeichensätze/die Verwendung von UTF-8
2.4.2. Änderungen an Konfigurationsdateien
2.4.3. Erweiterung für servergespeicherte Prozeduren
2.4.4. Datenbankbenutzer anlegen
2.5. Webserver-Konfiguration
2.5.1. Grundkonfiguration mittels CGI
2.5.2. Konfiguration für FastCGI/FCGI
2.6. Der Task-Server
2.6.1. Verfügbare und notwendige Konfigurationsoptionen
2.6.2. Automatisches Starten des Task-Servers beim Booten
2.6.3. Wie der Task-Server gestartet und beendet wird
2.6.4. Task-Server mit mehreren Mandanten
2.7. Benutzerauthentifizierung und Administratorpasswort
2.7.1. Grundlagen zur Benutzerauthentifizierung
2.7.2. Administratorpasswort
2.7.3. Authentifizierungsdatenbank
2.7.4. Passwortüberprüfung
2.7.5. Name des Session-Cookies
2.7.6. Anlegen der Authentifizierungsdatenbank
2.8. Benutzer- und Gruppenverwaltung
2.8.1. Zusammenhänge
2.8.2. Datenbanken anlegen
2.8.3. Gruppen anlegen
2.8.4. Benutzer anlegen
2.8.5. Gruppenmitgliedschaften verwalten
2.8.6. Migration alter Installationen
2.9. E-Mail-Versand aus kivitendo heraus
2.9.1. Versand über lokalen E-Mail-Server
2.9.2. Versand über einen SMTP-Server
2.10. Drucken mit kivitendo
2.10.1. Vorlagenverzeichnis anlegen
2.10.2. Standard
2.10.3. f-tex
2.10.4. RB
2.10.5. Allgemeine Hinweise zu LaTeX Vorlagen
2.11. OpenDocument-Vorlagen
2.12. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: - EUR
2.12.1. Einführung
2.12.2. Konfigurationsparameter
2.12.3. Festlegen der Parameter
2.12.4. Bemerkungen zu Bestandsmethode
2.12.5. Bekannte Probleme
2.13. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.13.1. Einführung
2.13.2. Konto 3804 manuell anlegen
2.14. Einstellungen pro Mandant
2.15. kivitendo ERP verwenden
3. Features und Funktionen
3.1. Wiederkehrende Rechnungen
3.1.1. Einführung
3.1.2. Konfiguration
3.1.3. Auflisten
3.1.4. Erzeugung der eigentlichen Rechnungen
3.1.5. Erste Rechnung für aktuellen Monat erstellen
3.2. Dokumentenvorlagen und verfügbare Variablen
3.2.1. Einführung
3.2.2. Variablen ausgeben
3.2.3. Verwendung in Druckbefehlen
3.2.4. Anfang und Ende der Tags verändern
3.2.5. Zuordnung von den Dateinamen zu den Funktionen
3.2.6. Sprache, Drucker und E-Mail
3.2.7. Allgemeine Variablen, die in allen Vorlagen vorhanden + kivitendo: Installation, Konfiguration, Entwicklung
kivitendo: Installation, Konfiguration, Entwicklung
   Weiter

kivitendo: Installation, Konfiguration, Entwicklung

Inhaltsverzeichnis

1. Aktuelle Hinweise
2. Installation und Grundkonfiguration
2.1. Übersicht
2.2. Benötigte Software und Pakete
2.2.1. Betriebssystem
2.2.2. Pakete
2.3. Manuelle Installation des Programmpaketes
2.4. kivitendo-Konfigurationsdatei
2.4.1. Einführung
2.4.2. Abschnitte und Parameter
2.4.3. Versionen vor 2.6.3
2.5. Anpassung der PostgreSQL-Konfiguration
2.5.1. Zeichensätze/die Verwendung von UTF-8
2.5.2. Änderungen an Konfigurationsdateien
2.5.3. Erweiterung für servergespeicherte Prozeduren
2.5.4. Datenbankbenutzer anlegen
2.6. Webserver-Konfiguration
2.6.1. Grundkonfiguration mittels CGI
2.6.2. Konfiguration für FastCGI/FCGI
2.7. Der Task-Server
2.7.1. Verfügbare und notwendige Konfigurationsoptionen
2.7.2. Automatisches Starten des Task-Servers beim Booten
2.7.3. Wie der Task-Server gestartet und beendet wird
2.7.4. Task-Server mit mehreren Mandanten
2.8. Benutzerauthentifizierung und Administratorpasswort
2.8.1. Grundlagen zur Benutzerauthentifizierung
2.8.2. Administratorpasswort
2.8.3. Authentifizierungsdatenbank
2.8.4. Passwortüberprüfung
2.8.5. Name des Session-Cookies
2.8.6. Anlegen der Authentifizierungsdatenbank
2.9. Benutzer- und Gruppenverwaltung
2.9.1. Zusammenhänge
2.9.2. Datenbanken anlegen
2.9.3. Gruppen anlegen
2.9.4. Benutzer anlegen
2.9.5. Gruppenmitgliedschaften verwalten
2.9.6. Migration alter Installationen
2.10. E-Mail-Versand aus kivitendo heraus
2.10.1. Versand über lokalen E-Mail-Server
2.10.2. Versand über einen SMTP-Server
2.11. Drucken mit kivitendo
2.11.1. Vorlagenverzeichnis anlegen
2.11.2. Standard
2.11.3. f-tex
2.11.4. RB
2.11.5. Allgemeine Hinweise zu LaTeX Vorlagen
2.12. OpenDocument-Vorlagen
2.13. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: + EUR
2.13.1. Einführung
2.13.2. Konfigurationsparameter
2.13.3. Festlegen der Parameter
2.13.4. Bemerkungen zu Bestandsmethode
2.13.5. Bekannte Probleme
2.14. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.14.1. Einführung
2.14.2. Konto 3804 manuell anlegen
2.15. Einstellungen pro Mandant
2.16. kivitendo ERP verwenden
3. Features und Funktionen
3.1. Wiederkehrende Rechnungen
3.1.1. Einführung
3.1.2. Konfiguration
3.1.3. Auflisten
3.1.4. Erzeugung der eigentlichen Rechnungen
3.1.5. Erste Rechnung für aktuellen Monat erstellen
3.2. Dokumentenvorlagen und verfügbare Variablen
3.2.1. Einführung
3.2.2. Variablen ausgeben
3.2.3. Verwendung in Druckbefehlen
3.2.4. Anfang und Ende der Tags verändern
3.2.5. Zuordnung von den Dateinamen zu den Funktionen
3.2.6. Sprache, Drucker und E-Mail
3.2.7. Allgemeine Variablen, die in allen Vorlagen vorhanden sind
3.2.8. Variablen in Rechnungen
3.2.9. Variablen in Mahnungen und Rechnungen über Mahngebühren
3.2.10. Variablen in anderen Vorlagen
3.2.11. Blöcke, bedingte Anweisungen und Schleifen
3.2.12. Markup-Code zur Textformatierung innerhalb von - Formularen
3.3. Excel-Vorlagen
3.3.1. Zusammenfassung
3.3.2. Bedienung
3.3.3. Variablensyntax
3.3.4. Einschränkungen
4. Entwicklerdokumentation
4.1. Globale Variablen
4.1.1. Wie sehen globale Variablen in Perl aus?
4.1.2. Warum sind globale Variablen ein Problem?
4.1.3. Kanonische globale Variablen
4.1.4. Ehemalige globale Variablen
4.2. Entwicklung unter FastCGI
4.2.1. Allgemeines
4.2.2. Programmende und Ausnahmen
4.2.3. Globale Variablen
4.2.4. Performance und Statistiken
4.2.5. Bekannte Probleme
4.3. SQL-Upgradedateien
4.3.1. Einführung
4.3.2. Format der Kontrollinformationen
4.3.3. Hilfsscript dbupgrade2_tool.pl
4.4. Translations and languages
4.4.1. Introduction
4.4.2. File structure
4.5. Die kivitendo-Test-Suite
4.5.1. Einführung
4.5.2. Voraussetzungen
4.5.3. + Formularen
3.3. Excel-Vorlagen
3.3.1. Zusammenfassung
3.3.2. Bedienung
3.3.3. Variablensyntax
3.3.4. Einschränkungen
4. Entwicklerdokumentation
4.1. Globale Variablen
4.1.1. Wie sehen globale Variablen in Perl aus?
4.1.2. Warum sind globale Variablen ein Problem?
4.1.3. Kanonische globale Variablen
4.1.4. Ehemalige globale Variablen
4.2. Entwicklung unter FastCGI
4.2.1. Allgemeines
4.2.2. Programmende und Ausnahmen
4.2.3. Globale Variablen
4.2.4. Performance und Statistiken
4.2.5. Bekannte Probleme
4.3. SQL-Upgradedateien
4.3.1. Einführung
4.3.2. Format der Kontrollinformationen
4.3.3. Hilfsscript dbupgrade2_tool.pl
4.4. Translations and languages
4.4.1. Introduction
4.4.2. File structure
4.5. Die kivitendo-Test-Suite
4.5.1. Einführung
4.5.2. Voraussetzungen
4.5.3. Existierende Tests ausführen
4.5.4. Bedeutung der verschiedenen Test-Scripte diff --git a/doc/kivitendo-Dokumentation.pdf b/doc/kivitendo-Dokumentation.pdf index d290bb466..90284df1c 100644 Binary files a/doc/kivitendo-Dokumentation.pdf and b/doc/kivitendo-Dokumentation.pdf differ