Reimbursement data checking and inputting method, enterprise internal shopping mall system, equipment and medium

Abstract

The invention provides a reimbursement data checking and inputting method, an enterprise internal shopping mall system, equipment and a medium, and the method comprises the steps: receiving reimbursement data pushed by at least one external fee control system; performing protocol analysis and field mapping on the reimbursement data, and converting the reimbursement data into standard data in an enterprise internal shopping mall system; performing security verification on the request for receiving the reimbursement data; after the security verification is passed, performing data integrity verification, invoice and order matching verification and business compliance verification on the standard data; if verification is passed, reimbursement data associated with the standard data is written into a database of the enterprise internal shopping mall system, and a success response is returned to the external fee control system; and if any item does not pass, an error response is returned to the external fee control system. By adopting the method, the efficiency and accuracy of reimbursement data processing are remarkably improved, and the security of data transmission and the compliance of the process are enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of enterprise data management, in particular, to a method for checking and entering accounting data, an enterprise internal mall system, a device and a medium. BACKGROUND

[0002] With the continuous expansion of enterprise procurement business, the interaction of accounting data between the enterprise internal mall system and the external cost control system becomes more frequent. The accounting data covers key content such as order information, invoice details, cost application, and is the core basis for enterprise financial compliance audit and fund settlement. The processing quality directly affects the smoothness of the financial process and the efficiency of enterprise operation.

[0003] In the prior art, the accounting data processing generally adopts the manual checking and entering mode. After completing the procurement, the employee needs to sort out the order vouchers and invoices and other materials and submit them to the financial department. The financial personnel need to search for relevant data in the enterprise internal mall system and the external cost control system respectively, manually compare the key information, and then manually enter the compliant accounting data into the internal mall system database to complete the accounting closed loop.

[0004] The prior art has the following significant defects: the manual checking and entering needs to complete the data searching, comparing and entering operation one by one, the operation process is tedious and time-consuming, and in the face of the increasing amount of accounting data of the enterprise, the processing efficiency is seriously insufficient, often resulting in accumulation and processing lag of accounting data, affecting the financial settlement progress and cross-department cooperation experience. SUMMARY

[0005] Therefore, the purpose of the present application is to provide a method for checking and entering accounting data, an enterprise internal mall system, a device and a storage medium, which not only significantly improves the efficiency and accuracy of accounting data processing, but also strengthens the security of data transmission and the compliance of the process.

[0006] In a first aspect, the embodiments of the present application provide a method for checking and entering accounting data, applied to an enterprise internal mall system, the method comprising: receiving accounting data pushed from at least one external cost control system; performing protocol analysis and field mapping on the accounting data to convert it into standard data inside the enterprise internal mall system; performing security verification on the request for receiving the accounting data; after passing the security verification, performing data integrity check, invoice and order matching check and business compliance check on the standard data; If the data integrity check, the invoice and order matching check, and the business compliance check all pass, write the expense report data associated with the standard data into the database of the enterprise internal mall system, and return a success response to the external fee control system; If any of the data integrity check, the invoice and order matching check, or the business compliance check fails, return an error response to the external fee control system.

[0007] Optionally, after writing the expense report data associated with the standard data into the database of the enterprise internal mall system, the method further comprises: Asynchronously pushing an expense report completion notification event to a business module of the enterprise internal mall system through a message queue to trigger an update of an order expense report state and a subsequent financial reconciliation process.

[0008] Optionally, the protocol parsing and field mapping of the expense report data to convert it into standard data within the enterprise internal mall system comprises: According to the configuration information corresponding to the external fee control system, calling a corresponding protocol parser to extract data field names; According to a pre-stored field mapping rule, mapping the extracted source data field names to corresponding standard field names, thereby generating the standard data.

[0009] Optionally, the security verification of the request to receive the expense report data comprises: Obtaining a sender identifier, a timestamp, and a first signature value from header information of the request; Verifying the validity of the timestamp; In the case where the timestamp is verified to be valid, obtaining a corresponding pre-allocated key according to the sender identifier; According to the sender identifier, the timestamp, the request body content of the expense report data, and the pre-allocated key, generating a second signature value according to a predetermined rule; Verifying whether the first signature value and the second signature value are consistent to complete the security verification.

[0010] Optionally, the data integrity check comprises: Performing a non-empty check on mandatory fields in the standard data, and performing a format check on specified fields; The mandatory fields at least include a reimbursement order number, an application agency name, and an invoice number; The format check includes verifying whether a date field conforms to a predetermined format, verifying whether an amount field is a positive number, and verifying whether a tax rate field conforms to a pre-set common tax rate value.

[0011] Optionally, the invoice and order matching verification comprises: retrieving, with the invoice code in the invoice information in the standard data as a core query condition, an order database of the enterprise internal mall system; if no matching order record is retrieved, determining that the invoice and order matching verification fails; if a matching order record is retrieved, performing an amount consistency verification based on the matching result.

[0012] Optionally, the amount consistency verification comprises: if the matching result is that a single invoice corresponds to a single order, verifying whether a deviation between a total amount of the invoice and a payment amount of the order is less than or equal to a first preset threshold value; if the matching result is that a single invoice corresponds to multiple orders, verifying whether a deviation between the total amount of the invoice and a sum of payment amounts of the multiple orders is less than or equal to the first preset threshold value.

[0013] In a second aspect, an embodiment of the present application provides an enterprise internal mall system, and the apparatus comprises: a reimbursement data receiving module configured to receive reimbursement data pushed from at least one external cost control system; a reimbursement data parsing module configured to perform protocol analysis and field mapping on the reimbursement data, and convert the reimbursement data into standard data inside the enterprise internal mall system; a request security verification module configured to perform security verification on a request of receiving the reimbursement data; a standard data verification module configured to, after the security verification, perform data integrity verification, invoice and order matching verification, and business compliance verification on the standard data; a reimbursement data writing module configured to, if the data integrity verification, the invoice and order matching verification, and the business compliance verification all pass, write reimbursement data associated with the standard data into a database of the enterprise internal mall system, and return a success response to the external cost control system; an error response returning module configured to, if any of the data integrity verification, the invoice and order matching verification, or the business compliance verification fails, return an error response to the external cost control system.

[0014] Optionally, the system further comprises a notification event completion module configured to: after the reimbursement data associated with the standard data is written into the database of the enterprise internal mall system, asynchronously push a reimbursement completion notification event to a business module of the enterprise internal mall system through a message queue, so as to trigger updating of an order reimbursement state and a subsequent financial reconciliation process.

[0015] Optionally, the protocol parsing and field mapping of the expense data converts the expense data into standard data within the enterprise internal mall system, and the protocol parsing and field mapping comprises: According to configuration information corresponding to the external expense control system, a corresponding protocol parser is called to extract a data field name; According to a pre-stored field mapping rule, the extracted source data field name is mapped to a corresponding standard field name, thereby generating the standard data.

[0016] Optionally, the security verification of the request for receiving the expense data comprises: A sender identifier, a timestamp, and a first signature value are obtained from header information of the request; The validity of the timestamp is verified; In the case where the timestamp is verified to be valid, a corresponding pre-allocated key is obtained according to the sender identifier; According to the sender identifier, the timestamp, a request body content of the expense data, and the pre-allocated key, a second signature value is generated according to a predetermined rule; The first signature value and the second signature value are verified to be consistent, so as to complete the security verification.

[0017] Optionally, the data integrity check comprises: Non-empty checking is performed on mandatory fields in the standard data, and format checking is performed on specified fields; The mandatory fields at least include a reimbursement order number, an application organization name, and an invoice number; The format checking comprises verifying whether a date field conforms to a predetermined format, verifying whether an amount field is a positive number, and verifying whether a tax rate field conforms to a preset common tax rate value.

[0018] Optionally, the invoice and order matching check comprises: Invoice information in the standard data is used as a core query condition to search an order database of the enterprise internal mall system; If no matching order record is searched, it is determined that the invoice and order matching check fails; If a matching order record is searched, an amount consistency check is performed based on a matching result.

[0019] Optionally, the amount consistency check comprises: If the matching result is that a single invoice corresponds to a single order, it is checked whether a deviation between a total amount of the invoice and a payment amount of the order is less than or equal to a first preset threshold value; If the matching result is that one invoice corresponds to multiple orders, it is checked whether a deviation between a total amount of the invoice and a sum of payment amounts of the multiple orders is less than or equal to the first preset threshold.

[0020] In a third aspect, the embodiments of the present application provide a computer device, comprising a processor, a memory and a bus, the memory stores machine readable instructions executable by the processor, when the computer device is running, the processor and the memory communicate through the bus, and the machine readable instructions are executed by the processor to perform the steps of the accounting data checking and entering method in any of the optional implementation manners of the first aspect.

[0021] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium, the computer readable storage medium stores a computer program, when the computer program is run by a processor, the steps of the accounting data checking and entering method in any of the optional implementation manners of the first aspect are performed.

[0022] The technical solutions provided by the present application include but are not limited to the following beneficial effects: The accounting data pushed from at least one external cost control system is received, which saves the operation of manually sorting and submitting the accounting vouchers and information by the employees, avoids the problems such as missing materials and submission delay in the manual submission process. At the same time, the data is directly pushed by the external cost control system, which ensures the timeliness and completeness of the accounting data acquisition, provides reliable data source support for the subsequent data processing link, and reduces the time cost of manual data collection.

[0023] The accounting data is protocol parsed and field mapped, and is converted into standard data in the internal mall system of the enterprise, which realizes the unified and standardized processing of heterogeneous data of different external cost control systems, and avoids the problems such as format error and field matching error in the manual data conversion process. It also ensures that the accounting data entering the system meets the unified standard, lays a foundation for the smooth development of the subsequent checking and storage link, and improves the standardization of data processing.

[0024] The request for receiving the accounting data is security verified, which effectively prevents the risks such as illegal access, data tampering and identity forgery in the data transmission process through a special security verification mechanism. Compared with the lack of strict security verification in manual processing, it ensures the legal source and transmission integrity of the accounting data, reduces the financial loss and compliance risk caused by the leakage and tampering of key financial data, and ensures the security of cross-system data interaction.

[0025] After passing the security verification, the standard data undergoes data integrity verification, invoice and order matching verification, and business compliance verification. This step achieves multi-dimensional automated verification of expense report data, covering key verification points that are easily overlooked in manual verification. It eliminates the need for finance personnel to search and compare data for each order, reducing the tediousness of manual operations and avoiding problems such as missing required fields, mismatched amounts, and non-compliant business practices caused by human error, thus improving the comprehensiveness and accuracy of data verification.

[0026] If all three verifications pass, the associated expense report data is written to the database and a success response is returned. This step automates and standardizes the writing of verified data, avoiding input errors and inconsistencies that may occur when manually entering data into the database. Simultaneously, a timely success response is sent to the external expense control system, clearly informing the system of the data processing result, reducing communication costs in cross-system collaboration, ensuring a smooth closed-loop expense report process, and improving the efficiency of data processing and cross-system collaboration.

[0027] If any verification fails, an error response is returned to the external expense control system. This step quickly locates the verification problem in the expense report data and reports it to the external expense control system, avoiding the need for repeated communication and confirmation after errors are discovered during manual verification. A clear error response helps relevant parties quickly identify and correct problems, reduces the time erroneous data remains, lowers the cost of subsequent error correction, and improves the timeliness of problem handling.

[0028] The aforementioned steps work together to comprehensively optimize the existing manual verification and data entry process. Through automatic data reception, standardized conversion of heterogeneous data, security verification, multi-dimensional automated validation, standardized writing, and response feedback, manual intervention is significantly reduced. This not only significantly improves the efficiency and accuracy of expense reimbursement data processing but also strengthens the security of data transmission and the compliance of the process. It effectively reduces the operational costs and compliance risks of corporate financial reimbursement and meets the needs of large-scale and standardized expense reimbursement data processing for enterprises.

[0029] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1The flowchart of a method for verifying and entering reimbursement data provided in Embodiment 1 of this application is shown; Figure 2 A flowchart of a standard data determination method provided in Embodiment 1 of this application is shown; Figure 3 A flowchart of a security verification method provided in Embodiment 1 of this application is shown; Figure 4 The flowchart of an invoice and order matching verification method provided in Embodiment 1 of this application is shown; Figure 5 This paper shows a schematic diagram of the structure of an internal e-commerce system provided in Embodiment 2 of this application; Figure 6 A schematic diagram of the structure of a computer device provided in Embodiment 3 of this application is shown. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0033] Example 1 To facilitate understanding of this application, the following is combined with... Figure 1 The flowchart illustrating the expense reimbursement data verification and entry method provided in Embodiment 1 of this application will be described in detail for Embodiment 1 of this application.

[0034] See Figure 1 As shown, Figure 1 The flowchart illustrates a method for verifying and entering reimbursement data according to Embodiment 1 of this application, wherein the method includes steps S101 to S103: S101: Receive expense reporting data pushed from at least one external expense control system.

[0035] Specifically, the external expense control system is an expense control system for multiple subsidiaries under the group, covering the group headquarters and subsidiaries of various business segments. It is used to manage expense reimbursement, invoice review and fund payment processes. The push frequency is set to daily timed, and the pushed data is limited to the reimbursement-related data of designated cooperative suppliers (several companies). The uniqueness of suppliers must be ensured by matching with the unified social credit code to prevent irrelevant data from entering the process.

[0036] The pushed expense report data is a structured data set containing three core parts: first, the main information of the expense report, such as the expense report number, the applicant organization, and the creation time; second, the list of payees, such as the payee name, the payee's account, and the payment amount; and third, the list of invoice information, such as the invoice number, the total price including tax, and the supplier's name. The whole set serves as the basic data unit for expense report processing, ensuring that subsequent steps have complete data support.

[0037] S102: Perform protocol parsing and field mapping on the expense report data, and convert it into standard data within the enterprise's internal e-commerce system.

[0038] Specifically, this process relies on a dual mechanism of "configurable field mapping and dynamic protocol parsing": First, dynamic protocol parsing is executed. When the system starts, all protocol parsers are preloaded. If the external expense control system interface protocol is REST, the Jackson utility class is called to extract data fields according to the preset JSON path (such as $.reimbursement_code to extract the expense report number, $.receive_list to extract the list of payees, and $.invoice_list to extract the list of invoices). If the protocol is SOAP, the DOM4J utility class is called to parse the XML format data through XPath expressions (such as / / reimbursement_code / text()).

[0039] During the parsing process, data from non-designated cooperative suppliers is automatically filtered out. By comparing the "payee name" in the data with the preset supplier list and corresponding unified social credit code, only the successfully matched data is retained for subsequent processes. Then, configurable field mapping is performed, and the matching of source fields and standard fields is completed based on the subsidiary dimension mapping relationship stored in the "Field Mapping Rules Table" (e.g., the "fb_no" field of a subsidiary's expense control system is mapped to the standard field "reimbursement_code" of the mall).

[0040] The mapping process also supports data format conversion. For example, if the "Payment Date" field of a subsidiary's expense control system is in the format of "yyyy / MM / dd", it will be automatically converted to the "yyyy-MM-dd" format required by the e-commerce platform using the SimpleDateFormat utility class. Furthermore, the field mapping rules can be configured visually through the e-commerce platform management backend. When adding a new subsidiary expense control system, no code modification is required, achieving "zero-code configuration integration".

[0041] S103: Perform security verification on the request to receive the expense report data.

[0042] Specifically, the security verification adopts a triple mechanism of "API key verification, data signature and HTTPS two-way authentication": First, the request identity is initially verified. When the external expense control system initiates a request, it needs to carry three key parameters in the HTTP request header: "X-System-Code" (sender identifier, such as 00000000 for the group headquarters and 00000001 for a subsidiary of a certain business segment), "X-Timestamp" (request timestamp, accurate to the second), and "X-Signature" (first signature value).

[0043] First, verify the validity of the timestamp: calculate the difference between the current system time and "X-Timestamp". If the difference exceeds 5 minutes, it is determined to be an invalid request, thereby preventing replay attacks (to prevent attackers from reusing expired request data); if the timestamp is valid, obtain the pre-allocated API key corresponding to the expense control system from the encrypted configuration center (which uses the AES-256 encryption algorithm to protect data) according to "X-System-Code" (each subsidiary's expense control system has its own exclusive key).

[0044] Next, the second signature value is generated: the complete string is concatenated in a fixed order of "X-System-Code, X-Timestamp, JSON string of expense data request body and pre-allocated API key", and then the string is encrypted and calculated using the SHA-256 hash algorithm. The resulting hash value is the second signature value. Finally, the first signature value and the second signature value are verified to be completely consistent. If they are consistent, the initial verification of identity and data integrity is passed.

[0045] Simultaneously, HTTPS two-way authentication is implemented: the e-commerce system deploys a server certificate issued by a CA, and the external expense control system deploys a client certificate issued by a CA. During the request process, both parties verify the validity of each other's certificates (such as whether they are valid and whether they were issued by a trusted CA), and the TLS 1.3 protocol is used to ensure the encryption of the transmission link. In addition, sensitive data in the request body (such as the recipient's account and fund_verify_code) must first be encrypted by the external expense control system using the e-commerce public key (RSA 2048 bits), and then decrypted by the e-commerce system using its private key after receiving the data, thus providing double protection for the security of sensitive information.

[0046] S104: After passing the security verification, perform data integrity verification, invoice and order matching verification, and business compliance verification on the standard data.

[0047] Specifically, data integrity verification is performed first: a verification rule base is built based on the "required field" requirement in the interface documentation, and a dual logic of "field non-empty verification and format verification" is adopted; field non-empty verification is implemented through JavaValidator framework annotations (such as @NotNull and @NotBlank), and the required fields to be verified include reimbursement form number, applicant organization name, recipient account, invoice number, etc. If any required field is missing, a "field missing" error is marked.

[0048] Format validation is performed on specific fields: Date fields (such as creation time, payment date, invoice date) must conform to the format "yyyy-MM-dd", validated using the regular expression "^\d{4}-\d{2}-\d{2}$"; Amount fields (such as payment amount, amount excluding tax) must be positive numbers, determined by BigDecimal.compareTo(BigDecimal.ZERO)>0; Tax rate fields must conform to preset common tax rate values ​​(0.03, 0.06, 0.13, etc.), validated by comparing with the preset tax rate list, and marked as errors if the format does not conform.

[0049] Next, perform invoice and order matching verification: The first step is to use the "invoice code" of the invoice information in the standard data as the core query condition to search for matching orders in the "order_invoice" table of the order database of the enterprise's internal mall system; if no matching record is found, the verification is directly determined to be unsuccessful, the status of the expense report is marked as "pending verification" and a log of reasons for non-matching is generated (including subsidiary identifier, invoice code, and processing time).

[0050] If a matching order record is found, first verify whether the "invoice header" and "order's affiliated organization name" are completely consistent (e.g., "a subsidiary of a certain group in a certain region" must be completely consistent with the order's affiliated organization). If the organizations are inconsistent, mark "organization mismatch" as an error. After the organizations are consistent, perform an amount consistency check based on the matching result (single invoice corresponding to a single order or multiple orders).

[0051] Finally, business compliance verification is performed: verification logic is designed for special scenarios in the interface documentation. First, for the prepayment reimbursement scenario: query the "prepayment table" in the mall, and verify whether there is a prepayment record that has been paid but not yet reimbursed in the "fund_verify_code" corresponding to the current reimbursement form, and the invoice issuance date must be later than the prepayment date. If both conditions are met, the verification passes. Second, for the scenario where the payee is an individual: use the regular expression "^[\u4e00-\u9fa5]{2,4}$" to determine whether the "payee name" is an individual's name. If it is an individual and the invoice "supplier_company_name" is one of the designated cooperative suppliers, it is necessary to verify whether the invoice remarks contain the "personal collection on behalf" identifier. If it does, the verification passes.

[0052] If any verification fails, a detailed error log containing "error fields, error reason and subsidiary identifier" is generated, stored on a dedicated log server, and an alarm mechanism is triggered (the error information is pushed to the email of the operations and maintenance personnel) to facilitate timely troubleshooting.

[0053] S105: If the data integrity verification, the invoice and order matching verification, and the business compliance verification all pass, the expense reimbursement data associated with the standard data is written into the database of the enterprise's internal e-commerce system, and a success response is returned to the external expense control system.

[0054] Specifically, data writing is implemented in batches using the MyBatis-Plus framework, writing to four core database tables according to table join logic: First, the "tb_reimbursement_main" table stores the main information of the reimbursement form, with the primary key "reimbursement_code"; second, the "tb_reimbursement_receiver" table stores the recipient information, which is joined to the main table through "reimbursement_code"; third, the "tb_reimbursement_invoice" table stores the invoice information, which is also joined to the main table through "reimbursement_code"; and fourth, the "tb_reimbursement_invoice_item" table stores the invoice line details, which is joined to the "tb_reimbursement_invoice" table through "invoice ID".

[0055] The write process uses Spring's declarative transaction management to ensure that data in all four tables is either written successfully or rolled back completely, avoiding data inconsistency (such as the main table being written successfully but the detail table failing to be written). The successful response returned to the external expense control system is in JSON format, for example {"code":0,"msg":"Data received successfully","success":true}, which conforms to the response specifications agreed upon in the interface documentation.

[0056] S106: If any of the data integrity verification, the invoice and order matching verification, or the business compliance verification fails, an error response is returned to the external expense control system.

[0057] Specifically, the error response is also in JSON format, clearly indicating the error reason and related fields, for example {"code":1,"msg":"Field[reimbursement_code] is missing","success":false}, which facilitates the external expense control system to quickly locate the problem; at the same time, the error log triggered by the error response will be synchronously recorded to the log server, and the log content includes information such as the time of error occurrence, subsidiary identifier, and request ID, supporting subsequent problem tracing.

[0058] In an optional implementation, after writing the expense reimbursement data associated with the standard data into the database of the enterprise's internal e-commerce system, the method further includes: The system asynchronously pushes a reimbursement completion notification event to the business modules of the enterprise's internal e-commerce system via a message queue to trigger the update of the order reimbursement status and subsequent financial reconciliation process.

[0059] Specifically, the message queue is implemented using RabbitMQ, and the pushed "reimbursement completion notification event" includes key business fields: reimbursement form number, associated order number, processing result (such as "reimbursement successful"), and processing time, ensuring that the business module can obtain complete reimbursement information.

[0060] The purpose of asynchronous push is to avoid synchronous processing blocking the main process and improve system response efficiency. The subsequent processes triggered after the push include: first, the "Order Management Module" of the mall updates the order reimbursement status (from "Pending Reimbursement" to "Reimbursed"); second, the "Financial Reconciliation Module" generates reconciliation tasks (linking reimbursement forms and order data for financial personnel to verify), so as to achieve seamless connection between the reimbursement process and subsequent business.

[0061] In an optional implementation, see Figure 2 As shown, Figure 2The flowchart of a standard data determination method provided in Embodiment 1 of this application is shown. The step of performing protocol parsing and field mapping on the expense report data to convert it into standard data within the enterprise's internal e-commerce system includes steps S201-S202: S201: Based on the configuration information corresponding to the external expense control system, call the corresponding protocol parser to extract the data field names.

[0062] Specifically, the configuration information is stored in the "Expense Control System Configuration Table" of the e-commerce system database. Each configuration corresponds to the expense control system of a subsidiary and includes the following core fields: system_code (unique system identifier), protocol type (REST / SOAP), request URL (uniformly / members / expense / push, with independent access routes deployed by each subsidiary), and field mapping rule ID (associated with the "Field Mapping Rule Table").

[0063] When the system starts, all protocol parsers (REST parser, SOAP parser) are preloaded. After receiving a request, the corresponding parser is automatically called according to the "protocol type" of the current fee control system in the "fee control system configuration table". When the parser extracts fields, it strictly follows the field paths agreed upon in the interface documentation (such as the JSON path of the REST protocol and the XPath of the SOAP protocol) to ensure that the extracted field names are completely consistent with the field names of the data pushed by the fee control system.

[0064] The parsing process also executes supplier filtering logic: extract the "payee name" and "supplier unified social credit code" from the data, compare them with the preset list of designated cooperative suppliers and their corresponding codes, retain only the data fields that match successfully, filter out the data of non-designated suppliers, and prevent invalid data from entering the subsequent mapping process.

[0065] S202: According to the pre-stored field mapping rules, the extracted source data field names are mapped to the corresponding standard field names, thereby generating the standard data.

[0066] Specifically, the field mapping rules are pre-stored in the "Field Mapping Rules Table" and configured by subsidiary dimension (i.e., each subsidiary's expense control system has independent mapping rules). Supported mapping types include simple field name mapping (e.g., mapping subsidiary expense control "fb_no" to e-commerce "reimbursement_code") and data format conversion (e.g., date format, numeric format).

[0067] Format conversion is achieved through utility classes: for example, when mapping date fields, if the field format of the subsidiary expense control system is "yyyy / MM / dd", the SimpleDateFormat utility class will be called to convert it to the mall's standard format "yyyy-MM-dd"; if the numeric field (such as amount) is a string type, it will be converted to BigDecimal type to avoid precision errors in subsequent calculations.

[0068] Mapping rules can be configured visually through the e-commerce management backend: When adding a new subsidiary expense control system, maintenance personnel only need to select the subsidiary, fill in the source field name, select the corresponding standard field name and format conversion rule in the backend, and complete the field mapping configuration without writing any code, achieving "zero development integration" and greatly shortening the integration cycle.

[0069] In an optional implementation, see Figure 3 As shown, Figure 3 The flowchart of a security verification method provided in Embodiment 1 of this application is shown, wherein the security verification of the request to receive the reimbursement data includes steps S301 to S305: S301: Obtain the sender identifier, timestamp, and first signature value from the header information of the request.

[0070] Specifically, the "Sender Identifier" field in the request header is "X-System-Code", which is a unique identifier assigned by the e-commerce system to each subsidiary's expense control system (e.g., 00000000 for the group headquarters, 00000001 for a certain business segment subsidiary), used to associate the configuration information and API key of the expense control system; the "Timestamp" field is "X-Timestamp", accurate to the second, in Unix timestamp or "yyyy-MM-dd HH:mm:ss" format to ensure time accuracy.

[0071] The field corresponding to the "first signature value" is "X-Signature", which is a hash value generated by the external expense control system according to the rules agreed upon with the mall. It is used to verify the identity and integrity of the request. When obtaining the three fields, the existence of the fields is checked first. If any field is missing, the security verification is directly determined to be unsuccessful and the request is rejected.

[0072] S302: Verify the validity of the timestamp.

[0073] Specifically, the timestamp validity verification logic is as follows: obtain the current system time (accurate to the second), calculate the difference between the current time and "X-Timestamp", if the difference is ≤ 5 minutes, the timestamp is considered valid; if the difference is > 5 minutes, it is considered invalid and the request is directly rejected.

[0074] The core purpose of this verification step is to prevent replay attacks: attackers may intercept historical request data and resend it. If the timestamp has no expiration date, attackers can perform illegal operations by resending it. The 5-minute expiration date not only ensures the time tolerance of normal requests (such as network latency) but also effectively resists replay attacks.

[0075] S303: If the timestamp verification is valid, obtain the corresponding pre-allocated key based on the sender identifier.

[0076] Specifically, the pre-allocated key is an API key (a random string composed of letters, numbers, and special characters) generated separately by the e-commerce system when connecting to the expense control system of each subsidiary, and is used for signature calculation; the key is stored in the encryption configuration center and protected by the AES-256 encryption algorithm to avoid key leakage.

[0077] When obtaining the key, the e-commerce system queries the "Fee Control System Configuration Table" based on the "X-System-Code" (sender identifier) ​​to obtain the "Key Storage Address" corresponding to the identifier. Then, it retrieves the original API key from the corresponding address in the encryption configuration center using a decryption algorithm (AES-256 decryption). If the corresponding key cannot be found (e.g., the sender identifier is incorrect), the security verification is deemed to have failed.

[0078] S304: Generate a second signature value according to a predetermined rule based on the sender identifier, the timestamp, the request body content of the expense report data, and the pre-allocated key.

[0079] Specifically, the predetermined rule is "string concatenation and hash encryption": the first step is to concatenate the strings in a fixed order, namely "X-System-Code (sender identifier), X-Timestamp (timestamp), JSON string of the expense data request body and pre-allocated API key". When concatenating, ensure that there are no extra characters (such as spaces and line breaks) in each part to avoid affecting the signature result.

[0080] The second step is to use the SHA-256 hash algorithm to encrypt the concatenated complete string: The hash value generated by the SHA-256 algorithm is a 64-bit hexadecimal string, which is irreversible and unique. That is, different input strings will generate different hash values, and the same input string will inevitably generate the same hash value, ensuring the uniqueness of the signature and preventing tampering.

[0081] If the request body is empty (e.g., for test requests only), the "reimbursement data request body JSON string" part will be treated as an empty string during concatenation to ensure consistency of signature generation rules and avoid signature calculation failure due to an empty request body.

[0082] S305: Verify whether the first signature value and the second signature value are consistent to complete the security verification.

[0083] Specifically, signature consistency verification is a direct string comparison: if the "X-Signature" (first signature value) is exactly the same as the generated second signature value (case sensitive), then the identity legitimacy and data integrity verification are passed; if they are inconsistent, it is determined that the request may have been tampered with or the sender's identity is illegal, and the request is rejected.

[0084] After the signature verification is successful, the HTTPS two-way authentication result must also be considered: if the two-way authentication fails (e.g., the client certificate is invalid or the server certificate is not trusted), the security verification will still be considered unsuccessful even if the signatures match; only when the signatures match and the two-way authentication is successful, and the sensitive data is successfully decrypted (e.g., RSA2048-bit encrypted data can be decrypted normally), can the security verification be considered to have been completely successful.

[0085] In an optional implementation, the data integrity verification includes: Perform non-empty checks on the required fields in the standard data, and perform format checks on the specified fields.

[0086] Specifically, the data integrity verification is based on a "verification rule base". The rule base is configured according to the interface documentation requirements and can be updated through the e-commerce management backend (such as adding required fields or adjusting format rules). Non-empty checks and format checks are performed simultaneously. If either check fails, the overall data integrity verification fails, avoiding efficiency losses caused by step-by-step verification.

[0087] The non-empty check targets core fields necessary for the reimbursement process, including the reimbursement form number, applicant organization name, invoice number, recipient account, payment amount, and invoice date, ensuring sufficient basic data for subsequent order matching and financial reconciliation. If a field value is null, an empty string, or contains only spaces, the non-empty check is considered to have failed.

[0088] The format check targets fields with clearly defined data types. In addition to date, amount, and tax rate fields, it also includes "invoice type" (which must be a preset enumerated value, such as VAT special invoice and VAT ordinary invoice) and "reimbursement status" (which must be a preset status value, such as pending review or submitted). This ensures that the field format conforms to the data storage and business logic requirements of the e-commerce system. When the format check fails, the error log will clearly indicate "field name, error type (such as format error) and expected format" to facilitate problem localization.

[0089] The required fields include at least the reimbursement form number, the name of the applying organization, and the invoice number.

[0090] Specifically, the "reimbursement form number" is the unique identifier of the reimbursement form, used to associate data such as the payee, invoice, and details. It is also the core index field for subsequent queries and reconciliation. If it is missing, data association cannot be achieved. The "applying organization name" is used to determine the department to which the reimbursement form belongs. It is a key field for business compliance verification (such as organizational consistency). If it is missing, it is impossible to determine whether the reimbursement complies with the department's authority.

[0091] The "invoice number" is the unique identifier of an invoice. Together with the "invoice code," it forms the basis for verifying the uniqueness of an invoice. Without it, it is impossible to match and verify the invoice with the order, or to complete the subsequent invoice archiving and tax compliance checks. All three are "indispensable fields" in the reimbursement process, and any missing one will result in an error response.

[0092] The format check includes verifying whether the date field conforms to a predetermined format, verifying whether the amount field is a positive number, and verifying whether the tax rate field conforms to a preset common tax rate value.

[0093] Specifically, the "predefined format" for date field validation is "yyyy-MM-dd", which covers fields such as creation time, payment date, and invoice date. If the field format is not the predefined format, such as "yyyyMMdd" or "yyyy / MM / dd HH:mm:ss", it will be judged as a format error. The validation is implemented through regular expressions to ensure the universality and accuracy of the validation logic.

[0094] The "positive number" judgment of the amount field is implemented through the BigDecimal type: after converting the amount field value to BigDecimal, the compareTo(BigDecimal.ZERO) method is called. If the result is >0, it is a positive number; if the result is ≤0, it is judged as a format error. The BigDecimal type is used instead of double to avoid misjudgment caused by floating-point operation errors (such as 0.01 yuan may be judged as 0 due to double precision issues).

[0095] The "preset common tax rate values" for tax rate field validation include 0.03 (3%), 0.06 (6%), and 0.13 (13%), covering the tax rates for most enterprise procurement scenarios. If the tax rate field value is 0.05, 0.17, or other non-preset values, it is necessary to further validate whether it is a custom tax rate for a special scenario (which needs to be configured in advance in the management backend). If it is not configured, it is judged as a format error to ensure that the tax rate meets financial compliance requirements.

[0096] In an optional implementation, see Figure 4 As shown, Figure 4 The flowchart of an invoice-order matching verification method provided in Embodiment 1 of this application is shown, wherein the invoice-order matching verification includes steps S401 to S403: S401: Using the invoice code in the invoice information of the standard data as the core query condition, perform a search in the order database of the enterprise's internal e-commerce system.

[0097] Specifically, the "invoice code" is a unique code assigned to invoices by the national tax system, which, together with the "invoice number," constitutes the unique identifier of an invoice, and is therefore used as a core query condition. The target table for retrieval is the "order_invoice" table in the mall's order database. This table stores the relationship between orders and invoices, and its fields include "order_code (order number)," "invoice_code (invoice code)," "invoice_no (invoice number)," and "supplier_name (supplier name)," etc.

[0098] During retrieval, auxiliary query conditions are used simultaneously: the "supplier name" and "invoice line detail service name" in the standard data are fuzzily matched with "supplier_name" and "product_name" in the "order table (order_main)" associated with the "order_invoice" table. For example, the service name "printed notebook of a certain model" can match the product name "leather notebook of a certain model", which improves the matching success rate (avoiding matching failures caused by differences between the invoice service name and the order product name).

[0099] The retrieval process uses indexed queries: the "invoice_code" field of the "order_invoice" table has been indexed to ensure retrieval efficiency (even with a large amount of order data, results can be returned quickly); if the retrieval times out (e.g., more than 3 seconds), it will automatically retry once. If the retry fails, it is determined to be a retrieval error, the reimbursement status is marked as "pending processing", and an alarm is triggered.

[0100] S402: If no matching order record is found, the invoice and order matching verification is deemed to have failed.

[0101] Specifically, "No matching record found" includes two situations: First, there is no record corresponding to the "invoice_code" in the "order_invoice" table; second, there is a record, but the auxiliary query conditions (supplier name, service name) do not match, and there are no fuzzy matching results; both situations are judged as failing the verification.

[0102] If the transaction fails to pass, the status of the expense report is marked as "pending verification" and an error log is generated. The log content includes "subsidiary identifier", "invoice code", "reason for non-match (e.g., no corresponding order record, supplier mismatch)", "processing time", and "request ID". It is stored in the log server for the convenience of maintenance personnel to check later (e.g., to confirm whether it is due to order not being synchronized or incorrect invoice code entry).

[0103] When a data entry fails, the expense report is not rejected outright. Instead, it is marked as "pending verification." This is because there may be a delay where "the invoice has been sent but the order data has not been synchronized to the online store." The "manual verification" function can be used to supplement the matching later, improving the process's fault tolerance. At the same time, a "pending verification" response is returned to the external expense control system instead of a direct error response to avoid misjudgment.

[0104] S403: If a matching order record is found, perform an amount consistency check based on the matching result.

[0105] Specifically, "a matching record was found" must meet two conditions: first, the "invoice_code" must be an exact match; second, at least one of the auxiliary query conditions (supplier name, service name) must be a match (exact match or fuzzy match). After the conditions are met, the "invoice header" and "order belonging organization name" must be completely consistent. If the organizations are inconsistent, the verification is deemed to have failed and the error "organization mismatch" is marked.

[0106] After the institutional consistency check passes, different amount consistency check logics are executed based on the matching results of "single invoice corresponding to a single order" or "single invoice corresponding to multiple orders": the matching result is determined by the number of "order_code" in the "order_invoice" table. If only one "order_code" is associated, it is a single order match; if multiple are associated, it is a multiple order match. The core of the amount consistency check is to ensure that the deviation between the invoice amount and the order payment amount is within the allowable range and meets the financial accuracy requirements.

[0107] In an optional implementation, the amount consistency verification includes: If the matching result is a single invoice corresponding to a single order, then it is verified whether the deviation between the total amount of the invoice and the payment amount of the order is less than or equal to a first preset threshold.

[0108] Specifically, the "total invoice amount" corresponds to the "total_amount (total price including tax)" field in the standard data, and the "order payment amount" corresponds to the "pay_amount (actual payment amount)" field in the "order_main" table. Both are converted to BigDecimal type for calculation to avoid floating-point operation errors.

[0109] The "first preset threshold" is set to 0.01 yuan by default. This threshold can be adjusted by subsidiary dimension through the mall management backend (e.g., if a subsidiary's financial requirement deviation is ≤0.05 yuan, it can be configured separately) to adapt to the financial accuracy standards of different subsidiaries. The deviation is calculated as "|total invoice amount - order payment amount|". If the result is ≤ the first preset threshold, the verification is passed; otherwise, it is deemed to have failed.

[0110] If the deviation exceeds the threshold, the error log will record the "total invoice amount", "order payment amount", "deviation value" and "preset threshold" in detail, so that the finance staff can check the cause of the deviation (such as whether it is a difference in tax rate calculation, order discount not synchronized, etc.). At the same time, the reimbursement status will be marked as "pending review" and manual intervention is required for confirmation.

[0111] If the matching result is that a single invoice corresponds to multiple orders, then it is verified whether the deviation between the total amount of the invoice and the sum of the payment amounts of the multiple orders is less than or equal to the first preset threshold.

[0112] Specifically, the calculation method for the total payment amount of multiple orders is as follows: query the "pay_amount" field of all "order_code" corresponding to the matching records in the "order_main" table in batches, and use the add() method of BigDecimal to accumulate them (to avoid loss of precision during the accumulation process). After obtaining the sum, compare it with the total amount of the invoice.

[0113] During the accumulation process, the "order_code" and "pay_amount" of each order are recorded and stored in the "order details" field of the "reimbursement_record" table for easy subsequent verification (such as quickly locating the discrepancy in the total sum due to an incorrect amount in a particular order). If data anomalies occur during the accumulation process (such as "pay_amount" being null for a particular order), it is determined to be a verification anomaly, marked as "pending processing," and an alarm is triggered.

[0114] The deviation judgment logic is consistent with the single order scenario, that is, "|Total invoice amount - Total payment amount of multiple orders| ≤ First preset threshold". If it passes, the verification passes; otherwise, it fails. If it fails, detailed error information is also returned, which supports manual intervention for verification to ensure the accuracy and compliance of financial data. Example 2 See Figure 5 As shown, Figure 5 This illustration shows a structural diagram of an enterprise internal e-commerce system provided in Embodiment 2 of this application, wherein the system includes: The expense reimbursement data receiving module 501 is used to receive expense reimbursement data pushed from at least one external expense control system; The expense report data parsing module 502 is used to perform protocol parsing and field mapping on the expense report data, and convert it into standard data within the enterprise's internal e-commerce system; The security verification module 503 is used to perform security verification on the request to receive the reimbursement data. The standard data verification module 504 is used to perform data integrity verification, invoice and order matching verification, and business compliance verification on the standard data after the security verification is passed. The expense reimbursement data writing module 505 is used to write the expense reimbursement data associated with the standard data into the database of the enterprise's internal e-commerce system and return a success response to the external expense control system if the data integrity verification, the invoice and order matching verification, and the business compliance verification all pass. Error response return module 506 is used to return an error response to the external expense control system if any of the data integrity verification, the invoice and order matching verification, or the business compliance verification fails.

[0115] In an optional implementation, the system further includes a notification event completion module, for: After the expense reimbursement data associated with the standard data is written into the database of the enterprise's internal e-commerce system, an expense reimbursement completion notification event is asynchronously pushed to the business module of the enterprise's internal e-commerce system through a message queue to trigger the update of the order expense reimbursement status and subsequent financial reconciliation process.

[0116] In an optional implementation, the step of performing protocol parsing and field mapping on the expense report data to convert it into standard data within the enterprise's internal e-commerce system includes: Based on the configuration information corresponding to the external expense control system, the corresponding protocol parser is invoked to extract the data field names; According to the pre-stored field mapping rules, the extracted source data field names are mapped to the corresponding standard field names, thereby generating the standard data.

[0117] In an optional implementation, the security verification of the request to receive the reimbursement data includes: Obtain the sender identifier, timestamp, and first signature value from the header information of the request; Verify the validity of the timestamp; If the timestamp verification is valid, the corresponding pre-allocated key is obtained based on the sender identifier; A second signature value is generated according to a predetermined rule based on the sender identifier, the timestamp, the request body content of the expense report data, and the pre-allocated key; The security verification is completed by verifying whether the first signature value and the second signature value are consistent.

[0118] In an optional implementation, the data integrity verification includes: Perform non-empty checks on the required fields in the standard data, and perform format checks on the specified fields; The required fields include at least the reimbursement form number, the name of the applying organization, and the invoice number; The format check includes verifying whether the date field conforms to a predetermined format, verifying whether the amount field is a positive number, and verifying whether the tax rate field conforms to a preset common tax rate value.

[0119] In an optional implementation, the invoice-order matching verification includes: Using the invoice code within the invoice information of the standard data as the core query condition, a search is performed in the order database of the enterprise's internal e-commerce system. If no matching order record is found, the invoice-order matching verification is deemed to have failed. If a matching order record is found, an amount consistency check is performed based on the matching result.

[0120] In an optional implementation, the amount consistency verification includes: If the matching result is a single invoice corresponding to a single order, then verify whether the deviation between the total amount of the invoice and the payment amount of the order is less than or equal to a first preset threshold. If the matching result is that a single invoice corresponds to multiple orders, then it is verified whether the deviation between the total amount of the invoice and the sum of the payment amounts of the multiple orders is less than or equal to the first preset threshold.

[0121] Example 3 Based on the same application concept, see [link / reference] Figure 6 As shown, Figure 6 This illustration shows a structural schematic diagram of a computer device provided in Embodiment 3 of this application, wherein, as shown... Figure 6 As shown, the computer device 600 provided in Embodiment 3 of this application includes: The computer device 600 includes a processor 601, a memory 602, and a bus 603. The memory 602 stores machine-readable instructions that can be executed by the processor 601. When the computer device 600 is running, the processor 601 communicates with the memory 602 through the bus 603. When the machine-readable instructions are executed by the processor 601, the steps of the expense reimbursement data verification and entry method shown in Embodiment 1 are performed.

[0122] Example 4 Based on the same concept, this application also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the steps of the expense reimbursement data verification and entry method described in any of the above embodiments.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0124] The computer program product for verifying and entering reimbursement data provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0125] The enterprise internal e-commerce system provided in this application embodiment can be specific hardware on a device or software or firmware installed on the device. The system provided in this application embodiment has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0126] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some communication interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0128] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0130] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0131] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for verifying and entering reimbursement data, characterized in that, The method, applied to an enterprise's internal e-commerce system, includes: Receive expense reporting data pushed from at least one external expense control system; The expense report data is parsed and mapped using protocols, and then converted into standard data for the enterprise's internal e-commerce system. The request to receive the expense report data is subject to security verification. After passing the security verification, the standard data is subjected to data integrity verification, invoice and order matching verification, and business compliance verification. If the data integrity verification, the invoice and order matching verification, and the business compliance verification all pass, the expense reimbursement data associated with the standard data is written into the database of the enterprise's internal e-commerce system, and a success response is returned to the external expense control system. If any of the data integrity verification, the invoice and order matching verification, or the business compliance verification fails, an error response is returned to the external expense control system.

2. The method according to claim 1, characterized in that, After writing the expense reimbursement data associated with the standard data into the database of the enterprise's internal e-commerce system, the method further includes: The system asynchronously pushes a reimbursement completion notification event to the business modules of the enterprise's internal e-commerce system via a message queue to trigger the update of the order reimbursement status and subsequent financial reconciliation process.

3. The method according to claim 1, characterized in that, The process of parsing and mapping the expense report data to convert it into standard data within the enterprise's internal e-commerce system includes: Based on the configuration information corresponding to the external expense control system, the corresponding protocol parser is invoked to extract the data field names; According to the pre-stored field mapping rules, the extracted source data field names are mapped to the corresponding standard field names, thereby generating the standard data.

4. The method according to claim 1, characterized in that, The security verification of the request to receive the reimbursement data includes: Obtain the sender identifier, timestamp, and first signature value from the header information of the request; Verify the validity of the timestamp; If the timestamp verification is valid, the corresponding pre-allocated key is obtained based on the sender identifier; A second signature value is generated according to a predetermined rule based on the sender identifier, the timestamp, the request body content of the expense report data, and the pre-allocated key. The security verification is completed by verifying whether the first signature value and the second signature value are consistent.

5. The method according to claim 1, characterized in that, The data integrity verification includes: Perform non-empty checks on the required fields in the standard data, and perform format checks on the specified fields; The required fields include at least the reimbursement form number, the name of the applying organization, and the invoice number; The format check includes verifying whether the date field conforms to a predetermined format, verifying whether the amount field is a positive number, and verifying whether the tax rate field conforms to a preset common tax rate value.

6. The method according to claim 1, characterized in that, The invoice and order matching verification includes: Using the invoice code within the invoice information of the standard data as the core query condition, a search is performed in the order database of the enterprise's internal e-commerce system. If no matching order record is found, the invoice-order matching verification is deemed to have failed. If a matching order record is found, an amount consistency check is performed based on the matching result.

7. The method according to claim 6, characterized in that, The consistency verification of the amount includes: If the matching result is a single invoice corresponding to a single order, then verify whether the deviation between the total amount of the invoice and the payment amount of the order is less than or equal to a first preset threshold. If the matching result is that a single invoice corresponds to multiple orders, then it is verified whether the deviation between the total amount of the invoice and the sum of the payment amounts of the multiple orders is less than or equal to the first preset threshold.

8. An internal e-commerce system for enterprises, characterized in that, The system includes: The expense reimbursement data receiving module is used to receive expense reimbursement data pushed from at least one external expense control system; The expense report data parsing module is used to perform protocol parsing and field mapping on the expense report data, converting it into standard data within the enterprise's internal e-commerce system; A security verification module is used to perform security verification on requests to receive the reimbursement data. The standard data verification module is used to perform data integrity verification, invoice and order matching verification, and business compliance verification on the standard data after passing the security verification. The expense reimbursement data writing module is used to write the expense reimbursement data associated with the standard data into the database of the enterprise's internal e-commerce system and return a success response to the external expense control system if the data integrity verification, the invoice and order matching verification, and the business compliance verification all pass. The error response return module is used to return an error response to the external expense control system if any one of the data integrity verification, the invoice and order matching verification, or the business compliance verification fails.

9. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the expense reconciliation and entry method as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the expense reimbursement data verification and entry method as described in any one of claims 1 to 7.

Images