2023年 6月 21日

会計システム Hieronymus(7)その後

2022年度の決算も終わりました

会計システム

ogochan

2022年度の決算も終わりました。

決算前後になるとHieronymusもいろいろいじられます。と言うか、いじらざるを得なくなります。

実のところ、そこそこ安定してしまっているので、決算作業中はせいぜい軽微なbug fix程度しかしてなかったのですが、その後にいろいろ機能追加を始めました。

せっかく作ったものなので、どこかの会計事務所とかと協業できないかなとか思ったりしています。

現在公開しているバージョン

現在公開しているmainブランチは、見掛け上は基本的にバグフィックスをしただけです。

内部的には、

Riotを全部Svelteに書き換えた
AdminLTEを廃止して、自前のスタイルにした

ところです。

RiotとSvelteを混ぜ書きすることはそれ自体は困難ではないのですが、似て非なるものが混在しているといろいろ面倒臭いものです。文化的にそれ程差異のあるものでもないので、思い切って全部Svelteにしてしまいました。見掛けで特に何がどうなったということはないのですが、ソースの管理は楽になりました。

AdminLTEの廃止は、基本的にNapierの時に作ったスタイルを適用しただけです。いつリリースするかわからないBootstrap5対応のAdminLTEを待って中途半端な状態にしておくよりは、諦めてしまった方が良かったですね。だいたいそのままで移行させたので、見掛けは変わっていません。

決算作業をしている途中では税理士から試算表の集計をつっこまれていたのですが、途中からなくなったところを見ると「正しいデータ」が入っていれば正しく出るのでしょう。この辺は私も税理士も決算処理を優先していたので、深く追っていません。

新電帳法に対応させているのは自分で使っていても便利で、伝票や領収書の管理が格段に楽になりました。弊社では紙の伝票は現在は「紙の証票をまとめるための台紙」として書いているようなものなので、電子データの時には書かないことにしました。まぁ、レシートやら紙の領収書(公共料金とかねぇ)がなくせないので、それの整理のためには紙の伝票も書くことになるのですが、伝票書きで死ぬということはなくなりました。

現在開発中のバージョン

決算が終わったあたりから、次のバージョンを作り始めました。mainとは別のブランチになっていますが、リポジトリの置き場は社内gitです。適当なところでGithubにブランチをpushするか、mainブランチにmergeしてしまうと思います。別に隠しておく必要はないんですが、いろいろねぇ。

以下は現在進行中のものです。

ユーザと権限の管理

立替金の精算の伝票は支払った人が入力してしまえば楽だなーと考えて、とりあえず私以外でも伝票入力が出来るようにということで、ユーザと権限の管理を追加しました。

自分一人でやっている分には、入力してしまえばそれで完了で良いですし、いつでも都合に合わせて伝票を修正したり削除したりが出来ても便利ではあっても不都合はないのですが、「他の人」ということを考えると、

操作権限
入力履歴
承認等のワークフロー

といったものが必須となるので、その辺のロジックを組み込んでいるところです。ユーザそのものは最初から複数持てたのですが、「全員root」みたいな状態なので、あまり良いとは言えないですよね。今のところトラッキングとか資格チェックとかは出来たので、あとは集計への反映とか、ワークフローでの警告(「承認の必要な伝票があります」的な表示とか)とかが出来れば完了です。

最終的には経費精算は専用の画面を用意して、後から事案とか単位でまとめて見れるとか、経費精算したら自動的に会計伝票を作るというような形にして、直接伝票を入力する必要がないようにしたいなと思っています。旅費精算とかだと、こうした方が後々わかりやすいですから。まぁこの辺は優先度低いんですが。

見積り請求処理

永年使っていたMS Accessの請求書システムのデータが、なんか部分的に壊れちゃったみたいな状態になってしまっています。今すぐに何がどうこうということはないのですが、これを機会に作ってしまおうかと考えています。今はテーブル定義とか作って、画面を作りかけているところです。

請求書を出すと、自動的に売掛金の計上やらしなきゃいけないですし、請求書自体を保存して閲覧可能にしておきたいとかは当然にあるので、そういった処理を組み込みます。売掛金の回収は預金通帳見ればわかるのですが、売掛金の計上自体を忘れるとか結構あるのです。別システムですから、そんなことはありますね。まぁすぐ気はつくんですけど。

実のところこれは別途そんなシステムを作ってAPIで連携とか思っていたのですが、なんだかんだ言って「バックオフィスシステム」としてまとまっている方が、弊社のような規模の会社ではやりやすいので、会計システムの拡張としてやっています。

ECサイトの在庫管理

今回の決算で一番面倒臭かったのが、いわゆる棚卸しに関する処理と、Amazonの売り上げの解釈です。

Amazonでショップをやったことがある人なら首もげるくらい納得してくれると思うのですが、Amazonからの精算の通知はとても難解です。特に、海外が絡んで(消費税がない)返品が絡んで... みたいなことになると、なかなか計算が合いません。税金計算のはしたとか、やる度に誤差が蓄積してしまったり。この辺実に面倒臭い。

また仕入は検品等を経て在庫となるわけですが、この辺の処理もとても面倒臭いです。

特にECサイトの運用は将来的には専用要員を確保するつもりでいるので、こういった面倒臭いことはなるべくシステムで解決しておきたいわけです。

これも別途そんなシステムを作ってAPI連携と思っていたのですが(以下同文

ここは私ではなくてmayumiが作っています。

将来

現在特にお客さんのいないシステムでしかないので、気ままに必要そうな機能を実装して行けば良いわけなんですが、それでも「次はこれ」といったロードマップ的なものは都度考えてやっています。と言うか、逆にお客さんがいないシステムなので、そうやっておかないと無限の時間を浪費しかねないですからね。

給与計算

バックオフィスの業務で欠けている大物は、給与計算ですね。

現在はExcelでまとめるだけで足りてしまっているので特に不自由はないのですが、それでも支給した時に別途伝票を入力しないといけないのは、面倒だけではなくて間違いの元です。とゆーか、たまに間違えてしまって次月に精算とかするハメになっています。やっぱり何とかしたいところですね。

給与計算はちゃんとしたシステムを作るのは決算処理をシステム化するのと同じくらい面倒臭い(年末調整がねぇ)のですが、決算処理も伝票入力して財務諸表が出来たら申告書類の作成とかは「よろ」と税理士に丸投げしているわけなので、給与計算も同じような前提でやる分にはそれ程大変ではありません。年末調整を自分で正確にやるのは面倒臭いですが、どうせ最後のところは税理士に依頼することを思えば、それを前提にシステム作っても良いと思っています。最後の数字だけ合っていれば良いわけで。

ということで、そういった緩い感じで給与計算を追加したいです。

経費計算

これは既に書いた通りです。経費の計算はそれ用のデータとして入れられると良いなということですね。

もっとも、これが必要な規模の会社になるかどうかの方が先の問題なのかも知れません。

顧客管理

これはまぁどこまでやるかって話に過ぎないのですが、請求書や見積書は顧客単位で整理されることになっているので、その延長でいろいろ入れて行けば良いなということです。

もっとも、弊社は直接そういったものを管理する「顧客」はあまりないので、そこまで重要ということもないのが残念です。せいぜい売掛金管理が出来ていれば良いのかも知れませんね。DMや年賀状を送るというようなこともありませんし。

その他

既に書いているように、今のところ利用者は自分達だけなので、それ程力の入ったシステムではありません。

とは言え、せっかく作ったものでもあるし、使えばそこそこ便利なものであることは自分達で感じているところなので、もうちょっとアウトリーチを目指しても良いんじゃないかと思っています。まぁそう思ったのでこのエントリを書いているわけですけど。今のところ、使いたいところがあれば、ある程度のお手伝いはします。

以前にもこのことは書いています。

会計システム Hieronymus(3) 弊社オープンソースの考え方と展開

この辺の考えは当時と変わっていません。ゴールもここで書いたことと同じですね。読み返さずに書いて同じことを書いてるということは、考えが変わってないとゆーことです。

これにつけ加えるとすると、この辺のことを一まとめにしてしまって、OrangePiを使った小さいアプライアンスサーバを作ってそれを提供するといったことが出来れば嬉しいかも知れないなということを考え始めたということです。Napierを使えば、オフィスの外から安全にバックオフィスシステムを使うこともできるわけです。ちなみに弊社は今はRaspberryPi4の上で動いてます。

まぁ繰り返しになりますが、弊社に会計のノウハウはありませんので、この辺のことに興味を感じた会計事務所とかと協業出来たら世の中のためになるなと思うところです。

ソフトウェア自体はAGPLを適用したオープンソースソフトウェアですので、勝手に使ってもらって構いませんし、それでビジネス始めてもとやかく言うこともありません。AGPLに従って下さいねというだけです。放っておいても決算頃には前年の版よりマシになっているはずですし、思い立ったら改良しているかも知れません。