QuickBooks'tan Odoo 19'a geçişi Türkiye kapsamıyla planlayın
Geçiş kararını ürün adına değil, mevcut QuickBooks yapılandırmasına dayandırın
6 Kasım 2026 tarihinde gözden geçirildi. Bu rehber olası bir migrasyon ve keşif senaryosudur; QuickBooks'un Türkiye'deki yaygınlığı veya Oakland müşterisi hakkında iddia içermez.
QuickBooks sürümü, şirket dosyası sayısı, kullanılan özellikler, eklentiler, şubeler ve mevcut e-belge düzeni çıkarılmadan Odoo 19 hedefi netleştirilemez. Aynı ürün adı altında farklı hesap planı, stok kullanımı, para birimi ve dışa aktarım yapıları bulunabilir. Bu nedenle ilk adım ekran görüntüleri veya genel özellik listeleri değil, gerçek dosyalar ve işlem örnekleridir.
Kaynak sürüm ve dosya: Doldurulacak bilgi: ________________________________________________
Şirket, şube ve eklenti listesi: Doldurulacak bilgi: ______________________________________
Taşınacak dönem ve açık işler: Doldurulacak bilgi: _______________________________________
Bu kayıt, hangi verinin taşınacağını ve hangi işlevin Odoo'da yeniden tasarlanacağını belirler. QuickBooks'taki her alanın birebir hedefi olacağı veya hazır bir bağlayıcının bütün geçmişi anlamlandıracağı varsayılmaz. Kullanılmayan geçmiş ile yasal ve operasyonel olarak gerekli açık kayıtlar ayrılır; dışa aktarımın okunabilirliği ve toplam kontrol değerleri ilk kabul noktası olur.
Hesap planı ve mali yapıyı mizanla birlikte eşleştirin
QuickBooks hesaplarını yalnızca kod ve ada göre Odoo hesaplarına bağlamak, raporlama ve vergi sonuçlarını zayıflatır. Hesabın türü, borç/alacak davranışı, para birimi, banka veya ödeme hesabı olması, stok ve kur farkı ilişkileri ile mevcut bakiye birlikte değerlendirilir. Odoo 19 l10n_tr yapıları başlangıç noktasıdır; KDV, muhtasar veya kurumlar beyannamesi gönderme özelliği olarak sunulmaz.
Kaynak hesap kodu ve adı: Doldurulacak bilgi: __________________________________________
Hedef hesap ve gerekçe: Doldurulacak bilgi: _____________________________________________
Dönem başı borç/alacak kontrolü: Doldurulacak bilgi: ___________________________________
Her eşleştirme için kaynak mizan satırı ve hedef mizan satırı saklanır. Aynı kaynak hesabın birden fazla hedefe bölünmesi gerekiyorsa hangi belge veya yardımcı hesap boyutunun kullanılacağı yazılır. TFRS veya BOBİ FRS raporlaması, şirketin kapsamına göre mali müşavirle ayrıca ele alınır. e-Beyanname hazırlama ve gönderme ise muhasebe hesap planı taşımasından bağımsız bir süreçtir.
Cari hesap ve ürün kayıtlarında kimlik ile vergi bilgisini ayırın
Müşteri, tedarikçi, çalışan ve diğer kişi kayıtlarında isim benzerliği yerine kaynak kimliği, vergi/TC kimlik alanı, adres, ülke, para birimi, ödeme koşulu ve açık belge bağlantısı kullanılır. e-Arşiv, e-Fatura uygulamasına kayıtlı olmayan alıcılara düzenlenen elektronik faturaları kapsar. Bu alıcılar yalnızca nihai tüketiciler değil, e-Fatura uygulamasına kayıtlı olmayan işletmeler de olabilir. Alıcının e-Fatura uygulamasına kayıtlı olup olmadığı ile e-Arşiv alıcı sınıfı ayrı alanlarda tutulur.
Ürünlerde birim, barkod, maliyet yöntemi, satış ve satın alma hesapları, stok takibi ve KDV kararı bulunur. Genel KDV yüzde 20 olsa da liste bazlı yüzde 1 ve yüzde 10 oranları, istisna, matrah, tevkifat/sorumluluk ve indirim durumu işlem bazında incelenir. Sıfır oran, istisna, ihracat kayıtlı teslim ve indirilemeyen KDV ayrı sonuçlardır.
Kaynak kişi/ürün kimliği: Doldurulacak bilgi: __________________________________________
Hedef kayıt ve belge/vergi kararı: Doldurulacak bilgi: ___________________________________
Açık belge ve ödemeleri kapalı toplamlar yerine bağlantılarıyla taşıyın
Açık satış ve satın alma faturaları, kısmi ödemeler, avanslar, iadeler ve düzeltme belgeleri kaynak belge kimlikleriyle taşınır. Yalnızca cari bakiyeyi tek bir açılış kaydına çevirmek, sonraki ödeme ve yaşlandırma çalışmasını zayıflatır. Her açık kalemin orijinal tutarı, kalan tutarı, para birimi, kuru, vadesi, muhasebe tarihi ve bağlı ödeme veya iade ilişkisi korunur.
e-Fatura veya e-Arşiv geçmişi bulunan belgelerin yeniden mali belge olarak gönderilmesiyle yalnızca muhasebe verisinin taşınması ayrılır. Önceki XML, XSLT görünümü, zarf/paket yanıtı ve varsa ticari KABUL/RED/İADE kaydı kanıt arşivinde tutulur. Temel senaryoya ticari alıcı yanıtı eklenmez; e-Arşiv rapor paketinin kabulü de alıcının belgeyi kabulü veya ödemesi olarak değerlendirilmez.
Kaynak belge ve kalan tutar: Doldurulacak bilgi: _______________________________________
Hedef açık kalem ve ödeme bağlantısı: Doldurulacak bilgi: ________________________________
Taşınan mali kanıtın türü: Doldurulacak bilgi: __________________________________________
Vergi ve e-belge eşleşmesini gerçek senaryolarla doğrulayın
Her satır için vergi oranı ve hesabı kadar belge senaryosu da belirlenir. e-Fatura uygulamasına kayıtlı kullanıcılar arasındaki belge alışverişi ile e-Arşiv alıcı kapsamı ayrılır. GİB Portalı'nı kullanan katılımcıların ayrıca rapor oluşturma veya yükleme yükümlülüğü yoktur; entegrasyon veya özel entegrasyon kullanıcılarının raporlama kanıtı ise ayrı tutulur. Genel 3 milyon TL ciro kuralı 2022 ve sonraki dönemlerle, sektör/faaliyet kategorileriyle, gönüllü ve GİB tarafından bildirilen kullanıcılarla değerlendirilir; bütün mükelleflere aynı başlangıç tarihi verilmez.
2026 için 573 ve 589 sıra numaralı Tebliğ ayrımı korunur. Yalnızca basit usulde ticari kazanç elde eden mükellefler ile işletme hesabı esasına göre defter tutan mükellefler için vergi dahil toplam 3.000 TL’yi aşan faturalara ilişkin sınır 31 Aralık 2026'ya kadar korunur. VUK 509 IV.2.4.3'teki bu eşik, e-Arşiv uygulamasına dahil olmayan mükelleflerin düzenlediği faturalar içindir; V.7 ve VIII. bölümlerdeki istisnalar saklıdır. Tutardan bağımsız kural 1 Ocak 2027’de yürürlüğe girer. Diğer mükellef grupları için 1 Ocak 2026 başlangıç hükmü ve ilgili istisnalar, mükellefin kapsamına göre ayrıca değerlendirilir. VUK 232'deki 12.000 TL genel fatura düzenleme sınırı evrensel e-Arşiv eşiği yapılmaz.
İşlem ve mükellef sınıfı: Doldurulacak bilgi: ___________________________________________
Belge senaryosu ve dayanak: Doldurulacak bilgi: _________________________________________
Mali müşavir onayı: Doldurulacak bilgi: _________________________________________________
UBL-TR ve Nilvera kabulünü kurulu Odoo 19 sürümünde yapın
Odoo'nun ürettiği XML içinde UBL-TR 1.2.1 paket özelleştirmesi ile CustomizationID TR1.2 ayrı alanlardır. ProfileID kurulu derleme ve etkin modüllere göre temel/e-Arşiv senaryolarında TEMELFATURA veya EARSIVFATURA; genişletilmiş kamu/ihracat senaryolarında KAMU veya IHRACAT; isteğe bağlı ticari senaryoda TICARIFATURA olur. Kabulden önce kurulu derleme ve modüller kayda geçirilir. İmzalı veya onaylı XML, mali açıdan esas alınan asıl belgedir; XSLT onun görsel sunumudur. Çelişkide XML esas alınır. ZIP’lenmiş XML ve zarf taşıma katmanıdır. Sıradan PDF yeterli kanıt değildir; özel izinli PAdES durumu dahi UBL-TR XML gerektirir.
Resmî Odoo 19 entegrasyonu doğrudan GİB yerine Nilvera ile çalışır. Test adresi https://apitest.nilvera.com, üretim adresi https://api.nilvera.com olarak kaydedilir. l10n_tr_nilvera_base_vat köprüsü l10n_tr_nilvera ile base_vat modüllerini birbirine bağlar; incelenen köprü manifestosu bu bağımlılıkları gösterir. Temel/e-Arşiv, durum/PDF ve genişletilmiş temel/kamu/ihracat senaryoları kaynakta incelenir. 16 Ekim 2026 geri taşımasındaki isteğe bağlı l10n_tr_gib_invoice_scenarios modülü ticari, iade, tevkifatlı iade ve karşı taraf kabul-ret işlevleri içerir. Müşteri kurulumunda modül ve sürüm test edilmeden ticari akışın hazır olduğu söylenmez; Odoo 20 özellikleri de kanıt olarak kullanılmaz.
TL, kuruş ve döviz dönüşümünü belge düzeyinde karşılaştırın
Bir TL 100 kuruştur. İşlem ve ödeme tutarları kuruşa yuvarlanır; yarım kuruş ve üzerindeki değerler bir kuruşa tamamlanır, yarım kuruşun altındaki değerler dikkate alınmaz. Bu kural birim fiyat, miktar, oran, kur, iskonto veya ara hesaplamalara genellenmez; bu alanların hassasiyeti ayrıca doğrulanır. Şema ve işlem vergisi yuvarlaması ayrı incelenir.
İncelenen Odoo TRY tanımında yuvarlama değeri 0.01, alt birim değeri Kurus olarak görünür. UBL parasal alanlarının iki, kur dönüşümlerinin ise altı ondalık basamak kullandığı ayrı testlerle doğrulanır.
Her belge için kaynak para birimi ve tutar, kur, tarih, kaynak, beklenen TL, Odoo'daki TL ve fark yazılır. İki ondalıklı aynen geçiş örnekleri 0.01 TL → 0.01 TL, 0.04 TL → 0.04 TL, 0.05 TL → 0.05 TL ve 0.09 TL → 0.09 TL; negatif aynen geçiş örnekleri -0.01 TL → -0.01 TL, -0.04 TL → -0.04 TL, -0.05 TL → -0.05 TL ve -0.09 TL → -0.09 TL olarak ayrıca etiketlenir.
Nihai işlem/ödeme sonucu örnekleri, yukarıdaki yarım kuruş kuralına göre 1.004 TL → 1.00 TL, 1.005 TL → 1.01 TL ve 1.006 TL → 1.01 TL şeklindedir. Negatif analoglar -1.004 TL → -1.00 TL, -1.005 TL → -1.01 TL ve -1.006 TL → -1.01 TL olarak test edilir; işaret davranışı ayrıca gözden geçirilir ve sonuç ilgili uzman ile sistem sorumlusu tarafından onaylanır.
Büyük tutarlar ve karışık belgeler de denenir. Farkın nedeni açıklanmadan toplam tolerans kullanılmaz.
Kaynak tutar ve kur kanıtı: Doldurulacak bilgi: ________________________________________
Beklenen/gerçekleşen TL ve kuruş: Doldurulacak bilgi: ___________________________________
Kalan fark, neden ve çözüm sahibi: Doldurulacak bilgi: __________________________________
Stok ve ek maliyetleri miktar, değer ve dönemle prova edin
QuickBooks'taki stok miktarı ve maliyeti Odoo'ya taşınırken ürün kategorisi, değerleme yöntemi, depo, teslim tarihi ve muhasebe dönemi birlikte ele alınır. Navlun, sigorta, gümrük ve diğer ek giderlerin hangi teslim ve ürünlere dağıtılacağı belirlenir. Odoo 19'da tedarikçi faturasından ek maliyet (landed cost) oluşturulurken, gerekli durumlarda AVCO veya FIFO uygunluğu kontrol edilir; Standart Fiyat (Standard Price) yöntemi için ayrı bir doğrulama yolu gerekir.
Kısmi satış yapılmış bir teslimata sonradan maliyet geldiğinde kalan stok ile satılan bölümün maliyet etkisi ayrı incelenir. Dönem kapandıysa muhasebe etkisinin hangi tarih ve onayla işleneceği yazılır. Yalnızca toplam stok değerinin yakın olması yeterli değildir; ürün, depo ve teslim bazındaki farklar açıklanır.
Teslim ve stok kontrolü: Doldurulacak bilgi: ____________________________________________
Ek maliyet belgesi ve dağıtımı: Doldurulacak bilgi: _____________________________________
Dönem etkisi ve mali onay: Doldurulacak bilgi: _________________________________________
Yükleme provasını tekrarlanabilir ve reddedilebilir biçimde çalıştırın
Her yüklemenin girdi sürümü, alan eşleşmesi, çalıştırma kimliği, çalıştıran kişi ve zamanı kaydedilir. Kişi ve hesaplar önce, ürün ve belgeler sonra gibi bağımlılık sırası uygulanır. Dış kimlikler sayesinde aynı paketin ikinci çalıştırmada mükerrer kayıt üretip üretmediği test edilir.
Reddedilen kayıtlar için hata nedeni, etkilenen bağımlı belgeler ve yeniden deneme koşulu tutulur. Bir cari veya hesap reddedildiğinde buna bağlı fatura ve ödemelerin ilerlemesine izin verilip verilmeyeceği önceden belirlenir. Hatalı satırı silip toplamı zorla eşitlemek yerine kaynak düzeltmesi veya onaylı istisna kaydı kullanılır.
Prova paketi ve bağımlılık sırası: Doldurulacak bilgi: __________________________________
Reddedilen kayıt ve durma kuralı: Doldurulacak bilgi: ___________________________________
Tekrar çalıştırma ve mükerrerlik sonucu: Doldurulacak bilgi: _____________________________
Geçişi imzalı mutabakat ve kullanıcı kabulüyle tamamlayın
Son karar öncesinde kaynak ve hedef kayıt sayıları, mizan, açık kalemler, banka bakiyeleri, stok miktarı/değeri, vergi raporları ve TL karşılıkları aynı kesim tarihiyle karşılaştırılır. Sistem yanıtı ile mali onay, paket kabulü ile alıcı kabulü ve muhasebe kaydı ile ödeme birbirinden ayrılır. Tüm farkların nedeni açıklanmalı, çözüm sorumlusu atanmalı ve kapatma kararı alınmalıdır; bunlar tamamlanmadan geçiş onayı verilmez.
Kasiyer, şube müdürü, satın alma sorumlusu, muhasebe sorumlusu, vergi sorumlusu, mali kontrol sorumlusu, bordro sorumlusu ve yönetici kendi rutin ve istisna senaryolarını uygular. Türkçe görev kartları, e-belge kanıtı ve POS kesinti/yanıt prosedürleri kullanılır. Sonradan çıkan farkların kim tarafından inceleneceği ve ilk şube kapanışının kim tarafından imzalanacağı belirlenir.
Mutabakat paketi ve açık farklar: Doldurulacak bilgi: ___________________________________
Rol bazlı kullanıcı kabulü: Doldurulacak bilgi: _________________________________________
Geçiş veya ek prova kararı: Doldurulacak bilgi: _________________________________________
Sonraki adım olarak migrasyon ve TL mutabakatı çalışma kitabını doldurun ve GİB/e-belge keşif rehberiyle teknik kanıt kapsamını karşılaştırın.
QuickBooks geçişini kendi örnek verilerinizle sınayın
Sürümü, şirket dosyalarını, şubeleri, hesap planını, stok kullanımını, para birimlerini ve taşınacak geçmişi paylaşın. Mizan, cari ve ürün örnekleri, açık belgeler, banka mutabakatı ve mevcut e-belge akışınızla bir prova planı çıkaralım.
İletişime Geçin
Buhaira Corniche, 43132 Sharjah,
Birleşik Arap Emirlikleri