ちょっとしたバグを発見しました。消込検索後の（複数候補による）組合せ検索において、諸入金伝票に対する各候補数が、たまたま一致してしまうと前処理の対象外となってしまいます。まぁ、前処理というのは飽くまで処理スピードを向上させるためのものであり、なくても処理結果には影響がないハズですが...
●バグフィックス
- 組合せ検索時、前処理が正常に行われないことがあるバグを修正
とりあえず実害はないハズなので、敢えて公開版の差し替えは行いません。つか、今回ひさびさにこの組合せ検索を使ってみたら、えらく使いづらいな〜(^^)。せめて、検索結果で該当するものが皆無だったときは、候補欄は消さずに元に戻すぐらいはした方がいいかな。
DLレポート、チョット遅れ気味で今日やっと届いたんだけど、イキナリVer. 1.11.00版の報告になってた。いつもだったら改版前の最終総数も知らされてたのに... ま、どうせそんな大した数でもないだろけどサ(T_T)。
- 元帳データ取込時、データが複数ない場合にエラーとなるバグを修正
- 元帳データのファイル名がデフォルト以外のとき、エラーとなるバグを修正
- 伝票レンジにデータを追加した直後、手動消込が誤動作するバグを修正
- 印刷時、消込経過確認レンジを印刷しないように変更
印刷対象は伝票レンジのみとしました。そのため印刷（およびプレビュー）を行った際に、消込経過レンジが自動的に非表示となります。これは、一旦他のシート（設定シート等）を選択し、再度そのシートを選択し直すことで表示されるようになります。手動で再表示させる必要はありません(^^)。マニュアルに説明文を設けましたのでそちらもご確認ください。【注】 公開版としては本バージョンから、印刷を前提としてレイアウトに若干の変更を行っています。この経緯については、こちらをご参照ください。
- カンマ区切り以外の元帳データファイル形式に対応
- 元帳データファイルの年設定について、西暦/和暦を自動認識するように拡張
ver. 1.10.00のときにゆってた、「配布前提のソフトに対する作りこみ」の部分、まぁ〜ったく考慮されてません... ゴメンナサイ(_ _)。今回も、飽くまでマイナーアップデートにとどまってイマス...
●イマイチかも...
ところで、コレでようやく印刷対応版をお届けできた訳ですが、自分的にはこの印刷結果、まだまだ満足いくものにはなっていません。というのも印刷されたものを見ると、消込の番号（セルの行番号を使っています）が直感的になんのことかわかりづらいと思ってます。ただ... これまた自分的には、前にも申し上げたとおり、印刷することはホトンドないため、使いづらいことに対する無頓着さがどうしてもあるのです（ま、いっかって...^^;;）。
●ご意見求む！
一応こんな風な方がいいのかなぁと思われるポイントとしては以下のようなものが思いつきます。
- 印刷の場合は、消込番号をアルファベットにする。
←イキナリ数字がならんでいても、伝票番号等との違いが一見して理解しづらいのではないかと思っています。ただし、通常使用時（実際に消込作業を行うとき）は、セルの行番号そのままの方が対応を追いやすいのではないかと考えており、印刷時だけの対応という点がちょっとメンドウなのです(^^)。 - 印刷時に非表示にするのはいいとして、復帰が自動でないのはいかがなものか
←コーディング上の手抜きによるもの(^^;;)。都度行数が違う印刷対象に対して、印刷範囲を設定するより、いらないところ（経過欄）を表示にして全部を印刷した方がラクだったのデス(^^;;)。これも作者があまり印刷しないので、たまにチョット煩わしいぐらいは許されるかな...と(^^;;;)。 - 印刷された伝票レンジの表が、単なる枠取りだけで見づらい
←色やパターンを設定した方が見やすいだろうなとは思うんですが...
...いかがでしょう？度合いの差こそあれ、いずれも手を抜きたい作者の怠慢で実装していないモノです(^^;)。印刷したものを見るのは（消込作業者でなく）全く別のヒトと考えると、今のままでは問題なのかなぁという気だけはしている、という状態です。実際に使ってみてどうかという、生の声がゼヒいただきたいのですが...(_ _)
弥生販売のデータを取り込む際、「カンマ区切り」で、かつ「年号が和暦」のデータしかサポートしていません。ボチボチ拡張していこうかとは思いますが... 例によって作者は不便を感じないし、要望があるわけでなし...（いじいじ）
ボチボチ新ネタを... と言いたいところだが、このヒトツキ、まーったくナンモいじってませーん。
断っとくが「終息」ではないので念のため(^^)。うーむ、1.10.00を公開すべきか否か。
今日ベクターからダウンロード数の連絡があった。どう解釈したものかチトとまどうのだが、この『BF消込』の方は、『元帳印刷』にあった既存ユーザによると思われるダウンロード数の跳ね上がりがナイ。うーむ。
●もしかして
『BF消込』って、ダウンロードはされても使われてないってことか？だからアップグレードの必要なんかないと？ガーン。しくしく(T_T)。これまた発信側に立って初めてわかる、無反応に対する絶望感... お願いだからナンか感想クダサイよ〜。
昨日、リンクに追加したサイト『Excelでお仕事！』であるが、そもそものところはナニかの役に立つこともあるかな、程度の気持ちだった。しかし、Excelベースのソフトを配布するにあたっての留意点のホンのとっかかりを少し読んでみただけでもイキナリ頬を張られたような衝撃である。
●印刷なんて考慮してませんでした
曰く「ページ設定は必ず行う。印刷目的でないことが明確なら別ですが、配布を受けた人が印刷しないとは限りません」。ガビーン(^^)。拙作の『BF入金消込』は、印刷を目的とはしていない。清書でなく処理が目的のシステムだからだ。事実ワタシはこのシートから印刷をかけたことなど一度もない。
●とは言うものの
そこが「配布」前提のソフトと、そうでないソフトの違いであろう。確かにワタシは印刷の必要はないと思う。しかしそれはワタシが弥生販売と組み合わせて使っているからだ。弥生と何の関係もなく、純粋にコレのみで消込帳票として使うヒトがいるかもしれない。となれば、シートの印刷機能は必要ではないか。
●でも公開はしないモンね(^^)
他に使うヒトがいるかもしれないから、と言っておきながらアレだが(^^)、しばらく公開するツモリはない。何より、今日ようやくベクターからVer.1.01.00の更新登録のしらせがあったばかりなのだ。自分が使う訳ワケでもない、ヒトから要望があったワケでもない、そんなモノをあわてて公開する必要もなかろう（全く反響もナニもないモノを更新するのってやる気が萎えるよね...）。
●習作
今回のバージョンアップは、「配布前提のソフト」開発のための習作的位置づけである。印刷以外にも満たすべき要件はまだまだあるはずだ。 その辺をじっくり検討・改変を加え、それが落ち着いた段階で公開を考えたい。
●拡張
- 印刷を前提としたレイアウトに変更
- 印刷向けの設定追加（ヘッダー、フッター等）
- 弥生データ取引時、最終伝票の表示位置がずれることがあるバグを修正
- 弥生データ取引時、現金取引伝票を取込まないように変更
→現金取引伝票に消込はいりますまい(^^) - 弥生データ取込ボタンを作業シートに配置
→いちいち設定シートを出すのがメンドウだったので。 - 伝票番号セルの表示形式を変更
→カンマを出なくしました
先日、『弥生元帳印刷』に比べると『BF入金消込』の出足が落ちてることについて言及したが、考えてみれば一応はアップデートがかかった直後のハナシなワケで、新規ユーザーが増えていっているコトにはならない。今度こそ同じ条件である。サテ、どちらに軍配が？（←そういう問題じゃない気もするが^^;）
こっそりマニュアル改訂(^^;;)
うーむ、先の公開から一ヶ月経過したが、未だに反応がない(T_T)。ここはいっちょ、もう一箇所公開場所を確保しよう... というワケで、ベクターに登録。
Excel Q&Aのお膝元、Excel Factoryさんのフリーソフトコーナーに登録していただく。
C言語と違い、VBAはbit演算がイマイチ弱い（と感じる）。特にビットシフト演算子がないのがなぁ。左シフトは2をかけて、右シフトは2で割る。ふぅ、やれやれ、まずは読出しモジュールができたぞ。get_nth(n,bin)とやると、バイナリデータbinの5bit配列でのn番目の要素を返す関数である。ここまではまぁ、順調だったのだが...
●書込みがうまくいかん〜(T_T)
put_nth(i,n,bin)とやると、n番目の要素にi (0<i<32)をセットするというもの。コレでデータをセットして、get_nthで読み出してみるんだけど、入れたデータと違うのが出てきたりする。ナゼじゃ〜。
●用途から機能を検討しよう
この5bit配列の用途は、言うまでもなく売上伝票の組合せを表す数列の格納である。詳細は省くが、組合せを作り出す時、前からある組合せ集合に新しい伝票番号を追加するようにしている(例えば集合{1, 2, 1-2}に要素3を加えて{1, 2, 1-2, 3, 1-3, 2-3, 1-2-3}となる）。つまり、いきなりn番目の要素にデータをセットすることはありえず、空の配列にまず1コのデータを1番目にセット、次のデータ1コを2番目にセット...という具合。
●何も普通の配列と同じ使い方ができなくても
というワケで書き込みモジュールは、データiを一番最後に追加する add_one(i,bin) のみとした。もちろんちゃんと動いた。
●よぉっしゃ！
いつもだったらスワップが起こるタイミングだが、オンメモリで動いている。当然検索時間も短〜い(^^)/
困ったときのSalon頼み(^^)。重複チェックのアルゴリズムについて、質問を投げてみた。正直「掲示板の趣旨が違う」と怒られるんじゃないかと戦々恐々である。
●ソレだッ！
やっぱヒトの意見は貴重だ。たとえ直接の答えでなくとも、新しい考え方のヒントを得られることが多い。キーワードは「二分検索」。コレは、既に既出チェックの際に使って上々の成果をあげているが、同じコトを重複チェックでもやりゃいいやん！
●結果は
チェックサム以上の劇的スピードアップ！比較量（バイト数）を減らすより、比較ステップ数を減らす方が効果的、という結論（当然か...）。しかも、完璧に重複ないし。やったー(^^)/
（このやりとりはSalon No.22173にて）
●でも比較量も少ないにコシタコトない
チェックサムほどでないにしても、現状32バイトほどもあるデータを短くできれば、スピードが速くなることは実証ずみ。なんか手はないものか... ん！考えてみたら、今3ケタの10進数をマンマ文字列3バイトでやってんだよなぁ... もしVBAで符号なしbyte型整数なんてのがあれば、０〜255まで1バイトで表現できる！データ量が3分の1になるぞぉ〜。
仮に255も検索対象伝票があったら、今の感じじゃソレこそ何日かかることやら。127でも多い。63か31か... うーむ、ほとんど31以下で済むと思うんだけど、時々40ぐらいあるからなぁ... ま、とりあえず31にして、5bit配列モジュールを作ろう！
これまで全伝票の組合せを検索してきたけど、考えてみりゃ入金額より高額の売上伝票は始めから対象外やんけ。お、トーゼンながら速くなった。ハッピー(^^)v
ワリと全体的にまとまってきた感じ。一応消込検索できるようになったし... ンが！やっぱ伝票数が増えると指数関数的に検索時間が増大する。検索そのものよりも、メモリのスワップに時間がかかってるようだ。三日三晩走らせ続けてやっと止まったと思ったら「メモリが不足しています」「システムが不安定になりました」(T_T)。いくらムチャな使い方だからってハングっていいワケじゃないぞ〜。このタコOSがッ！（怒）
前述の通り、組合せパターンは金額計をキーとして二分木に登録している。大雑把にこのときのアルゴリズムは以下の通り。
- 二分木検索により、ある組合せの金額計が既出かどうかをチェックする。
- 初めての金額計だったら、木のノードとして然るべき位置に追加。
- 既出だったら、その組合せが既に登録されている組合せと重複していないかチェックする。
- 重複していなければ、その金額計の組合せとして登録。重複なら捨てる（何もしない）。
手順3の、重複のチェックがクセモノである。組合せ情報は、伝票セルの行番号3桁をそのまま並べた文字列として登録している。伝票数は最大でも12ほどだったが、つまり、組合せのデータは1件につき3x12=36バイト使用しているワケだ。これが個々の金額計につき、（重複をなくしても）ヘタをすると数百も存在するのだ。1コ新しい組合せが出るたびに、数百も検索していては時間がかかってシャーない。ナンかいい手はないものか。
●チェックサム
お〜、懐かしい響き(^^)。昔16進ダンプを手入力するときにはズイブンお世話になってたものだ。余談はさておき、組合せパターンの重複チェックに、チェックサムを使ったらどうだろうか。組合せの伝票セル番号の合計を一緒に登録しておき、チェックの際は本体でなく合計同士のみチェックする。合計は当然整数型で精々4バイト。32バイトの比較から4バイトの比較になるんだから、単純計算で8倍の高速化になるハズだ。
●結果は
8倍どころじゃないくらいのスピードアップに感じる！しかぁし、あいにくというか当然というか、重複が残ってしまっている（例えば合計で10になる整数の組合せは何通りもある。チェックサムではそれらを認識できない）。それにチェックサムの分、確実にメモリは余計にかかっているし。sigh...
●「珠玉のプログラミング」購入
たまたま雑誌の書評欄を見ていたら紹介されていた本。コンピュータアルゴリズム関係の本らしい。作者がどうやって効率化を図り、スピードアップ、メモリ節約を実践したかが書かれているという。参考になりそうだ。
これでも某大学情報工学科を出たyonetch。サーチとかソートのコーディングについては講義でベンキョーした（ハズ）。「そうそう、昔やったぞ。二分検索とかクイックソートとか... アレ？でもあんときゃPascalのポインタ使って線形リスト構造とか二分木構造とかインプリしたんだったよな。VBAでできるんかいな？」
●Q&A Salonデビュー
自分なりに調べてみるものの、できるともできないとも判断のつかないyonetch。意を決してSalonで聞いてみることにする。「あの〜、数百万コのデータ処理でぇ（中略）ポインタってVBAで出来るんですかぁ？」
●キツい洗礼
「数百万なんてExcelにはムリです。データベースを使いましょう」。うがっ(T_T)！だよなー、普通はそう思うよなー。元SEとしての自分も同感だし(^^;)。しかぁし、趣味のプログラマとしての自分は、数百万を数万に減らすために「ポインタの使い方」を質問してるんだけどなー。質問に答えてほしいなー。
●ポインタはポインタでも
データ自体は普通に配列に格納し、そのインデックスを格納した別の配列を用意することでリストだろうが二分木だろうがインプリ可能なことを教えてもらう。ガーン！目からウロコが落ちまくり(^^)。そうか〜、PascalやC言語とは違うけど、これも一種のポインタだなー。
●ちょお速ッ＆軽ッ！
早速コーディング。このスレッドの中で、既出チェックに関する画期的な方法について示唆を受ける(己が無知やっただけじゃ^^）。あわせてコーディングすると、メモリ量もスピードもダンチ！（このやりとりは、Q&A Salon No.19280から始まるスレッドを参照）
気が付けばヒトツキ近くVBAのコードに触っていない。VBA習得の題材として選んだ入金消込だったのに、アルゴリズムに悩んでVBA習得自体が疎かになってしまった。本末転倒とはこのことじゃ〜。
●チカラ技でいこう！
何のために機械にやらすんだ。単純な繰り返し、これこそ機械の専門分野ではないか。というわけで、とにかく総当りで検索する方法でインプリメントしてみることにする（重そ〜^^;）。
●セルが足りん！
データの載ったシートの他にワーク用のシートを用意して、組合せのパターンをワーク用シートに並べてみた。とたんにセル不足に陥る。折り返しの位置計算とかもメンドウ。必然的に配列に格納することにする。
●全組合せを重複なく
まずは全組合せを作るための多重ループ。すぐにメモリが足りなくった(T_T)。あ、全組合せったって、この場合順序は関係ないんだからA,BとB,AやA,B,CとA,C,Bは重複だな。これでメモリが節約できる。
●既出かどうかチェックして組合せを登録
組合せた伝票の金額計が同じで重複しない組合せを、順次配列に格納。はじめの内はいいけど、要素数が増えるとむちゃくちゃ時間がかかる。メモリを節約してもこれじゃあ使い物にならん(T_T)。つまんなくなって(^^;)、またまたしばらくほったらかす...
これでようやくノミやカンナがちょっと使えるようになっただけ。これでどれだけ立派なウチが建てられるか？
●CSVファイルからデータ取り込み完成
なんといっても、まずは弥生販売のデータを取り込まにゃハナシにならん。CSVファイルの開き方、それらのデータを集計してシートに配置する方法、そのアタリを習得。
●組合せ検索のアルゴリズム
さて、データが用意できたところで、いよいよ検索モジュールの製作に入る... といったものの、サッパリ見当もつかない。単純に考えたら、入金額に対して売上額を適当に組合せて比較して... ってのを延々繰り返すってことになるが、なんかスマートじゃない。そんなチカラ技じゃない方法があるはずだ...
●展開がないとアキるよね(^^;)
で、1,2週間ヒマを見つけては考えるが、何も浮かばない。そうこうしているうちに、やる気というか興味がだんだん失せてしまい、しばらくほったらかしになる。
さーて、VBAにチャレンジするぞ。ナンか目的がないとモノにならんから、前から苦労してた入金消込を題材にしてみよう（弥生販売の入金消込ってナンデこんなタコなんや！）。サテ、VBAのコードって、ドコにどう書きゃいいのン？（先が思いやられる...T_T）
●Excel Q&A Salonとの出会い
どう考えても先達の知恵をお借りせねばラチがアカン(T_T)。ぜったいインターネット上にそういうサイトがあるハズだ。さて... というワケでいくつかあった中で、投稿者のレベルが高く、デザインや機能がスッキリして好感がもてたのがExcel Q&A Salon。しばらく、ROMに徹してVBAコーディングの基礎を学ぶ。