What the Data for This Use Case Looks Like
This use case provides daily revenue yield reporting services for hotel and catering enterprises. Relevant data is collected from store POS terminals, central kitchen inventory systems, member consumption management systems, and central settlement platforms. Data synchronization follows this schedule: real-time order data is synced to local cache; full daily settlement data is batch synced after daily store closure. Each dataset includes fields such as store code, business date, meal period identifier, actual revenue amount, food material cost amount, labor cost amount, consumable cost amount, and non-operating revenue and expense amount. All monetary fields use Chinese Yuan (CNY) as their unit. Data is partitioned and stored by store and business date. The number of fields in the daily dataset for a single store remains fixed.
Constraints on Conversation Logs and Auditing
Because data is synced in daily batch settlement batches, conversation logs must be associated with a clear business cycle dimension. Real-time auditing of unsettled data is not supported. Combined calculation logic for multiple cost and revenue items requires audit logs to fully record request filter conditions and returned core calculation fields. This prevents unclear traceability of revenue data. In scenarios with multiple stores operating in parallel, logs must be isolated by store permissions to prevent cross-store data leaks or confusion. The daily batch synchronization feature also requires audit processes to align with the synchronization cycle, to avoid calling empty datasets that have not completed synchronization.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
LOG_RETENTION_DAYS | 30–90 days | Hotel and catering daily log volume is moderate. Retaining logs for 30 to 90 days covers monthly and quarterly standard audit cycles, while controlling storage resource consumption |
filterByMetadata | ["store code", "business date", "meal period identifier"] | Hotel and catering data is partitioned and stored by store, date, and meal period. Configuring this rule enables precise filtering of target logs, avoiding performance loss from full-volume queries |
auditLogIncludeParams | ["requestBody.reqMetadata.storeId", "responseBody.totalProfit", "responseBody.costTotal"] | Core inputs (store ID) and outputs (total profit, total cost) for revenue yield calculations must be tracked to ensure audit trails fully trace data flow |
SYNC_DATA_INTERVAL | 86400 seconds | Hotel and catering completes data aggregation via daily settlement processes. A single daily sync covers audit requirements for that day's operational data |
LOG_QUERY_MAX_RESULTS | top 200 results | Daily log volume per store is manageable. Setting a 200-entry limit satisfies single-query needs for multi-store bulk audits, avoiding excessive redundant data returns |
AUDIT_LOG_LEVEL | info | Only core request and response information is logged. Debug-level logs are not required, balancing audit traceability needs and storage costs |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by data format, data volume and business rules. Specific issues require specific analysis. It is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- Symptom: Conversation history generated during debug preview is not filtered by store or date, and cross-store data is mixed. Cause: The
filterByMetadatarule is not configured, so the system does not perform dimension filtering on logs. - Symptom: Empty fields or no matching results are returned when calling revenue yield data. Cause:
SYNC_DATA_INTERVALis not configured to match the daily settlement cycle, resulting in calls to empty datasets that have not completed synchronization. - Symptom: Conversation logs cannot be cleaned up by specified store or business cycle. Cause: Cleanup dimension rules are not configured in
filterByMetadata, so the system cannot identify the cleanup scope.
How to Verify Proper Configuration
- Initiate a revenue yield query request targeting a specified store and business date. Check if the system audit log includes configured fields such as
requestBody.reqMetadata.storeIdandresponseBody.totalProfit. - View the audit log list to confirm only log entries within the configured store and date range are displayed, with no cross-store or cross-cycle irrelevant data.
- Wait for the daily data synchronization to complete, then query logs for the corresponding business date. Confirm that returned revenue data matches the synchronization results from the POS system.
- Initiate a query request across stores. Confirm that the system filters non-authorized scope logs per the
filterByMetadatarule, and cannot return data from unrelated stores.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.