Küresel Ölçekte Tüzel Kişi Belgelerini İzleyen Bir Web Uygulaması Nasıl Oluşturulur

Ne İnşa Ediyorsunuz ve Neden Önemli?

Çok uluslu bir şirket hızla “olmazsa olmaz” tüzel kişi belgeleri biriktirir: kuruluş belgeleri, siciller, yönetici atamaları, vekaletnameler, yıllık beyannameler, vergi kayıtları ve daha fazlası. Zorluk sadece dosyaları saklamak değil—her ülkenin kendine ait belge formatları, adlandırma kuralları, yenileme döngüleri, başvuru portalları ve kaçırılan son tarihler için cezaları olduğunda uyum sağlamak.

Bu işler e-postalarda ve elektronik tablolarda dolandığında riskler tahmin edilebilir şekilde ortaya çıkar: banka açılışında keşfedilen süresi geçmiş sertifikalar, denetimde eksik imzalar veya kimin sorumlu olduğu net olmayan bir yenileme. Sonuçta gecikmeler, cezalar ve önlenebilir stres olur; bunların çoğu daha net bir yönetişim ve paylaşılan bir kayıt sistemiyle engellenebilirdi.

Kimler fayda sağlar

Bu tür bir web uygulaması öncelikle kesinlik ve görünürlük isteyen ekipler içindir:

• Varlık hijyenini yöneten hukuki operasyonlar ve kurumsal sekreterlik ekipleri
• Bankacılık, ödemeler ve tedarikçi kabulünü yöneten finans ekipleri
• Denetimler ve iç kontroller için hazırlanan uyum ekipleri
• En son onaylı sürümlere erişmesi gereken dış hukuk danışmanları (her şeyi görmeden)

Bu uygulama ne işe yarar (ve ne yapmaz)

Bu bir takip ve yönetişim sistemi: neyin mevcut olduğunu, nerede saklandığını, kimin erişebileceğini, ne zaman sona ereceğini ve sonraki adımın ne olduğunu kaydedersiniz. Yerel yasaları yorumlayan veya hukuki tavsiye veren bir araç değildir; bunun yerine bilinen gereksinimleri operasyonelleştirmenize ve sahipliği belirgin hale getirmenize yardımcı olur.

Bu kılavuzda neler inşa edeceksiniz

Sonunda pratik bir sistem için bir planınız olacak:

• Varlıklar (şirket, şube, bağlı kuruluş) ülkeye ve duruma göre düzenlenmiş
• Belge türleri ile gerekli meta veriler, yenileme kuralları ve versiyon geçmişi
• Görevler ve son tarihler (uyumluluk takvimi) sahipleri ve hatırlatmalarıyla
• İş akışları yükleme → inceleme → onay → yenileme
• Uyarılar ve raporlar “Uyumlu muyuz?” sorusuna denetime hazır çıktılar üreten

Çok Ülke Varlık Belge Takibi için Temel Gereksinimler

Küresel bir varlık belge takipçisi, “varlık + ülke + belge + son tarih”i birincil veri olarak ele aldığında en iyi çalışır—klasör yapısı olarak değil. Ekranları veya depolamayı tasarlamadan önce, yerel kurallar farklı olsa bile her yerde takip edilmesi gerekenleri netleştirin.

En azından neyi takip etmelisiniz

Çoğu organizasyon birden fazla yargı bölgesinde farklı varlık türlerini yönetir:

• Bağlı kuruluşlar (faaliyet gösteren şirketler)
• Şubeler (yabancı bir şirketin tescilli uzantıları)
• Holding şirketleri
• SPV'ler (anlaşmalar, finansman veya fikri mülkiyet için özel amaçlı araçlar)

Her varlığın net bir kimlik profili olmalı: yasal ad(lar), kayıt numarası, yetki alanı, tescilli adres, durum (faal/uyku/dahil), ve temel tarihler (kuruluş, hesap dönemi sonu).

Her ülkede görünen belge türleri (yerel varyasyonlarla)

Genellikle saklamanız ve takip etmeniz gerekenler:

• Kuruluş belgeleri (sertifikalar, esas sözleşme/memo)
• Ana sözleşme veya eşdeğer yönetişim belgeleri
• Yasal siciller (yönetim kurulu, hissedarlar, UBO'lar gereken yerlerde)
• Vergi kimlikleri ve kayıtları (KDV, maaş bordrosu)
• Lisanslar ve izinler (sektöre özel)
• Yıllık beyannameler ve mali tablolar (gönderim kanıtlarıyla)

Uygulama, bir “belge türü” için birden fazla dosyayı desteklemelidir; çünkü ülkeler güncellenmiş dökümanlar ve yeniden mühürlenmiş kopyalar verir.

Güncellemeler ve son tarihleri tetikleyen ana olaylar

Belge yenilemelerini zorunlu kılan olaylar etrafında tasarlayın:

• Kuruluş ve kabul süreci
• Yönetici/görevli değişikliği
• Adres değişikliği
• Yenileme döngüleri (lisanslar, kayıtlar)
• Tasfiye veya kapatma

Başarıyı nasıl ölçeceksiniz

Öncelikleri net tutmak için sonuçları belirleyin:

• Daha az kaçırılan yenileme ve gecikme ücreti (belge sona erme takibi)
• Daha hızlı denetimler (denetime hazır paket üretme süresi)
• Daha net sahiplik ve yetki (hangi varlık kimin, kim imza atabilir)

Bu gereksinimler, ekipleri ülke ülke karmaşaya gömmeden küresel varlık yönetimi için zemin oluşturur.

Kullanıcılar, Roller ve Erişim Modeli

“Herkes her şeyi görebilir” veya onayların birinin gelen kutusunda olması gibi durumlar bir varlık takipçisini en hızlı batıran şeylerdir. Küçük ve net bir rol setiyle başlayın, sonra izinleri (ülke → varlık → belge türü) iş akışına uygun hale getirin.

Başlangıç rolleri

Admin: ülkeleri, varlıkları, belge türlerini, son tarihleri ve entegrasyonları yapılandırır; kullanıcıları ve denetim ayarlarını yönetir.

Katılımcı: günlük işlemleri yapan; belgeleri yükler, meta verileri günceller ve yenileme görevlerine yanıt verir.

Onaylayıcı: uyum/hukuk sahibi; inceleme, onaylama ve güncel sürümü yayımlama yetkisine sahiptir.

Görüntüleyici/Denetçi: liderlik, finans veya denetçiler için salt-okuma erişimi; delil görür ama değiştiremez.

Harici ortak (hukuk bürosu / yerel temsilci): atandığı varlık ve ülke için yükleme veya yorum yapabilir, fakat tam depo içinde gezinememelidir.

Sorumlulukları açık hale getirin (RACI tarzı)

Her belge türü için kimlerin:

• Responsible (Sorumlu): dosyayı yükleyen ve gerekli alanları dolduran
• Accountable (Hesap Verebilir): uyumluluk için kabul eden
• Consulted (Danışılan): yorum yapan veya değişiklik isteyen hukuki/uyum kişiler
• Informed (Bilgilendirilen): yalnızca bildirim alan paydaşlar (yenilemeler, sona erme, yükseltmeler)

Bu, darboğazları azaltır ve yükseltmeleri adil hale getirir.

Hesap yapısı ve izin kapsamları

Çoğu ekip için Organization → Workspace → Entities modeli yeterlidir. Workspaceler iş birimlerine veya bölgelere eşlenir ve veri ayrımını basitleştirir.

Yaygın izin kuralları:

• Ülke bazında erişim kısıtla (ör. AB uyum ekibi)
• Varlık bazında kısıtlama (ör. sadece bağlı kuruluşlar)
• Belge türü bazında kısıtlama (ör. bordroya ilişkin dosyalar)

Varsayılan olarak en az ayrıcalığı kullanın, yöneticilerin denetimler için geçici erişim vermesine izin verin (süresi belli).

Veri Modelini Tasarlayın (Varlıklar, Belgeler, Son Tarihler)

İyi bir veri modeli her şeyi kolaylaştırır: arama, hatırlatmalar, izinler, raporlama ve denetimler. “Belge nedir”, “kime ait”, “nerede geçerli” ve “sonraki adım ne” sorularını ifade edebilen bir model hedefleyin.

Temel tablolar (önerilen)

Çekirdek varlıkları küçük ve bileşenli tutun:

• LegalEntity: id, legal_name, entity_number, incorporation_date, status, parent_entity_id, default_owner_user_id
• Country: code, name
• Jurisdiction/State: id, country_code, name (federal vs. eyalet/prov. kurallarını destekler)
• DocumentType: id, country_code (veya jurisdiction_id), name, requires_expiry (bool), default_renewal_window_days
• Document: id, legal_entity_id, document_type_id, jurisdiction_id (nullable), status, issue_date, expiry_date, renewal_start_date, source (internal/vendor/government), owner_user_id, tags
• Filing/Task: id, legal_entity_id, jurisdiction_id, document_type_id (opsiyonel), due_date, status, assignee_user_id, vendor_contact_id
• Reminder: id, object_type (Document/Task), object_id, send_at, channel, recipients
• Vendor/Contact: id, name, email, phone, jurisdiction_id, notes

Versiyonlama ve geçmiş

Her yüklemeyi ayrı bir DocumentVersion olarak ele alın (document_id, version_number, file_id, uploaded_by, uploaded_at). Eski versiyonları superseded olarak işaretleyin, asla üzerine yazmayın. Bu denetim için uygun bir geçmiş korur.

Küresel karmaşıklığı ele alacak ilişkiler

“Uygulandığı yer”i açıkça modelleyin: bir LegalEntity birçok Jurisdictionda faaliyet gösterebilir ve her ülkenin DocumentType varyantları olabilir (ör. "Certificate of Good Standing" her yerde farklıdır). Kuralları DocumentType içinde (veya ayrı bir Rules tablosunda) saklayın; ülke başına kodlamayın.

Uygulamayı Kullanılamaz Hale Getirmeden Ülke Özel Kuralları

Her ülkeyi tek bir özel durum haline getirdiğinizde küresel uyum çöker. Hile, yerel kuralları yapılandırılmış bir biçimde kodlarken günlük deneyimi tutarlı tutmaktır.

Esnek bir belge taksonomisiyle başlayın

Bir “küresel” belge türleri listesi oluşturun, ardından ülkeye özgü takma adlar ve varyantlara izin verin. Örneğin, kullanıcılar Certificate of Good Standing seçebilmeli ve yetki alanına göre yerel adı veya eşdeğerini görmelidir. Çekirdek kavramı stabil tutun ki raporlama ülke genelinde tutarlı kalsın.

Kontrollü sözlükler kullanın (her ülke için yeni durum icat etmeyin)

Küçük, evrensel bir durum setini kilitleyin ki ekipler panolardaki anlamı anında kavrasın:

• Missing
• Uploaded
• In review
• Approved
• Valid
• Expiring soon
• Expired

Ülke kuralları gereksinimleri, son tarihleri ve meta veriyi değiştirmeli—bu durumların anlamını değil.

Özel mantık yerine ülke şablonları uygulayın

Her ülke için bir “uyumluluk şablonu” modelleyin:

• Varlık türüne göre gerekli belgeler
• Yenileme takvimi (yıllık, iki yıllık, olaya bağlı)
• Zorunlu meta veriler (veren, veriliş tarihi, tescil numarası, noter/onay)

Yeni bir varlık eklendiğinde, şablonu uygulayıp beklenen belge kontrol listesini ve uyumluluk takvimini üretin.

UI'yi bozmadan istisnalara hazırlanın

Gerçek hayat koşullu gereksinimler içerir. Destekleyin:

• Opsiyonel belgeler (önerilen, ancak engelleyici değil)
• Koşullu kurallar (ör. sadece çalışan varsa, KDV kaydı varsa veya belirli lisanslar gerekiyorsa)
• Sektörel ekler (finans, sağlık gibi) ile temel ülke şablonunun üzerine ekstra gereksinimler ekleyin

Böylece sistem öngörülebilir: şablonlar varsayılanı tanımlar, istisnalar ise açık ve izlenebilir ayarlardır.

İş Akışları: Yükleme, İnceleme, Yenileme ve Yükseltmeler

Bir belge takipçisi iş akışı netliğinde başarılı olur veya başarısız olur. İnsanlar "uyumluluğu yönetmek" istemez; bir sonraki adımın ne olduğunu ve neyin yapıldığını bilmek isterler.

Mutlu yol: yükle → incele → onayla → yayımla

Belgeleri az sayıda durum arasında hareket eden nesneler olarak ele alın. Yaygın bir model:

• Uploaded: biri dosya iliştirir ve minimal meta veri girer (varlık, belge türü, dönemi, biliniyorsa bitiş tarihi)
• In review: bir gözden geçirici eksiksizliği ve ülke şablonuna uygunluğu kontrol eder
• Approved: uyum sahibi onay verir
• Published/Current: raporlarda ve denetimlerde kullanılan sürüm olur

Geçiş kurallarını açık yapın: bir belgeyi kim ilerletebilir, kim geri gönderebilir ve her adımda hangi alanların zorunlu olduğu net olsun.

Mutlu olmayan yol: eksik belge → talep → takip

Eksik belgeler görev üretmeli, suçlama yaratmamalıdır. Gerekli belgenin yokluğunda bir istek oluşturun; sahibi, son tarihi ve hafif bir geçmiş ("istedildiği tarih", "taahhüt edilen", "alındığı tarih") olsun. Takipler otomatikleştirilebilir (ör. son tarihten 7 gün önce, son günde, 7 gün sonra).

Yenileme görevleri, hatırlatmalar ve son tarihler

Son tarihleri birincil nesne olarak modelleyin:

• Yenileme pencereleri (örn. "sona ermeden 60 gün önce başla")
• Tekrarlayan bildirimler (aylık/yıllık) ve dönem alanı
• Tek seferlik olaylar (yönetici değişikliği, adres güncellemesi)

Yükseltmeler ve kanıt yönetimi

Görevler geciktiğinde aşamalı yükseltmeler yapın: sahibe bildir → yöneticiye → admin ve zaman eşikleri net olsun. Kanıtları iş akışıyla birlikte tutun: başvuru onaylarını yükleyin, referans numaralarını saklayın ve ilgili e-postaları (ek veya ileti kimlikleri) bağlayın ki denetçi insan kovalamak zorunda kalmasın.

Belge Depolama, Versiyonlama ve Saklama Politikası

Dosyalar ve meta veriyi iki ayrı ürün gibi ele alın. İkili dosyayı object storage'ta saklayın (ör. S3-uyumlu) ve arama/raporlama için gereken her şeyi veritabanında tutun: varlık, ülke, belge türü, veriliş/sona erme tarihleri, durum, versiyon, yükleyen ve bir hash/checksum.

Hızlı kalan bir depolama mimarisi

Object storage büyük dosyalar ve yüksek aktarım için tasarlanmıştır; veritabanınız ise sorgular için. Bu ayrım, ileride tam metin arama gibi özellikleri eklemeyi de kolaylaştırır.

Karmaşayı önleyen dosya kuralları

Yüklemelerin çöplüğe dönüşmesini önlemek için kuralları baştan belirleyin:

• İzin verilen dosya tipleri (öncelikle PDF; gerekirse görüntüler) ve maksimum boyut
• Sunucu tarafı virüs/malware taraması dosya erişime açılmadan önce
• Önizleme oluşturma (küçük resim + PDF sayfa önizlemesi) ile kullanıcıların her şeyi indirmesine gerek kalmaması

Bu kuralları yükleme ekranında görünür yapın ve dostça hatalar döndürün ("Sadece PDF, en fazla 25MB").

Versiyonlama: geçmişi asla kaybetmeyin

Çoğu uyum hatası “en son”un “doğru”nun yerine geçmesinden kaynaklanır. İmmutable versiyonlar kullanın:

• Her yükleme yeni bir versiyon kaydı oluşturur
• Bir versiyon current (güncel) olarak işaretlenir; eskileri superseded olur
• Kimin/ne zaman/neden değiştirdiğini kısa bir "değişiklik notu" ile saklayın

Aşırı paylaşım olmadan güvenli paylaşım

Uygulamanın ötesinde kontrollü paylaşımı destekleyin:

• Süresi sınırlı paylaşılan linkler (dakikalar/günler) ve isteğe bağlı parola
• Önizlemelerde isteğe bağlı filigran ("Gizli — İnceleme için")
• İndirilebilirlik kontrolü (yalnızca görüntüleme vs indirme)

Saklama ve silme politikaları

Saklamayı politikaya göre planlayın, alışkanlığa göre değil. Eski versiyonları arşivleyin, superseded kayıtları aranabilir tutun ve mümkün olduğunda hard delete'ten kaçının. Silme gerekiyorsa “hukuki tutma” uygulayın ve sebebi, onaylayıcıyı ve zaman damgasını kaydedin ki denetimler ve soruşturmalar çıkmaz sokaklarla karşılaşmasın.

Yerelleştirme ve Çokdilli Düşünceler

Ülke belgelerini izlerken "sadece İngilizce" olmak hızla hata kaynağı olur: tarihler yanlış okunur, son tarihler zaman dilimleri arasında kayar ve ekipler yerelde gördükleri adlarla belge bulamaz.

Gösterimi yerelleştirin (sakladığınız şeyi değiştirmeden)

Veritabanında tek kanonik değer tutun, sonra kullanıcıya göre biçimlendirin.

Ülke adları (ve takma adları), tarih formatları ve zaman dilimlerini yerelleştirin. Herhangi bir parasal alan gösteriyorsanız (ücret, ceza, başvuru maliyeti) biçimlendirmeyi tutarlı yapın—para birimi dönüşümü yapmasanız bile.

Son tarihler için doğruluk sağlayın: zaman damgalarını UTC'de saklayın ve her zaman ilgili zaman diliminde gösterin (çoğunlukla varlığın kayıtlı olduğu yetki alanı, bazen kullanıcının tercihi). Tablo ve takvimlerde zaman dilimi etiketi gösterin ki “yarın son günüydü” kafa karışıklığı olmasın.

Çokdilli belgeleri destekleyin

Birçok belge yerel dilde düzenlenir; merkez İngilizce bağlam ister.

Belgeyi orijinal dilinde saklayın, ancak "Çevrilmiş başlık" ve "Çevrilmiş notlar" gibi çevrilmiş meta alanlar ekleyin. Bu, ekiplerin içeriği değiştirmeden arayıp anlamasını sağlar. OCR veya tam metin arama eklerseniz, algılanan dili etiketleyin ki arama doğru davransın.

Erişilebilirlik yerelleştirmenin parçasıdır

UI'yi herkes için okunabilir ve gezinilebilir yapın: net etiketler (mümkün olduğunca hukuk terimlerinden kaçının), yükleme/inceleme akışları için klavye gezinimi ve yüksek kontrastlı, öngörülebilir sütun sıralı tablolar. Bunu "iyi olur" değil temel gereksinim olarak ele alın.

Güvenlik, Gizlilik ve Denetim İzleri Tasarımı

Güvenlik bir uyumluluk uygulaması için "sonrası" özellik değildir—kullanıcılar pasaport, sertifika, kurul toplantı tutanakları ve diğer hassas dosyaları yükleyecek. Sistemi her belgenin denetimde istenebileceği ve her hesabın hedef alınabileceği varsayımıyla tasarlayın.

En az ayrıcalık (şirketlerin çalışma biçimine uygun RBAC)

Rollerle başlayın ve kapsamı doğru belirleyin: izinler genellikle varlık ve çoğu zaman ülke bazında atanmalı. Bölgesel finans sorumlusu yalnızca AB varlıklarını görebilir; dış hukuk bürosu sadece bir bağlı kuruluş için belge yükleyebilir ama İK ile ilgili dosyaları göremez.

Rolleri basit tutun (Admin, Onaylayıcı, Katılımcı, Görüntüleyici/Denetçi) ve bunları eylemlere (görünteleme, yükleme, indirme, meta düzenleme, onaylama, silme) eşleyin. Varsayılan “erişim yok” olsun ve erişim vermeyi açık hale getirin.

Her yerde şifreleme ve anahtar koruma

Tüm trafik için HTTPS/TLS kullanın. Dosyaları ve hassas meta veriyi dinamik ve durağan olarak şifreleyin (veritabanı + object storage). Uzun ömürlü kimlik bilgilerini kod veya konfigürasyonda tutmayın; veritabanı parolaları, API anahtarları ve imza anahtarları için secrets manager kullanın.

İmzalanmış indirme linkleri üretiyorsanız anahtarları döndürün ve link süresini sınırlayın. Anormal indirme artışlarını loglayın ve uyarı verin.

Gerçek denetim sorularını cevaplayan loglar

Denetim izi oynanamaz ve aranabilir olmalı. En azından kim görüntüledi, yükledi, indirdi, durumu değiştirdi veya meta düzenledi bilgilerini zaman damgası, varlık, ülke, belge türü ve önce/sonra değerleriyle loglayın.

Denetim günlüklerini uygulama verisinden ayrı tutun (farklı tablo veya farklı depolama) ve erişimi kısıtlayın; saklama kurallarını belirleyin.

Gizlilik ve uyumluluk beklentileri

Veri yerinde kalma gereksinimlerini erken planlayın (bazı ülkeler belgelerin bölge içinde kalmasını isteyebilir). Yedekleme/geri yükleme hedeflerini (RPO/RTO) tanımlayın, geri yüklemeleri test edin ve temel bir olay müdahale kontrol listesi yazın: oturumları iptal etme, anahtarları döndürme, yöneticileri bilgilendirme ve kanıt koruma adımları.

Entegrasyonlar ve Veri Geçiş Yolları

Entegrasyonlar uygulamanızın “güvenilen yer” olup olmayacağını belirler. Bunları erken planlayın ki göç uzun bir temizlik projesine dönüşmesin.

Zaten sahip olduklarınızı içe aktarma

Çoğu ekip dağınık kaynaklarla başlar: tablolar, paylaşılan sürücüler, e-posta gelen kutuları ve eski sistemler. Geçişi tekrarlanabilir bir boru hattı olarak ele alın, tek seferlik bir yükleme gibi değil.

Pratik yaklaşım:

• Varlıklar, belge türleri ve ana tarihler için CSV/XLSX içe aktarımı ile başlayın.
• Paylaşılan sürücü dışa aktarımları için toplu dosya alma (zip veya klasör sürükle-bırak) ve dosyaları varlıklara eşleme seçeneği ekleyin.
• E-posta gelen kutuları için workspace başına tekil yönlendirme adresi; ekleri “Unassigned” kuyruğuna yönlendirin.

Oluşturulan/atlanan/dikkat gerektirenleri gösteren bir içe aktarma günlüğü tutun—aksi halde kullanıcılar sonuçlara güvenmez.

Kimlik ve kullanıcı sağlama

Müşterileriniz zaten SSO kullanıyorsa SAML veya OIDC entegrasyonu yapın ki erişim kurumsal politikalarla tutarlı olsun. Büyük örgütler bekliyorsanız SCIM ile joiner/mover/leaver otomasyonu ekleyin (yönetici isteklerini azaltır). IdP gruplarını uygulama rolleriyle haritalandırın.

İnsanların gerçekten gördüğü bildirimler

Uyum işi zaten kullanılan araçlarda olur. E-posta, Slack/Teams ve takvim hatırlatmaları (ICS) ile kilit son tarihler için bildirim gönderin. Mesajları kısa tutun ve ilgili varlık/belge sayfasına doğrudan bir bağlantı ekleyin (örneğin: /entities/123/documents/456).