Signaturit in Odoo: Was ein natives Modul bietet, das Zapier nicht bietet

Kurze Antwort: Mit Zapier können Sie eine Signatur auslösen und erfahren, dass sie abgeschlossen wurde. Es reicht nicht, um die Zwischenstatus eines Dokuments in Odoo abzubilden, um sich von einem verlorenen Webhook zu erholen oder um das signierte PDF und sein Nachweisdokument im richtigen Datensatz abzulegen. Wenn Ihr Prozess endet, sobald der Kunde unterschreibt, genügt ein Zap und ist günstiger. Wenn Ihr Prozess beginnt, sobald der Kunde unterschreibt (Rechnung stellen, Vorgang eröffnen, einen Mitarbeiter anlegen), brauchen Sie die Status im ERP.

Ausgangspunkt: Das Dokument reist per E-Mail

Der übliche Ablauf hat drei manuelle Schritte: Jemand erzeugt in Odoo das PDF des Angebots, lädt es im Signaturit-Panel hoch und wartet; wenn der Kunde unterschreibt, landet das signierte PDF im Postfach einer Person; diese lädt es wieder in Odoo hoch, falls sie daran denkt. Die Symptome sind immer dieselben: Niemand weiß, ob der Kunde das Dokument geöffnet hat, das signierte PDF landet auf dem Desktop von irgendjemandem, und wenn der Nachweis gebraucht wird (das Nachweisdokument, der audit trail), liegt er nicht neben der Rechnung, wo ihn jeder suchen würde.

Vorab eine Voraussetzung, die alle drei Wege gleichermaßen betrifft: Ihr Signaturit-Tarif muss API-Zugang enthalten. Die Authentifizierung erfolgt über ein Bearer-Token, das Sie im Panel erzeugen, und Sandbox und Produktion sind zwei getrennte Einträge mit zwei verschiedenen Tokens. Signaturit veröffentlicht nicht offen, welche Tarife diesen Zugang enthalten, klären Sie das also mit dem Anbieter, bevor Sie etwas planen. Ohne Token gibt es weder Zap noch n8n noch Modul.

Die drei Wege der Verbindung und wann Zapier genügt

Die Signaturit-App in Zapier bietet derzeit einen einzigen Trigger («New Signed Document», also «ein Dokument wurde signiert») und fünf Aktionen: eine Signaturanfrage erstellen, sie aus einer Vorlage erstellen, sie stornieren, eine Erinnerung senden und eine zertifizierte E-Mail erstellen. Die App für selbst gehostetes Odoo stellt ihrerseits generische Triggers und Aktionen für Datensätze bereit (einen Datensatz, einen Lead, eine Aufgabe anlegen …). Das ist das gesamte verfügbare Rohmaterial.

Wann Zapier genügt (und Sie aufhören können zu lesen)

Wenn Sie nur einen Dokumenttyp, nur wenige pro Monat versenden und lediglich möchten, dass bei der Unterschrift eine Aufgabe entsteht oder ein Chat benachrichtigt wird, bauen Sie einen Zap und denken nicht weiter darüber nach. Es genügt auch, wenn das Dokument nicht in Odoo entsteht (ein NDA, das im Signaturit-Panel vorbereitet wurde). Die Regel lautet: Wenn der Signaturstatus keine Entscheidung im ERP verändert, muss das ERP ihn nicht kennen.

Welches Dokument aus welchem Odoo-Modell stammt

Das ist der Teil, den ein generischer Schritt «Datensatz erstellen» nicht leisten kann: Er weiß nicht, wie der QWeb-Bericht eines Verkaufsauftrags gerendert wird. Jedes Modell braucht drei eigene Angaben: den Titel, den der Unterzeichner sieht, den Standardempfänger und die Art, wie das PDF erzeugt wird. Im von uns gebauten Konnektor löst jede Brücke genau diese drei Punkte.

• Angebot und Verkaufsauftrag (sale.order): der Standardbericht des Verkaufsauftrags, mit dem Kunden als Unterzeichner.
• Rechnung (account.move) und Bestellung (purchase.order), für Annahmen und Lieferantenbestätigungen.
• Lieferschein (stock.picking): der Lieferscheinbericht, der nach der Unterschrift als Liefernachweis dient.
• Arbeitsvertrag: hr.contract in Odoo 17 und 18 sowie hr.version in Odoo 19, wo das Personalmodul neu aufgebaut wurde. Genau die Art von Detail, die dazu zwingt, drei Code-Zweige zu pflegen statt einen.
• Angebot an einen Bewerber (hr.applicant), CRM-Verkaufschance (crm.lead), Ticket (helpdesk.ticket) und Projekt und Aufgabe, für Abnahmen erbrachter Arbeit.

Der vollständige Statuszyklus, an dem alles andere scheitert

Die Signaturit-API v3 meldet pro Dokument acht Status: in_queue, ready, signing, completed, expired, canceled, declined und error. Ihre Webhook-Ereignisse sind noch feiner gegliedert: E-Mail zugestellt, E-Mail zurückgewiesen, Dokument geöffnet, Dokument signiert, Ausweisdokument hinzugefügt, Ablauffrist verlängert, audit trail erzeugt …

In Odoo muss das zu zwei verschiedenen Dingen werden. Erstens: die Anfrage selbst mit ihrem eigenen Zyklus (Entwurf, gesendet, in Bearbeitung, abgeschlossen, abgelehnt, abgelaufen, storniert, Fehler). Zweitens: ein Feld im Ursprungsdokument, damit der Vertriebsmitarbeiter, der das Angebot öffnet, den Status sieht, ohne das Angebot zu verlassen. In unserem Konnektor hat dieses Feld sieben Werte: nicht gesendet, Signatur ausstehend, signiert, abgelehnt, abgelaufen, storniert und Fehler.

Bei mehreren Unterzeichnern muss der Status aus der Gesamtheit abgeleitet werden: alle abgeschlossen, abgeschlossen; einer lehnt ab, abgelehnt; einige haben signiert und andere nicht, in Bearbeitung. Und es gibt einen Schutz, den man nur durch Scheitern lernt: Eine von Hand stornierte Anfrage darf niemals von einem späteren Ereignis überschrieben werden, denn Signaturit kann error pro Dokument in einer Anfrage melden, die Sie bereits storniert hatten. Ohne diesen Schutz wird eine bewusste Stornierung von selbst zu einem unerklärlichen Fehler.

Das letzte Teil: Die drei schlechten Endstatus (abgelehnt, abgelaufen und Fehler) dürfen nicht damit enden, nur eine Farbe zu ändern. Im Konnektor erzeugen sie eine offene Aktivität für die Person, die die Anfrage erstellt hat, mit der Anweisung zu entscheiden, ob erneut gesendet, die Frist verlängert oder ersetzt wird. Eine Ablehnung, die niemand ansieht, ist genau dasselbe, wie nichts davon zu erfahren.

Wiederholungen und Fehler: Warum ein verlorener Webhook schlimmer ist als ein sichtbarer Fehler

Ein sichtbarer Fehler hält Sie auf. Ein verlorener Webhook lässt Sie glauben, das Dokument sei noch offen, obwohl es seit Tagen signiert ist, oder umgekehrt. Die zweite Situation ist viel teurer, weil niemand sie sucht.

Wiederholungen müssen asymmetrisch sein. Im Konnektor hat jeder Aufruf standardmäßig ein Zeitlimit von 30 Sekunden, konfigurierbar. Ein Lesezugriff (GET) wird bei einem 429, 500, 502, 503 oder 504 bis zu zweimal mit steigender Wartezeit wiederholt. Ein Schreibzugriff (POST, PATCH, DELETE) wird nie wiederholt: Eine nicht idempotente Erstellung zu wiederholen bedeutet, denselben Vertrag zweimal an denselben Unterzeichner zu senden. Ein sichtbarer Fehler ist besser als ein stilles Duplikat. Und eine Regel, die oft fehlt: Eine Weiterleitung der API wird als harter Fehler behandelt und nie verfolgt, denn sie mit gesetztem Autorisierungs-Header zu verfolgen hieße, Ihr Token an die Adresse zu übergeben, die der Location vorgibt.

Der Webhook ist nicht die Wahrheit: Er ist eine Türklingel. Signaturit signiert seine Webhooks nicht kryptografisch (kein HMAC), und seine Dokumentation beschreibt keine automatische Wiederholungsrichtlinie; es bietet aber einen Endpoint, um ein Ereignis von Hand erneut auszulösen. Vor diesem Hintergrund wird das eingehende Ereignis im Konnektor mit einem Token pro Konto in der URL selbst authentifiziert, optional auf die von Signaturit veröffentlichte Ursprungs-IP beschränkt (nur eine, in Sandbox und Produktion dieselbe), mit einem Deduplizierungsschlüssel aus dem SHA-256 des kanonisierten JSON registriert, und erst dann wird die authentifizierte API erneut abgefragt. Eine doppelte Zustellung antwortet mit 200 und wird nicht zweimal verarbeitet.

Und wenn das Ereignis nie eintrifft, gibt es ein Sicherheitsnetz: Ein stündlicher Cron geht bis zu 200 ausstehende Anfragen durch und fragt sie erneut ab. Diese Zeile ist der eigentliche Unterschied zu einem Zap. Der Zap hängt vom Webhook ab; geht der Webhook verloren, gibt es nichts weiter.

Der zurückkehrende Anhang: Wo er liegt, wie er heißt und mit welcher Nachweisspur

Wenn die Anfrage den Status «abgeschlossen» erreicht, kommen zwei Dateien zurück, nicht eine. Das signierte PDF wird als <nombre>.signed.pdf und das Nachweisdokument als <nombre>.audit_trail.pdf abgelegt, beide am Datensatz der Anfrage angehängt, der wiederum auf das Angebot, die Rechnung oder den Lieferschein verweist, aus dem sie stammt. Keines von beiden landet im Postfach von irgendjemandem.

Ein Detail, das nur in der Produktion auftritt: Das Nachweisdokument ist nicht immer fertig, wenn das Dokument signiert wird. Signaturit erzeugt es separat und sendet ein eigenes Ereignis, sobald es verfügbar ist. Schlägt der Download fehl, darf keine Lücke bleiben: Man muss die Erzeugung ausdrücklich anfordern und es im nächsten Zyklus abrufen. Ein Konnektor, der das signierte PDF herunterlädt und die Spur vergisst, lässt Sie mit der Hälfte des Nachweises zurück. Und wenn Sie den Unterzeichner gebeten haben, Unterlagen hochzuladen (Ausweis, Wohnsitznachweis), werden diese Dateien separat in einem ZIP in denselben Datensatz heruntergeladen.

Worauf Sie vor der Wahl des Ansatzes achten sollten

1. Wie viele Dokumenttypen senden Sie zur Signatur? Nur einen: ein Zap. Vier oder mehr, jeder mit eigenem PDF und eigenem Empfänger: Vier Zaps zu pflegen kostet bereits mehr als ein Modul.
2. Verändert der Signaturstatus eine Entscheidung in Odoo? Wenn nach der Unterschrift fakturiert, geplant oder jemand angelegt werden muss, braucht das ERP den Status. Wenn nur jemand benachrichtigt werden soll, nicht.
3. Brauchen Sie das Nachweisdokument archiviert? Wenn Sie es einer Prüfung oder in einem Rechtsstreit vorlegen müssen, liegt es besser neben der Rechnung.
4. Was passiert, wenn zwei Wochen lang niemand ins Panel schaut? Fragen Sie, bei wem eine Aufgabe auftaucht, wenn ein Vertrag unsigniert abläuft. Lautet die Antwort «bei niemandem», haben Sie noch keine Integration.
5. Wie viele Odoo-Versionen müssen Sie unterstützen? Ein Zap hängt nicht von der Version ab; ein Modul schon, und der Sprung von hr.contract zu hr.version sind die realen Kosten davon.
6. Hat Ihr Signaturit-Tarif API-Zugang? Ohne Token funktioniert keine der drei Optionen. Prüfen Sie das zuerst.

Woher das alles stammt

Wir haben sieben Module auf dieser Integration aufgebaut: den Kern, der Konten, Anfragen, Empfänger, Ereignisse und Archivierung abdeckt, und sechs Brücken für CRM, Kundendienst, Personal, Projekte, Personalbeschaffung und Lager. Insgesamt 270 automatisierte Tests im Zweig für Odoo 19, 262 im Zweig für 18 und 266 im Zweig für 17: Derselbe Code wird gleichzeitig für alle drei Versionen gepflegt.

Keine der Entscheidungen in diesem Artikel stammt aus dem Lesen der Dokumentation. Sie stammen aus aufeinanderfolgenden QA-Runden gegen den echten Konnektor: In einer einzigen Runde wurden 23 beim Live-Test gefundene Fehler und 5 weitere aus einem adversarialen Audit gegen die API-Dokumentation behoben; in der nächsten weitere 17. Das Änderungsprotokoll des Moduls listet sie einzeln mit Datum auf. Eine automatisch erzeugte Seite nach dem Muster «Produkt A × Produkt B» hat keine dieser Narben, denn niemand hat sie je benutzt.

Nützliche Links innerhalb von FlexigoTech

Häufig gestellte Fragen

Was wir dazu anbieten