Professional Documents
Culture Documents
Foriba R&D - Sık Sorulan Sorular
Foriba R&D - Sık Sorulan Sorular
GİB e-Fatura sisteminde kayıtlı bulunan bir alıcı mükellefe, kağıt fatura
7
kesilebilir mi?
9
Bedelsiz (0 tutarlı) fatura kesilebilir mi?
10 e-Fatura' da bulunan tutar bilgisi virgülden sonra kaç hane olmalıdır?
Mevzuat Serbest bölgede bulunan, Türkiye'de faaliyet gösteren ve GİB'de kayıtlı bir
11 e-fatura mükellefine kesilen ihracat faturası alıcına nasıl iletilir veya iletilme
zorunluluğu var mıdır?
Mevzuat
Fatura ve uygulama yanıtı UBL' inin oluşturulması hakkında nasıl bir yol
3
izlenmelidir?
11 Zarf nedir?
14 Etiket nedir?
Genel Teknik
Sorular Gönderilen fatura veya uygulama yanıtı gönderilmiş statüye ulaşmamış ise
19
tekrar mı gönderilmeli ?
Gönderici taraf bir fatura veya uygulama yanıtı gönderdiğinde ancak fatura
21
veya uygulama yanıtı alıcı sistemde görünmediği durumda ne yapılmalıdır?
22 Fatura ID nasıl oluşturulur?
WS API
e-Fatura' nın doğrudan durumunun sorgulanabileceği bir web servis
6
metodu var mıdır?
Web serviste fatura, uygulama yanıtı veya sistem yanıtı sorgulamaları nasıl
10
yapılır?
Vergi Usül Kanunu’na göre 7 güne kadar geriye dönük e-Fatura gönderilebilir. Düzenlenme tarihi 7 günden eski e-Faturaların
efatura, geçmiş,
gönderilmesi özel entegratörlük sistemi tarafından engellenmez, ancak usül cezası mevcuttur. Bu şekildeki gönderilen tüm e-
geri, ceza
Faturalar için sorumluluk gönderici mükellefe ait olacaktır.
Kağıt faturalarda ihtilaf olmaması için fatura tutarı yazıyla ifade edilmektedir. e-Fatura, mali mühürle imzalandığı için üzerindeki efatura, tutar,
rakamları değiştirme ihtimali olmadığından ayrıca yazıyla belirtilmesine gerek yoktur. yazı, sayı
e-Fatura sistemiyle GİB üzerinden alıcılara iletilen ve işlemi başarıyla tamamlanarak GİB sisteminde sorgulandığında zarfının durumu
1300 “BASARIYLA TAMAMLANDI” statü koduna ulaşan fatura ve uygulama yanıtları iptal edilemez ya da yok sayılamaz. Ticari fatura
efatura, iptal, gib,
gönderildiyse alıcıdan reddetmesi istenebilir, ancak kabul cevabı verilmişse ya da temel fatura gönderilmişse alıcı tarafından iade e-
1300
faturası gönderilmesi gerekmektedir. Temel faturalar için ayrıca alıcı tarafında muhasebeleşmesi yapılmadığı taktirde noter ya da
KEP (Kayıtlı Elektronik Posta) kanalları üzerinden iptal işlemleri gerçekleştirilebilir.
Kullanılabilir ancak tarafların ticari fatura düzenleyebilmesi için önceden anlaşmış olmaları gerekmektedir. Ticari fatura senaryosunda ticari, fatura,
temel faturadan farklı olarak faturaya, kabul ve red uygulama yanıtları gönderilmektedir. kabul, red
Alıcı kendisine gelen temel faturayı sistemine almak zorundadır, yok sayamaz. Eğer gelen Temel Fatura kendisine ait değilse ya da
temel, fatura,
kabul etmiyorsa iki yöntemle faturayı reddedebilir; muhasebesine kaydedip iade e-Faturası gönderebilir ya da muhasebesine
red, iade
kaydetmeden noter kanalıyla itiraz edebilir.
kağıt, fatura, gib,
e-Fatura kullanımı sisteme kayıtlı mükellefler arasında zorunludur ve sistemde bulunan bir mükellefe kesilecek kağıt faturalar yok
zorunlu,
hükmündedir.
mükellef, alıcı
kağıt, efatura,
Hayır yoktur. Mükellef zorunlu olduğu halde e-Fatura’ya geçmemişse gönderici kağıt fatura kesebilir ve gönderici bu durumda
gib, zorunlu,
herhangi bir yaptırımla karşı karşıya kalmamaktadır. Böyle bir durumda sorumluluk alıcıya aittir.
ceza
bedelsiz, fatura,
%100 iskonto ve 0 Kdvli olacak şekilde 0 tutarlı fatura kesilebilmektedir. 0, tutar
Faturanın GİB kontrollerinden geçebilmesi için kalem tutarında virgülden sonra 8 hane, dip toplamda virgülden
tutar, vigül, hane
sonra 2 hane kullanılmalıdır.
ihracat faturalarında akış Gönderici - Gelir İdaresi Başkanlığı- Gümrük Ticaret Bakanlığı arasında gerçekleşir. Malın gönderildiği
firmaya fatura e-Fatura sistemi üzerinden gönderilmemektedir. Bu faturanın mail veya matbu olarak alıcıya iletilmesi yükümlülüğü ihracat, fatura
göndericidedir.
Vergi Usul Kanunun 242. Maddesinin Maliye Bakanlığına verdiği yetkiye dayanılarak çıkarılmıştır. Mali Mühür, 397 Sıra No’lu Vergi
Usul Kanunu Genel Tebliği çerçevesinde Başkanlık için TÜBİTAK bünyesindeki Kamu Sertifikasyon Merkezi (yetkili tek kuruluş)
tarafından üretilmektedir.
Elektronik Mali Mühür sertifikaları, tüzel kişiler ile kurum, kuruluş ve işletmeler tarafından elektronik belge olarak oluşturulacak e-
fatura, e-defter ve diğer yasal belgelerin;
• Bütünlüğünün, kaynağının ve içeriğinin garanti altına alınması,
mali, mühür,
• Elektronik ortamda muhataplarına iletilmesi ve elektronik ortamda saklanması sırasında güvenliğinin ve gizliliğinin sağlanması
imza
amacıyla tasarlanmıştır.
e-Fatura uygulamasını kullanmak için Mali Mühür temini zorunludur. Mali mühür elektronik bir belgedir ve bir USB cihaz içerisinde
KAMU SM tarafından sahibine teslim edilmektedir.
Mali Mühür, e-Fatura uygulamasına başvuru sırasında temin edilmekte olup, mükellef birden fazla lokalden e-Fatura uygulamasını
kullanmak istediğinde mükellefin aynı mali mührüne sahip ek USB cihazlar ilave olarak KamuSM’den temin edilebilmektedir.
Mali Mühürle ilgili detaylı bilgilere http://mm.kamusm.gov.tr/ adresinden ulaşılabilir.
Mükellefler aynı anda birden fazla özel entegratörle çalışabilirler, ancak her sistemde kendi VKN-TCKN’leri için birbirinden farklı entegratör, özel,
gönderici birim-posta kutusu etiketleri ve fatura serileri kullanmak zorundadırlar. farklı
e-Fatura uygulamasına başvururken mali mühür başvurularının da yapılması gerekmektedir. Mükellefin mali mührü, özel mali, mühür,özel,
entegratörlük sisteminde gönderilen fatura-uygulama yanıtlarının imzalanmasında kullanılmamaktadır, bu belgeler özel entegratör, imza,
entegratörlüğün mali mührüyle imzalanır. Yalnızca özel entegratöre kayıt ve iptal işlemleri için mükellefin mali mührü gerekmektedir. mükellef
e-Fatura uygulaması aynı anda sadece bir yöntemle kullanılabilmektedir. Mevcut durumda mükellefin ilk özel entegratör VKN-TCKN
ve etiket kaydı GİB sistemine gönderilip aktifleştikten bir süre sonra, GİB mükellefin GİB Portal hesabını kapatmaktadır. Aktifleşme
sonrası GİB tarafından belirlenen bir süre daha GİB Portal hesabına erişilip eski zarf, fatura ve uygulama yanıtlarına
özel, entegratör,
ulaşılabilmektedir, ancak herhangi bir yeni gönderimi ya da alımı yapılamaz. Bu sebeple mükellefler özel entegratöre geçişin hemen
gib, portal, hesap
öncesinde GİB Portal hesaplarında bulunan tüm fatura ve uygulama yanıtı zarflarını indirerek kendi sistemlerinde ya da özel
entegratörlük sisteminde saklamalıdır. GİB’in özel entegratör geçişi sonrası portal erişim süresini kısma ya da tamamen kapatma
seçeneği her zaman mevcuttur.
özel, entegratör,
Mükellefin tüm özel entegratör kayıtlarının iptali durumunda GİB Portal hesabı otomatik olarak tekrar açılacaktır. portal, otomatik,
gib, hesap
efatura, earşiv,
e-Fatura ve e-Arşiv fatura farklı özel entegratörler aracılığı ile kullanılabilir. özel, entegratör,
farklı
Hata Foriba sisteminden alınıyor ise;
Müşteri https://api.fitbulut.com/tools/ublValidator/ adresinden veya e-Fatura görüntüleyici üzerinden fatura UBL’i içerisinde bulunan
şema-şematron hatasının detayına erişerek hatayı düzeltmelidir.. sendUBL, 1230,
Hata alıcı sistemden alınıyor ise; şema, şematron,
Öncelikle faturanın e-Fatura görüntüleyicide geçerli olduğu kontrol edilmelidir, eğer fatura e-Fatura görüntüleyicide geçerli ise alıcı hata
sisteme, sistemini güncellemesi hakkında bilgi verilmelidir. Fatura e-Fatura görüntüleyicide geçerli değil ise faturanın şema-şematron
kontrolünden neden ve nasıl geçtiği teknik ekip tarafından incelenerek bilgi verilmelidir.
İlgili zarfların alıcısı farklı bir entegratör firma ile çalışıyor olabilir, alıcı sistemin çalıştığı entegratör firmanın hangi firma olduğu efatura, gib,
incelenmelidir. Zarfların hangi entegrator firmaya iletildiği konusunda GİB' den bilgi alınmalıdır. 1300, fatura, yok
UBL oluşturulurken Örnek .Net istemci uygulaması, GİB' in yayınlamış olduğu doküman ve XML veriler referans alınmalıdır(Temel- ubl, fatura,
Ticari-İstisna-Tevkifat-İhracat tüm fatura tipleri ve uygulama yanıtı örnekleri api dökumantasyonunda mevcuttur). İlgili proje ve uygulama, yanıtı,
dokümanlara "https://api.fitbulut.com/docs//" adresinden ulaşılabilir. xml
İhracat ve yolcu beraber faturalarının alıcısı GTB(Gümrük ve Ticaret Bakanlığı) 'dir, faturalar GTB' ye iletilir ve GTB' den ONAY veya
RED cevabı alınabilir.
ihracat, yolcu,
Fatura durumu 1300 ise fatura GTB' ye başarılı bir şekilde iletilmiş demektir, GTB' den gelen cevabı fatura göndericisi alabilir veya
beraber, gtb, alıcı
GTB' den gelen cevab portal de de görülebilir. İhracat fatura sürecinde alıcı müşteriye fatura iletilmemektedir, müşterinin talep etmesi
durumunda faturayı düzenleyen taraf müşterisine faturayı iletmekle yükümlüdür.
Bir ticari faturaya sekiz gün içerisinde birden fazla uygulama yanıtı gönderilebilir ve son gönderilen uygulama yanıtı geçerlidir. Alıcı ticari, fatura,
sistem 8 gün içerisinde birden fazla uygulama yanıtı gönderilmesine izin vermiyor ise bilgilendirilerek sisteminin güncellenmesi uygulama, yanıtı,
sağlanmalıdır. süre
iade, uygulama,
Gelen faturaya karşılık iade faturası kesilebilir. IADE faturasının gönderilme amacı, fatura kesen firmaya hızlı yoldan "aldığım
yanıt, temel,
malı/hizmeti iade edeceğim ve buna karşılık ilerleyen zamanda iade faturası keseceğim" mesajını iletmektir.
fatura
Temel,Ticari, İhracat ve Yolcu Beraber olmak üzere dört adet e-Fatura bulunmaktadır. Mükellefler birbirlerine e-Fatura sistemi
üzerinden Temel ya da Ticari fatura gönderebilirler. Ticari faturalara, temel faturalardan farklı olarak, alıcı tarafından yine e-Fatura
efatura, senaryo,
uygulaması üzerinden KABUL ya da RED cevapları gönderilebilir. Temel faturalara ise e-Fatura uygulaması üzerinden cevap
gtb, gib, ihracat,
verilememektedir. Taraflar aralarında anlaşarak birbirlerine hangi türde fatura düzenleyeceklerini serbestçe belirleyebilirler. ihracat
temel, ticari
işlemleri için İhracat ve Yolcu beraber fatura türleri oluşturulmuştur, bu faturalar GTB'ye iletilmekte olup GTB'den KABUL veya RED
cevabı alınmaktadır.
e-Fatura uygulamasını kullanan tüm sistemler aralarında 4 standart elektronik belge türüyle haberleşir:
• Zarf
• Fatura
• Uygulama Yanıtı efatura, tür,
• Sistem Yanıtı belge, zarf,
Bu belgeler Birleşmiş Milletler Ticaret Komisyonu(UN-CEFACT) tarafından belirlenen UBL 2.0 (Universal Business Language) fatura, sistem,
standart formatıyla tanımlanmıştır ve Türkiye’deki e-Fatura uygulaması için GİB tarafından UBL-TR 2.1 versiyonu oluşturulmuştur. Bu uygulama, yanıt
versiyon, global UBL standardının Türkiye’deki e-Fatura uygulamaları için özelleştirilmiş halidir. Böylece tüm mükellefler, birbirlerine
aynı tipte veri gönderip alabilmektedir. Fatura ve uygulama yanıtı belgelerinde mükelleflerin ya da özel entegratörlerin mali
mühürleriyle oluşturulmuş dijital imzalar da bulunmaktadır.
e-Fatura uygulamasını kullanmak için yeterli alt yapıya sahip olmayan kullanıcıların uygulamadan yararlanabilmelerini sağlamak efatura, portal
amacıyla geliştirilen ve e-Fatura uygulamasına ait temel fonksiyonları bünyesinde barındıran bir web uygulamasıdır.
Path hatası vermesinin nedeni imzager dosyasının okunamamasıdır. Dosya dizininde ya da pc isminde karakter hatası mevcut ise imzager, path,
imzagerde hata alınmaktadır. Eğer Mac bir bilgisayar ise imzasız dosyalar masaüstü yerine c klasörüne atılmalıdır. hata, mali, mühür
e-Fatura uygulamasında gönderilen tüm UBL fatura, uygulama ve sistem yanıtları, zarf denilen bir taşıyıcı elektronik belge içerisinde
sistemler arasında taşınmaktadır. Tüm zarflarda gönderici-alıcı bilgilerinin (VKN-TCKN ve etiketler) yanında zarfın tanımlayıcı zarf, nedir
numarası (UUID-Universal Unique Identifier) ve oluşturulma zamanı gibi bilgiler bulunmaktadır.
e-Fatura sisteminde gönderilen ticari faturalara alıcılar tarafından yine sistem üzerinden elektronik belge olarak gönderilen KABUL uygulama, yanıtı,
veya RED belgelerine uygulama yanıtı denilmektedir. nedir
Gönderilen fatura ya da uygulama yanıtı içeren zarflara, GİB ve alıcı sistemler tarafından gönderilen ve zarfın o sistemdeki işlem
sistem, yanıtı,
durumunu koduyla birlikte taşıyan e-Fatura uygulamasına özel sistemsel mesajlardır. Bir fatura ya da uygulama yanıtının GİB’den
nedir
geçip son kullanıcı tarafından başarıyla alındığı bilgisi bu belgelerle gönderici sistemine aktarılır.
Etiket, e-Fatura sistemine kayıt olan mükelleflerin VKN/TCKN bilgisinin yanında Gönderici Birim ve Posta Kutusu olarak ikiye ayrılan
etiket, gb, pk,
sistemdeki adresleridir. Gönderici Birim(GB) etiketinden (ör. defaultgb@firmaismi.com) sadece fatura gönderilir. Posta Kutusu(PK)
gönderici, birim,
etiketinden (ör. defaultpk@firmaismi.com) ise e-Fatura alınır ve gelen faturalara uygulama yanıtı gönderilir. Mükellefler aynı VKN ya
posta, kutusu
da TCKN için birden fazla GB veya PK etiketine sahip olabilir.
GİB, gönderilen zarf boyutunun maksimum 5 MB olmasına izin vermektedir. Bu zarf boyutu aşılmayacak şekilde zarf içerisindeki fatura, ek, dosya,
faturalara dosya eklenebilmektedir. ubl
e-Fatura’lar UBL formatında elektronik belgeler olduğundan faturanın görseli kağıt faturalardaki gibi bir anlam ifade etmemektedir. e-
Fatura’nın görüntülenebilmesi için HTML ve PDF gibi yaygın formatlar kullanılır ve bu formatlar UBL Fatura formatı içerisinde bulunan
XSLT dosyaları kullanılarak oluşturulur. Bu XSLT dosyaları e-Fatura’ nın göndericisi tarafından, gönderilen faturanın içerisine efatura, görsel,
eklenmekte ve görsel olarak e-Fatura’ nın nasıl görüneceğini belirlemektedir. Bu sebeple herhangi bir gelen faturanın görselinde bir görüntü, pdf,
sorun olduğunda, faturanın göndericisiyle görüşülmesi gerekmektedir. html, hata
e-Fatura görsellerinde problem olsa dahi faturanın kendisi geçerli sayılmaktadır. Ayrıca fatura görseli ile elektronik içeriği arasında
herhangi bir farklılık (ör. tutar) varsa, fatura verisi için yalnızca elektronik UBL içeriği baz alınmaktadır.
e-Fatura’ların HTML görselleri, e-Fatura içerisindeki XSLT dosyaları ile oluşturulmaktadır. Özel entegratörlük sisteminde, özel bir
tanımı olmayan tüm mükellefler için ortak bir XSLT dosyası kullanılır. Bu XSLT’ nin ürettiği görseli değiştirmek isteyen müşteri
logo, kalem,
kullandıkları GB etiketi için kendilerine özel bir XSLT hazırlayarak özel entegratörlük sistemini kullandığı yönteme (portal, adaptör,
görsel, fatura,
web servis entegrasyonu v.b.) göre bu XSLT dosyasının gönderilen faturalarda kullanılmasını ve istenilen formatta görüntülenmesini
görüntü
sağlayabilir. Sadece standart görüntüdeki firma logosunu eklemek-değiştirmek isteyen kullanıcılar, bu işlemi ilgili portal menüsünden
gerçekleştirebilirler ya da operasyon ekiplerine logolarını ileterek işlemin kendileri adına yapılmasını sağlayabilirler.
GIB’in entegrasyon ve özel entegratörlük müşterilerine koyduğu kurallara göre, alıcı sistemler yalnızca şema, şematron ve imza
kontrolleri uygulayabilirler. Özel entegratörlük sisteminden GİB’ e gönderilen tüm zarflar bu kontrollerden geçirilerek gönderildiği için
alıcı sistemden herhangi bir hata döndüğünde bunun sebebinin belgenin alıcısıyla çözülmesi gerekmektedir. Bazı sistemler uygun
olmayan ek kontroller koyarak geçersiz hatalar dönebilmektedir.
efatura, hata,
Karşı sisteme gönderilirken GİB ya da karşı sistemden hata alan, ya da alıcı sisteme iletilemeyen zarftaki faturalar ya da uygulama
karşı, sistem,
yanıtları yeni bir zarfla tekrar gönderilmelidir. Fatura serilerinin atlanmaması için tekrar gönderilen faturaların hata alan zarftaki
alıcı
faturalarla aynı Fatura ID’ye sahip olması gereklidir, ancak tekrar gönderim teknik olarak yeni bir gönderim olduğundan zarf, fatura,
uygulama yanıtı UUID’leri farklı olmalıdır. GİB ya da alıcı sistemden herhangi bir hata kodlu sistem yanıtı dönülen ya da alıcı sisteme
iletilemeyip 1215 - DOKUMAN GONDERIMI BASARISIZ. TERKAR GONDERME SONLANDI durumuna düşen tüm zarflardaki fatura
ve uygulama yanıtları hükümsüz sayılmaktadır.
Gönderilen tüm zarflar öncelikle GİB sistemi tarafından işlenmekte, işlem başarılı olduktan sonra da sistem yanıtı belgesiyle işlem
sonucu iletilmektedir. Daha sonra GİB bu zarfları alıcı sisteme iletmekte ve yine alıcı sistemden gelen başarılı-başarısız işlem
durumunu içeren sistem yanıtı belgelerini göndericiye iletmektedir. Herhangi bir fatura ya da uygulama yanıtı zarfı GİB’ e iletildikten 1220, statü,
sonra ilgili sistem yanıtlarının dönülmesi ya da bunların iletilmesi gerek GIB gerek alıcı sistemlerde yaşanabilen sıkıntı ve yoğunluk gönderilmiş,
durumlarından dolayı gecikebilmektedir. Bu durumlarda özellikle alıcı tarafından ilgili belgenin işlendiği ya da hata aldığı bilgisi fatura, uygulama,
dönülmediyse (GİB statü kodu 1220 – HEDEFTEN SISTEM YANITI GELMEDI), belgenin alıcısıyla temasa geçerek zarfın neden yanıtı
işlenmediğine dair bilgi alınmalıdır. Özel entegratörlük sistemi, GİB’ e gönderilmiş ve sonuçlanmamış belgelerin tekrar gönderilmesini
engellemektedir.
ticari, fatura,
Gönderilen ticari faturalar alıcı tarafından alındıktan 8 gün sonra otomatik olarak kabul edilmiş sayılmaktadır. Sistem başarıyla cevap, red,
gönderilmiş bir faturanın (temel ya da ticari) ya da uygulama yanıtının tekrar gönderilmesini engellemektedir. kabul, gelmedi,
tekrar, gönderim
Tüm e-Fatura zarfları GİB’in merkezi sisteminden geçmekte ve zaman zaman iletimde gecikmeler gerçekleşmektedir. Genel olarak 1 ulaşmayan,
günden daha uzun süren gecikmelerde göndericiden gönderilen fatura veya uygulama yanıtı zarfının UUID bilgisi öğrenilmeli ve daha sistem,
sonra GİB statüsü kontrol edilerek zarfın nerede takıldığı öğrenilmelidir. Özellikle etiket değiştirme ya da hatalı etiket girilmesi gibi düşmemiş,
durumlarda GİB alıcının farklı bir sistemine bu belgeleri ileteceği için VKN-TCKN ve etiket kontrollerinin de tekrar yapılması fatura, uygulama,
gerekmektedir. yanıtı
Foriba Bulut e-fatura sisteminde FaturaID (fatura numarası) oluşturmada firmaların tercih edebileceği iki yöntem mevcuttur. Birinci
yöntemde fatura numaralarının Foriba tarafından otomatik oluşturulması ve fatura serisinin otomatik takip edilmesidir. Bu yöntem ile
fatura serileri atlanmadan otomatik olarak takibi yapılmaktadır.
Bu yöntem ile oluşturulan fatura numaraları firmanın belirlediği iki adet ön ek ile başlar.
Ör: FT02018000000001
Fatura numarasında yer alan üçüncü karakter 0-7 arasında değişmektedir. Bu karakter sizin geçmiş tarihli fatura kesmenize imkan
faturaID, format,
verir ve buna göre değişkenlik gösterir. Bugün tarihli oluşturulan bir fatura "FT02018000000001" fatura serisi ile başlayacaktır. Eğer
önek
bir gün öncesine ait bir fatura düzenlenir ise fatura numarası "FT12018000000001", iki gün öncesine ait bir fatura düzenlirse fatura
numarası "FT22018000000001" şeklinde üretilecektir.
İkinci Yöntem ise fatura numarasının firma tarafından oluşturulmasıdır. Serinin devamı ve takibi firmaya aittir. Bu şekilde firmalar
fatura numaralarını ya kendi muhasebe programlarının içerisinde oluşturmakta ya da manuel olarak fatura numarası vermektedirler.
Fatura numaralarını 3 harften oluşan ön ek ile başlatabilirler.
Ör: FTD2018000000001 şeklinde fatura serisi başlatılabilir ve takibi sağlanabilir.
10 - Fatura alındı.
20 - Fatura yanıtı kaydedildi.
30 - Fatura yanıtı imzalandı.
40 - Fatura yanıtı GIB' e gönderildi.
50 - Fatura yanıtını GIB kabul etti. portal, gelen,
60 - Fatura yanıtına GIB' den hata döndü. fatura, statü,
70 - Fatura yanıtı GIB' den alıcıya iletilemedi, otomatik tekrar gönderilecek. kodlar
80 - Fatura yanıtı alıcıya iletilemedi, tekrar gönderilmeli.
90 - Alıcı fatura yanıtını başarıyla aldığını henüz onaylamadı.
100 - Fatura yanıtı alıcıya iletildi.
110 - Fatura yanıtına alıcıdan hata döndü.
Hata Kodu Açıklama
1000 Parametre Hatası
1010 Şema validasyonu hatası
1020 Şematron hatası
1080 UTF-8 validasyonu hatası
1100 Gönderici VKN/TCKN ve etiketi GIB' e kayıtlı değil
1101 Alıcı VKN/TCKN ve etiketi GIB' e kayıtlı değil
1110 Gönderici VKN/TCKN ve etiketi kayıtlı değil
1111 Alıcı VKN/TCKN ve etiketi kayıtlı değil
1112 VKN/TCKN ve etiket kayıtlı değil
1200 İstemci IP adresinin bu işleme yetkisi yok
1300 Çağrı limiti aşıldı
3010 Zarf UUID sistemde mevcut
3011 Fatura UUID sistemde mevcut
3012 Fatura ID sistemde mevcut
3013 Fatura ID otomatik üretiliyor, gönderilmemeli
3014 Fatura ID otomatik üretiliyor, müşteri fatura numarası gönderilmeli
3201 Uygulama yanıtı UUID sistemde mevcut efatura, hata,
3210 Uygulama yanıtı verilen fatura bulunamadı kod, web, servis
3211 Uygulama yanıtı verilen faturanın zarfı bulunamadı
3215 Fatura alıcıya ait değil
3220 Uygulama yanıtı verilen fatura ticari fatura değil
3230 Faturaya önceki gönderilen uygulama yanıtı sonuçlanmamış
3240 Fatura geliş tarihi 8 günü geçtiği için yanıt verilemez
3410 UUID'ye ait fatura bulunmadı
3420 CustInvID'ye ait fatura bulunmadı
3430 Fatura gönderilen VKN ve etikete ait değil
3440 Fatura görüntüsü doküman türü desteklenmiyor
3450 Fatura görüntüsü oluşturulamadı
3610 UUID'ye ait belge bulunmadı
3630 UBL gönderilen VKN/TCKN ve etikete ait değil
3910 UUID'ye ait belge bulunamadı
3920 Belge gönderilen VKN/TCKN ve etikete ait değil
3950 UUID'ye ait zarf bulunamadı
3960 Zarf gönderilen VKN/TCKN ve etikete ait değil
uygulama, yanıtı,
Uygulama yanıtı UBL' i içerisinde "KABUL" veya "RED" cevabı ile alakalı açıklayıcı bilgi "<cbc:Note>" tagi altına yazılmalıdır. açıklama, sebep,
not, red, kabul
sendUBL, şema,
"https://api.fitbulut.com/tools/ublValidator/ " adresinde bulunan şema-şematron kontrolü ile fatura UBL’i
şematron, ubl,
içerisindeki hata bulunarak düzeltilebilir, hata düzeltilemez ise teknik ekibe yönlendirme yapılabilir.
hata
sendUBL servisini kullanırken DocData parametresi alanına oluşturulan UBL dosyasının zipli hali, byteArray'e çevrilmiş şekilde sendUBL,
eklenmelidir. SoapUI gibi bir programla test ederken yada Soap requestlerini gönderirken base64 çevrimi gereklidir. DocData, zip,
Ek olarak ZIP dosyası ismi ile içerisinde bulunan XML dosyanın ismi aynı olmalıdır. xml
Müşteri kendisine gelen uygulama yanıtlarını sistemine almak için ilk olarak getUBLList servisini max 1 günlük tarih aralığı
parametresi ile çağırmalı ve uygulama yanıtı UUID bilgilerini almalıdır. İkinci adımda ise almış olduğu uygulama yanıtı UUID' lerini uygulama, yanıt,
getUBL servisinin request parametresinde kullanarak, uygulama yanıtlarının datalarını sistemine almalıdır. Uygulama yanıtı UBL'i getUBLList,
içerisinde <cac:DocumentReference> tag'i altındaki <cbc:ID> alanında bulunan UUID bilgisi uygulama yanıtının hangi faturaya getUBL
geldiği bilgisini vermektedir.
PDF görüntülerde oluşan sorun PDF dönüştürme kütüphaneleri ile ilgilidir, PDF dönüşümü için farklı kütüphaneler bulunmaktadır,
diğer sistemler farklı kütüphaneler kullanabilmektedir, Foriba sisteminde kütüphane değiştirilse bile bazı faturalar başarılı
getInvoiceView,
görüntülenebilirken bazıları görüntülenemeyecetir. Hatanın core sistem tarafından anlaşılması mümkün olmadığı için hatalı
pdf, görüntü,
oluşturulan görüntüler için ikinci kütüphaneyi kullanma durumu bulunmamaktadir. Bu nedenle fatura görüntüsünün bozuk olduğu
hata
ancak açılıp bakıldığında anlaşılabilir.
Çözüm olarak müşteri faturasının görüntüsünü HTML formatta oluşturarak PDF' e dönüştürme işlemini kendisi yapabilir.
Kullanılan servise göre "Çağrı limiti aşıldı" hatasının birden fazla sebebi olabilir, müşterinin kullanmış olduğu servis logları incelenerek
hatanın sebebi incelenmelidir.
"Çağrı limiti aşıldı" hatası altında sık karşılaşılan durumlar aşağıdaki gibidir;
1- Tüm servisler de alınabilen "IP adresi çağrı limitini aştı, daha sonra tekrar deneyiniz: " hatası;
Müşterinin WS API' yi doğru kullanmamasından kaynaklanmaktadır. çağrı, limiti,
2- GetEnvelopeStatus web servis metodu için "UUID sayısı izin verilen limitin üzerinde: " hatası; aşıldı, web,
Müşteri tek bir istekle 20 adet zarf durumu sorgulayabilmektedir, bu sınırın üzerine çıkılması durumunda yukarıda belirtilen hata servis, hata
alınacaktır.
3- GetUBLList web servis metodu için "Başlangıç ve bitiş tarihleri arası en fazla *** dakika olabilir" hatası;
Müşteri ile paylaşılan dokümanlarda da belirtildiği üzere getUBLList web servis metodu ile max bir günlük sorgu yapılabilmektedir, bir
günden fazla zaman aralığı sorgulanması durumunda belirtilen hata alınacaktır.
Doğrudan e-Fatura durumunun sorgulanabileceği bir web servis metodu bulunmamaktadır. GİB sisteminde de olduğu gibi zarfın
efatura, durum,
durumları sorgulanabilir ve zarfın statüsüne göre hareket edillebilir. Zarf durumlarının sorgulanması ile ilgili detaylı bilgi,
sorgulama, zarf
https://api.fitbulut.com/docs/ adresinde "Foriba Bulut e-Fatura Müşteri WS API v2.0" dokümanında bulunmaktadır.
Login web servis methodu bulunmamaktadır. Login işlemi için basic authentication kullanılmaktadır. SoapUI programının login,
kullanılması durumunda, programa wsdl dosyası eklenerek proje oluşturulduktan sonra web servisin istenilen metodunun request authentication,
parametreleri doldurulmalı ve kullanıcı ile paylaşılan kullanıcı adı, şifresi authentication alanına girilerek istek yapılmalıdır. soapUI
eFatura-eArşiv-eDefter web servis adreslerinden WSDL'ler güvenlik gereği alınamamaktadır, ilgili dokümanlar wsdl ,url, adres,
"https://api.fitbulut.com/" adresinde müşteri ile paylaşılmaktadır. erişim
Bulut e-Fatura
web, servis, test,
WS URL - Test : https://efaturawstest.fitbulut.com/ClientEInvoiceServices/ClientEInvoiceServicesPort.svc
url, canlı, adres
WS URL - Canlı : https://efaturaws.fitbulut.com/ClientEInvoiceServices/ClientEInvoiceServicesPort.svc
Fatura,uygulama yanıtı veya sistem yanıtı sorgulamaları tarih aralığı veya UUID ile yapılabilmektedir. Tarih aralığıyla sorgulama
yapılacak ise FromDate ve ToDate parametreleri aramanın başlangıç-bitiş tarihleri olarak kullanılır ve belgelerin Foriba Bulut e-Fatura efatura,
veritabanına kayıt tarihine göre arama yapılır. Bu tarih, gönderilen belgelerin sistemde oluşma tarihleri, gelen belgelerin ise GİB’ den uygulama, yanıtı,
alınma ve işlenme tarihleridir. FromDate ve ToDate tarihleri arasında maksimum 1 günlük süre bulunmalıdır, bu sayede 1 günlük sistem, yanıtı,
belge UUID listeleri tek seferde alınabilir. UUID ile sorgulama yapılacak ise en fazla 20 UUID kullanılabilir. Fatura, uygulama yanıtı ve sorgu
sistem yanıtı sorgulamalarının zarflı olarak tarih aralığı formatı ile sorgulama yapılması tavsiye edilmektedir.
toplu, html,
Toplu olarak HTML belgelerinin indirilebileceği bir web servis metodu bulunmamaktadır. HTML belge müşteri sistemine indirilerek, görüntü, belge,
müşteri sisteminden toplu sorgulama yapılabilir. metod, web,
servis
GTB Referans No bilgisi GTB tarafından gönderilen uygulama yanıtında bulunmaktadır. Uygulama yanıtına erişmek için ise ilk olarak
gtb, referans, no,
getUBLList metodu kullanılmalı ve bu metotdan alınan uygulama yanıtı UUID' si getUBL metodunun requestinde kullanılarak,
ihracat
uygulama yanıtının datasına erişilip GTB Referans No bilgisine ulaşılır.
POSTMAN servis örnekleri bulunmamaktadır, müşteri paylaşılan "EINV_SERV_CLIENTSERVICES_SAMPLE_REQUESTS-soapui-
soapui, proje,
project" adlı SoapUI projesi ile testlerini gerçekleştirebilir.
test, postman,
SoapUI projesi “https://api.fitbulut.com/docs/" adresinde Bulut e-Fatura \ WS API 2.0 dokümantasyonu içerisinde Bulut EFatura
servis
Müşteri WS API v2.0\EK2 - Teknik Belgeler\FIT Bulut e-Fatura Müşteri WS API v2.0\SOAP dosya yoluna gidilerek bulunabilir.
Soru Soru
1 e-Arşiv faturaları hangi alıcılara kesilebilir?
İptal edilen faturanın GİB’ den düşümü yani GİB’ den iptali söz
6
konusu mudur?
Herhangi bir zamanda gönderilmiş olan fatura, fatura düzenleme tarihinden sonra
fatura, düzenleme, tarih, iptal, geri
olmak koşulu ile hangi ayın raporlaması yapılıyorsa o tarihe iptal faturası kesilebilir.
İptal edilmiş bir faturanın seri numarası iptal edildiği bilgisi ile GİB' de kayıt edilir.
Faturanın seri numarası tekrar kullanılamaz. Fatura numarası sıralı olarak devam seri, numara, iptal, fatura, tekrar
etmelidir.
Operasyonel portalden mail ayarları kontrol edilmelidir. Mail ayarları doğruysa,
operasyonel, portal, mail, hata, süreç
teknik ekipten yardım istenilebilir.
Tekli fatura gönderimi ve çoklu (zarf) fatura gönderimi yapılır. zarf, tekli, toplu, çoklu, gönderim, earsiv
e-Faturada bir zarf içindeki faturaların hepsinin alıcısı aynı olma zorunluluğu var
iken e-Arşiv ürününde bu zorunluluk ortadan kaldırılmıştır. Her birine receiver bilgisi zarf, alıcı, alias, receiver, müşteri, vkn,
girilmesi zorunlu değildir. Ayrıca etiket(alias) bilgisi geçerli bir değer olmak zorunda tckn
da değildir.
Eğer zarfta hata yok ise içindeki bir faturada şematron veya şema hatası varsa
istek geçersiz sayılır ve zarf sisteme alınmaz. Zarf olsa bile tek bir faturaymış gibi
şema şematrondan geçer, hata varsa hata mesajı dönülür. Eğer zarf şema - şema, şematron, zarf, hata, validasyon,
şematrondan başarılı olarak geçer ve bazı faturalarda hata alınırsa, o faturalar gönderim, istek
hariç diğer faturalar sisteme kayıt edilir.
Faturanın iptali gerçekleştirilir. Daha sonra tekrar doğru alıcıya fatura kesilir. fatura, alıcı, yanlış
Bulut portal üzerinden tarih aralığı seçilerek arama yapılması gerekmektedir. portal, rapor, earsiv
e-Arşiv web servis adreslerinden WSDL' ler güvenlik gereği alınamaz. wsdl, adres, url, dosya
Operasyonel Portal üzerinden euromessage tanımlı VKN, test e-postası
euromessage, smtp, mail, gönderim,
gönderemez. Ancak smtp ayarları yapılmış VKN test sisteminde fatura
test
göndererek mail gönderimini test edebilir.
Zarf gönderimi sürecinde, faturalar zarf XML' inin içine tek tek eklenir ve o zarf
zarf, zip, ayrı, gönderim
ziplenerek gönderilir.
Prefixler istenilen şekilde yönetilir. Örnek olarak(ns1,ns2,ns3 yerine
prefix, önek, xml, zarf, ubl
cac,cbc,ccc,cdc gibi)
e-Arşiv fatura UBL' i oluşturulurken şemada yer alan sıralama önemlidir. GİB' in bu
adreste "http://www.efatura.gov.tr/efaturamevzuat.html" UBL-TR1.2.1 Paketi içinde şema, şematron, ubl, sıralama
yayınladığı klavuzlarda şema bilgileri mevcuttur.
getStatus web servis metodu ile faturanın bütün durumları sorgulanabilir. getStatus, statü, fatura, metod, durum
getReportData metodu ile rapor XML'i alınır ve raporun içeriği kontrol edilebilir. rapor, xml, içerik, metod, kontrol
1- Mükellefin anlık çıktı parametresi kapalı olabilir. Bulut operasyon ekibi tarafından
sendInvoice, outputtype, number, zip,
müsteri ayarlarından bu özellik açılmalıdır.
file
2- Mükellef zip içerisinde 1 den fazla fatura XML' i göndermiş olabilir.
Signature tagının e-Arşiv fatura UBL' inde bulunması zorunludur. Bu alan faturanın
signature, zorunlu, tag, ubl
imzalanmasında otomatik olarak tekrar doldurulacaktır.
getInvoiceDocument metodu ile faturanın HTML görüntüsü alınabilir.
html, getInvoiceDocument, format,
getInvoiceDocument metodunun requestinde OutputType alanına HTML yazılarak
görüntü
faturanın HTML görüntüsüne ulaşılabilir.
Elektronik defterde her yevmiye kaydında belge tipi yer almak zorunda
22
mıdır?
Bulut e-Defter
Genel Teknik
Sorular 6 Defterin Utf-8 format hatası alması durumunda ne yapılmalıdır?
Bulut e-Defter Özel mali döneme tabi firmaların mali dönem sonu defteri için son
1
WS API yükleme tarihi, defter tarihi mi kurumlar vergisi son tarihi midir?
Gönüllü olarak e-defter uygulamasına başvurmak mümkündür. Gönüllü olarak e-Deftere geçmek isteyen mükellefler
https://uyg.edefter.gov.tr/edefterbasvuru/linkinden başvurularını gerçekleştirebilirler. Başvuru sırasında gerçek kişiler elektronik
imza veya mali mühür, tüzel kişiler mali mühür kullanmalıdır.
1 Sıra No’lu Elektronik Defter Genel Tebliğinde yapılan değişiklik ile e-Defter uygulamasının ön koşullarından olan e-Fatura
kullanıcısı olma zorunluluğu kaldırılmıştır. Yani e-Fatura kayıtlı kullanıcısı olmadan e-Defter uygulamasından yararlanılabilir.
Zorunluluk kapsamında olan mükelleflerin başvurularını iptal etmeleri mümkün değildir. Gönüllü olarak e-defter uygulamasına
geçen mükellefler ise, iptal için Gelir İdaresi Başkanlığına durumu anlatan bir dilekçeyi Maliye Bakanlığı Ek Hizmet Binası Yeni
Ziraat Mahallesi, No:16 06110 Altındağ/ANKARA adresine göndermeleri gerekmektedir.
Unvan ve vergi kimlik numarası hariç başvuru formunda girmiş olduğunuz bilgileri güncellemek için yapılması gerekenler:
-Elektronik imza araçlarını (tüzel kişiler için MALİ MÜHÜR, gerçek kişiler için NİTELİKLİ ELEKTRONİK SERTİFİKA) kullanarak e-
Defter uygulamasına giriş yapınız.
-"Bilgi Güncelle" bölümüne tıklayınız.
-Açılan ekranda yer alan bilgileri güncelleyebilirsiniz.
e-Defter uygulamasına kayıtlı bir kullanıcı, unvanının değişmesi halinde 15 gün içinde unvan değişikliğine ait Ticaret Sicil
Gazetesinin fotokopisi ve durumu izah eden bir dilekçe ile Gelir İdaresi Başkanlığı’na posta yoluyla, yeni unvana ait mali mühür
temini için de Kamu Sertifikasyon Merkezine elektronik ortamda başvurması gerekmektedir. Unvan değişikliğine giden mükellefin e-
Defter sistemindeki unvanı, dilekçesine istinaden güncellenecektir.
Unvan değişikliğinin gerçekleştiği tarihten önceki ay kesrine ait eski unvanın defter ve beratının oluşturulup ilgili ayı izleyen üçüncü
ayın son gününe kadar (2 Sıra No’lu Elektronik Defter Genel Tebliğinde belirtilen süreler) beratların GİB e-Defter Uygulamasına
gönderilmesi gerekmektedir.
Unvan değişikliğinin gerçekleştiği tarihten sonraki ay kesrine ait yeni unvana ait defter ve beratının oluşturulup ilgili ayı izleyen
üçüncü ayın son gününe kadar (2 Sıra No’lu Elektronik Defter Genel Tebliğinde belirtilen süreler) beratların GİB e-Defter
Uygulamasına gönderilmesi gerekmektedir.
Hayır yapılmamalıdır. Firmalar e-Defter uygulamasına vergi kimlik numarası üzerinden başvuru yapmaktadır. Başvurunun ardından
firmalar, tercih ettikleri uyumlu yazılım programları vasıtasıyla merkez ve şube olmak üzere ayrı ayrı defter ve beratlarını
oluşturabilirler.
e-Defter uygulaması kapsamında kullanıcıların, elektronik defter ve beratlarını oluşturmada kullanacakları ve 1 Sıra No’lu Elektronik
Defter Genel Tebliği kapsamında, Gelir İdaresi Başkanlığından onay almış paket yazılımlara “uyumlu yazılım” denilmektedir. Bu
yazılımların listesine ulaşmak için tıklayınız .
Elektronik defter (e-Defter) oluşturmak, kaydetmek, muhafaza ve ibraz etmek isteyen mükellefler uyumluluk onayı almış bir
program kullanmak zorundadır.
Uyumlu Yazılımlar Listesinde yayımlanan firmaların hepsi, e-Defter uygulaması kapsamında elektronik defter ve beratları Gelir
İdaresi Başkanlığının belirlediği format ve standartlarda defter oluşturmak için izin almış uyumlu yazılım programlarıdır. Ancak bazı
firmalar, programlarına platform bağımsız özelliği katarak, kendi yazılımlarını muhasebe programlarından bağımsız hale getirmiştir.
Bu şekilde, müşterileri hangi muhasebe programını kullanırsa kullansın, veri aktarımında müşterisine uygun bir yol belirleyerek
elektronik defter ve berat üretebilmektedir. Bu özellikte olmayan firmalar ise, sadece onay aldıkları muhasebe programı üzerinden
veri aktarımı yaparak elektronik defter ve berat üretmektedir.
Uyumlu Yazılımlar Listesinde hangi yazılımın platform bağımsız olduğu bilgisi de verilmektedir.
Kendi yazılımını geliştiren mükellefler uyumluluk testlerini başarı ile tamamlamaları halinde bu yazılım aracılığı ile e-defter
tutabilecektir.
Uyumlu yazılım firmasını değiştirmek mümkündür. Bunun için Elektronik imza araçlarını (tüzel kişiler için MALİ MÜHÜR, gerçek
kişiler için NİTELİKLİ ELEKTRONİK SERTİFİKA) kullanarak e-Defter uygulamasına giriş yapıp, Bilgi Güncelle bölümüne tıklayınız.
Açılan ekranda yer alan bilgileri güncelleyebilirsiniz.
Eğer Hesap dönemi başlangıcında e-Defter uygulamasına başlandıysa, önceki hesap dönemine ait kâğıt defterlerin kapanış
tasdiki, Türk Ticaret Kanununa göre belirtilen yasal süreler içerisinde yapılmalıdır. Bu süre Türk Ticaret Kanununda “izleyen faaliyet
döneminin altıncı ayının sonuna kadar” şeklinde belirtilmiştir.
Eğer Hesap dönemi içerisinde e-Defter uygulamasına başlandıysa, e-Defter uygulamasına geçilmeden önceki tarihlere ait kâğıt
defterlerin kapanış tasdikinin hangi süreler içerisinde yapılacağı 2 Sıra No’lu Elektronik Defter Genel Tebliği’nde aşağıdaki şekilde
belirtilmiştir:
MADDE 4 - "3.3.4. Aylık dönem, sadece onaya sunulan ayın defter kayıtlarını ifade etmekte olup, önceki aylara ait kayıtları
içermez. Hesap dönemi veya takvim yılı içerisinde de elektronik defter tutmaya başlanabilir. Ancak hesap dönemi veya takvim yılı
içerisinde elektronik defter tutmaya başlayanlar, başladıkları tarihi izleyen bir aylık süre içerisinde eski defterlerine kapanış
tasdiklemesi yapılması gereklidir."
Açılış Onayı: 1 Sıra No’lu Elektronik Defter Genel Tebliğine göre Gerçek ve Tüzel kişiler için “Elektronik defter tutma sürecinde
hesap döneminin ilk ayının beratının alınması açılış onayı yerine geçecektir. ” hükmü bulunmaktadır. Berat yükleme süresi, ilgili
olduğu ayı takip eden üçüncü ayın son gününe kadar olduğundan, bu süreler içerisinde yapılan hesap döneminin ilk ayına ait berat
yüklemeleri açılış onayı yerine geçecektir.
Kapanış Onayı: 1 Sıra No’lu Elektronik Defter Genel Tebliğine göre Gerçek ve Tüzel kişiler için “Elektronik defter tutma sürecinde
hesap döneminin son ayının beratının alınması kapanış onayı yerine geçecektir.” hükmü bulunmaktadır.
• Tüzel Kişiler Hesap döneminin son ayına ait elektronik defterlerin beratları 1 Sıra No’lu Elektronik Defter Genel Tebliğinde yapılan
değişikliğe göre kurumlar vergisi beyannamesinin verildiği ayın son gününe kadar gönderilmelidir. Bu süreler içerisinde yapılan
hesap döneminin son ayına ait berat yüklemeleri kapanış onayı yerine geçecektir.
• Gerçek Kişiler Hesap döneminin son ayına ait elektronik defterlerin beratları 1 Sıra No’lu Elektronik Defter Genel Tebliğinde
yapılan değişikliğe göre ilgili olduğu ayı takip eden üçüncü ayın son gününe kadar gönderilmelidir. Bu süreler içerisinde yapılan
hesap döneminin son ayına ait berat yüklemeleri kapanış onayı yerine geçecektir.
Hayır değildir. Muhasebe kaydına esas teşkil eden işlemlerin büyük çoğunluğu bir belgeye dayanmakla beraber, hiçbir belgeye
dayanmayan işlemlerde mümkündür. Örneğin, açılış-kapanış işlemleri belgeye dayalı olmayabilir. Eğer muhasebe kaydına esas
teşkil eden işlem bir belgeye dayanmıyorsa, belge tipi (XBRL karşılığı documenttype) alanı elektronik defterde kullanılmamalı ve
muhasebe fiş girişi sırasında da belge tipi (documenttype), tarihi (XBRL karşılığı documentdate) veya numarası (XBRL karşılığı
documentnumber) gibi bilgiler verilmemelidir.
Serbest meslek erbabının, mesleki faaliyetlerine ilişkin her türlü tahsilatı için düzenlediği belge serbest meslek makbuzudur. Bu
makbuz e-Defter paketi içerisinde yer alan Yevmiye Defteri Kılavuzunda sayılan belge tipleri arasında yer alan makbuz (XBRL
karşılığı receipt) ile karıştırılmamalıdır. Serbest meslek makbuzu, kılavuzda sayılan belgeler arasında yer almadığı için belge türü
olarak “other” ve belge açıklaması “serbest meslek makbuzu” olarak kaydı yapılır. Ayrıca belgenin numarası ve tarihinin de girilmesi
zorunludur.
Ödeme ya da tahsilat yapıldıysa ödeme yöntemi alanı elektronik defterde kullanılmalıdır. Bu alana sadece ödeme türünü ifade
edecek bilgi girişi yapılır. Örneğin, Nakit, Banka, Kredi Kartı, Çek, Senet. Ödeme yöntemi alanı serbest metin olmasına rağmen,
yapılan işlemin adı bu alana ödeme yöntemi olarak yazılmamalıdır . Örneğin, bankadan yapılan bir Havale ya da EFT işlemin adı
iken ödeme yöntemi Banka’dır.
SM/SMMM veya YMM bir işletme için defter oluşturuyorsa, bu durumda muhasebeci bilgileri alanına SM/SMMM veya YMM’ye ait
unvan ve ad-soyadı yazılacaktır. Eğer defterler işletme bünyesinde tutuluyorsa, bu alana işletmenin muhasebe bölüm yetkilisinin
unvanı ve adı-soyadı yazılacaktır.
e-Defter uygulamasında beratı, GİB’e göndermenin iki yolu bulunmaktadır.
1-GİB e-Defter Uygulaması
2-Web servis aracılığıyla
Kullanıcılar, e-Defter uygulamasına https://uyg.edefter.gov.tr/edefter/ linkinden firmalarına ait mali mühürle giriş yapılabilmektedir.
e-Defter Uyumluluk Test Aracını, sadece Gelir İdaresi Başkanlığından uyumlu yazılım program onayı almak için başvuruda bulunan
firmalar kullanabilir. Uyumluluk Onay başvurusu yapan firmalar, Gelir İdaresi Başkanlığının bu kullanıcılara vermiş olduğu testmatik
hesabı ile https://uygtest.edefter.gov.tr/edefter/ linkinden giriş yapabilir. e-Defter kullanıcılarının bu alanı kullanmaları mümkün
değildir.
İlgili aya ait defterlerin Beratı GİB e-Defter uygulamasına gönderildikten sonra, o aya ait muhasebe kayıtlarında hiçbir şekilde
değişiklik yapılamaz.
Muhasebe kayıtlarının yasal defterlere işlenme süresi için Türk Ticaret Kanunu ve Vergi Usul Kanunu göz önünde
bulundurulmalıdır. Ancak bu süreler, 2 Sıra No’lu Elektronik Defter Genel Tebliğinde bahsi geçen berat yükleme süresiyle
karıştırılmamalıdır. 2 Sıra No’lu Elektronik Defter Genel Tebliğinde bahsi geçen berat yükleme süresi, muhasebe kayıtlarının
elektronik kayıtlar bütünü olarak defter ve berat oluşturulması ve bunlar üzerinde gerekli kontrollerin yapılması için mükelleflere
verilen süre olarak düşünülmelidir.
Bilindiği üzere 1 Sıra No’lu Elektronik Defter Genel Tebliğinde e-Defter kullanıcılarının uyması gereken muhafaza ve ibraz
sorumlulukları belirtilmiştir. Bu hükümler aşağıda belirtilmiştir:
“a) Elektronik defterler, istenildiğinde ibraz edilmek üzere ilgili olduğu beratları ile birlikte muhafaza edilmek zorundadır. b)
Elektronik defterler ile beratlarının veri bütünlüğünün sağlanması ile kaynağının inkâr edilmezliği, güvenli elektronik imza veya mali
mühür ile garanti altına alındığı için elektronik defterlerin kâğıt ortamında saklanmayacaktır. c) Defterlerini elektronik ortamında
tutanlar, elektronik defterlerini ve ilgili beratlarını vergi kanunları, Türk Ticaret Kanunu ve diğer düzenlemelerde yer alan süreler
dâhilinde elektronik, manyetik veya optik ortamlarda muhafaza ve istenildiğinde elektronik, manyetik veya optik araçlar vasıtasıyla
eksiksiz ve okunabilir şekilde ibraz etmekle yükümlüdür. ç) Muhafaza ve ibraz yükümlülüğü, elektronik defterlerin ve beratların
doğruluğuna, bütünlüğüne ve değişmezliğine ilişkin olan her türlü elektronik kayıt ve veri, (elektronik imza ve mali mühür değerleri
dâhil) veri tabanı dosyası, saklama ortamı ile doğrulama ve görüntüleme araçlarının tümünü kapsamakta olup, elektronik defterlere
istenildiğinde kolaylıkla erişebilmeyi, anlaşılabilir ve eksiksiz bir biçimde görüntüleyebilmeyi ve okunabilir kâğıt baskılarını
üretebilmeyi sağlayacak biçimde yerine getirilmelidir. d) Elektronik defterler ve beratların elektronik defter izni verilenlerin
kendilerine ait bilgi işlem sistemlerinde muhafaza edilmesi mecburi olup, üçüncü kişiler nezdinde ya da yurt dışında muhafaza
işlemi Başkanlık ve Genel Müdürlük açısından herhangi bir hüküm ifade etmemektedir. Muhafaza yükümlülüğünün Türkiye
Cumhuriyeti sınırları içerisinde ve Türkiye Cumhuriyeti kanunlarının geçerli olduğu yerlerde yerine getirilmesi zorunludur.”
Saklanması ile ilgili dizin yapısının detayı www.edefter.gov.tr sitesinde yayımlanan Yazılım Uyumluluk Kılavuzunda belirtilmiştir.
“Yevmiye/kebir dosyalarının, yevmiye/kebir beratlarının ve GİB onaylı yevmiye/kebir beratlarının içinde tutulduğu dizin yapısının
ekran alıntıları (Dizin yapısı standart ağaç yapısında olmalıdır ilgili ayın paketleri bir klasörde, tüm ayların toplamı yıl klasöründe ve
yılların hepsi de aynı klasörde olacak şekilde bilgisayarın yerel depolamasında saklanmalı. XML dosyalarını mükellefin/denetim
elemanının düzgün görüntüleyebilmesi için XSLT dosyaları da ilgili ay dizinlerine konulmalı. Dizin yapısı …. /VKN/YIL/AY/ altında
Y-K dosyaları [defterler], YB-KB dosyaları [defter beratları], GIB-YB ile GIB-KB dosyaları [GIB onaylı defter beratları] ve XSLT
dosyası şeklinde olmalıdır ”
Muhafaza edilmesi gereken dosyalar hem Yevmiye Defteri hem de Büyük Deftere ait oluşturulan defter, berat ve GİB imzalı
beratlardır. Bu dosyaların hepsi bir arada GİB’in yukarıda belirttiği dizin yapısında e-Defter kullanıcısının kendi bilgi işlem
sisteminde ve güvenli bir ortamda saklanmalıdır. Dizin yapısı konusuyla ilgili uyumluluk onayı alan yazılım firmaları, e-Defter
müşterilerini yönlendirmekle sorumludur.
e-Defter uygulamasında parçalı defter oluşturmak mümkündür. Bu parçalı defterlerin, herhangi birinde, oluşturulan tarih aralığında
hiçbir muhasebe kaydının olmaması durumunda, o defter parçasının da boş defter olarak oluşturulması ve beratının GİB e-Defter
uygulamasına iletilmesi gerekmektedir. Bunun amacı bir aya ait tarih bütünlüğünü korumaktır.
Hayır yoktur. Elektronik defterlerde, aylık devir ve bakiye bilgileri bulunmamaktadır.
Gelir İdaresi Başkanlığına (GİB) elektronik defterlere ait berat iletmede, GİB e-Defter uygulaması dışında bir diğer yöntem
webservistir. Ancak webservisi test etme ve canlı ortamda kullanmanın ön koşulu programı için GİB’den uyumluluk onayı almış bir
firma olmaktır. Bunun haricinde e-Defter kullanıcılarının veya uyumlu yazılım için başvurmamış veya da başvurup onay almamış
firmaların webservisi test etme veya kullanma gibi imkanları bulunmamaktadır.
Kontrol numarası, birbirinden ayrı olarak oluşturulan defter dosyalarının müteselsilliğini ve birbirleri ile bağlanabilmelerini sağlamaya
yönelik bir numaradır. 3 haneli harf grubunu ifade eden doküman kodu ile 12 haneli numaranın birleşiminden meydana gelen
uniqueID bu elemana yazılacaktır. 12 haneli numaranın ilk 4 hanesi dokümanın düzenlendiği takvim yılını sonra gelen 2 hane
defterin ait olduğu ayı, kalan 6 hane ise müteselsil numarayı ifade etmektedir. 3 haneli doküman koduna, yevmiye defteri için
“YEV”, büyük defter için “KEB” yazılacaktır. Dokümanı düzenleyen bünyesinde aynı uniqueID birden fazla kullanılamaz.Örnek
gösterimler:
YEV201101000001 (Ocak ayına ait tek parça defterin uniqueid örneği)
YEV201102000002
YEV201102000003
(Şubat ayına ait iki parça deftere ait uniqueid örneği)
YEV201103000004 (Mart ayına ait tek parça deftere ait uniqueid örneği)
Elektronik defterler, aylık dönemler itibariyle oluşturulur. Oluşturulan elektronik defterlerin görüntülenebilmesi ve doğrulanabilmesi
için teknik boyut sınırı bulunmaktadır. Bir aya ait defterin sıkıştırılmamış (paketlenmemiş) maksimum boyutu 200 MB olmalıdır. Bu
teknik boyut sınırı nedeniyle aylık olarak oluşturulacak bir defterin, birden fazla XML dosya olarak oluşturulması gerekebilir. Bu
şekilde oluşturulacak dosyaların her birine “ defter parçası” adı verilmektedir. 200 MB’lık teknik boyut sınırı, defterlerin
doğrulanması ve görüntülenmesi için kullanılacak donanımların optimum özellikleri dikkate alınarak tespit edilmiştir. Bu teknik boyut
sınırı e-defter paketi içerisinde yer alan teknik kılavuzlarda açıklanmış olup, uyumlu yazılımlar tarafından da bu boyut kontrolleri
yapılması zorunludur.
Dikkat edilmesi gereken husus, mükelleflerin oluşturdukları elektronik defterlerinin görüntülenmesinden ve ibrazından sorumlu
olduğudur. Dolayısıyla kendi bilgi işlem sistemlerini de göz önünde bulundurarak, 200 MB’ı aşmayacak şekilde, defterlerinin
görüntülenebildiği ergonomik boyutu tespit edip, elektronik defter oluşturabilirler.
Zaman Damgası, belli bir verinin belirtilen bir tarihte var olduğunu kanıtlayan araçtır. Gelir İdaresi Başkanlığının (GİB) e-Defter
sisteminde bir sorun oluşması ve yasal sürenin sonunda yüklenmeye çalışılan beratların GİB e-Defter uygulamasına
yüklenememesi durumunda, bu beratlara mali mührünün yanı sıra zaman damgası eklenmelidir. GİB sisteminde oluşan sorun
giderildiğinde zaman damgalı saklanan berat GİB e-defter uygulamasına yüklenmeli ve GİB imzalı berat indirilmelidir. Yasal
sürelerde beratı oluşturduğunuzun anlaşılması açısından zaman damgalı berat ispat aracı olarak kullanılacaktır. Sadece beratların
zaman damgalı olması yeterlidir. Elektronik defterlerin zaman damgalı olma zorunluluğu yoktur. Zaman damgası adet (kontör)
bazındadır. Her bir berata konulan zaman damgası bir kontör olarak adlandırılır. Defterlere de zaman damgası eklenmek zorunlu
değildir. Ancak yine de kullanıcı tercihen eklemek isterse, burada zaman damgası sayfa sayısına göre değil, defter parçasının
kendisine eklenmektedir. Dolayısıyla her defter parçasına konulan zaman damgası da bir kontör olarak hesabınızdan düşmektedir.
-e-Defter uygulamasına kayıtlı bir kullanıcı, nevi değişikliğine gitmesi halinde 15 gün içerisinde, nevi değişikliğine ilişkin ticaret sicil
gazetesinin fotokopisi ve durumu izah eden bir dilekçe ile Gelir İdaresi Başkanlığı’nın Yeni Ziraat Mah. Etlik Cad. No:16
Dışkapı/ANKARA adresine posta yoluyla bildirmesi, yeni unvana ait mali mühür temini için de Kamu Sertifikasyon Merkezinin
http://mm.kamusm.gov.tr/ adresinden elektronik ortamda başvurması gerekmektedir.
-Yeni vergi kimlik numarası için talep edilen mali mührün mükellefin eline ulaşması ile birlikte
http://edefter.gov.tr/edefterbasvuru.html web sitesinden yeni kimlik numarası için elektronik defter başvurusu yapılmalıdır.
-Başvuru da elektronik defter başlangıç tarihi, en erken bir sonraki izleyen ay olarak seçilmekte yani nevi değişikliğinin olduğu tescil
tarihi e-Defter başlangıç tarihi olarak seçilememektedir. Yeni nevi’nin elektronik defter başlangıç tarihinin, tescil tarihine
çekilebilmesi için elektronik defter başvurusunun yapıldığı ve tarih revizesinin yapılması gerektiği edefter@gelirler.gov.tr adresine
elektronik posta gönderilerek bildirilmelidir.
-Bunun ardından GİB e-defter sisteminde yeni nevi için yapılan başvurunun elektronik defter başlangıç tarihi tescil tarihine göre
güncellenecektir.
-Bu yeni başvuru ile birlikte mükellefin eski vergi kimlik numarası ve yeni kimlik numarası olmak üzere iki adet e-defter hesabı
olacağından, mükellef nevi değişikliğinin gerçekleştiği tarihten önceki ay kesrine ait eski unvan ve vergi kimlik numaralı defter ve
beratını oluşturması gerekmektedir. Oluşturulan defterlerin tarih aralığı, mükellefin eski unvanına ilişkin hesap döneminin son ayına
tekabül edeceğinden beratlar GİB e-Defter uygulamasına, Kurumlar Vergisi beyannamesinin (Hesap döneminin başından, nevi
değişikliğinin gerçekleştiği tarihe kadar ki hesap dönemine ait kurumlar vergisi beyannamesi) verildiği ayın son gününe kadar (2
Sıra No’lu Elektronik Defter Genel Tebliği) gönderilmelidir.
-Bu gönderim yapıldığında da edefter@gelirler.gov.tr adresine bilgilendirme yapılmalıdır.
-Nevi değişikliğinden önceki döneme ait son beratların gönderilmesi ile eski vergi kimlik numaralı e-defter kullanıcı hesabı GİB
tarafından kapatılacak ve mükellef nevi değişikliği sonrasında açılan yeni kullanıcı hesabı ile elektronik ortamda beratlarını iletmeye
devam edebilecektir.
-Ayrıca nevi değişikliğinin gerçekleştiği tarihten sonraki ay kesrine ait yeni unvan ve vergi kimlik numaralı defterlerin oluşturulup ilgili
ayı izleyen üçüncü ayın son gününe kadar (2 Sıra No’lu Elektronik Defter Genel Tebliğinde belirtilen süreler) beratların GİB e-Defter
Uygulamasına gönderilmesi gerekmektedir.
Örneğin, 7 Ocak 2015 tarihinde gerçekleşen Nevi değişikliğinde eski vergi kimlik numarası ve unvana ilişkin defter ve berat 01
Ocak – 07 Ocak 2015 tarihlerini kapsamalıdır. Bu tarihleri kapsayan eski vergi kimlik numarası ve unvana ilişkin defterler, eski
unvanın hesap döneminin son ayına tekabül edeceğinden beratları yasal süre olan kurumlar vergisi beyannamesinin (Hesap
döneminin başından, nevi değişikliğinin gerçekleştiği tarihe kadar ki hesap dönemine ait kurumlar vergisi beyannamesi) verildiği
ayın son gününe kadar GİB e-Defter uygulamasına gönderilmelidir.
Nevi değişikliğinden sonra yeni VKN ve unvana ilişkin defter ve berat 07 Ocak – 31 Ocak 2015 tarihlerini kapsamalıdır. Bu tarihleri
kapsayan yeni vergi kimlik numarası ve unvana ilişkin defterlerin beratları yasal süre olan ilgili ayı izleyen üçüncü ayın son gününe
kadar tarihine kadar GİB e-Defter uygulamasına gönderilmelidir.”
3(üç) kez yanlış PIN girilmesi sonucu kilitlenen kart için(Nitelikli Elektronik Sertifika) https://nesbireysel.kamusm.gov.tr/nb.go
sayfasına Şifreli Giriş yapılarak Kilit Çözme seçeneğinden Yeni PIN Üret işlemleri gerçekleştirilmelidir.
Operasyonel portalde "Şirket İşlemleri" altında seçmiş olduğunuz şirkete ait "parametre" bölümünde "Parametre Ekle" işlemi
yaparak VERGI_DETAYI parametresini ekleyebilirsiniz. THP hesap planı kullanan müşteriler için hesap kontrolünü kaldıracaktır.
Defter detay satırı 30.000 satırı aşması durumunda portal imzada hata verebilmektedir, teknik destek ile manuel imza gereklidir.
Muhasebeci tanımlama sürecinde Sözleşme Detayı alanı önemlidir.
Muhasebeci İşlemleri - Sözleşme Detayı bilgisi alanı için muhasebeci firma içinden ise bu alana "-" yazıp ilerleyebilir. Muhasebeci
firma dışından ise alan aşağıdaki formatdaki gibi doldurulmalıdır.
Sözleşme Detayı : Bu alan 3 bilgiyi (Sözleşme Açıklaması, Sözleşme Başlangıç Tarihi, Sözleşme Numarası) de içinde
barındıracak şekilde doldurulmalıdır.
Ör : " SMMM Sözleşmesi,2010-08-01,A10560 " formatında doldurulmalıdır.
Firmanın SMMM, YMM'si olması durumunda, portal muhasebeci kaydında ilk etapta SMMM sonrasında YMM kaydı yapılmalıdır.
Bu durumda beratta SMMM bilgileri görünecektir, yalnız XML içinde hem SMMM hem de YMM bilgileri bulunacaktır.
e-Defter ile ilgili Nevi değişikliği sırasında yapılması gereken işlemler aşağıdaki linkteki gibidir:
http://edefter.gov.tr/dosyalar/Nevi_degisikligi.pdf
Yukarıdaki işlemler tamamlanmadan yapılacak unvan ve VKN değişikliğinde GİB' in yönlendirmesi aşağıdaki gibidir.
- Aksi belirtilmedikçe bir özel entegratör firmanın hesabını kapatırsa sonrasında firmanın GİB-Portali açılır. Nev'i değişikliklerinde
firmanın eski VKN' ye ait portalinin açılmaması ya da açıldıysa kapatılması için GİB ile iletişime geçmesi gerekmektedir (Yukarıdaki
bağlantıdaki bilgiler doğrultusunda posta yolu ile işlem yapılarak). GİB-Portaliniz açılırsa, eski unvanlı ve VKN' li bu hesabınıza
faturalar gelebilir. Özel entegratörünüz yeni vergi kimlik numaranızla e-fatura hesabınızı açacaktır. (Sorun yaşarsa GİB forumdan
22219 numaralı sorunun cevabına bakılmalıdır.)
ADRES: Yeni Ziraat Mah. Etlik Cad. No:16 06110 Dışkapı/ ANKARA
Gib eDefter Mail : edefter@fitbulut.com
EK BİLGİ; Gönderici/Alıcı firmalar farketmeksizin; Nevi-unvan değişikliğine istinaden mükelleflerin yeni unvanlarına ait Mali Mühür
Sertifikalarını temin ederek gerekli güncellemeler yapılana kadar, mükellefin sistemde tanımlı olan eski unvanlarına e-fatura
düzenlenmelidir. Not alanına firmanın yeni VKN unvanları da eklenebilir
Notepad++ da Kodlama segmesinden formatın Utf-8 olma durumu kontrol edilmeli, defterde Utf-8 formatında olmayan karakterlerin
bulunma durumuna bakılmalıdır.
Hata GİB' den dönmektedir. GİB'e başvuru yapılan ay haricinde ilk defterin yüklenmeye çalışıldığını belirtmektedir
Defter içinde tüm headerlar için yevmiye madde numarası boş gönderilmesi durumunda sistem otomatik atamaktadır. Bir header
için dahi yevmiye madde numarası dolu ise sistem hata verir. Yevmiye madde no ya tüm veride boş gelmeli veya tüm veride dolu
gelmelidir.
Defteri XML olarak çeken firmalar için;
Yevmiye XML datasından aşağıdaki tüm alanları topluca silmek gerekmektedir.
<gl-cor:account>
<gl-cor:accountSub>
</gl-cor:accountSub
</gl-cor:account>
- XML_Backup programında yevmiye datası açılmalı.
- Tablolar alanı sorgulara kadar silinmelidir.
- XML data içeri aktarılır (account ve accountSub alanları silinmelidir)
- TXT' nin tamamı seçili iken defter Metin Dosyası şeklinde dışarı aktarılır.
a) Gerçek kişiler elektronik defterlerini, ilgili olduğu ayı takip eden üçüncü ayın son gününe kadar kendilerine ait güvenli elektronik
imza veya mali mühür ile imzalar.
b) Tüzel kişiler elektronik defterlerini, ilgili olduğu ayı takip eden üçüncü ayın son gününe kadar (Hesap döneminin son ayına ait
defterler kurumlar vergisi beyannamesinin verildiği ayın son gününe kadar) kendilerine ait mali mühür ile onaylar.
Özel hesap dönemine tabi tüzel kişiler, hesap dönemlerinin son ayına ait e-defterlerini kurumlar vergisi beyannamesinin verildiği
ayın son gününe kadar gönderebilirler. Ancak e-Defter sistemi özel hesap dönemine tabi tüzel kişilerin son ayını tespit
edememektedir. Bu durumdaki mükelleflerin Gelir İdaresi Başkanlığı'na dilekçe ile başvurmaları halinde e-Defter sistemi kurumlar
vergisi beyannamesinin verildiği ayın son gününe kadar açılacaktır.
HSM cihazı içerisine yüklenen şirketlere ait olan imza sertifikaları ile elektronik imzalama işlemi için kullanılmaktadır. e-Defter
uygulaması için berat ve defter belgelerinin XML olarak oluşturulması esnasında elektronik imzalama işlemi yapılmaktadır. HSM
cihazı içerisinde bulunan elektronik imza sertifikaları ile bu imzalama işlemi gerçekleştirilir.
RCS e-Defter Kurulumu için gerekli olanlar
Portal için:
1- Kurulumun yapılacağı server'a bağlanmak için VPN bilgileri.
2- Kurulumun yapılacağı server'a bağlanmak için Uzak masaüstü bağlantısı bilgileri. (IP, Kullanıcı Adı, Şifre)
3- Kurulumun yapılacağı server'a kurulan PI veya Netweaver için administrator yetkili kullanıcı ve şifresi
(default kullanıcı: j2ee_admin)
4- SAP'den indirilen edefter uygulamasının server içerisinde bir yere konulması.
5- Bu portal üzerinde çalışacak olan şirketlerin VKN bilgileri. Şubeleri varsa şube kodları.
6- ERP tarafında oluşturulan web servislerin URL'leri. Yevmiye ve Büyük Defter için birer tane URL olmalı.
Ve bu URL'leri çağırma yetkisi olan kullanıcı adı ve şifre (ERP tarafında kullanıcı)
7- Eğer birden fazla ERP varsa her ERP için Yevmiye ve Büyük Defter URL'leri, kullancı adı, şifreleri.
Hangi VKN'nin hangi ERP sisteminde olduğu bilgisi. Ve her ERP sisteminin sistem ID leri.
8- Şirket-Muhasebeci Bilgileri dökümanı doldurulmalıdır.
İmza için:
1- Kurulumun yapılacağı server'a bağlanmak için Uzak masaüstü bağlantısı bilgileri. (IP, User, Pass)
2- Her VKN için Token kullanılıyorsa PIN bilgileri, HSM kullanılıyorsa ALIAS ve PASSWORD bilgileri
3- İmza lisansı dosyasının doldurulması
https://docs.google.com/a/fitcons.com/forms/d/16HiCpRKXBBXH_CmWilij7hTSLYuBYfsjP303y2eF4ck/viewform?
edit_requested=true
4- Şirketlerin VKN'sini içeren imza lisansının danısman ile paylasılması
5- Tüm şirketler için bir tane TEST ZAMAN DAMGASI kullanıcı adı şifre yeterli oalcaktır.
Ve bir tane de CANLI ZAMAN DAMGASI kullanıcı adı şifre yeterli olacaktır
(Eğer Canlıda ayrı zaman damgası kullanmak istiyorlarsa ayrı ayrı CANLI ZAMAN DAMGASI)
6- İmza sunucusu internete proxy ile çıkıyorsa zaman damgası alabilmek için Proxy bilgileri
( Proxy Host,Port,User,Password, Type(http/https))
Etiket
edefter, nedir
edefter, format, standart
kim, edefter, mükellef, uygulama
berat, nedir
zorunlu, edefter
gönüllü, edefter
e-Bilet uygulamasına geçiş zorunlu mudur? e-Bilet düzenlemek isteyen firmalar için
2
e-Fatura kayıtlı kullanıcısı olmak şart mıdır?
İnternet siteleri üzerinden başka firmaların karayolu taşıma biletlerini satan firmaların
6
e-Bilet' e geçme zorunluluğu var mıdır?
3 UUID numarası için yılda vb. herhangi bir zaman diliminde GİB tarafından sıfırlama
istenmekte midir?
4 Bilet çıktısı üzerinde olması gereken zorunlu ibare ve alanlar nelerdir?
5 Bilet satışı yapılıp Foriba' ya gönderildikten sonra, bilet üzerinde isim değişikliği ya da
bilette herhangi bir değişiklik yapıldığında (fiyat hariç) nasıl bir yol izlenmelidir?
Genel Teknik Foriba' ya gönderilen satın alınan biletlerden gelen cevapta bulunan UUID ve e-Bilet
Sorular 6 numarası; bilet iptal işleminin sonunda gelen UUID ve e-Bilet numarası ile aynı mıdır?
Yoksa her gönderilen bilet için farklı UUID ve farklı e-Bilet numarası mı
üretilmektedir?
7 Ek hizmetler (değişim, bagaj vb) için ikinci ek ücret alınmakta ayrıca sefer vb.
olmayacak olup ayrı bir bilet kesilmesi mi gerekir ?
Bir e-Bilet' te %50 kredi kartı, %50 nakit veya %50 kredi kartı, %50 paracık(hopi) ile
8 tahsilat yapılsa e-Bilet' e ödeme olarak ne gönderilmelidir?
Özetle parçalı tahsilatlarda e-Bilet' e ödeme olarak ne gönderilmelidir ?
9 Açığa alınan biletler ile ilgili sefer bilgisi yolcu bilet alana kadar bilinmemektedir. Bu
durumda sefer bilgisi olmadan e-Bilet gönderilebilir mi?
10 Uçak veya helikopter kiralama işleminde bilet kesilirken nereden nereye bilgisi
olmadan e-Bilet gönderilebilir mi?
Müşteri şikayeti gibi nedenlerden dolayı sefer saatinden sonra iptal edilen biletler
11 olduğunda bu biletler teknik raporda nasıl gösterilmeli. Daha önceden gönderilen
yolcu raporunun revize edilerek gönderilmesi gerekir mi? (Yolcunun sefere katılıp
daha sonrasında müşteri şikayetinden kaynaklı iade yaptığı durumlar için geçerli.)
Bedelsiz/Ücretsiz/0 Bedelli bilet nasıl oluşturulmalı ve raporlanmalı ayrıca indirimli
12
bilet 0 tutarlı olabilir mi?
İptal bilet haricinde iade bilet gibi bir yöntem düşünülmekte midir? Satılan biletler 5dk
13 içinde ücretsiz değiştirilebilmektedir; bu biletler için iptal yeni bilet süreci yerine bu gibi
bir işlem mümkün müdür?
14 e-Bilet için oluşturulan .xml dosyası içerisinde ki zorunlu alanlar nelerdir ?
15 e-Bilet için oluşturulan PDF içerisinde ki zorunlu alanlar nelerdir ?
1 Web servis metodları ile ilgili detaylı bilgi nereden bulunabilir?
WS API
2 e-Bilet' in durumu( Foriba ve GİB' de ki durumu) nereden öğrenilebilir?
Cevap
Tüzel kişi mükellefler 397 Sıra No.lu Vergi Usul Kanunu Genel Tebliği ile getirilen elektronik fatura uygulamasından yararlanma
iznine sahip olmalıdır. Gerçek kişi mükellefler, güvenli elektronik imzaya sahip olmalıdır. Bu Tebliğde açıklanan usul ve esaslara
uygun olarak, elektronik bilet ve yolcu listesi düzenleme ve biletleri yolculara sunabilme konusunda hazırlıklarını tamamlamış
olmalıdır. Tebliğin (8) numaralı bölümünde belirlenen raporlama ihtiyaçlarının karşılanması Kara, Deniz, Hava yolu taşımacılığı
hususunda, gerekli altyapı ve hazırlıklarını tamamlamış olmalıdır.
e-Bilete geçiş zorunlu değildir ancak 462 sıra no lu teblğin 14. Maddesinde de belirtildiği gibi ilgili tebliğ 334 no lu Vuk tebliğini
1/7/2016 tarihi itibariyle yürürlükten kaldırdığından eski koçan usulü bilet kesmenin teknolojik gelişmelerin varlığıyla zor
olacağından, dolaylı olarak bir zorunlu geçiş söz konusudur. e-Bilet' e geçmek isteyen firmalar için (Dar mükellef kurumlar hariç)
e-Fatura kayıtlı kullanıcısı olmak zorunluluktur.
e-Bilet düzenlemek isteyen firmalar, kendi bilgi işlem sistemlerini entegre ederek ya da e-Bilet özel entegratörü firmalar
aracılığıyla e-Bilet kayıtlı kullanıcısı olabilirler. Detaylı bilgiye www.efatura.gov.tr internet adresinden ulaşabilir.
1- Kara yolu taşımacılığı
2- Hava yolu taşımacılığı
3- Deniz yolu taşımacılığı
4- Etkinlikler
Hava yolu yolcu taşımacılığı ile ilgili 462 nolu Tebliğe göre; acenteler aracılığıyla yapılan satışlarda e-Biletin Türkiye’de
mükellefiyeti bulunan acenteler tarafından düzenlenmesi durumunda söz konusu acenteler, e-Bilet üzerinde yolcu bilgilerine
ilave olarak kendilerine ait mükellefiyet bilgilerine ya da IATA nezdinde kendileri için oluşturulmuş bilgilere yer vererek yolcuya
e-Bilet muhteviyatını da içeren bir fatura düzenleyeceklerdir. Bu fatura üzerinde yolcu bilgilerine ilaveten yolcu tarafından talep
edilmesi halinde hesabına yolculuk yapılan mükellef bilgilerine de yer verilecektir. Bu nedenle acentelerin e-Bilete geçme
zorunluluğu yoktur.
Yolcu taşıma işi ile iştigal etmeyen ancak başka firmaların biletlerini elektronik ortamda satan mükelleflerin e-Bilet uygulamasına
geçme zorunluluğu yoktur. Bununla bitlikte,internetten bu satışı gerçekleştiren mükelleflerden 5 Milyon TL ve üzeri ciroya sahip
olanların e-Arşiv uygulamasına başvurmaları ve bu kapsamda işlem yapmaları gerekmektedir. e-Arşiv' e başvurmanın
şartlarından biri de kayıtlı e-Fatura kullanıcısı olmaktır. Detaylı bilgiye www.efatura.gov.tr internet adresinden ulaşılabilir.
TC vatandaşı olmayan yolcular için pasaport numarası girilebilir. Pasaport bilgisi olmayan yabancı yolcu için ise, 99999999999;
Türk yolcu için ise, 11111111111 yazılabilir.
e-Biletlerin XML olarak oluşturulması ve imzalanması mümkün değildir. e-Bilet Tebliğleri gereği e-Bilet formatı olarak üzerinde
mali mühür/NES barındıran genel tanınırlığa sahip bir format kullanılmalıdır. Bu kapsamda Başkanlıkça aksi belirtilmediği /
format ve standardı yayımlanmadığı sürece .xml kullanımı söz konusu değildir. Mevcut durumda piyasada yaygın olarak .pdf
kullanılmaktadır.
Takip edilebilirlik, tekil sorgulama ve özellikle performans/hata engelleme anlamında kazanç sağlamaktır.
UUID' nin herhangi bir sıfırlama zorunluluğu bulunmamaktadır; tüm programlama dillerinde üretilebilen özel algoritmalı unique
değer üretilmesi için standart hale getirilmiş bir değer öbeğidir. [Örnek değer: 5a93d9e7-6e63-4802-9a04-545c1dd2e46c]
Elektronik bilette bulunması gereken bilgiler e-Bilet "415 nolu" tebliğinin 4. sayfasında mevcuttur.
Foriba sistemine gönderilmiş biletin üzerinde değişiklik yapılması durumunda iptal bileti üretilip sonra tekrar yeni bilet
oluşturulması gerekmektedir.
Bilet belgeleri ve iptal bilet belgeleri ayrı XML yapılarından oluşur, ayrı web servis metotları ile Foriba sistemine gönderilir. Ve bu
belgeler oluşturulurken bilet numaraları ve iptal bilet numaraları ile UUID bilgilerinin gönderici tarafından oluşturulması gerekir.
Foriba tarafında bu bilgiler oluşturulmamaktadır. Her gönderilen bilet belgesinin UUID ve bilet numarası farklı olmalıdır. Aynı
şekilde iptal bilet numrası ve UUID bilgileri de iptal biletler için tekil olmalıdır.
Ek hizmetler bilet üzerinde belirtilip ayrı bir bilete konu olmamalıdır.
Birden fazla ödeme tipi olması durumunda DIGER değeri seçilerek gönderilmelidir..
Sefer bilgisi sadece kara ve deniz yolu biletleri için zorunlu bir alandır. Hava yolu biletleri için zorunlu bir alan değildir. Böylece
hava yolu biletlerinde sefer bilgisini doldurulmadan bilet gönderilebilir.
Nereden nereye bilgisi e-Bilet şemasına göre seçimli bir alandır. Bu bilgiler doldurulmadan bilet gönderilebilir.
Yolcu raporunun sefer kalkmadan gemide de bulunması zorunlu olduğundan düzenlenen yolcu raporu, sonradan yapılan iade
iptallerden dolayı değişmeyecektir, o an sefere ait yolcu raporu oluşmuş olacak, hasılattaki sonraki değişimlerden kaynaklı bir
revize olmayacaktır.
İade bilet yöntemi tavsiye edilmemekte, bilet ve iptal bilet kurgusu üzerinden gidilmesi önerilmektedir.
e-Bilet Belgeleri Alan Tanımları Excel dokümanı içerisinde detaylı bilgiye ulaşabilir.
e-Bilet Belgeleri Alan Tanımları Excel dokümanı içerisinde detaylı bilgiye ulaşabilir.
Foriba e-Bilet Müşteri Web Servis Dokümantasyonu v2.0 içerisinde detaylı bilgi bulunabilir.
Foriba Bulut e-Bilet Portal' den biletin durumu öğrenilebilir. https://ebilet.fitbulut.com/ETIC_WEB_CUST_10/index.html#/login
Etiketler