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
LaTeX- und HTML-Vorlagen kann man die Form dieser Tags auch verändern
(siehe Anfang und Ende der Tags verändern).
kivitendo unterstützt LaTeX-, HTML- und OpenDocument-Vorlagen. Sofern es nicht ausdrücklich eingeschränkt wird, gilt das im Folgenden gesagte für alle Vorlagenarten.
Insgesamt sind technisch gesehen eine ganze Menge mehr Variablen verfügbar als hier aufgelistet werden. Die meisten davon können allerdings innerhalb einer solchen Vorlage nicht sinnvoll verwendet werden. Wenn eine Auflistung dieser Variablen gewollt ist, so kann diese wie folgt erhalten werden:
SL/Form.pm
öffnen und am Anfang die
Zeile "use Data::Dumper;" einfügen.
In Form.pm
die Funktion
parse_template
suchen und hier die Zeile
print(STDERR Dumper($self)); einfügen.
Einmal per Browser die gewünschte Vorlage "benutzen", z.B. ein PDF für eine Rechnung erzeugen.
Im error.log
Apache steht die Ausgabe
der Variablen $self
in der Form 'key'
=> 'value',
. Alle key
s sind
verfügbar.
Um eine Variable auszugeben, müssen sie einfach nur zwischen die
Tags geschrieben werden, also z.B.
<%variablenname%>
.
Optional kann man auch mit Leerzeichen getrennte Flags angeben,
die man aber nur selten brauchen wird. Die Syntax sieht also so aus:
<%variablenname FLAG1 FLAG2%>
. Momentan
werden die folgenden Flags unterstützt:
NOFORMAT
gilt nur für Zahlenwerte und gibt
den Wert ohne Formatierung, also ohne Tausendertrennzeichen mit
mit einem Punkt als Dezimaltrennzeichen aus. Nützlich z.B., wenn
damit in der Vorlage z.B. von LaTeX gerechnet werden soll.
NOESCAPE
unterdrückt das Escapen von
Sonderzeichen für die Vorlagensprache. Wenn also in einer
Variablen bereits gültiger LaTeX-Code steht und dieser von LaTeX
auch ausgewertet und nicht wortwörtlich angezeigt werden soll, so
ist dieses Flag sinnvoll.
Beispiel:
<%quototal NOFORMAT%>
In der Admininstration können Drucker definiert werden. Auch im
dort eingebbaren Druckbefehl können die hier aufgelisteten Variablen
und Kontrollstrukturen verwendet werden. Ihr Inhalt wird dabei nach
den Regeln der gängigen Shells formatiert, sodass Sonderzeichen wie
`...`
nicht zu unerwünschtem Verhalten
führen.
Dies erlaubt z.B. die Definition eines Faxes als Druckerbefehl, für das die Telefonnummer eines Ansprechpartners als Teil der Kommandozeile verwendet wird. Für ein fiktives Kommando könnte das z.B. wie folgt aussehen:
send_fax --number <%if cp_phone2%><%cp_phone2%><%else%><%cp_phone1%><%end%>
Der Standardstil für Tags sieht vor, dass ein Tag mit dem
Kleinerzeichen und einem Prozentzeichen beginnt und mit dem
Prozentzeichen und dem Größerzeichen endet, beispielsweise
<%customer%>
. Da diese Form aber z.B. in
LaTeX zu Problemen führen kann, weil das Prozentzeichen dort
Kommentare einleitet, kann pro HTML- oder LaTeX-Dokumentenvorlage der
Stil umgestellt werden.
Dazu werden in die Datei Zeilen geschrieben, die mit dem für das
Format gültigen Kommentarzeichen anfangen, dann
config:
enthalten, die entsprechende Option
setzen und bei HTML-Dokumentenvorlagen mit dem Kommentarendzeichen
enden. Beispiel für LaTeX:
% config: tag-style=($ $)
Dies würde kivitendo dazu veranlassen, Variablen zu ersetzen,
wenn sie wie folgt aussehen: ($customer$)
. Das
äquivalente Beispiel für HTML-Dokumentenvorlagen sieht so aus:
<!-- config: tag-style=($ $) -->
Diese folgende kurze Auflistung zeigt, welche Vorlage bei
welcher Funktion ausgelesen wird. Dabei ist die Dateiendung
".ext
" geeignet zu ersetzen:
".tex
" für LaTeX-Vorlagen und
".odt
" für OpenDocument-Vorlagen.
bin_list.ext
Lagerliste
check.ext
?
invoice.ext
Rechnung
packing_list.ext
Packliste
pick_list.ext
Sammelliste
purchase_delivery_order.ext
Lieferschein (Einkauf)
purcharse_order.ext
Bestellung an Lieferanten
request_quotation.ext
Anfrage an Lieferanten
sales_delivery_order.ext
Lieferschein (Verkauf)
sales_order.ext
Bestellung
sales_quotation.ext
Angebot an Kunden
zahlungserinnerung.ext
Mahnung (Dateiname im Programm konfigurierbar)
zahlungserinnerung_invoice.ext
Rechnung über Mahngebühren (Dateiname im Programm konfigurierbar)
Angeforderte Sprache und Druckerkürzel in den Dateinamen mit
eingearbeitet. So wird aus der Vorlage
sales_order.ext
bei Sprache
de
und Druckerkürzel lpr2
der Vorlagenname sales_order_de_lpr2.ext
.
Zusätzlich können für E-Mails andere Vorlagen erstellt werden, diese
bekommen dann noch das Kürzel _email
, der
vollständige Vorlagenname wäre dann
sales_order_email_de_lpr2.ext
. In allen Fällen
kann eine Standarddatei default.ext
hinterlegt
werden. Diese wird verwendet, wenn keine der anderen Varianten
gefunden wird.
Die vollständige Suchreihenfolge für einen Verkaufsauftrag mit der Sprache "de" und dem Drucker "lpr2", der per E-Mail im Format PDF verschickt wird, ist:
sales_order_email_de_lpr2.tex
sales_order_de_lpr2.tex
sales_order.tex
default.tex
Die kurzen Varianten dieser Vorlagentitel müssen dann entweder Standardwerte anzeigen, oder die angeforderten Werte selbst auswerten, siehe dazu Metainformationen zur angeforderten Vorlage.
Diese Variablen liefern Informationen darüber welche Variante einer Vorlage der Benutzer angefragt hat. Sie sind nützlich für Vorlagenautoren, die aus einer zentralen Layoutvorlage die einzelnen Formulare einbinden möchten.
template_meta.formname
Basisname der Vorlage. Identisch mit der Zurordnung
zu den Dateinamen ohne die Erweiterung. Ein
Verkaufsauftrag enthält hier
sales_order
.
template_meta.language.description
Beschreibung der verwendeten Sprache
template_meta.language.template_code
Vorlagenkürzel der verwendeten Sprache, identisch mit dem Kürzel das im Dateinamen verwendetet wird.
template_meta.language.output_numberformat
Zahlenformat der verwendeten Sprache in der Form
"1.000,00
". Experimentell! Nur
interessant für Vorlagen die mit unformatierten Werten
arbeiten.
template_meta.language.output_dateformat
Datumsformat der verwendeten Sprache in der Form
"dd.mm.yyyy
". Experimentell! Nur
interessant für Vorlagen die mit unformatierten Werten
arbeiten.
template_meta.format
Das angeforderte Format. Kann im Moment die Werte
pdf
, postscript
,
html
, opendocument
,
opendocument_pdf
und
excel
enthalten.
template_meta.extension
Dateierweiterung, wie im Dateinamen. Wird aus
format
entschieden.
template_meta.media
Ausgabemedium. Kann zur Zeit die Werte
screen
für Bildschirm,
email
für E-Mail (triggert das
_email
Kürzel im Dateinamen),
printer
für Drucker, und
queue
für Warteschlange enthalten.
template_meta.printer.description
Beschreibung des ausgewählten Druckers
template_meta.printer.template_code
Vorlagenürzel des ausgewählten Druckers, identisch mit dem Kürzel das im Dateinamen verwendetet wird.
template_meta.tmpfile
Datei-Prefix für temporäre Dateien.
account_number
Kontonummer
bank
Name der Bank
bank_code
Bankleitzahl
bic
Bank-Identifikations-Code (Bank Identifier Code, BIC)
business
Kunden-/Lieferantentyp
city
Stadt
contact
Kontakt
country
Land
c_vendor_id
Lieferantennummer beim Kunden (nur Kunden)
v_customer_id
Kundennummer beim Lieferanten (nur Lieferanten)
cp_email
Email des Ansprechpartners
cp_givenname
Vorname des Ansprechpartners
cp_greeting
Anrede des Ansprechpartners
cp_name
Name des Ansprechpartners
cp_phone1
Telefonnummer 1 des Ansprechpartners
cp_phone2
Telefonnummer 2 des Ansprechpartners
cp_title
Titel des Ansprechpartners
creditlimit
Kreditlimit
customeremail
Email des Kunden; nur für Kunden
customerfax
Faxnummer des Kunden; nur für Kunden
customernotes
Bemerkungen beim Kunden; nur für Kunden
customernumber
Kundennummer; nur für Kunden
customerphone
Telefonnummer des Kunden; nur für Kunden
discount
Rabatt
email
Emailadresse
fax
Faxnummer
gln
GLN (Globale Lokationsnummer)
greeting
Anrede
homepage
Homepage
iban
Internationale Kontonummer (International Bank Account Number, IBAN)
language
Sprache
name
Firmenname
natural_person
Flag "natürliche Person"; Siehe auch Hinweise zur Anrede
payment_description
Name der Zahlart
payment_terms
Zahlungskonditionen
phone
Telefonnummer
shiptocity
Stadt (Lieferadresse) *
shiptocontact
Kontakt (Lieferadresse) *
shiptocountry
Land (Lieferadresse) *
shiptodepartment_1
Abteilung 1 (Lieferadresse) *
shiptodepartment_2
Abteilung 2 (Lieferadresse) *
shiptoemail
Email (Lieferadresse) *
shiptofax
Fax (Lieferadresse) *
shiptogln
GLN (Globale Lokationsnummer) (Lieferadresse) *
shiptoname
Firmenname (Lieferadresse) *
shiptophone
Telefonnummer (Lieferadresse) *
shiptostreet
Straße und Hausnummer (Lieferadresse) *
shiptozipcode
Postleitzahl (Lieferadresse) *
street
Straße und Hausnummer
taxnumber
Steuernummer
ustid
Umsatzsteuer-Identifikationsnummer
vendoremail
Email des Lieferanten; nur für Lieferanten
vendorfax
Faxnummer des Lieferanten; nur für Lieferanten
vendornotes
Bemerkungen beim Lieferanten; nur für Lieferanten
vendornumber
Lieferantennummer; nur für Lieferanten
vendorphone
Telefonnummer des Lieferanten; nur für Lieferanten
zipcode
Postleitzahl
employee_address
Adressfeld
employee_businessnumber
Firmennummer
employee_company
Firmenname
employee_co_ustid
Usatzsteuer-Identifikationsnummer
employee_duns
DUNS-Nummer
employee_email
employee_fax
Fax
employee_name
voller Name
employee_signature
Signatur
employee_taxnumber
Steuernummer
employee_tel
Telefonnummer
salesman_address
Adressfeld
salesman_businessnumber
Firmennummer
salesman_company
Firmenname
salesman_co_ustid
Usatzsteuer-Identifikationsnummer
salesman_duns
DUNS-Nummer
salesman_email
salesman_fax
Fax
salesman_name
voller Name
salesman_signature
Signatur
salesman_taxnumber
Steuernummer
salesman_tel
Telefonnummer
tax
Steuer
taxbase
zu versteuernder Betrag
taxdescription
Name der Steuer
taxrate
Steuersatz
delivery_term
Datenbank-Objekt der Lieferbedingung
delivery_term.description
Beschreibung der Lieferbedingung
delivery_term.description_long
Langtext bzw. übersetzter Langtext der Lieferbedingung
Abweichende Rechnungsadressen gibt es nur in Verkaufsbelegen. Die entsprechenden Variablen sind nur dann mit Inhalt gefüllt,
wenn im Beleg eine abweichende Rechnungsadresse ausgewählt wurde. Ob eine Adresse überhaupt ausgewählt wurde, kann über die
Variable billing_address_id
getestet werden, die die Datenbank-ID der abweichenden Rechnungsadresse enthält,
wenn eine ausgewählt ist.
Die Variablennamen starten alle mit dem Präfix billing_address_
und heißen anschließend so, wie ihre Pendants
aus der Standard-Rechnungsadresse des Kunden. Beispiel: die Postleitzahl, die in der normalen Rechnungsadresse in
zipcode
steht, steht für die abweichende Rechnungsadresse in billing_address_zipcode
.
Die folgenden Variablen stehen so zur Verfügung: billing_address_name
,
billing_address_department_1
, billing_address_department_2
,
billing_address_contact
, billing_address_street
,
billing_address_zipcode
, billing_address_city
, billing_address_country
,
billing_address_gln
, billing_address_email
, billing_address_phone
und
billing_address_fax
.
creditremaining
Verbleibender Kredit
currency
Währung
cusordnumber
Bestellnummer beim Kunden
deliverydate
Lieferdatum
duedate
Fälligkeitsdatum
globalprojectnumber
Projektnummer des ganzen Beleges
globalprojectdescription
Projekbeschreibung des ganzen Beleges
intnotes
Interne Bemerkungen
invdate
Rechnungsdatum
invnumber
Rechnungsnummer
invtotal
gesamter Rechnungsbetrag
notes
Bemerkungen der Rechnung
orddate
Auftragsdatum
ordnumber
Auftragsnummer, wenn die Rechnung aus einem Auftrag erstellt wurde
payment_description
Name der Zahlart
payment_terms
Zahlungskonditionen
quodate
Angebotsdatum
quonumber
Angebotsnummer
rounding
Betrag, um den invtotal
gerundet
wurde (kann positiv oder negativ sein)
shippingpoint
Versandort
shipvia
Transportmittel
subtotal
Zwischensumme aller Posten ohne Steuern
total
Restsumme der Rechnung (Summe abzüglich bereits bezahlter Posten)
transaction_description
Vorgangsbezeichnung
transdate
Auftragsdatum wenn die Rechnung aus einem Auftrag erstellt wurde
Diese Variablen können mit dem LaTeX Modul qrbill verwendet werden: https://ctan.org/pkg/qrbill?lang=de
Für die Erstellung von QR-Rechnungen mit OpenDocument Vorlagen siehe: Abschnitt 2.15, „OpenDocument-Vorlagen“
IBAN/QR-IBAN des Rechnungsstellers, aus System → Bankkonten
Länderkürzel des Rechnungsstellers gem. ISO 3166, aus Mandantenkonfiguration → Firmenname und -adresse
Länderkürzel des Rechnungsempfängers gem. ISO 3166, aus der jeweiligen Rechnung
Betrag für die QR-Rechnung (Zahl ohne Tausendertrennzeichen mit zwei Nachkommastellen), entsprechend total
QR-Referenz der jeweiligen Rechnung, sofern in der Mandantenkonfiguration → Features → Variante QR-IBAN mit QR-Referenz erzeugen aktiviert ist
bin
Stellage
description
Artikelbeschreibung
cusordnumber_oe
Bestellnummer des Kunden aus dem Auftrag, aus dem der Posten ursprünglich stammt (nur Verkauf)
discount
Rabatt als Betrag
discount_sub
Zwischensumme mit Rabatt
donumber_do
Lieferscheinnummer des Lieferscheins, aus dem die Position ursprünglich stammt, wenn die Rechnung im Rahmen des Workflows aus einem Lieferschein erstellt wurde.
drawing
Zeichnung
ean
EAN-Code
image
Grafik
linetotal
Zeilensumme (Anzahl * Einzelpreis)
longdescription
Langtext, vorbelegt mit dem Feld Bemerkungen der entsprechenden Ware
microfiche
Mikrofilm
netprice
Alternative zu sellprice
, aber
netprice
entspricht dem effektiven
Einzelpreis und beinhaltet Zeilenrabatt und Preisfaktor.
netprice
wird rückgerechnet aus Zeilensumme
/ Menge. Diese Variable ist nützlich, wenn man den gewährten
Rabatt in der Druckvorlage nicht anzeigen möchte, aber Menge *
Einzelpreis trotzdem die angezeigte Zeilensumme ergeben soll.
netprice
hat nichts mit Netto/Brutto im
Sinne von Steuern zu tun.
nodiscount_linetotal
Zeilensumme ohne Rabatt
nodiscount_sub
Zwischensumme ohne Rabatt
number
Artikelnummer
ordnumber_oe
Auftragsnummer des Originalauftrags, aus dem der Posten ursprünglich stammt. Nützlich, wenn die Rechnung aus mehreren Lieferscheinen zusammengefasst wurde, oder wenn zwischendurch eine Sammelauftrag aus mehreren Aufträgen erstellt wurde. In letzterem Fall wird die unsprüngliche Auftragsnummer angezeigt.
p_discount
Rabatt in Prozent
partnotes
Die beim Artikel gespeicherten Bemerkungen
partsgroup
Warengruppe
price_factor
Der Preisfaktor als Zahl, sofern einer eingestellt ist
price_factor_name
Der Name des Preisfaktors, sofern einer eingestellt ist
projectnumber
Projektnummer
projectdescription
Projektbeschreibung
qty
Anzahl
reqdate
Lieferdatum
runningnumber
Position auf der Rechnung (1, 2, 3...)
sellprice
Verkaufspreis
serialnumber
Seriennummer
tax_rate
Steuersatz
transdate_do
Datum des Lieferscheins, wenn die Rechnung im Rahmen des Workflows aus einem Lieferschein stammte.
transdate_oe
Datum des Auftrags, wenn die Rechnung im Rahmen des Workflows aus einem Auftrag erstellt wurde. Wenn es Sammelaufträge gab wird das Datum des ursprünglichen Auftrags genommen.
transdate_quo
Datum des Angebots, wenn die Position im Rahmen des Workflows aus einem Angebot stammte.
unit
Einheit
weight
Gewicht
Für jeden Posten gibt es ein Unterarray mit den Informationen
über Lieferanten und Lieferantenartikelnummer, Kunde und Kundenartikelnummer
und Kunden- bzw. Lieferantentyp und zugehöriger Artikelnummer mit Beschreibung
und Langtext. Diese müssen jeweils mit
einer foreach
-Schleife ausgegeben werden, da
für jeden Artikel mehrere Lieferanten- und Kundeninformationen bzw.
kunden- bzw. lieferantenspezifische Informationen hinterlegt sein
können. Die Variablen dafür lauten:
make
Lieferant
model
Lieferantenartikelnummer
mm_part_description
Lieferantenartikelbeschreibung
mm_part_longdescription
Lieferantenartikelbeschreibung (Langtext)
customer_make
Kunde
customer_model
Kundenartikelnummer
cm_part_description
Kundenartikelbeschreibung
cm_part_longdescription
Kundenartikelbeschreibung (Langtext)
business_make
Kunden-/Lieferantentyp
business_model
Kunden-/Lieferantentyp-spezifische Artikelnummer
bm_part_description
Kunden-/Lieferantentyp-spezifische Artikelbeschreibung
bm_part_longdescription
Kunden-/Lieferantentyp-spezifische Artikelbeschreibung (Langtext)
Für jeden Posten stehen auch die benutzerdefinierten Variablen zum
Artikel zur Verfügung. Ihre Namen bestehen aus dem Präfix
ic_cvar_
und dem vom Benutzer festgelegten
Variablennamen.
Ebenso stehen die benutzerdefinierten Variablen zum positionsbezogenen
Projekt unter dem Namen mit dem Präfix project_cvar_
und dem vom Benutzer festgelegten Variablennamen zur Verfügung.
payment
Betrag
paymentaccount
Konto
paymentdate
Datum
paymentmemo
Memo
paymentsource
Beleg
Die vom Benutzer definierten Variablen für Kunden und
Lieferanten stehen beim Ausdruck von Einkaufs- und Verkaufsbelegen
ebenfalls zur Verfügung. Ihre Namen setzen sich aus dem Präfix
vc_cvar_
und dem vom Benutzer festgelegten
Variablennamen zusammen.
Beispiel: Der Benutzer hat eine Variable namens
number_of_employees
definiert, die die Anzahl der
Mitarbeiter des Unternehmens enthält. Diese Variable steht dann
unter dem Namen vc_cvar_number_of_employees
zur
Verfügung.
Die benutzerdefinierten Variablen der Lieferadressen stehen
unter einem ähnlichen Namensschema zur Verfügung. Hier lautet der
Präfix shiptocvar_
.
Analog stehen die benutzerdefinierten Variablen für
Ansprechpersonen mit dem Namenspräfix cp_cvar_
zur Verfügung.
Auch für das globale Projekt des Belegs stehen die
benutzerdefinierten Variablen mit dem Namenspräfix
project_cvar_
zur Verfügung.
Die Namen der Vorlagen werden im System-Menü vom Benutzer
eingegeben. Wird für ein Mahnlevel die Option zur automatischen
Erstellung einer Rechnung über die Mahngebühren und Zinsen
aktiviert, so wird der Name der Vorlage für diese Rechnung aus dem
Vorlagenname für diese Mahnstufe mit dem Zusatz
_invoice
gebildet. Weiterhin werden die Kürzel
für die ausgewählte Sprache und den ausgewählten Drucker
angehängt.
Die Variablen des Bearbeiters, bzw. Verkäufers stehen wie
gewohnt als employee_...
bzw.
salesman_...
zur Verfügung. Werden mehrere
Rechnungen in einer Mahnung zusammengefasst, so werden die Metadaten
(Bearbeiter, Abteilung, etc) der ersten angemahnten Rechnung im
Ausdruck genommen.
Die Adressdaten des Kunden stehen als Variablen
name
, street
,
zipcode
, city
,
country
, department_1
,
department_2
, und email
zur
Verfügung. Der Ansprechpartner cp_...
steht auch
zu Verfügung, wird allerdings auch nur von der ersten angemahnten
Rechnung (s.o.) genommen.
Weitere Variablen beinhalten:
dunning_date
Datum der Mahnung
dunning_duedate
Fälligkeitsdatum für diese Mahhnung
dunning_id
Mahnungsnummer
fee
Kumulative Mahngebühren
interest_rate
Zinssatz per anno in Prozent
total_amount
Gesamter noch zu zahlender Betrag als
fee
+ total_interest
+ total_open_amount
total_interest
Zinsen per anno über alle Rechnungen
total_open_amount
Summe über alle offene Beträge der Rechnungen
dn_amount
Rechnungssumme (brutto)
dn_duedate
Originales Fälligkeitsdatum der Rechnung
dn_dunning_date
Datum der Mahnung
dn_dunning_duedate
Fälligkeitsdatum der Mahnung
dn_fee
Kummulative Mahngebühr
dn_interest
Zinsen per anno für diese Rechnung
dn_invnumber
Rechnungsnummer
dn_linetotal
Noch zu zahlender Betrag (ergibt sich aus
dn_open_amount
+ dn_fee
+ dn_interest
)
dn_netamount
Rechnungssumme (netto)
dn_open_amount
Offener Rechnungsbetrag
dn_ordnumber
Bestellnummer
dn_transdate
Rechnungsdatum
dn_curr
Währung, in der die Rechnung erstellt wurde. (Die Rechnungsbeträge sind aber immer in der Hauptwährung)
Die Variablen des Verkäufers stehen wie gewohnt als
employee_...
zur Verfügung. Die Adressdaten des
Kunden stehen als Variablen name
,
street
, zipcode
,
city
, country
,
department_1
, department_2
,
und email
zur Verfügung.
Weitere Variablen beinhalten:
duedate
Fälligkeitsdatum der Rechnung
dunning_id
Mahnungsnummer
fee
Mahngebühren
interest
Zinsen
invamount
Rechnungssumme (ergibt sich aus fee
+
interest
)
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:
quodate
für Angebotsdatum etc. Bei Bestellungen
wiederum fangen sie mit ord
für "order" an:
ordnumber
für Bestellnummer etc.
Manche Variablen sind in anderen Vorlagen hingegen gar nicht vorhanden wie z.B. die für bereits verbuchte Zahlungseingänge. Dies sind Variablen, die vom Geschäftsablauf her in der entsprechenden Vorlage keine Bedeutung haben oder noch nicht belegt sein können.
Im Folgenden werden nur wichtige Unterschiede zu den Variablen in Rechnungen aufgeführt.
quonumber
Angebots- bzw. Anfragenummer
reqdate
Gültigkeitsdatum (bei Angeboten) bzw. Lieferdatum (bei Preisanfragen)
transdate
Angebots- bzw. Anfragedatum
ordnumber
Auftragsnummer
reqdate
Lieferdatum
transdate
Auftragsdatum
cusordnumber
Bestellnummer des Kunden (im Verkauf) bzw. Bestellnummer des Lieferanten (im Einkauf)
donumber
Lieferscheinnummer
transdate
Lieferscheindatum
Für jede Position eines Lieferscheines gibt es ein Unterarray
mit den Informationen darüber, von welchem Lager und Lagerplatz aus
die Waren verschickt wurden (Verkaufslieferscheine) bzw. auf welchen
Lagerplatz sie eingelagert wurden. Diese müssen mittels einer
foreach
-Schleife ausgegeben werden. Diese
Variablen sind:
si_bin
Lagerplatz
si_chargenumber
Chargennummer
si_bestbefore
Mindesthaltbarkeit
si_number
Artikelnummer
si_qty
Anzahl bzw. Menge
si_runningnumber
Positionsnummer (1, 2, 3 etc)
si_unit
Einheit
si_warehouse
Lager
c0total
Gesamtbetrag aller Rechnungen mit Fälligkeit < 30 Tage
c30total
Gesamtbetrag aller Rechnungen mit Fälligkeit >= 30 und < 60 Tage
c60total
Gesamtbetrag aller Rechnungen mit Fälligkeit >= 60 und < 90 Tage
c90total
Gesamtbetrag aller Rechnungen mit Fälligkeit >= 90 Tage
total
Gesamtbetrag aller Rechnungen
Variablen für jede Rechnungsposition in Sammelrechnung:
invnumber
Rechnungsnummer
invdate
Rechnungsdatum
duedate
Fälligkeitsdatum
amount
Summe der Rechnung
open
Noch offener Betrag der Rechnung
c0
Noch offener Rechnungsbetrag mit Fälligkeit < 30 Tage
c30
Noch offener Rechnungsbetrag mit Fälligkeit >= 30 und < 60 Tage
c60
Noch offener Rechnungsbetrag mit Fälligkeit >= 60 und < 90 Tage
c90
Noch offener Rechnungsbetrag mit Fälligkeit >= 90 Tage
Der Parser kennt neben den Variablen einige weitere Konstrukte, die gesondert behandelt werden. Diese sind wie Variablennamen in spezieller Weise markiert: <%anweisung%> ... <%end%>
Anmerkung zum <%end%>: Der besseren Verständlichkeit halber kann man nach dem end noch beliebig weitere Wörter schreiben, um so zu markieren, welche Anweisung (z.B. if oder foreach) damit abgeschlossen wird.
Beispiel: Lautet der Beginn eines Blockes z.B. <%if type == "sales_quotation"%>, so könnte er mit <%end%> genauso abgeschlossen werden wie mit <%end if%> oder auch <%end type == "sales_quotation"%>.
<%if variablenname%> ... <%end%>
Eine normale "if-then"-Bedingung. Die Zeilen zwischen dem "if"
und dem "end" werden nur ausgegeben, wenn die Variable
variablenname
gesetzt und ungleich 0 ist.
Handelt es sich bei der benannten Variable um ein Array, also um einen Variablennamen, über den man mit <%foreach variablenname%> iteriert, so wird mit diesem Konstrukt darauf getestet, ob das Array Elemente enthält. Somit würde im folgenden Beispiel nur dann eine Liste von Zahlungseingängen samt ihrer Überschrift "Zahlungseingänge" ausgegeben, wenn tatsächlich welche getätigt wurden:
<%if payment%> Zahlungseingänge: <%foreach payment%> Am <%paymentdate%>: <%payment%> € <%end foreach%> <%end if%>
Die Bedingung kann auch negiert werden, indem das Wort
not
nach dem if
verwendet
wird. Beispiel:
<%if not cp_greeting%> ... <%end%>
Zusätzlich zu dem einfachen Test, ob eine Variable gesetzt ist oder nicht, bietet dieser Block auch die Möglichkeit, den Inhalt einer Variablen mit einer festen Zeichenkette oder einer anderen Variablen zu vergleichen. Ob der Vergleich mit einer Zeichenkette oder einer anderen Variablen vorgenommen wird, hängt davon ab, ob die rechte Seite des Vergleichsoperators in Anführungszeichen gesetzt wird (Vergleich mit Zeichenkette) oder nicht (Vergleich mit anderer Variablen). Zwei Beispiele, die beide Vergleiche zeigen:
<%if var1 == "Wert"%>
Testet die Variable var1
auf
übereinstimmung mit der Zeichenkette Wert
.
Mittels !=
anstelle von ==
würde auf Ungleichheit getestet.
<%if var1 == var2%>
Testet die Variable var1
auf
übereinstimmung mit der Variablen var2
. Mittel
!=
anstelle von ==
würde
auf Ungleichheit getestet.
Erfahrere Benutzer können neben der Tests auf (Un-)Gleichheit
auch Tests auf Übereinstimmung mit regulären Ausdrücken ohne
Berücksichtung der Groß- und Kleinschreibung durchführen. Dazu dient
dieselbe Syntax wie oben nur mit =~
und
!~
als Vergleichsoperatoren.
Beispiel für einen Test, ob die Variable
intnotes
(interne Bemerkungen) das Wort
schwierig
enthält:
<%if intnotes =~ "schwierig"%>
<%foreach variablenname%> ... <%end%>
Fügt die Zeilen zwischen den beiden Anweisungen so oft ein,
wie das Perl-Array der Variablen variablenname
Elemente enthät. Dieses Konstrukt wird zur Ausgabe der einzelnen
Posten einer Rechnung / eines Angebots sowie zur Ausgabe der Steuern
benutzt. In jedem Durchlauf werden die zeilenbezogenen
Variablen jeweils auf den Wert für die aktuelle Position
gesetzt.
Die Syntax sieht normalerweise wie folgt aus:
<%foreach number%> Position: <%runningnumber%> Anzahl: <%qty%> Artikelnummer: <%number%> Beschreibung: <%description%> ... <%end%>
Besonderheit in OpenDocument-Vorlagen: Tritt ein
<%foreach%>
-Block innerhalb einer
Tabellenzelle auf, so wird die komplette Tabellenzeile so oft
wiederholt wie notwendig. Tritt er außerhalb auf, so wird nur der
Inhalt zwischen <%foreach%>
und
<%end%>
wiederholt, nicht aber die
komplette Zeile, in der er steht.
Wenn der Benutzer innhalb von Formularen in kivitendo Text anders formatiert haben möchte, so ist dies begrenzt möglich. kivitendo unterstützt die Textformatierung mit HTML-ähnlichen Tags. Der Benutzer kann z.B. bei der Artikelbeschreibung auf einer Rechnung Teile des Texts zwischen Start- und Endtags setzen. Dieser Teil wird dann automatisch in Anweisungen für das ausgewählte Vorlagenformat (HTML oder PDF über LaTeX) umgesetzt.
Die unterstützen Formatierungen sind:
Text wird in Fettdruck gesetzt.
Text wird kursiv gesetzt.
Text wird unterstrichen.
Text wird durchgestrichen. Diese Formatierung ist nicht bei der Ausgabe als PDF über LaTeX verfügbar.
Erzeugt einen ausgefüllten Kreis für Aufzählungen (siehe unten).
Der Befehl <bullet> funktioniert momentan auch nur in Latex-Vorlagen.
Das Flag "natürliche Person"
(natural_person
) aus den Kunden- oder
Lieferantenstammdaten kann in den Druckvorlagen zusammen mit
dem Feld "Anrede" (greeting
) z.B. dafür
verwendet werden, die Anrede zwischen einer allgemeinen und
einer persönlichen Anrede zu unterscheiden.
<%if natural_person%><%greeting%> <%name%><%else%>Sehr geehrte Damen und Herren<%end if%>