A financial reconciliation system and method for a ride-hailing order

Abstract

The application provides a financial checking system and method for a network car-hailing order, which comprises a front-end project based on an MVVM mode and a back-end platform based on a Flask MTV mode; the front-end project is used for sending a financial checking instruction input by a user through a user interaction interface to the back-end platform; the back-end platform is used for performing a financial checking operation in response to the financial checking instruction, obtaining financial checking data, and feeding back the financial checking data to the front-end project; and the front-end project is further used for displaying the financial checking data through the user interaction interface. Through the application, the payment, advance payment, price change and refund of instant orders, post-payment orders and reservation orders can be effectively dealt with through order numbers, the expected settlement data of account incomes and expenses of drivers, fleets, channels and companies and the like can be accurately calculated, the actual settlement data is compared, the one-key financial checking function is realized, the manual operation errors are reduced, and the accuracy and efficiency of account checking are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of software development technology, specifically to a financial verification system and method for ride-hailing orders. Background Technology

[0002] With the rapid development of the ride-hailing industry, the importance of account verification for different order types (such as instant orders, post-pay orders, and pre-booked fixed-price orders) and related payment, advance payment, fare adjustment, and refund operations is self-evident. However, the traditional manual account income verification process has become increasingly complex and error-prone. Existing technology, for specific order types, generally uses Excel or scripts to calculate the income of each account based on the order amount, commission rate, and fixed calculation formulas. For pre-booked orders, multiple amount fields need to be extracted; if the driver's or fleet's commission rate is adjusted, the Excel or script also needs to be modified. Furthermore, there is a lack of effective solutions for complex fare adjustment and refund scenarios, which is time-consuming and labor-intensive. In addition, the ride-hailing industry also has a complex multi-party revenue-sharing system (driver / fleet / channel / platform, etc.), involving diverse order types such as instant, post-pay, and pre-booked fixed-price. However, traditional clearing methods have the following drawbacks: manual verification relies on Excel formulas, resulting in low processing efficiency (more than 5 minutes per order); scenarios such as price changes / refunds require cross-system queries of work order data, leading to a high error rate; it cannot verify the consistency between actual transaction volume and expected revenue sharing in real time; changes to revenue sharing rules require rewriting scripts, resulting in high maintenance costs; and it does not support special fees for pre-booked orders (such as price increases / channel fluctuations). Currently, no single technology can completely overcome all these challenges. Summary of the Invention

[0003] To address this, the present invention provides a financial reconciliation system and method for ride-hailing orders, aiming to solve the technical problems of high development costs, low accuracy, and low efficiency in existing technologies for reconciling ride-hailing order accounts.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] According to a first aspect of the present invention, the present invention provides a financial verification system for ride-hailing orders, the system comprising:

[0006] A front-end project based on the MVVM pattern; wherein, the front-end project includes a View layer, a ViewModel layer, and a Model layer connected in sequence; the View layer is used to provide a user interface; the Model layer is used to obtain financial verification data from the back-end platform; the ViewModel layer is used to convert the financial verification data into display data for the user interface;

[0007] And, a backend platform based on the Flask MTV model; wherein, the backend platform includes a basic database, a model processing layer, and a business logic layer connected in sequence; the basic database is used to acquire and store order-related information; the business logic layer is used to convert financial verification instructions from the front-end project into database model objects, and to analyze and process target data from the model processing layer to obtain financial verification data recognizable by the front-end project; the model processing layer is used to query / retrieve target data in the basic database based on the database model objects;

[0008] The front-end project is used to send the financial verification instructions entered by the user through the user interface to the back-end platform;

[0009] The backend platform is used to perform financial verification operations in response to the financial verification instruction, obtain financial verification data, and feed the financial verification data back to the frontend project;

[0010] The front-end project is also used to display the financial reconciliation data through the user interface;

[0011] The financial reconciliation instruction carries an order identifier, reconciliation type, and / or order environment; the reconciliation type includes account reconciliation and / or clearing reconciliation.

[0012] Furthermore, the backend platform is also used to manage database operations based on the SQLAlchemy framework, specifically for:

[0013] ORM (Object-Relational Mapping) technology simplifies the SQL writing for the model processing layer when querying / retrieving target data in the underlying database, allowing the target data to be queried / retrieved based on the mapping relationship between the database model objects and the database table structure; and / or,

[0014] Utilize marshmallow technology to achieve data serialization / deserialization with the aforementioned front-end project; and / or,

[0015] The third-party interface is called through Python's requests library to enable API communication with at least one finance-related module; wherein the finance-related module includes at least one of the following: order payment module, account management module, financial accounting module, and work order business module.

[0016] Furthermore, the ViewModel layer is also used to establish two-way data binding between the View layer and the Model layer, specifically for:

[0017] Data binding technology is used to convert financial reconciliation data from the backend platform into display data for the user interface;

[0018] The data binding technology includes at least one of the following: declarative binding, reactive listening, event-driven updates, and virtual DOM optimization.

[0019] And / or,

[0020] The DOM event listening technology is used to convert user operations from the View layer into financial reconciliation instructions that can be recognized by the backend platform.

[0021] The DOM event listening technology includes at least one of operation binding, mapping processing, input update, data pass-through, and decoupled interaction.

[0022] Furthermore, the business logic layer includes at least one of the following: an order data acquisition module, a real-time order calculation module, a pre-booked order calculation module, an actual clearing and settlement module, and an account income and expenditure settlement module;

[0023] The order data acquisition module is used to acquire order-related information based on the order identifier, and process the order-related information according to multi-dimensional data processing rules that match different order types to obtain target order information;

[0024] The real-time order estimation module is used to obtain target order information from the order data acquisition module, and to estimate the expected settlement data of instant orders and postpaid orders under different settlement scenarios based on the basic order information and order-specific information in the target order information.

[0025] The reservation order estimation module is used to obtain target order information from the order data acquisition module, and to estimate the expected settlement data for different settlement scenarios of the reservation fixed-price order based on the basic order information and order-specific information in the target order information.

[0026] The actual settlement module is used to collect the actual settlement data corresponding to the instant orders, the postpaid orders, and the pre-booked fixed-price orders.

[0027] The account income and expenditure settlement module is used to collect the actual income and actual expenditure of different account types corresponding to the instant orders, the postpaid orders and the pre-booked fixed-price orders, and obtain actual account data.

[0028] Furthermore, the order data acquisition module is also used for:

[0029] Before processing the order-related information according to multi-dimensional data processing rules that match different order types, the order-related information is pre-verified according to a hierarchical verification mechanism to obtain usable order-related information.

[0030] Furthermore, the business logic layer also includes a route-based front-end interaction interface; the front-end interaction interface is used for:

[0031] Receive and forward financial reconciliation instructions from the aforementioned front-end project; and,

[0032] Receive expected settlement data from the real-time order calculation module and the pre-order calculation module, actual clearing data from the actual clearing and settlement module, and / or actual account data from the account income and expenditure settlement module;

[0033] The expected settlement data, actual clearing data, and / or actual account data are verified to obtain financial verification data identifiable by the front-end project, specifically including:

[0034] For the actual clearing data and / or the actual account data, traverse each key-value pair in the expected value dictionary corresponding to the expected settlement data to generate a corresponding structured comparison object;

[0035] The structured comparison object is generated by generating Chinese tags through tag mapping, and the difference between the original value and the actual value of the structured comparison object is calculated to obtain clearing and verification data and / or account verification data.

[0036] The clearing and verification data and / or the account verification data are fed back to the front-end project as financial verification data.

[0037] According to a second aspect of the present invention, the present invention provides a financial reconciliation method for ride-hailing orders, applied to a financial reconciliation system for ride-hailing orders as described in any one of the first aspects of the present invention, the method comprising:

[0038] The front-end project responds to user actions from the user interaction page, generates a financial verification instruction for the target order, and sends the financial verification instruction to the back-end platform; the financial verification instruction carries the order identifier, verification type, and / or order environment;

[0039] The backend platform retrieves relevant order information through the financial module based on information retrieval rules that match the order type of the target order; the order types include instant orders, postpaid orders, and pre-booked fixed-price orders.

[0040] Based on the order-related information, different settlement scenarios corresponding to each order type are determined. Based on the expected settlement rules that match the different settlement scenarios of different order types, the expected settlement data of the target order is calculated. The expected settlement data includes expected clearing data and / or expected account data.

[0041] The actual clearing data and / or actual account data are retrieved and compared with the expected clearing data and / or expected account data to obtain clearing verification data and / or account verification data, which are then fed back to the front-end project as financial verification data.

[0042] The front-end project uses a user interface to display the financial reconciliation data;

[0043] The order-related information includes at least one of the following: order status, order type, channel ID, payment status, advance payment status, order amount, payment amount, refund amount, discount amount, basic commission rate, driver commission rate, insurance premium, surcharge amount, channel order placement fluctuation, channel commission rate, work order settlement method, and channel refund settlement method.

[0044] Furthermore, the step of retrieving relevant order information through the financial module according to the information retrieval rules matching the order type of the target order includes:

[0045] Retrieve basic order information through the aforementioned financial module;

[0046] Perform a completion check on the target order based on the basic order information;

[0047] If the target order has been prepaid or paid, determine the order type of the target order based on the basic order information;

[0048] Retrieve the corresponding order-specific information based on the order type;

[0049] The basic order information includes at least one of the following: order status, order type, channel ID, payment status, advance payment status, order amount, payment amount, insurance premium, surcharge amount, and channel order placement fluctuation. The order-specific information includes at least one of the following: refund amount, discount amount, basic commission rate, driver commission rate, channel commission rate, work order settlement method, and channel refund settlement method.

[0050] Furthermore, after performing a completion check on the target order based on the basic order information, the method further includes:

[0051] If the target order is not completed, an incomplete order status message will be sent to the front-end project.

[0052] If the target order has been completed, determine whether the target order has been prepaid or paid.

[0053] If the target order has not been prepaid or paid, a notification indicating that it has not been prepaid or paid will be sent to the front-end project.

[0054] Furthermore, before calculating the expected settlement data of the target order based on the expected settlement rules matching different settlement scenarios for different order types, the method further includes:

[0055] The order-related information is pre-verified according to a hierarchical verification mechanism to obtain usable order-related information; wherein, the hierarchical verification mechanism includes: verifying the basic status of the order, the integrity of the order data, and / or the consistency of the commission rate based on the order-related information, and filtering invalid / abnormal orders; and / or,

[0056] The order-related information is processed according to multi-dimensional data processing rules that match different order types; wherein, the multi-dimensional data processing rules include: advance payment-payment linkage processing rules, special fee processing rules, work order management rules, and commission rate standardization rules.

[0057] The present invention, by adopting the above technical solution, has at least the following beneficial effects:

[0058] This invention provides a financial reconciliation system for ride-hailing orders, comprising a front-end project based on the Vue.js framework and a back-end platform based on the Flask MTV model. The front-end project sends financial reconciliation commands input by the user through the user interface to the back-end platform. The back-end platform responds to the financial reconciliation commands by performing financial reconciliation operations, obtaining financial reconciliation data, and feeding the data back to the front-end project. The front-end project also displays the financial reconciliation data through the user interface. This invention enables rapid processing of payment, advance payment, price modification, and refund scenarios for instant orders, postpaid orders, and pre-booked fixed-price orders using order numbers. It accurately calculates the expected settlement data for driver, fleet, channel, and company accounts, compares it with actual settlement data, and achieves one-click financial reconciliation, reducing manual errors and significantly improving the accuracy and efficiency of account reconciliation.

[0059] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 This diagram illustrates the structure of a financial reconciliation system for ride-hailing orders according to an embodiment of the present invention.

[0062] Figure 2 A simplified schematic diagram of a user interface provided in an embodiment of the present invention is shown;

[0063] Figure 3 This diagram illustrates the structure of a business logic layer according to an embodiment of the present invention.

[0064] Figure 4 This invention provides a schematic diagram of the structure of a financial verification system for ride-hailing orders according to another embodiment of the present invention;

[0065] Figure 5 The diagram shows a flowchart of a financial verification method for ride-hailing orders provided by an embodiment of the present invention. Detailed Implementation

[0066] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0067] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0068] This invention provides a financial reconciliation system for ride-hailing orders, such as... Figure 1As shown, the system may include: a front-end project 100 based on the MVVM pattern, and a back-end platform 200 based on the Flask MTV pattern.

[0069] In this embodiment of the invention, the front-end project 100 can use the React framework or the Vue.js framework to efficiently build the user interface, and the back-end platform 200 uses Python language combined with Flask MTV mode to process business logic, so as to support the financial verification processing of instant orders, postpaid orders and pre-booked fixed-price orders, and can effectively deal with complex scenarios such as payment, advance payment, price change and refund.

[0070] Specifically, the front-end project 100 can be developed based on the MVVM pattern to ensure a clear separation between the data transmitted by the back-end platform 200 and the user view. The front-end project 100 includes a View layer 110, a ViewModel layer 120, and a Model layer 130 connected sequentially. The View layer 110 provides the user interface; the Model layer 130 retrieves financial verification data from the back-end platform; and the ViewModel layer 120 converts the financial verification data into display data for the user interface. The ViewModel layer 120, as the core of the MVVM model, acts as a bridge connecting the View layer 110 and the Model layer 130, handling business logic processing, network request processing, and data caching. The core function of the ViewModel layer 120 is to establish a two-way data binding between the View layer 110 and the Model layer 130, including converting the data transmitted by the back-end platform 200 into the specific display of the user interface, and converting user actions through the user interface into instructions recognizable by the back-end platform 200.

[0071] In one optional embodiment, the ViewModel layer 120 can be used to convert financial reconciliation data from the backend platform into display data for the user interface using data binding technology. This data binding technology includes declarative binding, reactive listening, event-driven updates, and virtual DOM optimization. Declarative binding refers to directly associating view elements and data elements through template syntax, such as form fields and list rendering. When data elements change, view elements automatically update without manual DOM manipulation. Reactive data listening involves proxying or monitoring the data model. When model data is added, deleted, modified, or queried, the view content is re-rendered. For example, after a user inputs content, the model data updates, and the view synchronously displays the latest content. Event-driven updates involve user interaction triggering events, such as user clicks or input, which trigger event handling functions to write the operation results to the data model. When the data model changes, the view is notified to update, achieving bidirectional data flow. Virtual DOM optimization involves generating a new virtual DOM tree when data changes, efficiently updating the real DOM by comparing differences, reducing unnecessary rendering overhead, and improving performance. ViewModel layer 120 can also be used to convert user operations from the View layer into financial reconciliation instructions recognizable by the backend platform using DOM event listening technology. DOM event listening technology includes operation binding, mapping processing, input updates, data pass-through, and decoupled interaction. Event binding refers to triggering events in the View layer 110 by listening for user operations; for example, an `input` event is triggered when a user enters content in an input box, and a `click` event is triggered when a button is clicked. Event handling refers to capturing user operations through event listeners and directly mapping the operation results to the corresponding data attributes in the ViewModel layer 120. For example, changes in the input box value will directly update the fields in the ViewModel layer 120 without additional logic processing. Data updates refer to the automatic synchronization of modified data attributes in the ViewModel layer 120 to the view layer through the data binding mechanism after an event is triggered; for example, the input box content is updated in real time. Simultaneously, the data in the ViewModel layer 120 can be directly used as input parameters for the backend interface without additional processing. Pass-through data refers to data generated by user operations, such as form input and button clicks. This data is directly written to the data model through event listeners, and upon subsequent submission, the model data is directly sent to the backend platform 200, ensuring consistent data format between the frontend and backend without intermediate processing. Decoupling the interaction separates event listeners from data binding. The View layer 110 is only responsible for capturing user behavior and passing it to the ViewModel layer 120, while the ViewModel layer 120 focuses on data management, avoiding direct coupling between the View layer 110 and the backend interface.

[0072] In this embodiment of the invention, the backend platform 200 may include a basic database 210, a model processing layer 220, and a business logic layer 230 connected in sequence; the basic database 210 is used to acquire and store order-related information; the business logic layer 230 is used to convert financial verification instructions from the frontend project 100 into database model objects, and to analyze and process target data from the model processing layer 220 to obtain financial verification data that the frontend project 100 can recognize; the model processing layer 220 is used to query / retrieve target data in the basic database 210 based on the database model objects.

[0073] In an optional embodiment, the backend platform 200 can manage database operations based on the SQLAlchemy framework. Specifically, it can utilize ORM (Object-Relational Mapping) technology to simplify the SQL writing when the model processing layer 220 queries / retrieves target data in the basic database 210. The target data is queried / retrieved based on the mapping relationship between database model objects and database table structures. ORM is a technology that maps database table structures to objects (classes) in a program to abstract database operations and simplify SQL writing. For example, when querying information such as orders and work orders, it improves development efficiency and code maintainability.

[0074] In another optional embodiment, the backend platform 200 can also utilize marshmallow technology to achieve data serialization / deserialization with the frontend project 100. Data serialization / deserialization is a process of converting data between different formats. Specifically, data serialization refers to converting model objects such as clearing and verification data and / or account verification data stored in the basic database 210 into a format recognizable by the frontend project 100, such as JSON; data deserialization refers to verifying the JSON-formatted financial verification instructions transmitted by the frontend project 100 and converting them into database model objects for logical processing by the backend platform 200.

[0075] In another optional embodiment, the backend platform 200 can also utilize Python's requests library to call third-party interfaces to achieve API communication with at least one external financial-related module and obtain external financial-related data through the API interface. The financial-related modules include an order payment module, an account management module, a financial accounting module, and a work order business module. Specifically, the order payment module ensures that accounting is performed based on the latest payment data by obtaining real-time order payment status (e.g., success / failure), advance payment records, and transaction details, avoiding allocation errors caused by data lag. The account management module provides accurate parameter support for income distribution rules by providing basic account information (e.g., balance, profit-sharing ratio, status) and dynamic change records for entities such as drivers, fleets, and channels, ensuring that profit-sharing rules are synchronized with account status in real time. The financial accounting module performs account reconciliation, discrepancy analysis, and anomaly warnings by connecting with the expected settlement data and actual settlement data generated by the business logic layer 230. The work order business module provides the basis for business changes to the business logic layer 230 by synchronizing the approval records and business vouchers (such as the reason for the price change and the amount of the refund) for operations such as order price modification and refund, so as to ensure the dynamic adaptation and compliant execution of the profit sharing rules in abnormal scenarios.

[0076] The front-end project 100 constructed in this embodiment of the invention can be used to send the financial verification instructions entered by the user through the user interaction interface to the back-end platform 200. The back-end platform 200 can be used to respond to the financial verification instructions to perform financial verification operations, obtain financial verification data, and feed the financial verification data back to the front-end project 100. The front-end project 100 can also be used to parse the financial verification data and convert it into display data for the user interaction interface.

[0077] like Figure 2 The image shown is a simplified diagram of the user interface. Figure 2As can be seen, the financial reconciliation request issued by the user through the front-end project 100 can carry the order identifier, reconciliation type, and order environment. The reconciliation type can include account reconciliation and clearing reconciliation. In actual operation, the user inputs the order identifier and order environment through the user interface and selects the reconciliation type to generate a financial reconciliation request carrying this information. The financial reconciliation instruction is sent to the ViewModel layer 120 through the nginx middleware. The ViewModel layer 120 converts the financial reconciliation request into a financial reconciliation instruction that the back-end platform 200 can recognize. The business logic layer 230 responds to the financial reconciliation instruction to perform financial reconciliation operations and, when appropriate, calls the model processing layer 220 to execute the relationship mapping between business objects and the basic database 210, obtain order-related information, perform corresponding data processing, obtain financial reconciliation data, and output it to the front-end project 100. The front-end project 100 parses the financial reconciliation data, typesets it, and displays the data (HTML) for the user interface to the user.

[0078] like Figure 3 The diagram shown is a structural schematic of the business logic layer 230. In this embodiment of the invention, the business logic layer 230 undertakes the core responsibility of financial reconciliation processing. It includes multiple public function modules stored through business processes, including an order data acquisition module 231, a real-time order calculation module 232, a pre-order calculation module 233, an actual clearing and settlement module 234, and an account income and expenditure settlement module 235.

[0079] The order data acquisition module 231 can be used to obtain order-related information based on the order identifier, process the order-related information according to multi-dimensional data processing rules that match different order types, and obtain the target order information.

[0080] The order-related information can include order status, order type, channel ID, payment status, advance payment status, order amount, payment amount, refund amount, discount amount, basic commission rate, driver commission rate, insurance premium, surcharge amount, channel order placement fluctuation, channel commission rate, work order settlement method, and channel refund settlement method. Multi-dimensional data processing rules can include: advance payment-payment linkage processing rules, special fee processing rules, work order management rules, and commission rate standardization rules.

[0081] Specifically, the advance payment-payment linkage processing rule refers to establishing differentiated processing logic for payment orders after advance payment. When there is a difference between the advance payment amount and the payment amount, a dual-track accounting strategy is implemented. When drivers or fleets settle accounts, revenue is calculated based on the advance payment amount; when the company confirms revenue, the actual amount received is used as the accounting base. In specific applications, differentiated processing for different channels is achieved through parameterized configuration. The commission rate standardization rule refers to standardizing commission rates and constructing a unified rate calculation framework, such as standardizing mathematical units (yuan / fen / percentage) and precision control strategies (magnification factor / decimal / rounding / truncation). The special fee processing rule refers to building a fee item accumulation engine to support conditional accumulation of multi-dimensional fee items and setting default value mechanisms, such as automatically setting unconfigured fee items to zero. The work order management rule refers to building work order trigger condition judgment logic, establishing a differentiated settlement label system, such as normal settlement without refund / normal settlement / no settlement / partial settlement, etc., and defining corresponding work order settlement method mapping rules.

[0082] In practical applications, in order to differentiate and process different settlement scenarios for different order types, the order data acquisition module 231 can also be used to construct a multi-dimensional data dictionary matrix, placing the processed order data of different types into different dictionaries, such as the core order dictionary, the instant / postpaid dictionary, the reservation fixed price dictionary, the multi-dimensional settlement dictionary (including channel / work order / payment dimensions), and the clearing rules dictionary, etc.

[0083] The order data acquisition module 231, through the aforementioned structured data management and condition judgment mechanism, achieves accurate data processing and flexible calculation adaptation in complex order scenarios, supports flexible expansion and rule iteration of subsequent calculation modules, and effectively ensures the accuracy and traceability of data processing.

[0084] In an optional embodiment, the order data acquisition module 231 can also be used to perform pre-verification of order-related information according to a hierarchical verification mechanism before processing order-related information according to multi-dimensional data processing rules matching different order types, thereby obtaining usable order-related information. The hierarchical verification mechanism includes: verifying the basic order status, order data integrity, and / or commission rate consistency based on order-related information, and filtering invalid / abnormal orders. In practical applications, the basic order status can be verified through interface calls to filter invalid orders; then, the integrity of financial data can be verified through database queries to remove unsettled orders; finally, the consistency of commission rates can be verified through interface comparison to identify abnormal orders in the process, thereby obtaining usable order-related information.

[0085] The real-time order estimation module 232 can be used to obtain target order information from the order data acquisition module, and to estimate the expected settlement data of instant orders and postpaid orders under different settlement scenarios based on the basic order information and order-specific information in the target order information. The basic order information includes order status, order type, channel ID, payment status, advance payment status, order amount, payment amount, insurance premium, surcharge amount, and channel order placement fluctuation, etc.; the order-specific information includes refund amount, discount amount, basic commission rate, driver commission rate, channel commission rate, work order settlement method, and channel refund settlement method, etc. It should be noted that the real-time order estimation module 232 is used to determine different order types and their corresponding different settlement scenarios based on the basic order information and order-specific information. For example, under separate settlement or unified settlement, there are paid / advanced orders with no work order refunds or with work order refunds but normal driver settlement; under separate settlement mode, there are paid / advanced orders with work order refunds and partial driver settlement; under separate settlement mode, there are paid / advanced orders with work order refunds but no driver settlement. In practical applications, the real-time order calculation module 232 is also configured with corresponding expected settlement calculation rules for different types and scenarios. Based on the expected settlement calculation rules and target order information, the expected clearing data and expected account data corresponding to immediate orders and postpaid orders can be calculated.

[0086] The pre-booking order estimation module 233 can be used to obtain target order information from the order data acquisition module, and to estimate the expected settlement data for different settlement scenarios of pre-booked fixed-price orders based on the basic order information and order-specific information in the target order information. Similar to the real-time order estimation module 232, the pre-booking order estimation module 233 has corresponding expected settlement calculation rules configured for the scenario segmentation of pre-booked fixed-price orders. Based on the expected settlement calculation rules and the target order information, the expected clearing data and expected account data corresponding to the pre-booked fixed-price order can be calculated.

[0087] The Actual Settlement and Reconciliation Module 234 can be used to collect actual settlement data for instant orders, postpaid orders, and pre-booked fixed-price orders. In practical applications, actual settlement data can be obtained by calling external financial modules through API interfaces to ensure the accuracy of settlement data for each account (including but not limited to drivers, fleets, labor services, channels, and the company itself) and to support subsequent comparative analysis.

[0088] The Account Income and Expenditure Settlement Module 235 can be used to collect the actual income and expenditure of different account types corresponding to instant orders, postpaid orders, and pre-booked fixed-price orders, thus obtaining actual account data. In practical applications, external financial modules can be called through API interfaces to obtain the actual income and expenditure results of each account for the above three order types. Through accurate calculation of actual account data, a solid data foundation is provided for the final financial report.

[0089] In an alternative embodiment, such as Figure 4 As shown, the business logic layer 230 may also include a routing-based front-end interaction interface 236; the front-end interaction interface 236 may be used to: receive and forward financial verification instructions from the front-end project 100; and receive expected settlement data from the real-time order calculation module and the pre-order calculation module, actual clearing data from the actual clearing and settlement module, and / or actual account data from the account income and expenditure settlement module; perform verification processing on the expected settlement data, actual clearing data, and / or actual account data to obtain financial verification data recognizable by the front-end project 100, specifically including: for the actual clearing data and / or actual account data, traversing each key-value pair in the expected value dictionary corresponding to the expected settlement data to generate a corresponding structured comparison object; generating Chinese tags corresponding to the structured comparison object through tag mapping, and calculating the difference between the original value and the actual value of the structured comparison object to obtain clearing verification data and / or account verification data; and feeding back the clearing verification data and / or account verification data as financial verification data to the front-end project 100.

[0090] In practice, the front-end interaction interface 236 performs secondary processing on the result data from modules 231-235. It determines whether the verification type is settlement verification or account verification, it iterates through each key-value pair in the expected value dictionary corresponding to the expected settlement data, and dynamically generates a structured comparison result object. Taking settlement verification as an example, it dynamically generates corresponding Chinese tags (e.g., “driver settlement income”) based on the key name (e.g., 'driver_ledger') through tag mapping. It retains the original string format of the expected value (expected settlement data) and the actual value (actual settlement data), and performs precise difference calculation. It can perform numerical subtraction on the expected and actual settlements based on the decimal high-precision library, retaining two decimal places for the result. Then, it performs structured aggregation, appending the dictionary object containing the Chinese tags, expected settlement data, actual settlement data, and the difference to the result list to obtain the settlement verification data. The secondary processing method for account verification is similar, yielding account verification data, which will not be elaborated further in this invention. Through the secondary processing shown above, we ensure that the information presented to the user is both accurate and easy to understand.

[0091] This invention provides a financial verification system for ride-hailing orders, including a front-end project based on the Vue.js framework and a back-end platform based on the Flask MTV pattern. The front-end project sends financial verification instructions input by the user through a user interface to the back-end platform. The back-end platform responds to the financial verification instructions by performing financial verification operations, obtaining financial verification data, and feeding the data back to the front-end project. The front-end project also displays the financial verification data through the user interface. This invention has at least the following beneficial effects:

[0092] 1) Multi-order type support: Traditional accounting software typically only handles single-type orders, while this invention can simultaneously process multiple order types (such as instant orders, postpaid orders, and pre-booked fixed-price orders), and accurately handles different payment, advance payment, price modification, and refund operations for each order type. This greatly improves the applicability and flexibility of account reconciliation.

[0093] 2) Simulates a real-world environment: The system can simulate a real trading environment within the company, ensuring that the testing process closely resembles actual operations. This allows for more accurate evaluation of the system's performance and accuracy, reducing risks after deployment.

[0094] 3) Automation and Efficiency: Traditional manual account reconciliation processes are not only time-consuming and labor-intensive, but also prone to errors. This system significantly improves the efficiency and accuracy of account reconciliation by automating order-related financial operations and quickly calculating the expected income and expenditure results for drivers, fleets, channels, and the company.

[0095] 4) Comprehensive Comparison Function: This system not only calculates expected results but also compares them with actual results, helping to identify potential problems and correct them in a timely manner. This comprehensive comparison function helps ensure the consistency and reliability of financial data, improving the overall quality of financial management.

[0096] 5) Adapted to the characteristics of the ride-hailing industry: In response to the rapid development of the ride-hailing industry and its unique business model (such as multiple order types and complex payment methods), the system has been specially optimized to better meet the special needs of this industry and provide more accurate and efficient financial solutions.

[0097] To enhance the understanding of those skilled in the art regarding the application of the ride-hailing order financial reconciliation system proposed in the embodiments of the present invention, the embodiments of the present invention also provide a ride-hailing order financial reconciliation method, applied to the aforementioned ride-hailing order financial reconciliation system, such as... Figure 5 As shown, it may include at least the following steps S501 to S505:

[0098] In step S501, the front-end project responds to the user's operation from the user interaction page, generates a financial verification instruction for the target order, and sends the financial verification instruction to the back-end platform.

[0099] When processing a target order, the specific processing flow can first be determined based on the financial verification instructions entered by the user through the user interface, including the order identifier (such as the order number), verification type, and order environment.

[0100] In step S502, the backend platform retrieves the relevant order information through the financial module according to the information retrieval rules that match the order type of the target order.

[0101] If the verification type is "clearance verification", the corresponding clearance verification process will be initiated, which involves the acquisition and calculation of expected clearance data and actual clearance data in the subsequent business logic layer; if the verification type is "account verification", the account verification process will be followed, which involves the acquisition and calculation of expected account data and actual account data in the subsequent business logic layer 230.

[0102] Before executing the corresponding verification process, relevant data can be queried through the backend platform's API interface to obtain basic order information, including order information extracted from the order table, financial table, and capacity table, in order to aggregate basic order details, financial status, and settlement status. Then, based on the basic order information, a completion check can be performed on the target order; if the target order is not completed, an incomplete status notification is sent to the frontend project, and the process is terminated; if the target order is completed, it is determined whether the target order has been prepaid or paid; if the target order has not been prepaid or paid, an unpaid status notification is sent to the frontend project, and the process is terminated.

[0103] For target orders that have already been paid or prepaid, determine the order type based on the basic order information, such as instant orders, postpaid orders, and pre-booked fixed-price orders. Retrieve relevant order-specific information based on the order type, such as information on related work orders, including details such as the driver's settlement type (normal settlement, no settlement, or partial settlement), passenger trip fare, surcharges, and refund amount, as well as trip fare, surcharges, settlement snapshots, and commission rates.

[0104] Step S503: Determine the different settlement scenarios corresponding to each order type based on the order-related information, and calculate the expected settlement data of the target order based on the expected settlement rules that match the different settlement scenarios of different order types.

[0105] Before calculating the expected settlement data for the target order, a tiered verification mechanism can be used to pre-verify the order-related information to obtain usable order-related information. The tiered verification mechanism includes: verifying the basic status of the order, the integrity of the order data, and / or the consistency of the commission rate based on the order-related information, and filtering invalid / abnormal orders; and / or processing the order-related information according to multi-dimensional data processing rules that match different order types. The multi-dimensional data processing rules include: advance payment-payment linkage processing rules, special fee processing rules, work order management rules, and commission rate standardization rules.

[0106] For details on the implementation of the above mechanisms / rules, please refer to Figure 1 The corresponding description of a financial reconciliation system for ride-hailing orders will not be elaborated here.

[0107] In practical applications, the calculation of expected settlement data for target orders can be implemented based on the business logic layer of the backend platform. This business logic layer has corresponding expected settlement calculation rules configured for different order types and settlement scenarios. Specifically, the different settlement scenarios corresponding to each order type include, but are not limited to: separate settlement - no work order refund or work order refund but driver normal settlement; unified settlement - no work order refund or work order refund but driver normal settlement; separate settlement - work order refund and driver partial settlement; separate settlement - work order refund but driver not participating in settlement; separate withdrawal - normal settlement - channel surcharge refund participating in commission; separate withdrawal - normal settlement - channel surcharge refund not participating in commission; unified withdrawal - normal settlement - channel surcharge refund participating in commission; unified withdrawal - normal settlement - channel surcharge refund not participating in commission; separate withdrawal - partial refund and partial settlement - channel surcharge refund participating in commission; separate withdrawal - partial refund and partial settlement - channel surcharge refund not participating in commission. The terms and conditions are as follows: Commission-based withdrawal, unified withdrawal - partial refund and partial settlement - channel surcharge refund participating in commission-based withdrawal, unified withdrawal - partial refund and partial settlement - channel surcharge refund not participating in commission-based withdrawal, separate withdrawal - no settlement before payment - channel surcharge refund participating in commission-based withdrawal, separate withdrawal - no settlement before payment - channel surcharge refund not participating in commission-based withdrawal, unified withdrawal - no settlement before payment - channel surcharge refund participating in commission-based withdrawal, unified withdrawal - no settlement before payment - channel surcharge refund not participating in commission-based withdrawal, separate withdrawal - no settlement after payment - channel surcharge refund participating in commission-based withdrawal, separate withdrawal - no settlement after payment - channel surcharge refund not participating in commission-based withdrawal, unified withdrawal - no settlement after payment - channel surcharge refund participating in commission-based withdrawal, and unified withdrawal - no settlement after payment - channel surcharge refund not participating in commission-based withdrawal, etc.

[0108] Step S504: Retrieve the actual clearing data and / or actual account data, compare them with the expected clearing data and / or expected account data to obtain clearing verification data and / or account verification data, and feed them back to the front-end project as financial verification data.

[0109] Actual clearing data and / or actual account data can be implemented based on the business logic layer of the backend platform. Clearing verification data and account verification data are obtained by calculating the difference between the actual clearing data and the expected clearing data, as well as the difference between the actual account data and the expected account data. This step is implemented based on the front-end interaction interface connecting the front-end interface and the front-end project. For specific implementation details, please refer to [reference needed]. Figure 1 The corresponding description of a financial reconciliation system for ride-hailing orders will not be elaborated here.

[0110] Step S505: The front-end project displays financial reconciliation data using a user interface.

[0111] Finally, the front-end project parses the financial verification data fed back from the back-end platform, converts it into display data for the user interface, and renders it for users to view.

[0112] This invention provides a method for financial reconciliation of ride-hailing orders, comprising: a front-end project responding to user operations from a user interaction page, generating a financial reconciliation instruction for the target order, and sending the instruction to a back-end platform; the back-end platform retrieving relevant order information through financial modules according to information retrieval rules matching the order type of the target order; determining different settlement scenarios for each order type based on the order information, and calculating expected settlement data for the target order based on expected settlement rules matching different settlement scenarios for different order types; the expected settlement data includes expected clearing data and / or expected account data; retrieving actual clearing data and / or actual account data, comparing it with the expected clearing data and / or expected account data to obtain clearing verification data and / or account verification data, which are then fed back to the front-end project as financial reconciliation data; and the front-end project displaying the financial reconciliation data using a user interaction interface. This invention introduces functions such as multi-order type support, simulation of a real environment, automated processing, and comprehensive comparison, providing a new and more efficient solution for financial management and account reconciliation in the ride-hailing industry.

[0113] It should be noted that other corresponding descriptions of the functional modules involved in the financial verification method for ride-hailing orders provided in this embodiment of the invention can be found in [reference needed]. Figure 1 The corresponding description of the system shown will not be repeated here.

[0114] Those skilled in the art will clearly understand that the specific working process of the systems, devices, modules and units described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.

[0115] Furthermore, the functional units in the various embodiments of the present invention can be physically independent of each other, or two or more functional units can be integrated together, or all functional units can be integrated into one processing unit. The integrated functional units described above can be implemented in hardware, or in software or firmware.

[0116] Those skilled in the art will understand that if the integrated functional unit is implemented in software and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or all or part of it, 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 computing device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of the present invention when running the instructions. 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.

[0117] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as a computing device, personal computer, server, or network device) related to program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the computing device, the computing device executes all or part of the steps of the methods described in the various embodiments of the present invention.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of the present invention, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to depart from the protection scope of the present invention.

Claims

1. A financial reconciliation system for ride-hailing orders, characterized in that, The system includes: A front-end project based on the MVVM pattern; wherein, the front-end project includes a View layer, a ViewModel layer, and a Model layer connected in sequence; the View layer is used to provide a user interface; the Model layer is used to obtain financial verification data from the back-end platform; the ViewModel layer is used to convert the financial verification data into display data for the user interface; And, a backend platform based on the Flask MTV model; wherein, the backend platform includes a basic database, a model processing layer, and a business logic layer connected in sequence; the basic database is used to acquire and store order-related information; the business logic layer is used to convert financial verification instructions from the front-end project into database model objects, and to analyze and process target data from the model processing layer to obtain financial verification data recognizable by the front-end project; the model processing layer is used to query / retrieve target data in the basic database based on the database model objects; The front-end project is used to send the financial verification instructions entered by the user through the user interface to the back-end platform; The backend platform is used to perform financial verification operations in response to the financial verification instruction, obtain financial verification data, and feed the financial verification data back to the frontend project; The front-end project is also used to display the financial reconciliation data through the user interface; The financial reconciliation instruction carries an order identifier, reconciliation type, and / or order environment; the reconciliation type includes account reconciliation and / or clearing reconciliation. The business logic layer includes at least one of the following: an order data acquisition module, a real-time order calculation module, a pre-booked order calculation module, an actual clearing and settlement module, and an account income and expenditure settlement module. The order data acquisition module is used to acquire order-related information based on the order identifier, and process the order-related information according to multi-dimensional data processing rules that match different order types to obtain target order information; The real-time order estimation module is used to obtain target order information from the order data acquisition module, and to estimate the expected settlement data of instant orders and postpaid orders under different settlement scenarios based on the basic order information and order-specific information in the target order information. The reservation order estimation module is used to obtain target order information from the order data acquisition module, and to estimate the expected settlement data for different settlement scenarios of the reservation fixed-price order based on the basic order information and order-specific information in the target order information. The actual settlement module is used to collect the actual settlement data corresponding to the instant orders, the postpaid orders, and the pre-booked fixed-price orders. The account income and expenditure settlement module is used to collect the actual income and actual expenditure of different account types corresponding to the instant order, the postpaid order and the pre-booked fixed price order, and obtain the actual account data; The business logic layer also includes a route-based front-end interaction interface; the front-end interaction interface is used for: Receive and forward financial reconciliation instructions from the aforementioned front-end project; and, Receive expected settlement data from the real-time order calculation module and the pre-order calculation module, actual clearing data from the actual clearing and settlement module, and / or actual account data from the account income and expenditure settlement module; The expected settlement data, actual clearing data, and / or actual account data are verified to obtain financial verification data identifiable by the front-end project, specifically including: For the actual clearing data and / or the actual account data, traverse each key-value pair in the expected value dictionary corresponding to the expected settlement data to generate a corresponding structured comparison object; The structured comparison object is generated by generating Chinese tags through tag mapping, and the difference between the original value and the actual value of the structured comparison object is calculated to obtain clearing and verification data and / or account verification data. The clearing and verification data and / or the account verification data are fed back to the front-end project as financial verification data.

2. The system according to claim 1, characterized in that, The backend platform is also used to manage database operations based on the SQLAlchemy framework, specifically for: The ORM (Object-Relational Mapping) technology simplifies the SQL writing for the model processing layer when querying / retrieving target data in the base database, and queries / retrieves the target data based on the mapping relationship between the database model object and the database table structure; And / or, Utilize marshmallow technology to achieve data serialization / deserialization with the aforementioned front-end project; and / or, The third-party interface is called through Python's requests library to achieve API communication with at least one finance-related module; wherein the finance-related module includes at least one of the following: order payment module, account management module, financial accounting module, and work order business module.

3. The system according to claim 1, characterized in that, The ViewModel layer is also used to establish two-way data binding between the View layer and the Model layer, specifically for: Data binding technology is used to convert financial reconciliation data from the backend platform into display data for the user interface; The data binding technology includes at least one of the following: declarative binding, reactive listening, event-driven updates, and virtual DOM optimization. And / or, The DOM event listening technology is used to convert user operations from the View layer into financial reconciliation instructions that can be recognized by the backend platform. The DOM event listening technology includes at least one of operation binding, mapping processing, input update, data pass-through, and decoupled interaction.

4. The system according to claim 1, characterized in that, The order data acquisition module is also used for: Before processing the order-related information according to multi-dimensional data processing rules that match different order types, the order-related information is pre-verified according to a hierarchical verification mechanism to obtain usable order-related information.

5. A method for financial verification of ride-hailing orders, characterized in that, The financial verification system for ride-hailing orders as described in any one of claims 1 to 4, the method comprising: The front-end project responds to user actions from the user interaction page, generates a financial verification instruction for the target order, and sends the financial verification instruction to the back-end platform; the financial verification instruction carries the order identifier, verification type, and / or order environment; The backend platform retrieves relevant order information through the financial module based on information retrieval rules that match the order type of the target order; the order types include instant orders, postpaid orders, and pre-booked fixed-price orders. Based on the order-related information, different settlement scenarios corresponding to each order type are determined. Based on the expected settlement rules that match the different settlement scenarios of different order types, the expected settlement data of the target order is calculated. The expected settlement data includes expected clearing data and / or expected account data. The actual clearing data and / or actual account data are retrieved and compared with the expected clearing data and / or expected account data to obtain clearing verification data and / or account verification data, which are then fed back to the front-end project as financial verification data. The front-end project uses a user interface to display the financial reconciliation data; The order-related information includes at least one of the following: order status, order type, channel ID, payment status, advance payment status, order amount, payment amount, refund amount, discount amount, basic commission rate, driver commission rate, insurance premium, surcharge amount, channel order placement fluctuation, channel commission rate, work order settlement method, and channel refund settlement method.

6. The method according to claim 5, characterized in that, The step of retrieving relevant order information through the finance-related module according to the information retrieval rules matching the order type of the target order includes: Retrieve basic order information through the aforementioned financial module; Perform a completion check on the target order based on the basic order information; If the target order has been prepaid or paid, the order type of the target order is determined based on the basic order information; Retrieve the corresponding order-specific information based on the order type; The basic order information includes at least one of the following: order status, order type, channel ID, payment status, advance payment status, order amount, payment amount, insurance premium, surcharge amount, and channel order placement fluctuation. The order-specific information includes at least one of the following: refund amount, discount amount, basic commission rate, driver commission rate, channel commission rate, work order settlement method, and channel refund settlement method.

7. The method according to claim 6, characterized in that, After performing a completion check on the target order based on the basic order information, the method further includes: if the target order is not completed, then sending an incomplete status notification to the front-end project. If the target order has been completed, determine whether the target order has been prepaid or paid. If the target order has not been prepaid or paid, a notification indicating that it has not been prepaid or paid will be sent to the front-end project.

8. The method according to any one of claims 5 to 7, characterized in that, Before calculating the expected settlement data of the target order based on the expected settlement rules matching different settlement scenarios for different order types, the method further includes: The order-related information is pre-verified according to a hierarchical verification mechanism to obtain usable order-related information; wherein, the hierarchical verification mechanism includes: verifying the basic status of the order, the integrity of the order data, and / or the consistency of the commission rate based on the order-related information, and filtering invalid / abnormal orders; and / or, The order-related information is processed according to multi-dimensional data processing rules that match different order types; wherein, the multi-dimensional data processing rules include: advance payment-payment linkage processing rules, special fee processing rules, work order management rules, and commission rate standardization rules.

Images