Procuros für n8n

Mit diesem Community Node verbinden Sie n8n direkt mit der Procuros API v2. Sie können eingehende Geschäftsvorfälle abholen und als verarbeitet melden, ausgehende Nachrichten senden oder Fehler melden, alle Transaktionen durchsuchen sowie die Verbindung testen – ohne eigene HTTP-Knoten zu pflegen.

Für wen ist dieser Node?

Für Integrationsverantwortliche und Automatisierer, die n8n nutzen und Procuros als Schnittstelle zum Austausch von Geschäftsdokumenten mit Handelspartnern einsetzen.
Keine Entwickler-Umgebung nötig: Installation erfolgt über die Community Nodes in n8n mit dem npm-Paket.

Voraussetzungen

| Voraussetzung | Hinweis | |----------------|---------| | n8n | Selbst gehostet oder verwaltete Instanz mit Unterstützung für Community Nodes | | Procuros-Zugang | API-Token der ERP-Verbindung aus dem Procuros-Umfeld | | Netzwerk | Ausgehende HTTPS-Verbindungen zu api.procuros.io bzw. Staging-Domain |

Installation in n8n

1. In n8n zu Einstellungen → Community Nodes wechseln (oder gleichwertiger Bereich Ihrer n8n-Version).

2. Community Node installieren und als Paketname eingeben:

   @t4dt/n8n-nodes-procuros-community-node

3. Nach erfolgreicher Installation den Node „Procuros“ in neuen Workflows unter den Knoten auswählen können.

Die aktuelle Versionsnummer finden Sie auf npmjs.com unter dem Paket @t4dt/n8n-nodes-procuros-community-node.

Zugangsdaten (Credentials): „Procuros API“

Legen Sie ein Credential vom Typ Procuros API an und tragen Sie ein:

| Feld | Beschreibung | |------|----------------| | Basis-URL | Host ohne abschließenden Schrägstrich, z. B. https://api.procuros.io (Produktion) oder https://api.procuros-staging.io (Staging). | | API-Token | Bearer-Token Ihrer ERP-Verbindung (wie in der Procuros-Dokumentation beschrieben). |

Über Credential testen (falls in Ihrer n8n-Version verfügbar) kann die Verbindung mit GET /v2/ping geprüft werden.

Knoten „Procuros“ im Überblick

Der Knoten ist in Ressourcen gegliedert. Zuerst wählen Sie die Resource, dann die Operation.

Ressource: Incoming Transaction (eingehend)

| Operation | Zweck (kurz) | |-----------|----------------| | List Unprocessed | Liste der noch nicht als verarbeitet gemeldeten eingehenden Transaktionen. | | Mark Processed | Eine Transaktion als erfolgreich oder fehlgeschlagen melden. | | Bulk Mark Processed | Bis zu 1000 Transaktionen in einem Schritt melden. |

Typische Felder

• Filter: Type – Optional nur einen Dokumenttyp (z. B. Auftrag, Lieferschein) laden.
• Return All – Alle Treffer über mehrere API-Seiten holen (die Pagination läuft intern, ohne Cursor-Felder in der Oberfläche).
• Limit – Nur sichtbar, wenn „Return All“ aus ist: maximale Anzahl Ergebnisse.
• Page Size – Interne Seitengröße für API-Anfragen (Standard oft sinnvoll; nur bei sehr großen Datenmengen anpassen).

Bei Mark Processed geben Sie die Procuros Transaction ID an und ob die Verarbeitung erfolgreich war. Bei Fehler sind Fehlergrund und Fehlertyp relevant; optional Fehlerkontext als JSON mit Textfeldern.

Bei Bulk Mark Processed übergeben Sie die Liste als JSON im Format der API (Array von Objekten oder { "items": [ … ] }).

Ressource: Outgoing Transaction (ausgehend)

| Operation | Zweck (kurz) | |-----------|----------------| | Send Transaction | Ein ausgehendes Geschäftsvorfälle-Payload gemäß API senden (JSON mit type und content). | | Report Outgoing Error | Melden, dass beim Erzeugen eines ausgehenden Dokuments ein Problem aufgetreten ist (gleicher Ausnahme-Flow wie bei Verarbeitungsfehlern). |

Send Transaction erwartet den vollständigen JSON-Body entsprechend der Procuros-Spezifikation für ausgehende Nachrichten (je nach Dokumenttyp). Details und Beispiele: Procuros API v2 – Übersicht & OpenAPI.

Ressource: All Transaction (Archiv / Gesamtliste)

| Operation | Zweck (kurz) | |-----------|----------------| | List | Alle Transaktionen mit Filtern listen (inkl. Status/Flow/Zeitraum nach API). | | Get | Eine Transaktion anhand der Procuros Transaction ID laden. |

Filter (bei „List“ der Reihe nach möglich):

• Filter: Type, Filter: Flow, Filter: Status
• Filter: Erstellt zwischen – Format YYYY-MM-DD,YYYY-MM-DD wie von Procuros beschrieben.

Return All / Limit / Page Size – gleiche Bedeutung wie bei eingehenden Listen.

Ressource: System

| Operation | Zweck (kurz) | |-----------|----------------| | Ping | Prüft, ob die API mit gültigem Token erreichbar ist (GET /v2/ping). |

Ausgabe des Knotens

• Listen geben in der Regel ein Datensatz pro Transaktion aus (mehrere Items am Knotenausgang).
• Einzelaktionen (Mark Processed, Bulk, Send, Report Error, Get, Ping) liefern typischerweise ein Item mit der Antwort der API als JSON.

Die genaue Struktur entspricht der Procuros API v2.

Typische Workflows (Konzept)

1. Eingehend abarbeiten
   Incoming Transaction → List Unprocessed → für jedes Item ERP/Logik → bei Erfolg Mark Processed oder bei Batch Bulk Mark Processed.

2. Ausgehend senden
   Daten aus ERP oder Vorlage → JSON für Send Transaction bauen → Antwort auswerten (Erstellt/Angenommen/Fehler gemäß Procuros).

3. Monitoring / Support
   All Transaction → List mit Filtern oder Get für eine konkrete ID; bei Bedarf System → Ping für Health-Checks.

Fehler und API-Rückmeldungen

Procuros nutzt standardisierte HTTP-Codes und strukturierte Fehlerantworten (z. B. Validierung mit HTTP 422 und Hinweisen im Portal).
Im Fehlerfall zeigt n8n die Meldung des Knotens an; Details stehen in der Antwort bzw. im Procuros-Portal (je nach Antworttyp).

Ausführliche Beschreibung der Endpunkte und Payloads: Procuros API v2 Dokumentation.

Datenschutz und Sicherheit

• Das API-Token wird wie andere n8n-Credentials gespeichert – Zugriff nur für berechtigte n8n-Benutzer konfigurieren.
• Übermittelte Daten entsprechen den von Ihnen gewählten Transaktionen und Filtern; keine zusätzliche Telemetrie durch diesen Knoten.

Lizenz und Kontakt

• Lizenz: MIT
• Paket: @t4dt/n8n-nodes-procuros-community-node
• Maintainer: Robert Wall | T4DT GmbH — https://t4dt.de, [email protected]

Weiterführende Links

• Procuros API v2 – Übersicht
• npm-Paket @t4dt/n8n-nodes-procuros-community-node