A method, system, equipment, and storage medium for intelligent monitoring of school meal prices.
Patent Information
- Application Number
- CN202610973511.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-01
- Publication Date
- 2026-09-15
Smart Images
Figure CN122760184A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of information management technology, specifically to a method, system, device, and storage medium for intelligent monitoring of campus meal prices. Background Technology
[0002] With increasingly stringent requirements for campus food safety and canteen price supervision, the need for unified management, real-time monitoring, and early warning of abnormalities in the procurement prices of school canteen ingredients within the jurisdiction is becoming increasingly urgent for education regulators. Currently, school meal price management still largely adopts a traditional manual model, with schools reporting ingredient prices themselves and regulators manually verifying them. The overall process has a low level of informatization and intelligence, and suffers from many technical deficiencies.
[0003] In the price reporting process, a standardized reporting mechanism has not been established, leading to problems such as omissions, delays, and duplicate reporting. Furthermore, the system cannot automatically adjust reporting requirements based on semester start and end dates, winter and summer breaks, etc., resulting in chaotic handling of semester boundaries and cross-month cycles, making it difficult to guarantee data standardization and timeliness. Regarding price supervision and anomaly detection, regulatory departments cannot obtain real-time food prices from each school and must rely on manual comparison of reported data with guidance prices. This is not only inefficient and time-consuming but also prone to misjudgments and omissions, leading to delayed detection of price anomalies. In terms of early warning and statistical analysis, the system lacks automatic early warning capabilities. Issues such as price overruns and failure to report on time cannot be promptly alerted, and early warning information is prone to duplication and omissions. The status cannot be automatically updated according to price or guidance price adjustments. In addition, data statistics only support simple summaries and cannot provide effective data support for regulatory decision-making. Summary of the Invention
[0004] In view of this, this application aims to provide a method, system, device and storage medium for intelligent monitoring of school meal prices, in order to solve the technical problems of how to achieve intelligent calculation of reporting cycle, automatic price comparison and closed-loop management of anomaly warning in the monitoring of school meal prices.
[0005] The first aspect of this application provides a method for intelligent monitoring of campus meal prices, the method comprising: Obtain the current date, and determine the start date and end date of the statistical period corresponding to the price reporting period for the current date based on the preset period division rules and reporting deadline rules; Receive the menu price data submitted by the school before the reporting deadline, and perform data deduplication and storage based on menu identifier, school identifier and period information; The system automatically compares the reported school prices with the corresponding pre-set guidance prices for the period, calculates the price difference, and generates an excess indicator. Based on the aforementioned exceedance identifier, an over-guidance price warning is generated, and a non-reporting warning is generated by checking schools that have not reported on time through a scheduled task; When price data or guidance price changes, the status of the out-of-state condition is automatically recalculated and the status of the corresponding warning record is updated synchronously. Price data from various schools is aggregated by category and level, and the distribution of schools exceeding the guidance price is statistically analyzed.
[0006] In one possible implementation of this application, the cycle division rule is as follows: each month is divided into a first half-month cycle and a second half-month cycle, wherein the first half-month cycle corresponds to the 1st to the 14th of each month, and the second half-month cycle corresponds to the 15th to the last day of the month; the reporting deadline rule is as follows: the 15th of each month is the reporting deadline for the first half-month cycle, and the 29th of each month is the reporting deadline for the second half-month cycle.
[0007] In one possible implementation of this application, determining the start date and end date of the statistical period corresponding to the price reporting period for the current date includes: If the current date is between the 1st and the 14th, return the deadlines for the first half and second half of the previous month; If the current date is between the 15th and 28th, return the deadline for the second half of last month and the deadline for the first half of the current month; If the current date is between the 29th and 31st, return the deadlines for the first half and second half of the current month.
[0008] In one possible implementation of this application, a semester boundary determination step is also included: Get the semester timetable, which includes the start and end dates of the semester; The calculated reporting deadline must fall within the current semester's timeframe; If the calculation result is not within the range of the current semester, it will automatically fall back to the range of the previous semester for matching; Price reporting will be suspended during winter and summer vacations.
[0009] In one possible implementation of this application, the method for generating the unreported warning includes: setting a scheduled task to be automatically triggered on the day after the reporting deadline for the first half of each month and the day after the reporting deadline for the second half of each month, scanning the price reporting status of all schools in the jurisdiction for the corresponding period, and generating unreported warning records for schools that have not reported.
[0010] In one possible implementation of this application, the step of automatically recalculating the out-of-state status and synchronously updating the corresponding warning record when the price data or guidance price changes includes: In response to the school modifying the reported price data, recalculate the excess amount and update the excess label; In response to regulatory adjustments to guidance prices, update relevant price records and recalculate the excess status; When the price status changes from exceeding to not exceeding, the corresponding warning record status will be automatically updated to processed. When the error rate changes from never exceeding the limit to exceeding the limit, a new warning record is automatically generated.
[0011] In one possible implementation of this application, the aggregation of price data from various schools by menu category level and the statistical analysis of the distribution of schools exceeding the guidance price include: The dishes are categorized using a two-level tree structure, where the parent level is the ingredient category and the child level is the specific ingredient. By counting the number of school records where each dish exceeds the true mark across all schools, we can obtain the number of schools that exceed the mark for each sub-dish. Aggregate the number of schools exceeding the guide price for each sub-category dish to the corresponding parent ingredient category to obtain the total number of schools exceeding the guide price under each ingredient category.
[0012] The second aspect of this application provides an intelligent monitoring system for campus meal prices, including: The cycle calculation module is used to obtain the current date and determine the start date and end date of the statistical cycle corresponding to the price reporting cycle for the current date based on the preset cycle division rules and reporting deadline rules. The price reporting module is used to receive the menu price data submitted by the school before the reporting deadline, and to perform data deduplication and storage based on menu identifier, school identifier and period information; The price comparison module automatically compares the reported school prices with the corresponding period's preset guidance price, calculates the price difference, and generates an excess indicator. The early warning generation module is used to generate an early warning for exceeding the guidance price based on the exceeded identifier, and to check schools that have not reported on time through a scheduled task and generate an early warning for not reporting. The early warning update module is used to automatically recalculate the out-of-state status and synchronously update the status of the corresponding early warning record when the price data or guidance price changes. The statistics output module is used to aggregate price data from various schools by dish category level and to statistically analyze the distribution of schools that exceed the guidance price.
[0013] A third aspect of this application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform a campus meal price intelligent monitoring method as described in the first aspect and possible implementations thereof.
[0014] The fourth aspect of this application provides a computer storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the intelligent monitoring method for campus meal prices as described in the first aspect and possible implementations of the first aspect.
[0015] The fifth aspect of this application provides a computer program product, comprising: a computer program that, when executed by a processor, implements a method for intelligent monitoring of campus meal prices as described in the first aspect and possible implementations of the first aspect.
[0016] The intelligent monitoring method for school meal prices provided in this application fundamentally solves many technical pain points of the traditional manual monitoring model through a fully automated design. First, by automatically calculating the reporting cycle using preset period and deadline rules, it standardizes price reporting time, completely eliminating problems such as arbitrary reporting, omissions, and delays by schools, ensuring data standardization and timeliness. Second, by using multi-dimensional deduplication storage and automatic price comparison, it replaces the inefficient manual verification mode, significantly improving the accuracy and efficiency of anomaly detection and enabling real-time determination of price exceeding limits. Third, through a dual-type early warning automatic generation and dynamic update mechanism, it achieves a shift from passive to proactive monitoring, ensuring timely detection and closed-loop handling of anomalies. Finally, through hierarchical aggregation and statistics of dishes, it achieves multi-dimensional data analysis from micro to macro levels, providing comprehensive and traceable data support for regulatory decisions. This method as a whole realizes full-process intelligent monitoring of school meal prices, significantly improving regulatory efficiency, data accuracy, and the scientific nature of decision-making, meeting the education department's needs for efficient and precise monitoring. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating the intelligent monitoring method for campus meal prices provided in an embodiment of this application.
[0019] Figure 2 A flowchart is provided for the statistical period start date and reporting deadline in the embodiments of this application.
[0020] Figure 3 A schematic diagram of the structure of a smart monitoring system for campus meal prices is provided for an embodiment of this application.
[0021] Figure 4This is a layered architecture diagram of the intelligent monitoring system for campus meal prices provided in this application embodiment.
[0022] Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0024] Exemplary method: This application provides a flowchart illustrating an intelligent monitoring method for school meal prices. This method can be applied to a monitoring system consisting of an education bureau server and school terminal devices. It is suitable for the education bureau to uniformly monitor the prices of school canteens within its jurisdiction, enabling intelligent reporting, automatic comparison, anomaly warning, and multi-level statistics of school meal raw material prices. Figure 1 As shown, the method specifically includes: S101: Obtain the current date, and determine the start date and end date of the statistical period corresponding to the price reporting period for the current date based on the preset period division rules and reporting deadline rules.
[0025] Specifically, this invention uses the system date when a school user logs in as the current date and extracts the year, month, and day information. The invention pre-sets cycle division rules and reporting deadline rules in the monitoring system. Specifically, each month is divided into a first half-month cycle and a second half-month cycle: the first half-month cycle corresponds to the 1st to the 14th of each month, and the second half-month cycle corresponds to the 15th to the last day of the month; the 15th of each month is the reporting deadline for the first half-month cycle, and the 29th of each month is the reporting deadline for the second half-month cycle.
[0026] By dividing each month into two fixed cycles and setting a unified deadline, the problem of schools submitting reports arbitrarily, omitting reports, or submitting reports late has been completely eliminated. This standardizes the reporting time and streamlines the process for all schools in the jurisdiction, significantly reducing management costs. The two deadlines, the 15th and the 29th, are evenly spaced and allow ample time for schools to submit their reports, while also enabling the education bureau to obtain price data twice a month in a timely manner, avoiding congestion and data backlog caused by concentrated reporting.
[0027] Furthermore, based on the number of days within which the current date falls, determine the start date and end date of the statistical period corresponding to the current price reporting cycle: 1. When the current date falls between the 1st and 14th, the system returns the cut-off dates for the first half of the previous month (i.e., the 15th of the previous month) and the cut-off dates for the second half of the previous month (i.e., the 29th of the previous month). Taking April 10th as an example, the current date falls within the range of the 1st to the 14th. The system returns the 15th and 29th of the previous month (March), meaning the statistical period started on March 15th and the reporting deadline was March 29th. This means that when the school logs in on April 10th, the system informs it that it needs to report price data for the second half of March (March 15th to 29th).
[0028] 2. When the current date is between the 15th and 28th, the system returns the deadline for the second half of the previous month (i.e., the 29th of the previous month) and the deadline for the first half of the current month (i.e., the 15th of the current month). For example, if the school logs in on April 20th, the system returns the 29th of the previous month (March) and the 15th of the current month (April).
[0029] 3. When the current date is between the 29th and 31st, return the deadline for the first half of the current month (i.e., the 15th of the current month) and the deadline for the second half of the current month (i.e., the 29th of the current month). For example, if the school logs in on April 29th, the system will return the 15th and 29th of the current month (April).
[0030] Figure 2 The diagram shows the process of date calculation in the campus meal price monitoring system: Input any target date (TargetDate), and after rule judgment and special month processing, finally output the "statistical period start date" and "reporting deadline" (or related date objects) corresponding to that date.
[0031] The following is an explanation of the flowchart: 1. Entry Point and Initial Judgment Input target date TargetDate: The system retrieves the date to be calculated. Determine the TargetDay range: First, the date is divided into three regular intervals to determine the basic upper and lower half-month cycle: 1-14: In the first half of the month cycle.
[0032] 15-28: This period falls in the middle of the second half of the month.
[0033] 29-31: At the end of the month (the end of the second half of the month).
[0034] 2. Base Date Calculation (Branches A, B, C): Based on the initial range, calculate the preliminary base dates for "15th" and "29th". Branch A (1-14): Calculate the 15th and 29th of last month.
[0035] Branch B (15-28): Calculates the 29th of last month and the 15th of the current month.
[0036] Branch C (29-31): Calculates the 15th and 29th of the current month.
[0037] 3. Special Month Handling (Core Node): To handle the special cases of February having an irregular number of days (28 or 29 days) and January (involving the previous year's December), the process enters the getDateWithSpecialHandling (special handling date retrieval) module: Is this a special case in February? Yes (involving February): Branch 1: If it is not a leap year, special treatment is given for February with 28 days.
[0038] Branch 2: If it is a leap year, special treatment is given for February with 29 days.
[0039] No (not February, such as January): In special cases, March 1st represents February 29th (or the date is completed to the 29th according to the rules).
[0040] 4. Final calibration for leap years How to determine if it is a leap year? If so: Return to February 29th.
[0041] If not: Return to the 1st of the next month (or correct to the start of the next month, thereby correcting the date offset in February, which is a non-leap year).
[0042] 5. Final Output Set the date directly / Return the calculation result: Finally, generate the target date - 28 days or the corrected date using the calibrated date.
[0043] Finally, a DateMonth object is returned (i.e., encapsulated data containing the start month and end date information of the period), which can be used by subsequent price reporting, comparison, and alert modules.
[0044] This invention, through an algorithm involving three-interval segmentation and special corrections for leap years / February, solves the problem of misaligned reporting deadlines caused by alternating long and short months and fluctuating days in February. It ensures that the system accurately maps dates to the preset 15th / 29th monitoring period on any date (including January year-end processing and February leap year processing), guaranteeing the accuracy of data statistics.
[0045] Meanwhile, this embodiment of the invention also includes a semester boundary judgment step: the system maintains a semester start and end schedule and limits the reporting deadline to the current semester; if it exceeds the current semester, it automatically reverts to the previous semester for matching; price reporting is suspended during winter and summer vacations.
[0046] By introducing a semester timeline for strict constraints, invalid reporting during non-semester periods is effectively avoided, ensuring that price data is collected and statistically analyzed only within the effective teaching cycle. When the calculation results exceed the current semester's range, the system automatically reverts to the previous semester for matching. This achieves a high degree of adaptability between the price reporting cycle and the pace of teaching management, ensuring both the timeliness and compliance of the data, and automatically suspending reporting tasks during winter and summer vacations. This fundamentally solves technical pain points such as cross-semester data corruption, duplicate statistics, and invalid data entry, improving the overall data quality and operational efficiency of the monitoring system.
[0047] S102: Receive the menu price data submitted by the school before the reporting deadline, and perform data deduplication and storage based on menu identifier, school identifier and period information.
[0048] Specifically, the school submits the menu price data before the corresponding reporting deadline based on the reporting cycle calculated by the system. In this embodiment, the school administrator inputs the menu price information through a terminal device, including fields such as menu ID, price, upload cycle, and school ID.
[0049] After receiving the aforementioned price information, the system performs data deduplication and storage based on the dish ID, school ID, and period information. Specifically, the system first checks the database to see if there are price records for the same school, the same dish, and the same period. If they exist, the old record is deleted, and then the new record is inserted; if they do not exist, the new record is inserted directly. This "delete + insert" update upload mechanism ensures that only the latest price record is retained for each dish in each period for each school, avoiding data redundancy.
[0050] S103: Automatically compare the reported school prices with the corresponding period's preset guidance prices, calculate the price difference, and generate an excess indicator.
[0051] Specifically, while storing price data, the system automatically associates it with the corresponding pre-set guidance price for the corresponding period. In this embodiment, the guidance price is pre-configured by the education bureau in two monthly periods, with each period including two indicators: the average guidance price and the minimum guidance price. For example, the education bureau sets the average guidance price for "pork" at 30 yuan / kg for the first half of March 2026.
[0052] The system queries the corresponding guide price based on the dish ID and reporting period. After obtaining the guide price information, it calculates the difference between the school's price and the guide price using the formula: Excess Amount = School Price - Guide Price. If the excess amount is greater than 0, the excess flag is set to true; otherwise, it is set to false. For example, if a school reports a price of 35 yuan / kg for "pork" and the guide price is 30 yuan / kg, the excess amount is 5 yuan, and the excess flag is set to true. If the reported price is 28 yuan / kg, the excess amount is -2 yuan, and the excess flag is set to false. The system saves the price record, including price information, guide price information, excess amount, and excess flag, to the database.
[0053] S104: Generate an over-the-price warning based on the over-the-price identifier, and check schools that have not reported on time through a scheduled task and generate an unreported warning.
[0054] Specifically, when the exceedance flag is true, an exceedance warning record is constructed, which includes fields such as price information, school information, menu information, warning type (FOOD_PRICE_OVER_GUIDANCE), warning time, and warning status (e.g., pending).
[0055] Meanwhile, the system checks for existing duplicate alerts using multiple criteria, including school ID, month, dish ID, alert type, and alert status. If a duplicate alert exists, the alert record is updated; otherwise, a new alert record is created. This deduplication mechanism prevents the same price anomaly from triggering duplicate alerts.
[0056] In addition, the system generates unreported alerts via scheduled tasks. Specifically, the system is set to automatically trigger at midnight on the 16th of each month (the day after the reporting deadline for the first half of the month) and the 30th of each month (the day after the reporting deadline for the second half of the month). The scheduled tasks scan the price reporting status of all schools within the jurisdiction for the corresponding period. For schools that fail to report on time, an unreported alert record (FOOD_PRICE_UNCOMMIT) is generated. By automatically triggering scheduled tasks the day after the fixed reporting deadline, a unified scan and verification of the reporting status of all schools within the jurisdiction is performed. This achieves fully automated, comprehensive, and real-time alerts for unreported behavior, completely replacing manual checks, significantly improving the timeliness and coverage of supervision, effectively avoiding regulatory blind spots caused by missed or delayed reporting, and ensuring the standardized implementation of price reporting procedures.
[0057] S105: When price data or guidance price changes, automatically recalculate the out-of-state status and synchronously update the status of the corresponding warning record; Specifically, the system monitors price changes in real time, retrieves original price records, and receives updated prices. There are two scenarios that trigger automatic handling of alert status: 1. When a school modifies the uploaded raw material price, the system responds by modifying the reported price data, recalculating the excess amount, and determining whether it exceeds the guidance price. For example, a school changes the price of "pork" from 30 yuan / kg to 28 yuan / kg. The system receives the updated price, recalculates the excess amount, and finds that the excess flag changes from true to false. The system automatically queries the guidance price exceedance warning record associated with this price record and updates its warning status to "processed".
[0058] 2. After the Education Bureau adjusts the guidance price, the system responds by automatically updating the price records of all schools referencing that guidance price, recalculating the excess status of each school and updating the warning record information accordingly, recalculating the excess amount, and determining whether it exceeds the guidance price. For example, the Education Bureau adjusts the guidance price for "pork" from 30 yuan / kg to 32 yuan / kg. The system asynchronously synchronizes the price records of all schools referencing that guidance price and recalculates the excess status of each school. If a school's original price was 35 yuan / kg, and the original excess indicator was true, the excess amount under the new guidance price of 32 yuan / kg would be 3 yuan, still exceeding the guidance price, and the warning status would remain unchanged. If another school's original price was 31 yuan / kg, and the original excess indicator was true (because it was higher than 30 yuan), the excess amount under the new guidance price of 32 yuan / kg would be -1 yuan, and the excess indicator would become false, then the corresponding warning status would be automatically updated to "processed".
[0059] The system compares price status changes. When the price changes from exceeding the limit to not exceeding the limit, the system automatically queries relevant warning records. The query conditions include price record ID, warning type, and warning status, and updates the warning status to "processed." When the price changes from normal to exceeding the limit, the system automatically generates a new warning record. The system saves the updated price record, including the updated price, the amount exceeding the limit, the exceeding indicator, and the update time.
[0060] S106: Aggregate price data from various schools by dish category level, and statistically analyze the distribution of schools exceeding the guidance price.
[0061] Specifically, in this embodiment, the menu dictionary adopts a two-level tree structure, where the parent level is the ingredient category and the child level is the specific ingredient; the parent level is the ingredient category (such as vegetables, meat, grains and oils), which is managed uniformly by the Education Bureau; the child level is the specific ingredient (such as cabbage, pork, rice), and each child level is associated with the corresponding parent level category through the parentId field.
[0062] When conducting price comparison analysis, the first step is to query all sub-level price data based on the upload period and the sub-level dish ID list, filtering out records where the price exceeds the guideline price (marked as true). Then, for each individual dish, the number of schools with the "exceeds the guideline price" flag is counted across all schools, yielding the number of schools exceeding the guideline price for each sub-level dish; that is, how many schools have prices exceeding the guideline price for the same dish. For example, if the price of "pork" exceeds the guideline price in 3 out of 10 schools within the jurisdiction, then the number of schools exceeding the guideline price for "pork" is 3.
[0063] The number of schools exceeding the price guidelines for each sub-category of dishes is further aggregated upwards to the corresponding parent-level food category. For example, the "Meat" category includes three sub-categories: pork, beef, and chicken, with 3, 2, and 1 schools exceeding the guidelines respectively. Therefore, the total number of schools exceeding the guidelines under the "Meat" category is 6 (or the details of each sub-category can be displayed according to actual statistical needs). Through this hierarchical aggregation, the education bureau can quickly identify which food categories have the most significant price exceedances, providing data support for regulatory decisions.
[0064] This invention, through a hierarchical aggregated statistical structure and a tree-like logic of parent-child classification, elevates the regulatory perspective from "individual dishes" to "major ingredient categories," achieving multi-dimensional data analysis from micro to macro levels. Its effect lies in clearly presenting the overpricing distribution of specific ingredients and further aggregating it to the major category level. This allows regulatory authorities to accurately identify abnormal dishes while also grasping the overall price risk situation of various ingredients, providing comprehensive, layered, and traceable data support for regulatory decisions and significantly improving the depth and efficiency of analysis.
[0065] The following example illustrates the implementation process of this embodiment: Assume that there are three schools, A, B, and C, under the jurisdiction of the Education Bureau of a certain city. On April 10th of a certain year, the administrator of school A logs into the system. The system obtains the current date, April 10th (which falls within the range of 1-14 days), and returns the 15th and 29th of the previous month (March) as the start date and reporting deadline of the statistical period, according to the rules. The system then prompts school A to report the price data for the second half of March (March 15th to 29th).
[0066] On April 12th, an administrator at School A reported the price of pork as 35 yuan / kg. The system received the price data, stored it, and automatically looked up the guidance price (the guidance price for pork in the second half of March was 30 yuan / kg). It calculated the excess amount as 5 yuan, set the excess flag to true, and generated an alert record for exceeding the guidance price.
[0067] In the early morning of April 16, a scheduled task was triggered, and a scan revealed that School B and School C had not reported price data for the second half of March. An alert record for non-reporting was generated for School B and School C respectively.
[0068] On April 20th, the Education Bureau discovered a rise in pork market prices and adjusted the guidance price for pork for the second half of March to 32 yuan / kg. The system asynchronously synchronized the price records of School A and recalculated: 35 yuan / kg was still higher than 32 yuan / kg, so the exceeding indicator remained true, and the warning status remained unchanged.
[0069] On April 25th, the administrator of School A changed the price of "pork" to 31 yuan / kg. The system recalculated: 31 yuan / kg is lower than 32 yuan / kg, the excess flag changed to false, and the corresponding warning record for exceeding the guidance price was automatically updated to "processed".
[0070] The education bureau administrator logged into the system to view the price statistics. The system aggregated the data by level and showed that the number of schools exceeding the guidance price under the "Meat" category was 0 (because School A has already corrected its price), and the prices of all schools now met the guidance price requirements.
[0071] Through the above steps, this embodiment realizes intelligent management of the entire process of campus meal price supervision.
[0072] Exemplary system: Figure 3 This is a schematic diagram of the intelligent monitoring system for campus meal prices provided in an embodiment of this application, as shown below. Figure 3 As shown: The cycle calculation module 301 is used to obtain the current date and determine the start date and end date of the statistical cycle corresponding to the price reporting cycle of the current date according to the preset cycle division rules and reporting deadline rules. The price reporting module 302 is used to receive the menu price data submitted by the school before the reporting deadline, and to perform data deduplication and storage based on menu identifier, school identifier and period information; The price comparison module 303 automatically compares the reported school prices with the corresponding period's preset guidance prices, calculates the price difference, and generates an excess indicator. The early warning generation module 304 is used to generate an early warning of exceeding the guidance price based on the exceeding identifier, and to check schools that have not reported on time through a scheduled task and generate an early warning of non-reporting. The early warning update module 305 is used to automatically recalculate the out-of-state status and synchronously update the status of the corresponding early warning record when the price data or guidance price changes. The statistical output module 306 is used to aggregate price data from various schools by dish category level and to statistically analyze the distribution of schools that exceed the guidance price.
[0073] In one or more embodiments of this application, the cycle division rule in the cycle calculation module 301 is as follows: each month is divided into a first half-month cycle and a second half-month cycle, wherein the first half-month cycle corresponds to the 1st to the 14th of each month, and the second half-month cycle corresponds to the 15th to the last day of the month; the reporting deadline rule is as follows: the 15th of each month is the reporting deadline for the first half-month cycle, and the 29th of each month is the reporting deadline for the second half-month cycle. In one or more embodiments of this application, the period calculation module 301 determines the start date and end date of the statistical period corresponding to the price reporting period for the current date, including: If the current date is between the 1st and the 14th, return the deadlines for the first half and second half of the previous month; If the current date is between the 15th and 28th, return the deadline for the second half of last month and the deadline for the first half of the current month; If the current date is between the 29th and 31st, return the deadlines for the first half and second half of the current month.
[0074] In one or more embodiments of this application, a semester boundary determination step module is further included, used for: Get the semester timetable, which includes the start and end dates of the semester; The calculated reporting deadline must fall within the current semester's timeframe; If the calculation result is not within the range of the current semester, it will automatically fall back to the range of the previous semester for matching; Price reporting will be suspended during winter and summer vacations.
[0075] In one or more embodiments of this application, the method for generating unreported warnings in the warning generation module 304 includes: setting a timed task to be automatically triggered on the day after the reporting deadline for the first half of each month and the day after the reporting deadline for the second half of each month, scanning the price reporting status of all schools in the jurisdiction during the corresponding period, and generating unreported warning records for schools that have not reported.
[0076] In one or more embodiments of this application, an update module is further included, configured to: In response to the school modifying the reported price data, recalculate the excess amount and update the excess label; In response to regulatory adjustments to guidance prices, update relevant price records and recalculate the excess status; When the price status changes from exceeding to not exceeding, the corresponding warning record status will be automatically updated to processed. When the error rate changes from never exceeding the limit to exceeding the limit, a new warning record is automatically generated.
[0077] In one or more embodiments of this application, the statistical output module 306 includes: The dish category unit is used to classify dishes using a two-level tree structure, where the parent level is the ingredient category and the child level is the specific ingredient; The sub-level dish statistics module is used to count the number of school records where each dish exceeds the true mark across all schools, based on the dimension of a single dish, and obtain the number of schools where each sub-level dish exceeds the mark. The school total count unit is used to aggregate the number of schools exceeding the guide price for each sub-level dish to the corresponding parent-level ingredient category, thus obtaining the total number of schools exceeding the guide price under each ingredient category.
[0078] The system provided in this application embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.
[0079] In one embodiment, Figure 4 The layered architecture diagram of the intelligent monitoring system for school meal prices fully demonstrates the end-to-end technical architecture from user interaction to data storage. Specifically: 1. A_Front-end layer (user interaction entry point) Education Bureau Front-end: Used by regulatory authorities for configuring guidance prices, viewing early warnings, and statistically analyzing the distribution of schools exceeding price limits.
[0080] School front-end: Used by the school cafeteria to report food price data before the deadline.
[0081] Function: As the human-computer interaction entry point of the system, it undertakes the operation needs of two types of users and is the starting point and result display end of the entire supervision process.
[0082] 2. B_Interface Layer (Bridge between front-end and back-end interaction) EduGuidancePriceController (Guidance Price Management Interface): Connects to the education bureau's front-end to handle operations such as adding, deleting, modifying, querying, and adjusting guidance prices.
[0083] EduItemWarnController (Alert Management Interface): Connects to two types of front-ends to handle alert viewing, status updates, push notifications, and other operations.
[0084] EduFoodPriceController (Price Management Interface): Connects to the school's front-end to handle operations such as reporting, modifying, and querying price data.
[0085] Function: To encapsulate business requests, decouple the front-end and back-end, and forward front-end operations to the back-end business logic layer.
[0086] 3. C - Business Logic Layer (The Core Brain of the System) EduGuidancePriceService: Handles the business logic of guidance prices, including period matching, price synchronization, and change triggering.
[0087] EduFoodPriceWarnService (Alert Service): The core alert logic, generating overprice alerts, unreported alerts, and handling alert status updates.
[0088] EduFoodPriceService: The core pricing business, handling price reporting, deduplication and storage, comparison calculation, etc.
[0089] EduTimeConfigService (Time Configuration Service): Configures time rules such as cycle division, reporting deadline, and semester schedule, providing a time benchmark for the entire system.
[0090] PriceUtils (Pricing Utility Class): Encapsulates common utility methods for various services to call, improving code reusability.
[0091] Function: It carries all the core business logic of the system and is the central hub connecting the interface layer, algorithm layer, and data layer.
[0092] 4. D Core Algorithm Module Intelligent time rule calculation: Implements periodic calculation logic, automatically matching the statistical period and end date based on the current date.
[0093] Periodic query range conversion: Maps the reported date to the corresponding query range to solve the problem of querying data across months.
[0094] Automatic early warning generation: Enables scheduled early warnings and automatically generates unreported early warnings.
[0095] Price comparison analysis: Automatically compares the price with the guide price and generates an excess indicator.
[0096] Excess Amount Calculation: Enables accurate calculation of excess amount, providing data support for early warning.
[0097] Function: It transforms the core inventive concepts of this application (periodic rules, early warning, comparison, statistics) into executable algorithms, which is the core of system intelligence.
[0098] 5. E-Data Access Layer (Data Read / Write Intermediate Layer) EduFoodPriceMapper (Price Table Mapper): Operates on the price table, handling the addition, deletion, modification, and query of price data.
[0099] EduGuidancePriceMapper (Guidance Price Mapper): Operates on the guidance price table, handling the storage and updating of guidance prices.
[0100] EduFoodPriceWarnMapper (Warning Table Mapper): Operates on the warning table, handling the generation and status update of warning records.
[0101] EduFoodPriceDictMapper (Dishes Dictionary Mapper): Operates on the dishes dictionary table and maintains a two-level tree-structured dish classification.
[0102] Function: Encapsulate database operations, decouple business logic from data storage, and ensure the standardization of data reading and writing.
[0103] 6. F_Data Storage Layer (Data Persistence) Price list: Stores the menu price data reported by schools, including menu ID, school ID, cycle, price, etc.
[0104] Price Guide: This list contains the official guide prices for each storage period and each dish, serving as a benchmark for price comparison.
[0105] Warning Table: Stores all overprice warnings and unreported warning records, including warning status, trigger time, etc.
[0106] Menu dictionary table: Stores two-level tree-structured menu categories (parent ingredient category, child specific ingredients), providing data support for hierarchical statistics.
[0107] Function: To persist all core data of the system and provide a data foundation for the entire business process.
[0108] By dividing the system into six independent layers—front-end, interface, business logic, core algorithm, data access, and data storage—the responsibilities of each layer are clearly defined. The front-end layer is only responsible for user interaction, the business logic layer focuses on core business processing, and the data access layer encapsulates database operations. The layers communicate with each other through standardized interfaces. This loosely coupled architecture ensures that modifications or upgrades to any layer will not affect the entire system, reducing maintenance costs and change risks. While ensuring the accurate execution of campus meal price monitoring, it also considers the system's scalability, maintainability, and multi-platform adaptability, providing solid technical architectural support for intelligent campus meal price monitoring.
[0109] Exemplary device; Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device of this embodiment includes a processor 501 and a memory 502.
[0110] The memory 502 stores computer-executed instructions; the processor 501 executes the computer-executed instructions stored in the memory to implement the various steps performed by the electronic device in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.
[0111] Alternatively, the memory 502 can be either standalone or integrated with the processor 501.
[0112] When the memory 502 is set up independently, the electronic device also includes a bus 503 for connecting the memory 502 and the processor 501.
[0113] Exemplary media and products: This application also provides a computer storage medium storing computer execution instructions. When the processor executes the computer execution instructions, the above-mentioned intelligent monitoring method for campus meal prices is implemented.
[0114] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the above-described intelligent monitoring method for campus meal prices.
[0115] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.
[0116] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.
[0117] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.
[0118] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.
[0119] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.
[0120] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.
[0121] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0122] The aforementioned storage medium can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to a general-purpose or special-purpose computer. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.
[0123] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A method for intelligent monitoring of campus meal prices, characterized in that, The method includes: Obtain the current date, and determine the start date and end date of the statistical period corresponding to the price reporting period for the current date based on the preset period division rules and reporting deadline rules; Receive the menu price data submitted by the school before the reporting deadline, and perform data deduplication and storage based on menu identifier, school identifier and period information; The system automatically compares the reported school prices with the corresponding pre-set guidance prices for the period, calculates the price difference, and generates an excess indicator. Based on the aforementioned exceedance identifier, an over-guidance price warning is generated, and a non-reporting warning is generated by checking schools that have not reported on time through a scheduled task; When price data or guidance price changes, the status of the out-of-state condition is automatically recalculated and the status of the corresponding warning record is updated synchronously. Price data from various schools is aggregated by category and level, and the distribution of schools exceeding the guidance price is statistically analyzed.
2. The method according to claim 1, characterized in that, The cycle division rule is as follows: each month is divided into a first half-month cycle and a second half-month cycle, where the first half-month cycle corresponds to the 1st to the 14th of each month, and the second half-month cycle corresponds to the 15th to the last day of the month; the reporting deadline rule is as follows: the 15th of each month is the reporting deadline for the first half-month cycle, and the 29th of each month is the reporting deadline for the second half-month cycle.
3. The method according to claim 2, characterized in that, The determination of the statistical period start date and reporting end date corresponding to the price reporting period for the current date includes: If the current date is between the 1st and the 14th, return the deadlines for the first half and second half of the previous month; If the current date is between the 15th and 28th, return the deadline for the second half of last month and the deadline for the first half of the current month; If the current date is between the 29th and 31st, return the deadlines for the first half and second half of the current month.
4. The method according to claim 1, characterized in that, It also includes the steps for determining the semester boundary: Get the semester timetable, which includes the start and end dates of the semester; The calculated reporting deadline must fall within the current semester's timeframe; If the calculation result is not within the range of the current semester, it will automatically fall back to the range of the previous semester for matching; Price reporting will be suspended during winter and summer vacations.
5. The method according to claim 1, characterized in that, The method for generating the unreported warning includes: setting a scheduled task to be automatically triggered on the day after the reporting deadline for the first half of the month and the day after the reporting deadline for the second half of the month, scanning the price reporting status of all schools in the jurisdiction for the corresponding period, and generating unreported warning records for schools that have not reported.
6. The method according to claim 1, characterized in that, The automatic recalculation of the out-of-state status and synchronous update of the corresponding warning record when price data or guidance price changes includes: In response to the school modifying the reported price data, recalculate the excess amount and update the excess label; In response to regulatory adjustments to guidance prices, update relevant price records and recalculate the excess status; When the price status changes from exceeding to not exceeding, the corresponding warning record status will be automatically updated to processed. When the error rate changes from never exceeding the limit to exceeding the limit, a new warning record is automatically generated.
7. The method according to claim 1, characterized in that, The aggregation of price data from various schools by menu category and the statistical analysis of the distribution of schools exceeding the guidance price include: The dishes are categorized using a two-level tree structure, where the parent level is the ingredient category and the child level is the specific ingredient. By counting the number of school records where each dish exceeds the true mark across all schools, we can obtain the number of schools that exceed the mark for each sub-dish. Aggregate the number of schools exceeding the guide price for each sub-category dish to the corresponding parent ingredient category to obtain the total number of schools exceeding the guide price under each ingredient category.
8. A smart monitoring system for campus meal prices, characterized in that, include: The cycle calculation module is used to obtain the current date and determine the start date and end date of the statistical cycle corresponding to the price reporting cycle for the current date based on the preset cycle division rules and reporting deadline rules. The price reporting module is used to receive the menu price data submitted by the school before the reporting deadline, and to perform data deduplication and storage based on menu identifier, school identifier and period information; The price comparison module automatically compares the reported school prices with the corresponding period's preset guidance prices, calculates the price difference, and generates an excess indicator. The early warning generation module is used to generate an early warning for exceeding the guidance price based on the exceeded identifier, and to check schools that have not reported on time through a scheduled task and generate an early warning for not reporting. The early warning update module is used to automatically recalculate the out-of-state status and synchronously update the status of the corresponding early warning record when the price data or guidance price changes. The statistics output module is used to aggregate price data from various schools by dish category level and to statistically analyze the distribution of schools that exceed the guidance price.
9. An electronic device, characterized in that, include: At least one processor; The system also includes a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform the intelligent monitoring method for campus meal prices as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the intelligent monitoring method for campus meal prices as described in any one of claims 1 to 7.