7. 出荷

完成品在庫（または生産完了した受注）を、実際にお客様（トヨタ紡織・アイシン・デンソーなど）へ送り出すまでの一連の処理。受注データ(JUDP)1行＝1受注明細という構造が出荷まで貫かれ、出荷専用の別ファイルは存在しない。

1. 業務の目的と位置づけ

出荷業務は、生産完了した受注をお客様の工場へ届けるまでの最終工程。大きく4段階で進む。

1. 出荷指示 JSBS08 / JSBS09
   どの受注をいつまでに出荷するか、社内向けに指示書を発行する。
   担当: 出荷担当
2. 出荷準備 JSBS10
   現場が現品をピッキング・梱包し、生産完了＝出荷準備完了をシステムに記録する。
   担当: 生産ライン
3. 出荷実績入力 SSBS01（ITND50R）
   実際に出荷した日・数量・伝票№を受注データ(JUDP)に記録する。
   担当: 出荷担当
4. 在庫展開 SSBS02（ITND01R）
   出荷が確定した分だけ、完成品・部品の現在庫数を一括で減算する。
   担当: 出荷担当（別実行）

このあと下流の売上計上（請求書発行、ITS000R/001R/002R系）へ引き継がれる。売上計上は財務エージェントの領域だが、JUDPレコードの JUNOHI（納入日）・JUSEHI（請求対象年月）が橋渡しキーとなる。(出典: itnd50r.md #UPDATセクション)

2. 出荷指示のフロー

JSBS08 出荷・組付指示書発行（オーケストレーター）

エントリ: MENUJ1（受注管理）オプション8 → CL JSBS08 → JSBS08C 本体。JSBS08Cはそれ自体はデータ処理を一切行わない、純粋なオーケストレーター。画面（JSBS08D）は確認のみ・入力項目なしで、実行キーを押すと最大6回までExcelが自動起動する旨が画面に明記される。(出典: jsbs08c.md「Purpose」節)

パイプラインは6フェーズ・22の子プログラムから成る固定シーケンス:

「何を印刷するか」＝6種類のBATプログラム（すべて Excel/VBA）:

「何を決めるか（引当）」は出荷指示書発行（ITSJ07R）が担う。在庫確認 PBZKCKR（読み取り専用）と在庫マスタ処理 PBZKUPR（実際にZKDPの引当数・現在庫数を増減する在庫引当エンジン）を呼び出し、その日出荷できる分の在庫を実際に押さえてから受注データにスタンプを打つ。これはRPGの実物コールで、Excel帳票のBAT0109はあくまで印刷担当（ITSJ07Rは印刷を持たず、印刷はJUDPP1ステージングテーブル経由でBAT0109のExcelマクロが担う）。(出典: itsj07r.md「Purpose」節)

【ヒアリングで判明】フェーズ5のITSS08R（部品展開・在庫引当）は、新實さんの確認では試作品（受注区分２）の受注経路における「肝」の処理にあたります。試作品はMENUT→MENUA（前段階）を経てMENUJ1のJSBS08へ進み、ここで部品展開と在庫引当が行われます。受注区分の全体像は3. 受注 §7を参照。(出典: 新實さん、2026-07-20メール、docs/feedback/analysis/2026-07-20-niimi-shijikeitai.md参照)

各BATプログラムの実体は「サーバー2台目 \\SERVER2\KANRI\BATCH\<name>.XLSM を開いてマクロを実行するだけ」の薄いCLラッパー。現行の移行版TypeScriptではこのステップを「ログを出してスキップ（PRINT-SEAM defer-loud）」として実装している。(出典: jsbs08-seam-and-stubs.md §B)

JSBS09 出荷指示書発行（号口）との違い

JSBS09 はJSBS08と別の独立CLで、ITSJ05R を呼ぶ。JSBS08が「出荷・組付指示書発行」という全パイプライン（単品出荷品も組付品も両方処理）であるのに対し、JSBS09（ITSJ05R）は「号口」区分専用にITSJ01R をPMKBN='G'で呼び、日付判定にCLMPではなくDCMP（ＤＫカレンダー）を使う点が異なる。(出典: itsj05r.md; menuj1-open-questions.md #84)

3. 出荷準備

JSBS10 号口出荷準備完了入力（ITJM79R）

MENUJ1オプション10。号口（JUD605=51〜69）の受注1件について、「生産ラインが出荷準備を完了した」ことを記録するだけの小さな画面。サブファイルなし、作業者コードサインオンなし、証跡プリントなし、在庫演算も一切なし — 4節のITND50R（出荷入力）と比べてはるかに単純。(出典: itjm79r.md「Purpose」節)

記録する内容:

対象条件: JUKUED=0（未完了）、JUKUST=blank（中止でない）、JUD605が51〜69（号口）のみ。この画面は号口専用で、それ以外の区分は「この受注№はこのプログラムでは消し込みできません」というエラーで弾かれる。(出典: itjm79r.md #CHECK)

出荷準備Excelジョブ Excel/VBA

ディレクトリ source/shipping/出荷準備/ には品番ごとに個別のExcelファイル（例: 047460-0580.xls, 146250-4861.xls など、品番№がファイル名）が大量に格納されている。内容は現物のピッキング・梱包手順書（写真付き、PHOTOサブフォルダあり）、荷姿の説明、納品書の作成手順（「納品書の処理手順（デンソー機工）.xls」「同（ヒサダ）.xls」「同（浅賀井製作所）.xls」「同（アイシン機工）.xls」等、取引先ごとに個別の納品書作成マニュアルが存在）、完成ストア入庫前検査（完成ストア入庫前検査/A-様式.xls）、表面処理準備作業（表面処理準備作業/B-様式.xls）のチェックリスト、および全体の「出荷作業手順書」が含まれる。

「出荷準備データ検索.xlsx」もVBAなしの静的ファイルで、中身はAS/400への問い合わせではなく、得意先/品番/品名の一覧表から同フォルダ内の各品番手順書ファイル（および完成ストア入庫前検査/A-*.xls・表面処理準備作業/B-*.xls）へのハイパーリンク集（外部リンク約40件、ExcelのTargetMode="External"）だった。いわば「どの品番の手順書がどこにあるか」を引くための手作業インデックスであり、検索エンジンやAS/400クエリではない。(出典: 出荷準備データ検索.xlsx sharedStrings.xml/rels実測)

出荷準備/の各ドキュメントは、JSBS10（ITJM79R）が記録する「生産ラインが出荷準備を完了した」という事実の裏側で実際に行われる手作業（ピッキング・梱包・検査・表面処理準備）を支えるデスクリファレンスであり、JSBS10からもJSBS10へも自動的な読み書きは無い——JSBS10はJUKUED=8等のスタンプを打つだけの小さな画面（3節冒頭参照）で、実際の作業手順はこれらのExcel文書に完全にオフシステムで存在する。

品番紙・現品票 — 出荷指示書発行/のExcel/VBA実測

JHMP（受注品番マスター）のJHD033（品番紙要不要）フラグで、品番ごとに「品番紙（品番ラベル/かんばんラベルに相当）」を印刷するかどうかを制御する。(出典: itjm59r.md)

この設定は JSBS45（ITJM59R 品番紙情報入力）画面で保守する。実際の品番紙印刷そのものはAS/400側ではなくPC（Excel）側で行われる（原文コメント引用: 「09/11/03 変更 デンソー機工向けのすべての号口品に品番紙が要るようになったため、デンソー機工の製品についてはAS400側が作成しない設定になっていてもPC側で要るように変更するようにした」）。この引用は品番紙印刷（ロット№付）.xlsm内の09/10/30付変更履歴コメントとほぼ同一文面で、VBA側の記述として直接確認できる。

source/shipping/出荷指示書発行/配下には他に「デンソー機工品番紙.xlsx」（マスタ原紙一覧、マクロ無し）・「品番紙個別印刷.xlsm」がある。後者はBAT系とは無関係の手動ツール: 操作者が「入力画面」シートに品番と必要枚数を最大8件手入力し、ボタンでマスタ原紙から品番紙をA4に割付印刷するだけで、AS/400ファイルもメールも一切扱わない（原本が見つからない品番はメッセージボックスで警告するのみ）。既存の1回限りの追加印刷・再発行に使われるとみられる。デンソー機工品番紙_<受注№>[_軍次].xlsという日付・受注№付きファイルはこのツールまたはマスタ原紙の出力スナップショットで、いずれもVBAを含まない。(出典: 品番紙個別印刷.xlsm VBA実測 Sub Main)

実業務手順書で解明 — デンソー機工向け品番紙の現場運用を記した2008年作成の社内手順書「デンソー機工　品番紙にロット№記入」（作成者: 新実、現ヒアリング回答者の新實さんと同一人物と見られる）には、実際のタグ書式が図示されている: 品番：Ｂ８０２１－５７６０２／ロットＮＯ：（作業指示書のロット№を転記）／梱口　個／仕入先名　㈱板倉製作所。手順は「メッキ完了後、東工場２Ｆへ移動→作業指示書のロット№を品番紙に手書きで転記し箱数分すべてに添付→出荷専用の指定箱（2008-01-17時点は緑１号箱・200個入り、変更の可能性ありと注記）に移し替えて品番紙を付け替える」という2段階。この2008年時点の手順は手書きでロット№を記入する運用であり、本節前段のVBAコメント引用「09/11/03変更 デンソー機工向けのすべての号口品に品番紙が要るようになった」による自動化（BAT0811によるロット№印刷）は、この手書き運用より後に導入されたものと見られる。(出典: source/work-procedures/作業手順書/デンソー機工　品番紙にロット№記入.doc参照)

品番紙データは「メール定期自動送信」ジョブでも定期的に添付ファイルとして送信されている（添付ファイル/*_品番紙データ.xls、6節参照）——これは出荷指示書発行.xlsmのSub JOB_Hinbansi／Hinbansi_Data_Sendが生成するもので、BAT0109（出荷指示発行）が走るたびに号口(G)かつ入り数に対して端数のある品番だけを対象に作成される（6節で詳述）。

4. 出荷実績 — SSBS01 出荷入力（ITND50R）

いつ・誰が記録するか

MENUS1（出荷管理サブシステム）オプション1「出荷入力」。生産完了した受注（JUKUED=8、つまり出荷準備が済んだ状態）に対して、実際に出荷したという事実を記録する画面。操作者コード（SGMPマスタ）のサインオンが必須。(出典: itnd50r.md「Purpose」節、画面フローGMRD)

何を記録するか（GM2詳細画面の入力項目）

4つのモード（機能キーで切替）:

1. 追加
   生産完了済み受注に対して初めて出荷を記録する。前提条件: JUKUST≠'D'（中止でない）・JUNOHI=0（未出荷）・JUKUED=8（生産完了済）・JUD104≠9（在庫引落未完了は不可）。
2. 修正
   既に入力済みの出荷内容を訂正する。プルーフリストに前/後2行で印字される。
3. 中止補償
   中止（キャンセル）済み受注に対する補償出荷を記録する。
4. 削除
   出荷入力を取り消し、受注を未出荷状態に戻す。

各モードで受付前提条件が異なる。詳細は pilot/spec/itnd50r.md「Validations」節を参照。トランザクションごとにQPRINT（出荷入力プルーフリスト）へ証跡が印字される（作業内容/受注№/出荷日/出荷数/打切区分/伝票№/伝票区分/受注品番/得意先/注残数の列）。

納品書・受領書の印刷について

ITND50R自体はプルーフリスト（内部証跡）のみを印刷し、得意先向けの納品書・受領書は発行しない（仕様書に明記された事実）。推測 得意先向け納品書は前述の「出荷準備」Excelジョブ側（取引先別の納品書作成手順書、3節参照）で別途作成されると見られるが、具体的なタイミング・ツールは特定できず未解明事項5。

【ヒアリングで判明】「出荷準備Excelジョブ側で別途作成」という上記の推測は誤りだったと確定した——新實さんの回答: 「基本的に納品書は客先指定納品書が中心。受注後客先より印刷されたものを渡されるか、データで受け取って印刷するものが多い。手書き伝票だが客先指定のもの、当社の手書き伝票と混在しているが、納品書をAS400から発行することはない。製品が完成し（在庫含む）納期が一定期間内になったら、出荷指示書がAS400より発行され、それを元に納品書を手書きで記入、出荷指示書が営業課に回収され、営業課で出荷入力される」。つまり得意先向け納品書はAS/400からもExcelジョブからも発行されず、客先支給または当社手書きのいずれかであり、AS/400が発行する出荷指示書は納品書そのものではなく、営業課が手書き納品書へ転記するための社内トリガーに過ぎない。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照、hearing.html C9)

5. 在庫展開 — SSBS02 出荷データ在庫展開（ITND01R）

【ヒアリングで判明】SSBS02の実行頻度・タイミングについて、新實さんの確認により運用ルールが判明した: 「SSBS01を実行した後に、SSBS01実行者がSSBS02を実行することになっています。基本的に1人が１日１回実行します。」——つまり自動化された日次バッチではなく、SSBS01を実行した本人がその都度続けて手動でSSBS02を実行するという担当者ベースの運用ルールであり、実務上は1日1回のペースで回されている。(出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照)

実業務手順書で解明 — 2001年作成の社内手順書「データフロー（出荷処理）」の図には、出荷入力（３－１）と出荷データ在庫展開（３－２）の間に「15:00〜17:00の間、データの不整合発生中」という注記が明記されている。当時から出荷入力と在庫展開の間に日次の時間差ウィンドウが存在し、その間は出荷済みでも在庫が未反映という状態が業務上想定されていたことがわかる——上記のヒアリングで判明した「1人が1日1回実行する」運用の、より具体的な歴史的裏付けと見られる。(出典: source/work-procedures/作業手順書/データフロー（出荷処理）.doc参照)

「展開」とは何をしているか

「出荷が確定した受注」を一括でスキャンし、完成品在庫（JHMP）と部品在庫（BHMP）をまとめて減算するバッチ処理。画面上の説明文をそのまま引用（ITND01D.txt）:

現在庫数から出荷した製品数を減らします。
組付する製品は、部品に直して部品の現在庫数を修正します。

「部品に直して」の部分が「展開＝BOM展開」に相当する処理で、構成マスタ（KSMP）をたどって組付製品を構成部品に分解し、各部品の現在庫数（BHZASU）を消費数量（＝構成数量×出荷数量）だけ減算する。(出典: itnd01r.md「#KSMP — BOM component walk」節)

対象の選び方

処理対象は「JUDL31」という論理ファイル（JUDPをキーJUNOJUで見たビュー）で、あらかじめ「JUNOHI>0（納入日あり）かつJUKBWN=blank（未処理）」の行だけに絞り込まれている。さらにRPGコード側で下記3条件すべてを満たす行だけが対象:

• JUKBWN = blank（未処理、二重チェック）
• JUKUED = 9（打切区分=9。値9の業務的な意味はソースにコメントが無く、「出荷確定/完了」という意味だと推測されるが未解明 — 未解明事項1）
• JUKUST ≠ 'D'（中止でない）

処理後はJUKBWN（出荷処理区分）に'E'をスタンプし、二重処理を防ぐ（同じ受注が2回展開されることはない）。

在庫減算の対象・条件

• 完成品在庫（JHZASU）とS/A在庫（JHD091）の減算は、JHD062（指示形態）が51〜69の範囲のときのみ行われる（この範囲の業務的な意味も未文書化 — 未解明事項2）。範囲外の受注は最終出荷日（JHEDSH）だけ更新され、在庫数は変わらない。
• 組付製品は構成マスタ（KSMP）を辿って部品ごとにBHZASU（部品現在庫数）を減算する。
• 特殊な「S/A状態で出荷される製品」用の例外テーブル（SHN/AHN配列、ハードコードされた品番2件のみ）がある — 拡張時は配列サイズも同時に直す必要がある注意書きがソースコメントに残っている。

実行方法とバックアップ

SSBS02は確認画面1枚だけの一括バッチ（対話的な項目入力は無し、実行キーで開始 or F3で中止のみ）。実行前に自動的に3ファイルのバックアップコピーが取られる（JUDP→JUDPSV, JHMP→JHMPSV, BHMP→BHMPSV）。これが唯一のロールバック手段であり、失敗時は手動でCPYFにより復元する必要がある。実行完了後は「"出荷データ在庫展開"処理が終了しました。」というメッセージが表示されるのみで、エラー時の個別通知は無い（欠品などは静かにスキップされる）。(出典: itnd01r.md「SSBS02C backup copies」節、「Validations」節)

6. 納入形態

出荷準備のExcelジョブ群のファイル名や納品書手順書（3節）から、取引先（デンソー機工、ヒサダ、浅賀井製作所など）ごとに異なる納品書フォーマット・処理手順が存在することが確認できる。推測 各得意先の受入形態（かんばん納入方式か通常納入方式か等）が異なるためと推測されるが、本調査で読んだソース内には「かんばん納入」と「通常納入」を明示的に区別する業務ロジック（フラグや分岐）は見つからなかった（未解明事項6）。

【ヒアリングで判明】「かんばん納入」と「通常納入」を区別する業務ロジックが出荷フロー内に見つからなかったのは正しかった——そもそも板倉側では区別しておらず、システムレベルの分岐ではないことが新實さんの回答で確定した。「客先からのかんばんを納品書として扱っている。通常の納入と同じ。客先から板倉へ一方通行。その指定日にいるだけのかんばんが発行される」「かんばんがあるのは、浅賀井製作所、ヒサダ、アイシンぐらい。デンソープレステックは納品書」。つまり客先が発行するかんばん自体をそのまま納品書として扱っているだけ（客先→板倉の一方通行）であり、それ以外の得意先（デンソープレステック等）は通常の納品書を使うという運用の違いにすぎない。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照、hearing.html C3)

かんばんという語自体は複数のspec（itgo40r.md, itjm56r.md/57r.md/58r.md, itjm81r.md, itsj81r.md/82r.md/84r.md等）に登場するが、これらは主に受注入力（内示/確定のかんばん情報取り込み）側の話であり、出荷業務そのものの中でかんばんが果たす役割は本ブリーフのソース調査範囲では確認できなかった。

メール定期自動送信ジョブに見える出荷案内らしきもの

source/as400-admin/mail-auto-settei/は出荷業務専用ではなく全社共通のメール自動送信基盤（設計書: 各業務プログラムが「メール本文Excelファイル」を所定フォルダに書き出すと、別プログラムが定期的にフォルダを監視しMailingList.xlsxから宛先を引いて送信する仕組み）。

これらは出荷案内メール（得意先向け）ではなく、社内向けの業務連絡メールと見られる（メールの宛先がMailingList.xlsx＝社内配布リストであることから）。得意先向けの出荷案内（ASN等）に相当する仕組みは本調査では発見できなかった（未解明事項12）。トラック便・納入時間に関する具体的な設定・マスタも本調査範囲では見つからなかった（未解明事項）。

7. 特殊ケース

再発行（JSBS14/24/25/26）

出荷・組付指示書の再発行は目的別に4種類のCLに分かれている:

JSBS25 出荷指示書再発行: 受注№を1件入力すると、既存の出荷指示内容（指示品番/品名/納期/指示数）を確認表示してから、ITSJ01R経由でJUDPP1に1件ステージングし、&KENSU>0ならBAT0109（Excel印刷）を起動する。JSBS08の全パイプラインを回さず1受注だけをピンポイントで再印刷できる小さな対話プログラム。(出典: itsj51r.md)

JSBS26 組付指示書再発行: 受注№を入力すると、既発行か未発行かをBJDP（組付部品状況）のBJKBWKから判定し、未発行ならBJD101=9/BJKBWK='S'（新規発行として在庫引当からやり直し）、既発行ならBJD101=1/BJKBWK='F'（既存引当のまま再発行）にスタンプし直すだけ。印刷そのものはこのプログラムでは行わず、次回のJSBS08C（オプション1-8）実行時に初めてBAT0108が呼ばれる — つまり「再発行フラグを立てるだけ」で即座には印刷されない設計。まとめ指示（BJD601=31）の受注はJSBS26では拒否されJSBS24（ITKM18R）に誘導される。(出典: itss04r.md「No &KENSU output」節)

分納出荷

打切区分（JUKUED）が「0＝継続（未打切）」の状態で出荷入力すると、受注は分納継続扱いとなり、同じ受注に対して複数回出荷入力ができる。組付側の分納再引当はJSBS08Cフェーズ5b（ITSS03R）が担当し、BJDPQ4という専用の作業キューテーブルで前回までの分納引当状況を管理する。(出典: itnd50r.md #UPDAT; jsbs08-seam-and-stubs.md §A.7)

直送

推測・未解明 直送（得意先から板倉を経由せず直接第三者へ出荷する形態）に相当する明示的なフラグ・分岐は今回読んだソース内には見当たらなかった（未解明事項8）。

【ヒアリングで判明・部分的】明示的なフラグ・分岐が見つからなかったのは正しいと確定した——新實さんの回答: 「直送は少ないがある。いずれも客先指定伝票と記憶している（営業課に確認要）。特に通常納品と区別することはしていない（納める先が違うだけ）」。つまり直送はまれだが実在し、システム上は通常出荷と同一のフロー（客先指定伝票）で処理され、単に届け先が違うだけで特別な分岐・フラグは設けられていない。ただし新實さん自身「記憶している」という留保付きの回答であり、確定には営業課への追加確認が必要と明言された（100%確定ではない）。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照、hearing.html C9)

出荷訂正（間違えた場合の是正）

SSBS01（ITND50R）の「修正」「削除」「中止補償」の3モードがそのまま訂正手段になっている（4節参照）。ただし以下の制約に注意:

• 修正・削除は「累積処理」（月次締め）が完了すると一切できなくなる（JUKBWN≠blank → MSG,14）。締め後の訂正は別ルート（社外/経理との調整）が必要と推測される。
• 在庫が既にSSBS02（在庫展開）で減算済みの場合、SSBS01側の削除・修正では在庫は自動的に戻らない（ITND50Rは在庫演算をしないため）。出荷を取り消したい場合、在庫の復元は別途手動対応が必要と見られる推測。【実資料で判明】 2008年のAS/400開発者自身のフロー分析に「在庫の増減は、在庫の入庫出庫では行われず、完成、出荷を基準に行われる。したがって不良等の通常以外の入出庫があった場合の連絡がないと確実に差異が発生してしまう」という明記があり、この手動対応の必要性は推測ではなく設計時からの既知の前提だったことが確認できた。当時から実地棚卸と理論在庫の差異を計算する専用パイプライン（ITGZ07R〜ITGZ11R）が運用されている。詳細はproduction.html §6.6参照。(出典: source/dev-archive/20081030_号口品棚卸在庫合わせフロー/号口品棚卸在庫合わせフロー 20081030　.xls参照)
• 修正モードのプルーフリストには前後（前/後）2行が印字され、変更内容の監査証跡が残る。

8. 実データスナップショット

ここまでの記述は仕様書に基づく。ここでは実際の7年分のAS/400実データ（PostgreSQL、587,000行）にSELECTクエリを実行し、出荷業務が実運用でどう現れているかを確認する。JUDP全体は45,545行。実運用データの主要な時期は2018年〜2026年（記載時点で7月）——2001〜2017年分は年数件〜十数件と極めて少なく、システム移行前後のテスト/サンプルデータと見られる。

8.1 年別出荷実績（JUNOHI基準）

JUDP全45,545行のうち36,537行（80.2%）が出荷済み（JUNOHI>0）で、残り9,008行は未出荷・進行中の受注明細。年間出荷件数は概ね4,000〜4,800件/年で安定しており、2020〜2021年がピーク。

8.2 打切区分（JUKUED）の実分布

8.3 中止区分（JUKUST）のNULL率

8.4 分納の実態

受注データ1行＝1受注明細という構造上、同一受注が複数回に分けて出荷される「分納」がJUDP上でどう現れるかを、親受注№（JUNOJO）でグルーピングして確認した。JUNOJOが自分自身の受注№（JUNOJU）と異なる——つまり明示的に別の親を持つ「分割された子行」——は45,545行中175行（0.4%）のみで、複数行を持つ親グループは151件（129件が2行、17件が3行、1件が5行）にとどまる。JUKUED=0（継続）が19.5%を占める一方で、実際に複数のJUDP行に分かれる分納は稀——大半の「継続」状態の受注は、同一行のまま出荷入力（SSBS01）を繰り返すことで分納を処理しており、行を分割する分納は例外的なケースにとどまると見られる。

参考: 未解明事項§9（まとめ指示の実運用影響範囲）に関連して、KMDP（まとめ指示データ）の実件数を確認したところ378行存在した。まとめ指示は実運用で実際に使われている実態があり、移行版でこの経路が未実装（W6スコープ）であることの潜在的な影響範囲は少なくとも378件規模ということになる（0件ではない）。

8.5 リードタイム（受注日→出荷日）

JUJUHI（受注日）からJUNOHI（出荷日）までの日数を、明らかな日付異常値（365日超、61件・0.17%、AS/400側の不正な日付起因と見られる）を除いた36,343件で集計:

中央値17日は号口の標準的な補充サイクルとしては妥当な範囲。ただしJUJUHIは号口の自動採番受注（生産ページ§3.1で述べた99xxxxxx受注№）も含む可能性があり、厳密な「顧客が発注した日〜出荷日」ではなく「JUDP行作成〜出荷」に近い可能性がある点は留意（要現場確認）。

8.6 出荷先の実データ（JUCDTK上位）

件数トップは冒頭リード文で名前が挙がる3社（トヨタ紡織・アイシン・デンソー）のうちデンソー系（デンソープレステック）で、僅差でトヨタ紡織が続く。3位以下は浅賀井製作所・ヒサダ・佐藤工業・山崎工業・鈴木鈑金工業所・エクセディ・コデラダイナックスといった板金加工の協力会社群が並び、実際の出荷先はリード文が示唆する大手3社だけでなく裾野の広いサプライチェーンであることが実データから確認できる。

-- 8.1 年別出荷実績
SELECT (junohi/10000)::int AS year, count(*), sum(junosu) FROM judp WHERE junohi>0 GROUP BY 1 ORDER BY 1;
SELECT count(*), count(*) FILTER (WHERE junohi>0) FROM judp;

-- 8.2 打切区分
SELECT jukued, count(*) FROM judp GROUP BY jukued ORDER BY count(*) DESC;

-- 8.3 中止区分NULL率
SELECT jukust, count(*) FROM judp GROUP BY jukust ORDER BY count(*) DESC;

-- 8.4 分納・まとめ指示
SELECT count(*) FILTER (WHERE junojo = junoju), count(*) FILTER (WHERE junojo <> junoju AND junojo>0)
FROM judp;
SELECT count(*) FROM kmdp;

-- 8.5 リードタイム
WITH d AS (
  SELECT to_date(jujuhi::text,'YYYYMMDD') od, to_date(junohi::text,'YYYYMMDD') sd
  FROM judp WHERE jujuhi>20000101 AND junohi>20000101 AND junohi>=jujuhi
)
SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY sd-od) FILTER (WHERE sd-od<=365),
       percentile_cont(0.9) WITHIN GROUP (ORDER BY sd-od) FILTER (WHERE sd-od<=365),
       avg(sd-od) FILTER (WHERE sd-od<=365)
FROM d;

-- 8.6 出荷先
SELECT jucdtk, count(*), sum(junosu) FROM judp WHERE junohi>0 GROUP BY jucdtk ORDER BY count(*) DESC LIMIT 10;
SELECT tkcdtk, trim(tknmkj) FROM tkmp WHERE tkcdtk IN (20,5000,30,6000,16);

9. 関連マスタ・帳票一覧

主要テーブル

すべて analysis/out/schema.sql に定義済み。

帳票一覧

注: BAT系はすべて \\SERVER2\KANRI\BATCH\<name>.XLSM を呼ぶ薄いCLラッパー。BAT0109とBAT0811の2本はExcelマクロ本体（VBA）が本リポジトリ出荷指示書発行/フォルダに実在することを確認済み（実VBAで解明、上記2節参照）。BAT0108/BAT0108A/BAT0108B/BAT0108C/BAT1001の5本は今回の調査範囲では見つからず、従来通りリポジトリ外（ネットワーク共有上のみ）と扱う。移行版アプリでは「印刷シーム（PRINT-SEAM）」として、ステージングテーブルへのINSERTとログ出力のみを行い、実際のExcel起動は延期している。

10. 用語集

出荷指示書

どの受注をどれだけ・いつまでに出荷するかを現場に示す帳票（単品出荷品向け）

組付指示書

部品を組み立てて出荷する製品向けの指示書

まとめ指示

複数の号口受注をひとまとめにして1回の組付指示にする仕組み（指示形態=31）

号口

量産品の受注区分（指示形態51〜69）。試作品と対比される

単品出荷品

組み立て不要でそのまま出荷する製品（指示形態11〜19）

打切区分（JUKUED）

0=継続（分納可）、8=生産完了、9=出荷確定・打切

中止区分（JUKUST）

'D'=受注キャンセル済み

出荷処理区分（JUKBWN）

在庫展開（SSBS02）が処理済みかどうかのフラグ（'E'=処理済）

受注処理区分（JUKBWJ）

出荷指示発行フローの初回通過フラグ

引当（在庫引当）

出荷予定分の在庫数量を確保すること。ZKDPで管理、PBZKUPR/PBZKCKRが実処理

展開（在庫展開）

組付製品を構成部品まで分解（BOM展開）し、完成品/部品それぞれの在庫を減算する処理

品番紙

現品に貼る品番ラベル（かんばんラベルに相当）。印刷はPC(Excel)側

客先伝票№

得意先が指定する伝票番号。操作者が手入力、システム自動採番なし

分納

1受注を複数回に分けて出荷すること

直送

得意先を介さず第三者へ直接出荷する形態。まれだが実在し、通常出荷と同一のフロー（客先指定伝票）で処理される、届け先が違うだけの扱い。【ヒアリングで判明・部分的】新實さん本人が「記憶している」との留保付きで回答——最終確定には営業課への追加確認が必要（hearing.html C9）

印刷シーム（PRINT-SEAM）

移行版で「Excel印刷を実行する代わりにログとステージングだけ行う」設計パターン

ステージングテーブル

印刷対象データを一時的に格納し、Excelマクロが読み取るための中間テーブル（JUDPP1, BJDPP2等）

ALCOBJ/DLCOBJ

AS/400のファイル排他ロック取得/解放。出荷入力・出荷指示発行等が使用

11. 他業務との接続点

• 受注（納期）: 出荷は受注データ(JUDP)そのものに出荷情報を上書きする形で行われるため、受注入力・受注変更（ITJM71R等、受注担当エージェント範囲）が出荷フローの前提データを作っている。受注品番マスター(JHMP)の品番紙設定(JHD033)や入り数(JHD061)も受注担当・出荷担当双方が触るマスタ。
• 生産（完成在庫）: 出荷準備（JSBS10）の前提はJUD605指示形態とJUKUED（打切区分）が生産完了を示していること。生産完了処理（生産管理エージェント範囲と推測）が「出荷できる状態」を作る。
• 売上計上（下流）: JUDP.JUSEHI（請求対象年月）はSSBS01の出荷入力時にJUNOHI（納入日）から自動生成され、これが請求書発行（ITS000R/001R/002R、財務エージェント範囲）が参照するキーとなる。「請求済」を示す独立フラグはJUDPに存在せず、請求済みかどうかはTK1P.T1DYSM（締日）による日付ガードのみで守られている（出荷入力(ITND50R)の日付検証ロジックがこの締日を参照）。つまり出荷担当が誤って締め済み月の出荷日を入力しようとすると弾かれる、という形で財務側の整合性が担保されている。(出典: menus1-open-questions.md)
• 得意先マスタの納入先情報: 得意先名(TKMP.TKNMKJ/TKNMRJ)は出荷入力画面・出荷指示書に表示されるが、個別の「納入先」を得意先とは別に持つマスタは今回のスキーマ調査（analysis/out/schema.sqlgrep）では見つからなかった。得意先コード(TKCDTK)＝納入先という1:1の運用と推測される推測（未解明事項7）。
• 製品単価・見積（ハンドオフ）: SSBS04/05/12/17/18（製品単価）は本ページの範囲外。ただしJUDPP1のp1nmtk（得意先名）等の表示用フィールドはTKMPを共通参照しており、マスタレベルでは単価担当領域と重複する。