システムが動作する上で必要とする、または動作した結果が格納される[[変数>アドオン/変数]]のこと。
* 概要 [#ga531ff7]
システム項目の正体はSYSTという[[構造>SAPのオブジェクト/構造]]のデータで、これを元にSYという構造が自動生成される。
** 処理結果系 [#xa469724]
-SY-SUBRC
[[SELECT>ABAP/SELECT]]命令や[[汎用モジュール>SAPのオブジェクト/汎用モジュール]]など、諸々の処理結果が格納される変数。
-SY-DBCNT
[[SELECT>ABAP/SELECT]]命令で抽出したデータの件数が格納される。
-SY-MSGID
発行したメッセージの[[メッセージクラス>SAPのオブジェクト/メッセージクラス]]。
-SY-MSGTY
発行したメッセージのメッセージタイプ。
-SY-MSGNO
発行したメッセージのメッセージ番号。
-SY-UCOMM
[[機能コード>ABAP/機能コード]]が格納される。
-SY-DYNNR
実行中のプログラムの[[Dynpro>ABAP/Dynpro]]番号が格納される。
-SY-CPROG
実行中のプログラムのプログラムIDが格納される。
呼び出し元がある場合は呼び出し元のプログラムIDが格納される。
-SY-REPID
実行中のプログラムのプログラムIDが格納される。
-SY-PAGNO
出力した帳票の現在表示しているページの番号が格納されり。
** 環境系 [#y5af6ddb]
-SY-LANGU
[[ログオン言語>SAPの共通用語/言語キー]]が格納される。
-SY-DATUM
サーバ日付が格納される。
ジョブなどサーバ日付が重要なシーンではこちらを使用すること。
-SY-UZEIT
サーバ時刻が格納される。
DATUMと同じく、ジョブや[[ベーシス]]的なシーンでは、こちらを使用すること。
-SY-DATLO
[[タイムゾーン>SAPの共通用語/タイムゾーン]]を考慮した日付項目。
日本にサーバを設置する日本企業への導入においてはSY-DATUMとイコールであるため気にすることもないかもしれないが、業務的な[[レポート>アドオン/レポート]]や[[フォーム>アドオン/フォーム]]においてはこちらを使うこと。
-SY-TIMLO
[[タイムゾーン>SAPの共通用語/タイムゾーン]]を考慮した時刻項目。
上記DATLOと同じく、業務的なシーンではこっちを使うこと。
* まとめ前のメモ [#w943927e]
** システム日付の利用の仕方 [#t5c9a6f3]
プログラムの中で、システム日付は安易に使用してはならない。
というのも、システム本体あるいはサブシステム移行にあたって過去日の伝票を入力するなんてこともあるわけだが、ことごとく邪魔になる。
そもそも内部的な処理を除けばシステム日付に頼らざるを得ないシーンは多くはないはずで、例えば得意先発注日や伝票日付および転記日などシステム日付なんかよりもよっぽど妥当性が高い項目はある。
あるいは、選択条件でもよいし。
移行とかシステム切り替えとかイチイチ導入時に考えてられるかよ!という話もあるのだが、SAP導入企業ですら諸般の事情によりシステムの寿命が数年しかないこともあるわけだから、細部まではケアできなくとも、後々薬価になりそうなロジックは組み込まないのが吉。
** SY-DATUMとSY-DATLOの違い [#gc3f9fc5]
何の疑問もなく、システム日付=SY-DATUMだと思っていないか?使っていないか?
DATUMはサーバ時刻、DATLOはサーバ時刻にタイムゾーンを加味したローカル時刻。
「いや、日本企業が日本にデータセンタがあるパターンが殆どじゃんwww」というオメデタイ人も割といるが、そういうプレハブ的な思考回路だから変化に弱い仕組み、コンセプトを理解しない設計をして余計な人員と工数を無駄遣いする羽目になる。
こういう「目の前に実害があるか否かも大事だけど、それだけじゃなくて、本来どうあるべきかを考える」ってのが本来のコンサルティングなわけで、目の前の即物的なことだけしか見ない聞かない考えないっていうファストフード的なITとの関わり方をプロフェッショナルがやっちゃいけない。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)