Bir restoran adisyonunun muhasebe fişine dönüşme serüveni

Merhaba;

Bu yazımda yaptığımız entegrasyonlarda basit anlamda bir noktadan başka bir noktaya veri taşırken, veriyi nasıl hesaplamalara sokmak durumunda kaldığımızı anlatacağım.

Gerçek hayattan örnek bir adisyon ele alıp bunu muhasebe fişine dönüştürdükten sonra bir muhasebe sistemine aktarım aşaması için ne gibi çalışmalar yapılabilir ki entegrasyondur neticede bu kadar da zor olamaz diye düşünüyor olabilirsiniz.

Örnek bir adisyon ele alalım.

Malum ülkemizde muhasebe sistemi biraz karmaşık, yiyecek ve içecek bedellerinin kdv oranları ve hatta yiyeceklerin servis edilme veya edilmeme şekline göre bile kdv oranları değişkenlik gösterebiliyor. Bu durumda eğer muhasebe entegrasyonları ile uğraşıyorsanız söz konusu entegrasyonlardan önce mevzuatı öğrenmeniz ve o mevzuata göre aktarım yapmanız ve hatta müşterilerinizden mevzuatı hatalı uygulayanlar varsa o süreci de entegrasyon öncesi düzeltmeniz gerekmekte.

Örnek adisyonda baya bi yiyecek ve içecek, alkol vs var. Adisyon o kadar büyük ki, ekran görüntüsünü alamadığım için verileri excel’e döküp yan sütünlara taşıdım :)

Şimdi özellikle bu adisyonda işleri karıştıran sadece kdv değil, aynı zamanda bu adisyonda belli bir iskonto oranı uygulanmış.

Ülkemizde restoran sistemi geliştiren veya bu sektörde iş yapmaya çalışan yazılım firmalarında çalışanlar bu yazıyı okuduğunda ne demek istediğimi anlayacaktır. İşin iskonto bacağı en sıkıntılı taraftır. Çünkü gerçek hayatta restoranlarda işler düz mantık ilerlemez, masa taşımalar, masa birleştirmeler, ikramlar, servis ücretleri, yuvarlama iskontoları, satır veya genel iskontolar bir çok kavram devreye girer.

Aynı zamanda devlete karşı yükümlülüklere göre uygulanan iskontonun da vergilendirme yöntemi değişkenlik gösterecektir. Yani devlet der ki, iskonto yapabilirsin fakat bu yaptığın iskontonun da vergisini vereceksin. Yani hem müşteriye ikram edeceksin hem de almadığın paranın vergisini ödeyeceksin.

Bu sistemleri tasarlamak kadar bu sistemlerdeki verileri muhasebe sistemlerine aktarmak da zordur. Şimdi bizim işimiz tam olarak bu olduğu için buradaki mevzuat ve hesaplamaları, veriler arasındaki karmaşıklığı öncelikle basitleştirmek ve hatta muhasebe (tek düzen hesap planına) uygun hale getirmek gibi ekstra bir işimiz daha var.

Çünkü kullanıcı bir kaydın hatalı aktarıldığını söylerse, bizim tarafta neyin ne şekilde hatalı olduğunu anlayabileceğimiz yöntemler uydurmamız ve o kadar satırın olduğu bir adisyonda tek tek ürün arayıp hesaplama yapmamamız gerekmekte.

Şimdi özellikle belirtmek isterim ki, Son kullanıcıların kullandığı ön muhasebe veya hızlı satış sistemleri muhasebe hesap planı için bir çıktı oluşturmaz. Bildiğimiz adisyon başlık ve adisyon detay tablolarında kayıtları tutar ve siz entegrasyon yaparken bu kayıtların kdv oranlarına göre gerekiyorsa tersten hesap yapmak durumunda kalabilirsiniz.

Şimdi bu senaryoda müşteri diyor ki, ben muhasebe sistemimde sadece yevmiye fişi ile hesabımı kitabımı takip ediyorum. Ön muhasebe tutmuyorum, sen yapılan satışları muhasebe sistemime düzgün bir biçimde aktar. Ben bunları işlemek için uğraşmayayım ve ay sonu geldiğinde tek tuş ile muhasebe kayıtlarım sistemimde oluşsun.

Z raporlarımla yani cirolarımla kayıtlarım örtüşsün.

Bu durumda bizim bu adisyonu aşağıdaki format’a yani borç, alacak, ve satırlardaki kayıtları da iskontosuna kadar kdv lerine ayrıştırılmış hale dönüştürmemiz gerekiyor.

Özellikle bu adisyondaki tutarların detaylarına baktığınızda, turşu satışı ile yiyecek satışı ayrılmış durumda peki sizce neden ?

Hemen cevap vereyim, restoran muhtemelen masaya servis dışında ayrıca kasada kavanozda da turşu satıyor ve bunun kdvsi vergi usül kanunu gereği %1

Şimdi asıl mevzu ya gelelim.

Özellikle iskontolu satışlarda aşağıdaki gibi bir muhasebe hesabı oluşturulmakta.

Yani borç ve alacak taoplamlarının 0 vermesi gerekmektedir. Tabiiki bu örnekte az bir kuruş fark veriyor, bu da muhasebe sistemlerinin yapısına göre kabul edilebilir veya kabul edilemez durumda değerlendiriliyor.

Bazı muhasebeciler bu iskonto hesabının ayrılmamasını ve tutarlardan düşülmesi gerektiğini savunuyor.

Bu durumda da yine aktarım yapılırken ilgili tutarlar öncesinde oluşturulan data set sayesinde gelir ve kdv tutarlarından düşülüyor.

Yani sonuç olarak, Entegrasyon kavramı sadece bir noktadan başka bir noktaya veri taşımak değildir, aynı zamanda verinin ne şekilde taşınacağına da karar vermektir.