GİB Test Ortamı Nedir? Tanımı, Kullanım Alanları ve Dikkatler

GİB test ortamı, e-belge yazılımının GİB teknik kurallarına göre canlı kullanım öncesinde denendiği ayrı çalışma alanı demektir. Bu alan, gerçek ticari işlem yerine kontrollü veri ve test kimlik bilgileriyle çalışır.

Bu rehber; e-Fatura entegrasyonu geliştiren şirketlere, yazılım ekiplerine, mali müşavirlere ve canlıya geçiş hazırlığı yapan işletmelere yarar. Test hesabı, senaryo seçimi, hata incelemesi ve güvenli geçiş konularındaki belirsizlikleri azaltır.

GİB test ortamı nedir?

GİB test ortamı, e-belge gönderme, alma ve yanıt süreçlerini canlı sistemden önce denemeyi sağlayan teknik ortam demektir. Burada amaç, yazılımın belge üretmesini ve beklenen yanıtları doğru işlemesini kontrol etmektir.

Test ortamındaki şirket, kullanıcı, sertifika, servis adresi ve kimlik bilgileri canlı ortamdan ayrı tutulur. Bu ayrım, yanlışlıkla gerçek alıcıya belge gönderilmesini ve üretim kayıtlarının test verileriyle karışmasını önlemeye yardımcı olur.

Bir test belgesinin başarılı gönderilmesi, belgenin gerçek ticari işlem olarak kabul edildiği anlamına gelmez. Test sonucu; teknik uyumluluk, bağlantı ve iş akışı açısından değerlendirilir, hukuki geçerlilik açısından değerlendirilmez.

Testlerde XML veya UBL-TR yapısı, zorunlu alanlar, imza süreci, zarf hareketi ve uygulama yanıtları incelenebilir. Kullanılan senaryolar, işletmenin e-Fatura veya başka bir e-belge uygulamasına göre değişir.

GİB test ortamı, yalnızca yazılımcıların kullandığı bir alan değildir. Muhasebe ekibi de alıcı seçimi, belge kontrolü, yanıt takibi ve hata bildirimlerini test ederek canlı süreçteki görevini önceden öğrenebilir.

Yanlış: Testte kabul edilen her belge canlıda otomatik olarak geçerli olur. Doğru: Canlı kimlik, yetki, imza, adres ve belge senaryosu ayrıca doğrulanmalıdır.

Test ortamının adresi, erişim yöntemi ve desteklenen akışları zaman içinde değişebilir. Bu nedenle güncel GİB teknik kılavuzunu, kullandığınız yazılımın belgelerini ve mali müşavirinizi birlikte kontrol edin.

GİB test ortamı nerede kullanılır?

GİB test ortamı, e-belge yazılımı canlıya alınmadan önce bağlantı ve belge akışını sınamak için kullanılır. Özellikle yeni entegrasyon, yazılım güncellemesi, sistem değişikliği ve yeni belge senaryosu öncesinde yararlıdır.

Bir ERP sistemi GİB servislerine bağlanacaksa geliştirici ekip önce test kimlikleriyle bağlantı kurar. Servis adresi, kimlik doğrulama, imza ve yanıt alma adımları ayrı ayrı izlenir.

Özel entegratör kullanan işletmelerde test ortamı, entegratör paneli ile işletmenin muhasebe yazılımı arasındaki akışı denemek için kullanılabilir. Hangi ekranların ve servislerin test edileceği, sağlayıcının teknik planına göre belirlenir.

Test alanı, gerçek fatura kesmek veya gerçek müşteriye belge ulaştırmak için kullanılmaz. Gerçek satış, tahsilat, sevk ya da iade işlemleri için canlı ortamın doğru yetkileri gerekir.

Yazılım güncellemesinden sonra eski belge şablonları, yeni alanlarla birlikte tekrar denenmelidir. Sadece bağlantının kurulması yeterli değildir; belge oluşturma, gönderme, yanıt alma ve kayıt işleme zinciri tamamlanmalıdır.

Bir departman değişikliği yapıldığında kullanıcı eğitimi de test ortamında yürütülebilir. Böylece personel, yanlış alıcı seçimi, eksik alan veya bekleyen durum gibi sorunları gerçek işlem oluşturmadan görür.

Test ortamı kullanılamıyorsa canlıda deneme yapılmamalıdır. Sağlayıcının deneme prosedürü, GİB duyuruları ve teknik kılavuzlar incelenmeli; gerekiyorsa mali müşavir ve yazılım sorumlusu birlikte karar vermelidir.

GİB test ortamını kimler kullanabilir?

GİB test ortamını, e-belge entegrasyonu geliştiren yazılım ekipleri, özel entegratör teknik personeli ve bu süreci yöneten mükellefler kullanabilir. Erişim yetkisi, uygulama türüne ve tanımlanan test hesabına bağlıdır.

Yazılım geliştiricisi teknik bağlantıyı ve veri formatını sınar. Muhasebe sorumlusu belge içeriğini, vergi bilgilerini ve iş akışını kontrol eder. Mali müşavir ise mevzuata uygun senaryonun seçilmesine yardımcı olur.

İşletme sahibi, testte her teknik ayrıntıyı kendisi yapmak zorunda değildir. Ancak hangi belgenin denendiğini, beklenen sonucu ve canlıya geçiş onayını yazılı olarak takip etmelidir.

Test için genellikle test şirket bilgileri, kullanıcı yetkileri, imza veya sertifika yöntemi, servis bilgileri ve örnek belge verileri gerekir. Bu bilgilerin hangilerinin zorunlu olduğu uygulamanın teknik dokümanında belirtilir.

Test hesabı ile canlı hesap aynı kullanıcı adı veya sertifikayı kullanmayabilir. Aynı bilgiyi iki ortamda denemek, yanlış servise bağlanma ve güvenlik açığı oluşturma riskini artırır.

Portal üzerinden manuel işlem yapan bir kullanıcı ile API entegrasyonu geliştiren kullanıcının test ihtiyacı farklıdır. Manuel kullanıcı ekran ve rol akışını, geliştirici ise servis çağrılarını ve yanıt işleme kodunu test eder.

Erişim başvurusu veya test hesabı açılışı için güncel prosedür izlenmelidir. Kullanıcı, eski bir blog yazısındaki adresi veya kimlik bilgisini doğrudan kullanmamalı; GİB duyurusunu ve sağlayıcısının güncel açıklamasını kontrol etmelidir.

GİB test ortamı ile canlı ortam arasındaki fark nedir?

GİB test ortamı deneme ve hata ayıklama içindir; canlı ortam ise gerçek e-belge işlemlerinin yürütüldüğü üretim alanıdır. İki ortamın amacı, erişim bilgileri, verileri ve sonuçları birbirinden ayrıdır.

En önemli fark, testte oluşturulan belgenin gerçek ticari belge olarak kullanılmamasıdır. Canlıda gönderilen belge ise ilgili uygulamanın kurallarına, alıcı durumuna ve muhasebe sürecine göre işlem görür.

Testte başarılı olan bağlantı, canlıya geçiş için yalnızca bir kanıttır. Canlı adres, sertifika, kullanıcı rolü, belge numaralandırması ve işyeri bilgileri ayrıca kontrol edilmeden geçiş yapılmamalıdır.

Yanlış: Testte kullanılan şirket bilgileri canlıda da kullanılabilir. Doğru: Her ortamın kimlik, adres, yetki ve veri seti ayrı doğrulanmalıdır.

Bu farklar, özellikle ilk kez entegrasyon yapan işletmeler için önemlidir. Canlı ortamda deneme amacıyla belge göndermek, alıcıya gereksiz bildirim veya muhasebe kayıtlarında düzeltme ihtiyacı doğurabilir.

GİB test ortamında test hesabı nasıl hazırlanır?

GİB test ortamında test hesabı hazırlamak için önce uygulama kapsamı, kullanıcılar, erişim bilgileri ve denenecek belge senaryoları yazılı hale getirilir. Hazırlık tamamlanmadan rastgele belge gönderilmemelidir.

İlk adım, kullanılan uygulamanın güncel teknik dokümanını edinmektir. Bu dokümanda test servis adresi, kimlik doğrulama yöntemi, sertifika gereksinimi, dosya biçimi, yanıt yapısı ve desteklenen işlemler açıklanır.

İkinci adım, test verisini hazırlamaktır. Firma bilgileri, vergi bilgileri, adres, birim, ürün, miktar, fiyat, vergi ve alıcı bilgileri kontrollü örneklerle oluşturulmalıdır.

Üçüncü adım, yetki ayrımı yapmaktır. Geliştirici, muhasebe kullanıcısı ve onay yetkilisi aynı erişim bilgilerini paylaşmamalıdır. Kullanıcı rolleri, yapılacak işlemin gerektirdiği en düşük yetkiyle sınırlandırılmalıdır.

• Test servis adresinin canlı servis adresinden farklı olduğu doğrulanmalıdır.
• Test kullanıcı adı, parola, sertifika veya API bilgisinin ayrı olduğu kontrol edilmelidir.
• Örnek belgelerde gerçek müşteri verilerinin gereksiz kullanılmadığı incelenmelidir.
• Gönderme, alma, yanıt ve hata kayıtlarının tutulacağı klasör veya ekran belirlenmelidir.
• Canlıya geçişten önce sorumlu kişi ve onay ölçütü yazılı olarak tanımlanmalıdır.

Hazırlık sırasında gerçek özel anahtar dosyaları, parola listeleri veya kişisel veriler ekip sohbetlerine yüklenmemelidir. Test verisi mümkün olduğunca maskelenmeli ve erişim kayıtları sınırlı tutulmalıdır.

Test hesabı açılışının nasıl yapıldığı her sağlayıcıda aynı olmayabilir. Bu nedenle burada sabit bir başvuru süresi veya ekran adı vermek yerine güncel GİB duyurusunu, entegratör açıklamasını ve mali müşavirinizi kontrol edin.

GİB test ortamında e-Fatura testi nasıl yapılır?

GİB test ortamında e-Fatura testi, belge oluşturma, teknik doğrulama, imzalama, gönderme, yanıt alma ve muhasebe sistemine işleme adımlarının birlikte denenmesiyle yapılır.

Önce basit bir satış senaryosu seçilir. Belge tarihi, numarası, para birimi, satıcı ve alıcı bilgileri, ürün satırları, miktar, birim fiyat, vergi ve toplam tutar kontrol edilir.

Sonra beklenen yanıt belirlenir. Belgenin sisteme ulaşıp ulaşmadığı, zarfın işlenme sonucu ve uygulama yanıtının yazılım tarafından doğru yorumlanıp yorumlanmadığı kayıt altına alınır.

1. Test şirketi ve alıcı bilgilerini, güncel teknik kurallara uygun şekilde tanımlayın.
2. Tek bir basit belge oluşturun ve zorunlu alanları belge öncesinde kontrol edin.
3. Belgeyi test servisine gönderin ve işlem kimliğini kaydedin.
4. Gelen teknik veya uygulama yanıtını beklenen sonuçla karşılaştırın.
5. Başarılı ve hatalı senaryoları ayrı kayıtlarla tekrar deneyin.
6. Sonuçları muhasebe yazılımına aktararak kayıt ve rapor ekranını doğrulayın.

Test senaryosunda yalnızca başarılı belgeyi denemek yeterli değildir. Eksik vergi alanı, hatalı alıcı, yanlış toplam veya yinelenen numara gibi kontrollü hatalar da yazılımın doğru uyarı verdiğini göstermelidir.

e-Fatura akışının teknik ayrıntıları için e-Fatura ürün sayfasındaki kapsamı ve kullandığınız entegrasyon dokümanını birlikte inceleyin. Ürün sayfası, GİB’in güncel teknik kılavuzunun yerine geçmez.

Vergi hesaplaması içeren senaryolarda belge türü, vergi kodu ve istisna bilgisi ayrıca doğrulanmalıdır. Tevkifatlı işlemlerin mantığını anlamak için tevkifatın tanımını açıklayan rehbere bakılabilir.

GİB test ortamında e-Arşiv ve e-İrsaliye test edilir mi?

GİB test ortamında e-Arşiv ve e-İrsaliye testinin mümkün olup olmadığı, ilgili uygulamanın güncel teknik yapısına ve kullandığınız sağlayıcının sunduğu test akışına bağlıdır.

e-Arşiv senaryosunda alıcı türü, belge bilgileri, gönderim yöntemi, raporlama akışı ve çıktı biçimi birlikte kontrol edilir. E-Fatura mükellefine ve farklı alıcı türlerine ilişkin kurallar aynı kabul edilmemelidir.

e-İrsaliye senaryosunda malın sevki, irsaliye bilgileri, taşıma ayrıntıları ve alıcı yanıtı önem taşır. Fatura testi başarıyla tamamlandı diye sevk sürecinin de otomatik olarak doğru çalıştığı varsayılamaz.

İşletme, önce hangi belge türünün kapsamda olduğunu belirlemelidir. Ardından test hesabının ilgili belgeyi destekleyip desteklemediği, test endpointinin bulunup bulunmadığı ve sonuçların nasıl raporlandığı yazılı olarak teyit edilmelidir.

Bu ayrım, e-belge kontör planlamasında da önemlidir. Canlı işlemlerde gelen ve giden belgelerin her biri bir kontör düşürür; test işlemlerinin kontör hesabına etkisi ise sağlayıcının koşullarından kontrol edilmelidir.

Kontörün tek havuzda farklı e-belgelerde kullanım mantığını öğrenmek için havuz kontör açıklamasına bakabilirsiniz. Testte belge sayısını ve canlıdaki beklenen hacmi birbirine karıştırmayın.

e-Arşiv ve e-İrsaliye kapsamı için e-Arşiv fatura ve e-İrsaliye sayfalarındaki güncel bilgileri, GİB teknik dokümanlarıyla karşılaştırın. Emin olmadığınız noktada güncel GİB duyurusunu ve mali müşavirinizi kontrol edin.

GİB test ortamında API anahtarı ve durum kodu nasıl yönetilir?

GİB test ortamında API anahtarı, yazılımın test servisine kimlik doğrulaması yapmasını sağlayan gizli erişim bilgisi demektir. Bu anahtar, kullanıcı adı veya parola gibi korunmalı ve canlı anahtardan ayrılmalıdır.

API anahtarı kaynak koduna, açık hata ekranına veya ortak dosyaya yazılmamalıdır. Güvenli değişken deposu, sınırlı erişim, kayıtlı kullanım ve gerektiğinde anahtar yenileme yöntemleri tercih edilmelidir.

API anahtarının işlevi hakkında ayrıntı için API anahtarı rehberini okuyabilirsiniz. Rehberdeki genel güvenlik ilkeleri, GİB entegrasyonu dışındaki servisler için de geçerli olabilir.

Durum kodu, bir belge veya servis isteğinin hangi aşamada olduğunu bildiren teknik sonuç demektir. Kodun anlamı, tek başına belgenin hukuki olarak kabul edildiğini göstermez; yanıt metni ve işlem kaydı da incelenmelidir.

Başarılı, bekleyen, reddedilen veya teknik hatalı sonuçların yazılımda ayrı işlenmesi gerekir. Kullanıcı ekranında yalnızca renk göstermek yerine kod, açıklama, zaman ve işlem kimliği birlikte saklanmalıdır.

Durum kodlarını anlamak için durum kodu açıklamasını inceleyin. Her kodun kesin yorumu için yine ilgili GİB veya entegratör teknik kılavuzundaki açıklama esas alınmalıdır.

Test ve canlı anahtarların karışmasını önlemek için ortam adları açıkça yazılmalıdır. Yanlış: Testte çalışan anahtarı canlı yapılandırmasına kopyalamak. Doğru: Canlı anahtarı ayrı üretmek, yetkisini sınırlamak ve geçişte kontrollü biçimde tanımlamaktır.

GİB test ortamında hangi hatalara dikkat edilir?

GİB test ortamında en sık görülen sorunlar, yanlış servis adresi, hatalı kimlik doğrulama, eksik zorunlu alan, geçersiz imza, şema uyumsuzluğu, yinelenen numara ve beklenmeyen yanıt işlemeyle ilgilidir.

Bağlantı kurulamazsa önce ağ erişimi, endpoint, sertifika ve test hesabı kontrol edilmelidir. Belge reddedilirse XML yapısı, alan uzunluğu, kod listesi, tarih biçimi ve toplam hesapları sırayla incelenmelidir.

Hata kaydı yalnızca hata mesajından oluşmamalıdır. İstek zamanı, işlem kimliği, belge numarası, kullanılan ortam, yanıt kodu ve yazılım sürümü kaydedilirse aynı sorun daha hızlı tekrarlanabilir.

Uzman notu: Hata mesajını düzeltmeden önce aynı belgeyi tekrar tekrar göndermeyin; yinelenen kayıt riskini azaltmak için önce işlem kimliğini ve son durumu kontrol edin.

Bir zaman aşımı, belgenin kesinlikle gönderilmediği anlamına gelmeyebilir. Servis yanıt vermemiş olabilir, fakat işlem arka planda tamamlanmış olabilir. Bu durumda yeni gönderimden önce sorgulama yapılmalıdır.

Yanlış: Kırmızı uyarı görüldüğünde belge kesin olarak reddedilmiştir. Doğru: Uyarı metni, durum kodu, servis yanıtı ve kayıt zamanı birlikte incelenmelidir.

Hata çözümü sırasında her seferinde bir değişken değiştirmek daha sağlıklıdır. Aynı anda vergi, alıcı, imza ve numara değiştirilirse hangi düzeltmenin sonucu etkilediği anlaşılamaz.

Bir hata teknik dokümanda açıklanmıyorsa sağlayıcının destek kaydına örnek işlem kimliğiyle başvurulmalıdır. Gerçek müşteri verilerini destek mesajına eklemeden önce maskeleme yapılmalı ve güncel GİB duyurusu kontrol edilmelidir.

GİB test sonuçları nasıl doğrulanır ve saklanır?

GİB test sonuçları, beklenen senaryo ile gerçekleşen teknik yanıtın karşılaştırılmasıyla doğrulanır. Başarılı gönderim, doğru yanıt işleme ve muhasebe kayıtlarına doğru aktarım birlikte değerlendirilmelidir.

Her senaryo için bir test kartı hazırlanabilir. Kartta amaç, kullanılan veri, beklenen sonuç, gerçekleşen sonuç, işlem kimliği, tarih, sorumlu kişi ve varsa hata düzeltmesi bulunmalıdır.

Belge içeriği ile yazılım ekranı karşılaştırılırken satır toplamı, vergi, genel toplam, alıcı bilgisi ve belge numarası kontrol edilmelidir. Görsel çıktı doğru görünse bile kaynak XML ayrıca incelenmelidir.

Test kayıtları, canlıda kullanılacak resmi saklama sürecinin yerine geçmez. Gerçek e-belgelerin saklama, erişim ve ibraz yükümlülükleri farklıdır; güncel mevzuat ve mali müşavir görüşü esas alınmalıdır.

Testte gerçek kişilerin adı, adresi veya iletişim bilgisi kullanılmışsa gereksiz kopyalar silinmeli veya anonimleştirilmelidir. Ekip, yalnızca test amacı için gerekli verilere erişmeli ve dosya paylaşım izinlerini sınırlamalıdır.

Yazılım güncellendiğinde önceki test sonucu otomatik olarak geçerli sayılmaz. Sürüm, şablon, sertifika veya servis değişikliği varsa kritik senaryolar yeniden çalıştırılmalı ve eski sonuçla yeni sonuç karşılaştırılmalıdır.

Canlıya geçiş kararı, tek bir başarılı belgeye dayanmamalıdır. En azından bağlantı, başarılı senaryo, kontrollü hata, yanıt sorgusu, kayıt aktarımı ve yetki kontrolü için yazılı onay alınmalıdır.

Küçük işletme GİB test ortamını nasıl kullanmalı?

Küçük işletme, GİB test ortamını günlük satışları durdurmadan sınırlı ve planlı senaryolarla kullanmalıdır. En pratik yöntem, işletmenin en sık yaptığı belge akışını örnek verilerle baştan sona denemektir.

Örneğin küçük bir eczane, dağıtıcıdan aldığı ürünlerle ilgili e-Fatura akışını test etmek isteyebilir. Eczane sahibi önce alıcı ve satıcı bilgilerinin test verisini oluşturur, ardından bir ürün satırı ve vergi bilgisiyle örnek belge hazırlar.

İkinci aşamada belge gönderilir ve işlem kimliği kaydedilir. Muhasebe sorumlusu, gelen yanıtın ekranda doğru göründüğünü; yazılımın belgeyi bekleyen, kabul edilen veya hatalı durumuyla uygun klasöre işlediğini kontrol eder.

Eczane tıbbi cihaz alım veya satımı da yapıyorsa belge senaryosu ayrıca incelenmelidir. Ürün bilgisi, alıcı türü ve varsa özel vergi uygulaması için tıbbi cihaz faturası rehberini karşılaştırma amacıyla kullanabilir.

Testte kullanılan firma, müşteri ve ürün bilgileri örnek olmalıdır. Gerçek alıcıya ait verileri kopyalamak yerine maskeleme yapılması, küçük işletmelerde bile veri güvenliği açısından daha doğru bir yaklaşımdır.

Eczane yalnızca portal kullanıyor ve dış yazılım entegrasyonu bulunmuyorsa API testi yapmak gerekmeyebilir. Bu durumda ekran yetkileri, belge oluşturma, yanıt takibi ve çıktı alma süreçleri öncelikli olarak denenmelidir.

İşletme canlıya geçerken günlük belge hacmini ve kontör planını ayrıca hesaplamalıdır. Test sonucunu canlı tüketim hesabı sanmamalı; gelen ve giden belgelerdeki kontör düşümünü sağlayıcının güncel koşullarıyla kontrol etmelidir.

GİB test ortamında güvenlik ve veri gizliliği nasıl korunur?

GİB test ortamında güvenlik, test ve canlı erişim bilgilerinin ayrılması, örnek verilerin korunması ve işlem kayıtlarının sınırlı kişilerce tutulmasıyla sağlanır.

Test parolası veya API anahtarı e-posta gövdesinde, ekran görüntüsünde veya kaynak kodunda paylaşılmamalıdır. Erişim bilgileri gerektiğinde yetkili kişiye güvenli kanal üzerinden iletilmeli ve kullanılmayan anahtarlar iptal edilmelidir.

Test verisi hazırlanırken gerçek müşteri adı, vergi numarası, adresi ve banka bilgisinin tamamını kullanmak çoğu senaryoda gerekli değildir. Alanların biçimini koruyan örnek veya maskeli veri genellikle yeterlidir.

İmza sertifikası kullanılan yapılarda sertifikanın özel anahtarı yalnızca yetkili sistemde tutulmalıdır. Test için ayrı sertifika veya sağlayıcının önerdiği güvenli yöntem bulunuyorsa üretim sertifikasıyla deneme yapılmamalıdır.

Log kayıtları hata çözümü için gerekli olsa da kişisel verileri gereksiz biçimde içermemelidir. Saklama süresi, erişim yetkisi ve silme yöntemi işletmenin bilgi güvenliği politikasına göre belirlenmelidir.

Bir yazılım geliştiricisi, test ortamındaki açık bir anahtarı fark ederse anahtarın sadece silinmesi yeterli olmayabilir. Anahtar yenilenmeli, erişim kayıtları incelenmeli ve sağlayıcının güvenlik prosedürü uygulanmalıdır.

Güvenlik uygulamalarının teknik ayrıntısı sağlayıcıya göre değişebilir. Bu nedenle güncel API dokümanı, entegratör güvenlik talimatı ve kurum içi yetki politikanız birlikte incelenmelidir.

GİB test ortamında hangi belge alanları kontrol edilir?

GİB test ortamında belge alanları kontrol edilirken kimlik, tarih, numara, alıcı, satır, vergi, toplam ve yanıt bilgileri birlikte incelenmelidir. Sadece PDF görünümünü kontrol etmek teknik uyumluluğu kanıtlamaz.

Kimlik alanlarında satıcı ve alıcının unvanı, vergi bilgisi, adresi ve alıcı türü karşılaştırılır. Yanlış alıcı tipi, doğru görünen bir belgenin teknik veya işlevsel olarak hatalı işlenmesine neden olabilir.

Belge numarası ve tarih, işletmenin numaralandırma kuralıyla uyumlu olmalıdır. Testte kullanılan numaralar canlı numara serisiyle karıştırılmamalı; geçiş öncesinde canlı seri başlangıcı ayrıca teyit edilmelidir.

Satır kontrolünde ürün veya hizmet adı, miktar, birim, birim fiyat, iskonto ve vergi bilgisi incelenir. Satır toplamları ile genel toplamın yazılım tarafından aynı matematiksel mantıkla hesaplandığı doğrulanmalıdır.

İstisna, tevkifat veya özel vergi senaryosu kullanılıyorsa ilgili kod ve açıklama birlikte kontrol edilir. Muhasebe ekibi, teknik kodun ticari işlemle gerçekten eşleştiğini mali müşavirinden teyit etmelidir.

Yanıt tarafında işlem kimliği, durum kodu, hata açıklaması ve zaman damgası incelenir. Yanıtın kullanıcı ekranında doğru belgeyle eşleşmesi, özellikle yoğun işlem yapan işletmelerde kritik bir kontroldür.

Kontrol sonuçları tablo veya test kartında işaretlenebilir. Bir alanın boş olması her zaman hata değildir; alanın zorunlu olup olmadığı ilgili e-belge şeması ve güncel teknik kılavuzdan doğrulanmalıdır.

GİB test ortamında canlıya geçiş ne zaman yapılır?

GİB test ortamından canlıya geçiş, belirlenen kritik senaryolar başarıyla tamamlandığında ve üretim bilgileri ayrı doğrulandığında yapılmalıdır. Bunun için yalnızca teknik ekipten değil, işletme süreçlerinden de onay alınmalıdır.

Önce test kapsamı kapatılır. Başarılı belge, hatalı veri, bekleyen yanıt, tekrar gönderim, kullanıcı yetkisi ve muhasebe aktarımı gibi senaryoların sonucu yazılı şekilde kaydedilir.

Sonra canlı yapılandırması hazırlanır. Canlı servis adresi, üretim kullanıcıları, sertifika, numara serisi, firma bilgileri, çıktı ayarları ve bildirim alıcıları test bilgilerinden bağımsız kontrol edilir.

Canlıya geçiş mümkünse düşük işlem yoğunluğu bulunan bir zaman aralığında planlanmalıdır. İlk gerçek belgelerden sonra durum ekranı, gönderim kuyruğu, yanıtlar ve muhasebe aktarımı sorumlu kişi tarafından yakından izlenmelidir.

İlk canlı işlemden önce personel, testte kullandığı ekranın canlı olduğunu açıkça görmelidir. Ortam adı görünmüyorsa kullanıcı arayüzünde renk, başlık veya erişim rolü gibi ek ayraçlar kullanılabilir.

Geçiş planında geri dönüş yöntemi bulunmalıdır. Sorun çıktığında yeni belge gönderimini durdurma, destek kaydı açma, işlem listesini dışa aktarma ve mali müşavire bilgi verme adımları önceden belirlenmelidir.

GİB veya sağlayıcı tarafında bakım, sürüm değişikliği ya da yeni teknik kural duyurulduğunda eski test onayı yeniden değerlendirilebilir. Güncel GİB duyurusunu ve mali müşavirinizi kontrol etmeden kesin geçiş tarihi belirlemeyin.

GİB test ortamında portal ve entegrasyon testi nasıl ayrılır?

Portal testi, kullanıcının web ekranında belge oluşturma ve takip etmesini; entegrasyon testi ise yazılımın servisler üzerinden otomatik işlem yapmasını sınar. İki test türü aynı sonucu hedeflese de kontrol noktaları farklıdır.

Portal testinde giriş, rol, firma seçimi, belge alanları, taslak kaydı, gönderim ve yanıt ekranı incelenir. Kullanıcının doğru menüyü bulması ve hata mesajını anlayabilmesi de test kapsamına alınır.

Entegrasyon testinde API isteği, kimlik doğrulama, XML veya UBL üretimi, imza, gönderim kuyruğu, yanıt sorgusu ve hata yönetimi incelenir. Kullanıcı arayüzü doğru görünse bile arka plandaki aktarım ayrıca doğrulanır.

Ücretsiz portal kullanan bir işletme, yalnızca manuel işlem yapıyorsa API anahtarı testine ihtiyaç duymayabilir. ERP bağlantısı, otomatik aktarım veya toplu belge süreci varsa entegrasyon testi gerekir.

Portal ile entegrasyon aynı anda kullanılıyorsa belge sahipliği ve numara yönetimi netleştirilmelidir. Aynı belgenin iki kanaldan gönderilmesi, yinelenen işlem ve takip güçlüğü oluşturabilir.

Test planında hangi kanalın resmi işlem kanalı olacağı yazılmalıdır. Bir kullanıcı portalı, diğer kullanıcı ERP yazılımını kullanıyorsa yetki ve kontrol sorumlulukları birbirinden ayrılmalıdır.

Bu ayrım küçük işletmelerde gözden kaçabilir. İşletme, yalnızca ihtiyacı olan akışı test etmeli; kullanmadığı API, toplu aktarım veya otomatik yanıt özellikleri için gereksiz karmaşıklık oluşturmamalıdır.

GİB test ortamında mevzuat açısından nelere dikkat edilir?

GİB test ortamındaki sonuçlar, mevzuat yükümlülüklerinin yerine getirildiğini tek başına göstermez. Test, teknik işleyişi doğrular; mükellefiyet, belge türü, süre, saklama ve bildirim yükümlülükleri ayrıca değerlendirilir.

Bir işletmenin hangi e-belge uygulamasına dahil olacağı; faaliyet alanı, mükellefiyet durumu, işlem türü ve güncel düzenlemelere göre değişebilir. Test hesabı açılması, işletmenin otomatik olarak ilgili uygulamaya geçtiği anlamına gelmez.

Belge iptali, red, iade, düzeltme veya yeniden düzenleme gibi süreçler testte ayrıca modellenmelidir. Bu işlemlerin yöntemi, belgenin türüne ve güncel mevzuatla teknik kılavuzlara göre farklılaşabilir.

Yıllık güncellenen hadler, süreler ve idari yaptırım tutarları için rakamı eski içerikten almamak gerekir. Güncel GİB duyurusunu, yürürlükteki mevzuatı ve mali müşavirinizi kontrol ederek işlem yapın.

Test belgesini gerçek fatura, irsaliye veya makbuz yerine kullanmak doğru değildir. Gerçek belge düzenlenmesi gerektiğinde canlı ortam, doğru kullanıcı ve uygun belge türü kullanılmalıdır.

Mevzuat kontrolü yapılırken teknik ekip tek başına karar vermemelidir. Mali müşavir, muhasebe sorumlusu ve entegrasyon yöneticisi; belge senaryosunun ticari işlemle uyumunu birlikte değerlendirmelidir.

Bir test sonucu teknik açıdan olumlu, mevzuat açısından ise eksik olabilir. Bu nedenle test raporunda teknik başarı ile mali uygunluk ayrı sütunlarda gösterilmeli ve onaylayan kişi açıkça yazılmalıdır.

Özet: 5 maddede GİB test ortamı nedir?

GİB test ortamı, e-belge sistemlerini canlı kullanımdan önce kontrollü verilerle sınamaya yarayan teknik çalışma alanıdır. Testin amacı gerçek belge düzenlemek değil, bağlantı ve iş akışındaki sorunları önceden bulmaktır.

• GİB test ortamı, e-Fatura ve uygun teknik akışların canlı öncesinde denendiği ayrı ortam demektir.
• Test hesabı, kullanıcı, sertifika, API anahtarı, servis adresi ve veri seti canlı ortamdan ayrı tutulmalıdır.
• Başarılı test, belgenin hukuki geçerliliğini veya işletmenin mevzuat kapsamını tek başına kanıtlamaz.
• Bağlantı, belge alanları, yanıtlar, durum kodları, kontrollü hatalar ve muhasebe aktarımı birlikte sınanmalıdır.
• Canlıya geçişten önce güncel GİB teknik dokümanı, sağlayıcı açıklaması ve mali müşavir görüşü kontrol edilmelidir.

Test sırasında gerçek müşteri verisini gereksiz kullanmayın, gizli anahtarları paylaşmayın ve her işlemin kimliğini kaydedin. Hata çıktığında aynı belgeyi körlemesine tekrarlamak yerine önce son durumu sorgulayın.

Test kapsamınız e-Arşiv, e-İrsaliye veya başka bir e-belge içeriyorsa ilgili uygulamanın güncel test imkanını ayrıca teyit edin. Portal ve API akışlarının aynı olduğunu varsaymayın.

Canlıya geçişte tüm üretim bilgilerini yeniden doğrulayın. Mevzuat tutarları ve tarihleri yıllık güncellenebildiği için güncel GİB duyurusunu ve mali müşavirinizi kontrol edin.

Testten canlıya geçerken efaturakontor.com üzerinde tüm e-belgelerde geçerli havuz kontör paketlerini 100'den 500.000 kontöre kadar inceleyebilirsiniz. Ücretsiz e-Fatura portalı, Sovos altyapısına aynı gün tanımlama ve 12-18 ay kullanım süresi seçenekleri için güncel paket bilgilerini kontrol edin.