X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/1725e45ad587ba8d7f637d3e8e00221e959424d1..87eebe6:/doc/dokumentation.xml diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml index fd3c085d3..759ff0f01 100644 --- a/doc/dokumentation.xml +++ b/doc/dokumentation.xml @@ -538,7 +538,7 @@ exit wird: AddHandler cgi-script .pl -Alias /kivitendo-erp/ /var/www/kiviteno-erp/ +Alias /kivitendo-erp/ /var/www/kivitendo-erp/ <Directory /var/www/kivitendo-erp> Options ExecCGI Includes FollowSymlinks @@ -2170,6 +2170,82 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/ [periodic_invoices]. + + Spezielle Variablen + + + Um die erzeugten Rechnungen individualisieren zu können, werden beim Umwandeln des Auftrags in eine Rechnung einige speziell + formatierte Variablen durch für die jeweils aktuelle Abrechnungsperiode gültigen Werte ersetzt. Damit ist es möglich, z.B. den + Abrechnungszeitraum explizit auszuweisen. Eine Variable hat dabei die Syntax <%variablenname%>. + + + + Diese Variablen werden in den folgenden Elementen des Auftrags ersetzt: + + + + Bemerkungen + Interne Bemerkungen + Vorgangsbezeichnung + In den Beschreibungs- und Langtextfeldern aller Positionen + + + Die zur Verfügung stehenden Variablen sind die Folgenden: + + + + <%current_quarter%>, <%previous_quarter%>, <%next_quarter%> + + + + Aktuelles, vorheriges und nächstes Quartal als Zahl zwischen 1 und 4. + + + + + + <%current_month%>, <%previous_month%>, <%next_month%> + + + + Aktueller, vorheriger und nächster Monat als Zahl zwischen 1 und 12. + + + + + + <%current_month_long%>, <%previous_month_long%>, <%next_month_long%> + + + + Aktueller, vorheriger und nächster Monat als Name (Januar, Februar etc.). + + + + + + <%current_year%>, <%previous_year%>, <%next_year%> + + + + Aktuelles, vorheriges und nächstes Jahr als vierstellige Jahreszahl (2013 etc.). + + + + + + <%period_start_date%>, <%period_end_date%> + + + + Formatiertes Datum des ersten und letzten Tages im Abrechnungszeitraum (z.B. bei quartalsweiser Abrechnung und im ersten + Quartal von 2013 wären dies der 01.01.2013 und 31.03.2013). + + + + + + Auflisten @@ -2688,6 +2764,22 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/ + + c_vendor_id + + + Lieferantennummer beim Kunden (nur Kunden) + + + + + v_customer_id + + + Kundennummer beim Lieferanten (nur Lieferanten) + + + cp_email @@ -5476,11 +5568,10 @@ file = /tmp/kivitendo-debug.log charset - Empfohlen. Gibt den Zeichensatz an, in dem das Script - geschrieben wurde, z.B. "UTF-8". Aus - Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei - Abwesenheit des Tags der Zeichensatz - "ISO-8859-15" angenommen. + Empfohlen. Gibt den Zeichensatz an, in dem das Script geschrieben wurde, z.B. "UTF-8". Aus + Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei Abwesenheit des Tags für SQL-Upgradedateien der Zeichensatz + "ISO-8859-15" angenommen. Perl-Upgradescripte hingegen müssen immer in UTF-8 encodiert sein und sollten + demnach auch ein "use utf8;" enthalten. @@ -5548,6 +5639,48 @@ file = /tmp/kivitendo-debug.log + + Format von in Perl geschriebenen Datenbankupgradescripten + + In Perl geschriebene Datenbankscripte werden nicht einfach so ausgeführt sondern müssen sich an gewisse Konventionen + halten. Dafür bekommen sie aber auch einige Komfortfunktionen bereitgestellt. + + Ein Upgradescript stellt dabei eine vollständige Objektklasse dar, die vom Elternobjekt + "SL::DBUpgrade2::Base" erben und eine Funktion namens "run" zur Verfügung stellen muss. Das + Script wird ausgeführt, indem eine Instanz dieser Klasse erzeugt und darauf die erwähnte "run" aufgerufen + wird. + + Zu beachten ist, dass sich der Paketname der Datei aus dem Wert für "@tag" ableitet. Dabei werden alle + Zeichen, die in Paketnamen ungültig wären (gerade Bindestriche), durch Unterstriche ersetzt. Insgesamt sieht der Paketname wie folgt + aus: "SL::DBUpgrade2::tag". + + Welche Komfortfunktionen zur Verfügung stehen, erfahren Sie in der Perl-Dokumentation zum oben genannten Modul; aufzurufen mit + "perldoc SL/DBUpgrade2/Base.pm". + + Ein Mindestgerüst eines gültigen Perl-Upgradescriptes sieht wie folgt aus: + + # @tag: beispiel-upgrade-file42 +# @description: Ein schönes Beispielscript +# @depends: release_3_0_0 +package SL::DBUpgrade2::beispiel_upgrade_file42; + +use strict; +use utf8; + +use parent qw(SL::DBUpgrade2::Base); + +sub run { + my ($self) = @_; + + # hier Aktionen ausführen + + return 1; +} + +1; + + + Hilfsscript dbupgrade2_tool.pl @@ -5866,6 +5999,10 @@ filenames Test::Deep (Debian-Paketname: libtest-deep-perl; Fedora Core: perl-Test-Deep; openSUSE: perl-Test-Deep) + Test::Exception (Debian-Paketname: libtest-exception-perl; Fedora Core: + perl-Test-Exception; openSUSE: perl-Test-Exception) + Test::Output (Debian-Paketname: libtest-output-perl; Fedora Core: + perl-Test-Output; openSUSE: perl-Test-Output) Test::Harness 3.0.0 oder höher. Dieses Modul ist ab Perl 5.10.1 Bestandteil der Perl-Distribution und kann für frühere Versionen aus dem CPAN bezogen werden.