This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 28.999999999999996%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
如何使用write这个用法不太懂
SD関連トランザクションコード一覧
販売管理
受注
T-code |
名称 |
更新/照会 |
|---|---|---|
VA01 |
受注伝票登録 |
更新 |
VA02 |
受注変更 |
更新 |
VA03 |
受注照会 |
照会 |
VA05 |
受注伝票一覧 |
照会 |
V.02 |
不完全受注伝票一覧 |
照会 |
分納契約
T-code |
名称 |
更新/照会 |
|---|---|---|
VA31 |
分納契約の登録 |
更新 |
VA32 |
分納契約変更 |
更新 |
VA33 |
分納契約照会 |
照会 |
出荷
T-code |
名称 |
更新/照会 |
|---|---|---|
VL01N |
出荷伝票登録 (受注参照) |
更新 |
VL02N |
出荷伝票変更 |
更新 |
VL03N |
出荷伝票照会 |
照会 |
VL06F |
一般出荷一覧-アウトバウンド出荷伝票 |
照会 |
VL09 |
出荷取消 |
更新 |
VL10B |
出荷伝票登録 (発注参照) |
更新 |
VL10G |
今回出荷対象の伝票 |
更新 |
VLPOD |
出荷証明変更 |
照会 |
入荷
T-code |
名称 |
更新/照会 |
|---|---|---|
VL31N |
入荷伝票登録 |
更新 |
VL32N |
入荷伝票変更 |
更新 |
VL33N |
入荷伝票照会 |
照会 |
シップメント
T-code |
名称 |
更新/照会 |
|---|---|---|
VT01N |
シップメント登録（BKG登録） |
更新 |
VT02N |
シップメント変更（BKG） |
更新 |
VT03N |
シップメント照会（BKG） |
照会 |
VT11 |
シップメント選択: 品目計画（BKG） |
照会 |
VT70 |
出力: シップメント（S/I） |
照会 |
請求
T-code |
名称 |
更新/照会 |
|---|---|---|
VF01 |
輸出書類登録（INV・P/L） |
更新 |
VF02 |
請求伝票変更 |
更新 |
VF03 |
請求伝票の照会 |
照会 |
VF05 |
請求伝票一覧 |
照会 |
VF05N |
請求伝票一覧 |
照会 |
VF11 |
請求伝票取消 |
更新 |
VF31 |
請求伝票からの出力 |
照会 |
VFX3 |
ブロック中請求伝票一覧 |
照会 |
運賃
T-code |
名称 |
更新/照会 |
|---|---|---|
VI01 |
運賃登録 |
更新 |
VI02 |
運賃変更 |
更新 |
VI03 |
運賃照会 |
照会 |
VI05 |
運賃一覧 |
照会 |
得意先マスタ（Tr:VD01,Tr:XD01）
取引を開始するためには、まず得意先を登録する必要がある。
継続的な取引を行わないワンタイム取引先というものもあるが、基本的には企業間で一定額以上の取引を行うので、相手の信用力や継続的な関係維持のためにマスタ化して情報管理するのは必須となる。
品目マスタ（Tr:MM01）
品目の属性情報をあらかじめシステム上に登録しておくのが品目マスタ。マスタ登録をしておくことで、受注伝票に品目コードを入力するだけで、品目の属性や名称が伝票上に呼び出される。
SDでは販売管理タブを登録しておくことで受注伝票上で入力が可能となる。
販売価格マスタ（Tr:VK11）
本体価格や運賃、値引、消費税といった価格要素は、「条件タイプ」というカスタマイズで管理される。
条件タイプごとに条件マスタを設定し、販売組織・販売グループ・品目といった種々のキーごとに価格を設定することが出来る。
これがSDにおける価格のマスタとなる。
SDのカスタマイズ
受注伝票タイプ（Tr:VOV8）
販売プロセスの種類によって、伝票タイプを予め切り分けておく。
こうすることで取引別に画面の挙動や必要設定を切り分けたり、権限設定の切り分け、後々の集計などにも活用できる。
明細カテゴリ
取引の種類をさらに細分化するパラメータ。
例えば明細カテゴリには、標準明細（通常の取引で使用）、無償明細（譲渡などの取引で使用）、サービス明細、テキスト明細などがある。
明細カテゴリの中身は様々なパラメータがあり、特殊在庫からの引き当て（特殊在庫フラグ）とするか、請求の対象となるか（請求関連フラグ）、出荷処理を行う対象であるかどうか（出荷関連明細フラグ）、価格設定を行うかどうか（無償明細なら価格設定なし、など）、自動ロット決定を行うか、受注数量を常に1とするか、といった明細の挙動を決定するパラメータで構成されている。
出荷タイプ（Tr:0VLK）
出荷プロセスの種類によって、伝票タイプを予め切り分けておく。
受注伝票タイプと同様の切り分けとしても良いし、別体系としても良い。
取引別に画面の挙動や必要設定を切り分けたりするのは、受注伝票タイプと同様。
出荷明細カテゴリ（Tr:0VLP）
出荷数量に関わる設定（警告出力するかどうか）、利用可能在庫確認をするかどうか、ピッキング関連とするかどうかや、保管場所入力を必須とするかどうか、といったパラメータで構成される。
明細ごとの挙動に関わる設定を行う。
割当：保管場所（ピッキング）
出荷ポイント・プラント・保管条件をキーに、どの保管場所から在庫を取得するかを決定するためのカスタマイズ。
定義：請求伝票タイプ（Tr:VOFA）
「伝票タイプ」とある項目では、請求処理を行う際にバックグラウンドで起票される会計伝票を指定することが出来る。
価格決定表や出力決定表の設定を行う。
設定：請求伝票のコピー管理（Tr:VTFA）
受注伝票から引き継いで請求伝票を作成する際に、どの項目をどのように引き継ぐのかを設定する。
コピー管理は受注⇔請求、請求⇔請求、出荷⇔請求など、複数伝票間でのコピー管理が存在する。
定義/割当：価格決定表
価格決定において加味される諸条件をテーブルとして定義したもの。
各行が「条件タイプ」によって構成され、正味額、運賃、値引、消費税、総額、といった形で価格を決定するための要素が設定されている。
これらの明細行を加算あるいは減算するなどの計算式も設定することができ、そうした価格要素の総和として価格が決定される。
各行は「STEP」という項目により価格決定表上の明細の順位を指定し、例えば値引項目など総額算出をした後に適用される行は価格決定表の下方に配置する。
また、価格要素を手動で更新するかどうか、条件タイプを必須とするかどうか、表示用（統計）のみに使用する行か、といった設定も可能。
こうした制御を駆使して、複雑な価格決定要素をうまく並べて価格計算を行うのが価格決定表だ。
（条件テクニックという。上手く組める人は良いSDコンサルと言える）
更に勘定キーという項目もあり、FIに対してどのように連携するか（価格要素をどの勘定に転記するか）を制御できる。
割当：勘定コード
会計への連携の際に計上する勘定を制御できる。
どの項目を制御キーとするか、テーブルを定義できるが、たとえば条件タイプ・販売組織・勘定キーの組み合わせにてG/L勘定を割り当てることで、その条件の請求が転記された場合、当該のG/L勘定にてFI伝票を起票する。
SDのトランザクション
受注伝票（Tr:VA01）
受注を受けた場合は受注伝票を登録する。
受注伝票登録は、在庫の引き当て、あるいは生産や購買への所要量伝達、出荷や請求への処理につなげる起点となる。
受注伝票の登録・変更・照会は以下のトランザクションから行う。
・受注伝票登録 Tr:VA01
・受注伝票変更 Tr:VA02
・受注伝票参照 Tr:VA03
受注伝票は以下のトランザクションで一覧照会できる。
・受注一覧 Tr:VA05
次に受注伝票上の主要項目について解説する。
受注先
得意先コードを設定する。
どの得意先から受注したかを表す。
出荷先
得意先コードを設定する。
納品場所は、受注先の住所であるとは限らない。
得意先は通常、多くの拠点を持っており、どこに納入するかはオーダーによって異なる。
得意先発注番号
発注をしてきた得意先で使っている番号体系と、自社で使っている受注の番号体系は、当然異なる。
しかし、相手先のオーダー番号を控えておかないと、相手先からのどの注文に対して納品するのかが分からなくなってしまう。
よって得意先の方で使用している発注番号を、自社の受注伝票上も記録しておく。
品目・数量
言わずもがなではあるが、得意先が何をいくらオーダーしてきたかを入力する。
予め登録された品目マスタから諸情報を引っ張ってくるために、明細上に品目コードを指定する。
また、その品目コードについてどれくらいの量を得意先がオーダーしているのかを指定する。
明細カテゴリ
明細カテゴリには、標準明細（通常の取引で使用）、無償明細（譲渡などの取引で使用）、サービス明細、テキスト明細などがあり、その明細の目的に応じて適切な明細カテゴリを選ぶ。
実務運用上は、ユーザが困らないようにある程度、選ぶべき明細カテゴリは限定されている。
所要量タイプ（調達タブ）
所要量をどのように伝達するかを決定するパラメータ。
例えば通常の所要としてMRPに伝達する、あるいは所要自体を発生させない（MRPの自動計算対象などにならない）、独立所要量から受注所要量を削減する、特殊在庫として通常在庫の所要とはわける、などと言ったことが出来る。
出荷ブロック・請求ブロック
何らかの理由で、販売や出荷、請求をブロックしなければならない理由が生じた時に、ブロックを指定する。
このブロックを設定しておくことで後続処理に流れないようにする。
自動的に出荷を行う設定などにしている場合、ブロック設定によって自動処理が流れるのを防いだりする。
拒否理由
得意先からオーダーはあったものの、何らかの理由で失注するというのは、あまりいい話ではないが想定しておくべき事態でもある。
品質不良やキャンセル、競合他社に引き合いを取られるなど、そういった事態が発生した場合には販売伝票の明細に「拒否理由」を設定し、なぜ得意先から拒否されたのかを記録しておく。
与信管理
販売管理において重要なのが与信管理だ。
つどつど現金精算をしているのであれば「与信」という概念は不要だが、通常、企業間の取引は掛け売りとなる。
つまり相手が将来的に支払いをするという信用に基づいて取引しているわけだが、様々な理由からこの債権を回収できなくなる場合がある。
こうした時に備え、相手の信用力（企業規模であったりキャッシュフローや経営状況）に応じて、与信の上限を予め設定しておく。
（得意先マスタを登録するときに審査部門の通過プロセスを入れている企業もあるだろう）
受注伝票上でオーダーを入力した際、得意先に対して持っている債権の総額が与信の上限を超えた場合、警告やブロックをすることが出来る機能が、与信管理機能だ。
バリアント選定タブ・特性照会
明細に対して特性入力が可能となる。
その品目のスペック（色や形といったオプション）など、受注時の要件を入力する。
この特性の設定を活用することで、バリエーションごとに品目マスタを登録するといったことが不要になり、品目マスタレコード数が膨大になることを防ぐことが出来る。
伝票フロー照会
画面上部の伝票フロー照会を押すことで、受注伝票の後続として登録されている出荷や請求の伝票の紐づきを確認することができる。
出荷伝票（Tr:VL01N）
受注した物品を十分な数量確保できたのであれば、得意先に向けて出荷する。
出荷は受注伝票で指定した出荷先の住所に対して行われる。
受注伝票のメニューから「出荷伝票」を選ぶことでも登録画面に遷移できる。
諸情報は受注伝票から引き継ぐので、調整を頻繁に行う業務要件がなければ、ほとんどの主要項目は改めて入力する必要が無い。
参考：出荷伝票は以下トランザクションから一覧化可能。
・Tr:VL06F 出荷伝票一覧
明細ステータス
利用可能在庫確認や梱包、出荷や請求など、それぞれのステータスがどこまで進んでいるのか（未処理なのか、完了なのか）が表示される。
ロット分割
出荷ロットを出荷明細上で分割したい場合に使用する。
貿易管理/税関タブ
税関を通すために必要な書類や条件が揃っているかを管理できるタブ。
原産国や仕向国、輸出手続きや取引のタイプを設定できる。
システムステータスが表示されており、条件をクリアすると緑信号になる。
出庫確認ボタン
出荷伝票は保存しただけでは在庫の払出は起きず、出庫確認ボタンを押すことで初めて出荷される。
（参考）出庫取消（Tr:VL09）
取消を行いたい出庫があるときは、このトランザクションから出荷伝票番号などを指定して取り消しを行う。
請求伝票（Tr:VF01）
受注伝票をベースとして、債権が立てられる状態となった場合は請求伝票を登録する。
受注伝票のメニューから「請求伝票」を選ぶことでも登録画面に遷移できる。
諸情報は受注伝票から引き継ぐので、ほとんどの主要項目は改めて入力する必要が無い。
なお、請求伝票の一覧は以下トランザクションから確認できる。
・請求一覧 Tr:VF05
条件タブ
請求する金額およびその内訳が確認できる価格決定表が表示されている。
請求すべき金額に誤りが無いかをここで確認する。
請求伝票のリリース
請求伝票は登録しただけでは会計伝票の起票（FIへの連携）は起こらない。
リリース処理を行うことで、会計伝票がバックグラウンドで起票される。
リリース権限を部門責任者に持たせることで、これを請求の承認行為とすることもある。
バックオーダー（Tr:V_RA, Tr:V_V2)
受注伝票の在庫引き当てを行う、または調整する必要がある場合にバックオーダー処理を実行する。
バックオーダー処理には手動と自動（一括処理）が存在する。
・Tr:V_RA バックオーダー（手動）
・Tr:V_V2 バックオーダー（一括）
手動による在庫引当調整では、主に引き当て済みの在庫を別の受注伝票に付け替えるケースで使用する。自動（一括）の場合は在庫未引当の受注伝票が複数ある場合に一括で在庫引当をしたいケースで使用する。自動の場合は受注伝票の登録順に引当処理が走る。
販売管理に関わる知識
FIとの連携
出荷（出庫転記）や請求（リリース）を転記した際、バックグラウンドでFIに会計データが連携されている。この際の仕訳について解説する。
出荷の仕訳
出荷する際は会社の資産（棚卸資産）を売り先への移転させるので、即ち資産が減少する。
したがって、在庫の減少と、その減少分のコスト（損失）を仕訳する必要がある。
売り上げに伴い発生したコストであるから、相手勘定は売上原価となる。
売上原価 / 在庫
請求の仕訳
財やサービスを売ったことに伴い、得意先への請求という行為が発生する。
したがって、収益として売上を計上する必要がある。
また、得意先から売上分の金銭を貰う権利が発生するので、相手勘定として債権が増加する。
債権 / 売上
売上原価と売上の差額が利益になっている、というわけだ。
入金の仕訳
SDのプロセスではなく会計のプロセスになるが、得意先から入金があった場合の仕訳についても確認する。
債権が立った場合、支払いサイト（Xヶ月後支払）に応じて得意先が指定口座に入金をする。
入金が完了できた場合、債権を消し込んで、取引完了となる。
預金勘定 / 債権
預金残高が増え、債権勘定が減るため、上記のような仕訳となる。
ちなみに、大方の場合は入金されたデータをシステム連携して電子銀行報告書として計上する。
この場合、以下のように間に銀仮勘定を噛ませることになる。
・入金（電子銀行報告書）
預金勘定 / 銀行仮勘定
・債権と入金の消込
銀行仮勘定 / 債権
銀行仮勘定同士で相殺しあうので、最初に書いた仕訳と同じこととなる。
諸掛とは
取引を行う上で、本体の代金以外にも様々な費用が掛かる。
輸送コストであったり、海外との取引であれば通関に関わる費用であったり、各種保険であったりする。
そういった諸々の費用を諸掛と呼ぶ。
諸掛には大きく分けて、仕入諸掛と販売諸掛がある。
仕入諸掛とは仕入に際してかかった費用のことで、たとえば輸入取引であれば通関手数料や関税などがそれにあたる。
販売諸掛とは販売に際してかかって費用のことで、出荷時の梱包費や発送費用などを指す。
ピッキングについて
ピッキングにはいくつかの方式がある。
代表的なものがオーダー別ピッキングと品種別ピッキングだ。
・オーダー別ピッキング方式
摘取り方式あるいはシングルピッキングとも呼ばれ、オーダー（受注単位）ごとに作業者が保管場所を回り、必要な品目をピッキングする。
品種が多く、受注量が少ない場合はこの方式を採用する。
・品種別ピッキング方式
種まき方式あるいはトータルピッキングとも呼ばれ、オーダーを集約して品目ごとにまとめてピッキングし、あとからオーダー別に仕分ける。
品種が少なく、受注量が多い場合はこの方式を採用する。
さらに、この二つの利点を取り入れたのが、ウエーブピッキングと呼ばれるもので、WMS（倉庫管理システム）を導入している倉庫などで見られる方式。
SAP SDのカスタマイズでも「ピッキングウエーブ」というものがあるが、これに該当するカスタマイズだ。
（原語ではWave picksとなっているはずだが、なぜか単語が前後逆になっている）
Hi,
This is an English language forum, I suggest you transform the language to English. The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
２．販売伝票の構造について
SAPでは、販売関連の取引については、販売伝票として登録されます。これらは、 4 種類のカテゴリに分類されます。
・プリセールス伝票: 引合および見積
・受注
・基本契約および分納契約などの販売契約
・無償出荷、クレジットメモ依頼の元となる得意先の問題およびクレーム
販売伝票の構造としては、どの販売伝票も基本的に同一の構造を持っています。1つの伝票ヘッダがあり、その下に1行または複数行の明細があります。
1つの明細の中でも、1行または複数行の納入日程行を持つことができます。
ヘッダデータ、明細データについて、少し詳しくお話します。
■ヘッダデータ
SAPの販売伝票には、一般データと呼ばれる伝票全体に対して有効なデータがあります。伝票のヘッダデータに記録されます。
例えば、以下の通りです。
・受注先コード
その名の通り、受注先を示すコードになります。
・出荷先コード
販売伝票上の品目を、どこに出荷するのかを示すコードになります。
・支払人コード
販売伝票上の品目の支払いを行う取引先コードになります。
・伝票通貨
販売伝票上で用いる通貨を記録します。
・換算レート
会社コードの通貨とは異なる伝票通貨を用いた場合、その通貨との換算レートを記録します。
・納入日付
受注する品目の納入日付を記録します。
・出荷ポイント
受注する品目をどこに出荷するか、その場所と紐づく組織のコードになります。
・ヘッダテキスト
販売伝票ヘッダにテキスト情報を持たせることができます。
■明細データ
伝票ヘッダのデータが、伝票の全ての明細に適用されるのに対し、明細ごとに適用されるデータになります。このデータは明細レベルで保存され、主には以下の情報を含みます。
・品目コード
受注する品目のコードを記録します。
・目標数量
受注する品目がいくつなのかを記録します。
・出荷先コードおよび支払人
このコードの明細に対して、代替の出荷先または支払人を定義することができます。
・明細テキスト
販売伝票明細にテキスト情報を持たせることができます。
・納入日程行データ
1つの明細には､1つまたは複数の納入日程行が入力されます。納入日程行には納入に必要なすべてのデータが含まれます。例えば、得意先からある特定品目 20 個の注文を受けて、販売伝票に明細を 1 行入力したとします。
現時点で納入可能なのは 10 個のみで、残り 10 個の納入は来月になるため、出荷を 2つに分割して計画する必要があります。これらの出荷に関するデータ ( 日付、確認数量) は、2つの異なる納入日程行に保存されます。
納入データが関連していない販売伝票 ( 基本契約、クレジットおよびデビットメモ依頼など) には、納入日程行が登録されません。
納入日程行には以下のデータが記録されます。
・納入日程行数量
・納入日付
・確認数量
３．販売伝票の画面について
ここでは、販売伝票の画面構成についてお話します。
販売伝票は各画面、各タブで構成されており、大きく分けて以下の通りになっております。
概要画面タブページ : 販売、明細概要、受注先、調達、出荷、拒否理由
ヘッダ画面タブページ : 販売、出荷、請求、支払伝票、請求計画、勘定、条件、取引先、テキスト、購買発注データ、ステータス、追加データA 、追加データB
明細画面タブページ : 販売A、販売B、出荷、請求、国、条件、勘定設定、納入日程、取引先、テキスト、購買発注データ、ステータス、構成、追加データA 、追加データB
更に、それぞれの画面についてもう少し詳しくお話します。
■概要画面
概要画面では、伝票ヘッダに関するデータを選択することができます。表示領域に、その伝票に対する明細を含む領域があります。
この概要画面から、いくつかのタブページ間を切り替えることができます。タブページの販売には、伝票ヘッダの重要項目が含まれております。販売伝票の概要を把握するのに役立ちます。
概要画面は、カスタマイジングで、非表示にする項目を定義することができます。これによって、明細を表示するための領域がより大きくなります。
画面明細概要には、ヘッダデータの一部が表示されます。一部なので、明細に対して、より大きな領域を確保することができます。
受注先、調達、出荷、拒否理由のタブページには、それぞれ関連する領域のデータが表示されます。調達のタブページには、明細と納入日程行の両方が表示されます。
設定のタブページを使用して、ある 1つの明細に対する特性属性の概要を、素早く照会することができます。この照会機能は、比較的設定が単純な設定の品目、
必要不可欠な特性が頻出するモデルで作業を行う場合に特に役立ちます。
設定のタブページは、特性照会を更新した場合にのみ、販売伝票に表示されます。カスタマイジングでエントリが 1つもない場合、タブページは表示されません。
概要画面での特性照会に対する設定を参照するには、販売管理のカスタマイジングで、 販売管理 → 受注伝票 → 概要画面の特性照会を選択します。導入ガイド(IMG)で、詳細情報を照会することができます。
■ヘッダ画面
ヘッダ画面には、伝票ヘッダのデータが表示されるタブページが複数あります。
販売、出荷、請求伝票、および会計のタブページをそれぞれ表示することができます。
カスタマイズで追加できる画面については、”追加データ A” および ” 追加データ B” という 2つのタブページが用意されており、 ” 追加データ B” については、ユーザのニーズに合うように設計することが可能です。
■明細画面
明細画面では、伝票に対する1行または複数行ある個別の明細に関するデータが表示されます。この画面にも選択可能な複数のタブページが用意されています。
ヘッダ画面の場合と同様、明細画面のタブページを使用することにより、販売、出荷、請求という 3つの詳細画面の各データに直接アクセスすることができます。
他には、“販売 A” 、 ” 販売 B” 、 “出荷” 、 “請求” の各タブページ内で照会することができます。
販売データに対して 2つのページ ( 販売 A 、販売 B) が用意されており、小さな画面上でもタブページ全体を表示することができます。
カスタマイズで追加することのできる追加データは、”追加データA” 、”追加データB”の２つがあります。
■追加画面
概要画面、ヘッダ画面、明細画面に対して、販売伝票の全てのデータが表示されるわけではありません。
・納入日程行
納入日程行画面の納入日程行を参照するには、この画面を表示する代わりに、明細画面から納入日程行のタブページにジャンプして行うことができます。
(または、納入日程行テーブルの下にある拡大鏡をダブルクリックすることでも、同様の画面遷移になります。) この画面には、 1つの納入日程行に対する詳細情報が表示されます。
・分納契約
異なる納入日程計画のリリースタイプ (納入日程予測、ジャストインタイム納入日程、納入日程計画) を持つ分納契約リリースを、
1つの分納契約明細に、最大で3つまで割り当てることができます。各納入日程は、分納契約リリース (リリースヘッダ) の一般データと、納入日程内の納入日程行一覧から構成されます。
分納契約の明細には納入日程行がないので、他のタイプの販売伝票と違い、納入日程行に対するタブページは存在しません。
納入日程予測、ジャストインタイム納入日程、および納入日程計画に対するタブページがあります。これらのタブページは、分納契約タイプとは関係なく表示されます。
ページには現行の納入日程の概要が、ページ上部には納入日程ヘッダデータ、ページ下部には納入日程の納入日程行の一覧というように表示されます。
納入日程ヘッダ (納入日程予測およびジャストインタイム納入日程の場合のみ) および、納入日程行のいずれかのアイコンをクリックしても、詳細画面に遷移することができます。
メニューの補足を選択すると、出力画面などを含む他画面を照会することができます。
■従属画面によるデータの簡易入力
伝票データを素早く効率的に入力するには、受注ヘッダおよび明細に関する全ての重要な詳細データを直ちに入力し、それを一目で確認できることが重要です。
そのため、販売および明細詳細タブページが拡張されています。これらのタブページを使用し、ヘッダおよび明細についての詳細データを複写することができます。
従属画面では、ヘッダおよび明細に関する詳細データの全てを利用することができます。
SAP標準では、各項目を選択し、これらの従属画面に値を入力することができます。
なお、トランザクションバリアントの使用によって、従属画面にさらに詳細に項目を入力する、あるいは不要な項目を削除することができます。
これにより、ヘッダデータに対する入力領域の大きさや、個別に表示したい項目等を定義することができます。従属画面上の特定数の項目から、この画面領域に対するスクロールバーが自動的に作成されます。
トランザクションバリアントに対して、個別の受注タイプを割り当てることができます。
■ナビゲーション
メニューバーのジャンプを選択すると、概要画面、ヘッダ画面、明細画面間を素早く切り替えることができます。
操作の例として、概要画面からジャンプ → 明細 → 出荷を選択すると、明細画面に到達しますが、前面には出荷のタブページが自動的に表示されます。
アイコンによるナビゲーションとは対照的に、メニュー上のジャンプを使用すると、表示したいタブページを正確に指定することができます。
ダブルクリックで詳細画面に切り替えることができる領域は、強調表示されます。
これらの領域は、関連するオブジェクト上にカーソルを合わせた場合、そのカーソルが変形して表示されます。カーソルが変形したところでダブルクリックすると、
以下のオブジェクトに関する詳細情報が販売伝票処理時に呼び出されます。
・受注先または出荷先
受注先、または出荷先をダブルクリックすると、ヘッダの取引先タブページが表示されます。
・購買発注データまたは得意先発注番号
購買発注データ、または得意先発注番号をダブルクリックすると、ヘッダの購買発注データタブページが表示されます。
４．販売伝票の共通機能
ここでは、各販売伝票タイプ共通の処理の一部を紹介します。
■販売サマリ
必要な得意先の情報に関する迅速なアクセスを提供することで、販売サマリによるすべてのプリセールス活動の準備および最適なカスタマケアの提供を実現できます。
■販売伝票の削除
後続の伝票がない場合にのみ、販売伝票全体を削除することができます。
■販売伝票の明細削除
後続の伝票がない場合にのみ、販売伝票の個別明細を削除することができます。例えば、明細の出荷処理がすでに行われている場合、販売伝票の明細を削除することはできません。
■受注伝票明細の拒否
拒否理由は、 1つまたは複数の明細に入力することができます。これらの明細は、後続伝票にコピーされなくなります。
■受注先の変更
間違って入力した場合などのため、販売伝票を入力した後に、その伝票に割り当てられている受注先を変更することができます。
SAで受注を登録するには、まずトランザクションVA01を開き、受注を登録します。
次に、得意先からの受注を登録するために、受注タイプ（標準受注を表すOR）を入力します。
登録の概要
登録した指図に応じて、今すぐ販売組織と流通チャネルを入力するか、後で入力することができます。続行するにはEnterキーを押してください。
標準受注登録概要では、受注先と出荷先を入力する必要があります。受注先は商品を発注する顧客であり、出荷先は納入先の顧客です。たとえば、購買部門が注文を出しても、配達先は別の倉庫です。
して顧客のリストを開き、注文を出した正しい顧客を見つけることができます。
販売組織、流通チャネル、および部門が以前に選択されていない場合は、ターゲット組織で登録された得意先に対してのみ受注を登録することが可能であるため、この選択を今すぐ選択するように求められます。
得意先への受注番号である得意先参照、または受注を識別するための内部指図、および得意先が発注した日付、またはでの得意先参照を入力する必要があります。それは受け取られました。この日付は未来にはあり得ません。
品目データ
次に、受注の概要で、明細概要に製品詳細を入力します。
顧客が注文している品目を見つけ、顧客が注文した数量やこれらの製品の数量単位など、必要な情報をすべて入力します。
品目の説明は、品目マスタデータから自動的に取得されます。
商品の金額と通貨がそこに入力されます。それらは、カスタマイズされた製品標準価格および価格条件から自動的に計算されますが、その受注作成画面で更新することができます。
受注テーブルは次のとおりです。
VBAK、販売伝票：ヘッダデータ、
VBAP、SAP販売伝票：明細データ
VBSK、販売伝票の一括処理
VBSN、分納契約に関する変更ステータス
VBSP、品目モデルのSD伝票明細、
VBSS、一括処理：販売伝票、
VBUK、販売伝票：ヘッダステータスと管理、
VBUP、SAP販売伝票：明細ステータス、
VBRK、請求伝票：ヘッダデータ、
VBRL、販売伝票：請求書一覧、
VBRP、請求伝票：明細データ
VBAG、販売伝票：納入日程行別のリリースデータ、
VBBE、販売要件：個々の記録、
VBBPA、販売伝票：パートナ、
VBBS、SAP販売要求合計レコード
VBEH、納入日程履歴、
VBEP、販売伝票：納入日程行データ
VBFA、販売伝票フロー、
VBFS、一括処理のエラーログ
VBHDR、ヘッダー更新、
VBKA、セールス活動、
VBKD、販売伝票：ビジネスデータ、
VBKK、SD Doc.Export信用状、
内部テーブルの宣言
ステップ１：データ型の定義
始めのステップとして必要なのが内部テーブルの行を表す構造の定義です。内部テーブルを宣言するには、この構造定義を参照する形で宣言を行うのが一般的です。
以下に内部テーブル作成用の構造定義のサンプルコードを記載します。この例では、id,name,ageというカラムを持つ ty_employee という構造を定義しています。
* データ型の定義
TYPES: BEGIN OF ty_employee,
id TYPE i,
name TYPE string,
age TYPE i,
END OF ty_employee.
内部テーブルと構造は、どちらもABAPプログラムでデータを一時的に格納および操作するために使用されるデータ構造ですが、主な違いは以下のとおりです。
ABAP,変数,構造,内部テーブル
図1：変数 vs 構造 vs 内部テーブル
内部テーブルは複数の行と列から成り立つメモリ領域。一方で構造（ワークエリア）は単一の行のみから構成されるメモリ領域です。
内部テーブルの各行は、構造を使用して定義されることが一般的です。
さらに詳しく学習しておきたい方は以下の記事をご覧ください。
【ABAP】変数・構造・内部テーブル―データオブジェクトの違いを１分で解説
【初心者向け】ABAPの基本―。変数・構造・内部テーブルとは何か？３つのデータオブジェクトの違いを初めてABAPを勉強する方向けに図解します。
it-biz.online
2021.01.10
ステップ２：内部テーブルの宣言
ステップ１で定義した構造（データ型）を使用して内部テーブルを宣言します。
この際、内部テーブルのタイプ（標準テーブル、ソート済みテーブル、ハッシュテーブル）を指定することができます。
参考 内部テーブルの分類と特徴
* 内部テーブルの宣言（標準テーブル）
DATA: it_employee TYPE STANDARD TABLE OF ty_employee.
* ソート済みテーブルの宣言
DATA: it_employee_sorted TYPE SORTED TABLE OF ty_employee WITH UNIQUE KEY id.
* ハッシュテーブルの宣言
DATA: it_employee_hashed TYPE HASHED TABLE OF ty_employee WITH UNIQUE KEY id.
上記のサンプルコードでは標準テーブル（it_employee）、ソートテーブル（it_employee_sorted）、ハッシュテーブル（it_employee_hashed）の3種類の内部テーブルを宣言しています。
構造を定義せずに内部テーブルを宣言するパターン①
あまりおすすめできる方法ではないのですが、ステップ１の構造（データ型）を明示的に定義せずに内部テーブルを宣言するサンプルを以下に記載します。
* 内部テーブルの宣言（標準テーブル）
DATA: it_employee TYPE STANDARD TABLE OF ( id TYPE i, name TYPE string, age TYPE i ).
この例では、内部テーブルit_employeeの宣言時に直接フィールドとデータ型を指定しています。
ただし、この方法ではコードの再利用性と可読性が低くなるため、通常はデータ型を明示的に定義して使用することが推奨されます。
構造を定義せずに内部テーブルを宣言するパターン②
SAPの標準テーブルを参照して内部テーブルを宣言することができます。
これにより、既存のデータベーステーブルの構造を継承し、内部テーブルを定義することができます。以下に、SAP標準テーブル（例：MARA）を参照して内部テーブルを宣言する方法の例を示します。
* 内部テーブルの宣言（標準テーブル）
DATA: it_mara TYPE STANDARD TABLE OF MARA.
この例では、MARA（マテリアルマスタデータテーブル）を参照して、内部テーブルit_maraを宣言しています。
こちらはしばしば利用されるパターンで頭に入れておくと良いでしょう。
SAP標準テーブルを参照して内部テーブルを宣言する場合でも、必要に応じて標準テーブル、ソートテーブル、ハッシュテーブルのいずれかのタイプを指定することができます。ただし、内部テーブルの操作に特定のキーが必要な場合、適切なキーを指定して宣言する必要があるため注意しましょう。
ステップ３：ワークエリアの宣言
最後に内部テーブルに対して操作を行う際に使用されるワークエリアを宣言します。ワークエリアは、内部テーブルの行構造と同じデータ型です。
* ワークエリアの宣言
DATA: wa_employee TYPE ty_employee.
ステップ１～３をまとめて以下に記載します。
* データ型の定義
TYPES: BEGIN OF ty_employee,
id TYPE i,
name TYPE string,
age TYPE i,
END OF ty_employee.
* 内部テーブルの宣言（標準テーブル）
DATA: it_employee TYPE STANDARD TABLE OF ty_employee.
* ソート済みテーブルの宣言
DATA: it_employee_sorted TYPE SORTED TABLE OF ty_employee WITH UNIQUE KEY id.
* ハッシュテーブルの宣言
DATA: it_employee_hashed TYPE HASHED TABLE OF ty_employee WITH UNIQUE KEY id.
* ワークエリアの宣言
DATA: wa_employee TYPE ty_employee.
内部テーブルを宣言する際にワークエリアを必ずしも一緒に宣言する必要があるわけではありません。ただし、ワークエリアは内部テーブルの操作に便利なため、一般的には両方を宣言します。
ワークエリアは、主に以下のような目的で使用されます。
ワークエリアを同時に宣言する目的
内部テーブルへのデータの挿入や更新
ワークエリアを使用して、内部テーブルにデータを追加（APPEND文）や更新（MODIFY文）することができます。
内部テーブルからのデータの読み取り
READ TABLE文を使用して、内部テーブルからデータを読み取り、ワークエリアに格納することができます。これにより、内部テーブルのデータを個別に処理することができます。
内部テーブルのデータの削除
DELETE文を使用して、ワークエリアに一致するデータを内部テーブルから削除することができます。
ループ処理
LOOP文を使用して、内部テーブルのすべての行をワークエリアにコピーしながら繰り返し処理を行うことができます。
要するに、ワークエリアを使用することで、内部テーブルのデータを効率的に操作できる（ワークエリアを宣言せずに内部テーブルのデータを操作する方法も存在しますが、その場合、コードが複雑になり可読性が低くなる）ので、内部テーブルを宣言する際には、一般的にはワークエリアも一緒に宣言すると覚えておきましょう。
内部テーブルの宣言方法：まとめ
構造（データ型）定義後に標準テーブル、ソートテーブル、ハッシュテーブルのいずれかのタイプを指定して宣言。
同時にワークエリアも宣言しておくのが一般的。
* データ型の定義
TYPES: BEGIN OF ty_employee,
id TYPE i,
name TYPE string,
age TYPE i,
END OF ty_employee.
* 内部テーブルの宣言（標準テーブル）
DATA: it_employee TYPE STANDARD TABLE OF ty_employee.
* ソート済みテーブルの宣言
DATA: it_employee_sorted TYPE SORTED TABLE OF ty_employee WITH UNIQUE KEY id.
* ハッシュテーブルの宣言
DATA: it_employee_hashed TYPE HASHED TABLE OF ty_employee WITH UNIQUE KEY id.
* ワークエリアの宣言
DATA: wa_employee TYPE ty_employee.