Verträge und Vereinbarungen als PDF

Klauseln, die nur erscheinen, wenn sie gelten

Der größte Teil eines Vertrags ist für alle gleich. Was sich unterscheidet, sind eine Handvoll Werte und ein paar Klauseln. Die Werte sind Felder der Daten. Eine Klausel, die nur manche Geschäfte haben, steht in einer Bedingung: Das Beispiel druckt seine Abwerbeklausel, wenn die Daten ihr eine Zahl von Monaten geben, {{#if agreement.non_solicitation_months}}, und lässt sie sonst weg.

Sicher wird das durch die Nummerierung. Die Nummern schreiben CSS-Zähler; die Klausel nach einer ausgelassenen rückt also von selbst auf, und kein Vertrag geht hinaus, in dem auf Klausel 5 die Klausel 7 folgt.

ol.clauses { margin: 6mm 0 0; padding: 0; list-style: none; counter-reset: clause; }
ol.clauses > li { counter-increment: clause; margin-bottom: 4mm; }
ol.clauses h2::before { content: counter(clause) ". "; }

Daten und Zahlen kommen von Helfern: date formatiert ein Datum für die Sprache der Vorlage, dateAdd rechnet den Tag aus, an dem eine Laufzeit endet, und numToWords schreibt eine Zahl auf Deutsch, Englisch, Französisch, Spanisch, Italienisch oder Niederländisch aus. Der Unterschriftsblock hat break-inside: avoid; eine Unterschriftslinie landet also nie ohne ihren Namen auf einer Seite. Das NDA-Beispiel ist die vollständige Vorlage mit ihren Daten.

Kein Vertrag mit einer Lücke

Ein Feld, das Ihr Code vergessen hat, wird als leerer Text gedruckt, und ein Vertrag mit leerem Parteinamen ist schlechter als kein Vertrag. Speichern Sie ein Datenschema bei der Vorlage, kennzeichnen Sie die Felder, ohne die ein Vertrag nicht auskommt, als Pflichtfelder, und senden Sie "validate_data": true mit dem Rendering. Daten, die nicht passen, werden dann mit 422 data_validation_error und einer Liste aller fehlenden oder falschen Felder abgelehnt, bevor etwas gerendert oder gezählt wird.

Dasselbe Schema wirkt, bevor überhaupt eine Anfrage gesendet wird. Der Editor unterstreicht Variablen, die in den Beispieldaten fehlen, formfeed types macht aus dem Schema TypeScript- oder Python-Typen, sodass ein fehlendes Feld schon in Ihrem eigenen Editor ein Fehler ist, und das Veröffentlichen einer Version, deren Schema Daten ablehnen würde, die die veröffentlichte annimmt, wird angehalten, bis jemand es erlaubt. Mehr unter typisierte Vorlagendaten.

Wortlaut mit Geschichte

Eine Vertragsvorlage ändert sich, wenn die Rechtsabteilung einen Satz ändert, und es kommt darauf an, welche Verträge vorher hinausgegangen sind. Jedes Speichern einer Vorlage ist eine neue Version, nie die Änderung einer alten. Die API rendert die veröffentlichte Version; ein neuer Wortlaut gilt also, wenn ihn jemand veröffentlicht, nicht wenn er gespeichert wird. Im Editor steht jede gespeicherte Version auf Wunsch neben der, an der Sie arbeiten, und eine ältere lässt sich als neuer Entwurf wiederherstellen.

Wem der Wortlaut gehört, der muss kein HTML lesen. Mit Text bearbeiten klicken Inhaber, Admins und Editoren in der Vorschau auf einen Absatz und tippen, und die Werte aus den Daten bleiben Werte; Text mit einer Bedingung darin wird im Code geändert. Ein Absatz, den mehrere Verträge teilen, eine Haftungsklausel oder ein Unterschriftsblock, kann ein geteiltes Partial sein: Einmal geändert, steht der neue Text binnen einer Minute in jeder Vorlage, die ihn einbindet, auch in den veröffentlichten. Ab dem Starter-Plan hat eine Vorlage außerdem Release Channels; ein Staging-System rendert dann den Wortlaut, der für es freigegeben wurde.

Welchen Text haben sie erhalten?

Jedes Rendering speichert, woraus es entstanden ist: die Nummer der Vorlagenversion, eine Prüfsumme dieser Version (template_checksum), den Chromium-Build und die Vorlagensprache (engine_version) und einen SHA-256 der Datei (output_sha256). Bewahren Sie die beiden Prüfsummen beim Vertrag in Ihrem eigenen System auf: Die erste sagt später, welche Version des Wortlauts die Datei erzeugt hat, die zweite, dass eine Datei Byte für Byte die gerenderte ist. meta in der Anfrage trägt Ihre Vorgangs- oder Kundennummer in das Rendering, das Render-Protokoll und jeden Webhook.

Ein geteiltes Partial ist von dieser Prüfsumme nicht erfasst, weil es sich ohne neue Version der Vorlage ändert. Das Rendering hält die Version jedes geteilten Partials fest, das es verwendet hat, und sein Eintrag in der App zeigt sie. Wortlaut, der an eine Version eines Vertrags gebunden sein muss, gehört in die Vorlage selbst.

AGB anhängen, Entwurf kennzeichnen, Datei verschließen

Ein Vertrag reist selten allein. post führt PDF-Schritte am fertigen Dokument im selben Rendering aus: merge_after hängt weitere PDFs an, etwa Ihre AGB aus der Dateibibliothek oder eine eben gerenderte Anlage, watermark stempelt einen Text oder ein Bild über jede Seite, und password verschlüsselt das Ergebnis mit AES-256.

{
  "template": "mutual-nda",
  "data": { … },
  "post": {
    "merge_after": ["terms.pdf"],
    "watermark": { "text": "DRAFT", "opacity": 0.15 },
    "password": { "user": "open-sesame", "permissions": ["print"] }
  }
}

Die Schritte laufen immer in dieser Reihenfolge, gleich in welcher die Anfrage sie nennt, weil ein verschlüsseltes PDF nicht mehr geändert werden kann. Jeder Schritt kostet eine halbe Einheit zusätzlich zum Rendering, und Post-Processing setzt den Starter-Plan voraus. Ein Passwort zum Öffnen hält die Datei vertraulich; die Berechtigungen (print, copy, modify, annotate) beachten PDF-Viewer, sie sind aber kein Schutz gegen jemanden, der die Datei öffnen kann. Dateien der Bibliothek sind für jeden öffentlich, der ihre Adresse kennt, und laufen nicht ab: richtig für AGB, falsch für alles Vertrauliche.

Dieselben drei Werkzeuge arbeiten auch auf Dokumenten, die Sie früher gerendert haben, über POST /v1/pdf/merge, /pdf/watermark und /pdf/protect: siehe PDF-Tools. Das Angebot als Entwurf und die vertrauliche Gehaltsabrechnung sind Beispiele mit Wasserzeichen und Passwort in ihrer Anfrage.

Wenn der Vertrag eine Word-Datei ist

Viele Verträge gibt es als Word-Dokument, das die Rechtsabteilung freigegeben hat, und ein Nachbau in HTML hieße, es noch einmal freizugeben. Ab dem Starter-Plan kann diese Datei die Vorlage sein: Tippen Sie dieselben Tags in ihren Text, {{ party_a.name }}, wo ein Name hingehört, eine Bedingung allein in einem Absatz vor und nach einer Klausel, und laden Sie die Datei hoch. Ein Rendering füllt eine Kopie und gibt sie als DOCX zurück, für eine Gegenseite, die darin kommentieren will, oder als PDF. Papier, Ränder, Kopf- und Fußzeilen bleiben, was das Dokument sagt; eine Änderung am Wortlaut wird in Word gemacht und neu hochgeladen. Mehr unter Word- und PowerPoint-Vorlagen.

Was ein Vertrag kostet

Ein Vertrag mit bis zu fünf Seiten ist eine Einheit, und jede weiteren fünf Seiten kosten eine mehr. AGB anhängen, ein Wasserzeichen und ein Passwort kosten je eine halbe Einheit. Der Free-Plan hat 100 Einheiten im Monat und verlangt keine Kreditkarte; Post-Processing und Word-Vorlagen beginnen mit Starter, das 3.000 Einheiten für 19 € im Monat hat. Renderings mit einem Test-Schlüssel kosten nichts, solange Sie bauen, und ein fehlgeschlagenes Rendering wird nie gezählt. Alle Pläne stehen auf der Preisseite.

Was bei Ihnen bleibt

Formfeed druckt den Vertrag, den Ihre Vorlage und Ihre Daten beschreiben. Es schreibt den Wortlaut nicht und prüft ihn nicht: Das Beispiel zeigt die Mechanik, und Ihren Text sollte eine Juristin oder ein Jurist lesen, bevor er hinausgeht. Es holt keine Unterschriften ein und fügt keine Signaturfelder ein; das PDF geht an den Signaturdienst, den Sie nutzen, oder in den Drucker. Und es ist nicht Ihr Archiv: Dateien bleiben für die Aufbewahrung Ihres Plans erhalten, einen Tag im Free-Plan, 30 Tage bei Starter und 365 Tage bei Pro; speichern Sie also jeden Vertrag selbst. Ab dem Pro-Plan geht von jeder Datei beim Rendern eine Kopie in Ihren eigenen S3- oder R2-Bucket.