Odoo 19'u mevzuat, veri ve kabul kanıtlarıyla birlikte tasarlayın
Oakland, Türkiye'deki finans ve operasyon ekiplerine BAE'den uzaktan çalışma modeliyle destek olur. GİB/e-belge kapsamını, TL ve döviz mutabakatını, kaynak veriyi, şube/POS işlerini ve Türkçe eğitimi aynı kabul planında ele alır; yerel varlık veya otomatik yasal uyum iddiasında bulunmaz.
Ürün
Odoo, ekranda
Tekliften ve bütçeden önce: finans ve operasyon yöneticilerinizin her sabah açacağı yazılımı görün.
Özel hazırlanmış bir demo değil, standart Odoo ekranları.
Türkiye için uzaktan, kanıta dayalı uygulama modeli
6 Kasım 2026 tarihinde gözden geçirildi. Bu sayfa genel keşif ve uygulama rehberidir; belirli bir mükellef için hukuki, vergi veya mali müşavirlik görüşü değildir.
Oakland, Türkiye'deki finans ve operasyon ekipleriyle BAE'deki uygulama organizasyonundan uzaktan çalışır. Toplantı planı, müşteriyle kararlaştırılan Türkiye saati esas alınarak teklif edilir; bu bir yerel ofis veya Türkiye'de görevli ekip vaadi değildir. Resmî Odoo Gold Partner kimliği küresel bir yetkinlik göstergesidir. Türkiye'de müşteri, şube, çalışan, yerel telefon, veri yerleşimi veya GİB onayı kanıtı olarak kullanılmaz.
İlk görüşmede şirketin tüzel yapısı, şubeleri, belge akışları, mevcut muhasebe ve stok düzeni, entegratörü, bankaları ve kullanıcı rolleri çıkarılır. Amaç, ürün özelliklerini genel bir listeye çevirmek değil; hangi işin standart Odoo 19 ile doğrulanacağını, hangi kararın mali müşavir veya sağlayıcıya ait olduğunu ve hangi gereksinimin özel geliştirme kapsamı doğuracağını görünür kılmaktır.
Keşif, gerçek kayıtlar ve kabul kanıtıyla başlar
Keşif çalışmasında bir satış faturası, bir alış faturası, bir iade örneği, cari hesap dökümü, banka mutabakatı, stok değerleme raporu ve şube kapanışı birlikte incelenir. Belgelerin hukuki kapsamı ile sistemdeki teknik karşılığı birbirine karıştırılmaz; önce mükellef ve işlem kararı netleştirilir, ardından bu karar Odoo'daki alan, hesap, günlük ve entegrasyon akışıyla eşleştirilir.
Her kabul senaryosunda girdi, beklenen sonuç, kanıt biçimi, inceleyen kişi ve hata durumunda izlenecek yol yazılır. Örneğin yalnızca “fatura gönderildi” ifadesi yeterli değildir. İmzalı XML, XSLT görünümü, zarf veya paket yanıtı, ticari senaryodaki alıcı yanıtı ve muhasebe kaydı ayrı kanıtlar olarak değerlendirilir. Eksik veya çelişkili kayıtlar, genel bir toleransla kapatılmaz; sahibi ve çözüm kararı olan açık iş olarak kalır.
KDV oranı tek başına yapılandırma kararı değildir
Genel KDV oranı yüzde 20'dir; mevcut kararlar kapsamında liste bazlı yüzde 1 ve yüzde 10 oranları da bulunur. Yüzde 20 ve yüzde 10 oranlarına ilişkin değişiklikler 10 Temmuz 2023'te yürürlüğe girdi. Bir ürün veya hizmet için yalnızca oran seçmek yerine işlemin kapsamı, ilgili liste, istisna, matrah, tevkifat veya sorumluluk ve indirim durumu birlikte incelenir.
Tevkifat, işlemin ana KDV oranını değiştiren bir kısayol değildir. İstisna, sıfır oran, ihracat kayıtlı teslim ve indirilemeyecek KDV birbirinden farklı mali ve kanıt sonuçları doğurur. Odoo'daki vergi hesapları, mali pozisyonlar ve rapor etiketleri bu kararların ardından yapılandırılır. Örnek işlemler mali müşavir tarafından onaylanan beklenen tutarlarla karşılaştırılır; her faturaya genel oran uygulanacağı veya raporun beyanname yerine geçeceği varsayılmaz.
e-Fatura ve e-Arşiv alıcı kapsamı ayrıştırılır
e-Fatura, kayıtlı kullanıcılar arasında GİB merkezli sistem üzerinden belge alışverişini konu eder. 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. 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ında rapor paketleri ZIP’lenmiş XML olarak sendDocumentFile ile gönderilir ve getBatchStatus ile izlenir; paket kabulü alıcının faturayı kabulü veya ödemesi değildir. Bu nedenle e-Arşiv'i yalnızca B2C satış kanalı olarak modellemek, işletmeden işletmeye belgelerin yanlış akışa girmesine yol açabilir.
Genel e-Fatura için 2022 ve sonraki dönemlere ilişkin 3 milyon TL ciro kuralı; sektör ve faaliyet kategorileri, gönüllü kullanıcılar ve GİB tarafından bildirilen kullanıcılarla birlikte değerlendirilir. Tek bir ciro cümlesi bütün mükelleflere aynı başlangıç tarihini vermez. Çalışma kitabında mükellefin dönem, faaliyet, kayıt ve bildirim kanıtları tutulur; geçiş tarihi ancak bu incelemeden sonra yazılır.
2026 e-Arşiv kurallarında tebliğ ve mükellef grubu korunur
573 sıra numaralı Tebliğ ile 1 Ocak 2026'dan itibaren öngörülen tutardan bağımsız kural esas alınır. Bununla birlikte 589 sıra numaralı Tebliğ, 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 korur. 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 kapsamındaki 2026 genel fatura düzenleme sınırı 12.000 TL, evrensel bir e-Arşiv eşiği olarak kullanılmaz. Yeni e-Arşiv raporlama uygulamasına ilişkin 5 Kasım 2026 test duyurusu ve 7 Aralık 2026'ya kadar istenen testler ayrı bir gündemdir. 5 Kasım 2026 duyurusunda üretim geçiş tarihi yer almamaktadır. Her sınıf için dayanak tebliğ ve müşteri onayı çalışma satırına yazılır.
UBL-TR, XML, XSLT ve yanıt türleri aynı şey değildir
UBL-TR 1.2.1 paketi Türkiye özelleştirmesidir. CustomizationID alanında TR1.2 bulunur. 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. Paket sürümü ile CustomizationID birbirinin yerine kullanılmaz. Kabulden önce kurulu derleme ve modüller kayda geçirilir ve bu alanlar ayrı ayrı doğrulanır.
İmzalı veya onaylı XML, mali açıdan esas alınan asıl belgedir; XSLT onun görsel sunumudur. Çelişkide XML önceliklidir. ZIP’lenmiş XML ve zarf taşıma katmanıdır. Sıradan PDF tek başına yeterli değildir; e-Arşiv için özel izinli PAdES durumu dahi UBL-TR XML ile birlikte değerlendirilir. Sistem yanıtı zarfın teknik durumunu anlatır, faturanın hukuki içerik onayını değil. Ticari senaryodaki KABUL, RED ve İADE uygulama yanıtları temel senaryoya genellenmez. e-Arşiv rapor paketinin kabulü de alıcının faturayı kabulü veya ödemesi değildir.
Odoo 19 Nilvera entegrasyonu kurulu sürüme göre doğrulanır
Resmî Odoo 19 entegrasyonu doğrudan GİB'e değil, Nilvera üzerinden iletişim kurar; test adresi https://apitest.nilvera.com, üretim adresi https://api.nilvera.com olarak incelenir. 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 fatura/e-Arşiv akışları, durum ve PDF alma ile genişletilmiş temel, kamu ve ihracat senaryoları kaynakta bulunur. 16 Ekim 2026'da geri taşınan isteğe bağlı l10n_tr_gib_invoice_scenarios paketi ticari, iade, tevkifatlı iade ve karşı taraf kabul-ret senaryolarını ekler.
Bu modüllerin kaynakta bulunması her Odoo 19 kurulumunda aynı ticari akışın hazır olduğu anlamına gelmez; kurulu derleme, modül sürümü, Nilvera sözleşmesi ve test sonucu birlikte doğrulanır. Odoo 20'deki yeni ticari, iade veya e-fiş akışları Odoo 19 kanıtı sayılmaz. Doğrudan GİB, başka entegratör, PayTR veya özel banka dosyası gereksinimi ise ayrı sağlayıcı ve geliştirme kapsamıdır.
e-Defter, berat ve beyanname süreçleri faturadan ayrılır
e-Defter; yasal defterler, imza veya mühür ve berat süreçleriyle ilgilidir. Faturanın alıcıya ulaştırılması veya vergi beyannamesi verilmesiyle aynı iş değildir. 2025 hesap dönemi için e-Defter kapsamı ve envanter defterinin 1 Ocak 2026'dan itibaren elektronik tutulabilmesi, süreç ve istisnalarla birlikte incelenir.
Odoo'nun e-Ledger çıktısı veya ZIP’lenmiş veri, nihai yasal e-Defter ve berat üretimi olarak sunulmaz. Berat, defter içeriğinin denetlendiği veya mali açıdan onaylandığı anlamına gelmez. Odoo 19 l10n_tr ve l10n_tr_reports yapıları da KDV, muhtasar veya kurumlar beyannamesi gönderimi değildir. TFRS ve BOBİ FRS uygulanabilirliği şirket özelinde değerlendirilir; e-Beyan ve e-Beyanname ayrı süreç ve yetkilendirme gerektirir.
TL, kuruş ve kur dönüşümü kayıt bazında mutabık kalır
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 yuvarlaması ile işlem vergisi yuvarlaması da ayrı kontrol edilir.
İ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. Migrasyon çalışma kitabında kaynak tutar, işlem para birimi, kur, tarih, kaynak, beklenen TL, gerçekleşen TL ve kalan fark yer alır. Her fark açıklanır ve sahibine bağlanır; toplamın yaklaşık görünmesi, belge bazındaki hataları kapatmak için kullanılmaz.
QuickBooks ve Zoho Books geçişi kaynak kanıtıyla planlanır
QuickBooks veya Zoho Books'tan geçiş, hazır bir bağlayıcı çalıştırmak yerine kaynak sürüm ve gerçek dışa aktarımların incelenmesiyle başlar. Hesap planı, cari hesaplar, ürünler, vergiler, açık faturalar, ödemeler, stok hareketleri, para birimleri ve kullanıcı yetkileri için hedef alanlar belirlenir. Dış kimlikler ve bağımlılık sırası, yüklemelerin tekrarlanabilmesini sağlar.
Her prova; kaynak ve hedef kayıt sayısı, borç/alacak toplamı, açık kalem bağlantısı, stok değeri, TL karşılığı ve reddedilen kayıt listesiyle karşılaştırılır. Bu iki ürün adı, Türkiye'deki pazar yaygınlığı veya mevcut Oakland müşterisi iddiası olarak kullanılmaz. Geçiş kararı, işletmenin kendi verileri ve imzalı mutabakatı üzerinden verilir.
Stok değerleme ve sonradan gelen maliyetler ayrıca sınanır
İthalat ve dağıtım senaryolarında satın alma, teslim alma, stok değerleme ve tedarikçi faturası aynı zaman çizelgesinde incelenir. Navlun, sigorta, gümrük ve diğer ek maliyetlerin hangi ürün ve değerleme yöntemine dağıtılacağı açıkça tanımlanır. 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.
Dönem kapandıktan sonra gelen maliyet faturası, yalnızca toplam maliyeti değiştiren bir kayıt olarak bırakılmaz. Önceki teslim, kısmi satış, kalan stok, maliyet farkı ve muhasebe dönemi etkisi test edilir. Migrasyonda hedef stok miktarı ile değerin yanı sıra bu geç maliyet bağlantıları da korunur; ürün başına tutar farkının nedeni ve onaylayanı kaydedilir.
Şube ve POS kabulü cihaz, belge ve kapanışla yapılır
Her şube için ağ, yazıcı, tarayıcı, para çekmecesi, müşteri ekranı ve ödeme terminali envanteri çıkarılır. Temel veya ticari fatura senaryosu, e-Arşiv alıcı sınıfı, fiş/fatura çıktısı, iade, açılış ve sayılan TL, farklı ödeme türleri, stok ve faturalanmamış siparişler aynı kabul turunda denenir.
Odoo 19 POS geçici kesintide sipariş oluşturabilir ve sonrasında eşitleyebilir; ancak ödeme terminali, müşteri kaydı ve gerçek zamanlı stok gibi bağlantı gerektiren işlevler ayrıdır. Senkronizasyon tamamlanmadan tarayıcı kapatılmaz, sayfa yenilenmez ve site verisi silinmez. Bağlantı döndüğünde yerel ve sunucu siparişleri sayı, referans ve durum bakımından karşılaştırılır; ödeme, stok, fatura ve kapanış kayıtları mutabık kalınmadan gün kapatılmaz.
Bordro, banka ve ödeme kapsamı bağımsız doğrulanır
Odoo 19'da Türkiye için l10n_tr_hr_payroll ve l10n_tr_hr_payroll_account bulunur; ücret kuralları, katkılar ve muhasebe bağlantıları mevcuttur. Ekranda görülen 2025 parametreleri, 2026 için geçerli değerler olarak kullanılmamalıdır. Çalışan ve kategori parametreleri, güncel mevzuatı bilen yetkili bir uzman tarafından incelenmelidir. Otomatik SGK/e-Bildirge veya GİB gönderimi ve banka üzerinden ödeme kanıtı varsayılmaz.
Resmî iyzico sağlayıcısı vardır; ödeme akışı, banka veri beslemesi ve mutabakatı aynı özellik değildir. İncelenen resmî Odoo 19 çekirdeğinde payment_paytr bulunmamıştır; bu yalnızca incelenen kaynakla sınırlı bir bulgudur. Banka senkronizasyonu kurum, sağlayıcı, izin ve aboneliğe bağlıdır; varsayılan on iki saatlik akış gerçek zamanlı değildir. Her banka ve ödeme senaryosu kendi sözleşme ve test kanıtıyla kabul edilir.
Dört uygulamalı kaynak, dört farklı çalışma ürünü sağlar
GİB/e-belge keşif çalışma kitabı; mükellef, alıcı, senaryo, teknik kanıt, entegratör ve sorumluluk satırlarını bir araya getirir. Migrasyon ve TL mutabakatı kitabı; ham kaynak tutardan kalan farkın onayına kadar her kaydı izler. Şube/POS kontrol listesi; cihazdan yeniden bağlanmaya kadar canlıya geçiş kanıtlarını toplar. Türkçe rol bazlı eğitim planı ise her kullanıcıyı kendi rutini ve istisnasıyla değerlendirir.
- GİB/e-belge keşif çalışma kitabını açın
- Migrasyon ve TL mutabakatını inceleyin
- Şube/POS kontrol listesini kullanın
- Türkçe rol bazlı eğitim planını açın
Bu kaynaklardaki kalın etiketli satırlar müşteri girdisiyle doldurulur. Parola, özel anahtar veya tam sertifika bilgisi istenmez. Her çalışma ürünü, diğer üç rehbere bağlantı verir ve aynı kabul dosyasında birleştirilebilir.
Kasiyer, şube müdürü, teslim alma ve sayım sorumlusu, satın alma sorumlusu, muhasebe sorumlusu, vergi sorumlusu, mali kontrol sorumlusu, bordro sorumlusu ve yönetici için görev ve kanıt sahipleri belirlenir.
Kapsam, TL teklif ve sonraki adım açıkça ayrıştırılır
Keşif ve fonksiyonel tasarım bağımsız bir aşamadır. Uygulama aşamaları onaylı tasarıma, migrasyon ise tekrarlanabilir yükler ve imzalı TL mutabakatına bağlanır. E-belge sağlayıcısı, özel senaryo, entegrasyon, Türkçe belge, cihaz ve eğitim çalışmaları teklif içinde görünür kalemlerdir; sayısal hazır paket toplamları yayımlanmaz.
Odoo abonelikleri, Nilvera veya diğer entegratör ücretleri, banka ve ödeme sağlayıcıları, donanım, altyapı ve müşterinin kendi emeği Oakland hizmetlerinden ayrılır. Barındırma kararı; özel uygulama gereksinimi, üretim ve yedek konumları, geri yükleme testi, dış hizmet aktarımları ve destek modeliyle verilir. TL kapsam çerçevesini inceleyin veya mevcut belge ve mutabakat örneğinizle keşif görüşmesi isteyin.
Bir fatura, bir mutabakat ve bir şube kapanışıyla başlayalım
Mevcut süreçleri, mükellef kapsamını, entegratörü, para birimlerini, kaynak sistemleri, cihazları ve kullanıcı rollerini paylaşın. Odoo 19'da doğrulanabilenleri; mali müşavir, sağlayıcı, banka veya özel geliştirme gerektiren kararları ayrı bir iş planına dönüştürelim.
İletişime Geçin
Buhaira Corniche, 43132 Sharjah,
Birleşik Arap Emirlikleri