NetSuite’te Depozito / Avans Tahsilat Yönetimi: 340’tan 120’ye Otomatik Virman, Fatura Kapatma ve Kur Değerleme (Detaylı Rehber)

Birçok şirkette sahada gördüğümüz standart senaryo şu:

• Müşteriden önce ödeme (depozito/avans) geliyor.

• Muhasebe bu tahsilatı 340 (Alınan Sipariş Avansları / Depozitolar) benzeri hesaplarda tutuyor.

• Sonra satış faturası kesilince bu avansı 120 (Alıcılar) tarafına virmanlayıp faturayla kapatmak gerekiyor.

• Kur farkı olan işlemlerde iş daha da uzuyor:

  tahsilat kuru, fatura kuru, ay sonu değerleme kuru ve oluşan farklar…

Bu yazıda NetSuite tarafında bu yapıyı sürdürülebilir ve otomatik hale getirmenin mantığını, muhasebe etkisini ve kurguyu adım adım anlatıyorum.

1) İşin Muhasebe Mantığı: Neyi, Ne Zaman, Hangi Kurla Taşıyoruz?

Bu yapıda 3 temel olay var:

A) Depozito/Avans Tahsilatı Geldiğinde

• Para bankaya girer.

• Muhasebe etkisi (örnek):

  • 102 Banka (Borç)

  • 340 Avanslar (Alacak)

NetSuite’te bu “Customer Deposit / Customer Payment” gibi standart akışlarla yapılabilir; ancak bazı şirketlerde süreç/kurgu/yerel ihtiyaç nedeniyle bu avans “prepayment” gibi standart modülle değil, manuel/entegrasyonla 340’a alınmış olabilir. Sizdeki senaryo da bu: mevcut düzeni bozmayacağız.

B) Fatura Kesildiğinde

Fatura GL etkisi genellikle:

• 120 Alıcılar (Borç)

• 600/391 vb. (Alacak)

Ama burada “müşteri zaten ödemişti” dediğimiz noktaya geliyoruz. Yani 120’de alacak oluştu ama tahsilat 340’ta bekliyor.

Çözüm:

Fatura kesildiği an, 340’taki avansın fatura tutarı kadar kısmını 120’ye virmanlamak.

Muhasebe virman kaydı:

• 340 (Borç)

• 120 (Alacak)

Bu kayıt sonrası 120’de fatura borcu ile 120’ye gelen “alacak virman” birbirini kapatabilecek hale gelir.

C) Faturayı Kapatma (Apply / Match)

Son adımda NetSuite’te faturanın kapatılması gerekir. İki yöntem vardır:

1. Payment üzerinden faturayı kapatmak (Apply)

2. Journal ile kapatmak (NetSuite’de “Journal Apply” mantığı – hesap türleri ve ayarlara bağlı)

Sizin ihtiyacınız “otomatik” olduğu için tipik yaklaşım:

• Fatura oluşunca virman jurnalını üret,

• Ardından “apply” işlemini otomatikleştir (script ile) veya yapıyı “fatura ödeme eşleştirmesi” şeklinde kurgula.

2) NetSuite’te Sağlam Bir Kurgunun Temel Taşları

Bu işin düzgün çalışması için 4 yapı taşını netleştirmek lazım:

2.1. Depozito / Avansın Faturaya Bağlanma Anahtarı

Sahada en çok hata buradan çıkar.

Bağlantı anahtarı seçenekleri:

• Sales Order numarası

• Fatura üzerindeki sipariş referansı (created from / custom field)

• Müşteri + Proje + Dönem gibi kombinasyon

• External ID (entegrasyon varsa)

Öneri: “fatura üzerinde bulunan sipariş numarası” sizde anahtar gibi duruyor. En sağlamı:

• Tahsilat kaydında (340’a atan) hangi SO / hangi iş / hangi referans olduğunu net tutmak

• Fatura üzerinde aynı referansı taşımak

2.2. GL Hesaplarının Netliği (340/120) ve Çoklu Defter (varsa)

NetSuite multi-book kullanılıyorsa bu virmanın hangi book’ta oluşacağı, hangi subsidiary’de çalışacağı önemlidir.

• 340 ve 120 aynı subsidiary / aynı book mantığında mı?

• Intercompany var mı?

• Tek hesap planı mı, subsidiary bazlı farklı hesap mı?

Bunlar net değilse script doğru jurnal üretse bile “kapanış” tarafında muhasebe itirazı gelir.

2.3. Para Birimi ve Kur Mantığı

Kur farkı konusu ikiye ayrılır:

• İşlem anındaki kur (tahsilat, fatura)

• Ay sonu değerleme kuru (revaluation)

Bunları ayrı ele almak gerekir.

2.4. Otomasyonun “İdempotent” Olması

Bu kelime kritik: Aynı faturaya script 2 kere çalışırsa 2 kere jurnal basmamalı.

Bu yüzden:

• Fatura üzerinde “Virman Oluşturuldu” flag’i

• Oluşan jurnal internal id’si fatura body field’ına yazılır

• Yeniden çalışırsa aynı kaydı bulur, ikinciyi üretmez

3) Otomasyon Akışı: Fatura Kesilince Ne Olacak?

Burada en temiz senaryo:

1. Fatura (Invoice) oluşturulur / onaylanır (status)

2. Script invoice’u yakalar (UE afterSubmit veya Scheduled/MapReduce)

3. Fatura tutarı + para birimi + referans (SO no) alınır

4. İlgili müşterinin 340’ta bekleyen avansları bulunur

5. Toplam avans >= fatura tutarı ise:

   • 340→120 virman journal oluştur

   • Journal’ı invoice’a referansla bağla

   • Apply/Close adımını çalıştır

6. Avans < fatura tutarı ise:

   • Kısmi virman yap (isteniyorsa)

   • Kalan tutar 120’de açık kalsın

   • Uyarı / log / görev üret

   
   

“Avansları bulma” yaklaşımı

Avanslar sistemde nasıl tutuluyor?

• Eğer avanslar “Customer Payment” ile giriliyor ama GL 340’a gidiyorsa, aramada “deposit/prepayment” yerine “payment transaction + GL impact” tarafı incelenir.

• Eğer avanslar “Journal Entry” ile 340’a alınıyorsa, o journal’lar filtrelenir.

• En sağlıklı yöntem: Avansı yaratan kayıtta mutlaka bir “reference field” taşımak (SO No / Project / External Ref).

4) Kapanış İşlemi: Journal ile Fatura Kapanır mı?

Bu sorunun cevabı NetSuite’te “kurguya” bağlı.

• Standart yaklaşım: Payment transaction’ı üzerinden Invoice “apply” edilir.

• Journal doğrudan “apply” edilmez (klasik muhasebe mantığında da jurnal bir ödeme değildir).

  Ancak bazı hesap tipleri ve ayarlarla “Journal Application” benzeri kapatma davranışları kurgulanabilir.

Sizin senaryoda hedef:

• Müşteri ödeme işlemi zaten “340’ta”

• Biz 340’ı 120’ye taşırken ödeme gibi davranmak istiyoruz

  
  

Bu yüzden 2 yaklaşım var:

Yaklaşım 1 (Muhasebe açısından en temiz):

Customer Payment/Deposit’ı doğru mantıkla kullanmak ve invoice apply’ı standarttan yapmak.

Ama siz “mevcut yapıyı koruyacağız” dediğiniz için bunu değiştirmiyoruz.

Yaklaşım 2 (Mevcut yapıya uyumlu):

• 340→120 virman journal üret

• Sonra invoice’u kapatmak için:

  • ya ikinci bir “Customer Payment” yaratıp apply etmek (sanal ödeme)

  • ya da mevcut deposit/payment kaydını invoice’a bağlamak (script ile)

En pratik olan genelde:

invoice oluştuğunda, “application” işlemini otomatik yapan bir script.

5) Kur Değerleme (Revaluation) İşin Neresinde?

Kur değerleme iki yerde karşımıza çıkar:

5.1. Tahsilat ile Fatura Arasındaki Kur Farkı

Örnek:

• Avans 1.1000 kurla geldi

• Fatura 1.1500 kurla kesildi

Burada 340’ta bekleyen tutar ve faturanın 120 etkisi farklı kurdan olduğu için virman sırasında kur farkı doğabilir.

Bu farkın muhasebeleşmesi için 2 seçenek var:

1. Virmanı fatura kurundan yaparsın, aradaki farkı “kur farkı” hesaplarına atarsın

2. Virmanı avans kurundan yaparsın, fatura açık kalır ve kapanışta fark oluşur

Hangi yöntem doğru?

• Şirketin muhasebe politikası + denetim yaklaşımı + yerel uygulamalar belirler.

Türkiye’de pratikte çoğu firma:

• Ödeme ve fatura farklı kurdan ise aradaki farkı kur farkı gelir/gider olarak muhasebeleştirir.

5.2. Ay Sonu Değerleme (Unrealized FX)

Ay kapanışında 120’de açık bakiye varsa değerleme yapılır.

Ama siz otomasyonla faturayı kapatıyorsanız, 120 açık kalmayacağı için değerleme etkisi azalır.

Asıl soru:

• 340 hesabı da dövizli bakiye tutuyor mu?

• Ay sonu 340 için de revaluation gerekiyor mu?

  
  

Eğer 340 dövizli açık bakiye taşıyorsa:

• 340 da revaluation’a tabi olabilir (hesap tipine ve muhasebe yaklaşımına göre)

• NetSuite’te revaluation genelde AR/AP hesaplarına odaklıdır; ama hesap bazlı revaluation kurguları ayrıca ele alınır.

  
  

Bu yüzden iyi bir tasarımda:

• 340’ta dövizli bakiye kalmaması hedeflenir (mümkünse)

• Ya da 340 için de kur değerleme kuralı netleştirilir

6) Kenar Senaryolar (Gerçek Hayatın Zor Kısmı)

Bu otomasyon en çok şu durumlarda patlar; baştan tasarlamak gerekir:

6.1. Kısmi Avans + Kısmi Fatura

• Avans 5.000 USD

• Fatura 8.000 USD

  
  

Ne yapacağız?

• 5.000 USD’lik kısmı 340→120 virman

• Kalan 3.000 USD invoice açık

Bu durumda script:

• “available deposit” mantığıyla kısmi virman yapmalı

• ve bir sonraki tahsilatta kalan kısmı kapatacak şekilde çalışabilmeli

  
  

6.2. Bir Avans ile Birden Fazla Fatura

• Avans tek, faturalar parçalı

Burada avansı “allocation” yapmanız gerekir:

• Avansın kalan bakiyesi izlenmeli

• Hangi faturaya ne kadar gittiği loglanmalı

Genelde bu noktada bir “custom record: deposit allocation ledger” mantığı şart olur.

6.3. İade / Credit Memo

Fatura kesildi, kapandı, sonra iade oldu.

• 340’a geri mi atılacak?

• Müşteriye nakit iade mi?

• Sonraki faturaya mı sayılacak?

Bu senaryoları tasarlamazsanız otomasyon bir ay sonra “muhasebe kabusu” olur.

6.4. Subsidiary / Intercompany

Avans bir subsidiary’de, fatura başka subsidiary’deyse:

• intercompany due to/from gerekir

• düz 340→120 virmanı yetmez

7) Minexa Yaklaşımı: Bu İş Neden “Script Yazdım Bitti” Değil?

Bu tip otomasyonlar sadece kod değil:

• Muhasebe politikası

• Kur yönetimi

• Referans anahtarı tasarımı

• Denetlenebilir kayıt izi (audit trail)

• Hata yönetimi (re-run, rollback, log)

ile birlikte bir “mini ürün” gibi tasarlanmalı.

İyi bir çözümde mutlaka şunlar olur:

• Fatura üzerinde “Avans Bulundu / Virman Yapıldı / Kapatıldı” statüleri

• Oluşan journal ve payment referansları

• Hata olursa kullanıcıya açıklayan log + e-posta bildirim

• Tekrar çalıştırınca çift kayıt basmayan idempotent yapı