School meal charging subsystem

Abstract

The invention relates to a school meal charging subsystem, which comprises a mode selection module used for setting whether a pre-receiving mode and a receivable mode are supported or not; the information management module is used for setting a reading field; the temporary recording module is used for temporarily storing user data and marking a data processing path; when the receivable mode is supported, the account information and the account balance of the user are forwarded to the data pre-screening module; judging that the account balance is greater than or equal to a balance threshold value, forwarding the account balance to a first delivery order generation module by default, and processing delivery order generation in a pre-receiving mode; and if the account balance is less than the balance threshold, forwarding the account balance to a second delivery order generation module by default, and processing the generation of the delivery order in the receivable mode. According to the invention, a modular design and a flexible charging mode switching mechanism are adopted, so that the defects of an existing school meal system in the aspect of supporting a post-charging mode (receivable mode) are effectively overcome; the stability of the original pre-receiving mode is reserved, the support of the receivable mode is added, and the diversified management requirements of different schools are met.

Description

Technical Field

[0001] The present invention relates to the technical field of catering fee management, in particular to a school meal fee subsystem. Background Art

[0002] The existing school meal system mainly revolves around a prepayment model (pay first, then eat), and payment can be completed on the PC backend management terminal and mobile terminal. The system includes modules such as school management, delivery order management, leave management (students can complete basic functions such as payment and leave on mobile terminals), bill generation, and report query, and supports the import and export of basic data. However, as business needs expand, the system needs to be redesigned and developed according to customer needs in order to support the post-payment model (receivable model, that is, eating first and paying later).

[0003] The existing school meal system only supports a prepayment model and lacks the adaptability to a post-payment model. A single charging model cannot meet the management needs of schools under a receivable model, limiting the system's scope of application. Regarding delivery order management, the system cannot distinguish between prepayment and receivable models, and the delivery order generation logic does not consider the detailed student delivery order data under the receivable model, resulting in an inability to flexibly handle business processes under different charging models. Furthermore, the system lacks a leave import function and cannot flexibly handle leave records before and after delivery order generation, affecting data accuracy and management efficiency.

[0004] The existing school meal system lacks the ability to automatically generate and review bills, and cannot meet the needs of automatically generating bills or manually generating bills at the end of the month. The bill generation logic does not take into account the identification of leave records, which may lead to inaccurate calculation of bill amounts, thereby affecting the standardization of fee management. On the mobile side, the payment function does not support the receivable mode, the payment amount cannot be dynamically displayed according to the bill, and there is a lack of payment record query and consumption detail query functions under the receivable mode. The reporting function is also imperfect. It is impossible to query students' daily delivery details in the receivable mode. There is a lack of flexible query and export functions, which makes it difficult to meet the school's needs for refined management.

[0005] The information disclosed in this background technology section is only intended to deepen the understanding of the overall background technology of the present invention and should not be regarded as an admission or any form of suggestion that the information constitutes the prior art already known to those skilled in the art. Summary of the Invention

[0006] In response to the defects in the existing technology, the purpose of the present invention is to provide a school meal charging subsystem, which adopts modular design and a flexible charging mode switching mechanism to effectively solve the shortcomings of the existing school meal system in supporting the post-charging mode (receivable mode); it not only retains the stability of the original pre-payment mode, but also adds support for the receivable mode, meeting the diverse management needs of different schools.

[0007] In order to achieve the above purpose, the technical solution adopted by the present invention is:

[0008] A school meal fee collection subsystem, characterized by comprising:

[0009] Mode selection module, used to set support for only prepayment mode or both prepayment mode and receivable mode;

[0010] An information management module, configured to read information of a charging mode standard field or read information of a charging mode standard field and a charging mode extension field according to the setting of the mode selection module;

[0011] A temporary recording module is used to temporarily store user data and mark the data processing path according to the settings of the mode selection module; the user data defaults to the user's meal purchase order in the school meal system;

[0012] When only prepayment mode is selected, the data processing path of user data is marked as forwarded to the charging management module embedded in the school dining system for processing; the charging management module embedded in the school dining system completes the corresponding charging processing according to the existing prepayment mode;

[0013] When both the prepayment mode and the receivable mode are supported, the data processing path of the user data is marked as forwarded to the data pre-screening module embedded in the school meal fee collection subsystem for processing;

[0014] After the user successfully logs into the school meal system, the corresponding account information and account balance are forwarded to the data pre-screening module;

[0015] Presetting a balance threshold in the data pre-screening module;

[0016] When the account balance is greater than or equal to the balance threshold, it is forwarded to the first delivery order generation module by default to handle the delivery order generation in the pre-collection mode;

[0017] When the account balance is less than the balance threshold, it is forwarded to the second delivery order generation module by default to handle the delivery order generation in the receivable mode.

[0018] On the basis of the above technical solution, a charging mode extension field is added to the database, and the original charging-related table fields in the database are mapped to charging mode standard fields;

[0019] The charging mode standard field is used to support the original pre-collection mode data processing logic;

[0020] The charging mode extension field is used to support the newly added receivable mode data processing logic.

[0021] On the basis of the above technical solution, the first delivery order generation module obtains the information of the charging mode standard field, and generates a pre-paid delivery order based on the pre-paid mode information processing logic and the paid amount and the meal purchase order.

[0022] Based on the above technical solution, after the pre-paid delivery order is generated, a corresponding balance deduction notification is created and sent simultaneously to the Finance Department, users, the school catering management department and the system log.

[0023] Based on the above technical solution, the second delivery order generation module obtains information of the charging mode standard field and the charging mode extended field, and generates a receivable delivery order based on the meal purchase order and account balance based on the receivable mode information processing logic.

[0024] Based on the above technical solution, after the receivable delivery order is generated, a corresponding payment notification is created and sent simultaneously to the Finance Department, users, the school catering management department and the system log.

[0025] Based on the above technical solution, users who log in to the school meal system must first complete registration in the school management information module and bind the corresponding school name, grade, class, and student number.

[0026] Based on the above technical solution, the school meal fee collection subsystem accesses the leave management module of the school meal system through the data interface, and imports the newly added leave records and the modified leave records after the last update according to the operation timestamp;

[0027] Check whether the leave record is in valid or invalid state, then find the pre-collected delivery order or receivable delivery order of the user corresponding to the leave record on the leave date, and mark the corresponding delivery order as invalid or valid.

[0028] On the basis of the above technical solutions, it also includes:

[0029] A bill generation module, used to create a charging bill based on the request;

[0030] The request comes from a timed trigger set by the system, or a temporary trigger manually operated by the user;

[0031] Based on the meal supply date, output the meal purchase order information for each day within the date range, as well as leave information, pre-collected delivery orders and receivable delivery orders.

[0032] Based on the above technical solution, the mobile terminal supports manual operation to temporarily trigger the creation of charging bills and supports exporting charging bills;

[0033] The PC backend management terminal supports regular monthly triggering of requests to create billing invoices, and supports sending batch reminder SMS messages to corresponding users.

[0034] The school meal fee collection subsystem described in the present invention has the following beneficial effects:

[0035] 1. The mode selection module and data pre-screening module enable dynamic switching between pre-collection mode and receivable mode. The information management module and temporary recording module ensure the accuracy and integrity of user data.

[0036] 2. By adding extended fields for charging modes and optimizing the database structure, the system can efficiently process data logic under prepayment mode and receivable mode, improving the system's flexibility and scalability;

[0037] 3. The first and second delivery order generation modules generate delivery orders for the pre-collection and receivable modes respectively, and implement an intelligent delivery order processing process through an automatic judgment mechanism based on the balance threshold.

[0038] 4. The system has been comprehensively optimized in terms of user registration, leave record management, bill generation and reminder functions, further improving user experience and management efficiency;

[0039] Users are required to bind their school information when logging in, ensuring the accuracy of user data; dynamic import of leave records and real-time update of delivery order status avoid billing errors caused by leave; the bill generation module supports timed triggering and manual triggering, meeting management needs in different scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The present invention has the following accompanying drawings:

[0041] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.

[0042] Figure 1 System architecture diagram of embodiment 1 of the school meal fee collection subsystem described in the present invention. DETAILED DESCRIPTION

[0043] The present invention will be described in further detail below with reference to the accompanying drawings. The detailed description, which is provided for illustrative purposes only and includes various details to aid understanding of the embodiments of the present invention, should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted from the following description.

[0044] like Figure 1 As shown, the school meal fee collection subsystem of the present invention includes:

[0045] Mode selection module, used to set support for only prepayment mode or both prepayment mode and receivable mode;

[0046] The information management module is used to select and read the information of the charging mode standard field, or read the information of the charging mode standard field and the charging mode extension field according to the settings of the mode selection module; the charging mode standard field is obtained by mapping the original charging-related database table fields in the database to support the original pre-collection mode data processing logic; the charging mode extension field is a field added to the database to support the newly added receivable mode data processing logic. The two together constitute the "charging mode" field, which runs through the entire system and can ensure that each module dynamically adjusts its functions and data processing logic according to the charging mode;

[0047] A temporary recording module is used to temporarily store user data and mark the data processing path according to the settings of the mode selection module; the user data defaults to the user's meal purchase order in the school meal system;

[0048] When only prepayment mode is selected, the data processing path of user data is marked as forwarded to the charging management module embedded in the school dining system for processing; the charging management module embedded in the school dining system completes the corresponding charging processing according to the existing prepayment mode;

[0049] When both the prepayment mode and the receivable mode are supported, the data processing path of the user data is marked as forwarded to the data pre-screening module embedded in the school meal fee collection subsystem for processing;

[0050] After the user successfully logs into the school meal system, the corresponding account information and account balance are forwarded to the data pre-screening module;

[0051] A balance threshold is preset in the data pre-screening module; the balance threshold can be dynamically adjusted according to the operation strategy and actual situation of the school meal system;

[0052] When the account balance is greater than or equal to the balance threshold, it is forwarded to the first delivery order generation module by default to handle the delivery order generation in the pre-collection mode;

[0053] When the account balance is less than the balance threshold, it is forwarded to the second delivery order generation module by default to handle the delivery order generation in the receivable mode.

[0054] This implementation implements the selection of charging modes, which can support only the prepayment mode, or support both the prepayment mode and the receivable mode. According to the settings of the mode selection module, the information management module will read the corresponding charging mode standard field or read the information of the charging mode standard field and the charging mode extension field at the same time. The temporary recording module will temporarily store user data, which defaults to the user's meal purchase order in the school meal system. According to the settings of the mode selection module, the module will mark the data processing path of the user data accordingly. According to the different mode selections, it is divided into the following situations:

[0055] If the system is set to support only pre-payment mode, user data will be directly forwarded to the charging management module embedded in the school meal system, and charging will be processed according to the existing pre-payment mode;

[0056] If the system is set to support both pre-collection mode and receivable mode, user data will be forwarded to the data pre-screening module embedded in the school meal fee collection subsystem;

[0057] The working process of the data pre-screening module is as follows:

[0058] Account information and balance judgment stage: After the user successfully logs into the school meal system, the system will forward the corresponding account information and account balance to the data pre-screening module. A balance threshold is preset in the data pre-screening module to determine the user's payment ability;

[0059] Delivery order generation stage: If the account balance is greater than or equal to the balance threshold, the system will forward the user data to the first delivery order generation module by default, which corresponds to the pre-collection mode; if the account balance is less than the balance threshold, the system will forward the user data to the second delivery order generation module by default, which corresponds to the receivable mode.

[0060] The system architecture provided in this embodiment supports flexible switching of multiple charging modes, retaining the original prepayment mode and adding support for the payment mode, thus meeting the actual needs of different schools.

[0061] The setting of the data pre-screening module enables the system to automatically make a preliminary judgment based on the user's account balance, thereby deciding which delivery order generation module to use, improving the system's automation level and processing efficiency; the use of the temporary recording module ensures the accuracy and completeness of user data during the processing process, avoiding the occurrence of missed processing, repeated processing, etc. of meal purchase orders.

[0062] On the basis of the above technical solution, a charging mode extension field is added to the database, and the original charging-related table fields in the database are mapped to charging mode standard fields;

[0063] The charging mode standard field is used to support the original pre-collection mode data processing logic;

[0064] The charging mode extension field is used to support the newly added receivable mode data processing logic.

[0065] On the basis of retaining the original database format and function, an extended charging mode field is added, and a mapping method is used to generate a charging mode standard field. The two together constitute the "charging mode" field, which is used to distinguish the charging mode adopted by the school (prepayment or receivable). The "charging mode" field runs through the entire system to ensure that each module dynamically adjusts its functions and data processing logic according to the charging mode.

[0066] In this embodiment, the charging model standard field is mapped from existing charging-related database table fields to support the existing pre-collection model data processing logic; the charging model extension field is a field added to the database to support the newly added receivable model data processing logic. Based on the specific data processing logic required, the information management module selects to read information from the charging model standard field, or read information from both the charging model standard field and the charging model extension field, according to the settings of the mode selection module.

[0067] On the basis of the above technical solution, the first delivery order generation module obtains the information of the charging mode standard field, and generates a pre-paid delivery order based on the pre-paid mode information processing logic and the paid amount and the meal purchase order.

[0068] Based on the above technical solution, after the pre-paid delivery order is generated, a corresponding balance deduction notification is created and sent simultaneously to the Finance Department, users, the school catering management department and the system log.

[0069] For example, the first delivery order generation module obtains information from the standard charging model field and, based on the pre-collection model information processing logic, generates a pre-collection delivery order based on the paid amount and the meal order. After the pre-collection delivery order is generated, a corresponding balance deduction notification is created and simultaneously sent to the Finance Department, the user, the school's catering management department, and the system log. The notification includes information such as the deduction amount, deduction time, and order details.

[0070] Based on the above technical solution, the second delivery order generation module obtains information of the charging mode standard field and the charging mode extended field, and generates a receivable delivery order based on the meal purchase order and account balance based on the receivable mode information processing logic.

[0071] Based on the above technical solution, after the receivable delivery order is generated, a corresponding payment notification is created and sent simultaneously to the Finance Department, users, the school catering management department and the system log.

[0072] For example, the second delivery order generation module obtains information from the standard and extended fields of the charging model and, based on the receivables model information processing logic, generates an A / R delivery order based on the meal purchase order and account balance. After the A / R delivery order is generated, a corresponding pending payment notice is created and simultaneously sent to the Finance Department, the user, the university's catering management department, and the system log. The notice includes information such as the pending payment amount, payment deadline, and order details.

[0073] Based on the above technical solution, users who log in to the school meal system must first complete registration in the school management information module and bind the corresponding school name, grade, class, and student number.

[0074] Based on the above technical solution, the school meal fee collection subsystem accesses the leave management module of the school meal system through the data interface, and imports the newly added leave records and the modified leave records after the last update according to the operation timestamp;

[0075] Check whether the leave record is in valid or invalid state, then find the pre-collected delivery order or receivable delivery order of the user corresponding to the leave record on the leave date, and mark the corresponding delivery order as invalid or valid.

[0076] Based on the above technical solution, when importing newly added leave records or modified leave records after the last update, the binding relationship between the meal purchase order and the school is verified to determine whether the imported information is accurate;

[0077] When entering leave information, the binding relationship between the entrant and the school is verified to determine whether the entered information is from a credible source and then transferred to the subsequent approval process.

[0078] On the basis of the above technical solutions, it also includes:

[0079] A bill generation module, used to create a charging bill based on the request;

[0080] The request comes from a timed trigger set by the system, or a temporary trigger manually operated by the user;

[0081] Based on the meal supply date, output the meal purchase order information for each day within the date range, as well as leave information, pre-collected delivery orders and receivable delivery orders.

[0082] The bill generation module is used to create a bill based on a request; the request comes from a timed trigger set by the system, or from a temporary trigger manually operated by the user; based on the meal supply date, the module outputs the meal purchase order related information (including order number, meal name, quantity, price, etc.) for each day within the date range, as well as leave related information (including leave date, leave type, approval status, etc.), as well as relevant information of pre-collected delivery orders and receivable delivery orders (including delivery order number, delivery time, order amount, etc.). The output format is an editable spreadsheet (such as Excel format) or a printable document format (such as PDF format).

[0083] Based on the above technical solution, when there is doubt about the charges, the user can set an abnormal status mark to mark one or more or all records in the bill as abnormal and initiate a review request.

[0084] Based on the above technical solution, manual operations on the mobile terminal are supported to temporarily trigger the request to create a charging bill, and the charging bill can be exported.

[0085] On the mobile side, it supports manual operations to temporarily trigger the request to create a charging bill, and supports exporting charging bills in common electronic document formats, which is convenient for users to view and save; on the PC background management side, it supports regular monthly scheduled triggering of the request to create charging bills, and supports batch sending of reminder SMS messages to corresponding users. The SMS content includes bill generation notifications, payment reminders and other information.

[0086] Based on the above technical solution, the PC backend management terminal supports regular monthly triggering of requests to create charging bills, and supports batch sending of reminder SMS messages to corresponding users.

[0087] On the basis of the above technical solution, the creator, creation time, review status, reviewer, review time, abnormal status mark, reviewer, and review time of each piece of information are further presented based on the permission setting.

[0088] The contents not described in detail in this specification belong to the prior art known to those skilled in the art.

[0089] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by those skilled in the art based on the contents disclosed in the present invention should be included in the protection scope recorded in the claims.

Claims

1. A school meal fee collection subsystem, characterized in that: include: Mode selection module, used to set support for only prepayment mode or both prepayment mode and receivable mode; An information management module, configured to select and read information of the charging mode standard field, or read information of the charging mode standard field and the charging mode extension field according to the setting of the mode selection module; A temporary recording module is used to temporarily store user data and mark the data processing path according to the settings of the mode selection module; the user data defaults to the user's meal purchase order in the school meal system; When only prepayment mode is selected, the data processing path of user data is marked as forwarded to the charging management module embedded in the school dining system for processing; the charging management module embedded in the school dining system completes the corresponding charging processing according to the existing prepayment mode; When both the prepayment mode and the receivable mode are supported, the data processing path of the user data is marked as forwarded to the data pre-screening module embedded in the school meal fee collection subsystem for processing; After the user successfully logs into the school meal system, the corresponding account information and account balance are forwarded to the data pre-screening module; Presetting a balance threshold in the data pre-screening module; When the account balance is greater than or equal to the balance threshold, it is forwarded to the first delivery order generation module by default to handle the delivery order generation in the pre-collection mode; When the account balance is less than the balance threshold, it is forwarded to the second delivery order generation module by default to handle the delivery order generation in the receivable mode.

2. A school meal fee collection subsystem as claimed in claim 1, characterized in that: Add a charging model extension field in the database and map the original charging-related table fields in the database to the charging model standard fields; The charging mode standard field is used to support the original pre-collection mode data processing logic; The charging mode extension field is used to support the newly added receivable mode data processing logic.

3. A school meal fee collection subsystem as claimed in claim 1, characterized in that: The first delivery order generation module obtains information of the charging mode standard field, and generates a pre-paid delivery order based on the pre-paid mode information processing logic, the paid amount and the meal purchase order.

4. A school meal fee collection subsystem as claimed in claim 3, characterized in that: After generating the pre-collected delivery order, a corresponding balance deduction notification is created and sent simultaneously to the Finance Department, the user, the school catering management department, and the system log.

5. A school meal fee collection subsystem as claimed in claim 3, characterized in that: The second delivery order generation module obtains information of the charging mode standard field and the charging mode extended field, and generates a receivable delivery order based on the receivable mode information processing logic, the meal purchase order and the account balance.

6. A school meal fee collection subsystem as claimed in claim 5, characterized in that: After the A / R delivery order is generated, a corresponding payment notification is created and sent simultaneously to the Finance Department, the user, the school's catering management department, and the system log.

7. A school meal fee collection subsystem as claimed in claim 1, characterized in that: Users who log in to the school meal system must first complete registration in the school management information module and bind the corresponding school name, grade, class, and student number.

8. A school meal fee collection subsystem as claimed in claim 5, characterized in that: The school meal fee collection subsystem accesses the leave management module of the school meal system through the data interface, and imports newly added and modified leave records after the last update based on the operation timestamp; Check whether the leave record is in valid or invalid state, then find the pre-collected delivery order or receivable delivery order of the user corresponding to the leave record on the leave date, and mark the corresponding delivery order as invalid or valid.

9. A school meal fee collection subsystem as claimed in claim 5, characterized in that: Also includes: A bill generation module, used to create a charging bill based on the request; The request comes from a timed trigger set by the system, or a temporary trigger manually operated by the user; Based on the meal supply date, output the meal purchase order information for each day within the date range, as well as leave information, pre-collected delivery orders and receivable delivery orders.

10. A school meal fee collection subsystem according to claim 9, characterized in that: On the mobile side, manual operations are supported to temporarily trigger the creation of charging bills, and charging bills can be exported; The PC backend management terminal supports monthly scheduled triggering of requests to create billing invoices, and supports batch sending of reminder SMS messages to corresponding users.

Images