MT940 çözümleyici: dosyayı yapıştırın, hareket tablosu çıksın

1 Satır sonu CRLF mi LF mi?

Belirti:

Dosya doğru görünüyor ama çözümleyici “etiket bulunamadı” diyor.

Nedeni:

MT940 dosyaları genellikle CRLF (\r\n) ile üretilir. Dosya bir metin düzenleyiciden geçtiğinde ya da kopyala-yapıştır yapıldığında satır sonu LF’ye döner, bazen tek başına CR kalır. Etiketi satır BAŞINDA arayan bir okuyucu bu durumda hiçbir şey bulamaz.

Çözümü:

Bu araç üç biçimi de kabul eder: metni okumadan önce \r\n ve tek CR, LF’ye çevrilir. Kendi aktarımınızı yazıyorsanız satır sonunu normalleştirmeden ayrıştırmaya başlamayın.

2 :86: açıklaması ikinci satıra taşınca kayboluyor

Belirti:

Açıklamanın yalnızca ilk 65 karakteri tabloya geliyor.

Nedeni:

:86: alanı en çok altı satır olabilir ve devam satırları etiketsizdir. “Satır satır oku, başındaki etikete bak” diye yazılmış bir okuyucu devam satırlarını tanımadığı için atar.

Çözümü:

Bir alan, bir sonraki “:” etiketine kadar sürer. Etiketsiz satır, açık olan son alanın devamıdır. Aynı kural :61: satırının altındaki 34 karakterlik ek bilgi alanı için de geçerlidir.

3 Tutarda ondalık ayracı virgüldür

Belirti:

48250,00 tutarı 4.825.000 ya da 48 olarak okunuyor.

Nedeni:

SWIFT tutar biçiminde ondalık ayracı virgüldür ve binlik ayracı yoktur. Virgülü binlik ayracı sanan ya da parseFloat gibi noktayı bekleyen bir dönüşüm sayıyı sessizce bozar.

Çözümü:

Virgülü ondalık ayracı olarak alın. Bu araç ayrıca dışa aktarılmış dosyalarda görülen “1.180,50” ve “1180.50” sapmalarını da doğru okur; iki ayraç birden varsa sondaki ondalık kabul edilir.

4 RD ve RC yön kodları ters toplanıyor

Belirti:

Bakiye, bir iptal kaydının tutarının iki katı kadar sapıyor.

Nedeni:

İşaret alanı iki karakterdir ve C/D dışında RC ile RD de alır. Yalnızca ilk karaktere bakan bir okuyucu RC’yi alacak, RD’yi borç sayar — oysa ikisi de ters kayıttır ve etkileri tam tersidir.

Çözümü:

RD bakiyeyi artırır, RC azaltır. Bu araç dört işareti de ayrı ayrı tanır ve tabloda “borç iptali / alacak iptali” diye gösterir.

5 İki haneli yıl ve yılsız işlem tarihi

Belirti:

Ocak ayındaki ekstrede bazı hareketler bir yıl ileri ya da geri görünüyor.

Nedeni:

Valör tarihi YYMMDD (6 hane), işlem tarihi ise MMDD (4 hane) yazılır; işlem tarihinde yıl bilgisi hiç yoktur. Yılı doğrudan valörden kopyalayan bir okuyucu, 31 Aralık’ta kaydedilip 1 Ocak valörlü bir hareketi bir yıl ileri taşır.

Çözümü:

İşlem tarihinin yılı valörden türetilir, ama ay farkı altıdan büyükse yıl kaydırılır. İki haneli yıl için bu araç 00–99 aralığını 2000–2099 olarak yorumlar; standart yüzyılı tanımlamaz.

6 Türkçe karakterler ve dosya kodlaması

Belirti:

Açıklamalarda “Ş” yerine bozuk karakterler çıkıyor.

Nedeni:

SWIFT’in x karakter kümesinde Türkçe harfler yoktur; bankalar açıklamaları ASCII’ye indirerek yazar (“ŞİRKETİ” yerine “SIRKETI”). Buna rağmen bazı dışa aktarımlar windows-1254 baytları taşır ve UTF-8 sanılarak okunduğunda bozulur.

Çözümü:

Bu araç yüklediğiniz dosyayı önce katı UTF-8 olarak çözmeyi dener, başarısız olursa windows-1254’e düşer. Metni doğrudan yapıştırdığınızda bu sorun zaten oluşmaz.

7 İşlem tip kodu standarda uymuyor

Belirti:

Referans kolonunda referansın başına dört harf yapışmış görünüyor.

Nedeni:

İşlem tip kodu 1!a3!c biçimindedir ve ilk karakteri S, N ya da F olmak zorundadır. Bazı üretimlerde bu alan boş bırakılır ya da farklı bir harfle başlar; kodu körlemesine dört karakter sayan bir okuyucu referansın başını yer.

Çözümü:

Bu araç kodu yalnızca S/N/F ile başlıyorsa ayırır. Uymuyorsa kodu boş bırakır, satıra not düşer ve kalan metnin tamamını referans olarak gösterir — tahmin etmez.

8 Dosyanın başındaki {1:…}{2:…}{4: blokları

Belirti:

İlk etiket bulunamıyor ya da ilk satır bozuk okunuyor.

Nedeni:

MT mesajları bazen SWIFT blok çerçevesiyle birlikte gelir: başta {1:} temel başlık, {2:} uygulama başlığı, {4:} metin bloğu; sonda -} bitişi. Ekstre alanları bu çerçevenin İÇİNDEDİR.

Çözümü:

Bu araç blok çerçevesini temizler ve içerideki alanları okur. Çerçeveli ya da çerçevesiz dosya farketmez.