Michael weiß was

Ich habe entdeckt, dass es seit einigen Tagen eine vollwertige und sehr günstige Lösung zum digitalen Signieren von Rechnungen gibt. Da ich selbst etwas Hintergrundwissen zu digitalen Zertifikaten besitze, habe ich das Angebot auf sein Vollwertigkeit hin überprüft.

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.

Die kleine freundliche Software PUTTY ist ein hervorragender Freeware-SSH-Client für den verschlüsselten Zugriff auf die Kommandozeile eines entfernten Linux-Servers. Wer einen eigenen Server bei einem Provider betreibt, kommt an diesem Werkzeug nicht vorbei. Bei dem Thema „Zeichensatz“ habe ich lange nicht tiefer nachgedacht und hatte deshalb so meine Überraschungen. Da gibt es den Midnight-Commander, der gut für das Navigieren in den Verzeichnisbäumen und zum Editieren von Dateien geeigenet ist, der zur guten Darstellung Liniensymbole verwendet. Und da gibt es unter Suse-Linux z.B. das Konfigurationswerkzeug YAST, dass auch Linensymbole verwendet. Lange habe ich mich damit abgefunden, dass die Liniendarstellung nie in beiden Werkzeugen gleichzeitig funktioniert hat. Jetzt kommt noch hinzu, dass ich mit einer Webanwendung den Datei-Upload anbiete und dabei die Nutzer auf die Idee kommen Dateien von ihrem Windows hochzuladen, die Umlaute im Dateinamen haben. Da war jetzt der Zeitpunkt gekommen, an dem ich mich mit der richtigen Darstellung aller Symbole in meinem Putty beschäftigen musste, mit folgendem Ergebnis:

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

Die internationale Kontonummer IBAN wird immer öfter auch ein Thema für Programmierer. Erst einmal wird sie im erleichterten europäischen Zahlungsverkehr immer häufiger genutzt, und dann kann man die IBAN per Software gut nach verschiedene Kriterien geprüften.

• 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.

Seit einigen Monaten biete ich meinen Kunden/Interessenten in einer Webanwendung einen Callback-Service an. Sie können dazu eine Webseite aufrufen und angeben wann sie auf welcher Nummer angerufen werden wollen. Damit ich schnell reagieren kann, versendet meine Webanwendung nach Eingabe des Callback-Wunschs eine Email an mich, und eine SMS auf mein Mobiltelefon. So kann mir kein Callback-Wunsch verloren gehen, auch wenn ich gerade unterwegs bin und der Callback innerhalb kurzer Zeit gewünscht wird.

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

Simon Morris ist gestern im Weblog bei java.net auf diese Frage ausführlich eingegangen. Er betont zwar, dass er ganz sicher kein Gegner von RIAs ist, aber er hat aus diversen Gesprächen drei wesentliche Argumente herausgearbeitet, die diese Frage aufkommen lassen.

Ich interessiere mich schon länger für das Programmieren von Flash-Anwendungen. Jetzt habe ich mich mal dem Thema Flash-Lite zugewandt, weil ich ein Smartphone Nokia E61 besitze. Da habe ich dann herausbekommen, dass dort ein Flash-Lite der Version 1.1 drauf ist ( nachdem ich das Symbian auf S60 3rd Edition upgedatet hatte). Bei Adobe habe ich aber gesehen, dass es das Flash-Lite bereits in der Version 2.1 gibt. Und tatsächlich gibt es dort auch ein passendes Update für mein E61, allerdings nur in englisch. Das Flash-Lite 1.1 aus dem Symbian-Update ist in deutsch. Das stört mich aber nicht, Englisch ist für mich kein Problem.

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.