Produkt

KIMU Confirm – eingehende Belege prüfen und freigeben

Die Abläufe, die Belege auswerten und ins ERP schreiben, brauchen eine Stelle, an der ein Mensch entscheidet. Diese Stelle ist KIMU Confirm: eine Anwendung im eigenen Netz, in der eingehende Vorgänge geprüft, freigegeben und übergeben werden.

Übersichtsliste in KIMU Confirm mit Statuskacheln für neu, in Prüfung, freigegeben, abgelehnt, übertragen und ERP-Fehler sowie einer Tabelle eingegangener Vorgänge Vergrößern
Die Startansicht je Modul: eingegangene Vorgänge mit Status, Kundenreferenz und Ergebnis der Validierung. Ansicht aus der Testumgebung mit Demo-Daten – der gelbe Streifen weist sie aus, aus ihr geht nichts in ein Live-System.

Warum es die Anwendung gibt

Automatisierung braucht
einen Ort für die Entscheidung.

Ein Ablauf, der Belege ausliest und Werte gegen das ERP prüft, kann den Regelfall allein erledigen. Was er nicht kann, ist die Restmenge verantworten: die abweichende Menge, den verschobenen Termin, die Preisstaffel, die diesmal nicht gegriffen hat. Diese Fälle brauchen einen Menschen – und der braucht eine Oberfläche, in der er den Vorgang vollständig sieht und in der seine Entscheidung nachvollziehbar festgehalten wird.

Genau das ist KIMU Confirm. Die Anwendung nimmt ausgewertete Vorgänge über eine Schnittstelle entgegen, stellt sie zur Prüfung, und übergibt sie nach der Freigabe an das ERP. Sie läuft im Netz des Kunden; die Belege verlassen das Haus nicht.

Alles, was danebenliegt – Auswertung, Validierung gegen Fremdsysteme, die eigentliche ERP-Übergabe – findet in Abläufen statt, die an dieser Anwendung angebunden werden. Confirm ist der feste Punkt, die Abläufe sind je Kunde verschieden.

Der ganze Weg

Confirm in der Mitte,
die Abläufe außen herum.

Drei Abläufe hängen an der Anwendung: einer nimmt Belege an, einer prüft gegen das ERP, einer schreibt nach der Freigabe zurück. Jeder ist je Modul und je Umgebung einzeln eingetragen und einzeln austauschbar.

Weg eines Belegs durch KIMU Confirm und die angebundenen Abläufe Aus dem Postfach übernimmt der Annahme-Ablauf die Mail, trennt die Anhänge, ruft ein lokal betriebenes Modell auf und stellt den Vorgang in KIMU Confirm ein. Dort wird geprüft, korrigiert und freigegeben. Aus Confirm heraus stößt der Validierungs-Ablauf eine Prüfung gegen das ERP an und meldet das Ergebnis zurück. Nach der Freigabe schreibt der Import-Ablauf den Vorgang ins ERP. Postfach oder Ablage aus Confirm NODE-RED Annahme-Ablauf Anhänge trennen · lokales Modell · Schema prüfen KERNPRODUKT KIMU Confirm Vorgang liegt in der Liste prüfen und korrigieren freigeben oder ablehnen jede Entscheidung protokolliert Belege bleiben am Vorgang NODE-RED Validierungs-Ablauf Werte gegen das ERP prüfen aus Confirm angestoßen, meldet zurück NODE-RED Import-Ablauf Vorgang ins ERP schreiben erst nach der Freigabe ERP-System Bestellung · Auftrag

Die Anwendung ruft die Abläufe über gewöhnliche Web-Aufrufe auf und hält Anfrage, Antwort und Fehler je Phase fest. Was im Ablauf geschieht, ist je Kunde verschieden – die Anwendung bleibt dieselbe.

Der Weg eines Vorgangs

Vom Posteingang
bis in die Auftragsverwaltung.

  1. Eingang

    Eine Mail mit Anhang läuft in einem überwachten Postfach ein oder wird aus der Anwendung heraus abgelegt. Ein angebundener Ablauf übernimmt sie unverändert.

  2. Auswertung

    Der Ablauf liest den Beleg aus und liefert strukturierte Felder an die Schnittstelle von Confirm – Kopfdaten, Positionen, Termine, Beträge. Das Original bleibt erhalten und bleibt am Vorgang hängen.

  3. Prüfung

    Der Vorgang erscheint in der Liste. Die Sachbearbeitung sieht ausgelesene Werte und Beleg nebeneinander, kann Felder korrigieren, eine Notiz hinterlegen und eine Validierung gegen das ERP anstoßen.

  4. Freigabe

    Freigeben oder ablehnen. Solange nicht freigegeben ist, findet keine Übergabe statt – das ist als Reihenfolge festgelegt und nicht umgehbar.

  5. Übergabe

    Nach der Freigabe übergibt ein zweiter Ablauf den Vorgang an das ERP. Schlägt das fehl, bleibt der Vorgang mit dem Status ERP-Fehler stehen und kann erneut übergeben werden.

Prüfung

Ausgelesene Werte,
Beleg und Entscheidung nebeneinander.

In der Prüfansicht steht links der Beleg, rechts das, was daraus ausgelesen wurde. Jedes Feld ist korrigierbar. Die Entscheidung – in Prüfung, freigeben, ablehnen – wird mit Zeitpunkt und Person festgehalten.

Rechte Spalte der Prüfansicht mit Klassifikation, Freigabe-Schaltflächen, ERP-Anbindung, Kopfdaten und Positionen Vergrößern
Ausschnitt der Prüfansicht mit Demo-Daten. Unter „ERP-Anbindung" steht, welcher Ablauf für Validierung und Übergabe zuständig ist und in welchem Zustand er sich befindet.

Anbindung

Hier hängen
die Abläufe.

Jeder Ablauf wird als Konnektor eingetragen – getrennt nach Modul, nach Umgebung und nach Aufgabe: Belege annehmen, gegen das ERP validieren, nach der Freigabe übergeben. Ein Ablauf lässt sich in der Testumgebung erproben und anschließend in die produktive Umgebung kopieren.

Konnektor-Verwaltung in KIMU Confirm mit Einträgen für Import, Validierung und Mail-Annahme, jeweils mit Umgebung, Modus, Phasenzahl und Status Vergrößern
Die Konnektoren zeigen auf Abläufe, die wir in Node-RED entwickeln und im Netz des Kunden betreiben. Confirm kennt nur die Adresse und das Ergebnis – nicht den Inhalt des Ablaufs.

Ein Ablauf von innen

Was hinter einem
Konnektor steckt.

Ein Ablauf ist eine überschaubare Kette von Schritten – hier die Annahme: Postfach abfragen, Anhänge trennen, ein lokal betriebenes Modell aufrufen, die Antwort gegen ein festgelegtes Schema prüfen und den Vorgang an Confirm übergeben. Was das Schema nicht erfüllt, geht in die Nachbearbeitung statt in die Anwendung.

Node-RED-Ablauf mit den Schritten Postfach abfragen, Anhang zu Text, lokales Modell, Schema prüfen, Verzweigung gültig, Übergabe an Confirm sowie einem getrennten Fehlerpfad Vergrößern
Beispielablauf zur Veranschaulichung. Die tatsächlichen Abläufe entstehen je Kunde und je Belegart und laufen im Netz des Kunden.

Nachvollziehbarkeit

Wer hat was
wann entschieden.

Jede Statusänderung, jede Korrektur, jede Übergabe und jeder Schnittstellenzugriff steht im Protokoll – mit Zeitpunkt, Person und betroffenem Vorgang. Das ist die Grundlage, um im Zweifelsfall zu klären, was geschehen ist.

Aktivitätslog in KIMU Confirm mit Zeitpunkt, Benutzer, Aktion und betroffenem Vorgang je Zeile Vergrößern
Einträge bleiben erhalten, auch wenn ein Benutzerkonto später gelöscht wird.

Was drin ist

Was die Anwendung
mitbringt.

Zwei getrennte Umgebungen

Produktiv und Test in einer Installation. Ein Vorgang aus der Testumgebung kann nie einen produktiven Ablauf auslösen. Neue Abläufe werden erst dort erprobt.

Rechte je Modul und Umgebung

Wer welches Modul sieht und wer löschen darf, wird je Umgebung einzeln vergeben. Zugriffe über die Schnittstelle laufen über eigene Schlüssel.

Beleg und Original bleiben

PDF-Anhänge, die ursprüngliche Mail und weitere Dateien bleiben am Vorgang. Die Mail ist im Original einsehbar, nicht nur als ausgelesener Text.

Korrigieren statt neu erfassen

Jedes ausgelesene Feld ist im Vorgang bearbeitbar. Die Korrektur wird protokolliert und geht in die Übergabe ein.

Sperre bei paralleler Bearbeitung

Öffnet jemand einen Vorgang, ist er für andere gesperrt. Nach einer Minute ohne Aktivität wird die Sperre wieder frei.

Notizen am Vorgang

Rückfragen an den Lieferanten, Absprachen, Begründungen für eine Ablehnung – am Vorgang statt im Postfach der bearbeitenden Person.

Aufbau

Für die technische Prüfung

Für die technische Prüfung

Womit die Anwendung arbeitet

Zur Einordnung durch Ihre IT-Leitung oder Ihr Systemhaus.

  • Anwendung in NestJS und React, Datenhaltung in PostgreSQL, Betrieb in Containern
  • Läuft im Netz des Kunden oder auf einem gemieteten Gerät in einem deutschen Rechenzentrum – nicht als geteilter Dienst
  • Anmeldung über JWT, Zugriffe von Abläufen über eigene Schlüssel je Modul und Umgebung
  • Belegannahme über eine dokumentierte REST-Schnittstelle; die Auswertung selbst liegt im angebundenen Ablauf, nicht in der Anwendung
  • Konnektoren rufen Abläufe phasenweise auf und halten Anfrage, Antwort und Fehler je Phase fest
  • Auswertung der Belege wahlweise über ein Modell auf eigener Hardware oder über einen externen Dienst – die Anwendung bleibt davon unberührt
  • Protokollierung aller Statusänderungen, Korrekturen und Schnittstellenzugriffe mit fester Aufbewahrungsdauer

Häufige Fragen

KIMU Confirm –
häufige Fragen.

Läuft die Anwendung bei uns oder bei Ihnen?

Bei Ihnen. Die Installation erfolgt auf einem Server in Ihrem Netz oder auf einem gemieteten Gerät in einem deutschen Rechenzentrum, das Ihnen zugeordnet ist. Es gibt keinen geteilten Dienst, in dem die Daten mehrerer Kunden liegen.

Welche Belegarten sind abgedeckt?

Grundsätzlich jede wiederkehrende Belegart. Jede kommt als eigenes Modul dazu, alle nach demselben Aufbau – das ist Umsetzungsaufwand, keine Neuentwicklung. Beispiele sind Eingangsrechnungen, Lieferscheine, Gutschriften oder Rahmenverträge.

Sind wir an Ihre Abläufe gebunden?

Die Anwendung spricht mit Konnektoren über normale Web-Aufrufe. Was dahinter liegt, kann Ihr eigenes System sein. In der Praxis entwickeln wir die Abläufe, weil dort die fachliche Arbeit steckt – technisch nötig ist es nicht.

Mit welchen ERP-Systemen funktioniert die Übergabe?

In der Praxis am häufigsten mit APplus (AP+). Ebenso mit gängigen Mittelstands-ERP wie proALPHA, Sage oder SAP Business One – angebunden über einen Konnektor, den wir je System entwickeln. Grundsätzlich funktioniert die Übergabe mit jedem System, das eine Schnittstelle bereitstellt.

Was passiert, wenn die ERP-Übergabe scheitert?

Der Vorgang bleibt mit dem Status ERP-Fehler stehen und ist in der Übersicht sofort sichtbar. Anfrage und Antwort der fehlgeschlagenen Phase sind einsehbar. Nach Klärung wird erneut übergeben – es geht kein Vorgang still verloren.

Können wir Änderungen erst testen?

Dafür ist die zweite Umgebung da. Ein neuer oder geänderter Ablauf wird in der Testumgebung mit echten Belegen erprobt; produktive Systeme werden dabei nicht angefasst. Erst danach wird der Konnektor in die produktive Umgebung kopiert.

Wie kommen die Belege hinein?

Über ein überwachtes Postfach, das ein Ablauf ausliest, oder direkt aus der Anwendung heraus: Eine Mail lässt sich per Datei in die Anwendung ziehen und wird von dort an den Ablauf gegeben. Der zweite Weg ist für Nachzügler und Sonderfälle gedacht.

Was kostet der Betrieb?

Der Betrag richtet sich nach Modulanzahl, Belegmenge und Betreuungsumfang. Wir nennen ihn im Erstgespräch, bevor Aufwand entsteht.

Schildern Sie uns einen Vorgang.

Ein Anruf genügt für eine belastbare Einschätzung: ob er sich automatisieren lässt, was das kostet – und ob er sich überhaupt trägt.