SAP und Agorum als DMS Lösung

Mögliche Alternative wenn ein SAP Content Server nicht im Arbeitsprozess integrierbar ist.

Es sind Umstände vorstellbar, in denen die Integration von Belegen in das SAP System garnicht gewünscht sind. Große Steuerberater erhalten die Belege als Scan von ihren Mandanten und ein kopieren in das SAP eigene DMS, dem SAP Content Server, ist garnicht gewünscht. Es ist aber Standard, die Originalbelege zum Systembeleg abzulegen, zumindest eine Referenz herzustellen. Das Belegfeld „Referenznummer“ dient zur Aufnahme der Fremdbelegnummer und hat im weiteren Belegprozess eine Bedeutung. Das vermerken der Systembelegnummer auf dem Originalbeleg ist angeraten und wird in der Praxis meisst per Hand vollzogen.

Wenn ich mit meinem Lieblings-DMS, dem von Agorum, arbeite, arbeite ich auf zwei Bildschirmen. Links ist die Buchungsmaske, rechts das Dokument. Wenn ich links buche, wird eine Systembelegnummer generiert die ich rechts auf dem Originalbeleg vermerken sollte. So ist ein suchen und finden von Belegen von beiden Applikationen aus möglich.

Das gilt es zu automatisieren. Ich will dabei garnicht zu sehr ins Detail gehen, etwas Vorkenntnis setze ich voraus – im Zweifel fragen!

Möglichkeiten, in die SAP Software manipulativ einzuwirken, gibt es viele. Eine sehr schöne und einfache Möglichkeit sind BTE’s ( Business Transaction Events ).  Der Name lässt schon auf die Systematik schliessen: In den Arbeitsprozessen werden zu bestimmten Zeitpunkten, einfach gesagt, nach geschaut, ob der Kunde an diesem Punkt eigenen Programmcode ablaufen lassen möchte. Wirklich sehr einfach dargestellt!

Solche Eventtimes existieren in jedem Arbeitsprozess und zu mehreren sinnvollen Zeitpunkten. Den richtigen Zeitpunkt zu finden, kann in stundenlangen Suchorgien ausarten. Wenn man aber das Wochende mit dem austesten glücklich verbracht hat, hat man etwas gelernt. Kurz: Für unsere Zwecke hat sich der Zeitpunkt 1030 ganz anständig vorgestellt. Wir sprechen von einem Zeitpunkt im Arbeitsprozess „Beleg buchen“ welcher nach der Belegprüfung und nach dem „speichern“ aber vor dem COMMIT WORK liegt. Zu diesem Zeitpunkt steht fest, das und mit welcher Belegnummer gespeichert wird. Im Dictionary befinden sich für jeden Zeitpunkt ein beispielhafter Funktionsbaustein der in seinen Parametern nicht verändert werden darf. Dieser wird in den eigenen Namensraum kopiert. ( Listing )

Bevor es an die Programmierung geht, kurz ein Gedanke zum pro cedere. Der Buchhalter bucht, zum Beispiel, über die FB50 Belege ein. Dort stehen uns Felder für den Belegkopf zur Verfügung. Wenn wir nun eine Verbindung zu einem externen Originalbeleg herstellen wollen, bedient man sich allgemein dem Referenzfeld. Wie schon weiter oben gesagt, hat das Feld eine Aufgabe. Nämlich die, der Zuordnung beim maschinellen Ausgleich. Im Agorum DMS liegt ein File, mit einem Namen und einer Objekt ID. Hier können wir also keine einfache Verbindung zwischen Systembeleg und Originalbeleg assoziieren. Ich habe es ersteinmal so gelöst, ohne Programmierung von kundeneigenen Feldern, das Feld „Belegkopftext“ Zweck zu entfremden.

Dazu habe ich eine neue Belegart „AG“ erstellt und das Feld  „Belegkopftext“  zum Mussfeld gemacht. Damit ist zwingend das Feld mit der Objekt ID des im Agorum DMS befindlichen Originalbelegs zu befüllen.

Wenn nun die Buchung verbucht wird, kommt es zum Event 1030 zu dem die Belegkopfdaten als Notiz an den Originalbeleg im Agorum DMS hinzu gefügt werden sollen. Dazu stellt Agorum eine REST API zur Verfügung. Über URL mit POST/GET angesprochen, wird eine Antwort per XML zurück gegeben. Im SAP System bediene ich mich dazu der Klasse CL_HTTP_CLIENT. ( Listing )

Wir sehen in den Zeilen 45 bis 65 das zunächst der http Client initialisiert  und eine Session ID angefordert wird. Die lokale Variable lv_bin enthält nun die XML Antwort von Agorum als XSTRING und wird in den Zeilen 95 bis 100 in eine itab gelesen. Beim programmieren kommt man nicht ohne Debugger weiter, denn der Aufbau des XML ist nicht klar. Das Ergebnis wird schlicht als „value“ übertragen und hängt demnach von der Anforderung ab. Werden mehrer Anforderungen gestellt, heißen alle Werte „value“.

Die Zeilen 80 bis 93, das Suchen nach dem Filenamen, hat zwei Gründe: Es kann eine Tabelle aufgebaut werden, in der die Verbindung Objekt ID, Filename und Systembelegnummer protokolliert wird. Und es war nicht möglich, nach dem Abfragen der Session ID direkt die Notiz zu generieren. Es kommt ohne vorheriges GET vor dem POST zur Fehlermeldung seitens Agorum DMS.

In den Zeilen 112 bis 135 wird es haarig. Uns stehen an dieser Stelle alle Daten zur Verfügung: Objekt ID, Session ID und Belegdaten. Diese müssen als escaped JSON formatiert werden. Nach dem senden ist die Zeile 142 entscheident. Erfolgt nach dem send kein receive, wird die Notiz nicht erstellt.

Dieser neue kundeneigene Funktionsbaustein ist nun, nach dem aktivieren, dem Event zu zuordnen. Über die Transaktionen BF24 und BF34 können wir unser Produkt ersteinmal benennen, aktivieren und einem Zeitpunkt, hier 00001030, zuordnen.

Das Ergebnis ist, das wir im SAP System an der Belegart und dem Belegtext erkennen, das es einen Originalbeleg im Agorum DMS gibt. Im Agorum DMS können wir schnell an der vorhandenen Notiz erkennen, das eine Buchung im SAP System vorgenommen wurde. Im Detail können wir nach Systembelegnummern, Buchungsdatum usw. suchen.

Eine einfache und praktikable Lösung.

GoB konforme Mailarchivierung

Der GfUD Server von HALSYSTEM speichert auf Wunsch Mails GoB konform und bietet auf verschiedener Art und Weise Zugriff.

Mails, im gewerblichen Verkehr, sind aufbewahrungspflichtige Dokumente. Es ist ein Spagat zwischen Pflichterfüllung und Geheimhaltung: Postfächer in Firmen werden mit Werbemails überschwemmt und gelegentlich werden Mails privater Natur oder mit brisantem Inhalt versendet.

Dem User kann aber nicht die Entscheidung darüber, welche Mail ist Wichtig, welche kann gelöscht werden, überlassen werden. Es muss seitens des Systems sicher gestellt sein, das eine Mail zu jeder Zeit verfügbar ist.

Es ist, genau genommen, eine Verletzung des Postgeheimnisses. Mails an einen bestimmten Empfänger, werden für Andere sicht- und lesbar. Es ist also Aufgabe des Administrators hier mit äussester Vorsicht und Verschwiegenheit, bedacht vor zu gehen.

Von Seiten des Mailservers ist es schon immer vorgesehen gewesen, Mails an einen BCC (Blind Carbon Copy) zu senden. Mit der Direktive „always_bcc = user@archiv.tld“ wird jede Mail, die rein oder raus transportiert wird, in Kopie versendet. In der Transporteinstellung ist es zu empfehlen, für das Agorumarchiv eine ausschließlich intern bekannte und erreichbare Mailadresse einzurichten, denn die Mail in einem IMAP Postfach zu lagern, macht keinen Sinn.

In der täglichen Praxis ist es so, das Sender- und Empfänger abhängig weiter geleitet wird. Auf dem aktuellen HALSYSTEM Server werden eine vielzahl an privaten und gewerblichen Mails verarbeitet; oft ist eine Archivierung weder notwendig noch gewünscht. Die Einrichtung von sender_bcc und recipient_bcc Hash Tabellen ist unablässig. Es hat sich bewährt, im Agorum für jedes Archiv einen User mit eigener ACL ein zu richten. Mit Hilfe der Mailregeln lassen sich Ordner für bestimmte Zwecke einrichten und einer oder mehreren bestimmten Gruppe Usern zur Verfügung stellen.

Innerhalb des Agorumarchivs kann es verschiedene Lösungen geben. Es ist nicht sinnvoll, das Archiv allen Usern zur Verfügung zu stellen. Wie erwähnt, verstoßen wir gegen das Postgeheimnis, sodass EINEM User – nämlich der, der die Postfächer sauber hält – Zugang gewährt wird. Wenn nötig, können bestimmte User lesenden Zugriff mit der Einrichtung entsprechender ACL, erhalten. Agorum beherrscht die Kunst, Mails untereinander in Beziehung zu stellen und auch Belege mit einer Mail zu verlinken.

So ist es ein äußerst produktiver Nebeneffekt, das zum Beispiel, eine Kundenbestellung per Mail mit der Ausgangsrechnung im Archiv miteinander verknüpft werden können. Sucht man also entsprechenden Beleg, findet man auch stets die passende Mail dazu. Da der User grundsätzlich keine Löschrechte hat und auch nichts verändern kann, ist ein solches Archiv revisionssicher.

Agorum OCR Lösung

Einfache Konvertierung von nicht OCR fähigen PDF Dateien für die Indexierung im Agorum DMS System.

Einfache Scanner kopieren Belege als Bilddatei und sind damit nicht im Klartext lesbar. Nicht lesbar bedeutet, das ein Archivsystem nicht in der Lage ist, den Beleg ein zu sortieren oder wieder zu finden.

Ich selbst arbeite auch mit solch einem einfachen Scanner und statte meine Dateiablage mit einem kleinem Script aus, welches die PDF auf ihre Lesbarkeit hin überprüft und diese ggf. übersetzt.

In der Praxis hat es sich bewährt, Belege grundsätzlich zu paginieren – mit einer laufenden, einmaligen Zahl zu versehen. Sie lassen sich dann eindeutig in der Buchhaltung und im DMS System identifizieren und verknüpfen.

Den Code stelle ich zur Verfügung.

Mit dem Code muss gespielt werden, da das Ergebnis stark von der Qualität des Scanners abhängt. Mit meinem Scanner ist eine Auflösung von 300dpi mit einer Graustufentiefe von 8 optimal. Auch kann ich auf den Einsatz des Programms UNPAPER verzichten – dieses würde Schlieren und Streifen entfernen.

Die erkannten Texte lassen sich in die PDF, also nicht als anhängende Seiten, integrieren. Mit Absicht hänge ich den OCR Text aber an das original PDF um direkt eventuelle Ungenauigkeit zu erkennen und diese im Agorum durch hinzufügen von Notizen zu ergänzen.

SAP und Agorum DMS

AgorumCore DMS integration in SAP

Die SAP-Integration von agorum® core verbindet Ihr Dokumentenmanagement-System über den SAP ArchiveLink nahtlos mit Ihren Anwendungen in SAP. So nutzen Sie alle Vorteile eines systemübergreifenden Dokumentenmanagements.

Link