Paraşüt’teki faturaları ERP’ye aktarmak: mükerrer kayıt olmadan

Yeni bir ERP kurarken en sevimsiz an, ilk aktarımın bittiği andır. Her cari iki kez açılmıştır, faturaların bir bölümü çiftlenmiştir, bakiyeler tutmaz. Bunu düzeltmek genellikle veriyi silip baştan başlamak demektir — ve ikinci denemede de aynı şey olur, çünkü sorun aktarımın kendisinde değil, öncesinde atlanan bir adımda.

Neden çiftleniyor

Muhasebe programındaki Marmara Bilişim Teknolojileri Anonim Şirketi ile ERP’deki Marmara Bilişim Teknolojileri A.Ş. aynı firmadır. İnsan bunu bir bakışta anlar; program anlamaz. Metin karşılaştırması burada yeterli değil, çünkü:

• Unvanlar farklı yazılır: “Ltd. Şti.” / “Limited Şirketi” / “LTD.ŞTİ.”
• Aynı firmanın iki şubesi iki ayrı kart olabilir.
• Şahıs firmalarında kart bazen kişi adıyla, bazen işletme adıyla açılmıştır.
• Stoklarda kod aynı, ad farklıdır; ya da tersi.

Bu yüzden “akıllı eşleştirme” tek başına bir çözüm değil. Yapılabilecek en iyi şey, güvenilir bir anahtar varsa onu kullanmak, yoksa karar vermeyi kullanıcıya bırakmak.

Güvenilir anahtarlar

“Tarih + tutar” zayıf çünkü aynı gün aynı müşteriye aynı tutarda iki fatura kesmek hiç de olağandışı değil. Zayıf anahtarları aday üretmek için kullanmak doğru; kayıt yazmak için kullanmak değil.

Sıra: eşleştir, sonra çek

1. Cariler. Önce bunlar, çünkü fatura carinin üstüne yazılır. Yanlış eşlenen bir cari, ona bağlı bütün faturaları yanlış hesaba taşır.
2. Ürünler. Fatura kalemi ürüne bağlanır; eşlenmemiş ürün yeni stok kartı açar ve stok listeniz bir gecede ikiye katlanır.
3. Kasa ve banka hesapları. Tahsilat aktaracaksanız şart: tahsilatın karşı hesabı bir para hesabı olmak zorunda.
4. Faturalar. En sona. İki tarafta da duran faturaları eşlersiniz; eşlenmiş fatura ikinci kez çekilmez.

Çekerken: idempotent olmak

Aktarım işleminin tekrarlanabilir olması gerekir: aynı dönemi ikinci kez çekmek yeni kayıt üretmemeli, yalnız eksikleri tamamlamalı. Bunun tek sağlam yolu, kaynak sistemdeki kimliği hedefte saklamak ve o kimliğin benzersizliğini veritabanı seviyesinde garanti altına almak.

Uygulama kodundaki “önce bak, yoksa yaz” kontrolü tek başına yetmez: iki istek aynı anda “yok” cevabını alıp ikisi de yazabilir.

Kalem seviyesinde neler kayboluyor

• Alan uzunlukları. Kaynakta 250 karakter yazılabilen açıklama, hedefte 100 karakterlik alana girmeyebilir. Kırpmak mı, reddetmek mi — karar verip belgelemek gerekir. Sessizce kırpmak en kötüsü.
• İskonto biçimi. Bir tarafta yüzde, diğerinde tutar tutuluyorsa çevirmek kolay; ama iki iskonto üst üste uygulanıyorsa sıra önemlidir.
• Yuvarlama. Kalem bazında yuvarlanan KDV ile fatura toplamında yuvarlanan KDV kuruş farkı üretir. Hangisinin esas olduğu baştan seçilmeli.
• Kalemsiz belgeler. Gider faturaları çoğu zaman kalemsizdir; tek satırlık bir hizmet kalemine dönüştürmek gerekir.

Ne kadar sürer

Paraşüt API’si on saniyede on istek kabul ediyor ve sayfa başına en fazla 25 kayıt veriyor. Bin faturalık bir geçmiş, ilişkili kayıtlarla birlikte, kırk sayfa demek. Birkaç dakikadan bahsediyoruz, saniyeden değil. İlk aktarımı mesai dışına almak ya da dönem dönem yapmak makul.

Bu sınırların ayrıntısı: Paraşüt API’siyle çalışırken karşılaşılan sınırlar.

Kontrol listesi

• Eşleştirme cari → ürün → kasa → fatura sırasıyla yapıldı mı?
• Vergi numarası boş olan cariler elle gözden geçirildi mi?
• Deneme olarak önce tek bir ay çekildi ve bakiyeler karşılaştırıldı mı?
• Aynı ay ikinci kez çekildiğinde kayıt sayısı değişmiyor mu?
• Kalem toplamları ile fatura genel toplamları tutuyor mu?

Dördüncü madde en önemlisi: aktarımın tekrarlanabilir olduğunu, aktarıma güvenmeden önce sınayın.