Tekliften Siparişe, Siparişten Faturaya Belge Dönüşümü

Teklif, sipariş, irsaliye ve fatura aynı verinin dört aşamasıdır; doğru kurulmuş yazılımda biri diğerinden elle kopyalanarak değil, ona bağlanarak oluşur. Bağ kurulmazsa aynı satır dört kez yazılır, dördünde farklı bir hata yapılır ve sonradan hangi faturanın hangi siparişten doğduğu bulunamaz. Dönüşümün tek kuralı şudur: veri bir kez girilir, sonraki belge kaynağına referansla üretilir.

Dört belge, dört ayrı iş

Belgeler birbirinin kopyası değildir; her biri farklı bir soruyu cevaplar. Teklif bir öneridir, bağlayıcı değildir ve stoğu etkilemez. Sipariş karşılıklı bir taahhüttür; stoğu rezerve eder ama mülkiyeti devretmez. İrsaliye malın fiilen çıktığını gösterir ve stoğu düşürür. Fatura ise borcu doğurur ve cari hesabı etkiler.

Bu ayrım yazılımda tek bir belge tipine indirgenirse süreç bilgisi kaybolur: teklif aşamasındaki bir satır sipariş gibi stok rezerve eder ya da sevk edilmemiş mal borç yazar. Hangi belgenin neyi hareketlendirdiği baştan yazılı olmalıdır.

Teklifin ayrı bir özelliği de revizyondur. Aynı müşteriye verilen ikinci teklif, birincinin üzerine yazılmak yerine yeni bir sürüm olarak tutulur; hangi sürümün onaylandığı ve siparişe dönüştüğü sonradan sorulacak bir bilgidir. Sürüm tutulmayan yazılımda onaylanan teklif ile basılan teklif arasındaki fark kanıtlanamaz. Aynı mantık siparişte de geçerlidir: miktar ya da fiyat değişikliği kaydın üzerine sessizce yazılmaz, değişiklik geçmişi belgeye bağlı kalır.

Hangi alan nereye gider

Tablodaki en çok atlanan satır müşteri bilgisidir. Fatura, müşteri kartına bakarak değil belgenin kesildiği andaki bilgiye bakarak basılmalıdır; unvan altı ay sonra değiştiğinde eski faturanın yeni unvanla yazılması istenmez. Bu yüzden belge, karta referans tutar ama basılacak alanları kendi içinde saklar.

Dönüşümde değişmesine izin verilen alanlar

Her alanın serbestçe değiştirilebildiği bir dönüşüm, zinciri anlamsız kılar. Pratikte üç grup vardır:

• Taşınır ve kilitlenir: belge numarası, kaynak belge referansı, müşteri kimliği. Bunlar dönüşümde değişmez.
• Taşınır ama azaltılabilir: miktar. Sevk edilen ya da faturalanan miktar sipariş miktarını aşamaz; aşması gerekiyorsa yeni bir sipariş satırı açılır.
• Taşınır ve yetkiyle değişebilir: fiyat, iskonto, vade. Değişiklik kimin yaptığı ve gerekçesiyle kayda geçer; iz kaydı bu değişikliği sonradan göstermelidir.

Fiyat alanını serbest bırakan bir yazılımda teklif ile fatura arasındaki fark hiç kimseye görünmez. Yetki kademeleri ve onay akışı kurulduğunda ise fark ya onaylanmış olur ya hiç oluşmaz; onay düzeninin genel çerçevesi onay akışı yazısında duruyor.

Kalan miktar takibi

Dönüşüm çoğu zaman bütün hâlinde olmaz: siparişin bir kısmı sevk edilir, bir kısmı faturalanır. Bu yüzden her sipariş satırı dört sayıyı birlikte taşır: sipariş miktarı, sevk edilen, faturalanan ve kalan. Kalan miktar elle güncellenen bir alan değil, bağlı belgelerden hesaplanan bir sonuç olmalıdır.

Kalan sıfıra indiğinde satır kapanır; satırların hepsi kapandığında belge kapanır. Belgeyi elle kapatma yetkisi ayrı tutulur ve gerekçe ister, çünkü kapatılan satır bir daha faturalanmayacak demektir. Açık kalan satırların listesi, hem müşteriye verilen sözün hem de henüz kesilmemiş faturanın takibidir.

Kalan miktarın hesaplanması iptal edilen belgeleri de doğru ele almalıdır: iptal edilmiş bir irsaliye kalan miktarı eski hâline döndürür. Bu geri dönüşün otomatik olmadığı yazılımlarda açık sipariş listesi zamanla gerçeği göstermez ve depo elindeki işi listeden değil hatırlayarak yapmaya başlar.

Belge zinciri ve iptal

Her belge kendisini doğuran belgeye işaret eder; böylece faturadan siparişe, siparişten teklife geri gidilebilir. Zincir iki yönlü olmalıdır: siparişten de hangi faturaların doğduğu görülmelidir. Bu bağ olmadan iade, iptal ve mutabakat işleri elle eşleştirmeye kalır.

İptal kuralı da zincire bağlıdır: kendisinden başka bir belge doğmuş olan belge silinmez. Sipariş faturalanmışsa sipariş silinmez; fatura iptal belgesiyle kapatılır, sipariş ise iptal durumuna alınır. Resmî belge tarafının teknik akışı e-belge entegrasyonu yazısında ayrıca ele alındı.

Kısa kontrol listesi

• Fatura siparişe referansla mı oluşuyor, yeniden girilerek mi?
• Belgede basılan müşteri bilgisi o anın değeri olarak saklanıyor mu?
• Miktar artışı yeni satır açmayı mı gerektiriyor, yoksa serbest mi?
• Fiyat ve vade değişikliği yetkiye ve gerekçeye bağlı mı?
• Kalan miktar hesaplanıyor mu, elle mi yazılıyor?
• Her belge tipi kendi numara serisini mi kullanıyor?
• Kendisinden belge doğmuş kayıt silinmeye karşı korunuyor mu?

KAV Yazılım, teklif ve sipariş akışını işletmenin belge düzeniyle birlikte kurar; dönüşüm kuralları yazılımın içinde tanımlı olur, kullanıcının dikkatine bırakılmaz.