2.2.2.3. openSUSE Leap 15.4 und SUSE Linux Enterprise Server 15
Für openSUSE Leap 15.4, sowie SLES 15 stehen alle benötigten Perl-Pakete als RPM-Pakete zur Verfügung.
Damit diese installiert werden können, muß das System die erforderlichen Repositories kennen und Zugriff über das Internet darauf haben.
Daher machen wir die Repositories dem System bekannt.
Um die zusätzlichen Repositories für die Installation zur Verfügung zu stellen, kann man diese mit YaST oder auch in einem Terminal auf der Konsole bekannt geben. Wir beschränken uns hier mit der Eingabe auf der Konsole. In den allermeisten Fällen verwenden die Administratoren eine sichere SSH-Verbindung zum zu administrierenden Server.
2.2.2.3. openSUSE Leap 15.4 und SUSE Linux Enterprise Server 15
Für openSUSE Leap 15.4, sowie SLES 15 stehen alle benötigten Perl-Pakete als RPM-Pakete zur Verfügung.
Damit diese installiert werden können, muß das System die erforderlichen Repositories kennen und Zugriff über das Internet darauf haben.
Daher machen wir die Repositories dem System bekannt.
Um die zusätzlichen Repositories für die Installation zur Verfügung zu stellen, kann man diese mit YaST oder auch in einem Terminal auf der Konsole bekannt geben. Wir beschränken uns hier mit der Eingabe auf der Konsole. In den allermeisten Fällen verwenden die Administratoren eine sichere SSH-Verbindung zum zu administrierenden Server.
Danach geben wir noch die beiden folgenden Befehle ein:
zypper clean
zypper refresh
Sollte zypper eine Meldung ausgeben, ob der Repositorie Key abgelehnt, nicht vertraut oder für immer akzeptiert werden soll, ist die Beantwortung durch drücken der "i" Taste am besten geeignet. Wer noch mehr über zypper erfahren möchte, kann sich einmal die zypper Hilfe anschauen.
zypper --help
Anmerkung
Offiziell wird von openSUSE nur noch Versionen ab 15.4 unterstützt. Die SuSE Macher haben ab Version 15.x einen großen Umbau in der Verwaltung der Pakete vorgenommen, das heißt, der Paketumfang ist der SLE 15 als Programmunterbau angepasst. Dies gilt besonders der openSUSE Distribution. Es gibt ja einmal die openSUSE Distri und die professionelle SLE (SUSE Linux Enterprise) Version. Dadurch sind viele Pakete aus dem ursprünglich nur für die openSUSE geltenen Repositorie enfernt worden, aber auch viele auf aktuellem Stand gehalten. Mit der openSUSE Leap 15.4 ist es dem Benutzer ganz einfach gemacht worden zur professionellen SUSE Linux Enterprise zu wechseln, da die RPM Paketbasis identisch ist.
Ob openSUSE Leap oder SLE, man kann die Distribution auch als reine Text Version, also ohne KDE Oberfläche aufsetzen. Vorteil hierbei ist, dass weniger Balast und unnötige Pakte installiert werden. Diese Variante wird gerne auch als 'Server', 'minimale Server' oder auch 'minmal X' Variante bezeichnet.
Als Administrator hatte man jedoch auch immer die Möglichkeit, bei der Installation der Distribution die KDE (graphische) Oberfläche zu aktivieren. In dieser Konstellation hat man die Möglichkeit, eine VNC Verbindung vom administrativen Client zu verwenden. Ist das nicht eingerichtet, arbeitet der Admin dann direkt am Bildschirm des Servers. Nun loggen wir uns am Server direkt ein, starten Yast2 in einer Konsole wie folgt:
yast2 return.
Oder über die Menüführung wie folgt: Ein Klick auf das runde Icon, ganz links unten in der Menüleiste, dann die Maus verfahren auf System und YaST.
Im weiteren Verlauf der Installation, beschränken wir uns mit dem Installations Werkzeug zypper. Zypper ist ein Komandozeilen basiertes Installations Tool, welches bei openSUSE Standard ist. Zypper weist ein etwas eigenartiges Verhalten auf, dass sich in etwa wie folgt darstellt. Hat man die Repositories eingerichtet, kann man diese mit Yast als auch mit Zypper benutzen, setzt man einen Befehl wie etwa: zypper up ab, so findet zypper mehr neuere Programmversionen als Yast. Ich habe im allgemeinen noch keine Nachteile damit erlebt.
Programmpakete können mit folgendem Befehl installiert werden:
zypper install Paketname
Es wird empfohlen zusätzliche Pakete nicht direkt mit CPAN zu installieren, da man diese auch über andere Repositories beziehen kann, die bei openSUSE zur Verfügung stehen. Dadurch hat man den Vorteil, dass die Pakete mit YaST verwaltet werden, also wieder deinstalliert oder durch neuere ersetzt werden können. Zudem kann man auch noch eventuelle Bugs an openSUSE senden und diese dem Maintainer melden.
zypper install kivitendo-erp
Für Entwickler installiert man noch das folgende Paket:
zypper install kivitendo-erp-devel
2.2.3. Andere Pakete installieren
+ "OSS-15.4-App_ERP_kivitendo_eval"
Danach geben wir noch die beiden folgenden Befehle ein:
zypper clean
zypper refresh
Sollte zypper eine Meldung ausgeben, ob der Repositorie Key abgelehnt, nicht vertraut oder für immer akzeptiert werden soll, ist die Beantwortung durch drücken der "i" Taste am besten geeignet. Wer noch mehr über zypper erfahren möchte, kann sich einmal die zypper Hilfe anschauen.
zypper --help
Anmerkung
Offiziell wird von openSUSE nur noch Versionen ab 15.4 unterstützt. Die SuSE Macher haben ab Version 15.x einen großen Umbau in der Verwaltung der Pakete vorgenommen, das heißt, der Paketumfang ist der SLE 15 als Programmunterbau angepasst. Dies gilt besonders der openSUSE Distribution. Es gibt ja einmal die openSUSE Distri und die professionelle SLE (SUSE Linux Enterprise) Version. Dadurch sind viele Pakete aus dem ursprünglich nur für die openSUSE geltenen Repositorie enfernt worden, aber auch viele auf aktuellem Stand gehalten. Mit der openSUSE Leap 15.4 ist es dem Benutzer ganz einfach gemacht worden zur professionellen SUSE Linux Enterprise zu wechseln, da die RPM Paketbasis identisch ist.
Ob openSUSE Leap oder SLE, man kann die Distribution auch als reine Text Version, also ohne KDE Oberfläche aufsetzen. Vorteil hierbei ist, dass weniger Balast und unnötige Pakte installiert werden. Diese Variante wird gerne auch als 'Server', 'minimale Server' oder auch 'minmal X' Variante bezeichnet.
Als Administrator hatte man jedoch auch immer die Möglichkeit, bei der Installation der Distribution die KDE (graphische) Oberfläche zu aktivieren. In dieser Konstellation hat man die Möglichkeit, eine VNC Verbindung vom administrativen Client zu verwenden. Ist das nicht eingerichtet, arbeitet der Admin dann direkt am Bildschirm des Servers. Nun loggen wir uns am Server direkt ein, starten Yast2 in einer Konsole wie folgt:
yast2 return.
Oder über die Menüführung wie folgt: Ein Klick auf das runde Icon, ganz links unten in der Menüleiste, dann die Maus verfahren auf System und YaST.
Im weiteren Verlauf der Installation, beschränken wir uns mit dem Installations Werkzeug zypper. Zypper ist ein Komandozeilen basiertes Installations Tool, welches bei openSUSE Standard ist. Zypper weist ein etwas eigenartiges Verhalten auf, dass sich in etwa wie folgt darstellt. Hat man die Repositories eingerichtet, kann man diese mit Yast als auch mit Zypper benutzen, setzt man einen Befehl wie etwa: zypper up ab, so findet zypper mehr neuere Programmversionen als Yast. Ich habe im allgemeinen noch keine Nachteile damit erlebt.
Programmpakete können mit folgendem Befehl installiert werden:
zypper install Paketname
Es wird empfohlen zusätzliche Pakete nicht direkt mit CPAN zu installieren, da man diese auch über andere Repositories beziehen kann, die bei openSUSE zur Verfügung stehen. Dadurch hat man den Vorteil, dass die Pakete mit YaST verwaltet werden, also wieder deinstalliert oder durch neuere ersetzt werden können. Zudem kann man auch noch eventuelle Bugs an openSUSE senden und diese dem Maintainer melden.
zypper install kivitendo-erp
Für Entwickler installiert man noch das folgende Paket:
zypper install kivitendo-erp-devel
2.2.3. Andere Pakete installieren
poppler-utils 'pdfinfo' zum Erkennen der Seitenanzahl bei der PDF-Generierung
Postgres Trigram-Index Für datenbankoptimierte Suchanfragen. Bspw. im Paket postgresql-contrib enthalten
2.3. Installation mittels Ansible auf Ubuntu 22.04
Ansible ist ein Open-Source-Automatisierungstool, das verwendet
wird, um die Bereitstellung, Konfiguration und Verwaltung von
IT-Systemen zu automatisieren. Dabei führt es Aufgaben über SSH auf
diff --git a/doc/html/ch02s04.html b/doc/html/ch02s04.html
index 9d3bc8d37f..a841d36379 100644
--- a/doc/html/ch02s04.html
+++ b/doc/html/ch02s04.html
@@ -1,6 +1,6 @@
Wir empfehlen eine Installation mittels des Versionsmanager
git. Hierfür muss ein git-Client installiert sein. Damit ist man sehr
viel flexibler für zukünftige Upgrades. Installations-Anleitung (bitte
die Pfade anpassen) bspw. wie folgt:
cd /var/www/
diff --git a/doc/html/ch02s05.html b/doc/html/ch02s05.html
index 787ed27c08..7261daea0e 100644
--- a/doc/html/ch02s05.html
+++ b/doc/html/ch02s05.html
@@ -1,6 +1,6 @@
- 2.5. kivitendo-Konfigurationsdatei
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
diff --git a/doc/html/ch02s06.html b/doc/html/ch02s06.html
index 01708c1689..fe2361d0dd 100644
--- a/doc/html/ch02s06.html
+++ b/doc/html/ch02s06.html
@@ -1,6 +1,6 @@
PostgreSQL muss auf verschiedene Weisen angepasst werden.
Dies variert je nach eingesetzter Distribution, da distributionsabhängig unterschiedliche Strategien beim Upgrade der Postgres Version eingesetzt werden.
+
PostgreSQL muss auf verschiedene Weisen angepasst werden.
Dies variert je nach eingesetzter Distribution, da distributionsabhängig unterschiedliche Strategien beim Upgrade der Postgres Version eingesetzt werden.
Als Hinweis einige Links zu den drei Distribution (Stand Dezember 2018):
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 000-default.conf eingestellt
@@ -104,13 +104,13 @@
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.
Kivitendo unterstützt, dass Benutzerauthentifizierung über den Webserver mittels des »Basic«-HTTP-Authentifizierungs-Schema erfolgt
(siehe RFC 7617). Dazu ist es aber nötig, dass der dabei vom Client
mitgeschickte Header Authorization vom Webserver an Kivitendo über die Umgebungsvariable
HTTP_AUTHORIZATION weitergegeben wird, was standardmäßig nicht der Fall ist. Für Apache kann dies über die
folgende Konfigurationsoption aktiviert werden:
-
2.7.4. Aktivierung von mod_rewrite/directory_match für git basierte Installationen
Aufgrund von aktuellen (Mitte 2020) Sicherheitswarnungen für git basierte Webanwendungen ist die mitausgelieferte .htaccess
restriktiver geworden und verhindert somit das Auslesen von git basierten Daten.
Für debian/ubuntu muss das Modul mod_rewrite einmalig so aktiviert werden:
@@ -125,13 +125,13 @@
Require all denied
</DirectoryMatch>
-
2.7.5. Weitergehende Konfiguration
Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung
+
2.7.5. Weitergehende Konfiguration
Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung
von kivitendo nur über https-verschlüsselten Verbindungen, sowie
weiteren Zusatzmassnahmen, wie beispielsweise Basic Authenticate. Die
Konfigurationsmöglichkeiten sprengen allerdings den Rahmen dieser
Anleitung, hier ein Hinweis auf einen entsprechenden Foreneintrag
(Stand Sept. 2015) und einen aktuellen (Stand Mai 2017)
- SSL-Konfigurations-Generator.
2.7.6. Aktivierung von Apache2 modsecurity
Aufgrund des OpenSource Charakters ist kivitendo nicht "out of the box" sicher.
+ SSL-Konfigurations-Generator.
2.7.6. Aktivierung von Apache2 modsecurity
Aufgrund des OpenSource Charakters ist kivitendo nicht "out of the box" sicher.
Organisatorisch empfehlen wir hier die enge Zusammenarbeit mit einem kivitendo Partner der auch in der
Lage ist weiterführende Fragen in Bezug auf Datenschutz und Datensicherheit zu beantworten.
Unabhängig davon empfehlen wir im Webserver Bereich die Aktivierung und Konfiguration des Moduls modsecurity für den Apache2, damit
diff --git a/doc/html/ch02s08.html b/doc/html/ch02s08.html
index 3264533e5a..4d0504e6f0 100644
--- a/doc/html/ch02s08.html
+++ b/doc/html/ch02s08.html
@@ -1,6 +1,6 @@
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 u.a. für die Erzeugung der wiederkehrenden Rechnungen und weitere
@@ -44,7 +44,7 @@
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.8.3.1. SystemV-basierende Systeme (z.B. ältere Debian, ältere
+ anstelle eines symbolischen Links verwendet werden können.
Kopieren Sie die Datei
scripts/boot/system-v/kivitendo-task-server
nach /etc/init.d/kivitendo-task-server. Passen
@@ -52,12 +52,12 @@
DAEMON=....). Binden Sie das Script in den
Boot-Prozess ein. Dies ist distributionsabhängig:
Danach kann der Task-Server mit dem folgenden Befehl gestartet
- werden:
/etc/init.d/kivitendo-task-server start
2.8.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)
Kopieren Sie die Datei
+ werden:
/etc/init.d/kivitendo-task-server start
2.8.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)
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:
Kopieren Sie die Datei
scripts/boot/systemd/kivitendo-task-server.service
nach /etc/systemd/system/. Passen Sie in der
diff --git a/doc/html/ch02s09.html b/doc/html/ch02s09.html
index 85a1d6f102..d8af3bb975 100644
--- a/doc/html/ch02s09.html
+++ b/doc/html/ch02s09.html
@@ -1,6 +1,6 @@
2.10. Benutzerauthentifizierung und Administratorpasswort
Informationen über die Einrichtung der Benutzerauthentifizierung,
über die Verwaltung von Gruppen und weitere Einstellungen
2.10.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
diff --git a/doc/html/ch02s11.html b/doc/html/ch02s11.html
index 6af5219903..697f8e965f 100644
--- a/doc/html/ch02s11.html
+++ b/doc/html/ch02s11.html
@@ -1,6 +1,6 @@
- 2.11. Mandanten-, Benutzer- und Gruppenverwaltung
Nach der Installation müssen Mandanten, Benutzer, Gruppen und
Datenbanken angelegt werden. Dieses geschieht im Administrationsmenü,
das Sie unter folgender URL finden:
Im Administrationsmenü gibt es ferner noch die beiden Menüpunkte
Druckeradministration und System.
2.12.1. Druckeradministration
Unter dem Menüpunkt Druckeradministration lassen sich beliebig
viele "Druckbefehle" im System verwalten. Diese Befehle werden
mandantenweise zugeordnet. Unter Druckerbeschreibung wird der Namen
diff --git a/doc/html/ch02s13.html b/doc/html/ch02s13.html
index 48fdc9446e..a857392ddc 100644
--- a/doc/html/ch02s13.html
+++ b/doc/html/ch02s13.html
@@ -1,6 +1,6 @@
kivitendo kann sowohl E-Mails direkt aus dem Programm heraus E-Mails
versenden, als auch in das Programm importiern. Damit dies
funktioniert, müssen die E-Mail-Parameter korrekt konfiguriert sein.
diff --git a/doc/html/ch02s14.html b/doc/html/ch02s14.html
index 4173601754..73b5edbf17 100644
--- a/doc/html/ch02s14.html
+++ b/doc/html/ch02s14.html
@@ -1,6 +1,6 @@
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:
@@ -148,9 +148,9 @@
Da man heutzutage nur noch moderne Schriftformate Verwenden sollte, wird hier lediglich die Variante für |lualatex| aufgelistet.
Die Konfiguration läuft hierbei über das \pck{fontspec} Paket (Doku siehe \cite{fontspec}).
Dann hängt es davon ab, ob die Basisschriftart eine Serifenschriftart ist oder nicht.
In jedem Fall wird die Änderung entweder in der insettings.tex, sofern sie für alle
- Mandant*innen gelten soll oder in der Mantant*innenspezifischen Konfigurationsdatei gsesetzt.
2.14.2.10.1.1. Änderung, falls es ein Schriftpaket gibt
Wenn möglich sollte die Schriftart über ein entsprechendes Konfigurationspaket gesetzt werden.
- Ob ein solches existiert kann man sehr leicht über eine Suche nach dem Namen unter \url{ctan.org} herausfinden.
2.14.2.10.1.2. Änderung der Basisschriftart auf eine Schriftart mit Serifen
- \setmainfont{|\meta{Name der Schriftart, z.B. SourceSerifPro}|}
2.14.2.10.1.3. Änderung der Basisschriftart auf eine Schriftart ohne Serifen
+ Mandant*innen gelten soll oder in der Mantant*innenspezifischen Konfigurationsdatei gsesetzt.
2.14.2.10.1.1. Änderung, falls es ein Schriftpaket gibt
Wenn möglich sollte die Schriftart über ein entsprechendes Konfigurationspaket gesetzt werden.
+ Ob ein solches existiert kann man sehr leicht über eine Suche nach dem Namen unter \url{ctan.org} herausfinden.
2.14.2.10.1.2. Änderung der Basisschriftart auf eine Schriftart mit Serifen
+ \setmainfont{|\meta{Name der Schriftart, z.B. SourceSerifPro}|}
2.14.2.10.1.3. Änderung der Basisschriftart auf eine Schriftart ohne Serifen
\setsansfont{|\meta{Name der Schriftart, z.B. SourceSansPro}|}
\renewcommand*{\familydefault}{\sfdefault}
2.14.2.10.2. Unterscheidungen durch String-Vergleich
\Ifstr{\lxmedia}{printer}{Falls gedruckt werden soll} {sonst}
2.14.3. Der Druckvorlagensatz RB
Hierbei handelt es sich um einen vollständigen LaTeX
diff --git a/doc/html/ch02s15.html b/doc/html/ch02s15.html
index 7aaed4d025..ef1e1f78eb 100644
--- a/doc/html/ch02s15.html
+++ b/doc/html/ch02s15.html
@@ -1,22 +1,22 @@
kivitendo unterstützt die Verwendung von Vorlagen im
OpenDocument-Format, wie es LibreOffice oder OpenOffice (ab Version 2)
erzeugen. kivitendo kann dabei sowohl neue OpenDocument-Dokumente als
auch aus diesen direkt PDF-Dateien erzeugen. Nachfolgend ist die
Verwendung mit LibreOffice beschrieben. Für die Verwendung mit
- OpenOffice müssen die Einstellungen allenfalls angepasst werden.
2.15.1. Grundeinstellung
Um die Unterstützung von OpenDocument-Vorlagen zu aktivieren,
+ OpenOffice müssen die Einstellungen allenfalls angepasst werden.
2.15.1. Grundeinstellung
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.
- Dies ist die Standardeinstellung.
2.15.2. Direkte Erzeugung von PDF-Dateien
Während die Erzeugung von reinen OpenDocument-Dateien keinerlei
+ Dies ist die Standardeinstellung.
2.15.2. Direkte Erzeugung von PDF-Dateien
Während die Erzeugung von reinen OpenDocument-Dateien keinerlei
weitere Software benötigt, wird zur Umwandlung dieser Dateien in PDF
LibreOffice oder OpenOffice benötigt.
Unter Debian kann dieses installiert werden mit:
apt install libreoffice
Der Pfad zu LibreOffice kann in der Datei
config/kivitendo.conf, im Abschnitt
applications, angepasst werden. Unter Debian sollte
- dies nicht notwendig sein.
2.15.2.1. Variante 1)
In der Standardeinstellung wird LibreOffice für jedes Dokument
+ dies nicht notwendig sein.
2.15.2.1. Variante 1)
In der Standardeinstellung wird LibreOffice für jedes Dokument
neu gestartet. Es ist keine weitere Konfiguration
- erforderlich.
2.15.2.2. Variante 2)
Die zweite Variante startet ein LibreOffice, das auch nach der
+ erforderlich.
2.15.2.2. Variante 2)
Die zweite Variante startet ein LibreOffice, 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 möglicherweise reduziert wird,
@@ -29,7 +29,7 @@
python_uno_path in der Konfigurationsdatei
config/kivitendo.conf dienen zur Anpassung der
Python uno Pfade. Unter Debian sollte keine Anpassung notwendig
- sein.
2.15.3. Vorbereitungen
2.15.3.1. Adminbereich
Damit beim Erstellen von Rechnungen und Aufträgen neben der
+ sein.
2.15.3. Vorbereitungen
2.15.3.1. Adminbereich
Damit beim Erstellen von Rechnungen und Aufträgen neben der
Standardvorlage ohne Einzahlungsschein weitere Vorlagen (z.B. mit
Einzahlungsschein) auswählbar sind, muss für jedes Vorlagen-Suffix
ein Drucker eingerichtet werden:
Druckeradministration → Drucker hinzufügen
Mandant wählen
Druckerbeschreibung → aussagekräftiger Text: wird in der
@@ -38,16 +38,16 @@
Aufträgen oder Rechnungen als odt-Datei keine Bedeutung, darf
aber nicht leer sein)
Vorlagenkürzel → besr bzw. selbst gewähltes Vorlagensuffix
(muss genau der Zeichenfolge entsprechen, die zwischen
- "invoice_" bzw. "sales_order_" und ".odt" steht.)
speichern
2.15.3.2. Benutzereinstellungen
Wer den Ausdruck mit Einzahlungsschein als Standardeinstellung
+ "invoice_" bzw. "sales_order_" und ".odt" steht.)
speichern
2.15.3.2. Benutzereinstellungen
Wer den Ausdruck mit Einzahlungsschein als Standardeinstellung
im Rechnungs- bzw. Auftragsformular angezeigt haben möchte, kann
dies persönlich für sich bei den Benutzereinstellungen
konfigurieren:
Programm → Benutzereinstellungen → Druckoptionen
Standardvorlagenformat → OpenDocument/OASIS
Standardausgabekanal → Bildschirm
Standarddrucker → gewünschte Druckerbeschreibung auswählen
- (z.B. mit Einzahlungsschein Bank xy)
Anzahl Kopien → leer
speichern
2.15.3.3. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer
+ (z.B. mit Einzahlungsschein Bank xy)
Anzahl Kopien → leer
speichern
2.15.3.3. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer
odt-Rechnung (analog bei Auftrag)
Im Fussbereich der Rechnungsmaske muss neben Rechnung,
OpenDocument/OASIS und Bildschirm die im Adminbereich erstellte
Druckerbeschreibung ausgewählt werden, falls diese nicht bereits bei
den Benutzereinstellungen als persönlicher Standard gewählt
- wurde.
2.15.4. Schweizer QR-Rechnung mit OpenDocument Vorlagen
Mit der Version 3.6.0 unterstützt Kivitendo die Erstellung von
+ wurde.
2.15.4. Schweizer QR-Rechnung mit OpenDocument Vorlagen
Mit der Version 3.6.0 unterstützt Kivitendo die Erstellung von
Schweizer QR-Rechnungen gemäss Swiss
Payment Standards, Version 2.2. Implementiert sind hierbei die
Varianten:
@@ -55,11 +55,11 @@
QR-Referenz
IBAN ohne Referenz
-
2.15.4.1. Einstellungen
2.15.4.1.1. Mandantenkonfiguration
Unter System → Mandantenkonfiguration →
+
2.15.4.1. Einstellungen
2.15.4.1.1. Mandantenkonfiguration
Unter System → Mandantenkonfiguration →
Features. Im Abschnitt Einkauf und
Verkauf, beim Punkt Verkaufsrechnungen mit
Schweizer QR-Rechnung erzeugen, die gewünschte Variante
- wählen.
2.15.4.1.2. Konfiguration der Bankkonten
Unter System → Bankkonten muss bei
+ wählen.
2.15.4.1.2. Konfiguration der Bankkonten
Unter System → Bankkonten muss bei
mindestens einem Bankkonto die Option Nutzung mit
Schweizer QR-Rechnung auf Ja gestellt werden.
Die IBAN muss ohne Leerzeichen angegeben werden.
Tipp
Für die Variante QR-IBAN mit
QR-Referenz muss dieses Konto unter IBAN eine gültige
@@ -67,12 +67,12 @@
unterscheidet sich von der regulären IBAN.
Zusätzlich muss eine gültige Bankkonto
Identifikationsnummer angegeben werden
(6-stellig).
Diese werden von der jeweiligen Bank vergeben.
Sind mehrere Konten ausgewählt wird das erste
- verwendet.
2.15.4.1.3. Rechnungen ohne Betrag
Für Rechnungen ohne Betrag (z.B. Spenden) kann, in der
+ verwendet.
2.15.4.1.3. Rechnungen ohne Betrag
Für Rechnungen ohne Betrag (z.B. Spenden) kann, in der
jeweiligen Rechnung, die Checkbox QR-Rechnung ohne
Betrag aktiviert werden. Diese Checkbox erscheint nur,
wenn QR-Rechnungen in der Mandantenkonfiguration aktiviert sind
(variante ausgewählt).
Dies wirkt sich lediglich auf den erzeugten QR-Code aus. Die
- Vorlage muss separat angepasst und ausgewählt werden.
2.15.4.2. Adressdaten
Die Adressdaten zum Zahlungsempfänger werden aus der
+ Vorlage muss separat angepasst und ausgewählt werden.
2.15.4.2. Adressdaten
Die Adressdaten zum Zahlungsempfänger werden aus der
Mandantenkonfiguration entnommen. Unter System →
Mandantenkonfiguration → Verschiedenes, Abschnitt
Firmenname und -adresse.
@@ -82,13 +82,13 @@
z.B. "Schweiz" oder "CH".
Es sind lediglich Ziffern erlaubt. Allfällige Buchstaben und
Sonderzeichen werden entfernt und fehlende Stellen werden mit
- führenden Nullen aufgefüllt.
2.15.4.4. Vorlage
Der Vorlagensatz "rev-odt" enthält die Vorlage
+ führenden Nullen aufgefüllt.
2.15.4.4. Vorlage
Der Vorlagensatz "rev-odt" enthält die Vorlage
invoice_qr.odt, welche für die Erstellung von
QR-Rechnungen vorgesehen ist. Damit diese verwendet werden kann muss
wie obenstehend beschrieben ein Drucker hinzugefügt werden, allerdings
@@ -103,7 +103,7 @@
Bild-Kontextmenü → Einstellungen →
Optionen → Name einstellbar. Siehe dazu auch die
- Beispielvorlage.
2.15.4.4.1. Zusätzliche Variablen für Vorlage
Zusätzlich zu den in der Vorlage standardmässig verfügbaren
+ Beispielvorlage.
Seit der Version 3.5 werden für Buchungen in kivitendo
einheitlich folgende Bezeichnungen verwendet:
Erfassungsdatum (en: Entry
Date, code: Gldate)
bezeichnet das Datum, an dem die Buchung in kivitendo
diff --git a/doc/html/ch02s17.html b/doc/html/ch02s17.html
index 8ea82dc8cf..e75cf5cb5c 100644
--- a/doc/html/ch02s17.html
+++ b/doc/html/ch02s17.html
@@ -1,6 +1,6 @@
- 2.17. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR
2.17. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung:
+ 2.17. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung: EUR
2.17. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung:
EUR
2.17. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung:
EUR
2.17.1. Einführung
kivitendo besaß bis inklusive Version 2.6.3 einen
Konfigurationsparameter namens eur, der sich in der
diff --git a/doc/html/ch02s18.html b/doc/html/ch02s18.html
index 8e6e872eab..37ab010fe2 100644
--- a/doc/html/ch02s18.html
+++ b/doc/html/ch02s18.html
@@ -1,6 +1,6 @@
- 2.18. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.18. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.18. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb
2.18.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
diff --git a/doc/html/ch02s19.html b/doc/html/ch02s19.html
index 3dc8842215..c127910771 100644
--- a/doc/html/ch02s19.html
+++ b/doc/html/ch02s19.html
@@ -1,6 +1,6 @@
Bis Version 3.0 wurde "closedto" ("Bücher schließen zum") als
Grundlage für das Startdatum benutzt. Schließt man die Bücher allerdings
monatsweise führt dies zu falschen Werten.
In der Mandantenkonfiguration kann man dieses Verhalten genau
einstellen indem man:
weiterhin closed_to benutzt (Default, es ändert sich nichts zu
diff --git a/doc/html/ch02s20.html b/doc/html/ch02s20.html
index 5f91b7ab4c..8fa9f39ca0 100644
--- a/doc/html/ch02s20.html
+++ b/doc/html/ch02s20.html
@@ -1,6 +1,6 @@
Beim Jahresabschluss stehen 2 Methoden zur Verfügung, die in der
Buchungskonfiguration der Mandantenkonfiguration eingestellt werden
können.
Standard-Methode.
Sowohl Bestandskonten wie auch Erfolgskonten werden
diff --git a/doc/html/ch02s21.html b/doc/html/ch02s21.html
index c614fa24b2..2fe465f970 100644
--- a/doc/html/ch02s21.html
+++ b/doc/html/ch02s21.html
@@ -1,6 +1,6 @@
Seit der Version 3.4.1 existiert in kivitendo der Bericht
Erfolgsrechnung.
Die Erfolgsrechnung kann in der Mandantenkonfiguration unter
Features an- oder abgeschaltet werden. Mit der Einstellung
default_manager = swiss in der
diff --git a/doc/html/ch02s22.html b/doc/html/ch02s22.html
index 78b7d311a3..27b026d021 100644
--- a/doc/html/ch02s22.html
+++ b/doc/html/ch02s22.html
@@ -1,6 +1,6 @@
In der Schweiz hat die kleinste aktuell benutzte Münze den Wert
von 5 Rappen (0.05 CHF).
Auch wenn im elektronischen Zahlungsverkehr Beträge mit einer
Genauigkeit von 0.01 CHF verwendet werden können, ist es trotzdem nach
wie vor üblich, Rechnungen mit auf 0.05 CHF gerundeten Beträgen
diff --git a/doc/html/ch02s23.html b/doc/html/ch02s23.html
index abb992653f..54e2c43085 100644
--- a/doc/html/ch02s23.html
+++ b/doc/html/ch02s23.html
@@ -1,6 +1,6 @@
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 →
diff --git a/doc/html/ch02s24.html b/doc/html/ch02s24.html
index 53552101c2..9715e12ff0 100644
--- a/doc/html/ch02s24.html
+++ b/doc/html/ch02s24.html
@@ -1,6 +1,6 @@
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
diff --git a/doc/html/ch03s02.html b/doc/html/ch03s02.html
index 67ac72b06d..cc6e385d26 100644
--- a/doc/html/ch03s02.html
+++ b/doc/html/ch03s02.html
@@ -1,6 +1,6 @@
Dies ist eine Auflistung der Standard-Dokumentenvorlagen und
aller zur Bearbeitung verfügbaren Variablen. Eine Variable wird in
einer Vorlage durch ihren Inhalt ersetzt, wenn sie in der Form
<%variablenname%> verwendet wird. Für
@@ -421,7 +421,7 @@
Vorgangsbezeichnung
transdate
Auftragsdatum wenn die Rechnung aus einem Auftrag
- erstellt wurde
3.3.8.2. Variablen für die schweizer QR-Rechnung
Diese Variablen können mit dem LaTeX Modul qrbill verwendet
+ erstellt wurde
Die Variablen in anderen Vorlagen sind ähnlich wie in der
+
Rechnungsnummer
3.3.10. Variablen in anderen Vorlagen
3.3.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/ch03s04.html b/doc/html/ch03s04.html
index 50a681319b..81ac7a00ce 100644
--- a/doc/html/ch03s04.html
+++ b/doc/html/ch03s04.html
@@ -1,6 +1,6 @@
Dieses Dokument beschreibt den Mechanismus, mit dem
Exceltemplates abgearbeitet werden, und die Einschränkungen, die damit
einhergehen.
3.4.2. Bedienung
Der Excel Mechanismus muss in der Konfigurationsdatei aktiviert
werden. Die Konfigurationsoption heißt excel_templates =
diff --git a/doc/html/ch03s05.html b/doc/html/ch03s05.html
index 6f0c2ef703..3f1ede1e5b 100644
--- a/doc/html/ch03s05.html
+++ b/doc/html/ch03s05.html
@@ -1,6 +1,6 @@
- 3.5. Mandantenkonfiguration Lager
Die Lagerverwaltung in kivitendo funktioniert standardmässig wie
folgt: Wird ein Lager mit einem Lagerplatz angelegt, so gibt es die
Möglichkeit hier über den Menüpunkt Lager entsprechende Warenbewegungen
durchzuführen. Ferner kann jede Position eines Lieferscheins ein-, bzw.
diff --git a/doc/html/ch03s06.html b/doc/html/ch03s06.html
index eaabf57cd2..33dea22f6f 100644
--- a/doc/html/ch03s06.html
+++ b/doc/html/ch03s06.html
@@ -1,6 +1,6 @@
Seit der Version 3.5 stehen in kivitendo 3 Kontenpläne für den
Einsatz in der Schweiz zur Verfügung, einer für Firmen und
Organisationen, die nicht mehrwertsteuerpflichtig sind, einer für
Firmen, die mehrwertsteuerpflichtig sind und einer speziell für
diff --git a/doc/html/ch03s07.html b/doc/html/ch03s07.html
index 76e0d71922..c4e610349d 100644
--- a/doc/html/ch03s07.html
+++ b/doc/html/ch03s07.html
@@ -1,15 +1,15 @@
Die Klassifizierung von Artikeln dient einer weiteren
Gliederung, um zum Beispiel den Einkauf vom Verkauf zu trennen,
gekennzeichnet durch eine Beschreibung (z.B. "Einkauf") und ein Kürzel
(z.B. "E"). Für jede Klassifizierung besteht eine Beschreibung und
eine Abkürzung die normalerweise aus einem Zeichen besteht, kann aber
auf mehrere Zeichen erweitert werden, falls zur Unterscheidung
- notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen.
3.7.2. Basisklassifizierung
Als Basisklassifizierungen gibt es
Einkauf
Verkauf
Handelsware
Produktion
- keine - (diese wird bei einer Aktualisierung für alle
+ notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen.
3.7.2. Basisklassifizierung
Als Basisklassifizierungen gibt es
Einkauf
Verkauf
Handelsware
Produktion
- keine - (diese wird bei einer Aktualisierung für alle
existierenden Artikel verwendet und ist gültig für Verkauf und
Einkauf)
Es können weitere Klassifizierungen angelegt werden. So kann es
- z.B. für separat auszuweisende Artikel folgende Klassen geben:
Lieferung (Logistik, Transport) mit Kürzel L
Material (Verpackungsmaterial) mit Kürzel M
3.7.3. Attribute
Bisher haben die Klassifizierungen folgende Attribute, die auch
+ z.B. für separat auszuweisende Artikel folgende Klassen geben:
Lieferung (Logistik, Transport) mit Kürzel L
Material (Verpackungsmaterial) mit Kürzel M
3.7.3. Attribute
Bisher haben die Klassifizierungen folgende Attribute, die auch
alle gleichzeitg gültig sein können
gültig für Verkauf - dieser Artikel kann im Verkauf genutzt
werden
gültig für Einkauf - dieser Artikel kann im Einkauf genutzt
werden
separat ausweisen - hierzu gibt es zur Dokumentengenerierung
@@ -19,7 +19,7 @@
pro separat auszuweisenden Klassifizierungen die Variable< %separate_X_subtotal%>, wobei X das
Kürzel der Klassifizierung ist.
Im obigen Beispiel wäre das für Lieferkosten <%separate_L_subtotal%> und für
Verpackungsmaterial
- <%separate_M_subtotal%>.
3.7.4. Zwei-Zeichen Abkürzung
Der Typ des Artikels und die Klassifizierung werden durch zwei
+ <%separate_M_subtotal%>.
3.7.4. Zwei-Zeichen Abkürzung
Der Typ des Artikels und die Klassifizierung werden durch zwei
Buchstaben dargestellt. Der erste Buchstabe ist eine Lokalisierung des
Artikel-Typs ('P','A','S'), deutsch 'W', 'E', und 'D' für Ware
Erzeugnis oder Dienstleistung und ggf. weiterer Typen.
Der zweite Buchstabe (und ggf. auch ein dritter, falls nötig)
diff --git a/doc/html/ch03s08.html b/doc/html/ch03s08.html
index 2c11f8009d..99391792dc 100644
--- a/doc/html/ch03s08.html
+++ b/doc/html/ch03s08.html
@@ -1,10 +1,10 @@
Parallel zum alten WebDAV gibt es ein Datei-Management-System,
das Dateien verschiedenen Typs verwaltet. Dies können
aus ERP-Daten per LaTeX Template erzeugte
PDF-Dokumente,
zu bestimmten ERP-Daten gehörende Anhangdateien
unterschiedlichen Formats,
per Scanner eingelesene PDF-Dateien,
per E-Mail empfangene Dateianhänge unterschiedlichen
- Formats,
sowie speziel für Artikel hochgeladene Bilder sein.
3.8.2. Struktur
Über eine vom Speichermedium unabhängige Zwischenschicht werden
+ Formats,
sowie speziel für Artikel hochgeladene Bilder sein.
3.8.2. Struktur
Über eine vom Speichermedium unabhängige Zwischenschicht werden
die Dateien und ihre Versionen in der Datenbank verwaltet. Darunter
können verschiedene Implementierungen (Backends) gleichzeitig
existieren:
Dateisystem
WebDAV
Schnittstelle zu externen
@@ -23,7 +23,7 @@
für "attachment" und "image" nur die Quelle "uploaded". Für "document"
gibt es auf jeden Fall die Quelle "created". Die Quellen "scanner" und
"email" müssen derzeit in der Datenbank konfiguriert werden (siehe
- Datenbank-Konfigurierung).
Die Daten werden bei den ERP-Objekten als extra Reiter
dargestellt. Eine Verkaufsrechnung z.B. hat die Reiter "Dokumente" und
"Dateianhänge".
Bei den Dateianhängen wird immer nur die aktuelle Version einer
Datei angezeigt. Wird eine Datei mit gleichem Namen hochgeladen, so
@@ -39,13 +39,13 @@
so sind diese z.B. bei Einkaufsrechnungen sichtbar:
Statt des Löschens wird hier die Datei zurück zur Quelle
verschoben. Somit kann die Datei anschließend an ein anderes
ERP-Objekt angehängt werden.
Derzeit sind "Titel" und "Beschreibung" noch nicht genutzt. Sie
- sind bisher nur bei Bildern relevant.
3.8.4. Konfigurierung
3.8.4.1. Mandantenkonfiguration
3.8.4.1.1. Reiter "Features"
Unter dem Reiter Features
+ sind bisher nur bei Bildern relevant.
3.8.4. Konfigurierung
3.8.4.1. Mandantenkonfiguration
3.8.4.1.1. Reiter "Features"
Unter dem Reiter Features
im Abschnitt Dateimanagement ist neben dem "alten" WebDAV das
Dateimangement generell zu- und abschaltbar, sowie die Zuordnung
der Dateitypen zu Backends. Die Löschbarkeit von Dateien, sowie
die maximale Uploadgröße sind Backend-unabhängig
Die einzelnen Backends sind einzeln einschaltbar.
Spezifische Backend-Konfigurierungen sind hier noch
- ergänzbar.
3.8.4.1.2. Reiter "Allgemeine Dokumentenanhänge"
Unter dem Reiter Allgemeine
+ ergänzbar.
3.8.4.1.2. Reiter "Allgemeine Dokumentenanhänge"
Unter dem Reiter Allgemeine
Dokumentenanhänge kann für alle ERP-Dokumente (
Angebote, Aufträge, Lieferscheine, Rechnungen im Verkauf und
Einkauf ) allgemeingültige Anhänge hochgeladen werden.
Diese Anhänge werden beim Generieren von PDF-Dateien an die
diff --git a/doc/html/ch03s09.html b/doc/html/ch03s09.html
index f2e07450b3..15aa468c02 100644
--- a/doc/html/ch03s09.html
+++ b/doc/html/ch03s09.html
@@ -1,13 +1,13 @@
Das Shopmodul bietet die Möglichkeit Onlineshopartikel und
Onlineshopbestellungen zu verwalten und zu bearbeiten.
Es ist Multishopfähig, d.h. Artikel können mehreren oder
unterschiedlichen Shops zugeordnet werden. Bestellungen können aus
mehreren Shops geholt werden.
Zur Zeit bietet das Modul nur einen Connector zur REST-Api von
Shopware. Weitere Connectoren können dazu programmiert und eingerichtet
- werden.
3.9.1. Rechte für die Webshopapi
In der Administration können folgende Rechte vergeben
- werden
Webshopartikel anlegen und bearbeiten
Shopbestellungen holen und bearbeiten
Shop anlegen und bearbeiten
3.9.2. Konfiguration
Unter System->Webshops können Shops angelegt und konfiguriert
- werden
3.9.3. Webshopartikel
3.9.3.1. Shopvariablenreiter in Artikelstammdaten
Mit dem Recht "Shopartikel anlegen und bearbeiten" und des
+ werden.
3.9.1. Rechte für die Webshopapi
In der Administration können folgende Rechte vergeben
+ werden
Webshopartikel anlegen und bearbeiten
Shopbestellungen holen und bearbeiten
Shop anlegen und bearbeiten
3.9.2. Konfiguration
Unter System->Webshops können Shops angelegt und konfiguriert
+ werden
3.9.3. Webshopartikel
3.9.3.1. Shopvariablenreiter in Artikelstammdaten
Mit dem Recht "Shopartikel anlegen und bearbeiten" und des
Markers "Shopartikel" in den Basisdaten
zeigt sich der Reiter "Shopvariablen" in den
Artikelstammdaten. Hier können jetzt die Artikel mit
@@ -16,11 +16,11 @@
Stelle können auch beliebig viele Bilder dem Shopartikel zugeordnet
werden. Artikelbilder gelten für alle Shops.
Die Artikelgruppen werden direkt vom Shopsystem geholt somit
ist es möglich einen Artikel auch mehreren Gruppen
- zuzuordenen
3.9.3.2. Shopartikelliste
Unter dem Menu Webshop->Webshop Artikel hat man nochmal
+ zuzuordenen
3.9.3.2. Shopartikelliste
Unter dem Menu Webshop->Webshop Artikel hat man nochmal
eine Gesamtübersicht. Von hier aus ist es möglich Artikel im Stapel
unter verschiedenen Kriterien <alles><nur Preis><nur
Bestand><Preis und Bestand> an die jeweiligen Shops
- hochzuladen.
3.9.4. Bestellimport
Unter dem Menupunkt Webshop->Webshop Import öffnet sich die
+ hochzuladen.
3.9.4. Bestellimport
Unter dem Menupunkt Webshop->Webshop Import öffnet sich die
Bestellimportsliste. Hier ist sind Möglichkeiten gegeben Neue
Bestellungen vom Shop abzuholen, geholte Bestellungen im Stapel oder
einzeln als Auftrag zu transferieren. Die Liste kann nach
@@ -52,7 +52,7 @@
auch der Grund für die Auftragssperre sein.
Die Buttons "Auftrag erstellen" und "Kunde mit
Rechnungsadresse überschreiben" zeigen sich erst, wenn ein Kunde
aus dem Listing ausgewählt ist.
Es ist aber möglich die Shopbestellung zu löschen.
Ist eine Bestellung schon übernommen, zeigen sich an dieser
- Stelle, die dazugehörigen Belegverknüpfungen.
3.9.5. Mapping der Daten
Das Mapping der kivitendo Daten mit den Shopdaten geschieht in
+ Stelle, die dazugehörigen Belegverknüpfungen.
3.9.5. Mapping der Daten
Das Mapping der kivitendo Daten mit den Shopdaten geschieht in
der Datei SL/ShopConnector/<SHOPCONNECTORNAME>.pm
z.B.:SL/ShopConnector/Shopware.pm
In dieser Datei gibt es einen Bereich wo die Bestellpostionen,
die Bestellkopfdaten und die Artikeldaten gemapt werden. In dieser
diff --git a/doc/html/ch03s10.html b/doc/html/ch03s10.html
index e546f75aaf..ee998a46c8 100644
--- a/doc/html/ch03s10.html
+++ b/doc/html/ch03s10.html
@@ -1,6 +1,6 @@
Für die Erstellung von ZUGFeRD PDFs wird TexLive2018 oder höher benötigt.
Anmerkung
Wer kein TexLive2018 oder höher installieren kann, kann eine lokale Umgebung nur für kivitendo wie folgt erzeugen:
@@ -35,12 +35,12 @@
3.10.3. Erstellen von ZUGFeRD Rechnungen in Kivitendo
Für die Erstellung von ZUGFeRD Rechnungen bedarf es in
kivitendo zwei Dinge:
Die Erstellung muss in der Mandantenkonfiguration
aktiviert sein
Beim mindestens einem Bankkonto muss die Option
- „Nutzung von ZUGFeRD“ aktiviert sein
3.10.3.1. Mandantenkonfiguration
Die Einstellung für die Erstellung von ZUGFeRD Rechnungen
+ „Nutzung von ZUGFeRD“ aktiviert sein
3.10.3.1. Mandantenkonfiguration
Die Einstellung für die Erstellung von ZUGFeRD Rechnungen
erfolgt unter „System“ → „Mandatenkonfiguration“ → „Features“.
Im Abschnitt „Einkauf und Verkauf“ finden Sie die Einstellung
„Verkaufsrechnungen mit ZUGFeRD-Daten erzeugen“.
Hier besteht die Auswahl zwischen:
ZUGFeRD-Rechnungen erzeugen
ZUGFeRD-Rechnungen im Testmodus erzeugen
Keine ZUGFeRD Rechnungen erzeugen
Rechnungen die als PDF erzeugt werden, werden je nach
- Einstellung nun im ZUGFeRD Format ausgegeben.
3.10.3.2. Konfiguration der Bankkonten
Unter „System → Bankkonten“ muss bei mindestens einem
+ Einstellung nun im ZUGFeRD Format ausgegeben.
3.10.3.2. Konfiguration der Bankkonten
Unter „System → Bankkonten“ muss bei mindestens einem
Bankkonto die Option „Nutzung mit ZUGFeRD“ auf „Ja“ gestellt
werden.
3.10.4. Einlesen von ZUGFeRD Rechnungen in Kivitendo
Es lassen sich auch Rechnungen von Kreditoren, die im
ZUGFeRD Format erstellt wurden, nach Kivitendo importieren.
diff --git a/doc/html/ch03s11.html b/doc/html/ch03s11.html
index 23e392e160..64b2ef2359 100644
--- a/doc/html/ch03s11.html
+++ b/doc/html/ch03s11.html
@@ -1,5 +1,5 @@
Reklamationen dienen dazu im Verkauf die Kundenzufriedenheit zu verbessern und Fehler in der Abwicklung von Aufträgen aufzuspüren und dann zu vermeiden.
Im Einkauf helfen Reklamationen beanstandete Lieferungen zu verwalten und zu kontrollieren.
3.11.1. Konfiguration des Reklamationsmodul
Unter dem Menu "System->Reklamationsgründe" muss mindestens ein Reklamationsgrund erfasst werden.
Aufgrund der Gründe können später in den Berichten Auswertungen gemacht werden.
3.11.2. Reklamation erfassen
Aus den Belegen EK/VK Auftrag, EK/VK Lieferschein, EK/VK Rechnung kann unter "Workflow->Reklöamation erfassen" eine dem Workflow zugehörige Reklamation erfasst werden.
+
Reklamationen dienen dazu im Verkauf die Kundenzufriedenheit zu verbessern und Fehler in der Abwicklung von Aufträgen aufzuspüren und dann zu vermeiden.
Im Einkauf helfen Reklamationen beanstandete Lieferungen zu verwalten und zu kontrollieren.
3.11.1. Konfiguration des Reklamationsmodul
Unter dem Menu "System->Reklamationsgründe" muss mindestens ein Reklamationsgrund erfasst werden.
Aufgrund der Gründe können später in den Berichten Auswertungen gemacht werden.
3.11.2. Reklamation erfassen
Aus den Belegen EK/VK Auftrag, EK/VK Lieferschein, EK/VK Rechnung kann unter "Workflow->Reklöamation erfassen" eine dem Workflow zugehörige Reklamation erfasst werden.
Die Reklamationsmaske ähnelt im großem die der Auftragsmaske.
Es werden alle Positionen aus dem Beleg übernomen. Deswegen müssen hie die Positionen angepasst werden.
- Zusätzlich muss noch ein Reklamationsgrund angegeben werden.
Die Reklamationsgründe sind für spätere Auswertungen notwendig
Anmerkung
Anmerkung: Da bei einem Auftrag, sowohl im EK als auch im VK, noch keine Ware versendet bzw. empfangen wurde, könnte hier ein Reklamationsgrund "Lieferver sein.
3.11.3. Reklamationen auswerten
Bisher gibt es nur eine Liste mit Reklamationen und deren Filtermöglichkeiten.
Einen individuellen Reklamationsbericht kann über einen "benutzerdefinierten Datenexport" erstellt werden
\ No newline at end of file
+ Zusätzlich muss noch ein Reklamationsgrund angegeben werden.
Die Reklamationsgründe sind für spätere Auswertungen notwendig
Anmerkung
Anmerkung: Da bei einem Auftrag, sowohl im EK als auch im VK, noch keine Ware versendet bzw. empfangen wurde, könnte hier ein Reklamationsgrund "Lieferver sein.
3.11.3. Reklamationen auswerten
Bisher gibt es nur eine Liste mit Reklamationen und deren Filtermöglichkeiten.
Einen individuellen Reklamationsbericht kann über einen "benutzerdefinierten Datenexport" erstellt werden
\ No newline at end of file
diff --git a/doc/html/ch03s12.html b/doc/html/ch03s12.html
index c8434edfff..9d50a9be13 100644
--- a/doc/html/ch03s12.html
+++ b/doc/html/ch03s12.html
@@ -1,14 +1,14 @@
- 3.12. Dispositionsmanager/Einkaufshelfer
Der Einkaufshelfer generiert Lieferantenaufträge anhand eines Warenkorbes. Der Warenkorb kann
einzeln oder mit dem Meldebestandsbericht gefüllt werden. Mit dem Filter „Lieferant“ im
Warenkorb werden die Artikel einem Lieferanten zugeordnet und können dann bestellt, d.h. ein
- Lieferantenauftragerstellt, werden.
3.12.1. So kommen die Artikel in den Einkaufswarenkorb:
1) Sofern ein Artikel einen oder mehrere Lieferanten hat kann dieser über den Button „Einkaufen“
+ Lieferantenauftragerstellt, werden.
3.12.1. So kommen die Artikel in den Einkaufswarenkorb:
1) Sofern ein Artikel einen oder mehrere Lieferanten hat kann dieser über den Button „Einkaufen“
in den Einkaufswarenkorn gelegt werden. Soll der Einkauf über den Mindestlagerbestand gesteuert werden sind die Felder "Mindestlagerbestand" und "Bestellmenge" auszufüllen.
Der Button „Einkaufen“ ist deaktiviert, wenn es keinen Lieferanten zu diesem Artikel gibt oder der
Artikel schon im Einkaufswarenkorb liegt.
2) Bericht „Meldebestand“
Über das Menu "Einkauf->Meldebestand" kann der Meldebestand abgerufen werden
Die obere Tabelle zeigt die Artikel an, die den Mindestbestand unterschritten haben und können
sofern markiert über die Aktion "Einkaufen" in den Einkaufswarenkorb gelegt werden. Hierzu muss
- das Feld Mindesbestand in den Artikelstammdaten einen Wert > 0 haben
Die untere Tabelle zeigt die Artikel an, die den Mindestbestand unterschritten haben aber bestellt sind.
3.12.2. Der Einkaufswarenkorb
Ohne Filter: der erste Lieferant ist ausgewählt. Hier kann jetzt auch ein anderer Lieferant
+ das Feld Mindesbestand in den Artikelstammdaten einen Wert > 0 haben
Die untere Tabelle zeigt die Artikel an, die den Mindestbestand unterschritten haben aber bestellt sind.
3.12.2. Der Einkaufswarenkorb
Ohne Filter: der erste Lieferant ist ausgewählt. Hier kann jetzt auch ein anderer Lieferant
ausgewählt werden.
Wird dann nach einem Lieferanten gefiltert und dieser ist und bleibt eindeutig, kann daraus ein
Lieferantenauftrag erstellt werden.
Die obere Tabelle zeigt die Artikel an, die den Mindestbestand unterschritten haben, der untere Teil zeigt alle
Artikel des Lieferanten an, somit ist es möglich diese Artikel auszuwählen und gleich mitzubestellen
\ No newline at end of file
diff --git a/doc/html/ch03s13.html b/doc/html/ch03s13.html
index 17adc0b3e8..ffa5e05f62 100644
--- a/doc/html/ch03s13.html
+++ b/doc/html/ch03s13.html
@@ -1,6 +1,6 @@
- 3.13. Zeiterfassung
Seit der Version 3.5.7 enthält kivitendo ein Modul zur Zeiterfassung.
Damit ist es möglich, auftrags-, kunden- oder projektbezogen,
Arbeitszeiten zu erfassen. Die erfassten Zeiten können über einen
diff --git a/doc/html/ch04.html b/doc/html/ch04.html
index a068bb1022..e0864ded39 100644
--- a/doc/html/ch04.html
+++ b/doc/html/ch04.html
@@ -1,6 +1,6 @@
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 Datumsformat dateformat und
@@ -122,10 +122,10 @@
überwiegend die Daten, die sich unter Programm
-> Einstellungen befinden, bzw. die
Informationen über den Benutzer die über die
- Administrator-Schnittstelle 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 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,7 +135,7 @@
"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
@@ -144,7 +144,7 @@
Dessen Einstellungen können über
$::auth->client abgefragt werden; Rückgabewert
ist ein Hash mit den Werten aus der Tabelle
- auth.clients.
4.1.3.6. $::lx_office_conf
Objekt der Klasse
+ auth.clients.
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
@@ -154,16 +154,16 @@
file_name = /tmp/kivitendo-debug.log
ist der Key file im Programm als
$::lx_office_conf->{debug}{file}
erreichbar.
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
- 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
@@ -176,20 +176,20 @@
$::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.
\ No newline at end of file
diff --git a/doc/html/ch04s02.html b/doc/html/ch04s02.html
index 115f14d783..4231121394 100644
--- a/doc/html/ch04s02.html
+++ b/doc/html/ch04s02.html
@@ -1,6 +1,6 @@
- 4.2. Entwicklung unter FastCGI
Wenn Änderungen in der Konfiguration von kivitendo gemacht
werden, muss der Webserver neu gestartet werden.
Bei der Entwicklung für FastCGI ist auf ein paar Fallstricke zu
achten. Dadurch, dass das Programm in einer Endlosschleife läuft,
müssen folgende Aspekte beachtet werden.
4.2.2. Programmende und Ausnahmen
Betrifft die Funktionen warn,
diff --git a/doc/html/ch04s03.html b/doc/html/ch04s03.html
index da4eedf337..f720050192 100644
--- a/doc/html/ch04s03.html
+++ b/doc/html/ch04s03.html
@@ -1,6 +1,6 @@
Es ist möglich, Funktionen in kivitendo programmatisch aus anderen Programmen aufzurufen. Dazu ist nötig, dass
Authentifizierungsinformationen in jedem Aufruf mitgegeben werden. Dafür gibt es zwei Methoden: die HTTP-»Basic«-Authentifizierung
oder die Übergabe als spziell benannte GET-Parameter. Neben den Authentifizierungsinformationen muss auch der zu verwendende Mandant
diff --git a/doc/html/ch04s04.html b/doc/html/ch04s04.html
index 195c255823..c508ddbdc0 100644
--- a/doc/html/ch04s04.html
+++ b/doc/html/ch04s04.html
@@ -1,6 +1,6 @@
Datenbankupgrades werden über einzelne Upgrade-Scripte
gesteuert, die sich im Verzeichnis
sql/Pg-upgrade2 befinden. In diesem Verzeichnis
muss pro Datenbankupgrade eine Datei existieren, die neben den
diff --git a/doc/html/ch04s05.html b/doc/html/ch04s05.html
index fd0e6329d7..9e91234b3f 100644
--- a/doc/html/ch04s05.html
+++ b/doc/html/ch04s05.html
@@ -1,6 +1,6 @@
Dieser Abschnitt ist in Englisch geschrieben, um
internationalen Übersetzern die Arbeit zu erleichtern.
This section describes how localization packages in kivitendo
are built. Currently the only language fully supported is German, and
since most of the internal messages are held in English the English
diff --git a/doc/html/ch04s06.html b/doc/html/ch04s06.html
index 3654bfe2cd..d240e0d447 100644
--- a/doc/html/ch04s06.html
+++ b/doc/html/ch04s06.html
@@ -1,6 +1,6 @@
Die folgenden Regeln haben das Ziel, den Code möglichst gut les-
und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich
eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden
wird (Stichworte "Klammern" oder "Hash-Keys").
Diese Regeln sind keine Schikane sondern erleichtern allen das
diff --git a/doc/html/ch04s08.html b/doc/html/ch04s08.html
index ab3561f65e..6a72636800 100644
--- a/doc/html/ch04s08.html
+++ b/doc/html/ch04s08.html
@@ -1,6 +1,6 @@
Diese Dokumentation ist in DocBook™
XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor.
Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen
Editor nutzt, der spezielle Unterstützung für
diff --git a/doc/html/index.html b/doc/html/index.html
index 6dc1c31b13..01d53d6bbc 100644
--- a/doc/html/index.html
+++ b/doc/html/index.html
@@ -1,9 +1,9 @@
- kivitendo 3.9.0: Installation, Konfiguration, Entwicklung
kivitendo 3.9.0: Installation, Konfiguration,
- Entwicklung
\ No newline at end of file
diff --git a/doc/kivitendo-Dokumentation.pdf b/doc/kivitendo-Dokumentation.pdf
index ea1a1f17ea..c06aded64d 100644
Binary files a/doc/kivitendo-Dokumentation.pdf and b/doc/kivitendo-Dokumentation.pdf differ
![[Anmerkung]](system/docbook-xsl/images/note.png)
![[Tipp]](system/docbook-xsl/images/tip.png)
![[Warnung]](system/docbook-xsl/images/warning.png)