SAPの品目振替
ある品目コードを別の品目コードに振替したい場合に、SAPでは、品目振替という機能を用いて振替処理を行います。品目コードを変えることもできますし、品目コードにぶらさがるロットを振り替えることもできます。
機能としては、トランザクションコード：MIGOで実行します。アクション「在庫転送」、移動タイプは309を選択します。転送元（振替元）、転送先（振替先）の品目コードを指定して、プラント・保管場所を入力して保存します。品目振替の特徴としては、入出庫伝票上、出庫と入庫の明細が2行できます（品目を出す行と入れる行）。
SAPで出荷伝票を分割する基準のメモです。
- 出荷先
- 出荷ポイント
- インコタームズ
- 出荷条件
- 輸送グループ
- 出荷優先順位
出荷分割のカスタマイズ：Tr-CD: VLSP
SAP IDocとは？
SAPのプロジェクトをやっていると、IDocという仕組みに触れることがあると思います。ABAPで作成したアドオンインタフェースプログラムとは毛色が異なるため、私も最初に聞いたときはIDocって何？？？と思いました。IDocとはIntermediate Documentの略でトランザクションデータを転送するためのSAPが定めたドキュメントフォーマットのことです。SAPではないシステムもIDocの仕組みを使用してSAPとインタフェースを構築することができます。例えば、SAP側でIDocを使用していて購買発注伝票を作成すると、IDoc機能によりこのデータがVendor側のシステムに送信され、Vendor側のシステムでは自動で受注伝票が作成されるといった感じです。
IDoc実例
私が以前に関わっていたPJでは、グループ会社間の取引でIDocを使用していました。以下のようなイメージとなります。本社、製造子会社ともにSAPを導入していて、本社から製造子会社に発注する際にMessage Type: ORDERS/ORDCHGを用いて発注データの連携をして、製造子会社側で受注して製造して出荷するという流れです。製造子会社側で出荷伝票に対して出庫確認するとMessage Type: DESADVのIDocが作成されて、本社側に入荷伝票（作に作成された購買発注伝票に紐づく）が作成されます。つまり、製造子会社側を製品出荷したので、本社側では入荷予定として入荷伝票を作成するというわけです。
IDoc関連設定
IDocデータを作成するためには出力レコードが必要となるので、出力タイプを設定します。Tr-CD: SPROからIMG -> 物流管理 -> 出荷管理 -> 基本出荷機能 -> 出力管理 -> 出力決定 -> 設定：出力タイプ
出庫確認で作成されるDESADVを例に取ると、出荷伝票の出力タイプはLAVA（出荷通知送信）を使用します。これはSAP標準の出力タイプで、標準プログラムが定義されています。また、価格の条件マスタなどと同様に出力用のマスタも設定する必要があります（Tr-CD: VV21）
また、Tr-CD: WE20でパートナプロファイルの設定を行います。パートナとは、DESADVであれば、得意先コードとなります（Partner TypeはKU）。
設定した後に出荷伝票を作成すると、出力レコードが作られていることが確認できます。
出荷伝票作成時点で未処理の出力レコード（黄色信号）が作成されます。
出庫確認することで、出力が処理されて緑色信号となります（このタイミングでIDocデータも作成される）。
作成されたIDocデータはTr-CD: BD87やWE02で見ることができます。保守を担当している方などはIDocの送受信でエラーがないかなどのモニタリングを下記の画面で確認していると思います。
以上、簡単ですがSAP IDocの紹介でした。
追記
IDOC番号と伝票番号のつながりを記事にしました。
SAPでの出荷指示に対する分割納入（倉庫システムで数量分割された場合）
SAPの一般的なプロセスとして受注伝票 -> 出荷伝票 -> 出庫確認 -> 請求伝票となります。
出庫確認とは、倉庫から在庫を引き落として、顧客への配送を開始することを意味し、SAPでは、
出荷伝票に対して、出庫確認ボタンを押下し、出荷伝票の在庫移動ステータスがCとなり完了となります。
SAPの動きとしては出庫確認は出荷数量全数に対して出庫確認するため、部分数量だけ出庫するという
ことはできなくなります。
顧客要件として出荷伝票（出荷指示）に対して、倉庫側では部分数しか在庫を確保できず
部分数だけでも出庫したいということがあります。このような場合、出荷の部分数量をピッキング数量
項目に入力し、全数そろった時点で出庫確認するという対応が考えられます。
あるプロジェクトでは、分納数出荷した分だけSAP上で新たに出荷伝票を作成し、出庫確認するという
アドオン機能を実装したこともありました。しかし、そのようなアドオン機能を作ると、倉庫との出荷指示⇔出庫確認という
インタフェースがあった場合、新たに作り出した出荷伝票を再度送信しないようにするなどの
制御が必要となり、システムとしては複雑なつくりになってしまいます。
一括納入フラグとは
受注伝票明細の出荷タブにあります。意味合いとしては、
得意先が明細の一括納入または分割納入を要求しているかどうかを指定します。
区分としては以下があります。
【区分】
Blank 分割納入可能
A １以上の出荷数量で受注伝票が完了しています
B 出荷伝票 1 件のみ登録 (数量ゼロも含む)
C 一括納入のみ (分割納入不可)
D 継続出荷伝票に制限なし
例えば、顧客によって、発注した数量を全数そろえてから納品してほしい場合は、
区分：Cを選択し、分割納入を許容しません。逆に、全数そろうまでに、出荷可能になった数量だけでも
先に出荷してほしい場合は、区分：Blankを選択します。
通常、得意先マスタ（受注先）の出荷管理タブ -> 分割納入（明細別）項目に区分を設定しておき、
受注伝票明細に初期提案するようにします。そして、受注伝票上で変更することも可能です。
SAP BADIとは？
似たような言葉にBAPIがありますが、こちらはBusiness Application Interfaceの略でBADIとは異なる意味です。BAPIはSAP社が提供しているデータの登録、更新、取得をするためのAPIです。SAPは受注伝票登録や出荷伝票登録など様々なBAPIを提供しています。別システムからデータを渡してこれらのBAPIをコールすることもできますし、アドオンプログラムにBAPIを組み込んで実装することもできます。
話がそれましたが、BADIです。BADI。
BADIとは、SAPの用語でBusiness Add Inの略語です。SAPの標準機能と言われる機能に対して追加機能を実装する仕組みとなります。それではExitも標準機能に対する追加機能ではないかと思われるかもしれませんが、その通りなのです。
どちらも標準機能に対する追加実装するための仕組みですね。ちなみに、あまりテクニカルなところに詳しくないクライアントに説明する時にはBADIという言葉を使わないでBADIのことをExitと言ったほうが伝わりやすい場面も度々あります。そういう意味で、BADI/Exitという用語を細かく使い分けていないProjectもあるのではないでしょうか。
出荷のBADIを例に見ていきましょう。LE_SHP_DELIVERY_PROCという出荷BADIがあり、
これはSE18のBADI BuilderでEnhancement Sport項目に入力してDisplayボタンを押すと確認できます。Descriptionは、「Enhancements in delivery processing」とありますね。
また、「LE_SHP_DELIVERY_PROC」は、あくまでもBADIの定義で、出荷プロセスで使用されるMethodは実際にはBADI Interfaceに紐付けられています。
IF_EX_LE_SHP_DELIVERY_PROCがInterface名になります。
Technical Detailsタブから確認できます。
Interfaceをダブルクリックすると、Methodがズラッと表示されます。
Method例
Check_item_deletion
Delivery_final_check
Save_document_prepare
各Methodの説明はInterface documentationに簡単な説明書きがあります。
また、Methodで使用できるParameterはParametersボタンを押すと確認できます。業務要件に合わせてどのMethodが適切かを調査する必要があります。
そして、このBADIのMethodにロジックを実装するためにSE19でBADI Implementationを作成します。BADIを使う利点の一つに、一つのBADI Definitionに対して複数のBADI Implementationを実装することができます。つまり、LE_SHP_DELIVERY_PROCのBADI Definitionに複数のImplementationを作れます。
BADIを理解するには、Class/Methodというオブジェクト指向プログラミングの概念を理解する必要がありますね。元々、SAPにはUser Exitという標準に対するアドオン拡張の機能があったが（現在でも使われている）、そこにABAPの世界にもオブジェクト指向の考え方が入ってきて、現在のBADIという仕組みが実装されるようになった。
今日は表面的なところだけで、ここらへんまで。
もっと勉強してうまくまとめられるようにしたい！
アビームコンサルティング社について少し調べてみました。アビーム社は国内のSAPプロジェクトを数多く手掛けているコンサルティング企業として知られています。2015年にNECの子会社となっています。
売上高/営業利益/純利益
2014年からの売上高/営業利益/純利益です。アビームコンサルティングは未上場企業のため、数値は決算公告から取得しました。2018年時点で、売上高は717億、営業利益72億、当期純利益58億となっています。ここ数年、業績は順調に推移していますね。また、同社は同業他社と比較して、営業利益率は10%前後と比較的高い傾向にあります。
営業利益率推移
SAP認定資格保有者数
次に、国内のSAPコンサルティングの認定資格保有者数を見ていくと、2位アクセンチュアの約2倍、3位富士通の約5倍と他社を大きく引き離してダントツで一位となっています。同社の社員数が5915名であることを考えると、2人に1人がSAP認定資格を保有していることになります。
他のコンサルティング会社に比べて、アビーム社は売上に占める割合としてSAP案件が非常に高いと推測できます。そのため、戦略コンサルなどの仕事がやりたくて、アビーム社に入ったとしても、なかなかそのチャンスは少ないかもしれません。逆に、SAPのスキルを獲得したい場合は、とても適した企業になりますし、若い人でも高額な年収を稼げるという点も魅力的です。コンサルティングファームというと、労働時間が長くて休みも取れないなど、非常に激務のイメージがあります（高い報酬をもらうので、当然かも知れませんが。。）。ただ、外資系のコンサルファームや合理性のない奴隷労働のような日系SI企業に比べると、アビーム社は報酬・ワークライフバランス・スキルアップなど全体的にバランスはいいと思います。
キーワード
SAP SD、返品、保留在庫、得意先返品、受注返品、返品受注
SAPでの得意先返品
得意先へ商品を納品しましたが、その商品が故障していた場合は、返品処理を行います（モノの返品を伴わない場合は、クレジットメモ依頼により減額処理を行います）。
受注伝票作成
返品受注伝票の作成からスタートします。返品となるわけですから、元伝票である受注伝票 or 請求伝票をコピーして作ることが可能です。そうすることで、元の受注とのシステム的な繋がりができます。元伝票の番号が不明な場合は、一から返品伝票を打つこともできます。
入庫処理
返品入庫処理をすると自社倉庫に在庫が入庫されます。このときの移動タイプは標準プロセスでは、保留在庫の扱いとなります（移動タイプ651）。返品される商品＝故障しているという考えのため、出荷にブロックが掛かる在庫となります検査の結果、あるいは修理して、使用可能と判断すれば、在庫転送機能により利用可能在庫に転送します（移動タイプ453）。このタイミングで評価在庫としてカウントされます。
ちなみに、返品であっても最初から利用可能在庫として入庫したい場合は、納入日程カテゴリを分けて、利用可能在庫の移動タイプを設定しておく必要があります。
請求伝票作成
最後に、返品の請求伝票を作成します。標準プロセスでは、受注伝票を参照して請求伝票を作成します。これはモノの動きとは連動していないため、入庫していなくても返金プロセスを進めることが可能です。
【得意先返品ステップ】
1. 返品受注伝票作成（伝票タイプRE） T-Code:VA01
2. 返品出荷伝票作成 T-Code:VL01N
3. 入庫確認 T-Code:VL02N
4. 返品請求伝票作成 T-Code:VF01
以下の日経新聞の記事によると、2025年末までとしていた既存SAP ERPのサポート終了を2年間延長して2027年までとしたとのことです。https://www.nikkei.com/article/DGXMZO55314780W0A200C2000000/
そのため、新しいSAP S4 HANAへのシステム移行は2027年までに完了させるっ必要があります。
約1000社がこの壁に直撃するとのこと。SAP ERPを基幹システムとして導入している企業としては、せっかく高い導入コストをかけて構築したシステムを作り直すことになるため、難しい決断を迫られることになります。しかしながら、これは日本でフリーで働くSAPコンサルにとっては案件の増加、契約金のアップにつながる可能性があると思います。日本のシステム開発の業界は「キツい、キビシイ、帰れない」という3K業界というイメージが定着したため、最近の大学生の就職先として人気は低いです。そのため、これからを支える若手のITエンジニアは慢性的には不足しています。
また、SAPというシステムは基本的に追加開発なしで導入可能ですが、日本の大手企業は追加要件が多くて独自のアドオン開発（ABAPプログラム）が膨らむ傾向にあります。アドオンが多いことは業務に合わせるためユーザー観点ではの使いやすさは向上するのですが、システムバージョンアップ時には工数負担が大きくなります。特にS4 HANAは既存のSAP ERPと大きくシステムモデル、データ構造が変わっているため、アドオン機能は影響を受けやすいです。
様々な業界で人手不足が叫ばれる昨今の日本ですが、SAP業界でも今後ますます人手不足が加速するでしょう。新型コロナウイルスへの騒ぎが一段落した後には、システム開発需要は多くなルノではないかと思います。
SAP バックオーダ処理と再日程計画処理について
SAP SDの機能にバックオーダー処理（T-Code：V_RA）と再日程計画処理（T-Code：V_V2）という機能があります。この2つの機能は似たようなことができますが、どういった点に違いがあるかを整理したいと思います。在庫品販売のケースにおいて、自社倉庫に保管してある在庫数以上の注文が複数顧客から入ってきた場合を考えます。基本的にSAPでは受注伝票登録時に利用可能在庫確認（在庫の引当）を行いますから先に注文を受けた受注伝票から在庫を確保していきます。しかし、後からより重要な顧客から注文を受けた場合は、その重要顧客に向けて出荷してあげたくなりますよね。この問題に対処するために、バックオーダー処理や再日程計画処理を使うことができます。
バックオーダー処理（T-Code：V_RA）
バックオーダーとは、なんとなく単語からイメージできると思いますが、まだ在庫が割り当てられていないオーダーを意味します。バックオーダー処理はこの在庫が割り当てられていない受注伝票明細（オーダー）に対して、在庫を割り当てる作業を行います。割り当てるための在庫の元は、新たに入庫される在庫を待つか、すでに先に登録された受注伝票に割り当てられている在庫を引き剥がして、後に登録された受注伝票に再割当てすることができます。この処理は受注伝票に対して個別に行います。
再日程計画処理（T-Code：V_V2）
再日程計画処理は「品目コード」と「プラント」で検索してオープンな受注伝票明細に対して、在庫の再割り当てを行います。在庫再割当ての優先順位としては、デフォルトでは出荷優先順位、伝票登録日付 or 納期、伝票番号、明細番号となります。出荷優先順位は得意先マスタの販売エリア -> 出荷タブで設定できます。
つまり、すでに在庫が引き当てられているオーダーでもより出荷優先順位が高い顧客のオーダーや伝票登録日付の早いオーダーがあれば、在庫をそれらのオーダーのために使用するよう在庫の再引当処理を行います。
再日程計画処理はバックグランドジョブで定期的に処理している企業が多いと思います。
SAPでのサービス売上について
SAPで扱う品目というのは多くは製品や商品だと思いますが、サービス品目を作るケースもあると思います。例えば、PCメーカーであれば、アフターサービスのパソコンの修理などが考えられます。サービスの場合も通常の製品販売と同様に受注伝票を作る点では変わりません。その他、特徴は以下となります。
・サービス品目の明細カテゴリグループは「LEIS」（基本ビュー&販売組織2ビュー）
・受注伝票明細の明細カテゴリは標準機能では「TAD」（サービス）
・受注伝票から直接請求伝票を作成する（出荷伝票を作成しない）
また以前、品目タイプにある非在庫品との違いが気になりました。非在庫品は在庫管理しないというだけで、あくまでも「モノ」ですね。例えば、入庫してすぐに消費するネジや釘などがあります。これらは、すぐに消費されるわけですから、在庫としては数量も金額も管理されません。
SAP SDで発生する仕訳
SAP SDでは、どのような会計仕訳が発生するかについて整理していきたいと思います。SAPでは、各モジュール間で連携しているので、SD（販売管理）モジュールとデータを作るとリアルタイムにFI（財務会計）モジュールへ連携されていきます。販売システムと会計システムが個別にあると、リアルタイムには連携できませんね。SAPでは、以下の販売プロセスが基本的なもので、出庫確認時と請求伝票登録時に会計仕訳が発生します。
出庫伝票：自社倉庫から商品（製品）を出荷するタイミング。出庫確認というオペレーションにより伝票ができます。会計仕訳「売上原価 100/ 商品 100」
請求伝票：商品が顧客へ到着するタイミングで売上計上を行います。「売掛金 220 / 売上 200, 消費税 20」
このように、商品販売時に、在庫勘定から売上原価勘定へ振り替える売上原価対立法を使用しているため、商品の在庫状況がリアルタイムに分かります。また、売上と売上原価が計上されていることにより利益率を正確に求めることができます。
■SAPおすすめ書籍
