Accessの修復

少し前のことになるのですが、Access2007で使用している販売管理プログラムが少しフォーム編集すると直ぐに落ちてしまうといった状態になってしまいました。「accdbファイルが壊れてしまったのかもしれない。ヤバイナー」
元々販売管理プログムラはAccess97で作成しました。それを2000、2003とバージョンを上げてその都度、mdbファイルを変換してきました。現在はAccess2007で、最初はしばらくmdbで使用していましたが、特に問題ないようだったのでaccdbファイルに変換しました。
変換後、レポートでラベルコントロールをテキストボックスコントロールに変換する時、必ずAccessが落ちてしまうので、Accessそのものにバグがあるのだろうと思っていました。そうこうするうちにフォームを編集する（テキストボックスを追加だったかした時に）と落ちてしまうようになりました。こうなると、もうどうにもなりません。何らか対処しなければなりません。
Accessが壊れた時の最終手段、空データベースに壊れただろうデータベースのテーブル、フォーム、レポートなどをドラッグしてコピーします。最初は何も考えずに、ナビゲーションウンドウの全てのオブジェクトを一度に空データベースにコピーしました。これだと、うまくいきませんでした。クエリーで参照しているテーブルがまだコピーされていないと、クエリーがうまくコピーされません。オブジェクトをコピーする際にも順番があるようです。最初にテーブルをコピーして、クエリー、レポートと順を追ってコピーしていきます。また、リンクテーブルはコピーすると元テーブルそのものを取り込んでしまうので、これは外部データからリンクを張り直してやらなければなりません。
一応、これでAccessが頻繁に落ちるという症状は治りました。
ただ、多少問題もあります。チェックボックスが小さくなってしまったフォームがいくつもありました。チェックボックスの大きさは一種類だと思っていましたが、Access2007純正コントロールだと一回り小さいチェックボックスが用意されているようで、大小二つのチェックボックスがあるようです。（ちなみに、クエリーデザインで使用されているチェックボックスが小さいチェックボックスです。）
フォームによってチェックボックスが大きかったり小さかったりするので、これを大きいチェックボックスに統一しました。
コピー前とコピー後で同じaccdbファイルでもタブコントールの色が白っぽく変わりました。

超漢字Ｖからデータベースを使う

特に必要というわけではないのですが、超漢字Ｖでデータベースを使おうと思った時どうすればよいか調べてみました。パーソナルメディアのホームページには「超漢字ソリューション for Oracle」が載っています。Oracleが使えるのなら、PostgreSQLも使えるのではないかと思い試験してみました。
WindowsならODBCドライバー経由でPostgreSQLに接続するのが簡単ですが、超漢字ではODBCという接続プロトコル自体が用意されていないので、接続はブラウザ経由になります。データベースをサーバーサイドスクリプトで表示してブラウザで表示、更新というかたちになります。
サーバーはWindowsXPでWindows版のPostgreSQL8.1をインストールして簡単なテーブルを定義します。ホームページはVisual Studio 2005を持っているので、Visual Web Developer 2005 を使用して作成しました。DetalisViewコントロールをODBC経由でlocalhostのPostgreSQLと連結してみます。とりあえず簡単そうな「挿入」だけクエリーを書いてみました。サーバーに使用するWindowsXPには超漢字Ｖはインストールしていません。
これをIISで公開して他のPCにインストールした超漢字Ｖから閲覧します。
囲碁棋士の元本因坊　王銘エン（左が「王」右が「宛」）のエンという字は、日本棋院のホームページでもカタカナになっています。これを超漢字Ｖから入力して表示されるかどうか調べてみます。
超漢字Ｖの「ブラウザ用紙」ではJISコードの漢字も表示できない（漢字を入力したレコードに移動するとエラーになってしまう）ので「Mozilla Firebird 0.7 for 超漢字」から試してみます。今度は表示されます。超漢字固有文字「エン」を入力してみます。入力可能です。また、レコードを移動して再表示してみても表示できます。PostgreSQLに超漢字固有文字の入力は可能なようです。
今度は超漢字ＶをインストールしたホストOSのWindowsXPから表示できるか確認してみました。ＩＥからもFireFoxからも「エン」が表示できます。試しに「エン」をコピーしてメモ帳にペーストして保存、開いてみると「？」になってしまいます。やはりWinodowsXPに登録がないフォントもブラウザ上では表示されるようです。超漢字ＶをインストールしていないPCから閲覧しても「エン」はちゃんと表示されます。
現在のPostgreSQLの最新バージョンは8.3ですが、あえて8.1を使用しました。というのは多分、超漢字固有コードはPostgreSQLではWindowsXPの外字と同じような扱いになるのではないかと思ったからです。以前、8.1のダンプデータを8.2にリストアしようとして失敗したことがありました。8.1ダンプデータに含まれた外字がPostgreSQLのEUC_JP<->UTF8の変換マップになかったためです。当然、超漢字固有文字は変換マップにありません。なので、多分リストアできない8.3より8.1の方が超漢字のデータを登録できる可能性が高いのではないかと思いました。PostgreSQLのような完成度の高いデータベースでバージョンが低い方が良いということはちょっと考えられないので、何らかオプションを設定すればこんな問題は解決できるようにも思いますが、あまり調べていないのではっきりしたことは言えません。

Access自分流 「資金繰り表」

特に作成しなければならない画面もなくなってしまったので、資金繰り表を作ることにしました。資金繰りは社長がやっているので、何をどいうふうに作れば良いのかよくわかりません。それでも何となく作っています。
資金繰り表は非常に難しいです。これまでの処理は全て確定したものの入力処理、集計処理でした。資金繰り表は違います。仮定を設定しながら見通しを立てていかなければなりません。

１．資金繰り表と一口に言ってみても何がわかるようにしなければならないか
自分でやったことがないので、よく考えてみました。ようするに倒産しないよう資金見通しが立てばよいのでしょう。支手決済ができるよう当座残高の見通しがたてば良いということだと思います。
当月の当座の動きは前月までの売上、仕入金額がわかっているのでほぼ正確に見通しを立てることができます。当月の入金、当月支払わなければならない金額。これは月初には確定金額として当然わかります。
なので、資金繰り表が対象とするのは翌月以降の当座の動きということになります。

２．何を仮定するか
まだ、未定の売上に対する入金、支払いを予想して当座残高の動きを検討するのですから、何かを仮定していかなければ予想しようがありません。それで下記ような手順で作業を進めていきました。
（１）当月売上金額と当月請求金額の比較
通常、売上予想する場合、当月の売上を予想します。しかし、入金予定表を作成する場合、対象となる金額は得意先に郵送した請求金額です。１５日締めの得意先であれば前月１６日から当月１５日の売上を請求します。なので、当月売上金額は当月請求金額と一致しません。入金予定表は請求金額を対象にしているので、当月入金予想も請求金額について考えることになります。
実際に比較してみるとやはり１割程度の差があります。が、仕方ないのでこの金額は一致するものと仮定します。
（２）当月仕入金額と仕入先からの請求金額の比較
売上金額と同様関係が仕入金額についてもあります。支払いは仕入先からの請求金額を支払います。当月仕入金額と仕入先から送られてくる当月請求金額計とは一致しません。
調べてみると、この差は売上金額の場合よりはなはだ異なっています。２割以上差がでてしまう月もありました。
これも仕方なく、一致するものと仮定します。
（３）当月売上金額に対する入金金種
次に当月売上した金額に対してどのような金種で何ヶ月後に入金するか調べてみました。これも月によってかなりまちまちですが、平均して金種割合を仮定しました。
（４）当月仕入金額に対する支払金種
売上対入金金種と同様に仕入対支払金種の金種割合を仮定しました。
（５）利益率
利益率は年間を通じて２％程度の差はありますが、従来から経営の指標にしていたので、まあ、通常このくらいという％は容易に仮定できます。

以上を仮定すれば、資金繰り表は作成可能です。仮定設定した項目まとめてみると、
・当月売上金額に対しての入金金種割合
・当月仕入金額に対しての支払金種割合
・利益率

これだけ設定してしまえば、当月、来月、再来月の売上金額を予想してやれば、資金繰り表が作成できます。

実際、作成してみると、入金は売上割引を差し引かれて翌月入金になるものも多い反面、まとまった買掛金の支払いは２ケ月後以降に決済するものがほとんどです。ということは翌々月の支払いについてはほぼ確定した数字が集計できるということになります。予想の主体は金種として翌月当座入金の金額予想です。

しかし実際、当座の見通しを立てるためにはこれだけでは不十分です。給与、納税といった経費の出金見通しが必要です。この辺りは昨年の仕訳データを使用しました。「当座」の相手勘定が「売掛金」、「買掛金」、「支払手形」など以外の経費分だけを取り出して当月の経費予測をしました。

以上の手順で資金繰り表を作ってはみたものの、かなり強引な仮定をしているので２割以上の差がでても全く不思議ではありません。これが使えるものか、これから検証してみるところです。
しかし、資金繰り表の作成方法としてこの方法以外思いつかないのですが、世間一般にはどんなふうにされているのでしょうか。２割の誤差が不思議でないとなると余裕をみて当座には月商の半分程度の残高を残しておかないと、不安ということになってしまいます。かなり荒い見通しになります。

もともと、資金繰り表を作成しようと思ったのは昨年１０月以降の不景気が原因しています。売上３割減が３ケ月続くと、売上サイトに対して支払サイトが３ケ月短ければ３割×３ケ月＝９割、約月商分の資金需要が瞬間的に必要になります。実際、そんな風になってしまうのかと思い資金繰り表を作成することにしました。調べてみると、支払いのサイト負担はさほどでもなく、安心しましたが、この程度の予想はできても良いではないかと思いました。