Es gibt das Angobt smskaufen.de der Firma EventVoiceMedia GmbH. Unter dieser Adresse bieten sie gewerblichen Nutzen SMS, MMS und Faxdienste in leistungsfähigen Versionen zu günstigen Preisen an (siehe auch). Seit kurzem haben sie den Service für digitales Signieren von Rechnungen hinzugenommen. Das Angebot ist aus zwei Gründen sehr attraktiv:

• Der Preis: Es wird nur pro Rechnung abgerecht, weshalb das Angebot gerade auch für Leute interessant ist, die monatlich nur ein Hand voll Rechnungen erstellen. Der Preis pro signierter Rechnung liegt unter 20 Cent, es gibt keinen Grundpreis.
• Der Komfort: Für kleine Mengen funktioniert der Service ganz einfach per Web-Upload und Email. Sie laden ihre PDF-Rechnung per Web-Upload auf einer Webseite des Anbieters zu ihm hoch, und bekommen promt die signierte PDF-Rechnung per Email zurück. Im Angebot ist aber auch eine Webschnittstelle, mit der sich der Upload der unsignierten PDF-Rechnung und die Entgegennahme der signierten Rechnung in Webanwendungen und in lokalen Anwendungen automatisieren lässt.

Ich habe selbst nachgeforscht, ob dieser günstige und einfache Weg wirklich für den Umsatzsteuerabzug anerkannt ist. Das BMF hat in einem wichtigen Schreiben zum Gesamtthema “Umsatzsteuer” vom 19.1.2004 im Punkt 2.4 geregelt, dass das digitale Signieren von Rechnungen auch an Dienstleister abgegeben werden kann, und dass der Dienstleister dafür ein eigenes digitales Zertifikat verwenden darf. Der Dienstleister muss zusätzlich von der Bundesnetzagentur geprüft worden sein.

Das heißt also, sie unterschreiben ihre Rechnung nicht selbst, sondern sie lassen ihre Rechnung von einem Dienstleister unterschreiben, der das machen darf. Und das ist eine Vorgehensweise, die das BMF offiziell zugelassen hat.

Was an der Stelle auch gesagt werden kann: Es müssen nur Rechnungen digital signierte werden, die an Unternehmen mit Vorsteuerabzugsberechtigung gehen. Wenn sie eine Rechnung an Privatpersonen oder Kleinunternehmer senden, dann brauchen diese Rechnungen keine digitale Signatur. Es geht bei diesem ganzen Thema nur um die Vermeidung von Umsatzsteuerbetrug.

Was auch noch gesagt werden sollte: Wer umsatzsteuerabzugsberechtigt ist und tatsächlich digital signierte Rechnungen entgegen nimmt, steht vor einer noch ganz anderen Herausforderung. Die digital signierte Rechnung ist das einzige Original der Rechnung. Jeder normale Ausdruck ist nur ein Kopie davon (selbst wenn man sich den Ausdruck vom Ersteller nachsenden lässt). Deshalb ist der Empfänger in diesem Fall verpflichtet dieses digitale Original der Rechnung in digitaler Form revisionssicher und ausreichend lange lesbar zu archivieren. Er darf auf keinen Fall einen einfachen Ausdruck anfertigen und das digitale Original dann löschen. Wovon ich allerdings schon gelesen habe, ist, dass man die Rechnung zusammen mit der digitalen Signatur ausdrucken kann. Die digitale Signatur wird dabei in einer zweidimensionalen, digital lesbaren Form als Pixelgrafik ausgedruckt. In wieweit so ein Ausdruck das digitale Original vollständig ersetzt, weiß ich noch nicht. Das werde ich noch erforschen.

Das Suse-Linux, und sicher auch andere Linux-Versionen können bereits problemlos mit dem internationalen Zeichensatz UTF-8 umgehen, auch in Dateinamen. Das Linux lässt sich aber auch nicht verwirren, wenn ein Dateiname die Umlaute aus dem europäischen Zeichensatz ISO8859-1 verwendet. Das kann ganz gemischt geschehen. Die Frage am Ende ist nur, wie wird es auf der Konsole, oder im Webbrowser der Nutzers dargestellt, und wo muss eventuell wie konvertiert werden, damit das sichtbar wird, was gewünscht ist.

Bei PUTTY sieht die Sache eigentlich ganz einfach aus: Die Linux-Konsole kennt die Umgebungsvariable LC_CTYPE die sollte für deutsche Nutzer entweder den Wert “de_DE” haben, dann “denkt” die Konsole in ISO8859-1, oder sie sollte den Wert “de_DE.UTF-8″ haben, dann “denkt” sie in UTF-8. Damit das im PUTTY dann auch so wahr wird, muss allerdings in der Konfiguration “Window/Translation” in der Auswahl für den Zeichensatz der passende Zeichensatz ausgewählt werden. Wenn Server-Variable und PUTTY-Einstellung gleich sind, funktioniert es. Das heißt:

Im UTF-8-Mode werden alle UTF-8-Sonderzeichen richtig dargestellt, also ein 2 Byte langes ‘ä’ wird richtig als ein ‘ä’ dargestellt. Alle Zeichen, die im UTF-8-Zeichsatz ungültig sind, werden als ? angezeigt, und im UTF-8-Zeichensatz sind die Umlaute und Liniensymbole des ISO8859-1-Zeichensatzes solche ungültigen Zeichen. Also überall, wo Dateienamen im ISO-Zeichensatz erstellt wurden, werden ? angezeigt. Damit lassen sich solche Dateien auf der Konsole nicht kopieren oder umbenennen, da man im UTF-8-Mode das eigentliche Zeichen nicht sieht und auch nicht eingeben kann. Und es gibt Shell-Anwendungen wie das Suse-YAST, die geben ihre Liniensymbole immer im ISO-Zeichensatz aus, egal wie die Umgebunsvariable gesetzt ist. Damit sieht YAST im UTF-8-Mode schrecklich aus.

Arbeitet man dagegen komplett im ISO8859-1-Mode, funktionieren offensichtlich alle Shell-Anwendungen richtig. Mit den Dateinamen sieht es jetzt allerdings ganz anders aus. Nun werden natürlich alle ISO-Zeichen richtig angezeigt und Dateien mit solchen Zeichen können jetzt kopiert und umbenannt werden. Aber mit den UTF-8-Zeichen in Dateinamen gibt es jetzt Probleme. Jetzt wird natürlich jedes Byte einzeln angezeigt, ein UTF-8-”ä” wird als “ä” angezeigt. Das geht ja noch, weil beide Bytes einzeln auch im ISO-Zeichensatz vorkommen. Aber z.B. bei den großen Umlauten ist das zweite Byte ein Zeichen, dass im ISO-Zeichensatz nicht dargestellt werden kann. Hier wird jetzt wieder ersatzweise ein “?” angezeigt, somit wird das Kopieren und Umbenennen auch wieder ein Problem.

Fazit, wer mit UTF-8-Zeichen arbeitet, sollte sich darauf einrichten immer mal wieder zwischen einer UTF-8-Dartsellung und einer ISO8859-1-Darstellung umschalten zu müssen. Das ist, wie oben dargestellt, nicht sehr schwierig. Wer das oft braucht, könnte sich auf der Serverseite kleine Makros schreiben, muss aber daran denken auch im PUTTY die Translation umzustellen.

Ein sehr empfehlenswerter Link zum UTF-8-Zeichensatz ist
http://www.utf8-zeichentabelle.de

• Sie darf (ohne Leerzeichen) nicht länger als 36 Zeichen sein.
• In jedem europäischen Land hat sie eine feste Länge (in Deutschland 22 Zeichen). Ein Liste der Länge und der Aufteilung in Bankleitzahl und Kontonummer steht hier bei Wikipedia
• Die zweite und dritte Stelle der IBAN ist eine errechnete Prüfsumme, die per Software errechnet oder geprüft werden kann.

Ich zeige hier, wie die Berechnung und Prüfung in einem PHP-Programm durchgeführt werden kann. Das Ganze ist deswegen etwas spannend, weil eine Modulo-Rechnung, also eine Ganzzahl-Division mit einer bis zu 38-stelligen Ganzzahl durchgeführt werden muss. Wegen der meist nur zur Verfügung stehenden 32-Bit-CPUs können mit PHP aber nur maximal 9 Stellen mit allen Ziffern genutzt werden. Deshalb muss die Modulo-Rechnung in mehere Teilschritte zerlegt werden.

function test_iban( $iban ) {
    $iban = str_replace( ' ', '', $iban );
    $iban1 = substr( $iban,4 )
        . strval( ord( $iban{0} )-55 )
        . strval( ord( $iban{1} )-55 )
        . substr( $iban, 2, 2 );

    $rest=0;
    for ( $pos=0; $pos<strlen($iban1); $pos+=7 ) {
        $part = strval($rest) . substr($iban1,$pos,7);
        $rest = intval($part) % 97;
    }
    $pz = sprintf("%02d", 98-$rest);

    if ( substr($iban,2,2)=='00')
        return substr_replace( $iban, $pz, 2, 2 );
    else
        return ($rest==1) ? true : false;
}

Diese PHP-Funktion ergänzt die richtige Prüfziffer, wenn beim Aufruf der Funktion eine IBAN mit Prüfziffern “00″ übergeben wird. Wird dagegen eine vollständige IBAN mit Prüfziffer übergeben, gibt es als Rückgabe “true” wenn die Prüfziffer zu der IBAN passt, andernfalls gibt es das Ergebnis “false”.

Diese Berechnung bezieht sich übrigens nur auf die einheitlichen IBAN-Prüfziffern an der dritten und vierten Stelle der IBAN. In manchen Ländern werden weiter hinten auch noch Prüfziffern zu den eigentlichen Kontonummern hinzugefügt. Diese müssen vor der Berechnung mit der hier gezeigten Funktion schon bekannt sein. Das Wissen um diese weiteren Prüfziffern ist eher nur von Bedeutung, wenn man aus einer IBAN die nationalen Bankdaten ableiten möchte. Wer es ganz genau wissen möchte, findet auf dieser Webseite die Informationen, wo die zusätzlichen Prüfziffern stehen, und dort gibt es auch Links zu Dokumenten der jeweiligen nationalen IBAN-Regeln.

Damit das funktioniert, habe ich mir einen Zugang bei dem Anbieter “smskaufen.de” eingerichtet. Ich kann hier berichten, dass dieser Anbieter zu günstigen Preisen (ab 4 Cent pro SMS) sehr zuverlässig SMS versendet. Der Anbieter versendet auch MMS und Faxe. Das wichtigste ist eine gut dokumentierte Webschnittstelle, über die man diese Versendungen ausführen kann. Jedes Programm, dass in der Lage ist einen HTTP-Post zu versenden und einen HTTP-Response zu empfangen kann die Dienste von “smskaufen.de” nutzen.

Neben der Webschnittstelle, können die Dienste auch über die Webseiten von “smskaufen.de” und auch über ein lokal installierbares Programm aufgerufen werden, und es gibt eine Email-Schnittstelle, die dort eintreffende Emails in SMS, MMS oder Faxe umwandelt. Zusätzlich wird noch ein WAP-Gateway angeboten, mit dem man von Mobiltelefon aus diese günstigen SMS versenden kann.
Ich freue mich, dass mir ein Geschäftspartner im vorigen Jahr diesen zuverlaässigen Anbieter empfohlen hat.

• Hier der Link zu “smskaufen.de”
• und hier der Link zum WAP-Gateway

Verfügbarkeit von Netzanbindung

Selbst wenn Webanwendungen in Form von RIAs so komfortabel wie Desktop-Anwendungen werden, so stehen sie doch nur zur Verfügung, wenn man eine genügend breitbandige Anbindung an das Internet hat. Ohne Internet keine Software, keine Daten, also Stillstand bei der Arbeit. Und eine verfügbare Internet-Anbindung kann auch in Zukunft noch lange nicht als garantiert angesehen werden. Bei der Zuverlässigkeit ist die Internet-Anbindung eben immer noch sehr weit von der Zuverlässigkeit z.B. der Stromversorgung entfernt.

Natürlich gibt das Internet auch wieder Hilfen, die diese Problematik abzufedern kann. So kann z.B. ein Kollege an einem anderen Standort reibungslos die Webanwendung weiter nutzen und die Bearbeitung der Aufgaben sicherstellen, was mit einer Desktop-Anwendung nicht möglich wäre.

Das Internet ist nicht so sicher, wie das eigene Gebäude

Bei Webanwendungen liegen die zu bearbeiteneden Daten auf Webserver weit ab vom Nutzer und werden zur Bearbeitung über das Internet hin und her transportiert. Auch wenn immer mehr Menschen keinerlei Hemmungen haben persönlichste Informationen in Text-, Bild- oder Videoform öffentlich im Internet zu speichern, so wird es trotzdem immer unternehmenskritische Daten geben, die auf keinen Fall in die falschen Hände kommen dürfen. Damit das nicht geschied, müssen die Verbindungen zwischen Anwendung und Server und die Server selbst optimal geschützt/verschlüsselt werden. Leider wird das von den meisten Entwicklern nicht so ernst genommen, oder erst nachträglich übergestülpt, sodass das Risiko für Sicherheitslücken auch in Zukunft nicht so schnell verschwinden wird und auch ziemlich stark von den Fähigkeiten der Entwickler abhängt.

Die Lösung ist auch hier erkennbar: Es müssen standardisierte, überall verfügbare, ausgereifte Sicherheitslayer existieren, auf die Softwareentwickler problemlos zugreifen können. Dann bestünde die Chance, die Sicherheit der im Internet bewegeten und abgelegten Daten auf konstant hohem Niveau, unabhängig von den Fähigkeiten der Entwicklern, zu gewährleisten.

Datenbanken sind keine Dateien

Der Desktop-Nutzer hat gelernt mit Dateien umzugehen, er weiß genau was EXE, MP3 oder JPG bedeutet. Diese Dateien lassen sich kopieren, anhängen, speichern, ansehen und bearbeiten. Das gilt so im Internet nicht mehr. Webanwendungen speicher fast immer die Daten in entfernten Datenbanken. Man kann seine Mailbox bei WEB.DE nicht nehmen, und auf den Memorystick kopieren. Man kann sein Flikr-Bild nicht an eine Email anhängen, oder zumindest nur über den Umweg eines Downloads und wieder Uploads. Es fehlt den Webanwendungen die Verbindung auf der Nutzerseite. Das macht heute viele Arbeitsschritte sehr schwierig bis unmöglich.

Die Lösung hier heißt wohl eher nur: Alle Nutzer müssen warten, bis ein Großer wie Microsoft das allumfassende Internet-Betriebssystem geschaffen hat. Denn das Desktop-Betriebssystem (meist ein Windows) hat ja auf dem lokalen PC genau die Grundlagen geschaffen, die das Hin und Her von Dateien zwischen den verschiedensten Desktop-Anwendungen erst möglich gemacht hat.

Simon Morris meint deshalb in seine Zusammenfassung: Die Argumente gegen Webanwendungen sind da, sie sind aber lösbar, und sie werden in vielen Webanwendungen schon in vielfacher Form mehr oder wendiger gut gelöst. Es müssen aber erst alle diese Erkenntnisse in einem globalen Internet-Betriebssystem zusammengeführt werden, bevor Webanwendungen den wirklichen Durchbruch erleben können.

Hier finden Sie den Artikel von Simon Morris auf java.net (in englisch)

Nach der Installation von Flash-Lite 2.1 habe ich eine kleine Flash-Animation auf das E61 geladen. Wenn ich diese Animation über den Browser anklicke, wird weiterhin das alte Flash-Lite 1.1 gestartet. Wenn ich die Animation mit dem neuen Flash-Lite laufen lassen will, muss ich erst über “Programme” das neue Flash-Lite starten, um dann aus dem Flash-Lite heraus die Animation auszuwählen, die dann tatsächlich auch im neuen Flash-Lite läuft.

Bisher habe ich noch an keiner Stelle einen Hinweis gefunden, wie ich das nachträglich installierte neue Flash-Lite zum “Default”-Player machen kann. Da das alte Flash-Lite irgendwo im Symbian-Paket mit drinnen steckt, kann ich das alte Flash-Lite auch gar nicht deinstallieren. Der neue Player wird also voraussichtlich in meinem E61 ein etwas aussetziges Leben führen müssen. Mal sehen, wie das gehen wird, ich fange demnächst an, erste kleine Testprogramme für diesen Player zu schreiben.

Die Adobe-Seite für Nokia-Besitzer ist: http://www.adobe.com/devnet/devices/nokia.html

Von dort aus geht es nicht nur zum Player-Download, sondern es gibt auch Links zu vielen Unterlagen für Entwickler.