Dumm gelaufen

Ich wollte nur mal kurz was unter Windows 7 probieren und hab gar nicht gemerkt, dass da im Hintergrund Upates herunter geladen werden.

update

Naja, der Download war schnell – die Installation hingegen hat mich 2 Stunden lahmgelegt.

Unter Linux irgendwie besser gelöst, da werden die Updates zur Laufzeit installiert und werden mit dem nächsten Neustart des Rechners bzw. teilweise schon mit dem Neustart der Programme wirksam.

VoIP rückt immer näher….

Bei meinem Mitgesellschafter ist nun auch ISDN abgeschaltet und VoIP eingeführt worden.

Ok – konventionelles Setup dort: ISDN Telefonanlage im Keller und ein verlotterter Router für DSL.

Umstellung wurde für Ende Januar angesagt, letzten Donnerstag stand der Techniker vor der Tür (die DTAG erledigt sowas schneller als das Licht – also weit vor dem Termin).

Der hat einfach eine kleine VoIP-ISDN-Kiste vorgeschaltet und neuen Router installiert. Klappte alles prima, ich hab das Netz bei dieser Gelegenheit mal von 172.x nach 192.x umgezogen und tote Konfigurationen entfernt.

Heute wollte ich von dort aus eine Mail versenden. Denkste auch nur!

Erst dachte ich, dass mein Mailserver abgeschmiert ist. Dort eingeloggt, alles OK und es dämmerte mir, dass eventuell die Telekom Mailversand über den normalen Port 25 mittlerweile abgeklemmt hat (halte ich für legitim, denn diesen Weg nutzen die meissten infizierten Rechner auch um irgendwelchen Pillenspam zu versenden). Also das umkonfiguriert auf eine alternative Methode wo auch gleich Verschlüsselung stattfindet.

Und wtf? geht auch nicht.

Kurzer Blick in die diversen Foren: per Default ist im Telekomrouter der Mailversand auf bestimmte Mailhosts beschränkt. Also Telekom-Mailserver und dann eine Latte von Systemen die bevorzugt von denwelchen N00bs genutzt werden deren Rechner sowieso immer Virenverseucht ist.

Und diese kaputte Liste ist auch nicht änderbar – lediglich eigene Mailserver sind zufügbar. Hab ich gemacht, Mail ging raus, prima.

Deutsche Gründlichkeit halt eben: alles absichern und links noch ein riesiges Scheunentor offenhalten.

IBAN die Schreckliche (aus den Memoiren eines Programmierers)

PAIN

Der Beitrag „Meine Bank hat einfach zu viel Nullen“ meines alten Freundes Tobias Schrödel hat mich daran erinnert aufschreiben, welchen „Spass“ ich mit der SEAP-Umstellung hatte.

„Früher“ gab es „DTA-Austausch“, ein recht altertümliches Format aus der Zeit der Großrechner (feste Satzlänge, Umlaute sowieso nicht) und etlichen Einschränkungen die sich halt daraus ergeben. Sozusagen der „LADA Niva“ der Informatik: einfach, robust, unkaputtbar. Ausserdem war die Datensatzbeschreibung so gut, dass mit ihrer Hilfe ein brauchbarer Programmierer binnen eines Tages was zusammenschustern und die Testdatei (es gab ein Flag „ich bin nur ein Test“) der Bank zur Prüfung übergeben konnte.

Bei SEPA sollte alles anders werden. Moderne Datenstruktur (XML-Basierend), flexibel usw.. Also kein Lada mehr, eher ein Humvee.

Als wir Anfang 2013 mit der Planung angefangen haben war das erste Problem: wo bekommt man eine schlagkräftige Datensatzbeschreibung sowie dokumentierte Musterdateien her und wer prüft das, was ich da ausspucke. Ausser buntigen Flyern als PDF oder Powerpoint welche die Vorzüge von SEPA erklären war nämlich nichts zu haben was man brauchen könnte. Und wenn man bei den Banken genauer nachgefragt hatte kam heraus, dass man an keiner Stelle soweit war mit den Dateien irgendwas anfangen zu können – was mich verwunderte, denn ISO 20022 gibt es seit 2004 und müsste zumindest Bankintern schon seit paar Jahren eingesetzt werden.

Eher schon nach der Jahresmitte 2013 trudelten dann von mehreren Stellen zumindest schonmal Musterdatensätze ein, anhand der darin enthaltenen XML-Tags wie zum Beispiel „ReqdExctnDt“ konnte man über die Suchmaschine des geringsten Misstrauens Seiten im Netz finden, die sich damit schon näher auseinander gesetzt haben.

Je mehr wir ins Detail gingen, um so schlimmer wurde es. Manche Banken mussten gestehen, dass sie noch lange nicht so weit sind – „Payments Initiation“, abgekürzt „pain“, bekam schnell eine neue Bedeutung.

Sehr spannend war zb. die Frage, wieviel Text man denn im Belegtext unterbringen darf (es war in der Summe weniger als im alten DTA-Format) und ob man den Eintrag mit dem Belegtext beliebig oft wiederholen kann (lt. XML-Schema hätte ich jetzt die Frage mit „Ja“ beantwortet, in der Praxis darf das nur 1x per Transaktion an den Kunden/Lieferanten vorkommen). Der Belegtext ist insofern spannend, weil dort normalerweise drinsteht wer was zu welchen Konditionen bezahlt hat. Das kann im Extremfall so aussehen: D400083488 R70015547 1180,25 -2% Skto = 1156,65 (Zahlung Kunde an Lieferant, Kundennummer beim Lieferanten = 4000883488, Rechnungsnummer = 70015547, Bruttobetrag 1180,25 anzüglich 2% = 1156,65). Bei Skontozahlungen in Fremdwährung hat man unter Umständen einen noch längeren Buchungstext weil dann die Wechselkurse noch mit rein müssen. Und ich hab in ISO 20022 jede Menge Kram gefunden, aber nichts womit man den Belegtext in irgendeiner Forum strukturieren kann – selbst wenn es dafür eine Möglichkeit gibt, hab ich so meine Zweifel dass das bei jeder Bank folgerichtig implementiert wurde.

So – und nun möge der geneigte Leser sich vorstellen was passiert, wenn mit einer Überweisung 30-40 Rechnungen ausgeglichen werden. Das Feld hat ca. 130 Stellen und da passen mit viel Glück die Zahlungsinformationen für 15 Überweisungen rein, mit viel Pech nur eine einzige.

Nach vielem Telefonieren hab ich im Februar 2014 jemanden bei einer kleinen Bank gefunden der sich zumindest besser als ich mit dem Kram auskennt und der meinte „soweit wie ich das sehe müssen Sie für sowas einzelne Überweisungen machen.“ Mein Hinweis, dass seine Bank für jede Transaktion zwar kleines – aber in der Summe richtig viel Geld – haben möchte, kam erstmal nichts.

(Gibts da wirklich keine bessere Lösung?)

Was wir dann letztendlich gemacht haben: es wird bei einem drohenden Feldüberlaif wie seit 40 Jahren reingeschrieben „lt. Avis“ und dann ein Fax/E-Mail mit den detaillierten Zahlungsinformationen rausgeschickt.

Der 1. Februar 2014 (Letzter Termin für die Umstellung) rückte immer näher, wir hatten zwar schon länger alles fertig aber keiner der Banken konnte uns sagen ob alles richtig war. Die Kunden kauten nervös ihre virtuellen Fingernägel und erweiterten vorsorglich ihre Kreditlinien um im Fall der Fälle mal paar Tage länger ohne Geldeingang auszukommen.

Und es kam so, wie ich es mir schon im Januar gedacht habe: „Weil die Wirtschaft noch nicht so weit ist, gibt es eine Übergangsfrist bis zum 1. August“ (dass die Banken ebenfalls oftmals noch nicht wirklich fertig waren, hat man hier dezent verschwiegen). Leider haben paar Banken trotzdem eine Drohkulisse aufgebaut: „Wir stellen zum 1. Februar um und akzeptieren nichts mehr im DTA-Format“. Fand ich etwas ärgerlich weil es eigentlich nur die Banken waren, die vorher arg geschludert hatten und selber froh waren dass sie es rechtzeitig irgendwie hinbekommen hatten (in dieser Zeit aufgebaute Bekanntschaften in den EDV-Abteilungen dort haben mir Dinger erzählt …)

Wir habens dann im Februar gemächlich fertig gemacht und bei allen Kunden eingebaut. Testen lassen, gut wars. Bislang keine Beanstandungen, paar optische Fehler.

Was war sonst noch?
Bei der SEPA-Implementierung sind wir auf Probleme gestossen, die eigentlich schon bei der Referenzprogrammierung (sofern es eine solche gibt, vermutlich nicht) ein Stolperstein hätten sein müssen.

Um die Prüfziffer der IBAN bzw. ID zu generieren oder umgekehrt anhand der Prüfziffer zu testen ob die eingegebene IBAN gültig ist muss eine recht grosse Integerzahl durch 97 geteilt werden. Leider haben ältere Runtimes oder Umgebungen gar nicht die Möglichkeit, 123456789012345678/97 zu rechnen – flugs war ich wieder ein kleines Kind in der Klasse von Ada Olbrich und habe auf Karopapier dividiert und es dann genauso in Software gegossen. Nicht besonders Elegant – aber hinreichend schnell und vorallem funktioniert es fehlerfrei.

Nachwehen
Mein Freund Tobias hat in seinem Blogeintrag schon darauf verwiesen, dass die IBAN bei der Ausgabe alle 4 Stellen mit einem Leerzeichen versehen werden soll damit das irgendwie lesbar wird.

Leider interessiert das keine Sau, auf den üblichen Geschäftspapieren meiner Lieferanten ist die IBAN oft in einem Rutsch weggeschrieben (ADAC Überweisungsformulare zb.)

Bei der BIC (der „Bankleitzahl“) hat irgendein Vollspacken im ISO-Komitee auch Zahlen zugelassen – mit dem Ergebnis, dass HELAB1FF von HLABIFF bei den üblichen Fonts auf Geschäftspapieren kaum zu unterscheiden ist (fast alles was mit Sparkassen zu tun hat)

Die DEVK-Versicherung hat sich „nur“ in der Prüfziffer bei den Überweisungsformularen vertan. Teure Geschichte war das bestimmt 🙂