カテゴリー: その他

■タイトル
ABAP 実行時エラー
LIST_HASH_BAD_LENGTH

■原因(事例)
NEW-PAGE PRINT ON.とNEW-PAGE PRINT OFF.はネストできない。
ネストした状態でWrite文を実行するとショートダンプすることがある。

■対策
・ネストをしない
・次のNEW-PAGE PRINT ONの前にNEW-PAGE PRINT OFFを行なう
・GET_PRINT_PARAMETERSのOUT_PARAMETERSを使いまわししない

移動タイプ=561で入庫する。品目が標準原価の場合、標準原価で評価され、異なる金額を入力すると差異は、価格差異勘定に転記される。

移動平均原価の場合は、金額を入力するとその金額で品目が評価され、品目マスタの移動平均原価が更新される。

金額を入力しなければ、品目マスタの移動平均原価で評価され、品目マスタの移動平均原価は更新されない。

同じソースコードを、
バージョン違いの環境で動作させようとしたら、
動きがおかしい・・・。

そういう経験はないだろうか?

実は、そこには、
大きな問題が隠れている。

SAP標準の構造、汎用モジュールの違い、その他オブジェクトの違い等がある。

なので、その調査を行わずに、
スケジュールを組んだとき、
予定外のトラブルに巻き込まれる可能性がある。

また、バージョンが同じでも、
サービスパッケージの違いで
同様の現象が起こる場合がある。

テンプレート導入時は、
必ず、調査フェーズを確保して、
その調査結果によっては、導入を見合わせるか、
もしくは、再見積もりが発生するようにしておくことをオススメする。

この、「調査フェーズ」を
用意しなかったために、顧客とトラブルのは
可能な限り避けたい。

是非、バージョンの違い、
サービスパッケージの違いは必ずチェックしよう。

他にも、バージョンで
OSの違い、ブラウザの違い、
SAP-GUIの違い(パッチレベルも含む)をチェックしよう。

計画作成時は、プロジェクト内で
べーシス、コンサル、開発者、保守など、
十分に検討して、営業やプロマネ単独での
ジャッジメントは十分避けることをオススメする。

ルーチンワーク以外には実質的な答えはない。
プロジェクトとはそういうものだ。

何が正しいか、何が正しくないか。
結局のところ悩んでも時間の無駄だ。

計画、実行。
まず、実行することが何よりも大切で、
その後、どうなるか?どうなっているか?

計画通り行っているか?
行っていないのか?

上手くいかなかったらやり方を改めればよい。
まあまあでも、もっと良い方法が良いと思えば
その方法を試してみればよい。

結局、改善を繰り返すしかない。
1回で上手くやろうとすると、
悩むことになる。

それを1000回転、改善のプロセスを
繰り返したほうが良い結果になる。
改善スピードこそが重要だ。

伝票の最終変更時間を取得するには
CDHDR:伝票ヘッダ変更 テーブルより

下記の項目をキーにして
・オブジェクトクラス
・対象値
・変更文書番号

下記の項目を取得します。
・変更伝票の登録日付
・変更時刻

-以上-

バッチインプットで受注伝票(VA01)の購買発注データ登録時、ヘッダの得意先発注番号と明細の得意先発注番号が同一の場合、明細の得意先発注番号がVBKDに登録されない。

R/3の標準仕様で、データ領域の節約の為かと思われる。

■禁句
1.期日を曖昧にする言葉
・早い段階で
・近々に
・近日中に
・随時
・現在～中
・月初
・～月中
・上旬
・下旬
・早急に
・できるだけ早く

■問題から目をそらす言葉
・概ね
・特に問題なし
・比較的
・～面では
・基本的には

■アクションを曖昧にする言葉
・～が必要
・検討を要する

■受身になりがちな言葉
・予定
・検討中
・実施中

■判断・行動条件を曖昧にする言葉
・状況によって
・場合によって
・必要に応じて

近年、企業のシステム構成は複数のサーバーで成り立っている。個別の機能ごとに一つのサーバーで構成されていたりする。

それをEAIサーバーでつなぐ。

本番移行の順番でシステムの構成が一時的に変わってしまう。家庭用のコンセントとはわけが違うのでとても面倒くさい。

これからはEAIは切っても切れないので、
誰もがぶち当たる壁だ。「俺には関係ない」とか言っている人がいるかもしれないが、周りのだれかが面倒なことをやっている。

でも、保守を考えると複数のサーバーに分散しているのでリスク軽減にはなっている気がする。

移行リハーサルでは、各サーバーのテスト機が用意できないと、切り替えミスで、大変なことになったりする。

最低でも、各システムのネットワークが、テスト用と本番用で２つ存在していることが望ましい。可能なら開発、テスト、本番の３ネットワーク構成が理想。

維持費は、結構かかりそうだけど。