Leistungsbeschreibung zum Handling der eVV und Bordereau

Das Handling (Abholung und Aufbewahrung) der elektronischen Veranlagungsverfügungen (eVV) sowie Bordereau ist Bestandteil der Softwarelösung loggPRO®.edec bzw. der im Hintergrund agierenden Cloud-Services.

Funktionsweise:

  • Auto-eVV-Bord
    Im loggPRO®.edec können elektronische Veranlagungsverfügungen (eVV) sowie Bordereau optional auch automatisch abgeholt und in die jeweilige User-Datenbank eingearbeitet werden!

    die elektronische Veranlagungsverfügungen (eVV) sowie Bordereau werden Nachts zwischen 2:00 und 6:00 Uhr durch den Deamon (vgl. https://ssl.loggpro.net/ksinfo/?p=2634) von den generierenden Zollrechnern heruntergeladen und in die jeweiligen Benutzer-Datenbanken eingearbeitet;

  • der User hat anschliessend die Möglichkeit die eVV und Bordereau interaktiv, mit Hilfe des loggPRO®.edec-Clients, weiter zu verarbeiten;
  • optional besteht für die User die Möglichkeit, die eVV sowie Bordereau automatisch den jeweiligen Empfängern via SMTP mailen zu lassen.

Transfersicherheit:

  • das Scannen (Abholung) der betr. Dokumente erfolgt übers IP-Netz abgesichert durch SSL, basierend auf EZV-/Zoll-seitig generiertem asymmetrischen RSA-Schlüssel;
  • der Client/Server Datenaustausch (d.h. beim Arbeiten mit loggPRO®.edec insb. bei gehosteter Datenbank) erfolgt übers IP-Netz mit Standard-SSL, basierend auf einem proprietären symmetrischen transObjects®Schlüssel.

Aufbewahrungssicherheit:

  • Die Aufbewahrung der betr. Dokumente ist geografisch auf das Gebiet der Schweiz beschränkt. Sicherheiten auf dem Level eines Schweizer Datacenters sind stets gegeben: https://ssl.loggpro.net/ksinfo/?p=1086.
  • Die Aufbewahrung gilt „Lifetime“, d.h. sie ist nur durch die Lebenszeit der jeweiligen Systeme (insb. der inhouse-Systeme) beschränkt;
  • Die aufbewahrten Daten – sowohl primär als auch sekundär (Backups) – unterliegen stets einer standard 256-Bit AES-Verschlüsselung.

Sicherheit von transObjects® und loggPRO®.net gegenüber Quantencomputing

NichtLinearKrystal
Erzeugung von verschränkten Photonen im nicht-linearen Krystal. Quelle: BBC.uk.com.

Es gibt durchaus nicht wenige Menschen, die hier und da mal etwas über „Quantencomputer“, „Quantenkryptographie“ etc. gelesen oder gehört haben. Puristen unter ihnen (und das sind nicht selten unsere geschätzten Kunden und Anwender 😉 Continue reading „Sicherheit von transObjects® und loggPRO®.net gegenüber Quantencomputing“

Systemvoraussetzungen für transObjects®-Applikationen

loggPROLogon
Logon-Screen (hier ins loggPRO®) indiziert ein geeignetes Client-Betriebssystem sowie eine korrekt zustande gekommene Verbindung zum Datenbank-Server.

Um die „klassischen“ transObjects®-Applikationen (z.B. loggPRO®) nutzen zu können, benötigen Sie eine geeignete Umgebung, sowohl für die Clients als auch für die Server. Dabei können beide Seiten der Client-/Server-Topologie teils oder durchgehend in die Cloud verlagert werden.

Die Systemvoraussetzungen gliedern sich demzufolge nach Clients und Servern. Was die Clients anbelangt, so gehen die Systemanforderungen nicht über die der jeweiligen (Windows- !) Betriebssysteme hinaus. So benötigen Sie ganz einfach eine hinlänglich dimensionierte Windows-Workstation – physikalisch oder virtuell, inhouse oder in der Cloud – mit Internet-Anbindung und/oder einer Verbindung zum Datenbank-Server.

Beispiel:

  • Computersystem mit Windows 10, 64bit ➡
  • Intel oder AMD Prozessor mit mindestens 2.0 GHz
  • 4 GB RAM oder mehr
  • Stabile Internetverbindung
  • .NET Framework 4.0 oder höher

Gerade die „stabile Internetverbindung“ ermöglicht eine Kommunikation zum Datenbank-Server (Caché) bzw. -Pool – insbesondere dann, wenn sich dieser in der Cloud befindet. Letzteres ist grundsätzlich auch die Empfehlung der K&S, wobei die Entscheidung „inhouse oder Cloud“ durchaus schwierig sein kann und ggf. einer tiefgründigen Anforderungsanalyse bedarf. Dies gilt insbesondere für den Fall der Inhouse-Installation. Hier ist zunächst eine geeignete Server-Umgebung vonnöten, das empfohlene Betriebssystem ist x64-Linux etc. (andere Anforderungen a.A.)

➡ Bei Einsatz von 64-Bit Windows (x64) ist eine 64-Bit-Version von MS Office zwingend, um z.B. Mailing-Funktion von loggPRO® nutzen zu können.

Inhouse vs. Cloud: inhärente Datensicherheit auf loggPRO®.net

FAQ’s (abstract):
.

  • Wo „liegen“ denn physikalisch meine Daten? In welcher Form?

➡ Physikalisch befinden sich Ihre Daten auf diversen Datenträgern an verschiedenen Standorten (Nodes) des loggPRO®.net. Dabei kann es sich um Online sowie Offline-Bestände handeln – je nach dem, welche Stufe der Datenredundanz der jeweilige Node ausführt. Sowohl die Nodes als auch die eingesetzten Replikationstechniken werden in Ihrem Interesse geheim gehalten.

➡ Zumindest Ihre wichtigsten und sensibelsten Daten sind nirgendwo in „konventioneller“ Form gespeichert, sondern befinden sich vielmehr in strikt verschlüsselten Datenbanken. Das bedeutet, dass es grundsätzlich keine Möglichkeit gibt, diese Daten auf konventionellem Wege auf einen anderen Datenträger zu kopieren.

  • Wie werden meine Daten geschützt – vor Verlust, Entstellung, Entwendung?

➡ Die Speicherung der Daten in verschlüsselten Datenbanken stellt einen sehr hohen Sicherheitslevel dar: Entwendung ganzer Datenträger und selbst ganzer Server wäre vollkommen nutzlos. Der Verlust bzw. Entstellung beträfen sicherlich nur einen Standort.

  • Wer hat Zugriff auf meine Daten?

➡ Nur die 1st-Level-Supporter können Ihre Daten teilweise einsehen, wobei selbst diesem engen und oft überprüften Personenkreis praktisch nur sehr begrenzte Möglichkeiten offen stehen.

Der Hintergrund
.

ObscuredByClouds
„Obscured By Clouds“ © Pink Floyd

Als unser loggPRO®.net in den 90’er Jahren online ging, war der Terminus „Cloud“ allenfalls wettertechnisch oder künstlerisch geläufig; so gesehen waren wir der Zeit gute 10-15 Jahre voraus… Von daher ist es nicht sonderlich überraschend, dass gerade jetzt, in Zeiten von Spionageaffären, organisierter (Bank- 😳 Continue reading „Inhouse vs. Cloud: inhärente Datensicherheit auf loggPRO®.net“

CH-Verzollung ohne CH-Domizil – wie geht das?

loggPRONCTS
loggPRO®.ncts. Der transObjects®-Client für elektronische Transitabfertigung

Die CH-Verzollungen, also Warenabfertigungsverfahren aus Sicht der Schweiz, erfuhren seit Anfang der 1990’er Jahre eine kontinuierliche Entwicklung in Richtung Digitalisierung, so dass sie heute als nahezu durchgehend papierlos und vereinheitlicht gelten. Die K&S Informatik, die seit Anbeginn dabei gewesen war, hatte diese Entwicklung stets mit den modernsten (Windows-) Technologien unterstützt und so zu einer Verfügbarkeit des AEA, Zoll’90 etc. für jedermann bzw. jeden PC beigetragen.

Doch während die Verfügbarkeit wesentlich von der eingesetzten Technik abhängt, tut es die praktische Zugänglichkeit eher weniger; hier ist offensichtlich das zugrunde liegende Gesetz, das Zollgesetz, maßgebend. Das bis vor kurzem geltende ZG noch aus dem Jahre 1925 machte da selbst für Zollbeteiligte ohne Domizil in der Schweiz kaum Probleme. Denn die noch vom Zollmodell’90 übergekommene Spediteur-Nr. samt ZAZ-Nr. konnte grundsätzlich jeder beantragen und anschließend mit den passenden Programmen arbeiten.

Doch dies änderte sich spätestens mit Inkrafttreten des neuen ZG vom 18.03.2005 sowie der Zollverordnung (ZV) vom 01.11.2006 🙁 Continue reading „CH-Verzollung ohne CH-Domizil – wie geht das?“

Die Baukasten-Architektur von loggPRO®.*

loggPROScrMxloggPRO® ist strikt nach dem „Baukastenprinzip“ aufgebaut. Wie nebenan ➡ dargestellt, bildet der Baustein „Spedition“ den logistischen Kernbereich von loggPRO® und ist dabei in den Debitoren- sowie den Kreditoren-Bereich aufgeteilt.

Einen weiteren solchen Baustein bilden diverse Verzollungs-Module, wie z.B. ATLAS oder EDEC, was entsprechend zu den wohl bekannten Namensschöpfungen geführt hat, etwa:

loggPRO®.atlas
loggPRO®.edec
loggPRO®.slog
loggPRO®.efreight
loggPRO®.eforward

um nur diese zu nennen.

s. auch loggPRO®-Navigation durch die embedded Apps

Was ist „efreight“ und wie hängt es mit loggPRO®.efreight zusammen?

ig-aircargoefreight“ ist ein von der IG Air Cargo konzipiertes und der K&S Informatik (Schweiz) GmbH pilotiertes IT-Projekt, mit dem Ziel, eine Plattform zwecks elektronischen (papierlosen) Handlings von logistischen Vorgängen zu schaffen.

Die erste Phase des Projektes „efreight“ widmet sich der Luftfracht – andere, wie z.B. Seefracht, sollen später folgen. Demzufolge gelten die Entwicklungsaktivitäten zunächst dem Airway Bill (AWB). Continue reading „Was ist „efreight“ und wie hängt es mit loggPRO®.efreight zusammen?“

Wie funktioniert und was ist loggPRO®.net-API?

loggPROnet

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!