3. 受注

得意先（トヨタ紡織・アイシン・デンソー機工など）からの注文書・かんばん・内示・EDIデータが、生産管理システム全体の「入口」である中核テーブル judp（受注データ）へどう収束していくかを追います。MENUJ1 受注管理サブシステム（JSBS01〜JSBS26、約203プログラム）が対象です。

1. 受注の位置づけ — システム全体の入口

受注管理サブシステム（MENUJ1）は、得意先からの発注情報を judp（受注データ） という単一の中核テーブルへ記録し、そこから社内の生産・購買・出荷の各業務へデータを流していく、生産管理システム全体の「入口」です。得意先からの発注は大きく3つの経路で judp に入ってきます。

いずれの入口を通っても最終的には同じ judp テーブルへ収束します（第4章参照）。judp に書かれた1行1行が、その後の 構成展開（BOM展開）→組付部品在庫引当→出荷指示書・組付指示書発行（JSBS08、出荷ドメイン）や、外製発注（外製管理サブシステムMENUG1、別ドメイン）の起点になります。受注データが誤っていれば、そのまま生産・購買・出荷のすべてに波及するため、MENUJ1は「入力ミスを構造的に防ぐ・修正履歴を残す」仕組み（3段階検証、JUDPR1監査ログ、二重ゲートなど）が特に厚く作り込まれています。実データでは、judpには2018〜2026年の間に45,545件の受注行が記録されており、この単一テーブルが日々どれだけの入口を受け止めているかがうかがえます（実データスナップショット参照）。

(出典: docs/MIGRATION-MAP.md:15,39-45, pilot/schema/menug1.sql:279-350)

2. 受注の種類（MECE分類）

MENUJ1における「受注の入り方」は、トリガー・入力者・データの性質で以下のように分けられます。同じ judp テーブルに書き込まれますが、入口ごとに固定値・検証内容が大きく異なります。

試作の受注経路については、専用の入口がなくタグで区別する特殊な仕組みのため、第7章で単独に扱います。

3. 標準フロー — 受注入力（JSBS01）ステップバイステップ

新人が最初に習う「一番シンプルな受注入力」の流れです。

1. GM0（タイトル画面） AS/400
2. GM1（ヘッダー入力） AS/400
   得意先コード、担当者名、受注者コード、受注日を入力する。TKMP（得意先マスター）で得意先名を自動デコード表示。
   担当: 受注担当オペレーター
3. GM2（明細入力） AS/400
   1画面5行のサブフィールで、行ごとに受注品番・受注数・納期・依頼区分・受注区分・試作№・伝票№・支給日・材支日・表面処理区分を入力する。 JHMP（受注品番マスター）で品名・担当班・指示形態を取得し、KSMP（構成マスター）で構成登録の有無を確認。
   担当: 受注担当オペレーター
4. 3段階の検証 AS/400
   ハードエラー（ブロック）・警告（advisory）・表示デコードのみ、の3段階で入力をチェックする（下記詳細参照）。
5. 確認パス AS/400
   全項目を入力保護した状態で警告メッセージを表示する。
6. 受注№採番・書込 AS/400
   jkmp（受注管理マスター）から受注№を採番し、judpへ1〜5件WRITE。QPRINTへ確認用プルーフリストが出力される。 GM1へループして次の受注ヘッダーを続けて入力できる。

3段階の検証ロジック

新人にとって「なぜこのメッセージで止まるのか／止まらないのか」を理解する最重要ポイントです。

(出典: pilot/spec/itjm71r.md:172-195,61-68,345-350,259-408)

受注№の採番（jkmpの仕組み）

受注№(junoju)は、jkmp（受注管理マスター）のキー999999にある単一の制御レコードのフィールドjkrnbn（最終使用№）から採番されます。ITJM71Rは、入力予定の最大件数ぶん（last+1〜last+5）を一括で候補予約し、実際に書き込んだ行数だけjkrnbnを前進させます（＝連続したブロックを確保する方式）。排他制御は、レガシーではCLレベルのALCOBJ JKMP *EXCLRDで行われていましたが、移植後はSELECT … FOR UPDATEをトランザクション内で使う、より堅牢な方式に置き換えられています。

(出典: pilot/spec/itjm71r.md:446-465, pilot/spec/menuj1-open-questions.md:654-667)

受注票（judpp2）への流れとBAT0103印刷

JSBS03C3（新規・設変の受注入力leg）・JSBS14（受注票再発行、第8章）の2つの入口だけが、印刷用ステージングテーブルjudpp2（43列）を触ります。両方とも実行前にCLRPFM JUDPP2で全消去してから、共通ビルダーITJM75Rが43列のレコードを書き込む「truncate-then-fill」方式です。書込件数&KENSU>0なら、両呼び出し元CLがCALL BAT0103（Excel/VBAの受注票印刷マクロExcel/VBA、本リポジトリには実体が存在しないため処理境界として記録するに留める）。

(出典: pilot/spec/itjm72r.md:400-421, pilot/spec/itjm74r.md:1-67,242-282, pilot/spec/itjm75r.md:1-49,155-164,332-378)

4. デンソー機工とのEDIデータ受信フロー

デンソー機工とは、受注入力（第2章の号口手入力）とは別に、完全に並行するEDI電子データ取込パイプラインが存在します。MENUJ1のメニューツリーから直接は到達できない「MENUD1（ＤＮＰＴ号口処理サブシステム）」という別サブシステム配下（DSBS群のCLラッパー）で動きます。

オリジナル系統 vs 変更系統

デンソーからのEDIフィードは2種類あり、データ自体にフラグはなくメールで届くファイル名によってどちらの系統かを判別します。それぞれが独立した「取込→変換→適用→印刷」のパイプラインを持ちます。

変更系統は、既存受注の数量増減・キャンセル・追加などの差分データを扱います（P3BFSU変更前数量／P3CHSU変更量／P3KUCH変更区分／P3JUSU変更後数量、というフィールド構成）。オリジナル系統は、その時点の全件再スナップショットで、まずITJM03R（デンソー機工号口内示取消処理）が対象受注をいったん取消してから、ITJM61R/62Rが新しいフィードから作り直します。既存の取消済み行との突き合わせで、可能な限り「復活」させて不要なキャンセル・再発行を減らす工夫がされています。

(出典: pilot/spec/dsbs-denso-orchestrator.md:22-35,136-208,236-263, pilot/spec/itjm03r.md:16-19, pilot/spec/itjm62r.md:23-39, pilot/spec/itjm63r.md:132-148,143-148)

パイプライン全体像

1. 外部メールボックス処理 Excel/VBA
   メール添付の固定長テキストを復号する（本リポジトリのスコープ外）。
2. 系統判定 BAT0013
   ファイル名を見て「オリジナル」か「変更」かを判定する。
3. PC→AS/400転送 Excel/VBA
   対応するExcel/VBAマクロ（BATDS04.XLSM/BATDS17.XLSM、CALL BATCH00経由）がデータ転送を行い、judpdkへ書き込む。
4. 件数チェック CTJUDPDK
   0件なら「オリジナル/変更を取り違えていないか」を警告して中断する。
5. 整形 ITJM60R/61R（オリジナル）／ ITJM60R/63R（変更）
   judpdkをjudpp3（西暦8桁変換・CVMPによる品番変換込み）に変換する。
6. 適用 ITJM62R（オリジナル）／ ITJM64R（変更）
   judpp3を突き合わせ、judp行を作成・復活・更新する。

(出典: pilot/spec/dsbs-denso-orchestrator.md:236-263, pilot/spec/itjm60r-61r.md:107-113,§2.3,§5.1, pilot/spec/itjm63r.md:132-148)

受信の実態 — メール受信から手動アップロードまで 【実VBAで解明】

「外部メールボックス処理」「PC→AS/400転送」という上記フローの中身を、DNKデータ処理フォルダのVBA調査で 具体的に確認できました。デンソープレステック側のサーバーが日次で自動メール送信します（送信元 dnpt-hashin@denso-presstech.co.jp、件名「[デンソープレステック発信情報]定期部品発注指示書」／ 「変更部品発注指示書」、本文に「このメールは、サーバより自動発信しております。本メールアドレスには返信しないで ください。」と明記）。宛先は共有メールボックスではなく特定個人1名の名前付きメールアドレスです。

整形結果はJUDPDK.txtとして保存され、AS/400へのアップロード自体を行うスクリプトは本リポジトリには 存在しません——手動でClient Access「データ転送（PCからAS/400へ）」をJUDPDK.FDFを使って実行している と推測されます（推測）。アップロード後はData_Check.xlsmが JUDPBF_DATA_Trans.dtf/JUDP_DATA_Trans.dtfという2つのClient Access転送定義を実行し、 アップロード前後のJUDPテーブルをダウンロードして9列を行比較、変化した行だけを人間が目視確認します。 JUDPDKのデータがAS/400のJUDPテーブルへ実際に書き込まれるwrite pathであることは確定していますが、承認/差し戻しの ゲートはなく、書き込み後の事後検証のみという運用です。 (出典: DNK処理済データ/Data_Check/Data_Check.xlsm)

手入力とEDIの関係

デンソー機工向けの号口受注は、第2章の手入力（JSBS04）とEDI取込（本章）の2経路が完全に並行して存在し、互いを呼び出すことはありません。両者は以下の点で収束します。

• 同じjudpテーブルへ書き込む。
• 同じjkmpのjkrnbn（999999キー）カウンタから受注№を採番する（ただし「復活」＝既存キャンセル行の再利用の場合はjkmpを一切触らない）。
• どちらのパイプラインも得意先コード=20（デンソー機工）を固定的に扱う。

(出典: pilot/spec/itjm62r.md:143-153,§1.5b, pilot/spec/itjm64r.md:353-360)

5. 受注の変更・訂正・取消（5つの入口）

「一度入力した受注を直す」ための入口は目的別に5種類あり、制御の厳しさが目的に応じて明確に段階分けされています。新人にはこの段差を理解してもらうことが重要です。

6. 番号管理 — 受注№・伝票№・試作№

3種類の番号が、それぞれ別のマスター・別の仕組みで管理されている点が新人には分かりにくいので整理します。

ナンバー管理マスター（nkmp）は受注№とは無関係に、設計№・品番コードの採番専用マスターです。受注№(jkmp)・伝票№/試作№(n1dp/n2dp/n3dp)とは完全に別系統の採番資源であることを、この章のまとめとして押さえておいてください。

(出典: pilot/spec/itjm62r.md:143-153, pilot/spec/itjm41r.md:162-165, pilot/spec/itjm64r.md:353-360, pilot/spec/itjm32r.md:33-37,97-104,222-257, pilot/spec/itjm33r.md:66-81,207-213, pilot/spec/itjm34r.md:13-23,272,302-364, pilot/schema/menuj1.sql:953-963, pilot/schema/menus1.sql:404-421, pilot/spec/itks16r.md:90,122-137, pilot/spec/itjm41r.md:201,237-239)

7. 試作の受注経路

試作品専用の受注入力プログラムは見当たりません。試作品は通常受注(JSBS01/ITJM71R)または新規・設変(JSBS03/ITJM72R)と同じ入口から入力され、judp.jud605（指示形態）というコード値によって「これは試作品である」と分類される、というのが最も整合的な理解です。

指示形態(JUD605／JHD062)のコード体系 【ヒアリングで判明】

2026-07-20メール添付の参考図（コード改訂表）により、指示形態コードの全体像と現行／改訂後の対応が確認できました。JUD605は現行の単一値フィールド（レコード1件につき1つの値）で、JHD062はこれを範囲へ拡張する計画中の改訂フィールドです。改訂はまだ全面稼働しておらず、一部（52）は改訂内容自体が未定です。

(出典: 新實さん、2026-07-20メール添付コード表、docs/feedback/analysis/2026-07-20-niimi-shijikeitai.md参照)

(出典: pilot/spec/itju01r.md:41-50,94,108,164-166, pilot/spec/itju02r.md:43-55,104-126,248-249, pilot/spec/itju03r.md:9-19,99, pilot/app/public/data/screen-help.json（L6,9,49-92,140-185）, analysis/out/menu_tree.md:332-334, 新實さん2026-07-20メール)

8. 特殊ケース

8-1. 事前完成処理（JSBS07 → ITJM31R）

構成展開（BOM展開）前の受注データに対し、以降の生産処理を完全にスキップさせたいときの単発メンテナンスです。受注№を1件キー入力し、確認Enterのみ（入力項目はほぼなし）。適用条件は、受注№が存在し、jukbwj=空白（構成展開前）、jukued=0（未打切）であることです。効果はjukbwj='E'（構成展開以降の処理をしない印）とjukued=8（生産完了スタンプ）の2フィールドのみの更新で、完成日・完成数・完成度は書きません。

(出典: pilot/spec/itjm31r.md:24-58,78-124,163-262)

8-2. トヨタ紡織管理表（JSBS13 → ITJM40R）

画面を持たない純粋バッチです。得意先コード=5000（トヨタ紡織）に固定してjudpを走査し、jukued=0かつjukust=空白（未処理）の受注のみを対象にします。各行をjudps8（5列: 受注品番/受注納期/受注№/試作№/客先伝票№）へ書き込む際、試作№・伝票№はjudpの数値項目ではなくn1dp/n2dp（第6章の英数字サイドテーブル）を優先的に参照します（アルファベットを含む伝票№を正しく表示するため）。トヨタ紡織という特定の大口得意先向けに、社内標準の受注残一覧表とは別フォーマットの管理表を提供する、得意先固有の帳票要件と考えられます。JSBS13はjudps8をCLRPFMで毎回全消去してからITJM40Rを呼び、その後Excel/VBAマクロ（BAT0113Excel/VBA、リポジトリ外）が実際の表を組み立てます。

(出典: pilot/spec/itjm40r.md:11-98)

8-3. 最終受注納期問合せ（JSBS23 → ITJM27R）

完全に読み取り専用（データの書込・更新は一切行わない）です。受注品番を1件入力すると、その品番自体のjudp受注納期(jujnok)の最大値と、その品番を構成する部品（構成マスターksmpを1階層だけ展開した各部品）の受注納期の最大値とを比較し、より遅い方を「最終的に約束できる納期」として提示します。「この注文／品番について、実際にいつまでに得意先へ約束できる納期か」を、部品供給の遅れも考慮して確認するための問合せ画面です。

(出典: pilot/spec/itjm27r.md:8-16,42-46,154-185, pilot/spec/itju01r.md:129-134,229-232, pilot/spec/itju02r.md:172,256-258)

8-4. 受注票再発行（JSBS14 → ITJM74R）

オペレーターが既存の受注№を入力すると、検証・確認画面を経て（自らはjudpp2へ書込まず）第3章のITJM75Rビルダーへ委譲し、受注票印刷ステージングを再構築します。既存であれば無条件で再発行可能（存在チェックのみ）— キャンセル済み・出荷済み・完了済みの受注であっても再発行できてしまう仕様であり、これも意図的なレガシー挙動として維持されます。

(出典: pilot/spec/itjm74r.md:1-67,242-282)

8-5. 品番差し替え・受注データ変更（JSBS19/16/20）

これらは本質的に「受注の訂正」であるため、詳細は第5章（受注の変更・訂正・取消）を参照してください。

8-6. シュラウド振分確認処理（デンソー機工向け、実資料で判明・新規）

現場手順書（Ｂ－０７／Ｂ－０８）に、これまでどのページにも記載のなかった号口部品の在庫振分（振分）という業務が記録されています。仕組みは「1つの共通した絞り（プレス）加工済み半製品の在庫を、複数の完成品番へ振り分けて割り当てる」というもので、共有元の在庫品番はワイルドカード的な先頭一致で管理されます。

• 7440系列（Ｂ－０７）: 共有在庫 022712-7440* を 022712-7440／022712-7450／022712-7460-1／022712-9520* の4品番へ振り分ける。
• 1240系列（Ｂ－０８）: 共有在庫 146241-1240* を 146241-3130／146241-3990／146241-4011／146241-4300／146241-1240／022782-0850 の6品番へ振り分ける。

確認の流れは、まず現物在庫を2階で数え、次に8.号口管理→14.号口部品作業指示状況問合せで共有元品番と各振分先品番の指示状況を照会し、不足していれば10.試作管理→6.試作作業指示変更で日程を前倒しするか、それでも足りなければ8.号口管理→7.社内かんばん用作業指示書発行で新規の作業指示を起票します。この「1つの半製品在庫を複数の完成品番で共有する」という運用は、他ページの在庫モデル（品番1件＝在庫1件）には現れておらず、標準在庫マスタhzmpの設計（品番のみでユニーク）とどう整合するかは要確認です。

(出典: source/work-procedures/作業手順書/（Ａ）　受注処理関係/（Ｂ－０７）　シュラウド振分確認処理（７４４０）.doc・（Ｂ－０８）　シュラウド振分確認処理（１２４０）.doc参照)

8-7. 社内かんばん（物理カード方式、実資料で判明・新規）

現場手順書（Ｂ－０６）に、第6章・第2章で扱ったかんばん内示／確定入力（受注管理→47/48/49、データ上の仕組み）とは別に、物理カードが実際に現場を巡回するかんばん方式がデンソー機工の部品ファミリー「3762」専用に記録されています。カードは2階を巡回し、戻ってきたカード＋入荷予定カードの枚数がカード裏面に印刷された閾値に達すると、担当者が8.号口管理→15で既存の未完了指示があるかを確認し、無ければ8.号口管理→7.社内かんばん用作業指示書発行で新規の作業指示を起票します。つまり社内かんばんは「内示→確定」の月次データ処理ではなく、物理カードの巡回枚数がトリガーとなる補充方式であり、両者は同じ「かんばん」という語を使いながら別の仕組みです。本章・第2章で「かんばん」と呼んでいる仕組みを新人に説明する際は、この2系統（データ内示／確定 vs 物理カード補充）を混同しないよう注意してください。

(出典: source/work-procedures/作業手順書/（Ａ）　受注処理関係/（Ｂ－０６）　社内かんばんの処理.doc参照)

8-8. 試作作業指示書発行のパスワードゲート（実資料で判明・新規）

現場手順書（Ａ１－０３／Ｂ－０３）によれば、10.試作管理→3.試作作業指示書発行（試作・号口いずれの作業指示発行にも共通で使われる画面）は、実行前にパスワード「ＮＩＩＮＯＭＩ」の入力と右Ctrlキーでの確定を要求します。作業指示発行という比較的頻度の高い操作に個人名を思わせるハードコードされたパスワードが埋め込まれている点は、他ページで確認済みの人名コメント（例: shipping.htmlのJSBS09に残る「2010年NIINOMI」というプログラムコメント）とあわせて、板倉製作所のAS/400システム全体で「NIINOMI」という識別子が非公式な管理者ゲート／署名として繰り返し使われていることを示す一例です。移行版でこのパスワードゲートを権限ロールとして正式にモデル化するか、単なる形骸化した儀式として廃止するかは要確認です。また、この画面発行の直前直後には「出荷入力(3→1)」と「出荷データ在庫展開(3→2)」の間で号口作業指示書発行を実行してはならないという明示的な運用上の禁止時間帯も手順書（Ｂ－０３）に記録されています。

(出典: source/work-procedures/作業手順書/（Ａ）　受注処理関係/（Ａ１－０３）　追加受注入力.doc・（Ｂ－０３）　号口用作業指示書発行.doc参照)

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

ここまでの記述はRPGソース・仕様書からの再構成ですが、実際に7年分のAS/400データ（judp 45,545件を含む）が本リポジトリのPostgreSQLに取り込まれています。以下はjudpを実際に集計した結果です。日付データを確認したところ、大半のレコードは2018年〜2026年（本稿執筆時点の2026年分は年央までの暫定値）に集中しており、これが実データの主要な対象期間（2018〜2026年の実データインポート時点）です。ごく少数（126件、全体の0.28%）に「1899-12-30」「2000〜2017年」「2028年以降」といった外れ値があり、テスト入力または未確定日付のダミー値と推測されます（集計からは除外）。

年別受注件数の推移

上記以外に2000〜2017年・2028年以降・1899-12-30（ダミー値）に計126件（0.28%）の外れ値あり。

得意先分布（上位10社、受注行数ベース）

上位2社（デンソープレステック・トヨタ紡織）だけで受注行数の66.3%を占め、上位5社では88.8%に達します。取引先71社のうち少数の量産大口先に受注が強く集中している構造です。

指示形態(jud605)の分布

本ページ第7章の指示形態表（11-19／21-29／31／51-69）はコード範囲としては実データと矛盾しませんが、実際にjudpに現れる値は各範囲の先頭付近（11・21・51・61）に偏っており、範囲内の他のコード（12〜19、22〜29、52〜60、62〜69等）は今回の7年分のデータには一件も出現しませんでした。範囲そのものの定義が誤っているわけではなく、実運用での使用コードが想定より少ないというだけの可能性が高い点に留意してください。

分納・状態フラグ

-- 総件数・日付範囲・外れ値
SELECT count(*), min(jujuhi), max(jujuhi) FROM judp;
SELECT count(*) FILTER (WHERE jujuhi = 18991230) AS sentinel_1899,
       count(*) FILTER (WHERE jujuhi/10000 BETWEEN 2019 AND 2026) AS in_range,
       count(*) FILTER (WHERE jujuhi/10000 > 2026) AS after_2026,
       count(*) FILTER (WHERE jujuhi/10000 < 2019 AND jujuhi <> 18991230) AS before_2019_other
FROM judp;

-- 年別件数
SELECT floor(jujuhi/10000)::int AS yr, count(*)
FROM judp WHERE jujuhi <> 18991230 GROUP BY 1 ORDER BY 1;

-- 得意先分布
SELECT j.jucdtk, t.tknmkj, count(*) AS n
FROM judp j LEFT JOIN tkmp t ON t.tkcdtk = j.jucdtk
GROUP BY j.jucdtk, t.tknmkj
ORDER BY n DESC LIMIT 10;
SELECT tkcdtk, tknmkj FROM tkmp WHERE tknmkj ILIKE '%デンソー%';
SELECT count(*) FROM tkmp;

-- 指示形態(jud605)分布
SELECT jud605, count(*) FROM judp GROUP BY jud605 ORDER BY jud605;

-- 分納・状態フラグ
SELECT count(*) FILTER (WHERE jud604 <> 0) AS bunno_child_rows,
       count(*) FILTER (WHERE jukued = 9) AS uchikiri_rows,
       count(*) AS total
FROM judp;
SELECT jukust, count(*) FROM judp GROUP BY jukust ORDER BY 2 DESC;

-- 1件の受注サンプル（号口・非中止・数量10-200・2023年6月受注）
SELECT j.junoju, j.jucdtk, t.tknmkj, j.juhnbj, j.jujusu, j.junosu, j.jujnok,
       j.jujuhi, j.jud605, j.jukust, j.jukued, j.junotd, j.junoss,
       j.jutank, j.jukath, j.jukuir, j.jukuju
FROM judp j LEFT JOIN tkmp t ON t.tkcdtk = j.jucdtk
WHERE j.jud605 = 51 AND j.jukust IS NULL
  AND j.jujusu BETWEEN 10 AND 200
  AND j.jujuhi BETWEEN 20230601 AND 20230630
ORDER BY j.junoju LIMIT 5;

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

主要テーブル

(出典: pilot/schema/menug1.sql:151-350, pilot/schema/menuj1.sql各所, pilot/schema/menus1.sql:404-421, pilot/spec/itks16r.md, pilot/spec/itks17r.md, pilot/spec/itjm71r.md:61-68)

照会・一覧系プログラム（読み取り専用の受注残一覧）

移植先TSモジュール名とJSBS対応は docs/MIGRATION-MAP.md:287-376 に全85行の一覧があります。JSBS08〜10（出荷・組付指示）、JSBS24〜26（組付指示書再発行）は出荷担当ドメインへの引き渡し先として第11章で触れます。

(出典: docs/MIGRATION-MAP.md:357-360, pilot/spec/itjm02r.md:1-16, pilot/spec/itjm04r.md:1-16)

10. 用語集

受注№

受注1行ごとにjkmpから採番される一意な番号。judp.junoju。

号口（ごうぐち）

量産段階の製品について、得意先の「かんばん」「内示」に基づき、同一品番を複数納期に分割して反復登録する発注方式。指示形態51〜69。

内示（ないじ）

得意先が発行する、数か月先までの見込み受注数量の通知。号口の元データの一つ。

かんばん

トヨタ生産方式由来の、実際の生産・納品指示票。号口のもう一つの元データ。「号口かんばん品内示」（JSBS48）「号口かんばん品確定」（JSBS49）という専用画面がある。

設変（せつへん）

設計変更。既存品番の仕様・構成を変更すること。新規登録と同じJSBS03画面で扱う。

分納（ぶんのう）

生産完了済みの受注を複数回に分けて納品すること。子受注として新規judp行を作る（JSBS05）。

引当／引継ぎ（ひきあて／ひきつぎ）

在庫や部品を特定の受注に紐づけること（引当）、既存受注の引当状態を新しい受注に流用すること（引継ぎ、JSBS06）。

指示形態（しじけいたい、jud605/jhd062）

受注の性質を表す分類コード。11-19試作単品出荷品、21-29試作組付品、31組付まとめ指示、51-69号口出荷。

依頼区分／受注区分

受注ごとの処理方法を表すコード（NMMPでデコードされる）。号口はそれぞれ固定値（' A'／1）。

中止区分／打切区分

中止区分＝キャンセル状態（空白／'D'）。打切区分＝受注のライフサイクル状態（0未打切／8生産完了／9打切済）。似て非なる2つの区分。実データでは「空白」は文字通りの半角スペースではなくSQL NULLとして格納されており（有効37,541件・中止'D'8,004件）、移植時のNULL/空文字の扱いには注意が必要。

構成（BOM）

ある品番を作るために必要な部品の一覧。ksmp（構成マスター）に登録。

見積単価／決定単価

jhmp.jhmtan（見積）は受注票に印字される暫定価格、jhmp.jhktan（決定）が最終確定価格。受注票の価格は見積値である点に注意（第3章、2. 見積・製品単価参照）。

JUDPR1（受注データ変更履歴）

JSBS16/20の編集内容を変更前(B)/変更後(A)ペアで記録する監査ログ。

作業者コード（sgcl）／ITSQ11R

JSBS16/18/19/20だけに課される追加ゲート。パスワードではなく、社内スタッフの作業者コードが作業者マスター(sgmp)に登録されているかの存在確認。

DFU

AS/400標準の対話型テーブル直接編集機能。JSBS02がこれを使う（バリデーションなし）。

号口区分（jhmp.jhkugo）

品番マスター側で持つ号口／試作の分類フラグ（表示用デコードとして使われる）。

オリジナル系統／変更系統（デンソーEDI）

デンソー機工からの電子データ取込パイプラインの2系統。全件スナップショット（オリジナル）と差分（変更）。

JUDPDK

デンソーEDIの128バイト固定長受信ステージングファイル。

CDTK（12/10/14/5000）

試作関連プログラムで使う拠点コード。新豊/試作/新川/トヨタ紡織。

まとめ指示（指示形態31）

複数の受注をまとめて1回の組付指示として処理する特殊区分。JSBS20はこの専用の変更処理。

品番差し替え

既発注の受注の品番そのものを別の品番に入れ替える操作（JSBS19）。旧品番はソフトキャンセルし、新しい受注№で作り直す。

事前完成処理

構成展開前の受注を、生産処理をスキップして即完了扱いにする特殊操作（JSBS07）。

ナンバー管理マスター（nkmp）

受注№ではなく、設計№・品番コードの採番専用マスター。

試作組付品／試作単品出荷品

試作品のうち組立を伴うもの（指示形態21-29）／伴わないもの（指示形態11-19）。

11. 他業務との接続点

• 見積（単価）: 受注票に印字される単価・型費はjhmpの見積値（jhmtan/jhmkat）であり、確定単価（jhktan）とは別管理です。見積段階の情報がそのまま受注票に流用される設計であり、見積部門とのデータ連携点になります（第3章）。詳細は 2. 見積・製品単価。
• 技術情報（品番登録）: タスク前提では「技術情報部門での事前品番登録が受注入力の前提」と想定されがちですが、実際にはJSBS03（新規・設変受注入力）自体の中で、受注担当がITKS16R画面を通じて品番マスター(jhmp)・構成マスター(ksmp)・単品品番マスター(bhmp)・設計№マスター(snmp)を新規登録できます。つまり品番登録は「別部門の前提条件」ではなく、受注担当が受注入力の一部として自ら行うワークフローです（第2章）。ただし単品品番データ登録（ITKS02R）はJ系・KS系複数のサブシステムから共有される汎用マスタメンテであり、技術情報寄りの管理項目（材質、板厚など）も含みます。詳細は 4. 技術情報。
• 生産指示: 受注データ(judp)がJSBS08（出荷・組付指示書発行バッチ）で構成展開(ITSS01R)・在庫引当・組付指示書発行へと処理されます。この構成展開以降の工程は出荷担当ドメインの範囲です。事前完成処理（JSBS07）はこの構成展開を意図的にスキップさせる特殊ケースです。詳細は 5. 号口生産・組付。
• 出荷: JSBS08（出荷・組付指示書発行）・JSBS09（出荷指示書発行、号口）・JSBS10（号口出荷準備完了入力）は、受注データを起点に出荷担当が扱う領域です。ITJM76R（部品引継ぎ）が作ったjud602リンクは、このJSBS08バッチが実際の在庫付け替えに使います。詳細は 7. 出荷。
• 売上: judpにスタンプされるjutank（単価）・jukath（型費）・jusehi（請求対象年月）が、後続の経理・請求処理の起点データになります。番号管理・単価管理の正確性が売上計上に直結します。詳細は 9. 売上・請求・支払・経理。
• 外製発注（MENUG1）: 号口・試作の一部品番は支給品（bjcdng内外コード）として外製先へ発注されます。受注データの指示形態・内外コードが外製管理サブシステムとの連携キーになります。詳細は 8. 外製・仕入。

未解明事項 — 現場担当者への質問リスト