Das E-Signatur-Modul bietet Administratoren weitreichende Möglichkeiten, das Verhalten an die individuellen Anforderungen Ihres Unternehmens anzupassen.
Konfiguration der Systemeinstellungen
Die grundlegende Verbindung werden über die Systemeinstellungen gesteuert. Diese werden durch den Initialisierungsprozess befüllt, können bei Bedarf (z.B. Wechsel von der Demo- zur Produktivumgebung) jedoch manuell angepasst werden:
-
Basis-Url: Der API-Endpunkt. Für Produktivsysteme in Europa lautet dieser in der Regel https://eu.docusign.net/ und ist entsprechend vorbelegt.
-
Authentifizierungs-Url: Ist entsprechend für Produktivsysteme auf https://account.docusign.com vorbelegt.
-
API Account Id: Ihre eindeutige DocuSign-Kontonummer.
-
Integration Key: Die Client-ID der registrierten App.
-
Secret Key: Das Client-Secret der registrierten App.
Gestaltung der Unterschriften-Größe
Die visuelle Darstellung der Unterschrift im finalen PDF-Dokument wird über zwei Parameter in der E-Signatur-Entität gesteuert:
-
Breite der Unterschrift (SignWidth ): Standardwert ist 100 Pixel.
-
Höhe der Unterschrift (SignHeight): Standardwert ist 40 Pixel.
Diese Werte werden beim API-Aufruf an Docusign übergeben und bestimmen die Skalierung des Unterschriftenfeldes. Sie können im Rahmen von Kundenprojekten je nach Dokumententyp angepasst werden.
Bindefristen und Ablaufsteuerung
Im CRM-Standard wird beim Start des Prozesses kein festes Ablaufdatum (Deadline) übergeben. In diesem Fall greift die Standard-Bindefrist von Docusign, welche 120 Tage beträgt. Nach Ablauf dieser Frist markiert Docusign den Umschlag automatisch als "voided" (ungültig). Über den Connect-Webhook wird dieser Status an das CRM gemeldet, woraufhin der Prozess dort als FEHLERHAFT geschlossen wird.
Eine kundenindividuelle Anpassung ermöglicht es, das Feld Deadline dynamisch vorzubelegen (z.B. Angebotsbindefrist + 14 Tage), um kürzere Fristen zu erzwingen.
Vorbereitung von Dokumentenvorlagen (Anchor-Tags)
Damit Docusign weiß, an welcher Stelle im PDF-Dokument die Unterschrift platziert werden soll, müssen in den Word-Vorlagen eindeutige Textanker (Anchor-Tags) eingefügt werden.
Funktionsprinzip
Ein Textanker ist eine reine Positionskoordinate für Docusign. Er enthält keine Formatierungen. Docusign sucht im generierten PDF nach diesem Text und platziert das Unterschriftenfeld exakt darüber.
Best Practices für Administratoren:
-
Eindeutige Syntax verwenden: Nutzen Sie die Standard-Konvention \s{Nummer}\ für Unterschriftenfelder.
-
\s1\ für den ersten Unterzeichner.
-
\d1\ für das Datum
-
-
\s2\ für den zweiten Unterzeichner.
-
\d2\ für das Datum
-
-
Textanker unsichtbar machen: Damit die Zeichenketten im gedruckten oder finalen Dokument den Lesefluss nicht stören, formatieren Sie den Text in der Word-Vorlage in weißer Schriftfarbe auf weißem Grund. Docusign kann den Text im PDF-Quellcode weiterhin auslesen, für den Unterzeichner ist der Textanker jedoch nicht sichtbar.
-
WICHTIG – Keine Ausblendung nutzen: Verwenden Sie nicht die Word-Funktion "Text ausblenden". Ausgeblendete Texte werden beim PDF-Export des CRM-Systems vollständig entfernt, wodurch Docusign die Ankerpunkte nicht mehr finden kann.
Beispiel einer Word-Vorlage mit markierten unsichtbaren Textankern
Erweiterung auf mehrere Unterzeichner (Kundenindividuell)
Während der CRM-Standardprozess für Angebote auf einen Unterzeichner (den externen Ansprechpartner) ausgelegt ist, unterstützt das Datenmodell und die API-Schnittstelle beliebig viele Unterzeichner.
Sie können das System so konfigurieren, dass:
-
Sequenzielles Signieren: Unterzeichner erhalten die Signatur-E-Mail nacheinander. Dies wird über aufsteigende Werte im Feld routingOrder gesteuert (z.B. erst Ansprechpartner routingOrder = 1, danach interner Geschäftsführer routingOrder = 2).
-
Paralleles Signieren: Alle Unterzeichner erhalten die E-Mail gleichzeitig und können in beliebiger Reihenfolge unterschreiben (alle besitzen dieselbe routingOrder).
-
Als Unterzeichner können flexibel sowohl externe Ansprechpartner als auch interne Mitarbeiter definiert werden.