指標字典
每個指標註明業務問題、分子與分母、統計週期、排除項、更新時間和責任人。例如實際供餐份數、下單份數與支付筆數分別統計；退款、取消和測試記錄要有一致處理規則。
CAPABILITIES
餐飲大數據
以真實記錄、統一口徑和責任閉環，支持餐飲經營判斷。具體數據範圍、系統接入與分析能力須按專案確認。
數據底座
餐飲數據的價值在於解釋現場並支持行動。先圍繞菜單、訂餐、採購、庫存、生產、供餐、結算和回饋確定數據來源，明確每項記錄由誰產生、何時發生、如何核對，再選擇適合的採集和展示方式。共享的是口徑與協作規則，不要求不同系統預設共用資料庫。
專案方案還應明確菜單營養與過敏原資訊、預約取餐、餐補權益以及驗收、溫控、消毒、留樣和配送記錄如何關聯。數據清單應列明來源系統或表單、業務負責人、更新頻率、必填欄位、使用目的與保存要求。匯入、介面或人工記錄均要檢查缺失、重複和延遲。資訊不完整時保留「未採集」或「待核實」狀態，不能填零或補造記錄，以免誤導經營判斷。
統一口徑
將組織、場地、餐廳、檔口、餐次、菜品、原料與供應商分別建立穩定編碼和名稱對照。記錄規格、單位換算、有效期及修改責任人，使同名異物、同物異名和歷史版本能夠被區分。主數據變更應先評估報表與結算影響，再確定生效日期，不能用直接覆蓋抹掉歷史口徑。
可比分析
跨專案比較時同時列出營業天數、服務餐次、人員範圍與外部變化。剩餐應區分未售出、加工損耗和餐後剩餘；成本比較先統一含稅範圍、計量單位和分攤方法。
身份權限
先區分就餐資格、業務操作權限和管理查看範圍。員工、學生、訪客等身份只提供完成服務所必需的資訊；現場人員、專案管理者與財務人員按職責存取不同範圍。帳號開通、崗位變動、臨時授權與離場停用需要明確發起人、批准人和生效時間。
個人資訊使用應說明目的並具備相應處理依據。對健康、生物識別及未成年人等敏感資訊另行評估必要性和保護條件；能夠用彙總數據回答的問題，不必展示個人明細。介面授權、操作日誌、匯出控制和保存期限需在專案方案中確定，本頁不代表統一身份認證或人臉識別系統已經接入。
帳實核對
採購訂單、到貨驗收、庫存收發、領用生產與費用結算需要建立對應關係。核對先檢查品名、規格、單位、數量、單價和時間，再解釋差額來自短收、退貨、替換、報損或跨期入帳。餐飲訂單、支付、退款和餐補分別核對，避免把支付成功直接等同於已經供餐。
對帳以原始記錄和批准憑據為依據。重複匯入應識別同一業務單據；更正保留原值、原因、操作者和批准記錄。無法解釋的差異進入待處理清單，由採購、現場或財務負責人核查後再確認，不用自動平帳掩蓋問題。
業務關係
從經營問題出發理解資料
菜品銷量、庫存成本與時段營運提供不同角度的資訊。分析需要先統一口徑，再支持經營調整，並以復盤檢視調整後的變化。
營運決策
現場需要的是能夠回答問題的視圖：高峰集中在哪個時段，哪些菜品容易缺貨，剩餘與生產計畫有什麼關係，配送延遲影響了哪些餐次。以餐廳、餐次、菜品和時間為維度組織資訊，再由負責人結合班次、天氣、活動和臨時安排判斷調整方式。
預測功能若進入專案，應先說明輸入數據、適用條件和人工修正機制，並與明確基準比較。歷史不足、節假日或菜單變化時降低對結果的依賴。圖表用於輔助判斷，採購、菜單和人員調整仍需業務確認；沒有實際驗證的演算法能力和改善比例不寫成既有成果。
交付與維護
數據方案可按範圍交付來源清單、主數據字典、指標說明、核對規則、角色權限表、異常處理流程和報表樣例。驗收關注記錄能否追到來源、相同輸入是否得到同口徑結果、越權存取是否被阻止、差異是否有人跟進。上線後約定欄位與介面變更流程，明確停機時的人工記錄和補錄方式。食品安全記錄異常應及時交由相應負責人處理，不能等待經營報表週期結束。
行業參考
個人資訊保護邊界參考官方法律原文。本文的數據組織和核對流程為可按專案設計的方法，不證明任何具體系統、模型、介面或客戶數據已經接入。