riceshop の機能要件・非機能要件を定義するドキュメントです。システムの目的・利用者・全体像は システム概要 を、各機能の実装詳細は features/ を参照してください。本書は「何を満たすべきか」を整理し、**現行実装との差異がある箇所には「実装メモ」**を添えています。
このドキュメントは旧 specs/01_要件定義書.md (Ver.4.3) を、会話の残骸（【更新提案】 ヘッダや本文を囲む markdown フェンス）を除去したうえで、現行コードと照合して再構成したものです。
本書は、お米販売システムの開発における要求と仕様を定義するドキュメントです。システムの目的・機能・非機能要件を網羅し、開発の指針とします。
厳密なウォーターフォールではなく、要件定義・設計・実装・テストを機能単位で繰り返す反復的・発展的な開発アプローチ（スパイラルモデルに近い考え方）を採ります。途中で生じる仕様変更・改善要求に柔軟に対応し、完成度を段階的に高めます。
農場で生産したお米を、特定の顧客（Facebook のフレンドおよびリアルフレンド）にオンライン販売する WEB システムです。新規顧客の獲得ではなく、既存の販売業務における 業務効率化・ミス防止／作業の最適化支援／状態の可視化 を目的とします。詳細は システム概要 を参照してください。
- 購入者 — 商品の閲覧および注文を行う。
- 管理者 — 農場主 1 名のみ。全ての管理機能を操作する。
- 購入者は、管理者が事前に発行した ID・パスワードでログインする。
- ID・パスワードは UTF-8 文字セット（ひらがな・カタカナ・漢字・スペース等を含む）に対応する。
- 購入者自身によるアカウント新規登録機能は不要。
- パスワードのオンライン再設定機能は不要（管理者が手動対応）。
実装メモ: ID は全角・半角スペースを無視して照合する（IgnoreSpaceModelBackend）、ログイン画面のパスワード欄は既定で平文表示——いずれも IT 操作に不慣れな顧客向けの意図した仕様です。詳細は features/アカウント認証 を参照。
- お届け先の選択: 商品一覧上部で、管理者が登録したお届け先から送付先を 1 つ選ぶ。
- 商品表示: 「商品内容（品種名・精米/玄米・容量）」「価格」「購入可能な残り在庫数」を表示。購入者が閲覧・購入できるのは「販売中」かつ「アクティブ販売年度」の商品だけである（Issue #17 Phase 3b）。
- 在庫状況: サイドバーに品種ごとの残り在庫量（kg・小数）と、自身のカート消費量（玄米換算）を併記。
- ショッピングカート: お届け先ごとに独立した配送グループを持ち、複数を同時保持できる。カート追加・数量変更時にリアルタイム在庫チェックを行い、不足時は操作をブロックする。年度切替前にカートへ入れた商品が対象年度外になった場合も、購入可否をサーバー側で再検証する（Issue #17 Phase 3b）。
詳細は features/購入者向け機能。
- サイドバー内容を確認 →「注文内容の確認へ」。全配送グループの内容を一覧表示し、参考送料（梱包見込み箱数から算出）と参考合計額を「※送料は管理者が梱包を確定した後に正式決定」の注釈付きで表示する。
- 「この内容で注文する」で最終在庫確認 → 確保できれば各配送グループをお届け先ごとの個別注文として一括記録し、参考送料を
provisional_shipping_fee に保存する。不足時は中断しエラー表示。
- 注文履歴／ステータス確認: マイページで履歴、注文詳細で現在ステータスと送料状態（参考／確定）を確認。
- 配送状況確認: 発送済みの箱ごとに伝票番号と配送業者の追跡リンクを表示。
- 注文のキャンセル: ステータスが「新規注文」の間のみマイページから可能。
- 注文の変更: ステータスが「新規注文」の間のみ可能。変更できるのは各商品の数量のみで、非同期通信のスムーズな UI で提供する。
- 請求書ダウンロード: 注文履歴一覧から複数注文の一括請求書（PDF）をいつでもダウンロード。都度最新内容で自動生成し、
final_shipping_fee 未設定の注文が 1 件でも含まれる場合は「送料（未確定）」「合計（暫定）」を明記する。
ログイン後のトップに「次に何をすべきか」を ToDo リスト形式で表示する。
| ToDo 項目 |
件数カウントの対象 |
遷移先 |
| 新規注文（未受付） |
ステータス「新規注文」の注文数 |
注文管理画面 |
| 要袋詰リスト |
「注文受付」済から集計した品種・容量ごとの必要袋数 |
袋詰管理画面 |
| 未入金リスト |
入金ステータス「未入金」の注文を持つ顧客数 |
注文管理画面 |
| 要パッケージングリスト |
袋詰完了・箱詰め待ちの宛先数 |
自動引当ボード |
| 発送準備完了 |
パッケージステータス「発送準備完了」の荷物数 |
発送管理画面 |
実装メモ: 現行のダッシュボードでは、「要パッケージングリスト」は Package.status=PACKAGING の宛先 distinct 数を集計して表示します（dashboard/views.py、packaging_count）。一方、「発送待ちパッケージ」「手渡し準備完了」に当たる 2 件（shipping_packages_count / ready_for_pickup_count）は 0 固定で表示されます（実集計が未実装）。要件表の「発送準備完了」と実テンプレートの表示名の対応も含め、詳細は features/管理者向け補助機能。
- 商品価格: 品種の基準価格・容量・精米/玄米・価格係数から提案単価を算出し、100円未満を四捨五入して100円単位に丸める。管理者は商品マスタ編集でこれを参考に価格設定でき、注文編集で個別に手動上書きも可能。
- 送料: お届け先の「送料区分（通常/遠地）」に基づき自動計算（購入者向けは参考値、管理者向けは確定値）。詳細は features/送料計算。
- 消費税: 管理者が設定する全価格は内税として扱う。
- 注文一覧: ステータス・キーワードで柔軟に検索・絞り込み。
- 注文受付: 新規注文を確認し、ステータスを「注文受付」に変更。
- 注文編集: 発送完了前なら、お届け先・商品数量・商品単価・商品の追加/削除を変更できる。商品内容（数量・追加・削除）が変更されると
final_shipping_fee は自動的に NULL（未確定）に戻る。
実装メモ:
- 顧客側の注文変更では、品種ごとの増加分を基準に在庫充足を検証します。全体重量が増えない変更でも、増えた品種の在庫超過は拒否されます（Issue #2 対応済み）。
- 管理者の注文編集でのお届け先変更制御は Issue #4 で整理済みです。顧客側のお届け先変更 UI は Issue #5 により、新規注文の間だけ利用できるように整理済みです。
- 詳細は features/注文管理。
- 袋詰管理: 「注文受付」済の全注文から品種・容量ごとの必要袋数を自動集計し、物理袋詰後に完了袋数を登録（袋在庫として管理）。
- 自動引当・パッケージング提案ボード: 「未引当の袋在庫エリア」と「宛先ごとのエリア」で構成。ドラッグ＆ドロップ／クリックで箱詰め・移動・予約を操作でき、宛先単位／一括の自動梱包提案、箱ごと 3 段階ロック（変更可／追加のみ可／変更不可）を備える。梱包確定時にその宛先の受付済み注文に紐づくパッケージ完了を判定し、完了していれば箱数から最終送料を計算して
final_shipping_fee に保存する。同一宛先に複数注文が含まれる場合、宛先単位の送料は1回だけ請求されるように記録する。
- 発送管理: 「発送準備完了／伝票印刷済み／完了済み」をタブ管理。ヤマト B2 用 CSV 出力、伝票番号付き CSV インポート、ステータス更新・差し戻しに対応。
詳細は features/出荷ワークフロー。確定後のパッケージ変更で送料が stale になる問題（Issue #8）は解消済み。
- 顧客管理: 顧客の検索・新規作成・編集・パスワード再設定、お届け先の CRUD を専用 UI で完結（→ features/顧客管理）。
- マスタ管理: 品種マスタ・商品マスタの CRUD を専用 UI で提供（→ features/商品在庫マスタ）。
- 商品の販売年度（Issue #17 Phase 3a/3b）: 品種は年度によらないマスタとし、商品には必須の販売年度を持たせる。同じ品種・種類・容量でも年度ごとに商品を登録できる。管理者は年度締め画面から、締める年度の販売中商品だけを一括で販売停止し、アクティブ販売年度を次年度へ切り替えられる（BLOCK項目なし・次年度商品の準備・確認チェック・年度再入力を実行前提条件とする単一トランザクション処理）。管理者向けの注文作成・編集は、引き続き全年度の販売中商品を選択肢に含める（購入者向けのようなアクティブ年度制限は適用しない）。
- 年度の商品を一括複製（Issue #22）: 年度締め前の次年度商品準備を効率化するため、商品マスタからコピー元年度・コピー先年度（登録済みの後続OPEN年度）を選び、コピー元年度の全商品を複製できる。価格・価格係数は引き継ぎつつ、複製後の商品は必ず「未公開」から開始し、誤って即時販売されることを防ぐ。コピー先に同一構成の商品が既にある場合は上書きせずスキップし、作成件数・スキップ件数を表示するため、同じ操作を再実行しても重複商品は作成されない。在庫・注文・袋・箱などの関連業務データは複製の対象外。
- 年度単位の業務管理（Issue #17 Phase 4方針・詳細設計済み・未実装）: 注文は必ず1つの販売年度に属し、異なる販売年度の商品を同じ注文へ混在させない。在庫は食品の年度切替時に持ち越さず、販売年度・品種単位で新年度を0から開始し、旧年度分は履歴として保持する。年度、商品、注文、在庫、出荷、顧客残高の年度間繰越を一貫して管理するため、
SalesSeason 相当の年度モデルを導入する。締め済み年度への新規注文・増量・在庫変更は禁止する一方、旧年度注文の後始末に必要なキャンセル・数量減少は許可する。具体的なモデル構造（SalesSeason/Product.season/Order.season/SeasonStock/Package.season/CreditApplicationAllocation等）・段階的移行手順・フェーズ分割（Phase 4-A〜4-H）・判断事項は 検討用/17_..._実装案 §Phase 4詳細設計 で確定した。Phase 4着手をブロックする未決事項は残っていない。
- 在庫管理: 品種ごとの玄米換算在庫。「総供給量」と「総注文量」を保持し「現在在庫量」は差分から動的計算。管理者は「総供給量」を調整量（増減）で更新する。
- 動的価格提案: 商品の作成・編集時、品種・容量の変更に応じて提案価格をリアルタイム計算。
- 安全な削除: 注文等に利用中の品種・商品は削除ボタンを非活性化する。
実装メモ: 品種マスタは、配下の商品が注文・袋に使われている場合、または品種に精米作業記録（MillingRecord）がある場合に削除ボタンを非活性化します。削除可能な品種でも配下に未使用商品がある場合は、品種削除により商品もカスケード削除されることを確認ダイアログで明示します。詳細は features/商品在庫マスタ。
- システム設定: 依頼主情報・送料・各種計算係数・請求書の振込先口座などは Django 管理サイトで設定する（→ development/補足資料 §3.4）。
- 旧システムデータ移行: 旧システムからエクスポートした SQL ファイルを専用画面からアップロードし、顧客・お届け先情報を一括取り込みする。
実装メモ: データ移行ビューの redirect 未 import は Issue #9 で修正済みです。移行は引き続き破壊的な全置換処理のため、運用詳細は operations/データ移行 を参照してください。
- コンテキスト対応: 開いている画面に応じた関連ヘルプをモーダルで表示する。
- マニュアル管理: Markdown（
.md）ファイルを専用画面からアップロード・削除できる。
実装メモ: マニュアル管理画面のフォーム送信先は実在する URL 名 dashboard:manuals を参照します（Issue #10 対応済み）。詳細は features/管理者向け補助機能。
- 華美な装飾は不要。シンプルで機能的、直感的に操作できる分かりやすさを最優先する。
- 管理者向けの主要操作（顧客編集・マスタ管理・データ移行など）は Django 管理サイトに遷移せず、システム内で完結する一貫した体験を提供する。
- SSL/TLS: 全ページの通信を常時暗号化（HTTPS 化）する。
- インフラ: 管理者が用意する Docker＋traefik（リバースプロキシ）環境上で動作させる。
- 在庫整合性: 注文確定・変更・キャンセルなど在庫数を変更する全処理は、DB のトランザクションおよび排他ロックで保護し、同時アクセス時のデータ整合性を保証する。
実装メモ: 本番セキュリティ設定（SECURE_SSL_REDIRECT 等）は DEBUG=False 時に有効化されます（→ development/共通基盤 §1.6）。
元資料: specs/01_要件定義書.md (Ver.4.3) を現行コード・既存 docs（features 各文書）と照合し、会話残骸を除去して再構成
関連: README, specs棚卸し表, Issue #1