8. 外製・仕入
社外の協力会社(外注先・仕入先)に加工・処理を委託し、発注→受入→支払データ作成までを担当する「外製管理サブシステム(MENUG1)」の業務ガイド。板倉製作所から見るとお金を「払う」側の流れ(発注→支払)の入口にあたる。
1. 業務の目的と位置づけ
2. 登場人物
3. 外製発注の標準フロー(GSBS01)
4. 変更・中止・再発行(GSBS02/03/10)
5. 受入の標準フロー(GSBS04)
6. 外製加工費用問合せ(GSBS13)
7. 支払明細書印刷(GSBS06)— 経理への引き渡し
8. 仕入関係Excelジョブ
9. 特殊ケース
10. 実データスナップショット — 本番DBによる検証
11. 関連マスタ・データ/帳票一覧
12. 用語集
13. 他業務との接続点
未解明事項 — 現場担当者への質問リスト
- 外製管理(MENUG1)は設計上「発注→受入→支払明細」だが、2026-07ヒアリングで判明: 実務ではほぼ「発注書(注文書)の印刷」専用に縮退しており、受入入力・支払明細発行は行われていない(下記callout参照)。
- SFDP23,194件のうち受入完了フィールドが埋まっているのはわずか99件(0.4%)しかない——これは上記の運用実態と整合する。
- 発注先497社中、実際に取引実績があるのは77社(15.5%)、上位1社が発注件数の62.4%を占める。
対象システム: AS/400 生産管理システム MENUG1「外製管理」サブシステム(メニュー項目 GSBS01〜GSBS26のうち実装確認できた7本)+その周辺(仕入先マスタ、支払明細への引き渡し)。板倉製作所は自社で作れない、または自社でやらない工程を社外の協力会社(外注先・仕入先)に委託しており、このサブシステムはその「発注→受入→支払データ作成」までを担当する。
以下、3節〜9節はMENUG1の設計上のフロー(発注→変更/中止→受入→支払明細)を説明しているが、新實さんへのヒアリングにより、実務ではこのうち発注(GSBS01→注文書印刷)以外はほぼ行われていないことが確定した——「MENUG1はほとんど停止しています。注文書を印刷するためだけに使用しています。受入れの入力もしていませんし、支払明細の発行もしていません。注文書は下請法に定められた記入項目を網羅するために定めた様式で発行できるように運用しています」。
つまりこのページで説明する5節(受入)・7節(支払明細書印刷)は、現在は実質的に運用されていない。これにより、本ページが以前「未解明事項」として挙げていた複数の論点(受入データがほぼ空白である謎、支払明細書とSHDPの二重管理・突合、検収の記録場所、分納受入・受入後の中止・単価連絡表再発行の実運用有無)が、個別にではなく一つの根本原因(GSBS06系の受入・支払明細発行がそもそも運用されていない)で解消される。各該当箇所に反映済み。なお注文書について「すべての外注先に発行されているか」は新實さんからも「営業部へ確認してください」との留保が付いており、営業部への追加確認待ちの小さな残課題として残る。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照、hearing.html E1/E2)
1. 業務の目的と位置づけ
板倉製作所はプレス加工(金属を型で打ち抜く・絞る)を中心とした自動車部品メーカーで、構成マスタ(KSMP、部品の親子関係を管理するデータ)の各部品行には「内外コード」という区分がある。
| コード | 意味 |
|---|---|
1 | 内製(自社で作る) |
2 | 外注(社外に委託する) |
8 | 中間S/A(組付指示の対象外の中間半製品、扱いが特殊) |
10 | 中間S/A(サブアセンブリ)品番、独立して外注する場合のみのタグ 【ヒアリングで判明】 |
(出典: pilot/spec/itgo12r.md 60行目「KSCDNG(内外コード、KSMP、2桁)= '1 '(内製)or '2 '(外注)」、pilot/spec/itzr12r.md 18行目も同コード値を使用。pilot/spec/itgo42r.md 256行目は '10' の意味を「未確認」としている)
'10'の意味が確定 【ヒアリングで判明】新實さんの回答: 「10は組み付ける途中の中間S/Aの品番です。板倉の構成データは2階層のみ(完成品=受注品番、と何も組み付いていない部品のみ)で登録される。実作業では順に組み付けていくと中間の状態を表すS/A品番があるが、無視して2階層のみにしている。ただしS/A品番で治具を外注したりするケースがあり、S/A品番の存在がないと不便なので「10」で通常の部品と区別して構成マスタに追加している(構成展開上は無視する)」。つまり板倉のBOMデータモデルは意図的に2階層(受注品番/未組付部品のみ)に単純化されており、実際の多段階組立工程で生じる中間サブアセンブリ状態は構成展開上は意図的に無視・畳み込まれる設計。その中間S/A品番自体を独立して外注(治具作成等)に出す必要がある例外ケースだけ、通常部品と区別するため内外コード'10'でタグ付けし、構成マスタに存在だけを記録する(構成展開時にはこの'10'は無視される)。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
外注の具体的な中身を示す最有力の証跡は、外注発注入力(GSBS01)で発注ごとに指定する「加工種類コード」(型種マスター TYMP、WSCDTY)である。TYMPのソースコメント(source/as400-admin/transport-tooling/ITLIBS/TYMP.txt、SHIFT-JIS復号済み)には次の記述がある。
- 「TYCDKT(型種コード) 100〜399は表面処理用」
- 「型種マスタというよりは、外注への依頼内容マスタ」
- 「変更前=3絞り型」(コード3はかつて「絞り型」=プレスの絞り加工用金型を意味していた)
つまり「型種マスター」という名前は歴史的なもので、実体は外注先への依頼内容(何をお願いするか)を表すコード表。100〜399番台は表面処理(めっき・塗装・熱処理などが一般的だが、個別の工程名まではソースから確認できていない 推測)に使われており、プレス部品メーカーとして最も典型的な外注理由と一致する。低い番号帯には「絞り型」のような金型関連の依頼も存在した形跡がある。
(出典: source/as400-admin/transport-tooling/ITLIBS/TYMP.txt)docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
全体の流れ(procure-to-pay)
外注加工費用の照会(GSBS13)は上記フローに割り込まず、いつでも受注品番単位でコストを確認できる読み取り専用機能。 (出典: analysis/out/menu_tree.md 31-57行目、analysis/out/pilot_MENUG1.md プログラム一覧、各 pilot/spec/itsi0*r.md)
2. 登場人物
| 役割 | データ上の呼び名 | 説明 |
|---|---|---|
| 外注先・仕入先 | 仕入先(SIMPマスター、仕入先コード SICDSI) | 加工・処理を委託する社外の会社。名称(漢字/カナ)、住所、電話、振込銀行・支店、支払条件などをマスタで管理 (出典: analysis/out/masters_registry.json 424行目〜、simpテーブル定義) |
| 発注者 | 作業者マスター(SGMP、発注者コード SFCDHA/WSCDSG) | 社内で発注操作を行う担当者・作業者。GSBS01/02の発注入力で必須項目 |
| 得意先 | 得意先マスター(TKMP) | 外注部品が最終的に組み込まれる先の顧客(トヨタ紡織・アイシン・デンソー等)。発注データにも得意先コードが引き継がれる(受注品番から自動解決) |
外注発注は「受注(お客様からの注文)に紐づく部品」を対象に行われる(設計№/受注№/受注品番のいずれかで対象を特定する、次節)。つまり外注先への発注は基本的にお客様の注文が起点になっている(見込み生産用の外注枠は本調査からは確認できていない 推測 — 未解明事項)。
3. 外製発注の標準フロー(GSBS01 外製発注入力)
- 対象の特定 GSBS01
GSBS01は手動の対話型入力であり、受注データから自動的に発注が生成される仕組みは確認できていない。オペレーターが設計№(図面番号のようなもの)・受注№・受注品番のいずれか一つを入力すると、プログラムが各種マスタ(SNMP設計№マスター・SJDP製造指示データ・JUDP受注データ・JHMP受注品番マスター・KSMP構成マスター)を自動でたどり、注文品番・注文品名などを解決する。担当: 発注担当者(出典: pilot/spec/itsi01r.md「Target resolution」節、57-68行目) - キー画面の入力 GSBS01
発注日・仕入先コード・発注者コード・設計№/受注№/受注品番のいずれか、を入力する。 - 明細画面の入力 GSBS01
注文品番/注文品名(自動解決されるが手入力で補完可)、注文数、単位(デフォルト「コ」=個)、加工種類コード(外注先への依頼内容)、単価(希望単価。発注時点で決める単価で、この時点では「決定単価」ではない)、希望納期・希望時間を入力する。 - 確認画面 → 更新 GSBS01
内容を確認して確定入力(Enter)すると、発注№が仕入先ごと・月ごとに001から始まる連番としてYYMMNNNNという8桁のキーでSFDP(仕入ファイル)に書き込まれる。担当: 発注担当者 - 発注書の印刷 ITSI10R Excel/VBA
発注登録後、自動的に「仕入伝票印刷」の仕組み(ITSI10R → SFDPP2ステージングテーブル → ExcelマクロBAT0201.XLSM)が起動し、未印刷の発注(SFKBWK=空白のもの)をまとめてExcel経由で印刷する。印刷前に、備考欄を入れるかどうか(F5=備考なし/F8=備考あり)を選ぶ画面が出る。 (出典: pilot/spec/itsi10r.md)
発注入力時に入力するのは「希望単価」(SFDP.SFKTNI)のみ。実際に支払う単価(決定単価、SFDP.SFNNTN)は受入入力(GSBS04)の時点で別途入力する。発注時の単価はあくまで目安で、確定するのは受入時。加えて「仕入先見積単価」(SFSITN)という第三の単価枠もあり、外注加工費用問合せ(GSBS13/ITSI22R)では「決定単価 > 見積単価 > 希望単価」の優先順位で表示価格を選ぶ。
4. 変更・中止・再発行の使いどころ
| 機能 | プログラム | 何ができるか | 主な使いどころ |
|---|---|---|---|
| 発注変更 | GSBS02 (ITSI02R) | 発注者・設計№・受注品番・注文品番/品名・希望納期/時間・注文数・単位・加工種類・希望単価を編集 | 発注後に条件が変わった時(納期変更、数量修正など) |
| 発注中止 | GSBS03 (ITSI08R) | SFD201に「 D」(中止フラグ)を立てる。物理削除はしない | 発注ミス、注文自体のキャンセル |
| 発注書再発行 | GSBS10 (ITSI09R) | SFKBWKを空白に戻し、次の印刷バッチで再印字させる | 発注書を紛失した、印刷不良だった等 |
docs/staff-review-menug1.md A-2項目で現場確認中の論点。
- 既に中止済みの発注は二重に中止できない(エラー)。
- 受入済み(すでにGSBS04で受入登録済み)の発注でも、現行システムは変更・中止を止めない。受入済みの発注を中止すると、その発注は支払明細書(GSBS06)の集計対象から外れてしまう=支払われなくなる。新システムでは「既に入荷済の発注です。」というエラーで止める方向に変更予定(
docs/staff-review-menug1.mdA-3項目)。【ヒアリングで判明】新實さん本人の回答は「現在は、運用していません」——MENUG1系の受入入力自体がそもそも運用されていないため、このシナリオ自体が実務では発生しない。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照) - 中止しても発注書の印刷済みフラグ(SFKBWK)はそのまま。中止済みでも未印刷(SFKBWK空白)なら通常の印刷バッチに紛れて印字されてしまう(現行の弱点。新システムでは中止済みは印刷しない方針)。 (出典: docs/staff-review-menug1.md A-1項目、pilot/spec/itsi13r.md)
5. 受入の標準フロー(GSBS04 外製受入入力) 実務上停止
ITSI04R(GSBS04)の設計仕様の説明。ページ冒頭の重要calloutの通り、新實さんへのヒアリングで「受入れの入力もしていません」と明言されており、この画面は実務では使われていない。以下の項目(単価連絡表・SFDP更新内容・検収・金額欄手入力)はいずれも、コードとしては存在するが実運用で到達されることのない仕様として読むこと。
外注先から品物が戻ってきたときに、既存の発注データ(SFDP)に「納入日・納入数・仕入先見積単価・決定単価・金額」を追記する画面。伝票№(発注№)+発注日+仕入先コードで対象の発注を特定し、明細を表示 → 受入情報を入力 → 確認 → 更新、という流れ。 (出典: pilot/spec/itsi04r.md)
SFKUTT(単価通知区分)を「9=単価連絡表発行済扱い」に強制設定する。つまりこの画面を通った受入は、外注先への「単価連絡表」という別帳票が二度と発行されない扱いになる。同名の「単価通知あり」版が別に存在した可能性がある(コメントからの推測。ソースは今回未発見) 推測 — この点自体は今回のヒアリングでも直接回答されておらず未解明のままだが、上記の通りそもそもこの画面自体が実務で使われていないため、実害としては生じない。
更新される内容(SFDP)
| SFDP項目 | 内容 |
|---|---|
| SFNOHI 納入日 | 受入日 |
| SFNOSU 納入数 | 受入数量 |
| SFNNTN 納入単価 | 決定単価 |
| SFNNKN 納入金額 | 金額(受入数×決定単価で自動計算、ただし金額欄を手入力すればその値が優先される) |
| SFSITN 仕入先見積単価 | 参考値 |
| SFKUTT 単価通知区分 | 常に9固定 |
支払費用データ(SHDP、支払条件・振込先などの請求サイド情報)はここでは更新されない。SHDPは経理側の別プログラム(RSBS01/ITSW10R)で入力される、完全に別系統のデータである(7節参照)。
詳細: 検収(品質検査)はあるか 【ヒアリングで判明】
ソース上、受入数と発注数の比較(超過受入は警告のみで登録は可能)以外に、数量・金額の妥当性チェックはほぼ無い。検収(品質合否判定)を記録する独立の工程やフィールドはこのプログラム内には見当たらない。受入入力=検収記録という運用なのか、検収は別途紙やExcelで行っているのかは未解明事項(要現場確認)。——受入入力(ITSI04R)自体が実務では運用されていないことがヒアリングで判明したため、この画面内に検収記録フィールドが無いのは仕様の欠落ではなく、受入入力自体が行われていない以上、検収記録の要否自体が生じないという、より根本的な理由で説明される。 (出典: pilot/spec/itsi04r.md Open questions 2、新實さん2026-07-23ヒアリングシート回答E)
詳細: 金額欄の手入力について(要現場確認事項)
現行仕様では、金額欄に0以外の値を手で入れると自動計算(受入数×決定単価)を無視してその値がそのまま登録される。新システムでは自動計算に統一する方向で検討されており、docs/staff-review-menug1.mdのA-4項目で「端数調整・値引き・一式金額などのため手入力しているケースはあるか」を現場に確認中(回答は本調査時点で未記入) — 未解明事項。
6. 外製加工費用問合せ(GSBS13、受注品番別)
特定の受注品番(お客様の注文品番)について、これまでに発生した外注加工費用(すべての外注発注・受入の明細)を一覧照会する、読み取り専用の画面。新規登録・更新は一切行わない。
一覧に出る主な項目: 仕入先名、注文品番、受入日、受入数、単価(希望/見積/決定の優先順位で選ばれる。3節参照)、金額、伝票№、品名、型種(加工種類)。まだ受入していない発注(納入日が未入力)も一覧に混じって表示される。 (出典: pilot/spec/itsi22r.md)
用途としては「この受注品番、外注費がどれくらいかかっているか」を一目で把握できる、原価把握・見積り検証のための照会機能と考えられる(推測 — 実際の利用シーンは未確認)。合計金額の自動集計機能はない(明細を並べるだけ)。
7. 支払明細書印刷(GSBS06)— 月次締めと経理への引き渡し 実務上停止
ITSI13R)の設計仕様の説明。ページ冒頭の重要calloutの通り、新實さんへのヒアリングで「支払明細の発行もしていません」と明言されており、このプログラムは実務では実行されていない。以下の内容(支払明細書の行構成、経理SHDPとの突合、明細ゼロ月の扱い)は、コードとしては存在するが実際には動いていない仕様として読むこと。
指定した仕入先・対象月(YYYYMM)について、その月に納入日が入った(=受入登録済みの)SFDPの明細行をすべて集め、消費税・合計・前月繰越・当月支払内訳などのサマリー行と一緒にExcel転記用テーブルSFDPP3に書き出す。その後Excelマクロ(BAT0206.XLSM)が実際の「支払明細書」帳票を印字する。 (出典: pilot/spec/itsi13r.md)
中止フラグ(SFD201=' D')が立った受入行は集計対象から除外される。
支払明細書の内容(生成される行の種類)
| 行種別 | 内容 |
|---|---|
| C9(明細) | 受入1件ごとの明細(納入日・伝票№・注文品番/品名・親品番・納入数・単位・納入単価・納入金額) |
| B1 合計 | その月の納入金額合計 |
| B2 消費税 | 合計×税率(切り捨て。税率は対象月初日の日付でITSW99R照会) |
| B3 総合計 | 合計+消費税 |
| A1/A2 | 仕入先コード・対象年月のヘッダー行 |
| A3 前月繰越額 | 支払費用データ(SHDP)由来 |
| A4 当月仕入金額 | =総合計 |
| A5〜A9 | 現金・手形・振込・手数料・繰越金額(すべてSHDPが存在する場合のみ出力) |
新實さんより「ITSI13Rは現在使用していません。移植の必要はありません」と明言され(hearing.html A8)、この技術的特徴を移行時に注意すべき「留意事項」として持ち越す必要自体が無くなった。前月繰越ロジックの解釈(前月・同一仕入先を検索起点とする業務ルール)は既に
docs/decisions.md D3・pilot/DEVIATIONS.md #5として逸脱登録済みで、移植版pilot/app/src/domain/stagingShiharai.tsに実装・テスト済み(詳細はfinance.html 未解明事項参照)。以後この論点への追加投資(再検証等)は不要と判断する。
(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)
経理業務への引き渡しポイント(ここから先は経理・支払業務の担当)
このサブシステムが作るのは「支払明細書」(外注先ごとの請求内容を確認する書類)まで。実際の支払い(振込データ作成・手形処理・総合振込・支払総括書の作成・締め処理)はMENUR1「経理管理サブシステム」の担当であり、本ガイドの対象外。
- 受入実績に基づく明細作成 GSBS06
本サブシステムが作るのは「受入実績に基づく請求内容の明細」(SFDPP3、支払明細書)— 外注先ごとの支払うべき金額の元データ。担当: 外注担当者 - 支払費用データ(SHDP)の入力 RSBS01 (ITSW10R)
経理担当者が別途、経理管理サブシステム(MENUR1)の「支払金額データ入力・修正」で、支払費用データ(SHDP)を仕入先・発生月ごとに手入力する。ここで請求金額(本社請求・工機請求)と支払条件(全額振込/一部手形など)を指定すると、振込・手形・小切手への自動振り分け計算が走る。担当: 経理担当者 - 振込データ・支払総括書の作成 RSBS06/07/10/11/23
経理側でさらに、総合振込データ作成(RSBS06)・支払案内書(RSBS07)・支払総括書(RSBS10/11/23)などの帳票・振込データが作られ、実際の支払(銀行振込・手形発行)が実行される。担当: 経理担当者 — 9. 売上・請求・支払・経理を参照
(出典: pilot/spec/rsbs01-itsw10r.md, pilot/spec/rsbs06-07-10-11-23.md, docs/MIGRATION-MAP.md 1102行目「ExportPaymentDetail ITSI13R | Outsourcing | AccountsPayable」)
「GSBS06が作った支払明細書の金額」と「SHDPに経理が入力する請求金額」は別々に管理されており、システム上の自動連携(GSBS側のSFDP金額をSHDPへ自動転記する仕組み)は確認できなかった。経理担当者は外注先からの請求書(または支払明細書の金額)を見ながらSHDPへ手入力していると考えられる — 実際の突合方法は未解明事項、二重入力・転記ミスによる金額不一致のリスクが構造的に存在する点に注意。
新實さんへのヒアリングにより、この「二重管理・突合なし」問題自体が、より根本的な事実で解消されることが判明した——「MENUG1はほとんど停止しています。(中略)支払明細の発行もしていません」。つまりGSBS06側の支払明細発行がそもそも運用されていないため、SHDPと突合すべき「もう一方」がそもそも実在せず、二重管理・転記ミスのリスクという問題そのものが発生し得ない。経理側のSHDP手入力(9. 売上・請求・支払・経理)が実質唯一の請求管理経路になっている。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
現行システムは0件ならExcelが起動せず何も表示しない。新システムでは「0件です」という画面表示にする方向(——GSBS06自体が実務では実行されていないため(本節冒頭callout参照)、このシナリオも実務では発生しない。 (出典: 新實さん、2026-07-23ヒアリングシート回答E)docs/staff-review-menug1.md C-3項目、現場回答は未記入)。
8. 仕入関係Excelジョブが付け加えているもの
source/outsourcing/には以下のExcelファイルが存在する。
仕入伝票.xlsx仕入伝票(備考あり).xlsm仕入伝票印刷.xlsm
これらはGSBS01/02/10が起動するBAT0201.XLSM(本体はsource/as400-workspace/WorkSpace/配下、あるいは同等の配布物)に対応する、PC側の帳票印刷マクロと考えられる。AS/400側はSFDPP2という17項目のステージングテーブルにデータを書き出すだけで、実際の紙面レイアウト・「備考あり」版の書式切り替えはExcelマクロ側が担っている。 (出典: pilot/spec/itsi10r.md「Downstream: BAT0201」節) Excel/VBA
仕入伝票印刷.xlsmはSFDPP2.xlsを無人印刷し、印刷後にコピーを仕入伝票(備考あり).xlsmとして保存する。この仕入伝票(備考あり).xlsmにはAuto_Openがなく、ボタン起動のPrint_Sheet()のみを持つ——人間が後で開いて備考欄を手書き入力し、ボタンで再印刷するという明確な手動ステップが確認できた。同様に
支払明細表印刷.xlsm→支払明細表.xlsmも、後者は「正副印刷」という1ボタンマクロのみの薄いブックで、ラベルを「(正)」→印刷→「(副)」→印刷→「(正)」に戻すという正本・副本の2部印刷トリックを人間のボタンクリックで実行する。いずれもAS/400側で計算済みのSFDP系ステージングを整形・印刷するだけで、PC側の金額計算ロジックはほぼ持たない(請求書発行・支払案内書作成と同じ一貫パターン)。
(出典: 仕入関係/仕入伝票印刷.xlsm, 仕入伝票(備考あり).xlsm, 支払明細表印刷.xlsm, 支払明細表.xlsm)
BAT0206.XLSMも同様の位置づけ。AS/400側から見た「仕入関係Excelジョブ」が単なる印刷代行以上の業務ロジック(例: 追加の集計・按分計算)を持っているかどうかは、Excelマクロ自体を開いて確認しない限り判断できない。なお
BAT0201.XLSM/BAT0206.XLSMの本体そのものは、本リポジトリの仕入関係・受注票・売上関係・費用集計の4フォルダいずれにも存在しないことを確認した(findで確認)。同じ番号を持つsource/as400-admin/transport-tooling/ITLIBS/BAT0201.txt・BAT0206.txtやsource/as400-admin/transport-tooling/Work_Folder/BAT0201.dtf・BAT0206.dtfは別物(AS/400側CLソースメンバーITLIBS/QCLSRC(BAT0201)のバックアップ用Data Transfer定義)であり、命名の偶然一致に注意が必要。BAT0201.XLSM/BAT0206.XLSM自体は本番サーバー側の\\Server2\kanri\batch\CA\Batch\フォルダ(自動実行ログで実在が確認済みのパス)に存在すると推測されるが、本リポジトリには未取込のまま(推測、見積書発行フォルダで見つかった同種のリポジトリ範囲ギャップと同じパターン)。
新實さんへ「外注帳票のExcel(BAT0201/0206)は何を印刷していますか?」と尋ねたところ、両方まとめて「外注への注文書です」という回答だった。ソース側の設計ではBAT0201.XLSM=発注書(仕入伝票、GSBS01/02/10経由)、BAT0206.XLSM=支払明細書(GSBS06経由)という役割分担で追跡してきており(11節の帳票一覧参照)、字面通りなら回答は「BAT0206も注文書」という点でこの役割分担とズレる。ただし本ページ冒頭のcalloutの通り、GSBS06(支払明細書発行)自体が実務では運用されていないことが同じヒアリングで判明しており、新實さんが現在の実務で日常的に触れているのは注文書印刷(BAT0201)だけである可能性が高い——そのため2つのマクロ名を区別せず「注文書」とまとめて回答した可能性がある、というのが最も整合的な解釈だが、これは推測でありBAT0206.XLSMの内部ロジック自体が支払明細書用のままなのか、実際に注文書用に転用・統合されているのかは未確認のままである。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
9. 特殊ケース
特殊ケース: 分納受入(複数回に分けての納品) 【ヒアリングで判明】
現行システムでは分納は正しく扱えない。同じ発注に対して2回目の受入を入力すると、1回目の納入数・金額を上書きしてしまう(合算されない)。GSBS04の確認メッセージには「受入数合計>注文数」という文言があるが、実際は単発の入力値との比較であり「合計」ではない。 (出典: pilot/spec/itsi04r.md Open questions 3) 分納の実運用があるかどうかは新實さん本人の回答:「現在は、運用していません」——受入入力自体が実務では行われていないため(本ページ冒頭callout参照)、分納シナリオも発生しない。移行版でこの上書き仕様の修正を優先する必要は無い。 (出典: 新實さん、2026-07-23ヒアリングシート回答E)docs/staff-review-menug1.md C-2項目で現場確認中(未回答)。分納が実在するなら、新システムで仕様変更が必要な重要論点。
特殊ケース: 受入後の中止 【ヒアリングで判明】
受入済み(すでにGSBS04で受入登録済み)の発注でも、現行システムは変更・中止を止めない。受入済みの発注を中止すると、支払明細書(GSBS06)の集計対象から外れてしまう=支払われなくなる(4節参照)。実運用の有無は新實さん本人の回答:「現在は、運用していません」——受入入力自体が行われていないため、このシナリオも発生しない。 (出典: 新實さん、2026-07-23ヒアリングシート回答E)docs/staff-review-menug1.md A-3項目で現場確認中(未回答)。
特殊ケース: 明細ゼロ月 【ヒアリングで判明】
対象月に受入実績が0件のとき、現行システムはExcelが起動せず何も表示しない。新システムでは「0件です」という画面表示にする方向(GSBS06自体が実務では実行されていないため(7節参照)、このシナリオも発生しない。 (出典: 新實さん、2026-07-23ヒアリングシート回答E)docs/staff-review-menug1.md C-3項目、現場回答は未記入)。
単価改定
発注時の「希望単価」・受入時に別途入力する「仕入先見積単価」「決定単価」の3種類が並存する(3節参照)。これは「単価改定のたびにマスタを直す」という仕組みではなく、発注のたびに単価を都度入力する運用になっている。継続的な単価契約(外注先ごとの標準単価表のようなマスタ)は、少なくともMENUG1の範囲では見当たらない(未解明事項 — 別サブシステムに単価マスタがある可能性は否定できない)。
支給材(無償/有償支給)
MENUG1(外製管理)自体には支給材(会社側が材料を外注先へ渡す仕組み)を扱う機能は見当たらない。ただし「支給」という業務自体はこのシステムに広く存在する — ただし別サブシステム(MENUA1組付管理/MENUA2支給品管理)の対象で、対アイシン向けの「支給品」を管理するsmmp支給品マスタ、skdp支給品データなどがある。 (出典: docs/STATUS.md 1055-1095行目、docs/MIGRATION-MAP.md 808行目「AssemblySuppliedParts (組付・支給品管理) — MENUA1」)
この「支給品」は得意先(アイシン)から板倉製作所への支給であり、板倉製作所から外注先への支給材(無償支給/有償支給)とは別の業務と考えられる(推測)。板倉製作所→外注先の支給材管理がシステム上どこにあるか(あるいは存在しないか)は本調査では特定できなかった — 未解明事項。プレス外注の場合、材料(鋼板等)を発注元が支給するのが一般的な業界慣行であるため、実運用としては存在する可能性が高いが、紙・Excel等システム外で管理されている可能性もある。
検収 vs 受入 【ヒアリングで判明】
GSBS04「受入入力」は数量・単価・金額の記録が主目的で、独立した「検収(合否判定)」のステップ・フィールドはソース上確認できなかった。「受入=検収」として一体運用されているのか、品質保証部門が別途紙の検収記録を持っているのかは未解明事項。新實さんへのヒアリングにより、受入入力(ITSI04R)自体がそもそも実務で運用されていないことが判明したため(5節参照)、この問いはより根本的な理由で解消される——受入入力が行われていない以上、その内部で検収を兼ねるかどうかという問い自体が生じない。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
10. 実データスナップショット — 本番DBによる検証
itakura、読み取り専用接続)へ直接クエリした。対象はSFDP(仕入ファイル、23,194件)・SIMP(仕入先マスター、497件)。件数はいずれも想定通り。データの実際の年代幅は、SFDPの発行日(SFHAHI)ベースで1999年4月〜2026年(一部欠陥データを除く)と、想定の「7年分」よりはるかに長い期間をカバーしていた。
10.1 SFDPの年次推移(発注日ベース)と「受入未記録」問題
発行日(SFHAHI、全23,194件で欠損なし)を年単位で集計すると、2002〜2007年が発注件数のピーク(年2,000〜2,933件)で、その後は年200〜800件程度まで減少し、直近(2020年代)は年250〜500件程度で推移している。
| 期間 | 年平均件数 | 備考 |
|---|---|---|
| 1999〜2001年 | 約13件 | データ立ち上がり期(サンプル数僅少) |
| 2002〜2007年 | 約2,305件 | ピーク期。2003年が最多で2,933件 |
| 2008〜2013年 | 約449件 | 大幅減少(2008年は295件のみ) |
| 2014〜2019年 | 約683件 | やや回復 |
| 2020〜2026年(2026年は年途中) | 約388件 | 直近は横ばい〜微減傾向 |
なおSFHAHIには2030・2031・2040・2045・2088年という明らかに誤入力の未来日付が5件混じっている(AS/400の2桁年入力ミスと推測される、いずれも件数上は無視できる規模)。
5節で説明する通り、SFDPは「発注情報+受入情報を同じ行に持つ」テーブルで、発注時に空で確保され受入時に追記される設計。ところが実データを見ると、受入時に埋まるはずのフィールド(SFNOSU納入数・SFNNTN納入単価・SFNNKN納入金額)が値を持つ行は全23,194件中わずか98〜99件(0.4%)しかない。発行日(SFHAHI)は全件に入っているのに対し、受入完了を示すフィールドはほぼ空のまま、ということになる。
さらにその99件の内訳を見ると、2020年33件・2021年40件・2022年24件・異常値2件と、ほぼ2020〜2022年の3年間に集中しており、それ以外の年(1999〜2019年、2023年以降)には受入完了データが実質存在しない。これは「大半の発注が実際には受入未処理のまま」という意味ではなく、受入記録の運用またはこのDBへの取り込み方法自体が年代によって大きく異なっていた可能性を示す実データ上の食い違いであり、5節「検収 vs 受入」・未解明事項10とあわせて現場確認が必要な論点として追加する。
新實さんへのヒアリングで根本原因が判明した——「MENUG1はほとんど停止しています。(中略)受入れの入力もしていません」。つまり0.4%という極端な低さは取り込み時の欠落やバグではなく、受入入力自体がそもそも実務でほとんど行われていないという運用実態をそのまま反映した数字であると考えるのが自然。2020〜2022年に集中する99件についても、この運用停止と整合的な「ごく一部だけ試験的・例外的に入力された名残」と解釈できる(ただしこの3年間クラスタの具体的な経緯自体を新實さんが直接確認したわけではなく、あくまで整合的な推測にとどまる)。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
10.2 仕入先マスター(SIMP)の稼働実態
登録済み仕入先497件のうち、SFDPに実際に発注実績がある(SFCDSIとして1件以上出現する)のは77件(15.5%)のみ。残り84.5%はマスタには存在するが、少なくとも今回インポートされたSFDPの範囲では取引実績が確認できない。
発注件数(全期間・受入未完了含む)トップ10:
| 順位 | 仕入先 | 発注件数 |
|---|---|---|
| 1 | 株式会社 スペック | 14,472(全体の62.4%) |
| 2 | 藤塗装工業株式会社 | 3,853 |
| 3 | 小寺理研工業 | 1,100 |
| 4 | 井上メッキ工業 株式会社 | 906 |
| 5 | 株式会社 石実メツキ工業所 | 658 |
| 6 | 藤田螺子工業株式会社 | 548 |
| 7 | 日高工業株式会社 | 486 |
| 8 | 斉藤工機(棚尾) | 206 |
| 9 | 光塗装工業所 | 111 |
| 10 | 松川製作所 | 91 |
1位「株式会社スペック」だけで全SFDP行の62.4%を占め、上位2社(スペック+藤塗装工業)で78.8%に達する、非常に集中度の高い取引構造。両社とも社名から表面処理系(塗装・メッキ)の外注先と推測でき、10.3節の型種コード集計とも整合する。
11節(本ページ)や9. 売上・請求・支払・経理ページのマスタ表ではSIMP.SIKBWKを「使用停止フラグ」と説明しているが、analysis/out/schema.sqlのカラムコメントは実際には「処理区分」となっており、「使用停止」という意味は一次資料からは確認できない。
実データで確認すると、497件中SIKBWK='E'が354件・空欄が143件。もし「E=使用停止」なら、SFDPで実際に発注実績がある77件はほとんどが空欄側に集中するはずだが、実際にはE側が59件・空欄側が18件と、むしろ「E」フラグの仕入先の方が多く稼働している——という数字だけを見ると矛盾のように映る。
【ヒアリングで判明】新實さんへ「仕入先のSIKBWK='E'は『使用停止』ですか、別の意味ですか?」と尋ねたところ、「使用停止です。」と明確な回答があった——schemaコメントの「処理区分」表記とは無関係に、当初の「E=使用停止」という読みが正しかったことが確定した。ただしこれはSIKBWKの意味そのものの確認であり、上記の「E側の仕入先の方がSFDPに多く登場する」という実データ上の食い違いを直接説明するものではない——なぜ使用停止のはずのE側仕入先の方が稼働実績が多いのかという食い違いの原因自体は、今回の回答でも触れられておらず別要因として未解明のまま残る(意味の確定と実データの食い違いの説明は別問題であることに注意)。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)
【2026-07-29ヒアリングで完全クローズ】 「矛盾」という前提自体が誤りだったことが判明した。新實さんの回答: 「ながいこと仕事をしていると、付き合う仕入先も変わっていく。全く付き合わなくなったり、廃業されたりしてもデータをしては残しているので、使用停止の仕入れ先の方が多いのはむしろ当然」。SIMPは物理削除をしない累積台帳(論理削除方式)であり、取引終了・廃業した仕入先もレコードとして残る。SFDP(発注実績)は過去分も含む履歴なので、何十年分の累積では「もう使っていない仕入先」の方が「現役の仕入先」より多く登場するのは当然——矛盾ではなく、マスタ設計の当然の帰結。
移行への含意: 新システムでもSIMPは論理削除を維持すべき(過去の発注履歴が参照する仕入先レコードを物理削除すると履歴が壊れる)。SIKBWK='E'は「新規発注時の選択候補から外す」フィルタとしてのみ使い、履歴表示では使わないこと。
docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)
10.3 型種コード・種別の実データ確認
1節の「型種マスター(TYMP)の実体は外注依頼内容コード表」「100〜399=表面処理」という記述を、SFDP実データのSFCDKT(型種コード・加工内容)で確認したところ、23,194件中21,714件(93.6%)が100〜399番台に該当した。つまり板倉製作所の外製取引の9割以上が表面処理系の外注であることが、実データからも裏付けられる(10.2節の上位仕入先が塗装・メッキ会社である点とも一致)。
また、SIMPの種別(SICDSB)で仕入先を分類し直すと、SICDSB=1(外注、finance.html 9.5節のコード体系と共通)に分類される仕入先だけでSFDPの23,098件(99.6%)を占めた。SFDPが実質「外注専用」の台帳であるという1節の説明は、実データ上ほぼ100%成立している。
10.4 単価・金額の実データレンジ
3節で述べた「希望単価・仕入先見積単価・決定単価の3種類」のうち、発注時点で入力される希望単価(SFKTNI)は23,194件中1,863件(8.0%)にしか値が入っておらず、大半の発注が単価未定のまま登録されている実態が確認できた。受入完了行(10.1節の99件)に限定した決定単価・金額は次の通り。
| 項目 | 件数 | 中央値 | 平均 | 最大 |
|---|---|---|---|---|
| 希望単価(SFKTNI、0以外) | 1,863 | 180円 | 1,167円 | 850,000円 |
| 決定単価(SFNNTN、受入完了分) | 約98 | 1,900円 | 4,964円 | 28,500円 |
| 納入金額(SFNNKN、受入完了分) | 約98 | 7,200円 | 9,429円 | 32,000円 |
希望単価の最大85万円は明らかに個別の単価行(金型製作費のような一式費用)とみられ、中央値180円との差が大きい点は「小ロット・低単価の量産部品加工が主で、まれに高額な単発案件が混じる」という外注取引の性格を反映していると考えられる。
10.5 季節性
発行日(SFHAHI)を月別に集計すると、6月(2,336件)・7月(2,376件)がピーク、8月(1,682件)が谷という緩やかな季節性が見える。8月の落ち込みはお盆休みによる稼働日減少と考えるのが自然だが、月ごとの差は最大でも1.4倍程度で、劇的な季節変動というほどではない。
集計に使ったSQL
-- SFDP行数・発行日カバレッジ(検証環境/10.1)
SELECT count(*), min(sfhahi), max(sfhahi) FROM sfdp;
-- 年次推移(10.1)
SELECT (sfhahi/10000)::int AS yr, count(*) n FROM sfdp GROUP BY yr ORDER BY yr;
-- 受入完了フィールドの充足率(10.1)
SELECT count(*) total,
count(*) FILTER (WHERE sfhahi IS NOT NULL AND sfhahi>0) has_hahi,
count(*) FILTER (WHERE sfnosu IS NOT NULL AND sfnosu<>0) has_nosu,
count(*) FILTER (WHERE sfnntn IS NOT NULL AND sfnntn<>0) has_nntn,
count(*) FILTER (WHERE sfnnkn IS NOT NULL AND sfnnkn<>0) has_nnkn
FROM sfdp;
SELECT (sfnohi/10000)::int AS yr, count(*) n FROM sfdp
WHERE sfnohi IS NOT NULL AND sfnohi > 0 GROUP BY yr ORDER BY yr;
-- 登録済み vs 稼働中の仕入先(10.2)
SELECT count(DISTINCT sicdsi) FROM simp;
SELECT count(DISTINCT sfcdsi) FROM sfdp;
-- 発注件数トップ10(10.2)
SELECT s.sicdsi, s.sinmkj, count(*) n
FROM sfdp f JOIN simp s ON s.sicdsi = f.sfcdsi
GROUP BY s.sicdsi, s.sinmkj ORDER BY n DESC LIMIT 10;
-- SIKBWK実データと稼働実績のクロス集計(10.2)
SELECT sikbwk, count(*) FROM simp GROUP BY sikbwk;
SELECT s.sikbwk, count(DISTINCT f.sfcdsi) used_in_sfdp
FROM simp s LEFT JOIN sfdp f ON f.sfcdsi = s.sicdsi GROUP BY s.sikbwk;
-- 型種コード・種別の分布(10.3)
SELECT count(*) FILTER (WHERE sfcdkt BETWEEN 100 AND 399) surface_treat,
count(*) FILTER (WHERE sfcdkt NOT BETWEEN 100 AND 399 OR sfcdkt IS NULL) other
FROM sfdp;
SELECT s.sicdsb, count(*) n_rows FROM sfdp f JOIN simp s ON s.sicdsi=f.sfcdsi GROUP BY s.sicdsb;
-- 単価・金額のレンジ(10.4)
SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY sfktni) median, avg(sfktni), max(sfktni), count(*)
FROM sfdp WHERE sfktni > 0;
SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY sfnntn) median, avg(sfnntn), max(sfnntn),
percentile_cont(0.5) WITHIN GROUP (ORDER BY sfnnkn) median_kingaku, avg(sfnnkn), max(sfnnkn)
FROM sfdp WHERE sfnntn > 0;
-- 月別季節性(10.5)
SELECT (sfhahi::bigint / 100) % 100 AS mon, count(*) n FROM sfdp WHERE sfhahi > 0 GROUP BY mon ORDER BY mon;
11. 関連マスタ・データ/帳票一覧
マスタ(参照専用)
| マスタ | テーブル | 内容 |
|---|---|---|
| 仕入先マスター | SIMP | 仕入先コード・名称・住所・振込銀行支店・支払条件など (出典: analysis/out/masters_registry.json simpエントリ) |
| 型種マスター(加工種類) | TYMP | 実質「外注依頼内容」コード表。100-399=表面処理系(1節) |
| 作業者マスター | SGMP | 発注者コード |
| 受注品番マスター | JHMP | 受注品番⇔品名⇔得意先の紐付け |
| 構成マスター | KSMP | 部品の親子構成+内外コード(内製/外注の判定) |
| 得意先マスター | TKMP | 得意先名 |
| 設計№マスター | SNMP | 設計№⇔品番の紐付け |
トランザクションデータ
| データ | テーブル | 内容 |
|---|---|---|
| 仕入ファイル | SFDP | 外注発注1件=1行。発注情報+受入情報を同じ行に持つ(発注時に空で確保、受入時に追記) |
| 仕入伝票印刷FOR EXCEL | SFDPP2 | 発注書印刷用ステージング(都度クリア) |
| 支払明細表印刷FOR EXCEL | SFDPP3 | 支払明細書印刷用ステージング(都度クリア) |
| 支払費用データ(経理側) | SHDP | 支払条件・振込先などの請求管理データ(本サブシステムの範囲外、経理入力) |
帳票一覧
| 帳票 | 生成元 | 用途 |
|---|---|---|
| 発注書(仕入伝票) | GSBS01/02/10 → ITSI10R → Excel/VBA BAT0201.XLSM | 外注先へ渡す注文書 |
| 支払明細書 | GSBS06 → ITSI13R → Excel/VBA BAT0206.XLSM | 外注先への支払内容の明細(月次) |
| 外製加工費用問合せ | GSBS13(画面表示のみ、帳票化なし) | 受注品番別の外注費用一覧 |
欠落プログラム 使用停止
GSBS05, 07, 08, 09, 11, 12, 14〜21, 23〜26 の19本はメニューに項目として存在するがソースが見つかっていない。ラベルも空欄で、docs/decisions.mdのD6調査で「空ラベル=実質死んでいるメニュー項目」と判定されている。 (出典: docs/decisions.md「19 dead slots omitted (blank-label proven dead in D6 sweep)」) つまり実運用で使われている外製管理機能は、確認できた7本(GSBS01/02/03/04/06/10/13)でほぼ全てと考えてよい。【2026-07-29ヒアリングで確定】 新實さんより「未使用」と明確に確認され、D6調査時点の推定は顧客証言により確定に変わった。KSML1の例(B8、archived source found by re-search)を踏まえるとこの19本もsource/配下の再点検で見つかる可能性はあるが、未使用が確定した以上探す実益は無く、追わない。(出典: 新實さん、2026-07-29ヒアリングシート回答、hearing.html E4、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)
12. 用語集
- 外製/外注
- 社外の協力会社に加工・処理を委託すること(本システムでは同義で混用)
- 仕入先
- 外注先・購入先の総称。SIMPマスターで管理
- 発注№
- 仕入先×月ごとの連番(YYMMNNNN形式)。伝票№とも呼ばれる
- 内外コード
- 部品ごとに内製か外注かを区分するコード(KSMP、1=内製/2=外注)
- 型種(加工種類)
- 実質は「外注先への依頼内容」コード。100-399=表面処理
- 希望単価
- 発注時に仮に入れる単価
- 仕入先見積単価
- 外注先から提示された見積単価(受入時に入力)
- 決定単価
- 実際に確定した支払単価(受入時に入力、支払明細の基礎)
- 中止区分(SFD201)
- 発注の取消フラグ(' D')。物理削除ではなくソフト削除
- 印刷済フラグ(SFKBWK)
- 発注書が印刷済みかどうかの管理フラグ
- 単価通知区分(SFKUTT)
- 「単価連絡表」という別帳票を発行したかどうかの管理フラグ
- 受入
- 外注先から品物が戻ってくること、およびその記録作業
- 検収
- (本システム上は独立工程として未確認)品質面での合否判定
- 支給(材)
- 発注元が材料・部品を委託先へ渡すこと(無償/有償の別あり)。MENUG1範囲では未確認
- 締め
- 月次で受入実績を確定し支払明細を作成する区切り(GSBS06が担当)
- 支払明細書
- 仕入先・対象月ごとの受入実績の集計帳票。経理への引き渡しデータ
- 支払費用データ(SHDP)
- 経理側が管理する請求・支払方法(振込/手形/小切手)データ
- 単価連絡表
- 外注先へ単価を通知する別帳票(詳細は本調査未解明)
- 構成マスター(KSMP)
- 製品の部品構成(親品番⇔子部品番)とその内外区分を持つマスタ
13. 他業務との接続点
上流(このサブシステムに入ってくるもの)
- 受注/生産指示: 発注入力(GSBS01)は受注№・受注品番・設計№を起点に対象を特定する。受注データ(JUDP)・製造指示データ(SJDP)・受注品番マスター(JHMP)を参照する。つまり「お客様の注文」または「社内の製造指示」が外注発注の出発点。 (出典: pilot/spec/itsi01r.md Target resolution節)
- 構成マスター(KSMP): どの部品が外注対象か(内外コード=2)を決めている上流データ。BOM設計・原価企画(型種コードの割当を含む)は本サブシステムの外側で行われていると考えられる(推測)。
下流(このサブシステムから出ていくもの)
- 経理・支払(MENUR1): 7節の通り、支払明細書(SFDPP3)が経理への引き渡しデータ。実際の支払実行(振込・手形・支払総括書)は9. 売上・請求・支払・経理「経理管理サブシステム」の担当 — 本ガイドの範囲外。
- 原価把握: 外製加工費用問合せ(GSBS13)が受注品番別の外注コストを提供しており、これは製品単価入力(ITUR01R、得意先向け販売単価の設定画面)が持つ「外注費用」という原価内訳項目(PRHYGU)と対応関係にあると考えられる(推測)。 (出典: pilot/spec/itur01r.md 65行目) ただしGSBS13とITUR01Rの間にデータの自動連携があるかは確認できていない(要確認)。
材料(支給材)
9節の通り、板倉製作所→外注先への支給材の管理箇所は本調査で特定できず。対アイシン向けの「支給品管理」(MENUA1/A2)は方向が逆(得意先→自社)であり、別業務と考えられる。
現場向け確認シートdocs/staff-review-menug1.md(12項目、外注担当者宛て)に対し、新實さんから2026-07-23付でセクションE(外注・仕入担当)の回答一式が届いた。最大の発見はMENUG1がほとんど停止しており、注文書印刷専用に縮退している(受入入力・支払明細発行はいずれも実務では行われていない)という根本事実で、本ページ冒頭のcalloutと各節に反映済み。以下、項目ごとの解決状況。
型種コード(100-399=表面処理)の個別コード名(めっき/熱処理/塗装など具体名)の実データ一覧—— 部分解決: 100番台=鍍金、200番台=塗装と判明(1節)。ただし新實さんご本人も記憶ベースの回答であり現在の実運用状況は営業部へ確認要。300番台以降は今回も未回答。「単価通知なし」版(ITSI04R)に対応する「単価通知あり」版の受入プログラムの実在・仕様。—— 解決: 受入入力(ITSI04R)自体が実務では運用されていないため、この論点は実害を及ぼさない(5節)。支払明細書(SFDPP3、GSBS側の金額)と支払費用データ(SHDP、経理入力の請求金額)の間の突合・整合確認の実際の運用方法。—— 解決: GSBS06側の支払明細発行自体が運用されていないため、突合すべき「もう一方」が実在せず、突合問題そのものが発生しない(7節)。GSBS05/07/08/09/11/12/14-21/23-26(19本)— ソース欠落、機能不明(D6調査により実運用では使われていない可能性が高いと判定済み)。今回のヒアリングでも言及なし、未解明のまま残る。—— 完全解決: 2026-07-29のヒアリングで新實さんより「未使用」と明確に確認された。D6調査時点の推定(可能性が高い)が顧客証言により確定に変わり、19本は移行対象外。(出典: 新實さん、2026-07-29ヒアリングシート回答、hearing.html E4、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)分納受入の実運用有無(C-2、現場未回答)。—— 解決: 「現在は、運用していません」(9節)。受入済み発注の変更・中止の実運用有無(C-1、A-3、現場未回答)。—— 解決: 「現在は、運用していません」(4節・9節)。対象月0件時の支払明細書の要否(C-3、現場未回答)。—— 解決: GSBS06自体が実行されていないため発生しないシナリオ(7節)。再発行時に単価連絡表を出し直す必要性(C-4、現場未回答)。—— 解決: 「現在は、運用していません」(9節)。- 板倉製作所→外注先への支給材(無償/有償)管理の所在 — 本調査では特定できず。今回のヒアリング対象外、未解明のまま残る。
検収(品質合否判定)が独立工程として存在するか、その記録場所。—— 解決: 受入入力自体が運用されていないため、検収を兼ねるかという問い自体が生じない(5節・9節)。内外コード—— 解決: 中間S/A(サブアセンブリ)品番を、独立して外注する場合にのみ通常部品と区別してタグ付けするコード。構成展開時は無視される(1節)。'10'の正確な意味(部品リンクとしての用法とKSMPそのものの意味の関係)。- Excelマクロ(BAT0201.XLSM/BAT0206.XLSM)側の内部ロジック —— 【所在は実VBAで解明、内部ロジックは未解析のまま】 本体そのものが本リポジトリの4フォルダ(仕入関係・受注票・売上関係・費用集計)いずれにも存在しないことを確認した。同名の
BAT0201.txt/.dtfはAS/400側CLソースのバックアップ用転送定義で別物。実体は本番サーバー\\Server2\kanri\batch\CA\Batch\にあると推測されるが未取込のため、内部ロジックの検証自体は依然として未解析。ヒアリングでは両マクロとも「外注への注文書です」という回答を得たが、これは設計上の役割分担(BAT0206=支払明細書)とズレる可能性があり、GSBS06自体が実務で使われていないことと合わせて8節で別途整理した——未解明部分が残る。\\Server2\kanri\batch\CA\Batch\フォルダ全体を追加でリポジトリに取り込んでよいか(見積書関連と同じ収録漏れパターン)、現場に確認したい。 (実データで新たに判明)受入完了フィールドの空白問題: SFDP全23,194件のうち、受入完了時に埋まるはずのフィールド(納入数・決定単価・納入金額)に値があるのはわずか99件(0.4%)で、しかもほぼ全て2020〜2022年に集中している。—— 解決: 受入入力自体がほぼ運用されていないという運用実態をそのまま反映した数字と判明(10.1節)。(実データで新たに判明)SIMP.SIKBWKは本当に「使用停止フラグ」か —— 部分解決: 「使用停止です」と意味自体は確定(10.2節)。ただし実データで—— 完全解決: 2026-07-29のヒアリングで「食い違い」という前提自体が誤りだったと判明した。SIKBWK='E'の仕入先の方が空欄より多くSFDPに登場するという食い違いの原因自体は今回も説明されず、未解明のまま残る。SIMPは物理削除をしない累積台帳(論理削除方式)で、取引終了・廃業した仕入先もレコードとして残るため、SFDP(発注実績、過去分含む履歴)でE側が多く登場するのはマスタ設計の当然の帰結——矛盾ではない。詳細は10.2節のcallout参照。(出典: 新實さん、2026-07-29ヒアリングシート回答、hearing.html E3、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)
(出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照、hearing.html セクションE)
主要ソース一覧(証跡索引)
analysis/out/menu_tree.md— MENUG1メニュー構成analysis/out/pilot_MENUG1.md— プログラム/テーブル/画面一覧pilot/spec/itsi01r.mditsi02r.mditsi04r.mditsi08r.mditsi09r.mditsi10r.mditsi13r.mditsi22r.md— 各プログラムの詳細仕様pilot/spec/rsbs01-itsw10r.mdrsbs06-07-10-11-23.md— 経理側(支払)の接続点pilot/spec/itgo12r.mditzr12r.mditgo42r.md— 内外コード(KSCDNG)の実例source/as400-admin/transport-tooling/ITLIBS/TYMP.txtKSMP.txt— マスタ定義ソース(SHIFT-JIS)analysis/out/masters_registry.json— 仕入先マスタ等のカラム定義pilot/app/public/data/screen-help.json— 画面説明・入力ガイド文言docs/MIGRATION-MAP.md— ドメインモデル、AccountsPayableとの境界docs/decisions.md— D6/D7調査の意思決定記録docs/staff-review-menug1.md— 現場向け確認シート(未回答分あり)source/outsourcing/*.xlsx, *.xlsm— 外注帳票印刷Excelマクロ(未解析)