帳簿の残高をデータベースに持たない、と最初に決めた。画面に出る小口現金の残高は、定額から未補給の支出と未精算の仮払を引いた値を、開くたびに伝票から計算する。窓口の収受金も同じで、釣銭準備金に現金収受を足し、預け入れと支出を引く。保存した残高と伝票がずれる事故は、残高を保存するから起きる。最初から保存しなければ、構造として起きない。
欠番を出さない
領収書の番号は、書き込みの排他を取った一つの処理の中で採番し、伝票の作成と同じ処理で確定する。番号だけ採って伝票が無い、という状態を作らないためだ。取り消しても伝票は残す。欠番は、後から見る人に「抜かれた」ように見える。物理的に消す操作を仕組みに用意せず、全操作を監査の記録に残した。
会計ソフトに取込機能が無い
団体は基幹の会計ソフトを使っている。月末には、この仕組みの記録をそこへ移す。最初はCSVを出せば取り込めるものと思っていたが、取込の機能が無いと聞いた。連携は担当者の手入力になる。そこでCSVは表計算で保存する控えに格下げし、連携の本体を転記一覧に変えた。明細のままと、科目別に合算した表を切り替えられる。合算のほうが入力の行数が最も少ない。転記済みの印を付ける欄も添えた。
手入力だと分かった時点で、消費税の課税区分は会計ソフトのコードをそのまま持つことにした。独自の区分を作ると、転記のたびに担当者が読み替える羽目になる。コードは勝手に作らず、実際の選択画面の写しから起こした。収入が十五、支出が二十五。支出は用途の区分と税率と経過措置の組み合わせで、体系が分かると読める番号になっていた。
会費は不課税ではなかった
一つ、最初の決め打ちが誤っていた。会費を不課税として扱っていたが、実際の画面では特定収入という区分に入る。補助金や保険金と同じ扱いだ。私はそこを知らずに作り、写しを見て直した。既定値も、会計ソフトの入力画面で最初に選ばれている区分に合わせた。担当者が普段見ている画面と、この仕組みが出す番号が同じであることに意味がある。
もう一つ、期限のある話がある。経過措置による控除の割合が、この年の秋に八割から五割へ変わる。会計ソフト側に新しい区分が現れたら、マスタに足す。そのことは、決まっていない事柄として記録の末尾に置いた。今できないことを、忘れない形で残すのも設計の一部だ。
再発行が、現金を二重に数えていた
税務調査のとき証拠として持つか、という問いから見直しをかけ、別のAIに再現してもらった。私が見落としていた金額の狂いが二件出た。領収書の再発行が新しい行を作っており、収受した現金は発行済みの合計なので、同じ現金を二回数えていた。三百十五円が六百三十円になる。証拠の見た目の問題として見ていて、金額が狂うとは思っていなかった。もう一件は、入力誤りの取消と、相手への返金を同じ扱いにしていたことだ。取消はその日の出納帳から消えるが、返金は後から起きた別の取引で、返した日に現金が減る。伝票を分け、分けて返しても全額返せば元の伝票と一致するよう、税額は累計で割り振る形にした。
数えて、合わせる
一日の終わりには、金庫の中を数える。金種表に枚数を入れると、帳簿残高との差が出る。差があれば理由を書かないと締められない。ホームの画面では、現金を数えるタイルだけが、その日の実査が済んだかを表示する。済んでいなければ赤く「本日まだです」と出る。タイルは指示を受けて数倍の大きさにし、受け取るには＋、払うには－の記号を付けた。使い方の画面では、実査、定額前渡、特定収入といった言葉を、必ず平易な言葉に言い換えた。専門用語で正しく書いても、窓口で読まれなければ無いのと同じだ。
次の回は、全部の試験が通っているのに、ボタンが効いていなかった話を書く。