From: Jan Büren
- <DirectoryMatch "(\.git|config)/"> + <DirectoryMatch "/(\.git|config)/"> Require all denied </DirectoryMatch>
diff --git a/doc/html/ch02s12.html b/doc/html/ch02s12.html index 5faec2fe0..5f783e5ef 100644 --- a/doc/html/ch02s12.html +++ b/doc/html/ch02s12.html @@ -14,8 +14,8 @@
zypper install texlive-collection-latex texlive-collection-latexextra \ texlive-collection-latexrecommended texlive-collection-langgerman \ texlive-collection-langenglish
-
kivitendo bringt drei alternative Vorlagensätze mit:
RB
f-tex
rev-odt
Der ehemalige Druckvorlagensatz "Standard" wurde mit der Version - 3.3 entfernt, da er nicht mehr gepflegt wurde.
Es lässt sich ein initialer Vorlagensatz erstellen. Die +
Anmerkung | |
---|---|
kivitendo erwartet eine aktuelle TeX Live Umgebung, um PDF/A zu erzeugen. Aktuelle Distributionen von 2020 erfüllen diese. Ãberprüfbar ist dies mit dem Aufruf des installation_check.pl mit Parameter -l: scripts/installations_check.pl -l |
kivitendo bringt drei alternative Vorlagensätze mit:
RB
marei
rev-odt
Der ehemalige Druckvorlagensatz "f-tex" wurde mit der Version + 3.6 entfernt, da er nicht mehr gepflegt wird.
Es lässt sich ein initialer Vorlagensatz erstellen. Die LaTeX-System-Abhängigkeiten hierfür kann man prüfen mit:
./scripts/installation_check.pl -lv
Der Angemeldete Benutzer muss in einer Gruppe sein, die über das Recht "Konfiguration -> Mandantenverwaltung" verfügt. Siehe auch Abschnitt 2.9.4, âGruppen anlegenâ.
Im Userbereich lässt sich unter: "
@@ -24,7 +24,7 @@ Druckvorlagen aus Vorlagensatz erstellen" auswählen.
Vorlagen auswählen
: Wählen Sie hier den
Vorlagensatz aus, der kopiert werden soll
- (RB
, f-tex
oder
+ (RB
, marei
oder
odt-rev
.)
Neuer Name
: Der Verzeichnisname für den
neuen Vorlagensatz. Dieser kann im Rahmen der üblichen Bedingungen
@@ -44,102 +44,7 @@
werden, z.B. für Kopf- und FuÃzeilen, und Infos wie
Bankdaten
mehrere vordefinierte Varianten für Logos/Hintergrundbilder
Berücksichtigung für Steuerzonen "EU mit USt-ID Nummer" oder - "AuÃerhalb EU"
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, Proformarechnung, Lieferschein, aber eben nicht für - Paketaufkleber etc.
Leichte Anpassung an das Firmen-Layout durch Verwendung - eines Hintergrund-PDFs. 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 Hintergrund-PDF verwiesen. Ich empfehle
- über dieses PDF die persönlichen Layoutanpassungen vorzunehmen und
- sample.lco
unverändert zu lassen. 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_head.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.
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
- heftig 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 als auch 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 Nettopreise 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 revidiert 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.
Hierbei handelt es sich um einen Dokumentensatz der mit odt-Vorlagen erstellt wurde. Es gibt in dem Verzeichnis eine Readme-Datei, die eventuell aktueller als die Dokumentation hier ist. Die odt-Vorlagen in diesem Verzeichnis "rev-odt" wurden von revamp-it, @@ -166,7 +71,7 @@ die verrechneten Mahngebühren und Verzugszinsen.
Zur Zeit gibt es in kivitendo noch keine Möglichkeit, odt-Vorlagen bei Briefen und Pflichtenheften einzusetzen. Entsprechende Vorlagen sind deshalb nicht vorhanden.
Fehlermeldungen, Anregungen und Wünsche bitte senden an: - empfang@revamp-it.ch
In den allermeisten Installationen sollte das Drucken jetzt + empfang@revamp-it.ch
In den allermeisten Installationen sollte das Drucken jetzt schon funktionieren. Sollte ein Fehler auftreten, wirft TeX sehr lange Fehlerbeschreibungen, der eigentliche Fehler ist immer die erste Zeile, die mit einem Ausrufezeichen anfängt. Häufig auftretende Fehler diff --git a/doc/html/ch02s13.html b/doc/html/ch02s13.html index c59057144..5c4891415 100644 --- a/doc/html/ch02s13.html +++ b/doc/html/ch02s13.html @@ -63,14 +63,14 @@ Verzeichnis umbenannt werden.
Dieses Verzeichnis, wie auch das komplette
users
-Verzeichnis, muss vom Webserver beschreibbar
sein. Dieses wurde bereits erledigt (siehe Manuelle Installation des Programmpaketes), kann aber erneut
- überprüft werden, wenn die Konvertierung nach PDF fehlschlägt.
OpenDocument Vorlagen können Makros enthalten, welche komplexere + überprüft werden, wenn die Konvertierung nach PDF fehlschlägt.
OpenDocument Vorlagen können Makros enthalten, welche komplexere Aufgaben erfüllen.
Der Vorlagensatz "rev-odt" enthält solche Vorlagen mit Schweizer Bank-Einzahlungsscheinen (BESR). Diese Makros haben die Aufgabe, die in den Einzahlungsscheinen benötigte Referenznummer und Kodierzeile zu erzeugen. Hier eine kurze Beschreibung, wie die Makros aufgebaut sind, und was bei ihrer Nutzung zu beachten ist (in fett sind nötige einmalige - Anpassungen aufgeführt):
Damit beim Erstellen von Rechnungen und Aufträgen neben der + Anpassungen aufgeführt):
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 @@ -79,11 +79,11 @@ 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
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
In der Vorlage sind als Modul "BESR" 4 Makros gespeichert, die aus dem von kivitendo erzeugten odt-Dokument die korrekte Referenznummer inklusive Prüfziffer sowie die Kodierzeile in OCRB-Schrift erzeugen und am richtigen Ort ins Dokument @@ -112,12 +112,12 @@ angepasst werden. Dabei ist darauf zu achten, dass sich die Positionen der Postkonto-Nummern der Bank, sowie der Zeichenfolgen dddfr, DDDREF1, DDDREF2, 609, DDDKODIERZEILE nicht - verschieben.
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.
Falls beim Ãffnen einer von kivitendo erzeugten odt-Rechnung + wurde.
Falls beim Ãffnen einer von kivitendo erzeugten odt-Rechnung die Meldung kommt, dass Makros aus Sicherheitsgründen nicht ausgeführt werden, so müssen folgende Einstellungen in LibreOffice angepasst werden:
Extras â Optionen â Sicherheit â Makrosicherheit
Sicherheitslevel auf "Mittel" einstellen (Diese
diff --git a/doc/html/ch03s03.html b/doc/html/ch03s03.html
index e64368eea..fbc4f88d3 100644
--- a/doc/html/ch03s03.html
+++ b/doc/html/ch03s03.html
@@ -617,7 +617,7 @@
invdate
Rechnungsdatum
invnumber
- Rechnungsnummer
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/ch03s07.html b/doc/html/ch03s07.html
index ce29a7a81..8831e4e23 100644
--- a/doc/html/ch03s07.html
+++ b/doc/html/ch03s07.html
@@ -1,15 +1,15 @@
Die Klassifizierung von Artikeln dient einer weiteren +
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.
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.
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
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
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%>.
Der Typ des Artikels und die Klassifizierung werden durch zwei + <%separate_M_subtotal%>.
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 523930e20..06ef0ccb8 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, +
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.
Ãber eine vom Speichermedium unabhängige Zwischenschicht werden + Formats,
sowie speziel für Artikel hochgeladene Bilder sein.
Ã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 + 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.
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.
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 4e146dc56..7586da908 100644 --- a/doc/html/ch03s09.html +++ b/doc/html/ch03s09.html @@ -1,13 +1,13 @@
-Das Shopmodul bietet die Möglichkeit Onlineshopartikel und +
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.
In der Administration können folgende Rechte vergeben - werden
Webshopartikel anlegen und bearbeiten
Shopbestellungen holen und bearbeiten
Shop anlegen und bearbeiten
Mit dem Recht "Shopartikel anlegen und bearbeiten" und des + werden.
In der Administration können folgende Rechte vergeben + werden
Webshopartikel anlegen und bearbeiten
Shopbestellungen holen und bearbeiten
Shop anlegen und bearbeiten
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
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.
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 99c9db07d..949375af7 100644 --- a/doc/html/ch03s10.html +++ b/doc/html/ch03s10.html @@ -35,12 +35,12 @@
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
Die Einstellung für die Erstellung von ZUGFeRD Rechnungen + âNutzung von ZUGFeRDâ aktiviert sein
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.
Unter âSystem â Bankkontenâ muss bei mindestens einem + Einstellung nun im ZUGFeRD Format ausgegeben.
Es lassen sich auch Rechnungen von Kreditoren, die im ZUGFeRD Format erstellt wurden, nach Kivitendo importieren. diff --git a/doc/html/ch04.html b/doc/html/ch04.html index 6f8b6f0f6..3d5642df8 100644 --- a/doc/html/ch04.html +++ b/doc/html/ch04.html @@ -1,6 +1,6 @@
-Globale Variablen liegen in einem speziellen namespace namens +
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:
$PACKAGE::form
.local $form
Alle Ãnderungen an $form
werden am Ende
- des scopes zurückgesetzt
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.
Um dieses Problem im Griff zu halten gibt es einige wenige + schnell ein Tippfehler einschleichen.
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):
Ist ein Objekt der Klasse + Eigenschaften (Konventionen):
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"}; # ... -}
Das einzige Hash unter den globalen Variablen
Wird spätestens benötigt wenn auf die Datenbank +}
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
-> befinden, bzw. die Informationen über den Benutzer die über die - Administrator-Schnittstelle eingegeben wurden.Objekt der Klasse "Locale"
Wird pro Request erstellt
Muss auch für Tests und Scripte immer verfügbar + Administrator-Schnittstelle eingegeben wurden.
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.
Objekt der Klasse "LXDebug"
Wird global gecached
Muss immer verfügbar sein, in nahezu allen + Zahlen- und Datumsformatierungen laufen über dieses Objekt.
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});
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});
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 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{
Dessen Einstellungen können über
$::auth->client
abgefragt werden; Rückgabewert
ist ein Hash mit den Werten aus der Tabelle
- auth.clients
.
Objekt der Klasse
+ auth.clients
.
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 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{ 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. |
Objekt der Klasse + Hashkeys, sind also nicht gegen Tippfehler abgesichert.
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.
Objekt der Klasse + ob die berüchtigte Bestandsmethode zur Anwendung kommt.
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.
Hashref (evtl später Objekt)
Wird pro Request neu initialisiert.
Keine Unterstruktur garantiert.
+ Objekt untergebracht.
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 @@ file_name = /tmp/kivitendo-debug.log
ist der Key f
$::request
Muss ich von anderen Teilen des Programms lesend drauf
zugreifen? Dann $::request
, aber Zugriff über
- Wrappermethode
Die folgenden Variablen waren einmal im Programm, und wurden - entfernt.
Die folgenden Variablen waren einmal im Programm, und wurden + entfernt.
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}
-
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.
Inhaltsverzeichnis
Inhaltsverzeichnis
- - |
-
|
- ||||||||||||||||||
- - |
-
|
- ||||||||||||||||||
- - |
-
|
- ||||||||||||||||||
- - |
-
|
- ||||||||||||||||||
- - |
- |
-
|
- ||||||||||||||||||||||||||||
- |
-
|
- ||||||||||||||||||||||||||||
- |
-
|
- ||||||||||||||||||||||||||||
- |
-
|
- ||||||||||||||||||||||||||||
- | |||||||||||||||||||||||||||||
- | Please make check payable to <%company%>. - | -||||||||||||||||||||||||||||