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