アドオン/レポート
概要 †
一般的な認識としては、ある単位でデータが纏まったもの/纏められたものが相応か。
ある単位とは、○○マスタという括りでの一覧、システムへの入力内容を日/月/年など期間で纏めたもの、果ては伝票単体の中など。
いずれについても、報告書という言葉が包含する通り、網羅性と正確性を担保していることが大前提となる。
なお、広義ではフォームも包含するという見方もあるが、そちらはリンク先を参照のこと。
レポートの存在意義 †
お客さんが作ってといったから作るというレベルでは、結局その人や組織およびその人のロールが充足しなければならない要求を満たせないため、存在する目的が何なのかを厳密に定義すべきと考える。
具体的には、そのレポートの役割は何であるか？と後続のアクションが何であるか？である。
役割および目的 †
例えば、純然たる自分たちの管理および分析目的なのか、例えば本社や上長への報告義務を全うするためなのか
によって充足されるべき要求は大きく異なり、自然、実現手段、ロジック、プログラム仕様、テーブル設計に大きく関与する。
これがユーザトレーニングや納品の段になって引っ繰り返っては大事になるため、ここを詰めることに費やす労力は惜しんではいけない
そして、ここが明確にならないのであれば、いっそ作らない方がいい。
目先の仕事は取ることができるかもしれないが、投資対効果という目で見られる日がいつか必ず来る。
後続のアクション †
レポートは、暇つぶしに見るものではない。
出した後、二次加工したものを含めてそれを誰かに報告および提出するか、自分が何かアクションを起こすかしなければ、そのレポートは「いらない子」なのである。
例外ケースで「いつでもこのレポートを出せるようにしておく、それを担保することに意味がある」とか、法律や業法での決まりごとや、その業界の慣例のようなものもあるが、それはさておく。
繰り返すが、二次加工したものを含めてそれを誰かに報告および提出するか、
自分が何かアクションを起こすかしなければ、或いはアクションするに足るだけの情報を出すか、
そういった役割を担っていないレポートには、何の価値も無い。
レポートの性質 †
下記の二つに大別できる。
管理用 †
業績分析や文字通り報告書という位置付けでマネージャ層が見るためのレポート。
SAPには標準レポートをはじめ、レポートペインタ、レポートライタなどの機構、LISやSLなどそのための基盤、財務諸表バージョンやセットなどの道具が提供されている。
業務用 †
実業務の遂行上に必要となるレポートで、具体的には集計した金額を伝票に入力する、承認/却下をジャッジするなど。
SAP標準で用意されているものとしては、Tr-CD：ME28やWB24など。
SAPでの実現手段 †
レポーティングツール †
レポーティングの為の機構、パーツ †
在庫レポートのデザイン例 †
注意点 †
基本的には「ありものを集める」という発想で設計・実装すべきであり、ややこしい計算をする羽目になるのであれば、下手にベタコーディングはせず汎用モジュールなどで共通化すること。
また、品目締め処理などの標準機能との絡みは、忘れずに考慮する。
デザインの勘所 †
要素は、大きく「何で抜くか」と「何を出すか」の二つしかないわけで、決して難しいわけではない。
プロトタイピングのノリで、ざっくり作ってReviseする・・・を、2回目で終わらせることを目標にしよう。
目に見える形になったら、大抵は「ああ～ここは・・・」なんてのが始まるので、早めに収束させるという意味で。
- 選択画面のパラメータ
どんな条件で抜きたいか？
これに尽きる。
但し、表示項目を出すためにという逆引き、ベタ打ちで判定したくない伝票タイプなどについては、バリアントで非表示にしたりバリアント変数を経由して定義するというルートもある。
これは条件分岐などでも利用できる有用な手段である。
- 会社コード
「ある法人のみ」「本社しか導入対象でない」と限定されているにしろ、システム屋として非表示パラメータで定義しておく位のリテラシーは欲しいもの。 - プラント、保管場所、品目マスタ
言わずもがな。 - 利益センタ
誰の持ち物？ということで、ニーズは多い。
ただ厳密には途中変更が追えなくなるため、それも考慮した利益センタグループが有力な代替手段として挙げられる。 - 基準日
転記日をズバリFrom～Toで指定する方式と、会計年度および会計期間で指定する方式が挙げられる。
前者は便利だが、実行時点で期間が締まっている/いない等を見る意味で、設計と実装が複雑化する。
後者は、一か月分纏めて出す方式ではあるが、そのあたりの制御が楽であると言える。 - 伝票タイプや移動タイプなどの、ロジック分岐用項目
増えたから、漏れてたから、除外したいから・・・
こんな理由で改修するのは嫌なもので、これを回避するために用意しておいたりする。
- レポート表示項目
- SAP標準の項目
- プラント、保管場所、品目マスタ、ロット、移動タイプ、特殊在庫区分
いわずもがな。 - 数量
在庫単位での数量は勿論のこと、オーダー数量単位での照会も。
ロット依存数量換算を使用している場合は、ロット特性より換算係数を取得する。 - 金額
評価レベル別を基軸とし、必要に応じて評価タイプ別に定義したもの。 - 単価
SAPの特性として、移動平均原価は営業外入出庫において用いられるが、本質的には、「更新された在庫金額を元にした割戻し」であるため、原価価格単位も加味しなければならない。 - 取引先
仕入先支給品や得意先預託品の場合。 - 製品部門
事業を定義するフィールドであるため、レポートでなく、パラメータとして定義すべきかもしれない。 - 品目グループ
定義した品目の粒の大きさにもよるが、「場所」に依存しない、品目を束ねるフィールドとして必要。 - 品目階層
品目グループと同様ではあるものの、原則として販売管理側のフィールドであるため、在庫を主眼に置いた場合は、あまり利用されない・利用すべきでないかもしれない。 - 利益センタ
原則、プラントビューの現在設定を正として拾うか、荷動きを正とするしかなく、少なくとも前残は履歴テーブルから抽出することが一般的であることを鑑みれば、組織変更などの考慮は、少なくともロジ側の在庫レポートにおいては利益センタグループで拾うべきかと思う。 - ロットのマスタ項目
標準には最終移動日や仕入先マスタ/仕入先などの項目が存在するが、
①必ずしも利用者側の意図通り更新されないこと
②標準で更新されない項目があり、EXIT更新が前提の節があること
上記①については滞留在庫を見たくても在庫転送でも更新されてしまうこと、上記②についてはどうせEXITを仕込むのであれば、項目に限りがあるロットマスタに対しロット特性は制限がないこと・・・という理由から、筆者はロット特性への保持をお勧めする。
- プラント、保管場所、品目マスタ、ロット、移動タイプ、特殊在庫区分
- SAP標準の項目
- SAP標準の項目でない、または判断/分岐条件が介入する項目
- ロット特性
同一品目マスタで、物性がロット依存である製造ロット番号など。 - 在庫そのもの、ないし在庫移動の識別子
所要や入出庫の源泉・要因に基づく色付けなど。 - 物理的場所
保管場所がSAPの思想ではあるが、プラントの定義に実組織が介入する場合は同一の物理的場所が複数のコードで定義される場合があるため、そのサマリとして。
なお、本来的にはコード定義による横串での照会などでカバーすべきことは補足しておく。 - 荷動き別のサマリフィールド
例えば、生産活動に係るもの、在庫廃棄等の通常の営業活動に属さない荷動きを纏めて集計するなどがあるが、凝りだすと、移動タイプや入出庫伝票にマッピングされていない恣意的な条件を持ち込みがち。
しかしながら、SAP標準がこれを用いていない理由は考えてみるべきである。
- ロット特性
コメントはありません。 Comments/アドオン/レポート?
