Was sind die Unterschiede zu anderen Integrations-Plattformen, „Datendrehscheiben“ etc.?

Um das, was in unserem Fallbeispiel dargelegt ist, leisten zu können, muss loggPRO^®.net eine Unmenge Daten mit den unterschiedlichsten Clients austauschen, also per se muss es eine Vielzahl von Standards und Formaten beherrschen. Dennoch wurde bereits zu Zeiten des FAQ-Artikels FAQid=18, als es um die Kopplung ans TransObjects® ging (demnach lange vor loggPRO^® und erst recht loggPRO^®.net), eine Empfehlung zugunsten von XML und SOAP ausgesprochen. Warum?

transObjects^® war und ist eine objektorientierte Technologie und als solche favorisiert sie diejenigen Standards, die der „oo“-Sicht der Dinge möglichst nahe kommt; SOAP bedeutet immerhin „Simple Object Access Protokoll“, scheint also einer ähnlichen Sicht der Dinge entsprungen zu sein. Und nicht nur entsprungen: mittlerweile setzen sich XML und SOAP unübersehbar durch, mindestens im Gleichschritt mit der Objektorientierung im Allgemeinen. Dass der Schweizer Zoll beispielsweise das Verfahren „e-dec“ genau daran angelehnt hat, kommt da sicherlich nicht von ungefähr.

Natürlich sind XML und SOAP nicht die einzigen Standards, die das loggPRO^®.net bieten muss, denn damit wäre beispielsweise der Datenaustausch im Rahmen des Verfahrens „Atlas“ bis dato nicht möglich gewesen. Aber – um eine der Ausgangsfragen aufzugreifen – es ist schon von Bedeutung, wie eine Plattform konzipiert ist; erinnert sei an dieser Stelle nur an die seinerzeit „umgeschriebenen“ 16 Bit’er oder an die angebliche „Objektorientierung“ bei einem bekannten ERP-Anbieter, der dies seinem von „Uralt“ herüber gezogenen System aus Marketinggründen gerne andichtet. Wer ist es wohl… 😉 ?

Wie dem auch sei. Nachfolgend wollen wir das Besondere am loggPRO^®.net ausarbeiten, indem wir dessen Funktionsweise ausführlich charakterisieren und uns dadurch der Ausgangsfrage nach dem loggPRO^®.net-API (hoffentlich) gut nähern. Wie die nachfolgende Abbildung zeigt, weist loggPRO^®.net eine 2-stufige Topologie auf, bestehend aus einem Backend- und einem Frontend-Bereich (letzteres ist nicht mit der Firewall zu verwechseln, die es noch anderweitig gibt).

Eine unübersehbar zentrale Rolle spielt hierbei der im Backend befindliche 64-Bit-Cluster, der mit hinlänglich hoher Rechenleistung aufwartet. In diesem Cluster werden künftig die allermeisten Rechenoperationen durchgeführt, sei es durch den Caché-Server selbst, sei es durch transObjects^®-Services, die speziell für eine Cluster-Umgebung konzipiert worden sind oder sei es schliesslich durch andere Instanzen, die dort künftig aktiv werden.

Das Wesen einer solchen Frontend/Backend-Topologie besteht nun darin, dass all die Instanzen, von denen wir soeben sprachen, nicht direkt von aussen „angesprochen“ werden können. Vielmehr führt der Weg dorthin stets über die Frontend-Maschinen. Diese sind auch diejenigen Instanzen, die jede Anfrage zunächst entgegen nehmen, diese dann entsprechend verifizieren und dann evtl. entscheiden, welche Transaktionen mit dem Backend-Cluster einzuleiten sind. Das erhöht entsprechend den Schutz des „Herzstücks“ des loggPRO^®.net!

E-Mail-Archivierung ist sowohl in der Schweiz als auch in Deutschland Pflicht!

.
Sachlage Deutschland: Continue reading „E-Mail-Archivierung: die Rechtslage“ →

Die erste Frage ist relativ einfach zu beantworten: Die technologischen Vorzüge von transObjects^® Gen.5/R2 sind so gewaltig, dass sie auch und gerade für das Dokument- und Archivmanagement handfeste Vorteile bieten. Bei dem loggPRO^®.dms hingegen bedarf das „nomen est omen“ allerdings einer genaueren Erläuterung.

Archivierung und Management von Dokumenten („dms“ steht für document management system) gehören zu denjenigen branchenübergreifenden IT-Bereichen, die in naher Zukunft einen der stärksten Wachstumsschübe erfahren dürften. Der Grund liegt dabei klar auf der Hand: Die Fortschritte der letzten Jahre auf dem Gebiet der Speicherungstechnik haben es möglich gemacht, in Puncto Kapazitäten ganze Aktenberge auf einige wenige Datenträger speichern zu können (!). Das, was früher ganze Archive mit mehreren Räumen, Etagen oder gar ganzen Gebäuden gefüllt hat, passt heutzutage in der Tat auf ein kleines NAS-System mit einem Volumen von einigen Kubikzentimetern. Der Gewinn für Mensch und Umwelt, die Schonung natürlicher Ressourcen etc. müssen hierbei nicht sonderlich erwähnt werden.

Auf der anderen Seite ist ein solches Potential der modernen elektronischen Dokumentspeicherung sehr verlockend – ja, man könnte sagen, es weckt Begehrlichkeiten. Denn wenn man schon eine derart mächtige Archivierungstechnik hat, so möchte man damit doch nicht nur Platz (und Zeit, etwa beim Wiederauffinden der Dokumente) einsparen, sondern auch und insbesondere den gesetzlichen Aufbewahrungspflichten gleich mit begegnen. Der Gesetzgeber ist ja auch längst auf den Plan getreten (alles andere wäre mehr als seltsam 😉 ) und hat – je nach Land bzw. Steuerrecht – ein mehr oder minder kompliziertes Regelwerk vorgegeben. Die sog. „rechtskonforme Archivierung“ hat leider mit derjenigen, die sonst relativ einfach zu haben gewesen wäre, praktisch nichts mehr zu tun…

So ist die elektronische Speicherung von etwas „sensibleren“ Dokumenten (etwa Rechnungen, Veranlagungsverfügungen o.ä.) häufig erst dann rechtskonform, wenn sie fälschungssicher, sicher vor unbefugtem Zugriff bzw. Vervielfältigung etc. gespeichert (denken wir an bestimmte Daten-CD’s der vergangenen Jahre mit „brisantem“ Inhalt 😉 ) und zu guter Letzt auch noch leicht wiederauffindbar ist, da man es dem Prüfer möglichst komfortabel zu machen hat. Darüber hinaus: Diese Vorgaben sind stark volatil, d.h. gilt heute in Deutschland eine Bestimmung „§x“ und in der Schweiz nicht, kann es morgen genau umgekehrt sein.

Gerade um sich dieser Volatilität zu entziehen, arbeiten die Entwickler der K&S GmbH an einer Lösung, die von vorne herein versucht allen rechtlichen Erfordernissen – auch denjenigen, die noch nicht da sind – zu begegnen. So arbeitet loggPRO^®.dms stets auf verteilten und transzendent verschlüsselten Caché-Datenbanken, so dass eine Entwendung der Datenträger völlig nutzlos bleibt. Darüber hinaus wird jedes Objekt (Dokument) mit einem fälschungssicheren Zeitstempel versehen, was es zusammen mit der mitgeführten Chronik de facto nicht fälschbar macht.

Eine etwas andere Sache ist die allseits bekannte Indizierung, womit wir bei der Frage „nomen est omen“ wären. Mit der Indizierung wollen wir es nicht so sehr dem Prüfer erleichtern, sondern allem voran uns selbst. Wir wissen, dass eine Fotoaufnahme eines Dokumentes für sich genommen überhaupt nichts über dessen Inhalt besagt, zumindest nicht für das Wesen mit dem IQ=0 in unserer Nähe. Ein Dokument-Scan ist für den Computer so wie ein Urlaubsfoto vor dem Wegweiser nach Villa O’Higgins: Eine Ansammlung von Punkten mit unterschiedlichen Helligkeiten und Farben, aber der Schriftzug „Villa O’Higgins“ ist als solcher nur für Wesen mit einem höheren IQ ersichtlich. Wir erfassen diesen Schriftzug im Bruchteil einer Sekunde.

Was also tun? Schließlich wollen wir nicht nur die gescannte Rechnung sondern auch deren Nummer, (Teil-) Beträge, buchhalterische Konten etc. mit abspeichern.

Hier kann nur der Mensch mit seinem humanen Einsatz helfen, indem er beim Speichern all die Informationen schlicht eintippt. Oder wir bedienen uns der OCR-Technik. Die Texterkennung, die zuletzt immer mehr verfeinert worden ist, kann hierbei Abhilfe schaffen. Das Problem ist nur der Aufwand und die mehr oder weniger gute Erkennungssicherheit. Und was ist, wenn die Trefferquote eher schlecht als gut ist?

An dieser Stelle nutzt unser loggPRO^®.dms den Informationsvorsprung gnadenlos für sich (und somit für Sie als loggPRO^®-User) aus. Denn die für die sichere Indizierung benötigten Daten sind ja im loggPRO^®-System bekannt. Hat jemand z.B. die Veranlagungsverfügung mit loggPRO^®.edec erzeugt, sind alle Daten, die für die Indizierung benötigt werden, vorhanden und ausserdem über mögliche OCR-Fehler erhaben. Es müssen keine Zahlen erkannt und keine Strichcodes eingelesen werden. Somit kann der User, der im loggPRO^® arbeitet, seine Dokumente automatisch archivieren und das rechtskonform, mit 100% „OCR”-Sicherheit!

Äquivalenz zwischen loggPRO^®– und loggPRO^®.dms-Strukturen

Einem Auftragsdossier mit der Relation „99“, Do-Nr „1001“, Position „0“ (also. Auftrags-Nr. etwa 99/1001/0) wird eine Liste von PDF-Dokumenten hinzugefügt (unten-links).
Diese sind dann im loggPRO^®.dms -Explorer unter dem Thread dossier->99->1001->0 zu sehen (oben-rechts).