GnuCash 5.9 yayımlandı

 (gnucash.org)
2 puan yazan GN⁺ 2024-10-02 | 1 yorum | WhatsApp'ta paylaş
  • GnuCash 5.9, kararlı 5.x serisinin onuncu sürümü olarak 5.8'den sonra bulunan hataları düzeltirken CSV tarih ayrıştırma ve çevrimiçi fiyat tekliflerinde iyileştirmeler getiriyor
  • Bu sürüm; mutabakat penceresi, MySQL arka uç hata mesajları, işlem kopyalama/yapıştırma, hesap silme çökmesi ve Windows sayısal tuş takımındaki ondalık ayırıcı yerel ayar hatası dahil 12 hatayı düzeltiyor
  • Çevrimiçi fiyat tekliflerine YH Finance(FINANCEAPI) API anahtarı yapılandırması ve financeapi kaynağı eklendi; CSV içe aktarma ise yerel ayar tabanlı tarihleri ve İngilizce ay adlarını daha iyi işliyor
  • Windows 10 ve üzeri, macOS 10.13 High Sierra ve üzeri için paketler ile Flathub flatpak sunuluyor; doğrudan derlemek için Gtk+, Guile, Boost gibi belirtilen asgari bağımlılıklar gerekiyor
  • Almanya'daki AQBanking kullanıcıları paketle gelen AQBanking 6.5.4 sürümünü kullanacak; yeni PIN/TAN uygulamasının betası yalnızca GnuCash nightly builds içinde sunuluyor

GnuCash 5.9 sürümünün niteliği

  • GnuCash 5.9, kararlı 5.x serisinin onuncu sürümüdür
  • GnuCash, GNU General Public License(GPL) ile dağıtılan ücretsiz ve açık kaynaklı bir muhasebe programıdır; GNU/Linux, *BSD, Solaris, macOS ve Microsoft Windows'u destekler
  • Geliştirme 1997'de başladı ve ilk kararlı sürüm 1998'de yayımlandı

5.8'den sonra düzeltilen başlıca sorunlar

  • Mutabakat sırasında yeni işlem eklendiğinde mutabakat penceresinde görünmeme sorunu giderildi
  • MySQL arka ucu, hatalı kimlik bilgileri için "bad or corrupt data" yerine "access denied" hatasını bildiriyor
  • İşlem kopyalama/yapıştırma ve kesme/yapıştırma davranışları düzeltildi
    • Buna, işlem kesme/yapıştırmanın işlemi hedef hesaba taşımaması sorunu da dahil
  • sqlite arka ucunda yeni dosya oluşturulurken örnek Python betiğinin hata çıktısı vermesi sorunu düzeltildi
  • Transaction Journal görünümünde işlem değişikliği commit edildikten sonra imleç konumunun kayması sorunu giderildi
  • Mutabakat tarihi ayrıştırma hatası, hesap silme çökmesi ve göreli tarih ofsetlerinde çeyrek hesaplama hatası çözüldü
  • Windows'ta sayısal tuş takımı ondalık girişinin yerel ayarla uyuşmaması sorunu düzeltildi
  • Fatura yayımlama ekranındaki hesap açılır liste kutusunun fazla küçük olması ve aralıklı fiyat teklifi sorunları giderildi

Çevrimiçi fiyat teklifleri ve CSV içe aktarma iyileştirmeleri

  • Çevrimiçi fiyat teklifi altyapısına YH Finance(FINANCEAPI) API anahtarı yapılandırması eklendi
    • Online Quotes sayfasında ilgili ayarlar yönetilebiliyor
    • financeapi, bilinen fiyat teklifi kaynaklarına eklendi
  • CSV tarih ayrıştırıcısı, ICU ve Boost kullanacak şekilde iyileştirildi
    • ICU tabanlı Locale tarih biçimiyle geçerli yerel ayardaki tarihleri ayrıştırıyor
    • "3 May 2023" veya LC_TIME=zh_TW.utf8 altında "2024年9月13日" gibi girdileri işleyebiliyor
    • d-m-y, m-d-y, y-m-d biçimleri Boost'un UK/US/ISO ayrıştırıcılarıyla destekleniyor
    • "30 Sep 2023", "May 4, 1978", "2023-Dec-25" gibi İngilizce ay adları içeren tarihler de CSV içe aktarmada işlenebiliyor
    • Boost ayrıştırıcısı iki basamaklı yılı tanımadığından "30 Sep 24" geçerli değil
  • CSV Import Assistant'ın giriş sayfası iyileştirildi

İç temizlik ve geliştirici odaklı değişiklikler

  • Kopyalanan öğeleri işleme yapısı düzenlendi
    • copied_class ve copied_leader_guid, statik değişkenlerden copied_item yapısının bir parçasına taşındı
    • clear_copied_item çağrısının copied_item kullanılmadan önce gerekli olduğu daha açık hale geldi
  • Dosya geçmişinde dosya açılırken commit edilmemiş düzenlemeler doğru şekilde işleniyor
  • gnc_difftime, time64 değerini double'a cast ettiği için deprecated olarak işaretlendi ve kullanılmaması öneriliyor
  • Kullanılmayan gnc_pricedb_substitute_commodity, gnc_pricedb_lookup_at_time64 kaldırıldı

Çeviri ve dokümantasyon değişiklikleri

  • Yeni eklenen veya güncellenen çeviriler Assamese, Chinese(Simplified), Chinese(Traditional), Croatian, Dutch, English(United Kingdom), Hebrew, Hungarian, Macedonian, Norwegian Bokmål, Portuguese(Brazil), Russian, Spanish, Swedish ve Turkish oldu
  • Dokümantasyon tarafındaki değişiklik GitHub CI actions sürüm güncellemesi oldu
  • Doküman çevirilerinde German yeni eklendi veya güncellendi
  • Çeviriye katkı bilgileri Weblate üzerindeki GnuCash projesinde yer alıyor

AQBanking ile ilgili notlar

  • Almanya'daki AQBanking kullanıcıları için ayrı bir bilgilendirme yer alıyor
  • AQBanking geliştiricisi, güncellenmiş PIN/TAN kodunu tamamlama çalışmalarını sürdürüyor
  • Bu sürümün Flatpak, macOS ve Windows paketlerinde son kararlı sürüm olan AQBanking 6.5.4 bulunuyor
  • Kararlı AQBanking çalışmıyorsa, yeni uygulamanın betasını içeren GnuCash nightly builds değerlendirilebilir
  • Açık hataların tam listesi GnuCash hata listesinde görülebilir

Dağıtım paketleri ve derleme koşulları

  • GnuCash 5.9, Microsoft Windows 10 ve üzeri ile macOS 10.13 High Sierra ve üzeri için önceden derlenmiş hepsi bir arada paketler olarak sunuluyor
    • Windows paketi yükleyici biçiminde
    • macOS paketi, sürükle-bırak uygulama paketini içeren bir disk imajı biçiminde
  • Flathub.org üzerinden flatpak olarak da sunuluyor
  • İndirilebilir dosyalar arasında tarball, Windows kurulum dosyası, Apple Silicon için dmg, Intel Mac için dmg ve dokümantasyon tarball'ı bulunuyor
  • Kaynak kodu SourceForge ve GitHub'dan bzip2 veya gzip biçiminde alınabilir; ayrıca Git deposundan doğrudan checkout da yapılabilir
  • Elle derlemek için şu asgari bağımlılıklar gerekiyor
  • Bağımlılıkların tam listesi ve doğru sürümler için kaynak ağacındaki README.dependencies dosyasına bakılmalı

GnuCash 5.9 dokümantasyonu

  • GnuCash 5.9 dokümantasyonuna GnuCash web sitesindeki Documentation page üzerinden erişilebilir
  • GnuCash v5 (current stable release) altında çeşitli dillerde çevrimiçi okuma ve indirme seçenekleri sunuluyor
  • İndirme biçimleri arasında pdf, epub, mobi yer alıyor
  • Dokümanlar macOS ve Windows uygulama paketlerine de dahil
  • GnuCash Documentation 5.9 kaynakları SourceForge veya GitHub'dan alınabilir, ayrıca Git deposundan doğrudan checkout yapılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-02
Hacker News yorumları

  • İşletme muhasebesi için GnuCash kullanıyorum ve ihtiyaç duyduğum işlevleri fazlasıyla karşılıyor.
    VC’lerin bloglarda önerdiği QuickBooks’u kullanmıyorum; kullanışlı özellikleri var ama o fiyatı ödeyecek kadar değil, ayrıca VC sermayesine ya da CPA’ya da ihtiyacım yok.
    GnuCash’i SQLite ile hiç denemedim ama zamanım olursa denemek isterim; güvenilirliğinin nasıl olduğunu merak ediyorum.
    Eskiden Oracle EBS’te teknik/işlevsel mühendis olarak çalıştım; yardımcı defterlere kadar birbirine geçmiş karmaşık şemalarla uğraştım ve GnuCash’e gelir tahakkuku işlevi ekleme fikri de hep aklımdaydı.
    SQLite şemasına bakınca belki bir deneme yapılabilir gibi görünüyor.

    • QuickBooks’tan geçiş yapan biri başkalarına yardımcı olmak isterse, qb-escape QuickBooks→GnuCash dönüştürücüsünün yardıma ihtiyacı var: https://github.com/erikmack/qb-escape/
    • GnuCash’te SQLite kararlı çalışıyor.
      Birkaç yıl önce XML’den SQLite’a geçtim ve sorun yaşamadım.
    • Kişisel kullanım ya da çok küçük işletmeler için harika, ama gerçek bir startup’ı GnuCash ile yürütmeye kalkarsanız başınız ciddi derde girebilir.
      Kendi deneyimime göre GnuCash taassubu zararlı; iş dünyası GnuCash’ten hoşlanmıyor ve yalnızca QuickBooks’u önemsiyor.
      2000’lerin başından beri kâr amacı gütmeyen kuruluşlarda ve startup’larda bu mücadeleyi verdim; eskiden ben de “mutlaka GnuCash kullanmalıyız” diyen kişiydim.
      İdeal bir dünyada GnuCash ya da QuickBooks dışındaki herhangi bir araç küçük işletme muhasebesinde bir seçenek olurdu; fakat gerçekte Intuit, API’leri ve dosya biçimleriyle QuickBooks dışındaki seçenekleri zorlaştırdı.
      QuickBooks kullanmazsanız bankalar, yatırımcılar, bordro sistemleri, vergi sistemleri ve muhasebeciler için her şey zorlaşır; bazı durumlarda hibeler ya da denetimler bile engellenebilir.
      İyi niyetli açık kaynak taraftarlarının GnuCash kullanılmasını talep ettiği durumları sık görüyorum; o kişi olmamak gerekir.
      Dünya QuickBooks’u seçti; bu seçim baskı ve yozlaşmış güç komisyonculuğu içinde yapılmış olsa da karar çoktan verildi.
      Makul SaaS seçenekleri olabilir, ama yalnızca Intuit izin verdiği sürece var olurlar; QuickBooks ile rekabet edenlerin Intuit tarafından satın alınıp ortadan kaybolması kuvvetle muhtemel.
      Birçok kâr amacı gütmeyen kuruluş ve işletmede GnuCash seçildiğini, ardından finansman kapanışları, banka gereklilikleri, kredi talepleri ve hibe başvuruları yüzünden aceleyle platform değiştirmek zorunda kalındığını gördüm; sonunda muhasebe sorumlusu haftada 60 saatin üzerinde çalışarak her şeyi yeniden yapmak zorunda kaldı.
      GnuCash harika bir proje ve herkes kullanabilse keşke; ama gerçek işletmelerde keyfî ve yapay nedenlerden dolayı kullanılamıyor.
      Muhasebe sorumlunuz gelip size NetBeans kullanmanızı dayatsa bunu kabul etmezdiniz; araç seçiminde onlara da aynı nezaketi göstermek gerekir.
    • Bu, özgür yazılımın bedava bira gibi ücretsiz olma niteliği sayesinde başarılı olduğu bir başka örnek gibi görünüyor

  • Çok sayıda kişisel muhasebe yazılımı denedim ama eski PalmOS için Pocket Money dışında hepsinde harcama girişi çok zahmetliydi.
    Bir mağaza ziyaretinin tamamını “Lidl’de market alışverişi” gibi tek bir işlem olarak kaydederseniz katlanılabilir oluyor; ama fişteki her satırı bölünmüş bir işlemin ayrı kalemi olarak girmeye çalışırsanız, geçmiş kayıtlara dayalı iyi öneriler olmadan her seferinde yeniden yazmanız gerekiyor.
    Örneğin karşı taraf Lidl ise sadece “br” yazınca food:bread ve fiyatını önerecek, karşı taraf Victoria Secret ise clothing:bra ve farklı bir fiyat önerecek kadar incelikli olabilir; ama denediklerim arasında bunu destekleyen yoktu.
    Gerçekten eski PalmOS 3.0 Pocket Money çok rahattı; masaüstü ya da mobil, geri kalanların hepsi bu konuda çok daha kötü.
    İşlemleri çok ayrıntılı kaydedecekseniz, iç içe “hesaplar” yerine iç içe kategorilerin daha iyi olduğunu düşünüyorum.
    Neredeyse yalnızca görünüşle ilgili bir fark ama “nakit” ile “food:meat:pork”un aynı tür nesne olması tuhaf.
    Parayı “food:meat:pork”a transfer etmiyorsunuz, ona harcıyorsunuz; parayı ürüne değil mağazaya gönderiyorsunuz.
    Bildiğim kadarıyla profesyonel muhasebe sistemleri de her monitör, dizüstü bilgisayar, bilgisayar ve fare için ayrı şirket varlığı hesabı tutmuyor.
    Acaba hâlâ bulamadığım bir şey mi var, önerebileceğiniz bir şey var mı merak ediyorum.

    • Fişteki her kaleme kadar takip etmenin gerçekten bu kadar faydalı olup olmadığından şüpheliyim.
      Bazı satın alma türleri için işe yarayabilir ama harcanan emeğe kıyasla o kadar değer üretmeyen gereksiz ayrıntı işi olma ihtimali yüksek.
    • Geçmişte çeşitli araçlar denedim; 2009 civarında özel mülk OS X yazılımlarından, özellikle iBank’ten sıkıldım, GNUCash ve KDEMoney de hoşuma gitmeyince sonunda kendim basit bir açık kaynak uygulama yaptım.
      Native bir Cocoa uygulaması; son zamanlarda Linux için Qt portu da var ve o zamandan beri her gün kullanıyorum.
      Eskiden kategorileri çok ayrıntılı ayırıyordum ama artık pek anlamlı bulmuyorum; uygulama bölünmüş işlemleri destekliyor, fakat genelde yalnızca “market”, “içecekler”, “temel ihtiyaçlar” gibi kategoriler kullanıyorum.
      Yine de “kahve” gibi şeyleri “Drinks:Coffee” altında tutuyorum ki belirli bir kaleme ne kadar harcadığımı görebileyim.
      Sonuçta bu kadar hassas kaydetme çabası ile gerçek kullanım değeri arasındaki denge meselesi gibi görünüyor; “Car:Fuel”, “Car:Service” gibi örnekler için de aynı.
    • Finansımı takip etmeye başladığımda yalnızca elektronik tablolar çok çabuk yetersiz kaldı; mevcut seçenekler de ihtiyaçlarıma uymuyordu.
      Çoğu insan için bu kadar ayrıntılı takip fazla olabilir ama benim için çok zaman almıyor.
      Sonunda kendi uygulamamı yaptım: https://github.com/VMelnalksnis/Gnomeshade
      Hesaplar konusunda da benzer hissettiğim için işlemleri transfer ve satın alma olarak iki parçaya ayırdım; bu sayede birden fazla para birimini işlerken kategorileri hesaplardan ayrı ele alabiliyorum.
      Bahsettiğiniz otomatik önerilere bakmadım; onun yerine sık aldığım ürünlerin fişlerini ayrıştırma yoluna gittim.
    • Muhtemelen fazla ayrıntıya iniyorsunuz.
      Ben sadece “market”, “sarf malzemeleri”, “giyim” gibi ayırıyorum.
      Tam olarak neye ihtiyacınız olduğunu tamamen anlamadım ama ben 10 yıldan da uzun süre önce GnuCash’ten KMyMoney’ye geçtim.
      Walmart’ta daha önce kalem kalem giriş yaptıysam, bir dahaki Walmart alışverişinde kredi kartı ekstresini içe aktarırken toplam tutarı benzer olan eski Walmart işlemini başlangıç noktası olarak seçmesi biraz yardımcı oluyor.
      Ayrıca KMyMoney hesaplar yerine kategorileri kullanıyor; ancak hesap yaklaşımı muhasebe ilkelerine daha uygun.
    • Fişlerde bu amaç için bir QR kod formatı olsa iyi olurdu.
      Kabaca mağaza adı/konumu, toplam tutar, vergi için ayrı alanlar, basit bir alışverişse “yakıt” ya da McDonald’s fişindeki “yemek” gibi genel kategori ve Costco gibi hem market ürünü hem de giyim alınabilen yerler için kalem grupları içerebilir.
      Ana kategoriler için çeşitli ülkelerin tüketici fiyat endeksi sınıflandırmalarında kullandıkları temel alınabilir.
      https://www150.statcan.gc.ca/n1/pub/71-607-x/2018016/cpi-ipc...
      https://www.bls.gov/news.release/cpi.t01.htm
      https://www.stat.go.jp/english/data/cpi/158c.html
      https://www.ecb.europa.eu/stats/macroeconomic_and_sectoral/h...

  • GNUCash modelini pek sevmiyorum.
    Kullanması biraz zahmetli ve istediğim istatistikleri çıkarmak da epey zor; bu yüzden geçmişte birkaç başka paketi denedikten sonra birinde karar kılmıştım.
    Yine de onlarca yıl önce ilk işime girdiğimde GNUCash vardı ve bugün de var.
    Bu kadar süreklilik göstermiş başka paket pek yok gibi.

    • 90’ların ortası tarzı bir yardımcı program tasarımına sahip olması çekici.
      Aynı zamanda tam da o 90’lar tarzı arayüz yüzünden inanılmaz sinir bozucu.
      GNUCash kadar arayüz tasarımı neredeyse hiç gelişmemiş bir yardımcı program gördüğümü sanmıyorum.
      Sanki bir prototip yapıp “Mükemmel!” demişler, ardından kullanıcı girdilerini yok sayıp backend işlerine geçmişler gibi.
    • Bu sürekliliğin muazzam bir değeri var.
      90’ların sonundan beri gnucash kullanıyorum ve 2000 yılına kadar uzanan tüm veri dosyalarına sahibim.

  • Birkaç yıl önce denemiştim ama sonunda HLedger’da karar kıldım.
    GnuCash gibi verilerimin sahibi olup onları kontrol edebiliyorum; ayrıca HLedger’da Sublime Text içinde doğrudan düzenleyerek toplu halde bir şeyleri düzeltebiliyor ya da değiştirebiliyorum.
    Elbette benim kullanım senaryom oldukça temel ve iş açısından kritik bir sistem değil; bu yüzden kişiden kişiye değişebilir.

    • GnuCash kullanmamak için geçerli bir neden.
      XML biçiminin harika olmadığına katılıyorum ama ben SQLite biçimini kullanıyorum; bunun üzerine betikler yazabiliyorum.
    • Firefly III kullanıyorum: https://firefly-iii.org
      Kendi barındırdığım bir web uygulaması olduğu için, çoğunlukla telefondan kullanan benim için iyi.
      Oldukça kapsamlı bir API’si var; metin dosyası kadar kolay toplu düzenlenmese de nispeten basit olmalı.
      Toplu düzenleme için kullanılabilecek bir kural sistemi de var.
    • GnuCash kullanıyorum; toplu değişikliklerin ya da kolay betiklemenin olmaması epey can sıkıcı.
      Örneğin CSV içe aktarmada küçük bir hata yaptığınızda özellikle böyle.
    • hledger ve ledger’ı, özellikle de lots özelliğini, uzun yıllardır kullanıyorum.
      hledger’ın iyi yanlarından biri çok esnek CSV kural sistemi.
      Buna basit bir Python betiği ekleyerek sermaye kazancı kayıtları için gereken ek bilgileri koydum.
      Sonuçta ham girdi verisi, kayıtları içeren CSV dosyaları; çıktı ise farklı ayrıntı düzeylerinde finansal raporlar oluyor.
    • gnucash XML’ini ledger’a dönüştüren küçük bir betiği gerçekten çalıştırıyorum; dönüşüm sonucunu ve özgün XML’i git ile izliyorum.
      gnucash arayüzüne veri girerken bunu oldukça sık çalıştırırsanız değişiklikleri okunması kolay git günlükleri ve diff’ler olarak görebilirsiniz.
      Ancak “toplu değişiklik” yeteneği eksik.
      gnucash sonuçta sadece XML olduğu için doğrudan düzenlemek de mümkün olabilir ama henüz buna cesaret edemedim.
      [0] temel alınmıştır: https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...

  • Hackerspace muhasebesi için GnuCash kullanıyorum.
    Ya bunu kullanacaktık ya da yakındaki makerspace’in muhasebe sorumlusunun önerdiği “wave” adlı siteyi.
    wave’e kaydolup biraz kurcaladım ama emin olamadım; birkaç hafta sonra wave’i kullanmaya karar verdiğimde hesabım hiçbir neden gösterilmeden kilitlenmişti.
    Bu yüzden GnuCash’e yöneldik.
    İyi bir yazılım; sonunda libgnucash kütüphanesine dinamik olarak bağlanan kod yazarak üye aidatları için aylık faturaları otomatik oluşturmasını sağladım.

    • GnuCash’i otomatikleştirmenin daha iyi bir yolu, örneğin Bash veya Python betikleri gibi bir şey olup olmadığını merak ediyorum.
    • İlginç; kodu paylaşabilir misiniz merak ediyorum.

  • Kişisel finans yazılımı olarak Beancount ya da genel düz metin muhasebesini seçmeden önce GnuCash’e ayrıntılı biçimde bakmıştım.
    Belirleyici takıldığım nokta GnuCash’in dahili XML veya SQLite biçimiydi.
    Ham veri toplama ya da rapor üretimini betiklemeye pek uygun değil; Beancount veya HLedger gibi düz metin araçlarının hedeflediği şey de tam olarak bu.
    Düz metin araçlarıyla karşılaştırınca GnuCash fazla kapalı bahçe gibi hissettiriyor.
    Düz metin biçimi başlangıçta daha fazla emek istiyor ama alışınca ve betikleme geçmişiniz varsa harika.

    • Zevk meselesi olabilir ama benim deneyimim bunun tam tersi.
      Düz metin insan gözüne basit görünür ama yapısal olarak ayrıştırması kâbus gibidir; düz metin düzenlemeyi betiklemek de dağınıktır.
      Buna karşılık veritabanları tam olarak bu tür kullanım için yapılmıştır.
      Düz metin muhasebeyle ilgili şikâyetlere ve iyileştirme denemelerine çok zaman harcadıktan sonra şimdi SQLite kullanıyorum; muazzam bir iyileşme oldu.
    • XML/DB şeması belgelenmişse, pratikte Beancount/Ledger’ın düz metin biçiminden daha iyi ve sağlamdır.
      Ben KMyMoney’nin XML arka ucunu kullanıyorum ve verileri Ledger biçimine dönüştüren bir betiğim de var.
      Serbest biçimli metin olmadığı için o betiği yazmak aksine daha kolaydı.
    • Beancount + Fava birleşimi epey iyi görünüyor; deneyiminizi anlatabilir misiniz merak ediyorum.
    • SQLite yeterli değilse GnuCash SQL arka uçlarını da destekliyor.
      Ben neredeyse 10 yıldır bu şekilde çalıştırıyorum.

  • GnuCash’in gönlümde özel bir yeri var.
    Üniversiteden mezun olduktan sonraki ilk birkaç yılda dar gelirle çok sıkı bir bütçe yürütüyordum; her market alışverişinden sonra fişi eve getirip deftere özenle giriyordum.
    Her zaman her şey tutardı ama inanılmaz çok işti.

  • İsveç’te serbest danışman olarak son 10 yılı aşkın sürede GnuCash’e birkaç kez baktım ama hep aynı sorun vardı.
    Bizim ekonomi ve vergi dairesi sistemimize göre uyarlanmış değil.
    İsveç’te cironuz yılda 3 milyon SEK’in altındaysa “förenklat årsbokslut”, kabaca “basitleştirilmiş yıl sonu kapanışı” kullanabilirsiniz.
    Pratikte gider ve gelirleri yöneten çok temel bir programı kendiniz yapıp gerekli sayıları üretmeniz ve bunları her yıl vergi dairesinin çevrimiçi uygulamasına elle girmeniz yeterli oluyor.

    • Ben de basitleştirilmiş defter tutan tek kişilik bir freelancer’ım.
      Çift taraflı muhasebe, ilk öğrenme eğrisini aştıktan sonra tek taraflı defter tutmadan daha fazla çaba gerektirmedi.
      Çünkü yaygın hatalardan otomatik olarak kaçınmanızı sağlıyor.
      GnuCash’i 20 yıldır sorunsuz kullanıyorum; kırılgan elektronik tablolara ya da kötü yapılmış Access DB’lere dönmeye hiç niyetim yok.

  • Bir süre GnuCash kullandım, ama çevrim içi senkronizasyon ayarlarını tutturmaya çok fazla zaman harcar oldum
    Elle indirip içe aktarmam gereken hesaplarda, bu sürtünme yüzünden içe aktarmayı ertelemeye başladım
    Şimdi Quicken Classic için para ödüyorum ve her yıl harcadığım paralar arasında memnuniyetimin en yüksek olduğu şeylerden biri
    Çevrim içi hesap bağlantıları sürekli beklediğim gibi çalışıyor ve genel olarak işleri çok daha az baş ağrısıyla hallediyor

    • ABD, Kanada, AB’de iki ülke ve Meksika’daki hesaplarla ilgilenmem gerekiyor
      Quicken Classic gibi banka bağlantıları güvenilir şekilde çalışan ücretli bir seçenek olsa iyi olurdu, ama ABD ile büyük AB ekonomilerinden birini bile aynı anda kapsayan tek bir ürün yok gibi; ihtiyaç duyduğum tüm bölgeler ise daha da zor
      Quicken Classic yalnızca ABD ve Kanada’ya yönelik
      Böyle bir seçenek ya da bu amacı makul biçimde birlikte kullanarak sağlayabilecek birden fazla seçenek bilen var mı merak ediyorum
      İşlem verilerine erişim sağlayan şirketlerin ABD-AB arasındaki köprüyü bireylerin doğrudan kullanmasına uygun şekilde geçmemesine bakınca, iki tarafın bürokratik sistemlerinin uyumsuzluğu gibi bir neden var gibi görünüyor
      Ya da yeterince çok insan bu kadar uluslararası bir hayat yaşamıyor olabilir

  • GnuCash ile işimi yürüttüm; maaş ödemeleri ve 401k hesapları yönetimi gibi şeyleri de yaptım
    Stabil çalışıyordu; harcamaları sınırlı bir işiniz ya da muhasebe geçmişiniz varsa gider takibi de yeterliydi
    Muhasebeciye verebileceğim bilanço ve gelir tablosu oluşturabilmesi gerçekten harikaydı