注文管理
注文タブは、顧客から入るすべてのカフェテリア注文を扱うライブダッシュボードです。クラウドを 3 秒ごとにポーリングし、新しい動きがあるとデスクトップ通知、音声アラート、タブ見出しの未処理件数バッジで知らせます。
レイアウト
注文ページには 2 つの領域があります。
| 領域 | 役割 |
|---|---|
| ステータスタブ | 注文状態で絞り込みます: all、placed、confirmed、preparing、ready、served。cancelled と refunded の注文は既定で除外されます。 |
| 注文一覧 | 注文ごとのカードです。新しいものが上に来る順でグループ化されます。各カードにはテーブルコード、入力があれば顧客の電話番号、明細、合計、操作ボタンが表示されます。 |
ライブポーリング
注文ダッシュボードは 3 秒ごとに /v1/cafeteria/admin/orders/poll をポーリングします。新しい注文が入るたびに次の処理が発生します。
- テーブルコードと商品数を含むデスクトップ通知を表示します。
- 設定 > カフェテリア でサウンド通知が有効なら、サーバーのスピーカーから音声アラートを再生します。
- 注文タブの未処理件数バッジが 1 つ増えます。
- プリンターが「新規注文時に自動印刷」に設定されていれば、レシートを自動印刷します。
placed または confirmed の注文がより進んだ状態になるか、取り消されるまでバッジは表示され続けます。バッジはサイドバーのカフェテリアセクション全体で確認できるため、注文タブを開きっぱなしにしておく必要はありません。
注文のライフサイクル
すべての注文は、決まった状態遷移をたどります。
| 状態 | 意味 |
|---|---|
placed |
顧客が注文を送信した状態です。スタッフの操作はまだありません。 |
confirmed |
スタッフが注文を受け付けた状態です。 |
preparing |
調理中です。 |
ready |
提供または受け取り可能な状態です。 |
served |
顧客に提供済みです。 |
cancelled |
スタッフがキャンセルしました。ライブ表示からは消えますが、履歴には残ります。 |
refunded |
支払い後の返金が発行された状態です。 |
各注文カードの操作バーには、次に進められる状態が表示されます。進行はワンクリックです。UI はオプティミスティック更新を使っており、新しい状態は即座に表示されます。サーバーが変更を拒否した場合は、状態が元に戻り、エラー通知が表示されます。
明細ごとのステータス
注文によっては、完了時間が異なる複数の明細を含むことがあります。たとえば、バーガーはピザより先にできあがるかもしれません。明細ごとのステータスを使うと、各行を個別に追跡できます。
各明細には 5 つの選択肢を持つ独自のドロップダウンがあります: placed、preparing、ready、served、cancelled。各明細には 3 つのタイムスタンプもあります。
created_atは注文が届いたときに設定されます。ready_atは、その明細が初めてreadyになったときに設定されます。served_atは、その明細がservedになったときに設定されます。
顧客向けメニューでは各行の横にバッジが表示され、どの明細が準備完了か、どれが配達中かを顧客が確認できます。
注文のキャンセル
- 注文カードを開きます。
- キャンセル をクリックします。
- 表示されるダイアログで確認します。
- 注文は
cancelledに遷移します。履歴には残りますが、既定のライブ表示からは消えます。
キャンセルは注文全体に対する操作です。1 行だけ取り消したい場合は、その行の明細ステータスを cancelled に変更してください。
精算(Settle Check)
精算は、テーブル上の未処理注文を 1 ステップでまとめて閉じます。顧客が退店して、全額を支払いたいときに使います。
- テーブルページ、またはフロアプランのアクションメニューからテーブルを開きます。
- 精算 をクリックします。
- モーダルに、そのテーブル上の
servedではない注文がすべて一覧表示されます。 - 支払い方法を選びます。選択肢は Cash、Card、Online、Other です。
- 確認します。
サーバーは次の処理を原子的に実行します。
- テーブル上の未処理注文はすべて
payment_status=paidのservedに遷移します。 - 合計金額、支払い方法、作成時刻を含む
cafeteria_settlementsレコードが作成されます。 - どの注文がこの精算に属するかを示す settlement-orders の監査履歴が記録されます。
- テーブルのセキュリティコードが失効し、QR が無効になります。
- テーブルは
idleに戻ります。
支払い方法として Online を選んだ場合、精算レコードは online-paid としてマークされます。この操作で Stripe の請求は発生しません。顧客側のオンライン決済は注文時に処理され、精算アクションは会計帳簿用のキャッシュフロー記録として機能します。
開始後タイマー
各テーブルには、顧客が着席したときに設定される opened_at タイムスタンプがあります。フロアプランとテーブルページには、その時点からのライブタイマーが表示されます。これにより、長時間注文がないままアクティブなテーブルや、セッション終了が近いかもしれないテーブルをスタッフが見つけやすくなります。
このタイマーは、テーブルを閉じるか精算すると 0 に戻ります。
動的準備時間の表示
商品の動的準備時間が有効な場合、注文カードには商品名の横に推定時間が表示されます。顧客向けメニューで「メニューに準備時間を表示」がオフでも、スタッフには推定時間が見えます。
推定値は、新しい注文が入るたび、そして注文が完了するたびに更新されます。システムは実際の厨房のペースから学習します。
新規注文通知の挙動
通知はタブ単位ではなくアプリ全体に対して発生します。つまり、管理パネルや設定など、HandyCafe サーバーの別の場所を見ていても通知を受け取れます。音声アラートは 設定 > カフェテリア > サウンド通知 で有効/無効を切り替えます。
デスクトップ通知を表示するには、OS 側で HandyCafe に通知権限が付与されている必要があります。新規注文後に通知が見えない場合は、OS の通知設定を確認してください。
ヒント
- ステータスタブで作業を分担してください。
preparingに絞った画面は厨房キューの表示に向いています。readyの画面は配達待ちの確認に便利です。 - テーブルを閉じる最速の方法は精算です。個別注文のキャンセルは、明確な誤りがあったときだけに使ってください。
- スタッフには、ステータスを一貫して進めるよう教えてください。動的準備時間の推定はこれらのシグナルから学習するため、状態を飛ばすと精度が落ちます。
- キャンセルや返金済みの注文は、定期的に管理エンドポイントから監査して、スタッフの操作ミスの傾向を把握してください。