X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/0fe866714abb2a0a63653afcded66b89d0ebe69f..HEAD:/doc/html/ch02s11.html diff --git a/doc/html/ch02s11.html b/doc/html/ch02s11.html index 1e6b10d28..23d633576 100644 --- a/doc/html/ch02s11.html +++ b/doc/html/ch02s11.html @@ -1,101 +1,83 @@
-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
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 auf.
Wählen Sie dort einen Benutzer aus oder legen Sie einen neuen an. In der Benutzerbearbeiten-Maske müssen Sie zwei Dinge - angeben:
- Name: Der Verzeichnisname für den neuen Vorlagensatz. Dieser kann im Rahmen der üblichen
- Bedingungen für Verzeichnisnamen frei gewählt werden.
- 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
Der Standard-Vorlagensatz von Kivitendo. Wie unter http://demo.kivitendo.org zu - sehen.
Ein Vorlagensatz, der in wenigen Minuten alle Dokumente zur Verfügung stellt.
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.
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.
-
- 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.
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.
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.
-
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.
Nach der Installation müssen Mandanten, Benutzer, Gruppen und + Datenbanken angelegt werden. Dieses geschieht im Administrationsmenü, + das Sie unter folgender URL finden:
+ http://localhost/kivitendo-erp/controller.pl?action=Admin/login +
Verwenden Sie zur Anmeldung das Passwort, das Sie in der Datei
+ config/kivitendo.conf eingetragen haben.
kivitendo verwaltet zwei Sets von Daten, die je nach Einrichtung + in einer oder zwei Datenbanken gespeichert werden.
Das erste Set besteht aus Anmeldeinformationen: welche Benutzer
+ und Mandanten gibt es, welche Gruppen, welche BenutzerIn hat Zugriff
+ auf welche Mandanten, und welche Gruppe verfügt über welche Rechte.
+ Diese Informationen werden in der Authentifizierungsdatenbank
+ gespeichert. Dies ist diejenige Datenbank, deren Verbindungsparameter
+ in der Konfigurationsdatei config/kivitendo.conf
+ gespeichert werden.
Das zweite Set besteht aus den eigentlichen Verkehrsdaten eines + Mandanten, wie beispielsweise die Stammdaten (Kunden, Lieferanten, + Waren) und Belege (Angebote, Lieferscheine, Rechnungen). Diese werden + in einer Mandantendatenbank gespeichert. Die Verbindungsinformationen + einer solchen Mandantendatenbank werden im Administrationsbereich + konfiguriert, indem man einen Mandanten anlegt und dort die Parameter + einträgt. Dabei hat jeder Mandant eine eigene Datenbank.
Aufgrund des Datenbankdesigns ist es für einfache Fälle möglich, + die Authentifizierungsdatenbank und eine der Mandantendatenbanken in + ein und derselben Datenbank zu speichern. Arbeitet man hingegen mit + mehr als einem Mandanten, wird empfohlen, für die + Authentifizierungsdatenbank eine eigene Datenbank zu verwenden, die + nicht gleichzeitig für einen Mandanten verwendet wird.
kivitendos Administration kennt Mandanten, Benutzer und Gruppen, + die sich frei zueinander zuordnen lassen.
kivitendo kann mehrere Mandaten aus einer Installation heraus + verwalten. Welcher Mandant benutzt wird, kann direkt beim Login + ausgewählt werden. Für jeden Mandanten wird ein eindeutiger Name + vergeben, der beim Login angezeigt wird. Weiterhin benötigt der + Mandant Datenbankverbindungsparameter für seine Mandantendatenbank. + Diese sollte über die Datenbankverwaltung + geschehen.
Ein Benutzer ist eine Person, die Zugriff auf kivitendo erhalten + soll. Sie erhält einen Loginnamen sowie ein Passwort. Weiterhin legt + der Administrator fest, an welchen Mandanten sich ein Benutzer + anmelden kann, was beim Login verifiziert wird.
Gruppen dienen dazu, Benutzern innerhalb eines Mandanten Zugriff + auf bestimmte Funktionen zu geben. Einer Gruppe werden dafür vom + Administrator gewisse Rechte zugeordnet. Weiterhin legt der + Administrator fest, für welche Mandanten eine Gruppe gilt, und welche + Benutzer Mitglieder in dieser Gruppe sind. Meldet sich ein Benutzer + dann an einem Mandanten an, so erhält er alle Rechte von allen + denjenigen Gruppen, die zum Einen dem Mandanten zugeordnet sind und in + denen der Benutzer zum Anderen Mitglied ist,
Die Reihenfolge, in der Datenbanken, Mandanten, Gruppen und + Benutzer angelegt werden, kann im Prinzip beliebig gewählt werden. Die + folgende Reihenfolge beinhaltet die wenigsten Arbeitsschritte:
Datenbank anlegen
Gruppen anlegen
Benutzer anlegen und Gruppen als Mitglied zuordnen
Mandanten anlegen und Gruppen sowie Benutzer zuweisen
Zuerst muss eine Datenbank angelegt werden. Verwenden Sie für
+ den Datenbankzugriff den vorhin angelegten Benutzer (in unseren
+ Beispielen ist dies âkivitendoâ).
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 werden zwar in der Authentifizierungsdatenbank + gespeichert, gelten aber nicht automatisch für alle Mandanten. Der + Administrator legt vielmehr fest, für welche Mandanten eine Gruppe + gültig ist. Dies kann entweder beim Bearbeiten der Gruppe geschehen + ("diese Gruppe ist gültig für Mandanten X, Y und Z"), oder aber wenn + man einen Mandanten bearbeitet ("für diesen Mandanten sind die Gruppen + A, B und C gültig").
Wurden bereits Benutzer angelegt, so können hier die Mitglieder + dieser Gruppe festgelegt werden ("in dieser Gruppe sind die Benutzer + X, Y und Z Mitglieder"). Dies kann auch nachträglich beim Bearbeiten + eines Benutzers geschehen ("dieser Benutzer ist Mitglied in den + Gruppen A, B und C").
Beim Anlegen von Benutzern werden für viele Parameter + Standardeinstellungen vorgenommen, die den Gepflogenheiten des + deutschen Raumes entsprechen.
Zwingend anzugeben ist der Loginname. 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.
Hat man bereits Mandanten und Gruppen angelegt, so kann hier + auch konfiguriert werden, auf welche Mandanten der Benutzer Zugriff + hat bzw. in welchen Gruppen er Mitglied ist. Beide Zuweisungen können + sowohl beim Benutzer vorgenommen werden ("dieser Benutzer hat Zugriff + auf Mandanten X, Y, Z" bzw. "dieser Benutzer ist Mitglied in Gruppen + X, Y und Z") als auch beim Mandanten ("auf diesen Mandanten haben + Benutzer A, B und C Zugriff") bzw. bei der Gruppe ("in dieser Gruppe + sind Benutzer A, B und C Mitglieder").
Ein Mandant besteht aus Administrationssicht primär aus einem + eindeutigen Namen. Weiterhin wird hier hinterlegt, welche Datenbank + als Mandantendatenbank benutzt wird. Hier müssen die Zugriffsdaten + einer der eben angelegten Datenbanken eingetragen werden.
Hat man bereits Benutzer und Gruppen angelegt, so kann hier auch + konfiguriert werden, welche Benutzer Zugriff auf den Mandanten haben + bzw. welche Gruppen für den Mandanten gültig sind. Beide Zuweisungen + können sowohl beim Mandanten vorgenommen werden ("auf diesen Mandanten + haben Benutzer X, Y und Z Zugriff" bzw. "für diesen Mandanten sind die + Gruppen X, Y und Z gültig") als auch beim Benutzer ("dieser Benutzer + hat Zugriff auf Mandanten A, B und C") bzw. bei der Gruppe ("diese + Gruppe ist für Mandanten A, B und C gültig").