Satış Siparişi Yönetimi

Kabul edilen teklif ikinci kez yazılmasın.

GERÇEK SORUN

Teklif kabul edildi, sonra ne oldu

Teklif onaylandı, müşteri “gönderin” dedi. Çoğu şirkette sonrası e-posta ve telefonla yürüyor. Teklifteki kalemler bir sipariş formuna elle yeniden yazılıyor, bir kalem eksik giriliyor, fiyat teklifin ikinci revizyonundan değil birincisinden alınıyor.

İkinci sorun kısmi sevkiyat. Yüz adetlik sipariş üç parti halinde gidiyor; kaçının gittiği, kaçının kaldığı bir Excel’de tutuluyor. İki kişi aynı dosyayı açınca rakam ikiye katlanıyor.

Üçüncüsü kavram karışıklığı. Aynı şirkette “sipariş” kelimesi hem tedarikçiye verilen siparişi hem müşteriden alınan siparişi anlatıyor. İkisi aynı tabloda tutulunca hangisinin ne olduğu her seferinde sorulmak zorunda kalıyor.

TEKLİFTEN SİPARİŞE

Sipariş numarası geldiği teklifi taşıyor

Onaylanan teklifte “Siparişe Dönüştür” deniyor, bütün kalemler, iskontolar ve tutarlar siparişe geçiyor. Kimse tabloyu yeniden yazmıyor. Teklif tarafının kendisi satış teklifi hazırlama sayfasında.

Dönüşürken bir sipariş şablonu seçiliyor. Şablon teklif tarihinden sonra güncellendiyse sistem bunu söylüyor ve ayrıca onay istiyor; araya giren bir şablon değişikliği sessizce uygulanmıyor.

Tekliften dönen siparişin numarası, teklif numarasının önüne bir önek alarak oluşuyor. Sipariş numarasına bakan kişi hangi tekliften geldiğini görüyor, ayrıca sormuyor. Doğrudan açılan siparişte kendi günlük serisi kullanılıyor.

Dönüşen teklif kilitleniyor ve bu kilit dört şeyi birden kapatıyor: durumu değiştirilemiyor, güncellenemiyor, silinemiyor, revizyon alınamıyor. Kartta o dört buton pasifleşiyor. Bu durumu kullanıcı elle de seçemiyor, yalnızca gerçekten siparişe dönüşünce oluşuyor. Siparişe dönmüş teklif artık bir belge; geriye dönüp değiştirilemiyor.

Şablonlar sipariş türüne göre ayrılıyor: normal, ihraç kayıtlı, KDV muafiyetli, proforma, döviz ve ihracat. Her tür için şablon oluşturuluyor, yeni sürüm çıkarılıyor, varsayılan yapılıyor.

DURUM

Dört durum, bir zorunlu sebep

Sipariş dört durumdan birinde: onayda, onaylandı, revizyonda, reddedildi. Tekliften dönen sipariş onayda doğuyor.

Reddederken sebep zorunlu. Teklif tarafındaki sebep listesiyle aynı; böylece kaybın nerede yaşandığı sipariş aşamasında da kayda geçiyor.

Revizyon alındığında sipariş yeni bir sürüm oluyor, numarasına sürüm eki geliyor ve eski hâl versiyon geçmişinde duruyor. Siparişin kendi PDF’i, kendi ek belge alanı ve kendi durum tarihçesi var; teklifle aynı kalem ve hesap yapısını taşıyor.

Dürüst bir sınır: sipariş tarafında durum geçiş kuralı yok. Her durumdan her duruma geçilebiliyor, kilitlenen durum yok. Fırsat modülündeki “şu aşamaya geçmek için şu alan dolu olmalı” kurgusu burada yok. Ayrı bir sipariş iptali işlemi de yok; karşılığı sebebi zorunlu “reddedildi” durumu.

SEVKE HAZIR

Kamyon ikonuna basılan an

Siparişi asıl ayıran şey “sevk edilebilir” işareti. Bu işaret siparişin kalemlerini lojistik tarafının planlama ekranına düşürüyor; satışla sevkiyat arasındaki kapı burası.

İşaret yalnızca “onaylandı” durumundaki siparişte konulabiliyor, başka durumda buton pasif ve ipucu bunu söylüyor. Açılan formda sevk ülkesi zorunlu, il ve planlanan sevkiyat tarihi giriliyor, teslim alacak kişiler ad ve telefonla yazılıyor, sevkiyat notu ekleniyor. Planlanan tarih siparişin bütün kalemlerine işleniyor.

Formun üstünde teklifte söz verilen teslimat süresi, teslimat yeri ve adres bilgi olarak duruyor. Sevk bilgisini giren kişi, müşteriye ne söz verildiğini aynı ekranda görüyor.

Bir de “Sevk Onay Geçmişi” sekmesi var: işaret ne zaman, kim tarafından, hangi bilgilerle kondu; kaldırıldıysa o da kayıtlı. İşareti kaldırmak onay soruyor.

Sonrası sevkiyat ve nakliye yönetimi sayfasında anlatılıyor.

KISMİ SEVKİYAT

Kalan miktar saklanmıyor, hesaplanıyor

Bu, anlatmaya değer bir tasarım kararı.

Bir kalemin ne kadarının sevk edildiği bir sayaç olarak tutulmuyor. Her sevkiyatın o kalemden çektiği miktar ayrı bir satır olarak kaydediliyor ve sevk edilen toplam her zaman bu satırların toplamı. Kalan miktar hiçbir yerde saklanmıyor, her seferinde hesaplanıyor.

Pratik sonucu şu: aynı sevkiyat iki kez işlense miktar şişmiyor. Sevkiyat iptal edilince satır düşüyor, toplam kendiliğinden düzeliyor. “Kalan” ile “sevk edilen” birbirini tutmuyor diye bir durum oluşmuyor, çünkü ikisi aynı defterden okunuyor.

Kalem listesi hiç sevk edilmemiş ve kısmen sevk edilmiş diye süzülebiliyor. Sipariş sonradan düzenlendiğinde de sevkiyat bilgisi korunuyor; kalemler yeniden yazılırken sevk edilen miktar ve planlanan tarih ürün eşleşmesiyle taşınıyor.

HESAP VE KUR

Ekranda gördüğünüz toplam, kaydedilen toplam

Sunucu tarayıcıdan gelen toplamlara güvenmiyor. Kaydederken iskonto, toplam, KDV, ağırlık, maliyet ve kâr alanlarını kendisi yeniden hesaplayıp yazıyor. Ekrandaki anlık hesapla sunucunun hesabı aynı kod olduğu için ikisi arasında fark çıkmıyor.

Döviz kurları Merkez Bankası’ndan çekiliyor, alış ve satış ayrı. Sipariş kaydedilirken o anki kur belgenin içine yazılıyor; belge sonradan açıldığında kur değişmiş olsa bile tutar kaymıyor. Çalışan para birimleri Türk lirası, dolar ve euro.

PANO

Onay bekleyen, revizyondaki, sevke hazır

Sipariş panosunun iş listesi bileşenleri üç tane: onay bekleyen siparişler, revizyondaki siparişler, sevkiyata hazır siparişler. Satış müdürünün her sabah baktığı üç liste.

İstatistik tarafında sipariş özeti, günlük ve aylık dağılım, satış temsilcisine göre dağılım, en çok sipariş veren firmalar ve Türkiye haritası üzerinde il dağılımı var.

Bir nüans: sipariş istatistikleri yalnızca onaylanmış siparişleri sayıyor. Onayda bekleyen sipariş rakama girmiyor. “Bu ay kaç sipariş aldık” sorusunun cevabı “kaç sipariş onaylandı”.

Tedarikçiye verilen sipariş ayrı bir modül ve sipariş süreci sayfasında anlatılıyor. O sayfa satın alma, bu sayfa satış.

KİMİN İÇİN

Bu modül kime uygun

Teklifle satan ve siparişi parça parça sevk eden şirketler için. Üretici, ithalatçı ve proje bazlı satış yapan yapılar bu tanıma giriyor; ihracat yapanlarda tür bazlı şablonlar ayrıca işe yarıyor.

Raf ürünü satan, siparişi tek seferde teslim eden işlerde bu kurgu gereğinden geniş kalıyor. Sipariş kartındaki görüşmeler sekmesi görüşme ve takip yönetimi sayfasında, zincirin bütünü CRM ve satış yönetimi sayfasında anlatılıyor. Hangi paketin neyi kapsadığı ürünler sayfasında.

SIK SORULANLAR

Sık sorulan sorular

Teklif olmadan sipariş açabiliyor muyuz?

Açabiliyorsunuz. Doğrudan açılan sipariş kendi günlük numara serisini kullanıyor; tekliften dönen sipariş ise teklif numarasını taşıyor.

Siparişe dönüşen teklifi sonradan değiştirebiliyor muyuz?

Hayır. Dönüşen teklif kilitleniyor; durumu, içeriği ve revizyonu kapanıyor. Değişiklik sipariş üzerinde revizyon alınarak yapılıyor.

Siparişi iptal edebiliyor muyuz?

Ayrı bir iptal işlemi yok. Karşılığı “reddedildi” durumu ve sebep girmek zorunlu.

Kısmi sevkiyatta kalan miktarı nereden görüyoruz?

Kalem listesinde. Sevk edilen, her sevkiyatın çektiği miktarın toplamı; kalan her seferinde hesaplanıyor. Liste “hiç sevk edilmemiş” ve “kısmen sevk edilmiş” diye süzülüyor.

Siparişi müşteriye sistemden gönderebiliyor muyuz?

Gönderemiyorsunuz. PDF indirilip yazdırılıyor; e-posta ve WhatsApp gönderimi yalnızca teklif tarafında.

Belirli tutarın üzerindeki sipariş onaya düşüyor mu?

Kutudan çıkan hali bunu yapmıyor. Onay zinciri isteyen müşterilerde projeye özel geliştiriliyor.

Sipariş muhasebe programımıza aktarılıyor mu?

Hayır. Sipariş sevkiyata akıyor, finans tarafına hazır bir bağ yok. Entegrasyon projeye özel yazılıyor.

Dövizli siparişte kur ne zaman sabitleniyor?

Sipariş kaydedildiği anda. Merkez Bankası kuru belgenin içine yazılıyor, sonradan kur değişse de belgedeki tutar kaymıyor.