3.3. Dokumentenvorlagen und verfügbare Variablen

3.3.1. Einführung

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 keys sind verfügbar.

3.3.2. Variablen ausgeben

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%>

3.3.3. Verwendung in Druckbefehlen

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%>

3.3.4. Anfang und Ende der Tags verändern

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=($ $) -->

3.3.5. Zuordnung von den Dateinamen zu den Funktionen

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)

3.3.6. Sprache, Drucker und E-Mail

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:

  1. sales_order_email_de_lpr2.tex

  2. sales_order_de_lpr2.tex

  3. sales_order.tex

  4. 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.

3.3.7. Allgemeine Variablen, die in allen Vorlagen vorhanden sind

3.3.7.1. 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.

3.3.7.2. Stammdaten von Kunden und Lieferanten

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

[Anmerkung]Anmerkung

Anmerkung: Sind die shipto*-Felder in den Stammdaten nicht eingetragen, so haben die Variablen shipto* den gleichen Wert wie die die entsprechenden Variablen der Lieferdaten. Das bedeutet, dass sich einige shipto*-Variablen so nicht in den Stammdaten wiederfinden sondern schlicht Kopien der Lieferdatenvariablen sind (z.B. shiptocontact).

3.3.7.3. Informationen über den Bearbeiter

employee_address

Adressfeld

employee_businessnumber

Firmennummer

employee_company

Firmenname

employee_co_ustid

Usatzsteuer-Identifikationsnummer

employee_duns

DUNS-Nummer

employee_email

Email

employee_fax

Fax

employee_name

voller Name

employee_signature

Signatur

employee_taxnumber

Steuernummer

employee_tel

Telefonnummer

3.3.7.4. Informationen über den Verkäufer

salesman_address

Adressfeld

salesman_businessnumber

Firmennummer

salesman_company

Firmenname

salesman_co_ustid

Usatzsteuer-Identifikationsnummer

salesman_duns

DUNS-Nummer

salesman_email

Email

salesman_fax

Fax

salesman_name

voller Name

salesman_signature

Signatur

salesman_taxnumber

Steuernummer

salesman_tel

Telefonnummer

3.3.7.5. Variablen für die einzelnen Steuern

tax

Steuer

taxbase

zu versteuernder Betrag

taxdescription

Name der Steuer

taxrate

Steuersatz

3.3.7.6. Variablen für Lieferbedingungen

delivery_term

Datenbank-Objekt der Lieferbedingung

delivery_term.description

Beschreibung der Lieferbedingung

delivery_term.description_long

Langtext bzw. übersetzter Langtext der Lieferbedingung

3.3.7.7. Informationen über abweichende Rechnungsadressen (nur Verkaufsbelege)

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.

3.3.8. Variablen in Rechnungen

3.3.8.1. Allgemeine Variablen

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

3.3.8.2. Variablen für die schweizer QR-Rechnung

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“

qrbill_iban

IBAN/QR-IBAN des Rechnungsstellers, aus System → Bankkonten

qrbill_biller_countrycode

Länderkürzel des Rechnungsstellers gem. ISO 3166, aus Mandantenkonfiguration → Firmenname und -adresse

qrbill_customer_countrycode

Länderkürzel des Rechnungsempfängers gem. ISO 3166, aus der jeweiligen Rechnung

qrbill_amount

Betrag für die QR-Rechnung (Zahl ohne Tausendertrennzeichen mit zwei Nachkommastellen), entsprechend total

qr_reference

QR-Referenz der jeweiligen Rechnung, sofern in der Mandantenkonfiguration → Features → Variante QR-IBAN mit QR-Referenz erzeugen aktiviert ist

3.3.8.3. Variablen für jeden Posten auf der Rechnung

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)

3.3.8.4. Benutzerdefinierte Variablen für jeden Posten auf der Rechnung

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.

3.3.8.5. Variablen für die einzelnen Zahlungseingänge

payment

Betrag

paymentaccount

Konto

paymentdate

Datum

paymentmemo

Memo

paymentsource

Beleg

3.3.8.6. Benutzerdefinierte Kunden- und Lieferantenvariablen

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.

3.3.9. Variablen in Mahnungen und Rechnungen über Mahngebühren

3.3.9.1. Namen der Vorlagen

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.

3.3.9.2. Allgemeine Variablen in Mahnungen

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

3.3.9.3. Variablen für jede gemahnte Rechnung in einer Mahnung

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)

3.3.9.4. Variablen in automatisch erzeugten Rechnungen über Mahngebühren

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

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: 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.

3.3.10.2. Angebote und Preisanfragen

quonumber

Angebots- bzw. Anfragenummer

reqdate

Gültigkeitsdatum (bei Angeboten) bzw. Lieferdatum (bei Preisanfragen)

transdate

Angebots- bzw. Anfragedatum

3.3.10.3. Auftragsbestätigungen und Lieferantenaufträge

ordnumber

Auftragsnummer

reqdate

Lieferdatum

transdate

Auftragsdatum

3.3.10.4. Lieferscheine (Verkauf und Einkauf)

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

3.3.10.5. Variablen für Sammelrechnung

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

3.3.11. Blöcke, bedingte Anweisungen und Schleifen

3.3.11.1. Einführung

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"%>.

3.3.11.2. Der if-Block

<%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"%>

3.3.11.3. Der foreach-Block

<%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.

3.3.12. Markup-Code zur Textformatierung innerhalb von Formularen

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:

<b>Text</b>

Text wird in Fettdruck gesetzt.

<i>Text</i>

Text wird kursiv gesetzt.

<u>Text</u>

Text wird unterstrichen.

<s>Text</s>

Text wird durchgestrichen. Diese Formatierung ist nicht bei der Ausgabe als PDF über LaTeX verfügbar.

<bullet>

Erzeugt einen ausgefüllten Kreis für Aufzählungen (siehe unten).

Der Befehl <bullet> funktioniert momentan auch nur in Latex-Vorlagen.

3.3.13. Hinweise zur Anrede

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%>