Onaylar, bütçe kontrolleri, satınalma siparişleri ve tedarikçi iletişimi için roller ve statülerle iç satınalma talepleri tasarlamak için bu şablonu kullanın.
E-posta zincirleri ve elektronik tablolar aynı tahmin edilebilir şekillerde başarısız olur. Talepler gömülür. Dosyalar "final_v7" gibi parçalanır. Onaylar kaydı olmadan yan sohbetlerde verilir. Birisi "Bunu almaya onayımız var mı?" diye sorduğunda cevap, kimin çevrimiçi olduğuna ve hangi tabloya güvendiklerine bağlıdır.
Bir talep uygulaması, statüyü her an görünür kılmalıdır. Bir talebi açtığınızda hemen kimin gönderdiğini, ne satın almak istendiğini, beklenen maliyeti ve bundan sonra ne olacağını görmelisiniz. Ayrıca temiz bir geçmişe ihtiyaç vardır: kim onayladı veya reddetti, bunu ne zaman yaptı ve sonrasında ne değişti.
En azından her talep şu soruları kazmadan yanıtlamalıdır:
Kapsam, birçok ekibin aşırıya kaçtığı yerdir. Erken karar verin: yalnızca talepten satınalma siparişine kadar mı kapsıyorsunuz, yoksa fatura mutabakatı ve mal kabul gibi sonraki adımları da mı? Talep→PO genellikle ilk kilometre taşı için en iyi tercihtir: temiz onayları ve bütçe kontrollerini zorunlu kılar, ancak projeyi sınırlı tutar.
İlk sürümü basit tutun. Bir ekip, tek bir onay yolu ve "tamam" tanımıyla başlayın. Örneğin, 1.000 USD altındaki IT talepleri sadece yönetici onayı gerektirebilirken, daha büyük satın almalar finansa gider.
Kod yazmadan hızlıca inşa etmek istiyorsanız, AppMaster pratik bir seçenektir. Talep verisini modelleyebilir, onay adımları kurabilir ve aynı taslaktan üretime hazır web ve mobil uygulama oluşturabilirsiniz.
Bir satınalma talep uygulaması izinlere bağlı olarak yaşar veya ölür. Yanlış kişinin bir talebi onaydan sonra değiştirebilmesi ya da ekiplerin ihtiyaç duyduklarını görememesi süreci yavaş ve riskli hale getirir.
Önce net roller belirleyin. Unvanlar şirkete göre değişir, ama çoğu uygulama şu kalıcı sorumluluklara ihtiyaç duyar: talepçiler (talep oluşturur ve soruları yanıtlar), yöneticiler (ihtiyacı ve zamanlamayı doğrular), satınalma (tedarikçiyi doğrular ve PO oluşturur), finans (bütçeyi ve politikayı onaylar) ve bir veya daha fazla onaycı (onay yetkisi). Bazı iş akışlarında paylaşılan, dışa dönük bilgiler için sınırlı erişimli tedarikçi kontakları da yer alır.
Ardından her rolün her aşamada ne yapabileceğini tanımlayın. Tek bir kural birçok anlaşmazlığı önler: talep gönderildikten sonra, talepçi sadece açıklama amaçlı alanları (notlar, ekler, teslimat detayları) düzenleyebilsin. Fiyat, tedarikçi, miktar, para birimi ve maliyet merkezi gibi alanlar resmi bir değişiklik ve yeniden onay gerektiren sert alanlar olmalıdır.
Görünürlük kuralları da en az izinler kadar net olmalıdır. Talepçiler kendi taleplerini ve statülerini görmelidir. Yöneticiler, doğrudan raporlarının taleplerini görmelidir. Satınalma ve finans genellikle bölüm ötesi görünürlüğe ihtiyaç duyar. Tedarikçi kontakları iç notları, bütçe verisini veya diğer tedarikçileri asla görmemelidir.
Vekâlet önemlidir çünkü biri yokken onaylar durmamalıdır. Planlı vekâlet (tatil) ve acil yedek (hastalık) destekleyin. Vekâlet onay haklarını devretmeli, ancak talebi yeniden yazma yetkisi vermemelidir.
Bölümler arası talepler yaygındır (ör. IT, Marketing için yazılım alıyor). "Talep eden ekip" ile "maliyet merkezi sahibi"yi ayırın. Onayları maliyet merkezi sahibine yönlendirin ve hem talep edeni hem ödeyeni kayıtta gösterin, böylece kimin talep ettiği ve kimin ödediği açık olur.
AppMaster'da roller, kayıt sahipliği ve aşama bazlı eylemleri Veri Modeli ve İş Süreçlerinde modelleyebilirsiniz, böylece aynı kurallar web ve mobil ekranlarda tutarlı uygulanır.
İyi bir satınalma talep uygulaması temiz bir veri modeliyle başlar. Tablolarınız netse, onaylar, bütçe kontrolleri ve satınalma siparişleri otomatikleştirmek ve raporlamak daha kolay olur.
Çoğu ekip, küçük bir varlık setiyle vakaların çoğunu kapsar:
Requests için yönlendirmeye yardımcı ve geri dönüşleri azaltan alanlar ekleyin: talep eden, departman, maliyet merkezi, ihtiyaç tarihi, iş gerekçesi ve ekler (teklifler, teknik şartlar, ekran görüntüleri). Basit bir tercih edilen tedarikçi referansı işe yarar, tedarikçi seçimi daha sonra netleşse bile.
Statüler açık olduğunda en iyi şekilde çalışır ve zaman damgalarıyla desteklenmelidir. Requests üzerinde tek bir statü alanı tutun (Draft, Submitted, Approved, Rejected, Ordered, Closed) ve submitted_at, approved_at, rejected_at, ordered_at ve closed_at gibi ana tarihleri saklayın. Bu, raporlamayı (döngü süresi, yaşlanma, darboğazlar) günlük kayıtlardan tahmin etmeden basit hale getirir.
PurchaseOrders için PO başlığını (numara, tedarikçi, gönderim adresi, fatura adresi, ödeme koşulları) ve PO satırlarını ayrı tutun ve orijinal talep ve satırlara bağlayın. Fiyatlar değiştiğinde bu izlenebilirlik önem kazanır.
Onaylar denetim izinizdir, ama genellikle sadece "onaylandı/reddedildi"den fazlasına ihtiyaç vardır. Kim harekete geçtiğini, ne zaman yaptığını, ne karar verdiğini ve nedenini saklayın.
Hafif bir yöntem olarak Activity/Audit tablosu tutabilirsiniz: actor_user_id, entity_type, entity_id, action, old_value, new_value ve created_at gibi alanlar. AppMaster'da bu Veri Tasarımında kolayca eşlenir ve İş Süreçlerinden otomatik doldurulabilir, böylece her değişiklik izlenebilir.
Bir satınalma talep uygulaması, herkes aynı tedarikçi verilerini kullandığında işler. Tedarikçi tablonuzu tek gerçek kaynağınız olarak görün; insanların her talepte yeniden yazdığı bir şey olmasın. Tedarikçi detayları tek yerde olunca onaylar hızlanır ve finans daha az sürpriz görür.
Başlangıç için tedarikçi kaydı şu temel bilgileri tutmalı: yasal ad, görüntüleme adı, vergi kimliği (kullanıyorsanız), varsayılan para birimi, fatura adresi ve ödeme koşulları. Ana muhasebe e-posta adresini saklayın ve teklif için ayrı, fatura için ayrı olmak üzere birden fazla kontak bulundurun.
Tedarikçi engellemelerini tutarlı hale getirecek bir tedarikçi statüsü ekleyin: Active (seçilebilir), Pending review (izinli ama ekstra doğrulamaya yönlendirilir) ve Blocked (inceleme olmadan kullanılamaz).
İletişim takibi "son kim e-posta attı?" problemini önler. Vendor ve mümkünse belirli bir Request, Quote veya Purchase Order ile bağlı VendorInteraction (veya Communication) varlığı oluşturun. Her kayıt kanal (e-posta, arama, toplantı), yön (giden/gelen), zaman damgası, sahip ve kısa bir özet yakalamalıdır. Teklif topluyorsanız bunları yapılandırılmış kayıtlar (tutar, para birimi, geçerlilik tarihi) olarak saklayın ve gerekirse dosya ekleyin.
Tedarikçi verilerini temiz tutmak için birkaç kural işleri yavaşlatmadan düzenli tutar:
AppMaster'da Vendor, VendorContact ve VendorCommunication'ı Veri Tasarımında modelleyebilir ve talep ile PO ekranlarında tam geçmişi bir tıkla gösteren bir zaman çizelgesi sunabilirsiniz.
Bütçe kontrolü basit bir soruyu yanıtlar: şu an bu talep için yeterli onaylı paramız var mı? Erken karar verin: şirketiniz bütçeyi sert bir durdurma olarak mı ele alır (ilerleyemez) yoksa uyarı mı verir (devam edebilir ama ekstra onay gerekir)? Bu tek seçim talep edenler ve onaycılar için tüm deneyimi değiştirir.
Bütçe farklı kaynaklardan gelebilir, bu yüzden kaynağı açıkça belirtin. Yaygın seçenekler yıllık departman bütçesi, proje bütçesi veya maliyet merkezi için aylık üst sınırdır. Bir talep kaynaklar arasında bölünebiliyorsa, kaynak başına bölünmüş tutarları yakalayın ki raporlama temiz kalsın.
Sürprizleri önlemek için beklenen harcamayı finansın daha sonra hesapladığı aynı şekilde hesaplayın. Bir talep uygulaması ancak herkes onaylamadan önce aynı sayıyı görüyorsa işe yarar.
Çoğu ekip tarafından kullanılan basit hesap kontrol listesi: satır toplamı (miktar x birim fiyat), indirimler, vergi, nakliye ve elden teslim ücretleri ile döviz dönüşümü (kuru ve tarihini saklayın). Sonra beklenen harcama kullanılabilir bütçe ile karşılaştırılır (bütçe eksi halihazırda taahhüt edilen tutarlar). Taahhütleri izliyorsanız, bekleyen talepleri ve açık PO'ları da dahil edin, sadece ödenmiş faturalar değil.
Bütçe eksik olduğunda talep sahibini tahmin etmeye zorlamayın. Bir yol seçin ve iş akışına kodlayın: bütçe sahibine yönlendir (bir kaynak ataması için), bir seferlik finans onayıyla geçişe izin ver, talebi "bütçe detayları" görevine geri gönderin veya her zaman bütçe gerektiren kategorileri otomatik reddet.
Örnek: bir ekip yeni bir laptop paketi talep ediyor. Uygulama kalem bedeli artı vergiyi hesaplar, departman para birimine çevirir ve bir 1.150 USD talep karşısında yalnızca 900 USD kaldığını tespit eder. Eğer bunu bir uyarı sayıyorsanız, yine de yöneticiye gidebilir ama finans onayı zorunlu hale gelir.
AppMaster'da bütçe kaynaklarını Veri Tasarımında modelleyebilir ve ilk onay kararı öncesinde iş süreci adımı olarak kontrolü çalıştırabilirsiniz.
Onaylar bir talep uygulamasının ya zaman kazandırdığı ya da yavaş bir gelen kutusu rölesine dönüştüğü yerdir. Varsayılan yolu basit tutun, sonra yalnızca gerçek riski önleyen kuralları ekleyin.
Her onayın neyi koruduğunu tanımlayarak başlayın. Yaygın bir set: yönetici onayı (ihtiyaç ve öncelik), finans onayı (bütçe ve muhasebe), satınalma onayı (tedarikçi ve satın alma yöntemi). Belirli kategoriler veya tedarikçiler gerektiğinde güvenlik ve hukuk ekleyin.
Yönlendirme kuralları öngörülebilir olmalıdır. İnsanlar Submit'e basmadan önce ne olacağını tahmin edebilmelidir. Tipik yönlendirme faktörleri tutar eşikleri, kategoriye göre yönlendirme (yazılım güvenliğe, sözleşmeler hukuka), tedarikçi risk seviyesi, departman veya maliyet merkezi kuralları ve satın alma türüdür (CapEx vs OpEx, abonelik vs tek seferlik).
Sıralı onayları sıra önemli olduğunda kullanın. Örneğin, finans bir talebi maliyet merkezi olmadan engelleyebilir, bu yüzden satınalma zaman harcamadan önce bunu yakalamak daha iyidir. Ekipler bağımsız olarak inceleyebiliyorsa paralel onay kullanın; örneğin güvenlik ve hukuk, finans bütçe kontrolüyle eşzamanlı inceleyebilir.
Temiz bir yeniden çalışma döngüsü planlayın. Bir onaycı talebi geri gönderdiğinde, talep sahibi eksik detayları ekleyip kaydı kaybetmeden tekrar gönderebilmelidir. Tüm onayların zaman damgası, yorumları ve miktar, tedarikçi, kategori gibi ana alanların versiyonunu içeren bir onay günlüğü tutun.
Örnek: 12.000 USD'lik bir SaaS aracı önce yönetici ve finans onayına gider. Her iki onaydan sonra güvenlik ve satınalma paralel çalışır. Güvenlik veri işleme detayları eksik dediğinde talep talep sahibine geri döner, sonra aynı adıma geri gelerek denetim izini korur.
AppMaster'da iş akışı durumlarını ve geçişlerini Bir İş Süreci olarak modelleyin, böylece yönlendirme görünür kalsın ve politika geliştikçe kolayca ayarlanabilsin.
İyi bir akış taleplerin kaybolmasını engellerken detayların sapmadan ilerlemesini sağlar. Erken yeterli bilgiyi yakalayın, sonra incelemeler başladığında önemli alanları dondurun.
Çoğu ekip için pratik sıra şöyledir:
Örnek: destek ekibi 10 yeni kulaklık talep eder. Teklifi ekler, IT Supplies kategorisini seçer ve gönderir. Uygulama IT bütçesini kontrol eder, ekip liderine (1.000 USD altı) ve sonra finansa (500 USD üzeri için) yönlendirir. Onaydan sonra PO oluşturulur ve gönderilir, alıcı onayı ve teslimat tarihi kaydedilir.
AppMaster gibi kod yazmadan araçlarda bu genellikle birkaç ekran (Draft, Review, PO) ve alanları kilitleyen, bütçe mantığını çalıştıran ve PO kaydını otomatik oluşturan bir İş Süreci olur.
Bir satınalma siparişi (PO) ancak tutarlı, izlenebilir ve yanlışlıkla değiştirilemeyecek kadar sabit olduğunda işe yarar. İş akışınızda PO güvenilir bir kayıt halini almalıdır ki tedarikçi ve finans buna güvenebilsin.
PO numarasını, PO tedarikçiye resmi olarak iletildiğinde üretin; birinin taslak oluşturmaya başladığında değil. Taslaklar silinir, yeniden başlatılır ve birleştirilir; bu boşluklara ve tekrar eden numaralara yol açar.
Tekrarlardan kaçınmak için bir sonraki PO numarasını tek bir kontrollü yerde saklayın ve atomik bir adımla atayın (başarılı olmalı veya tamamen başarısız olmalı). İnsan dostu bir numara isterseniz yıl veya tüzel kişi ön eki ekleyin, ama benzersiz sayaç asla tekrar etmeyecek kısım olsun.
PO'yu başlık ve satır öğelerine ayırın. Başlık bağlamı tutar; satırlar ne alındığını.
Başı odaklı tutun: tedarikçi ve kontak, gönderim ve fatura adresi, para birimi, ödeme koşulları, beklenen teslim tarihi, durum (Draft, Issued, Acknowledged, Closed) ve teklif referansı.
Satır öğeleri fatura karşılaştırması için yeterince katı olmalı: açıklama, miktar, birim, birim fiyat, vergi, indirim ve maliyet merkezi veya bütçe kodu. Toplamlar manuel değil, hesaplanmış olmalı.
Revizyonun ne zaman izinli olacağını baştan kararlaştırın. Teslimat tarihi veya notlar gibi küçük değişiklikler revize versiyon (ör. PO-1042 v2) olarak yapılabilir ve "v1'i geçersiz kılar" bağlantısı açık olur. Tedarikçi, para birimi veya toplamda maddi değişiklikler genellikle "iptal et ve yeniden çıkar" gerektirir ki kimse yanlış belgeye göre sevkiyat yapmasın.
Örnek: talep 10 dizüstü için onaylandı ama tedarikçi teklifinde teslim süresi 2 haftadan 8 haftaya değişti. Güncellenmiş teslim tarihli bir revizyon oluşturun ve orijinal teklif detaylarını ekleyin, böylece PO her zaman üzerinde anlaşılanla eşleşir.
AppMaster'da PO başlığı, satır öğeleri ve PO versiyonlarını ayrı varlıklar olarak modelleyin ki revizyonlar temiz ve izlenebilir kalsın.
Bildirimler, iç satınalma iş akışının pürüzsüz mü yoksa zincir-avına dönüşüp dönüşmediğini belirler. Mesajları sürecin bir parçası gibi ele alın ve bunları statü değişikliğine veya net bir sonraki adıma bağlayın.
İç güncellemeler için küçük bir setle başlayın ki insanlar bunları görmezden gelmesin: onaylandı/reddedildi, bütçe kontrolü başarısız ya da açıklama gerekiyor, PO oluşturuldu ve gönderilmeye hazır, onay gecikti veya teslimat gecikti, PO değiştirildi veya iptal edildi.
Her bildirim 10 saniyede okunabilir olmalı. Talep başlığı, toplam tutar, mevcut durum ve alıcının bir sonraki ne yapması gerektiğini açıkça veren tutarlı bir şablon kullanın. Onaycılara harcama nedeni ve en önemli satır kalemlerini kısaçe ekleyin.
Tedarikçi iletişimi de yapılandırılmalı. Tedarikçilerin çoğu PO gönderimi, PO değişikliği, iptal ve teslimat soruları ister. Her giden ve gelen mesajı o PO veya talep için tedarikçi dizisinde saklayın. Sonuçları şu basit alanlarla takip edin: durum (taslak, gönderildi, teslim edildi, başarısız), vendor_response (yok, cevaplandı, geri döndü), follow_up_needed (evet/hayır) ve takip tarihi.
Örnek: bir dizüstü talebi onaylandı, PO gönderildi ve tedarikçi modelin stokta olmadığını yanıtladı. Uygulama yanıtı kaydeder, follow_up_needed'i evet yapar ve talep sahibini alternatif seçimi için bilgilendirir. AppMaster'da durum değişikliklerini e-posta/SMS/Telegram adımlarına bağlayabilir ve mesaj sonucunu PO ile birlikte saklayabilirsiniz.
En büyük risk eksik özellik değil. Yanlış kuralları kurmak ve şirketin bunların etrafında çalışmayı öğrenmesidir.
Yaygın bir başarısızlık talebi bir statü labirentine dönüştürmektir. Eğer insanlar "Pending validation" ile "Under review" arasındaki farkı anlayamıyorsa, güncellemeyi bırakır ve veriniz gürültü olur. Statüleri net eylemler ve sahiplerle bağlayın. Her statü bir soruyu cevaplamalı: "Sırada ne var ve bunu kim yapacak?"
Bir diğer tuzak sahibinin veya son tarihin olmayan onaylardır. Onaycı izindeyken talepler takılır. Gruplara atanan onaylar için yedekleme ekleyin ve basit bir zaman beklentisi koyun, resmi olmasa bile.
Bu hatalar en çok yeniden çalışmaya yol açar:
Onay sonrası düzenlemeler özel dikkat gerektirir çünkü küçük "zararsız" değişiklikler riski değiştirir. Birisi 900 USD'lik 10 dizüstü için onay aldıysa sonra daha pahalı modele veya miktar artışına giderse, onaylananla satın alınan uyuşmayabilir.
Ayrıca bütçe doğrulamayı tek bir evet/hayır alanı olarak ele almayın. Finans genellikle harcamanın nasıl raporlandığıyla ilgilenir: departman, proje, GL hesabı ve zaman penceresi. Uygulamanız aylık kontroller yapıyorsa ama finans çeyreklik raporluyorsa, "kullanılabilir bütçe" hep yanlış görünecektir.
AppMaster'da onay sonrası ana alanları kilitleyin ve her istisnayı bir olay olarak kaydedin (kim, ne zaman, neyi değiştirdi ve neden). Böyle bir denetim izi anlaşmazlık ve denetimlerde sizi kurtarır.
Lansmandan önce temel kuralları yazın. Çoğu "onay kaosu" küçük bir kural veya zorunlu alanın eksikliğinden kaynaklanır.
Basit bir lansman kontrol listesi:
Bu kuralların varlığından sonra, bir talep ilerlemeden önce çalışan hızlı doğrulamalar ekleyin: tedarikçi seçimi (veya yeni-tedarikçi yolu), doğru dönem için bütçe kapsama, fiyat kanıtı, eksiksiz gönderim/fatura detayları ve gerçek bir iş gerekçesi.
Örnek senaryo: bir ekip lideri yeni başlayan için laptop talep eder. Tercih edilen tedarikçiyi seçer, teklifi ekler ve doğru maliyet merkezini etiketler. Yönetici işe alım planıyla uyduğu için onay verir. Finans bütçe kontrolü geçince onay verir. Satınalma PO'yu oluşturur, tedarikçiye gönderir ve tedarikçinin onayı ile beklenen teslim tarihini aynı kayıtta kaydeder; böylece talep sahibi ekstra e-posta olmadan ilerlemeyi takip edebilir.
Sonraki adımlar: veri modelinizi ve iş akışı kurallarınızı prototipleyin, sonra küçük bir pilot ekip ve bir-iki satın alma kategorisiyle test edin. AppMaster'da tabloları Data Designer'da oluşturup yönlendirme mantığını Business Process Editor'da haritalandırabilirsiniz. Kısa bir pilot çalıştırın, taleplerin takıldığı yerleri inceleyin, zorunlu alanları sıkılaştırın ve sonra daha geniş çapta yayınlayın. Bu yaklaşımın gerçek bir uygulama yapısına nasıl dönüştüğünü görmek isterseniz, AppMaster (appmaster.io) onay mantığı, API'ler ve hem web hem native mobil arayüzleri aynı modelden oluşturmak için tasarlanmıştır.
Procurement talep uygulaması için ilk kilometre taşı ne olmalı?Start with request to PO. It forces clear approvals, budget checks, and traceability without dragging you into invoice matching and receiving right away. You can add downstream steps after the team trusts the first milestone.
İnsanların kafasının karışmaması için hangi talep statülerini kullanmalıyız?Use a small, explicit set like Draft, Submitted, Approved, Rejected, Ordered, and Closed. Each status should clearly indicate who owns the next step and what action is expected, so nobody has to interpret vague labels.
Onay sonrası insanların fiyatı veya tedarikçiyi değiştirmesini nasıl engelleriz?Lock key fields at submission and require a formal change that triggers re-approval for anything that affects risk or spend, such as vendor, currency, quantity, unit price, cost center, or total. Allow only clarifications like notes, attachments, or delivery details without restarting the whole process.
Bir satınalma talep iş akışında hangi roller ve izinler vazgeçilmez?Define roles first, then define what each role can do at each stage. A simple default is: requesters see and edit their own drafts, managers see direct reports, and finance/procurement have cross-department visibility, while vendor contacts never see internal notes or budget data.
Biri tatildeyken onay delege etme nasıl çalışmalı?Make delegation a built-in feature, not an exception. Delegation should transfer approval rights for a time window, but it should not allow the delegate to rewrite the request content, so accountability stays intact.
IT'nin Marketing için satın alma yapması gibi departmanlar arası talepleri nasıl ele almalıyız?Separate who requested the purchase from who pays for it. Route approvals to the cost center owner even if the requester is from another team, and store both parties on the record so it’s always clear who initiated and who is accountable for budget.
Finansın güveneceği şekilde bütçe kontrollerini en basit nasıl uygularız?Calculate expected spend the same way finance will later, including tax, shipping, discounts, and currency conversion with a stored rate and date. Decide upfront whether insufficient budget blocks the workflow or allows escalation with an extra approval step.
Tedarikçi verilerini temiz tutup riskli satın almalardan nasıl kaçınırız?Keep a vendor master table as the single source of truth, and select vendors from a list rather than free text. Add a vendor status like Active, Pending review, and Blocked so risky vendors are consistently routed or prevented without relying on memory.
PO numarasını ne zaman oluşturmalıyız ve tekrarları nasıl önleriz?Generate the PO number only when the PO is officially issued, not when someone starts drafting. Assign it in a single controlled step to avoid duplicates, and keep the PO header and line items structured so totals are calculated rather than manually typed.
Bunu kod yazmadan kurabilir miyiz ve AppMaster neyle yardımcı olur?Yes, if you need a fast build without writing code. With AppMaster, you can model the data, define stage-based permissions and approval routing, and generate production-ready web and native mobile apps from the same model, which helps keep the workflow consistent across devices.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
