TSUGITE 受発注クラウド継手 — 元請と協力会社をつなぐ

Phase 1は「発注書と請求書を紙で回すのをやめる」ことだけを達成する。施工管理（写真・工程表・チャット）には手を出さない。電子署名・タイムスタンプ・電子帳簿保存法の完全対応はPhase 2に置くが、後から載せられるデータ構造を最初から作るのがPhase 1の隠れた要件。

ロールは元請テナント側5種＋協力会社側2種。承認権限だけはロールに固定せず、金額閾値つきの承認ルート設定（G-92）で個別に指定する。中小の元請では「社長が全部承認」から「500万超だけ社長」まで運用がばらつくため。

Phase 1が扱う9ステップ。元請と協力会社が同じ1件のデータを交互に触るのが本システムの本体で、メールやFAXでの受け渡しは一度も発生しない。

全54画面。ただし全部を同時には作らない。A は最初に動く受発注ループを成立させる必須画面、B はPhase 1後半で足す画面。Aだけなら33画面で、これが実質のMVP境界。
本節には主要46画面を載せ、常用発注・控除・契約約款に関わる残り8画面は、設計の文脈が必要なため 09章〜12章の各末尾に置いた。

共通（C）

元請 — ダッシュボードと案件（G-0x / G-1x）

元請 — 取引先（G-2x）

元請 — 見積（G-3x）

元請 — 発注・検収（G-4x / G-5x）

元請 — 請求・支払（G-6x / G-7x）

元請 — 設定（G-9x）

協力会社（P）

協力会社側は画面数を極限まで減らす。現場から片手のスマホで操作する前提で、1画面1アクションに徹する。

取引の骨格となる16テーブル。見積 → 発注 → 検収 → 請求 → 支払が左から右へ一本の鎖でつながり、それぞれが明細テーブルを1つ持つ対称構造にしてある。協力会社は下段から3箇所に参照されるバスとして描いた。

主要テーブルの列定義。id（UUID）、tenant_id、created_at / updated_at / created_by / updated_by、deleted_at（論理削除）は全テーブル共通のため以下では省略する。金額はdecimal(14,2)、数量はdecimal(14,3)で統一する（浮動小数点は使わない）。

組織・取引先

案件・予算

見積

発注・検収

請求・支払

横断

本システムの実装量の半分はここに集中する。どの状態で誰が何を編集できるかを先に固めないと、後から必ず「承認後に金額が書き換わる」事故が出る。原則として承認済以降のレコードは編集不可とし、金額を変えたい場合は変更発注または差戻しで対応する。

発注（purchase_orders）

請求（supplier_invoices）

その他のステータス

8.1 登録番号の自動検証

国税庁の適格請求書発行事業者公表システムはWeb-APIを無償公開している（利用にはアプリケーションIDの事前申請が必要）。登録番号を渡すと、公表されている氏名・名称、登録年月日、失効年月日、所在地が返る。

• 即時検証：G-21・P-50で登録番号を入力した瞬間に照会し、公表名称を取得して入力欄へ反映。手入力の社名と食い違う場合はその場で警告する。
• 月次バッチ：全取引先を毎月1日に再照会。失効・名称変更を検知したら管理者と経理に通知し、G-24に一覧化する。
• スナップショット：請求提出時にreg_no_snapshotとis_qualifiedを請求レコードへ固定保存する。取引先が後から失効しても、過去の請求の判定は不変。
• フォールバック：API障害時はuncheckedのまま処理を続行させ、業務を止めない。未検証件数はダッシュボードに出す。

8.2 消費税と端数処理

計算順序を明示する。① 明細を税率（10% / 軽減8% / 不課税）でグループ化し、税抜金額を合計 → ② 各グループの合計額に税率を乗じ、そこで初めて端数処理 → ③ 税率別の税抜合計・税額・税込合計をsubtotal_by_rate / tax_by_rateに保存 → ④ 帳票にはこの3組を税率ごとに印字する。見積・発注も同じ計算器を共有し、見積・発注・請求で税額がずれない状態にする。

8.3 予算残高チェック

発注明細は必ず予算行に紐づく（po_items.budget_item_id）。発注入力中、対象の予算行について次を常時表示する。

予算残 = 予算行の金額 − その予算行に紐づく発注済（下書き・取消を除く）合計 − 入力中の金額

残高がマイナスになる場合、警告を出したうえで承認ルートを予算超過ルートに強制的に切り替える。ブロックはしない——現場では予算超過が実際に起きるため、止めると運用外の口頭発注に逃げられ、システムを使わなくなる。止めずに記録し、承認者に必ず見せるのが正しい設計。

8.4 3点突合

請求がsubmittedになった時点で自動実行し、結果をreviewing画面の先頭に固定表示する。

8.5 承認ルートの判定

申請時にapproval_routesから、対象種別・金額帯に合致する行をstep_no順に取得し、approvalsレコードを一括生成する。多段の場合は前段がapprovedになって初めて次段に通知が飛ぶ。予算超過が検出された発注はis_budget_over_routeのルートを優先する。承認者が不在（無効化済み）の場合は管理者にエスカレーションする。

8.6 全銀フォーマット出力

総合振込データ（全銀協規定・固定長120バイト、ヘッダ/データ/トレーラ/エンドの4レコード構成、半角カナ）を生成する。実装上の注意点。

• 受取人名は半角カナへの正規化が必要。濁点・半濁点は1文字として分離、長音・記号の変換表を持つ。ここは自動変換に頼らず、取引先マスタにカナ名を人が確認して保存する欄を用意する。
• 金融機関コード・支店コード・預金種目・口座番号はマスタ側で桁数と数値のみを検証する。
• 出力したバッチはexported_atとfile_hashを記録して以後編集不可。再出力は履歴を残したうえで許可する。
• 銀行によって細部の要求が異なるため、最初の顧客の取引銀行の仕様書を必ず入手してから実装する。汎用実装を先に書くと確実に手戻る。

8.7 採番規則

8.8 通知

アプリ内通知とメールを同一イベントから発火する。過剰な通知は最速で嫌われるため、Phase 1では次の8種のみに絞る。①見積依頼が届いた ②見積回答が届いた ③発注が届いた ④請書が届いた ⑤完了連絡が届いた ⑥検収された（＝請求できる）⑦請求が届いた／差戻された ⑧承認依頼が来た。加えて、期限系のリマインドを1日1回のダイジェストで送る（個別には送らない）。

建設業の発注には性質の違う2種類があり、これを1つの明細構造で扱おうとすると必ず破綻する。purchase_orders.order_typeで分岐させる。

常用発注のデータ設計

常用は「発注書を出して終わり」ではなく、日々の記録が金額を作る。したがってdaywork_reportsを独立テーブルとして持ち、検収はその集約として組み立てる。

追加画面

控除の発生源をデータで持つ

控除額を経理が手入力する設計にすると、金額の根拠が失われて協力会社と揉める。控除は必ず発生源のレコードから自動で積み上げる。

保留金はオプション機能にする

年商5〜30億規模の元請では保留金を取らない会社のほうが多い。テナント設定で既定OFFとし、ONにしたときだけ発注画面に保留率の欄と支払時の自動留保が現れる構成にする。データ構造はPhase 1で入れておくが、UIは設定で隠す。

追加画面

協力会社は複数の元請と取引する。ここを「元請ごとに別アカウント」で作ると、協力会社は元請の数だけログインを持つことになり、2社目の導入時点で必ず嫌われる。法人を表すグローバルなテーブルを1枚挟むのが唯一の解で、これは後付けするとデータ移行が極めて重くなるためPhase 1で構造だけ入れる。

基本契約約款の管理

約款はテナントごとに版管理し、協力会社は初回に同意する。同意の記録が後々の紛争時の証跡になる。

帳票の記載項目

請求書の記載項目は適格請求書の要件そのもので、これらはP-40の自動生成で構造的に必ず埋まる。協力会社が手書きで作った請求書のように項目が欠けることが起きない、というのがこのシステムの元請側への最大の売り文句になる。

追加画面

税抜経理か税込経理かで仕訳の形が変わるため、tenants.tax_accounting（excluded / included）で分岐する。既定は税抜。

仕訳のパターン

出力形式

Phase 1は汎用の仕訳CSVのみとする（日付／伝票区分／借方科目／借方補助／借方金額／借方税区分／貸方科目／貸方補助／貸方金額／貸方税区分／摘要／取引先コード／案件コード）。マネーフォワードや勘定奉行の専用インポート形式は仕様が細かく、実際の顧客が使っているソフトが判明してから1本だけ作るほうが確実に速い。汎用CSVでも大半の会計ソフトは取込設定で吸える。

提案であり確定ではない。方針はコンポーネント数を最小にすること——少人数で運用する自社SaaSでは、動く部品が増えるほど障害対応が回らなくなる。キューも全文検索もPostgreSQLに載せて、管理対象をアプリとDBとストレージの3つに抑える。

テナント分離を二重にする

アプリ層のスコープ漏れは必ず起きる。1箇所のバグが他社のデータ流出に直結するのがマルチテナントSaaSの最大のリスクなので、DB側にも同じ制約を置いて二重にする。

2週間スプリント×8本＝約4ヶ月。S4の終わりで一度、実際の元請1社に触ってもらうことを前提に順序を組んでいる。そこまでで「見積依頼を出して発注して請書が返る」までが動く。

残る論点 — 実データを見るまで確定しないもの

09〜13章で商慣行まわりは設計を確定させた。以下は設計ではなく数値と運用の問題なので、パイロット1社の実データを見てから詰める。

• 常用の日単価の持ち方——取引先ごとに固定か、職種ごとか、現場ごとに変わるか。テーブル構造は決まっているが、単価マスタをどの粒度で持つかは実際の運用次第。
• 締日と支払サイトのばらつき——20日締め翌月末払いが多いが、取引先ごとに違う会社もある。payment_termsを取引先単位にするか全社一律にするかで、支払一覧の作りが変わる。
• 全銀フォーマットの銀行別の差異——8.6のとおり、最初の顧客の取引銀行の仕様書を入手してから実装する。
• 会計ソフトの specific な取込形式——汎用CSVで足りるか、専用形式が要るか。
• 協力会社のログイン手段——メールアドレスを持たない職人がどの程度いるか。SMS招待・電話番号ログイン・元請による代理登録のどれが必要かは、実際の取引先名簿を見ないと判断できない。S2の着手前に必ず確認する。

この文書の使い方

• 意思決定に使う章——01（何を作り何を作らないか）、16（いつ何が動くか）。ここだけ読めば投資判断ができる。
• 開発が参照する章——04〜08、14。実装中はここを見る。
• 業務側・営業と擦り合わせる章——03、09〜13。ここに書いた商慣行の理解が間違っていると全部が崩れるので、建設業の実務を知っている人に必ず読ませる。
• 12章の法令解釈は着手前に弁護士へ当てること。本書はその確認を代替しない。