Teklif numarasının GÖRÜNÜŞÜNÜ — önek, yıl, uzunluk, ayraç — siz seçersiniz ve istediğiniz zaman değiştirebilirsiniz. Ama SAYAÇ ayrı bir şeydir: formatı değiştirmek geçmiş tekliflerinizi yeniden numaralamaz ve sayacı sıfırlamaz. Üstelik numaraya şube eklemek sayacın kendisini böler, yıl damgası eklemek ise onu yıllık sıfırlanan bir sayaca çevirir. Bu yazı Smartifie Quote'ta bu iki katmanın (şekil / sayaç) neden ayrı tutulduğunu, hangi kararın hangi davranışı tetiklediğini anlatıyor.
Teklif numarasının "şekli" ne demek: önek, yıl, uzunluk, ayraç
Quote'ta bir teklif numarası beş parçadan oluşur: önek (ör. QUO), yıl damgası (yok / 2 hane / 4 hane), sıra numarasının basamak sayısı (3 ile 12 arası), adım (numara her seferinde kaç artacak — 1, 2, 5, 10 veya 100) ve ayraç (tire, eğik çizgi, nokta, alt çizgi veya hiçbiri). Varsayılan şekil şuna benzer: QUO-2026-000001. Ayarlar ekranındaki her alan iki değil ÜÇ durumdan birini taşır: "varsayılanı kullan" (henüz bir seçim yapılmamış, ürünün önerisi bir yer tutucu olarak görünür), "yok" (ör. önek istemiyorum) veya kendi seçtiğiniz bir değer. Bu ayrım önemli: varsayılan değerle doldurulmuş bir form ile hiçbir şey seçilmemiş bir form aynı görünür ama farklı bir şey SÖYLER — biri "şirket QUO-2026-000001'i bilinçli seçti" der, diğeri "şirket henüz karar vermedi, ürünün önerisi geçerli" der. Kaydet'e basana kadar hiçbir şey veritabanına yazılmaz.
Format ile sayaç iki ayrı şeydir: birini değiştirmek diğerini sıfırlamaz
Bu yazının merkezi tezi budur. Quote'un kendi kod yorumu bunu birebir söylüyor: şeklin (NumberScheme) ve sayacın (DocumentNumberSequence) ayrı tutulması bilinçli bir tasarım kararı. Öneki, ayracı veya basamak sayısını değiştirdiğinizde geçmiş teklifleriniz eski numaralarını korur — hiçbiri yeniden numaralanmaz — ve sayaç da geriye alınmaz; yeni teklifler sayacın kaldığı yerden, yalnızca yeni görünümle devam eder. Aynı mantık "ayarları temizle" (Clear) düğmesi için de geçerli: şekli varsayılana döndürür ama sayacı BİLİNÇLİ OLARAK dokunulmadan bırakır, çünkü sayacı da sıfırlasaydı zaten var olan belgelerle çakışan bir numaradan yeniden başlardı ve bir sonraki her kayıt mükerrer-anahtar hatasıyla başarısız olurdu.
Yıl damgası eklemek sayacı YILLIK sıfırlanan bir sayaca çevirir
Yıl damgası bir görünüm ayarı gibi görünür ama aslında sayacın DAVRANIŞINI belirler. Yıl basmamayı seçerseniz (0 hane) sayaç hiç durmadan, yıllar boyunca artmaya devam eder. 2 veya 4 haneli bir yıl eklerseniz, sayaç o yıla özel hale gelir ve her Ocak ayında 1'den yeniden başlar. Bu, veritabanındaki sayaç tablosunun bir sütununa yazılan değerin ta kendisidir — kozmetik bir seçim değil, sayacın hangi sütunda saklandığını belirleyen bir karardır. Pratikte fark şurada ortaya çıkar: yıl damgası açık bir şirkette 2027'nin ilk teklifi QUO-2027-000001 olur, 2026'nın son teklifi kaç numaradaysa ondan bağımsız olarak; yıl damgası kapalı bir şirkette ise sayaç 2026'dan kaldığı yerden (ör. 000847'den) devam eder.
Şube eklemek sayacın kendisini böler, yalnız yazıyı değil
Numaraya bir şube grubu eklediğinizde, tek yaptığınız şey numaranın üzerine bir şube kodu basmak değildir — her şubeye kendi bağımsız sayacını verir. Şube grubu yoksa tek bir kiracı-geneli sayaç tüm şubeler tarafından paylaşılır. Bunun pratikte ne anlama geldiğini bir örnekle gösterelim: İstanbul ve İzmir şubeleri aynı paylaşılan sayacı kullanıyorsa ve İstanbul QUO-2026-000010'u alırsa, İzmir'in bir sonraki teklifi QUO-2026-000011 olur — kendi şube geçmişine göre sıralı görünmez, çünkü sayaç şubeler arasında paylaşılmaktadır. Şube grubu eklenirse bu "zıplama" biter: her şube kendi 1, 2, 3... dizisini görür. Ürünün ayarlar ekranı bunu ayrıca bir uyarı olarak da gösterir, çünkü form üzerinde bu davranışı göstermenin başka bir yolu yoktur.
Teklif numarası yasal bir zorunluluk mu?
Bu soru ülkeye göre farklı cevaplanıyor, ve üçünü de karıştırmadan ayrı ayrı vermek gerekiyor.
İspanya için birincil kaynak net: RD 1619/2012'nin 6.1.a maddesi yalnız FATURA ("factura") için seriler içinde korelatif (sıralı) numaralandırma ister — "la numeración de las facturas dentro de cada serie será correlativa" der. Bu maddenin metninde "presupuesto" (teklif) ya da "factura proforma" (proforma fatura) kelimesi hiç geçmez; yani teklif ve proforma bu yönetmeliğin kapsamı DIŞINDADIR. Bununla birlikte İspanyol muhasebe kaynakları (faconia.com, pymesyautonomos.com) yasal zorunluluk olmasa da proformaya ayrı bir seri verilmesini önerir — gerekçe, aksi halde gerçek faturaların izlenebilirliğinin (trazabilidad) karışabileceği.
İngilizce konuşulan piyasalarda da benzer bir örüntü var: proformanın gerçek faturadan farklı olarak resmî bir numaralandırma rejimi yoktur, ama pratik tavsiye (tinytax.co.uk gibi muhasebe rehberlerinden — bu resmî mevzuat değil, ikincil bir kaynaktır) yine ayrı bir seri kullanmak yönünde, aksi halde bir denetimde gerçek fatura serisinde boşluk ya da mükerrer numara sorunu çıkabileceği söyleniyor.
Türkiye için bu yazıda bir mevzuat maddesi numarası VERMİYORUZ. Teklif bir fatura değildir, dolayısıyla üzerindeki numaranın biçimini kanun değil kendi ihtiyacınız belirler — ama hangi mevzuat maddesinin hangi belgeyi bağladığını burada iddia etmiyoruz, çünkü bu konuda birincil bir kaynağı bu oturumda doğrulayamadık.
Teklif ve proforma neden aynı sayaçtan numara almaz
Quote'ta teklif ve proforma, ayrı bir belge türü anahtarına ve dolayısıyla ayrı bir sayaca sahiptir; varsayılan önekleri QUO ve PI'dir ve ikisi de tüm arayüz dillerinde AYNI kalır (bilinçli olarak çevrilmez — İspanya'ya ihracat yapan bir Türk şirketi belgede Türkçe bir kısaltma istemez). Proformanın kendi numarasını ilk indirmede nasıl kalıcı olarak aldığını ayrı bir yazıda zaten anlattık, burada tekrar etmiyoruz: proformanın kendi numarasını ilk indirmede nasıl aldığı. Bu ayrımın §5'te işlenen "ayrı seri kullanın" tavsiyesiyle örtüştüğünü de eklemek gerekir: teklif ile proforma bu üründe zaten ayrı sayaçlar kullanıyor, dolayısıyla bu konuda ek bir ayar açmanıza gerek yok.
Veri bir yerden bir yere taşındığında sayaç ne olur?
Cihazdan buluta ya da yeni bir kuruluma veri taşındığında sayaç satırı bu taşımaya dahil DEĞİLDİR — yalnız belgeler taşınır. İlk kayıt anında ürün, mevcut belgeler arasında GEÇERLİ şekle (aynı önek ve aynı genişlik) uyan en büyük numarayı arar ve sayacı ORADAN başlatır. Bu arama önemli bir sınır taşır: farklı bir eski şeklin ürettiği numaralar bu aramaya hiç GİRMEZ — yalnız hem önek hem toplam genişlik olarak bugünkü şekle uyan numaralar sayılır. Bunun neden önemli olduğunu ürünün kendi kod yorumu açıkça söylüyor: bu yeniden-tohumlama olmasaydı, geride kalan bir sayaç mevcut belgelerle çakışan bir numaradan başlardı ve her yeni kayıt kalıcı bir mükerrer-anahtar hatasıyla başarısız olurdu — bu ekosistem bunu bir kez yaşamış.
Biz bu tarafta ne yapıyoruz, ne yapmıyoruz
Numara YALNIZ kayıt anında (Kaydet'e basınca) verilir — form açılırken ya da taslak yazılırken değil. Bunun nedeni basit: yarıda bırakılan bir taslak numara "yakmaz", dolayısıyla iptal edilen bir teklif sayaçta bir boşluk açmaz. Adım (Step) 1, 2, 5, 10 veya 100 arasından seçilebilir, ama ilk numara HER ZAMAN 1'dir — adımın kendisi değil; bu, adım 100 seçen bir şirketin ilk teklifinin doğrudan "numara 100" olmasını önler. Ayarlar ekranındaki önizleme numarası canlı hesaplanır ama HİÇBİR ZAMAN saklanmaz — yalnızca bir tahmindir; başka bir kullanıcı önce kaydederse gösterilen numara değişir.
Bir de açıkça söylemek gereken sınır var: sipariş (Order) numarası da bu sistemde tanımlıdır ve formatı önceden ayarlanabilir, ama ürün BUGÜN bir sipariş belgesi üretmiyor — bu alan yalnız "ileride kullanılabilir" durumda, hiçbir belgeye numara atamıyor. Bunu "ürünümüzde sipariş yönetimi var" gibi okumamak gerekir.