Systemberichte (fest zugewiesene Berichte)

Die meisten Berichte waehlt der Anwender selbst: er oeffnet ein Grid, klickt Berichte und sucht sich einen aus. Fuer ein paar Dokumente bringt calServer den Platz dagegen selbst mit. Das hat drei Auspraegungen:

• calServer erzeugt das Dokument von sich aus, an einer Stelle, an der niemand gefragt wird — der Leihschein, den die Ausleihe-Maske nur ueber ein Haekchen anbietet („Leihschein per E-Mail senden").
• Das Dokument gehoert zum Produkt, auch wenn der Anwender es selbst ausloest — die Preisliste, die die Preislisten-Seite als PDF anbietet, und der Versandschein im Arbeitsplatz Schnellerfassung > Versandschein. Ausgewaehlt wird dort aus den Vorlagen des jeweiligen Bereichs, und auf einer frischen Installation ist diese Liste leer: Die Flaeche gibt es, nur sagt nichts, welches Bundle hineingehoert.
• Ein zweiter Vorgang liest dieselbe Zeile — der Auftragsbeleg. Er wird wie jeder Bericht aus dem Menue gewaehlt, aber seine Rechnungsvariante ist zugleich die Quelle der E-Rechnung nach ZUGFeRD/EN 16931. Deren Aktivierung und Feldzuordnungen muessen an einer verlaesslichen Zeile haengen; „irgendein Auftragsbericht, den jemand mal angelegt hat" ist fuer ein steuerlich relevantes Dokument kein Ankerpunkt.

Solche Berichte heissen hier Systemberichte. Sie liegen in derselben Berichtsverwaltung wie alle anderen und werden genauso gepflegt: hochladen, versionieren, Briefkopf zuweisen, Berichtsvariablen setzen, Signaturen und Freigaberegeln konfigurieren.

Der Platzhalter

Jeder Systembericht hat eine feste Zeile in **Administration > Berichtsverwaltung

Master-Reports** — den Platzhalter. Er wird bei der Installation angelegt (und auf bestehenden Systemen beim naechsten Update nachgetragen) und ist von Anfang an da, auch wenn noch nichts hochgeladen wurde.

Er ist an zwei Dingen zu erkennen:

• am Etikett Systembericht neben dem Namen,
• am Hinweis „Noch kein Bericht hochgeladen" samt Name des passenden Referenz-Bundles, solange die Zeile leer ist.

Der Platzhalter ist nicht loeschbar. Das ist Absicht: er ist die einzige Stelle, an der der zugehoerige Vorgang konfiguriert wird. Waere er weg, ginge die Leihschein-Mail wieder ohne Anhang raus, ohne dass irgendwo im Programm sichtbar waere, warum. Soll der Bericht nicht mehr erzeugt werden, wird die Zeile deaktiviert, nicht geloescht.

Alles andere ist frei: Name, Ordner, Format, Briefkopf, DMS-Ablage, Rollen- und Gruppenbeschraenkung. Ein Duplikat eines Systemberichts ist ein ganz normaler Bericht — es erbt die Systemkennzeichnung nicht und ist wieder loeschbar.

Solange nichts hochgeladen ist

Ein leerer Platzhalter taucht nicht im Berichte-Menue der Detailseite auf — ein Knopf, der nur eine Fehlermeldung erzeugen kann, waere kein Angebot. Sobald ein Bericht hinterlegt ist, steht er dort wie jeder andere und kann auch von Hand gedruckt werden.

Verfuegbare Systemberichte

Systembericht	Grid / Ordner	Wann calServer ihn erzeugt	Referenz-Bundle
Leihschein	location / locations	Beim Buchen einer Ausleihe, als Anhang der Leihschein-E-Mail an Entleiher bzw. Lieferkontakt	LOCATION-JSON-SAMPLE
Preisliste	price_list / prices	Auf Knopfdruck unter Preise > Preisliste, je Preisgruppe und Stichtag	PRICE-LIST-JSON-SAMPLE
Auftragsbeleg	booking / orders	Aus dem Auftrag heraus: Angebot, Auftragsbestaetigung, Lieferschein oder Rechnung — welcher Beleg entsteht, entscheidet der Auftragsstatus. Zugleich Quelle der E-Rechnung	ORDER-JSON-SAMPLE
Versandschein	free_delivery / individual_delivery	Im Arbeitsplatz Schnellerfassung > Versandschein: das Lieferpapier fuer Geraete ohne Auftrag — Warenannahme, Ruecksendung, Uebergabe an ein Fremdlabor	FREE-DELIVERY-JSON-SAMPLE
Geraeteetikett	inventory / inventories	Auf Knopfdruck aus der Geraeteliste: fuer eine Zeile ueber Etikett drucken im Zeilenmenue, fuer eine Auswahl ueber Etiketten drucken in der Werkzeugleiste	STICKER-CAL-INV-ZEBRA-JSON-SAMPLE

Geraeteetikett mit QR-Code

Das Zebra-Bundle codiert die Inventarnummer — ein Handscanner liest sie als Text zurueck. Soll das Etikett stattdessen auf die Geraeteseite der QR-Code-Rolle fuehren, nehmen Sie STICKER-INV-40X30MM-QR-JSON-SAMPLE: Scannen mit dem Telefon oeffnet ohne Anmeldung Stammdaten, Kalibrierstatus und Dokumente. Gleiche Zeile, anderes Bundle, gleicher Zuschnitt wie der QR-Kalibrieraufkleber — eine Rolle Etikettenmaterial fuer beide.

Voraussetzung ist auch hier, dass QR-Links eingeschaltet sind (Administration > Grundeinstellungen > Portal). Sind sie aus, codiert derselbe QR die Inventarnummer.

| Kalibrieraufkleber | calibration / calibrations | Genauso aus der Kalibrierliste — der uebliche Fall ist die Auswahl nach einer Kalibrierrunde | STICKER-DAKKS-18MM-JSON-SAMPLE |

Kalibrieraufkleber mit QR-Code

Soll der Aufkleber einen QR-Code tragen, der auf die Geraeteseite der QR-Code-Rolle fuehrt, nehmen Sie statt des 18-mm-Bundles STICKER-DAKKS-40X30MM-QR-JSON-SAMPLE — dieselbe Zeile, anderes Bundle. Der QR braucht Platz: ein Deep-Link mit uuid ergibt ein Symbol von rund 17,6 mm Kantenlaenge, damit es auf einem 203-dpi-Etikettendrucker zuverlaessig scannt. Auf 12 oder 18 mm bliebe daneben nichts mehr fuer Kalibrierzeichen und Datum.

Voraussetzung ist, dass QR-Links eingeschaltet sind (Administration > Grundeinstellungen > Portal). Sind sie aus, codiert derselbe QR die Inventarnummer statt eines Links.

Sie haben schon einen Auftragsbericht?

Auf aus V1 migrierten Systemen gibt es den Auftragsbeleg meist laengst. Heisst Ihre Zeile Auftragsbeleg und liegt sie unter booking/orders, wird sie beim Update uebernommen — sie behaelt Bundle, Briefkopf und Variablen und bekommt nur die Systemkennzeichnung dazu. Heisst sie anders (und das ist der haeufigere Fall), bleibt sie ein ganz normaler Bericht und daneben entsteht ein leerer Platzhalter. Das ist Absicht: viele Systeme haben mehrere Auftragsberichte, und calServer raet nicht, welcher davon „der richtige" ist. Sie koennen den Platzhalter entweder befuellen oder deaktivieren — nur fuer die E-Rechnung muessen Sie ihn benutzen.

Einen Systembericht einrichten

1. Referenz-Bundle aus calhelp/calServer-reports herunterladen — welches, steht in der Tabelle oben (und auf der Platzhalter-Zeile selbst). Es ist jeweils eine V2-JSON-Vorlage im Sinne von V2-Berichte mit JSON-Datenquelle: kein eingebettetes SQL, damit unabhaengig vom Datenbank-Backend.
2. In Administration > Berichtsverwaltung > Master-Reports die Platzhalter-Zeile suchen (Etikett Systembericht) und ueber Datei hochladen das Bundle als ZIP hinterlegen.
3. Fertig. Der Datensatz-Contract wird am Bundle erkannt (location-report beim Leihschein, price-list bei der Preisliste, order-document beim Auftragsbeleg, free-delivery-note beim Versandschein, inventory-datasheet beim Geraeteetikett, calibration-certificate beim Kalibrieraufkleber), eine Berichtsvariable data_contract ist nicht noetig.

Danach benutzt calServer den Bericht: Der Leihschein haengt an der E-Mail, die Preisliste steht als PDF-Knopf auf der Preislisten-Seite, der Auftragsbeleg im Berichte-Menue des Auftrags.

Ist nichts hochgeladen, passiert nichts Schlimmes — die Leihschein-Mail geht weiterhin raus, nur ohne Anhang, und die Preislisten-Seite sagt beim Klick auf PDF, dass noch keine Vorlage hinterlegt ist. Eine Buchung scheitert nie an einem fehlenden oder fehlerhaften Bericht.

Fensterbrief: Leihschein, Versandschein und Auftragsbeleg

Vier Referenz-Bundles sind Fensterbriefe nach DIN 5008 Form B — der Leihschein (LOCATION-JSON-SAMPLE), der Versandschein (FREE-DELIVERY-JSON-SAMPLE) und der Auftragsbeleg (ORDER-JSON-SAMPLE, samt der schlanken Lieferschein-Fassung DELIVERY-JSON-SAMPLE). Sie teilen dieselbe Geometrie: Anschriftfeld 20 mm von links und 45 mm von oben (85 × 45 mm), Ruecksendeangabe darueber im Feld, Informationsblock ab 125 mm, Betreffzeile bei 98,4 mm, Falz- und Lochmarken bei 105 / 148,5 / 210 mm. Ein DIN-lang-Umschlag nach DIN 680 zeigt damit genau die Anschrift.

Beim Auftragsbeleg gilt das in jeder Variante: Angebot, Auftragsbestaetigung, Lieferschein, Rechnung und der neutrale Beleg (bei einem Status ausserhalb der Statusgruppen) benutzen denselben Kopf; nur die Bloecke darunter unterscheiden sich. Welche Anschrift im Fenster steht, entscheidet der Belegtyp: Rechnungen adressieren die Rechnungsadresse, Lieferscheine die Lieferadresse, alles andere den Auftraggeber. Eine davon abweichende zweite Adresse steht als Info-Block unter der Betreffzeile, nicht im Fenster — dort ist nur Platz fuer eine.

Die vier Briefe passen auf Briefpapier

Hinterlegen Sie eine Bogenvorlage (Berichtseinstellung Vorlage verwenden, PDF-Vorlage oder globaler Briefkopf), legt calServer sie unter den Beleg — Seite 1 der Vorlage unter Belegseite 1, Seite 2 unter jede Folgeseite. Die vier Fensterbriefe halten dafuer eine feste Freizone ein und laufen nicht in Kopf, Fuss oder Seitenrand des Bogens:

Zone	Grenze auf dem Blatt
Satzspiegel links / rechts	20 mm / 195 mm
Oberkante Folgeseiten	26,8 mm
Oberkante Seite 1 (Anschriftfeld)	45 mm
Unterkante Inhalt	249 mm

Bleibt Ihr Briefkopf oberhalb von 26,8 mm und Ihr Fussblock unterhalb von 249 mm, passt jeder der vier Belege ohne Anpassung. Die 20 mm links sind bewusst der Rand, den vorgedrucktes Briefpapier ueblicherweise fuer seine Kopf- und Fusslinien benutzt: Tabelle und Trennlinien des Belegs stehen damit buendig unter dem Bogen.

Zwei Angaben druckt ein Bogen meist selbst. Damit sie nicht doppelt auf dem Blatt stehen, schalten Sie sie am Beleg ab:

Variable	Wirkung
show_fold_marks	0 schaltet Falz- und Lochmarken ab. Wirkt auf alle vier Fensterbriefe
show_supplier_footer	0 schaltet Anschrift, USt-IdNr./Steuernummer, Handelsregister und Bankverbindung in der Fusszeile ab. Nur der Auftragsbeleg druckt sie

Beide stehen ab Werk auf 1: Ohne Briefpapier muss der Beleg die Pflichtangaben nach Paragraf 14 UStG selbst tragen. Ein Bogen mit hoeherem Kopf oder Fuss als oben braucht eine angepasste Kopie des Bundles — welche vier Zahlen das sind, steht in der README des jeweiligen Bundles.

Der Leihschein als Versanddokument

Das Referenz-Bundle LOCATION-JSON-SAMPLE ist ein Fensterbrief nach DIN 5008 Form B: Die Lieferadresse steht im Anschriftfeld (20 mm von links, 45 mm von oben, 85 × 45 mm) und erscheint damit im Fenster eines DIN-lang-Umschlags. Darueber druckt die kleine Ruecksendeangabe, und die Pruefmittelliste traegt je Zeile ein Ankreuzfeld — der Schein ist zugleich die Abhakliste beim Packen und beim Wareneingang. Unterschriftszeilen hat er nicht: Das Blatt reist mit der Sendung, es wird nicht am Tresen quittiert.

Damit die Ruecksendeangabe nicht leer bleibt, brauchen die company_*-Berichtsvariablen einen Inhalt — dieselben, aus denen sich auch Versandschein und Auftragsbeleg bedienen. Am einfachsten mit report_type = all einmal pflegen:

Variable	Inhalt
company_sender_line	Die fertige einzeilige Absenderangabe. Leer lassen, dann setzt der Bericht sie aus den vier folgenden zusammen
company_name, company_street, company_zip, company_city	Absenderanschrift
company_country	Ihr Land. Steuert zugleich die Landzeile des Empfaengers: Sie wird nur gedruckt, wenn das Lieferland davon abweicht
show_fold_marks	0 schaltet Falz- und Lochmarken ab (fuer vorgedrucktes Briefpapier, das sie schon traegt). Wirkt auf alle vier Fensterbriefe

Sendungsnummer und Versandhinweis kommen aus der Buchung selbst — nur weiss calServer nicht von allein, in welchem Standortfeld Sie die beiden fuehren. Deshalb zeigen zwei Berichtsvariablen vom Typ location darauf:

Variable	Zeigt auf das Feld mit
shipping_tracking_field	der Sendungsverfolgungsnummer
shipping_note_field	der Bemerkung zur Sendung

Als Inhalt genuegt der api_name des Feldes, so wie ihn Administration > Feldverwaltung fuer die Tabelle location anzeigt (der Spaltenschluessel geht genauso — calServer uebersetzt ihn). Auf einer Werksvorgabe-Installation tragen die beiden Felder noch ihren V1-Code als api_name; nehmen Sie den Wert einfach aus der Feldverwaltung. Heisst das Feld bei Ihnen schon tracking_number bzw. shipping_note, findet der Bericht es ohne Variable.

Ist nichts konfiguriert, bleiben Sendungsnummer und Hinweis auf dem Schein weg — es steht dann kein leeres Feld da.

Ein eigenes Layout ist davon unberuehrt: Die Zeile nimmt jedes Bundle, und Form A (Anschriftfeld ab 27 mm) ist im Referenz-Bundle eine einzige Koordinate im Anschriftfeld-Rahmen.

E-Rechnung (ZUGFeRD) am Auftragsbeleg

Die E-Rechnung ist optional und wird an genau diesem Bericht eingeschaltet. Ohne die Variable aendert sich am heutigen Verhalten nichts.

Einschalten

Berichtsvariable zugferd am Auftragsbeleg setzen (Reiter Variablen der Berichtszeile), Inhalt:

Wert	Bedeutung
en16931	Das Profil, das die deutsche E-Rechnungspflicht erfuellt. Empfehlung.
basic	Kleinerer Pflichtumfang, fuer einfache Belege
extended	Erweitertes Profil

Nicht gesetzt heisst aus. Ein Tippfehler (en16391) heisst ebenfalls aus — es wird bewusst nicht auf ein Profil zurueckgefallen, das niemand gewaehlt hat.

Die Ausgabe greift nur, wenn der Auftrag in der Statusgruppe Rechnung steht und das Format PDF ist. Angebot, Auftragsbestaetigung und Lieferschein bleiben unveraendert.

Stammdaten, die dazugehoeren

Die E-Rechnung braucht mehr als der Ausdruck. Ergaenzen Sie bei den Berichtsvariablen (Typ booking oder all):

Variable	Wofuer
company_vat_id oder company_tax_number	Pflicht nach § 14 UStG
company_country (oder company_country_code)	Muss auf ein Land aufloesen — „Deutschland" und „DE" gehen beide
company_payment_due_days	Zahlungsziel in Tagen; daraus entsteht das Faelligkeitsdatum
company_iban, company_bic, company_bank_name	Zahlungsweg auf der Rechnung
zugferd_invoice_number_field	Nur wenn die Rechnungsnummer nicht die Auftragsnummer ist: api_name des Zusatzfeldes, das sie traegt
zugferd_delivery_date_field	api_name des Zusatzfeldes mit dem Leistungsdatum (§ 14 UStG)
zugferd_buyer_reference_field	api_name des Feldes mit der Kundenreferenz; bei Behoerden die Leitweg-ID

Rechnungsnummer-Feld: gesetzt heisst verbindlich

Ist zugferd_invoice_number_field konfiguriert und das benannte Feld am Auftrag leer, entsteht keine E-Rechnung — es wird nicht stillschweigend die Auftragsnummer genommen. Sonst traegt die Rechnung eine Nummer, die Ihre Buchhaltung nicht kennt, und niemand merkt es.

Vorher pruefen

Bevor Sie scharfschalten, pruefen Sie an einer echten Rechnung:

GET /api/v2/bookings/{auftrag-id}/reports/{bericht-id}/einvoice

Antwortet der Endpunkt mit dem XML, reichen Ihre Stammdaten. Antwortet er mit 422, steht in der Antwort, was fehlt — Steuernummer, Landescode, Rechnungsnummer. Der Endpunkt funktioniert auch ohne gesetzte zugferd-Variable; er ist genau dafuer da, das Einschalten vorzubereiten.

Derselbe Endpunkt liefert das reine XML fuer Empfaenger, die kein Hybrid-PDF nehmen (Behoerden, manche Grosskunden).

Was dabei herauskommt

Ein PDF/A-3b mit eingebetteter factur-x.xml — auf allen Wegen, auf denen die Rechnung das Haus verlaesst: Download, E-Mail-Anhang, DMS-Ablage und Freigabe. Die Vorschau bleibt ein einfaches PDF; ein XML-Anhang ist am Bildschirm ohnehin nicht zu sehen.

Wenn etwas schiefgeht

Scheitert die Einbettung, geht das PDF ohne Anhang raus und der Grund ins Log. Eine Installation, die nach dem Einschalten gar keine Rechnungen mehr drucken kann, waere der schlechtere Ausfall. Ob eine Rechnung als E-Rechnung taugt, sagt Ihnen vorher der Pruef-Endpunkt.

Grenzen

• Steuerkategorien nur Regelsatz und 0 %. § 19 UStG (Kleinunternehmer), Reverse Charge und innergemeinschaftliche Lieferung brauchen zusaetzliche Befreiungsgruende und sind noch nicht abgedeckt.
• Gutschriften und Storno-Belege noch nicht.
• Einheiten, die der internationale Katalog nicht kennt, werden als „Stueck" codiert. Der gedruckte Text bleibt unveraendert; der Pruef-Endpunkt sagt Ihnen, welche Einheiten das betrifft.

Besonderheiten der Etiketten

Etiketten sind Berichte wie alle anderen — mit drei Unterschieden.

Sie gehen durch die Vorschau wie jeder Bericht. Ein Klick auf Etikett drucken oeffnet die Berichts-Maske: Jasper rendert, die Vorschau zeigt den Aufkleber, Drucken gibt ihn an den Druckdialog. Bis August 2026 sprang der Etikettendruck direkt in den Druckdialog — was auf dem Aufkleber steht, sah man damit erst auf dem Papier, und ein falsch belegter Bogen Etiketten ist nicht rueckgaengig zu machen. Die Seitengroesse kommt weiterhin aus der Vorlage: Ein Label-JRXML mit 30x15 mm laesst den Dialog nach Etikettenpapier fragen, nicht nach DIN A4. Die alte Einstellung „Label-Hoehe" wird dafuer nicht mehr gebraucht und gilt nur noch fuer calServer V1.

Eine Auswahl ist ein Druck. Mehrere Zeilen markieren und Etiketten drucken in der Werkzeugleiste klicken erzeugt eine PDF mit einem Etikett je Zeile, in der Reihenfolge der Auswahl. Nicht zwanzig Downloads mit zwanzig Druckdialogen. Die Vorschau zeigt den ganzen Stapel vor dem Druck und traegt die Anzahl im Titel; ausser Drucken und Herunterladen bietet sie dort nichts an — DMS-Ablage, Freigabe, Unterschrift und Versand haengen alle an einem Datensatz, den ein Stapel nicht hat. Hoechstens 500 Etiketten je Druck — darueber sagt die Oberflaeche, wie viele es sind und dass die Auswahl kleiner werden muss.

Zwei Grundeinstellungen wirken mit. Unter Grundeinstellungen > Regeln > Barcode & Etikett:

Einstellung	Wirkung auf das Etikett
Barcode-Typ	Symbologie, in der die Vorlage den Code rendert (DataMatrix, QR, Code 128/39, Codabar, EAN, UPC, 2 aus 5 Interleaved). „Deaktiviert" druckt keinen Code
Barcode-Feld	Welches Feld den Wert liefert, der codiert wird. api_name oder V1-Code

Aufbau und Groesse des Etiketts stehen dagegen in der Vorlage, nicht in einer Einstellung. Wer ein anderes Layout braucht, laedt ein anderes Bundle hoch — so wie bei jedem anderen Bericht auch.

Mehrere Etikettenformate

Ein Duplikat eines Systemberichts ist ein ganz normaler Bericht und behaelt das Etiketten-Kennzeichen nicht. Wer ein zweites Format braucht (z. B. 12 mm und 18 mm), legt eine zweite Berichtszeile an und setzt dort Etikett selbst.

Ab dem zweiten Etikettenbericht fragt calServer, statt zu waehlen: Das Zeilenmenue zeigt dann einen Eintrag je Etikettenbericht, mit dessen Namen dahinter („Etikett drucken (Geraeteetikett)"), und Etiketten drucken in der Werkzeugleiste laesst vor dem Stapel auswaehlen. Der Systembericht steht dabei vorn und ist vorausgewaehlt. Bei genau einem Etikettenbericht — dem Normalfall — bleibt es beim einen Eintrag ohne Rueckfrage.

Steht ein Etikettenbericht ohnehin schon namentlich im Menue (Platzierung Detail oder Master-Detail), bekommt er keinen zweiten Eintrag: Beide oeffneten dieselbe Vorschau. „Etikett drucken" erscheint dort also nur fuer einen Etikettenbericht, den das Menue sonst gar nicht fuehrt — etwa einen mit Platzierung Master.

Besonderheiten der Preisliste

Die Preisliste hat keinen Datensatz, an dem sie haengt: Ihr „Gegenstand" ist das Paar aus Preisgruppe und Stichtag, beides oben auf der Seite Preise > Preisliste einstellbar. Beide Werte gehen als Parameter in den Bericht und stehen im Dateinamen (Preisliste_<Gruppe>_<Stichtag>.pdf).

Der Briefkopf kommt wie bei jedem Bericht ueber das Overlay der Berichtsverwaltung, nicht aus der Vorlage. Das Referenz-Bundle laesst dafuer oben bewusst Platz frei und druckt dort selbst nichts — deshalb passt dieselbe Vorlage fuer jeden Mandanten.

Anders als der Leihschein steht die Preisliste nicht in der Berichtsauswahl der E-Mail-Vorlagen: Sie wird gedruckt und uebergeben, nicht automatisch verschickt.

Besonderheiten des Versandscheins

Der Versandschein hat wie die Preisliste keinen Datensatz, an dem er haengt — nur haengt er hier an gar keinem: Das Papier entsteht fuer Geraete, zu denen es noch keinen Vorgang gibt. Warenannahme am Tresen, Ruecksendung nach der Kalibrierung, Uebergabe an ein Fremdlabor. Zusammengestellt wird es im Arbeitsplatz Schnellerfassung > Versandschein aus vier Angaben: Kunde, Lieferanschrift, Kopfdaten (Nummer, Datum, Betreff, Ansprechpartner, Sendungsnummer, Hinweis) und der Geraeteliste.

Gespeichert wird nichts. Der Arbeitsplatz sammelt, druckt und vergisst; es entsteht kein Auftrag, keine Leihe und kein Dokument in der Dokumentenverwaltung. Wer den Vorgang festhalten will, legt einen Auftrag an — dann ist es kein freier Versandschein mehr, sondern der Lieferschein zum Auftrag (das ist der Auftragsbeleg).

Welche Anschrift ins Fenster kommt, entscheidet calServer: Traegt der gewaehlte Lieferkontakt eine eigene Anschrift (das ist bei Lieferadressen der Normalfall — „Wareneingang, Tor 3"), geht die Sendung dorthin; sonst an die Kundenanschrift. Der Empfaengername ist immer der Kunde.

Absenderangaben kommen aus denselben company_*-Berichtsvariablen wie beim Auftragsbeleg und beim Leihschein (siehe Der Leihschein als Versanddokument). Ohne sie bleibt die Ruecksendeangabe leer; das ist kein Fehler, der Umschlag traegt sie dann selbst.

Berechtigung: Der Arbeitsplatz haengt an der Operation Versandschein (individual_delivery_report) — dieselbe, die in calServer V1 den freien Lieferschein freigegeben hat. Eine aus V1 uebernommene Rolle kann also unveraendert weiterbenutzt werden. Die Auswahllisten der Maske folgen den gewoehnlichen Leserechten: Ohne Kunden ansehen bzw. Inventar ansehen bleiben sie leer.

Migriert aus V1? Dann stehen dort zwei Zeilen

Auf einem aus V1 uebernommenen System gibt es den alten Bericht Free_Delivery.jrxml unter booking/individual_delivery weiterhin — V1 sucht ihn genau dort, und solange beide Staende parallel laufen, wird er nicht angefasst. Der V2-Platzhalter entsteht daneben, unter free_delivery. Nach der V1-Abschaltung koennen Sie die alte Zeile loeschen; sie ist ein ganz normaler Bericht.

Wer seine angepasste V1-Vorlage mitnehmen moechte, laedt sie auf den neuen Platz hoch: Die Parameter heissen unveraendert Dokumentnummer_Val, Dokumentdatum_Val, Kundennummer_Val, Header_Standard, Ansprechpartner_Val, Email_Adresse_Val und Telefon_Val. Die Geraeteliste zieht eine solche Vorlage weiter ueber ihr eigenes SQL — ein SQL-Bundle bekommt keinen JSON-Datensatz.

Vorschau aus dem Buchungsformular

Beim Ausleihen laesst sich der Leihschein vor dem Buchen ansehen: im Buchungsformular unter dem Haekchen „Leihschein per E-Mail senden" liegt Leihschein-Vorschau. Sie rendert den Bericht aus den Werten, die gerade im Formular stehen — Geraet, Kunde, Lieferkontakt, Leihzeitraum, Bemerkung.

Gerendert wird ueber denselben Bericht, den auch die E-Mail anhaengt, mit demselben Briefkopf. Was die Vorschau zeigt, geht also auch raus.

Dabei wird nichts geschrieben: kein Leiheintrag, keine Belegung, und Nummernkreise ([GLOBAL_COUNTER_1] & Co. in den Feld-Vorgaben) werden nur vorgerechnet, nicht verbraucht. Zweimal vorschauen ueberspringt keine Nummer.

Bei einer Set-Buchung zeigt die Vorschau das Hauptgeraet — so wie auch nur ein Leihschein fuer das ganze Set verschickt wird.

Braucht eine V2-JSON-Vorlage

Die Vorschau setzt voraus, dass der hinterlegte Leihschein ein V2-Bundle mit JSON-Datenquelle ist. Eine klassische SQL-Vorlage liest den Leiheintrag aus der Datenbank — den es vor dem Buchen noch nicht gibt, sie koennte also nur ein leeres Blatt liefern. In dem Fall sagt die Vorschau das und rendert nichts. Ist gar kein Bericht hochgeladen oder der Bericht deaktiviert, nennt sie ebenfalls den Grund.

Eigene Vorlage statt der Referenz

Die Referenz-Bundles sind Startpunkte, keine Vorschrift. Wer ein eigenes Layout hat, laedt es genauso hoch — auch eine klassische V1-Vorlage mit eingebettetem SQL funktioniert auf derselben Zeile (dann laeuft sie ueber JDBC statt ueber den JSON-Datensatz).

Wo der Leihschein sonst noch haengen kann

Auf aus V1 migrierten Systemen kann die Leihschein-Mail einen Bericht direkt zugewiesen haben: in der E-Mail-Vorlage location_create ueber Anhang = Master-Report plus Berichtsauswahl. Diese Zuweisung hat weiterhin Vorrang vor dem Platzhalter — eine bestehende Konfiguration aendert sich durch das Update also nicht. Zeigt sie ins Leere (Bericht geloescht), faellt calServer auf den Platzhalter zurueck.

Wer die Zuweisung loswerden will, setzt den Anhang der Vorlage zurueck; danach zieht ausschliesslich der Platzhalter.