Entegrasyon Süreci: Sözleşme Süreci → API/Teknik Dokümanlar → Test Cihazı Alımı → Testler → Geliştirme Süreci → Ar-Ge Pilot Onayı → Pilot Süreci → Canlı Kullanım
buradaki en kritik nokta; herhangi bir yazılımsal sandbox (sanal test ortamı) sunulmuyor olması. entegrasyon kodunu yazıp test edebilmeniz için donanım maliyetini tamamen üstlenerek fiziki bir test cihazı satın almanız zorunlu tutuluyor.
bu süreç pratikte ne anlama geliyor?
sıfır sandbox / yüksek giriş maliyeti: dünya genelinde Stripe Terminal, Adyen, Square gibi yapılar veya avrupa'daki mali kayıt sistemleri (Fiskaly, EFSTA vb.) geliştiriciye ücretsiz sandbox ve SDK sunarken, bizde geliştirmeye başlamadan önce cebinizden donanım parası çıkarmanız gerekiyor.
bürokratik yük: dokümana ulaşmak için bile sözleşme, onay ve pilot süreçleri gibi uzun bürokratik aşamalardan geçmek şart.
geliştirici dostu olmayan yaklaşım: bağımsız bir yazılımcı olarak hazır, yayınlanmaya uygun bir masaüstü POS/kasiyer yazılımı üretseniz dahi kapalı protokoller ve zorunlu donanım satışı nedeniyle adeta ekosistemin dışına itiliyorsunuz. çözüm olarak hangi yola yöneldim? bu yaklaşım ve şartlar karşısında ÖKC entegrasyonu adımından tamamen vazgeçtim. yazılımı mevzuata uygun tutarak sunmanın çok daha basit bir yolunu tercih ediyorum; e-fatura + sanal POS. bu ÖKC meselesi basit bir tercih veya entegre edilmiş bir teknolojik özellik meselesi değil. ne yazık ki geliştirici için bazı alanlarda bir zorunluluk artık. bir berbere "müşteri takibi" veya "randevu sistemi" diye yazılım satabilirsiniz ama bu yazılım oradaki mali süreci devlete bildirmek zorunda veya bir restoran için qr menü adisyon sistemi kurabilirsiniz; bu yazılımda mali süreci devlete bildirmek zorunda. eğer bu mali bildiriyi direkt donanım (ÖKC) üzerinden yapacak olursanız böyle bir sürece tabi oluyorsunuz. ancak e-fatura da aynı işlevi yerine getiriyor. başta e-faturayı tercih etmeme nedenim, programımın internete gereksinimi olmadan çalışabilmesini bir pazarlama unsuru olarak kullanmaktı. öyle işte, bakalım ne zaman iş hayatına tekrardan atılmayı başarabileceğim.
GÜNCELLEME:
https://ynokc.gib.gov.tr/UploadedFil..._ynokc2025.pdf
1. Yol: %100 İnternet / B2B veya Banka Havalesiyle Satış (ÖKC’siz Süreç)
Eğer yazılımınız üzerinden yapılan satışlarda fiziki mağazada/kasada müşteriyle yüz yüze gelme durumu yoksa (örn: e-ticaret, B2B sipariş portalı, sadece banka havalesi veya sanal POS ile ödeme alma):
- ÖKC kullanma zorunluluğunuz yoktur.
- Müşteriye doğrudan e-Fatura / e-Arşiv Fatura kesip e-posta ile göndermeniz yasal olarak yeterlidir.
2. Yol: Fiziki Mağazada Perakende Satış + e-Fatura / e-Arşiv Düzenleme (ÖKC Zorunlu)
Eğer yazılım fiziki bir mağazada/kasada çalışacaksa ve müşteri tezgah başında dururken satış yapılıyorsa:
- Müşteriye e-Fatura veya e-Arşiv Fatura kesseniz dahi, ödemeyi alırken fiziki ÖKC (Yazar Kasa POS) kullanmak veya yazılımı ÖKC ile entegre etmek zorunludur.
- Yani yazılımdan faturayı tetikleseniz de arkada ödemenin/belgenin ÖKC'den geçmesi gerekir.
3. Yol: YN ÖKC Entegrasyonu (ÖKC + e-Fatura Birlikteliği)
Yazılımınızı ÖKC'den tamamen bağımsız kılmak yerine, ÖKC entegrasyonlu (EFT-POS özellikli YN ÖKC) hale getirebilirsiniz.
- Yazılımınız satış detayını ve tutarı ÖKC cihazına aktarır.
- ÖKC ödemeyi alır, mali fişini veya e-Fatura/e-Arşiv bilgi fişini basar.
- Böylece hem yazılımınız e-Fatura uyumlu kalır hem de fiziki perakende satış mevzuatını ihlal etmemiş olursunuz.
3 maddelik bu örnek açıklamayı gemini'ye hazırlattım.
@sefac; ve @Biu; 'a benim kalın kafamın almadığı bu durumu ısrarla izah ettikleri için ayrıca teşekkürler.
