[ÇÖZÜLDÜ] En Kolay E-Fatura entegratörü hangisi?

[RAD Coder]

(21-05-2024, Saat: 23:25)rmzgenius Adlı Kullanıcıdan Alıntı: Arkadaşlar, son durum ile ilgili özet bir bilgi vereyim istedim. Sorduğum her 10 kişiden 9'unun ÇOK KOLAY entegre olacağımı söylediği Hızlı Bilişim'in E-Fatura entegrasyonu ile hiçbir mesafe kat edemedik. İnanılmaz zorlaştırmışlar, Önce bir başvuru formu ile başvurup secret key ve Api Key alıyorsunuz. Secret key ile onların verdiği bir link üzerinden request göndererek dönen şifrelenmiş kullanıcı adı ve  şifrelerini elde ediyorsunuz. Sonra o şifreli kullanıcı adı ve parola ile Login olup, login olduktan sonra response'da dönen Token değerini saklıyorsunuz, ki sonraki tüm işlemlerde (Fatura gönderme, çekme, VKN sorgulama vb. ) bu token değerini de request'e ekliyorsunuz. JWT (Json Web Token) deniyormuş buna.

Sözün özü, Hızlı Bilişim maceramız daha  başlamadan sona erdi.

SOVOS (EDM'yi de bunlar satın almışlar)  isimli bir firma ile görüştüm, sadece WSDL web servisleri var. REST servisi yok. İki tarih arasında fatura sorgulama imkanı sunmuyorlar. Çözüm önerileri şöyle, her gün programım tüm gelen faturaları indirip kendi veritabanında saklayacakmış ve faturaları oradan gösterecekmişim. Gösterilen fatura indirilmek istenirse GUID değerinden faturayı sorgulayacakmışım

Şimdilik 2 tane firma ile görüşebildim. Ama şu anda .Net projemizde servislerini kullanmış olduğumuz Uyumsoft'un aslında ne kadar kolay ve basit imkanlar sunduğunu da anlamış oldum. Uyumsoft, hem SOAP hem de REST servisleri sunuyor ve Hızlı Bilişim gibi teferruat da istemiyor. Sanırım Delphi projemde de yine Uyumsoft ile devam edeceğim.

Bu süreçte konuya cevap veren herkese, özellikle de hem fikren hem de kod olarak yardımlarını esirgemeyen @RAD Coder a çok teşekkür ederim.

Yardımcı olabildiysek ne mutlu bizlere.
RESTful mimarilerde genellikle JSON Web Token (JWT) yöntemi kullanılıyor. Bu yöntem, verilerin güvenli iletilmesini sağlayan bir standarttır.
JWT payload kısmında, müşteriyi tanımlayan bilgiler (kullanıcı adı, şifre veya daha farklı bilgiler de olabilir) yer alır. Bu bilgiler, bir hash algoritması ile kriptolu transfer edilir.
Hızlının yeni sistemi tüm RESTful mimarilerde olan süreçlerdir. Bu yapıya bir defa entegre olmanız demek bundan sonraki tüm RESTful mimarileri bir çırpıda çözeceğiniz anlamına gelir. 
Günümüzde artık veriler bu mimari ile paylaşılıyor.

[enigma]

Size şunu söyleyebilirim (Gözlemime dayanarak) Ben izibiz entegratör ile 2020 yılından bu yana çalışma yapıyorum. SOAP üzerinden XML formatında e-fatura gönderip alıyoruz. Geçen seneydi izibiz dedi ki, Ben, end-point adreslerini değiştireceğim. İnanın bunu uygulamaya tam olarak koyamadılar. Yani eski end-pointler kapatılamadı. Şu an her ikisi de çalışır durumda. Buna sebep olarak pek çok entegratörün yazılımlarını güncelleyemediklerini söylemeleriydi. Müşterileri de mağdur olmasın başka firmalara kaçmasın diye güncelleme öylece kaldı. Yani nasıl başlarsa öyle gidiyor. Çok fazla kişiye dağılmış bir uygulama kolay kolay değişemiyor.

[nguzeller]

bende 2020 beri İzibiz çalışıyorum Delphi SOAP servisi vardı, onu kullanarak Delphi ile gönderim yapabiliyorum, Uyumsoft ile kararsız kalmıştım, İzibiz yazılım sorumlusuna Restfull sistemlere ekleme tavsiye ettim, umarım Restfull sistemlerde gelir.

sadece fatura gönderme yapıyorum, diğer tüm işlemler İzibiz portal kullanıyor müşteriler.

[rmzgenius]

(22-05-2024, Saat: 10:29)RAD Coder Adlı Kullanıcıdan Alıntı: RESTful mimarilerde genellikle JSON Web Token (JWT) yöntemi kullanılıyor. Bu yöntem, verilerin güvenli iletilmesini sağlayan bir standarttır.
JWT payload kısmında, müşteriyi tanımlayan bilgiler (kullanıcı adı, şifre veya daha farklı bilgiler de olabilir) yer alır. Bu bilgiler, bir hash algoritması ile kriptolu transfer edilir.
Hızlının yeni sistemi tüm RESTful mimarilerde olan süreçlerdir. Bu yapıya bir defa entegre olmanız demek bundan sonraki tüm RESTful mimarileri bir çırpıda çözeceğiniz anlamına gelir. 
Günümüzde artık veriler bu mimari ile paylaşılıyor.

Üstad mimarinin genel yapısını anladım ama sadece bir test hesabı için bile bu kadar teferruat istiyorlar. Ben gerçek uygulamamda her müşterim için tek tek secret key ve api key mi oluşturacağım? o kısım muamma. Deseler ki, al sana Api key, kullanıcı kodu ve şifre. Bunları kullan işini gör deseler sorun yok. Ama her müşterim için şifrelenmiş bir kullanıcı adı ve parola oluşturmam gerekecek. Bunu onlar sağlamıyorlar. Yok her seferinde şifreli giriş yapacağım, her girişte oluşan token'i tutacağım. o Token ile request-response yapacağım. Gereksiz bir karmaşa var orada. BasicAuthentication gibi kolay bir şey yapmaları lazım. Eski usül SOAP servisi daha kolay şu anda.

Aynı şekilde her ne kadar uyumsoft'tan genel anlamda memnun olmasam da onlarda da restful servisler var, ve sizin öğrettiğiniz JSON örnekleri aracılığıyla çok kolay veri okuyabildim mesela. Hiç key'miş token'miş vs. uğraşmıyorum. Sadece kullanıcı adı ve şifrem yetiyor. Onlar nasıl yapıyor o zaman bu işi anlamadım.

[hi_selamlar]

(22-05-2024, Saat: 14:33)rmzgenius Adlı Kullanıcıdan Alıntı:

(22-05-2024, Saat: 10:29)RAD Coder Adlı Kullanıcıdan Alıntı: RESTful mimarilerde genellikle JSON Web Token (JWT) yöntemi kullanılıyor. Bu yöntem, verilerin güvenli iletilmesini sağlayan bir standarttır.
JWT payload kısmında, müşteriyi tanımlayan bilgiler (kullanıcı adı, şifre veya daha farklı bilgiler de olabilir) yer alır. Bu bilgiler, bir hash algoritması ile kriptolu transfer edilir.
Hızlının yeni sistemi tüm RESTful mimarilerde olan süreçlerdir. Bu yapıya bir defa entegre olmanız demek bundan sonraki tüm RESTful mimarileri bir çırpıda çözeceğiniz anlamına gelir. 
Günümüzde artık veriler bu mimari ile paylaşılıyor.

Üstad mimarinin genel yapısını anladım ama sadece bir test hesabı için bile bu kadar teferruat istiyorlar. Ben gerçek uygulamamda her müşterim için tek tek secret key ve api key mi oluşturacağım? o kısım muamma. Deseler ki, al sana Api key, kullanıcı kodu ve  şifre. Bunları kullan işini gör deseler sorun yok. Ama her müşterim için şifrelenmiş bir kullanıcı adı ve parola oluşturmam gerekecek. Bunu onlar sağlamıyorlar. Yok her seferinde şifreli giriş yapacağım, her girişte oluşan token'i tutacağım. o Token ile request-response yapacağım. Gereksiz bir karmaşa var orada. BasicAuthentication gibi kolay bir şey yapmaları lazım. Eski usül SOAP servisi daha kolay şu anda.

Aynı şekilde her ne kadar uyumsoft'tan genel anlamda memnun olmasam da onlarda da restful servisler var, ve sizin öğrettiğiniz JSON örnekleri aracılığıyla çok kolay veri okuyabildim mesela. Hiç key'miş token'miş vs. uğraşmıyorum. Sadece kullanıcı adı ve şifrem yetiyor. Onlar nasıl yapıyor o zaman bu işi anlamadım.

Merhabalar,

Aslında firmanın size verdiği kullanıcı adı ve şifreyi (bir defaya mahsus) servise gönderip Secretkey ile şifreleyip, dönen değeri kaydedip (bundan sonra hep bu kadi/şifre ile devam ediyorsunuz!)
Dönen bu şifreleri bilgileri Apikey ile TOKEN oluşturup sonrasında token gönderip sorguları çalıştırıyorsunuz. Bu arada Token süresi 3 gün belirlenmiş. Yani her defasında token almanıza da gerek yok.

Bende zamanında bir kaç firma ile görüştüm. Test bilgisi rica ettim fakat günün sonunda firmalar bayimiz olun sonra size test oratamı açalım diyor.

@RAD Coder hocamın aktardığı güzel bilgi ve tecrübelerinden sonra bende en kısa sürede SOAP yerine RestFull ile devam etmeye çalışacağım.

Kolay gelsin.

[RAD Coder]

(22-05-2024, Saat: 14:33)rmzgenius Adlı Kullanıcıdan Alıntı:

(22-05-2024, Saat: 10:29)RAD Coder Adlı Kullanıcıdan Alıntı: RESTful mimarilerde genellikle JSON Web Token (JWT) yöntemi kullanılıyor. Bu yöntem, verilerin güvenli iletilmesini sağlayan bir standarttır.
JWT payload kısmında, müşteriyi tanımlayan bilgiler (kullanıcı adı, şifre veya daha farklı bilgiler de olabilir) yer alır. Bu bilgiler, bir hash algoritması ile kriptolu transfer edilir.
Hızlının yeni sistemi tüm RESTful mimarilerde olan süreçlerdir. Bu yapıya bir defa entegre olmanız demek bundan sonraki tüm RESTful mimarileri bir çırpıda çözeceğiniz anlamına gelir. 
Günümüzde artık veriler bu mimari ile paylaşılıyor.

Üstad mimarinin genel yapısını anladım ama sadece bir test hesabı için bile bu kadar teferruat istiyorlar. Ben gerçek uygulamamda her müşterim için tek tek secret key ve api key mi oluşturacağım? o kısım muamma. Deseler ki, al sana Api key, kullanıcı kodu ve  şifre. Bunları kullan işini gör deseler sorun yok. Ama her müşterim için şifrelenmiş bir kullanıcı adı ve parola oluşturmam gerekecek. Bunu onlar sağlamıyorlar. Yok her seferinde şifreli giriş yapacağım, her girişte oluşan token'i tutacağım. o Token ile request-response yapacağım. Gereksiz bir karmaşa var orada. BasicAuthentication gibi kolay bir şey yapmaları lazım. Eski usül SOAP servisi daha kolay şu anda.

Aynı şekilde her ne kadar uyumsoft'tan genel anlamda memnun olmasam da onlarda da restful servisler var, ve sizin öğrettiğiniz JSON örnekleri aracılığıyla çok kolay veri okuyabildim mesela. Hiç key'miş token'miş vs. uğraşmıyorum. Sadece kullanıcı adı ve şifrem yetiyor. Onlar nasıl yapıyor o zaman bu işi anlamadım.

Bir API key ile tüm müşteriler adına iş yapamak pek tercih edilmeyebilir. Her API Key bir müşteriye özgüdür.  Entegratör gözüyle ScretKey=Müşteri.
Entegratöre göre müşteri siz değilsiniz, e-fatura mükellefiyeti olanlardır. 

Daha açık ifade etmek gerekirse;
Farz edelim ki ben geliştirici olarak bir ön muhasebe uygulaması yazıyorum ve bunu kullanan yüzlerce müşterim var. 
Müşterilerim (yani ön muhasebe uygulamasını kullananlar), e-fatura uygulama hizmeti almak istediklerini beyan ettiklerinde ne yapmalıyım?


- GİB ile entagre olmalıyım. Bunu nasıl yapabilirim? Doğrudan veya bir entegratör aracılığıyla yapabilirim.
- Entegratör ile yola devam etmek en kolay yöntem olduğu için müşteriye e-fatura işlemleri için şu firmanın (entegratör) e-fatura sistemine abone olun derim.
- Müşteri, entegratör firma ile iletişime geçip, kontür satın alır ve web servis için kullanıcı bilgilerini iletir. 
- Geliştirici, uygulamada müşterisi adına e-fatura işlemlerini yürütecek alt yapıyı hazırlar ve sunar. 
- e-Fatura mükellefiyeti olan müşteri, geliştirdiğimiz uygulama ayarlarına kendi API keylerini ve kullanıcı bilgilerini (ScretKey ile alınan şifreler; yada bunu bir defaya mahsus entegrasyon kapsamında biz yaparız) girecek.
- Uygulamada e-fatura işlemini yaparken, e-fatura hangi müşteriye aitse o müşterinin kendi token'ı ile işlem yapmamız gerekir. Bunun için müşterinin girmiş olduğu kullanıcı bilgileri kullanılır. 

Yanlış bir mantık ise düzeltebilirseniz memnun olurum. 
Olması gereken en ideal yöntem ne ise o istikamette ilerlemek daha doğrudur. 
Bugün klasik yöntemle ilerlemek, belki işinizi çözebilir. Fakat gelecek nereye gidiyorsa biz de (geliştiriciler olarak) orada ve en önde olmalıyız.
Yenilikler, bilinmediği için zor gelir. 
Alışageldik yöntemler, karmaşık olsa da bilindiği için her zaman kolay gelir (En kısa yol bildiğin yol prensibi).
Yenilikler, eskinin her zaman iyisi olduğu için ortaya çıkarlar. 
Hiç bir yenilik eskiden kötü olmaz, olsa zaten yenilik olmaz. 
( Kusura bakma yavaş yavaş felsefeye kaydı, konu saptı.  )

[nguzeller]

kullancı şifre değiştimi ScretKey değişir mi.
ScretKey madem zorunlu o zaman entertör firma bu key döndüren bir hizmet sağlıyor mu.

[RAD Coder]

(22-05-2024, Saat: 16:10)nguzeller Adlı Kullanıcıdan Alıntı: kullancı şifre değiştimi ScretKey değişir mi.
ScretKey madem zorunlu o zaman entertör firma bu key döndüren bir hizmet sağlıyor mu.

ScretKey sabit. Müşteriye özgü bir defaya mahsus veriliyor.
Aynı scretkey, aynı kullanıcı adı ve şifresini oluşturuyor. 
Kullanıcı adı ve şifre değişimi için entegratörden yeni bir scretkey talep edilmelidir. 
Scretkey döndürülmüyor. 
Siz talepte bulunduğunuzda, size apikey, scretkey, user name ve password veriliyor. 
1 - scretkey, username ve pasword'ü bir metoda gönderip kullanıcı adı ve şifre alıyorsunuz. Bu işlem bir defaya mahsus yapılıyor. Sonrasında bu 3 parametreyi hiç kullanmıyorsunuz.
2- Tüm işlemler Access token ile yapılıyor. Accesss token almak için yukarıdaki işlem sonucunda elde ettiğiniz kullanıcı adı şifresi ile apikey kullanıyorsunuz. 
3- İşlemleriniz için 3 saat geçerli (@hi_selamlar bahsetmişti) token gönderip, sonuç alıyorsunuz.

[nguzeller]

scretkey artısı müşterin user ve paswort db kayıt etmeden işini görebiliyor olması, müşteri scretkey alıp programı girmesi sorun olmaz gibi geliyor.

[RAD Coder]

(22-05-2024, Saat: 16:41)nguzeller Adlı Kullanıcıdan Alıntı: scretkey artısı müşterin user ve paswort db kayıt etmeden işini görebiliyor olması, müşteri scretkey alıp programı girmesi sorun olmaz gibi geliyor.

En kritik key, scretkey bu müşteride kalabilir. 
Bununla üretilen kullanıcı adı ve şifrenin uygulamda kullanılması yeterli.