ValueOS データモデル

位置づけ: クライアントERP（ValueOS）

概要

本ページはValueOS（正本 github.com/stanaka-blip/valueos）の全テーブルをカタログとして一覧化する。概要・アーキテクチャが5本柱を軸にした構造の要約、業務フローが決済区分別の判定ロジックを扱うのに対し、本ページはテーブル単位の主キー・主要カラム・関連（外部キー）を網羅する参照ページである。

情報源はlib/database.types.ts（Supabase生成の型定義）・supabase/migrations配下のDDL・各テーブルの登録画面（app/**/new/page.tsx）のコードである。lib/database.types.tsは主要28テーブルを型定義済みだが、コメントに明記される通り「既存テーブルはライブスキーマから抽出した互換型」であり、外部キー制約・登録画面のコードから実在を確認できる関連テーブルが型定義の範囲外になお存在する。本ページは型定義済みの28テーブルに加え、そうした関連テーブルも含めて整理する。確認できた主要テーブルは39本である（別途、API側のレート制御専用テーブルが1本ある。本ページ末尾の「インフラ用テーブル」の節を参照）。

ValueOSの主キー設計は一貫している。全テーブルがUUID（idまたはrequest_id）を主キーに持ち、case_no（VE-…）・order_no・invoice_noのような人間可読の業務番号は別列として保持する。当方のProduct.model（型番を主キーとする設計）やWholesaleCase.id（W-XXXX形式の文字列を主キーとする設計）とは主キー設計の方針が異なる。詳細は当方データモデルとの対応を参照。

スコープ/対象

このページの対象はValueOSのテーブル構造（エンティティ・主キー・主要カラム・関連）である。決済区分別の発注可否・請求可否ロジック、三社間金銭フローの詳細な計算式は対象外とし、業務フローを参照する。当方CRMとの項目突合・機能差分の詳細は対象外とし、差分・突合を参照する。

データ（分類別テーブル一覧）

案件/明細・タスク

テーブル	主キー	主要カラム	関連
cases	id	case_no、dealer_id、customer_name/customer_phone、site_address、order_type、order_received_date、desired_delivery_date、construction_desired_date/construction_completed_date、status、department、assigned_user、priority	dealers（dealer_idでID参照）
case_products	id	case_id、line_type、product_id、package_id、supplier_id、quantity、purchase_price/sales_price/gross_profit（価格スナップショット）、sales_price_id/purchase_price_id（採用した価格レコードの参照）、is_manual_price、price_fetched_at	cases、products、packages、sales_prices、purchase_prices
case_packages	id	case_id、package_id、quantity、case_product_id（case_productsとの1対1紐付）	case_products、packages
case_package_items	id	case_package_id、product_id、source_package_item_id、quantity、unit_purchase_price/total_purchase_price（NULL可。案件登録時に価格未確定でも保存できる）、requirement_type、selection_group、商品名等のスナップショット列群、is_selected/is_added_manually/is_hidden	case_packages、products
tasks	id	case_id（null可）、title、status、due_date、assigned_user、priority	cases（null可＝未紐付けを許容）

価格

テーブル	主キー	主要カラム	関連
sales_prices	id	dealer_id、price_target_type（PRODUCT/PACKAGE）、product_id/package_id、単価、is_active、start_date/end_date	dealers、products/packages
purchase_prices	id	supplier_id、price_target_type、product_id/package_id、purchase_price（単価）、is_active、start_date/end_date	suppliers、products/packages

有効価格の判定条件は両テーブル共通で、is_active = trueかつstart_date <= 基準日かつ（end_dateが未設定またはend_date >= 基準日）を満たすレコードのうちstart_date降順の先頭1件を採用する。purchase_pricesにdealer_id列はない（仕入価格は仕入先軸のみ）。基準日は原則order_received_date。金額はROUND（単価×数量）で保存し、画面プレビューは単価のみを返す。

決済

テーブル	主キー	主要カラム	関連
case_settlements	id	case_id（1対1）、settlement_type（正式値: 前金／売掛／3社間決済／カード）、fee_rate/fee_amount、deposit_rate/deposit_amount、payment_terms、card_brand/card_status/card_status_updated_at、finance_company/approval_number、loan_status/loan_status_updated_at	cases

settlement_typeは2026-08-01のマイグレーションで正規化済み。旧値「掛売」は「売掛」へ、「ローン」「三社間決済」は「3社間決済」へ移行し、「その他」はレガシー値として保持するが正式区分には含めない。判定ロジックの詳細は業務フローを参照。

三社間・入金

テーブル	主キー	主要カラム	関連
three_party_money_requests	request_id	action、case_id、resource_id、status、payload_hash、response	cases（3社間金銭アクションの冪等リクエスト表）
finance_receipts	id	case_id、finance_company、scheduled_date/scheduled_amount、actual_date/actual_amount、status、cancelled_at/cancel_reason、corrects_id（訂正元への自己参照）	cases、finance_receipts（自己参照）
dealer_settlements	id	case_id、dealer_id、statement_no、issue_date、finance_receipt_id、invoice_id、credit_received_amount、ve_share_amount、adjustment_total_amount、payout_amount、scheduled_payout_date/actual_payout_date/actual_payout_amount、status、corrects_id	cases、dealers、finance_receipts、invoices、dealer_settlements（自己参照）
dealer_settlement_lines	id	dealer_settlement_id、sort_order、line_kind（transfer_fee/discount/offset/other等）、description、amount、memo	dealer_settlements
supplier_payments	id	case_id、supplier_id、order_id、due_date、scheduled_amount、paid_date/paid_amount、status、cancelled_at/cancel_reason、corrects_id	cases、suppliers、orders、supplier_payments（自己参照）
payments	id	invoice_id、case_id、payment_date、payment_amount、payment_method、payer_name、bank_account、status（確認待ち／入金確認済／取消）	invoices

finance_receipts（信販会社からの入金）・dealer_settlements+dealer_settlement_lines（販売店への仕切精算）・supplier_payments（仕入先への支払）は、3社間決済の案件が持つ3系統の独立した金銭実体である。paymentsは既存の入金管理（前金・売掛向け）と独立しており、3社間決済では使わない。

受発注

テーブル	主キー	主要カラム	関連
orders	id	case_id、supplier_id、order_no、order_date、expected_delivery_date、delivered_date、order_amount、status、memo	cases、suppliers
order_items	id	order_id、product_id、case_product_id、quantity、unit_price、amount、memo、sort_order	orders、products、case_products

請求

テーブル	主キー	主要カラム	関連
invoices	id	case_id、invoice_no、invoice_date、due_date、invoice_amount、subtotal_ex_tax/tax_amount（2026-08-07追加、NULL可）、status	cases
invoice_line_items	id	invoice_id、sort_order、line_kind（product/package/custom）、description、quantity、unit、unit_price_ex_tax/amount_ex_tax、tax_rate、case_product_id、source_product_id/source_package_id	invoices、case_products、products/packages

請求明細はスナップショットであり、パッケージ内の構成商品は展開せず1行として計上する。

マスタ

テーブル	主キー	主要カラム	関連
products	id	manufacturer_id、series_id、category、model_no、name、capacity、unit、product_type、specification、price_list_category、default_supplier_id、is_active	manufacturers、product_series、suppliers
packages	id	manufacturer_id、series_id、name、package_code、capacity/capacity_unit、system_type、warranty_years、specification、pricing_method、default_supplier_id、is_active	manufacturers、product_series、suppliers
package_items	id	package_id、product_id、quantity、requirement_type、sort_order	packages、products
manufacturers	id	name、company_type、contact_name、phone、email、memo	—
product_series	id	manufacturer_id、name、説明、is_active	manufacturers
suppliers	id	name、supplier_type、contact_name、phone、email、order_method（発注方法）、closing_day（締日）、payment_site（支払サイト）、credit_limit（買掛上限）、memo	—
dealers	id	name、contact_name、phone、email、address、payment_type、credit_limit（与信枠）、sales_person、memo	—
contractors	id	name、postal_code/address/phone、delivery_name/delivery_address/delivery_phone（配送先）、receiver_name、memo、is_active	案件への外部キー・同期は持たない独立マスタ
company_settings	id（boolean。単一行運用）	company_name、postal_code/address/phone/fax/email、invoice_registration_number（インボイス登録番号）、bank_name/bank_branch/bank_account_type/bank_account_number/bank_account_holder	—
staff_profiles	id（auth.users.idと一致）	display_name、is_active、is_admin	auth.users（emailはauth.users側を正式値とし本テーブルには持たない）

申請系（RPC冪等キュー）

すべてrequest_id（UUID）を主キーとし、status・payload_hash（入力の正規化ハッシュ）・error_code/error_message・response（結果JSON）・completed_atという共通カラム構成を持つ。書込はservice_role専用（RLSは無効化し、GRANT/REVOKEによるACLでPUBLIC/anon/authenticatedから権限を剥奪、service_roleにのみSELECT/INSERT/UPDATEを付与）。

テーブル	対象RPC	参照先（対象エンティティ）
case_registration_requests	create_case_registration（案件新規登録）	cases
case_line_append_requests	append_case_line（既存案件への明細追加）	cases、case_products、case_packages
product_setup_requests	create_product_setup（新規商品セットアップ）	products
existing_product_price_setup_requests	create_existing_product_price_setup（既存商品への価格追加）	products
supplier_purchase_price_bulk_requests	create_supplier_purchase_prices（仕入価格一括登録）	suppliers
dealer_sales_price_bulk_requests	create_dealer_sales_prices（販売価格一括登録）	dealers
package_bulk_setup_requests	create_package_bulk_setup（パッケージ＋構成商品一括登録）	manufacturers
product_bulk_setup_requests	create_product_bulk_setup（商品一括登録）	manufacturers
purchase_order_create_requests	create_purchase_orders（発注一括作成。仕入先ごとにorders＋order_itemsをトランザクション生成）	cases

添付

テーブル	主キー	主要カラム	関連
case_attachments	id	case_id、attachment_type、original_filename、content_type、byte_size、storage_bucket/storage_path、uploaded_by_sid/uploaded_by_user_id/uploaded_by_label、is_active、deleted_at/deleted_by_sid/deleted_by_user_id	cases
case_attachment_upload_intents	id	attachment_id、case_id、attachment_type、original_filename、content_type、declared_byte_size、storage_bucket/storage_path、status、expires_at、completed_at	cases、case_attachments

ファイル本体はSupabase Storageの非公開バケットcase-attachmentsにDirect-to-Storageで保存し、case_attachmentsはメタデータのみを持つ。case_attachment_upload_intentsはアップロード発行から完了までの中間状態（署名URLの有効期限管理）を扱う。

インフラ用テーブル（注記）

gateway_rate_limits（主キーbucket_key）はAPIゲートウェイのレート制御専用テーブルであり、業務データを持たないため上記9分類の対象外とする。

エンティティ関連図

erDiagram
    cases ||--o| case_settlements : "1:1"
    cases ||--o{ case_products : "line_type"
    case_products ||--o{ case_packages : "内包"
    case_packages ||--o{ case_package_items : "展開明細"
    cases ||--o{ orders : "supplier_id別"
    orders ||--o{ order_items : "明細"
    cases ||--o{ invoices : "請求"
    invoices ||--o{ invoice_line_items : "明細スナップショット"
    invoices ||--o{ payments : "入金(複数可)"
    cases ||--o{ three_party_money_requests : "3社間ledger"
    cases ||--o{ finance_receipts : "信販入金"
    cases ||--o{ dealer_settlements : "仕切精算"
    dealer_settlements ||--o{ dealer_settlement_lines : "明細"
    cases ||--o{ supplier_payments : "仕入先支払"
    cases ||--o{ tasks : "case_id(null可)"
    products }o--|| manufacturers : "manufacturer_id"
    products }o--o| product_series : "series_id"
    packages ||--o{ package_items : "構成部材"
    products ||--o{ sales_prices : "dealer別価格"
    products ||--o{ purchase_prices : "supplier別原価"

画面・機能

テーブル群と対応する主要画面の関係を示す。各画面の業務仕様は概要・アーキテクチャ、判定ロジックは業務フローを参照する。

画面領域	対応テーブル群
app/cases	cases、case_products、case_packages、case_package_items、case_settlements
app/orders	orders、order_items
app/invoices	invoices、invoice_line_items
app/payments	payments
app/tasks	tasks
app/products、app/packages、app/series、app/manufacturers	products、packages、package_items、product_series、manufacturers
app/suppliers、app/dealers、app/contractors	suppliers、dealers、contractors
app/prices、app/sales-prices	purchase_prices、sales_prices
app/dealer-settlements	dealer_settlements、dealer_settlement_lines
app/queues	申請系テーブル全般（処理状況の監視）
app/dealer/orders/new	cases、case_products/case_packages/case_package_items、case_settlements（販売店発注の入口。現行はRPC非経由の直接INSERT）
app/settings、app/staff、app/admin	company_settings、staff_profiles

業務ルール/ワークフロー

• スナップショット設計: case_products／case_package_items／invoice_line_itemsは登録時点の価格・商品名をコピー保持する。マスタ側の価格・名称変更は既存の案件・請求データに影響しない。
• 価格の有効判定: sales_prices／purchase_pricesとも、is_activeかつ有効期間内のレコードをstart_date降順で1件採用する。共通ロジックであり画面ごとの個別実装はない。
• 申請系の冪等性: 申請系テーブルはすべてrequest_id（クライアント発行UUID）とpayload_hashにより、同一リクエストの再送を安全に処理する。書込権限はservice_roleに限定し、クライアントから直接INSERT/UPDATEはできない。
• 訂正・取消の履歴保全: finance_receipts／dealer_settlements／supplier_paymentsは確定済み金額を直接UPDATEしない。訂正はcorrects_idで元レコードを参照する新規行、取消はcancelled_at/cancel_reasonの記録で扱い、常に履歴が残る。
• 発注可否・請求可否の判定: case_settlements.settlement_typeを起点にWorkflowEngineが機械判定する。テーブル構造上の前提条件（例: 売掛の請求可否はorders全件のstatus/delivered_dateに依存）は本ページの各テーブルに現れるが、判定ロジックそのものは業務フローを正本とする。

権限

社内ユーザーの認証はSupabase Authが担い、staff_profiles.is_active／is_adminでアカウント有効性・管理者権限を判定する。販売店発注フォーム（app/dealer/orders/new）は社内認証の外側にあり、案件系テーブルへ直接INSERTする（申請系の冪等RPC経路は現行未接続）。三社間金銭アクション・申請系RPCへの書込権限はservice_roleに限定する。これらのテーブルはRLSを無効化したうえでGRANT/REVOKEによるACLを用い、PUBLIC/anon/authenticatedからの権限を剥奪してservice_roleのみに書込を許可する方式であり、RLSポリシーによる制御ではない。

当方データモデルとの対応

当方の新エンティティ全体像は先行スコープのデータモデルを参照。ValueOSとの構造的な対応は次のとおりである。

当方（/data-model/entities-phase1/）	ValueOS	対応関係
WholesaleCase	cases	概ね一致。当方はIDW-XXXXが主キー、ValueOSはUUID主キー＋case_no表示番号
WOrder/WInvoice/WPayment（WholesaleCaseに内包する配列）	orders/invoices/payments（独立テーブル）	構造差。ValueOSは番号・日付・金額を個別エンティティで保持し、当方はフラグ集約に近い内包配列
WholesalePrice（品目×仕入先の単一テーブル）	sales_prices（販売店×商品/パッケージ）／purchase_prices（仕入先×商品/パッケージ）	軸差。ValueOSは販売価格・仕入価格を別テーブルに分離し、対象を商品/パッケージで型分けする
WholesaleTask	tasks	フィールド構成が一致（case_idnull許容／status／due_date／assignee／priority）
EventCompany（代理店・名称一致でWholesaleCaseと結合）	dealers（cases.dealer_idでID参照）	ValueOSはID参照、当方は名称一致。当方側の正規化課題
Supplier	suppliers	概ね一致。ValueOSはorder_method/closing_day/payment_site/credit_limitなど経理項目を持ち、当方のSupplierマスタは薄い
Product（型番modelが主キー）	products（UUID主キー＋model_no列）	主キー設計が異なる。ValueOSは型番変更をUUID固定のまま列更新で扱える
なし（決済区分はWholesaleCase.settlementに内包）	case_settlements（案件と1対1の独立テーブル）	ValueOSは決済詳細（手数料・頭金・カード情報・ローン情報）を専用テーブルに分離
なし	three_party_money_requests／finance_receipts／dealer_settlements（+明細）／supplier_payments	当方に対応エンティティなし。三社間の下流精算（信販入金・販売店仕切・仕入先支払）はValueOSのみが構造化済み

項目単位の詳細な突合・差分は差分・突合を正本とする。用語の対応表は用語統一を参照する。

関連リンク

• valueos/overview — ValueOSの概要・アーキテクチャ・5本柱
• valueos/workflow — WorkflowEngineの判定ロジック・三社間金銭フロー
• redesign/valueos-gap — 当方CRMとの機能差分・項目突合の正本
• data-model/entities-phase1 — 当方の先行スコープのデータモデル
• redesign/terminology — 当方CRMとValueOSの用語対応表