トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS

品目マスタ の変更点

Top/品目マスタ

品目マスタとは、''品''とその属性や性質をシステムに表現したレコードのこと。

----
#contents
----

* 概要 [#x5f2a1ca]
なぜ''品''などという漠然とした表現をするかというと、製品・商品といったいわゆる''すぐに売れるモノ''、半製品・原材料といった''まだ売れないモノ''、消耗品・梱包材などの''売るものではないモノ''、さらに運賃やサービス料などの''モノですらないモノ''すら包含するためである。

これらを販売管理、在庫管理、購買管理などの各プロセスで、目的に応じて使用する。

* 大括りな分類 [#b52f3d64]
[[品目マスタ]]の登録時、外部採番であればコード自体の他に指定する2つの項目について。

** [[品目タイプ>品目マスタ/品目タイプ]] [#y2d2f542]
大きくは、上記の大括りな性質について、''コード体系・使用するビューや項目の使用可否・金額/数量管理の対象であるか否か((評価レベルごと))''などを設定し、住み分けるための要素。
例えば、販売対象と対象外はコード体系を分けたい、サービスや運賃を表現する目的を鑑みれば[[保管場所ビュー>品目マスタ/保管場所ビュー]]は要らない、などの制御を目的に定義される。

** [[産業コード>品目マスタ/産業コード]] [#i9865249]
他にも色々あるが、画面の項目選択などに絡む・・・とだけ。
とりあえず、大抵の場合は''C''(化学)を入れとけってことで、それ以外のものを使用している事例はあまり聞かない。

* コード体系 [#na182aea]
詳細は、[[番号範囲>SAPの共通用語/番号範囲]]に譲るが、大まかに言えばマスタのコードそのものに保持したルールのこと。

** 規定するメリット [#m8db4cc7]
大きくは、視認性の向上、検索効率の向上、処理を自動化やレポーティングのサマリを前提として、システムが判断可能な基準を設けることが挙げられる。
前者で言うならTシャツ系はT始まり・Yシャツ系はY始まりであれば担当者や所属部署は特定しやすいであろうし、後者はチェック/代入のルールに用いることができる。
但し、コード体系を規定するに当たり、良いことばかりではない。

** メリットおよび前提条件 [#j0aa8564]
・面倒くさい
・コード管理部署が無ければ統制が取りにくい、ないし統制を取るための機能が必要となる
・組織や事業を組み入れた場合など、コード体系自体が陳腐化し得る
・細分化するレベル、レコード数、桁長(標準なら18)によっては、コードが足りなくなる
など。

** 定義の例 [#j0497b35]
*** メーカーにおける品目 [#l5e96b72]
まず、派生品的な品目が多く存在し、且つそれらをカテゴライズするニーズが高いこと、他業種と比較すると品目数およびその改廃頻度が相対的に少ないことから、有意採番に優位性があると考える。

*** 商社における品目 [#ub7b14e4]
在庫の取り扱いはあるもののメーカー程の比率でなく、[[Back-to-Back>販売管理/仕入先直送]]や手数料のみの商いが多いこともあり、有意採番が良いと考えるが、メーカーで採用する程の細微・緻密なコード体系は不要と思われる。
理由としては、私見だが在庫するような商品もドカっと仕入れてドカっと売る商いが多いこともあり、あまりにも細微な定義はむしろ足を引っ張るだけにもなりかねないため、荒いレベルでの有意体系+無意が妥当と考える。

*** 消費財における品目 [#b0404a1b]
標準の18桁を1番から無意味連番としてすら足りなくなる程の品目数を誇るため、有意採番は非常に難しい。
また、改廃頻度が非常に高く取り扱い部署も非常に多いこと、[[在庫管理]]ニーズや[[所要管理]]ニーズが低いことも有意採番を採用しない要因となっている。

* SAPにおける構成 [#wf88fb90]
他の主要マスタと同じく、階層構造となっており、下記に大別した。
補足として、T-Code:MM01では[[タブストリップ>ABAP/タブストリップ]]で色々と入力するところがあるが、必ずしも保存先が分かれている訳ではなく、例えば一般プラントタブと購買タブの保存先は、どちらもMARCである。
※テーブルについては、[[品目マスタ/関連テーブル]]参照。

-[[基本ビュー>品目マスタ/基本ビュー]]
品名や[[在庫管理単位>品目マスタ/基本数量単位]]などの基本情報を保持し、Table:MARAに保存される。

-[[プラントビュー>品目マスタ/プラントビュー]]
[[利益センタ>管理会計/利益センタ]]や[[利用可能在庫確認の確認グループ>ロジスティクス共通/利用可能在庫確認の確認規則]]などの[[プラント>ロジスティクス共通/プラント]]依存情報を保持し、Table:MARCに保存される。

-[[販売ビュー>品目マスタ/販売ビュー]]
[[販売単位>販売管理/販売単位]]や最低受注数量などの[[販売エリア>販売管理/販売エリア]]依存([[販売組織>販売管理/販売組織]]と[[流通チャネル>販売管理/流通チャネル]]と、品目自体の[[製品部門>販売管理/製品部門]])のデータを保持し、Table:MVKEに保存される。

-[[購買ビュー>品目マスタ/購買ビュー]]
[[購買単位>購買管理/購買単位]]や[[購買許容値キー>品目マスタ/購買許容値キー]]などがあるが、依存するのは[[購買組織>購買管理/購買組織]]でなく、前者は[[プラント>ロジスティクス共通/プラント]]で後者は基本ビューであり、Table:[[MARA>品目マスタ/基本ビュー]]やの[[MARC>品目マスタ/プラントビュー]]と共に保存される。

-[[保管場所ビュー>品目マスタ/保管場所ビュー]]
[[温度条件区分>品目マスタ/温度条件区分]]や[[保管条件>品目マスタ/保管条件]]などの[[保管場所>ロジスティクス共通/保管場所]]依存情報を保持し、Table:MARDに保存される。

-[[会計ビュー>品目マスタ/会計ビュー]]
[[評価クラス>在庫管理/評価クラス]]や[[評価カテゴリ>在庫管理/評価カテゴリ]]をはじめ、[[原価管理区分>在庫管理/原価管理区分]]や[[移動平均原価>在庫管理/移動平均原価]]や[[標準原価>在庫管理/標準原価]]など[[品目原価>在庫管理/品目原価]]に係る[[評価レベル>在庫管理/評価レベル]]依存情報を保持し、Table:MBEWに保存される。
なお、一般的には[[評価レベル>在庫管理/評価レベル]]の定義が[[プラント>ロジスティクス共通/プラント]]レベルなこともあり、[[プラント>ロジスティクス共通/プラント]]依存と考える人もあるが、ちょっと違う。

-[[貿易管理ビュー>品目マスタ/貿易管理ビュー]]
[[HSコード>ロジスティクス共通/HSコード]]がマッピングされる[[統計品目コード>品目マスタ/統計品目コード]]や[[CAS番号>ロジスティクス共通/CAS番号]]や[[原産国>品目マスタ/原産国]]など、貿易絡みの情報が保存される。
なお、[[タブ>ABAP/タブストリップ]]としては輸出と輸入に分かれているが、何れも[[プラント>ロジスティクス共通/プラント]]依存であり、Table:MARCの[[プラントビュー>品目マスタ/プラントビュー]]と共に保存される。

-[[MRPビュー>品目マスタ/MRPビュー]]
[[MRPグループ>ロジスティクス共通/MRPグループ]]や[[MRPタイプ>ロジスティクス共通/MRPタイプ]]などの[[プラント>ロジスティクス共通/プラント]]依存MRP情報を保持し、Table:MARCに保存される。
なお、一部の項目のみ[[保管場所>ロジスティクス共通/保管場所]]依存であるためTable:MARDに保存される。

-[[テキスト系>テキスト管理]]
--販売テキスト
[[受注伝票>販売管理/受注伝票]]に引っ張るための[[伝票テキスト>テキスト管理/伝票テキスト]]。
--購買発注テキスト
[[購買発注伝票>購買管理/購買発注伝票]]に引っ張るための[[伝票テキスト>テキスト管理/伝票テキスト]]。

-[[追加データ>品目マスタ/追加データ]]
--[[言語キー>SAPの共通用語/言語キー]]ごとの[[品目マスタ/品目テキスト]]
--[[代替数量単位>品目マスタ/代替数量単位]]と[[換算係数>品目マスタ/換算係数]]
--テキスト
---基本データテキスト
---検査テキスト
---内部コメント

* misc [#c9fb8d87]
コンフィグの仕方やその豆知識など、つらつらと。

** [[品目マスタ/登録画面の画面順序]] [#ec580b9c]
T-Code:MM01の画面は、実は''コンフィグ''。解説は[[こちら>品目マスタ/登録画面の画面順序]]。

** 化学品などの含有物の管理について [#h958b06b]
代表的なものとして、主要含有物の含有率の把握と、含有物ごとの含有率の管理ニーズがある。
背景として、科学分野での取り扱い品目では、化審法・消防法・安衛法などの業法が関与し、それらの対象となる品目か否かの把握であったり、一定期間に一定の数量までの商いにしなければならず、ウオッチしなければならなかったり、輸入時に特定の届出を出している倉庫でしか保管できない品目があったり、品目の含有物ごとの[[HSコード>ロジスティクス共通/HSコード]]や実ロットをトレースできていなければならない・・・・などが挙げられる。

これについて、主要含有物の含有率であれば、どこかの空き項目やAppendしてもタカが知れているので大したことはないが、裏を返せばそれ以外は把握できないため、33.33%×2の品目が出てきたり、2番目に多い含有率の管理ニーズが出てきた瞬間に破綻することは忘れてはならない。

簡易な把握のみであれば主要含有物のみをマスタ上に保持すればよく、大して工数も費やさずに実現できるという良い点はあるが、上記の通り変化に弱いため、「強いシステム」たるには、含有物ごとの含有率を管理するのが上策かと思う。

ただ、品目ごとに含有物や含有率は普遍であるという前提は、いずれの場合も念頭に置いたほうがよく、変更になる場合は新しくコードを取る方が無難。
また、酒類のアルコール度数のように同じ製品でも含有率が一定のレンジで変動する場合は、[[ロット特性]]に持たせることも一案かと思う。
また、酒類のアルコール度数のように同じ製品でも含有率が一定のレンジで変動する場合は、[[ロット特性>分類管理/ロット特性]]に持たせることも一案かと思う。


** 品目コードの辞書編集 [#n36550ff]
T-Code:OMSLで設定可能。
品目コード長(フル桁使うか10桁など任意に長さを縛るかなど)、品目コードテンプレート(ヘルプによると「__-_____-_」のようにコード体系と区切り文字を設定するなど)、左ゼロ詰めするか否か等。
なお、品目コード登録後に設定を変更すると色々と不都合があるそうなので、マスタ登録前に行うこと。

この設定は、例えば「数字始まりで数字だけコード」と「数字始まりでアルファベットを含むコード」が混在した場合のソート順、ひいてはレポートの表示に関与する・・・のだが、個人的には「どうでもいいだろそんなの」と思っている。

なぜなら、それらが混在するコード体系って、おかしくない?

だって、コードを数字だけとするなら殆ど無意味連番でokとなるはずだし、英字が混在するなら外部採番=コード体系を持たせるってことなわけだから。
似たようなコードなのに自動と手動が混在してかつ同じ分類としてソートして見たいってシーンは多くないのでは?

詳細はコード体系の項に譲るが、繰り返しになるが、数字だけで構成されるコードだったら、せいぜい上一桁に大分類を持たせる程度の無意味連番でokなはず。


~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)