Fatura Adresi Nedir? Teslimat Adresinden Farkı
Fatura adresi nedir, teslimat adresinden nasıl ayrılır? Faturalama, sözleşme ve müşteri kayıtlarında adres tutarlılığını sağlamak için kurumsal rehber.
Sipariş ya da teklif formlarında çoğu zaman iki adres alanı bulunur. Biri ürünün gideceği yeri, diğeri faturanın düzenleneceği adresi gösterir. Pek çok müşteri için ikisi aynı olduğundan kurum içinde de tek bir bilgi gibi ele alınır. Oysa fatura adresi nedir sorusunun cevabı, teslimat adresinden farklı bir amacı ve farklı bir sorumlu ekibi gösterir. Bu ayrım netleşmezse finans, satış, müşteri hizmetleri ve lojistik ekipleri aynı müşteri için farklı adresler tutar. Sorun da çoğunlukla bir fatura düzeltmesi, tutmayan bir mutabakat ya da uzayan bir iade sırasında fark edilir.
Bu rehberde EKKASOFT Ekibi olarak önce iki kavramı birbirinden ayırıyoruz. Ardından tutarsızlığın etkilerini, bir karar çerçevesini, aşamalı uygulama planını, sık yapılan hataları ve başarının nasıl izleneceğini ele alıyoruz. Yazının sonunda ekibinizle paylaşabileceğiniz bir kontrol listesi bulacaksınız.
Bu yazı genel bilgi amaçlıdır. Faturada yer alması gereken bilgiler ve sözleşmelerde yazan adreslerin hukuki sonuçları için mali müşavirinize ve hukuk danışmanınıza başvurun.
Fatura adresi nedir?
Fatura adresi, faturada alıcı olarak görünen kişinin ya da kurumun adresidir. Ürünün nereye gittiğini göstermez. Satışın kime yapıldığını ve belgenin kimin adına düzenlendiğini gösterir.
Bireysel müşterilerde fatura adresi genellikle kişinin beyan ettiği ev ya da iş adresidir. Kurumsal müşterilerde ise bu adresin, şirketin ticari ve vergi kayıtlarında kullandığı merkez ya da şube adresiyle uyumlu olması beklenir. Karşı tarafın muhasebesi faturayı kendi kayıtlarına işleyecektir. Bu nedenle uyuşmayan bir adres, belgenin geri gönderilmesine ya da düzeltme talebine yol açabilir.
Fatura adresini teslimat adresinden üç özellik ayırır:
- Belgeye bağlıdır. Fatura, düzenlendiği andaki adresle kalır. Müşteri sonradan taşınsa da geçmiş belge değişmez.
- Finansın sorumluluğundadır. Bu adresteki bir hata, muhasebede düzeltme, yeniden düzenleme ve ek yazışma olarak geri döner.
- Seyrek değişir ama değiştiğinde zincirleme etki yaratır. Kurumsal bir müşterinin merkez adresi değiştiğinde açık siparişlerin, sözleşmelerin ve cari hesabın birlikte gözden geçirilmesi gerekir.
Teslimat adresi nedir, fatura adresinden farkı ne?
Teslimat adresi nedir sorusunun cevabı daha somuttur: Ürünün ya da hizmetin fiziksel olarak ulaşacağı yerdir. Kargo firması, kurye, montaj ekibi ya da saha personeli bu adrese gider. Bir müşterinin tek fatura adresi ama birden fazla teslimat adresi olabilir.
| Ölçüt | Fatura adresi | Teslimat adresi |
|---|---|---|
| Cevapladığı soru | Satış kime yapıldı? | Ürün nereye gidecek? |
| Asıl kullanan ekipler | Finans, muhasebe, satış | Lojistik, depo, saha, müşteri hizmetleri |
| Bağlı olduğu kayıt | Fatura ve cari hesap | Sipariş ve gönderi |
| Değişim sıklığı | Seyrek | Siparişten siparişe değişebilir |
| Hatanın tipik sonucu | Fatura düzeltmesi, mutabakat farkı, gecikmiş tahsilat | Teslim edilemeyen gönderi, yeniden gönderim, şikâyet |
İki adres en çok şu durumlarda birbirinden ayrılır:
- Ödemeyi yapanla ürünü teslim alan kişinin farklı olduğu hediye siparişleri
- Faturanın merkeze, teslimatın şubeye, depoya ya da şantiyeye gittiği kurumsal alımlar
- Tek faturaya bağlı, birden çok noktaya yapılan B2B sevkiyatlar
- Hizmetin faturadakinden farklı bir adreste verildiği kurulum işleri
Kurumların çoğunda bunlara ek adres rolleri de vardır: sözleşmede tarafların ve yazışmaların adresi, ürünün geri alınacağı iade adresi ve CRM'deki iletişim adresi. Buradan çıkan ilk ilke basittir: Her adres kaydının bir rolü olmalı ve bu rol kayıtta açıkça yazılmalıdır.
E-ticaret formlarındaki "Fatura adresim teslimat adresimle aynı" seçeneği müşteri için kolaylıktır. Ancak bu seçim, sipariş anında iki ayrı kayıt olarak saklanmalıdır. Aksi hâlde teslimat adresinde sonradan yapılan bir düzeltme, faturanın adresini de fark edilmeden değiştirebilir.
Farklı sistemlerde farklı adres: Tutarsızlık nasıl başlar?
Orta ölçekli bir işletmede bile adres bilgisi pek çok yerde tutulur: e-ticaret altyapısı, ERP ya da muhasebe yazılımı, CRM, kargo entegrasyonu, çağrı merkezi ekranı, sözleşme arşivi ve ekiplerin tabloları. Tutarsızlık çoğunlukla şu yollardan biriyle başlar:
- Farklı giriş biçimleri. Bir sistemde il, ilçe ve mahalle ayrı alanlardadır, diğerinde adres tek satırlık serbest metindir. "Caferağa Mh. Moda Cd. No:12" ile "Moda Caddesi 12, Caferağa, Kadıköy" aynı yeri anlatır. Sistemler için ise iki ayrı metindir.
- Tek yerde kalan düzeltme. Geri dönen bir gönderinin ardından adres kargo panelinde düzeltilir, CRM ve ERP ise eski adresle kalır.
- Adla eşleştirme. Aynı mahalle adı farklı ilçelerde, hatta aynı ilçedeki farklı yerleşimlerde bulunabilir. Adlarına göre birleştirilen kayıtlar yanlış yere bağlanır.
- Rol karmaşası. Fatura adresi alanına teslimat adresi yazılır ya da bunun tersi olur.
Bir örnek senaryo düşünelim. Kurumsal bir müşteri merkez ofisini taşır ve bunu satış temsilcisine bildirir. Temsilci CRM kaydını günceller ama ERP'deki cari kart eski adreste kalır. Sonraki faturalar eski adresle düzenlenir ve müşterinin muhasebesi düzeltme ister. Aynı hafta başka bir çalışan "adresi güncellemek" için müşterinin teslimat adreslerini de değiştirir. Bu yüzden şubeye gitmesi gereken bir gönderi yeni merkeze yönlenir. Tek bir bilgi değişikliği satış, finans ve lojistikte ayrı ayrı iş doğurmuş olur.
Hatalı adresin teslimat tarafındaki maliyet kalemlerini hatalı adresin e-ticarete maliyeti yazımızda ele almıştık. Bu yazının odağı ise adres bilgisinin kurum içinde tutarlı kalmasıdır.
Tutarsızlığın faturalama, mutabakat ve iade süreçlerine etkisi
Faturalama ve sözleşmeler
Hatalı bir fatura adresi düzeltme, iptal ve yeniden düzenleme döngüsü başlatır. Kurumsal alıcılar çoğu zaman belgeyi onaylamadan ödeme sürecini başlatmadığı için tahsilat da gecikir. Sözleşmedeki adres CRM'deki ve faturadaki adresten farklıysa yazışma ve bildirimlerin nereye gönderileceği belirsizleşir. Bunun sonucu sözleşmenin içeriğine bağlıdır. Hangi adresin esas alınacağını hukuk ekibinizle belirleyin ve bu kararı kayıtlara yansıtın.
Mutabakat
- Cari hesap: Aynı müşteri farklı adreslerle iki ayrı cari kart olarak açılmışsa faturalar ve ödemeler iki hesaba dağılır. Dönem sonunda bakiyeler müşterinin kayıtlarıyla tutmaz.
- Lojistik: Taşıyıcının faturasındaki gönderiler sipariş kayıtlarıyla eşleştirilirken farklı yazımlar eşleşmeyi bozar. Bazı taşıma anlaşmalarında adres düzeltme ya da yeniden gönderim faturaya ayrı bir kalem olarak yansıyabilir.
- Satış raporları: Bölge bazlı ciro ve prim hesapları adrese dayanıyorsa yanlış girilmiş bir ilçe, satışın yanlış bölgeye yazılmasına yol açar.
İade süreçleri
Bir iadede üç adres aynı anda devreye girebilir: orijinal siparişin teslimat adresi, orijinal faturanın adresi ve ürünün geri alınacağı adres. Bu adresler ayrı rollerle tutulmuyorsa iade kaydı açılırken birbirine karışır. Para iadesi ve iade belgeleri orijinal faturayla eşleştirilir. Müşteri sistemlerde iki ayrı kayıt olarak duruyorsa bu eşleştirme elle yapılır ve süreç uzar. Kurumsal alıcılarda iade belgesinin nasıl düzenleneceği konusunda mali müşavirinizin görüşünü alın.
Karar çerçevesi: Bu konu sizin için ne kadar öncelikli?
Adres tutarlılığı bir veri kalitesi konusu gibi görünür, ancak yatırım kararını operasyon maliyetine bakarak vermek gerekir. Şu sorular, önceliği ve kapsamı belirlemenize yardımcı olur:
- Bir müşterinin adresi değiştiğinde kaç sistem ve kaç kişi devreye giriyor?
- Fatura düzeltmeleri neden koduyla kaydediliyor mu? "Adres" ayrı bir neden olarak görülebiliyor mu?
- Mutabakatta eşleşmeyen kayıtlar kimde birikiyor?
- Aynı müşteri için birden fazla cari kart ya da CRM kaydı var mı?
- Adresi kimler değiştirebiliyor ve yapılan değişiklik kayda geçiyor mu?
- Geçmiş faturalar, düzenlendikleri andaki adresi koruyor mu?
Bu soruların cevapları, aşağıdaki üç düzeyden hangisinde olduğunuzu gösterir:
| Durum | Tipik belirti | Önerilen kapsam |
|---|---|---|
| Adres tek sistemde, ağırlıkla bireysel müşteriler | Ara sıra teslimat sorunu, seyrek fatura düzeltmesi | Yapılandırılmış form, fatura ve teslimat adresinin ayrılması |
| Adres birden fazla sistemde, ekipler ayrı çalışıyor | Mükerrer müşteri kaydı, tek yerde kalan düzeltmeler | Tek doğruluk kaynağı, doğrulama, aktarım kuralları |
| Ağırlıkla kurumsal, sözleşmeli ve çok şubeli müşteriler | Sık fatura düzeltmesi, mutabakat farkları | Ana veri yönetimi: sahiplik, onay akışı, sürüm takibi, raporlama |
Bütçeyi değerlendirirken iki tarafı yan yana koyun. Yatırım tarafında entegrasyon emeği, mevcut kayıtların temizliği için harcanacak ekip zamanı, eğitim ve adres verisi hizmetinin paket maliyeti yer alır. Etki tarafında ise elle düzeltme emeği, mutabakat süresi, yeniden gönderimler, tahsilat gecikmeleri ve raporların güvenilirliği bulunur. Etki kalemlerini tahmine dayanarak değil, aşağıda anlatılan göstergelerin başlangıç değerlerini ölçerek değerlendirmek kararı sağlamlaştırır.
Tek doğruluk kaynağı: Adres nerede tutulur, kim sahiplenir?
Tek doğruluk kaynağı, bir bilginin kurum içinde yalnız bir yerde oluşturulup güncellendiği, diğer sistemlerin ise bu kayda başvurarak çalıştığı düzendir. Adres için bu yer çoğunlukla müşteri ana verisinin tutulduğu ERP ya da CRM'dir. Hangi sistem seçildiğinden çok, tek bir sistemin seçilmesi önemlidir.
- Adres ayrı bir kayıt olsun. Müşteriye bağlı, rolü (fatura, teslimat, iade, sözleşme) ve geçerlilik tarihleri belli kayıtlar kullanın.
- Bileşenlerine ayrılsın. İl, ilçe, mahalle, cadde/sokak ve dış kapı numarası ayrı alanlarda tutulsun. İç kapı, kat, bina adı ve tarif ise ayrı bir açıklama alanına yazılsın. Adres kataloğu dış kapı düzeyine kadar iner. Daire ve tarif bilgisini kendi kayıtlarınızda tutarsınız.
- Adla değil kimlikle bağlansın. API Türkiye'de il, ilçe, mahalle, sokak ve dış kapı kayıtlarının her biri, katalog sürümünden bağımsız bir kimlik (
stableId) taşır. Bu kimliği saklarsanız, yazımı farklı iki kaydın aynı yeri gösterip göstermediğini kolayca anlarsınız. Aynı adı taşıyan mahalleler de birbirine karışmaz. - Sahiplik yazılı olsun. Her adres rolünü kimin değiştirebileceği ve kimin onaylayacağı belli olmalı.
Aşağıdaki matris bir başlangıç örneğidir. Kendi yapınıza göre uyarlayın:
| Adres rolü | Oluşturan/güncelleyen | Onaylayan | Kullanan sistemler |
|---|---|---|---|
| Fatura | Müşteri, satış | Finans (kurumsal müşterilerde) | ERP, e-ticaret, CRM |
| Teslimat | Müşteri, müşteri hizmetleri | Operasyon (gerektiğinde) | Kargo, depo, saha |
| İade | Müşteri hizmetleri | Operasyon | Kargo, finans |
| Sözleşme ve yazışma | Satış | Hukuk | Sözleşme arşivi, CRM |
Bir adres verisi hizmeti bu yapıya iki noktada katkı sağlar.
- Yeni kayıtlar: Formlarda il, ilçe, mahalle, cadde/sokak ve dış kapı adım adım listeden seçilir. Yazım hatalarını tolere eden akıllı arama da adresi bulmayı hızlandırır. Böylece yeni kayıtlar baştan bileşenlerine ayrılmış olarak girilir. Bu özellikler ücretsiz Core paketinde yer alır. Form tasarımı için hazır adres seçici bileşen örneklerine göz atabilirsiniz.
- Mevcut kayıtlar: Pro ve üzeri paketlerdeki adres doğrulama ve standartlaştırma özelliği, kayıtları katalogla karşılaştırır. Sonuçta adresin standart yazımını ve her bileşenin kimliğini döndürür. Doğrulamanın genel mantığını adres doğrulama sistemi rehberimizde anlatmıştık.
Doğrulamanın sınırını da bilmek gerekir. Doğrulama, adresin katalogda bulunduğunu ve bileşenlerinin birbiriyle uyumlu olduğunu gösterir. Ancak o adresin müşterinin gerçek fatura adresi olduğunu ya da teslimatın mutlaka yapılabileceğini kanıtlamaz. Bunu müşterinin beyanı ve sizin teyit süreçleriniz sağlar.
Değişiklik yönetimi: Adres değiştiğinde ne yapılmalı?
Bir kayıttaki adres iki nedenle değişir: Ya müşteri taşınır ya da adresin kendisi değişir. İki durum farklı süreçler gerektirir.
Müşteri kaynaklı değişiklik
- Eski kaydı silmeyin, kapatın. Yeni adres için yeni bir kayıt açın, eskisini geçerlilik bitiş tarihiyle kapatın. Böylece geçmiş siparişler bağlamını kaybetmez.
- Belgeye adresin kopyasını yazın. Fatura, adresi düzenlendiği andaki hâliyle taşımalıdır. Belge yalnız güncel adres kaydına bağlanırsa, adres değiştiğinde geçmiş fatura da farklı görünmeye başlayabilir.
- Rolleri birbirinden bağımsız tutun. Teslimat adresindeki bir değişiklik fatura adresini kendiliğinden değiştirmemelidir. Tersi de geçerlidir.
- Açık işlemleri gözden geçirin. Bekleyen siparişleri, kesilecek faturaları, planlı sevkiyatları ve yenilenecek sözleşmeleri kontrol edin.
- Her değişikliği kayda geçirin. Kim, ne zaman, hangi talep üzerine değiştirdi? Kurumsal müşterilerde fatura adresi değişikliğini yazılı talebe ve finans onayına bağlamayı değerlendirin.
- Aktarımı tanımlayın. Değişiklik, ana kayıttan diğer sistemlere otomatik olarak ya da yazılı bir prosedürle aktarılsın.
Katalog kaynaklı değişiklik
Müşteri taşınmasa da adresinin yazımı değişebilir. Sokak adları değişir, mahalle düzenlemeleri yapılır, yeni dış kapılar eklenir. Bu durumda şunlara dikkat edin:
- Kayıtlarda
stableIdsaklayın. Dış kapı kayıtlarındakiidalanı ise yalnız o anki katalog sürümüne aittir ve sürümler arasında değişebilir. Bu yüzden onu kalıcı referans olarak kullanmayın. - Doğrulama sırasında dönen katalog sürüm bilgisini (
datasetVersion) adres kaydıyla birlikte saklayın. Böylece her kaydın hangi katalog sürümüne göre kontrol edildiği bilinir. Yeni bir sürüm yayınlandığında kayıtları planlı biçimde yeniden kontrol edebilirsiniz. - Katalogdaki değişiklikleri düzenlenmiş belgelere yansıtmayın. Yalnız sonraki işlemlerde kullanılacak yazımı güncelleyin. Kurumsal fatura adreslerinde yazımı değiştirmeden önce müşteriyle teyit edin. Böylece karşı tarafın kayıtlarıyla uyum korunur.
Uygulama planı: Aşamalar, roller, girdiler ve çıktılar
Önce rolleri belirleyin:
- Sponsor: Genellikle operasyon ya da finans yöneticisidir. Önceliği ve bütçeyi sahiplenir.
- Veri sahipleri: Her adres rolü için kuralları koyar ve değişiklikleri onaylar.
- Süreç sahipleri: Finans, satış, müşteri hizmetleri ve lojistikte yeni kuralların uygulanmasından sorumludur.
- Teknik ekip: Entegrasyonu, sistemler arası aktarımı ve raporlamayı kurar.
| Aşama | Sorumlu | Girdi | Çıktı |
|---|---|---|---|
| 1. Envanter | Sponsor, süreç sahipleri, teknik ekip | Sistem listesi, örnek kayıtlar, son dönem düzeltme ve iade kayıtları | Adres akış haritası, göstergelerin başlangıç değerleri |
| 2. Model ve kurallar | Veri sahipleri, finans, hukuk | Adres rolleri, mevcut formlar | Veri sözlüğü, sahiplik matrisi, değişiklik prosedürü |
| 3. Giriş noktaları | Teknik ekip, e-ticaret ve CRM sorumluları | Model, form tasarımları | Yapılandırılmış formlar, kimlikle saklanan yeni kayıtlar |
| 4. Mevcut kayıtların temizliği | Teknik ekip, müşteri hizmetleri, finans | Mevcut kayıtlar, doğrulama sonuçları | Standart kayıtlar, inceleme kuyruğu, birleştirilmiş mükerrer kayıtlar |
| 5. Aktarım ve değişiklik süreci | Teknik ekip, veri sahipleri | Prosedür, sistem bağlantıları | Hangi sistemin adresi güncelleyip hangisinin yalnız okuyacağını belirleyen kurallar, değişiklik kaydı |
| 6. İzleme | Sponsor, veri sahipleri | Göstergeler | Düzenli rapor, iyileştirme listesi |
Bu sıralama bilinçli bir tercihtir. Formlar düzeltilmeden yapılan temizlik, yeni kayıtlar geldikçe boşa gider. Temizlikte önceliği aktif müşterilere, açık siparişlere ve yürürlükteki sözleşmelere verin. Kurumsal fatura adreslerini müşteriyle teyit etmeden otomatik olarak değiştirmeyin.
Teknik ekibinize kısa not
Dördüncü aşamada her kayıt, bileşenlerine ayrılmış hâlde doğrulama servisine gönderilir. Bu özellik Pro ve üzeri paketlerde bulunur. Aşağıdaki örnekteki adres yalnız yanıtın biçimini göstermek içindir:
curl "https://api.apiturkiye.com/v1/addresses/validate" \
-H "X-API-Key: apt_live_..." \
-H "Content-Type: application/json" \
--data '{"province":"İstanbul","district":"Kadıköy","neighborhood":"Caferağa Mahallesi","street":"Moda Caddesi","doorNumber":"12"}'
Yanıt iki sonuçtan birini verir:
- Tam ve tek bir eşleşme bulunursa: Yanıt
valid: truedeğerini taşır. Bununla birlikte standart yazım (normalizedAddress), bileşen kimlikleri (components) ve katalog sürümü (meta.datasetVersion) döner. Ana kayda yazılacak bilgiler bunlardır. - Eşleşme yoksa ya da birden fazla aday varsa: Yanıt
valid: falsedeğerini taşır.failedAtalanı, adresin hangi bileşende eşleşmediğini gösterir. Varsasuggestionsalanı da aynı üst bölgedeki aday kayıtları listeler. Bu kayıtlar inceleme kuyruğuna gönderilir. Böylece inceleyen kişi neye bakması gerektiğini bilir.
API anahtarı yalnız sunucu tarafında tutulmalı, tarayıcı koduna ya da paylaşılan tablolara yazılmamalıdır. Ayrıntılar API dokümantasyonunda yer alır.
Sık yapılan hatalar, riskler ve önlemler
| Hata ya da risk | Sonucu | Önlem |
|---|---|---|
| Fatura adresini teslimat adresine kalıcı olarak bağlamak | Teslimat düzeltmesi faturayı da fark edilmeden değiştirir | Sipariş anında iki ayrı kayıt oluşturmak |
| Adresi tek bir serbest metin alanında tutmak | Karşılaştırma ve doğrulama zorlaşır | Bileşenlerine ayrılmış alanlar |
| Kayıtları adlarına göre eşleştirmek | Aynı adı taşıyan mahalleler yanlış birleşir | Katalog kimliğiyle eşleştirmek |
| Temizliği tek seferlik bir proje saymak | Tutarsızlık yeni kayıtlarla geri gelir | Önce formları düzeltmek, sonra temizlik ve düzenli izleme |
| Doğrulamayı teslimatın yapılabileceğinin ya da müşteri beyanının teyidi saymak | Yanlış güven, atlanan kontroller | Doğrulamayı yalnız bir katalog kontrolü olarak görmek |
| Herkese adres düzenleme yetkisi vermek | Kimin ne değiştirdiği izlenemez | Rol bazlı yetki, değişiklik kaydı |
| Adresi gereğinden fazla yerde kopyalamak | Tutarsızlık ve yetkisiz erişim riski | Kopyalamak yerine ana kayda bağlanmak, erişimi sınırlamak |
Son satırın bir boyutu daha vardır: Bireysel müşterilerin adresi kişisel veri niteliği taşıyabilir. Kopya sayısını azaltmak hem tutarlılığı hem de veriyi korumayı kolaylaştırır. Saklama süreleri, aktarım ve erişim yetkileri için KVKK konusunda uzman bir danışmanın görüşünü alın.
Başarıyı nasıl ölçersiniz?
İşe başlamadan önce mevcut durumu kayda geçirin. Ardından aynı göstergeleri, aynı yöntemle ve düzenli aralıklarla ölçün. Hedeflerinizi kendi başlangıç değerlerinize göre belirleyin.
- Yapılandırılmış kayıt oranı: Ana kayıttaki adreslerin ne kadarı bileşenlerine ayrılmış ve katalog kimliğiyle saklanıyor?
- Adres kaynaklı fatura düzeltmeleri: Düzeltme ve iptal taleplerinde "adres" nedeninin payı zamanla nasıl değişiyor?
- Mutabakat ve iade farkları: Adres nedeniyle elle eşleştirilen kayıtların sayısı ve bunların çözüm süresi.
- Mükerrer müşteri kayıtları: Aynı müşteri için açılmış birden fazla cari kart ya da CRM kaydı.
- Değişikliğin yayılma süresi: Müşterinin bildirimi ile adresin tüm sistemlerde güncellenmesi arasında geçen süre.
- İnceleme kuyruğundaki bekleme süresi: Doğrulanamayan kayıtların kuyrukta ne kadar beklediği.
- Sistemler arası farklar: Ana kayıt ile diğer sistemler düzenli olarak karşılaştırıldığında çıkan uyuşmazlıklar.
Bu göstergelerin bir kısmı, neden kodu tutulmadan ölçülemez. Fatura düzeltmeleri ve iadeler "adres", "tutar" ya da "ürün" gibi nedenlere göre sınıflandırılmıyorsa ilk iş bu sınıflandırmayı başlatmaktır. Her göstergenin bir sorumlusu ve bir gözden geçirme takvimi olsun.
Kontrol listesi
- Fatura, teslimat, iade ve sözleşme adresleri ayrı roller olarak tanımlandı. Her rolün sahibi ve onay kuralı yazılı.
- Adresler bileşenlerine ayrılmış alanlarda tutuluyor. İç kapı ve tarif bilgisi ayrı bir alanda.
- Kayıtlar katalog kimliğiyle (
stableId) saklanıyor ve adlarına göre eşleştirme yapılmıyor. - "Fatura adresi teslimat adresiyle aynı" seçimi iki ayrı kayıt oluşturuyor.
- Düzenlenen faturalar, adresin o anki kopyasını taşıyor.
- Adres değişiklikleri eski kayıt silinmeden, geçerlilik tarihleri ve değişiklik kaydıyla yapılıyor.
- Tek doğruluk kaynağı belirlendi. Diğer sistemlerin adresi nasıl okuyup güncelleyeceği kurala bağlandı.
- Doğrulanamayan kayıtlar, bir sorumluya atanmış inceleme kuyruğunda bekliyor.
- Kurumsal fatura adreslerindeki düzeltmeler müşteriyle teyit ediliyor.
- Doğrulamada kullanılan katalog sürümü, adres kaydıyla birlikte saklanıyor.
- Fatura düzeltmeleri ve iadeler neden koduyla kaydediliyor. Göstergelerin başlangıç değerleri ölçüldü.
- Adres verisine erişim ve saklama kuralları uzman görüşüyle gözden geçirildi.
Sonraki adım
Fatura adresi nedir sorusu tek cümleyle cevaplanabilir. Asıl iş, bu adresin kurumdaki her sistemde aynı kalmasını sağlamaktır. Bu da yeni kayıtların baştan doğru girilmesiyle başlar. Türkiye adres API'si ile formlarınızda il, ilçe, mahalle, sokak ve dış kapı seçimini yapılandırabilir, Core paketiyle ücretsiz başlayabilirsiniz. Mevcut kayıtları doğrulamak için gereken paketleri paket karşılaştırmasında inceleyebilir, teknik ekibinizi API dokümantasyonuna yönlendirebilirsiniz. Denemeye hazırsanız API anahtarınızı ücretsiz kayıt sayfasından alabilirsiniz.