HandyCafe Docs
owner cashier

注文管理

注文タブは、顧客から入るすべてのカフェテリア注文を扱うライブダッシュボードです。クラウドを 3 秒ごとにポーリングし、新しい動きがあるとデスクトップ通知、音声アラート、タブ見出しの未処理件数バッジで知らせます。

レイアウト

注文ページには 2 つの領域があります。

領域 役割
ステータスタブ 注文状態で絞り込みます: all、placed、confirmed、preparing、ready、served。cancelled と refunded の注文は既定で除外されます。
注文一覧 注文ごとのカードです。新しいものが上に来る順でグループ化されます。各カードにはテーブルコード、入力があれば顧客の電話番号、明細、合計、操作ボタンが表示されます。

ライブポーリング

注文ダッシュボードは 3 秒ごとに /v1/cafeteria/admin/orders/poll をポーリングします。新しい注文が入るたびに次の処理が発生します。

  1. テーブルコードと商品数を含むデスクトップ通知を表示します。
  2. 設定 > カフェテリア でサウンド通知が有効なら、サーバーのスピーカーから音声アラートを再生します。
  3. 注文タブの未処理件数バッジが 1 つ増えます。
  4. プリンターが「新規注文時に自動印刷」に設定されていれば、レシートを自動印刷します。

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 になったときに設定されます。

顧客向けメニューでは各行の横にバッジが表示され、どの明細が準備完了か、どれが配達中かを顧客が確認できます。

注文のキャンセル

  1. 注文カードを開きます。
  2. キャンセル をクリックします。
  3. 表示されるダイアログで確認します。
  4. 注文は cancelled に遷移します。履歴には残りますが、既定のライブ表示からは消えます。

キャンセルは注文全体に対する操作です。1 行だけ取り消したい場合は、その行の明細ステータスを cancelled に変更してください。

精算(Settle Check)

精算は、テーブル上の未処理注文を 1 ステップでまとめて閉じます。顧客が退店して、全額を支払いたいときに使います。

  1. テーブルページ、またはフロアプランのアクションメニューからテーブルを開きます。
  2. 精算 をクリックします。
  3. モーダルに、そのテーブル上の served ではない注文がすべて一覧表示されます。
  4. 支払い方法を選びます。選択肢は Cash、Card、Online、Other です。
  5. 確認します。

サーバーは次の処理を原子的に実行します。

  • テーブル上の未処理注文はすべて payment_status=paidserved に遷移します。
  • 合計金額、支払い方法、作成時刻を含む cafeteria_settlements レコードが作成されます。
  • どの注文がこの精算に属するかを示す settlement-orders の監査履歴が記録されます。
  • テーブルのセキュリティコードが失効し、QR が無効になります。
  • テーブルは idle に戻ります。

支払い方法として Online を選んだ場合、精算レコードは online-paid としてマークされます。この操作で Stripe の請求は発生しません。顧客側のオンライン決済は注文時に処理され、精算アクションは会計帳簿用のキャッシュフロー記録として機能します。

開始後タイマー

各テーブルには、顧客が着席したときに設定される opened_at タイムスタンプがあります。フロアプランとテーブルページには、その時点からのライブタイマーが表示されます。これにより、長時間注文がないままアクティブなテーブルや、セッション終了が近いかもしれないテーブルをスタッフが見つけやすくなります。

このタイマーは、テーブルを閉じるか精算すると 0 に戻ります。

動的準備時間の表示

商品の動的準備時間が有効な場合、注文カードには商品名の横に推定時間が表示されます。顧客向けメニューで「メニューに準備時間を表示」がオフでも、スタッフには推定時間が見えます。

推定値は、新しい注文が入るたび、そして注文が完了するたびに更新されます。システムは実際の厨房のペースから学習します。

新規注文通知の挙動

通知はタブ単位ではなくアプリ全体に対して発生します。つまり、管理パネルや設定など、HandyCafe サーバーの別の場所を見ていても通知を受け取れます。音声アラートは 設定 > カフェテリア > サウンド通知 で有効/無効を切り替えます。

デスクトップ通知を表示するには、OS 側で HandyCafe に通知権限が付与されている必要があります。新規注文後に通知が見えない場合は、OS の通知設定を確認してください。

ヒント

  • ステータスタブで作業を分担してください。preparing に絞った画面は厨房キューの表示に向いています。ready の画面は配達待ちの確認に便利です。
  • テーブルを閉じる最速の方法は精算です。個別注文のキャンセルは、明確な誤りがあったときだけに使ってください。
  • スタッフには、ステータスを一貫して進めるよう教えてください。動的準備時間の推定はこれらのシグナルから学習するため、状態を飛ばすと精度が落ちます。
  • キャンセルや返金済みの注文は、定期的に管理エンドポイントから監査して、スタッフの操作ミスの傾向を把握してください。