Satış nasıl kaydedilir

Bir satış kaydettiğinizde neyi oluşturuyorsunuz

Skyline Nexus'ta bir satış, işlemler tablosunda türü sell olan bir satır, buna bağlı bir dizi satış satırı ve sıfır ya da daha fazla ödeme kaydından oluşur. Bu üçü bilerek birbirinden ayrı tutulur. Fatura, müşteriden olan alacak hakkıdır. Satırlar, raftan çıkan mallardır. Ödemeler, gelen paradır. İnsanların bir ERP'de satışlarla yaşadığı karışıklığın çoğu, bu üçünü tek bir olay gibi ele almaktan kaynaklanır; çünkü bir mağaza tezgâhında genellikle aynı saniyede gerçekleşirler.

Muhasebe açısından ise aynı olay değildirler. Fatura hasılat ve alacak doğurur. Satırlar stoğu azaltır ve satışların maliyetini oluşturur. Ödeme alacağı kapatır ve nakdi hareket ettirir. Vadeli satış yaparsanız ödeme haftalar sonra gelir ve arada alacak bilançoda durur. Avans alırsanız para, fatura daha oluşmadan gelir. Sistem bunların hepsini modeller; çünkü hepsi gerçek işletmelerde yaşanır.

Dolayısıyla bir satış kaydederken pratik soru yalnızca hangi düğmelere basılacağı değildir. Soru şudur: bu üç şeyden hangisini şu anda oluşturuyorum ve hangisini bilerek henüz oluşturmuyorum? Cevabı neredeyse tamamen formdaki tek bir alan belirler: aşağıda ele alınan “Durum” alanı.

Aynı belgeye açılan üç kapı

Sol menüde “Satış” adlı bir açılır menü bulunur. Altında, hepsi sonunda aynı tür belgeyi yazan, yalnızca formun ne kadarını gösterdikleri ve ne kadar hızlı doldurulabildikleri bakımından farklılaşan birkaç giriş vardır.

Tamamlanmış belgeler, hangi kapıdan girmiş olursanız olun “Tüm satışlar” (/sells) altında listelenir. Taslakların ve tekliflerin kendi listeleri vardır, “Taslakları Listele” (/sells/drafts) ve “Teklifleri listele” (/sells/quotations); çünkü bunlar henüz gerçek fatura değildir ve satış listesini kalabalıklaştırmamalıdır. Satış noktası fişleri de ayrıca “POS Listesi” (/pos) altında görünür.

Bazı davranışları açıkladığı için bilinmeye değer bir uygulama ayrıntısı: Satış Ekle formu, POS ekranıyla aynı denetleyiciye gönderilir. Bunlar tek bir kaydetme rutininin üzerindeki iki ayrı ön yüzdür. Hangi ekrandan başlarsanız başlayın vergi kurallarının, stok kurallarının ve deftere işlemenin aynı olmasının nedeni budur; bir POS fişi ile bir Satış Ekle faturasının muhasebe tarafından farklı ele alınmasını beklememeniz gerektiğinin nedeni de budur.

• “POS” (/pos/create) dokunmatik öncelikli tezgâh ekranıdır. Tek müşteri, bir ürün ızgarası, bir ödeme paneli; birkaç saniyede tamamlanır. Perakende, restoran ve her türlü tezgâh üstü satış için doğru kapıdır.
• “Satış Ekle” (/sells/create) tam fatura formudur. Her alan görünürdür: fatura şeması, para birimi, ödeme vadesi, sevkiyat, özel alanlar, birden fazla ödeme satırı. İşletmeden işletmeye bir fatura, teslimata dayalı bir satış ya da vadeli her işlem için doğru kapıdır.
• “Doğrudan satış” (/sells/direct/create), sade faturalar için Satış Ekle ekranının kısaltılmış bir sürümüdür.
• “Taslak Ekle” (/sells/create?status=draft) ve “Teklif Ekle” (/sells/create?status=quotation) yine aynı formdur; yanlışlıkla kesinleştiremeyesiniz diye durum önceden ayarlanmış olarak açılır.
• “Satış Siparişi Ekle” (/sells/create?sale_type=sales_order), daha sonra faturalanacak bir müşteri siparişini kaydeder. Yalnızca POS ayarlarında satış siparişleri açık olduğunda görünür.

Satış Ekle ekranını doldurmak

İlk kart “Satış ayrıntıları” kartıdır. “Şube Seç” zorunludur ve süs değildir: satışın hangi stoktan düşeceğini, hangi fatura numaralandırma serisinin kullanılacağını, hangi ödeme hesaplarının sunulacağını ve e-fatura düzenliyorsanız satışın bildirilip bildirilmeyeceğini belirler; çünkü e-fatura lokasyon bazında etkinleştirilir. “Fatura şeması”, faturanın alacağı numarayı belirler. “Satış Tarihi” belgenin muhasebe tarihidir ve varsayılan olarak şu andır. “Fatura Para birimi” ve “SAR döviz kuru” alanları yalnızca dövizli satış yapılandırılmışsa görünür.

“Fatura No.” alanına ulaşmak bilerek zorlaştırılmıştır. Yalnızca fatura numarası düzenleme yetkisine sahip kullanıcılara ve yalnızca belge taslak durumundayken, “Otomatik olarak oluşturmak için boş bırakın” yardım metniyle birlikte gösterilir. Doğru tasarım budur. Bir kasiyerin üzerine yazabildiği bir fatura numarası bir seri değildir ve bozuk bir seri, bir vergi denetçisinin ilk fark ettiği şeydir.

Müşteri kartı, cariyi ve “Ödeme vadesi” alanını alır; bu alan bir sayı ile “Ay” ya da “gün” birimi olarak girilir. Bu ekranda ayrı bir vade tarihi alanı yoktur: vade tarihi ödeme vadesinden türetilir ve alanı boş bırakırsanız müşterinin kendi varsayılan ödeme vadesi kullanılır. Ödeme vadelerini her faturada değil müşteri kaydında tanımlamanın beş dakikaya değmesinin nedeni budur.

Neredeyse her şeyi durum belirler

Satış Ekle ekranındaki “Durum” alanı “Final”, “Taslak”, “Teklif” ve “Proforma” seçeneklerini sunar. Formdaki en sonuç doğurucu alandır; çünkü sonraki davranışların neredeyse tamamı ona bağlıdır.

Taslak kuralının bilinçli bir istisnası vardır ve sizi şaşırtmadan önce bilmeniz iyi olur. POS ayarları altında, “Taslak faturalar için stoktan düş” etiketli bir işletme ayarı, saf taslakların kaydetme anında stoğu azaltmasını ve satış, kâr, satışların maliyeti ve nakit akışı raporlarında tamamlanmış bir peşin satışla tamamen aynı şekilde sayılmasını sağlar. Varsayılan olarak kapalıdır ve üründeki yardım metni bunu açıkça söyler. Yalnızca taslakları gerçekten toplama (sevk hazırlığı) belgesi olarak kullanıyorsanız açın ve bu durumda taslakları finansal olarak gerçek kılmış olduğunuzu bilin.

Pratik kural: mallar gittiyse ve müşteri size borçluysa durum Final'dir. Aksi hâlde bir işlem değil, bir niyet kaydediyorsunuz. Taslağı, endişe ettiğiniz bir hatadan kaçınmanın yolu olarak kullanmayın; çünkü hiç kesinleştirilmeyen bir taslak, hiçbir yerde görünmeyen bir satıştır.

• Final gerçek bir faturadır. Stoğu azaltır, ödeme kabul eder, genel deftere işlenmeye uygundur ve e-faturanın etkin olduğu yerlerde vergi idaresine bildirilir.
• Taslak, üzerinde çalışılan bir belgedir. Deftere işlenmez ve ödeme kabul etmez: kaydetme rutini, durumu taslak, teklif ya da proforma olan bir satış için ödeme kaydı yazmayı reddeder. Varsayılan olarak stoğa da dokunmaz.
• Teklif bir tekliftir. Hiçbir şey hareket etmez. Stok yok, defter kaydı yok, ödeme yok.
• Proforma, faturadan önce düzenlenen bir belgedir. Teklif gibi hiçbir şeyi hareket ettirmez.

Satışta vergi nasıl hesaplanır

Vergi bir satışa iki düzeyde girebilir ve aradaki fark önemlidir. Satır vergisi, tek bir ürün satırına bağlı bir vergi oranıdır. Sipariş vergisi ise ürün ızgarasının altındaki “Sipariş Vergisi” alanında seçilen ve belgenin bütününe uygulanan tek bir orandır. Çoğu işletme birini ya da diğerini kullanır. Aynı belgede ikisini birden kullanmak, başka sistemlerde insanların başının derde girdiği yerdir ve Skyline Nexus tam olarak bu hatayı önlemek üzere kurulmuştur.

Sipariş vergisi, kendi satır vergisini zaten taşıyan satırları hariç tutan bir matraha uygulanır. Kendi oranı belge oranına eşit olan bir satır, belge vergisi matrahına hiçbir katkı yapmaz. Açıkçası: sistem KDV üzerine KDV hesaplamaz ve belge oranıyla zaten vergilendirilmiş bir satırı iki kez vergilendirmez. Bu, fatura toplamı rutinindeki bir hesaplama kuralıdır; işaretlemeyi hatırlamanız gereken bir ayar değildir.

Bir fiyatın vergi dahil mi hariç mi verildiği faturanın değil, ürünün bir özelliğidir. Ürün formunda “Dahil” ve “Hariç” seçeneklerine sahip “Satış fiyatı vergi türü” adlı bir alan bulunur. Satır daha sonra her iki rakamı da, yani vergi öncesi birim fiyatı ve vergi dahil birim fiyatı saklar; böylece fatura yeniden hesaplama yapmadan ikisinden birini gösterebilir. Satış formundaki satır bazlı vergi seçicisi yalnızca işletme için satır içi vergi açıksa görünür; kapalıysa vergi üründen ve sipariş vergisi alanından gelir.

Yuvarlama, faturaya özgü bir karar değil, bir işletme ayarıdır. Varsayılan, her satırı yuvarlayıp yuvarlanmış rakamları toplamak yerine tam hassasiyetle toplamak ve faturayı en sonda bir kez yuvarlamaktır. İki yöntem uzun bir faturada ara para biriminin birkaç birimi kadar farklılaşır; bu, müşteri için önemsizdir, ama defterle mutabık olması gereken bir KDV beyannamesi için son derece önemlidir.

Ödeme, faturadan ayrı bir kayıttır

Formun altındaki “Ödeme ekle” kartı isteğe bağlıdır. Her ödeme satırı “Tutar”, “Ödendi”, “Ödeme Yöntemi” ve “Ödeme Hesabı” alanlarını, ayrıca isteğe bağlı bir “Ödeme notu” alanını ister. “Ödeme Satırı Ekle”, tek bir faturayı birkaç ödeme aracına bölmenizi sağlar; müşteri bir kısmını nakit, bir kısmını kartla ödediğinde istediğiniz de budur. Satırların altında “Toplam Ödenecek”, “Toplam Ödeme”, “Para üstü” ve “Bakiye” yer alır.

Satış vadeliyse “Veresiye satış — tutarın tamamı ödenecek” kutusunu işaretleyin. Bu, ödeme tutarını sıfırlar, ödeme satırlarını gizler ve kaydetme rutinine ödeme kaydı oluşturmayı tamamen atlamasını söyler. Fatura düzenlenir, alacak yerinde durur ve para daha sonra tahsil edilir. Vadeli satışı kaydetmenin doğru yolu budur; sıfır tutarlı bir ödeme satırı girmek değildir.

Belgedeki ödeme durumu yazılmaz, türetilir. Alınan toplam en az fatura toplamı kadarsa ödenmiş, bir kısmı alınmış ama tamamı alınmamışsa kısmi, hiçbir şey alınmamışsa vadesi gelen olarak görünür. Bu türetme, bir ödeme her eklendiğinde, düzenlendiğinde ya da silindiğinde yeniden çalışır; sonraki ödemeleri faturayı düzenleyerek değil, satış listesindeki “Ödeme ekle” işlemiyle (/payments/add_payment/{id}) tahsil etmeniz gerekmesinin nedeni budur. Rakamları tutturmak için faturayı düzenlemek yanlış bir içgüdüdür ve işlemlerin iptali ile düzeltilmesine ilişkin rehberde ele alınmıştır.

Satışın stoğa etkisi

Bir satış Final olarak kaydedildiğinde her satır, ilgili ürün varyasyonunun o işletme lokasyonundaki kullanılabilir miktarını azaltır. Stok takibi yapılmayan ürünler atlanır: stok yönetimi kapalı olan bir ürün için azaltma rutini hiçbir şey yapmaz; hizmet ve işçiliği aynı ekrandan negatif stok oluşturmadan satabilmenizin yolu budur.

Ardından, insanların nadiren gördüğü ama bilmesi gereken ikinci bir adım çalışır. Satılan her miktar, geldiği belirli satınalma satırlarına karşı eşleştirilir ve bu eşleştirme saklanır. Satışların maliyetini tahmini değil gerçek kılan bu eşleştirmedir: sistem hangi maliyetle yapılan hangi satınalmanın hangi satışı karşıladığını bilir. Parti ve son kullanma kurallarını uygulayan ve fazla satışa izin verilmeyen yerlerde yazılımın fazla satışı reddetmesini sağlayan da budur.

Bu eşleştirme satış anında kurulduğu için, haftalar sonra, o arada hareket etmiş bir stoğa karşı kaydedilen bir satış, zamanında kaydedilseydi olacağından farklı eşleşir. Bu bir hata değil, aritmetiktir ve satışları gerçekleştikleri gün kaydetmenin en güçlü pratik gerekçesidir.

Genel deftere ne işlenir

Final bir satış dahili bir olay tetikler ve muhasebe modülü bu olayı dinler. Her şey yapılandırılmışsa bu dinleyici bir yevmiye kaydı yazar. Kayıt, alacaklar kontrol hesabını fatura toplamının tamamıyla borçlandırır, hasılatı net tutarla ve hesaplanan KDV hesabını vergiyle alacaklandırır. Kategorilerin kendi hasılat hesapları olduğu yerlerde hasılat ürün kategorisine göre bölünür; böylece hem mal hem hizmet satan bir işletme, hiçbir manuel analiz yapmadan bunları gelir tablosunda ayrı ayrı görebilir.

Üç koşulun tamamı sağlanmalıdır, aksi hâlde hiçbir şey işlenmez; defterin bozuk olduğu sonucuna varmadan önce üçünü de kontrol etmeye değer. Birincisi, satış Final olmalıdır. Taslaklar, teklifler ve proformalar tasarım gereği atlanır. İkincisi, işletmenin /accounting/settings adresindeki muhasebe ayarlarında “Satış işlemlerini otomatik deftere işle” seçeneği açık olmalıdır. Üçüncüsü, hesaplar eşleştirilmiş olmalıdır: /accounting/settings/mapping adresinde yapılandırılan bir alacak hesabı, bir hasılat hesabı ve bir hesaplanan KDV hesabı. Eksik bir eşleştirme hiçbir şeyi bozmaz, yalnızca kaydı işlemeyi reddeder.

Ay sonunda insanları yakalayan dördüncü bir kapı daha vardır: satış tarihini kapsayan mali dönem açık olmalıdır. Dönem kapatılmış ya da kilitlenmişse kayıt, kapalı bir aya sessizce geriye dönük işlenmek yerine reddedilir. Doğru davranış budur ve bir dönemi kapatmanın bütün amacı da budur; ancak bu, kilitli bir aya tarihlenmiş bir satışın deftere ulaşması için dönemin yeniden açılması ya da tarihin düzeltilmesi gerektiği anlamına gelir.

Uygulandığı yerde e-fatura

Suudi Arabistan'da e-fatura modülü, bir satış Final olarak kaydedildiğinde faturayı otomatik olarak oluşturur ve bildirir. İşletmenin tamamı için değil, işletme lokasyonu bazında etkinleştirilir; böylece bir şirket bir lokasyonunu e-fatura rejimi altında çalıştırırken diğeri henüz kayıtlı olmayabilir. Yapılandırma /zatca/configuration adresindedir.

Bildirim idempotenttir: sistem neyin zaten bildirildiğini kaydeder ve aynı faturayı iki kez bildirmez. Bir bildirim başarısız olursa satış yine de kaydedilir. Bu bilinçli bir tercihtir; çünkü vergi idaresinin uç noktasına ulaşılamadığı için bir satışı kaybetmek, onu birkaç dakika geç bildirmekten çok daha kötü olurdu. Başarısız bir bildirim satışın kendisinden yeniden gönderilebilir.

Bir fatura bildirildikten sonra düzenlemeye kilitlenir. Sistemin verdiği mesaj açıktır: fatura zaten bildirilmiştir ve artık düzenlenemez; düzeltmek için bir alacak notu ya da borç notu düzenlemeniz gerekir. Bu, yazılımın zorluk çıkarması değildir. Bildirilmiş bir fatura artık vergi idaresinin elinde bulunan bir belgedir ve onu değiştirmenin tek yasal yolu başka bir belgedir.

Kaydettikten sonra

Satış, fatura numarası, müşterisi, toplamı, ödeme durumu ve ilgiliyse e-fatura durumuyla birlikte “Tüm satışlar” listesinde görünür. Satır menüsünden onu görüntüleyebilir, yazdırabilir, ödeme ekleyebilir, ödemelerini görebilir ya da ona karşı bir iade başlatabilirsiniz. /sells/show/{id} adresindeki ayrıntı görünümü satırları, vergi dökümünü ve ödeme geçmişini tek bir yerde gösterir; biri size belirli bir faturada ne olduğunu sorduğunda açmanız gereken ekran budur.

Müşterinin bakiyesi satıştan sonra yeniden hesaplanır; böylece alacak hemen müşteri hesap ekstresinde ve alacak yaşlandırmasında görünür. Deftere işleme açık ve yapılandırılmışsa aynı rakamlar muhasebe modülü aracılığıyla mizanda ve bilançoda da görünür. İkisi tutmuyorsa olağan neden, aritmetik bir hata değil, yukarıdaki üç işleme kapısından biridir.

Kısa bir kontrol listesi

• Lokasyon doğru mu? Stoğu, numaralandırmayı, ödeme hesaplarını ve e-faturayı o belirler.
• Durum Final mi? Başka herhangi bir durum henüz satış değildir.
• Satış tarihi, onu yazdığınız tarih değil, satışın fiilen gerçekleştiği tarih mi?
• Müşteri ödeme yapmadıysa, sıfır tutarlı bir ödeme satırı yerine “Veresiye satış — tutarın tamamı ödenecek” işaretli mi?
• Vadeli satışsa, faturanın doğru yaşlanması için ödeme vadesi tanımlı mı?
• Vergi rakamları, kaydettikten sonra değil, kaydetmeden önce toplamlar şeridinde doğru görünüyor mu?