Feature

キッチン / 会計 14 Scenarios

Kitchen & Billing — UC-10 〜 UC-13

UC-10 注文ステータス更新（キッチン） KIT-007 〜 KIT-009

バリスタがキッチン画面で注文のステータスを更新し、提供完了をホールスタッフに伝える。

Background 各シナリオの共通前提

Givenバリスタは認証済みでキッチン画面 /kitchen を表示している

Scenarios

Scenario · @happy-path

注文を「提供済み」にする

Given注文カードが "pending" ステータスで表示されている

Whenバリスタが「調理開始」ボタンをクリックする

ThenORDERレコードのステータスが "preparing" に更新される

Whenバリスタが「提供済み」ボタンをクリックする

ThenORDERレコードのステータスが "served" に更新される

And「進行中」タブから対象注文カードが消える

# 遷移は pending → preparing → served の順のみ。スキップ・逆行は 422 を返す

Scenario · @alternative

全注文が提供済みの場合

Givenキッチン画面に pending の注文が 0 件

Then「現在 pending の注文はありません」が表示される

UC-11 会計処理（精算） BILL-007 〜 BILL-019

スタッフがテーブルの会計を処理する。BILLレコードを生成し、税額・割引・合計をサーバーサイドで算出（整数yen）。employee_idはJWTペイロードから自動取得（なりすまし防止）。

Background 各シナリオの共通前提

Givenスタッフは認証済みである

Andテーブルが着席登録済みで served 状態の注文が1件以上ある（精算対象は served オーダーのみ）

Scenarios

Scenario · @happy-path

現金精算

Givenスタッフは会計画面で注文内容を確認している

And支払方法として "cash" を選択している

When「精算する」ボタンをクリックする

ThenBILLレコードが生成される（status: "settled"）

And税額・割引・合計がサーバーサイドで自動計算される

Andテーブルのステータスが "checked_out" に更新される

# 税率 10%, 整数yen, Math.round(taxable * 0.1)

Scenario · @happy-path

クレジットカード精算

Given支払方法として "credit" を選択している

When「精算する」ボタンをクリックする

ThenBILLレコードが payment_method = "credit" で生成される

Scenario · @happy-path

割引適用精算

Givenスタッフが割引金額（円）を入力している

When「精算する」ボタンをクリックする

Then割引後の合計金額でBILLレコードが生成される

# discount_amount はJSONボディで受け取る（min: 0）

Scenario · @error

注文が0件の状態での精算試行

Givenテーブルに注文が1件もない

When「精算する」ボタンをクリックする

Then「注文がありません」エラーを表示する

UC-12 会計履歴の閲覧・取消 BILL-005 〜 BILL-008

スタッフが会計一覧画面 /bills で精算済みの会計履歴を検索・閲覧し、レシート明細を確認する。店長は精算済みの会計を取り消すことができ、取消理由・日時・実行者（voided_by）が監査ログとして記録される。

Background 各シナリオの共通前提

Givenスタッフは認証済みで会計一覧画面 /bills を表示している

And1 件以上のBILLレコードが存在する

Scenarios

Scenario · @happy-path

会計履歴の検索・絞り込み

Givenスタッフは日付を指定して会計履歴を絞り込んでいる（GET /v1/bills?date=YYYY-MM-DD）

When指定日の会計一覧を取得する

Then該当日のBILLの一覧（会計番号・支払方法・金額・状態）が表示される

And表示中の一覧は支払方法（現金 / クレジット / すべて）でクライアント側で絞り込める

And取消（voided）を除いた合計売上金額のサマリーが表示される

# サーバー側の絞り込みは date / limit / offset のみ。支払方法フィルターは取得済み一覧へのクライアント側処理

Scenario · @happy-path

レシート明細の表示

Givenスタッフは一覧から会計行を選択している

When会計を開く

Then注文明細・小計・税額（10%）・割引・合計を含むレシートが表示される

And取消済みの会計には取消理由・取消日時が表示される

Scenario · @happy-path

会計の取消

Given店長は対象会計を選択している

When取消理由を入力して「取消確定」ボタンをクリックする

ThenBILLレコードのステータスが "voided" に更新される

Andvoid_reason・voided_at・voided_by が記録される

# voided_by = JWTペイロードの employee_id（監査ログ）

Scenario · @error

取消理由が未入力

Given店長が取消理由を入力していない

When「取消確定」ボタンをクリックする

Then「取消理由は必須です」エラーを表示する

Scenario · @error

既に取消済みの会計への操作

Given対象のBILLが既に "voided" 状態

When取消操作を試みる

Then「取消済みの会計は操作できません」エラーを表示する

# manager ロール以上のみ実行可能（guardRole(c, "manager")）

UC-13 日次締め CLOSE-001 · CLOSE-002

店長が当日の売上を締める。DAILY_CLOSEレコードを生成し翌日の集計を管理する。店長ロール必須。

Background 各シナリオの共通前提

Given店長は認証済みである

# guardRole(c, "manager") — manager ロール必須

Scenarios

Scenario · @happy-path

日次締めの実行

Given店長は日次締め画面 /daily-close を表示している

And当日の営業が終了している

When「本日分を締める」ボタンをクリックする

ThenDAILY_CLOSEレコードが生成される（status: "closed"）

And当日の売上サマリーが記録される

Scenario · @error

既に締め済みの場合

Given本日の日次締めが完了済み

When締め操作を試みる

Then「本日は既に締め済みです」エラーを表示する

Scenario · @warning

未精算会計が残っている場合

Given精算が完了していないテーブルが存在する

When「本日分を締める」ボタンをクリックする

Then警告メッセージを表示する

# 強制締めではなく確認を促す警告（未精算は任意続行）

キーワード凡例 / Keyword Legend

Given事前条件 When操作 Then期待結果 And前のステップを継続 But例外・除外条件