procuros-community-node

n8n module for procuros

Package Information

Released: 5 mo ago
Downloads: 9 weekly / 70 monthly
Latest Version: 2.0.0
Author: Robert Wall | T4DT GmbH

Available Nodes

Documentation generating…

Procuros icon
Procuros
Procuros API v2 (eingehende/ausgehende Transaktionen, Archiv, Ping)

Documentation

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

Weiterführende Links

Discussion