- 0
- 0
- 10
質問
-
物品管理のテーブルについて
質問
DBの設計をされるのでしょうか
いきなりのDBの設計も結構ですが まずはExcelくらいで表をつくるところから始めてはどうでしょうか
＞ お客様にレンタルする機器
が再利用を主に行うのであれば
一品別に履歴と将来予定（廃却とか計測器なら校正とか）を時系列にならべておいて”現状ではＯＯ様にレンタル中”というフラグを立てる くらいでよいでしょう
発注についてはまったく別管理にして 入庫したら在庫テーブルに加える というだけでよいのではないでしょうか
「ＯＯ様にレンタル中の物品一覧」がほしいときは 在庫テーブルから”現状ではＯＯ様にレンタル中”をキーにして抽出して表にすればいいです
（私はレンタル機器はやったことはありませんが お客にデモ機を貸し出す管理のシステムは作ったことがあります といってもExcelのマクロとフォームだけで作ってExcelのメニューを非表示にしたものです みんなは専用でシステムを作ったと思っていたみたいですが 実はただのExcelでした。 扱い件数は 機器そのものは2~300なのですがアクセサリ類や特殊コードも入れると1000点を超えました）
レンタルが一過性（一度、レンタルしたものはほかのお客には出さない）ならば、客別の一覧表を主にするほうがいいかもしれません
経験からのアドバイスになります。
参考になれば参考にしてみてください。
（※だいぶ簡略化しています、ご了承ください）
■マスタ
・顧客マスタ（不要かも）
・商品マスタ
※その他いろいろ
■トランザクションデータ
・注文テーブル
・レンタル情報テーブル（どの注文でどの商品をいつからいつまで借りるか）
・入出庫テーブル（在庫）
※その他いろいろ（請求、発注等）
肝は商品Aがありその在庫はいくつあるのか。いつからいつまでの期間では
貸し出し可能な数はいくつかを把握できる必要があるかと思います。
（返却日に必ず返却されない可能性があるならばそこも考慮しないといけません）
商品Bを10個仕入れました。
→ 在庫テーブルに1レコード（YYYY/MM/DD 商品B IN10）追加
Aさんが商品Bと商品Cを借りました。（注文D)
→ 注文テーブルに1レコード、レンタル情報テーブルに2レコード（それぞれいつからいつまで情報）
Aさんが商品Bだけ返却しました。
→ レンタル情報テーブルの注文D 商品Bのステータスを返却に。
現在で、商品Bはいくつ貸せるか、1ヵ月後に商品Cはいくつ貸せるか。をとります。
（一ヶ月に貸せる商品Cの数は運用の決め等が必要です）
こんな感じです。
＞ 商品Bを10個仕入れました
一般の商店ならこういう考え方でいいのですが
レンタルの管理となると 1品別の管理のほうがよいと思います
すなわち
商品B01、商品B02、商品B03、．．、商品B10 は全部別物とします
コメントありがとうございます。
発注、在庫管理は別にしようと思いましたが、一部の商品は、レンタル申込に同時発注されます。
そのため、在庫管理、物品管理の機能を同一システム上に実装して、データの手操作を防ぐのがいいと考えています。
現状では、レンタル受注 → 物品引当 → ない場合は発注 → 入庫 → 物品管理 という流れにしようかと。まだわかりませんが、物品販売も発生する可能性もなくはないのでやはり、物品テーブル、在庫テーブルを設定しようかと思います。
細かい設計方法を伝えても意味がない気がするので、私の経験から困ったこと、こうしたら良かったと思うことを幾つか書いときます。ちょっと長くなってすみません。
在庫管理をするにあたって、単位（枚、本、ケース）の管理に悩みました。在庫テーブル上に単位があるのですが、１ケース４枚入りの商品で、発注するときはケース、お客様には本で提供ということがあります。この場合、同じ商品で単位違いの在庫管理が必要になります。
数量が０になった在庫マスタを物理削除していたのですが、後々データがないことが原因で苦労しました。月別に在庫の入出荷数量を確認しようとしてもデータがない、発注データから在庫を探そうとして、肝心の在庫が見つからないとか。物理削除を駆使した設計は危険かと。
オペレーションミスや返品などがあった時、それを取り消すデータの保持方法に苦しみました。通常時の運用を考えた設計は簡単なのですが、真価を問われるのはイレギュラーケースに対応しきれるかです。このあたり、すでに業務が動いているなら、過去数年のトラブル履歴を漁ってみると参考になるかもしれません。
他にも色々とありますが。私が運用を引き継いで困ったのはこんな感じ。
書ききれなかったので分割して投稿しました。
あと、他の方も言っていますが、テーブルが云々と考える前に業務フローを書いた方が良いと思います。参考までに私のやり方を書いておきます。
まず、業務の流れを順番に書いていきます。それが出来たら、その業務を実行するのに必要な画面や帳票を考えます。業務の中には、
ここはサラッと簡単に。Excelでも、何なら手書きでもいいので必要（そう）な項目を適当に配置していきます。ここで画面や帳票に必要な項目が、そのままテーブルに必要な項目になるはずです。
ここから、頭の中で必要そうなテーブルに上記で洗った項目を当てはめていきます。次に、シミュレーションをします。Excelあたりに架空のデータを作って、各画面や帳票をイメージしながら、実際にデータを書き換えていきます（正確には、履歴にした方が良い）。
おそらく、真剣に業務をイメージしてデータを動かすと何らかの不整合が出るはずなので、それを随時修正して満足するまでシミュレーションを繰り返します。ここで、各テーブルの持つ重複項目などが洗い出せます。
また、画面上で思い描いた検索条件が、テーブルのインデックスをどうするのか考えるヒントになるはずです。
これが綺麗に流れるようになったら、今度はイレギュラーケースを考えます。社内SEならご存知とは思いますが、ユーザーは私たちの想像を超えたシステムの使い方をします。なので、先に作成した業務フローを見ながらイレギュラーケースを洗い出して、テーブルがイレギュラーケースに対応できているのか、同じ方法でシミュレーションします。
ここが、最も苦しむ場所になると思います。なお、私の場合は「どうすればシステムを壊せるだろう」という観点でイレギュラーケースを考えます。
ここまで上手くできたなら、そうそう大きな問題は出ないと思います。
何れにしても、データベースはシステムの心臓部。画面や帳票がダメでもデータベースがしっかりしていれば何とかなりますが、逆だと本当に手の打ちようが無くなります。
時間を変えて、慎重に、真剣に取り組んで良い場所だと思います。
desatoさん、指摘ありがとうございます。
kotakeshiさん、説明不足でしたが固体識別が必要となる場合
レコードはアイテム単位で管理する必要が発生します。
入出庫を個別に登録するか、一括で登録して中間テーブルで運用するか等
いろいろ立ち回り方があるので、要件に応じて対応してみてください。
皆さん、いろいろなご意見ありがとうございます。
参考にさせていただきます。
ハリコフさん
「どうすればシステムを壊せるだろう」
これは非常に参考になる一言です。
sysjojoさん
私もER図を現在作成していて、主となる商流をまずは確定してから、扱うデータの最小単位から構成を考えています。テーブル、項目がしっかりしていればあとは画面項目はビューのようなものですからね。それ以外には、将来の顧客のビジネスの展望を考えて構築しています。（ここは情シスの方でも把握していないことが多々あり確認するのに時間がかかりますね。）
kidさん
個別レコード入力の場合は一括取り込み必須ですね。確認してみます
私だったら
＞ 在庫管理をするにあたって、単位（枚、本、ケース）の管理に悩みました。
発注システムでは”発注単位””最低発注量”という項目を設けてそれにしたがって発注します 個数によって値段が違うこともあるので”発注数連動単価”も必要でしょう でも 納入されたとたんに１個１個に分割して在庫管理します。
＞ 何を一意にするかは、どういう単位で買うか/貸すかで変わるでしょう
ですね。 「一意」とは英語でユニークのことですが一般認識のユニーク＝変わってる ではなくて キーで指定したら特定の一個を指し示す ということになります（ファイルやDBの設計ではよく出てきます）
貸し出す単位も重要で 「カートンケースに入ったモニタディスプレイには電源コードとRGBケーブル１．５ｍが付属している」 ですが別途に「RGBケーブル３ｍ」を貸し出したりしますのでこれも別物として管理します 返却されたときに”同梱品の確認”、”小物（この場合RGBケーブル３ｍ）がきちっと返却されたか”の管理が重要です チェックシートを現品につけて返却時にお客に確認させ、受け取るときも確認します（後から「あれがないんですけど」といってもお客は とぼける だけです。
＞ テーブルが云々と考える前に業務フローを書いた方が良い
そうですね 前述の受け取り時の確認作業などもしっかり定義しておく必要があります レンタル料金は1品いくらとか、いつからいつまでが期限とか、送料はどっち持ちとか、．．．
「棚卸」も必要になるはずです 置場をしっかり管理しないと「あるはずだけどどこにいったかわからない」になります 特に小物は置場を固定して置く必要があります おおきなダンボール箱に入ったものは床に直置きになるでしょうけどこれもフロアを碁盤の目に仕切って「D-5」というようにロケーションします
管理したものは完全に廃棄するまでは在庫レコードに残します 在庫が０と在庫レコードなしとは違います 廃棄の時は資産廃却の手続きも決めておく必要が出てきます 「陳腐化してレンタルする見込みがないから廃却」とか「故障して修理不能で廃却」とか理由がはっきりしていることが必要です さがしたけどどうしても見つからないと仕方なく棚卸減耗もあるでしょうね。
うーむ、在庫管理は奥が深いなぁ。
お役に立ちましたか？他にもたくさんの ノウハウが共有されています。
質問
現在、お客様にレンタルする機器等の物品管理についてテーブル設計を検討しています。
不足している物品（通信機器など）については、発注して資産管理をする形ですので、発注、在庫テーブルが必要と考えていて、引当後には資産テーブルへ登録、受注テーブルに反映させるようなテーブル設計を考えています。
参考になるサイトもしくはご経験ございましたら、是非ともアドバイスの程よろしくお願いいたします。