第16.5回：MZ プラットフォームによるシステムの簡単な構築方法2（実践）
第16回のおまけ
16回は説明はほとんど無いが全て組み上げて起動すれば受注管理システムが立ち上がる。
実際に社内で使うには項目が足りないが、体感する事は出来るだろう
作業日報やってみよう！（実践）
「受注管理」に次いで良く聞く管理項目が「日報管理」である。
１：日報で何を管理するか考える
２：マスターの再考
３：入力画面の構築
という流れで行ってみよう！
①日報に登録するデータを考察する
自社担当・工程（機械）・仕事番号・開始時刻・終了時刻・要した時間
⇒後に取得したデータを活用する事を考えて決まる事
ダメパターン：あれこれ欲張るのは×。入力が面倒になると誰も使わない・・
②マスターの追加の有無（16回同様⇒共通情報として何回も使う項目は別途マスターを設ける）
・工程（機械）マスター
名前・フラグ・レート
（追加するなら）エリア、作業レベル、購入日など
・データベースに列名とデータ型をセット
(.sqlファイル。判らない方は13.5回を参照）
④マスター画面の構築
工程マスターを製作する
※下記デモ用サンプルは前16回のMZ system.mzaxに繫げて用いる事※
(.mzcxファイル。リファレンス判らない方は15回を参照）
⑤日報入力画面を構築
(.mzaxファイル。リファレンス判らない方は15回を参照）
⑥DBを開いてみて、データが格納されている事を確認する事
⑦登録情報を（Select文）を用いて参照出来るかやってみよう！
⇒これは簡単なので自作してみよう
・Select * from `Report`
とやってしまうと
| ID | Member_ID | Process_ID | Orders_ID | Start | Stop | Time |
| 1 | 2 | 1 | 1 | 2020/2/2 2:02:02 | 2020/2/2 2:22:02 | 20.0 |
こんな感じのデータが取れるので、社内の人に表示しても「？」となる。
・Select Report.Member_ID , Member.name from `Report` , `Member` Where Report.Member_ID = Member.ID
とすれば
| Member_ID | Name |
| 1 | 鈴木 |
ReportテーブルとMemberテーブルから情報を参照してWhere区の中でReportのMemer_IDはMemberテーブルIDと同じと記載している
他の項目も続けて同じ様に参照（Select）すると
①
Select
Report.Member_ID , Member.name ,
Report.process_ID ,Process.name ,
Report.orders_ID , orders.no ,
Report.start , Report.stop ,Report.Time
from `Report` , `Member` , `process`, `orders`
Where Report.Member_ID = Member.ID and Report.process_ID = process.ID and Report.orders_ID = orders.ID
となるの。
実際に参照されたデータは数字とテキスト名が出るので社内の人も理解出来る。
さらにこの記載方法だと長ったらしいので
②
r.Member_ID , m.name ,
r.process_ID ,p.name ,
r.orders_ID , o.no ,
r.start ,r.stop ,r.Time
from `Report` as r, `Member` as m , `process` as p, `orders` as o
Where r.member_ID = m.ID and r.process_ID = p.ID and r.orders_ID = o.ID
文章のFrom区でテーブルを「as ○○」すれば短く出来る。
①と②は同じ結果が返ってくる。
16回との連動効果！
★受注情報に基づいて原価把握出来る
登録された仕事番号に基づいて加工実績が連動する。
どの程度時間を掛けて製作されたのか見える化できる
★工程（機械）別での分析の可能に！
仕事番号でソートすれば仕事毎の原価把握に使える。同じく
工程毎にソートすれば負荷の高いエリアの把握など分析幅が広がる
まとめ
少ない取得情報で現場の苦労を減らしつつ、管理者側も効率的な情報を得る必要がある。
皆が等しく入力してくれないと不確かな情報が集まるので
これは大変難しいバランスとなる。
ぼやき：この辺りまで来るとボランティアの範囲を超えている気がする・・。