10 · JWNET 標準EDI 接続テスト（Greco 側の手順）¶
最終更新: 2026-09-15
接続テスト期間は 2026-10-05〜10-18、平日 9:00–17:00（日本時間） です。 Greco で要求ファイルを生成し、主経路の常駐ゲートウェイ搬送で送受信した結果を Greco で判定します。 保険として手動（VM の Biware）の手渡し方式も残します。
前提と画面¶
collector の管理者（admin）で JWNET設定 を開き、
「接続テスト」へ設定票③の接続登録番号・枝番・加入者番号・EDI利用確認キーを手入力します。
環境は test（利用区分3）です。デモ・本番用の資格情報を代用しません。
設定票原本と管理された保管先で値を確認し、文書・コード・チャット・スクリーンショットに転記しないでください。
「接続テストページを開く」から 接続テスト画面 へ進みます。 グローバルナビゲーションには表示されません。資格情報の取得中・取得失敗・未設定はそれぞれ表示され、 いずれも要求ファイルを生成できません。失敗時は再試行し、未設定時は設定画面へ戻ります。
VM・IPsec・Biware の前提と送受信の確認は runbook Phase F に従ってください。 テストケース・日別計画・証跡は テスト仕様書 が正典。
要求ファイル生成から結果判定まで¶
- 3101（番号指定照会）から開始します。設定票③で指定された事前登録マニフェスト番号を1行に1件入力します。 Greco のマニフェスト台帳には登録しません。3101は最大299件、報告はD31/D62などの後続レコードを含めて合計300件以内です。
- 送り先を選びます。「ファイルをダウンロード」は手渡し方式（下記 3〜6）、「ゲートウェイで送信」はゲートウェイ搬送（「ゲートウェイで送信する」節）です。 ゲートウェイ搬送では 3〜6 を飛ばし、「送受信キュー」で進捗を見ます。 「要求ファイルを生成」を押します。番号のチェックディジット、必須項目、日付、数量、SHIFT_JISのバイト長等で 不正があれば入力エラーを列挙します。推測で項目を補わず、確認できた値を入力してください。
- 保存された
{要求コード}.csv（TEST はTEST-<要求コード>.txt）と画面の要求コード・ファイル名・SHA-256・作成日時を確認し、 「送信記録（JSON）を保存」します。これは生成記録です。Biwareで送信が成功した証明ではありません。 - 要求ファイルのウィルスチェックを行い、VM の
C:\jwnet\outboxへ原本のまま配置します。 ファイルは SHIFT_JIS・BOMなしです。Excelやテキストエディタで開いて再保存しないでください。 - 利用時間内に Biware で送信し、通信結果を記録します。送信操作とトラブル対応は runbook Phase F の保険（手渡し）に従います。
C:\jwnet\inboxの結果ファイルを原本のまま保全し、接続テスト画面の「結果ファイル」で選び、 「結果ファイルを判定」を押します。- HR1 → HR2 → 個票 → E01 の順に確認します。照会結果は番号・自社運搬区間ごとの判定を確認します。
予約段階、承認待ち、自社区間未取得は受理済みとして扱いません。3101/3201の判定は運搬報告が対象であり、
処分終了報告やマニフェスト登録の受理証明には使いません。結果に含まれない番号も判定できません。
3101 を収運 / 処分の名義で送ると判定表の自社区間は資格情報（排出）基準で unchanged / 未取得になります。区間番号は 3101 判定画面の反映ボタン（区間は R19 全区間から）か原本 R19 で読みます。
TEST は画面から送ります。ゲートウェイ搬送では送受信キューが照合待ち（
result-correlation-failedまたはresult-parse-failed）になるのが正で、受信原本（C:\jwnet\receivedとartifacts/に保全）で E01（フォーマット不正）を確認するのが合格条件 ② の証跡です。画面の「判定を表示」は TEST 行に出ません。保険の手渡しではTEST-<要求コード>.txtをダウンロードして Biware から直送します。 - 照会内容を基に必要な報告機能を選び、運搬終了日・区間・数量/単位・処分終了日・承認否認等を入力して 2〜7を繰り返します。複数番号には同じ入力値が適用されます。内容が異なる番号は別ファイルに分けてください。 番号・区間番号・収運の送信名義は 3101 の判定画面から報告系の入力へ反映できます。終了日・数量・担当者は手入力します。
- 「判定記録（JSON）を保存」し、要求・結果原本、生成記録、Biwareの応答、判定記録を要求コードでまとめます。 画面の記録が必要な場合は実値を隠した状態で作成してください。
Greco の送信状態（submission）は変更しません。 この画面は jwnet_submissions を作成せず、
要求コードの採番だけを消費します。判定は解析のみで、取込・再送・照合解除のRPCを呼びません。
ゲートウェイで送信する¶
主経路はゲートウェイ搬送です。常駐ゲートウェイが稼働している場合は、手動配置の代わりにゲートウェイ搬送を使います。 手渡し方式（保険）は、ゲートウェイが不調・claim が進まない・全銀レベルの切り分けが必要なときの fallback として残します。
- 要求ファイルの生成画面で送り先の「ゲートウェイで送信」を選び、「要求ファイルを生成」を押します。 条件検索（3201）もゲートウェイで送れます（送信名義の入力は不要です）。
- 成功すると要求コードと SHA-256（先頭 12 桁）を通知し、ファイルを返さず送受信キューへ積みます。 要求ファイル本文は暗号化して保存され、平文は Greco に残りません。
- ゲートウェイがキューを 1 ファイルずつ搬送します。前の結果を受信するまで次は送りません。 進捗は「送受信キュー」で確認します。待機中・送信中・送信済（結果待ち）がある間は30秒ごとに更新します。
送受信キューの見方¶
状態は待機中 / 送信中 / 送信済・結果待ち / 受信済 / 失敗 / 照合待ち / 取り下げで表示します。 受信済の行は「判定を表示」で、手動受信と同じ判定表示（HR1 → HR2 → 個票 → E01）を確認します。 待機中の行は「取り下げ」でキューから外せます（確認ダイアログを通します）。 送信中・送信済（結果待ち）の行は経過時間を表示し、送信 12 分・受信 35 分の予算を 超えたら「要確認」と次の行動を出します。送信予算は claim 時刻起点で、原本保存 + スキャン最大 120 秒 + 送信（scheduler 300 秒 + 安定待ち / command は E-2.6 の 外側期限で最大 420 秒）+ R4 の 30 秒 ≈ 10 分を包む上界です。予算内は正常な待ち （スキャン + 送信の合計が数分かかるのは正常）であり、再起動は不要です。
失敗の行はエラーコードと文言を表示します。エラーコード biware-send-rejected は
「Biware が送信前に拒否。要求を再生成して送り直す」を意味します。自動再送の導線はありません。
再送は新しい要求コードで生成してください（受理済みの報告を再送すると二重報告になります）。
照合待ちの行は、判定者が原本と EDI 処理状況照会で受理の有無を確認してから、再送するかを決めます。
TEST の照合待ちは正常です。原本のエラーコード（フォーマット不正）を目視して記録すれば完了です。再送は不要です。
ゲートウェイを再起動しても「送信済・結果待ち」の行は消えず、再起動後に受信を再開します。受信中の再起動は避け、health が止まっているときだけ nssm start / nssm restart を使います。例外として、受信予算（送信時刻から約 35 分）を超えて「送信済・結果待ち」が続くときは、下の「照合待ちの復旧と次のサイクルへの戻し方」の (d) に従って再起動します。
照合待ちの復旧と次のサイクルへの戻し方¶
照合待ちになった行を 受信済 に戻す操作はありません（R6 は 送信中 /
送信済・結果待ち からしか遷移できません）。照合待ちは次の送信を阻止しないので、
下の分岐で原本を保全・判定して記録し、次の要求へ進みます。いずれの分岐も
自動再送は無いため、送り直すときは新しい要求コードで生成します。
| 状況 | 操作 |
|---|---|
(a) 結果ファイルが後から届いた / C:\jwnet\received に残っていた |
原本は保持し、判定用のコピーだけを元の名前（ファイル名先頭の日時・PID・連番を除いた部分）に付け直して「結果ファイルを判定」（アップロード）で HR1 → HR2 → 個票を読む → 判定者が受理の有無を記録。行の状態は変えない（TEST は原本目視で記録し、アップロードしない。命名の詳細は runbook Phase F の残留手順） |
| (b) 受信だけをやり直したい | 照合待ちの行の受信は再実行できない（R7 は 送信中 / 送信済・結果待ち しか再開しない）。手動受信の前に排他する: (1) 同テナントに 待機中 の要求が無いことを画面で確認する（あれば取り下げるか、受信が終わるまで待つ）(2) 送信中 / 送信済・結果待ち が無いことを確認する (3) ゲートウェイを停止する（v1.94.0 以降は停止契約で 送信済・結果待ち は保たれる。それ以前は in-flight が無い状態で nssm stop）(4) Biware の受信ジョブを手で起こす（command なら第 7 章のコマンド・scheduler ならジョブの手動実行）→ inbox に落ちたファイルを人が C:\jwnet\received\manual\ へ移す（manual フォルダが無ければ作る）(5) nssm start で再開する → (a) の手順で判定。代替: Biware の受信先をゲートウェイが監視しない一時フォルダに切り替えて受信する |
| (c) 確認済みの残留がある | 保管先へ移す（ファイル名は 要求コード_取得時刻）。outbox に要求ファイルが残ったまま再稼働すると Biware が再送する恐れがあるため、再稼働前に outbox を空にする（runbook Phase F の再稼働前チェック） |
| (d) 次の送信へ進みたい | 送信中 / 送信済・結果待ち が無ければ次の送信は自動で進む。送信済・結果待ち が受信予算（約 35 分）超過で health が正常なら v1.94.0 は nssm restart で再開する。ゲートウェイが死んでいて 送信中 のまま戻らないときだけ、下記の service_role の R6 手順を使う |
service_role の R6（最終手段・判定者の承認が必要）: 当日の判定者が指定する端末から、
対象テナント・対象行・照合待ち への遷移に限定して R6（理由 gateway-dead-manual）を
打つ。打った理由・時刻・行 id・要求コードを日次記録に残す。service_role の直接 DML
（表の UPDATE / DELETE）や無条件の再 enqueue はしない。
選べる機能¶
| 区分 | 機能 |
|---|---|
| 疎通確認 | TEST（手順書 §4 ⑥。中身は TEST のテキスト。番号・項目・名義の入力なし。結果はフォーマット不正のエラーコードが正で原本で目視） |
| 収運 | 1000 運搬終了報告 / 1100 修正 / 1300 取消 / 0701 承認・否認 / 0208 予約情報の修正 |
| 処分 | 1501 処分終了報告 / 1601 修正 / 1700 再資源化修正 / 1800 取消 / 0702 承認・否認 / 0209 予約情報の修正。再資源化等情報（D62）は1700で1件以上必須、1501/1601では任意（下記の報告区分条件に従う） |
| 処分 | 2001 最終処分終了報告 / 2100 取消。再資源化等情報（D62）は2001で1件以上必須（下記の入力節）。2100は区間番号を持たない |
| 排出 | 0103 予約情報の登録 / 0403 マニフェスト情報の登録 / 0503 マニフェスト情報の登録（新規） / 0605 修正 / 0207 予約修正 / 0300 予約情報の取消 / 0800 マニフェスト情報の取消 / 1200 承認・否認 |
| 照会 | 3000 通知情報照会 / 3101 番号指定 / 3102 再資源化等情報（番号指定）/ 3201 条件検索（運搬終了の未報告、期間は3か月以内） |
3101/3201は基本情報と収集運搬情報を取得し、予約・取消を含みます。3101の承認待ち情報の別取得は対象外です。 3102 は再資源化等情報を番号指定（最大 299 件）で取得し、結果の R63 / R65 を解釈します。1700 の要求は 3102 で照会した情報を基に作成します。 3000はセンターからの通知情報を照会します。通知日（FROM）は送信当日が既定で、最大1か月前まで照会できます。接続テスト当日は from = to = 当日で送ります（原本 §4 ⑥ の指定）。判定はR23（要求内容のエコー）の受理確認までで、通知明細（R24）は表示しません。 報告では通常の結果ファイルを要求します。数量と単位は両方入れるか両方空にします（数量 0 も設定値であり、単位だけの入力は生成できません）。単位コードは 1=t・2=m³・3=kg・4=リットル・5=個・台で、有価物量に 5 は使えず、基準重量の単位は kg（3）固定です。 排出の0300/0800/1200は選択できます（取消・承認否認は区間番号を持たず、承認否認フラグは1=承認・2=否認）。 0103 / 0403 / 0503 / 0605 / 0207はD31-01と後続レコードを、0208はD31-02、0209はD31-03と後続レコードを生成します。 数量は小数点以下3桁（Z9.999）、 単位は既存の数量単位コード、数量確定者は01〜07です。荷姿・分類コードは形式検証を通し、 コードの有効性は設定票・マスタ・JWNET応答で確認してください。
送信名義（排出 / 収運 / 処分報告）¶
機能ごとに「送信名義」へ加入者番号を入力します。空欄のままでは資格情報の加入者番号で送ります。 排出の機能（3000 を含む）は自社の接続テスト加入者番号、0208は収運、0209・1501・1601・1700・1800・0702・2001・2100・3102は処分の テスト加入者番号を入力します。確認キーは資格情報のものを使います（接続テストの加入者は確認キーが共通です）。 入力値はこの端末にだけ記憶し、送信記録には残しません。0103 / 0503は新規登録のため番号欄は不要です。
2001 / 2100 の送信名義は処分です（EDI 仕様書 §2-1 の機能表で ２００１ 最終処分終了報告（再資源化等情報を含む） と ２１００ 最終処分終了報告の取消 は処分業者の列。§2-1(3)「Ｗｅｂ－ＥＤＩ機能で利用できる機能」の表でも同じ）。
送信名義は機能の役割ごとに切り替えます。2001 / 2100 は「報告及び 2 次登録」の名義（資料③ No.11）で送り、No.7 と取り違えません。
（引用の注意: EDI 仕様書 PDF のページ下部にある印刷ページ番号（例: 2-15）は節番号ではない。引用は節番号と見出しの併記で行う。）
3000 通知情報の照会は §2-1 の機能表で 4 列すべてにあり、どの事業者区分でも送れますが、区分で返る通知の種類が変わります（§2-2 の機能概要）。当方は排出名義で送り、運搬終了報告通知・処分終了報告通知・確認期限切れ通知・修正／取消要請通知などの報告系の通知を受けます。
3102 再資源化等情報の照会は §2-1 の機能表で排出事業者・処分業者・中間処理業者〈2次〉の 3 列にあり（収集運搬業者の列には無い）、当方は処分報告の名義で送ります。
1501 / 1601 / 1700：再資源化等情報の入力¶
処分終了日は 1501/1601 とも必須です（1700 では入力しません）。 「再資源化等情報を追加」で処分業者・事業場・処分方法・処理前後の分類と数量を入力し、 不要な行は「取消」で外します。件数は入力行から自動計算され、1700は0行で生成できません。 1501の中間処理は0件、最終処分は1件以上が必要です。1601は中間処理から最終処分へ変更する場合に 入力し、その他の場合は0件にします。既登録の区分を照会原本で確認してください。 1501/1601 の再資源化等情報のマニフェスト区分は 1 に限ります（区分 2 以上は生成できません）。 処理前廃棄物は2次以降で入力し、1次では空欄です。独自細分類001〜999には名称も必要で、000は名称を空欄にします。 処分方法は処分業者用コードを選び、未使用の後続方法は000、主たる方法は入力した方法から選びます。 数量単位はkg固定、数量は小数点以下3桁で出力します。基準重量には1次分の処分量合計を入力してください。 区分 1 の処分量合計が、基準重量の 90〜110% に収まる必要があります（小数 3 桁で照合。 重量 W の許容範囲は S/1.1 ≤ W ≤ S/0.9 で、3 桁の内側丸めで表示します）。 基準重量欄の横に区分 1 の合計を表示するので、合わないときは「合計を基準重量に入れる」で転記できます。 複数番号には同じ再資源化等情報を適用するため、内容が異なる番号は別ファイルにします。 D60とD62の合計300レコード以内で生成してください。D62結果原本の業務受理は未実測です。結果に未対応レコードが含まれると画面は422で判定を止めるため、受理とE01はJWNETの応答原本で確認します。
2001：最終処分終了報告の入力¶
「再資源化等情報を追加」で処分業者・事業場・処分方法・処理前後の分類と数量を入力し、 不要な行は「取消」で外します。件数は入力行から自動計算され、2001は0行で生成できません。 基準重量には1次分の処分量合計を入力してください。区分 1 の処分量合計が、基準重量の 90〜110% に収まる必要があります（小数 3 桁で照合・区分 2 以降の行は合計に入れません。 重量 W の許容範囲は S/1.1 ≤ W ≤ S/0.9 で、3 桁の内側丸めで表示します）。 数量単位はkg固定、数量は小数点以下3桁で出力します。 D61とD62の合計300レコード以内で生成してください。結果のR61は受理・E01を個票ごとに判定します。 3101照会の判定画面の「報告系への反映」から番号を 2001 の入力へ反映できます（反映先の機能で 2001 を選ぶ）。送信名義は No.11「報告及び 2 次登録」の記憶キーを使い、処分報告（No.7）とは別に記憶します（初回は空欄）。D62 の内容は手入力で、区分 1 と区分 2 以上を各 1 行以上（実効最小 2 行）入れてください。
0403：3101照会から登録入力へ¶
- 3101の受信原本を「結果ファイルを判定」で読み込み、対象番号の「0403入力に反映」を押します。 現在の入力を置き換え、機能0403・対象番号・照会で確認できた区間と収集運搬業者加入者番号を設定します。 R35が本登録済みのマニフェスト情報の場合は「0605入力に反映」となり、修正入力へ進みます。予約修正0207は機能を明示選択してください。
- 「未写像項目」の一覧は選択機能と判明済みの加入者条件で入力できる項目を表示します。必須・条件必須を確認し、引渡し日、排出事業場、担当者、廃棄物分類・数量・単位、数量確定者、 荷姿、処分業者、運搬先加入者・事業場番号などを確認して入力します。現在のパーサではR35の登録詳細を 読んでいないため、番号以外は自動転記しません。R19の報告数量・車番・担当者も登録値には転用しません。
- 収集運搬区間は0403/0503/0605で1〜5件、0103/0207/0208/0209で0〜5件です。「追加」「削除」で編集すると入力順に区間番号を付けます。 有害物質（D02）、最終処分予定（D04）、連絡番号（D05）、備考（D06）は必要な分を追加します。 D32は空固定です。報告不要業者や自己所有の運搬先の条件必須項目も確認してください。
- 「要求ファイルを生成」を押し、不足・不正項目の一覧を解消します。明細件数はサーバが後続を含めて導出し、 合計300レコードを超える入力は採番前に全体を拒否します。マニフェスト単位でファイルを分けてください。 1件の連鎖だけで上限を超える場合も分割しません。HD1/HD2とファイル全体のSHIFT_JISバイト上限も適用します。
- 保存・Biware送信は上記の共通手順で行います。この画面の結果判定は R31 個票の受理 / 不受理と E01 を表示します。 原本での確認は補助とし、3101の初期値や運搬報告判定を登録成功の証明として扱わないでください。
0605/0207では「設定済みの処分業者情報と同じ情報を設定」「収集運搬業者は追加のみ」の規則を守ります。 既登録情報との自動比較は行いません。0207の予約情報の修正許可は必須、引渡し日などは予約列に従って任意です。 不受理結果・番号重複では初期値候補を出さず、区間の重複・欠番・R35件数不一致は区間を未写像として残します。
TEST 疎通確認ファイル¶
機能で TEST を選ぶと番号・項目・名義の欄が消え、中身が「TEST」の疎通確認ファイルを送ります。
結果は相関失敗（result-correlation-failed）または解析失敗（result-parse-failed）のどちらかで照合待ちになる（両方とも正）。
画面の判定入口はファイル名 / HR1 要求コード検査で 422 になるので原本の E01 を目視します。
判定と E01 の読み方¶
| 判定 | 対応 |
|---|---|
HR1 0 |
ファイル正常。HR2と個票も確認します。 |
HR1 1 |
全体エラー。1件も受理されていません。ヘッダとE01を確認します。 |
HR1 3 |
一部エラー。成功した個票は受理されています。成功分をまとめて再送しません。 |
HR2 1 |
ブロック内に不受理あり（個票を見る）。画面にはHR2リターンコードとエラー件数を表示します。HR2のエラー件数が0なら個票ごとに判定し、受理済みの個票は再送しません。HR2のエラー件数が0より大きい場合は加入者単位で不受理です。HR2直後のE01と加入者情報を確認します（仕様書§6-1(4)(8)）。 |
| 個票にE01 | 当該個票は不受理。複数コードがあれば全て確認します。 |
| 照会の件数超過・打切り | 全件を確認できていません。条件を絞って照会し直します。 |
E01はコード・分類・人手確認の要否を表示します。ENは必須項目、EDはデータ形式、EBは業務条件、
EEはEDI固有、EF/EMはファイル・項目、CA/CBは件数超過、FC/FDはサイズ超過です。
ES（センターシステム）と未知の分類は 人手確認が必要（requiresHumanOps） と表示されます。
JWNETの応答と正式なエラー一覧を確認し、必要ならセンターへ照会してください。
未知レコード・HR1欠落・解析不能は422で理由を表示し、判定を確定しません。 403では自社テナント・担当段階・資格情報を確認します。原本を修正して通そうとせず、受信元と内容を確認してください。
記録の保全と監査の制限¶
要求原本のHD2には確認キーが含まれ、結果原本にも資格情報が含まれることがあります。 原本はアクセス制限された保管先に保存し、コード・テスト・文書・チャット・スクリーンショットへ転記しません。 画面の生成記録はページを離れると失われるため、JSONをその場で保存してください。
jwnet_message_log.submission_id はnullableですが、現在のサーバ書込トリガ（mig161）は
submissionのないservice-role行を拒否します。この経路では監査テーブルへ書き込まず、
応答・記録に auditStatus=unavailable_null_submission を明示します。
SHA-256と要求コードは原本の突合に使い、送信成功の判断にはBiwareとJWNETの応答を併せて保全してください。
旧章から引き継いだ項目との対応¶
| 旧項目 | 本画面の対応 |
|---|---|
| 1. 接続先を明示し本番を初期値にしない | env=test固定。demo/prodの要求は400。VMの接続先はPhase Fで確認。 |
| 2. 電子マニフェストだけを候補にする | JWNETの事前登録番号を直接入力。Grecoの紙・電子の候補一覧を使わず、実運用の電子限定判定は既存経路で維持。 |
| 3. 自社・担当段階・資格情報の認可 | adminページ、admin API、caller JWTの資格情報読取、自社tenant/testの暗号文読取。Greco台帳の担当段階束縛は実運用経路に残す。 |
| 4. 応答確認から再送へ直行させない | parse-only。HR1/HR2/個票/E01を表示し、再送操作は設けない。 |
| 5. 403の条件・担当段階を案内 | テナント・担当段階・資格情報の確認を表示。 |
| 6. 要求コード不一致を拒否し原本を保つ | 結果ファイル名から得た要求コードとHR1を照合。不一致は422。生バイトを解析し、原本を書き換えない。 |
接続テスト通過後に、この専用経路の撤去または本番経路への統合を判断します。
接続テスト前のリハーサル¶
devで保存した要求原本は、送信前に端末内の独立バリデータで検査できます。 リポジトリのルートで、保存したファイルを指定します。
node scripts/jwnet-edi/validate-request-file.mjs /local/private/REQCODE.csv --env test
node scripts/jwnet-edi/validate-request-file.mjs /local/private/REQCODE.csv --env test --json
実値を含むファイルは端末外へ出さず、コード・チャット・文書へ貼り付けません。 バリデータは原本を変更せず、出力にはフィールドの値を出しません。HD2の加入者番号と EDI利用確認キーも、長さと検査結果だけを表示します。規則ID・レコード番号・仕様書の項番から 入力箇所を確認し、FAILはGrecoの入力を直して再生成します。原本を直接編集して通しません。 HD2項番5はheadレコードの件数です。D31の子・D62・D25などの従属レコードを除き、加入者ブロックごとに一致を検査します（EE02009）。
終了コード0は検査した規則が全てPASS、1はFAILです。uncheckedは未確認の項目です。
輸送ファイルIDはCSV内にないため、Biwareの設定値を --file-id で別途渡すと利用区分との
対応を検査できます。省略時の TRANSPORT_FILE_ID は未検証を意味します。
この検査は接続登録・確認キーの正しさや、JWNETの受理を証明するものではありません。
D32の確定桁数と残る未照合事項、生成手順、全規則はリポジトリ内の
scripts/jwnet-edi/README.md に記録しています。
2026-09-07のPDF画像裁定により、D32のA0は整数3桁＋小数2桁（最大999.99）、B0/C1/C2は整数7桁で検査します。
結果判定は scripts/jwnet-edi/fixtures/results/ の合成ファイルで練習できます。
接続テスト用の実設定と分けたdevのリハーサル専用テナントで行い、実設定を上書きしません。
報告結果の解析だけでも、接続テスト用資格情報が設定済み（configured）でなければ409になります。
照会の自社区間を再現するには、そのテナントの接続テスト設定を合成加入者番号 0000001、
確認キー DUMMYKEY、合成接続登録番号 DUMMY000、枝番 000000 にします。
これらは合成専用であり、接続テストへ送る資格情報ではありません。
設定の確認キーは8文字が必要です。結果fixture内の合成キーとは照合しないため、原本側の値を書き換えません。
- 専用テナントのcollector管理者で接続テスト画面を開きます。
- 「結果ファイル」で下表の原本を選びます。ファイル名の要求コードとHR1を一致させてあるため、名前を変更しません。
- 「結果ファイルを判定」を押し、HR1・HR2・個票・E01・照会判定を順に確認します。
- 「判定記録（JSON）を保存」し、合成リハーサルとして記録します。Biwareへ送信せず、接続テスト合格記録には数えません。
V8（dev E2E リハーサル）では上記のうち 1000・3101・3102 の 3 行を、画面の
「ゲートウェイで送信」→ 模擬搬送 → 「判定を表示」で通します。TEST 行の終点は
照合待ち + 保存原本の目視です（判定ボタンも 422 も出ません）。TEST 行の模擬搬送は
--keep-request-code を付けます（付けないと sim が outbox ファイル名から要求コードを
推定して HR1 を書き換え、照合待ちにならない）。詳しい手順と期待状態は準備計画 §5
「V8 の手順」に従います。
| ファイル名に含まれる要求コード | 確認する結果 |
|---|---|
OK1000 |
HR1=0、HR2=0、R09の2件が受理 |
FULL1000 |
HR1=1、EF/EEエラー。全件不受理 |
PART1000 |
HR1=3、HR2=1・エラー件数0。R09のエラー件数は1・0で、先頭R09の直後にE01が1件。先頭1件が不受理、後続1件が受理 |
SUB1000 |
HR2=1・エラー件数1。HR2直後のE01（EE02003）により2件とも加入者単位で不受理 |
MIX3101 |
受理・未報告・承認待ち2件（終了日あり/なし）・自社区間なしが混在。承認待ちと自社区間なしはunchanged |
UNKNOWN |
正常なHR1/HR2、未知XYZが1行、正常R09が1行。未知レコードを理由に422で判定を確定しない |
PARTEX4 |
§6-1(8)④の2加入者。HR1=3、HR2は0/1・ともにエラー件数0、R09のエラー件数は0・0・2、末尾にE01が2件。先頭2件が受理、末尾1件が不受理 |
NOHR1 |
既知R09が1行だけ。HR1欠落を理由に422で判定を確定しない |
OK2001 |
HR1=0、HR2=0、R61（2001）の1件が受理 |
OK3000 |
HR1=0、HR2=0、R23（3000）の通知1件が受理（明細なし） |
D31HDR |
HR1=1、HR1直後のE01（EF01005）。ファイル不受理で明細なし |
OK3102 |
HR1=0、HR2=0、R63エコー+R25×2+R65×2と従属R62が受理 |
TESTFMT |
HR1=1、HR1直後のE01（EF01001）。ファイル不受理で明細なし。[仮説] の合成であり Day-1 の TC-00 で実物を観測したら差し替える |
実設定のテナントで MIX3101 を試すと合成加入者番号と一致せず、自社区間なしになります。
合成原本へ実加入者番号を書き込んで合わせないでください。
これらのファイルは判定経路用で、センターが返した実績ではありません。
合成fixtureのshared自動テストはHR1/HR2・個票のエラー件数・E01の位置とコード・R19/R35の解析結果だけを検証します。
S1 25は13種類の原本を実API・実DBで判定し、UNKNOWN/NOHR1の422と拒否理由、submission・監査ログ・採番の不変を確認します。
表示は末端renderテストと同じ文言ヘルパでも確認します。dev実画面の通し操作は人間タスクH4で補います。
接続テストの要求ファイル生成・結果ファイル判定は、どちらも collector admin 限定です。normal / driver は画面と API の両方で拒否されます。結果判定も自社のテスト資格情報を読み、暗号鍵の設定を確認します。資格情報がない場合は、権限と設定を確認してから再試行してください。