|
||
| <HOME <お願い事項 <Access2000 TOP <Access97 TOP <サイト内検索 | |
|
|
||
| MS-Access2002 なりきりデータベース設計 | ||
| 1 2 | ||
これでとりあえず「パイナップル」も表示されるようになりましたが、アレー・・・在庫数、出てこないよ。。。。
これは、「（売上）数量の合計」が空欄だからです。
売上の集計結果にはパイナップルなんてデータは存在していないわけで、空欄＝存在してない＝値がない＝Null ってことなんですけどね。Nullはゼロとは違うんですよ。「値がない」ものを足したり引いたりしても、「値がない」という答えしか返ってこないのです。
そこで、何らかの方法で、「（売上）数量の合計」が空欄の場合はゼロとみなしてもらうように工夫しないとなりません。
いろんな方法があるんですが、Nz関数ってやつが結構使えると思います。
VBEのウィンドウのほうのヘルプで、この関数を調べてみると、
Nz関数
Nz 関数は、バリアント型 (Variant) の変数が Null 値である場合、0、長さ 0 の文字列 ("")、または別の特定の値を返します。たとえば、この関数を使用して、Null 値を別の値に変換し、式が Null 値に評価されないようにします。
と、こんな解説が載っていて、さらに下のほうに
次の例では、変数 varFreight が Null 値の場合は、Nz 関数の引数 valueifnull に指定した "配送料無料" という文字列が返されます。
varResult = Nz(varFreight, "配送料無料")
こんな使用例が載っています。
それでは、これをまねて・・・。
仕入に関しても、もしかしたら１回も仕入れない商品もあるかもしれませんから、Nz関数を使っておくといいと思います。
これでどうでしょう。
Nz関数は、数値を返す関数ではないので、文字扱いになって、左端によっちゃってますけどもね。
Val関数というのがあるので、これを使って、数値扱いするようにしておいたほうがいいかもしれません。単に数字を表示させたいだけではなくて、在庫数の計算をするわけですからね。
Val 関数
指定した文字列に含まれる数値を適切なデータ型に変換して返します。
クエリを使っている分には、MS-Accessがうまいことやってくれそうですが、データ型はきちんとしておいたほうがいいですもんね。
ついでに、「式１」「式２」じゃあんまり・・・。ちゃんと列名はつけておいたほうがよさそうですね。
まあ、計算結果が出ればいいことなので、変えなくてもいいかもしれませんけど。。。。
まさか、どこを変えたらいいのかわからない、とかいう人、いませんですよね。
「在庫数が出なくなっちゃったんですけど」とかいう人も、いませんですよね。大丈夫ですね。
各商品の在庫数を知りたいとき、このクエリを開けばすぐにわかるようになりました。
在庫を調べたいときに、このクエリを開いて使うもよし。
このクエリを基にしてレポートを作って、仕事を始める前に手元に置いておいたり、フォームを作っていつでも手軽に見れるようにしておいたり・・・。でも、このクエリをデータシートビューで見るだけでも、結構使えると思うんですよね。
また、このクエリから情報を引き出すようにすれば、売上の入力のときに在庫を知ることも可能ですよね。
方法はいろいろあるはず。やり方はひとつではありませんよね。なのでこれは、皆さんで考えてみてください。
具体的な方法が今思いつかなくても、「こういうとき何を考えればいいか」は、ご存知のはず。
挑戦してみてください。
このままでも、とりあえず大体の在庫は把握できると思います。
在庫を把握するためのテーブルの構造は見えてきましたので、本題はここまでといたしまして、余談を少しばかり・・・。
大体、と申しましたのは、マイケルの店で扱っている商品は、木の実とか果物とかなので、多分、虫食ってるとか、腐ってるとか、考えられると思うんですよね。つまり、実際の売上数と仕入数以外にも、在庫数を左右する要素って考えられると思うんです。
日がたつにつれ、さっき作ったクエリで算出される在庫数と、実際に倉庫や店頭にある商品の数と、合わなくなってくることも・・・。あっ、アクセルくんがつまみ食いを・・・。
これは、取り扱う商品の種類や流通経路をしっかり見極めないと判断が難しいところかもしれませんが・・・。
定期的に「棚卸」が必要かもしれませんね。ほら、街の商店やデパートなんかでも、早めに店を閉めて店内の商品の数や状況をチェックしたりって、たまにやってるでしょう。物はしょっちゅう動きますから、どこかで営業活動を一時停止しないと正確な数や状況が確認できない業界も多々あるんだと思います。
マイケルも、いずれ、たまに、店の中と倉庫の商品の数をチェックして、在庫数の帳尻を合わせようと思っています。
考え方はいくつかあると思うんですけど・・・今のところ、
「商品マスター」の「期初在庫数」
「仕入テーブル」の「仕入数」を商品別に集計した「Q_商品別仕入数集計」の「仕入数の合計」
「売上テーブル」の「数量」（売上数）を商品別に集計した「Q_商品別売上数集計」の「数量の集計」
を足したり引いたりして、在庫数を出しているわけですよね。
この3つの要素の関連を理解しておかなくてはなりません。
定期的に棚卸をするとして、倉庫や店頭の商品数をチェックした後、「商品マスター」の「期初在庫数」を実際の在庫数に書き換えておこうと思います。でも、「商品マスター」の「期初在庫数」が書き換わっているのに、仕入と売上に関してはずっと昔から計算してしまうんだと合わなくなっちゃいますよね。そこで、
１）棚卸をして「商品マスター」の「期初在庫数」を書き換える。
２）「Q_商品別仕入数集計」と「Q_商品別売上数集計」は１）をやった日から後の分だけ集計するようにする
ってのはどうでしょう。
あるいは、
１）棚卸をして「商品マスター」の「期初在庫数」を書き換える。
２）「仕入テーブル」と「売上テーブル」のデータを他のテーブルに移し、「仕入テーブル」と「売上テーブル」を空にする
とか。
マイケルの店の場合は、前日の売上数を見たりしてますので、前者の方法のほうがよさそうな気がしますが、皆さんはどう思われますか？
具体的にどういう方法でやるかということを考えるのではございませんよ。マイケルの店の業務形態にあった考え方はどれかな、ということを考えるわけです。
前者なら、「最終棚卸日」を常に保存しておくための小さいテーブルを作っておけばいけるんじゃないかと思います。
後者の方だと、
・「仕入テーブル」「売上テーブル」と同じデザインのテーブルを作っておく。仮に「仕入テーブル２」「売上テーブル２」
・棚卸後、「商品マスター」の「期初在庫数」を書き換えた後、
1）「仕入テーブル」のレコードを「仕入テーブル２」に追加クエリで追加。
2）「売上テーブル」のレコードを「売上テーブル２」に追加クエリで追加。
3）「仕入テーブル」のレコードを削除クエリで全部削除。
4）「売上テーブル」のレコードを削除クエリで全部削除。
と、４つのクエリをマクロかコードで連続して開くようにし、コマンドボタンクリックしたらそのマクロが動くようにする
というような処理の流れを考えて、「仕入テーブル」「売上テーブル」に常に「棚卸後の仕入および売上のデータだけ」が入るようにしてやるといいかもしれませんね。
（このコーナーはデータベース設計を目的としてますので、追加クエリや削除クエリの作り方のお話はいたしませんです）
こうやって、ひとつひとつ業務と照らし合わせてテーブルを作ってくれば、どのテーブルのどのフィールドにどういう値が入ってこなくちゃならないのか、結構見えくると思うんです。
・業務の内容を熟知して
・業務の中の、「品物」や「情報」や「人」の流れを理解して
・データの塊を作り、それぞれのデータの塊同士の結びつき方を考えて
その結果、ひとつひとつ丁寧に作り出したテーブルであれば、いちいち「ワケがわかんない」なんてことには、ならないはずです。
そのためのデータベース設計ですもんね。
今までお話してきた内容に、ちょいとオマケで、マイケルが考えた「棚卸処理」を付けてみました。
マイケルが考えた方法ということで、決して「これが棚卸処理だ」、というわけじゃありませんからね。
在庫の管理方法なんて、会社や業種によってぜんぜん違うはずですから、決まったやり方なんてないわけですよ。
それを、「在庫の管理をやりたいんですけど、どうしたらいいですか？」なんて、安易に社外の人にメールで質問したりしても、何の収穫も得られないですよ。そんなの、いけませんです。
mcl_donguri4.zip
「正解」はありませんから・・・どうか、そこのところ、取り違えてしまわないようにしてくださいね・・・。
イチからコツコツと積み上げて作ったテーブルが基盤になってるデータベースなら、きっと使いやすいものに仕上がりますよね。
がんばりましょう！
 |
|
 |