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.

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.

Für jeden Posten gibt es ein Unterarray mit den Informationen über Lieferanten und Lieferantenartikelnummer. Diese müssen mit einer foreach-Schleife ausgegeben werden, da für jeden Artikel mehrere Lieferanteninformationen hinterlegt sein können. Die Variablen dafür lauten:

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.

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:

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:

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.

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:

Variablen für jede Rechnungsposition in Sammelrechnung:

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.