Muhasebe programıyla entegrasyon nasıl kurulur?

Muhasebe programıyla entegrasyonun biçimini kaydın sahibi belirler; sahip belliyse aktarımın yönü, düzeltmenin nereye düşeceği ve elle kalan iş de kendiliğinden çıkar. Sahip tek ve sizseniz dönem kaydı sizin tarafınızda üretilir, defteri tutan taraf onu alır ve kaynağa dokunmaz. Pilatesco’da paketin satışı defterde bir satır açar, sonraki haftalarda kullanılan dersler açmaz; takvimden okunan kullanım muhasebe biçimli kayıt üretmez.

Muhasebe programı sizin olmayabilir

Bir işletme “entegrasyon” derken çoğunlukla kendi sistemine eklenecek bir modül düşünüyor. Defterin sahibi kendi dışındaysa eklenecek bir modül yok. Defteri mali müşavirin programı tutuyorsa muhasebe programıyla entegrasyon, sahibi ayrı iki kayıt arasına kurulan bir teslim noktasıdır.

Ayrımı görmek için kayıtların bugün nerede durduğuna bakmak yetiyor. Kendi ürünümüz olan AlgoCar servis yönetim yazılımını geliştirirken yola çıktığımız atölye düzeni buydu: atölyeye giren araç için açılan emir bir yazılımda tutuluyordu, tüketilen parçanın deposu ikincisinde, kesilen fatura üçüncüsünde. Üç yazılım, üç ayrı kayıt sahibi demek. Zinciri tek sistemde toplamak bizim işimiz ve şu an geliştirmeye devam ettiğimiz şey de o.

Ama bu sahiplerden biri toplanamıyor. Defter sizin dışınızdaki bir programda tutuluyorsa o program içeri alınamaz. Sahibi başkasıdır, kendi döneminin ritmine göre çalışır ve sizin sisteminiz ne yaparsa yapsın orada durmaya devam eder. İçeri alınamayan bir şeyin yerine kurulabilecek tek şey ise bir teslim noktasıdır.

Bu ayrım sık karıştırılan iki işi birbirinden ayırıyor. Entegrasyon ile kuruluş kararı arasındaki ayrımı daha önce ayrıca yazmıştık: entegrasyon ayrı sistemleri birbirine bağlar ve kurulan her bağ kendi bakımını ister; kuruluş kararı ise kayıtları baştan aynı yerde oluşturur, dolayısıyla bağlanacak bir şey bırakmaz. İçeri alınabilen kayıt için doğru cevap kuruluş kararıdır. Defter için o cevap yok, çünkü o kaydın nerede oluşacağını siz seçmiyorsunuz. Geriye dikiş kalıyor.

Dikişten geçen şeyi de baştan daraltmak gerekiyor. Geçen şey tek bir belge değil, muhasebe biçimli kayıt: dönem toplamı, cari hareket, tahsilat. Belgenin kendisi ayrı bir konu. Numarasının nerede verildiğini, hangi tipte düzenlendiğini ve resmî tarafa nasıl geçtiğini e-fatura entegrasyonunun nasıl çalıştığını anlatan yazıda açtık; burada konu defterin kendisi.

Karşı durum en baştan söylensin. Defter sizin kendi muhasebe ekibinizin, sizin sahipliğinizdeki bir programında tutuluyorsa ortada iki sahip yok demektir. O zaman soru dikiş sorusu değil kuruluş sorusudur ve bu yazının anlattığı iş size gelmez.

Hangi kayıt hangi tarafta oluşur

Teslim noktasının nereye kurulacağını sormadan önce ne teslim edileceğini sınıflamak gerekiyor. Kapsam da fiyat da bu sınıflamadan çıkıyor; yapılmadan konuşulan entegrasyon isteği hem tarifsiz hem fiyatsız kalıyor.

İki sütun var. Birincisi operasyonel kayıt: işin kendisi olan, sizin sisteminizde oluşan ve orada kalan kayıt. AlgoCar’da araç için bir emir açılıyor, tüketilen parça o emrin üstüne yazılıyor; ikisi de operasyonun kendisi. Pilatesco randevu ve paket takip sisteminde aynı sütunda paket satışı, rezervasyon ve kalan ders hakkı duruyor. Kalan hak müşterinin kendi kaydında taşınıyor, bunun için ikinci bir defter açılmıyor. Sistem yayında; destek ve güncellemeleri sürüyor.

İkinci sütun muhasebe biçimli kayıt: birinciden türeyen ve defterde karşılığı olan kayıt. Fatura bu sütunun en tanıdık üyesi. AlgoCar’da iş emri kaydından kesiliyor, Pilatesco’da paket satıldığı anda oluşuyor. Cari hareket, tahsilat ve dönem toplamı da aynı sütunun adları. Sizin sisteminiz bunları tutmuyor; bunların türediği operasyonel kaydı tutuyor. Bu ayrımın pratik karşılığı şu: bir kaydı tutmak, o kaydın oluştuğu yerin ve düzeltildiği yerin sizde olması demek.

Sınıflamanın en öğretici yeri ise negatif tarafı. Her operasyonel kaydın defterde bir karşılığı yok. Pilatesco’da haftalara yayılan ders kullanımı takvimden okunuyor ve muhasebe biçimli hiçbir kayıt üretmiyor. Buradan çıkan sonuç kapsamı doğrudan daraltıyor: karşı tarafa gidecek kayıt listesi, sizin tuttuğunuz kayıt listesinden her zaman kısadır.

Bir sınır daha var ve belgelenmiş hâli AlgoCar’da duruyor. İşletme tarafı ile muhasebe tarafı, servis kaydının durduğu aynı sistemi paylaşıyor; bu yüzden bir işin masrafı da karşılığı da aynı yerde kapanıyor. İçeride kapanan şeyin adı işin ticari kaydı. Yasal defterin hangi programda tutulacağı bu kaydın dışında, ayrı bir soru olarak duruyor. İkisini aynı şey sayan bir kapsam konuşması yanlış yerden başlıyor.

Karşı durum sınıflamanın alt sınırını çiziyor. Bir kayıt tipi sizin sisteminizde hiç oluşmuyorsa ondan muhasebe biçimli bir kayıt türetilemez. Pilatesco’nun başlangıç düzeninde kalan ders hakkı takvimin dışında, defterde takip ediliyordu. Sistemde var olmayan bir kayıttan hiçbir şey türemez; önce onu sistemin içine almak gerekir.

Tek yönlü türetme nasıl işler

Aktarımın yönü bir tercih gibi konuşuluyor. Değil. Yön, karşı tarafa kendi kaydınıza yazma hakkı verip vermediğinizin kararı ve bu karar veri modeli kurulurken veriliyor. Tek yönlü türetmede kaynak kayıt sizin sisteminizde kalır, muhasebe biçimli dönem kaydı ondan üretilip defteri tutan tarafa teslim edilir ve karşı taraf kaynağa yazmaz.

Yönün nasıl işlediğini tek sistemin içinde görmek daha kolay. AlgoCar’da tüketilen parça emrin üstüne yazıldığı anda stok azalıyor; depoya ikinci bir giriş yapılmıyor. Kaynak iş emri, stok hareketi ondan okunuyor. Ters yön hiç açılmıyor: depo ekranından yapılan bir düzenleme iş emrini yeniden yazmıyor. Kaynak kayıt ile türev kaydın kuruluşta ayrıldığını anlatan mimari yazısında bu ayrımı ayrıca kurmuştuk.

Aralık üstünden türetme de aynı yönü izliyor. Pilatesco’da haftalara yayılan kullanım takvim kayıtlarından okunuyor; kalan hak için ayrı bir tablo tutulmuyor. Paket satışı ile ders kullanımı tek müşteri kaydından okunuyor. Türev, kaynağın yanına ikinci bir gerçek koymuyor.

Aynı kuralı dikişe uygulayınca tek yönlü teslim çıkıyor. Kaynak kayıt sizde kalıyor, muhasebe biçimli dönem kaydı ondan üretiliyor, üretilen kayıt defteri tutan tarafa akıyor ve karşı taraf bir alıcı olarak duruyor. Burada dürüst olmak gerek: bu bir kurulum kuralı, gösterebileceğimiz bir vaka değil. Havuzumuzdaki hiçbir projede muhasebeye teslim edilmiş bir dönem kaydı belgelenmiş değil ve teslimi bir müşteri işinin sonucu diye anlatmıyoruz.

Teslim biçimini de bu yüzden jenerik anlatmak zorundayız. Ölçü şu: dönem kaydı sizin sisteminizden üretilir ve karşı tarafın okuyabildiği biçimde çıkar; teslim edildiği bilgisi de kaydın üstünde bir durum olarak durur. Ayrı bir bekleyenler listesi açılmaz, çünkü elle tutulan her ikinci liste ilkinden ayrışır ve bir süre sonra hangisinin doğru olduğu yeniden sorulur.

Karşı durum burada bir sınır çiziyor. Türetme ancak kaynak kayıt sizin sisteminizde oluşuyorsa kurulabilir. Kaynak, değiştiremediğiniz eski bir programda oluşuyorsa dönem kaydı türetilemez, yalnızca ikinci bir giriş olarak taşınır. O noktada yapılacak iş aktarım kurmak değil, önce o sistemi okuyup kaydın nerede oluştuğunu değiştirmektir. Bu, devralınan sistemi önce okuyan danışmanlık işinin konusu; bu yazının değil.

Çift yönlü eşitleme neden kalıcı bir mutabakat işine dönüşür

Çift yön genelde daha tam bir bağlantı gibi anlatılıyor: iki taraf da yazabilsin, ikisi de güncel kalsın. Mekanizma tersini söylüyor. Çift yönlü eşitlemede aynı kayıt iki ayrı defterde yazılabilir hâle gelir ve hangi değişikliğin geçerli olduğunu söyleyen kuralın yazılacağı ortak bir yer kalmaz.

Sorunun kendisi yeni değil ve tek sistemin içinde çözülmüş hâli elimizde var. AlgoKlima klima servis yönetim yazılımını geliştirirken karşımıza çıkan zorluklardan biri şuydu: ofisteki panel ile sahadaki uygulama, birbirinin ne yaptığını bilmeden tek kaydın üstünde değişiklik yapabiliyordu. Bunu iki arayüzü aynı sisteme bağlayarak ve bağlantı geri geldiğinde hangi değişikliğin geçerli olacağını kodda tanımlı bir kurala bağlayarak kapatıyoruz. Çevrimdışı çalışan mobil uygulamada çakışmanın nasıl çözüldüğünü anlatan yazıda kuyruğun kendisini ayrıca anlattık. Burada önemli olan, kuralın kimin elinde olduğu.

Çözümün iki şartı var. Ortada tek bir kayıt olacak. O kaydın üstündeki kuralın sahibi siz olacaksınız. Kuralın zamanı da erken: sıra kuralı sonradan seçilseydi, hangi değişikliğin kazandığı çoktan yazılmış kayıtlar üzerinde çözülmek zorunda kalırdı.

Dikişin öte yanı sizin sisteminiz değilse iki şart da düşüyor. Aynı kayıt iki ayrı defterde iki kez yaşıyor ve kuralın yazılacağı ortak bir kod tabanı yok. Bu durumda hangi tutarın geçerli olduğu bir kez kurulup bitmiyor. Her dönem yeniden kararlaştırılıyor ve kararı veren yazılım değil, iki tarafı yan yana açıp bakan bir insan oluyor. Mutabakatın kalıcı bir işe dönüşmesi tam olarak burada başlıyor; çift yönün alıcıya vaat ettiği kolaylık da burada tersine dönüyor.

Yazılımın sınırı da bu bölümde görünüyor. Çakışma çözümü kaydı tekilleştirir, kararı tekilleştirmez. İki defterin hangi tutarı doğru saydığı bir kayıt sorusu değil bir karar sorusudur; kod ancak o kararın nereye yazılacağını verir. Kararın sahibi belli değilse yazılacak yer de yoktur.

Karşı durum önemli, çünkü kural çift yönü yasaklamıyor. Sistemin iki yüzü de sizinse çift yön meşrudur ve kural kod olarak yazılır; AlgoKlima’da yaptığımız da bu. Sorunlu olan çift yön değil, sahibi olmayan çift yön.

Aktarım hangi sıklıkla akar

Sıklık sorusu genelde korkuyla cevaplanıyor: ne kadar sık gönderirsek o kadar güvenli oluruz. Sıklık korkudan değil kayıt tipinden türüyor. Operasyonel olay anında oluşuyor, defter kaydı dönemsel; bu yüzden muhasebe programına giden şey dönem kaydı oluyor.

Operasyonel tarafın hızı belli. AlgoCar’da parça emre yazıldığı anda stok azalıyor. Pilatesco’da takvime yazılan her rezervasyon paketten bir hak düşürüyor. İkisi de operasyonun hızında çalışıyor, çünkü ikisi de operasyonun kendisi.

Muhasebe biçimli kayıt aynı hızda oluşmuyor. Pilatesco’da fatura paketin satıldığı anda bir kez oluşuyor; sonraki haftalarda kullanılan dersler takvimden okunuyor ve yeni bir muhasebe kaydı üretmiyor. Satış anı ile kullanım aralığının neden ayrı taşındığını randevu ile servis talebini ayıran yazıda anlattık. Buradaki sonucu tek cümle: dikişin operasyon hızında çalışması gerekmiyor.

Aynı sistemin içinde iki hız yan yana durabiliyor. AlgoCar’da stok hareketi parça başına düşüyor, fatura iş emri başına kesiliyor. Tek zincir, iki ayrı sıklık. Dışarıya açılan dikiş bunlardan hangisine göre kurulacak sorusu da bu yüzden anlamlı bir soru.

İki taraf ayrı tutulduğunda buluşma yeri kendiliğinden ayın kapanışına kayıyor. AlgoCar’ın başlangıç düzeninde bir işin masrafı ile karşılığı ancak ayın kapanışında, insan eliyle karşı karşıya getiriliyordu. Dönemin iki defterin buluştuğu birim olduğunu en net orada görüyorsunuz: kimse bunu haftalık yapmıyor, çünkü defterin kendi birimi ay.

Buradan bir kurulum önerisi çıkıyor, bir vaka değil. Dönem kaydını dönem kapanışında teslim etmek, defteri kendi biriminde beslemek demek. Her olayı göndermek ise karşı tarafa kendi defterinde satırı olmayan kayıtlar yığmak. Muhasebeci gelen her hareketi kendi tarafında yeniden sınıflamak zorunda kalıyor ve teslim ettiğiniz şey veri değil iş oluyor.

Karşı durum sık karşımıza çıkıyor. Sisteminiz yalnız operasyonel kayıt tutuyorsa ve muhasebeye gidecek kayıt sayısı elle girişi zorlamıyorsa, aktarım kurmaya gerek yok. Dönem raporunu üretip teslim etmek yeter. Kurulan her bağın kendi bakımı var ve o bakım, bağın kaldırdığı işten büyük olabiliyor.

Muhasebeci aktarımdan sonra kaydı düzeltince ne olur

Asıl korku burada duruyor. Karşı taraf kendi programında bir rakamı düzeltiyor ve sizin sisteminizdeki kayıt sessizce yanlış kalıyor.

Tek yönlü düzende cevap net. Teslim edilmiş dönem sizin tarafınızda kapanmıştır; mali müşavirin kendi programında yaptığı düzeltme onun defterinin işidir ve kaynağa geri yazılmaz. Kaynak kayıt olduğu gibi kalır. Bu bir eksiklik değil, yönün kendisi: geri yazım açılsaydı kaydın iki sahibi olurdu ve bir önceki bölümdeki sorun bu kez sizin sisteminizin içine taşınırdı.

Kaynakta gerçekten bir hata varsa yol yine tek. Düzeltmeyi siz yaparsınız ve yeni bir kayıt olarak yaparsınız; teslim edilmiş dönemi geriye dönüp düzenlemezsiniz. Fark bir sonraki teslimle çıkar ve iki tarafın da elinde neyin ne zaman değiştiğini gösteren bir iz kalır.

İlkenin çalışan hâli Pilatesco’da duruyor. Dersin iptal edilmesi, müşterinin gelmemesi ve dersin tamamlanması paket bakiyesinde ayrı ayrı sonuç doğuruyor; hangisinin hakkı iade ettiği kurala yazılmış, kimsenin yorumuna bırakılmamış. Kimse bakiyeyi elle düzeltmiyor. Düzeltme, kuralı olan yeni bir kayıtla yapılıyor.

Düzeltmenin dağılmaması ise kuruluş kararının sonucu. AlgoCar’da bir işin masrafı ile karşılığı aynı kayıtta kapandığı için emirde yapılan bir değişiklik ikisini birden değiştiriyor. İki ayrı programa dağılmış bir düzende aynı değişikliği iki yere girmek gerekirdi ve ikisinin aynı kaldığını kimse garanti edemezdi.

Bir sınır: gönderilmiş bir belgenin kendi düzeltmesi, yani iptali ve itirazı, bu yazının konusu değil. Orada değişen şey defterin satırı değil belgenin kendisi ve kuralları da e-fatura entegrasyonu yazısının konusu.

Karşı durum bu bölümün en pratik kısmı. Muhasebecinin düzeltmesi kaynak kayıttaki bir hatadan geliyorsa, düzeltme yine kaynağa sizin tarafınızdan yeni kayıt olarak girilir. Otomatik geri yazım bu durumda da kurulmaz. Kurulursa hatanın hangi tarafta doğduğu bilgisi kaybolur ve bir sonraki dönemde aynı soru sıfırdan sorulur.

Üç kurulum yan yana

Tablo bir sıralama sunmuyor. Üç kurulumu yan yana koyuyor ve her birinin işletmede bıraktığı elle işi son sütunda gösteriyor. Belirleyici sütun ise kaydın sahibi.

Sütunlar arasındaki bağ tek yönlü. Kaydın sahibi belli olduğunda geri kalan üçü kendiliğinden belirleniyor: sahip tek ve sizseniz yön dışarı düşüyor, düzeltme yeni kayıt oluyor ve elle iş dönem teslimine iniyor. Sahip ikiyse yön iki yöne açılıyor, düzeltme her iki defterde ayrı ayrı yaşıyor ve elle iş her dönem tekrarlanan bir mutabakata dönüşüyor.

Çoğu işletme bugün ilk satırda duruyor. İkinci satıra geçmek bir ayar değişikliği değil; kaydın nerede oluşacağına dair bir karar ve o karar sistem kurulurken veriliyor. Üçüncü satır ise ilk bakışta ikincinin gelişmiş hâli gibi görünüyor, oysa kaydın sahibi sütununa bakıldığında ondan geri bir adım.

Zinciri kurarken sorduğumuz sıra hep aynı: hangi kayıt içeride oluşacak, hangisi dışarıda kalacak, dışarıda kalanla aramızdaki teslim noktası nereye düşecek. Operasyon, stok ve işin ticari kaydının tek zincirde kapandığı sistemleri böyle kuruyoruz; defterin nerede durduğunu da o sayfada okursunuz.