リポジトリオブジェクトは変更履歴に対してバージョン管理ができます。

バージョンは開発データベース(リポジトリ)上のバージョンとバージョンデータベース上の履歴バージョンと2種類と大別されます。

開発データベース上では、MAXで「有効」と「修正」と2バージョンが存在います。

• 有効バージョン
  有効バージョンは現在のSAP環境に有効になっているバージョンというもので、端末に問わず、プログラムを実行する際に、このバージョンが利用されます。
• 修正バージョン
  修正バージョンは現在修正中のステータスが格納されます。

有効化すると、修正バージョンのステータスを持って有効バージョンが上書きされると同時に、修正バージョンが削除されます。 有効化した後に、再修正が発生しない限り、開発データベースに有効バージョンのみで、修正バージョンが存在しない状態になります。 修正バージョンでもすべてのユーザに見えます。

バージョンデータベース上のバージョンは以下のようなものがあります。

バージョンの登録はシステムによる自動登録とユーザによるマニュアル登録の2種類があります。

• システムによる自動登録
  バージョン管理の目的はリポジトリオブジェクトのすべての変更履歴を記録することです。 そのため以下のようなタイミングで自動的にバージョンが登録されます。
  • リポジトリオブジェクトが変更される前
    変更されたそれぞれのオブジェクトが変更依頼に入力された時点 バージョン管理の最新バージョンが有効でなければ、このオブジェクトのバージョンは、オブジェクトが変更される前にバージョン管理に保存されます。 このようなバックアップバージョンはバージョン概要に「 S 」 または 「 I 」で示されます。
  • 変更依頼のリリース時
    変更されたオブジェクトのある変更依頼をリリースすると、バージョンが登録されます。 依頼番号は関連バージョンのバージョン概要に表示されます。
• ユーザによるマニュアル登録
  自動的に登録されたバージョン以外にも、任意の時点で仮バージョンを登録することもできます。 それには、リポジトリオブジェクト更新トランザクションの バージョン登録機能を使用します。 また、これらの仮バージョンを使用して、仮バージョンが有効化された後でもオブジェクトの前バージョンを復元することもできます。 依頼がリリースされると、仮バージョンは削除され、その時点で有効なバージョンと置換されます。

バージョン管理機能は、オブジェクトナビゲータ ( SE80 )、移送オーガナイザ(SE01)といったトランザクションに組み込まれており、それを利用して下記のようなことができます。

• バージョンの一覧表示
• 指定バージョンの内容表示
• 指定された二つバージョンの比較

ローカルオブジェクトは変更履歴が取られない以外に、リポジトリオブジェクトの変更は全て変更依頼に記録されます。 変更依頼は依頼と略称することができ、必ずしも移送依頼に限ることがありません。

依頼は依頼タイプによって下記のように分類することができます。

• ローカル変更依頼
  ローカル変更依頼のリリースは、移送ファイルが作成されないため、移送は不可能です。
• 移送可能変更依頼(ワークベンチ依頼)
  リポジトリオブジェクトを変更すると、ワークベンチ依頼を指定するためのクエリウィンドウが表示されます。変更依頼にオブジェクトを割り当てている場合は、変更のみを保存することができます。　
  通常、ワークベンチ依頼とそのタスクは、全クライアントのリポジトリオブジェクトとカスタマイジングへの変更の記録に使用されます。ただし、クライアント依存カスタマイジングを取り込むこともできます。
  リポジトリオブジェクトへの変更を移送するかどうかは、そのオブジェクトのパッケージの現行 SAP システムからの移送ルートが定義されているかどうかによって決まります。このシステム設定から、変更依頼が移送可能か、また変更依頼がどの対象システムに移送されるかが自動的に判断されます。
• 移送可能変更依頼(カスタマイジング依頼)
  カスタマイジング依頼では、1クライアント(依頼のソースクライアント) で行われたクライアント依存のカスタマイジング設定が記録されます。
  クライアントのカスタマイジング作業での変更の自動記録は、クライアントごとに クライアント制御を使用して有効化または無効化することができます。自動記録が有効な場合は、カスタマイジング設定を変更するとクエリウィンドウが表示され、カスタマイジング依頼を指定するように要求されます。
  カスタマイジング依頼が移送されるかどうかは、ワークベンチ変更依頼と同様に、入力されるオブジェクトには 依存しません。 SAP システム ( 拡張移送制御を使用する場合はクライアント) のカスタマイジング依頼は、システム設定に応じてすべて移送可能またはすべてローカルになります。変更依頼が移送可能かどうか、移送可能な場合はどの対象システムに移動するかは、 標準移送レイヤ によって自動的に判断されます。ただし、この設定はマニュアルで変更できます。

修正可能かどうか、リリース済みかどうかによって、依頼ステータスが下記の二つに分けられます。

• 修正可能(未リリース)
• リリース済(修正不可)

タスクは依頼の下位要素であり、ユーザ名で表されます。 タスクタイプは下記の二つがあります。

• 修正
• 仮修正

SE01で移送オーガナイザで新たな移送依頼を登録することができます。 なお、プログラム改修などの場合、既存の依頼を選択や新たな依頼を作成するウィザードが提示される場合もあります。

依頼へのオブジェクトの取り込みは以下のようなパターンがあります。

• 完全自動　
  変更は自動的に依頼に記録されます。 プログラムやテーブル構造などの変更はこのパターンに分類されます。
• マニュアル
  オブジェクトを変更するトランザクションの一つの機能として動作します。 以下のようなオブジェクトはこのパターンに分類されます。
  • テーブルデータ SE16 データブラウザ画面で「テーブルエントリ→エントリ転送」機能を利用
  • 翻訳 SLXT
  • ロール PPFG
• 完全マニュアル
  変更対象オブジェクトのオブジェクトディレクトリを指定、全てのオブジェクトはこの方法で依頼に記録することができます。

• SE01 移送オーガナイザ
  以下の機能が含められています。
  • 依頼の登録、削除、マージ、属性変更、リリース及び一覧照会など
    オブジェクトの編集により、依頼を登録することもできます
  • タスクの登録、削除、属性変更、リリース及び一覧照会など
    オブジェクトの編集により、依頼にタスクを登録することもできます
  • オブジェクトの追加、削除、バージョンの照会など
    オブジェクトの編集により、自動的に追加されることがあります。
• SE03 移送オーガナイザツール

以下の図で、移送管理システムのモデル構成を示します。

このモデルでは、3階層ランドスケープが一つのドメインと二つの移送グループで構成されます。次にその構成要素をそれぞれ取り上げて詳しく説明します。

移送ドメイン(transport domain)は、移送を一元管理するすべてのABAPシステムで構成されます。移送ドメイン内では、すべてのシステムに一意のシステムIDを設定し、これらのシステムから1つのシステムのみが移送ドメインコントローラとして指定されます。 デフォルトの移送ドメイン名は DOMAIN_<SID> (<SID> はドメインコントローラのシステムID) で設定されます。 また、移送ドメインには、１つ以上の移送グループが含まれます。

移送ドメインコントローラ(transport domain controller)は、移送ルートや RFC 接続の設定など、移送ドメイン全体に関する設定を管理します。 通常は、本稼動システムまたは品質保証システムをドメインコントローラとして設定します。ドメインコントローラのシステム負荷は小さく、負荷が増えるのは TMS 設定変更時のわずかな時間だけです。 ドメインコントローラとしての役割をもつ ABAPシステムが稼動していないと、TMS 設定を変更することはできません。

移送グループとは、共通移送ディレクトリを共有する１つ以上のシステムで構成されるものです。

移送ディレクトリとは、移送データのファイルを保管するために移送グループで使用する共通ディレクトリのことです。 移送グループはこのディレクトリを使用して、すべてのエクスポートとインポートし、すべての移送はこのディレクトリで実行する必要があります。

移送ディレクトリのモデルサブディレクトリ構成は以下にようになります。 共通移送ディレクトリのサブディレクトリ

• bin
  tpとTMSの設定ファイル
• buffer
  各システムの移送バッファ
• data
  エクスポートされたデータ
• cofiles
  コマンドファイルまたは移送依頼情報ファイル
• log
  移送ログ、トレースファイル、統計。
• tmp
  一時データとログファイル
• actlog
  全タスクと全依頼のアクションログ
• sapnames
  各SAPユーザの移送依頼に属する情報
• EPS
  SAPサポートパッケージのダウンロードディレクトリ

移送ルート(Transport Route)は、ランドスケープを構成するSAPシステム（「開発システム」「検証システム」「本稼働システム」）間の移送順序を指定したものです。移送ルートは、コンソリデーションルートまたはデリバリルートのいずれかのタイプです。

標準的な3 システムランドスケープの移送ルートは以下のとおりです。

• コンソリデーションルート
  コンソリデーションルートは、開発システムと品質保証システムを接続します。。 自動的に作成される移送レイヤの名称は、Z<SID> (<SID> は開発システムのシステム ID)となります。
• デリバリルートは
  デリバリルートは、品質保証システムと本稼動システムの間に作成されます。

開発システムでは、コンソリデーションルートに対応する (標準) 移送レイヤとリンクしているパッケージのオブジェクトに変更を加えた場合、その変更は変更依頼に記録され、品質保証システムを経て本稼動システムに移送されます。

SAP社が提供するオブジェクト（＝標準オブジェクトと呼ぶ）への変更は、変更依頼に「仮修正」属性のタスクとして記録されます。この場合、移送レイヤとして“SAP”を使用することを除いて、他のオブジェクトの場合と同じ方法で移送することができます。

移送レイヤは、リポジトリオブジェクトの開発/変更を実施するシステムおよび、該当オブジェクトの移送先システム（品質保証システムや本運用システムなど）を定義します。

リポジトリオブジェクトは特定の「パッケージ」に属し、「パッケージ」に「移送レイヤ」が割り当てられます。

同じABAPシステムで開発され、同じ移送ルートで移送された開発プロジェクトは、すべてまとめられて 1 つの移送レイヤ となります。

各リポジトリオブジェクトのオブジェクトタイプには、以下のようなさまざまな移送属性があります。

リポジトリオブジェクトおよびクライアント非依存カスタマイジングオブジェクトがあります。

各リポジトリオブジェクトには、 オブジェクト・ディレクトリ・エントリがあります。移送属性もその中に登録されます。

オブジェクトを登録する時に、パッケージを指定するように要求されます。パッケージは移送レイヤに割り当てられます。 TMSで、現在のシステムからのコンソリデーションルートが移送レイヤに定義されていると、オブジェクトは移送可能な変更依頼のタスクに記録されます。 TMSで、現在のシステムからのコンソリデーションルートが移送レイヤに定義されていない場合、オブジェクトは ローカルな変更依頼に属するタスクに記録されます。

変更依頼が移送可能な場合、依頼の対象はオブジェクトのコンソリデーション対象と同じです。

オブジェクトのマスタシステムは、そのオブジェクトが登録されたオリジナルシステムであり、開発と修正のためのオブジェクトの編集もこのシステムで行います。

オブジェクトは、1 つのシステムにのみオリジナルが存在します。 SAPから提供されたオブジェクト の場合は、オリジナルのシステムはSAP側に保存されています。カスタマシステムにおけるSAP標準のオブジェクトはすべてコピーとなります。この原則は、開発システム、およびそれに続くすべてのシステムにも適用されます。

独自のアプリケーションを作成する場合には、作成するオブジェクトは、その開発システムに存在するものがオリジナルになります。 開発したものを変更依頼に割り当てる場合には、タイプを開発/修正となります。 この依頼によって、開発システムから次のシステムへオブジェクトが移送されます。

オリジナルに対して変更を加えることを修正といいます。 これらの変更は、タスクのタイプが開発/修正である変更依頼に記録されます。 コピー(オリジナルシステム以外のオブジェクト) に対して変更を加えると、その変更は、 仮修正のタスクに記録されます。 SAP オブジェクトに対する仮修正は、モディフィケーションと呼ば れます。

カスタマイジングオブジェクトのみです。

クライアント依存のカスタマイジングオブジェクトは、 カスタマイジング依頼に属するタスクに記録されます。 TMSで、現在のシステムからのコンソリデーションルートが現在のシステムまたはクライアントの標準移送レイヤに定義されている場合、オブジェクトは 移送可能なカスタマイジング依頼に属するタスクに記録されます。

TMSで、現在のシステムからのコンソリデーションルートがシステムまたは現在のクライアントの標準移送レイヤに定義されていない場合、オブジェクトは移送対象のないカスタマイジング依頼のタスクに記録されます。

NetWeaver ABAP Platformにおける変更はすべて依頼/タスクにより管理されます。変更が移送可能な場合に、依頼は変更の移送(リリース)単位となります。タスクは依頼よりも下位レベルに位置し、依頼のなかではユーザ名で表されます。

前述の移送管理システムのモデル構成を例として移送の流れを説明します。

1. 開発機DEVで依頼をリリース
   依頼の各タスクがリリースされたら、依頼自体もリリース可能になります。
   依頼がリリースされたら、移送分が移送ディレクトリにExportされます。
2. 品証機QTSTに移送をインポート
3. 移送を移送グループ１の移送ディレクトリから移送グループ2の移送ディレクトリにコピー
4. 品証機QAS2に移送をインポート
5. 本番機PRODに移送をインポート

• STMS 移送管理システム
  移送管理システム機能には以下の機能が含められています。
  • 移送ドメインにおけるSAPシステムの役割の定義
  • 移送ルートの設定
  • 移送ツールプログラム(tp)のパラメータプロファイルの設定
  • 移送ドメイン内のすべてのSAPシステムのインポートキューの表示
  • 品質保証システム（QA）の品質保証／承認手続の定義
  • インポートキューにある移送依頼のインポートのスケジュール
  • 共通移送ディレクトリを使用しない、システム間の移送の実行
• SE01 移送オーガナイザ(拡張ビュー)
  移送オーガナイザも変更オーガナイザもこの一つのトランザクションに統合されています。
• SE03 移送オーガナイザツール

拡張フレームワーク(Enhancement Framework)とは、、従来の拡張テクニック(カスタマExitやクラシックBAdiなど)をオブジェクト指向の手法で改良したフレームワークです。 拡張フレームワークでサポートされる拡張仕組は、「BAdiによるオブジェクトプラグイン」と「Enhancement Optionによるソースコードプラグイン」に大別します。 ここのBAdiは従来のクラシックBAdiと区別して、新規BAdiと呼ばれます。クラシックBAdiから新規BAdiに自動的に変換することができます。

拡張フレームワークを構成しているコンポーネントには下記のようなものがあります。 •Enhacement Spot •Enhancement Implementaion •Enhancement Option

Enhacement Spotは、拡張が実装できる位置を管理します。 オブジェクトプラグインとしてのEnhacement Spotは明示的に作成しなければならないほか、ソースコードプラグインとしてのEnhacement Spotは、Enhancement Optionを作成する際に一緒に作成されます。 オブジェクトプラグインEnhacement Spotの例ソースコードプラグインEnhacement Spotの例

Enhancement Implementaionは、拡張実装を表します。オブジェクトプラグインとしてのBAdiによる拡張実装と、ソースコードプラグインとしてのEnhancement Optionによる拡張実装とも含められます。

ソースコードプラグイン を記述する位置はEnhancement Option によって管理されています。 Enhancement Option には、「ソース中の位置」「拡張タイプ(動的/静的、Point/Section)」などの属性があります。

Enhancement Option には、明示的なものと暗黙的なものがあります。 暗黙的なものとは、すべてのリポジトリオブジェクトにあらかじめ組み込まれたもので、Enhancement Spot を必要としません。 明示的なものとは、開発者が独自に作成するもので、Enhacement Point文やEnhancement Section文などを使用し、明示的に作成位置を指定します。 Enhancement Point は「挿入型」の拡張で、指定した行位置に拡張コードが挿入されます。 Enhancement Section は「置換型」の拡張で、指定した行範囲のコードが拡張コードで置換されます。

拡張をサポートさせるには、拡張できるようにさせたいソースコードに事前に拡張の仕掛けを組み込む必要があります。 拡張フレームワークには以下三つの拡張方法が用意されています。

1. BAdiによる拡張
2. 明示的Enhancement　Optionによる拡張
3. 暗黙的Enhancement　Optionによる拡張

「暗黙的Enhancement　Optionによる拡張」は、サブルーチンや、汎用モジュールといったリポジトリオブジェクトのソース実装の開始及び終了の場所に全て予め組み込まれていますので、個別定義する必要がありません。

以下の手順で、BADIによる拡張仕掛けを作成することができます。

1. クラスビルダでBAdi用インタフェースを作成
2. Enhancement　Spotを作成
   SE80を利用します　
3. Enhancement　Spot　Defineを作成
   SE80を利用します
   Create BAdiを選択し、先ほど作成済のBAdi用インタフェースを指定
4. 拡張するソースコードにGET BADI、CALL　BADIを実装

以下の手順で、明示的Enhancement　Optionによる拡張仕掛けを作成することができます。

1. 拡張するソースコードにEnhancement-Point文又はEnhancement-Sectionを記述
2. 保存してウィザードに従いEnhancement　Optionを作成
   Enhancement　Optionを管理するEnhancement　Spotも同時に作成

オブジェクトキーの入手

対象となるオブジェクトの修正にはオブジェクトキーと呼ばれる特殊な キーワードが必要となります。

SE37やSE38、SE11などを利用して、オブジェクトを修正します。

次のようにオブジェクトキー要求があります。

このとき表示されるオブジェクト名を OSS で登録し、その結果取得された アクセスキーを入力します。 これはシステム（インストール）が異なると同じバージョンでも値が変わり ますので、毎回取得する必要があります。 また確認メッセージが表示されます。

外部リンク

• SAPソフトウェア変更登録 (SSCR) キーの登録(PDF)-SAP Help Portal

ABAPプログラムは以下のタイプがあります。

• タイプ1：レポートプログラム(公式では実行可能プログラムと呼ばれている)
• タイプM：ダイアログプログラム(公式ではモジュールプールと呼ばれている)
• タイプF：汎用グループ、汎用モジュールのコンテナとして、汎用モジュールを実装できる唯一のプログラムタイプ
• タイプK：クラスプール、クラス定義のコンテナ
• タイプJ：インタフェースプール、インタフェース定義のコンテナ
• タイプS：サブルーチンプール、サブルーチン用のコードコンテナ
• タイプT：タイププール、型定義のコンテナ
• タイプI：インクルードプログラム

Dynpro画面を持つことができるのは、タイプ１、タイプM、タイプFの三つのみです。

プログラムタイプによってプログラムの基本的な技術属性が決まるため、プログラム作成時にタイプを設定する必要があります。

ABAPプログラムは直接実行可能プログラムと直接実行不可能プログラムに分類されます。Windowsアプリケーション開発の世界でこれに相当するのはEXEとDLLの分類になります。

ABAPプログラムを直接実行するには、二つの方法があります。

• トランザクションコードによる実行　
  トランザクションコードにより実行可能なプログラムは、レポートプログラム(TYPE 1)、ダイアログプログラム(TYPE M)、汎用グループ(TYPE F)があります。
  プログラムでは、CALL TRANSACTION やLEAVE TO TRANSACTIONといった命令を使ってトランザクションを起動することができます。
• プログラム名による実行
  SA38又はSE38でプログラム名により実行可能なプログラムは、レポートプログラム(TYPE 1)のみになります。バックグランドでも実行できるのもこのタイプのみです。
  プログラムでは、SUBMIT命令を使ってレポートプログラムを起動することができます。

直接実行可能プログラムはアプリケーションプログラムとも呼ばれます。

直接実行不可能プログラムは、プログラミングでしか呼び出されることができません。タイプによって呼び出す命令はそれぞれです。

• CALL FUNCTION : 汎用モジュール
• CALL METHOD　 : クラスのメソッド　
• PERFORM : サブルーチン

• データ型定義：オブジェクトのデータ定義はABAPディクショナリにのみ存在する
  • ドメイン
  • データエレメント
  • 構造
  • テーブルデータ
• データベースオブジェクト：オブジェクトのデータ定義は基盤となるデータベースにも自動登録される
  • テーブル
  • ビュー
  • 索引
• ツール関連： Dynpro 項目の編集に使用されるツールも提供
  • 検索ヘルプ
  • ロックオブジェクト

ABAPディクショナリオブジェクトは、ABAPプログラムから参照できます。実行時にABAPプログラムがロードされる際に、動的にABAPディクショナリオブジェクトの定義を展開されます。

以下にて各オブジェクトタイプをそれぞれ説明します。

ドメインは項目の技術属性を定義するものであり、項目のデータ型と長さを指定することで項目の値範囲を記述します。 例として、「性別」のドメインの定義を次に示します。

• 参考サイト：SAP Portal Help--ドメイン

データエレメントは意味属性であり、同じ意味を持つデータ項目は同じデータエレメントに割り当てるべきです。

下記の例を利用して、データ項目、データエレメント、ドメインの関連関係を説明します。

上記のテーブルに示された四つのデータ項目とも10文字の伝票番号であるため、同じドメインのVBELNを割り当てられます。但し同じ伝票番号といっても、請求伝票の伝票番号と受注伝票の伝票番号と二種類があるため、データエレメントは二つに分かれることになります。同じデータエレメントのデータ項目であれば結合検索できます。

• 参考サイト：SAP Portal Help--データエレメント

構造は複数のコンポーネント(項目)で構成されます。構造を構成するコンポーネント(項目)は、基本データ型の他に別の構造やテーブルデータ型を参照することができます。

• 参考サイト：SAP Portal Help--構造

テーブルデータ型は、ABAPにおける内部テーブルをグローバルで定義します。

• 参考サイト：SAP Portal Help--テーブルデータ

ABAPディクショナリのテーブルには、3種類のテーブルタイプが存在します。

1. 透過テーブル
   例：「VBRK」KNA1(得意先マスタ)など、殆どのテーブルです。
   透過テーブルは名前の通り、ABAPディクショナリと同じ構造で、DBテーブルが登録されています。
2. プールテーブル
   例：「Annn」条件マスタや「T001T」カスタマイズテーブルなどなど、テーブルプールに割り当てられたテーブルのことです。テーブルプールには、複数プールテーブルが格納され、DB上は、テーブルプールにデータが登録されています。
   複数のプールテーブルのデータが、どのようにテーブルプールに登録されているかというとプールテーブルの1行1行が、それぞれテーブルプールの1行となっていて、内部結合ではなく、単純に複数のテーブルがまとまっているだけです。
   
   
3. クラスタテーブル
   クラスタテーブルとは、例：「BSEG」会計伝票明細のようにテーブルクラスタに割り当てられたテーブルのことです。テーブルクラスタには、複数クラスタテーブルが割り当てられ、DB上は、テーブルクラスタにデータが登録されています。
   
   

クラスタテーブルとプールテーブルは、透過テーブルと違って以下の特徴が存在します。

• NativeSQLでは使用できません。
• Select文で、外部結合・内部結合できません。
• キー項目以外の項目は、ほとんどが文字列結合された状態で1項目に登録されています。
• 上記理由により、キー以外の項目を抽出条件とするとパフォーマンス悪化の要因になります。

クラスタテーブルかプールテーブルかによって、プライマリキーがかさなっている複数テーブルが存在する場合、そのデータの登録方法は異なります。

• クラスタテーブル　
  プライマリキーで内部結合された状態で複数テーブルがまとまって登録されています。
• プールテーブル　
  プライマリキーで内部結合せず単純に複数テーブルがまとまって登録されています。

テーブルには出荷クラス属性をもっております。出荷クラスは、インストールやアップグレード、クライアントコピー、およびカスタマシステム間移送の際に、テーブルデータの移送を制御します。出荷クラスは、拡張テーブル更新でも使用されます。

以下の出荷クラスがあります。

ABAPディクショナリに透過テーブルを定義する際、技術設定を更新する必要があります。

• データクラス
  データクラスは、テーブルを格納するデータベースの物理領域 (ORACLE では表領域と呼ばれます) を論理的に定義したものです。データクラスを正しく選択すれば、テーブルを ABAPディクショナリで有効化したときに、そのテーブルがデータベースの正しい領域に自動的に登録されます。
  データクラスには、マスタデータ、トランザクションデータ、組織データ、およびシステムデータなどがあります。さらに、カスタマデータクラス (USER、USER1) と呼ばれるデータクラスもあります。これは、カスタマ開発に使用されます。データベースに特別な保管域を割り当てる必要があります。
  • マスタデータ　
    マスタデータは、ほとんど変更されることのないデータです。マスタデータの例としては、名称、住所、および電話番号など、住所のデータが挙げられます。
  • トランザクションデータ　
    トランザクションデータは、頻繁に変更されるデータです。たとえば、倉庫の在庫品目は購買発注が登録されるたびに変更されるデータです。
  • 組織データ
    組織データは、システムの導入時にカスタマイジングで定義され、その後はほとんど変更されることのないデータです。たとえば、国コードなどです。
  • システムデータ
    システムデータは、SapECCシステム自体が必要とするデータです。たとえば、プログラムソースなどです。
• 􀂄バッファリング
  テーブルのレコードをバッファに入れるかを定義します。
• サイズカテゴリ　
  テーブルの予想レコード数はいくつかを定義します。
• ログ記録　
  データレコードへの変更ログを記録するかを定義します。

• 参考サイト：SAP Portal Help--テーブル

ビューとは、1つ以上の実テーブル表から任意のデータを選択し、それらをカスタマイズして表した仮想テーブルのことです。

• 参考サイト：SAP Portal Help--ビュー

索引は、いくつかの項目に縮小されたデータベースのコピーということができます。索引を使用すると、特定の検索条件を満たすデータレコードをテーブルから検索することができます。

• 参考サイト：SAP Portal Help--索引

検索ヘルプは、入力ヘルプ (F4 ヘルプ) を定義するための ABAPディクショナリオブジェクトです。

• 参考サイト：SAP Portal Help--検索ヘルプ

DBトランザクションレベルの排他制御はデータベース管理システムが用意していますが、それとは別に、SapECCは、独自のロックオブジェクトに基づいてアプリケーションレベルの排他制御を実現しています。

ロックオブジェクトにはロックするテーブルとロックするレコードのキー項目情報が定義され、ロックオブジェクトを有効にすると、汎用モジュールENQUEUE_<ロックオブジェクト名>とDEQUEUE_<ロックオブジェクト名>がロックを設定 / 解除するためにその定義から生成されます。

ロック設定汎用モジュールから掛けられたロックの情報はロックテーブルに格納されます。ロックテーブルは、エンキューサーバのメインメモリに存在するテーブルであり、システム内の現在のロックを記録します。ロック設定汎用モジュールでロックを掛けようとする前に、まずロックテーブルを参照して同じロックが既に存在する場合、エラー終了したり、待ち状態にしたりすることによって、排他制御の仕組みを実現します。

• 参考サイト：SAP Portal Help--ロックオブジェクト

リポジトリに格納される全ての開発オブジェクトは、アプリケーションコンポーネント→パッケージ→開発オブジェクトというカテゴリ構造で管理されます。

アプリケーションコンポーネントはアプリケーション階層にツリー構造で表示されます。SE81でアプリケーション階層を照会することができます。

上記の図から馴染みのSDやMMなどのアプリケーションコンポーネント名称を読み取ることができます。アプリケーションコンポーネントは公式名称ですが、実際には別名の「モジュール」のほうがよく使用されています。

パッケージはリポジトリオブジェクトをカテゴリ化で管理できるようにする仕組みです。SE21(パッケージビルダ)でパッケージを照会又は定義することができます。 パッケージとは、意味的に関連する開発オブジェクトのコンテナであり、以前の開発クラスにかわったものです。1つのパッケージに、異なる開発オブジェクト(プログラム、テーブル、Dynpro、汎用モジュール、クラスなど)を含めることができます。。パッケージの特徴は、プロパティのネスト、インタフェース、可視性、およびアクセス管理にあります。。 パッケージはパッケージビルダ(トランザクションSPAK)を使用して作成および管理される。また、オブジェクト変更の記録と移送は、パッケージへの割当を使用する移送/修正システム(CTS)によっても管理されます。 以下の図でパッケージMBを例として取り上げます。

リポジトリオブジェクトはSE84(リポジトリ情報システム)で検索できます。

リポジトリオブジェクトは主に以下のような大分類があります。

• ビジネスオブジェクト
• ABAPディクショナリ
• プログラム
• クラス
• WebDynpro

オブジェクトディレクトリは、全てのリポジトリオブジェクトに基本属性情報を管理します。

リポジトリ情報システムに格納される各リポジトリオブジェクトはその種類の抜粋を下記の表で示します。

• ビジネスロジックもデータベース化
• クライアントによる論理分割
• ダイアログを跨る作業論理単位

NetWearver ABAP Platformでは、ビジネスデータのみではなく、ビジネスロジックが反映されたアプリケーション及びパラメータ設定情報そのものもデータベースで統合的に管理されます。 NetWearver ABAP Platformのデータベースにおけるテーブルは、出荷クラスによって以下のように分類されます。

SapECCシステムはクライアントによって論理的に分けられます。 実体となる1つのシステム上に、自由に複数のクライアントを定義できて、仮想的に複数のシステムが存在しているかのように扱うことができるのです。 各クライアントには、独自のデータ環境があり、すなわち、クライアントごとに独自のアプリケーションデータと殆どの設定データがあります。 あるクライアントに属するデータは、他のクライアントのユーザからアクセスできないような仕組みになっています。この仕組みを実現するためには、以下のような仕掛けが掛けられています

• クライアント依存テーブルに全てクライアント番号を第1PKとして持たせる
• OpenSQLによるDBアクセス処理で対象クライアント制御条件を裏で自動的に付加する

クライアントは3桁の数字で識別されます、インストール時のデフォルトクライアントは以下の通りです。

普通の意味では、アプリケーションの動作のうち、「ある意味を持った一連の処理のまとまり」のことをトランザクションといいます。そして、トランザクション制御とはこの一つのトランザクション内でデータの整合性が保たれるようにすることです。

SapECCでは、正式的な名称として、この「ある意味を持った一連の処理のまとまり」を「トランザクション」ではなく、「作業論理単位(Logical Unit of Work、略するとLUW)」と呼んでいます。関連がありますが、SapECCの「トランザクション」は、トランザクションコードを使用して開始するアプリケーションプログラムのことと定義されています。

SapECCでは、DBMSが実装済のトランザクション制御の他に、業務レベルの作業論理単位制御をサポートしています。この二つの制御は、それぞれDB LUWとSAP LUWに呼ばれます。

DB LUW は、データが常に整合性を持つようにするために、OracleやMSSQLなどのDBMS(データベース管理システム)が使用するメカニズムです。DBMS側では、一般的にこのDB LUWを「トランザクション」と呼びます。

SAPのDB LUWは、以下のように動作します。

• DB LUWは一つのワークプロセスの中に完結しなければなりません
• ワークプロセスが正常又は異常終了する際に、コミットされていないDB更新に対して、暗黙的なデータベースコミット又はロールバックを行います
• プログラムが汎用モジュールDB_COMMITを呼び出して明示的にデータベースコミットを行うことができます。
• プログラムがSAP LUWの命令（COMMIT WORK、ROLLBACK WORK）を呼び出してSAP LUWを終了する同時に、DB LUWも終了します。
• 開始されるときや、前のDB LUW がコミット又はロールバックで終了するときに、新しいDB LUWが開始されます。
• DB LUW内で実行されるDB変更はでDBロックを起こします、そのDBロックはLUWの終了に伴い、自動的に解放されます。

DB LUWはデータベースに対して分割できない連続したデータ上の操作であり、完全に終了するか、まったく実行しないかのいずれかにする必要があります。SAP LUWは、システムに対して分割できない業務処理であり、その業務処理全体を完了するか、あるいはまったく実行しないかのいずれかにする必要があります。SAP-LUW は通常、複数のダイアログステップや複数のDB LUW に及ぶことがあります。 同じSAP LUW で発生したDBデータ変更要求は、全て最後にデータベースに反映されることになります。

SAP LUWは、DB LUWのように暗黙的に終了することがありません。「COMMIT WORK」や「ROLLBACK　WORK」命令を発行して、明示的に終了させる必要があります。

一つのSAP LUWの中の各更新は複数のダイアログステップに跨って発行されることがよくありますが、発行時に即時に実行されるとすれば、別々のDB LUWのDBデータ操作になりますので、作業単位としての原子性が完全に崩れてしまうことになります。

NetWeaverABAPでは、それらの更新を即時実行せずに、「更新依頼」オブジェクトを登録しておきます。「commit work」命令でSAP LUWがコミットされる際に、登録された「更新依頼」を一つのDB LUWで実行することにより、作業単位としての原子性を維持します。

SAP LUW毎に、違う更新キーが割り当てられます、更新依頼はその更新キーと一緒に更新キューに登録されますので、それにより同じSAP LUWのものかどうかを判断できます。

アプリケーションプログラム( TYPE 1、TYPE M)はそれぞれ別のSAP LUWをもっています。但し、トランザクション(機能)ではなく、「ダイアログモジュール」として起動される場合は、呼び出し元のSAP　LUWで実行されることになります。

NetWeaverABAPではワークプロセスごとに、固定DB接続1 つが割り当てられています。そのDB接続でDB LUWが実行されますので、ワークプロセスは常に一つのDB LUWと結び付いております。

ABAPプログラムの画面技術は、後からWEB対応のWebDynproも追加されましたが、従来からDynproを使ってきました。SapECCシステムで利用されている標準画面は、全てDynproで構成されています。 Dynpro画面はSapGUIウィンドウに表示されます。SapGUIは、SapECCシステムへのユーザインタフェースです。SapGUIはABAPアプリケーションサーバと通信し、ABAPアプリケーションからレスポンスされたプレゼンテーションを表示し、またユーザからの入力を処理し、そのアクションをABAPアプリケーションへリクエストします。

一般的な SapGUIウィンドウは以下のようなUIパーツから構成されます。

• メニューバー
• システム機能バー
• 表題バー
• アプリケーションバー
• Dynpro領域
• ステータスバー

下記の図でSapGUIウィンドウのレイアウト構成を示します。

Dynproは主に、Dynpro属性、画面レイアウト、エレメント一覧、PBO、PAIから構成されます。

• Dynpro属性
  Dynproが持つ基本情報です。Dynpro番号、Dynproタイプ(標準・従属画面・ダイアログボックス・選択画面）、後続Dynproなどがあります。
• 画面レイアウト
  画面のレイアウト情報です。各UIエレメントの位置やサイズを定義します。
• エレメント一覧
  Dynproが持っている各UIエレメントの詳細です。
• PBO
  Process Before Output、Dynpro画面が表示される前の処理を行う処理ブロックです。
• PAI
  Process After Input、Dynpro画面が表示され、ユーザがアクションを行った後の処理を行う処理ブロックです。

NetWearver ABAP Platformは、ABAPアプリケーション内に独自のスプールリングおよび印刷システムを提供しています。これはすべての印刷機能への統一的なインタフェースとなっています。

ABAPアプリケーションとプリンタの接続形式には以下の３つの方法があります。

• アプリケーションサーバのローカル接続 (アクセス方法 L, C)
• lpd hostを経由したリモート接続 (アクセス方法 U)
• PC と SAPlpdを経由したリモート接続 (アクセス方法 U or P)

ABAPアプリケーションのスプール管理は「トランザクションコード：SPAD」から管理・定義が可能です。

ABAPではアプリケーションは公式的にトランザクションと呼んでおり、リポジトリオブジェクトとして、トランザクションコードにより識別して起動されます。 一方、ABAPプログラムは実行可能なコードが含められるリポジトリオブジェクトであり、その中に、タイプ1(レポートプログラム)、タイプM(ダイアログプログラム)、タイプP(汎用グループ)はトランザクションに割り当てることができます。トランザクションに割り当てる時に、トランザクション起動時に実行されるプログラムのエントリが指定されます。

SapECCシステムは、基幹業務向けのERPパッケージソフトウェアであるため、殆どダイアログ実行型アプリケーションから構成されますが、運用によっては、一部の対話型アプリケーションもバッチ実行型に変更して、タイマなどのトリガーにより、バックグラウンドでで実行させることができます。

ABAPアプリケーションは、ダイアログ実行かバッチ実行かに問わず、すべてAS APAPのワークプロセスに対して、 AS APAP内で実行されます。 以下の図で、アプリケーションのダイアログ実行イメージを示します。

サーバへログインすると、ユーザに1 つの 「SAPguiセッション」が開かれます。また、ユーザが同時に最大6つのウィンドウを開くことができます。これらのウィンドウはそれぞれ、アプリケーションサーバ上で共有メモリの専用領域を使用する「メインセッション」に対応しています。図：メインセッション

メインセッションは一つ以上の内部セッションから構成されます。メインセッションで起動した最初のアプリケーションプログラムによって、メインセッション内の最初の内部セッションが開きます.

メインセッションで起動された各プログラムは同じSAPメモリを共有しています、つまりSAPメモリを通せば、データの受け渡しが可能です。

アプリケーションプログラム(TYPE 1、TYPE M)が呼び出されるたびに、新しい内部セッションが作成されます。 その他プログラムは新しい内部セッションを作成することがなく、必ず呼び出し元のアプリケーションプログラムの内部セッションで動作します。

• システムアーキテクチャー
• ソフトウェアアーキテクチャー
• アプリケーションアーキテクチャー
• パッケージアーキテクチャー

NetWeaver ABAPは基本的にSapECCの技術基盤として出荷されるため、SapECCを代表として、NetWeaver ABAPシステムの各アーキテクチャー構成をそれぞれ説明します。

システムアーキテクチャーはソフトウェア、ハードウェア、ネットワークを含め、情報システム全体の構成を示すものです。システム構成と呼ばれることがよくあります。 システムの構築開発作業を行う場合によく最初から作成されるシステム構成図はシステムアーキテクチャーを示すものだと考えられます。

SapECCは、導入企業によってシステムアーキテクチャーが異なりますが、殆どはSAP推奨の開発機→検証機→本番機を分離する3システムランドスケープに従っています。SapECCはシステムの稼働だけではなく、開発と検証も対象領域として統合して管理しています。下記はそのイメージ図です。

ソフトウェアアーキテクチャーとは、情報システムにおける各ソフトウェアの構成を示すものです。 情報システム特にWEBベースのシステムのソフトウェアアーキテクチャーは論理的に階層化されたものがおおいです。

SapECCのソフトウェアアーキテクチャーは、データベース、アプリケーション、プレゼンテーションの3階層のクライアントサーバシステムになっております。以下の図でSapECCのソフトウェアアーキテクチャーを示します。

NetWeaverアプリケーションサーバは、ABAP環境とJAVA環境の両方をサポートしており、それぞれ利用タイプAS ABAPとAS JAVAとして利用することができます。 以下の図でNetWeaverアプリケーションサーバのアーキテクチャ構成を示します。

以下の図で、ABAPアプリケーションサーバの構造を示します。

• ワークプロセス
  ワークプロセスはアプリケーション(すなわち1つのダイアログステップ) を実行することのできるコンポーネントです。
  J2EEにおいては、アプリケーションサーバの実行スレッドに相当します。　　
• ディスパッチャ　
  ディスパッチャは、ダイアログステップに対するリクエストを SAPgui から受け取って、それを空いているワークプロセスに転送します。J2EEにおいては、アプリケーションサーバ：ディスパッチャスレッドに該当します。
• ゲートウェイ
  ゲートウェイは、ECC通信プロトコル (RFC 、CPI/C) のインタフェースである。ゲートウェイは、同じ ECCシステム内の他のアプリケーションサーバと通信したり、他の R/3 システム、R/2 システム、または非 SAP システムと通信したりすることができます。
  J2EEにおいては、クライアントとアプリケーションサーバとのHTTP通信チャンネルに該当します。

以下の図で、ABAPアプリケーションサーバのワークプロセスの種類を示します。

• ダイアログ・ワークプロセス
  ダイアログ・ワークプロセスは、ユーザからのリクエスト（ダイアログステップ実行依頼）を実行します。
• 更新ワークプロセス
  更新ワークプロセスは、データベース更新依頼を実行します。更新依頼は SAP LUW の一部であり、ダイアログワークプロセスの結果として生じたデータベース操作群を 1 つのバックグランド処理用データベースLUW にまとめたものです。
• バックグランド・ワークプロセス
  バックグランド・ワークプロセスはユーザ・インタラクションなしで実行できるプログラム (バックグランドド・ジョブ) を処理します
• スプール・ワークプロセス
  スプール・ワークプロセスは、要求された内容を順次にプリンタなどの出力設備に出力します。スプール・ワークプロセスはアプリケーションサーバ毎に一つのみ存在します。
• エンキュー・ワークプロセス
  エンキューサーバは、SapECCシステムに一つのみ存在し、アプリケーションサーバ間の処理同期を管理します。

アプリケーションサーバは、起動する際に、ワークプロセスを必要な数量分全て作成しておきます。何かの処理が実行する必要になるときに、ディスパッチャにより、空いているワークプロセスの中から一つを割り当てられます。処理が終わったら該当ワークプロセスがまた空き状態に戻り、次の割り当てを待ちます。

SAPguiは、SapECCシステムをアクセスするためのフロントエンドソフトウェアであり、WebシステムにおけるWebブラウザと同様にThin-Clientの上に動作します。

SAPguiは、SapECCシステムのアプリケーションサーバである「NetWeaver Applicatiion Server ABAP」と通信し、サーバ上に動作しているABAPプログラムからレスポンスされたプレゼンテーションを表示し、またユーザからの入力を処理し、そのアクションをサーバへリクエストします。

SAP GUIにも以下の三種類あります。

• SAP GUI for Windows
  Windowsで動くクライアントソフトウェア。
• SAP GUI for Java
  Java環境で動くクライアントソフトウェア。
• SAP GUI for HTML　
  HTMLでアプレットとして動く

一番一般的なのは「SAP GUI for Windows」です。　　

SAPgui画面のメニューは大体下記のようなものから構成されます。

• システム固有
  • システムメニュー
    セッション開始やユーザ設定、ログオフといった、システム全体に影響する機能が含められます
  • ヘルプ
    さまざまな形式のオンラインヘルプが提供されます
• アプリケーション共通
  • オブジェクト
    品目など、通常は現在作業中のオブジェクト名をとって名付けられます。照会、変更、印刷、または終了など、オブジェクト全体に影響する機能が含まれます
  • 編集
    選択、編集、コピーなど、現在のオブジェクトの構成要素を編集することができます。
  • ジャンプ：　　　　　現在のタスクと関連する他の画面に直接移動することができます。
• アプリケーション固有
  実行中アプリケーション固有の機能が含められるメニューです。

処理の状態やエラーメッセージ等が表示されます

アプリケーション・アーキテクチャーとは、情報システムにおいてエンドユーザが利用する各アプリケーションの設計思想やその構成のことです。下記のようなアプリケーション・アーキテクチャーがよく見られます。

• クライアント/サーバアーキテクチャ
  アプリケーションは論理的にクライアント側とサーバ側と2階層に分割して実装されます。
• 3層アーキテクチャー
  アプリケーションはプレゼンテーション層、ビジネスロジック層、データ層の3階層に分割して実装されます。
  3層アーキテクチャーの基本原則として、プレゼンテーション層は決してデータ層と直接通信しない。つまり、全ての通信は必ずビジネス・ロジック層を通ることになります。WEBシステムを構築する際に、WEBプラットフォームの特性からこの3層アーキテクチャーが採用されるのはほとんどです。
• MVCアーキテクチャー
  MVCはプログラムを3つの要素、Model（モデル）、View（ビュー）、Controller（コントローラ）に分割して実装する設計思想であり、場所によってMVCアーキテクチャとも呼ばれていますが、ユーザインタフェースにおける画面上のコンポーネントの管理方法を表しているだけのため、、厳密に言うとアプリケーションアーキテクチャーと言えないと思わられます。MVC に基づくコンポーネントは、三層アーキテクチャのアプリケーションでもよく使われます。

SapECCのアプリケーションアーキテクチャーもソフトウェアアーキテクチャーに合わせて、プレゼンテーション→アプリケーション→データベースの3階層から構成されています。

• プレゼンテーション：DynproやWebDynpro
• アプリケーション：ABAP（汎用モジュールなど）、Java
• データベース：　各テーブル、ビュー等

COEPテーブルに格納されるデータを分類毎にまとめて説明します。

システム制御に利用される情報は主に以下の項目があります。

• どんな原価データなのか？　
  原価要素(KSTAR）から判断できます。
  
  
• どのCO対象のデータなのか　
  対象番号(OBJNR)に該当CO明細の金額が計上されるCO対象を識別するための番号が格納されます。例：
  • KS2011T201711
    原価センタ
  • OR420701000820
    指図
  • PR30019190
    WBS
  • KL2011T201711 ZXDEXH
    活動
  • BP2011BCL2-23
    ビジネスプロセス
    
    
• 取引相手はなんなのか？
  取引相手はパートナ対象と呼ばれて、PAROBとPAROB1の２項目がありますが、PAROB1がより確実的にとれるようです。
  FIから転記の場合はパートナ対象が空白と設定されます。
  
  
• どんな業務で生成されたデータのか？
  業務Transaction(VRGNG)項目から確認できます。例えば、FIからCOへの転記の場合、項目の値がCOIN、CO内のマニュアル再転記の場合、項目の値がKAMVになります。
  TrCD:OKC1ですべての CO 業務トランザクションを照会できます。
  
  
• 入り側(コスト)のデータのか、抜き側(配賦)のデータのか？
  FIから転記されたデータは常に入り側(コスト)となります、CO内部で転記されたデータは借方/貸方フラグ(BEKNZ)項目で判断できます。(FIから転記されたデータでは、BEKNZ項目値が金額依存となり、マイナス金額はC(貸方)、正数金額はD(借方)となります。)
  • C/O/S
    センダ貸方転記　⇒　抜き側
  • D
    レシーバ借方転記　⇒　入り側

金額関連情報は以下のような項目があります。

• 取引通貨金額 WTGBTR
• 対象通貨金額 WOGBTR
• 管理領域通貨金額 WKGBTR
• 取引通貨 TWAER
• 対象通貨 OWAER

管理領域の通貨は保持していないため、管理領域のマスタから取得できます。

数量情報をもっている伝票明細であれば、その情報が以下の項目に格納されます。

• 合計数量(MBGBTR)
• 数量単位(MEINH)

品目情報をもっている伝票明細であれば、その情報が以下の項目に格納されます。

• プラント(WERKS)
• 品目 (MATNR)
• 購買伝票(EBELN)
• 明細(EBELP)

COBKテーブルに格納されるデータを分類毎にまとめて説明します。

FIやMM、または別のCO伝票から自動転記されたCO伝票の場合、元伝票の参照情報が格納されます。 例えば、入出庫処理で自動転記されたCO伝票の場合、元伝票の入出庫伝票番号情報などが格納されます。元伝票の明細番号情報はCOEPに格納されます。

• 参照伝票タイプ(REFBT)
  元伝票の伝票タイプを示すフラグ、主に以下のようなタイプ値があります。
  • R
    FI伝票系
  • K
    CO伝票系 活動タイプ
  • 空白
    元伝票がない場合は空白になります。元伝票なし
    
    
• 参照伝票番号( REFBN)
  元伝票の伝票番号
  
  
• 参照会社コード(REFBK)
  元伝票の会社コード、FI伝票系の場合のみ
  
  
• 参照伝票会計年(REFGJ)
  元伝票の会計年度、FI伝票系の場合のみ

COKP　原価センタ別の一次原価要素の制御データ

AUAK　ヘッダ AUAA　明細 AUAS　明細合計 AUAV　ビジネスデータ AUAO　決算予定

管理会計(英：Controlling)とは、その名のとおり、会社が内部で管理を行うための会計のことをいいます。

経営者や管理者は、通常、この管理会計上の会計情報をもとにして、業務分析や意思決定を行います。

財務会計とは、企業の財務状況を企業外部の利害関係者（株主、債権者、徴税当局など）に対して提供することを目的とする会計のことです

原価とは、簡単に言うと、製品または商品にかかった費用、コストのことです。

企業で発生する費用は、「総原価」と「非原価」に分けることが出来ます。まず、下記の図で示すように、「売上高」から「営業利益」を引いたものが「総原価」となります。

総原価はさらに「製造原価(または仕入原価」と「販売費及び一般管理費」に分かれます。

販売費及び一般管理費（販管費とは、営業部門 における費用や総務部などの管理部門における費用のことです。なお、『非原価』とは、異常による損失や支払利息、さらには法人税及び住民税などとなります。

総原価は工業簿記での用語であり、財務諸表には特に出ておりません。

仕入原価とは、スーパーや商社などが完成した商品を仕入れて販売するときの原価です。 仕入原価は、商品をの購入代価に引き取り運賃や購入手数料・関税などの諸費用（これは仕入諸掛といいます）を加算して算定されます。

製造原価とは、メーカーが原材料を仕入れて加工して製品を作るときの原価です。 製造原価は、材料費、労務費、設備費などの経費で構成され、これに販売及び一般管理費を加算したものが総原価になります

一般的に、原価だけという場合は、「製造原価」を指す場合が多いようです。

原価要素とは、原価の構成要素のことです。製造原価要素はいくつかの分類方法が存在します。

原価は財務会計の費用発生を基礎として形態別に「材料費」「労務費」「経費」の3つに分類することができます。

• 材料費
  材料費は製品を製造するにあたり消費した物品の費用です。
• 労務費
  労務費は製品を製造する人に対して払う給料です。これは正社員だけでなく契約社員やパートタイマーに対いて支払う賃金も労務費にあたります。
• 経費
  材料費、労務費以外のものすべてが経費となります。水道光熱費、旅費交通費、減価償却費、支払手数料などさまざまなものがあります。

原価は「その費用が特定の製品に使用されたことが明確であるか？」という視点で以下のように分類できます。

• 直接費
  特定の製品に使用されたことが明らかな費用
• 間接費
  特定の製品に使用されたことが不明確な費用

例えば、工場でお菓子を作る場合、お菓子を作るのに使用した米などは直接費になりますが、お菓子を作っている工場の電気代などは、どのお菓子の製造に使用した電気代であるのかは不明確であるため、間接費となります。

操業度との関連における分類とは、操業度の増減により原価がどのように変動したかという観点による分類のことです。。 この分類方法では、製造原価要素は次の２種類に分類されます。

• 変動費
  操業度の増減に応じて比例的に変動する原価（操業度がゼロの場合には発生しない）
• 固定費
  操業度の増減に無関係に常に一定額が発生する原価

原価管理とは、1962年、財務省(当時の大蔵省)によって次のように定義されています。 「原価管理とは、原価の標準を設定してこれを指示し、原価の実際の発生額を計算記録し、これを標準と比較して、その差異の原因を分析し、これに関する資料を経営管理者に報告し、原価能率を増進する措置を講ずることをいう」

簡単にまとめると、原価管理とは、文字通り原価を管理するとのことですね、具体的には、以下3つのアクションがありす。

1. 原価企画
   製品を企画する際、製造に投じて良い原価を設定することです。
2. 原価維持
   目標原価の範囲で製品を製造するために、生産や調達を工夫することです。
3. 原価改善
   目標よりも安く原価を抑える取り組みのことです。

以下、拡張プログラムの呼び出し順番です。

1. BTE/Process:1100
2. 代入
3. チェック

以下、拡張プログラムの呼び出し順番です。

1. 代入(明細単位)
2. チェック(明細単位)
3. BTE/Process:1120
4. 完了伝票チェック
5. BTE/P&S:1030

以下、拡張プログラムの呼び出し順番です。

1. チェック
2. AC_DOCUMENT BADI
3. BTE/P&S:2218

以下、拡張プログラムの呼び出し順番です。

1. チェック(完了伝票)
2. 代入(明細)
3. チェック(明細)
4. BTE/Process:1120
5. チェック(完了伝票)
6. BTE/P&S:1030

以下、拡張プログラムの呼び出し順番です。

1. 代入(明細)
2. AC_DOCUMENT BADI
3. BTE/Process:1120
4. チェック(明細)
5. チェック(完了伝票)

転記済みの会計伝票の明細情報が格納されます。未転記の会計伝票の明細はこのテーブルに格納されます。 BSEGはクラスタテーブルであるため、BKPFと結合検索することができません。

BSEGテーブルに格納されるデータを分類毎にまとめて説明します。

システム制御に利用される情報は主に以下の項目があります。

• 転記キー(BSCHL)
  転記キーにより、勘定明細の勘定タイプと貸借区分が決定されます、それにその他の登録データも確定されます。
• 金額転記ストリング(BUSTW)

勘定の基本情報は以下の項目があります。

• 総勘定元帳勘定(HKONT)
  HKONTには本当の総勘定元帳勘定コードが格納されます
• G/L勘定(SAKNR)
  SAKNRには、取引先(仕入先または得意先)の統制勘定コードが格納されます。 統制勘定ではない明細にはSAKNRが空白になります。
  普通の統制勘定明細には、SAKNRの値がHKONTと同じになります。
  普通の統制勘定明細には、HKONTに特殊の総勘定元帳勘定コード、SAKNRに統制勘定コードがそれぞれ格納されます。
• 勘定タイプ(KOART)
  会計伝票明細の勘定タイプは以下の5種類が存在します。
  • A：資産
  • D：得意先
  • K：仕入先
  • M：品目
  • S：総勘定元帳
• 借方/貸方(SHKZG)
  借方か貸方かを示すフラグです。　H：貸方、S：借方。
• 貸借対照表勘定(XBILK)
  B/S勘定かどうかを示すフラグです。　空白か“X”かが設定されます。
• 損益計算書勘定(GVTYP)
  損益勘定かどうかを示すフラグです。　空白か“Z”かが設定されます。
• グループ勘定コード(ALTKT)
• 総勘定元帳の取引タイプ(VORGN)

会計伝票明細にはいくつかの金額が保持されています。

• 国内通貨額(DMBTR)
• 伝票通貨額(WRBTR)
• 総勘定元帳金額(PSWBT)、総勘定元帳通貨(PSWSL)
  総勘定元帳通貨は必ず国内通貨、伝票通貨の何れかに一致します。

消費税情報はすべての勘定タイプの勘定明細にとも設定されることがありますので、勘定タイプ別に説明します。

• 仕入先勘定
  買掛金がすべて同一の税率で掛けられている場合、該当税コードは税コード(MWSKZ)に格納されます。
  買掛金に異なる税率が含められている場合、税コード(MWSKZ)に“**”が格納されるとともに、税コード(MWSK1~3)、国内通貨額(DMBT1~③)、伝票通貨額(WRBT1~3)に各税率(三つまで)の税コードと課税対象金額がそれぞれ格納されます。
• 得意先勘定
  仕入先勘定の仕様に参照ください、買掛金を売掛金に書き換えるだけです。
• 資産勘定
  資産金額の増減が関わっている消費税コードは税コード(MWSKZ)に格納されます。
• 品目勘定
  品目在庫金額の増減が関わっている消費税コードは税コード(MWSKZ)に格納されます。
• 総勘定元帳勘定
  消費税勘定の明細には、税コード(MWSKZ)には該当消費税金額の税コードが格納されます。

• 支払条件ZTERM
• 支払方法ZLSCH
• 支払保留ZLSPR
• 支払基準日ZFBDT

源泉徴収税は、拡張源泉徴収税が有効化されているかないかによって動作が異なります。

• 拡張源泉徴収税が有効化されていない(従来の源泉徴収税方式)
  仕入先勘定、得意先勘定、総勘定元帳(源泉徴収税)の勘定明細には、源泉徴収税コード(QSSKZ)に該当明細が関わる源泉徴収税コードが格納されます。
• 拡張源泉徴収税が有効化されている(拡張源泉徴収税方式)
  仕入先勘定、得意先勘定の勘定明細には、源泉徴収税があった場合、源泉徴収税コード(QSSKZ)に“XX”がはいり、源泉徴収税)の勘定明細には、源泉徴収税コードではなく、源泉徴収税タイプがはいるようです。
  おそらくBSEGはこのケースにうまく対応できていないと考えられます。
  かわりに、仕入先勘定、得意先勘定の源泉徴収税詳細情報はWITH_ITEMから取得可能です。

資産勘定明細の場合のみ設定される情報は以下のものがあります。

• 資産番号(ANLN1)
• 資産補助番号(ANLN2)
• 資産取引タイプ(ANBWA)
• 資産評価日(BZDAT)

品目勘定明細の場合のみ設定される情報は以下のものがあります。

• 品目コード(MATNR)
• プラント(WERKS)
• 基本数量単位での数量(MENGE)
• 基本数量単位(MEINS) 在庫管理の単位
• 入力単位での数量(ERFMG)
• 入力単位(ERFME) 入出庫伝票で指定された入力単位
• 購買発注価格単位での数量(BPMNG)
• 購買発注価格単位(BPRME) 購買発注伝票で指定された購買発注価格単位
• 原価管理区分(VPRSV)
• 評価レベル(BWKEY)
• 評価タイプ(BWTAR)