皆さん、SAP触ってますか？
私は全然触れていません。
最近はSales Forceをよく触るようになったのですが、やっぱりSAPってよかったなぁーと思うこの頃です。
と、いうわけで、こちらの投稿では、SAPのトランザクションデータの項目説明を記憶をベースに行っていきます。
まずはじめにトランザクションデータの構造の解説をして、
SAPの購買管理、いわゆるMaterial Managementに
使用するドキュメントの一つ、購買要求/Purchase Requisitionの
項目の説明を行っていきます。
項目の意味、どんな時に使用するのか、そしてPurchase Requisitionを作成するときはどんな考えに基づいて値を指定すればよいのか、
それともマスターから自動で導出されるのでユーザーが指定する必要はないものなのか、といった点を説明していきます。
Agenda
【SAP】トランザクションデータの構造と購買要求の項目解説
想定読者
- SAPプロジェクトにかかわることになった事業会社、コンサルタントの方
- 購買管理業務を担当していてシステムにSAPを検定されている方
想定メリット
- SAPで購買管理に使用されている項目がわかる
- SAPで購買管理が想定している業務シナリオがわかる
- SAPを自社の業務に割り当ててよいのか、参考にできる
- 成果物として項目定義書を作ることになった時に参考にできる
項目に対して記載する内容
- 項目の意味
- 用途
- 指定方法
アジェンダ
- 基本概念：トランザクションデータはHeaderとItemでできています。
- Purchase Requisition のHeader項目
- Purchase Requisition Document Type
- Purchase Requisition Number
- Header note
基本概念：トランザクションデータはHeaderとItemでできています。
Purchase Requisitionの項目説明に入る前に、SAPのトランザクションデータが持つ2つの構造についてお話しします。
SAPのトランザクションデータは、基本的に2つの構造からなっています。
トランザクションデータは、取引データ、あるいは伝票と言い換えてもいいものになりますが、
Headerはそのデータ一つに対して一つ存在するもので、
ItemはHeaderにぶら下がる形で複数存在できるものになります。
Headerはドキュメントに一つ
Itemはドキュメントに複数
発注の例をとれば、どこに対して発注するのか、という内容は発注について一つになるのでHeaderにあり、
そして何を注文するのかという情報は複数あることも十分にあり得るのでItemにあるということになります。
データはHeaderとItemの2つだが、SAPの画面は
3構造：Header、Item Overview、Item Details
じゃぁSAPの画面はHeaderとItemの2つの構造になっているのかというと、実はそうではなく、より見やすさの観点からSAPの画面は3構造になっています。
3つの構造は、Header, Item Overview, Item Detailsとなります。
図で示すと、以下のような関係性で、かつSAPの画面でもこのような見え方になります。
上部にHeader、真ん中にItem一覧のItem Overview、
下部にはItemの詳細を示すItem Details
上部にHeader、真ん中にItem Overviewを配置し、Headerにぶら下がっているものが何なのか、一覧できるようになっています。
画面下部にはItem Detailsがありますが、ここにはItem Overviewに一覧化されているもののうち、選択された番号のItemの詳細が出てきます。
図の例では、Itemは10, 2, 30, 40とあるなか、10を選択しているので、10番の詳細が画面下部に表示されている、というわけです。
Header、Item Detailsにはタブがあり、
カテゴリーごとに項目・情報がわけられている
図でも示していますが、Header, Itemにはそれぞれタブがあり、カテゴリーごとに情報がまとまっています。
いずれ別の投稿で詳細を解説しますが、対象品の基本情報、保管時の情報、貿易関係の情報、会計関係の情報、といった粒度で
このタブはまとまっており、それらに関連した項目・情報が各タブの中にあります。
Purchase Requisition のHeader項目
さて、それでは各項目について、見ていきます。
まずはHeaderの項目から。
Purchase Requisition Document Type
意味: 購買要求のドキュメントタイプ
用途: 購買要求の業務シナリオを示すもので、後続のシステム処理、入力項目などを制御する。
Data Type: CHAR
Length: 4
Technical Name: EBAN-BSART
説明になってねーじゃねーかと言われそうなのでもう少し書かせて頂きます。こちらはドキュメントタイプ、伝票タイプとも呼ばれる項目になります。
業務シナリオを区別するために存在する。
シナリオ別にシステムでの処理を区別する役割を持つ。
SAPでは、いろいろと伝票は作成することができるのですが、業務シナリオ、業務フローが異なる場合はこの伝票タイプを別にしてしまって、
別の業務シナリオですよーと誰が見てもわかるようにすると便利です。
例えば、普通の購買であればStandard：N010、外注であればSubcontracting：S010、といったような具合に分けます。
伝票タイプを分けると何がいいのかというと、後続のシステム的な処理の流れを分けることができます。
業務シナリオごとに処理を分けたいときに
ドキュメントタイプでを使用する例
どんなふうに処理を分けるかといえば、ドキュメントタイプごとに必須で入れる必要のある項目が変わったり、
承認の段階が3段階から7段階になったりあるいはスキップされたり、セーブされたタイミングで何か別のデータを作るようにしたり、ということができます。
具体例を見ていきましょう。
以下のようにドキュメントタイプを分けたとしましょう。
- N010: 在庫部品購買要求
- F010: 固定資産購買要求
- S010: 外注購買要求
- T010: 在庫転送要求
- T011: 会社間在庫転送要求
どうしてこんな風に分けたかったのか、その例を以下に記載します。
- 在庫部品の購買と固定資産の購買では組織が違うので承認者なども異なる
⇒N010 とF010をそれぞれ定義する - 外注するときは契約内容についてリーガルチェックが必要でほかの購買とは業務の流れが違う
⇒S010の定義が必要 - 在庫転送は社内の在庫移動なので会計伝票が作られないようにするため購買とは分けたい
⇒T010を定義する - グループ会社間の在庫転送は実質通常の購買と一緒ではあるものの連結会計の時に簡単に消去できるように会計伝票が作成されるようにしたい
⇒T011を定義する
ドキュメントタイプを分ける切り口はいろいろ
ポイントは後続のシステム処理を分岐させる際の判定に使うかどうか
このほかにも、緊急度の低いものと高いもので希望納品日の設定ロジックを変えたいので別にするとか、
需要予測のシステムが作成したものであれば人間の承認行為を省きたいため別にするとか、業務シナリオによってさまざまに分かれていきます。
指定方法: 作成者が責任を持って指定する、あるいはシステムが自動で選ぶ
大企業であれば、自分は常に在庫部品の購買、あるいは固定資産の購買、という役割があるケースもあります。
そうした場合は、自分の役割が関係する伝票タイプを選択することとなります。
あるいは、個人の登録されているユーザーIDと組織の設定で、これしか選べない、という状況に設定する場合もあります。
中小企業のようなどんな購買も購買組織一つで対応しているケースであれば、なにを購買要求に出すのか、
といった業務シナリオを理解した状態で適切な伝票タイプを選択することとなります。
システムが購買要求を作るときは、事前にどれを使うべきかシステムが選べるようにする
システムが自動で選ぶようにする場合もあります。
PR：Purchase Requisition（購買要求のこと）の作成は、人が行うかシステムが行うかのどちらかですが、
システムが行う時は事前にシナリオごとにどのドキュメントタイプを選ぶべきか指定しておいてあげる必要があります。
例えば、受注を受けたものの在庫がなかったため、受注と同時に購買をかけなくてはいけないケースなどは、
人がやると忘れるリスクがあるのでシステムが自動で購買要求を作成する必要があります。この時に自動で選ばれるようにしておく、ということも出来ます。
業務の理解なくして
ドキュメントタイプの定義は不可能
一番はじめに出てくる項目ということもあり、SAPのなかでは非常に重要な項目となります。
実際、プロジェクトの中でも要件定義のかなり後半になってから最終化されるケースも少なくありません。
今回の投稿はPurchase Requisitionについてですが、このほかのトランザクションデータについてもドキュメントタイプというものは存在していて、
それらはどれもシステムの制御に深くかかわっています。
業務の理解と、このドキュメントタイプで何が制御できるのか、抑えておくことは非常に重要となります。
このポイントは別で投稿もしようと思います。
Purchase Requisition Number
意味: 購買要求を一意に特定する識別番号
用途: 組織内での管理、状況確認、追跡に使用する。
Data: CHAR
Length: 10
technical Name: EBAN-BANFN
こちらは、購買要求を作成したタイミングで発番する、内部管理用の番号となります。
購買組織およ要求部門での管理、識別に使用する番号
製品Aを買いたい、とある人が言ったとして、その後別の人が同じく製品Aを買いたいと言って購買要求を作成していたりすると、
自分の購買要求はいったいどれなのか、そしてどんな状況なのかわからなくなります。
そんな時は、内部管理用に採番しておいた購買要求を一意に特定するPurchase Requisition Numberで識別します。
システムによる自動採番で重複を防ぐのが一般的
システムが自動で重複しないように採番するのが標準ですが、設定によっては購買要求を作成したユーザーが自分で好きに入力できるようにすることもできます。
ただし、当然ながら重複は許されないので、既に存在している番号は取れません。もし取ろうとしたときは、画面にその番号はすでにとられています、というエラーメッセージが出ます。
指定方法：勝手に採番される場合は指定しない。
手入力する場合は重複しないように入力する
購買要求は、販売側の要求や、製造側の要求などでシステムによって自動で作成されるケースも非常に多いので、連番で採番するように設定するのが通常です。
都度ユーザーが入れていたら、管理しきれませんからね。
よって、指定するということはあまり一般的ではありません。
もし、指定する場合は、既存の番号と重複しないように手入力することとなります。
ドキュメントタイプごとに番号体系は分けてほしいとよく言われる
こちらの番号は、ドキュメントタイプごとに採番のルールを分けて欲しいと言われることが少なくありません。
どういうことかといえば、
在庫部品の購買は10始まり、外注は20始まり、在庫転送は30始まりにする、と言った具合に業務シナリオごとに番号の振り方を変えるということです。
要望の背景はItem側の情報だけでも
どの業務シナリオかわかるようにするため
ドキュメントタイプを見ればどの業務シナリオかはわかりますが、ドキュメントタイプはHeaderだけの項目なので、Item側には持っていません。
しかしPurchase Requisition NumberはHeaderとItemの双方に持っている番号であるため、この番号体系で業務シナリオがわかるようにすると、
Item側に持っている情報だけでもどの業務シナリオなのかがわかるようになるのです。
ちなみに、ここまでPurchase Requisition NumberはHeader項目として説明してきましたが、Item側のItem NumberだけではどのPurchase Requisitionに対する
Itemなのかがわからないので、Item側にもPurchase Requisition Numberが存在しています。
桁数は10桁まで持てるので、なかなか使い切ることは考えにくいですから、比較的通りやすい要望です。
ドキュメントナンバーは、
ドキュメントタイプに付随して設定が必要となる
こちらもPurchase Requisitionに限らずですが、ドキュメントナンバーの番号体系はドキュメントタイプの設定ごとに発生するものとなります。
お客様によってはドキュメントタイプが異なっても番号体系のルールは同じでOKとする場合もありますが、
その場合は場合でどのドキュメントタイプが同じ番号体系で問題ないのか、ということをきちんと理解したうえで設定していく必要があります。
Header Note
意味 : 購買要求のhedaerに持つテキスト情報
用途: 何か入れたければ入れる。ほかの人へのメッセージなど。
Data: CHAR
Length: Unlimited
こちらは、テキスト項目となります。
いきなり雑な説明になりますが、何か、入れたいことがあれば使う、ということになります。
一応、日本語も入れることはできます。
指定方法：入力する必要のあるテキストを入力する
常に入れるか、常に入れないかのどちらかにすべき
テキスト項目は、自由に使用できるのですが、使うのであれば必ず使うことにしておいて、使わないのであれば何も入れないようにすべきです。
理由は、入っていたり入っていなかったりすると必ず見落としが発生するためです。
あんまり、Header Noteは使用している例は見ないですね。
なので、あんまり語ることがありません。
おわりに
はい、PRについてのHeader項目の説明は以上となります。
PRのHeaderは結構項目が少ないのです。
Itemの説明からはたくさん説明が必要になってきますので、こちらはタブごとに説明を分けていこうと思います。