Yeni bir programa geçmeye karar verdiniz ve size bir liste verildi: şube, cari, stok kartı, açık siparişler. Listeyi hazırlayan taraf genellikle muhasebe ya da danışman; hazırlaması istenen taraf ise çoğu zaman depo. Bu iki taraf aynı kelimeleri kullanır ama aynı şeyi kastetmez. Muhasebe için stok kartı bir satırdır; depo için bir raftaki kutudur. Geçişin ilk günündeki hataların neredeyse tamamı bu tercüme boşluğundan doğar.
Bu yazının tezi tek cümlede duruyor: geçiş listesi muhasebeden gelir, ama listedeki her satırın doğru cevabı depodadır. Stok kodunun gerçekten tek olup olmadığına, birimin neyi saydığına ve bir koliye kaç adet girdiğine ancak rampada duran kişi karar verebilir. Veri temizliği bu yüzden bir tablo işi değil, bir depo işidir. Aşağıda hazırlığı dokuz karara bölüyoruz ve sonunda geçiş gününün kendisini planlıyoruz.
Geçiş listesi muhasebeden gelir, cevaplar depodan çıkar
Hangi programa geçerseniz geçin, size verilecek liste büyük ölçüde aynıdır: şirket ve şube bilgileri, cari kartlar, stok kartları, açık siparişler ve bir de "açılış bakiyeleri". İnternette bulacağınız yazıların çoğu tam olarak bu listeyi tekrarlar ve orada durur. Durduğu yer sorunun başladığı yerdir; çünkü listenin her satırı, aslında birinin fiziksel olarak karar vermesi gereken bir soruyu gizler.
Bir örnek: "stok kartlarını hazırlayın" cümlesi kâğıt üstünde bir dosya doldurma işidir. Depoda ise şu anlama gelir: bu rafta duran şeyin sistemdeki karşılığı hangi satır, o satırın birimi rafta saydığımız şeye uyuyor mu, aynı ürün ikinci bir kodla da kayıtlı mı? Bunları muhasebe bilemez; muhasebenin elinde yalnızca kodlar ve tutarlar vardır. Bu yüzden geçiş hazırlığında en verimli ilk hamle, listeyi doldurmak değil, listeyi doğru kişiye taşımaktır.
İkinci bir gerçek daha var: geçiş, bu soruların toplu olarak sorulabildiği tek andır. Sistem canlıya alındıktan sonra kimse dört yüz kartı tek tek açıp ölçü girmez; günlük iş her zaman öne geçer. Bugün hazırlanan tablo, önümüzdeki yıllarda okunacak belgelerin kaynağı olur. Bu arada tablonun kendisi bir düşman değil — geçişte taşıma aracı olarak tam da doğru şeydir. Onun asıl işi yürütmek olduğunda nerede tükendiğini ayrı bir yazıda tartıştık: tabloyla yürütmenin sınırı.
Aynı ürünün iki kodu varsa geçiş onu ikiye böler
Mükerrer stok kartı, eski sistemde yıllarca fark edilmeden yaşayabilir. Sebebi basit: iki kod da çalışır. Biri satın almanın açtığı karttır, diğeri satışın; biri ithalatçının kodunu taşır, diğeri sizin iç kodunuzu. İkisinden de belge kesilir, ikisi de doğru görünür. Geçiş bu barışı bozar, çünkü yeni sistemde iki kart iki ayrı ürün olarak doğar ve aralarında hiçbir bağ kalmaz.
Mükerreri isim benzerliğiyle aramak işe yaramaz — aynı ürün iki kartta iki farklı isimle durur, farklı ürünler ise neredeyse aynı isimle. İşe yarayan tarama fiziksel üçlüdür: ölçü, ağırlık ve paket içi adet. Bu üçü tutan iki kart, isimleri ne olursa olsun büyük ihtimalle aynı şeydir; tutmayan iki kart, isimleri aynı olsa da farklı şeydir. Tarama bu yüzden depoda yapılır: kartı açan kişi değil, kutuyu eline alan kişi karar verir.
İkinci sık kalıp, eski kodun boş bırakılmış varyantıdır: bir ürün için kart açılmış, ölçüsü ve ağırlığı hiç girilmemiş, üzerinden bir iki belge geçmiş ve unutulmuş. Bu kartlar geçişte en tehlikeli olanlardır, çünkü boş oldukları için hiçbir taramaya takılmazlar. Kararı verirken tek soru şudur: bu kart hâlâ bir şey ifade ediyor mu? Etmiyorsa yeni sisteme taşınmaz — geçiş, ölü kartları geride bırakmanın da tek fırsatıdır. Ediyorsa hangi kartın kalacağına, o ürünü sipariş eden ve sevk eden kişiler birlikte karar verir; bu bir teknik işlem değil, bir sahiplik kararıdır.
Burada iki konuya bilerek girmiyoruz, çünkü ikisi de ayrı yazıların konusu. Kodun biçimi — kaç basamak, baştaki sıfır, birbirine benzeyen karakterler — kod şeması tasarımıdır ve kuralları başka yerde duruyor: kod şeması tasarımının kuralları. Kodun barkoda yazılıp yazılmayacağı ise bambaşka bir karardır ve stok kodunuzla aynı şey olmak zorunda değildir: barkoda hangi numaranın yazılacağı ayrı bir karardır.
Kodu değiştirmek zorunda kalırsanız eski kod nereye yazılır
Geçişte kod değiştirmek bazen kaçınılmazdır: iki kart birleşir, ya da eski şema yeni sistemin kabul etmediği bir karakter taşır. Değiştirmenin bedeli çoğu zaman göz ardı edilir. Eski kod kaybolduğu anda, o kodla basılmış geçmiş belgeler okunmaz hâle gelir. Bir yıl önceki irsaliyeyi elinize aldığınızda üzerindeki kodu yeni sistemde arayamazsanız, belge tarih olur.
Çözüm karmaşık değil: eski kodu bir alanda yaşatın. Yeni sistemde ürün adının, model alanının ya da bir açıklama alanının içinde eski kodun geçmesi yeterlidir — aranabilir olması yeter, ayrı bir alan olması şart değil. Bunu geçişte yapmak bir dakikalık iştir; geçişten sonra yapmak imkânsıza yakındır, çünkü o zaman eşleştirmeyi hatırlayan tabloyu kimse bulamaz. Kural olarak şunu yazın: hangi eski kodun hangi yeni koda gittiğini gösteren tabloyu geçişten sonra da saklayın. Bu tablo, en çok ihtiyaç duyulacak ve en çok kaybedilen dosyadır.
Ölçü birimi: rampanın saydığı birim, faturanın yazdığı birim
"Kg mı yazayım, adet mi?" sorusu geçiş hazırlığının en çok vakit yiyen sorusudur ve çoğu zaman yanlış çerçevede sorulur. Doğru çerçeve şu: birimler iki türlüdür. Ayrık birimler sayılabilir bütünler ifade eder — adet, koli, palet, çift. Sürekli (kesirli) birimler ise ölçülen büyüklüklerdir: kilogram, metre, metreküp, litre. Aradaki fark akademik değil, son derece pratiktir: sürekli bir birim tek başına saymaya yetmez.
Kilogramla satılan bir ürünü düşünün. Fatura kilogram yazar, doğru. Ama rampada kimse kilogram saymaz; kimse "yirmi üç virgül dört kilogram yükledim" demez. Rampa kutu sayar. Yani o ürün kartında iki birimin birden bulunması gerekir: satışın kullandığı kesirli birim ve deponun kullandığı ayrık birim — bir de ikisi arasındaki dönüşüm oranı. Bu üçlü eksikse kart geçerli değildir; geçerli görünse bile ilk sevkiyatta sayı tutmaz.
Bu, bizim uygulamamızda bir tavsiye değil zorunluluk olarak kodlanmıştır: ürün içe aktarımında birim kesirli bir birimse, ikinci birim ve dönüşüm oranı dolu olmak ve ikinci birim ayrık olmak zorundadır; değilse o satır aktarılmaz. Kural sert görünüyor ama sertliği kasıtlı — kesirli birimle açılmış tek başına bir kart, üzerinden ilk koli etiketi basılana kadar sorunsuz görünür.
Pratik tavsiye: eski sistemden çıkardığınız listede birim sütununu tek tek gözden geçirin, çünkü orada göreceğiniz şey çoğu zaman bir birim değil, birinin bir gün yazdığı bir kelimedir. "Ad", "ad.", "AD", "adet", "ADET", "pcs" — hepsi aynı şeyi kastediyor olabilir ama sistem için altı ayrı değerdir. Bunu birleştirmek yarım günlük iştir ve geçişten sonra yapılması neredeyse imkânsızdır.
Birim serbest metin değil, kodlu bir alandır
Birim sütununu neden bu kadar ciddiye almak gerektiğinin belgelenmiş bir sebebi var. Türkiye'de e-belge XML'inde miktarın yanındaki birim serbest metin değildir: Gelir İdaresi Başkanlığı'nın UBL-TR Kod Listeleri kılavuzunda miktar alanı için bir birim kod listesi yayımlanır ve değer o listeden alınır. Kılavuzun bu yazının hazırlandığı sıradaki sürümü 1.43 (Temmuz 2026); listede adet C62, metre MTR, metrekare MTK, gram GRM gibi kodlarla geçer ve listede bulunmayan birimler için uluslararası birim kod listesine yönlendirilir (GİB e-Belge kılavuzları).
Sonucu şudur: bir stok kartında birim "ad.", ikincisinde "AD", üçüncüsünde "adet" yazıyorsa, bunların hepsi aynı koda çevrilmek zorundadır ve bu çeviriyi eninde sonunda biri yapacaktır. O biri siz olursanız geçiş sırasında yaparsınız; olmazsanız yıllar sonra bir belge üretilemediğinde yapılır. Uygulamamızda birim adı üç dilde de yazılabilir ve kanonik koda çevrilir; çözümlenemeyen bir birim yazan satır ise aktarılmadan atlanır — hangi kodların kabul edildiğini görebileceğiniz bir birim referans ekranı vardır ve her birimin sürekli mi ayrık mı olduğunu orada işaretler.
Paket içi adet: tek bir sayı, üç ayrı yerde patlar
Geçiş şablonlarında en çok itiraz gören zorunlu alan genellikle paket içi adettir. "Ürünün fiyatı var, adı var, kodu var — koliye kaç tane girdiğini neden şimdi sormak zorundasınız?" Cevap, bu sayının tek bir yerde değil üç ayrı yerde kullanılıyor olmasıdır ve üçü de sessizce yanlış çalışır.
Birincisi etiket: kaç etiket basılacağı, paket sayısı ile paket içi adet ilişkisinden çıkar. Bu ilişki bozuksa ya elinizde fazla etiket kalır ya da etiketsiz koli. İkincisi yükleme sayımı: okutarak yüklüyorsanız beklenen okutma sayısı yine aynı ilişkiden gelir; sayı yanlışsa yükleme ya erken "tamam" der ya da hiç tamamlanmaz. Üçüncüsü çeki listesi: listedeki miktar ile koli adedi arasındaki uyum, tam olarak bu sayının doğru olmasına dayanır. Yani tek bir hücredeki hata aynı anda üç belgeye birden yayılır ve üçünde de farklı bir kılıkta görünür.
Buradan çıkan pratik kural şu: paket içi adedi tahmin etmeyin. Bir kutuyu açın ve sayın. Bu, geçiş hazırlığının en sıkıcı ve en yüksek getirili işidir. Aynı sayıyı taşıyan etikete hangi alanların girdiğini ayrı bir yazıda anlattık: koli etiketinde hangi alanlar durur.
Boş bırakılan ölçü ve ağırlık alanları sonradan doldurulmuyor
En, boy, yükseklik ve net/brüt ağırlık, geçiş şablonlarında neredeyse her zaman isteğe bağlı alanlardır — ve tam da bu yüzden neredeyse her zaman boş kalırlar. Bunun bedeli hemen görünmez, birkaç ay sonra görünür. Hacim boyutlardan hesaplanan bir değerdir; boyut yoksa hacim de yoktur. Hacim yoksa yükleme planı yapılamaz, navlun teklifi kontrol edilemez, konteynere kaç palet gireceği tahmin edilemez.
Ağırlık tarafında durum daha nettir: net ve brüt ağırlık ihracat belgelerinde istenir ve o an geriye dönüp yüzlerce kartı açmak kimseye nasip olmaz. Pratikte ne olur? Ağırlık, belge hazırlanırken elle yazılır — her seferinde yeniden, her seferinde biraz farklı. Sonra iki belgede iki farklı ağırlık görünür ve kimse hangisinin doğru olduğunu bilmez.
Geçiş, bu alanların toplu doldurulabildiği tek andır, çünkü zaten satır satır bir tablo üzerinde çalışıyorsunuz. Bir kutuyu ölçmek yarım dakikadır; aynı ölçüyü sistem canlıya geçtikten sonra tek tek girmek asla başlamayan bir iştir. Ölçü birimini de birlikte yazın — santimetre mi milimetre mi olduğu belirtilmemiş bir boyut sütunu, boş bir sütundan daha tehlikelidir, çünkü dolu görünür.
Cari ve şube tarafı: adres bir metin değil, bir teslimat noktasıdır
Cari kartlar geçişte genellikle en kolay parça sanılır, çünkü muhasebe onları zaten temiz tutuyordur. Ama muhasebenin temiz tuttuğu şey fatura adresidir — verginin, unvanın ve ödemenin adresi. Deponun ihtiyacı olan şey ise teslimat adresidir ve ikisi çoğu müşteride farklıdır. Merkez ofise fatura kesip fabrikaya mal götürürsünüz; zincir mağazaya fatura kesip beş ayrı şubeye dağıtırsınız.
Aynı ayrım telefon numarası için de geçerlidir. Cari kartındaki telefon çoğunlukla muhasebenin telefonudur; oysa sevkiyat gününde aranması gereken kişi boşaltmayı yapacak olandır. Geçiş, bu iki bilginin ayrıştırıldığı iyi bir fırsattır — hangi alanın kimin işine yaradığını bir kere yazın, sonra yıllar boyunca herkes doğru numarayı arasın.
Bir de terim uyarısı: birçok programda şube ile depo aynı şey değildir. Bizim uygulamamızda şube, şirketin kendi organizasyon birimidir — bir depo gözü ya da raf lokasyonu değil. Geçiş şablonunu doldururken bu ikisini karıştırmak, sonradan düzeltmesi en zahmetli hatalardan biridir, çünkü yanlış kavramla açılmış kayıtlar zamanla belgelere yayılır. Kendi deponuzun iç lokasyonlarını adreslemek isterseniz o tamamen ayrı bir tasarım işidir: depo raf adresleme sistemi.
Yükleme sırası: hangi veri hangi veriden önce girer
Dosyalar hazır olduğunda son bir soru kalır ve genellikle en son sorulur: hangisini önce yükleyeceğim? Sıra keyfî değildir, çünkü kayıtlar birbirine bağlıdır. Doğru sıra şube → cari → ürün → sipariş'tir. Sebebi basit: sipariş satırı bir müşteriye, bir ürüne ve bir şubeye bağlanır; o üçü henüz yoksa bağlanacak bir şey de yoktur.
Burada bir noktayı dürüstçe düzeltmek gerekiyor, çünkü sık duyulan "ters sırada yüklerseniz satır sessizce kaybolur" uyarısı bizim uygulamamız için doğru değil — ve gerçek davranış aslında daha sinsi. Sipariş içe aktarımında olmayan bir cari ya da ürün koduyla karşılaşıldığında kayıt düşmez: uygulama o carinin ve o ürünün kartını kendisi açar ve size bir uyarı gösterir. Açtığı kart ise içi boştur — adı kodun kendisidir, birimi varsayılan, paket içi adedi bir, ölçüsü ve ağırlığı yok. Olmayan bir şube kodunda ise uyarı verip sizi şube giriş ekranına götürür.
Bu neden daha kötü? Çünkü kaybolan satır fark edilir, içi boş kart fark edilmez. Yeni sistemde stok listesine baktığınızda kartlar oradadır, sayıları doğrudur ve her şey yolunda görünür. Yolunda olmayan tek şey, o kartların hiçbirinde ölçü, ağırlık ya da gerçek bir paket adedi bulunmamasıdır — ve bu, ilk etiket basılana kadar ortaya çıkmaz. Doğru sırayla yüklemek, bu boş kartların hiç doğmamasını sağlar.
İçe aktarım sonunda çıkan mesaja da bakın: uygulamamız kaç kaydın aktarıldığını ve kaçının atlandığını söyler. Burada bir sınırı da açıkça söylememiz gerekiyor: hangi satırın neden atlandığını satır satır listelemez, yalnız toplamı verir. Yani atlanan sayısı sıfırdan büyükse, dosyayı yeniden gözden geçirme işi sizde kalır. Bunu bilerek bakın; sıfırdan büyük bir atlanan sayısı, üzerinden atlanacak bir ayrıntı değildir.
Önizleme neden kaydetmeden önce gelir
Sipariş içe aktarımında kaydetmeden önce bir önizleme adımı vardır ve bu adımın tek bir asıl işi vardır: dosya içinde aynı stok kodunun iki farklı birimle geldiği satırları işaretlemek. Bu, ölçü birimi tutarsızlığının yakalanabildiği son noktadır. Bir kere kaydedildikten sonra iki farklı birim iki farklı gerçeklik olur ve hangisinin doğru olduğunu artık dosya değil, insan hatırlamak zorunda kalır.
Burada da bir sınır var ve söylemek gerekiyor: bu önizleme yalnız sipariş içe aktarımında vardır. Ürün içe aktarımında önizleme yoktur — ürün dosyası doğrudan işlenir, kurala uymayan satırlar atlanır ve sonuçta yalnız bir sayı görürsünüz. Bu yüzden ürün dosyası, yüklenmeden önce en dikkatli okunması gereken dosyadır.
Geçiş günü: ne durur, yoldaki mal ne olur
Geçişin en çok ertelenen kısmı, kesme anının kendisidir. Herkes veriyi hazırlamayı konuşur, kimse "hangi saatte eski sistemde kayıt açmayı bırakıyoruz" sorusunu yazıya dökmez. Oysa bu tek cümle, geçişin en pahalı hatasını önler: aynı belgenin iki sistemde birden açılması.
Kesme anını yazarken tek bir tarih vermek yetmez; belge türü başına yazmak gerekir. Sipariş almayı ne zaman yeni sistemde başlatacaksınız? Sevk belgesini hangi tarihten sonrası için yeni sistemde keseceksiniz? Faturayı? Bu üçü aynı gün olmak zorunda değil ve çoğu zaman olmaz da. Yazılmadığında ise herkes kendi tahminine göre davranır ve bir hafta sonra iki sistemde de yarım kalmış belgeler bulursunuz.
En çok unutulan kalem yoldaki maldır: çıkmış ama henüz teslim edilmemiş sevkiyatlar. Bu mallar eski sistemde "gitti", yeni sistemde ise hiç var olmadı. Teslim edildiklerinde onları kabul edecek bir kayıt bulunmaz ve kimse bunu geçişten önce düşünmez. Kural şu olmalı: geçiş anında yolda olan her sevkiyat, kapanacağı sistemde açık bir kayıt olarak durmalıdır. Hangi sistemde kapatacağınıza siz karar verirsiniz — ama karar verilmiş olmalıdır.
Paralel çalışma — iki sistemi bir süre birlikte yürütmek — sık önerilir ve gerçekten de riski düşürür, ama bedeli her belgeyi iki kez girmektir. Ne kadar süreceğine dair bir sayı vermeyeceğiz, çünkü bunu belirleyen tek şey sizin belge hacminiz ve o işi yapacak kişinin dayanma gücüdür. Söylenebilecek olan şu: paralel çalışmanın bitiş koşulu baştan yazılmalıdır. "Bir süre iki sistemi de kullanalım" cümlesi, bitiş koşulu olmadığı için genellikle aylarca sürer ve iki sistemde de eksik veri bırakır.
Eski sistemi kapatmadan önce: veriyi kendinize alın
Yeni sistem çalışmaya başladığında eskisinin aboneliğini ya da bakımını sürdürmek anlamsız görünür — ve genellikle ilk kesilen kalem odur. Kapatmadan önce cevaplanması gereken tek soru şudur: o veriye bir daha ihtiyacım olursa nereden bakacağım?
Cevap "raporları PDF olarak bastık" ise yeterli değildir. PDF yığını bir arşiv değildir: içinde arama yapamaz, iki kaydı karşılaştıramaz, bir toplamı yeniden hesaplayamazsınız. Veriyi makinede okunabilir bir biçimde — CSV ya da JSON — dışarı almak, PDF basmaktan daha az emek ister ve karşılığında gerçek bir arşiv verir. Uygulamamızda bu iki biçimin ikisi de vardır; ama asıl mesele hangi programı kullandığınız değil, kapatmadan önce bu adımı atlamamanızdır.
Bir de yükümlülük tarafı var. Ticari ve mali kayıtların, mevzuatın öngördüğü saklama süresi boyunca okunabilir kalması gerekir — ve "okunabilir", kapanmış bir programın içinde kalmış bir veritabanı dosyası demek değildir. Süreyi ve kapsamı bu yazıdan değil, mali müşavirinizden öğrenin; ülkeye ve belge türüne göre değişir ve yanlış hatırlanan bir süre, hiç bilinmemesinden daha risklidir.
Son bir uyarı: veriyi almak ile veriyi okuyabilmek aynı şey değildir. Dışa aldığınız dosyayı kapatma gününden önce bir kere açın ve içinde bir kayıt arayın. Açılmıyorsa ya da sütun başlıkları anlaşılmıyorsa, elinizde arşiv değil bir dosya vardır.
Aynı ilke tersine de işler: veriyi içeri alırken üzerine yazma riskine dikkat edin. Bizim aktarım motorumuz bu konuda muhafazakâr davranır — hedefte aynı numaralı ya da kodlu bir kayıt varsa onu ezmez, o kaydı aktarmaz. Bu, yanlışlıkla ikinci kez çalıştırılan bir aktarımın veriyi bozmasını engeller; ama aynı zamanda "aktardım, güncellendi" beklentisini de boşa çıkarır. Hangi davranışın geçerli olduğunu, hangi programı kullanırsanız kullanın, ilk denemeden önce öğrenin.
Biz bu tarafta ne yapıyoruz, ne yapmıyoruz
Bu yazıyı bir ürün tanıtımıyla kapatmak yerine bir sınır çizgisiyle kapatmak istiyoruz, çünkü geçiş hazırlığında en pahalı hata yanlış beklentiyle yola çıkmaktır. Smartifie Logistic bir ERP değildir ve ERP yerine geçmeyi hedeflemez; sevkiyat tarafında duran bir uygulamadır.
Yaptıklarımız. Dört ekranda — ürün, cari, sipariş ve şube — indirebileceğiniz bir Excel şablonu ve içe aktarım vardır; ürün kartında stok kodu, paket içi adet ve birim zorunludur; kesirli birim kullanıldığında ikinci birim ve dönüşüm oranı da zorunlu hale gelir; hacim elle yazılmaz, girdiğiniz boyutlardan hesaplanır; sipariş içe aktarımı kaydetmeden önce önizleme verir ve aynı stok kodunun iki farklı birimle geldiği satırları işaretler; veriyi CSV ya da JSON olarak geri alabilirsiniz.
Yapmadıklarımız — ve bunları açıkça saymak istiyoruz. Uygulamada stok bakiyesi ya da eldeki miktar tutulmaz; "açılış stoğu" diye bir kayıt yoktur. Sayım (envanter) modülü yoktur. Lot, parti, seri numarası ve son kullanma tarihi takibi yoktur. Muhasebe yoktur — buradaki "cari" bir hesap değil, bir müşteri kartıdır; bakiye, açık fatura ya da hesap planı bulunmaz. Logo, Netsis, Mikro ya da benzeri bir ERP konnektörümüz yoktur; veri alışverişi Excel şablonu üzerinden, ek olarak da kendi veritabanınıza aktarım seçeneğiyle yapılır. Son olarak mükerrer kartları bulan ya da birleştiren bir temizlik sihirbazı yoktur; bu yazıda anlatılan taramayı yapan sizsiniz, uygulama değil.
Bu listeyi vermemizin sebebi tevazu değil, pratiklik: yukarıdaki maddelerden biri sizin için zorunluysa, çözümü başka yerde aramanız gerekir ve bunu geçişten önce bilmeniz gerekir. Buna karşılık, geçişin hangi tarafında durduğumuz da net: sipariş, sevk emri, yükleme, koli etiketi ve sevk belgesi aynı kayıttan üretilsin diye varız. Yazının başındaki teze dönerek bitirelim — geçiş listesi muhasebeden gelir, ama listedeki her satırın cevabı depodadır. Hazırlığı depoda yaparsanız, hangi programa geçerseniz geçin daha az şey kırılır.