2 ポイント 投稿者 GN⁺ 2024-10-02 | 1件のコメント | WhatsAppで共有
  • GnuCash 5.9は安定版5.xシリーズの10回目のリリースで、5.8以降に見つかったバグ修正に加え、CSVの日付解析とオンライン相場の改善を含む
  • 今回のバージョンでは、照合ウィンドウ、MySQLバックエンドのエラーメッセージ、取引のコピー/貼り付け、勘定科目削除時のクラッシュ、Windowsのテンキー小数点ロケール不具合など、12件のバグを修正
  • オンライン相場には**YH Finance(FINANCEAPI)**のAPIキー設定とfinanceapiソースが追加され、CSVインポートはロケールベースの日付と英語の月表記をより適切に処理する
  • Windows 10以降、macOS 10.13 High Sierra以降向けのパッケージとFlathubのflatpakが提供され、独自にビルドする場合はGtk+・Guile・Boostなど指定された最小依存関係が必要
  • ドイツのAQBankingユーザーはバンドルに含まれるAQBanking 6.5.4を使うことになり、新しいPIN/TAN実装のベータ版はGnuCash nightly buildsでのみ提供される

GnuCash 5.9リリースの性格

  • GnuCash 5.9は安定版5.xシリーズの10回目のリリース
  • GnuCashはGNU General Public License(GPL)で配布される無料のオープンソース会計ソフトウェアで、GNU/Linux、*BSD、Solaris、macOS、Microsoft Windowsをサポートする
  • 開発は1997年に始まり、最初の安定版リリースは1998年に公開された

5.8以降に修正された主な問題

  • 照合(reconcile)中に新しい取引を追加しても照合ウィンドウに表示されない問題が解決された
  • MySQLバックエンドは、不正な認証情報に対して"bad or corrupt data"ではなく**"access denied"**エラーを報告する
  • 取引のコピー/貼り付けと切り取り/貼り付けの動作が修正された
    • 取引の切り取り/貼り付けで、取引が対象の勘定科目へ移動しない問題を含む
  • sqliteバックエンドで新規ファイル作成時にサンプルPythonスクリプトがエラーを出力していた問題が修正された
  • Transaction Journalビューで取引変更をコミットした後、カーソル位置がずれる問題が修正された
  • 照合日の解析失敗、勘定科目削除時のクラッシュ、相対日付オフセットの四半期計算エラーが解決された
  • Windowsでテンキーの小数点入力がロケールと一致しない問題が修正された
  • 請求書の転記画面にある勘定科目ドロップダウンリストボックスが小さすぎる問題と、断続的な相場価格の問題が修正された

オンライン相場とCSVインポートの改善

  • オンライン相場インフラに**YH Finance(FINANCEAPI)**のAPIキー設定が追加された
    • Online Quotesページで関連設定を扱える
    • financeapiが既知の相場ソースに追加された
  • CSVの日付パーサーはICUとBoostを活用するよう改善された
    • ICUベースのLocale日付形式で現在のロケールの日付を解析する
    • "3 May 2023"またはLC_TIME=zh_TW.utf8での"2024年9月13日"のような入力を処理できる
    • d-m-ym-d-yy-m-d形式はBoostのUK/US/ISOパーサーで補強された
    • "30 Sep 2023""May 4, 1978""2023-Dec-25"のような英語の月表記の日付もCSVインポートで処理可能
    • Boostパーサーは2桁年を認識できないため、"30 Sep 24"は有効ではない
  • CSV Import Assistantの紹介ページが改善された

内部整理と開発者向け変更

  • コピーされた項目の処理構造が整理された
    • copied_classcopied_leader_guidが静的変数からcopied_item構造の一部へ移動した
    • copied_item使用前にclear_copied_item呼び出しが必要である点がより明確になった
  • ファイル履歴からファイルを開く際、コミットされていない編集を正しく処理する
  • gnc_difftimetime64をdoubleへキャストするため、使用しないようdeprecated扱いになった
  • 使用されていないgnc_pricedb_substitute_commoditygnc_pricedb_lookup_at_time64が削除された

翻訳とドキュメントの変更

  • 新規追加または更新された翻訳は、アッサム語、中国語(簡体字)、中国語(繁体字)、クロアチア語、オランダ語、英語(英国)、ヘブライ語、ハンガリー語、マケドニア語、ノルウェー語ブークモール、ポルトガル語(ブラジル)、ロシア語、スペイン語、スウェーデン語、トルコ語
  • ドキュメント側の変更はGitHub CI actionsのバージョン更新
  • ドキュメント翻訳はドイツ語が新規追加または更新された
  • 翻訳への参加はWeblateのGnuCashプロジェクトで案内されている

AQBanking関連の案内

  • ドイツのAQBankingユーザー向けの別途案内が含まれている
  • AQBankingの作者は、更新されたPIN/TANコードの仕上げ作業を継続中
  • このリリースのFlatpak、macOS、Windowsバンドルには、最後の安定版であるAQBanking 6.5.4が含まれる
  • 安定版AQBankingが動作しない場合、新しい実装のベータ版を含むGnuCash nightly buildsを検討できる
  • 未解決バグの全一覧はGnuCashのバグ一覧で確認できる

配布パッケージとビルド条件

  • GnuCash 5.9はMicrosoft Windows 10以降とmacOS 10.13 High Sierra以降向けの事前ビルド済みオールインワンパッケージとして提供される
    • Windowsはインストーラー形式
    • macOSパッケージはドラッグ&ドロップ式のアプリケーションバンドルを含むディスクイメージ
  • Flathub.orgからflatpakとしても提供される
  • ダウンロードファイルには、tarball、Windowsインストーラー、Apple Silicon向けdmg、Intel Mac向けdmg、ドキュメントtarballが含まれる
  • ソースコードはSourceForgeとGitHubからbzip2またはgzip形式で入手でき、Gitリポジトリから直接チェックアウトすることもできる
  • 自分でコンパイルするには、以下の最小依存関係が必要
  • 正確な依存関係の一覧とバージョンは、ソース内のREADME.dependenciesファイルを参照する必要がある

GnuCash 5.9ドキュメント

  • GnuCash 5.9のドキュメントはGnuCashウェブサイトのDocumentation pageで確認できる
  • GnuCash v5 (current stable release)の下で、複数の言語によるオンライン閲覧とダウンロードを提供する
  • ダウンロード形式にはpdf、epub、mobiが含まれる
  • ドキュメントはmacOSとWindowsのアプリケーションバンドルにも含まれる
  • GnuCash Documentation 5.9のソースはSourceForgeまたはGitHubから入手でき、Gitリポジトリから直接チェックアウトすることもできる

1件のコメント

 
GN⁺ 2024-10-02
Hacker News のコメント
  • GnuCashを事業会計に使っていて、必要な機能は十分にこなしてくれている
    VC がブログで勧める QuickBooks は使っていない。便利な機能はあるが、その価格を払うほどではなく、VC 資金も CPA も必要ない
    GnuCash を SQLite と組み合わせて使ったことはないが、時間ができたら試してみたいし、信頼性がどの程度なのか気になる
    以前 Oracle EBS の技術/機能エンジニアとして働いていて、補助元帳まで相互に絡み合う複雑なスキーマを扱っていたので、GnuCash に収益認識機能を追加することもずっと考えてきた
    SQLite のスキーマを見れば、一度試してみられるかもしれない

    • QuickBooks から移行する人がほかの人を助けたいなら、qb-escape の QuickBooks→GnuCash 変換ツールが協力を必要としている: https://github.com/erikmack/qb-escape/
    • GnuCash での SQLite は安定している
      数年前に XML から SQLite に移行したが、問題はなかった
    • 個人用途やごく小規模な事業には素晴らしいが、本物のスタートアップを GnuCash で運営しようとすると大変なことになりかねない
      実体験から言うと、GnuCash 信奉は有害で、ビジネスの世界は GnuCash を嫌い、QuickBooks だけを気にしている
      2000年代初めから非営利団体やスタートアップでこの戦いをしてきたし、昔は自分も「私たちは必ず GnuCash を使うべきだ」という側の人間だった
      理想の世界なら、GnuCash であれ QuickBooks ではない何らかのツールであれ、小規模事業会計の選択肢になっているはずだが、現実には Intuit が API とファイル形式によって QuickBooks 以外の選択を難しくしている
      QuickBooks を使わないと、銀行、投資家、給与システム、税務システム、会計士のすべてが苦労し、場合によっては助成金や監査まで妨げられることがある
      善意のオープンソース信奉者が GnuCash の使用を求める場面をよく見るが、そういう人になってはいけない
      世の中は QuickBooks を選んだ。その選択は圧力や腐敗した権力仲介の中で行われたものだが、すでに決まってしまっている
      まともな SaaS の選択肢はあり得るかもしれないが、それも Intuit が許している間だけ存在し、QuickBooks と競合するものは Intuit に買収されて消える可能性が高い
      複数の非営利団体や事業体で GnuCash を選んだものの、資金締め、銀行要件、融資申請、助成金申請のために急いでプラットフォームを変えざるを得ず、結局、会計担当者が週60時間以上働いてすべてをやり直すことになった
      GnuCash は素晴らしいプロジェクトで、誰もが使えるならいいと思うが、実際の事業では恣意的かつ人為的な理由によって使えない
      会計担当者がやって来て NetBeans を使えと強要したら受け入れないはずなので、ツール選びでは彼らにも同じ礼儀を示すべきだ
    • 自由ソフトウェアが無料のビールのようにタダであるという性質のおかげで成功した、もう一つの事例に見える
  • 個人向け会計ソフトはいろいろ使ってきたが、古い PalmOS 向け Pocket Money を除くと、どれも支出の入力があまりに不便だった
    店での買い物全体を「Lidl で食料品」のような1つの取引として記録するなら我慢できるが、レシートの各行を分割取引の個別項目として入れようとすると、過去の記録に基づく良い提案もなく、毎回入力し直さなければならない
    たとえば取引相手が Lidl なら「br」と打つだけで food:bread と価格を提案し、取引相手が Victoria Secret なら clothing:bra と別の価格を提案する、という具合に高度にできるはずだが、自分が使ったものの中で対応しているものはなかった
    本当に古い PalmOS 3.0 Pocket Money は非常に使いやすく、デスクトップでもモバイルでも、それ以外はこの点でははるかに劣る
    取引を非常に詳しく記録するなら、入れ子の「勘定」より入れ子の 分類 の方がよいと思う
    ほとんど見た目だけの違いではあるが、「現金」と「food:meat:pork」が同じ種類のオブジェクトだというのは奇妙だ
    お金を「food:meat:pork」に振り替えるのではなく、それに支出しているのであり、商品ではなく店にお金を送っているのだ
    本格的な会計システムでも、モニター、ノートPC、コンピューター、マウスごとに会社資産の勘定を別々に持つことはないと理解している
    もしかするとまだ見つけられていないだけなのか、おすすめできるものがあるのか気になる

    • レシートの各項目まで追跡することが実際にそこまで有用なのか疑問だ
      一部の購入タイプには役立つかもしれないが、かかる手間に見合う価値を生まない 不要な細部作業 である可能性が高い
    • 過去にいくつものツールを試し、2009年ごろにプロプライエタリな OS X ソフトウェア、特に iBank にいら立ったうえ、GNUCash と KDEMoney も気に入らなかったため、結局自分で簡単な オープンソースアプリ を作った
      ネイティブの Cocoa アプリで、最近は Linux 向けの Qt ポートもあり、それ以来毎日使っている
      以前は分類をかなり細かく分けていたが、今はあまり意味を感じず、アプリは分割取引に対応しているものの、通常は「食料品」「飲料」「必需品」程度の分類しか使わない
      ただし「コーヒー」のようなものは「Drinks:Coffee」として、特定の項目にいくら使っているかを見られるようにしている
      結局、そのくらい正確に記録する手間と実際の活用価値とのバランスの問題に見え、「Car:Fuel」「Car:Service」のようなものも同じだ
    • 家計の追跡を始めたとき、スプレッドシートだけではすぐ限界が来て、既存の選択肢も必要に合わなかった
      ほとんどの人にとってこの程度の詳細な追跡はやりすぎかもしれないが、自分にはそれほど時間はかからない
      結局、自分でアプリを作った: https://github.com/VMelnalksnis/Gnomeshade
      勘定についても同じように感じたので、取引を 振替と購入 の2つの部分に分けた。おかげで複数通貨を扱いながら、分類を勘定から切り離して扱える
      言及されていた自動提案は調べず、よく買う商品のレシートをパースする方向に進んだ
    • おそらく細分化しすぎているのだと思う
      私は「食料品」「消耗品」「衣類」程度にしか分けていない
      必要としているものが正確には何なのか完全には理解できていないが、私は10年以上前に GnuCash から KMyMoney に移った
      Walmart で以前に項目別に入力していたなら、次に Walmart に行ってクレジットカード明細を取り込むとき、合計額が近い過去の Walmart 取引を出発点として使ってくれるので、多少は役に立つ
      そして KMyMoney は勘定の代わりに分類を使うが、会計原則には勘定方式の方が合っている
    • レシートにこの用途向けの QRコード形式 があるとよさそうだ
      おおよそ店名/場所、合計額、税の分離フィールド、単純な購入なら「燃料」や McDonald’s のレシートの「食べ物」のような一般分類、そして Costco のように食料品と衣類を一緒に買える場所向けの項目グループを含められる
      主要な分類は、各国が消費者物価指数の分類に使っているものを参考にできる
      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 のモデルはあまり好きではない
    使うのが少し面倒で、欲しい統計を取り出すのもかなり難しかったので、以前はいくつか別のパッケージを試して落ち着いていた
    それでも、自分が何十年も前に最初の仕事に就いたとき GNUCash は存在していた し、今も存在している
    これほどの継続性を示した他のパッケージはほとんどないように思う

    • 90年代半ばのユーティリティデザインを持っている点は魅力的だ
      同時に、まさにその 90年代風インターフェース のせいで非常にいら立つ
      GNUCash ほどインターフェースデザインがほとんど進化していないユーティリティを見たことがない
      プロトタイプを作って「完璧だ!」と言ったあと、ユーザー入力を無視してバックエンド作業に移ったような感じだ
    • この継続性にはものすごい価値がある
      90年代末から gnucash を使っていて、2000年までさかのぼるすべてのデータファイルを持っている
  • 数年前に使ってみたが、結局 HLedger に落ち着いた
    GnuCash のように自分のデータを所有して管理できるうえ、HLedger では Sublime Text で直接編集して、大量に何かを修正したり変更したりできる
    もちろん私のユースケースはかなり基本的で、業務の中核システムではないので、人によって違うかもしれない

    • GnuCash を使わない妥当な理由だと思う
      XML 形式が優れていないという点には同意するが、私は SQLite 形式を使っていて、その上にスクリプトを書ける
    • Firefly III を使っている: https://firefly-iii.org
      セルフホスト型の Web アプリなので、ほとんどスマートフォンで使う私には向いている
      かなり幅広い API があり、テキストファイルほど一括編集が簡単ではないにしても、比較的シンプルなはず
      ルールシステムもあるので、一括編集に活用できる
    • GnuCash を使っているが、一括変更や簡単なスクリプト化ができない点がかなり厄介
      たとえば CSV インポートで小さなミスをしたときは特にそう
    • hledger と ledger、特に lots 機能を何年も使ってきた
      hledger の良い点の一つは、非常に柔軟な CSV ルールシステム
      そこに簡単な Python スクリプトを組み合わせて、キャピタルゲインの記録に必要な追加情報を入れた
      結局、生の入力データは記録が入った CSV ファイル群で、出力はさまざまな詳細レベルの財務レポートになる
    • gnucash XML を ledger に変換する小さなスクリプトを実際に走らせ、変換結果と元の XML を git で追跡している
      gnucash UI に入力しながらかなり頻繁に実行すると、変更内容を読みやすい git ログと diff で確認できる
      ただし「一括変更」の能力は欠けている
      gnucash は単なる XML なので直接編集もできるのだろうが、まだ思い切って試してはいない
      [0] ベース: https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...
  • ハッカースペースの会計に GnuCash を使っている
    これを使うか、近くのメイカースペースの会計担当者が勧めた「wave」というサイトを使うかの選択だった
    wave に登録して少し触ってみたが確信が持てず、数週間後に wave を使うことに決めたら、理由もなくアカウントがロックされていた
    それで GnuCash にした
    良いソフトウェアで、最終的には libgnucash ライブラリに動的リンクするコードを書き、会員会費の月次請求書を自動生成できるようにした

    • GnuCash を自動化するもっと良い方法、たとえば Bash や Python スクリプトのようなものがないのか気になる
    • 興味深い。コードを共有できるのか気になる
  • 個人向け財務ソフトとして Beancount か一般的なプレーンテキスト会計を選ぶ前に、GnuCash を詳しく調べた
    決定的に引っかかったのは、GnuCash の内部 XML または SQLite 形式だった
    生データの取り込みやレポート生成のスクリプト化にはあまり向いておらず、Beancount や HLedger のようなプレーンテキスト系ツールはまさにそこを狙っている
    プレーンテキスト系ツールと比べると、GnuCash はあまりに 閉じた庭のように感じる
    プレーンテキスト形式は最初により多くの作業が必要だが、慣れていてスクリプトを書く背景があるなら素晴らしい

    • 好みの問題だろうが、私の経験は正反対
      プレーンテキストは人間の目には単純に見えるが、構造的にパースするのは悪夢で、プレーンテキスト編集をスクリプト化するのもごちゃごちゃする
      一方でデータベースはこうした用途のために作られている
      プレーンテキスト会計への不満と改善の試みに多くの時間を費やしたあと、今は SQLite を使っており、ものすごい改善だった
    • XML/DB スキーマが文書化されているなら、実際には Beancount/Ledger のプレーンテキスト形式よりも優れていて堅牢
      私は KMyMoney の XML バックエンドを使い、データを Ledger 形式に変換するスクリプトも持っている
      自由形式のテキストではないので、むしろそのスクリプトは書きやすかった
    • Beancount + Fava の組み合わせはかなり良さそうに見えるが、使った経験を聞かせてもらえるのか気になる
    • SQLite で足りないなら、GnuCash は SQL バックエンドもサポートしている
      私はほぼ10年、それで運用している
  • GnuCash には心の中で特別な場所がある
    大学卒業後の最初の数年間、厳しい収入で非常に切り詰めた予算を回していて、買い物をするたびにレシートを家に持ち帰り、帳簿にこつこつ入力していた
    いつもすべての辻褄は合っていたが、ものすごく手間がかかった

  • スウェーデンのフリーランスコンサルタントとして、この10年以上 GnuCash を何度も調べてきたが、いつも同じ問題があった
    自分たちの経済や税務当局の仕組みに合っていない
    スウェーデンでは売上が年 300万 SEK 未満なら「förenklat årsbokslut」、大まかには「簡易年度決算」を使える
    実際には、支出と収入を管理するごく基本的なプログラムを自分で作り、必要な数字を生成して毎年税務当局のオンラインアプリに手入力すればよい

    • 私も簡易帳簿を使う一人フリーランス
      複式簿記は最初の学習曲線を越えれば、単式簿記より多くの労力はかからなかった
      よくあるミスを自動的に避けられるから
      GnuCash を20年間うまく使っており、壊れやすいスプレッドシートや中途半端な Access DB に戻るつもりはない
  • しばらく GnuCash を使っていたが、オンライン同期の設定を合わせるのに時間を使いすぎるようになった。
    手動でダウンロードして取り込む必要がある口座は、その手間が障壁になってインポートを先延ばしにしてしまった。
    今は Quicken Classic にお金を払って使っているが、毎年使うお金の中で最も満足度が高い。
    オンライン口座連携が期待どおりに安定して動き、全体的にずっと面倒なく用事を片付けてくれる。

    • 米国、カナダ、EU の2か国、メキシコの口座を気にする必要がある。
      Quicken Classic のように銀行連携が安定して動く有料の選択肢があればうれしいが、米国と主要な EU 経済圏の1つを同時にカバーする単一製品すらなさそうで、自分が必要とするすべての地域となるとなおさら難しい。
      Quicken Classic は米国とカナダ専用。
      こうした選択肢、あるいは組み合わせればこの目的を合理的に達成できる複数の選択肢を知っているか気になる。
      取引データアクセス企業が、米国と EU の間の橋渡しを個人が直接使いやすい形では行っていないのを見ると、双方の官僚的な仕組みの非互換性のような理由があるのだと思う。
      あるいは、これほど国際的な生活をしている人が十分に多くないだけかもしれない。
  • GnuCash で事業を運営し、給与や 401k 口座 の管理などもしていた。
    安定していて、支出が限られる事業や帳簿担当の経験があるなら、費用の追跡にも十分だった。
    会計士に渡す貸借対照表と損益計算書を作成できた点は本当に良かった。