このドキュメントは、データベースのテーブル名を業務用語に対応付け、SQLの知識がなくても技術ドキュメントを読めるようにするためのものです。
システム全体の中心となるエンティティの連鎖：
flowchart TD
User(["👤 社内ユーザー"])
User --> OPP
OPP["OPPORTUNITY\n購買依頼\n案件"]
OPP --> EST["ESTIMATE\n見積申請\n購買計画"]
EST --> REQ["ESTIMATE_REQUEST\n見積依頼\nRFQ送付"]
REQ --> ANS["ESTIMATE_ANSWER\n見積回答\nサプライヤーからの見積"]
ANS --> ORD["ORDER_LINE\n発注\n発注明細"]
ORD --> RCV["RECEIVE_ORDER\n受注\nサプライヤー側の受注確認"]
RCV --> DEL["DELIVERY\n納品"]
DEL --> ACC["ACCEPTANCE\n検収"]
ACC --> PAY(["💰 支払い"])
style OPP fill:#dbeafe
style EST fill:#dbeafe
style REQ fill:#dcfce7
style ANS fill:#dcfce7
style ORD fill:#fef9c3
style RCV fill:#fef9c3
style DEL fill:#fce7f3
style ACC fill:#fce7f3
詳細フローは 購買フロー 全体概要 を参照
ステータス遷移は 見積・発注ライフサイクル を参照
項目 内容 日本語名 購買依頼（こうばいいらい）/ 案件（あんけん） DBテーブル j2_buyer_group.buyer_order.opportunity説明 社内ユーザーによる購買ニーズの最初の記録。購買プロセス全体の起点となります。 作成者 依頼者（requester）または購買担当者（purchaser） 子テーブル opportunity_line（各品目・サービスの明細）
購買フロー種別（order_classification_type）：
値 名称 説明 1カタログ購買 カタログモールからの購買 2見積購買 見積プロセスを経た購買 3いきなり発注 見積なしの直接発注 4役務見積購買 役務の見積購買 5発注（当初・補充） 補充発注 6ダイレクト発注 ダイレクト発注 8セルフ見積購買 セルフ見積購買 9契約購買 契約に基づく購買
優先度分類（opportunity_class_type）：
値 名称 説明 0通常 通常案件 1緊急 緊急案件 2事後申請 購買後に申請する事後申請
項目 内容 日本語名 見積申請（みつもりしんせい） DBテーブル j2_buyer_group.buyer_order.estimate説明 OPPORTUNITYをもとに購買部門が作成する正式な購買計画。システム内で最も中核的なエンティティ（103カラム）。見積から発注までのライフサイクル全体を追跡します。 子テーブル estimate_request、estimate_answer、estimate_supplier、estimate_consultation
重要な注意： システムにおける”estimate”はサプライヤーからの見積書ではありません 。バイヤー側の購買計画・購買申請です。サプライヤーからの見積回答はestimate_answerです。
項目 内容 日本語名 見積依頼（みつもりいらい） DBテーブル j2_buyer_group.buyer_order.estimate_request説明 特定のサプライヤーへ送付する正式なRFQ（見積依頼書）。1件のESTIMATEに対して、複数のESTIMATE_REQUEST（複数サプライヤーへの依頼）が存在することがあります。 子テーブル estimate_request_line（品目明細）、estimate_request_delivery（納品情報）
見積種別（estimate_type）：
項目 内容 日本語名 見積回答（みつもりかいとう） DBテーブル j2_buyer_group.buyer_order.estimate_answer（バイヤー側）/ j2_supplier.supplier.estimate_answer（サプライヤー側）説明 サプライヤーがRFQに対して返送する見積回答。このテーブルはバイヤー側とサプライヤー側の両方 に存在します。 子テーブル estimate_answer_line（品目ごとの見積価格）、estimate_answer_service_line（役務の見積）
項目 内容 日本語名 発注（はっちゅう）/ 発注明細（はっちゅうめいさい） DBテーブル j2_buyer_group.buyer_order.order_line説明 承認完了後に発行される正式な発注書（PO）。発注→納品→検収→支払いまでの全ライフサイクルを追跡します。
ORDER_LINEのライフサイクル：
発注発行 → サプライヤー受注確認 → 納品（delivery_*）
→ 検収（acceptance_*） → 支払締め（closing_finished_date_time）
項目 内容 日本語名 受注（じゅちゅう） DBテーブル j2_supplier.supplier.receive_order_header + receive_order_detail説明 バイヤーのORDER_LINEに対するサプライヤー側のビュー。バイヤーがORDER_LINEを作成すると、システムが自動的にサプライヤー向けのRECEIVE_ORDERを生成します。
項目 内容 日本語名 承認ルート（しょうにんルート） DBテーブル j2_buyer_group.buyer_order.approval_route説明 誰がどの順番で承認するかを定義します。1件のESTIMATEまたはORDERに対して、複数段階の承認が設定可能です。 子テーブル approval_stage（各承認ステップ）、approval_route_referencer（具体的な承認者）
DBテーブル名 業務用語（日本語） データベース company会社 j2_master.common company_group会社グループ（顧客） j2_master.common company_division会社区分 j2_master.common userユーザー j2_master.common roleロール j2_master.common permission権限 j2_master.common screen画面 j2_master.common categoryカテゴリ j2_buyer_group.master_common account_title勘定科目 j2_buyer_group.master_common business_place事業所 j2_buyer_group.master_common supplier_masterサプライヤーマスタ j2_buyer_group.master_common tax税率 j2_master.common country国 j2_master.common static_entity静的エンティティ（列挙値） j2_master.common multi_language多言語翻訳 j2_master.common
DBテーブル名 業務用語（日本語） acceptance_group検収グループ auto_acceptance_setting自動検収設定 payment_closing_*支払締め（月次）
カラム 意味 delete_flg = true論理削除済み（物理削除はしない） version更新回数（楽観的ロック用） create_user_code / update_user_code作成者 / 最終更新者 create_date / update_date作成日時 / 最終更新日時 display_codeユーザー向けの表示コード（内部idとは別） is_temp = true一時保存中（正式申請前）
receive_statusテーブルのkaikataカラム：
値 名称 説明 1見積購買 見積プロセスを経た購買 2カタログ購買 カタログモールからの購買
Status ID 日本語名 説明 Status1_2（20）見積承認待ち 見積計画の承認待ち Status1_3（30）差戻し 修正依頼あり（返却） Status1_4（40）回答待ち RFQ送付済・サプライヤーの回答待ち Status1_15（150）回答あり サプライヤーから見積あり Status1_16（160）採用なし サプライヤー未選定 Status2_1（240）発注承認待ち 発注の承認待ち Status2_2（250）発注差戻し 発注が返却された Status2_3（260）受注待ち サプライヤーの受注確認待ち Status2_4（270）受注辞退 サプライヤーが発注を辞退 Status2_6（290）納品待ち 納品待ち Status2_7（300）未検収 納品済・検収待ち