A student nutrition meal management system and method

Abstract

The application discloses a student nutrition meal management system and method, and particularly relates to the technical field of student meal management, and is used for solving the problem that in the existing student centralized meal management, the quantity meal recipe only reflects the planned supply quantity, the meal taking record is difficult to reflect the actual intake deviation caused by temporary dish changing, less taking, not taking and dish remaining, and the nutrition supply deviation in continuous meals is difficult to track, compensate and write back in a closed loop. By establishing a meal state account book and locking the quantity meal recipe version, combining the meal taking state and effective intake state to generate a compensation queue, and then generating a compensation meal arrangement strategy according to the next meal menu, inventory quantity, meal serving window capacity and compensation boundary table and writing back the meal state account book, the planned supply, actual meal taking, dish remaining and cross-meal compensation are included in the same closed loop, and the problem that the actual intake deviation is difficult to track and compensate is reduced.

Description

Technical Field

[0001] This invention relates to the field of student dietary management technology, specifically to a student nutrition dietary management system and method. Background Technology

[0002] As school centralized meal management becomes increasingly information-based, canteen management systems typically manage meal plans, portion-rate menus, student identification, window service, and post-meal statistics. Current methods generally involve determining the planned dishes, portions, and quantities for a given meal based on student numbers, class rosters, meal schedules, and portion-rate menus before meal service. During meal service, student meal collection is recorded using campus cards, facial recognition terminals, meal code terminals, window service terminals, electronic scales, or quantitative dispensing equipment. Some schools also incorporate nutritional records, student meal nutrition standards, window service schedules, and inventory records into the system to compile and summarize data on food supply, nutritional provision, meal preparation consumption, and meal collection. These methods meet basic management needs such as meal plan development, identification verification, meal collection registration, inventory reconciliation, and post-meal report generation.

[0003] However, in actual centralized meal service settings, discrepancies often exist between the meal plan and students' actual intake. Quantity-based menus typically reflect the planned supply established before meal service, but they cannot directly reflect whether students actually received their meals at the window, whether the actual amount received was less than the planned amount, or changes in supply due to temporary changes in dishes at the window, insufficient food supply, or students taking less or not taking any food. While meal collection records can record student identity, the window where the food was served, and the food received, they usually only record "meal taken" or "food received," making it difficult to further link to the types and quantities of leftover food returned after meals. For situations where the same planned dish is served at multiple windows, the same student temporarily changes dishes, or there are leftover dishes or mixed leftovers on the same plate, relying solely on existing meal collection records or post-meal summary reports is insufficient to establish an effective intake status that can be directly compared to the planned supply benchmark.

[0004] Furthermore, existing student meal management systems often treat meal planning, meal collection records, returned plate statistics, and nutritional analysis as relatively independent management links, lacking a status connection indexed by the same student, the same meal, the same version of the meal plan, and the same planned dishes. When a meal results in under-collection, non-collection, temporary substitution, or returned plate residue, even if the system can detect statistical discrepancies after the meal, it is difficult to determine whether the discrepancy stems from uncollected planned dishes, insufficient portions collected, insufficient deductions from substituted dishes, or excessive leftovers. It is even more difficult to translate these discrepancies into compensatory meal arrangements for subsequent meals. Consequently, it is difficult to continuously collect, track, compensate, and record dietary deviations for students or classes across consecutive meals, causing meal plan management to remain at the level of meal planning and post-event statistics, failing to effectively support closed-loop management of dietary deviations in continuous school meal service scenarios. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the present invention provides a student nutrition diet management system and method to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a student nutrition diet management method, comprising: S1. Establish a dietary status ledger according to student ID, class ID, meal number, and recipe version with quantity, and record the planned dishes, planned portions, nutritional conversion values, serving windows, and remaining inventory. S2. Before serving meals, lock in the version of the menu with quantity, and supply the meal plan based on the nutritional standards of student meals, the list of allowed substitute dishes, and the compensation boundary table. S3. During the food collection stage, collect the identity verification record, window food dispensing record, actual food items collected, actual food portion size collected, and temporary replacement food record, and write them into the food collection status. S4. Collect the category and quantity of food returned after the meal, and subtract the remaining quantity from the returned plate from the actual amount of food taken in the meal taking state to generate an effective intake state. S5. Compare the effective intake status with the planned supply baseline, generate deviation items, deviation sources, amount to be compensated, and compensation priority, and write them into the compensation queue. S6. Generate a compensation meal distribution strategy based on the compensation queue, next meal menu, next meal inventory, next meal service window capacity, and compensation boundary table. After the compensation meal distribution strategy is executed, write back the meal status ledger according to the meal pick-up results and the remaining plate return results.

[0007] Furthermore, S1 includes: When establishing a dietary status ledger, students are identified using their internal student codes from the student registration system. The class identifier is the class record in the class roster effective on the day the meal service is provided. The version of the recipe with quantities is the version number in the confirmed recipe with quantities record; The planned dishes are listed in detail according to the recipe version with quantities and the serving window; The planned portion size is written in grams; Nutritional conversion values ​​are derived from the nutritional records of planned dishes and dishes with planned portion sizes. Inventory balance refers to the amount of finished dishes available for distribution after food preparation is completed; The same student ID, meal number, recipe version with quantity, planned dishes, and serving window form a unique detailed index.

[0008] Furthermore, S2 includes: When locking the version of the quantity-based recipe before meals are served, the version of the quantity-based recipe in the meal status ledger is compared with the confirmed quantity-based recipe records by version number, confirmation time and effective meal number; After comparison and agreement, based on the student meal nutrition standard version and the cost meal plan supply benchmark, a list of allowed substitute dishes and a compensation boundary table are then formed. The planned supply benchmark, the list of allowed substitute dishes, and the compensation boundary table for this meal each form a unique detailed index.

[0009] Furthermore, S3 includes: When writing the meal pickup status, first read the already booked meal status ledger, the planned supply benchmark for this meal, and the list of allowed substitute dishes; The alignment should be based on student identification, meal number, recipe version with portion size, planned dishes, and serving window. After the identity verification record is matched with the student ID and meal number, it is linked to the meal dispensing record in the window. After the window food dispensing record is matched with the planned dishes and the food serving window, the actual dishes taken and the actual portion sizes are recorded. When the actual dishes served differ from the planned dishes, a temporary substitution record is created based on the list of permitted substitution dishes. The order pickup status is used to create a unique detailed index based on alignment criteria.

[0010] Furthermore, S4 includes: When a valid intake status is generated, the recorded status is read as completed and not listed as a pending verification status for meal pickup. The meal collection status details are located by student identification, meal number, recipe version with quantity, planned dishes, and serving window. The remaining categories of returned dishes should be confirmed within the scope of the actual dishes picked up according to the order status details. Write the remaining amount in grams after unloading. The effective intake is calculated by subtracting the amount of food left on the returned plate from the actual amount of food taken. Effective intake status is uniquely indexed by student identifier, meal number, recipe version with quantity, planned dishes, and serving window.

[0011] Furthermore, S5 includes: When generating the compensation queue, student ID, meal number, recipe version with quantity, planned dishes, and serving window are used as comparison indexes; Align the completed but not yet checked effective intake statuses with the planned supply baseline for this meal to form deviation items; The source of the deviation was determined based on the food collection status under the same comparison index and the post-meal return records formed by the category and quantity of returned plates. The difference between the planned supply baseline and the effective intake status forms the amount to be compensated; Generate compensation priorities based on the source of the deviation and the amount to be compensated; The compensation queue forms a unique queue index based on the comparison index and the deviation item, and the compensation queue record number is appended to the dietary status ledger as the reference field to be compensated.

[0012] Furthermore, S6 includes: When generating a compensation meal distribution strategy, read records whose status is pending compensation and which are not included in the compensation queue to be verified. Match the compensation queue records with the next meal menu, the next meal inventory balance, the next meal service window capacity, and the compensation boundary table; Within the scope of the compensation boundary table, the compensation dishes are determined according to the food categories corresponding to the deviation items, and a compensation meal preparation strategy is formed that includes the compensation dishes, the compensation portion size, and the compensation serving window.

[0013] Furthermore, S6 also includes: After the compensation meal distribution strategy is implemented, the meal collection result is bound to the compensation meal distribution strategy record number; The remaining results of returned dishes are linked to the compensation meal distribution strategy record number and the compensation meal supply window; The amount of food returned from the return process is subtracted from the actual amount of food taken from the food taking results to form the amount of compensation completed. The amount of compensation completed, the amount of compensation still pending, and the write-back status are appended to the pending compensation reference field in the dietary status ledger.

[0014] On the other hand, the present invention provides a student nutrition diet management system, comprising: The meal status ledger creation module is used to create meal status ledgers by student ID, class ID, meal number, and recipe version with quantity, and to record planned dishes, planned portions, nutritional conversion values, serving windows, and remaining inventory. The planned supply benchmark generation module is used to lock the quantity-inclusive recipe version before meals are served, and to generate the planned supply benchmark for each meal, the allowed substitute dish table, and the compensation boundary table based on the student meal nutrition standards. The food collection status writing module is used to collect identity verification records, window food dispensing records, actual food items collected, actual food portion sizes collected, and records of temporarily replaced dishes during the food collection stage, and write them into the food collection status. The effective intake status generation module is used to collect the category and quantity of food left after the meal, and to subtract the remaining quantity from the returned plate from the actual amount of food taken in the meal taking status to generate the effective intake status. The compensation queue generation module is used to compare the effective intake status with the planned supply baseline, generate deviation items, deviation sources, amount to be compensated, and compensation priority, and write them into the compensation queue. The compensation meal preparation and write-back module is used to generate compensation meal preparation strategies based on the compensation queue, the next meal menu, the next meal inventory, the next meal service window capacity, and the compensation boundary table. After the compensation meal preparation strategy is executed, it writes back the meal status ledger according to the meal pick-up results and the remaining plate return results.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By establishing a dietary status ledger based on student identification, class identification, meal number, and the version of the quantified menu, and locking the quantified menu version before meal service, and combining the meal collection status formed during the meal collection stage and the effective intake status formed after the meal, the effective intake status is compared with the planned supply benchmark to generate deviation items, deviation sources, compensation amounts, and compensation priorities. Then, based on the compensation queue, the next meal menu, inventory balance, service window capacity, and compensation boundary table, a compensation meal matching strategy is generated. After execution, the dietary status ledger is updated according to the meal collection results and the results of returned plates. This achieves the effect of unifying planned supply, actual meal collection, dish replacement, returned plate surplus, and cross-meal compensation into a single closed loop of meal service management, avoiding the problem that the quantified menu only stays at the planning level and cannot reflect the actual intake deviation of students.

[0016] 2. By setting fixed sources, unique indexes, pending verification boundaries, pending supplementation boundaries, and append-based write-back rules for the quantity-based recipe version, planned supply benchmark, allowed substitute dish table, compensation boundary table, meal collection status, effective intake status, compensation queue, and compensation meal distribution strategy, and restricting the automatic inference and supplementation of student identification, planned dishes, planned portions, nutritional conversion values, inventory balance, returned plate remaining quantity, pending compensation quantity, and compensation completed quantity from being based on experience or historical records, the system achieves the effects of consistent meal records before and after, traceable sources of deviation, verifiable compensation execution, and traceable ledger status. This reduces the omission or double counting of temporary dish changes, under-collection, non-collection, and returned plate remaining quantities in continuous meal management. Attached Figure Description

[0017] Figure 1 A schematic diagram of the student nutrition and diet management system. Figure 2 A schematic diagram for creating a dietary status ledger; Figure 3 A schematic diagram for locking recipes with quantity and generating a baseline table; Figure 4 A schematic diagram illustrating the data collection and temporary replacement of meal pickup status records; Figure 5 This diagram illustrates the deduction of remaining food items after return and the effective intake status. Figure 6 A schematic diagram showing the generation and compensation queue for deviation items; Figure 7 A diagram illustrating the closed loop of meal delivery strategy implementation and ledger writing. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: Combined with Appendix Figures 1-7 This embodiment provides a student nutrition diet management method, including: S1. Establish a meal status ledger based on student ID, class ID, meal number, and recipe version with portion size, recording planned dishes, planned portion sizes, nutritional conversion values, serving windows, and remaining inventory. Specific implementation is as follows: After the meal plan for this meal is confirmed, the canteen management system establishes a meal status ledger. The meal status ledger forms the basic record of the meal plan according to student ID, class ID, meal number, and recipe version, and forms detailed rows according to the planned dishes. This step is completed on the meal plan page of the school canteen management system. The execution subject is the meal administrator. The time period is limited to after the recipe for this meal is confirmed and before the subsequent meal pick-up status is written. The meal status ledger that has been recorded can be read by subsequent steps according to the meal number and recipe version.

[0020] Student identification uses an internal student code generated by the student registration system. This code corresponds to a student who is eligible to dine within the current meal service area of ​​the school. The campus card account and facial recognition meal collection account are only used as a source of association verification and are not used as the main index of the meal status ledger. When creating a file, the student's enrollment status, meal service eligibility, and campus meal service area in the student registration system are compared. Only student identifications that match all three are entered into the ledger for this meal. If a student identification is missing, duplicated, expired, or has not obtained meal service eligibility, the student's record will be stopped from being processed and transferred to pending verification.

[0021] The class identifier is taken from the class roster in the academic affairs system that is effective on the meal service day. The class identifier corresponds to the class unit actually organized by the school for meal service. When creating the file, the student identifier is associated with the class roster to obtain the class identifier corresponding to the student on the meal service day. Class records that have been changed to other classes but have not been effective on the meal service day are not included in the merging. When a class identifier is missing, it can only be supplemented from the official class roster that is effective on the same meal service day. It cannot be inferred from historical consumption records or meal pick-up habit records.

[0022] The meal number is formed by the meal date, meal type, and campus meal batch. The meal type is limited to one of the actual centralized meal batches of breakfast, lunch, and dinner. The campus meal batch is used to distinguish the on-site arrangement of meal batches in different campuses of the same school or in the same campus. The meal number is generated when the meal plan is confirmed and does not change after it is generated, regardless of whether students actually pick up the meal. If the meal number is missing or inconsistent with the meal plan time, the ledger for this meal shall not be submitted.

[0023] The quantity-based recipe version is taken from the quantity-based recipe record confirmed by the catering unit. The quantity-based recipe version corresponds to the fixed record of the planned dishes, planned portions, ingredient composition and nutritional conversion method for this meal. When creating the file, the quantity-based recipe version in the confirmed state is read, and the version number, confirmer, confirmation time and effective meal are recorded. Only one quantity-based recipe version is allowed to be in the effective state for the same meal. The recorded record shall not be overwritten by the old version, and the original record shall not be silently modified. If a revision is necessary, a new quantity-based recipe version shall be added, and the original version shall be recorded in the new version.

[0024] The planned dishes are taken from the menu list in the recipe version with quantity control. The planned dishes correspond to the actual finished dishes prepared to be served at the serving windows. When creating the file, the planned dishes are read item by item according to the recipe version with quantity control, and the planned dishes are associated with the serving windows. When the same planned dish is served at multiple serving windows, a detailed line is formed for each serving window and is not merged into one line. If the planned dish name is missing, duplicated but the serving window cannot be identified, or does not appear in the recipe version with quantity control, the detailed line of the planned dish is moved to the pending entry.

[0025] The planned portion size is taken from the standard supply amount corresponding to each student in the version of the meal plan. The planned portion size in the meal status ledger is uniformly recorded in grams. When the original meal plan uses portions, bowls, or pieces for recording, it is converted to grams based on the standard weighing record confirmed by the catering unit on the day before filing. The conversion basis is also recorded together with the version of the meal plan. The planned portion size that has not been converted must not be written into the already recorded status, and must not be supplemented by the student's historical meal intake, the planned amount of adjacent meals, or human experience.

[0026] The nutritional conversion value is taken from the nutritional ledger of the recipe version with quantity. The nutritional conversion value is formed according to the planned dishes and planned portions. The recording scope is limited to the nutritional items corresponding to the planned dishes under the planned portion size in this meal. When creating the file, the nutritional ledger is matched with the planned dishes first, and then the nutritional conversion value of this meal is formed with the planned portion size. If the nutritional ledger is missing the corresponding planned dishes, the details line of the planned dishes will be transferred to pending entry. Dishes with similar names, historical dish records or individual student health information cannot be used as substitutes.

[0027] The meal service windows are taken from the canteen window scheduling records or class meal distribution point records. The meal service window corresponds to the on-site window number, floor location, or class meal pick-up point where students pick up the planned dishes. When creating the file, the meal number, planned dishes, and meal service window are linked together. If the window is not in use, under maintenance, or not scheduled, it will not be recorded in the ledger for that meal. When the window is temporarily adjusted, the last confirmed window scheduling record before the meal service shall prevail.

[0028] The remaining inventory is taken from the confirmed record of the amount of finished dishes available for distribution after meal preparation is completed. The remaining inventory corresponds to the number of dishes in this meal plan that can continue to be distributed to students at the corresponding serving window, and the unit is uniformly grams. When creating the file, only the remaining inventory that has been weighed and confirmed before serving or confirmed by the meal preparation and delivery slip is recorded. The quantity of subsequent meals is not deducted in advance. If the remaining inventory is missing, is negative, is inconsistent with the meal preparation and delivery slip, or has not been confirmed by the meal administrator, the details of the dishes in this plan will be transferred to pending verification.

[0029] The above field organization is performed in the following order: student ID, class ID, meal number, recipe version with quantity, planned dishes, planned portion size, nutritional conversion value, serving window, and remaining inventory. First, the meal plan for this meal is collected by meal number, then confirmed records are filtered by recipe version with quantity, then class ID is associated with student ID, and finally, planned dishes, planned portion size, nutritional conversion value, serving window, and remaining inventory are written as detailed rows. During the organization process, blank student IDs, invalid class IDs, and ineffective recipe versions with quantity are removed first, then planned dishes that do not belong to this meal are removed, and finally, only fields that can be directly obtained from official student records, official class rosters, confirmed recipe versions with quantity, and confirmed window scheduling records are supplemented.

[0030] Student identification, recipe version with quantity, planned dishes, planned portion size, nutritional conversion value, and remaining inventory should not be automatically inferred and supplemented. If any information is missing, it should be entered as pending verification or pending supplementation.

[0031] When submitting the meal status ledger, at least the student ID, class ID, meal number, recipe version with portion size, planned dishes, planned portion size, nutritional conversion value, serving window, remaining inventory, and submitter code should be included. The system will then return the ledger record number, the status of the entry, the reason for pending verification, and a list of fields to be added. The same student ID, the same meal number, the same recipe version with portion size, the same planned dishes, and the same serving window will form a unique detailed index. If the indexes are completely identical and the field contents are identical, the initial entry result will be retained. If the indexes are identical but the field contents are inconsistent, the old record will not be overwritten and will be transferred to pending verification.

[0032] When deduplicating, first remove duplicate student records by student ID and meal number, then remove duplicate detail rows by planned dishes and serving windows. When the same planned dish is distributed in different serving windows, retain different detail rows.

[0033] The evidence chain is limited to the source records and submission actions encountered in this step, including the time of student registration, the time of class roster, the time of confirmation of the quantity-based recipe, the time of confirmation of window scheduling, the time of confirmation of inventory balance, the submitter code, the ledger record number, and the version succession relationship. The recorded content cannot be deleted, only corrections can be added.

[0034] The security boundary is limited to fields necessary for meal management. The meal status ledger does not include ID number, home address, contact information, disease diagnosis, medical examination results, or family economic situation. Authorized personnel can only view meal records within the scope of their meal service responsibilities.

[0035] The meal status ledger is stored in the meal ledger database of the canteen management system. Only the detailed rows that are recorded and not listed as pending verification or supplementary entry can be called by the next step according to the meal number and the version of the recipe with quantity.

[0036] Preferably, a school establishes a meal status ledger 30 minutes before lunch service on June 17, 2026. Student identifiers are derived from the internal student codes in the student registration system, class identifiers are derived from the class roster effective at 7:00 AM that day, meal number is "20260617 Lunch Main Campus First Batch," and the recipe version is "20260617 Lunch Version 1." The planned dishes are rice, scrambled eggs with tomatoes, and stir-fried seasonal vegetables, with planned portions of 150g, 120g, and 100g respectively. The nutritional conversion value is generated from the nutritional ledger associated with this version of the menu. The meal service window is window number 2, with remaining inventory of 45,000 grams, 36,000 grams, and 30,000 grams respectively. The system completes the accounting for 1,200 students within 20 seconds. If the system submits the data twice, the same accounting record number is returned. When 60 detailed lines are randomly checked, the consistency rate of student identification, class identification, meal number, recipe version with quantity, planned dishes, planned portion, and meal service window is no less than 99%. If a detailed line with a missing nutritional conversion value is found, only that detailed line is moved to the pending entry stage, while the remaining complete detailed lines remain in the accounting status.

[0037] An alternative approach is that schools without electronic storage records can have their catering administrators enter the remaining inventory based on the weighing slips of the finished dishes after meal preparation. Schools without campus card records should still use the student identification codes within the student registration system to establish student identifiers. This alternative approach must not change the recording criteria for student identifiers, class identifiers, meal numbers, recipe versions with quantities, planned dishes, planned portions, nutritional conversion values, catering windows, and remaining inventory. It must also not change the order of entries in the meal status ledger, the unique detailed index, or the version inheritance relationship.

[0038] S2. Before meals are served, the version of the menu with quantities is locked in, and the supply benchmark for each meal is planned based on the student meal nutritional standards, the list of allowed substitute dishes, and the compensation boundary table. The specific implementation is as follows: After the meal status ledger is in the "accounted" state, the canteen management terminal locks the corresponding quantity-based menu version for this meal. This action occurs during the meal preparation verification period before the meal pick-up channel for this meal is opened, and is completed by the meal administrator on the meal preparation confirmation page of the canteen management system. The system reads the meal number, quantity-based menu version, planned dishes, planned portion size, nutritional conversion value, serving window, and remaining inventory from the meal status ledger, and also reads the student meal nutrition standard version approved by the school. The student meal nutrition standard version is saved according to the grade segment, meal type, food category, and nutritional items. The grade segment is obtained from the grade record corresponding to the class identifier, and is not obtained from the student's personal disease diagnosis, physical examination conclusion, or family information.

[0039] The version of the quantity-based recipe uses the version number already written in the meal status ledger. This version number corresponds to a fixed record of the planned dishes, planned portions, ingredient composition, and nutritional conversion values ​​for this meal. When locking, the quantity-based recipe version in the meal status ledger is compared item by item with the quantity-based recipe version confirmed by the catering unit. If the version number, confirmation time, and effective meal are all consistent, the version is marked as the locked version for this meal. If the version number is missing, the confirmation time is later than the opening time of the food collection channel, or there are multiple effective versions for the same meal, the generation of the planned supply benchmark for this meal is stopped, and the meal is transferred to the pending verification stage. The locked quantity-based recipe version cannot be rewritten in place. If a revision is necessary, only a new quantity-based recipe version can be added, and the original version that is inherited must be recorded.

[0040] The unit of measurement in the nutritional standards for student meals is locked along with the version of the nutritional standards for student meals. Energy items are measured in kilocalories, staple foods, vegetables, fruits, and meat, eggs, dairy and beans are measured in grams, protein, fat and carbohydrates are measured in grams, calcium and iron are measured in milligrams, and vitamin items are measured in milligrams or micrograms as recorded in the version of the standard. If the version of the standard, the grade level, the type of meal, or the unit of measurement is missing, it will not be supplemented by inferring from historical menus or records of adjacent meals. Instead, the corresponding meal or the corresponding detailed line will be transferred to the pending supplementation.

[0041] When setting the supply benchmark for the cost-based meal plan, the system uses the meal number, the locked recipe version with quantity, and the student meal nutrition standard version as boundaries. It reads the ledger details that have been recorded but not yet listed for verification or supplementation. A benchmark detail is formed by student identification, meal number, recipe version with quantity, student meal nutrition standard version, planned dishes, and serving window. The planned portion size, food category, nutritional conversion value, and inventory balance are recorded in this benchmark detail. When the same planned dish is served at different serving windows, a benchmark detail is formed for each serving window, and the inventory balance is not combined.

[0042] The supply baseline for this meal plan only records the planned supply scope for this meal and will not be changed based on meal pick-up records, returned plate records, or subsequent compensation records. If the planned dishes lack food categories, planned portions lack weight, nutritional conversion values ​​are missing, or inventory balances are missing, then this baseline detail will not be generated and will be transferred to the pending supplementary entry stage.

[0043] The list of dishes that can be replaced is generated after the planned supply baseline for this meal is completed. Each record starts with the original planned dishes and the original serving window, and is associated with the replacement dishes, replacement food categories, replacement portions, replacement serving windows, and the boundary where the replacement takes effect. Replacement dishes can only come from confirmed dishes within the locked recipe version with quantity, or from temporary meal preparation records that have been confirmed before the meal pick-up channel is opened. Dishes that have not been confirmed for preparation, have no remaining inventory, have no nutritional conversion value, or have no serving window cannot be written into the list of dishes that can be replaced.

[0044] The selection of substitute dishes should first be matched within the same food category. If there are no feasible substitute dishes in the food category to which the original planned dish belongs, only cross-category substitute relationships already listed in the student meal nutrition standard version or the school-approved substitute relationship can be read. Substitute relationships should not be automatically formed based on similar dish names, similar appearance of dishes, or historical substitute habits. The substitute portion size should take priority from the planned portion size of the original planned dish. If the student meal nutrition standard version or the school-approved substitute relationship lists the substitute weight separately, the substitute weight should be used. If the substitute weight is missing, the substitute relationship will be transferred to the pending entry.

[0045] The compensation boundary table is generated after the supply baseline for this meal plan is completed, and boundary rows are established according to food category and nutrition item. The food category boundary row uses the meal number, quantity-based recipe version, student meal nutrition standard version, food category and applicable meal type as the boundary, and the nutrition item boundary row uses the meal number, quantity-based recipe version, student meal nutrition standard version, nutrition item and applicable meal type as the boundary, respectively recording the lower limit, upper limit, continuous compensation frequency boundary and effective meal frequency boundary. The lower limit and upper limit are derived from the student meal nutrition standard version, and the continuous compensation frequency boundary and effective meal frequency boundary are derived from the school's approved meal management rules. If any boundary is missing, no default value is set, and it is not inferred from historical compensation records. The corresponding boundary row is transferred to the pending record.

[0046] The compensation boundary table only limits the scope of subsequent compensation strategies that can be used. It does not generate compensation meal planning strategies in this step and does not change the supply baseline of this meal plan.

[0047] The planned supply baseline uses student ID, meal number, recipe version with quantity, student meal nutrition standard version, planned dishes, and serving window as unique detailed indexes; the allowed substitute dishes table uses meal number, recipe version with quantity, original planned dishes, original serving window, substitute dishes, and substitute serving window as unique detailed indexes; in the compensation boundary table, the food category boundary row uses meal number, recipe version with quantity, student meal nutrition standard version, food category, and applicable meal type as unique detailed indexes, and the nutrition item boundary row uses meal number, recipe version with quantity, student meal nutrition standard version, nutrition item, and applicable meal type as unique detailed indexes.

[0048] When submitting repeatedly, records with identical unique detailed indexes and identical field contents will have their original record number returned. Records with identical unique detailed indexes but different field contents will not overwrite the original record and will be transferred to pending verification.

[0049] The recording order for this step is as follows: first, lock the recipe version with quantity, then the supply baseline for the regeneration cost meal plan, and then generate the table of allowed substitute dishes and the compensation boundary table; if any detail row fails, only that detail row is isolated, without interrupting other complete detail rows.

[0050] The system will write the locked time of the quantity-based recipe version, the version of the student meal nutrition standard, the planned supply benchmark record number, the record number of the allowed substitute dishes table, the record number of the compensation boundary table, the confirmer code, and the detailed reasons for failure into the meal benchmark database. The written content cannot be deleted, only correction records can be added.

[0051] Preferably, a school completes this step 25 minutes before the lunch pick-up channel opens on June 17, 2026. The version of the quantified menu is the first version of the lunch for June 17, 2026, and the version of the student meal nutrition standard is the spring 2026 version. The planned dishes of 150g rice, 120g scrambled eggs with tomatoes, and 100g stir-fried vegetables are written into the planned supply baseline for this meal. The 100g stir-fried vegetables can be associated with 100g garlic lettuce in the allowed replacement dish table. The compensation boundary table sets the lower limit of vegetable lunches to 100g, the upper limit to 150g, the boundary of consecutive compensation times to 2 times, and the boundary of effective meals to the next 3 meals. The system completes the baseline generation for 1200 students within 15 seconds. When 60 baseline details are randomly checked, the consistency rate of meal number, quantified menu version, student meal nutrition standard version, planned dishes, planned portion size, and serving window is not less than 99%.

[0052] An alternative approach is that schools that do not have an independent student meal nutrition standard database can provide a version of the student meal nutrition standard from the approved student meal plan. Schools that do not have temporary meal preparation records can only form a list of allowed substitute dishes from the locked recipe version. However, this alternative approach must not change the order in which the recipe version is locked, the planned supply basis for this meal, the list of allowed substitute dishes, and the compensation boundary table are formed, nor can it change the unique detailed index and recording scope of the three types of records.

[0053] S3. During the food collection stage, collect identity verification records, window food dispensing records, actual food items collected, actual food portion sizes collected, and records of temporarily replaced dishes, and write these records into the food collection status. The specific implementation is as follows: When students arrive at the food service window after the food collection channel for this meal session opens, the canteen management system collects the food collection stage record according to the on-site collection action. This action occurs from the opening of the food collection channel to the closing of the food collection channel, and the on-site location is the food service window, the class food collection point, or the meal distribution table. The execution is carried out by the window food service staff in cooperation with the canteen management system. The system first reads the meal status ledger that has been recorded, the planned supply benchmark for this meal session, and the list of allowed substitute dishes. The student identification, meal number, recipe version with quantity, planned dishes, and food service window are used as the alignment basis for food collection. Details of meal status ledgers that are not in the recorded state, details of planned supply benchmarks for this meal session that have not been generated, and details that are not in the food collection period for this meal session are not included in this step.

[0054] The identity verification record is taken from one of the authorized devices: campus card reader, facial recognition meal pickup terminal, meal pickup code terminal, or class meal pickup registration terminal. The identity verification record corresponds to the fact that the student's identity was confirmed at the meal pickup site for this meal. The record content includes student identity, meal number, confirmation time, confirmation device, and confirmation result. The student identity still uses the internal student code generated by the student registration system. The facial recognition meal pickup terminal only sends back the internal student code and confirmation result, and does not write the original facial image into the meal pickup status.

[0055] The system compares the identity verification record with the student ID, class ID, and meal number in the meal status ledger. If all three match and the confirmation time falls between the opening and closing of the meal pick-up channel for this meal, the system allows the registration of this meal pick-up to continue. If the student ID, class ID, meal number, student ID does not qualify for the meal, or the confirmation time is not within the meal pick-up time period for this meal, the system will not record the completed meal pick-up status and will create a record pending verification.

[0056] The window meal dispensing record is taken from the window meal dispensing terminal, electronic plate scale, meal dispensing scale, quantitative meal dispensing equipment, or the meal service personnel confirmation terminal. The window meal dispensing record corresponds to the on-site action of the meal dispensing window to the student for a dish that was originally planned. The record content includes the meal dispensing window, meal dispensing time, planned dish, meal service personnel code, and window confirmation result. The planned dish field records the originally planned dish corresponding to this dispensing action. The actual planned dish or the replaced dish dispensing on-site is written separately into the actual meal pick-up dish field. The system compares the window meal dispensing record with the meal dispensing window and planned dish in the planned supply benchmark for this meal. If the meal dispensing window and the planned dish are the same, the actual meal pick-up record continues to be collected. If the meal dispensing window is not in use, the meal dispensing window is not scheduled, or the meal dispensing window does not belong to the window corresponding to the planned dish, the window meal dispensing record is transferred to the pending verification stage.

[0057] The actual dishes picked up are determined by the dish confirmation information associated with the window's food dispensing record. This confirmation information comes from the dish name selected by the window staff at the terminal, the dish label scanning result, or the dish configuration record already bound to the food dispensing window. The actual dishes picked up must be planned dishes in the planned supply baseline for this meal, or substitute dishes corresponding to the same original planned dish in the allowed substitute dish list. If the dish name is missing, the dish label cannot be recognized, or the dish does not belong to the planned dishes and does not belong to the allowed substitute dish list, the dish will not be recorded as a dish picked up.

[0058] The actual portion size is taken from the standard portion size record confirmed by the electronic plate scale, serving scale, quantitative serving equipment, or window terminal. When recording the portion size, grams are used as the unit. When using weighing equipment, the tare weight of the plate or serving container bound before the meal is served is used first, and the gram value is recorded after the reading stabilizes. When using quantitative serving equipment, the gram value already bound to the planned supply benchmark or allowed substitute dishes list for the meal is read. When using portions, bowls, or individual servings, the locked gram value must be read first and then the gram value is written. It cannot be supplemented based on the experience of the serving staff, the students' historical portion size, or records of adjacent meals.

[0059] When the actual meal portion is determined, the system first associates it with the identity verification record, then with the window food dispensing record, then with the actual food items taken, and finally registers the corresponding gram value. The same student ID, the same meal number, the same recipe version with the same quantity, the same planned dishes, and the same food service window will form a meal collection status detail. If the card is swiped, the code is scanned, and the weight is weighed repeatedly under the same meal collection status detail, but no new window food dispensing record is formed and the actual food items and the actual meal portion do not change, the original on-site record will be retained and the completed meal collection status will not be written again.

[0060] Temporary replacement dish records are generated when the actual dishes taken differ from the planned dishes. The record includes the original planned dishes, the replacement dishes, the replacement portion size, the replacement serving window, and the basis for the replacement. The basis for the replacement must come from the list of permitted replacement dishes. If there is no corresponding replacement relationship for the same original planned dish, it cannot be directly written into the temporary replacement dish record based on the on-site instructions that have not been confirmed by the system. It must be transferred to the pending verification stage.

[0061] When the actual dishes taken are the same as the planned dishes, the temporary replacement dish record remains empty and does not affect the formation of the take-out status; the temporary replacement dish record only records the dish replacement that occurred during this take-out stage, does not change the planned supply benchmark for this meal, does not result in deduction of leftover dishes, and does not generate an effective intake status.

[0062] After the above-mentioned identity verification record, window food dispensing record, actual food dishes picked up, actual food portion size picked up, and temporary replacement food dish record are associated, the system writes them into the food collection status. The food collection status forms a unique detailed index with student ID, meal number, recipe version with quantity, planned dishes, and food service window. The record fields include identity verification record number, window food dispensing record number, actual food dishes picked up, actual food portion size picked up, temporary replacement food dish record number, record time, and record status.

[0063] If the unique detailed index is consistent and the field content is consistent, the record number of the first food pickup status will be submitted and returned repeatedly; if the unique detailed index is consistent but the actual food pickup dish, the actual food pickup portion, or the temporarily replaced dish record is inconsistent, the original food pickup status will not be overwritten and will be transferred to pending verification.

[0064] Meal collection status is stored in the meal collection status database of the canteen management system. Only meal collection statuses that are recorded as completed and not listed as pending verification can be read in subsequent post-meal stages according to student ID, meal number, recipe version with quantity, planned dishes, and serving window.

[0065] Preferably, after the first batch of lunch pick-up channels opened on June 17, 2026, a school collected the pick-up status. Students completed identity verification at window number 2 using their campus cards. The window's meal record corresponded to stir-fried vegetables, and the actual dish picked up was garlic lettuce. The temporary replacement dish record referenced the record in the allowed replacement dish list where 100 grams of stir-fried vegetables replaced 100 grams of garlic lettuce, and the actual portion size was recorded as 100 grams. The electronic plate scale recorded the gram value when the reading changed by no more than 3 grams in 2 consecutive seconds after tare. The system generated a pick-up status record number within 2 seconds. During the pick-up of 1200 students, the number of concurrent windows was 8. If a single pick-up status entry failed to be written, it was retried twice after a 3-second interval. If it still failed, it was transferred to the pending verification without interrupting other students' pick-up. When 60 pick-up status entries were randomly checked, the consistency rate of student identification, meal number, recipe version with quantity, actual dish picked up, and actual portion size was no less than 99%.

[0066] Alternative approaches include: schools without electronic meal scales can use quantitative meal dispensing equipment to provide the actual meal portions; schools without facial recognition meal collection terminals can use campus card readers to create identity verification records; and schools without food label scanning equipment can have window staff select the names of dishes already bound to the service window on the terminal. However, these alternative approaches must not alter the order in which identity verification records, window meal dispensing records, actual meal portions, and temporary replacement dish records are written into the meal collection status, the unit scope, the unique detailed index, and the boundaries to be verified.

[0067] S4. In the post-meal phase, collect the remaining categories and quantities of returned dishes, and subtract the remaining quantities from the returned dishes from the actual portion size taken in the meal taking status to generate an effective intake status. The specific implementation is as follows: After students finish their meals and return their trays, the cafeteria management system collects tray return records during the post-meal phase. This action occurs after the food collection channel closes and before the tray return channel closes. The location is the tray return station, the class tray collection point, or the cafeteria tray return weighing station. The system is executed by the tray return personnel in cooperation with the cafeteria management system. The system first reads the completed meal collection status and uses the student's identification, meal number, recipe version with portion size, planned dishes, serving window, actual dishes taken, and actual portion size as the basis for post-meal collection. Records that have not yet formed a completed meal collection status, are listed as pending verification, or whose meal number does not belong to the current post-meal phase are not included in this step.

[0068] The category of remaining dishes when returning plates is generated. The category of remaining dishes corresponds to the category of uneaten dishes on the plate that can be associated with the actual dishes taken under the same take-out status details. When recording, the name of the actual dishes taken and the food category to which the actual dishes taken belong are used. On-site, the personnel collecting the plates can select the category of remaining dishes at the plate return terminal, or the image recognition terminal that is bound to the list of dishes for this meal can provide candidates for the category of remaining dishes, which are then confirmed and written by the personnel collecting the plates.

[0069] The category of returned plate remnants can only be confirmed from the actual food items taken by the student in the current meal's pick-up status. It cannot be supplemented from other students' plates, the total remnants of the class, food items from adjacent meals, or unclaimed food items. When there are mixed remnants on the plate, only the portion that can be confirmed by the plate return personnel to belong to the actual food items taken under the same pick-up status detail will be registered as the category and quantity of returned plate remnants. When there are mixed remnants that cannot be confirmed to belong to the same pick-up status detail and will affect the deduction of the pick-up status detail, the pick-up status detail will not generate a valid intake status and will be transferred to pending verification.

[0070] Napkins, bones, packaging materials, disposable tableware, tableware residue, and non-food residue are not registered as leftover items when returning dishes.

[0071] The remaining amount of returned dishes is determined after the category of returned dishes is confirmed. The remaining amount of returned dishes corresponds to the remaining weight of the edible portion of the returned dish category confirmed during the dish return. The unit in the account is uniformly grams. When using a returned dish weighing station, the tare weight of the dish is deducted first, and then inedible items are removed or weighed in sections before recording the edible portion in grams. When using an image recognition terminal, the image recognition terminal only provides candidates for the category of returned dishes. The remaining amount of returned dishes is still based on the reading of the weighing equipment or the recorded and confirmed gram value corresponding to the volume and weight of the dishes that have been approved for this meal. When using centralized collection by class, each dish is still collected according to the student's identification or dish return registration, and is not evenly distributed to students according to the total remaining amount of the class.

[0072] The amount of food left on the returned plate must not exceed the actual amount of food taken under the same food taking status. If it exceeds this, the plate will not be automatically truncated, the effective intake status of that detail will not be generated, and the amount of food left on the returned plate and the corresponding food taking status will be transferred to pending verification. If the amount of food left on the returned plate is missing, the weighing equipment has not tare, the category of food left on the returned plate has not been confirmed, or the time of returning the plate is not within the post-meal collection period, the returned plate will not be recorded as a completed returned plate.

[0073] When deducting the remaining amount from the returned plate from the actual portion size in the meal pick-up status, the system locates the same meal pick-up status detail according to student ID, meal number, recipe version with portion size, planned dishes, and serving window. Within that detail, the remaining amount under the corresponding returned plate category is deducted based on the actual portion size, and the effective intake for that detail is obtained after the deduction. If there are multiple returned plate records with the same remaining plate category for the same actual meal pick-up dish, they are first merged into one returned plate remaining amount according to the record time and returned plate device number, and then the deduction is performed. For records that are scanned repeatedly, weighed repeatedly, and whose returned plate remaining category and returned plate remaining amount have not changed, only the first confirmed record is retained.

[0074] If the actual food taken differs from the planned food and there are records of temporary substitutions, the deduction will be based on the actual food taken in the food taking status, and cannot be deducted from the original planned food. If the tray return personnel confirm that there is no food left on the tray and the tray return record can be linked to the student's ID, the remaining amount of the returned tray in this detail will be recorded as 0 grams. If the tray is not returned, the returned tray cannot be linked to the student's ID, or there is visible food left on the tray but the category of food left left has not been confirmed, then this detail will not generate a valid intake status and will be transferred to pending verification.

[0075] Effective intake status is formed after deduction. Effective intake status corresponds to the student's meal management status after deducting the remaining amount after returning plates for this meal, the corresponding planned dishes, and the serving window. The recorded content includes student identification, meal number, recipe version with quantity, planned dishes, serving window, actual dishes taken, actual portion size taken, category of remaining plates after returning plates, remaining amount after returning plates, effective intake, formation time, and recording status. Effective intake status only represents the meal management result based on meal taking status and returning plate records. It does not represent medical absorption, nor does it introduce disease diagnosis, physical examination conclusions, or individual treatment recommendations.

[0076] The effective intake status is uniquely indexed by student ID, meal number, recipe version with portion size, planned dishes, and serving window. If the unique detailed index is consistent and the actual portion size, leftover category, and leftover quantity are consistent, the effective intake status record number generated the first time is resubmitted. If the unique detailed index is consistent but the leftover category or leftover quantity is inconsistent, the original record is not overwritten and is transferred to pending verification.

[0077] Effective intake status is stored in the effective intake status database of the canteen management system. Only effective intake statuses that are recorded as completed and not listed as pending verification can be retrieved in the next step according to student ID, meal number, recipe version with quantity, planned dishes, and serving window.

[0078] Preferably, after the lunch tray return channel of a school is opened on June 17, 2026, the school collects the return records. The student's identification shows that the actual food taken is garlic lettuce, and the actual portion size is 100 grams. The tray return staff confirms that the remaining type of the returned tray is garlic lettuce at the return terminal. After deducting the tare weight of the tray and removing inedible items, the return weighing station records the remaining amount of the returned tray as 35 grams. The system subtracts the remaining amount of 35 grams from the actual portion size of 100 grams to form an effective intake status of 65 grams. When the reading of the return weighing station changes by no more than 3 grams in 2 consecutive seconds, the gram value is recorded. A single effective intake status is written within 2 seconds. If the writing fails, it is retried twice after an interval of 3 seconds. If it still fails, it is transferred to the pending verification without interrupting the collection of other trays. When 60 effective intake statuses are randomly checked, the consistency rate of student identification, meal number, actual food taken, remaining type of returned tray, and remaining amount of returned tray is not less than 99%.

[0079] Alternative approaches include allowing school staff without image recognition terminals to select the remaining tray category at the tray return terminal, and allowing school staff without tray return weighing stations to use electronic scales with tare functions to collect the remaining tray quantity. However, these alternative approaches must not alter the remaining tray category, remaining tray quantity, actual portion size deduction, the order of formation of effective intake status, unit caliber, unique detailed index, or boundary to be verified.

[0080] S5. Compare the effective intake status with the planned supply baseline, generate deviation items, deviation sources, amounts to be compensated, and compensation priorities, and write them into the compensation queue. The specific implementation is as follows: After the effective intake status of a meal is established, the canteen management system compares it with the planned supply benchmark for that meal. This action occurs after the tray return channel is closed and before the next meal plan is confirmed. On-site, the meal administrator submits confirmation on the post-meal review page of the canteen management system. The system uses the planned supply benchmark for that meal as the comparison scope. It reads the planned dishes, planned portions, food categories, nutritional conversion values, and serving windows under the same meal number and the same quantity recipe version from the meal benchmark database. It reads the effective intake status records that are completed and not listed as pending verification from the effective intake status database. At the same time, it reads the completed meal pick-up status and the meal pick-up records pending verification under the same comparison index from the meal pick-up status database. It also reads the completed plate return records and the plate return records pending verification under the same comparison index from the post-meal plate return records. The system aligns the records using student ID, meal number, quantity recipe version, planned dishes, and serving window as comparison indexes. The meal pick-up status and post-meal plate return records are only used as the basis for determining the source of deviation and the boundary of pending verification, and do not change the already established effective intake status.

[0081] Details already listed in the planned supply benchmark as pending verification or supplementation will not be included in this step. Details with inconsistent recipe versions, inconsistent meal service windows, inconsistent planned dishes, or missing effective intake in the effective intake status will not be included in the comparison. When a field is missing, it will not be supplemented from historical meal times, adjacent student records, class averages, or manual experience.

[0082] Once the effective intake status aligns with the planned supply baseline, the system generates deviation items based on the details of the planned dishes. The smallest recording granularity for deviation items is the details that do not meet the planned supply standards under the same student ID, same meal number, same recipe version with the same quantity, same planned dishes, and same serving window. The corresponding food category and nutritional item affiliation are registered within the deviation item. Details where the effective intake reaches or exceeds the planned portion size do not generate deviation items. Details where the remaining amount after returning the plate exceeds the actual portion size, the effective intake is negative, or the actual dishes taken do not correspond to the planned dishes do not generate deviation items and are transferred to pending verification.

[0083] If the planned supply baseline contains details but no matching of completed effective intake status is found, and there are no pending meal collection records or pending plate return records for that detail, then the dishes in the planned menu will be considered deviation items. If the reason for not matching effective intake status is due to pending meal collection records or pending plate return records, then no deviation item will be considered, and the items will remain pending verification.

[0084] The source of deviation is determined based on the on-site records under the same comparison index. The record range is limited to sources of uncollected food, sources of under-collected food, sources of replacement food, and sources of remaining food. When there are details in the planned supply benchmark but no completed food collection status is matched, it is registered as a source of uncollected food. When the actual food collection amount is lower than the planned amount, it is registered as a source of under-collected food. When the actual food collection items are different from the planned items and there are records of temporary replacement items, it is registered as a source of replacement food. When the amount of food returned from the plate is greater than 0 grams, it is registered as a source of remaining food.

[0085] When the same deviation item meets multiple sources at the same time, the main deviation source is determined in the order of uncollected source, undercollected source, replaced source, and remaining source. The remaining sources are written into the auxiliary source field of the same deviation item and are not split into multiple compensation queue records. Situations that do not belong to the above four types of sources should not be automatically named as other sources and are transferred to pending verification.

[0086] The amount to be compensated is formed after the deviation item and the source of deviation are determined. The recording unit uses the grams, kilocalories, milligrams or micrograms in the planned supply benchmark of this meal. Grams, kilocalories, milligrams and micrograms are recorded separately and cannot be combined. When the same deviation item has both the amount to be compensated for in terms of the weight of the dish and the amount to be compensated for in terms of nutritional items, corresponding fields are formed separately and the record number of the same compensation queue is maintained. The amount to be compensated at the level of dish details is formed by the difference between the planned portion and the effective intake. The amount to be compensated under the source of no meal is formed by the planned portion of the dish in the plan. The amount to be compensated under the source of less meal and the source of remaining meal is formed by the difference between the planned portion and the effective intake. The amount to be compensated under the source of replacement is first calculated by deducting the planned portion of the original planned dish from the effective intake corresponding to the actual meal, and then the difference in nutritional items is recorded according to the same nutritional conversion caliber.

[0087] When a replacement dish lacks a nutritional conversion value, no compensation amount is generated at the nutritional item level; instead, it is transferred to the pending entry. If the compensation amount is less than or equal to 0, it is not written into the compensation queue. If the compensation amount for the dish's weight exceeds the planned portion size of the dish in the plan, it is not automatically truncated. If the compensation amount for a nutritional item exceeds the corresponding nutritional item value in the planned supply benchmark, it is not automatically truncated; both are transferred to the pending verification stage.

[0088] Compensation priority is generated after the amount to be compensated is formed, and the compensation priority is fixed as high, medium and low. Deviation items whose main source of deviation is the source of untaken food are registered as high-level; deviation items whose main source of deviation is the source of undertaken food and whose amount to be compensated reaches more than 50% of the corresponding planned portion are registered as high-level; deviation items whose main source of deviation is the source of undertaken food and whose amount to be compensated is less than 50% of the corresponding planned portion are registered as medium-level; deviation items whose main source of deviation is the source of replacement food are registered as medium-level; and deviation items whose main source of deviation is the remaining food are registered as low-level. If the same student ID has deviation items of the same food category in two consecutive completed meals before the current meal, the compensation priority of the current deviation item will be increased by 1 level, and high-level items will not be increased further.

[0089] The compensation priority only determines the order of items in the compensation queue; it does not generate a compensation meal matching strategy in this step, nor does it specify the dishes for the next meal.

[0090] The compensation queue is written after the deviation item, deviation source, amount to be compensated, and compensation priority are all completed. A single compensation queue record includes student ID, class ID, meal number, recipe version with quantity, planned dishes, serving window, deviation item, deviation source, amount to be compensated, compensation priority, formation time, and record status. The compensation queue uses student ID, meal number, recipe version with quantity, planned dishes, serving window, and deviation item as unique queue indexes. When the unique queue indexes are consistent and the deviation source, amount to be compensated, and compensation priority are consistent, the initial queue record number is returned. When the unique queue indexes are consistent but the above contents are inconsistent, the original record is not overwritten and is transferred to pending verification.

[0091] When writing to the compensation queue, the system first writes the deviation item, then the deviation source, followed by the amount to be compensated and the compensation priority, and finally submits the queue record status. If the writing fails, the comparison record and the reason for failure are retained, without interrupting the writing of other student records.

[0092] The compensation queue is stored in the compensation queue database of the canteen management system. Only queue records with a status of pending compensation and not listed as pending verification can be read in the next step according to student ID, meal number, quantity-based menu version, deviation item, and compensation priority. After the compensation queue is written, the system will append the compensation queue record number, deviation item, deviation source, amount to be compensated, compensation priority, and record status as reference fields to the meal status ledger. The appended content will not cover student ID, class ID, meal number, quantity-based menu version, planned dishes, planned portion size, nutritional conversion value, serving window, and inventory balance.

[0093] Preferably, after the lunch tray return channel of a school closes on June 17, 2026, a compensation queue is generated. A student's planned portion of stir-fried vegetables is 100 grams. The actual dish taken is garlic lettuce, and the actual portion taken is 100 grams. The remaining amount after returning the tray is 35 grams, and the effective intake is 65 grams. After comparison, the system generates the deviation item corresponding to the stir-fried vegetables. The food category is registered as vegetables, the main source of deviation is registered as the remaining source, the amount to be compensated is 35 grams, and the compensation priority is registered as low level. If the student has vegetable deviation items in the two consecutive completed meals before the current meal, the compensation priority is upgraded to medium level. The system completes the writing of the compensation queue for 1200 students within 10 seconds. When 60 queue records are randomly checked, the consistency rate of student identification, meal number, deviation item, deviation source, and amount to be compensated is not less than 99%.

[0094] An alternative approach is that schools without the capability to convert nutrition items can simply create deviation items under the planned menu and food category fields, without registering the nutrition item difference for the time being. However, this alternative approach must not change the relationship between the effective intake status and the planned supply benchmark, the generation of deviation items, the generation of deviation sources, the generation of compensation amounts, the generation of compensation priorities and the order of writing to the compensation queue, the unique queue index, and the boundary to be verified.

[0095] S6. Generate a compensation meal allocation strategy based on the compensation queue, next meal menu, next meal inventory, next meal service window capacity, and compensation boundary table. After the compensation meal allocation strategy is executed, write back the meal status ledger according to the meal pick-up results and returned plate results. The specific implementation is as follows: Before confirming the next meal plan, the canteen management system reads the compensation queue and generates a compensation meal distribution strategy that can be executed on-site for the next meal. This action occurs after the next meal's portion-weighted recipe version is locked and before the next meal pick-up channel is opened. On-site confirmation is made by the catering administrator on the meal distribution verification page of the canteen management system. The next meal is defined as the first executable meal after the original meal, within the valid meal boundary of the compensation boundary table, and with the portion-weighted recipe version already locked. If compensation cannot be executed for this meal due to insufficient inventory, insufficient capacity of the serving window, or the compensation amount not meeting the minimum single-distribution weight, the corresponding compensation queue record is retained as pending subsequent compensation and is not converted to compensated. The system reads queue records from the compensation queue database that are pending compensation and not listed as pending verification. The read content includes student ID, class ID, meal number, portion-weighted recipe version, planned dishes, serving window, deviation item, deviation source, amount to be compensated, and compensation priority. The system then matches the queue record with the next meal menu, inventory, serving window capacity, and compensation boundary table item by item.

[0096] The next meal menu is taken from the locked recipe version with quantity for the next meal, which corresponds to the planned dishes, planned portions, food categories, nutritional conversion values ​​and serving windows for the next meal. The next meal menu only uses the locked version. Unconfirmed dishes, temporarily added dishes that have not been confirmed, and dishes that have not been converted into nutritional values ​​cannot participate in the generation of the compensation meal strategy.

[0097] The remaining inventory is taken from the confirmed record of the amount of finished dishes available for distribution after the next meal preparation is completed, and the unit is uniformly grams; the system only reads the remaining inventory that has been weighed and confirmed at the corresponding serving window for the next meal, does not read the inventory in the raw material warehouse, and does not include dishes that have not yet been cooked, packaged, or confirmed for distribution in the available inventory.

[0098] The capacity of the catering windows is derived from the next meal catering window scheduling record and the window compensation distribution confirmation record. The record includes the number of students who can be compensated, the weight of the dishes that can be compensated, and the minimum weight of a single distribution. Windows that are not in use, not scheduled, or whose compensation distribution capacity has not been confirmed will not participate in the generation of compensation meal distribution strategies.

[0099] The compensation boundary table is taken from the meal benchmark database records corresponding to the original deviation items. The system reads the records according to food category, nutritional items, applicable meal type, lower limit, upper limit, continuous compensation number boundary, and effective meal boundary. When the queue record exceeds the effective meal boundary or has reached the continuous compensation number boundary, the queue record is transferred to pending verification. When the inventory is insufficient or the catering window capacity is insufficient, the queue record is retained for subsequent compensation and the reason for not generating the record is recorded.

[0100] When generating a compensation meal plan, the system first arranges the compensation queue according to compensation priority. Under the same compensation priority, the queue is arranged in order of the earliest formation time of the record. Then, the system searches for similar planned dishes in the next meal menu according to the food category corresponding to the deviation item. If similar planned dishes exist and the inventory, service window capacity, and compensation boundary table all meet the compensation requirements, the similar planned dishes are identified as compensation dishes. If similar planned dishes are insufficient, alternative dishes are only searched within the food categories or nutritional items allowed by the compensation boundary table. Substitution relationships cannot be automatically formed based on similar dish names, similar dish appearances, students' subjective preferences, or human experience.

[0101] The compensation meal distribution strategy record includes student ID, class ID, original meal number, original recipe version, deviation item, amount to be compensated, compensation priority, next meal number, compensation dish, compensation portion, compensation serving window, execution time period, and strategy status. The compensation portion must not exceed the amount to be compensated, remaining inventory, serving window capacity, and the upper limit allowed by the compensation boundary table. The compensation portion must be greater than 0 grams and reach the minimum single distribution weight in the serving window capacity. If the complete amount to be compensated cannot be met but the minimum single distribution weight can be reached, the compensation meal distribution strategy for this time will be generated according to the executable portion, and the unarranged portion will be retained in the compensation queue. If the minimum single distribution weight cannot be reached, the compensation meal distribution strategy for this time will not be generated and will be retained for subsequent compensation.

[0102] After the compensation meal distribution strategy is generated, the system will send the compensation meal distribution strategy record number, student ID, next meal number, compensation dishes, compensation portion size, and compensation meal distribution window to the corresponding meal collection terminal at the compensation meal distribution window. After the student completes identity verification for the next meal, the window staff will distribute the compensation dishes and compensation portion size, and a meal collection result will be generated during the execution process. The meal collection result is bound to the compensation meal distribution strategy record number, which is different from the normal meal collection status for the next meal. The record includes the student ID, next meal number, compensation dishes, actual meal portion size, compensation meal distribution window, and collection time. Records of incomplete identity verification, failure to go to the designated compensation meal distribution window, or actual meal portion size exceeding the compensation portion size will not be included in the completed meal collection result.

[0103] The system will collect the remaining plate results after the next meal. The remaining plate results will correspond to the remaining plate categories and quantities of the compensation dishes confirmed in the post-meal stage. The collection criteria will follow the rules for remaining plate categories and quantities. If the same dish exists in the regular menu of the next meal, the system will only associate the remaining plate results of the compensation portion with the compensation meal preparation strategy record number and the compensation meal service window. The remaining plate quantities corresponding to the regular meal will not be included in the compensation write-back.

[0104] When writing back to the meal status ledger after execution, the system locates the fields to be compensated in the meal status ledger using the student identifier, original meal number, original recipe version with portion size, deviation item, compensation queue record number, and compensation meal preparation strategy record number. Then, it subtracts the remaining amount from the returned plate from the actual portion size in the meal retrieval results to obtain the amount of compensation completed this time. If the amount of compensation completed this time is greater than 0 grams and less than the remaining amount to be compensated, it is written as partially compensated. If the amount of compensation completed this time reaches the remaining amount to be compensated, it is written as compensated. If the amount of compensation completed this time is equal to 0 grams and the meal retrieval results are completed, the corresponding field to be compensated continues to remain in the state of pending compensation. If the amount of compensation completed is less than 0 grams, the meal retrieval results are missing, the returned plate results are missing, and no food remains are confirmed, it is transferred to the state of pending verification.

[0105] When writing back the meal status ledger, only the compensation meal preparation strategy record number, meal retrieval result record number, plate return remaining result record number, compensation completed amount, remaining amount to be compensated, and write-back status are appended to the fields to be compensated. The original deviation items, deviation sources, amount to be compensated, compensation priority, and compensation queue record number are not deleted. When the same compensation meal preparation strategy record number is written back repeatedly and the field content is the same, the result of the first write-back is returned. If the field content is different, the original write-back record is not overwritten and is transferred to pending verification.

[0106] Preferably, before breakfast on June 18, 2026, a school reads the lunch compensation queue from June 17, 2026. A student's vegetable deviation item requires compensation of 35 grams. The next meal menu includes broccoli, and the remaining inventory is 28,000 grams. Window 2 has a compensation capacity of 200 people and 8,000 grams, with a minimum single distribution weight of 10 grams. The compensation boundary table allows a maximum vegetable breakfast compensation of 50 grams. The system generates a compensation meal plan of 35 grams of broccoli. The student actually receives breakfast. Broccoli 35g, after the meal, the remaining amount confirmed upon return of the plate is 5g. The system writes back the amount of compensation completed this time as 30g, and the corresponding field to be compensated is updated from "to be compensated" to "partially compensated", with the remaining amount to be compensated being 5g. The system completes the strategy generation for 1200 students within 10 seconds. After a single write-back fails, it retryes twice after a 3-second interval. If it still fails, it is transferred to the pending verification stage. When 60 write-back records are randomly checked, the consistency rate of the compensated dishes, compensation portions, meal pick-up results, remaining plate return results, and write-back status is no less than 99%.

[0107] Alternative approaches include: for schools without a window-based compensation prompt terminal, the catering administrator can print a compensation meal distribution list and hand it over to the compensation meal service window for execution; for schools without an automatic inventory record, the remaining inventory can be confirmed by the weighing slip of the finished dishes after meal preparation. However, these alternative approaches must not change the order of generating the compensation meal distribution strategy based on the compensation queue, the next meal menu, the remaining inventory, the capacity of the service window, and the compensation boundary table, as well as the order of writing back to the catering status ledger based on the meal pick-up results and the remaining plate return results, the unit scope, the write-back fields, and the boundaries to be verified.

[0108] In the operational scenario shown in this embodiment: 30 minutes before lunch service on June 17, 2026, the catering administrator of a school's main campus confirms the meal service plan for this meal on the meal planning page of the canteen management system, and establishes a meal status ledger according to student identifier, class identifier, meal number, and quantity-based recipe version. Among them, the student identifier uses the internal student code of the student registration system, the class identifier is taken from the class roster effective at 7:00 on the same day, the meal number is "20260617 Lunch Main Campus First Batch", the quantity-based recipe version is "20260617 Lunch Version 1", the planned dishes for this meal include rice, scrambled eggs with tomatoes, and stir-fried seasonal vegetables, with planned portions of 150 grams, 120 grams, and 100 grams, respectively. The nutritional conversion value is formed by the nutritional ledger of the dishes associated with this quantity-based recipe version, the serving window is window number 2, and the remaining inventory is 45,000 grams, 36,000 grams, and 30,000 grams, respectively.

[0109] The system locks the recipe version with quantity 25 minutes before the meal pick-up channel opens, and reads the 2026 Spring Edition Student Meal Nutrition Standard, the cost meal plan supply benchmark, the allowed substitute dish table, and the compensation boundary table. Among them, the allowed substitute dish table records that 100 grams of stir-fried vegetables can be replaced by 100 grams of garlic lettuce. The compensation boundary table records that the lower limit of vegetable lunch is 100 grams, the upper limit is 150 grams, the boundary of consecutive compensation times is 2 times, and the boundary of effective meal times is the next 3 meals.

[0110] During the meal collection phase, the student with the student ID STU202606170035 completed identity verification at window 2 using their campus card. The planned dish in the window's meal record was stir-fried seasonal vegetables. However, due to insufficient stock of stir-fried seasonal vegetables on-site and the existence of a corresponding substitution relationship in the allowed substitution dish list, the window staff confirmed at the terminal that the actual meal was garlic lettuce, with an actual portion size of 100 grams. The system then created a temporary substitution dish record and wrote it into the meal collection status.

[0111] After the meal, the student returned the plate. The plate returner confirmed at the plate return terminal that the remaining item was garlic lettuce. After deducting the tare weight of the plate and removing inedible items, the plate return weighing station recorded the remaining amount as 35 grams. The system then subtracted the remaining amount of 35 grams from the actual portion size of 100 grams taken in the meal taking status, generating an effective intake status of 65 grams.

[0112] After the plate return channel is closed, the system compares the effective intake status with the planned supply benchmark for this meal, confirms that the planned portion of vegetables corresponding to stir-fried vegetables is 100 grams and the effective intake is 65 grams, generates a deviation item as stir-fried vegetables, registers the food category as vegetables, registers the source of deviation as the remaining source according to the main deviation source rule, registers the amount to be compensated as 35 grams, registers the compensation priority as low level, and appends the compensation queue record number, deviation item, deviation source, amount to be compensated, compensation priority, and record status as reference fields to be compensated to the meal status ledger.

[0113] After the dinner menu version with portion control was locked on June 17, 2026, the system read the compensation queue record and matched it with the next meal menu, remaining inventory, serving window capacity, and compensation boundary table. The next meal menu included broccoli as a planned vegetable dish. The remaining inventory of broccoli at window 2 was 28,000 grams, the compensable vegetable weight was 8,000 grams, the number of students that could be compensated was 200, the minimum weight per distribution was 10 grams, and the compensation boundary table allowed a maximum compensation of 50 grams for vegetable dinners. Based on this, the system generated a compensation meal distribution strategy with broccoli as the compensable dish, a compensation portion of 35 grams, and window 2 as the compensation serving window, and sent the compensation meal distribution strategy record number to the meal collection terminal at window 2.

[0114] After confirming their identity at dinner, the student received 35 grams of broccoli, resulting in a meal collection record number linked to the compensation meal distribution strategy. Upon returning the plate after dinner, the plate returner confirmed that the remaining amount of the compensated broccoli was 5 grams. The system deducted the remaining 5 grams from the actual portion of 35 grams in the meal collection result, resulting in a compensation amount of 30 grams. The system then located the "To be Compensated" reference field in the meal status ledger using the student's identifier, original meal number, original recipe version, deviation item, compensation queue record number, and compensation meal distribution strategy record number. The system then appended the meal collection result record number, the remaining plate return result record number, the compensation amount, the remaining amount to be compensated, and the write-back status. Since the compensation amount of 30 grams was less than the original amount to be compensated (35 grams), the system updated the corresponding "To be Compensated" reference field from "To be Compensated" to "Partially Compensated," recorded the remaining amount to be compensated as 5 grams, and retained this remaining amount for subsequent meals within the valid meal boundary of the compensation boundary table.

[0115] Example 2: A student nutrition and diet management system, comprising: The meal status ledger creation module is used to create meal status ledgers by student ID, class ID, meal number, and recipe version with quantity, and to record planned dishes, planned portions, nutritional conversion values, serving windows, and remaining inventory. The planned supply benchmark generation module is used to lock the quantity-inclusive recipe version before meals are served, and to generate the planned supply benchmark for each meal, the allowed substitute dish table, and the compensation boundary table based on the student meal nutrition standards. The food collection status writing module is used to collect identity verification records, window food dispensing records, actual food items collected, actual food portion sizes collected, and records of temporarily replaced dishes during the food collection stage, and write them into the food collection status. The effective intake status generation module is used to collect the category and quantity of food left after the meal, and to subtract the remaining quantity from the returned plate from the actual amount of food taken in the meal taking status to generate the effective intake status. The compensation queue generation module is used to compare the effective intake status with the planned supply baseline, generate deviation items, deviation sources, amount to be compensated, and compensation priority, and write them into the compensation queue. The compensation meal preparation and write-back module is used to generate compensation meal preparation strategies based on the compensation queue, the next meal menu, the next meal inventory, the next meal service window capacity, and the compensation boundary table. After the compensation meal preparation strategy is executed, it writes back the meal status ledger according to the meal pick-up results and the remaining plate return results.

[0116] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0117] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0118] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0119] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus 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 or components 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 through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0121] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0123] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0125] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for student nutrition and dietary management, characterized in that, include: S1. Establish a dietary status ledger according to student ID, class ID, meal number and recipe version with quantity, and record the planned dishes, planned portions, nutritional conversion values, serving windows and remaining inventory; S2. Before serving meals, lock in the version of the menu with quantity, and supply the meal plan based on the student meal nutrition standards, the allowable substitution menu, and the compensation boundary table. S3. During the food collection stage, collect the identity verification record, window food dispensing record, actual food items collected, actual food portion size, and temporary replacement food item record; after the above identity verification record, window food dispensing record, actual food items collected, actual food portion size, and temporary replacement food item record are associated, the system writes the identity verification record, window food dispensing record, actual food items collected, actual food portion size, and temporary replacement food item record into the food collection status; S4. Collect the category and quantity of food returned after the meal, and subtract the remaining quantity from the returned plate from the actual amount of food taken in the meal taking state to generate an effective intake state. S5. After the effective intake status of the current meal is established, the canteen management system compares the effective intake status with the planned supply baseline for the current meal. The system generates deviation items according to the details of the planned dishes. The recording scope of deviation sources is limited to sources of uncollected food, sources of under-collected food, sources of substituted food, and sources of remaining food. When there are details in the planned supply baseline but no matching completed food collection status is found, the system registers it as a source of uncollected food. When the actual food collection amount is lower than the planned amount, the system registers it as a source of under-collected food. When the actual food collection items are different from the planned food and there are records of temporary substituted food, the system registers it as a source of substituted food. When the remaining amount on the returned plate is greater than 0 grams, the system registers it as a source of remaining food. The amount to be compensated is generated after the deviation items and deviation sources are determined. Compensation priorities are generated after the amount to be compensated is determined. Deviation items whose primary source of deviation is an unclaimed meal source are registered as high-level by the system; deviation items whose primary source of deviation is a short-claimed source and whose amount to be compensated reaches 50% or more of the corresponding planned portion are registered as high-level by the system; deviation items whose primary source of deviation is a short-claimed source and whose amount to be compensated is less than 50% of the corresponding planned portion are registered as medium-level by the system; deviation items whose primary source of deviation is a substitute source are registered as medium-level by the system; deviation items whose primary source of deviation is a remaining source are registered as low-level by the system. The compensation queue is written after the deviation item, deviation source, amount to be compensated, and compensation priority are all completed. After the compensation queue is written, the system will append the compensation queue record number, deviation item, deviation source, amount to be compensated, compensation priority, and record status as reference fields to the dietary status ledger. S6. Generate a compensation meal allocation strategy based on the compensation queue, next meal menu, next meal inventory balance, next meal service window capacity, and compensation boundary table. When writing back to the meal status ledger after execution, the system locates the field to be compensated in the meal status ledger using the student identifier, original meal number, original recipe version with portion size, deviation item, compensation queue record number, and compensation meal allocation strategy record number. Then, it deducts the remaining amount of returned plates from the actual portion size in the meal retrieval result to obtain the amount of compensation completed this time. The meal status ledger write-back only appends the compensation meal allocation strategy record number, meal retrieval result record number, remaining return plate result record number, compensation completed amount, remaining amount to be compensated, and write-back status after the field to be compensated.

2. The student nutrition diet management method according to claim 1, characterized in that, S1 includes: When establishing a dietary status ledger, students are identified using their internal student codes from the student registration system. The class identifier is the class record in the class roster effective on the day the meal service is provided. The version of the recipe with quantities is the version number in the confirmed recipe with quantities record; The planned dishes are listed in detail according to the recipe version with quantities and the serving window; The planned portion size is written in grams; Nutritional conversion values ​​are derived from the nutritional records of planned dishes and dishes with planned portion sizes. Inventory balance refers to the amount of finished dishes available for distribution after food preparation is completed; The meal status ledger forms the basic record of the meal plan according to student identification, class identification, meal number and recipe version with quantity, and forms detailed rows for planned dishes; when the same planned dish is served at multiple meal windows, detailed rows are formed for each different meal window and are not merged into one row.

3. The student nutrition diet management method according to claim 1, characterized in that, S2 include: When locking the version of the quantity-based recipe before meals are served, the version of the quantity-based recipe in the meal status ledger is compared with the confirmed quantity-based recipe records by version number, confirmation time and effective meal number; After comparison and agreement, based on the student meal nutrition standard version and the cost meal plan supply benchmark, a list of allowed substitute dishes and a compensation boundary table are then formed. When the production cost meal plan supply benchmark is set, the system reads the ledger details one by one and forms a benchmark detail with student identification, meal number, quantity-based recipe version, student meal nutrition standard version, planned dishes and meal service window. The planned portion, food category, nutritional conversion value and inventory balance are recorded in the benchmark detail. The list of dishes that can be substituted is generated after the planned supply baseline for this meal is completed. Each record in the list of dishes that can be substituted starts with the original planned dishes and the original serving window, and is associated with the substituted dishes, substituted food categories, substituted portions and substituted serving windows. The compensation boundary table is formed after the planned supply baseline for this meal is completed; the compensation boundary table only limits the scope of subsequent compensation strategies that can be used, does not generate compensation meal matching strategies in this step, and does not change the planned supply baseline for this meal.

4. A student nutrition diet management method according to claim 1, characterized in that, S3 includes: When writing the meal pickup status, first read the already booked meal status ledger, the planned supply benchmark for this meal, and the list of allowed substitute dishes; The system compares the identity verification record with the student ID, class ID, and meal number in the meal status ledger. If all three match and the verification time falls between the opening and closing of the meal pick-up channel for this meal, the system allows continued registration for this meal pick-up. The system compares the meal delivery records at the window with the meal delivery windows and planned dishes in the current meal plan. If the meal delivery windows and planned dishes are consistent, the system continues to collect the actual meals taken. When the actual dishes served differ from the planned dishes, a temporary substitution record is created based on the list of permitted substitution dishes. When the actual meal portion is determined, the system first links the identity confirmation record, then links the meal dispensing record at the window, then links the actual meal dishes taken, and finally registers the corresponding gram value; the same student ID, the same meal number, the same recipe version with the same quantity, the same planned dishes, and the same serving window form a meal collection status detail.

5. A student nutrition diet management method according to claim 1, characterized in that, S4 includes: When generating a valid intake status, the system first reads the meal collection status and uses the student ID, meal number, recipe version with quantity, planned dishes, serving window, actual dishes collected, and actual portion size as the basis for post-meal data collection. The remaining categories of returned dishes can only be confirmed from the actual dishes taken by students in the current meal's pick-up status; The remaining amount of returned plates corresponds to the remaining weight of the edible portion confirmed during plate return, and the unit in the account is uniformly grams; When deducting the remaining amount from the returned plate from the actual portion of food taken in the food taking status, the system locates the same food taking status detail according to student ID, meal number, recipe version with quantity, planned dishes and food serving window, and deducts the remaining amount from the returned plate under the corresponding category of the returned plate from the actual portion of food taken in that detail, and obtains the effective intake of that detail after deduction. The effective intake status is formed after the deduction is completed. The effective intake status corresponds to the student's meal management status after deducting the remaining amount after returning the plate in this meal, the corresponding planned dishes, and the food serving window.

6. A student nutrition diet management system, used to implement the student nutrition diet management method according to any one of claims 1-5, characterized in that, include: The meal status ledger creation module is used to create meal status ledgers by student ID, class ID, meal number, and recipe version with quantity, and to record planned dishes, planned portions, nutritional conversion values, serving windows, and remaining inventory. The planned supply benchmark generation module is used to lock the quantity-inclusive recipe version before meals are served, and to generate the planned supply benchmark for each meal, the allowed substitute dish table, and the compensation boundary table based on the student meal nutrition standards. The food collection status writing module is used to collect identity verification records, window food dispensing records, actual food items collected, actual food portion sizes, and temporary replacement food item records during the food collection stage, and write these records into the food collection status. The effective intake status generation module is used to collect the category and quantity of food left after the meal, and to subtract the remaining quantity from the returned plate from the actual amount of food taken in the meal taking status to generate the effective intake status. The compensation queue generation module is used to compare the effective intake status with the planned supply baseline, generate deviation items, deviation sources, amount to be compensated, and compensation priority, and write them into the compensation queue. The system generates a compensation meal planning strategy based on the compensation queue, the next meal menu, the next meal inventory, the next meal service window capacity, and the compensation boundary table. When writing back to the meal status ledger after execution, the system locates the fields to be compensated in the meal status ledger using the student identifier, original meal number, original recipe version with portion size, deviation item, compensation queue record number, and compensation meal planning strategy record number. Then, it subtracts the remaining amount of returned plates from the actual portion size taken in the meal retrieval results to obtain the amount of compensation completed this time. The meal status ledger write-back only appends the compensation meal planning strategy record number, meal retrieval result record number, remaining return plate result record number, compensation completed amount, remaining amount to be compensated, and write-back status to the fields to be compensated.

Images