0***関西電力の案件
【期間】2024/10 ～ 2025/08（テレワーク+出勤）
【案件】電力システム運用保守
【モジュール】FICO
【関連会社】元請け会社 ：LHC
エンドユーザー：関西電力
【担当内容】
①夜間バッチモニタリング
②夜間バッチエラー調査、データリカバリー
③マスタデータ運用維持
・勘定マスタ、会社マスタ、WBS要素など
③カスタマイズ対応
④エンドユーザーから問い合わせ対応
⑤会計伝票の拡張対応
⑤MM、HRモジュールと連携データの不具合調査、対応
使用した技術：コーディングブロック、チェック・代入、JP1など
1***富士通の案件
【期間】2024/03 ～ 2024/09（テレワーク）
【案件】サーバーパーツシステム刷新プロジェクト
【モジュール】MM
【関連会社】元請け会社 ：ベース
エンドユーザー：リコー
【担当内容】
①インターフェースの基本設計
・在庫受払残高明細（OUT）
・出庫指示リスト（OUT）
・返却受付結果（IN）など
②Fiori処理の仕様変更・不具合対応
フロント・バックエンド側の仕様変更対応、不具合の原因調査、対応案提出、対応及び検証
・一般注文処理、受注状況照会、通知一覧など
③チームメンバーをサポート、成果物レビュー、進捗報告
使用した技術：Fiori、CDSVIEW、BAPI、OdataServiceなど
・一般注文処理（Fiori）
一般注文データ登録および更新と各種SAP標準伝票の作成を行う。
新規登録：
注文入力から注文登録を行う。
選んだメーカーに応じて、画面表示が切り替わる。注文に必要な情報を入力する。
渡されたパラメータの値に従って、画面表示を切り替わる。受け取った品目・数量を明細部分に自動反映する。
更新：
受注照会から更新対象の注文まとめ番号を選択し、一般注文画面に遷移し、更新可能。
在庫解除・明細削除・（明細・ヘッダー）更新・即(そく)出庫・在庫転送・明細コピー・明細分割など
SAPのバックエンドプログラムは1万行以上あり、フロントエンドの画面は五つかあります。
私は主にST1とST2の段階での仕様変更および不具合調査に対応しています。
フロントエンドとバックエンドの両方を担当しています。
・返却受付結果（IN）
概要：生産システム側で返却受付・入庫実績実施した結果をSAP側連携する。
生産システムから返却受付結果を受信し、返却データテーブルを更新し、返却ステータス・受付数量を更新する
購買発注登録BAPI:BAPI_PO_CREATE1
出荷伝票登録BAPI:BAPI_OUTB_DELIVERY_CREATE_SLS
出庫転記BAPI:BAPI_GOODSMVT_CREATE
入庫転記BAPI:BAPI_GOODSMVT_CREATE
2***富士通の案件
【期間】2023/06 ～ 2024/02（テレワーク）
【案件】OneERP + JGGアドオン開発
【モジュール】MM
【関連会社】エンドユーザー：富士通
【担当内容】
①4人のチームリーダーとして、スケジュール管理、作業レビュー、進捗報告、作業サポートなど
②Fiori処理のバックエンド側の外部設計、新規、改修作業を担当
購買依頼伝票アップロード、ダウンロード、Pカード請求データアップロード、購買情報ダウンロード
など処理のアップロード、ダウンロード系処理の外部設計からテストまで新規・改修対応
③Fiori処理のバックエンド側の不具合調査、仕様変更対応
④購買情報登録処理などの拡張処理の調査分析など
使用した技術：BTP、Fiori、CDSVIEW、BAPI、Exitなど
■詳細情報
購買依頼伝票アップロード(汎用モジュール⇒BAPI)
購買依頼伝票ダウンロード(CDSVIEW)
購買発注アップロード(汎用モジュール⇒BAPI)
購買発注ダウンロード(CDSVIEW)
3**********日本システムズの案件**************
【期間】2023/01 ～ 2023/05（テレワーク・出勤）
【案件】製造業向けSAPシステムインボイス対応
【モジュール】FI
【関連会社】元請け会社 ：日本システムズ
エンドユーザー：日本ペイント（大阪市大淀）
【案件内容】
■請求書Invoice制度への対応のため、SAPにで発行している請求書の改修対応
【担当内容】
①請求書インボイス対応
・請求書Invoice変更に伴って、請求書発行に関わるアドオンプログラムの解析、仕様書修正、SmartForm改修
②固定資産移行作業対応
・移行データ変更ツール開発、固定資産一括登録プログラムの開発、移行結果の比較など
③拡張調査・実装
・WB21でトレード契約登録の明細入れると、「購入情報」に品目コードと契約タイプより税コードの初期設定
・FB60で仕入先請求書の明細に税コードの初期設定
④カスタマイズ対応
・消費税コードを追加、
・仕入先：一般データ（拡張）画面にカスタマイズ項目を追加
使用した技術：SmartForm、Dnypro、Exit、BADI、インターフェースなど
4 ニッセコムの案件
【期間】2022/04 ～ 2022/12（テレワーク・出勤）
【案件】製造業向けSAPシステム改修対応
【モジュール】FI、CO
【関連会社】元請け会社 ：ニッセコム（中の島）
エンドユーザー：日本山村硝子（やまむらがらす）
【案件内容】
■廃棄されたFICOモジュールを再開するため、アドオンプログラム対応
【担当内容】
①既存アドオン処理業務ロジック解析、不具合調査分析、解決案提出
②アドオンプログラムの改修、設計、新規、テスト
③クエリ、ビュー、テーブルの登録、
④Exitの調査実装
⑤パフォーマンス改善対応など
使用した技術：Dynpro、BatchInPut、クエリ、ビュー、BAPI、Exit、インターフェース、SmartFormなど
5 デトロイトの案件
【期間】2021/11 ～ 2022/03（テレワーク）
【案件】販売業向けBPマスタ移行対応作業
【モジュール】SD
【関連会社】元請け会社 ：デトロイト（Deloitte）
エンドユーザー：
【案件内容】
■一括受注登録、出荷実績登録・取消アドオン開発、CSDView開発
【担当内容】
①Up-oneシステム連携される受注・出荷データをと受け取るため、アドオン処理の新規作成
②BP Platformを連携するため、品目マスタ、受注伝票、出荷情報のCSDView作成
③CSDView作成
・取得すべき項目マッピング調査
・データ差分抽出案提出、サンプル作成
・CDSVIEW実装・テスト
④SAP側Cloud Connector設定調査・手順作成
使用した技術：インターフェース、汎用モジュール、BatchInPut、CDSViewなど
6 富士通の案件
【期間】2019/09 ～ 2020/04（テレワーク・出勤）
【案件】大手製造企業SAPシステム対応
【モジュール】SD、MM、FI
【関連会社】元請け会社 ：富士通
エンドユーザー：株式会社山善
【案件内容】
■S4 HANAバージョンアップ対応
【担当内容】
①共通部品の設計
②会計伝票のOPEN-FI、代入機能実装、FioriのEtag排他調査など
③仮出庫関する拡張機能対応（Exits、BADI）
④S/4 Fiori APP新規作業
⑤SAPシステムと周辺システム連携するため、 周辺システムへ送信用インターフェース連携の基本設計作成を担当
使用した技術：BAPI、BatchInPut、CDSView、インターフェースなど
■詳細情報
■共通部品の設計
・帳票共通選択画面項目チェック：帳票ID存在性チェック、選択画面の入力制御、FAX送信がONの場合、選択画面セットカーソルの設定Email送信がONの場合、メールアドレスのチェック
・処理日付管理データ取得、更新：処理がバックグラウンドで実行の場合、処理日時、更新件数など情報の更新
■拡張：
①出荷伝票BAdI 伝票入力チェック
出荷伝票の設計変更欄に指定した仮出庫NO 及び、仮出庫数量に対し、妥当性チェックを実施す
TCODE ：VL02N出荷伝票変更保存時
出庫確認時
PG:SAPMV50ALE_SHP_DELIVERY_PROCDELIVERY_FINAL_CHECK
②販売伝票EXIT 伝票保存前処理画面で入力された項目(明細カテゴリ、保管場所)間の整合性チェックを実施し、チェック、チェック結果を画面に表示する。
（受注明細情報の保管場所と納入日程の明細カテゴリとの関連チェック）
TCODE ：VA01受注伝票保存時
VA02
PG:SAPMV45A MV45AFZB USEREXIT_CHECK_VBEP
③入出庫伝票に明細テキスト
庫伝票（仮出庫関連）の明細テキストに仮出庫NOを設定する。
TCODE ：MIGO出庫・入庫ボタン押下時VL02N
BADI： MB_MIGO_ITEM_BADI
明細データ変更用 MIGO の BADI
■会計伝票のOPEN-FI、代入機能実装、FioriのEtag排他
①仮出庫一覧
②仮出庫数量集計
7 シャープ工場の案件
【期間】2017/02 ～ 2019/03（堺市・出勤）
【案件】大手電気製造メーカー保守案件
【モジュール】SD、MM、FI
【担当内容】
①アドオンプログラムの改修、設計、新規、単体テスト
②海外エンドユーザーから提出されるシステムのトラブルと不具合を調査分析して対応案を提出
③海外エンドユーザーさんのニーズに応じてカスタマイズを対応
④夜間バッチ処理のモニタリング、障害対応、データリカバリー、パフォーマンス改善対応
⑤消費税税率改定に従ってアドオン処理対応など
担当した処理 *******
FIモジュール
処理: 非会計要素データ登録
周辺システムから受信データによって、様々な非会計要素を算出し、利益センタ伝票として登録する処理であります。
技術については難しくないですが、選択画面で入力された検索条件によってデータを抽出し、編集されたデータをバッチインプット「9KE0」で利益センター伝票登録を行います。
パタンがめちゃ多いです。
11アドオンテーブルから「在庫データ・在庫移動状況・販売実績・生産単価・生産予算マスタ」などのデータを抽出し、金額・数量・重量・製品・半製品を分けて、汎用パラメータを使って非会計要素を算出します。
パタンは４０ぐらいあるので、パフォーマンスを考えしながら、ソースの共通化をしなければなりません。
最終ソースは５０００ステップあります。概要設計からテスト完了まで、一ヶ月（いちかげつ）ぐらいかかりました。
SDモジュール
処理１：売上伝票明細出力
伝票タイプ、支払人、出力日付などを検索条件に販売伝票、出荷、請求伝票から
販売情報、出荷請求情報を取得してALVで一覧を出力する
処理２：出荷明細出力
処理日、出荷日などを条件に出荷情報を検索し、出荷内容を一覧に出力する。
MMモジュール
処理１:購買予定入力
三つ機能：購買予定登録、更新、一覧
登録：購買情報を入力し、マスタ存在チェック、関連性チェックを実施します。
入力データエラーがなければ、バッチインプット「ME21」で購買発注登録を行います。
同時にいくつアドオンテーブル登録も実施されます。
更新：予定Noを条件に登録された購買予定情報を検索して、項目値を直して、
バッチインプット「ME22」で購買発注更新を行います。
EXITS VS BADI *****
User exits VS Customer exits (实装时候用CMOD和 SMOD)
- User exits 是以 FORM的形式存在,所以通过被SAP standard programs 通过 PERFORM调用.
Customer exits 以 FUNCTION module形式存在, 通过CALL CUSTOMER-FUNCTION语句调用. - 在user exit里你可以读写几乎所有的全局变量.
在customer exit里你只能访问import/export/changing/tables parameters. - User exits 更加灵活(因为你可以获得更多的信息,例如所有的全局变量),但同时也很容易因为对数据的不合理处理导致系统级错误, 甚至是数据库数据的一致性出现问题. Customer exits 更具有限制性,但是你可以确性你的程序不会导致数据库一致性出现问题.
- User-exit 没有什么分类.
而customer-exit 可以分为function-module exit, screen exit, menu exit. - User exits 基本上都是为SD模块设计的.
Customer exits被运用在MM, SD, FI, HR... 等几乎所有的模块当中.
EXITS只执行一次，BADI执行多次
BADI：SAP 标准代码使用类 CL_EXITHANDLER 来识别和调用相关的 BADI 类。
实装时候用SE18 和 SE19
インターフェース設計 ******
【処理】：受注明細データ送信
SAPの変更文書情報より、まず、前回処理以降に登録/変更された受注伝票を確定します。
次は受注明細データを編集します。最後、SAPサーバー上のI/F送信用ディレクトリに出力します。
【種類】バッチ、随時(ずいじ)
【選択画面項目】
・販売組織
・処理開始日付/時刻
・処理終了日付/時刻
・調整時間
処理日付管理テーブル:
前回処理日時を保持し、選択画面に「処理開始日付/時刻～処理終了日付/時刻」、及び「調整時間」を設定する。
送信履歴テーブル:
前回送信したレコード格納する。
【データ抽出】
難しい点①
選択画面に指摘された開始と終了期間の対象データ抽出：
新規登録データの確定：
⇒変更文書に記録されないため、受注伝票登録日時より取得できます
変更されるデータの確定：
⇒変更文書(CDHDR, CDPOS)「Object、テーブル、項目、変更Typ」
受注伝票の項目変更したら、変更文書テーブルにレコードが登録しますので、対象項目の変更の絞り込みが大事です。
まずヘーダー、明細、受注納入日程に変更対象項目確定し、次は変更文書から変更対象項目レコードの抽出条件を確定します。
※調整時間について補足
・「データ更新のCOMMIT」と、実際にDBに更新する「更新ワークプロセス完了」のタイミングに時差があるため、
例えば、10:00:00少し前に保存実行された受注伝票が、10:00:00に開始したI/Fデータ抽出の対象にならないことがある。
この為、調整時間により前回処理時刻の少し前から、今回処理対象データを抽出する。
・前回処理時と今回処理時の抽出データの重複については、後述の差分抽出処理にて除外する。
送信データと送信履歴テーブルに直近登録データと比較し、重複レコードを差分し、残る部分を送信します。
「送信履歴テーブル」と「処理日付管理テーブル」を登録します。
※一部出荷した受注明細が拒否された場合、明細削除ではなく、残る部分出荷停止と意味である。