経理の仕事について

販売管理プログラムを作成して思うのは、経理の仕事は電算化することで相当減らせるということす。

経理で扱うのは、ほとんど集計数字です。元々は売上明細だったり、仕入明細だったりしますが、100明細あろうが、1000明細あろうが、月計は１個だけです。もちろん、得意先別に集計しなければならない場合もあり、全明細の集計であったりするので、ケースバイケースですが、明細行の多少はプログラム的には関係ありません。
結局、集計をタイミングよく（期間を考慮しながら）行うだけです。今回、作成した販売管理プログラムでは下記のようなメニューを作りました。

入金予定表
支払予定表
当座入出金表
相殺表
手持手形推移表
受取手形推移表
裏書手形推移表
割引手形推移表
支払手形推移表

このうち、相殺表以下は通常の販売管理プログラムにはあまり含まれないものだと思います。
これらの表の元データは販売管理プログラム中で入力するので、当然作成可能です。もちろん、作表のために得意先マスター、仕入先マスターにそれ用のフィールドを用意しなければなりませんし専用テーブルも必要ですが。
入金予定表、支払予定表は一般の販売管理プログラムでもあると思いますが、相殺表はどうでしょうか？　あまり無いのではないかと思います。自作すればこそです。
入金予定表、支払予定表があれば、相殺表はできます。入金予定表、支払予定表、相殺表ができれば、後は支払手形データがあれば、販売管理にかかわる当座の動きを知ることがでいます。実際には、売掛買掛に関係しない経費の支払いが発生するので、それも加味しなければなりません。作成した、販売管理プログラムでは経費フラグを仕入マスターに作成し、経費分の入力も行っています。当座入出金表はその経費分の支払予定も上がってきます。仕入計算の場合は、経費フラグの立った仕入先は計算から除外します。

手形計算は非常に簡単です。手形の場合は、倒産でもない限り修正になることはありません。ただ、多少、工夫が必要なのは、銀行非営業日の扱いだけです。決算月最終日が土日の場合は、その日に決済予定の手形はその年度ではその手形は未決済になります。決済は直後の銀行営業日になります。手形記載の満期日で計算してしまうと当座残高、「当座預金」「受取手形」に不整合が起こってしまいます。そのため、銀行休日マスターを作成して、日付の調整を行います。
また、入金伝票入力時に受取手形データを作成、支払伝票入力時には支払手形データを作成、裏書手形での支払い時に受取手形データにその顛末を追加します。割引手形計算も販売管理プログラムで行います。そのデータも受取手形顛末として追加します。
これさえできてしまうと、それまで半日かかっていた手形計算が３分で終わってしまいます。
（それまで、記帳した補助簿の金額を手計算していました。Excelさえ使用していませんでした。ひどいでしょ！）
後は集計した、受取手形、裏書手形、割引手形の仕分けをするだけです。

経理の仕事は電算化に向いています。実際これで、仕事量は随分減りました。
経理電算化の目的は「正確な決算と人減らし」これにつきると思います。

給与計算について

日常、仕事は主として経理をしています。給与計算は昨年から担当することになりました。

前担当者は給与計算をExcelで行っていましたが、あまり面倒だったのでAccessで給与計算ソフトを作成しました。市販のソフトを使用してもよかったのですが、せいぜい１８人程度の給与計算にソフトを購入するのはもったいなかったのと、給与計算は健康保険、厚生年金保険などの保険料が変更になればソフトも更新せねばならず、年間メンテナンスを継続的に支払わなければならないので、それも嫌でした。

給与計算ソフトは販売管理ソフトと比較すると、量も少なく比較的簡単です。大体３ケ月くらいでほぼ製作が終わりました。難しいのは保険料変更にどのように対応するかということでした。自作の場合は実際どうにでも変更可能ですが、それでも時間が経つとプログラムの構成を忘れてしまうので、修正は結構、面倒です。できれば簡単に保険料変更に対応したいものです。
Access97で書きましたが、適用計算表をその都度インポートすることで対応しました。適用年月を含んだテーブル名にして、毎月計算に使用するテーブル名を検索することにしました。

実際、昨年、厚生年金保険料の変更が２度ありました。また、一昨年（？）は４０歳以上を対象にして介護料が加わりました。今年、４月からは雇用保険料の改定があります。今回、プログラムを作成するまで、社会保険料、所得税といったことはあまり興味もなく、よく知らなかったのですが、よくこんなに徴収できるなと思います。しかも年々料金が上がっており、天上知らずといった様相を呈しています。就職したての頃、定昇時期になると、給料が増えて嬉しかったですが、手取り金額は額面金額の半分程度しか増えないので、「ひどいもんだな！」と思いましたが、こんな社会保険料が多ければ当然です。
所得税にいたっては、定額減税が来年には完全になくなってしまいますし、各種控除が無くなりす。昨年は配偶者控除が無くなり、一昨年と比較すると、随分、年末調整での戻り金額は減りましたが、来年はむしろ支払いの人が多くなるのではないかと思います。
今年は老年者控除が無くなります。５０万円の控除です。６５歳以上で仕事をしている人はこの控除の適用はなくなります。高齢者は仕事そのものを見つけるのが大変なのに、その上、控除まで無くしてしまうなんて国は何を考えているのでしょう。

財政再建のためには、税収を増やすことは当然必要なことと思います。これだけ、国民の負担を増やすのなら、政治家自身がもっと襟を正すべきだと思います。
いつも思うのですが、政治家が全く尊敬を集められない社会はどこか病んでいます。それもこれも政治と金が原因です。政治資金がらみの汚い話が多すぎます。また、それを指摘する野党の姿勢もうんざりです。いつも、いつも予算委員会で自民党の政治資金の不正を取り上げるばかりで、もっと前向きの姿勢で検討できないのでしょうか。
（本当に、不正を無くす気があるのかよ！また、審議拒否とはどういうことだ、おまえら給料もらってるんだろ、チャント審議しろよ！　それが仕事だろ。）

あっさり、「企業献金を廃止して、全ての政治資金を税金から支払う。」という話が何ででないでしょうか？　税金から支払えば、その責任は重大です。もし、不正があればどんな場合でも政治生命は失われるでしょう。しかし、政治家からすれば、元々さしてやりたくもないだろう（？）政治資金集めから開放されるでしょうし、政治に専念できます。また、そんな政治家なら国民から尊敬されます。そういうことは政治家自身がわかっているはずですが、それでも企業献金全廃といった話が与党はもちろん、野党からさえもでないことが、政治家を信用できない第一の理由です。
以前、宮沢喜一が総理だった頃、企業献金廃止が議論されたことがありましたが、宮沢喜一が「企業も社会的存在ですから、」企業献金を廃止することはできない、といった答弁をしたのを良く覚えています。宮沢喜一は非常にクリーンな政治家だと思いますが、その宮沢さんでさえこんなものかと思うとがっかりしてしまいました。
あー、頭にくる。

税金の話になると、大きく話がそれてしまいました。

PostgreSQLについて

今回、データベースはPostgreSQLを使用させてもらいました。
(ありがとうございます！)

もし、クライアントが２台以上あるなら、クライアント・サーバー型のデータベース構造にすべきです。(最近は３層構造なるものもあるようですが、良く知りません。) 私は、クライアントはAccessを使用してプログラムを作成していますが、Accessをデータベースとして使用しているわけではありません。給与計算ソフトはAccessをデータベースとして使用していますが、これは自分しか使用しないので特にクライアント・サーバー型にする必要はないと思っているからです。明細行も20人程度なので、月々20明細増える程度です。この程度ならAccessをデータベースとしても問題ないと思います。

PostgreSQLがなかったら自作はありえませんでした。以前はBtrieveを使用していたのですが、Btrieveと比べると多少重いかもしれませんが、非常に使い易いです。

「PostgreSQL完全攻略ガイド 石井達夫著」がよかったのか、セッティング、テーブルの作成変更、データのインポートなど非常に簡単でした。
BtrieveからPostgreSQLへのデータの移行はTakeMagic～Excel～Access+ODBCで行いました。まあ簡単です。

バックアップするにしても、Btrieveの時はサーバーにあるファイルごとバックアップをとっていました。(他にも方法があったのかもしれませんが、外注したベンダーからは「ファイルまるごとコピー」の方法しか教わりませんでした。)
PostgreSQLの場合はpg_dump というダンプコマンドからテキストファイルにしてバックアップをとります。バージョンアップの際もこのダンプデータをリストアすることで行います。作業的には簡単です。しかも、ダンプ時にロックがかかりません。ファイルまるごとコピーの場合はその間、データにアクセスするクライアントがあると、コピーは失敗してしまいます。
Btrieveの時は最終的にファイルの大きさが300MByteくらいありましたが(プログラムも含めて)、バックアップは結構大変な作業でした。挙げ句のはてに、コピー時にデータを失い、前日のデータに戻って改めてその日のデータを打ち直しすることが２回位ありました。データを失うというトラブルはその時しかありませんでした。安全のためにデータを保存する作業中にデータを失ってしまうという、愚にもつかないことです。
PostgreSQLの場合はそういったことは全くありません。よく、「PostgreSQLはWeb用と考えた方が良い。」なんていうのを雑誌でみますが、Webのようにクライアントが非常に多くても使用に耐えるわけで、クライアント10台、20台なんてわけなく処理する高性能データベースという捉え方が正しいのではないかと思います。Btrieveの時のデータを移管して、１年間分のデータが加わって今、104MByteあります。この位のデータなら最近はフラッシュメモリーでバックアップがとれます。
(実は、昨年の台風まではネットワークドライブだけにコピーをとり、フラッシュメモリーへのバックアップはとらなかったのですが、台風の時、停電、雨漏りでPCそのものを失ってしまいそうになり、フラッシュメモリーにもバックアップをとることにしました。アー恐ろし！)

PostgreSQLをインストールして使用の際にはチューニングは必須です。デフォルトは搭載しているメモリがかなり少なくても動作するような設定になっています。ソートでは使用するメモリ領域が広いほど速度が上がりますが、デフォルトでは大抵の場合、搭載したメモリが有効活用されていません。しっかりメモリを使いきるためにチューニングが必要です。
石井先生の「PostgreSQL完全攻略ガイド改訂第3版」でチューニングは一番後ろの方にあるので、見落としがちですが、これはどうしてもやらなければならないことです。私の場合、設定を変更することで、ソートなどは３倍程度速くなりました。
私が使用しているのはVer.7.3.5なのですが、postgresql.confの下記の項目を設定しました。
max_connections
shared_buffers
sort_mem
最近でたVer.8.0では名称が変わりました。
また、カーネルの設定変更も必要です。/etc/sysctl.conf で
shmall
shmmax
を設定し直しました。
詳しくはgooで検索してみるなり、マニュアルを見るなりしてください。

また、性能を維持するために定期的なvacuumが必要です。私の場合、週１回、psql から vacuum full; しています。
(削除された領域を再利用するためにはreindexしなければなりませんが、実際にはほとんど削除しないので、今のところreindexはしたことがありません。)

Accessのバージョンアップ

バージョンアップということからAccessの使用を考えてみると。

１．現在、クライアントとしてのAccessのフログラムサイズは73MByteあります。非常に大きいと思います。Access97ですが、途中Access2000にバージョンアップしようと思いコンバートしたことがありましたが、途中でエラーを吐いて止まってしまうので、バージョンアップはあきらめました。使用しているPCにVisualBasic4もインストールしているので、VisualBasicの関数を知らず知らず使ってしまっているのだと思います。(実際、VisualBasic4をインストールしていないPCでは動きませんでした。)
それが原因してるのかどうかハッキリしませんが、とにかくコンバートが通らない。
この問題は、今後、64OSを使用する際に尾を引きそうで今から、頭が痛いです。
期待通り、64OSでAccess97が動けばよし、だめなら、Accessのバージョンアップをしなければなりません。アーイヤダ。

２．Accessそのもののバージョンアップは難しいのですが、データベースPostgreSQLのバージョンアップは比較的簡単です。少なくとも対応するODBCドライバーがありさえすれば、プログラムは何ら変更ありません。リンクテーブルを使用しているので、リンクを取り直してやるだけです。
新しい、バージョンのODBCドライバーを使用するとテーブル名の頭に「public_」が付いてしまうですが、一度リンクしたら、後はさわる必要がないので、必要になったらまあ、がまんして「public_」を外してリンクしていくつもりです。
動作が遅いODBCドライバーを使用しましたが、ことPostgreSQLのバージョンアップということになると、ODBCドライバー+リンクテーブルは悪い選択ではなかったと思います。
これが、nativeドライバーを使用していたらこうはいきません。
やったことはないのですが、多分、フォームに貼り付けたnativeドライバーのコントロールを一個一向新しいものに変更していき、コントロールのメソッドの使用方法が異なれば、コードそのものを変更しなければなりません。まあ、実際にはそんな作業はできないでしょうから、PostgreSQLのバージョンアップは無理ということになります。

10年先(2)

一応、20年は無理かもしれませんが、15年は何とかなるのではと、取らぬ狸の皮算用。

買い替えスケジュール

2005年～2010年 現在のPCの継続使用
2010年 64ビットOSへの切替え(おかしくなるまでは使うけどね)
2015年 最後の64ビットOSバージョンへ切替え(在庫処分品を安値で購入)
2015年～2020年 巷では128ビットOSの切替えが進行！？

この予定で2020年まではいけるのではないかと期待しているのですが。
(だましだましで2025年までは何とかなるか！？)

64ビットOSの間はWin32APIが破棄されることはないでしょうから、Access97がLonghorn移行の64ビットOSで動作する可能性はかなりあると思います。128ビットOSではWin32APIは破棄されるでしょうから、128ビットOSの発売直前ないしは、64ビットOSの発売が中止になりそうな頃、最後の買い替えをすれば、その後、５年は大丈夫。

実はこの頃(2025年頃)、定年で20年先移行のことは考えなくてもよいのです。
めでたし、めでたし。


(良く考えてみると、Access97にWin16APIが含まれていない保証はないですよね？)