元帳SMB
元帳SMB
開発者元帳SMB
初回リリース2006年9月6日 （2006年9月6日）
安定版リリース
1.13.2 / 2025年12月21日 ( 2025-12-21 )
リポジトリgithub .com /ledgersmb /LedgerSMB
書かれたPerl、PL/pgSQL、JavaScript
オペレーティング·システムUnix系、Mac OS、Windows、Android
プラットフォームクロスプラットフォーム
入手可能な英語、ノルウェー語、オランダ語、ドイツ語、ハンガリー語、エストニア語、マレー語、デンマーク語、ロシア語、...
タイプ会計、ERP、CRM
ライセンスGPL-2.0以降[ 1 ]
Webサイト元帳mb.org

LedgerSMBは、中小企業（自営業）に必要な機能に特化した、無料ソフトウェアの複式簿記および企業資源計画（ERP）システムです。数百万行の仕訳帳を持つ企業にも安心してご利用いただけます。 [ 2 ] 会計データは無料で利用できるデータベースサーバー（PostgreSQL）に保存され、標準的なWebブラウザをユーザーインターフェースとして使用できます。このソフトウェアは、ローカルホスティングだけでなく、様々なパブリッククラウドプロバイダーでも利用できます。複数のプロバイダーから商用サポートを受けることができます。[ 3 ]

LedgerSMB は、GPL 2.0 以降のライセンスの条件に基づいて配布されます。

特徴

LedgerSMBの機能

  • 複数通貨をサポートする完全な総勘定元帳。
  • 売掛金および買掛金、未払金および経過期間レポート。
  • プロジェクト会計およびその他の柔軟な会計次元。
  • 複数期間の比較を含む財務報告書:
    • 損益計算書（損益報告書）
    • 貸借対照表
    • 試算表。
  • 見積もりと注文管理。
  • 時間追跡。
  • 請求書発行機能（郵送、印刷）、請求書は次の基準に基づいて作成されます。
    • 注文（見積りに基づく場合もあります）
    • 出荷
    • タイムカード。
  • 在庫追跡と活動レポート。
  • 固定資産。
  • 請求書と総勘定元帳取引の職務の完全な分離。

LedgerSMBは、複数の通貨、複数の売上税率またはVAT税率、そしてユーザーごとの言語とロケール（数値書式）設定をサポートしています。また、顧客ごとの言語設定もサポートしているため、請求書を印刷時に複数の言語に翻訳できます。さらに、言語ごとの請求書テンプレートもオプションで用意されています。

リリース

LedgerSMBのバージョン番号は1.xyという形式で、新機能を含む毎年秋のリリースでは「x」が、バグ修正では「y」が加算されます。変更履歴の全文はこちらをご覧ください。過去2回の年次リリースではコミュニティサポートが提供されています。

1.12.0は、2024年12月14日にリリースされ、様々な内部的な改善と修正が行われました。ユーザーに見える変更点としては、配送先住所の「At the attention of」（Attn）のサポート、外部テンプレートレンダリングエンジンのサポート、新しい（試験的な）注文・見積WebサービスAPI、売掛金および買掛金取引の取引履歴などがあります。

1.11.0（サポート終了）は、2023年10月3日に、内部的な改善と修正を幅広く含んだバージョンとしてリリースされました。ユーザーにとって目に見える変更点としては、請求書へのバーコード入力のサポート追加、負の（流動）資産の負債への再分類、および逆仕訳済み取引と逆仕訳中の取引の関係の追跡機能などがあります。

1.10.0（サポート終了）は、2022年10月8日にリリースされ、幅広い改善と修正が行われました。このリリースでは、ユーザーにとって目に見える小さな変更が多数行われました。大きな変更は技術面で、UIの一部をVue3に移行し、Vue3ベースのUIをサポートするWebサービスを導入しました。

1.9.0（サポート終了）は2021年9月24日にリリースされ、AR/AP経過報告をメールで送信する機能（1.3.42でリグレッションした）の修復を含む、幅広い改善と修正が行われました。以前のリリースでは中心的なテーマや特別な焦点がありましたが、今回のリリースはコードベースのあらゆる部分に触れる、より包括的なクリーンアップリリースとなっています。

1.8.0（サポート終了）は、2020年9月4日にリリースされ、様々な改善と修正が行われました。この点において、このリリースは、特定の機能領域の改善を目指した1.5から1.7までのテーマ別リリースとは異なります。このリリースにおける主な変更点としては、コンテナイメージのサポート強化（印刷文書へのロゴ掲載用）により、ディスクではなくデータベースに保存できるようになったこと、標準コンテナの使用が可能になったこと、そして決済を一元管理できるようになったことが挙げられます。これまで決済データは取引データから取得されていましたが、このリリースではすべての決済を個別のデータ項目として保存することで、照合処理のエクスペリエンスが大幅に向上しました。

1.7.0（サポート終了）は2019年10月4日にリリースされました。外貨取引のサポート強化、大幅なコードクリーンアップ、そしてさらなるテストが実施されました。1.7.0リリースでも、プロジェクトはマイナーリリース（.0）間のサイクルを短縮するという傾向を継続しています。

1.6.0 (サポート終了) は、安定性と将来を構築するためのコード ベースに重点を置いた変更ログとともに 2018 年 6 月 10 日にリリースされました。

1.5.0 (サポート終了) は、安定性とユーザー エクスペリエンスに重点を置いた変更ログとともに 2016 年 12 月 24 日にリリースされました。

1.4.0 (サポート終了) は、さらに大きな変更ログとともに 2014 年 9 月 15 日にリリースされました。

1.3.0 (サポート終了) リリースは 2011 年 10 月 11 日にリリースされ、かなりの変更ログが含まれており、主にパフォーマンス、職務の分離、および 1.2 の (設計) 問題の修正に重点が置かれています。

1.2.0 (サポート終了) リリース (2007 年 4 月 6 日に発表) には、多数の非常に深刻なセキュリティ修正と、リファクタリング プロセスの開始が含まれていました。税金と価格のマトリックス コードは集中管理されていました。このリリースには大きな問題があり、コア チームは新旧のコードの統合に関する多くの問題のため、最終的に 1.2.0 と 1.2.1 を一般配布から引き上げました。コア チームのメンバーの多くが問題の深刻さに不満を表明しましたが、Chris Travers は概ねこれらの問題を Apache 2.0 [ 4 ]の問題になぞらえています。Apache 2.0では、アーキテクチャの変更によって問題のあるリリースが発生しました。1.2.x はおそらく史上最も困難で問題の多いリリースになるだろうというのが一般的な期待です。同時に、1.2.0 で発生した多くの問題は、十分なレビューを行わないまま急いで多くのことを行おうとしたことが原因であることは否定できません。

1.1.0（サポート終了）リリースでは、他のお客様向けに行われた多くのパッチがマージされましたが、コード構造に大きな変更はありませんでした。しかし、この時点でコアメンバーの大半は現在のアーキテクチャに満足しておらず、コードのリファクタリングに取り組むことを決定していました。

最初のリリース（2006年9月6日の1.0.0 [ 5 ]）とそれに至るまでの出来事については、「履歴」セクションで説明されています。

1.5以上の開発

1.5以降、開発はバックエンドのWebサービスにアクセスできる、より高機能な（ブラウザベースの）クライアントへと移行する方向に進んでいます。そのため、1.5のUIはシングルページWebアプリケーションとして実現されています。その結果、（はるかに）レスポンシブなエクスペリエンスが実現し、見た目もよりモダンになり、フロントエンドとバックエンドのより根本的な分離の基盤が構築されます。1.5の開発サイクルを通じて、品質保証対策の開発に多大な労力が費やされ、今後も引き続き注力していきます。

1.3+の開発

1.3 より前のバージョンでは、コードベースに数多くの課題がありました。例えば、Perl コードは文字列連結と文字列出力のページスニペットを組み合わせて HTML を作成し、データベースクエリとウェブページの両方を生成していました。これは確かにうまく機能していましたが、インターフェースの変更が非常に困難で、他の言語で書かれたプロジェクトとの相互運用性も特に困難でした。さらに、ほとんどの状態はグローバル変数に保存されており、これらの変数は頻繁に変更されるため、コードを変更するたびに予期せぬ結果が生じるという問題もありました。

これらの課題に直面したLedgerSMBチームは、ユーザーインターフェースにテンプレートのサポートを追加し、すべてのデータベース呼び出しをストアドプロシージャに移行することで、これらの問題に対処する新しいアーキテクチャを開発しました。構造的にはモデル・ビュー・コントローラ（MVC）によく似ていますが、他のMVC実装と全く同じ方法で分解されているわけではありません。[ 6 ]

全体的な設計上の考慮事項には、LedgerSMBロジックへのアクセスに複数のプログラミング言語をクロスプラットフォームで使用でき、これらのアプリケーション全体でセキュリティが一貫して適用されるようにするという要望が含まれていました。そのため、LedgerSMBチームはSQLに典型的な「1つのデータベース、複数のアプリケーション」環境を構想しました。全体的なアプローチでは、PostgreSQLのロール（アプリケーションユーザーはデータベースユーザーであり、ロールが割り当てられている）を多用しています。新しいコード（1.3以降で追加）のデータベースロジックへのアクセスは、名前付きクエリのように動作するストアドプロシージャを介して行われます。権限は、基礎となるリレーションまたはストアドプロシージャに対して付与される場合があります。ストアドプロシージャはセマンティックな引数名を持ち、オブジェクトプロパティの自動マッピングを可能にします。これらのプロパティは、比較的軽量なラッパーを介してPerlコードに公開されます。ユーザーインターフェースコードは、LaTeX、CSVファイル、Excel、Open DocumentなどからPDFを生成する際にも使用されるTemplate Toolkitをラップしています。ワークフローは、比較的軽量なPerlスクリプトによって処理されます。

歴史

このプロジェクトは、SQL-Ledgerのフォークとして始まりました。SQL-Ledgerのセキュリティバグへの対応に不満を抱いたChris TraversがChristopher Murtaghと協力し、CVE -2006-4244の修正を行いました。[ 7 ]このバグは、Chrisがパッチを作成する数ヶ月前[ 8 ]に、SQL-Ledgerの作者であるDieter Simaderに報告されていたようです。LedgerSMBの最初のリリースと、メインのメーリングリストでのバグの全面的な開示により、[ 9 ] SQL-Ledgerの支持者と初期のLedgerSMBプロジェクトのメンバーとの関係が緊張しました。

参照

参考文献

「 https://en.wikipedia.org/w/index.php?title=LedgerSMB&oldid=1329886370」から取得