9. 売上・請求・支払・経理

出荷から売上計上・請求書発行までの「お金をもらう」流れと、仕入・外製費用の支払データ作成から銀行振込までの「お金を払う」流れ、この二つの資金の流れが合流する場所——それが経理業務。このページでは両方を扱うが、色分けして区別する：売上・請求の手順は青系（class="flow"）、支払の手順はオレンジ系（class="flow p2p" / class="stream p2p"）で表示する。

1. 業務の目的と位置づけ — 二つのお金の流れ

板倉製作所の経理業務は、大きく二つの資金の流れが合流する場所である。

上の青い帯が売上系統（受注から入金までの「集金の尻尾」）、下のオレンジの帯が仕入・外製系統（発注から支払までの「支払の尻尾」）。このページ全体でも、売上・請求の手順は青系(flow)、支払の手順はオレンジ系(flow p2p)で色分けする。両系統は別々のマスタ・別々のメニューサブシステムで動いている点に注意。

2. 売上計上のフロー — 出荷実績が売上になるまで

2.1 出荷データの入力と「打切区分」

受注データJUDPは出荷担当がITND50R（出荷データ追加）などの画面から納入実績を登録することで更新される。追加・修正の際、次の2つのフィールドが売上計上の鍵になる。

1. JUSEHI（請求対象年月）が自動設定される ITND50R
   MOVEL JUNOHI JUSEHIにより、納入日(JUNOHI, YYYYMMDD 8桁)の左6桁がそのまま請求対象年月(YYYYMM)になる。つまり「入力された納入日の月でそのまま計上する」という単純なルール。
   担当: 出荷担当
   (出典: pilot/spec/itnd50r.md L329, L342, L347; ITND50R.txt L593)
2. JUKUED（打切区分）が9になって初めて請求対象になる ITND50R
   通常の追加/修正では8（生産完了・未出荷扱い）のままだが、中止補償や、オペレーターが打切区分9を明示的に入力すると9（請求対象として確定＝打切）になる。JUKUED=9でなければ、その行はどの請求書作成プログラムにも拾われない。
   担当: 出荷担当
   (出典: pilot/spec/itnd50r.md L599-611)

2.2 単価適用

単価は「受注データ自身が持つ単価が最優先」で、それが0のときだけ品番単価マスター(PBTANKR)へ問い合わせる、という共通ルールが複数のプログラムで繰り返し使われている。PBTANKRのモードには「決定のみ」(mode 1)と「見積含む」(mode 2)があり、呼び出し元によって使い分けられる。型費（金型費用）がある場合は単価に折り込まれることが多いが、プログラムによって扱いが違う（9.7節参照）。金額計算はほぼ全プログラムで「四捨五入なし・切り捨て」（MULT/DIVにH指定なし）という legacy 仕様が徹底している。 (出典: pilot/spec/its000r.md L179-185, itur31r.md L238-256)

2.3 締め日（TK1P.T1DYSM）という「凍結」の仕組み

3. 請求のフロー — 月次一括・範囲指定・都度作成の3本立て

板倉製作所の請求書発行は、目的の異なる3つのExcel連携バッチが並存している。いずれも本体はAS/400側でPC転送用ステージングテーブルを作り、Excelマクロ（BATCH00経由で起動）が実際の帳票を印字する、という共通の構造（「印刷はExcelマクロ側」という設計方針そのもの）。

(出典: pilot/spec/its000r.md, its001r.md, its002r.md)

3.1 月次一括（ITS000R）

得意先コード＋対象年月を入力すると、その月にJUKUED=9で確定した行だけを拾い、社内品番を客先品番に変換(CVMP)し、型費を単価に折り込んでJUDPR5へ書き出す。TKMP.TKKBWK='Y'（指定請求書様式あり）の得意先は明示的に拒否され、Excelは起動しない。また、得意先コード60/61・90/91は特別扱いで、60を指定すると61の分も一緒に1枚の請求書に乗る（関連会社をまとめて請求している可能性が高いが未確認 — 9.4節参照）。 (出典: pilot/spec/its000r.md L82-95, L189-196)

3.2 範囲指定（ITS001R） — 客先始動の判定に必要な情報を積む

複数の得意先をまとめて処理する版。ITS000Rとの決定的な違いは、抽出行すべてにTK1P.T1D101（請求書発行区分）とTK1P.T1D301（締め日）を複写する点。これはExcel側で「自社始動で発行すべき請求」と「客先始動＝先方の支払通知を待つべき請求」を仕分けるための情報で、2025年1月27-28日の履歴コメントには「インボイス制度対応」とある。つまりこのExcel出力は単なる帳票印刷ではなく、請求先ごとの発行方式の判定を助けるデータという位置づけ。 (出典: pilot/spec/its001r.md L38-45, L211)

3.3 都度作成（ITS002R） — 会計効果のない「下書き」

納品の都度請求する得意先向けの補助ツール。プログラム冒頭のコメントに「あくまで品番等の入力の補助として下書きを作成することが目的」と明記されており、TK1PにもJUSEHI/JUKUEDにも一切関与しない。したがって月次請求（ITS000R）と対象が重複しても構わない設計。 (出典: pilot/spec/its002r.md L47, L192-197)

3.4 請求書発行区分 — 自社始動 vs 客先始動

ITS996R（請求書発行区分入力・修正）がTK1P.T1D101を保守する。値の意味：

トヨタグループの大手取引先（トヨタ紡織・アイシン・デンソー等）は、自社の受入実績から支払額を計算し「支払通知書」を発注元に送る方式（いわゆる支払通知ベース取引）を採用することが多く、T1D101=1はこの慣行に対応するフラグだと考えられる推測（ソースコード上は「客先始動」としか説明がなく、具体的にどの得意先がこれに該当するかのデータは今回未確認）。 (出典: pilot/spec/its996r.md L33-35)

3.5 バグと運用上の注意点

• ITS996RのCLSSBS53には、権限判定用の変数&CLを'SSBS77'（本来は別プログラムのITS994R向け値）に設定してしまっているコピペバグがある。結果、請求書発行区分の変更権限が、請求済締日の変更権限と意図せず同じになっている。 (出典: pilot/spec/its996r.md L8-18)
• ITS001D画面には「アイシン安城に注意」という警告文言があるが、何に注意すべきかの説明はソース上にない（現場の暗黙知、未解明事項）。 (出典: ITS001D.txt L28)

4. 入金・消込

5. 支払のフロー — 経理管理サブシステム(MENUR1)

5.1 支払費用データの入力（RSBS01/ITSW10R）

MENUR1の中核。SHDP（支払費用データ、キー：仕入先コード＋発生月）へ1件ずつ手入力する画面。3画面ウィザード構成：

1. GM1（キー入力） RSBS01/ITSW10R
   仕入先コード＋発生月を入力する。
   担当: 経理担当
2. GM2（明細入力）
   本社請求金額・工機請求金額・支払条件コード(0/3/90/99)・（90の場合のみ）指定手形金額を入力する。
   担当: 経理担当
3. GM3（確認）
   振込/手形/小切手/預り/現金への自動按分結果と手数料を確認する。
   担当: 経理担当

(出典: pilot/spec/rsbs01-itsw10r.md)

支払条件コードの意味：

(出典: pilot/spec/rsbs01-itsw10r.md L43, L101-144)

消費税率は、振込予定日（発生月の翌月30日固定）に対してITSW99Rが返す税率テーブルで決まる（9.3節参照）。 (出典: pilot/spec/rsbs01-itsw10r.md L85-92)

5.2 支払費用データの照会（RSBS13/ITSW41R）

読み取り専用の一覧照会。仕入先コード＋発生月範囲を指定してSHDPを検索する。開かれた仕様上の疑問点はなし、と明記されている。 (出典: pilot/spec/rsbs13-itsw41r.md L52-55)

5.3 印刷帳票5点（すべてHTMLプレビュー化済み）

「銀行送金ファイルの実バイトやExcelマクロ相当物は作らず、内容確認用のHTMLプレビューに留める」という設計方針に従い、以下5帳票がpilot/app/src/print/registry.tsにプレビューseamとして実装済み。

(出典: pilot/spec/rsbs06-07-10-11-23.md)

5.4 支払明細書（ITSI13R） — 別サブシステムの類似帳票

既知の技術的負債（実務では未実行と判明——上記callout参照）：

• 前月繰越額の起点算出が、要求された仕入先コード(IICDST)ではなく読み込みループ終了時のSFCDSI（別の仕入先コードの可能性がある）をキーにしている（要確認）。 (出典: pilot/spec/itsi13r.md L182-190)
• ループ終了条件に無限ループの潜在バグがあり（最大仕入先コードの場合に発生しうる）、移行時には複製してはいけないと明記されている。 (出典: pilot/spec/itsi13r.md L173-178)

5.5 金融機関マスタ（BKMP）と振込

BKMP（キー：金融機関コード＋支店コード）は振込先銀行の名称・略称・手数料区分・当座預金枝番を保持する。RSBS01の手数料計算では実質的に参照されない点は5.1で述べた通り。仕入先マスタSIMPは仕入先ごとの振込銀行・支店コード(SICDBK/SICDST)、支払条件(SICDSR)、種別(SICDSB)を持ち、BKMPと組み合わせて振込先名称を表示する。

5.6 支払案内書作成 Excelジョブ（PC側マクロ） 【実VBAで解明】

source/finance/支払案内書作成/フォルダには13ファイルがあり（個別振込データ.xlsx, 支払案内書.xlsx, 支払総括書.xlsx(+保存用), 総合振込データ.xlsx/.csv/.FDF, 転送用支払データ作成.xlsm など）、5.3節の帳票群のPC側実体に相当する。VBAを全文確認した結果、この5マクロは直列パイプラインではなく、AS/400側で生成された3種の異なるSHDPレポート抽出を独立に消費する3本の並行ツールであることが判明しました（当初想定していた「総括書→案内書→転送データ」という順序仮説は誤りだった可能性が高い）。

新発見（先行調査brief-9-finance.mdの未解明事項を前進）: 「個別振込データ（個別振込データ.xlsx）に対応するAS/400側RPGプログラムを確認できていない」としていた先行調査に対し、本調査で転送用支払データ作成.xlsmが読むSHDPP4.xlsという、RSBS06が明示的に除外するSHD101=9（個別振込）行を扱う別経路の具体的な候補を特定できました（推測、SHDPP4を生成するRPGプログラム自体は未特定のまま）。また「総合振込データ」はVBAマクロによる生成ではなく、総合振込データ.FDFという独立したClient Access Data Transfer定義（RSBS06が書き出すワークファイルの直接ダウンロード）で作られていることも確認しました。支払案内書作成フォルダの5マクロは「PC側で計算・生成」ではなく「AS/400側RPGが計算済みのワークファイルをダウンロード/整形するだけ」という一貫した性格を持ちます。

転送用支払データ作成.xlsmと支払総括書作成.xlsm（保存用）の2本は、人間が事前に請求金額入力.xlsxへ金額を手入力しておく必要があるという共通の手動ステップを持ちます。総合振込データ.csvはヘッダなし3列（仕入先コード,0,金額）の単純抽出で、全銀(Zengin)固定長フォーマットではありません（確認済み）——振込先口座マスタを別途保持する銀行系ソフトウェアに読み込ませ、そちらでZengin形式に変換していると推測されます（本リポジトリ外）。総合振込データ.FDFはUTF-16LEの本物のAS/400 Data Transfer定義ファイルで、支払データがAS/400からの単純ダウンロードだけでなく、この転送機構を介してAS/400または銀行端末側への転送にも使われている可能性があります（推測）。

(出典: 支払案内書作成/支払総括書作成.xlsm・支払案内書作成.xlsm・転送用支払データ作成.xlsmヘッダコメント, 総合振込データ.csv/.FDF, brief-9-finance.mdのRSBS06/07/10/11抽出条件とのクロス統合)

6. 費用集計 【実VBAで解明】

source/finance/費用集計/フォルダの3本のVBAを全文確認した結果、費用集計はAS/400のRPGプログラムに対応物を一切持たない、完全にPC側Excelネイティブファイルだけで完結する衛星ジョブであることが確定しました（先行調査の推測を裏付け、かつ計算ロジックまで具体化）。

• 月別概算費用集計.xlsm: Auto_Openは締め月ドロップダウンの準備のみで、集計自体は人間がボタンを押してData_Select()を起動する対話型ツール（無人バッチではない）。2つのデータ源はいずれもPCネイティブExcel（AS/400ミラーではない）: ①材料発注依頼書.xlsx（材料発注データ、重量×単価で金額算出、鋼材はWeight_Keisan_Fe()という重量計算式）②購買データ.xlsx（既に部門別金額列が入力済みの一般購買データ）。両方とも発注先/材質/サイズによるルックアップで工機部門/試作部門/製造部門の3部門に按分する。
• その他費用集計.xlsm: 月別概算費用集計.xlsmの購買データ集計部分のみを抜き出した簡易版（鋼材計算なし）。
• 購買データ入力.xlsm: 完全手動のデータ入力フォーム。処理日/仕入先/振分区分/消費税/購入金額を人間が入力し、3部門への金額按分も人間が入力、「購入金額=3部門合計」の検算エラーチェック付きで購買データ.xlsxに追記する。部門帰属（この購入がどの部門のコストか）は請求書ごとに人間が都度判断する完全マニュアル作業であることが確定——Koubai_Data_Syukei()はこの人間の判断結果を機械的に合計しているだけ。

7. 月次の流れ — 経理担当者の1ヶ月

売上系統と支払系統は並行して動くが、時系列でまとめると次のようになる。

1. 月中随時：日々の納品登録 ITND50R
   出荷担当が日々の納品を登録。納入日でJUSEHIが自動的にその月に計上される。JUKUED=9（打切確定）が立った行だけが後の請求対象になる。
   担当: 出荷担当
2. 月中随時：支払費用データ入力 RSBS01/ITSW10R
   経理担当（または関連部署）が、仕入先・外注先から届く請求内容をSHDPへ随時入力し、支払条件コードに応じた振込/手形/小切手按分を確認する。
   担当: 経理担当
3. 月末：締め処理 ITS994R / ITS995R
   得意先1件ずつ、または一括でTK1P.T1DYSM（請求済締日）を進め、その月を「締める」。以後その日以前の納入日での新規出荷入力はブロックされる。
   担当: 経理担当
4. 請求書発行：月次一括 ITS000R
   自社始動の通常得意先へ月次請求書を作成する。
   担当: 経理担当
5. 請求書発行：範囲指定 ITS001R
   範囲指定・客先始動判定を含む一括処理（トヨタグループ系の支払通知ベース得意先を含む）。
   担当: 経理担当
6. 請求書発行：都度作成 ITS002R
   都度請求の得意先には随時下書きを作成する（締め処理とは無関係）。
   担当: 経理担当

7. 支払処理：総合振込データ RSBS06
   銀行への総合振込データを作成する。
   担当: 経理担当
8. 支払処理：支払案内書 RSBS07
   仕入先向け支払案内書を作成する。
   担当: 経理担当
9. 支払処理：支払総括書 RSBS10/11/23
   内部・保存用の支払総括書（集計帳票）を作成する。
   担当: 経理担当
10. 支払処理：支払明細書 ITSI13R(GSBS06)
    仕入先ごとの支払明細書を作成する（SFDPの当月受入実績を明細行に）。
    担当: 経理担当
11. 集計：費用集計Excelジョブ
    上記の支払データや購買データを部門別・月別に取りまとめる。AS/400との自動連携はなく、部門帰属は人間の手動判断（第6章）。
    担当: 経理担当

8. ケーススタディ — RSBS23「小計」問題：正しさより一貫性

9. 特殊ケース

9.1 相殺（ネッティング）

今回の調査範囲（pilot/spec/*.md, docs/decisions.md, source/finance/ディレクトリ一覧）では、関連会社間の相殺処理に相当する機能・テーブルは一切見つからなかった。存在しない可能性、または本ページの調査範囲外（別サブシステムまたは手作業）の可能性がある（未解明事項参照）。

【ヒアリングで判明】相殺している取引先は実在し、主なところはデンソープレステック、ヒサダ、トヨトミ、アイシンシロキの4社であることが確認された。AS/400上に相殺処理のテーブル・機能が見つからなかったのは調査漏れではなく、この業務がAS/400の外（Excel・手作業）で完結しているためと確定した。 (出典: 新實さん、2026-07-22ヒアリングシート回答、hearing.html F1、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

9.2 手形（約束手形）

SHDP.SHKGTG（手形金額）フィールドは確実に存在し、RSBS01の支払条件コード90（指定手形金額＋小切手）・4（10万円単位手形＋小切手、マスタ経由のみ）で計算ロジックも確認できる。ただし手形の期日・決済状況を追跡する専用テーブルは見当たらない。金額のフィールドだけがあり、期日管理は銀行側システムか手作業台帳で行われている可能性がある（未解明事項参照）。

【ヒアリングで判明】受け取った手形の期日は、\\Server2\Soumu_C2\経理\売上関係\入金管理表.xlsx（入金消込と同じ台帳）で一元管理されていることが確認された。専用テーブルがAS/400上に見当たらなかったのは、この業務自体が銀行サイト＋Excel台帳でAS/400の外で完結しているためだった。 (出典: 新實さん、2026-07-22ヒアリングシート回答、hearing.html F1、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

9.3 消費税

ITSW99R（消費税率照会）という共通ルーチンが複数のプログラム（RSBS01/ITSW10R、ITSI13R）から呼ばれ、日付に応じて税率を返す。

(出典: pilot/spec/rsbs01-itsw10r.md L85-92, itsi13r.md L82)

インボイス制度（2023年開始）固有の対応としては、ITS001Rが2025年1月にTK1P.T1D101/T1D301を全行に複写するよう改修された履歴が確認できる。これは、少なくとも2025年初頭時点で、AS/400側のプログラムが継続的に制度対応の改修を受けていたことを示す一次証拠である。 (出典: pilot/spec/its001r.md L211)

9.4 60/61・90/91 得意先ペアリング

ITS000R・ITS002R双方に、得意先コード60を指定すると61も、90を指定すると91も同時に請求対象へ含めるという、コードにハードコードされた特別ルールがある。関連会社をまとめて1枚の請求書で処理する慣行と推測されるが、対象となる会社名・理由はソースだけでは分からない（未解明事項参照）。 (出典: pilot/spec/its000r.md L189-196)

【ヒアリングで判明】60/61＝トヨトミ、90/91＝山崎工業であることが確定した。いずれも工場を2つ持つ会社で、納品先そのものは工場ごとに異なるが、請求書は2工場分をまとめて1通にする運用のため、得意先コードがペアで扱われている。「アイシン安城に注意」（ITS001D画面の警告文言）についても、取引先・データのリスクではなく新實さん個人の入力操作上の備忘メモ（範囲指定入力で「10から」スタートさせる癖の忘れ防止）であることが判明した。 (出典: 新實さん、2026-07-22ヒアリングシート回答、hearing.html F2、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

9.5 支払種別（5グループ）

SHDP.SHCDSB（種別、仕入先マスタSICDSBと同一体系）はNMMPのコードグループ13で名称管理されている。実データ照会（本番DBnmmpテーブル、nmkbnm='13'）で確認した正式な対応表：

SHDPは単なる「外注費」台帳ではなく、外注加工費・材料費（通常の仕入経路以外で発生したもの）・工具費・設備費・その他雑費を横断する非仕入系コストの一元台帳である。D25の実データ確認では、FY2025-2026の全期間で5種別すべてが毎回登場している。 (出典: docs/decisions.md D25, docs/STATUS.md L27-40)

9.6 支払条件コード早見表（再掲・5.1節参照）

0=全額振込条件付き先方負担／3=全額振込当方負担固定／90=指定手形額＋小切手／99=マスタ指定通り（内部的に4=10万円単位手形＋小切手が発現しうる）。

9.7 型費の扱いの不整合

ITS000R（月次請求）は型費を単価に折り込むが、ITS001R（範囲指定）は型費を別項目のまま出力する。この違いが意図的な設計か単なる実装差かは未確認（未解明事項参照）。

【ヒアリングで判明】社内で使う資料は型費・単価を常に別表示にしている一方、客先に提出する請求書は型費を単価に織り込んで個数割りする得意先が従来は多かった。ただし下請法の影響とみられる近年の傾向として、型費を別立てで請求明細に出すケースの方が増えており、現在は両方式が混在している。つまりITS000R／ITS001Rの違いは単なる実装差ではなく、得意先・時期による運用実態の混在を反映したものだった。 (出典: 新實さん、2026-07-22ヒアリングシート回答、hearing.html F3、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

10. 実データスナップショット — 本番DBによる検証

10.1 支払費用データ（SHDP）の実態

種別(SHCDSB)ごとの件数・金額を全130発生月で集計すると、9.5節で述べた「1=外注/2=材料/3=工具/4=設備/9=その他」の対応は実データでも成立している。ただし金額ベースで最大の割合を占めるのは外注（9.4%）ではなく材料（30.7%）で、9.5節が言う「SHDPは外注費台帳ではなく非仕入系コストの一元台帳」という位置づけを裏付ける結果になった。

「その他」区分が件数で41%を占めるのに金額では23.5%にとどまる（1件あたりの平均額が他区分より小さい雑費的な支払が多い）のも、一元台帳としての性格を示している。

発生月ごとの支払総額（SHKGSK合計）は、130期間で中央値7,764,611円／月・平均8,298,803円／月。最小は2025年5月の3,577,360円、最大は2025年12月の24,299,202円で、平均の約3倍に達する突出した月だった。内訳を見ると、この月は株式会社ウエノテックへの外注区分の単独支払11,969,485円が主因で、通常月にはない大口の一時支払（設備投資や大型外注案件と推測される）が乗ったことがわかる。

累計支払額の多い支払先トップ10（全期間・SIMP名称と結合）：

9位・10位に生命保険会社と商工連盟の協同組合が入っている点は象徴的で、SHDPが単なる仕入先・外注先への支払だけでなく、保険料や組合費のような一般管理費まで横断して扱う「非仕入系コストの一元台帳」であることを、上位ランキングそのものが裏付けている。

10.2 得意先締め日（TK1P）の実データ分布

2.3節の「締め日」カードで先述した通り、全140得意先のT1D301（締め日）は次の分布になっている。

請求書発行区分(T1D101)は0＝自社始動が108件（77.1%）、1＝客先始動が32件（22.9%）。3.4節で「トヨタグループの大手取引先は客先始動が多いのでは」と推測した通り、約2割の得意先が客先始動側に分類されている実態が確認できた（個別にどの得意先がそれかまでは今回未特定）。

なお2026-07-18時点のスナップショットでは、T1DYSM（請求済締日）は全140件が設定済みで、範囲は20260531〜20260620。つまり調査時点で「まだ一度も締めたことがない」得意先はゼロで、全社が直近1ヶ月弱の間に締め処理を経ていることになる。

10.3 売上金額トレンド（JUDP）— 実データで「算出不可」と判明

-- 発生月カバレッジ
SELECT min(shdyhs), max(shdyhs), count(*) FROM shdp;

-- 種別ごとの件数・金額（10.1）
SELECT shcdsb, count(*) n, sum(shkgsk) amt FROM shdp GROUP BY shcdsb ORDER BY shcdsb;

-- 発生月ごとの支払総額と中央値・平均（10.1）
SELECT shdyhs, sum(shkgsk) total FROM shdp GROUP BY shdyhs ORDER BY shdyhs;
SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY total) median_monthly_total,
       avg(total), min(total), max(total), count(*) n_periods
FROM (SELECT shdyhs, sum(shkgsk) total FROM shdp GROUP BY shdyhs) t;

-- 支払先トップ10（10.1）
SELECT s.sicdsi, s.sinmkj, sum(sh.shkgsk) total_amt, count(*) n
FROM shdp sh JOIN simp s ON s.sicdsi = sh.shcdss
GROUP BY s.sicdsi, s.sinmkj ORDER BY total_amt DESC LIMIT 10;

-- 締め日分布 / 請求書発行区分（10.2）
SELECT t1d301, count(*) n FROM tk1p GROUP BY t1d301 ORDER BY n DESC;
SELECT t1d101, count(*) n FROM tk1p GROUP BY t1d101 ORDER BY n DESC;
SELECT min(t1dysm), max(t1dysm), count(*) FROM tk1p WHERE t1dysm IS NOT NULL AND t1dysm > 0;

-- JUDP 単価ゼロ率（10.3）
SELECT count(*) FILTER (WHERE jukued=9) confirmed, count(*) total FROM judp;
SELECT count(*) FILTER (WHERE jutank=0 OR jutank IS NULL) zero_price, count(*) total
FROM judp WHERE jukued=9;

-- RSBS23 全期間再検証（8節）
SELECT count(DISTINCT n_groups), min(n_groups), max(n_groups)
FROM (SELECT shdyhs, count(DISTINCT shcdsb) n_groups FROM shdp GROUP BY shdyhs) t;

-- 手形金額の規模（9.2節・未解明事項3）
SELECT count(*) FILTER (WHERE shkgtg>0) n_tegata, sum(shkgtg), sum(shkgsk) FROM shdp;

-- BKKUTRの実際の入力状況（5.5節・未解明事項9）
SELECT bkkutr, count(*) FROM bkmp GROUP BY bkkutr;

11. 関連マスタ・データ／帳票一覧

11.1 マスタ

11.2 トランザクション／台帳データ

11.3 帳票（本ドメインで確認できたもの）

12. 用語集

締め日 / 請求済締日（T1DYSM）

この日以前の納入日では出荷入力ができなくなる、得意先ごとの会計上の境界日。ITS994R/ITS995Rで更新

打切区分（JUKUED）

受注行が「請求対象として確定した」ことを示すフラグ。9＝確定

請求対象年月（JUSEHI）

その受注行を請求書に含める対象年月(YYYYMM)。通常は納入日の月がそのまま入る

請求書発行区分（T1D101）

0=自社始動（自社から能動的に請求書を出す）、1=客先始動（先方の支払通知を待つ）

発生月（SHDYHS）

支払費用データ(SHDP)が「発生した」とされる月。請求対象年月とは別概念

種別（SHCDSB/SICDSB）

支払費用の分類。1=外注/2=材料/3=工具/4=設備/9=その他

支払条件（SICDSR/WSKUSS）

仕入先ごとの支払方法規定。全額振込/手形＋小切手など

型費

金型製作・改修費用。単価に折り込まれる場合と別建てで扱われる場合がある

単価区分（見積/決定）

品番単価マスターから引いた単価が「見積」段階か「決定」済みかを示すラベル

消込（このコードベースでの用法）

一般的な「入金消込」ではなく、出荷・納品データを受注に対して確定させる処理を指すことが多い（用語の二重使用に注意、4節参照）

客先品番変換（CVMP）

社内で使う品番を、得意先が使う品番表記に変換するマスタ

振込/手形/小切手/預り/現金

支払方法の5分類。SHDPは各金額を別フィールドで保持

手数料負担区分（当方/先方）

銀行振込手数料をどちらが負担するかの区分。支払条件と金額基準（3万円）で自動判定される場合がある

印刷プレビュー主義

本移行プロジェクトの設計方針。実際の銀行送金ファイルやExcelマクロ相当のバイト列は作らず、内容確認用のHTMLプレビュー(window.print())に留めるという判断

経理管理サブシステム（MENUR1）

MENU00の非表示オプション50からのみ到達できた、支払業務専用のAS/400サブシステム。2026年session 34で発見・移行

得意先マスター従属１（TK1P）

得意先マスター(TKMP)に1:1で紐づく、請求関連の制御フラグ専用テーブル

指定請求書様式（TKKBWK）

特定フォーマットの請求書が必要な得意先を示すフラグ。該当客はITS000Rの自動発行対象から除外される

インボイス制度対応

2023年開始の適格請求書等保存方式への対応。2025年にAS/400側にも改修履歴が残る

消費税率テーブル（ITSW99R）

適用日に応じて0%〜10%の税率を返す共通ルーチン

SHDP

支払費用データ。仕入先×発生月をキーとする、外注/材料/工具/設備/その他の非仕入系コスト台帳

PBTANKR

品番単価マスター参照の共通ルーチン。「決定」優先、必要に応じ「見積」を含める2モード

13. 他業務との接続点

• 出荷（納品）業務: ITND50R等の出荷データ追加が売上計上の起点。納入日・数量が売上金額計算の直接の入力になる（2.1節）。出荷ドメインの詳細な業務フローは7. 出荷ページ参照。
• 外製受入業務: SFDP（仕入ファイル）は外注先・仕入先からの受入実績を記録するテーブルで、ITSI13R支払明細書の明細行の直接の元データになる（5.4節）。外製受入の詳細は8. 外製・仕入ページ参照。
• 単価マスタ（品番単価マスター、PBTANKR）: 売上計上時の得意先向け単価決定にも、（今回のスコープでは直接追跡できなかったが）仕入・外注費用の妥当性確認にも関わる可能性がある共通ルーチン。詳細は2. 見積・製品単価ページ参照。
• マスタ保守（masters.html共通CRUD基盤）: TKMP/TK1P/SIMP/BKMPはいずれもこの基盤で登録・変更・削除・照会が可能（F7/F8前後データ送りなど、既存の汎用機能がそのまま適用される）。