Bill comparison method and device, equipment and medium
By using indicators in the bill comparison method to determine the correspondence and perform amount comparison, the manual operation error problem in cross-system reconciliation is solved, and a more efficient and accurate reconciliation process is achieved.
Patent Information
- Application Number
- CN202510572385.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-06
- Publication Date
- 2025-08-08
AI Technical Summary
The inter-span-system reconciliation in the prior art is prone to errors, and relying on manual operations leads to low efficiency and poor accuracy.
By acquiring the first target bill and the second target bill, determining the correspondence relationship using the indicator, comparing the first target data with the second target data, and warning is made based on the comparison result.
Improve the accuracy and efficiency of cross-system reconciliation, reduce the possibility of human error, and ensure data consistency and accuracy.
Smart Images
Figure CN120450879A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computers, and in particular to a bill comparison method, apparatus, device, and medium. Background Art
[0002] With the increasing popularity of internet commerce, more and more businesses are integrating online ordering systems as a new sales channel to increase sales, such as online food delivery platforms, online hotel platforms, and online retail platforms. This approach not only boosts business revenue but also brings new development opportunities to the internet.
[0003] However, this cross-platform operation mode from offline to offline also brings some inconveniences. Take financial reconciliation as an example. When users need to reconcile, they usually need to compare the transaction data recorded in the offline system with the transaction data in the online system one by one to identify inconsistent or abnormal transactions. This process usually relies on manual operation and is prone to errors. Summary of the Invention
[0004] The technical problem to be solved by the present disclosure is to overcome the defect that cross-system reconciliation in the prior art is prone to errors, and to provide a bill comparison method, device, equipment and medium.
[0005] The present disclosure solves the above technical problems through the following technical solutions:
[0006] In a first aspect, the present disclosure provides a bill comparison method, the method comprising:
[0007] Obtaining a first target bill and a second target bill; the first target bill includes at least one first target data, the second target bill includes at least one second target data, each first target data includes an indicator, and the indicator is used to indicate a corresponding relationship between each first target data and the second target data;
[0008] For each first target data, determining the corresponding second target data according to the indicator;
[0009] The amount in the first target data is compared with the amount in the corresponding second target data, and an early warning is issued based on the comparison result.
[0010] Optionally, obtaining the first target bill and the second target bill includes:
[0011] In response to the first target bill upload instruction, determining whether the request header of the first target bill upload instruction includes a first request token, the first request token being used to be generated by the front end when the format of the first target bill meets a preset format;
[0012] If the answer is yes, obtaining the first target bill;
[0013] Optionally, in response to the second target bill upload instruction, determining whether the request header of the second target bill upload instruction includes a second request token, the second request token being used to be generated by the front end when the format of the second target bill meets a preset format;
[0014] If the answer is yes, the second target bill is obtained.
[0015] Optionally, obtaining the first target bill and the second target bill includes:
[0016] Obtaining a transaction time range, a first initial bill, and a second initial bill, wherein the first initial bill includes at least one first initial data, and the second initial bill includes at least one second initial data;
[0017] Determining at least one first target data from at least one first initial data according to a transaction time range to obtain a first target bill;
[0018] At least one second target data is determined from at least one second initial data according to the transaction time range to obtain a second target bill.
[0019] Optionally, the first initial data includes a transaction time node, and the first target data is the first initial data whose transaction time node satisfies a transaction time range.
[0020] Optionally, the second initial data includes a transaction time node, and the second target data is the second initial data whose transaction time node satisfies a transaction time range.
[0021] Optionally, the first target bill includes a first store identifier, and the second target bill includes a second store identifier;
[0022] For each first target data, before determining the corresponding second target data according to the indicator, the method includes:
[0023] Determine whether the first store identifier and the second store identifier are the same;
[0024] If the answer is yes, the step of determining the corresponding second target data according to the indicator for each first target data is executed.
[0025] Optionally, the method further comprises:
[0026] Accumulating the first amount in the first target bill to obtain a first total amount;
[0027] Accumulating the second amount in the second target bill to obtain a second total amount;
[0028] When the first total amount is different from the second total amount, an early warning is issued for the first total amount.
[0029] In a second aspect, the present disclosure provides a bill comparison device, comprising:
[0030] A first acquisition module is configured to acquire a first target bill and a second target bill; the first target bill includes at least one first target data, the second target bill includes at least one second target data, each first target data includes an indicator, and the indicator is configured to indicate a corresponding relationship between each first target data and the second target data;
[0031] A first determining module, configured to determine, for each first target data, corresponding second target data according to the indicator;
[0032] The first comparison module is used to compare the amount in the first target data with the amount in the corresponding second target data, and issue an early warning based on the comparison result.
[0033] In a third aspect, the present disclosure provides an electronic device, comprising a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement the bill comparison method of the first aspect.
[0034] In a fourth aspect, the present disclosure provides a computer-readable storage medium, in which at least one instruction, at least one program, code set or instruction set is stored, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement a bill comparison method as described in any one of the first aspects.
[0035] The positive progress of this disclosure is:
[0036] The present disclosure indicates the first target data from the first target bill and the second target data from the second target bill through an indication mark, and can determine the second target data corresponding to the first target data during the reconciliation process. By comparing the first target data and the second target data, cross-system reconciliation is achieved, thereby improving the accuracy and efficiency of reconciliation.
[0037] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] Figure 1 A schematic diagram of an application scenario of a bill comparison method provided by an exemplary embodiment of the present disclosure;
[0039] Figure 2 A first flow chart of a bill comparison method provided by an exemplary embodiment of the present disclosure;
[0040] Figure 3 A second flow chart of a bill comparison method provided by an exemplary embodiment of the present disclosure;
[0041] Figure 4 A third flow chart of a bill comparison method provided by an exemplary embodiment of the present disclosure;
[0042] Figure 5 A schematic diagram of a comparison result provided by an exemplary embodiment of the present disclosure;
[0043] Figure 6 A schematic diagram of modules of a bill comparison device provided by an exemplary embodiment of the present disclosure;
[0044] Figure 7 A schematic structural diagram of an electronic device provided by an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION
[0045] The following will clearly and completely describe the technical solutions in the embodiments of the present disclosure in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present disclosure.
[0046] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0047] See also Figure 1 , Figure 1 This is a schematic diagram of an application environment provided by an embodiment of the present application, which includes a front end 100 and a server 110. After the server 110 receives the first target bill and the second target bill uploaded by the front end 100, it can compare the first target bill and the second target bill, and finally obtain the bill comparison result.
[0048] Specifically, the server 110 obtains the first target bill and the second target bill sent by the front end 100; the first target bill includes at least one first target data, the second target bill includes at least one second target data, and each first target data includes an indicator identifier, which is used to indicate the correspondence between each first target data and the second target data; for each first target data, the corresponding second target data is determined according to the indicator identifier; the amount in the first target data and the amount in the corresponding second target data are compared, and an early warning is issued if the comparison result is characterized as different first target data.
[0049] In the embodiment of the present disclosure, Figure 1 The front end 100 shown can be a physical device such as a user's smartphone, desktop computer, tablet computer, laptop computer, digital assistant, or smart wearable device. Smart wearable devices can include smart bracelets, smart watches, smart glasses, and smart helmets. Of course, the front end 100 is not limited to the aforementioned physical electronic devices. It can also be software running on these electronic devices. For example, the front end 100 can be a webpage or application provided to the user by a service provider.
[0050] Optionally, the front end 100 may include a display screen, a storage device, and a processor connected via a data bus. The display screen can be used to display the first target bill and / or the second target bill, and can also be used to display the comparison results. The display screen can be a touch screen of a mobile phone or tablet computer, for example. The storage device is used to store the first target bill and / or the second target bill, or other data, and can be the memory of the front end 100, or a storage device such as a smart media card, secure digital card, or flash memory card. The processor can be a single-core or multi-core processor.
[0051] In the embodiment of the present application, the first target bill and / or the second target bill may be received as follows: Figure 1 The server 110 shown may also be other computer terminals having the same functions as a server, or similar computing devices. Furthermore, the server 110 may be replaced by a server system, a computing platform, or a server cluster comprising multiple servers.
[0052] For example, the server cluster includes multiple servers, each of which can be responsible for different steps in the overall solution. For example, the first server receives the first target bill and the second target bill sent by the front end. The second server determines the corresponding second target data for each first target data item based on the indicator. The third server compares the amount in the first target data item with the amount in the corresponding second target data item. The fourth server, based on the comparison results sent by the third server, issues a warning level for the first target data item where the first target data item and the second target data item differ.
[0053] Each server in the above-mentioned server cluster may establish a connection relationship via a wireless link or a wired link. Optionally, each server may be placed in the same computer room or in different computer rooms.
[0054] The following describes a bill comparison method provided by an embodiment of the present disclosure. Figure 2 It is a flowchart of a bill comparison method provided by an embodiment of the present disclosure. This specification provides method operation steps such as the embodiment or flowchart, but may include more or fewer operation steps based on conventional or non-creative work. The order of steps listed in the embodiment is only one way of executing the steps among many orders, and does not represent the only order of execution. When the actual system or server product is executed, it can be executed in the order shown in the embodiment or the accompanying drawings or in parallel (for example, in a parallel processor or multi-threaded processing environment). Specifically, Figure 2 As shown, the method may include:
[0055] S201. Obtain a first target bill and a second target bill.
[0056] The first target bill includes at least one first target data item, and the second target bill includes at least one second target data item. Each first target data item includes an indicator that indicates the corresponding relationship between each first target data item and the second target data item. The first target data item includes the amount, transaction time, transaction method, transaction channel, product type, offline order number, online order number, payment status, etc. The second target data item includes the amount, transaction time, transaction method, transaction channel, product type, online order number, payment status, etc.
[0057] Specifically, the first target data in the first target bill comes from the first system, and the second target data in the second target bill comes from the second system. For the sake of convenience, in the following embodiments, the first system can be the user's offline system, and the second system can be the online order system. The orders between the offline system and the online system will be linked, and vice versa.
[0058] Taking hotel reservations as an example, the first system is the PMS system (Property Management System), and the second system is the EBK system (EBOOKING, online order management system).
[0059] The first target bill and / or the second target bill are usually in the form of Excel (spreadsheet software), but are not limited thereto. They may also be in the form of other spreadsheet software and can be set specifically according to system requirements.
[0060] S202: For each first target data, determine the corresponding second target data according to the indicator.
[0061] Among them, the indicator can be an online order number from the online order system. In a specific usage scenario, when the online order system receives a new order, it will generate a corresponding online order number. When the user receives the order issued by the online system in the offline system, the offline system will record the online order number and generate an offline order number at the same time. In the reconciliation link, the online order number can be used to find the second target data corresponding to the first target data from the second target bill.
[0062] S203: Compare the amount in the first target data with the amount in the corresponding second target data, and issue an early warning based on the comparison result.
[0063] The first target data and the second target data indicated by the indicator mark are from the same order, but their specific data content, such as the amount, transaction time node, etc., are not necessarily exactly the same. Therefore, they need to be compared in the reconciliation process to avoid errors.
[0064] Specifically, it can be configured that when the difference in the amount between the first target data and the second target data is within a preset allowable range, the comparison result is considered identical; when the difference in the amount between the first target data and the second target data is outside the preset allowable range, the comparison result is considered different. The preset allowable range is set to, but is not limited to, ±0.1% and is specifically configured based on actual application scenarios. If the comparison result is different for the first target data, an early warning is issued, such as sending an error prompt to the user.
[0065] In one embodiment, step S201 specifically includes:
[0066] In response to the first target bill upload instruction, it is determined whether the request header of the first target bill upload instruction includes a first request token. If the determination is yes, the first target bill is obtained.
[0067] The first request token is used to be generated by the front end when the format of the first target bill meets the preset format.
[0068] Since the first target bill is uploaded by the front-end user, during the upload process, in order to reduce the load on the server, the front-end will usually verify the file format of the first target bill, and will only transmit the first target bill to the server if it is verified that the format of the first target bill meets the required format set by the server.
[0069] Therefore, the front-end typically uses the Upload component from Ant Design (a component library for front-end design) to parse the first target bill in the browser, specifically extracting the file header information for format verification. Only if this verification passes will the first target bill be uploaded to the server. For uploaded first target bills that pass format verification, the front-end typically adds a first request token to the upload instruction. The server only accepts the first target bill if the request header contains the first request token. This helps to preemptively filter out invalid files that do not meet the requirements.
[0070] In addition, for the first target order that is successfully uploaded to the server, the front-end will obtain the file_name (file name) and URL (Uniform Resource Locator) address from the upload interface and save it to the front-end page. At the same time, the server will download the first target order based on the URL and save it in the server's memory.
[0071] In one implementation, the number of the second target bills is at least one.
[0072] Taking hotel reservations as an example, the second target bill includes both current and prepaid bills, and the second target data in the current and prepaid bills are different. When determining the second target data corresponding to the first target data using the indicator, the current and prepaid bills can be traversed until the corresponding second target data is found.
[0073] In one embodiment, step S201 specifically includes:
[0074] In response to the second target bill upload instruction, it is determined whether the request header of the second target bill upload instruction includes a second request token. If the determination is yes, the second target bill is obtained.
[0075] The second request token is used to be generated by the front end when the format of the second target bill meets the preset format.
[0076] Since the second target bill is uploaded by the front-end user, during the upload process, in order to reduce the load on the server, the front-end will usually verify the file format of the second target bill, and will only transmit the second target bill to the server if it is verified that the second target bill format meets the required format set by the server.
[0077] Therefore, the front-end typically uses the Upload component in Ant Design to parse the second target bill in the browser, specifically extracting the file header information for format verification. The second target bill is only uploaded to the server if it passes the verification. For uploaded second target bills that pass format verification, the front-end typically adds a second request token to the upload instruction. The server only accepts the second target bill if the request header contains the second request token. This helps to preemptively filter out invalid files that do not meet the requirements.
[0078] Additionally, for any second order successfully uploaded to the server, the frontend retrieves the file_name and URL from the upload API and saves them to the frontend page. Simultaneously, the server downloads the second order based on the URL and stores it in the server's memory.
[0079] In one embodiment, the file format verification work can also be handled by the server. After the server receives the file passed from the front end, it verifies the file format and file size of the first target bill and / or the second target bill to ensure that the passed file meets the system requirements.
[0080] Through the above embodiment, it is ensured that only bills that meet the format requirements participate in the subsequent reconciliation process, thereby improving the efficiency and accuracy of the reconciliation process on the server side.
[0081] In one embodiment, in addition to directly uploading the first target bill and / or the second target bill by the front end, the front end can also upload the unprocessed first initial bill and / or the second initial bill, and the server will process the data on them. Figure 3 , step S201 further includes:
[0082] S2011. Obtain the transaction time range, the first initial bill, and the second initial bill.
[0083] The first initial bill includes at least one first initial data item, and the second initial bill includes at least one second initial data item. The data contents of the first initial data item and the second initial data item can be found in the first target data item and the second target data item, and are not further described here. The first initial bill and the second initial bill are obtained by uploading the first initial bill and the second initial bill item from the front end to the server end. File format verification can also be performed during the upload process. The method for performing file format verification can be found in the above embodiment and is not further described here. The transaction time range is the transaction time range selected by the user for reconciliation.
[0084] Regarding the acquisition of transaction time range, the user is provided with a selection of time ranges in the front-end interface. The user selects a transaction time range for reconciliation, and after providing the first initial bill and the second initial bill, the user clicks the upload button to upload them together to the server.
[0085] S2012. Determine at least one first target data from at least one first initial data according to the transaction time range, and obtain a first target bill.
[0086] Specifically, the first initial data includes a transaction time node, and the first target data is the first initial data whose transaction time node meets a transaction time range.
[0087] The server utilizes the Apache POI library (an interface for reading and writing files of first-initial invoices) to automatically parse the uploaded first-initial invoice and extract the first-initial data. This automated process eliminates manual intervention and enables fast and accurate data parsing and calculation, improving efficiency and accuracy. After completing the pre-reading operations for the first-initial invoice, the server parses the first-initial data and extracts the first-initial data. During the parsing process, the server first filters the first-initial data required for comparison based on the transaction time range transmitted by the front-end to obtain the first target data.
[0088] At the same time, the server stores the aggregated first target data in a temporary data structure to obtain the first target bill for subsequent processing by the reconciliation module.
[0089] S2013. Determine at least one second target data from at least one second initial data according to the transaction time range, and obtain a second target bill.
[0090] Specifically, the second initial data includes a transaction time node, and the second target data is the second initial data whose transaction time node meets the transaction time range.
[0091] The server utilizes the Apache POI library (an interface for reading and writing files of secondary initial invoices) to automatically parse uploaded secondary initial invoices and extract the secondary initial data. This automated process eliminates manual intervention and enables fast and accurate data parsing and calculation, improving efficiency and accuracy. After completing the pre-reading operations for the secondary initial invoice, the server parses the secondary initial data and extracts the secondary initial data. During the parsing process, the server first filters the secondary initial data required for comparison based on the transaction time range transmitted by the front-end to obtain the secondary target data.
[0092] At the same time, the server stores the aggregated second target data in a temporary data structure to obtain the second target bill for subsequent reconciliation module processing. In this way, even if there are multiple transactions on the same date, the amounts can be correctly aggregated, ensuring the accuracy of the data.
[0093] In one embodiment, in addition to verifying the file format, the server also needs to verify the stores to which the first target bill and the second target bill belong to ensure that the two parties performing reconciliation are from the same store to avoid unnecessary errors.
[0094] Specifically, the first target bill uploaded to the server along with the transaction time node may further include the first store identifier, and the second target bill may further include the second store identifier. Before step S202, the method further includes:
[0095] Determine whether the first store identifier and the second store identifier are the same. If the determination is yes, execute step S202.
[0096] In one embodiment, see Figure 4 , the method further comprises:
[0097] S401. Accumulate the first amount in the first target bill to obtain a first total amount.
[0098] Specifically, the server will traverse each first target data, automatically extract the transaction time node, indicator and amount in the first target data, and accumulate and store the amount according to the transaction time node and indicator to obtain the first total amount. In this way, even if there are multiple transactions on the same date, the amount can be correctly summarized, ensuring the accuracy of the data.
[0099] S402: Accumulate the second amount in the second target bill to obtain a second total amount.
[0100] Specifically, the server will traverse each second target data, automatically extract the transaction time node, indicator and amount in the second target data, and accumulate and store the amount according to the transaction time node and indicator to obtain the second total amount. In this way, even if there are multiple transactions on the same date, the amount can be correctly summarized, ensuring the accuracy of the data.
[0101] S403: When the first total amount is different from the second total amount, issue an early warning for the first total amount.
[0102] This embodiment uses automated data analysis and calculation to quickly and efficiently complete reconciliation operations regardless of the data volume. The automated process not only improves efficiency but also reduces the possibility of human error, ensuring the accuracy and reliability of reconciliation results.
[0103] In one embodiment, the method further comprises:
[0104] Compare the transaction time nodes in the first target data with the corresponding transaction time nodes in the second target data, and issue an early warning based on the comparison results.
[0105] In one embodiment, the method further comprises:
[0106] The number of the first target data for which the second target data has not been determined according to the indication identifier is counted, and an early warning is issued when the number is greater than a first number threshold.
[0107] In one embodiment, the method further comprises:
[0108] When the number of differences between the comparison results of the first target data and the second target data is greater than a second number threshold, an early warning is issued.
[0109] In one embodiment, the method further comprises:
[0110] When the total amount of the difference between the comparison results of the first target data and the second target data is greater than the total amount, an early warning is issued.
[0111] In one embodiment, the warning method in the above embodiment is described as follows:
[0112] Warnings are delivered via email, system messages, and text messages. After receiving warnings, users can easily view and manage all abnormal data through the front-end interface. This allows the system to quickly identify abnormal data and promptly notify users, improving risk management capabilities.
[0113] In one embodiment, the method further comprises:
[0114] Generate a reconciliation result based on the first target bill and the second target bill.
[0115] Among them, the reconciliation results include the number of first target data in the first target bill to be reconciled, the number of first target data determining the second target data according to the indicator, the number of first target data for which the second target data is not determined according to the indicator, the number of first target data with the same comparison results as the second target data, etc., for users to view and analyze.
[0116] In addition, taking hotel reservations as an example, for the first target data whose reconciliation result is that the second target data is not determined according to the indicator, notes are also set for selection, including but not limited to: 1. Online order number is not filled in / entered incorrectly, 2. Channel name is not filled in / entered incorrectly, 3. Amount is entered incorrectly / not filled in, 4. Offline system order amount splitting error of 0.01, 5. Room upgrade / room consumption at the hotel, 6. Partial cancellation / early departure, 7. The modified check-in and check-out dates are no longer in the current reconciliation cycle, 8. Other input reasons to help users better understand the causes and handling methods of abnormal orders.
[0117] For the reconciliation results, Figure 5 As an example, at the top of the interface are the total number of orders (i.e., the number of first target data in the first target bill for reconciliation in this embodiment), the number of matched orders (i.e., the number of first target data for which the second target data is determined according to the indicator in this embodiment), the number of unmatched orders (i.e., the first target data for which the second target data is not determined according to the indicator in this embodiment), the number of orders with difference in amount (the number of orders for which the comparison results of the first target data and the second target data are different), and the unmatched orders (the first target data for which the second target data is determined according to the indicator) are detailed below (the PMS order number is the offline order number in this embodiment).
[0118] In addition, users can also export reconciliation results for further review and record keeping. This design not only improves the user experience but also provides users with flexible reconciliation result management methods.
[0119] The bill comparison method provided in this embodiment includes three core reconciliation rules: (1) Amount matching rule, which compares the amount of the first target data with the amount of the second target data indexed by the indicator, and issues an early warning based on the comparison result; (2) Order integrity rule, which indexes the second target data corresponding to the first target data by the indicator, and marks it as an exception if it is missing; (3) Date consistency rule, which compares the transaction time node of the first target data with the transaction time node of the second target data indexed by the indicator, and issues an early warning based on the comparison result.
[0120] Based on reconciliation results, users can clearly understand the consistency and accuracy of transaction data from different sources and proactively identify any anomalies, effectively mitigating risks. The system also provides a variety of reconciliation rules and alert conditions, providing greater flexibility and adaptability. Users can customize reconciliation rules and alert conditions based on specific business needs to suit diverse business scenarios. This allows users to better meet diverse needs and improve business efficiency and risk management capabilities.
[0121] An exemplary embodiment of the present disclosure further provides a bill comparison device, see Figure 6 , the device comprises:
[0122] A first acquisition module 61 is configured to acquire a first target bill and a second target bill; the first target bill includes at least one first target data, the second target bill includes at least one second target data, each first target data includes an indicator, and the indicator is used to indicate a corresponding relationship between each first target data and the second target data;
[0123] A first determining module 62 determines, for each first target data, corresponding second target data according to the indicator;
[0124] The first comparison module 63 is configured to compare the amount in the first target data with the amount in the corresponding second target data, and issue an early warning if the comparison result indicates that the first target data is different.
[0125] In one embodiment, the first acquisition module 61 includes:
[0126] The first response unit is used to respond to the first target bill upload instruction and determine whether the request header of the first target bill upload instruction includes a first request token. The first request token is generated by the front end when the format of the first target bill meets the preset format. If the judgment is yes, the first target bill is obtained.
[0127] In one embodiment, the first acquisition module 61 includes:
[0128] The second response unit is used to respond to the second target bill upload instruction and determine whether the request header of the second target bill upload instruction includes a second request token. The second request token is generated by the front end when the format of the second target bill meets the preset format; if the judgment is yes, the second target bill is obtained.
[0129] In one embodiment, the first acquisition module 61 includes:
[0130] A first acquiring unit is configured to acquire a transaction time range, a first initial bill, and a second initial bill, wherein the first initial bill includes at least one first initial data and the second initial bill includes at least one second initial data;
[0131] The first determining unit is configured to determine at least one first target data from at least one first initial data according to a transaction time range, and obtain a first target bill.
[0132] The second determining unit is configured to determine at least one second target data from at least one second initial data according to a transaction time range to obtain a second target bill.
[0133] In one embodiment, the first initial data includes a transaction time node, and the first target data is the first initial data whose transaction time node meets the transaction time range.
[0134] In one embodiment, the second initial data includes a transaction time node, and the second target data is the second initial data whose transaction time node meets the transaction time range.
[0135] In one embodiment, the first target bill includes a first store identifier, and the second target bill includes a second store identifier;
[0136] Before executing the first determination module 62, the following steps are included:
[0137] The judgment module judges whether the first store identifier and the second store identifier are the same; if the judgment is yes, the first acquisition module 61 is executed.
[0138] In one embodiment, the apparatus further comprises:
[0139] The first accumulation module is used to accumulate the first amount in the first target bill to obtain a first total amount.
[0140] The second accumulation module is used to accumulate the second amount in the second target bill to obtain a second total amount.
[0141] When the first total amount is different from the second total amount, an early warning is issued for the first total amount.
[0142] Figure 7 This is a structural diagram of an electronic device provided in an exemplary embodiment of the present disclosure. Figure 7 The electronic device 700 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present disclosure.
[0143] like Figure 7 As shown, the electronic device 700 may be a general-purpose computing device, such as a server device. Components of the electronic device 700 may include, but are not limited to, the at least one processor 701, the at least one memory 702, and a bus 703 connecting different system components (including the memory 702 and the processor 701).
[0144] The bus 703 includes a data bus, an address bus, and a control bus.
[0145] The memory 702 may include a volatile memory, such as a random access memory (RAM) 7021 and / or a cache memory 7022 , and may further include a read-only memory (ROM) 7023 .
[0146] The memory 702 may also include a program tool 70270 (or utility) having a set (at least one) of program modules 7024, such program modules 7024 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.
[0147] The processor 701 executes various functional applications and data processing by running the computer program stored in the memory 702, such as the method provided in any of the above embodiments.
[0148] Electronic device 700 can also communicate with one or more external devices 704. This communication can occur via input / output (I / O) interface 705. Furthermore, model-generated electronic device 700 can also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via network adapter 706. As shown, network adapter 706 communicates with other modules of model-generated electronic device 700 via bus 703. It should be understood that, although not shown, other hardware and / or software modules can be used in conjunction with model-generated electronic device 700, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, RAID (RAID) systems, tape drives, and data backup storage systems.
[0149] It should be noted that although several units / modules or sub-units / modules of the electronic device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.
[0150] An embodiment of the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, which implements the method provided in any of the above embodiments when the program is executed by a processor.
[0151] The readable storage medium may include, but is not limited to, a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof.
[0152] In a possible implementation manner, the embodiments of the present disclosure may also be implemented in the form of a program product, which includes program code. When the program product is run on a terminal device, the program code is used to enable the terminal device to execute a method for implementing any of the above embodiments.
[0153] The program code for executing the present disclosure may be written in any combination of one or more programming languages, and may be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on the remote device.
[0154] While specific embodiments of the present disclosure have been described above, those skilled in the art will appreciate that these are merely illustrative and that the scope of protection of the present disclosure is defined by the appended claims. Those skilled in the art may make various changes or modifications to these embodiments without departing from the principles and essence of the present disclosure, and such changes and modifications are intended to fall within the scope of protection of the present disclosure.
Claims
1. A bill comparison method, characterized in that: The method comprises: Obtaining a first target bill and a second target bill; the first target bill includes at least one first target data, the second target bill includes at least one second target data, each first target data includes an indicator, and the indicator is used to indicate a corresponding relationship between each first target data and the second target data; For each first target data, determining the corresponding second target data according to the indicator; The amount in the first target data is compared with the amount in the corresponding second target data, and an early warning is issued based on the comparison result.
2. The bill comparison method according to claim 1, characterized in that: The obtaining of the first target bill and the second target bill includes: In response to a first target bill upload instruction, determining whether a request header of the first target bill upload instruction includes a first request token, where the first request token is generated by the front end when a format of the first target bill meets a preset format; If the answer is yes, obtaining the first target bill; and / or, in response to the second target bill upload instruction, determining whether the request header of the second target bill upload instruction includes a second request token, the second request token being used to be generated by the front end when the format of the second target bill satisfies a preset format; If the judgment is yes, the second target bill is obtained.
3. The bill comparison method according to claim 1, characterized in that: The obtaining of the first target bill and the second target bill includes: Obtaining a transaction time range, a first initial bill, and a second initial bill, wherein the first initial bill includes at least one first initial data, and the second initial bill includes at least one second initial data; Determining at least one first target data from the at least one first initial data according to the transaction time range, and obtaining the first target bill; At least one second target data is determined from the at least one second initial data according to the transaction time range to obtain the second target bill.
4. The bill comparison method according to claim 3, characterized in that: The first initial data includes a transaction time node, and the first target data is the first initial data whose transaction time node meets the transaction time range.
5. The bill comparison method according to claim 3, characterized in that: The second initial data includes a transaction time node, and the second target data is the second initial data whose transaction time node meets the transaction time range.
6. The bill comparison method according to claim 1, wherein: The first target bill includes a first store identifier, and the second target bill includes a second store identifier; Before determining the corresponding second target data according to the indicator for each first target data, the method includes: Determining whether the first store identifier and the second store identifier are the same; If the answer is yes, the step of determining the corresponding second target data according to the indicator for each first target data is performed.
7. The bill comparison method according to claim 1, wherein: The method further comprises: Accumulating the first amounts in the first target bills to obtain a first total amount; Accumulating the second amounts in the second target bills to obtain a second total amount; When the first total amount is different from the second total amount, an early warning is issued for the first total amount.
8. A bill comparison device, characterized in that: The device comprises: A first acquisition module is configured to acquire a first target bill and a second target bill; the first target bill includes at least one first target data, the second target bill includes at least one second target data, each first target data includes an indicator, and the indicator is configured to indicate a corresponding relationship between the first target data and the second target data; a first determining module, configured to determine, for each first target data, the corresponding second target data according to the indication identifier; The first comparison module is used to compare the amount in the first target data with the amount in the corresponding second target data, and issue an early warning based on the comparison result.
9. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the bill comparison method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that The storage medium stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the bill comparison method as described in any one of claims 1 to 7.