Sipariş Bilgisi Zorunlu Hatası: Neden Olur ve Nasıl Çözülür?

Sipariş bilgisi zorunlu hatası, faturadaki sipariş referansı alanı boş, eksik veya hatalı olduğu için oluşur. Çözüm, gerçek sipariş numarasını ve tarihini ilgili alana girmek, belgeyi yeniden doğrulamak ve gönderim yanıtını kontrol etmektir.

Bu rehber, e-Fatura veya e-Arşiv düzenlerken aynı mesajla karşılaşan işletme sahiplerine, muhasebe çalışanlarına ve entegrasyon yöneticilerine yardımcı olur. Sipariş bulunmayan işlemlerde sahte bilgi girmeden hangi ayarın, müşteri talebinin veya veri eşleştirmesinin inceleneceğini açıklar.

Sipariş bilgisi zorunlu hatası ne demektir?

Sipariş bilgisi zorunlu hatası, sistemin fatura gönderilmeden önce sipariş referansı beklediği anlamına gelir. Bu referans genellikle sipariş numarası, sipariş tarihi veya müşterinin satın alma sistemindeki belge bilgisidir.

Mesaj, e-Fatura portalında taslak kaydederken, gönderim öncesi doğrulamada veya entegrasyonun XML kontrolünde görünebilir. Hatanın görüldüğü ekran, sorunun kaynağı hakkında ilk ipucunu verir.

Portal alanı boşsa sorun kullanıcı girişinden kaynaklanır. Alan dolu görünmesine rağmen hata devam ediyorsa, kayıt XML dosyasına aktarılmıyor veya sistem boşluk karakterini geçerli bilgi saymıyor olabilir.

Bu mesaj, her faturada sipariş numarasının genel olarak zorunlu olduğu anlamına gelmez. İşletme kuralı, müşteri satın alma prosedürü, sözleşme, sektör uygulaması veya entegrasyon ayarı bu alanı zorunlu hâle getirebilir.

Faturadaki sipariş numarası, fatura numarasıyla aynı değildir. Sipariş numarası müşterinin satın alma talebini, fatura numarası ise düzenlenen e-belgeyi tanımlar.

Yanlış: Sipariş yokken rastgele bir numara yazıp belgeyi göndermektir. Doğru: Sipariş kaydını doğrulamak veya zorunluluk kuralının neden etkin olduğunu yetkili kullanıcıyla incelemektir.

Hata, gönderim sonrasında oluşuyorsa ekrandaki uyarıdan çok GİB veya özel entegratör yanıtına bakılmalıdır. Yanıt kodu, alan adını ve belge durumunu birlikte değerlendirmek gerekir.

Sipariş bilgisi zorunlu hatası neden oluşur?

Sipariş bilgisi zorunlu hatası çoğunlukla sipariş numarasının faturaya aktarılmaması, yanlış alana yazılması veya entegrasyon eşleştirmesinin boş değer göndermesi nedeniyle oluşur.

Manuel düzenlemede kullanıcı, sipariş bilgilerini müşteri kartına veya açıklama alanına yazabilir. Ancak sistem, açıklama metnini sipariş referansı olarak kabul etmeyebilir ve ayrı sipariş alanını boş görür.

Entegrasyonlarda sipariş numarası, satış siparişi ekranındaki farklı bir koddan alınabilir. Kullanıcı sipariş kodunu değiştirirse, fatura şablonu eski alanı okumaya devam edebilir.

Sipariş tarihi ile fatura tarihi karıştırıldığında da doğrulama başarısız olabilir. Tarih formatı, boş değer, geçersiz gün veya sistemler arasındaki saat dönüşümü ayrıca incelenmelidir.

Müşteri kartındaki ayar da hataya yol açabilir. Bazı kartlarda satın alma siparişi numarası zorunlu seçilmiş olabilir; başka müşterilerde aynı alan koşullu çalışabilir.

Kopyalanan eski taslaklar, sipariş referansını taşımadan yeni fatura oluşturabilir. Bu nedenle yalnızca yeni faturanın ekranını değil, kullanılan şablonun ve taslak kaydının kaynağını da kontrol edin.

Hata fatura tarihiyle birlikte görünüyorsa [Fatura Tarihi Geçersiz Hatası Nasıl Çözülür? Rehber](/blog/fatura-tarihi-gecersiz-hatasi-nasil-cozulur-neden-olur-adim-adim-cozum) yazısındaki tarih kontrolüyle bu sorunu birbirinden ayırın.

Bu hata hangi sipariş alanlarını ister?

Sipariş bilgisi zorunlu hatasında istenen alanlar kullanılan portal veya yazılıma göre değişir. En sık kontrol edilen bilgiler sipariş numarası, sipariş tarihi ve müşteri sistemindeki referans kodudur.

Sipariş numarasını, müşterinin gönderdiği sipariş formundan veya ERP satış siparişi kaydından alın. E-posta konu satırı, sevk irsaliyesi numarası veya teklif numarası ancak müşteri bunları sipariş referansı olarak tanımlıyorsa kullanılmalıdır.

Sipariş tarihi, sipariş belgesinin düzenlendiği tarihtir. Bu alanı otomatik olarak fatura tarihiyle doldurmak, iki belgenin tarihi gerçekten aynı değilse hatalı eşleşme oluşturabilir.

UBL-TR kullanan bazı sistemlerde sipariş referansı XML içinde genellikle cac:OrderReference altında cbc:ID ve cbc:IssueDate alanlarıyla gösterilir. Bu yapıdaki alan adları, kullandığınız entegrasyonda farklı bir ekran etiketiyle sunulabilir.

Bir alanın ekranda görünmesi, XML içine doğru aktarıldığını kanıtlamaz. Doğrulama sonrası oluşturulan önizleme veya XML kontrolü, gerçek aktarımı görmek için daha güvenilir bir adımdır.

Alan adını bulamıyorsanız, portal yardım metnini ve kullanıcı yetkilerini kontrol edin. Menüde sipariş bilgisi görünmüyorsa, ilgili özellik rol bazında kapatılmış veya yalnızca belirli belge türlerinde açılmış olabilir.

Portalda sipariş bilgisi zorunlu hatası nasıl çözülür?

Portalda sipariş bilgisi zorunlu hatasını çözmek için taslağı açın, gerçek sipariş referansını ilgili alana girin, doğrulama çalıştırın ve başarılı kontrolden sonra belgeyi gönderin.

İlk olarak gönderilmemiş taslağın belge numarasını not edin. Aynı satış için yeni bir taslak açmadan mevcut kaydı düzenlemek, çift fatura oluşturma riskini azaltır.

1. Taslak faturayı açın ve Sipariş Bilgileri, Sipariş Referansı veya benzer adlı bölümü bulun.
2. Müşterinin sipariş belgesindeki numarayı ilgili sipariş numarası alanına eksiksiz girin.
3. Sipariş tarihini, sipariş formunda yazan tarihle karşılaştırarak tarih alanına aktarın.
4. Müşterinin istediği ek referansı açıklama alanına değil, varsa özel referans alanına yazın.
5. Kaydedin, taslağı yeniden doğrulayın ve ekranda kalan başka uyarıları tek tek inceleyin.
6. Doğrulama başarılıysa gönderin ve oluşan gönderim yanıtını belge numarasıyla birlikte saklayın.

Portal sipariş numarasını kabul etmiyorsa başındaki sıfırları, tireleri ve boşlukları sipariş belgesiyle karşılaştırın. Bazı sistemler numarayı metin olarak, bazıları ise belirli karakter kurallarıyla kaydedebilir.

Sipariş bulunmuyorsa alanı rastgele doldurmayın. Portalda zorunluluk ayarı işletme yöneticisi tarafından değiştirilebiliyorsa, değişikliğin müşteri prosedürüne ve muhasebe sürecine uygunluğunu önce teyit edin.

Fatura gönderilmiş veya onaylanmış durumdaysa aynı belgeyi geriye dönük değiştirmeye çalışmayın. Düzeltme, iptal, ret veya yeniden düzenleme yöntemi belge durumuna göre değişir; mali müşavirinize danışın.

Entegrasyonda sipariş bilgisi eşleştirmesi nasıl kontrol edilir?

Entegrasyonda bu hatayı çözmek için önce kaynak ERP alanını, sonra hedef e-belge alanını ve son olarak oluşan XML içeriğini karşılaştırın. Üç noktadan biri boşsa veri aktarımı tamamlanmamıştır.

Kaynak sistemde sipariş numarası satış siparişi, müşteri siparişi veya proje kodu adıyla tutulabilir. Entegrasyon eşleştirmesi bu alanlardan hangisini okuyacağını açıkça belirlemelidir.

Boş değer, yalnızca boş bırakılmış alan demek değildir. Null değer, tek boşluk, görünmeyen karakter veya formatı bozuk tarih de bazı doğrulama katmanlarında eksik bilgi gibi değerlendirilir.

Test ortamında çalışan eşleştirme, üretim ortamında aynı sonucu vermeyebilir. Müşteri kartı kodu, belge senaryosu, şube tanımı ve şablon sürümü iki ortamda ayrı ayrı karşılaştırılmalıdır.

Entegrasyon logunda istek zamanı, belge numarası, hata mesajı ve mümkünse maskelenmiş XML bulunmalıdır. Hassas ticari verileri açık kanallarda paylaşmadan, destek kaydına yalnızca gerekli teknik bölümü ekleyin.

Alanı düzelttikten sonra eski taslağı tekrar göndermek yerine yeni XML üretin. Şablon önbelleği veya önceki başarısız isteğin saklanması, doğru bilgi girilse bile aynı hatanın tekrarlanmasına neden olabilir.

Sipariş yoksa sipariş bilgisi zorunluluğu nasıl yönetilir?

Sipariş yoksa sipariş bilgisi zorunlu hatasını çözmenin doğru yolu, sahte bir referans girmek değil, zorunluluğun kaynağını belirlemektir. Kural işletme ayarıysa yetkili kullanıcıyla, müşteri şartıysa müşteriyle görüşülmelidir.

Önce satışın gerçekten siparişsiz olup olmadığını kontrol edin. Telefon görüşmesi, e-posta, teklif kabulü veya müşteri portalındaki talep, ayrı bir sipariş numarası bulunmasa bile işlemin dayanağını gösterebilir.

Örneğin küçük bir kafe, kurumsal etkinlik için 200 kişilik kahve hizmeti verirken müşteri satın alma siparişi istemiş olabilir. Kafe sahibi yalnızca sözlü onay aldıysa, önce müşteriden referans gerekip gerekmediğini yazılı teyit etmelidir.

Müşteri sipariş numarası istemiyor, işletme yazılımı ise her faturada alanı zorunlu tutuyorsa kural koşullu hâle getirilebilir. Bu değişiklik, yazılım yöneticisi tarafından test edilerek muhasebe sorumlusunun onayıyla uygulanmalıdır.

Yanlış: Sipariş bulunmadığı hâlde teklif numarasını sipariş numarası olarak göstermektir. Doğru: Teklifin siparişe dönüşüp dönüşmediğini belgelemek ve doğru referans türünü kullanmaktır.

Siparişsiz satışlarda açıklama alanına işlem dayanağını yazmak yardımcı olabilir. Ancak açıklama, sistemin teknik olarak beklediği sipariş referansı alanının yerine geçmeyebilir.

Tereddüt mevzuat veya belge düzeniyle ilgiliyse güncel GİB duyurusunu ve mali müşavirinizi kontrol edin. Yazılım uyarısını kaldırmak, tek başına işlemin muhasebe açısından doğru olduğunu göstermez.

e-Fatura ve e-Arşiv belge türü bu hatayı etkiler mi?

e-Fatura ve e-Arşiv süreçlerinde sipariş bilgisi kontrolünün ne zaman çalışacağı, belge türüne ve kullanılan uygulamanın kurallarına göre değişebilir. Aynı sipariş alanı bir belgede isteğe bağlı, diğerinde koşullu olabilir.

e-Fatura alıcısı, kendi satın alma sistemiyle eşleştirme yapmak için sipariş numarası isteyebilir. Bu talep çoğunlukla müşteri prosedürü, sözleşme veya kurumsal kabul süreciyle ilgilidir.

e-Arşiv düzenlerken de portal veya özel entegratör şablonu sipariş referansı isteyebilir. Ancak ekrandaki zorunluluğu aşmak için belge türünü gerçeğe aykırı biçimde değiştirmek doğru bir çözüm değildir.

Belge gönderimden sonra reddedildiyse ret açıklamasını okuyun. [e-Arşiv Fatura Reddedildi: Neden Olur, Çözüm Adımları](/blog/e-arsiv-fatura-reddedildi-hatasi-nasil-cozulur-neden-olur-adim-adim-cozum) yazısındaki genel ret kontrolü, sipariş uyarısını diğer ret nedenlerinden ayırmaya yardımcı olur.

Sipariş numarası, fatura numarası, irsaliye numarası ve müşteri referansı ayrı alanlardır. Birini diğerinin yerine yazmak, ekrandaki ilk uyarıyı geçirse bile sonraki doğrulamada yeni hata oluşturabilir.

Belge senaryosunu yalnızca hatayı gizlemek için değiştirmeyin. İşlemin gerçek niteliği, alıcının durumu ve mevzuat koşulları uygun değilse farklı senaryo seçimi yeni bir uyumsuzluk yaratabilir.

Belge türü konusunda güncel GİB duyurusunu ve mali müşavirinizi kontrol edin. Uygulama ekranındaki kural ile mevzuattaki yükümlülük aynı kavram değildir.

XML içinde sipariş referansı nasıl doğrulanır?

XML kontrolü, sipariş bilgisinin yalnızca ekranda değil, gönderilecek e-belgenin içinde de yer aldığını gösterir. Ekran doğru görünürken XML boşsa sorun kullanıcı girişinde değil, veri dönüşümündedir.

UBL-TR yapısında sipariş referansı çoğu uygulamada cac:OrderReference bölümü altında izlenir. Bu bölümde sipariş numarasını temsil eden cbc:ID ve sipariş tarihini temsil eden cbc:IssueDate alanları bulunabilir.

XML incelemesinde önce belgeyi, sonra sipariş bölümünü, ardından değerlerin doğru müşteri ve işlemle ilişkisini kontrol edin. Fatura numarasını OrderReference alanında görmek, sipariş bilgisinin doğru olduğu anlamına gelmez.

Şema hatası ile iş kuralı hatasını ayırmak önemlidir. Şema hatası XML yapısının veya veri tipinin uygun olmadığını, iş kuralı hatası ise belirli bir alanın işlem için beklenenden farklı olduğunu gösterebilir.

Önizlemede logo görünmüyor ancak sipariş uyarısı bulunmuyorsa iki sorunu birbirine bağlamayın. Görsel sorunlar için [Logo Görünmüyor Sorunu: Neden Olur, Nasıl Çözülür?](/blog/logo-gorunmuyor-sorunu-nasil-cozulur-neden-olur-adim-adim-cozum) rehberini ayrıca inceleyin.

Ürün satırlarında birim kodu hatası da varsa bu, sipariş referansından ayrı bir veri problemidir. [Birim Kodu Geçersiz Hatası: Adım Adım Nasıl Çözülür?](/blog/birim-kodu-gecersiz-hatasi-adim-adim-nasil-cozulur) yazısındaki birim eşleştirmesini kontrol edin.

Uzman notu: XML dosyasını elle değiştirmek yerine kaynak ERP alanını düzeltip belgeyi yeniden üretin. Elle değişiklik, imza ve bütünlük kontrollerinde yeni bir sorun oluşturabilir.

Bilgi girildiği hâlde hata neden devam eder?

Bilgi girildiği hâlde sipariş bilgisi zorunlu hatası devam ediyorsa sistem değeri kaydetmemiş, yanlış alanı okumuş veya eski taslağın XML içeriğini kullanıyor olabilir.

Önce alanı doldurduktan sonra kaydet düğmesine bastığınızı doğrulayın. Bazı portallar, sekme değiştirilmeden veya taslak yeniden kaydedilmeden girilen bilgiyi gönderim nesnesine aktarmayabilir.

Numaranın başındaki sıfırlar, tireler, eğik çizgiler ve sonundaki boşluklar karşılaştırılmalıdır. Müşterinin istediği biçim ile yazılımın kabul ettiği biçim farklıysa, desteklenen formatı öğrenmeden karakterleri rastgele silmeyin.

Kopya şablon kullanıyorsanız şablondaki sipariş alanının doğru kaynakla eşleştiğini inceleyin. Bir önceki müşteriye ait sabit değer, yeni faturada görünmese bile XML üretiminde kalmış olabilir.

Başarısız belgeyi art arda göndermek, aynı işlem için çok sayıda taslak veya mükerrer kayıt oluşturabilir. Her denemede yeni belge açmak yerine mevcut durumun ne olduğunu ve gönderim yanıtını kontrol edin.

Hata tarih bilgisiyle birlikte görülüyorsa sipariş tarihi ile fatura tarihini yeniden ayırın. Tarih alanı sorunu için [Fatura Tarihi Geçersiz Hatası Nasıl Çözülür? Rehber](/blog/fatura-tarihi-gecersiz-hatasi-nasil-cozulur-neden-olur-adim-adim-cozum) içindeki kontrol sırasını uygulayın.

Sorun devam ederse ekran görüntüsü, belge numarası, işlem zamanı, kullanılan senaryo ve hata yanıtını hazırlayın. Destek ekibine yalnızca aynı hatanın tekrarlandığını değil, hangi kontrolün başarıyla geçtiğini de bildirin.

Hata çözümü için hangi belgeler ve kayıtlar hazırlanır?

Sipariş bilgisi zorunlu hatasını incelemek için sipariş formu, müşteri talebi, ERP kayıt numarası, fatura taslağı ve teknik hata yanıtı birlikte hazırlanmalıdır.

İşlemin dayanağı bir e-posta ise gönderici, alıcı, tarih ve siparişe ilişkin bölüm korunmalıdır. Sözlü siparişte ise müşterinin yazılı teyidi veya işletmenin iç satış kaydı, açıklayıcı bir destek belgesi olabilir.

• Sipariş numarasının kaynak belgedeki biçimiyle karşılaştırıldığını doğrulayın.
• Sipariş tarihinin fatura tarihiyle karıştırılmadığını kontrol edin.
• Portalda doldurulan değerin taslak kaydına işlendiğini teyit edin.
• Entegrasyon logunda hedef sipariş alanının boş gönderilmediğini inceleyin.
• XML içinde sipariş referansının doğru bölümde bulunduğunu kontrol edin.
• Gönderim yanıtındaki belge durumunu ve hata açıklamasını saklayın.

Destek talebine müşteri unvanı, vergi bilgisi veya ticari sırları gereksiz yere eklemeyin. Teknik inceleme için gerekli alanları paylaşın ve kişisel veya ticari verileri mümkün olduğunca maskeleyin.

Belge daha önce gönderildiyse yeni denemeden önce önceki yanıtı kontrol edin. Reddedilmiş, işleniyor, kabul edilmiş veya iptal sürecindeki belgeler için izlenecek işlem aynı değildir.

Mevzuat yorumu, siparişsiz satışın belge niteliği veya düzeltme yöntemi konusunda güncel GİB duyurusunu ve mali müşavirinizi kontrol edin. Teknik destek, muhasebe kararının yerine geçmez.

Sipariş bilgisi zorunlu hatası nasıl önlenir?

Sipariş bilgisi zorunlu hatasını önlemek için müşteri kartlarını, sipariş alanı eşleştirmelerini, belge şablonlarını ve gönderim öncesi doğrulama adımlarını düzenli kontrol edin.

Her müşteri için aynı kuralı varsaymayın. Kurumsal alıcıların satın alma siparişi isteyip istemediğini, hangi referans biçimini kullandığını ve faturanın hangi kanaldan kabul edildiğini müşteri bazında kaydedin.

ERP içinde sipariş numarası, teklif numarası, sevk irsaliyesi ve proje kodu alanlarını ayrı tutun. Alanların birleştirilmesi, fatura oluşturulurken hangi bilginin aktarılacağını belirsiz hâle getirir.

Yeni şablon veya entegrasyon sürümünü önce düşük riskli bir test belgesiyle deneyin. Testte kaynak ekran, oluşturulan XML ve doğrulama yanıtını birlikte karşılaştırın.

Kullanıcı eğitiminde yalnızca alanın nerede olduğunu göstermeyin. Sipariş yoksa ne yapılacağını, hangi bilginin yazılmayacağını ve gönderilmiş belgenin neden doğrudan değiştirilemeyeceğini de açıklayın.

Farklı e-dönüşüm hatalarını sınıflandırmak, gereksiz işlem tekrarını azaltır. Örneğin e-Defter berat imza sorunu sipariş alanıyla ilgili değildir; bu ayrım için [e-Defter Berat İmza Hatası: Neden Olur, Adım Adım Çözüm](/blog/e-defter-berat-imza-hatasi-neden-olur-adim-adim-cozum) rehberine bakabilirsiniz.

Ayda bir kez başarısız gönderim raporlarını inceleyin. Aynı müşteri, kullanıcı veya şablonda tekrarlanan uyarılar, tek bir fatura hatasından çok sistematik bir eşleştirme problemine işaret eder.

Özet: 5 maddede sipariş bilgisi zorunlu hatası çözümü

Sipariş bilgisi zorunlu hatası çözülebilir; ancak çözüm, rastgele bir numara yazmak değil, sipariş kaynağını ve veri aktarımını doğrulamaktır. Aşağıdaki beş madde, portal ve entegrasyon süreçlerinde uygulanabilecek kısa bir kontrol çerçevesi sunar.

• Gerçek siparişi bulun: Sipariş numarası ve tarihini müşterinin satın alma belgesi, e-postası veya ERP kaydıyla karşılaştırın. Teklif, irsaliye veya fatura numarasını sipariş referansı yerine kullanmayın.
• Doğru alanı doldurun: Bilgiyi yalnızca açıklama bölümüne yazmak yerine Sipariş Bilgileri veya Sipariş Referansı alanına girin. Kaydettikten sonra alanın taslakta gerçekten korunduğunu yeniden açarak kontrol edin.
• XML aktarımını inceleyin: Ekranda görünen değerin oluşturulan XML içinde OrderReference bölümüne aktarıldığını doğrulayın. Alan boşsa kaynak ERP, entegrasyon haritası veya kullanılan şablon üzerinde düzeltme yapın.
• Sipariş yoksa kuralı sorgulayın: Sahte referans üretmeyin. Müşteri talebini ve işletme ayarını inceleyin; gerekiyorsa yetkili kullanıcıdan koşullu zorunluluk tanımlamasını isteyin.
• Belge durumunu kontrol edin: Yeni gönderimden önce eski taslağın veya reddedilen belgenin durumunu inceleyin. Düzeltme yöntemi için güncel GİB duyurusunu ve mali müşavirinizi kontrol edin.

Bu sıra, sorunu kullanıcı girişi, müşteri kuralı, portal ayarı ve teknik eşleştirme olarak ayırır. Her adımın sonucunu belge numarası ve işlem zamanı ile kaydetmek, tekrar eden hatalarda inceleme süresini kısaltır.

Belge sayınız arttığında, sipariş referanslarının hangi e-belge sürecinde kullanıldığını ve portalınızın kontör koşullarını ayrıca kontrol edin.

efaturakontor.com'da tüm e-belgelerde geçerli havuz kontör paketleri 100'den 500.000 kontöre kadar sunulur; ücretsiz e-fatura portalı bulunur, kontörler Sovos altyapısına aynı gün tanımlanır ve paketlerin kullanım süresi 12-18 aydır.