Türkiye'de şube ve Odoo 19 POS canlıya geçiş kontrol listesi
Şube pilotunu ve canlıya geçiş sorumluluğunu netleştirin
6 Kasım 2026 tarihinde gözden geçirildi. Bu kontrol listesi uygulama provası içindir; mali belge ve vergi kararları ilgili uzmanlarca onaylanır.
Her şubenin satış biçimi, müşteri türü, cihazları, ağ koşulu, stok hareketi ve vardiya düzeni farklı olabilir. Tek bir merkez ekranındaki başarılı satış, bütün şubelerin hazır olduğunu göstermez. Pilot şube ve kapsam belirlenir; ardından aynı şablonun hangi bölümlerinin diğer şubelere uygulanacağı yazılır.
Şube, depo ve POS oturumu: Doldurulacak bilgi: __________________________________________
Vardiya ve canlıya geçiş sorumlusu: Doldurulacak bilgi: __________________________________
Mali müşavir ve e-belge karar sahibi: Doldurulacak bilgi: __________________________________
Cihaz/ağ ve sağlayıcı sorumluları: Doldurulacak bilgi: ____________________________________
Pilot; normal satış, iade, karışık ödeme, e-Fatura/e-Arşiv alıcısı, stok eksikliği, bağlantı kesintisi ve gün kapanışını kapsar. Şube özelinde farklı sonuç doğuran ayarlar ayrıca listelenir. Odoo 19 POS davranışı, Odoo 20 gösterimi veya sağlayıcı/özel geliştirme işleviyle karıştırılmaz.
Ağ ve cihazları gerçek şube koşullarında doğrulayın
Yazıcı, tarayıcı, para çekmecesi, müşteri ekranı, terazi veya ödeme terminali gibi cihazların model, bağlantı ve sürücü bilgileri tutulur. Kablosuz ağın kapsama alanı, yedek bağlantı, IP/güvenlik gereksinimi ve elektrik kesintisi prosedürü test edilir. Cihazın listede desteklenmesi, şubedeki fiili çalışma kanıtının yerine geçmez.
Cihaz/model/bağlantı/sürücü: Doldurulacak bilgi: _________________________________________
Ağ, yedek bağlantı ve kesinti testi: Doldurulacak bilgi: __________________________________
Fiş/fatura yazdırma ve Türkçe karakter sonucu: Doldurulacak bilgi: ________________________
Barkod, çekmece ve terminal fonksiyon testi: Doldurulacak bilgi: __________________________
Her cihaz için rutin ve hata durumu denenir. Yanlış kağıt genişliği, Türkçe karakter bozulması, uzun ürün adı, iade kopyası veya çekmece açılmaması gibi sonuçlar kayıt altına alınır. Donanım satın alma bedeli ile yapılandırma/test hizmeti ayrıdır. Türkiye'de yerel teknik ekip veya servis varlığı iddia edilmez; uzaktan uygulama ve şubedeki müşteri sorumlusu açıkça yazılır.
Kullanıcı yetkisi ve Türkçe görev akışını rol bazında sınayın
Kasiyer, şube müdürü, teslim alma ve sayım sorumlusu, muhasebe sorumlusu, vergi sorumlusu ve sistem yöneticisi için ayrı kullanıcı ve yetki testi yapılır. Herkesin her işlemi yapabildiği genel hesap yerine gerçek görev ve onay sınırları kullanılır. İade, fiyat değişikliği, iskonto, nakit farkı ve gün kapanışı yetkileri ayrıca değerlendirilir.
Rol ve kullanıcı: Doldurulacak bilgi: ____________________________________________________
İzin verilen/yasak işlem: Doldurulacak bilgi: _____________________________________________
Türkçe görev kartı ve ekran etiketi: Doldurulacak bilgi: __________________________________
Rutin ve istisna değerlendirmesi: Doldurulacak bilgi: ______________________________________
Görev kartında Odoo'nun tanınabilir İngilizce ekran adları korunabilir; açıklama ve hata prosedürü Türkçe yazılır. XML, XSLT, zarf, paket ve ticari yanıt terimleri kullanıcıya ayrı öğretilir. Sistem yanıtını “fatura onaylandı”, paket kabulünü “müşteri kabul etti” veya “ödeme alındı” diye yorumlamak engellenir.
TL kasa ve ödeme türlerini açılıştan mutabakata kadar izleyin
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.
Açılıştaki TL nakdi ve sayımı yapan kişi: Doldurulacak bilgi: ________________________________
Nakit/kart/diğer ödeme türü: Doldurulacak bilgi: __________________________________________
Sağlayıcı brüt/net ödeme ve ücret: Doldurulacak bilgi: ____________________________________
Kasa farkı, açıklama ve onay: Doldurulacak bilgi: _________________________________________
Karışık ödeme, iade, avans, yabancı para birimi ve kısmi tahsilat senaryoları çalıştırılır. iyzico ödeme akışı ile banka beslemesi ve mutabakatı aynı işlev değildir. 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. PayTR veya banka özel dosyası gerekiyorsa ayrı sağlayıcı/özel geliştirme kapsamı doğrulanır.
e-Fatura/e-Arşiv alıcısını ve belge senaryosunu satışta belirleyin
e-Fatura, kayıtlı kullanıcılar arasında GİB merkezli sistemdeki belge alışverişidir. 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. Müşteri kaydındaki kayıt durumu, belge türü ve raporlama kararı satıştan önce kontrol edilir.
Alıcının e-Fatura uygulamasına kayıtlı olma durumu ve kontrol tarihi: Doldurulacak bilgi: ________
Temel/ticari veya e-Arşiv senaryosu: Doldurulacak bilgi: ___________________________________
İade/düzeltme ve önceki belge bağlantısı: Doldurulacak bilgi: _____________________________
e-Arşiv raporlama sorumlusu: Doldurulacak bilgi: __________________________________________
2026 değerlendirmesinde 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. 5 Kasım 2026 duyurusunda üretim geçiş tarihi yer almamaktadır.
Kaynaklar: e-Fatura mevzuatı, e-Arşiv teknik kılavuzu ve test duyurusu.
XML, XSLT, sistem ve ticari yanıt kanıtlarını ayrı saklayın
UBL-TR 1.2.1 paket özelleştirmesi ile CustomizationID TR1.2 aynı alan değildir. 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. ZIP’lenmiş XML ve zarf taşıma katmanıdır. XML ile XSLT farklıysa XML esas alınır. Sıradan PDF yeterli değildir; özel izinli PAdES durumu da UBL-TR XML gerektirir.
XML paket/CustomizationID/ProfileID: Doldurulacak bilgi: __________________________________
XSLT görünüm ve XML öncelik kontrolü: Doldurulacak bilgi: _________________________________
Zarf/sistem yanıtı ve teknik hata: Doldurulacak bilgi: ____________________________________
Ticari KABUL/RED/İADE, yalnızca ticari senaryoda: Doldurulacak bilgi: ______________________
e-Arşiv ZIP’lenmiş XML rapor paketi ve sendDocumentFile/getBatchStatus sonucu: Doldurulacak bilgi: _____________________
Sistem yanıtı, zarfın içerik onayını değil teknik durumunu bildirir. Ticari yanıt temel senaryoya genellenmez. Rapor paketinin kabulü alıcı kabulü veya ödeme değildir. Resmî Odoo 19 entegrasyonu Nilvera üzerinden çalışır; kurulu derleme ve l10n_tr_gib_invoice_scenarios modülü doğrulanmadan ticari akış hazır sayılmaz. Nilvera'nın listede olması Odoo'nun belgelendirilmesi değildir.
Çevrimdışı satışı bağlantı gerektiren işlevlerden ayırın
Odoo 19 POS geçici kesinti sırasında sipariş oluşturabilir ve yönetebilir, ardından senkronize edebilir. Ancak ödeme terminalleri, müşteri kaydı, gerçek zamanlı stok ve diğer arka uç işlevleri bağlantı gerektirir. İstenen faturalar bağlantı döndükten sonra oluşturulur. Çevrimdışı sipariş, mali belgenin veya ödeme onayının çevrimdışı tamamlandığı anlamına gelmez.
Kesinti başlangıcı ve kapsam: Doldurulacak bilgi: _________________________________________
Çevrimdışı oluşturulan sipariş referansları: Doldurulacak bilgi: ___________________________
Kullanılamayan ödeme/stok/müşteri/fatura işlevi: Doldurulacak bilgi: _______________________
Kullanıcıya verilen Türkçe uyarı: Doldurulacak bilgi: ______________________________________
Senkronizasyon tamamlanmadan tarayıcı kapatılmaz, sayfa yenilenmez, site verisi veya önbellek silinmez. Kullanıcı başka cihazdan aynı siparişi tekrar oluşturmaz. Kesinti sırasında alınan fiziksel ödeme veya verilen belge ayrı kontrollü prosedürle kaydedilir; sistemde sonradan oluşturulan kayıtla eşleştirilir.
Kaynak: Odoo 19 POS çevrimdışı kullanım.
Yeniden bağlanma ve mükerrerlik önleme kanıtını tamamlayın
Bağlantı döndüğünde önce senkronizasyonun tamamlanması beklenir. Yerel siparişler ile sunucudaki siparişler sayı, referans ve durum bakımından karşılaştırılır. Sonra ödeme, stok, fatura, faturalanmamış sipariş ve kullanıcı oturumu incelenir. Eksik veya mükerrer kayıt bulunursa gün kapanışı yapılmaz.
Yerel/sunucu sipariş sayısı: Doldurulacak bilgi: _________________________________________
Referans ve durum farkları: Doldurulacak bilgi: ___________________________________________
Ödeme, stok ve fatura mutabakatı: Doldurulacak bilgi: _____________________________________
Mükerrerlik/eksiklik ve çözüm sahibi: Doldurulacak bilgi: __________________________________
Geçici teknik hata ile reddedilen mali belge ayrılır. Tekrar gönderim yapmadan önce zarf/paket kimliği ve son durum kontrol edilir; aynı belgenin mükerrer mali kayıt oluşturması önlenir. Ticari senaryodaki alıcı yanıtı ile teknik yeniden deneme birbirinden ayrılır. Bağlantı sonrası oluşturulan e-belge için XML/XSLT ve raporlama kanıtı yeniden toplanır.
Şube kapanışını ve ilk destek dönemini imzalı kontrollerle bitirin
Kapanışta sayılan TL, sistem nakdi, kart ve diğer ödeme türleri, sağlayıcı brüt/net tutarı, iadeler, faturalanmamış siparişler, stok ve muhasebe kayıtları karşılaştırılır. Her farkın nedeni ve sorumlusu yazılır. Sistem toplamına bakarak farkı doğrudan gelir/gider hesabına kapatmak yerine onaylı inceleme yapılır.
Sayılan TL nakdi ve sistemdeki TL nakdi: Doldurulacak bilgi: _______________________________
Ödeme sağlayıcısı ve banka mutabakatı: Doldurulacak bilgi: ________________________________
Faturalanmamış sipariş ve stok farkı: Doldurulacak bilgi: __________________________________
Kapanışı onaylayan şube/muhasebe: Doldurulacak bilgi: _____________________________________
İlk destek döneminde hata, kullanıcı eğitimi ihtiyacı, sağlayıcı sorunu ve yeni kapsam talebi ayrılır. Yanıt hedefleri yalnızca operasyonel onayla yazılır. Şube şablonu ancak pilot farkları kapatıldıktan sonra diğer şubelere uygulanır; her yeni şube kendi cihaz, alıcı, kesinti ve kapanış testini yapar.
Canlıya geçiş kararını bütün kanıtlarla verin
Son kontrol; cihaz listesi, rol değerlendirmeleri, örnek satış ve iade, XML/XSLT, zarf/paket yanıtı, ticari yanıt, e-Arşiv raporu, çevrimdışı siparişler, yeniden bağlanma, ödeme ve kapanış mutabakatını içerir. Her satır için kanıt bağlantısı, inceleyen ve tarih bulunur.
Açık cihaz veya kullanıcı sorunu: Doldurulacak bilgi: ______________________________________
Açık belge/ödeme/stok farkı: Doldurulacak bilgi: ___________________________________________
Sağlayıcı veya özel geliştirme işi: Doldurulacak bilgi: ____________________________________
Canlıya geçiş, ek prova veya durma kararı: Doldurulacak bilgi: _____________________________
Diğer çalışma kitapları:
Odoo 20'deki POS, çevrimdışı veya muhasebe özellikleri Odoo 19 kanıtı değildir. e-Defter/berat da POS fatura teslimiyle aynı iş değildir; e-Defter çıktısı nihai yasal berat olarak kabul edilmez. Bu ayrımlar, şube kullanıcısının teknik durumu mali veya hukuki sonuç olarak yorumlamasını önler.