written: 2020-08-01 .. 2023-01-19

複式簿記システムの構築

[STEP 1] Google SpreadSheets に蓄積した仕訳を sqlite3 + CGI/Python で処理するシステムの確立

個人的に青色申告による複式簿記が必要なので、そのための必要十分なシステムを構築する。
（市販の会計ソフトは決して「必要十分」ではなく、単なる「十分」（つまり不必要な余計な要素を過剰に備えている）ので、論外。）

おおまかなイメージとしては：

• 逐次発生する会計イベントは人手によって「仕訳」してデータを入力し、1 年を通じてデータベース（仕訳帳）に蓄積する
• 年間の蓄積された仕訳帳に基く年度末の「総勘定元帳の集計」と「決算整理仕訳」と「損益計算書の作成」は、Python プログラムで自動化する。

具体的には：

• 仕訳帳は Google SpreadSheets を利用して家族で共有
• 集計・決算整理・損益計算は、Google SpreadSheets から TSV をダウンロードして、sqlite にインポートし、Python で SQL を操作してそれらの定型化された作業を行い、結果を複数の TSV としてアウトプットする。最後にそれら TSV を単一の .xlsx ファイルにマージして一つの総勘定元帳として得る。

スキーマの設計

データベースのスキーマは以下のような設計にする：

凡例：表名（列１の名前，列２の名前，……）
（※実線は主キーを表し、破線は外部キーを表す）

仕訳（id，伝票id，年月日，金額，借方科目，貸方科目，備考）

CREATE TABLE Journal (
	id         INTEGER PRIMARY KEY,
	voucher_id INTEGER,
	date       TEXT,
	amount     INTEGER,
	debit      TEXT,
	credit     TEXT,
	note       TEXT
);

伝票id は、一連の複合仕訳を識別するためのもので、データの入力時に、先頭のエントリーの id と同じ値を利用する（UI 機能として実装する）。値は特にそう（先頭エントリーの id）である必然性はないのだが、伝票id の列において、ある複合仕訳に所属する一連の仕訳のエントリーを他の複合仕訳から区別できることが担保されていればよい。単一仕訳の場合の伝票id の値は NULL とする。

また、複合仕訳の場合、それに所属する各エントリーの仕訳の相手方勘定科目は、「諸口」になる。

各勘定科目毎の元帳は、次のようにする：

元帳（id，年月日，摘要，仕訳id，金額，備考）

CREATE TABLE [勘定科目名] (
	id                INTEGER PRIMARY KEY,
	date              TEXT,
	particulars       TEXT,
	journal_reference INTEGER,
	amount            INTEGER,
	note              TEXT,
	FOREIGN KEY (journal_reference) REFERENCES Journal (id) ON DELETE CASCADE ON UPDATE CASCADE
);

借方、貸方の別は、金額の値に ± の区別をつけることで、＋（借方）、−（貸方）ということにする。

E-R 図は次のようになる：

基本的には以上だが、減価償却資産は、扱いがやや特別なので、次のように別個のものを用意する：

減価償却資産（名称，取得年月日，取得価額，耐用年数，償却率，本年中の償却月数，本年分の普通償却費，事業専用割合，本年分の必要経費算入額，未償却残高，摘要）

CREATE TABLE Depreciable_Asset (
	name                       TEXT PRIMARY KEY,
	date                       TEXT,
	acquisition_cost           INTEGER,
	useful_life                INTEGER,
	depreciation_rate          REAL,
	months_of_use_in_this_year INTEGER,
	gross_depreciation_amount  INTEGER,
	business_usage_proportion  REAL,
	net_depreciation_amount    INTEGER,
	residual_value             INTEGER,
	particulars                TEXT
);

仕訳帳と違って適宜更新するようなものではないので、Google Spreadsheets にする必要もなく、直接 TSV を作っても違いはない。

この表を基にして、その年度での減価償却費用を算出し、決算整理仕訳の処理の一環として組み込めばいいわけだ（👉 実装完了済）。

確定申告的には、上の処理は国税庁側のシステムが行うので、自前で用意したとしても二度手間になり、どうしても必要というほどのものでもないかもしれない。

[STEP 2] プロトタイプから完成版へ

1. Google SpreadSheets からは手動で journal.tsv をダウンロードする。
2. pptsv.py で TSV をプリプロセスする（日付や金額のフォーマットの修正）。
3. macOS 標準の sqlite3 コマンドを使って、accounting.sqlite ファイルに table を新規作成し、プリプロセスした journal.pp.tsv をインポートする。
   .mode tabs
   .import journal.pp.tsv Journal
4. Python 経由で上記データベースを処理して、決算整理仕分けを行ってデータベースをアップデートし、各勘定科目に分け、.tsv でエクスポートする（accounting.py）。
5. 勘定科目別にエクスポートされた .tsv を merge2xlsx.py で単一の 総勘定元帳.xls にマージする。

[STEP 3] Update

上記プロトタイプで、各処理を確立できたので、最終的に、accounting.py のみで TSV のプリプロセス以降（2 ~ 5）の処理を一挙に行えるようにコーディングし直して、一応の完成を見た。

1. Google SpreadSheets からは手動で journal.tsv をダウンロードする。
2. 上記ファイルを Python（accounting.py）で内部 sqlite データベースにインポートして処理し、決算整理仕分けを行ってデータベースをアップデートし、各勘定科目に分け、.tsv で一時ファイルにエクスポートし、それらの勘定科目別にエクスポートされた .tsv を merge2xlsx.py で単一の 総勘定元帳.xls にマージする（また、以下で「今後の課題」として挙げた減価償却資産に関する処理と出力 .tsv も、今ではマージできるようになっている）。

つまり、現時点（2021-02-13）において、残っている課題は Google SpreadSheets からのダウンロード作業（1 の部分）もプログラムに組み込むことくらいしか残っていない。（👉 2023-01-19 の時点でこれも実装し、さらにすべての処理を accounting.py に集約した）

<SQL>